Skip navigation

Blog Posts

Total : 4,273

Blog Posts

1 2 Previous Next

この記事ではCurlコマンドのみを利用した、ESXiのSSHサービスの有効化方法を示します。

 

SSHの有効化がコマンド実行毎に必要となる環境の例

VMware環境を監視するために、Zabbixなどのアプリケーションを用いて、SSHコマンドを定期的にESXi上で実行したりしている環境はそれなりにあると思います。

SSHコマンドをRemoteから実行するためには、当然ながらESXiでSSHサービスが有効になっている必要があります。

多くの場合はSSHサービスを事前に有効化しておけば問題ないのですが、HCI製品などでSSHサービスの管理が明示的に行えない場合も時折あるかと思います。

たとえば、HCI製品固有の管理用VMがESXi Cluster全体のSSHサービスのOff/Onを動的に実施している場合などです。

 

そういった環境でZabbixなどの外部サーバから、SSHコマンドによる出力の監視を行いたい、と考えた場合、事前にSSHを有効化しておいたとしても、Systemが自動的にESXiのSSHサービスを無効化してしまい、監視用のコマンドが失敗する、といったことがあり得ます。

 

もちろんコマンドを実行する前にSSHサービスを都度有効化しさえすれば問題ないのです。

そういったことはPowerCLIやpyvmomiなどを使えば比較的簡単に実施できると思います。

しかしながら場合によってはLinuxで実行する必要があったり(PowerCLI使用不可)、Pythonなどのモジュールを自由に導入できない場合などもあるかと思います。

 

そういう要件の環境においてCurlコマンドでESXiのSSHを有効化できたら非常に便利かな?と思いましたのでCurlコマンドで実現する方法を紹介いたします。

この記事では結論部分のみを紹介しますが、答えにたどり着くまで(約1時間半)にもいろいろと勉強になることがありましたので、機会があれば紹介したいと思います。

 

 

実施手法

今回はMOB経由で実施する方法を選びました。

ちゃんと調べてませんが、もしかしたらVersionによってはRESTAPIで実施可能だったり、別のInterfaceからCurlコマンドのみ実施可能かもしれませんが、今回は筆者都合かつ広いVersionをカバーする意図でMOBを利用しました。もっと便利なやり方を知っている方がいたら教えていただきたいです。

 

 

試験環境

以下の環境で試しました。

・実行OS:SUSE Linux Enterprise Server 12 SP2

・curl  version :curl-7.37.0-37.34.1.x86_64

・ESXi Version :VMware ESXi 6.7.0 build-13644319

 

事前準備

対象となるESXi上でMOBが有効になっている必要があります。

ESXi上のMOBサービスはデフォルト無効になっているようです。(vSphere 6.0以降)

その場合は以下のサイトを参考にMOBを有効化しておいてください。

https://www.virtuallyghetto.com/2015/02/quick-tip-vsphere-mob-is-disabled-by-default-in-esxi-6-0.html

また対象となるESXiのIP、ユーザ名、パスワードが必要です。

 

有効化のコマンド

細かいことは抜きにして、以下で有効化可能でした。

 

# hostuser=<username>

# hostpass=<password>

# hostip=<ip address>

 

# SessionID=$(curl -s -k --user "$hostuser:$hostpass" --cookie-jar vc_cookie.txt  "https://$hostip/mob/?moid=serviceSystem&method=start"|awk -v FS="(vmware-session-nonce|value=\"|)" '/vmware-session-nonce/{print $3}' | cut -d"\"" -f1)

# curl -s -k  --cookie vc_cookie.txt  -X POST -d "vmware-session-nonce=$SessionID&id=TSM-SSH"  "https://$hostip/mob/?moid=serviceSystem&method=start" > /dev/null

 

直接サービス起動のMethodを実行することはできないため、一度対象のページにアクセスして、SessionID(vmware-session-nonce)を取得したうえで、そのSessionIDと起動したいサービス名をPOSTしてあげることで可能になりました。

"vmware-session-nonce

In an earlier blog post,  I walked through various options on how to use Microsoft Authenticator with Workspace ONE Access (formerly known as VMware Identity Manager). In the final option, we talked about using the Microsoft Azure MFA Server.  However, as of July 1st, 2019, Microsoft is no longer offering the MFA Server for new deployments.

 

Microsoft does however provide another option to leverage Azure MFA by using the Network Policy Server extension for Azure.

 

In the blog I will walk through the process of configuring a Network Policy Server along with the NPS Extension.

 

 

 

Install and Configure the Network Policy Server

  1. Using the Server Manager -> Add Role and Features
    Screen Shot 09-25-19 at 01.42 PM.PNG
  2. Click Next
  3. Select Role-Based or feature-based Installation
  4. Select the Server from the Server Pool and click next
  5. Add the Network Policy and Access Services
    Screen Shot 09-25-19 at 01.43 PM.PNG
  6. Add the dependency features.
  7. Add the Network Policy Server
    Screen Shot 09-25-19 at 01.44 PM.PNG
  8. Complete the rest of the wizard to install the Network Policy Server.

 

Download and Install the NPS Extension

  1. Go to Download NPS Extension for Azure MFA from Official Microsoft Download Center
  2. Download the NPS Extension for Azure MFA Installer.
  3. Run the installer
    Screen Shot 09-25-19 at 01.49 PM 002.PNG
  4. Click Install

 

Configure the NPS Extension

  1. Run Windows Powershell as an Administrator
  2. At the powershell prompt, cd to "c:\Program Files\Microsoft\AzureMfa\Config"
  3. Run ".\AzureMfaNpsExtnConfigSetup.ps1"
  4. You will be prompted to authenticate with Azure.
  5. After successful authentication, you will be prompted to enter your tenant id. This is your Directory ID which can be copied from your Azure Console:
    directoryid.png
  6. This script will create a self signed certificate for you.

 

