Quantcast
Channel: VMware Communities : Blog List - All Communities
Viewing all 3135 articles
Browse latest View live

NSX の HoL シナリオを PowerNSX でためす。Part.1

$
0
0

VMware NSX for vSphere は REST API で操作することができます。

しかし運用手順の自動化をするときには、API を直接利用するよりも、

PowerShell などを介して利用する方が便利なことがあります。

そこで、PowerShell ベースのツールである PowerNSX で HoL のシナリオを進めてみます。

 

今回は、下記のラボを利用します。

 

HOL-1803-01-NET - VMware NSX - Getting Started

http://labs.hol.vmware.com/HOL/catalogs/lab/3661

 

PowerNSX での NSX Manager / vCenter への接続。

このラボには PowerNSX の PowerShell モジュールがインストールされています。

そのため PowerShell を起動すれば、そのまま PowerNSX が利用可能です。

hol1803-powernsx-01-01.png

 

PowerShell を起動して NSX Manager / vCenter へ接続し、NSX のバージョンを確認しておきます。

※コマンドラインは「テキストの送信」でコピー&ペーストできます。

Connect-NsxServer -vCenterServer vcsa-01a.corp.local -Username administrator@corp.local -Password VMware1!

 

NSX 6.3.1 であることがわかります。

hol1803-powernsx-01-02.png

 

論理スイッチを作成する。

それでは、ラボのモジュール 2 のシナリオに沿って論理スイッチを作成します。

 

PowerNSX でのオブジェクト作成ではトランスポート ゾーンを指定することが多いので

あらかじめ Get-NsxTransportZone で取得しておきます。

$tz = Get-NsxTransportZone

$tz

hol1803-powernsx-01-03.png

 

論理スイッチを作成します。

New-NsxLogicalSwitch -TransportZone $tz -Name Prod_Logical_Switch

 

論理スイッチが作成されました。

hol1803-powernsx-01-03a.png

 

vSphere Web Client でも、論理スイッチが作成されたことが確認できます。

hol1803-powernsx-01-04.png

 

ラボマニュアルでの指定どおりの設定になっています。

hol1803-powernsx-01-05.png

 

ESG に論理スイッチを接続する。

作成した論理スイッチを、NSX Edge Service Gateway(ESG)のインターフェースに接続します。

対象の ESG は下記です。

Get-NsxEdge -Name Perimeter-Gateway-01

hol1803-powernsx-01-06.png

 

ESG のインターフェースの構成は、下記のように確認できます。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface | select index,name,isConnected,portgroupName

hol1803-powernsx-01-07.png

 

VM を接続する論理スイッチ(先ほど作成したもの)を取得します。

$ls = Get-NsxLogicalSwitch -TransportZone $tz -Name Prod_Logical_Switch

$ls

hol1803-powernsx-01-08.png

 

ESG に論理スイッチを接続します。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface -Index 7 | Set-NsxEdgeInterface -Name Prod_Interface -type internal -Connected:$true -PrimaryAddress 172.16.40.1 -SubnetPrefixLength 24 -ConnectedTo $ls

hol1803-powernsx-01-09.png

 

vSphere Web Client でもインターフェースの設定変更が確認できます。

hol1803-powernsx-01-10.png

 

論理スイッチへの VM の接続。

作成した論理スイッチに、VM を接続します。

本来であれば、論理スイッチには vNIC を指定して接続しますが、

今回の VM は、それぞれ vNIC を 1つだけもっているので VM を指定して接続します。

 

今回の対象 VM は下記(web-03a、web-04a)です。各 VM の vNIC は1つだけです。

Get-VM web-0[34]a.corp.local

Get-VM web-0[34]a.corp.local | Get-NetworkAdapter | ft -AutoSize

hol1803-powernsx-01-11.png

 

vNIC が1つだけなので、VM を指定して接続します。

$vms = Get-VM web-0[34]a.corp.local

Connect-NsxLogicalSwitch -VirtualMachine $vms -LogicalSwitch $ls

 

接続されました。論理スイッチのバッキング ポートグループが接続されています。

hol1803-powernsx-01-12.png

 

vSphere Web Client でも、論理スイッチに VM が接続されたことが確認できます。

hol1803-powernsx-01-13.png

 

そして HoL のシナリオにあるように、web-03a と web-04a とで ping による疎通確認ができるはずです。

 

つづく・・・


Open Wins When Open Works

NSX の HoL シナリオを PowerNSX でためす。Part.2

$
0
0

VMware NSX for vSphere の HoL シナリオを PowerNSX で進めてみます。

 

前回の投稿はこちら。

NSX の HoL シナリオを PowerNSX でためす。Part.1

 

今回も、下記のラボを利用します。

HOL-1803-01-NET - VMware NSX - Getting Started

http://labs.hol.vmware.com/HOL/catalogs/lab/3661

 

今回は、モジュール3 の分散論理ルーティングを実施します。

このシナリオでは、Edge Security Gateway(ESG)でのルーティングを

分散論理ルータ(DLR)によるルーティングに変更して、

さらに ESG / DLR で OSPF によるダイナミック ルーティングを有効化します。

 

ESG から DLR へのインターフェース付け替え。

 

まず PowerShell を起動して、NSX Manager と vCenter に接続しておきます。

Connect-NsxServer -vCenterServer vcsa-01a.corp.local -Username administrator@corp.local -Password VMware1!

 

このラボのサンプル Web ページ「Customer DB App」は、

はじめは NSX Edge Service Gateway(ESG)でルーティングをしています。

まず、ESG のインターフェースの構成を確認しておきます。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface | select index,name,type,isConnected,portgroupName | ft -AutoSize

hol1803-powernsx-02-01.png

 

構成変更のため、ESG からインターフェース App_Tier と DB_Tier を削除します。

vnic3、vnic4 がクリアされます。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface -Name  App_Tier | Clear-NsxEdgeInterface -Confirm:$false

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface -Name  DB_Tier | Clear-NsxEdgeInterface -Confirm:$false

hol1803-powernsx-02-02.png

 

新たにネットワークを接続する、DLR のインターフェース構成を確認しておきます。

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterInterface | %{$ip = $_.addressGroups.addressGroup; $_ | select Index,type,name,connectedToName,{$ip.primaryAddress},{$ip.subnetPrefixLength}} | ft -AutoSize

hol1803-powernsx-02-03.png

 

論理スイッチを接続します。

$ls = Get-NsxLogicalSwitch -Name App_Tier_Logical_Switch

Get-NsxLogicalRouter -Name Distributed-Router-01 | New-NsxLogicalRouterInterface -Name App_Tier -Type internal -ConnectedTo $ls -PrimaryAddress 172.16.20.1 -SubnetPrefixLength 24

 

接続する論理スイッチは、下記のように指定することもできます。

Get-NsxLogicalRouter -Name Distributed-Router-01 | New-NsxLogicalRouterInterface -Name DB_Tier -Type internal -ConnectedTo (Get-NsxLogicalSwitch -Name DB_Tier_Logical_Switch) -PrimaryAddress 172.16.30.1 -SubnetPrefixLength 24