Configure your NPS Server

  1. Access your NPS Server (via Admin Tools)
  2. Under standard configuration, select "Radius server for Dial-up or VPN Connections"
  3. Click Configure VPN or Dial-up
  4. Select "Virtual Private Network (VPN) Connections"
  5. Provide a friendly name ie. Workspace ONE
  6. Click Next
  7. Under Radius Clients -> Click Add
  8. Provide a friendly Name, IP Address and a Shared Secret
  9. Click OK and Next
  10. Select Microsoft Encrypted Authentication version 2 (MS-CHAPv2)
  11. Click Next
  12. Under Groups, - Select a group that includes your MFA Users.
  13. Click Next for IP Filters
  14. Click Next for Encryption Settings
  15. Click Next for Realm Name (leave blank)
  16. Click Finish
  17. Click on Policies -> Connection Request Policies
  18. Double Click on the new "Workspace ONE Policy"
  19. Change the type to Unspecified
  20. Click on the Condition Tab
  21. Delete the NAS Port Type and Click Add
  22. Select "Access Client IPv4Address"
  23. Enter the IP Address of the Connector Server
  24. Click OK
  25. Click on Policies -> Network Policies
  26. Double Click on the new "Workspace ONE Policy"
  27. Change the Type to Unspecified
  28. Under Conditions, you should just have the group condition
  29. Under Constraints, select "Microsoft Encrypted Authentication version 2 (MS-CHAP-v2)"
  30. Click OK.

 

Configure Workspace ONE Access

  1. Log into your Workspace ONE Access Admin Console
  2. Go to Identity & Access Manager -> Setup
  3. Click on your Connector Worker -> Auth Adapters
    Screen Shot 10-14-19 at 04.17 PM.PNG
  4. Click on Radius Adapter
  5. Enter your Radius Host, Ports and Secret
    Note: Do not enter an accounting port.  I was not able to get this to work with the NPS Server.





  6. Select MSChapv2 as the encryption type.
  7. Click Save
  8. In the Workspace ONE Access Console, go to Identity Providers and edit the Built-In provider.
  9. Enable the Cloud Based Radius Adapter
  10. Click Save.
  11. You can now use the Cloud Radius Adapter in your Access Policies.

Memory resource provisioning is one of the biggest challenges for IT administrators and virtualization designers. Although the provision of CPU is the major factor in the virtual infrastructure, most of the time there is lesser attention to CPU, because many applications that are deployed in virtualization need more memory, not the prreclaim.jpgocessor. And also today CPU technologies are very powerful, but applications like SQL and Oracle for some of their processes need more memory. Lack of enough memory resources may restrict the development of many virtual infra, so what should we do in this situation, before providing more physical resources for our hypervisors?

There are many technologies to handle the problem of memory over-commitment  such as Swapping and Ballooning and VMware ESXi use some of them to confronting with these issues. in this post I will review act and importance both mentioned mechanism:

1. Virtual Memory Ballooning is just a memory reclaiming technique that lets the VMkernel retrieve idle memory pages. When the ESXi host has less than 6% free memory (actually >=6%), Ballooning will come into the ring to handle out of memory problem! If a VM has many idle pages, its host borrows them to use as the temporary overhead for the VMs with more memory demand because probably they have some memory-intensive processes.

When a virtual machine wants to release some of the old used page files dedicated from host physical memory, does not remove it exactly, just change the address space pointer of the allocated memory list to the free memory list. So VM with Balloon Driver (vmmemctl.sys) can decide which pages (idle pages) can be reclaimed back to the host (up to 65% of VM guest memory) and which ones are needed for itself yet (already used pages) without involving host in this decision procedure. Now time for inflating step to happen If you disable memory ballooning driver inside the guest OS, VM will not be aware of host memory state and amount of available or unused physical memory and hypervisor cannot understand how much memory can take it back for other VMs memory requests.

2. Host Swapping is another mechanism used in low memory status, but unlike the Ballooning, it does not relate to VM guest OS. Host Swapping (or vRAM) has occurred If the host has less than 2% free memory and needs to provide more memory resources for memory-intensive VMs, so hypervisors should have enough swap space. although swapping is a reliable way against memory over-commitment, but it may cause total performance degrading because the efficiency of generated swap files is highly depended on IOPS rate of datastore specified for swapping, So if we don't provision suitable Disks (Like SSD) for swap files, it can lead to low performance.

There is one crucial point: If Memory Compression could happen, there is no need for hypervisor swap procedure execution. (I will discus more about it later on another post)

Remember, ESXi Host's memory will stay in share state until total required memory for them (memory requests) is greater than available physical memory (over-commitment), So if we want to prevent this situation before ballooning activation, we need to do these jobs:

1. Estimate carefully about overall required memory and also provide at least 25% more memory in the design phase.ballooning.png

2. Use VMware DRS in cluster-level resources to distribute VMs between hosts and balance resource usage, then no need to worried about low-memory. It's recommended to provision equal memory for all of ESXi hosts.

3. Use Resource Pools, especially in cluster-level and reserved estimated memory for mission-critical application and high resource-demand VMs and ensure they access to enough resources. Also, reserved memory is protected against memory reclaiming, even contention happened.

4. Do Not disable Balloon Driver, because it's the best intelligent memory reclamation technique. but if you want to do that, you can do it via the vSphere Client setting (Remove sched.mem.maxmemctl entry from .vmx file) or Guest OS Windows Registry (Set value of HKLM\SYSTEM\CurrentControlSet\services\VMMEMCTL from 2 to 4)

 

Link of post on my personal blog: Undercity of Virtualization: Memory Virtualization: Management & Reclaiming - Section I

 

 

 

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、ここまでに作成した DHCP サービスを利用するオーバーレイ セグメントを追加作成します。

あわせて、前回までの投稿で追加した DHCP サーバの構成をもう少し掘り下げて確認してみます。

 

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

 

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.8

 

今回の環境について。

前回までの投稿で作成した NSX-T ラボ環境に、オーバーレイセグメントを追加して、

Tier-1 ゲートウェイを介してオーバーレイ セグメント同士で通信できる環境を用意します。

 

すでに作成ずみのオーバーレイ セグメント「seg-overlay-01」は、説明順序の都合から

オーバーレイ セグメントに後から DHCP サーバ範囲を指定しており、手順が前後していました。

今回は、セグメント作成の時点で、あわせて DHCP 範囲を指定します。

nsxt25-add-segment.png

 

オーバーレイ セグメントの作成。(2回目)

それでは、セグメントを作成します。

NSX-T の Manager で、「ネットワーク」→「セグメント」→「セグメント」タブを開いて、

「セグメントの追加」をクリックします。

nsxt-seg2-01.png

 

次のパラメータを入力します。

  • セグメント名: セグメントに付与する名前を入力する。
  • 接続されたゲートウェイとタイプ: 接続する Tier-1 ゲートウェイを選択する。

そして、「サブネットの設定」リンクをクリックします。

nsxt-seg2-02.png

 

「サブネットの設定」画面で「サブネットの追加」をクリックして、次のパラメータを入力して「追加」をクリックします。

最初に作成したセグメント「seg-overlay-01」とはことなり、この追加作成時点で「DHCP範囲」も指定します。

  • ゲートウェイ: サブネットのゲートウェイ IP アドレスを入力する。
  • DHCP 範囲: ゲートウェイのアドレスと同じネットワークアドレスで、
    かつゲートウェイアドレスとは重複しないレンジで IP アドレスの範囲を入力する。

nsxt-seg2-04.png

 

パラメータが入力されたことを確認して、「適用」をクリックします。

nsxt-seg2-05.png

 

サブネットが作成され、サブネットの数「1」が表示されています。

トランスポート ゾーンで、作成ずみのオーバーレイ トランスポート ゾーン「tz-overlay-01」を選択して、

「保存」をクリックします。

nsxt-seg2-06.png

 

設定の続行を確認する画面は「いいえ」で閉じます。

nsxt-seg2-07.png

 

これで、Tier-1 ゲートウェイに 2つめのオーバーレイ セグメントが作成されました。

Tier-1 ゲートウェイには DHCP サーバが接続ずみであり、オーバーレイ セグメントで DHCP 範囲が指定されているので、

このセグメントに接続された VM では DHCP サービスが利用可能になっているはずです。

nsxt-seg2-08.png

 

VM へのオーバーレイ セグメントの接続と確認。

作成したオーバーレイセグメント「seg-overlay-02」を VM に接続します。

 

以前の投稿でも紹介しましたが、NSX-T のセグメントは vSphere Client ではポートグループとして扱えるので、

VM の「設定の編集」で、仮想ネットワーク アダプタに割り当てることができます。

nsxt-seg2-10.png

 

vm03 という VM に、seg-overlay-02 を割り当てました。

nsxt-seg2-21.png

 

ゲスト OS でネットワークを再起動すると、DHCP サーバから IP アドレス(172.16.2.10/24)と、

DNS サーバのアドレス(172.16.253.254)が設定されたことがわかります。

※ゲスト OS には、VMware Photon OS 3.0 を利用しました。

※この DHCP サーバ/DNS サービス の設定は、以前の投稿で設定ずみのものです。

 

そして、1つ目のセグメント(172.16.1.10)とも疎通確認できます。

nsxt-seg2-22.png

 

これで、最低限の NSX-T ラボ環境が Simplified UI で作成できたかなと思います。

 

NSX-T Polic API による DHCP サーバの補足。

NSX-T の Policy API 操作による DHCP サービスの構成は、基本的に DHCP リレー構成となるようです。

DHCP を利用するセグメントを2つ作成した状態で、「ネットワークとセキュリティの詳細設定」画面側から確認してみます。

 

「DHCP」→「サーバ」に、以前の投稿で作成した DHCP サーバ(172.16.254.254)が表示されます。

オーバーレイ セグメントで指定した DHCP 範囲も、「IP プール」に表示されています。

nsxt-seg2-15.png

 

「リレー プロファイル」を開くと、

DHCP サーバ(172.16.254.254)のプロファイルが構成されます。

nsxt-seg2-13.png

 

そして、Tier-1 ゲートウェイの、オーバーレイセグメントを接続しているポートには、

それぞれリレーサービスが構成されていることがわかります。

nsxt-seg2-14.png

 

以上、NSX-T 2.5 ラボ環境を、あえて Simplified UI だけで構築してみる話でした。

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、Tier-1 ゲートウェイ配下のオーバーレイ セグメントで DNS フォワーダを利用できるようにします。

 

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

 

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.7

 

今回の DNS フォワーダの構成。

今回は、すでに Tier-1 ゲートウェイで NSX-T による DHCP サービスを利用可能にしてあります。(前回の投稿にて)

NSX-T による DNS フォワーダを追加して、Tier-1 ゲートウェイに接続します。

そして、DNS フォワーダから転送先 DNS サーバに到達できるようにしておく必要があるので、

Tier-1 ゲートウェイではルート アドバタイズ設定を追加します。

nsxt25-dnsf-01.png

 

デフォルト ゾーンの追加。

NSX-T の Manager で「ネットワーク」→「DNS」→「DNS ゾーン」を開き、

「DNS ゾーンの追加」→「デフォルト ゾーンの追加」をクリックします。

nsxt-t1-dns-02.png

 