hol1803-powernsx-02-05.png

 

DLR に、論理スイッチに接続したインターフェース App_Tier、DB_Tier が作成されました。

hol1803-powernsx-02-06.png

 

DLR で OSPF を有効化する。

DLR は、OSPF がまだ無効な状態です。

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | Get-NsxLogicalRouterOspf

hol1803-powernsx-02-07.png

 

DLR で OSPF を有効化します。

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | Set-NsxLogicalRouterRouting -EnableOspf -EnableOspfRouteRedistribution -RouterId 192.168.5.2 -ProtocolAddress 192.168.5.3 -ForwardingAddress 192.168.5.2 -Confirm:$false

hol1803-powernsx-02-08.png

 

OSPF Area を作成します。

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | New-NsxLogicalRouterOspfArea -AreaId 10 -Confirm:$false

hol1803-powernsx-02-09.png

 

DLR のアップリンク インターフェースに OSPF Area を追加します。

$if = Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterInterface -Name Transit_Network_01

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | New-NsxLogicalRouterOspfInterface -Vnic $if.index -AreaId 10 -Confirm:$false

hol1803-powernsx-02-10.png

 

分散ルータで OSPF が有効になりました。

hol1803-powernsx-02-11.png

 

OSPF のルート再配布テーブルに BGP の許可ルールを追加しておきます。

(本来ならルール編集がいいとは思いますが・・・)

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | New-NsxLogicalRouterRedistributionRule -Learner ospf -FromBGP -Action permit -Confirm:$false

 

 

NSX ESG に OSPF ルーティングを追加する。

NSX ESG も、まだ OSPF が無効です。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeRouting | Get-NsxEdgeOspf

hol1803-powernsx-02-12.png

 

ESG で OSPF を有効化します。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeRouting | Set-NsxEdgeRouting -EnableOspf -EnableOspfRouteRedistribution -Confirm:$false

hol1803-powernsx-02-13.png

 

OSPF Area を作成します。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeRouting | New-NsxEdgeOspfArea -AreaId 10 -Confirm:$false

hol1803-powernsx-02-14.png

 

ESG のインターフェースに OSPF Area を追加します。

$if = Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface -Name Transit_Network_01

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeRouting | New-NsxEdgeOspfInterface -Vnic $if.index -AreaId 10 -Confirm:$false

hol1803-powernsx-02-15.png

 

今回はルート再配布テーブルに許可ルールを追加してしまいます。

(こちらも本来はルール編集がいいとは思いますが・・・)

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeRouting | New-NsxEdgeRedistributionRule -Learner bgp -FromOspf -Action permit -Confirm:$false

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeRouting | New-NsxEdgeRedistributionRule -Learner ospf -FromBGP -FromConnected -Action permit -Confirm:$false

 

これで、ネットワーク構成を変更したあとも

HoL のサンプル Web ページ「Customer DB App」が表示できるようになるはずです。

 

つづく。

NSX の HoL シナリオを PowerNSX でためす。Part.3

$
0
0

ひきつづき、VMware NSX for vSphere の HoL シナリオを PowerNSX で進めてみます。

 

前回までの投稿はこちら。

NSX の HoL シナリオを PowerNSX でためす。Part.1

NSX の HoL シナリオを PowerNSX でためす。Part.2

 

今回も、下記のラボを利用します。

HOL-1803-01-NET - VMware NSX - Getting Started

http://labs.hol.vmware.com/HOL/catalogs/lab/3661

 

今回は、モジュール3 の続きです。

ここでは、この先に ECMP ルーティングの構成する準備として、

ラボに 2台目の NSX Edge Service Gateway(ESG)をデプロイします。

 

New-NsxEdge の都合上、クラスタでは DRS を有効にしてしまいます。

管理クラスタには NSX Controller も配置されているので、アンチアフィニティ ルールの都合上

可能なら DRS は有効にしておいた方がよい気がします。

ただし、ESG は基本的に常にトラフィックが発生するので

DRS を有効にしても、DRS のポリシーは必ずしも完全自動にはしなくてもよいかなと考えられます。

Get-Cluster RegionA01-MGMT01 | Set-Cluster -DrsEnabled:$true -Confirm:$false

hol1803-powernsx-03-00.png

 

ESG をデプロイする前に、New-NsxEdgeInterfaceSpec で

ESG のインターフェース設定を用意しておきます。

 

アップリンク側です。vNIC は vDS の分散ポートグループに接続します。

$vnic0 = New-NsxEdgeInterfaceSpec -Index 0 -Name Uplink -Type uplink -ConnectedTo (Get-VDPortgroup Uplink-RegionA01-vDS-MGMT) -PrimaryAddress 192.168.100.4 -SubnetPrefixLength 24

hol1803-powernsx-03-01.png

 

インターナル側です。vNIC は NSX の論理スイッチに接続します。

$vnic1 = New-NsxEdgeInterfaceSpec -Index 1 -Name Transit_Network_01 -Type internal -ConnectedTo (Get-NsxLogicalSwitch -Name Transit_Network_01) -PrimaryAddress 192.168.5.4 -SubnetPrefixLength 29

hol1803-powernsx-03-02.png

 

そして、NSX Edge をデプロイします。

New-NsxEdge -Name Perimeter-Gateway-02 -Username admin -Password "VMware1!VMware1!" -EnableSSH -Cluster (Get-Cluster RegionA01-MGMT01) -Datastore (Get-Datastore RegionA01-ISCSI01-COMP01) -FormFactor compact -Interface $vnic0,$vnic1 -FwEnabled -FwDefaultPolicyAllow

hol1803-powernsx-03-03.png

 

NSX Edge のデプロイは NSX のコンポーネントの中でも入力項目が多く失敗した時の悲しみが大きいので、

コマンドラインを用意しておくことで、成功率を上げたり、リトライしやすくすると便利かなと思います。

 

また経験上、Nsx Edge のデプロイが成功しない場合はまず下記のあたりを確認するとよさそうです。

  • デプロイ先のクラスタで DRS が有効になっているか。
  • インターフェースに指定した IP アドレスが正しいか。(ネットワーク アドレス的にも)
  • New-NsxEdgeInterfaceSpec や New-NsxEdge で指定しているオブジェクトが本当に存在しているか。
  • 指定したオブジェクトの名前が重複していないか。(同一 Edge での New-NsxEdgeInterfaceSpec の Name も)

 

まだまだ続く。

Unable to vMotion a virtual machine from one host to another

$
0
0

Unable to vMotion a virtual machine from one host to another. vMotion activity fails with the following error:-

Error code “The source detected that the destination failed to resume.
Heap dvfilter may only grow by 33091584 bytes (105325400/138416984), which is not enough for allocation of 105119744 bytes
vMotion migration [-1407975167:1527835473000584] failed to get DVFilter state from the source host <xxx.xxx.xxx.xxx>
vMotion migration [-1407975167:1527835473000584] failed to asynchronously receive and apply state from the remote host: Out of memory.
Failed waiting for data. Error 195887124. Out of memory

 