DNS ゾーンのパラメータを入力して「保存」をクリックします。

  • ゾーン名: いわゆる DNS のゾーンの名前ではなく、この設定に付与するオブジェクト名を入力。
  • DNS サーバ: クエリを転送する DNS サーバをカンマ区切りで入力。
    実際に DNS フォワーダから到達できる必要あり。
  • 転送元 IP: DNS サーバに接続する際の元 IP。
    今回はルート アドバタイズと SNAT だけで到達できる環境なので空欄のまま。

nsxt-t1-dns-03.png

 

DNS ゾーンが追加されました。

nsxt-t1-dns-04.png

 

DNS サービスの追加。

DNS サービス(フォワーダ)を追加します。

となりのタブの「DNS サービス」を開き、「DNS サービスの追加」をクリックします。

そしてパラメータを入力して「保存」をクリックします。

  • 名前
  • Tier-0/Tier-1 ゲートウェイ: 以前に作成した Tier-1 ゲートウェイを選択。
  • DNS サービス IP: この DNS フォワーダに設定する IP アドレスを入力する。
    このアドレスは、NSX-T の他のセグメントで使用していない範囲にする必要がある。
  • デフォルト DNS ゾーン: 先ほど作成した「DNS ゾーン」を選択する。

nsxt-t1-dns-06.png

 

DNS サービスが追加されました。

「状態」は、更新マークをクリックすると緑の「稼働中」になるはずです。

nsxt-t1-dns-07.png

 

この画面で、フォワード先の DNS サーバのアドレスを表示することもできます。

nsxt-t1-dns-09.png

 

Tier-1 ゲートウェイ。

DNS サービスを接続した Tier-1 ゲートウェイ(今回は t1-gw-01)では、

ルート アドバタイズを追加する必要があります。

 

「ネットワーク」→「Tier-1 ゲートウェイ」を開き、

対象の Tier-1 ゲートウェイで「編集」をクリックします。

nsxt-t1-dns-12.png

 

「ルート アドバタイズ」を開き、

「DNS フォワーダのすべてのルート」を ON(緑)にして、「保存」をクリックします。

nsxt-t1-dns-14.png

 

「編集を終了」をクリックして閉じます。

これで、DNS フォワーダが利用可能になるはずです。

nsxt-t1-dns-16.png

 

ゲスト OS での確認。

Tier-1 ゲートウェイ配下のセグメントに接続している VM では、

ゲスト OS 内でネットワークを再起動(DHCP でのネットワーク再設定)をすると、

参照先の DNS サーバとして、DNS フォワーダのアドレスが設定されたことがわかります。

ちなみに、ゲスト OS は VMware Photon OS 3.0 なので、DNS サーバのアドレスは

「resolvectl dns」コマンドで確認しています。

nsxt-t1-dns-18-a.png

 

今回の手順は、製品ドキュメントだと下記のあたりが参考になります。

Add a DNS Zone

Add a DNS Forwarder Service

 

もう少し続くつもり。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.9

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、オーバーレイ セグメントで DHCP サーバを利用できるようにします。

 

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

 

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.6

 

今回の DHCP サービスの構成。

NSX-T の従来の「ネットワークとセキュリティの詳細設定」画面から

オーバーレイ ネットワークに DHCP サーバを用意する場合、

論理スイッチ(セグメント)ごとに DHCP サーバを作成していました。

 

一方、Policy API では、 DHCP サーバを Tier-1 ゲートウェイごとに作成して、

各オーバーレイ セグメントでは DHCP リレーで利用します。

nsxt25-dhcp-sv-01.png

 

DHCP サーバの追加。

まず、DHCP サーバを追加(作成)します。

NSX-T の Manager で「ネットワーク」→「DHCP」を開き、「サーバを追加」をクリックします。

nsxt-dhcp-01.png

 

DHCP サーバのパラメータを入力して「保存」をクリックします。

  • サーバ タイプ: 「DHCP サーバ」を選択。
  • サーバ名: DHCP サーバに設定する名前を入力する。
  • サーバの IP アドレス: 「IP アドレス/サブネットマスクの長さ」を入力する。
    これは NSX-T のオーバーレイ ネットワークなどで使用中のネットワーク アドレスと重ならないようにする。
  • Edge クラスタ: 作成ずみの Edge クラスタを選択する。

nsxt-dhcp-02.png

 

DHCP サーバが作成されました。

nsxt-dhcp-03.png

 

Tier-1 ゲートウェイへの DHCP サーバ接続。

作成した DHCP サーバを、オーバーレイ セグメントを接続している Tier-1 ゲートウェイに接続します。

「ネットワーク」→「Tier-1 ゲートウェイ」で、以前に作成した Tier-1 ゲートウェイ「t1-gw-01」を表示すると、

まだ「IP アドレス管理」が「未設定」になっています。

nsxt-dhcp-04.png

 

Tier-1 ゲートウェイの「編集」をクリックします。

nsxt-dhcp-05.png

 

「IP アドレス管理」の隣にある「IP を割り当てない設定」リンクをクリックします。

nsxt-dhcp-06.png

 

「IP アドレス管理の設定」画面で、パラメータを入力して「保存」をクリックします。

  • タイプ: 「DHCP ローカル サーバ」を選択。
  • DHCP サーバ: 直前に作成した「dhcp-sv-01」を選択。

nsxt-dhcp-08.png

 

「IP アドレス管理」が「ローカル | サーバ」になったことを確認して、「保存」をクリックします。

nsxt-dhcp-09.png

 

Tier-1 ゲートウェイの設定画面は「編集の終了」をクリックして閉じます。

nsxt-dhcp-10.png

 

オーバーレイ セグメントでの DHCP 範囲の設定。

オーバーレイ セグメントで DHCP リレーを構成する必要がありますが、

これは「DHCP リレー」のような設定画面はありません。

かわりに、セグメントの「サブネット」で、「DHCP 範囲」を設定します。

 

「ネットワーク」→「セグメント」→「セグメント」タブを開くと、