As a workaround configure a larger Heap size on a suitable target host (that can be rebooted after making the changes)

-To increase the Heap Size use type the following command on the target host.
esxcfg-module -s DVFILTER_HEAP_MAX_SIZE=276834000 dvfilter
-This requires a reboot of the ESXi host to take effect.
- Once the target host is up try vMotion the affected VM again to the target host and see if it's successful.

 

This is a known issue that the NSX team have been working upon for a while. As per VMware the default heap size is increased in ESXi 6.7 to resolve this issue.

NSX の HoL シナリオを PowerNSX でためす。Part.4

$
0
0

ひきつづき、VMware NSX for vSphere の HoL シナリオを PowerNSX で進めてみます。

 

前回までの投稿はこちら。

今回の内容をためすためには、Part.2 ~ Part.3 の内容を実施しておく必要があります。

NSX の HoL シナリオを PowerNSX でためす。Part.1

NSX の HoL シナリオを PowerNSX でためす。Part.2

NSX の HoL シナリオを PowerNSX でためす。Part.3

 

今回も、下記のラボを利用します。

HOL-1803-01-NET - VMware NSX - Getting Started

http://labs.hol.vmware.com/HOL/catalogs/lab/3661

 

これまでのシナリオでデプロイした NSX Edge Service Gateway(ESG)である

Perimeter-Gateway-02 を利用して、ECMP のルーティングを構成します。

 

追加した ESG のダイナミック ルーティングを設定する。

これまでのシナリオで ESG / DLR の OSPF を有効化していますが、

ESG 「Perimeter-Gateway-02」では OSPF が未設定なので、ここで設定します。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | Set-NsxEdgeRouting -RouterId 192.168.100.4 -EnableOspf -Confirm:$false

hol1803-powernsx-04-01.png

 

OSPF の Area ID を指定します。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | New-NsxEdgeOspfArea -AreaId 10 -Confirm:$false

hol1803-powernsx-04-02.png

 

OSPF のインターフェース マッピングを追加します。

$if = Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeInterface -Name Transit_Network_01

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | New-NsxEdgeOspfInterface -Vnic $if.index -AreaId 10 -Confirm:$false

hol1803-powernsx-04-03.png

 

既存の ESG では BGP が有効化されていますが、

Perimeter-Gateway-02 では 未設定なので、ここで有効にします。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | Set-NsxEdgeRouting -EnableBgp -LocalAS 65001 -Confirm:$false

hol1803-powernsx-04-04.png

 

BGP ネイバーを追加します。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | New-NsxEdgeBgpNeighbour -IpAddress 192.168.100.1 -RemoteAS 65002 -Confirm:$false

hol1803-powernsx-04-05.png

 

BGP と OSPF のルート再配布を有効化します。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | Set-NsxEdgeRouting -EnableOspfRouteRedistribution -EnableBgpRouteRedistribution -Confirm:$false

hol1803-powernsx-04-06.png

 

OSPF のルート再配布を設定します。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | New-NsxEdgeRedistributionRule -Learner ospf -FromBGP -FromConnected -Action permit -Confirm:$false

 

BGP のルート再配布を設定します。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | New-NsxEdgeRedistributionRule -Learner bgp -FromOspf -FromConnected -Action permit -Confirm:$false

hol1803-powernsx-04-07.png

 

ECMP を有効化する。

 

それでは、ESG と 分散論理ルータ(DLR)で ECMP を有効化します。

 

DLR「Distributed-Router-01」です。

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | Set-NsxLogicalRouterRouting -EnableEcmp -Confirm:$false

hol1803-powernsx-04-08.png

 

ESG「Perimeter-Gateway-01」です。

※今回は ファイアウォールの無効化を省略しています。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeRouting | Set-NsxEdgeRouting -EnableEcmp -Confirm:$false

hol1803-powernsx-04-09.png

 

ESG「Perimeter-Gateway-01」です。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | Set-NsxEdgeRouting -EnableEcmp -Confirm:$false

hol1803-powernsx-04-10.png

 

これで、ラボの ESG 、DLR で ECMP が構成されました。

シナリオにある、ルーティング情報やパスの切り替えが確認できるはずです。

 

まだ続く・・・

NSX の HoL シナリオを PowerNSX でためす。Part.5

$
0
0

今回は、PowerNSX で NSX Edge Service Gateway(ESG)によるロードバランサを構成します。

 

今回も、下記のラボを利用します。

HOL-1803-01-NET - VMware NSX - Getting Started

http://labs.hol.vmware.com/HOL/catalogs/lab/3661

 

ESG のデプロイ。

ロードバランサとして利用するため、新しい ESG をデプロイします。

 

まず PowerShell を起動して、NSX Manager と vCenter に接続しておきます。

Connect-NsxServer -vCenterServer vcsa-01a.corp.local -Username administrator@corp.local -Password VMware1!

 

ロードバランサで利用する場合も、デプロイされる ESG は同じ仮想アプライアンスです。

デプロイされるものは変わりませんが、

ここでは以前の投稿とは少しコマンドラインを変更してデプロイします。

NSX の HoL シナリオを PowerNSX でためす。Part.3

 

今回も、クラスタでは DRS を有効にしてしまいます。

Get-Cluster RegionA01-MGMT01 | Set-Cluster -DrsEnabled:$true -Confirm:$false

 

ESG の仮想アプライアンスの設定を用意します。

今回はパラメータを変数で事前定義してから NSX Edge の仮想アプライアンスをデプロイします。

$esg_name = "OneArm-LoadBalancer"

$password = "VMware1!VMware1!"

$esg_spec = "compact"

$cluster = Get-Cluster RegionA01-MGMT01

$ds = Get-Datastore RegionA01-ISCSI01-COMP01

$vm_folder = Get-Folder -Type VM -Name "Discovered virtual machine"

$esg_dgw = "172.16.10.1"

 

インターフェースの設定を用意します。

ワンアーム 構成のロードバランサなので、インターフェースは最小限の1つだけ作成します。

$vnic0_name = "WebNetwork"

$vnic0_nw = Get-NsxLogicalSwitch -Name Web_Tier_Logical_Switch

$vnic0_type = "internal"

$vnic0_ip = "172.16.10.10"

$vnic0_prefix = 24

$vnic0 = New-NsxEdgeInterfaceSpec -Index 0 -Name $vnic0_name -Type $vnic0_type -ConnectedTo $vnic0_nw -PrimaryAddress $vnic0_ip -SubnetPrefixLength $vnic0_prefix

 

ESG をデプロイします。

New-NsxEdge -Name $esg_name -Username admin -Password $password -Cluster $cluster -Datastore $ds -FormFactor $esg_spec -VMFolder $vm_folder -Interface $vnic0 -EnableSSH -FwEnabled -FwDefaultPolicyAllow

hol1803-powernsx-05-01.png

 

ESG にデフォルトゲートウェイを設定します。