以前に作成したオーバーレイ セグメント「seg-overlay-01」があるので、

このセグメントで DHCP を利用できるようにします。

nsxt-dhcp-11.png

 

セグメントの「編集」をクリックします。

nsxt-dhcp-12.png

 

セグメントが編集可能な状態になるので、サブネット(の数)のリンクをクリックします。

nsxt-dhcp-13.png

 

「サブネットの設定」画面が開くので、「編集」をクリックします。

nsxt-dhcp-16.png

 

空欄になっていた「DHCP 範囲」に、IP アドレスの範囲を入力して、「追加」をクリックします。

これは入力済みの「ゲートウェイ」と合わせる必要があります。

例では、ゲートウェイが 17.16.1.1/24 と入力ずみなので、

そのネットワーク アドレス内でゲートウェイアドレスと重複しないように

「172.16.1.10-172.16.1.250」と入力しています。

nsxt-dhcp-17.png

 

DHCP 範囲が表示されたことを確認して、「適用」をクリックします。

ちなみに、セグメントに「DHCP 範囲」を設定すると UI から削除することはできず、

セグメントで DHCP 使用をやめる場合には、セグメント自体をいったん削除することになります。

nsxt-dhcp-18.png

 

「保存」をクリックします。

nsxt-dhcp-19.png

 

「編集を終了」をクリックして、画面を閉じます。

nsxt-dhcp-20.png

 

ゲスト OS でのネットワーク アドレス取得。

オーバーレイ セグメント「seg-overlay-01」を割り当てている仮想マシンでは、

ゲスト OS のネットワーク設定で DHCP を利用するようにしてあります。

 

ゲスト OS でネットワークを再起動すると、

「DHCP 範囲」で設定した範囲から、IP アドレス(172.16.1.10/24)が設定されます。

そして、デフォルト ゲートウェイには、オーバーレイ セグメントで指定した

ゲートウェイ アドレス(172.16.1.1)が設定されます。

ちなみに、例として使用しているゲスト OS は、VMware Photon OS 3.0 なので、

「systemctl restart systemd-networkd」コマンドでネットワークを再起動しています。

nsxt-dhcp-21.png

 

今回の手順については、製品ドキュメントでは下記のあたりが参考になります。

Add a DHCP Server

 

ちなみに、今回作成した DHCP サーバの仕組みについては、

下記の投稿(2つ目の DHCP 利用セグメント追加)の最後でも紹介しています。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.9

 

つづく。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.8

VMware vCenter Server Appliance Management Interface (VAMI) is a very useful web console environment for VCSA management & maintenance operations,vSAN-Error.png that has been existing on HTTPS://VCSA_URL:5480. One of these tools is Backup and with these tools, you can take a specified backup of vCenter data consists of Inventory & Configuration (Required) and Stats, Events & Tasks (Optional)

VMware published VCSA6.7 (version 6.7.0.14) with these protocols for Backup: FTPS, HTTPS, SCP, FTP, HTTP. But announced NFS & SMB will be supported after VCSA6.7U2 (version 6.7.0.3). We had two big problems with these useful tools,  One of them is related to VSAN Health Service.

 

Whenever the Backup task has been started, it was stopped immediately and generated a warning about VSAN Health Service, because it seems to be crashed. (VCSA Management GUI exactly will tell us this happened.) Sadly if you try to start this service (even with --force option) it leads to another failed attempt and result is something like this:

 

So after many retrying for starting this service, I decided to check the files structure of this service in path of /etc/VMware-vsan-health and compare them with a fresh-installed vCenter Server.

vSAN-files.png

Also, there are two files that could to be related to the cause of this issue: logger.conf  file that has been absolutely empty in the troubled vCenter Server and VI result shows nothing, whereas in the healthy VCSA you can see something like below results:

VSAN-logger.png

When I checked the vsanhealth.properties, it shows communication of this service is worked with HTTPS, so its connections need to have an SSL structure. Then I found the second file: fewsecrets, it contains something like two hash streams. So I decided to risk and remove this file and the logger.conf file too (of course after getting its backup). At last, after some minutes the next try of service start was successful.

vSAN-Started.png

 

Remember that you need always to check DNS (FWD, RVS), NTP, Certificate and Firewall, Especially if you setup the vSphere environment with an External Platform Service Controller. I will explain the second problem in another post.

Link to my personal blog: Undercity of Virtualization: VCSA Backup Failed because of VSAN

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、Tier-0 ゲートウェイに SNAT ルールを追加します。

 

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

 

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.5

 

今回の NSX-T ラボでの SNAT。

ラボ環境からラボの外部(別環境のネットワークやインターネットなど)に出る場合、

ラボ環境内のネットワークアドレスがプライベートなためルーティングできず、

対策として(外部に出た通信が戻れるように)ラボの出口になるルータで SNAT を利用することがあります。

この場合、ラボの出口になるルータには(ラボ内のプライベートではない)外部ネットワークのアドレスが付与されていています。

そしてラボ内からの通信については、SNAT ルールによって、通信元アドレス(Source アドレス)を

プライベートなアドレスからラボの出口になるルータのグローバル アドレスに変換します。

 

今回は、NSX-T のオーバーレイ セグメントに接続された VM が NSX-T より外部のネットワークにアクセスした際の「戻り」のために、

Tier-0 ゲートウェイで SNAT ルールを設定します。

これにより Tier-0 ゲートウェイ「t0-gw-01」の SNAT にて、オーバーレイ セグメントからの通信元アドレス「172.16.x.x」が、

「192.168.200.2」(t0-gw-01 のアップリンク インターフェースのアドレス)に変換されるようにします。

 