Get-NsxEdge -Name $esg_name | Get-NsxEdgeRouting | Set-NsxEdgeRouting -DefaultGatewayVnic 0 -DefaultGatewayAddress $esg_dgw -Confirm:$false

hol1803-powernsx-05-02.png

 

ESG にデフォルトゲートウェイが設定されたことが確認できます。

Get-NsxEdge -Name $esg_name | Get-NsxEdgeRouting | select -ExpandProperty staticRouting | select -ExpandProperty defaultRoute

hol1803-powernsx-05-03.png

 

ロードバランサの構成。

 

ESG のロードバランサを有効化します。

Get-NsxEdge -Name $esg_name | Get-NsxLoadBalancer | Set-NsxLoadBalancer -Enabled

hol1803-powernsx-05-04.png

 

アプリケーション プロファイルを作成します。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | New-NsxLoadBalancerApplicationProfile -Name OneArmWeb-01 -Type HTTPS -SslPassthrough

hol1803-powernsx-05-05.png

 

デフォルトの HTTPS モニタの設定です。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerMonitor -Name default_https_monitor | fl

hol1803-powernsx-05-06.png

 

PowerNSX ではモニタの設定変更が難しいため、今回は URL の異なる新しいモニタを作成します。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | New-NsxLoadBalancerMonitor -Name default_https_monitor-2 -Interval 5 -Timeout 15 -MaxRetries 3 -TypeHttps -Method GET -Url /cgi-bin/app.py

hol1803-powernsx-05-07.png

 

作成したモニタを指定して、ロードバランサ プールを作成します。

$monitor = Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerMonitor -Name default_https_monitor-2

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | New-NsxLoadBalancerPool -Name Web-Tier-Pool-01 -Monitor $monitor -Algorithm round-robin

hol1803-powernsx-05-08.png

 

プールにメンバ サーバ(web-01a、web-02a)を追加します。

 

web-01a を追加します。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerPool -Name Web-Tier-Pool-01 | Add-NsxLoadBalancerPoolMember -Name web-01a -IpAddress 172.16.10.11 -Port 443 -MonitorPort 443

 

 

web-02a を追加します。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerPool -Name Web-Tier-Pool-01 | Add-NsxLoadBalancerPoolMember -Name web-02a -IpAddress 172.16.10.12 -Port 443 -MonitorPort 443

hol1803-powernsx-05-09.png

 

メンバが追加されたことが分かります。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerPool -Name Web-Tier-Pool-01 | Get-NsxLoadBalancerPoolMember | ft -AutoSize

hol1803-powernsx-05-10.png

 

仮想サーバを作成します。

PowerNSX では、Add-NsxLoadBalancerVip で仮想サーバを作成できます。

$profile = Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerApplicationProfile -Name OneArmWeb-01

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Add-NsxLoadBalancerVip -ApplicationProfile $profile -Name Web-Tier-VIP-01 -IpAddress 172.16.10.10 -Protocol https -Port 443 -DefaultPool $pool

hol1803-powernsx-05-11.png

 

これでロードバランサが構成されて、ラボの「1-Arm LB Customer DB」ページや、

ESG でのステータス確認ができるはずです。

 

続く・・・

NSX の HoL シナリオを PowerNSX でためす。Part.6

$
0
0

今回は、ここまでのシナリオでの PowerNSX コマンドラインを工夫して

簡易的なスクリプトを作成してみます。

 

今回も、下記のラボを利用します。

HOL-1803-01-NET - VMware NSX - Getting Started

http://labs.hol.vmware.com/HOL/catalogs/lab/3661

 

以前のシナリオで、NSX Edge Service Gateway(ESG)から

分散論理ルータ(DLR)への論理スイッチの付け替えをしました。

NSX の HoL シナリオを PowerNSX でためす。Part.2

 

このときの論理スイッチの付け替え作業を、スクリプトで簡略化してみます。

 

スクリプトの内容。

スクリプトの内容は、下記のようにしています。

  • ESG のインターフェース名を指定して実行すると、
    論理スイッチとアドレス設定を DLR に移行します。
  • インターフェースは論理スイッチに接続されている必要があります。
    (標準 / 分散ポートグループではなく)
  • IP アドレス、サブネットマスク、ポートグループ(論理スイッチ)の設定は、
    ESG のインターフェースから情報取得することで、入力を省略しています。
  • 設定後の DLR のインターフェースの情報を表示します。

 

このスクリプトでは、例外処理(エラー処理など)は省略しています。

また、このラボの構成に合わせることで、スクリプトの内容を簡略化しています。

例えばトランスポートゾーンや NSX Edge の名前が決め打ちだったりしているので、

汎用的なスクリプトを作成する場合はさらに工夫が必要になります。

 

また、HoL のシナリオにある OSPF のルーティング設定はスクリプトに含まないので、

テストむけの「Customer DB App」ページを表示するには

OSPF を手作業で設定する必要があります。

 

スクリプトの内容は下記のようにしました。

migrate_hol_nw.ps1 · GitHub

# Usage:

#   PowerNSX> .\migrate_hol_nw.ps1 <ESG_IF_NAME>

 

$if_name = $args[0]

 

$tz = Get-NsxTransportZone -Name "RegionA0-Global-TZ"

$src_esg =  Get-NsxEdge -Name "Perimeter-Gateway-01"

$dst_dlr = Get-NsxLogicalRouter -Name "Distributed-Router-01"

 

# Disconnect from ESG

$if = $src_esg | Get-NsxEdgeInterface -Name $if_name

$if_ip = $if.addressGroups.addressGroup.primaryAddress

$if_prefix = $if.addressGroups.addressGroup.subnetPrefixLength

$if_pg_name = $if.portgroupName

$if | Clear-NsxEdgeInterface -Confirm:$false

 

$if_pg = Get-NsxLogicalSwitch -TransportZone $tz -Name $if_pg_name

 

# Disconnect to DLR

$dlr_if = $dst_dlr | New-NsxLogicalRouterInterface -Name $if_name -Type internal -ConnectedTo $if_pg -PrimaryAddress $if_ip -SubnetPrefixLength $if_prefix