そして下図の(NSX-T のラボとは直接関係しない部分の)補足として・・・

  • 「外部ルータ」は、本来は不要ですが、自宅ラボ環境と今回の SNAT とは関係ない検証の都合により配置されています。
  • 記載が省略されていますが「外部ルータ」のデフォルト ゲートウェイは「ルータ(インターネットへ)」に向けてあります。
  • 実際にこのラボ環境からインターネットなどにアクセスする場合は、図の最上部にある「ルータ」でも SNAT を利用します。

snat-01.png

 

Tier-0 ゲートウェイ への SNAT ルール追加。

それでは、Tier-0 ゲートウェイに SNAT ルールを追加します。

 

NSX-T の Manager で、「ネットワーク」→「NAT」を開き、

Tier-0 ゲートウェイ(ここでは t0-gw-01)を選択して「NAT ルールの追加」をクリックします。

nsxt25-snat-01.png

 

つぎのパラメータを入力して「保存」をクリックします。

  • 名前: SNAT ルールにつける名前を入力する。
  • アクション: SNAT を選択する。
  • 送信元 IP: SNAT の対象とするアドレスを入力する。
    今回は オーバーレイ セグメントで利用するつもりのネットワークアドレス(172.16.0.0/16)を入力。
  • 変換された IP: Tier-0 ゲートウェイの アップリンクにあたる インターフェースの IP アドレスを入力。

nsxt25-snat-02.png

 

これで SNAT ルールが作成されました。

状態が「不明」の場合は、となりの更新マークをクリックすると「稼働中」になるはずです。

nsxt25-snat-03.png

 

これで、オーバーレイ セグメントに接続された VM(vm01)のゲスト OS でネットワーク設定されていれば

SNAT ルールが機能して NSX-T 外部の(Tier-0 ゲートウェイより外部の)ネットワークに出て、戻ってこれるようになるはずです。

 

今回の手順は、製品ドキュメントだと下記のあたりが参考になります。

Configure NAT on a Gateway

 

まだ続く。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.7

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、Tier-0 ゲートウェイにスタティック ルートを追加します。

 

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

 

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.4

 

今回の NSX-T ラボのネットワーク セグメント構成。

今回の NSX-T ラボは、下図のようなネットワークを構成しています。

  • NSX-T で Tier-0 / Tier-1 ゲートウェイを利用した最小限のネットワークを構成しようと思い、
    あえて Tier-0 ゲートウェイでルーティングプロトコル(BGP)は設定せず、スタティックルートを設定します。
    一方、その観点では図中の「外部ルータ」は不要なのですが、既存の自宅ラボのネットワーク環境で
    Tier-0 ゲートウェイのアップリンクに VLAN ID を設定したかったため、やむなく配置しています。
  • 「外部ルータ」というのは、NSX Edge ではない(NSX-T の機能によるものではない)ルータです。
    この投稿では割愛していますが、このルータにも 172.16.0.0/16 宛を 192.168.200.2 にむけるスタティック ルートを設定しています。
  • Tier-0 ゲートウェイには、デフォルトルートを外部ルータに向けるスタティックルートを設定します。
    (この設定が、この投稿の主役です)
  • Tier-0 / Tier-1 ゲートウェイ間は、Tier-1 ゲートウェイのルート アドバタイズが設定されています。
    (Tier-1 ゲートウェイ作成のときに設定ずみのものです)
  • 図では省略していますが、「クライアントマシン」には 172.16.0.0/16 宛を外部ルータに向けるスタティック ルート、
    vm01 にはデフォルトゲートウェイとして 172.16.1.1 を設定しています。

lab-static-route-01.png

 

上記のようなルーティング設定をして、図中の「クライアント マシン」と「vm01」が通信できるようにします。

lab-static-route-02.png

 

Tier-0 ゲートウェイへのスタティック ルート追加。

NSX-T の Manager で、「ネットワーク」→「Tier-0 ゲートウェイ」を開きます。

この時点では、まだ Tier-0 ゲートウェイのスタティック ルートはゼロ件です。

nsxt-t1-route-01.png

 

Tier-0 ゲートウェイの「編集」をクリックします。

nsxt-t1-route-02.png

 

「ルーティング」→「スタティック ルート」のとなりの「編集」リンクをクリックします。

nsxt-t1-route-03.png

 

「スタティック ルートの追加」をクリックして、次のパラメータを入力します。

  • 名前: このルーティングを識別する名前を入力する。
  • ネットワーク: デフォルト ルートとして「0.0.0.0/0」を入力する。

そして、「ネクスト ホップの設定」リンクをクリックします。

nsxt-t1-route-05.png

 

「ネクスト ホップの追加」をクリックして、下記を入力して「追加」をクリックします。

  • IP アドレス: NSX-T 環境の外部ネットワークである「外部ルータ」の IP アドレスを指定。
  • インターフェイス: Tier-0 ゲートウェイ作成時に、あわせて作成した「t0-uplink-01」を選択。

nsxt-t1-route-07.png

 

ネクスト ホップが追加されたことを確認して「適用」をクリックします。

nsxt-t1-route-08.png

 

ネクスト ホップが 1 件となったことを確認して「閉じる」をクリックします。

nsxt-t1-route-09.png

 

スタティック ルートが 1件 になったことを確認して「編集を終了」をクリックします。

nsxt-t1-route-10.png

 

これで、Tier-0 ゲートウェイにスタティック ルートが設定されました。

「クライアントマシン」には 172.16.0.0/16 宛を外部ルータに向けるスタティック ルート、

vm01 にはデフォルトゲートウェイとして 172.16.1.1 を設定すれば、相互に通信できるようになるはずです。

 

今回の設定は、製品ドキュメントだと下記のあたりが参考になります。

Configure a Static Route

 

まだつづく。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.6

If you have read my previous blog on configuring Okta Device Trust for Workspace ONE you will know that Okta has not yet implemented device trust for Windows and MacOS. I also mentioned in the previous blog that if you want to leverage device trust for Windows and MacOS that you will need to use the original method with just routing rules.

 

In my previous blog I didn't go into the details on how you would configure device trust for both IOS/Android and Windows/MacOS. Its not really as straight forward as you would think because once you have configured an Identity Provider in Okta to use device trust, it will always send the device trust authentication context which will always result in an authentication failure for Windows and MacOS (assuming its being evaluated for Certificate and Device Compliance - AirWatch).

 

Note: This blog will not go into steps to configure Workspace ONE UEM or Workspace ONE Access to perform Certificate Based Authentication. We will assume that this has already been done.

 

There are a couple extra steps you will need to do.  Lets walk through the steps.

 

Create a New Identity Provider

 

First you will need to create another Identity Provider for Workspace ONE.

 

  1. Log into the Okta Administration Portal and go to Security -> Identity Providers
  2. Click Add Identity Provider -> Add SAML 2.0 IDP
  3. Configure this Identity Provider exactly as you've configured the previous one
  4. Click on Show Advanced Settings
  5. Make sure the Request Authentication Context is set to None
  6. Click Add Identity Provider
  7. Expand the Identity Provider you just created and download the metdata

 

Create a new Workspace ONE Application for Okta

 

  1. In Workspace ONE Access, got to Catalog and Click New
  2. Provide a name for this application (ie. Okta Device Trust for Windows/MacOS)
  3. Paste the metadata you downloaded in the previous step.
  4. Click Next, Next, Save
  5. Click Edit for the application you just created
  6. Click Configuration
  7. Modify to the username value to match the username format in Okta.
    Screen Shot 10-02-19 at 12.35 PM.PNG
  8. Click Access Policies
  9. Select the same policy you assigned to the Okta Application Source
    Screen Shot 10-02-19 at 12.36 PM.PNG
  10. Click Next - Save
  11. Assign the application to your users.
  12. Click on Identity and Access Management -> Policies
  13. Edit your Okta Policy
  14. Create a Policy Rule for MacOS to use Certificate and Device Compliance.
    Screen Shot 10-02-19 at 12.38 PM.PNG

 

Modify your Routing Rules in Okta

 

Finally, we can now add this new configuration into the routing rules in Okta

 

  1. Log into the Okta Admin Console
  2. Click on Security -> Identity Providers
  3. Click on Routing Rules
  4. Click Add Routing Rule
  5. Add a rule that will evaluate Windows and MacOS for your required applications and select the new "Workspace ONE - No Device Trust" identity provider we created in the first step.
    Screen Shot 10-02-19 at 12.52 PM.PNG
  6. Verify that there are no other rules that will take precedence over your newly created rule.

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、従来の「Tier-1 ルータ」にあたる「Tier-1 ゲートウェイ」を作成して、

あわせて従来の「オーバーレイ 論理スイッチ」のかわりになるセグメントを作成/接続します。

 

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

 

前回はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.3

 

Tier-1 ゲートウェイの作成。

さっそくですが、Tier-1 ゲートウェイを作成します。

この先の手順で指定する Tier-0 ゲートウェイ「t0-gw-01」は、前回の投稿で作成したものです。

 

NSX-T の Manager で、「ネットワーク」→「Tier-1 ゲートウェイ」を開き、

「Tier-1 ゲートウェイの追加」をクリックします。

t1-gw-and-seg-01.png

 

今回は、最小限のパラメータだけ設定変更しています。

まだ「保存」はせず、このままルート アドバタイズの設定します。

  • Tier-1 ゲートウェイの名前: ここでは「t1-gw-01」とした。
  • リンクされた Tier-0 ゲートウェイ: 前回作成した Tier-0 ゲートウェイを選択する。
  • Edge クラスタ:  作成ずみの Edge クラスタを選択する。

t1-gw-and-seg-03.png

 

「ルート アドバタイズ」を開き、「接続されているすべてのセグメントおよびサービス ポート」を

有効 (緑)にして、「保存」をクリックします。

t1-gw-and-seg-04.png

 

その後の確認画面は「いいえ」で、Tier-1 ゲートウェイの設定画面はいったん閉じます。

t1-gw-and-seg-05.png

 

オーバーレイ セグメントの作成。

オーバーレイ セグメントを、Tier-1 ゲートウェイに接続した状態で作成します。

 

これは VLAN のセグメントの作成と同様に、

NSX-T の Manager で、「ネットワーク」→「セグメント」を開き、「セグメントの追加」をクリックします。

表示されたセグメントの設定入力の画面で、次のパラメータを入力します。

  • セグメント名
  • 接続されたゲートウェイとタイプ: これは直前に作成した Tier-1 ゲートウェイを選択します。

そうすると、「サブネット」にある「サブネットの設定」リンクがアクティブになるので、クリックします。

t1-gw-and-seg-07.png

 

「サブネットの追加」をクリックし、ここでは「ゲートウェイ」の IP アドレスだけ入力して、「追加」をクリックします。

t1-gw-and-seg-21.png

 

ゲートウェイのアドレスが追加されたことを確認して「適用」をクリックします。

t1-gw-and-seg-22.png

 

セグメントの設定入力画面に戻ると、サブネットが「1」表示されます。

トランスポート ゾーンに、作成ずみのオーバーレイ トランスポート ゾーンを選択して「保存」します。

t1-gw-and-seg-10.png

 

設定続行の確認画面は「いいえ」で閉じます。

t1-gw-and-seg-11.png

 

これで、オーバーレイ セグメント 1つ接続してある Tier-1 ゲートウェイが作成されました。

作成されたオーバーレイ セグメントで「詳細設定」をクリックすると・・・

t1-gw-and-seg-13.png

 

オーバーレイ セグメントも、VLAN セグメントと同様に、

「ネットワークとセキュリティの詳細設定」画面でのそのオブジェクトを表示することができます。

t1-gw-and-seg-14.png

 