$dst_dlr | Get-NsxLogicalRouterInterface -Name $if_name | % {

    $ip = $_.addressGroups.addressGroup

    $_ | select `

        Index,

        type,

        name,

        connectedToName,

        @{N="primaryAddress";E={$ip.primaryAddress}},

        @{N="Prefix";E={$ip.subnetPrefixLength}}

}

 

これは、下記のように HoL の環境に「テキストの送信」して使用します。

スクリプトの内容は、PowerShell のヒアドキュメント(「@'」と、「'@」で囲む)を利用して保存しています。

hol1803-powernsx-06-01.png

 

スクリプトでのインターフェース移行。

それでは、スクリプトを実行してみます。

まず、HoL シナリオでは移行しなかった Web_Tier インターフェースを移行してみます。

このインターフェースを移行すると後続のモジュールのシナリオに影響がありますが、

今回はこのモジュールだけ実行する想定として、移行してしまいます。

 

まず、vSphere Web Client からスクリプト実行前の状態を確認しておきます。

ESG の index 2 インターフェースに「Web_Tier」が設定されています。

hol1803-powernsx-06-02.png

 

インターフェース名「Web_Tier」を指定して、スクリプトを実行します。

インターフェースが移行されて、移行後の DLR インターフェース設定が表示されました。

PS> .\migrate_hol_nw.ps1 Web_Tier

hol1803-powernsx-06-03.png

 

移行元である ESG の index 2 のインターフェース はクリアされました。

hol1803-powernsx-06-04.png

 

そして、DLR には期待通り Web_Tier のインターフェースが作成されました。

hol1803-powernsx-06-05.png

 

さらに、App_Tier、DB‗Tier のインターフェースも移行してみます。

PS> .\migrate_hol_nw.ps1 App_Tier

PS> .\migrate_hol_nw.ps1 DB_Tier

hol1803-powernsx-06-06.png

 

ESG の App_Tier、DB_Tier が接続されていたインターフェースがクリアされました。

hol1803-powernsx-06-07.png

 

そして DLR にインターフェースが作成されました。

hol1803-powernsx-06-08.png

 

NSX の GUI 操作は画面遷移が多く、設定変更箇所が多くなる傾向があります。

手順のステップが多いけれども繰り返し実行されるようなものは、

このようにスクリプト等を利用した自動化により、作業の効率化や作業ミスの防止が見込めます。

 

まだつづく・・・


email from Rajiv Ramaswami – COO Products and Cloud Services – VMware Inc

$
0
0

Hi,

I got a mail from Rajiv asking me to take a survey. When I click on the survey link, I get this error:

 

Server Error in '/common' Application.


Runtime Error

Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".

<!-- Web.Config Configuration File -->  <configuration> <system.web> <customErrors mode="Off"/> </system.web> </configuration>


Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.

<!-- Web.Config Configuration File -->  <configuration> <system.web> <customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/> </system.web> </configuration>

 

Have I done something wrong ?

 

Cheers,

 

Sek

NSX の HoL シナリオを PowerNSX でためす。Part.7

$
0
0

ここからは、NSX の分散ファイアウォール(DFW)を PowerNSX で操作してみます。

 

今回は下記のラボを利用します。

HOL-1803-02-NET - VMware NSX - Distributed Firewall and Micro-Segmentation

http://labs.hol.vmware.com/HOL/catalogs/lab/3662

 

今回は、いわゆる3層構成(Web / App / DB)アプリケーションを意識した

分散ファイアウォール ルールを、PowerNSX で作成してみます。

※HOL-1803-02-NET の、モジュール1のシナリオです。

※一番下のファイアウォール ルール「Default Rule」の Action は、あらかじめ Block にしておきます。

 

はじめに PowerShell を起動して、NSX Manager と vCenter に接続しておきます。

Connect-NsxServer -vCenterServer vcsa-01a.corp.local -Username administrator@corp.local -Password VMware1!

 

ファイアウォール セクションとセキュリティ グループの作成。

ファイアウォール セクションを作成して、そこにファイアウォール ルールを追加します。

 

ファイアウォール セクション「3-tier App」を作成します。

New-NsxFirewallSection -Name "3-tier App"

hol1803-powernsx-07-01.png

 

VM「web-01a」と「web-02a」が含まれるセキュリティ グループを作成します。

対象の VM は下記の 2台です。

$vms = Get-VM web-0[12]a.*

$vms

hol1803-powernsx-07-02.png

 

セキュリティグループ「Web-tier」を作成します。

あとでファイアウォールルールの指定で利用するため、ここで変数に入れておきます。

$web_sg = New-NsxSecurityGroup -Name Web-tier -IncludeMember $vms

$web_sg

hol1803-powernsx-07-03.png

 

外部 → Web 層のファイアウォール ルール作成。

Web 層の VM では、HTTPS と SSH サービスの通信を許可します。

特定のサービスを含めるとエラーになってしまうので、

今回は下記のような条件で 2つのサービスに絞っています。

$service_web = @()

$service_web += Get-NsxService -Name HTTPS | where {$_.isUniversal -eq "false"}

$service_web += Get-NsxService -Name SSH | where {$_.isUniversal -eq "false"}

$service_web

hol1803-powernsx-07-04.png

 

外部から Web 層へ通信を許可するルールを作成します。

Get-NsxFirewallSection -Name "3-tier App" | New-NsxFirewallRule -Name "Ext to Web" -Position Bottom -Destination $web_sg -Service $service_web -Action allow

hol1803-powernsx-07-05.png

 

Web 層 → App 層のファイアウォール ルール作成。

App 層のネットワークは「App_Tier_Logical_Switch」です。

$app_nw = Get-NsxLogicalSwitch -Name App_Tier_Logical_Switch

$app_nw

hol1803-powernsx-07-06.png

 

App サービスを定義しておきます。

$service_app = New-NsxService -Name MyApp -Protocol TCP -port 8443

$service_app

hol1803-powernsx-07-07.png

 

Web 層から App 層へ通信を許可するルールを作成します。

ファイアウォール セクションはルールを追加するたびにオブジェクトの再取得が必要なので

変数格納せずに、都度 Get-NsxFirewallSection で取得しています。

Get-NsxFirewallSection -Name "3-tier App" | New-NsxFirewallRule -Name "Web to App" -Position Bottom -Source $web_sg -Destination $app_nw -Service $service_app -Action allow

hol1803-powernsx-07-08.png

 

App 層 → DB 層のファイアウォール ルール作成。

DB 層のネットワークは「DB_Tier_Logical_Switch」です。

$db_nw = Get-NsxLogicalSwitch -Name DB_Tier_Logical_Switch

$db_nw

hol1803-powernsx-07-09.png

 

DB 層の VM では、このラボでは HTTP を許可します。

$service_db = Get-NsxService -Name HTTP | where {$_.isUniversal -eq "false"}

$service_db

hol1803-powernsx-07-10.png

 

App 層から DB 層へ通信を許可するルールを作成します。

Get-NsxFirewallSection -Name "3-tier App" | New-NsxFirewallRule -Name "App to Database" -Position Bottom -Source $app_nw -Destination $db_nw -Service $service_db -Action allow

hol1803-powernsx-07-11.png

 

これで「3-tier App」セクションには 3つのルールが作成されました。

Get-NsxFirewallSection -Name "3-tier App" | Get-NsxFirewallRule

hol1803-powernsx-07-12.png

 

vSphere Web Client からもルール追加されたことが確認できます。

hol1803-powernsx-07-13.png

 

さらに一番下のファイアウォール ルール「Default Rule」の Action を Block にすることで、

シナリオどおりデフォルト ルールで ping がブロックされつつ、

「Customer DB App」ページが表示できることが確認できるはずです。

 

ちなみに現行バージョンの NSX は基本機能でマルチテナント対応しているわけではないので、

実環境では、各ルールの「Applied To(適用先)」で環境やアプリケーションごとに

ルールの適用先を制御することになるかなと思います。

 

つづく!

VMware 製品のビルド番号とバージョンの関連付け

$
0
0

製品のアップデートやパッチがリリースされると、元になるバージョンや適用先バージョンを調べる必要があります。

その際にメーカー公式の情報として提供されているのが下記のページになります。

 

Correlating build numbers and versions of VMware products (1014508)

 

見慣れた製品群が一覧で表示されます。

01.png

 

各製品のリンクをたどると、それぞれの製品のバージョン、リリース日、ビルド番号が表示されます。

02.png

 

この情報を事前にしっかりと確認しておくことで、パッチ適用時のミスや、第三者とのやり取りの際の伝達ミスや認識違いを防ぐことができます。

ESXiやvCenter Serverなどは、Patch、Express Patch、数字の後に記号が付いたり、とバリエーションが多いので頭で覚えるのはなかなか困難です。

 

各製品のRSSフィードの更新内容はあまり当てにならないので、ブックマークをして定期的に閲覧するか、Web更新通知ツールなどを使うと更新情報が早くわかって良いかもしれません。

How to enable SSH access on the UAG Appliance

$
0
0

Even though some of the components of the UAG appliance can be fully configured from its web console interface, you may want to have remote access to the box itself for troubleshooting.

By default, SSH access is disabled on the appliance, but it can be easily activated.

 

Below I put together some steps to enable SSH on the UAG appliance:

 

Configure the sshd service:

Open to the UAG server from the vSphere console and login as root.

In order to enable SSH, you will need to modify the sshd_config configuration file, and enable the sshd service on the server.

 

Edit the sshd_config file. In this example I am using using vi.

On the Linux shell, type vi /etc/ssh/sshd_config and press <Enter>.

 

Screen Shot 2018-01-09 at 17.20.32.png

 

 

Make the following changes to the /etc/ssh/sshd_config file:

 

  • Change the PermitRootLogin setting from no to yes.
  • Comment the MaxSessions line (add # to the beginning of the line).
  • Comment the AllowGroups line (add # to the beginning of the line).

 

Screen Shot 2018-01-09 at 17.22.01.png

 

Screen Shot 2018-01-09 at 17.22.46.png

 

 

Save the file: <ESC>, :wq!, <Enter>.

 

 

Enable the sshd service:

Use YaST to enable the sshd service.

Type yast<Enter> on the Linux shell to access it.

 

Screen Shot 2018-01-09 at 17.24.05.png

 

 

Navigate to System > Services Manager using the arrow keys and then press <Enter>.

 

Screen Shot 2018-01-09 at 17.24.28.png

 

 

Use the arrow keys to select the sshd service.

Press <Alt>+E to enable the service and <Alt>+S to start it.

 

Screen Shot 2018-01-09 at 17.26.23.png

 

 

To save the configuration, select the OK option by pressing either <Alt>+O or F10.

To exit YaST, select the Quit option by pressing F9.

 

One way to test it is to connect to itself by typing ssh localhost.

 

Screen Shot 2018-01-09 at 17.28.43.png

 

 

 

--

 

The postings on this site are my own and do not represent VMware’s positions, strategies or opinions.

vSphere Management Assistant(vMA)はv6.5で廃止

$
0
0

vSphereのリモート管理、特にUPSとの連動シャットダウンの管理サーバーとしてvMAをよく使用していました。

メーカーオフィシャルなLinuxサーバーとして多目的に利用していましたが、このvMA、v6.5で廃止されたようです。

 

vSphere Management Assistant for vSphere 6.5 - VMware {code}

注: vMA は廃止されたため、vMA 6.5 が最後のリリースです。詳細および代替機能については、vMA リリース ノートを参照してください。

v6.5のリリースノートには、

vSphere Management Assistantの廃止予定は、vSphere Management Assistant 6.0.0.1リリースで発表されました。

とあります。

ちなみに、v6.0.0.1のリリースノートには、

, and vSphere Management Assistant (vMA) will be deprecated in a future release.

とあり、しっかり廃止予定が記載されていました。

代替機能については詳細に記載はありませんが、VMware PowerCLIやvCLIを使うか、vSphere SDKを使って置き換えていくか、という感じでしょうか。

なお、vMA 6.5がいつまで使えるかは、製品互換表に記載が無いので正確には分かりません。

 

参考までに、PCNS 4.2の対応OS表では、ESXi 6.7にvMA6.5を当てているようです。

03.png

引用元:PowerChute Network Shutdown v4.2 for Virtualization 対応OS表

PCNSもメーカー独自の仮想アプライアンスが提供されていますので、実際vMAを使う場面は限られています。

 

特定用途では利用があったvMAですが、ひっそりと廃止されていたので記事にまとめてみました。

ゲストOSのサポートおよびインストールガイド

$
0
0

VMwareの仮想化製品上で希望のゲストOSがサポートされるかどうかは、VMware Compatibility Guideで確認できます。

VMware Compatibility Guide - Guest/Host Search

https://www.vmware.com/resources/compatibility/search.php?deviceCategory=guestos

 

また、サポートされる個別のゲストOSのインストール方法について、インストールガイドがあります。

VMware Guest Operating System Installation Guide

http://partnerweb.vmware.com/GOSIG/home.html

古いOSから新しいものまで、結構充実してます。

 

サポートされるゲストOSの種類を調べるだけであればコンパチガイドで十分です。

ゲストOSごとの詳細なインストールに関わる情報を確認するには、インストールガイドを確認する必要があります。

殆どの場合、使い慣れたOSであればわざわざ手順を確認することも無いでしょうが、場合によってはお作法が必要なこともありますので、一度参照することをおすすめします。

 

例えばCentOSの場合、CentOS6まではVMware Toolsのインストールの記載のみですが、CentOS7ではOpen VM Toolsの記載が追加されています。

なお、CentOS7ではOpen VM Toolsが推奨になりますが、これについてはコンパチガイドでも確認できます。

04.png

 

ちなみに、Open VM ToolsについてのKBは下記にあります。

VMware による open-vm-tools のサポート (2073803)

https://kb.vmware.com/s/article/2073803?lang=ja

使用するゲストOSが、普段使い慣れない種類や、新しいメジャーバージョンを使う時などは、上記のガイドを参考にしてみてください。

Teste


PowerNSX で Edge Firewall のデフォルトルールを変更してみる。

$
0
0

今回は、PowerNSX で Edge Service Gateway(ESG)のファイアウォールの無効化 / 有効化と、

デフォルトルールのアクションの変更をしてみます。

 

今回も下記の VMware HoL 環境を利用しています。

HOL-1803-02-NET - VMware NSX - Distributed Firewall and Micro-Segmentation

http://labs.hol.vmware.com/HOL/catalogs/lab/3662

 

Edge ファイアウォールの無効化 / 有効化。

はじめは、Edge ファイアウォールが有効な状態です。

edge-fw-01.png

 

では、Edge ファイアウォールを無効にしてみます。

まず Get-NsxEdge  で ESG を取得します。

$edge = Get-NsxEdge -Name Perimeter-Gateway-01

 

そして、パラメータを変更して Set-NsxEdge で設定します。

$edge.features.firewall.enabled = "false"

$edge | Set-NsxEdge -Confirm:$false

edge-fw-02.png

 

Edge ファイアウォールが無効になりました。

edge-fw-03.png

 

今度は、有効化してみます。

$edge = Get-NsxEdge -Name Perimeter-Gateway-01

$edge.features.firewall.enabled = "true"

$edge | Set-NsxEdge -Confirm:$false

edge-fw-04.png

 

ファイアウォールが有効化されました。

edge-fw-05.png

 

デフォルトルール アクションの変更。

Edge ファイアウォールの「Default Rule」は、デフォルトではアクションが Accept になっています。

これを Deny に変更してみます。

edge-fw-06.png

 

PowerNSX でも、accept が設定されていることがわかります。

$edge = Get-NsxEdge -Name Perimeter-Gateway-01

$edge.features.firewall.defaultPolicy

edge-fw-07.png

 

それでは、Deny に変更してみます。

$edge.features.firewall.defaultPolicy.action = "deny"

$edge | Set-NsxEdge -Confirm:$false

edge-fw-08.png

 

Default Rule のアクションが Deny に設定変更されました。

edge-fw-09.png

 

ESG の設定内容の確認。

PowerNSX では、 Format-XML  で元の XML を確認することができます。

Get-NsxEdge の結果を Format-XML に渡すことで ESG の詳細な設定を確認することができます。

そして前項で指定した「$edge.features.firewall.defaultPolicy.action」といった設定箇所も

XML の構造をたどることで見つけることができます。

edge-fw-10.png

 

実は ESG の情報取得や設定は PowerNSX では難しいことがあり

今回のように Get-NsxEdge / Set-NsxEdge で設定したり、

REST API と同様に XML を扱うことになるケースもあったりします。

 

以上、PowerNSX による Edge ファイアウォールの設定変更例でした。

Pull Relay Servers

$
0
0

When utilizing Relay Servers, there are two ways the files can be sent from the Workspace ONE UEM console to the Relay Server: Push and Pull.

 

On a Push configuration, the files are sent to the Relay Server via an FTP connection (FTPS and SFTP are also supported). That means that SaaS users would need a public DNS to make the Relay Server available, so the Workspace ONE UEM server can open a connection to send over the files.

 

As an alternative, a Pull Service may be installed on the Relay Server. In this scenario, the Pull Service will regularly check the console server for files to download and, when there’s something available, it would download this content and place it on FTP home directory. Since the Pull Service is the component that opens a connection (HTTPS) to the Workspace ONE UEM console, there’s no need for it to be public.

 

Note that the Pull Service is only responsible for downloading files from the Workspace ONE UEM environment. The Relay Server still needs an FTP service running, so the devices can reach out to it to download packages.

 

Below is a diagram of how this communication would look like:

 

Screen Shot 2018-06-30 at 02.05.08.png

 

 

When installing the Pull Service, you will need both the Installer and the Configuration File (PullServiceInstaller.config). The Configuration File looks like the following:

 

<?xml version="1.0"?>

 

<PullConfiguration>

    <libraryPath>C:\FTP_Home\</libraryPath>

    <endPointAddress>https://<Console Server URL>/contentpull</endPointAddress>

</PullConfiguration>

 

Make sure you adjust the libraryPath and the endPointAddress accordingly before running the installer.

 

 

Outbound Proxy

 

In some cases, your internal network might need an outbound proxy, so the Relay Server can communicate to the SaaS environment. As the Pull Service installer does not give us an option to configure an outbound proxy, I got around this by doing the following:

 

1. After installing the Pull Service, the installation folder will have a file called AirWatch.Services.PullService.exe.config. This file will look like this:

 

<?xml version="1.0"?>

<configuration>

  <appSettings>

    (…)

  </appSettings>

  (…)

</configuration>

 

 

2. Between <configuration> and <appSettings>, add the following:

 

<system.net>

    <defaultProxy enabled="true" useDefaultCredentials="true">

        <proxy usesystemdefault="true" proxyaddress="http://<proxy_address>:<port>"/>

    </defaultProxy>

</system.net>

 

Note: Adjust the XML values accordingly.

 

 

3. Restart the Pull Service.

 

 

Troubleshooting

 

If you need to troubleshoot the Pull Service, a Log file is created on the folder where the Pull Service is installed. This log will indicate if files are being downloaded, if there’s any connectivity issues, etc.

 

 

 

The links below point to the documentation on how to install the Pull Relay Service:

 

Configure a Relay Server: https://docs.vmware.com/en/VMware-Workspace-ONE-UEM/9.5/vmware-airwatch-guides-95/GUID-AW95-ConfigureRelayServer.html

 

Create a Windows-Based Pull Service Relay Server: https://docs.vmware.com/en/VMware-Workspace-ONE-UEM/9.5/vmware-airwatch-guides-95/GUID-AW95-CreateWindowsPullRelayServer.html

 

Create a Linux-Based Pull Service Relay Server: https://docs.vmware.com/en/VMware-Workspace-ONE-UEM/9.5/vmware-airwatch-guides-95/GUID-AW95-CreateLinuxPullRelayServer.html

 

--

 

The postings on this site are my own and do not represent VMware’s positions, strategies or opinions.

Virtual EVC per VM

$
0
0

vSphere previously implemented Enhanced vMotion Compatibility (EVC) as a cluster-wide attribute because, at the cluster-wide level,  you can make certain assumptions about migrating a VM (for example, even if the processor is not the same across all ESXi hosts, EVC still works). However, this policy can cause problems when you try to migrate across vCenter hosts or vSphere clusters. By implementing per-VM EVC, the EVC mode becomes an attribute of the VM rather than the specific processor generation it happens to be booted on in the cluster.

PowerNSX で NSX Edge の構成情報を修正してみる。

$
0
0

NSX Edge をデプロイする時に クラスタ / リソースプールを指定しますが、

デプロイ後に VM(仮想アプライアンス)の配置を変更すると、

構成情報と実機での状態がずれて表示されてしまいます。

 

たとえば、デプロイ時には下記の状態であったとします。

infra-nsxesg-01 という NSX Edge が、infra-cluster-01 クラスタにデプロイされています。

nsx-edge-rp-01.png

 

「ホストおよびクラスタ」のインベントリでは下記の配置です。

infra-nsxesg-01 の VM は、infra-cluster-01 クラスタ直下に配置されています。

nsx-edge-rp-02.png

 

ここで vSphere Web Client から、NSX Edge の VM を別のリソースプールに移動してみます。

infra-nsxesg-01 の VM は、rp-01-infra というリソースプールに移動されました。

nsx-edge-rp-03.png

 

そうすと、NSX 側ではズレが生じます。

nsx-edge-rp-04.png

 

これは 再デプロイや REST API で修正することができますが、

今回は自宅ラボなので、PowerNSX の Set-NsxEdge コマンドで修正してみます。

 

まず、PowerNSX で NSX Manager と vCenter に接続します。

※今回の vCenter は infra-vc-01.go-lab.jp です。

PowerNSX> Connect-NsxServer -vCenterServer infra-vc-01.go-lab.jp

 

リソースプールの ID を確認しておきます。VM を配置しているリソースプールは下記です。

PowerNSX> Get-ResourcePool -Name rp-01-infra | select Name,{$_.ExtensionData.MoRef.Value}

 

Name        $_.ExtensionData.MoRef.Value

----        ----------------------------

rp-01-infra resgroup-61

 

 

NSX Edge の構成を確認しておきます。

PowerNSX> $edge = Get-NsxEdge -Name infra-nsxesg-01

PowerNSX> $edge.appliances.appliance.configuredResourcePool

 

 

id         name             isValid

--         ----             -------

domain-c36 infra-cluster-01 true

 

 

NSX Edge の構成情報を変更します。

PowerNSX> $edge.appliances.appliance.configuredResourcePool.id = "resgroup-61"

PowerNSX> $edge | Set-NsxEdge -Confirm:$false

 

リソースプールの情報が修正されました。

PowerCLI> $edge = Get-NsxEdge -Name infra-nsxesg-01

PowerCLI> $edge.appliances.appliance.configuredResourcePool

 

 

id          name        isValid

--          ----        -------

resgroup-61 rp-01-infra true

 

 

vSphere Web Client での表示も修正されました。

nsx-edge-rp-05.png

 

以上、NSX Edge の構成情報を PowerNSX で修正してみる話でした。

Autoscaling with vCloud Director 9.x

$
0
0

Software systems nowadays need to handle constantly changing load levels while being cost-effective. Peek load has always being a challenge, requiring a lot of spare capacity, and in recent years elasticity has proven itself as the best option.

Dynamically adjusting resources up or down to fit the current demand for the system is de facto the golden standard and benefits both the business and service provider. Scaling can be either vertical (adding more resources to a single node, e.g. more CPU and memory) or horizontal (adding more nodes in the system). The vertical scaling has some obvious limitations and scaling down is usually a problem.

In this blog post, we will present a horizontal autoscaling solution using:

  • vCloud Director (vCD)'s native UI extensibility as management frontend
  • vRealize Orchestrator (vRO) as backend.
  • vRealize Operations (vROps) as monitoring system.

Solution Architecture

First, we have to decide what our solution architecture should be. As I've already mentioned, vCD will serve as a management interface, vRO will be the orchestration engine, and vROps the monitoring component.

Here is a high-level system context diagram showing what the components are and how they interact with each other.

autoscale-blog-solution-diagram.png

There are two main flows:

  1. When the user manages (creates/deletes/updates) autoscaling rules:
    1. The user uses the vCD UI and the custom extension to perform the required tasks.
    2. The vCD UI extension uses API extension endpoint defined by vRO, which works through RabbitMQ notifications and makes it async by nature. This means, we can scale the vRO instances very easily.
    3. The vRO code that handles the notifications, either persists the changes requested by the user, or manipulates vROps domain objects to enable monitoring of resources.
  2. When monitoring event happens:
    1. vROps previously being configured to monitor the group of VMs to be autoscaled, triggers an alert.
    2. The alert is sent to vRO, which in our case would be an SNMP trap, which comes out of the box with vROps. But a more fitted approach would be to use an AMQP protocol and the RabbitMQ cluster for handling the notification.
    3. The vRO code handles the alert by scaling out or scaling in, based on the pre-configured definition.

The Solution

Let's see how this will look like in reality.

The vApp to Scale

To illustrate the autoscaling solution, we will use a simple web application within a vApp called website.

Screen Shot 2018-07-03 at 14.21.41.png

The List of Rules

Our custom UI extension lists all created rules.

Screen Shot 2018-07-03 at 14.19.21.png

Creating a Rule

Creating a rule is a simple as filling out the following form. What need to be provided is the following information:

  • Rule name - the name of the rule
  • Template - the vApp template with a single VM inside
  • Target vApp - is where are going to provision the new VMs
  • Edge gateway - which holds the load balancer
  • Pool name - the pool name of the load balancer
  • Thresholds - the % of CPU and memory average usage, which would trigger either scale out or scale in

Screen Shot 2018-07-03 at 14.23.09.png

The Custom APIs

To define the custom APIs, we use an abstraction library to hide the AMQP massage handling complexity. We provide the method, the API URI, and the callback function to handle the request. For example, when the UI hits the https://<vcd.hostname>/api/org/:orgId/autoscale with HTTP request method GET, it will invoke the callback function which will return all rules.

Screen Shot 2018-07-02 at 8.44.44.png

vROps Symptoms and Alert Definitions

We need to have several things predefined before we can create the scaling objects:

  1. Group Type - the object type of our group, used to define metrics on.
  2. Two super metrics to enable us to monitor average CPU and Memory for the group of VMs:
    1. SM-AvgVMMemUsage → 
      avg(${adapterkind=VMWARE, resourcekind=VirtualMachine, metric=mem|usage_average, depth=1})
      avg(Virtual Machine: Memory|Usage)
    2. SM-AvgVMCPUUsage →
      avg(${adapterkind=VMWARE, resourcekind=VirtualMachine, metric=cpu|usage_average, depth=1}) + avg(${adapterkind=VMWARE, resourcekind=VirtualMachine, attribute=cpu|readyPct, depth=1})
      avg(Virtual Machine: CPU|Usage)+avg(Virtual Machine: CPU|Ready)

Finally, we have to enable our SuperMetrix in the default policy.

Symptom Definitions

Screen Shot 2018-07-02 at 8.54.27.png

Alert Definitions

Screen Shot 2018-07-02 at 8.55.46.png

The Rule Store

For the purposes of this post, the RuleStore will be backed as a plain JSON file, stored as a resource element in vRO. In reality, it might be backed as a SQL or NoSQL DB, depending on what type of operations you want to perform.

Screen Shot 2018-07-02 at 8.49.41.png

When an Alert Triggers

When an alert is triggered, for example because of high CPU load, a notification will be sent to vRO, which will take the appropriate action to scale out.

Screen Shot 2018-07-02 at 8.53.37.png

The vRO handler looks simple, because we use a library to abstract the SNMP notification. It provides a way to filter the trapMessage and an async action execution to perform the operation asynchronously.

 

Screen Shot 2018-07-02 at 9.06.49.png

The ScaleOut Operation

The action itself does 3 things:

  • Deploys a New VM from a Template

Screen Shot 2018-07-02 at 8.42.30.png

  • Updates the preconfigured load balancer pool with the new member

Screen Shot 2018-07-02 at 9.12.20.png

  • Updates the vROps group with the new machine.

Screen Shot 2018-07-02 at 9.13.15.png

 

The Result

The machine can now serve requests.

output_XDok61.gif

Viewing all 3135 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>