オーバーレイ セグメントの VM への接続。

作成したオーバレイ セグメントは、従来の NSX-T オーバーレイ論理スイッチと同様に、

VM の vNIC にポートグループとして割り当てることができます。

 

vSphere Client では、VM の「設定の編集」画面にも、セグメントが表示されます。

※この VM は、NSX-T のホスト トランスポート ノードとしてセットアップずみの ESXi に配置されています。

t1-gw-and-seg-16.png

 

セグメントを割り当てた vNIC です。

VM を起動して、ゲスト OS 内でセグメントにあわせた IP アドレスを設定すれば、

さきほどセグメントの「サブネット」で設定したゲートウェイにアドレスに通信可能となるはずです。

(たとえば ping などで)

t1-gw-and-seg-17.png

 

今回の手順は、製品ドキュメントでは下記のあたりが参考になります。

Add a Tier-1 Gateway

Add a Segment ※オーバーレイ セグメントは VLAN セグメントと同じ画面から作成する。

 

続く。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.5

Embedded VCSAの構成変更とUpgrade

 

VxRail 環境では、構成変更や設定変更が一部制限されています。

VxRailのデザインになっている構成や設定を変更してしまうと、VxRailが想定通りに動作しない可能性があります。

また、Upgradeや交換作業などによって、変更した設定がデフォルトに戻ってしまうかもしれません。

 

VxRailに同梱されるVCSA/PSCの構成情報を変更した場合はどうなるのでしょうか。

VxRailのEmbedded VCSAは、デフォルトでSmallサイズとして構成されます。

VxRailでは最大でも64ホストなので、このサイズで足りる想定なのでしょうが、仮想マシンがとても多い環境など、場合によってはメモリを増やしたり、Diskを拡張したりしたい場合もあるかもしれません。

 

試しにEmbedded VCSA/PSCのCPU/Memory/Diskを変更して、Major Upgrade後に変更が維持されるかどうかを確認してみました。

今回のテストでは4.5.314 から 4.7.212への Upgradeで試しました。

 

 

事前の予想

VxRail 4.5.314 はvSphere 6.5系、VxRail 4.7.212はvSphere 6.7系なので、Upgradeに際して新しいVCSA/PSC VMが作成され、既存のVCSA/PSCからデータがMigrationされます。

なので、Upgrade前に変更した仮想ハードウェア情報は維持されないと予想しました。

 

構成変更なしでUpgradeをしてみた

まずは構成変更をせずに、vCenter 6.5 → 6.7へのUpgradeをしてみて、ログや証明書などが維持されるかどうか確認してみました。

結果は以下です。※PSCも同様なので割愛

 

維持されるもの

    • SSL証明書
    • タスク履歴
    • イベント履歴

 

維持されないもの

    • Host key fingerprint (SSH接続時に更新が必要)
    • ログ(/var/log/配下など)

 

構成変更してUpgradeをしてみた

次に仮想ハードウェアを構成変更して、変更が維持されるか確認しました。

※PSCも同様なので割愛

 

初期状態

Upgrade前の状態は以下です

 

1.PNG

 

デフォルトのままなので、vCPUは4、メモリは16GB、Diskサイズもすべてデフォルトです。

 

 

変更内容

以下の構成変更をしました。

      • vCPUを4 → 8
      • メモリを16GB → 32 GB
      • /storage/log (ハードディスク5) を 10GB → 20 GB

 

変更後の構成は以下です。

 

2.PNG

 

 

Upgrade後

Upgrade(Migration)後の構成は以下でした

 

3.PNG

 

結果は私の事前の予想と反し、CPUとメモリの変更は維持され、Diskサイズの変更はデフォルトに戻りました。

 

まとめ

今回のテストでは事前の予想とは異なる結果となりましたが、CPUとメモリの変更が維持されるのは安心できますね。

Diskについてはデフォルトに戻ってしまうので、/storage/logではなくDBのボリュームが拡張されていた場合にどうなるのかは気になります。

その他、パスワードの有効期限設定なども確認し忘れてしまったので、今後判明したらUpdateしようと思います。

ちょっと前の話なので今更感がありますが、Version 76以降のGoogle ChromeからFlashの実行がデフォルトでBlockされるようになりました。

以前であれば、Flashの実行が必要な際にポップアップが出てAllow or Blockを選択できましたが、Version 76にUpdateしたとたんに出なくなりました。

 

Flashが実行できないとWebClientが使えないことになってしまいますが、ブラウザの設定を変えれば以前のようにポップアップを出すことができます。

詳細は以下のURLをご確認ください。

 

https://gigazine.net/news/20190731-google-chrome-76/

VxRailの環境では、未構成NodeのDiscoveryのためにIPv6のマルチキャストが必要です。

マルチキャスト通信は定期的に行われており、ある程度の帯域を消費するわけですが、実際にどれくらいの通信量なのかと質問を受けたので実際にラボ環境で測定してみました。

 

ラボ環境では、VxRailが3クラスタあり合計12Nodeです。

そのうち一つのVxRail Manager VM上でTCPDUMPを実行し、結果をWireSharkで解析しました。

Loudmouthで利用するマルチキャスト IPv6 アドレスである ff02::fb 宛のパケットでフィルターをかけて収集したところ、

24917秒の観測時間中に、9740個のLoudmouthマルチキャストパケットが観測されました。

 

内訳は以下です。

 

1.jpg

 

12個以上のソースがあるのはVxRail ManagerやSmart Fabricなどがあるためです。

また、パケットの平均サイズは約220バイトでした。

 

2.jpg

 

これが多いのか、少ないのか、影響があるのかないのかの環境次第だと思いますが、とりあえず参考情報として公開してみました。

1 2 Previous Next

Actions

Looking for a blog?

Can't find a specific blog? Try using the Blog page to browse and search blogs.