Skip navigation
1 2 3 Previous Next

にほんごVMware

378 posts

NSX-T のネステッド ESXi 環境を利用したラボを構築してみます。

NSX Manager 初回ログイン後の、トランスポート ノードの作成について紹介します。

 

トランスポート ノードとは、NSX-T 独自の仮想スイッチ「N-VDS」が構成されるノードです。

NSX-T のトランスポート ノードには、ESXi ホストと NSX Edge の 2種類がありますが、

ここでセットアップするのは、ESXi の「ホスト トランスポート ノード」です。

 

前回はこちら。

自宅ラボで NSX-T 2.4 環境を構築する。Part.4

 

今回の NSX Manager でのセットアップでは、

N-VDS を使用する ESXi に NSX-T のコンポーネントをインストールします。

そのため、事前に vCenter では下記の準備をしておきます。

  • オーバーレイ ネットワークを構成するホストのクラスタ作成
    • NSX-T コンポーネントのインストールは、クラスタ単位になります。
  • ESXi ホストの vCenter とクラスタへの登録

 

NSX Manager への初回ログイン。

NSX Manager の初回ログインの画面です。

「はじめに」で、vCenter との登録から ESXi をトランスポート ノードとしてセットアップするまでの手順を、流れに沿ってすすめらられます。

これ以降の手順を個別に実施することもできますが、今回は「はじめに」から手順をすすめます。

nsx-setup-01.png

 

「トランスポート ノードのセットアップ」を進めます。

nsx-setup-02.png

 

vCenter Server の登録。

「コンピュート マネージャの追加」で、vCenter を登録します。

nsx-setup-04.png

 

事前に準備してある vCenter の、アドレスや接続情報を入力します。

このとき SSL 証明書のサムプリントを空欄ですすめると、

vCenter 実機のサムプリントで問題ないか確認画面が表示されます。

nsx-setup-05.png

 

ESXi への NSX-T コンポーネントのインストール。

vCenter を登録すると、トランスポート ノードにする ESXi のクラスタを選択できます。

nsx-setup-08.png

 

選択したクラスタに NSX-T のコンポーネントをインストールしてよいか確認メッセージが表示されます。

nsx-setup-09.png

 

しばらく待つと、ESXi ホストが「NSX インストール済み」となります。

画面更新に時間がかかることがありますが、インストール進行中でも

あえて「前へ」「次へ」ボタンをクリックしてみると、インストール完了していることがあります。

nsx-setup-11.png

 

オーバーレイ トランスポート ゾーンとオーバーレイ N-VDS の作成。

「オーバーレイ トランスポート ゾーンの作成」をすすめます。

nsx-setup-12.png

 

「オーバーレイ トランスポート ゾーンの作成」で、

トランスポート ゾーンの名前と、N-VDS(オーバーレイ N-VDS)の名前を入力し、作成します。

nsx-setup-14.png

 

アップリンク プロファイルの作成と指定。

オーバーレイ N-VDS の「アップリンク プロファイルの作成」をします。

今回の構成では、オーバーレイ ネットワークのトンネル エンドポイント(TEP)で VLAN ID を設定するので、

アップリンク プロファイルの新規作成が必要です。

nsx-setup-15.png

 

今回のようにウィザード形式でトランスポート ノードをセットアップしない場合は、

あらかじめアップリンク プロフィルを作成しておきます。

 

アップリンク プロファイルは、名前と・・・

nsxt-setup-uplink-01.png

 

チーミング設定、トランスポート VLAN(TEP となる vmk ポートに設定する VLAN ID)、MTU を設定します。

チーミングの「アクティブ アップリンク」と「スタンバイ アップリンク」に入力する名前は、

あとで ESXi の物理 NIC(vmnic)を紐づけるために利用します。

nsxt-setup-uplink-02.png

 

作成したアップリンク プロファイルを指定して、次のステップで TEP の IP アドレスと、物理 NIC の割り当てをします。

 

オーバーレイ N-VDS の TEP アドレス/物理 NIC の指定。

ESXi は、オーバーレイ トランスポート ゾーンを、オーバーレイ N-VDS で構成します。

ここでは、N-VDS のトンネル エンドポイントとなる TEP の IP アドレスと、

オーバーレイ ネットワークの物理経路となる、物理 NIC を割り当てます。

 

IP アドレスの割り当てには、DHCP(デフォルト)か IP アドレス プールが利用できます。

IP アドレス プールを使用する場合、IP アドレス プールは、この画面から作成できます。

nsx-setup-22.png

 

IP アドレス プールには、名前、IP アドレス範囲、ネットワーク アドレス(CIDR)が必須です。

TEP が複数の L3 ネットワークで構成される場合は、ゲートウェイも入力します。

nsx-setup-23.png

 

作成した IP アドレス プールを指定します。

そして ESXi の物理 NIC に対して、先ほど作成したアップリンク プロファイル名で指定した

アップリンクの名前を割り当てます。

ちなみに、ESXi で未使用(仮想スイッチに未割り当て)の物理 NIC が 3つ以上ある場合は、

さらに vmnic3 以降も表示されます。その際は、使用する物理 NIC だけにアップリンク名を指定します。

nsx-setup-26.png

 

ESXi へのトランスポート ノードのセットアップを終了します。

nsx-setup-27.png

 

オーバーレイ トランスポート ゾーンと N-VDS の確認。

「システム」→「ファブリック」→「トランスポート ゾーン」で、

作成されたトランスポート ゾーンが確認できます。

nsx-setup-29.png

 

vSphere Client では、ESXi に N-VDS が作成され、物理 NIC が接続されたことがわかります。

nsx-setup-30.png

 

トランスポート ノードのアップリンク設定の変更。

ここまでで設定したオーバーレイ N-VDS の設定変更をしたい場合には、

vSphere Client ではなく、NSX Manager で、

トランスポート ノードのアップリンク ポリシーを設定変更します。

 

アップリンク ポリシーの設定変更。

「システム」→「ファブリック」→「プロファイル」→「アップリンク プロファイル」にて、

対象のプロファイルを選択して「編集」から設定変更します。

nsx-setup-31.png

 

ESXi へのアップリンク ポリシーの指定、物理 NIC 割り当ての変更。

「システム」→「ファブリック」→「ノード」→「ホスト トランスポート ノード」にて、

管理元で vCenter の名前を選択します。

そして、対象のノードを選択して「管理」→「編集」から設定変更します。

nsx-setup-32.png

 

つづく…

NSX-T のネステッド ESXi 環境を利用したラボを構築してみます。

今回は、ネスト内側の ESXi でのネットワーク設定について紹介します。

 

前回はこちら。

自宅ラボで NSX-T 2.4 環境を構築する。Part.3

 

イメージ図のうち赤枠の部分が、今回の対象です。

ネステッド ESXi 側での、仮想スイッチとポートグループの構成について説明します。

NSX-T_Lab-2019_setup_Part04.png

 

このラボでは、下記の 2種類のネステッド ESXi ホストを用意します。

  • オーバーレイ ネットワークへの入り口になる ESXi ホスト(NSX Edge を搭載する)
  • 一般の VM むけの オーバーレイ ネットワークを利用する ESXi ホスト

この2種類のホストは 1台のホストにすることができますが、

今回はネットワーク構成を理解しやすいように、あえて独立させました。

それぞれの、ネットワーク構成を説明します。

 

オーバーレイ ネットワークへの入り口になる ESXi ホストの構成。

NSX-T によるオーバーレイ ネットワークへの入り口となる ESXi ホストでは、

NSX Edge の VM を稼働させます。

 

ESXi から見た pNIC は、3つ(vmnic0 ~ vmnic2)用意してあります。

これの実体はネステッド ESXi の vNIC です。

 

このホストは NSX-T のオーバーレイ ネットワークの入り口となりますが、

その役割は NSX Edge VM がもつため、ESXi には NSX-T 独自の仮想スイッチである N-VDS は構成されません。

 

vmnic0 の構成。

1つめの vmnic0 は、vSS(vSwitch0)に構成して下記の通信で利用しています。

  1. ESXi の vmk0 による管理通信
  2. NSX Edge への入り口(アップリンク)となる VLAN

 

ここでの NSX Edge のアップリンクは、NSX-T による仮想スイッチ(VLAN N-VDS)に接続されます。

VLAN N-VDS は Edge VM に構成されます。そして Edge VM のポートグループ割り当てによって経路が決まるので、

後述の vmnic0 / vmnic2 の経路とすることも可能ですが、

今回は「ためしに NIC を切断してみる」のような実験の利便性のため、vmnic0 経路にしています。

 

この pNIC に構成される仮想スイッチには VLAN だけが通るので

(オーバーレイ ネットワークは通らない)ので、

MTU は 1500 のままでも大丈夫です。

 

VLAN N-VDS では Edge VM の中で VLAN ID をうけるため、

Edge VM での VLAN N-VDS の vNIC に接続するポートグループは、前回の投稿にあるような

VLAN ID 4095(vDS であれば VLAN トランク)の設定をしておきます。

 

vmnic1 / vmnic2 の構成。

vmnic1 と vmnic2 は、どちらか片方、またはアクティブ/スタンバイの構成にして、

NSX-T によるオーバーレイ ネットワークで利用します。

ただし、このホストは NSX Edge がオーバーレイ ネットワークの終端となります。

つまり NSX Edge VM が トンネルのエンドポイント(TEP)をもちます。

また、ここでの vmnic のチーミングは、一般的なポートグループのチーミングポリシーで設定します。

 

この pNIC に構成される仮想スイッチには オーバーレイ ネットワークが通るので

MTU は 1600 などに拡張します。

 

今回の オーバーレイ N-VDS では TEP で VLAN ID をうけるため、

Edge VM での オーバーレイ N-VDS の vNIC に接続するポートグループも、

VLAN ID 4095(vDS であれば VLAN トランク)の設定をしておきます。

nsxt-lab-esxi-type-1.png

 

オーバーレイ ネットワークを利用する ESXi ホストの構成。

NSX-T によるオーバーレイ ネットワークを VM が利用するホストで、

ESXi には NSX-T 独自の仮想スイッチである N-VDS(オーバーレイ N-VDS)が構成されます。

ESXi ホスト同士や NSX Edge とは、オーバーレイ ネットワークを通すトンネルのエンドポイント(TEP)同士で通信をします。

 

ESXi から見た pNIC は、前述の ESXi ホストと同様に、3つ(vmnic0 ~ vmnic2)用意してあります。

 

vmnic0 の構成。

1つめの vmnic0 は、vSS(vSwitch0)を構成して、ESXi の vmk0 による管理通信で利用しています。

そのため、MTU は 1500 のままです。

 

vmnic1 / vmnic2 の構成。

vmnic1 と vmnic2 は、どちらか片方、またはアクティブ/スタンバイの構成にして、

NSX-T によるオーバーレイ ネットワーク(オーバーレイ N-VDS)で利用します。

 

先ほどのホストとは異なり、vmnic に設定は、NSX-T のアップリンク プロファイルで設定します。

そのため、ESXi では特に設定を実施せず、NSX-T のセットアップまで NIC を仮想スイッチでは未使用にしておきます。

 

(のちほど)アップリンク プロファイルでは、下記のような設定をすることになります。

  • NIC のチーミング
  • オーバーレイ ネットワークが通るので、MTU は 1600 などに設定。
  • オーバーレイ N-VDS の TEP での VLAN ID の設定。

nsxt-lab-esxi-type-2.png

 

つづく・・・

自宅ラボで NSX-T 2.4 環境を構築する。Part.5

NSX-T のネステッド ESXi 環境を利用したラボを構築してみます。

今回は、ネスト外側の ESXi でのネットワーク設定について紹介します。

 

前回の投稿はこちら。

自宅ラボで NSX-T 2.4 環境を構築する。Part.2

 

1回目投稿にあるイメージ図での赤枠の部分が、今回の対象です。

物理ネットワーク ~ 物理 NIC、物理 ESXi での仮想スイッチ/ポートグループの構成について説明します。

NSX-T_Lab-2019_setup_Part03.png

 

物理(外部)ネットワーク ~ 物理 NIC の構成について。

NSX-T 環境を構成する場合、ESXi では複数の物理 NIC を利用します。

しかし、今回のラボで NSX-T をインストールするホストはネステッド ESXi なので、

物理 ESXi 側では、物理 NIC が1つだけでも十分です。

(私の自宅ラボの物理マシンが 物理 NIC ポートが1つずつしかないという事情もあります。)

そこで、物理 ESXi では、1つの 1Gbps の物理 NIC(vmnic0)だけ利用しています。

nsxt-lab-pNW-02.png

 

ラボ環境では VLAN も利用するので、物理的なネットワーク スイッチのポートでも

トランクポートに設定して対象の VLAN ID が通過できるようにしておく必要があります。

(ただ一般家庭で利用しているようなスイッチング ハブであれば、デフォルトで通るかなとは思います。)

 

MTU は、オーバーレイ ネットワークを構成するためすこし大きめ(一般的な 1500 ではなく 1600 など)に

する必要があり、物理スイッチがでもそのサイズの MTU に対応しておく必要があります。

(ちなみに、これも一般家庭で利用しているようなスイッチング ハブであれば、デフォルトで満たしているはずです。)

物理 ESXi 側での MTU は仮想スイッチで設定することになります。

 

仮想スイッチの構成について。

物理 ESXi での仮想スイッチは、標準仮想スイッチ(vSS)/分散仮想スイッチ(vDS)のどちらでも構いません。

私のラボでは、物理 ESXi 6 台でのクラスタで vDS を利用しています。

nsxt-lab-pNW-01.png

 

NSX-T でのオーバーレイ ネットワークのために、

仮想スイッチでは MTU を拡張(1600 などに)しておきます。

仮想スイッチでの MTU 設定は、仮想ポート単位ではなく、スイッチ全体での設定です。

 

vDS の場合の MTU 設定

vDS の設定の場合は、vDS で 1回 MTU の設定を変更すれば、すべての ESXi に設定反映されます。

vDS の MTU は、下記のように vDS の「設定」→「プロパティ」画面で確認できます。

nsxt-lab-pNW-03.png

 

vSS の場合の MTU 設定

vSS の設定の場合は、それぞれの ESXi ホストの vSS(vSwtich0 など)で、MTU の設定を変更する必要があります。

vSS の MTU 設定は、ESXi ホストで仮想スイッチの「設定の表示」を開くと確認できます。

nsxt-lab-pNW-04a.png

nsxt-lab-pNW-04.png

 

ちなみに、ネステッド ESXi 側でも MTU 1600 に設定する部分がありますが、

物理 ESXi 側でその値以上に MTU を拡張する必要はありません。

仮想スイッチについては、ネスト(入れ子)にしているというより連結している構成となるので、

通常の物理ネットワーク スイッチを連結するときのように経路上の MTU を揃えておきます。

(外側 ESXi をより大きな MTU にするというわけではなく)

 

ポートグループの構成について。

ネスト環境では、ポートグループで VLAN とセキュリティ ポリシーの設定に工夫が必要です。

 

ちょっと古い投稿ですが、下記のような設定をします。

ネステッド ESXi で仮想スイッチ側 VLAN をためす。(VLAN4095 で VST)

 

1つめのポイントは、 VLAN の設定についてです。

ネスト環境でのネットワーク構成では、

できるだけ、物理 ESXi ではなくネステッド ESXi 側のネットワーク構成を

本来構成したいネットワーク(仮想スイッチ/ポートグループ/vNIC)の設定にすると扱いやすいかなと思います。

そこで、物理 ESXi 側の仮想スイッチでは VLAN をそのまま通して、ネステッド ESXi 側の仮想スイッチで VLAN を終端させます。

この設定は、物理 ESXi で vDS/vSS のどちらを利用しているかによって設定が異なります。

 

vSS を利用している場合は、トランクポートの設定ができないので、

VLAN ID 4095 を設定することで、

すべての VLAN ID をそのまま通過させてネステッド ESXi 側の仮想スイッチに渡します。

nsxt-lab-pNW-07.png

 

vDS を利用している場合、トランクポートの設定ができるので、

ネステッド ESXi で利用する VLAN ID の範囲をトランクで設定します。

逆に、vDS では VLAN ID 4095 が設定できないので、

すべての VLAN ID を通す場合は「0-4094」のように設定します。

nsxt-lab-pNW-05.png

 

2つめのポイントは、セキュリティの設定変更です。

ネステッド ESXi の環境では、ESXi VM 自身の vNIC(ネステッド ESXi での vmnic0 などにあたる)に設定される MAC アドレスと、

ネステッド ESXi 上の vmk ポートや vNIC とで MAC アドレスとが、不一致になります。

そのため、物理 ESXi 側の仮想スイッチではセキュリティ設定を緩和(「承諾」に変更)しておく必要があります。

この設定は、vDS / vSS どちらも共通で必要です。

(ただし vDS のほうがデフォルト値がセキュリティが高く設定されており、デフォルト値は異なります。)

なお、標準的にインストールした ESXi の vmk0 ポートは vmnic0 と MAC アドレスが一致するようになっており、

この設定をしなくても、ネステッド ESXi の vmk0 だけは通信ができてしまうはずです。

nsxt-lab-pNW-06.png

 

ちなみに、物理 ESXi に直接搭載する VCSA や NSX Manager の VM については

とくにネスト環境を意識することなく普通のポートグループを割り当てます。

 

続く。

自宅ラボで NSX-T 2.4 環境を構築する。Part.4

NSX-T の機能を確認できるように、ネステッド ESXi 環境を利用したラボを構築してみます。

ネスト環境として土台になる、外側の vCenter での設定について紹介します。

ここでは、VM の配置と、リソース割り当てについて紹介します。

 

前回はこちら。

自宅ラボで NSX-T 2.4 環境を構築する。Part.1

 

前提となるサーバの準備。

まずは、DNS / NTP / NTP / vCenter(VCSA)を用意しておきます。

これらのサーバは、vSphere にとっては、NSX-T を利用するか、ネスト環境であるかどうか

にかかわらず必要であり、特にネスト特有ではない一般的な手順で構築します。

ポイントは、下記のあたりかなと思います。

  • DNS サーバには、NSX Manager の 正引き/逆引きの設定(A / PTR レコード)も登録しておきます。
  • 共有データストアにする NFS サーバを VM として用意する場合も、ここに配置しておきます。
  • VCSA は、最小(tiny)サイズでのデプロイでも NSX-T の動作確認は可能です。

nsxt-lab-base-01.png

 

NSX Manager デプロイのポイント。

NSX Manager をデプロイして、起動しておきます。

nsxt-lab-base-02.png

 

NSX-T 2.4 の NSX Manager には、従来の NSX Manager と Controller 機能が統合されました。

NSX Unified Appliance という OVA ファイル(ファイル名は nsx-unified-appliance-2.4.1.0.0.13716579.ova)をデプロイします。

NSX Manager および利用可能なアプライアンスのインストール

 

デプロイ時のポイントは下記かなと思います。

  • 「nsx-manager nsx-controller」というロールを選択しておきます。
  • 最小サイズは「Cloud Service Manager」むけのもので、NSX Manger のサービスが起動できなくなるので、16GB メモリ / 4 vCPU以上のサイズを選択しておきます。

nsxt-lab-base-11.png

 

また、NSX Manager の VM は vCPU / メモリ(vRAM)の割り当てが大きいので、

小規模のラボむけに、リソース予約をあえて解除してから VM を起動します。

nsxt-lab-base-12.png

 

ESXi VM 設定のポイント。

ネステッド ESXi にする、ESXi VM の設定についてです。

nsxt-lab-base-03.png

 

ESXi VM では、ネステッド ハイパーバイザ上で VM を起動するため、

vCPU で「ハードウェア仮想化」を有効化しておきます。

仮想スイッチとポートグループの設定には工夫が必要です。※次回紹介する予定です。

 

そして、ESXi は、普通のインストーラ ISO ファイルからインストールします。

nsxt-lab-base-13.png

 

次は、土台になる外側の vCenter での、ネットワーク設定における工夫について紹介します。

 

つづく!

自宅ラボで NSX-T 2.4 環境を構築する。Part.3

NSX-T の機能を確認できるように、ネステッド ESXi 環境を利用したラボを構築してみます。

今回は、構築する NSX-T 環境の概要を紹介します。

 

今回のラボ構成の方針。

現時点で NSX-T に取り組む場合は、新技術のキャッチアップを目的とすることが多いかなと思います。

そこで、ソフトウェアはできるだけ新しいものを利用します。

  • NSX-T 2.4.1
  • vCenter Server 6.7 U2 / ESXi 6.7 U2

 

私の自宅ラボには高スペックなマシンがないので、VM 配置/リソース設定に工夫をしています。

  • 本当は手軽に物理マシン 1台でネスト環境を構成したいが、スペック不足のため複数台の物理 ESXi ホストを使用。
  • VCSA と NSX-T Manager などはリソース割り当てが大きいので、あえてネスト環境よりも外(NSX-T 環境の vCenter より外)に配置。
    • ただし実環境では、これらは NSX-T 環境の vCenter で管理することになるはずです。
  • 各 VM の構成/リソース割り当ては、推奨値以下のものもあり。
    • NSX Manager は VM のリソース予約を解除。そしてクラスタ構成ではなくシングル構成にする。
    • NSX Edge は最小のサイズ。
  • ネステッド ESXi でのメモリ節約のため、共有データストアは vSAN ではなく NFS にする。

NSX-T_Lab-2019_setup-VM.png

 

ネットワークまわりの構成は、ラボ目的での環境構築として意図的に下記のような構成としています。

作成するラボでは、主に操作感(GUI / API)、オーバーレイ ネットワーク、ファイアウォール機能を確認するつもりです。

  • NSX Edge は、あえてオーバーレイ ネットワークを構成するクラスタとは別のクラスタに配置。
    • これは、NSX Edge 専用のクラスタが必要、というわけではありません。
    • ESXi のトランスポート ノードと、Edge トランスポート ノードとで、搭載する側の ESXi の構成差異を見やすくするため。
  • Tier-0 ルータのアップリンク(オーバーレイ ネットワークへの入り口)は管理ネットワークと兼用。
    • NSX 特有のネットワークに入るまでの部分はシンプルにしたかったため。
  • Tier-0 ルータではルーティング プロトコルを利用せず、たんにスタティックルートで NSX のネットワークへ。
  • オーバーレイの TEP(VTEP)には VLAN ID を付与。
  • オーバーレイ ネットワークの、元 / 先 / それ以外、として 3ノードの ESXi を用意。
  • NFS データストアの接続は、NSX が構成するネットワークとは直接的に関係しないので、vmk0 の管理ネットワークを兼用。
  • オーバーレイ ネットワークで利用する pNIC ポート(ESXi VM の vNIC)はあえて複数構成。
    • アップリンク プロファイルを理解しやすいように複数本(vmnic1 + vmnic2 のような)で冗長化。

NSX-T_Lab-2019-NW.png

※そのうち物理 / 論理構成を分けて、アドレス例も入れてあらためて・・・

 

実際に構築する NSX-T ラボの様子。

まず、ラボ全体を管理する vCenter の vSphere Client(HTML5 Client)です。

vCenter 6.7 では、基本的にこの vSphere Client を利用します。

 

物理 ESXi ホストには、vCenter(VCSA)、NSX Manger、NFS サーバ、ESXi VM といったものが配置されます。

それぞれ、役割の想像がしやすそうな VM 名にしてみました。

ここでの「ESXi VM」とは VM に ESXi をインストールしたもの(ネステッド ESXi)で、

通常の ESXi と同様に VM を起動したり、vCenter から管理したりできます。

nsxt-lab-01-ext.png

 

そして次は、「ネステッド ESXi + NSX-T」環境を管理する vCenter の、vSphere Client です。

上記のスクリーンショットにある lab-esxi-~ という VM は、この vCenter に ESXi として登録してあります。

この環境では、すでに NSX-T との連携がされており、ESXi に「N-VDS」という

NSX-T ならではの特別な仮想スイッチが構成されています。

nsxt-lab-02-nested.png

 

最後に、NSX Manager の画面です。

これは、上記のスクリーンショットと同じ環境を NSX Manager から見たところです。

NSX for vSphere(NSX-V)では、vSphere Client から NSX の設定をしていましたが、

NSX-T では、NSX Manager が提供する別の UI から、NSX の設定をすることになります。

nsxt-lab-03-mgr.png

 

では、これから下記のような流れでポイントを紹介していこうと思います。

  • 土台になる、外側の物理 ESXi ホスト(の vCenter)での設定。
  • NSX-T と連携する vCenter(ネステッド ESXi を利用した環境)での設定。
  • NSX-T 環境のセットアップ。

 

つづく。

自宅ラボで NSX-T 2.4 環境を構築する。Part.2

前回の投稿では、ESXi のインストールメディアの転送に TFTP を利用しました。

 

ESXi を PXE Boot でインストールしてみる。(dnsmasq)

https://communities.vmware.com/people/gowatana/blog/2019/05/30/esxi-pxe-tftp

 

今回は、ESXi のインストーラの転送を HTTP に変更してみます。

ドキュメントでは、下記のあたりです。

Web サーバを使用した ESXi インストーラの PXE ブート

 

今回の環境。

今回は、前回の投稿で作成した環境を構成変更します。

おもな差分は、赤字の部分です。

  • OS: Oracle Linux 7
  • DHCP / TFTP サーバ: OS 標準提供の dnsmasq RPM
  • syslinux ブートローダ: OS 標準提供の syslinux-tftpboot RPM
  • PXE Boot 対象マシンのファームウェア: BIOS
  • ESXi インストール メディア: HTTP サーバに配置。Apache HTTP Server(httpd)を利用

 

PXE 環境の構成変更。

前回の構成では、ブートローダファイル pxelinux.0 を使用していました。

一方 HTTP でのインストールイメージ転送では、HTTP に対応している gpxelinux.0 を利用します。

そこで、DHCP オプションで指定してるファイル名を変更します。

 

ちなみに、前回利用した  pxelinux.0 のままだと、

下記のように URL を指定した HTTP によるファイルの読み込みができないようです。

esxi-pxeboot-10.png

 

今回は dnsmasq の DHCP 機能を利用しているので、/etc/dnsmasq.conf ファイルを編集します。

  • 赤字部分が前回からの差分です。
  • gpxelinux.0 は、syslinux-tftpboot RPM に含まれています。
  • PXE のプロセスでは TFTP を利用するので、TFTP 関連の設定はそのまま残します。

(省略)

interface=ens33

dhcp-range=192.168.163.200,192.168.163.209,6h

dhcp-boot=gpxelinux.0

enable-tftp

tftp-root=/var/lib/tftpboot

 

dnsmasq のサービスを再起動しておきます。

[root@pxe01 ~]# systemctl restart dnsmasq

 

前回 ESXi の ISO イメージ ファイルの内容をコピーした

TFTP サーバの公開ディレクトリ /var/lib/tftpboot/ESXi67u2/ には、

ブートで必要な下記のファイル(boot.cfg と mboot.c32)を残します。

[root@pxe01 ~]# ls -l /var/lib/tftpboot/ESXi67u2/

合計 96

-r-xr-xr-x. 1 root root  2713  5月 31 07:34 boot.cfg

-r-xr-xr-x. 1 root root 93288  3月 27 13:47 mboot.c32

 

そして boot.cfg の prefix を編集します。

 

編集前(前回のファイル)

[root@pxe01 ~]# cat /var/lib/tftpboot/ESXi67u2/boot.cfg | head -n 4

bootstate=0

title=Loading ESXi installer

timeout=5

prefix=ESXi67u2

 

編集後

※「192.168.163.149」はESXi のインストーラを配置する HTTP サーバのアドレスです。

[root@pxe01 ~]# cat /var/lib/tftpboot/ESXi67u2/boot.cfg | head -n 4

bootstate=0

title=Loading ESXi installer

timeout=5

prefix=http://192.168.163.149/ESXi67u2

 

HTTP サーバの用意。

OS 標準提供の Apache HTTP Server の RPM をインストールして、起動します。

[root@pxe01 ~]# yum install -y httpd

[root@pxe01 ~]# systemctl start httpd

[root@pxe01 ~]# systemctl enable httpd

 

HTTP サーバが起動して、Test Page が参照(HTTP でダウンロード)できるようになります。

※Test Page は Web ブラウザからでも確認できます。

[root@pxe01 ~]# curl -s http://192.168.163.149/ | head -n 3

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

        <head>

                <title>Apache HTTP Server Test Page powered by Linux</title>

 

ESXi インストールメディアの配置。

HTTP サーバの公開ディレクトリ(デフォルトの /var/www/html)配下に

「ESXi67u2」というディレクトリを作成して、そこに ESXi の ISO ファイルの内容をコピーします。

[root@pxe01 ~]# mkdir /var/www/html/ESXi67u2

[root@pxe01 ~]# mount -o loop VMware-VMvisor-Installer-6.7.0.update02-13006603.x86_64.iso /mnt

[root@pxe01 ~]# cp -pr /mnt/* /var/www/html/ESXi67u2/

 

配置したファイルに HTTP 経由でアクセスできることを確認しておきます。

※Web ブラウザからでも確認できます。

[root@pxe01 ~]# curl -s http://192.168.163.149/ESXi67u2/ | head -n 5

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<html>

<head>

  <title>Index of /ESXi67u2</title>

</head>

 

PXE Boot での ESXi インストーラ起動の様子。

PXE Boot のメニューで、ESXi インストーラを選択すると・・・

esxi-pxeboot-11.png

 

boot.cfg の prefix で指定したアドレスの HTTP サーバから

ファイルが読み込まれていることがわかります。

esxi-pxeboot-12.png

 

PXE Boot を利用するような環境では、RPM などの OS パッケージを配置したリポジトリ

(YUM サーバなど)を用意しているケースがあるかなと思います。

ESXi インストーラも HTTP サーバに配置することで、

PXE 環境と、OS & ESXi のリポジトリを分離して管理できそうです。

 

以上、ESXi インストーラを HTTP サーバに配置してみる話でした。

ESXi は、PXE でインストーラからブートしてインストールすることができます。

PXE 環境を用意するには、DHCP や TFTP といったサービスが必要です。

 

ドキュメントでは下記のあたりです。

ESXi インストーラの PXE ブート

 

今回は、PXE 環境を Linux と dnsmasq を利用して構築してみます。

dnsmasq は簡易的な DNS サーバとして利用されることが多いですが、

PXE に必要な DHCP サービスと TFTP サービスも提供できます。

 

今回の環境。

使用するソフトウェアは下記です。

  • OS: Oracle Linux 7
  • DHCP / TFTP サーバ: OS 標準提供の dnsmasq RPM
  • syslinux ブートローダ: OS 標準提供の syslinux-tftpboot RPM
  • PXE Boot 対象マシンのファームウェア: BIOS
  • ESXi インストール メディア: TFTP サーバに配置(PXE サーバ自身)

 

ちなみに、今回の PXE サーバとインストール対象サーバは

VMware Workstation Pro 15 に VM で作成しています。

 

PXE サーバにする OS の準備。

Linux は、Oracle Linux 7.6 を利用しています。

※ちなみに RHEL や CentOS でも同様の手順で構築可能なはずです。

[root@pxe01 ~]# cat /etc/oracle-release

Oracle Linux Server release 7.6

 

わかりやすく、ホスト名を変更しておきます。

そして OS にログインしなおしてプロンプトの文字列を変更しておきます。

[root@localhost ~]# hostnamectl set-hostname pxe01

 

手順を簡略化するため、firewalld は停止しています。

[root@pxe01 ~]# systemctl stop firewalld

[root@pxe01 ~]# systemctl disable firewalld

 

DHCP / TFTP サーバの構築。

dnsmasq をインストールします。

[root@pxe01 ~]# yum install -y dnsmasq

[root@pxe01 ~]# yum list dnsmasq

読み込んだプラグイン:ulninfo

インストール済みパッケージ

dnsmasq.x86_64                      2.76-7.el7                       @ol7_latest

 

あわせて、TFTP Boot むけ syslinux ブートローダの RPM(syslinux-tftpboot)も

インストールしておきます。

[root@pxe01 ~]# yum install -y syslinux-tftpboot

[root@pxe01 ~]# yum list syslinux-tftpboot

読み込んだプラグイン:ulninfo

インストール済みパッケージ

syslinux-tftpboot.noarch                 4.05-15.el7                 @ol7_latest

 

ちなみに、syslinux-tftpboot をインストールすると、下記のように

/var/lib/tftpboot/ ディレクトリ配下にブートローダ関連のファイルが配置されます。

[root@pxe01 ~]# rpm -ql syslinux-tftpboot

/var/lib/tftpboot

/var/lib/tftpboot/cat.c32

/var/lib/tftpboot/chain.c32

/var/lib/tftpboot/cmd.c32

/var/lib/tftpboot/config.c32

/var/lib/tftpboot/cpuid.c32

/var/lib/tftpboot/cpuidtest.c32

/var/lib/tftpboot/disk.c32

/var/lib/tftpboot/dmitest.c32

/var/lib/tftpboot/elf.c32

/var/lib/tftpboot/ethersel.c32

/var/lib/tftpboot/gfxboot.c32

/var/lib/tftpboot/gpxecmd.c32

/var/lib/tftpboot/gpxelinux.0

/var/lib/tftpboot/hdt.c32

/var/lib/tftpboot/host.c32

/var/lib/tftpboot/ifcpu.c32

/var/lib/tftpboot/ifcpu64.c32

/var/lib/tftpboot/ifplop.c32

/var/lib/tftpboot/int18.com

/var/lib/tftpboot/kbdmap.c32

/var/lib/tftpboot/linux.c32

/var/lib/tftpboot/ls.c32

/var/lib/tftpboot/lua.c32

/var/lib/tftpboot/mboot.c32

/var/lib/tftpboot/memdisk

/var/lib/tftpboot/memdump.com

/var/lib/tftpboot/meminfo.c32

/var/lib/tftpboot/menu.c32

/var/lib/tftpboot/pcitest.c32

/var/lib/tftpboot/pmload.c32

/var/lib/tftpboot/poweroff.com

/var/lib/tftpboot/pwd.c32

/var/lib/tftpboot/pxechain.com

/var/lib/tftpboot/pxelinux.0

/var/lib/tftpboot/reboot.c32

/var/lib/tftpboot/rosh.c32

/var/lib/tftpboot/sanboot.c32

/var/lib/tftpboot/sdi.c32

/var/lib/tftpboot/sysdump.c32

/var/lib/tftpboot/ver.com

/var/lib/tftpboot/vesainfo.c32

/var/lib/tftpboot/vesamenu.c32

/var/lib/tftpboot/vpdtest.c32

/var/lib/tftpboot/whichsys.c32

/var/lib/tftpboot/zzjson.c32

 

dnsmasq に DHCP / TFTP サービス関連の設定をします。vi エディタなどで、

/etc/dnsmasq.conf ファイルの末尾に下記を追記します。

  • interface は ens33 としていますが、環境によって eth0 や ens192 といった名前になります。
  • dhcp-range は、ESXi インストール対象のマシンが PXE サーバにアクセスする際に利用する IP アドレス レンジを指定します。

interface=ens33

dhcp-range=192.168.163.200,192.168.163.209,6h

dhcp-boot=pxelinux.0

enable-tftp

tftp-root=/var/lib/tftpboot

 

dnsmasq のサービスを起動しておきます。

[root@pxe01 ~]# systemctl start dnsmasq

[root@pxe01 ~]# systemctl enable dnsmasq

 

syslinux での PXE 設定ファイルの用意。

pxelinux.cfg ディレクトリを作成します。

[root@pxe01 ~]# mkdir /var/lib/tftpboot/pxelinux.cfg

 

/var/lib/tftpboot/pxelinux.cfg/default ファイルを、下記のような内容で作成します。

  • 「LABEL ESXi67u2」以降には、今回インストールで利用する ESXi 6.7 U2 のメニューを追加しています。
  • (必須ではありませんが)メニュー画面の見栄えをよくするために「MENU INCLUDE pxelinux.cfg/pxe.conf」といった設定をしています。

DEFAULT vesamenu.c32

TIMEOUT 800

ONTIMEOUT 1

PROMPT 0

MENU INCLUDE pxelinux.cfg/pxe.conf

NOESCAPE 1

LABEL 1

  MENU LABEL Local Boot

  localboot 0

  TEXT HELP

  Boot to local hard disk

  ENDTEXT

 

LABEL ESXi67u2

  KERNEL /ESXi67u2/mboot.c32

  APPEND -c /ESXi67u2/boot.cfg

  MENU LABEL ESXi67 Update 2 ^Installer

 

MENU INCLUDE で指定している pxe.conf ファイルは、下記の内容で作成しています。

 

/var/lib/tftpboot/pxelinux.cfg/pxe.conf

MENU TITLE  PXE Server pxe01

NOESCAPE 1

ALLOWOPTIONS 1

PROMPT 0

menu width 80

menu rows 14

MENU TABMSGROW 24

MENU MARGIN 10

menu color title 1;36;44 #ff008080 #00000000 std

 

PXE サーバへの ESXi インストーラの配置。

今回は、ESXi 6.7 U2 のインストーラを利用します。

My VMware サイトから、下記のファイルを入手しておきます。

VMware-VMvisor-Installer-6.7.0.update02-13006603.x86_64.iso

 

PXE サーバに ISO ファイルを転送ずみです。

[root@pxe01 ~]# ls -1

VMware-VMvisor-Installer-6.7.0.update02-13006603.x86_64.iso

anaconda-ks.cfg

 

インストーラを /mnt ディレクトリにマウントします。

[root@pxe01 ~]# mount -o loop ./VMware-VMvisor-Installer-6.7.0.update02-13006603.x86_64.iso /mnt

mount: /dev/loop0 is write-protected, mounting read-only

 

TFTP サーバが公開しているディレクトリの配下にディレクトリを作成して、

ISOファイルからファイルをコピーします。

[root@pxe01 ~]# mkdir /var/lib/tftpboot/ESXi67u2

[root@pxe01 ~]# cp -pr /mnt/* /var/lib/tftpboot/ESXi67u2/

 

通常の CD ブートから PXE ブートに変更するため、boot.cfg ファイルを編集します。

  • boot.cfg で指定されているファイル名から、先頭の「/」を削除。
  • それらのファイル名の先頭に、TFTP のディレクトリ名をつける。(prefix=ESXi67u2)

編集箇所が多いため、sed コマンドで置換をしています。

[root@pxe02 ~]# sed -i 's|/||g' /var/lib/tftpboot/ESXi67u2/boot.cfg

[root@pxe02 ~]# sed -i 's|prefix=|prefix=ESXi67u2|' /var/lib/tftpboot/ESXi67u2/boot.cfg

 

インストール対象マシンのパワーオン。

インストール対象となるマシン(VM でも可)をパワーオンすると、

ここまでで設定した PXE Boot のメニューが表示されます。

esxi-pxeboot-01.png

 

メニューを選択してブートすると、

通常の ISO ブートとはファイルのパスが変更されていることがわかります。

esxi-pxeboot-02.png

 

これで、PXE Boot で ESXi のインストールが開始できるようになり、

このあとは通常どおりインストールを進めることになります。

 

以上、ESXi インストーラを PXE Boot してみる話でした。

つづく。

ESXi を PXE Boot でインストールしてみる。(HTTP 併用)

VMware Photon OS 3.0 の参照 DNS サーバの設定は、

これまでの Photon OS とは様子が変わっているようです。

今回は、Photon OS 3.0 の DNS サーバ アドレスの確認と、設定変更をしてみます。

 

Photon OS 3.0 は、GitHub の URL からダウンロードできる

「OVA with virtual hardware v13 (UEFI Secure Boot)」を利用しています。

Downloading Photon OS · vmware/photon Wiki · GitHub

root@photon-machine [ ~ ]# cat /etc/photon-release

VMware Photon OS 3.0

PHOTON_BUILD_NUMBER=26156e2

 

Photon 3.0 の /etc/resolv.conf は下記のように、

nameserver に「127.0.0.53」というアドレスが設定されています。

root@photon-machine [ ~ ]# cat /etc/resolv.conf

# This file is managed by man:systemd-resolved(8). Do not edit.

#

# This is a dynamic resolv.conf file for connecting local clients to the

# internal DNS stub resolver of systemd-resolved. This file lists all

# configured search domains.

#

# Run "resolvectl status" to see details about the uplink DNS servers

# currently in use.

#

# Third party programs must not access this file directly, but only through the

# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,

# replace this symlink by a static file or a different symlink.

#

# See man:systemd-resolved.service(8) for details about the supported modes of

# operation for /etc/resolv.conf.

 

nameserver 127.0.0.53

 

このアドレスは、DNS サーバ関連のようで、UDP 53 番ポートで待ち受けているようです。

root@photon-machine [ ~ ]# ss -an | grep 127.0.0.53

udp   UNCONN  0        0                              127.0.0.53%lo:53                                               0.0.0.0:*

 

そして 53番ポートのプロセスを確認してみると、

resolv.conf のコメントとも関係ありそうな systemd-resolve というものです。

root@photon-machine [ ~ ]# tdnf install -y lsof

root@photon-machine [ ~ ]# lsof -i:53 -P -n

COMMAND   PID            USER   FD   TYPE DEVICE SIZE/OFF NODE NAME

systemd-r 205 systemd-resolve   12u  IPv4   3644      0t0  UDP 127.0.0.53:53

root@photon-machine [ ~ ]# ps -p 205

  PID TTY          TIME CMD

  205 ?        00:00:00 systemd-resolve

 

これは、systemd 229 以降に導入された名前解決マネージャーの仕組みのようです。

https://www.freedesktop.org/wiki/Software/systemd/resolved/

 

ちなみに、Photon 3.0 は systemd 239 でした。

root@photon-machine [ ~ ]# rpm -q systemd

systemd-239-10.ph3.x86_64

 

DNS サーバのアドレスは、/etc/systemd/network/*.network ファイルの

「DNS=」で設定したものが反映されます。

 

Photon OS 3.0 では、デフォルトでは DHCP 設定のファイルが配置されています。

root@photon-machine [ ~ ]# cat /etc/systemd/network/99-dhcp-en.network

[Match]

Name=e*

 

[Network]

DHCP=yes

IPv6AcceptRA=no

 

現時点では、DHCP 設定により自宅ラボの  DNS サーバ 2台が設定されています。

root@photon-machine [ ~ ]# resolvectl dns

Global:

Link 2 (eth0): 192.168.1.101 192.168.1.102

 

resolvectl では、より詳細な情報も確認できます。

(デフォルトだとページャが作用しますが、とりあえず cat で全体表示しています)

root@photon-machine [ ~ ]# resolvectl | cat

Global

       LLMNR setting: no

MulticastDNS setting: yes

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

Fallback DNS Servers: 8.8.8.8

                      8.8.4.4

                      2001:4860:4860::8888

                      2001:4860:4860::8844

          DNSSEC NTA: 10.in-addr.arpa

                      16.172.in-addr.arpa

                      168.192.in-addr.arpa

                      17.172.in-addr.arpa

                      18.172.in-addr.arpa

                      19.172.in-addr.arpa

                      20.172.in-addr.arpa

                      21.172.in-addr.arpa

                      22.172.in-addr.arpa

                      23.172.in-addr.arpa

                      24.172.in-addr.arpa

                      25.172.in-addr.arpa

                      26.172.in-addr.arpa

                      27.172.in-addr.arpa

                      28.172.in-addr.arpa

                      29.172.in-addr.arpa

                      30.172.in-addr.arpa

                      31.172.in-addr.arpa

                      corp

                      d.f.ip6.arpa

                      home

                      internal

                      intranet

                      lan

                      local

                      private

                      test

 

Link 2 (eth0)

      Current Scopes: DNS

       LLMNR setting: yes

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

  Current DNS Server: 192.168.1.101

         DNS Servers: 192.168.1.101

                      192.168.1.102

 

ためしに、DNS サーバのアドレスを変更してみます。

設定ファイルを vi エディタで編集します。

root@photon-machine [ ~ ]# vi /etc/systemd/network/99-dhcp-en.network

 

今回は、下記の赤字部分を追記します。

[Match]

Name=e*

 

[Network]

DHCP=yes

IPv6AcceptRA=no

Domains=go-lab.jp

DNS=192.168.1.1

DNS=192.168.1.2

 

ネットワークを再起動します。

root@photon-machine [ ~ ]# systemctl restart systemd-networkd

 

DNS サーバアドレスが追加登録されました。

DHCP サーバによる DNS サーバのアドレスよりも高優先度で

ファイルに追記した DNS サーバが追加されました。

root@photon-machine [ ~ ]# resolvectl dns

Global:

Link 2 (eth0): 192.168.1.1 192.168.1.2 192.168.1.101 192.168.1.102

 

resolvectl コマンドの末尾 10行だけ表示してみると、

「Domains」のドメインも追加されています。

root@photon-machine [ ~ ]# resolvectl | tail -n 10

       LLMNR setting: yes

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

         DNS Servers: 192.168.1.1

                      192.168.1.2

                      192.168.1.101

                      192.168.1.102

          DNS Domain: go-lab.jp

 

実際に名前解決が発生すると、利用されている DNS サーバ(Current DNS Server)がわかります。

root@photon-machine [ ~ ]# resolvectl | tail -n 10

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

  Current DNS Server: 192.168.1.1

         DNS Servers: 192.168.1.1

                      192.168.1.2

                      192.168.1.101

                      192.168.1.102

          DNS Domain: go-lab.jp

 

DNS サーバ のアドレスが変更されても、/etc/resolv.conf のアドレスは

127.0.0.53 のままですが、サーチドメインは追加されます。

root@photon-machine [ ~ ]# grep -v '#' /etc/resolv.conf

 

nameserver 127.0.0.53

search go-lab.jp

 

以上。Photon OS 3.0 の DNS サーバ アドレス設定の様子でした。

VMware Photon OS 3.0 で、簡易的な DNS サーバを構築してみます。

今回は、Photon OS の RPM リポジトリに登録されている dnsmasq を利用します。

 

Photon OS の準備。

VMware から提供されている、Photon OS の OVA をデプロイします。

今回は、「OVA with virtual hardware v13 (UEFI Secure Boot)」を利用しました。

Downloading Photon OS · vmware/photon Wiki · GitHub

 

OVA ファイルをデプロイ→パワーオンします。

そして、root / changeme で初期パスワードを変更してログインします。

root@photon-machine [ ~ ]# cat /etc/photon-release

VMware Photon OS 3.0

PHOTON_BUILD_NUMBER=26156e2

 

ホスト名を、わかりやすいもの(今回は lab-dns-01)に変更しておきます。

ログインしなおすと、bash のプロンプトにもホスト名が反映されます。

root@photon-machine [ ~ ]# hostnamectl set-hostname lab-dns-01

 

ネットワーク設定は、DHCP を利用しています。

 

DNS サーバの構築。(dnsmasq)

まず、dnsmasq をインストールします。

root@lab-dns-01 [ ~ ]# tdnf install -y dnsmasq

root@lab-dns-01 [ ~ ]# rpm -q dnsmasq

dnsmasq-2.79-2.ph3.x86_64

 

dnsmasq では、hosts ファイルのエントリを DNS レコードとして利用できます。

/etc/hosts ファイルに、DNS レコードの情報を記入します。

root@lab-dns-01 [ ~ ]# echo '192.168.1.20 base-esxi-01.go-lab.jp' >> /etc/hosts

root@lab-dns-01 [ ~ ]# echo '192.168.1.30 lab-vcsa-01.go-lab.jp' >> /etc/hosts

root@lab-dns-01 [ ~ ]# tail -n 2 /etc/hosts

192.168.1.20 base-esxi-01.go-lab.jp

192.168.1.30 lab-vcsa-01.go-lab.jp

 

dnsmasq を起動します。

root@lab-dns-01 [ ~ ]# systemctl start dnsmasq

root@lab-dns-01 [ ~ ]# systemctl is-active dnsmasq

active

root@lab-dns-01 [ ~ ]# systemctl enable dnsmasq

Created symlink /etc/systemd/system/multi-user.target.wants/dnsmasq.service → /lib/systemd/system/dnsmasq.service.

 

hosts ファイルを編集した場合は、dnsmasq サービスを再起動しておきます。

root@lab-dns-01 [ ~ ]# systemctl restart dnsmasq

 

iptables で、DNS のポートを開放しておきます。

iptables-save コマンドを利用するかわりに、/etc/systemd/scripts/ip4save ファイルへの

「-A INPUT -p udp -m udp --dport 53 -j ACCEPT」直接追記でも、同様に iptables の設定を永続化できます。

root@lab-dns-01 [ ~ ]# iptables -A INPUT -p udp -m udp --dport 53 -j ACCEPT

root@lab-dns-01 [ ~ ]# iptables-save > /etc/systemd/scripts/ip4save

root@lab-dns-01 [ ~ ]# systemctl restart iptables

 

名前解決の確認。

別の Photon OS 3.0 に、bindutils をインストールします。

root@photon-machine [ ~ ]# tdnf install -y bindutils

 

bindutils には、nslookup や dig コマンドが含まれます。

root@photon-machine [ ~ ]# rpm -ql bindutils

/etc/named.conf

/usr/bin/dig

/usr/bin/host

/usr/bin/nslookup

/usr/lib/tmpfiles.d/named.conf

/usr/share/man/man1/dig.1.gz

/usr/share/man/man1/host.1.gz

/usr/share/man/man1/nslookup.1.gz

 

登録したレコードの名前解決ができることを確認します。

ここでは、「lab-vcsa-01.go-lab.jp」と「192.168.1.30」を正引き / 逆引きで確認してみます。

「192.168.1.15」は、dnsmasq をインストールした DNS サーバのアドレスです。

root@photon-machine [ ~ ]# nslookup lab-vcsa-01.go-lab.jp 192.168.1.15

Server:         192.168.1.15

Address:        192.168.1.15#53

 

Name:   lab-vcsa-01.go-lab.jp

Address: 192.168.1.30

 

root@photon-machine [ ~ ]# nslookup 192.168.1.30 192.168.1.15

30.1.168.192.in-addr.arpa       name = lab-vcsa-01.go-lab.jp.

 

 

これで、ラボなどで利用する DNS サーバが用意できます。

 

以上、Photon OS 3.0 を DNS サーバにしてみる話でした。

自宅ラボの vSAN のキャッシュ ディスク容量について考える機会があり、

ためしに、vROps(vRealize Operations Manager)で、vSAN を見てみました。

今回は、vROps 7.5 で、vSAN 6.7 U1 を表示しています。

 

vROps では、vSAN アダプタを設定ずみです。

vrops-vsan-cache-size-00.png

 

vROps では vSAN のモニタリングも可能で、

よく話題になる、ディスク グループの書き込みバッファの空き容量(%)が確認できたりします。

vrops-vsan-cache-size-01.png

 

それでは、キャッシュ ディスクの推奨サイズを確認してみます。

「環境」→「すべてのオブジェクト」を開きます。

vrops-vsan-cache-size-02.png

 

「すべてのオブジェクト」→「vSAN アダプタ」→「キャッシュ ディスク」配下の

キャッシュ ディスクを選択します。

ESXi ホストに 128GB のキャッシュ用SSDが搭載されていることがわかります。

vrops-vsan-cache-size-03.png

 

キャッシュ ディスクを選択した状態で、

「すべてのメトリック」→「キャパシティ分析が生成されました」→「ディスク容量」

を開いて、「推奨サイズ(GB)」をダブルクリックすると、推奨サイズのグラフが表示されます。

この環境だと 59.62GB が推奨のようなので、キャッシュ ディスクの容量は十分なようです。

vrops-vsan-cache-size-04.png

 

ちなみにキャッシュ ディスクの情報は、下記のように「vSAN およびストレージ デバイス」

からでも表示できます。しかしキャッシュ ディスクだけを見る場合は、今回のように

「すべてのオブジェクト」からのツリーのほうが確認しやすいかなと思います。

vrops-vsan-cache-size-05.png

 

ちなみに、ドキュメントにも一応 vSAN のメトリックが記載されています。

(ただ、実機と一致はしていないような気も・・・)

vSAN のメトリック

 

まだ vROps をデプロイ&情報収集を開始してまもない状態の情報なので、

令和になったらまた見てみようと思います。

 

以上、vROps で vSAN キャッシュ ディスクの推奨サイズを見てみる話でした。

vSAN 6.7 U1 では、「仮想マシン ストレージ ポリシー」を考慮した

データストア空き容量の確認ができるようになっています。

 

下記のように、vSAN データストアの「容量の概要」画面の

「ポリシーで使用可能な容量」で仮想マシンが利用できる空き容量を確認できます。

スクリーンショットでは、デフォルトのポリシー「vSAN Default Storage Policy」で算出されています。

vsan-usage-01.png

 

そこで、別の仮想マシンストレージポリシーで使用可能容量を確認してみます。

デフォルトのポリシーでは「許容される障害の数:1 件の障害 - RAID-1(ミラーリング)」なので、

あえて、「policy-vsan-raid0」という名前で「データの冗長性なし」のポリシーを作成しました。

vsan-usage-02.png

 

「容量の概要」画面でこのポリシーを指定すると、このポリシーを利用した場合に

ポリシーで使用可能な容量が 2倍になることがわかります。(ただし冗長性はありません)

vsan-usage-03.png

 

実は、この情報は PowerCLI でも確認できるようになりました。

PowerCLI 11.2 Released, with more goodness for vSAN!

 

そこで、PowerCLI でも 同様の空き容量確認をしてみます。

 

今回は、PowerCLI 11.2 を利用しています。vCenter には既に接続ずみです。

PowerCLI> Import-Module VMware.PowerCLI

PowerCLI> Get-Module VMware.PowerCLI | select Name,Version

 

Name            Version

----            -------

VMware.PowerCLI 11.2.0.12483598

 

 

PowerCLI では、Get-VsanSpaceUsage で vSAN の容量情報を確認できます。

※ infra-cluster-01 は、vSAN クラスタの名前を指定しています。

 

ただし、下記にあるような FreeSpaceGB や CapacityGB には、

今回確認しているポリシーをもとにした空き容量が反映されません。

そこで、VsanWhatIfCapacity プロパティを確認します。

PowerCLI> Get-VsanSpaceUsage -Cluster infra-cluster-01

 

Cluster              FreeSpaceGB     CapacityGB

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

infra-cluster-01     2,911.358       4,657.552

 

 

特に仮想マシン ストレージ ポリシーを指定していない場合、

VsanWhatIfCapacity は情報を持ちません。

PowerCLI> Get-VsanSpaceUsage -Cluster infra-cluster-01 | select -ExpandProperty VsanWhatIfCapacity

PowerCLI>

 

デフォルトのポリシーを指定した場合です。

PowerCLI> Get-VsanSpaceUsage -Cluster infra-cluster-01 -StoragePolicy "vSAN Default Storage Policy" | select -ExpandProperty VsanWhatIfCapacity | Format-List

 

StoragePolicy         : vSAN Default Storage Policy

TotalWhatIfCapacityGB : 2328.77610206604

FreeWhatIfCapacityGB  : 1455.28823816683

 

 

今回作成した「policy-vsan-raid0」を指定すると、結果に反映されます。

PowerCLI> Get-VsanSpaceUsage -Cluster infra-cluster-01 -StoragePolicy "policy-vsan-raid0" | select -ExpandProperty VsanWhatIfCapacity | Format-List

 

StoragePolicy         : policy-vsan-raid0

TotalWhatIfCapacityGB : 4657.55220413208

FreeWhatIfCapacityGB  : 2910.5833046427

 

 

独自の仮想マシン ストレージ ポリシーを作成した時などに

確認手順に取り込んでおくと便利かもしれないと思いました。

 

以上、vSAN データストアの空き容量確認についての話でした。

vSAN に RAID5 / RAID6 の 仮想ディスク(VMDK)を配置するには、ノード数の要件があります。

  • RAID5 → 4ノード以上(4つ以上のフォルト ドメイン)
  • RAID6 → 6ノード以上(6つ以上のフォルト ドメイン)

参考: RAID 5 または RAID 6 イレージャ コーディングの使用

 

下記のサイトによると、これは vSAN の RAID の実装によるもので、

RAID5 が 4つ、RAID6 が 6つのコンポーネントとして実装されているためのようです。

 

VSAN ERASURE CODING FAILURE HANDLING

https://cormachogan.com/2018/12/13/vsan-erasure-coding-failure-handling/

 

そこで今回は 6より多いノード数で、

実際に vSAN の RAID5 / RAID6 ポリシーの VM を作成してみました。

 

vSAN 環境。

下記のように、オールフラッシュディスクグループの7ノード構成にしています。

  • vSAN 6.7 U1
  • ESXi 7ノード
  • オール フラッシュ(キャッシュ層 SSD + キャパシティ層 SSD)ディスクグループ
  • ディスクグループは各ノードで 1つずつ(キャッシュ層 x1 + キャパシティ層 x2)
  • フォールト ドメインはデフォルト構成のまま

vsan-raid56-00.png

 

仮想マシン ストレージポリシーの作成。

RAID5 のストレージポリシーを作成します。

今回は「許容される障害の数」だけデフォルト値から変更しています。

vsan-raid56-01.png

 

RAID5 のポリシー名は「vSAN-RAID5-Policy」にしました。

vsan-raid56-02.png

 

RAID6のポリシーも、同様に「vSAN-RAID6-Policy」として作成しました。

vsan-raid56-04.png

 

仮想マシンの作成。(RAID5)

仮想マシンを、「vSAN-RAID5-Policy」で作成しました。

ちなみに、今回は 40GB で Thin プロビジョニングの VMDK を 1つだけ作成しています。

vsan-raid56-05.png

 

RAID5 になっている仮想ディスクの物理配置を確認すると、ノード数が4つより多くても、

コンポーネントは 4つ(4ノード)に分散されています。

vsan-raid56-06.png

 

仮想マシンの作成。(RAID6)

次に、仮想マシンを「vSAN-RAID6-Policy」で作成しました。

vsan-raid56-07.png

 

RAID6 の仮想ディスクの物理配置についても、

ノード数が4つより多くても、コンポーネントは 6つ(6ノード)に分散されています。

vsan-raid56-08.png

 

vSAN の RAID5 / RAID6 は、基本的にはノード数が多いからといって

RAID のストライプ数があわせて増加するわけではないようです。

おそらくは、可用性と性能のバランスをとった設計なのだろうと思います。

 

以上、vSAN の RAID5 / RAID6 の仮想ディスク コンポーネントを見てみる話でした。

vSphere 6.0 から vCenter 間での vMotion が可能になりましたが、

標準的な vSphere Web Client / vSphere Client(旧 HTML5 Client)から実行するには

vCenter が同一の PSC / vSphere Single Sign-On(SSO)ドメインに所属している必要があります。

そして vCenter の SSO ドメインが異なる場合の vCenter 間の vMotion は、

API や PowerCLI から実行する必要があります。

vCenter Server インスタンス間の移行の要件

 

そこで、今回は PowerCLI を利用して、できるだけシンプルな構成で

Cross vCenter vMotion を実行してみます。

 

今回の環境。

vCenter 6.7 を 2台用意しました。それぞれ別の SSO ドメインに所属しているので、

それぞれ別の vSphere Client からの管理となっています。

 

移行元の vCenter の名前は、lab-nsxt-vcsa-01.go-lab.jp です。

この vCenter 配下の VM「vm05」を vMotion します。

xvc-vmotion-01.png

 

移行先の vCenter の名前は、infra-vc-01.go-lab.jp です。

xvc-vmotion-02.png

 

PowerCLI 11 を利用します。

PowerCLI> Get-Module -ListAvailable VMware.PowerCLI | select Name,Version

 

Name            Version

----            -------

VMware.PowerCLI 11.0.0.10380590

 

 

PowerCLI による Cross vCenter vMotion の実行。

今回は、PowerCLI のスクリプト実行ではなく、対話的な実行(コマンドラインの手入力)で

できるだけ簡潔に Cross vCenter vMotion を実行してみます。

 

まず、vMotion 元 / 先それぞれの vCenter に接続します。

PowerCLI> $vc_a = Connect-VIServer lab-nsxt-vcsa-01.go-lab.jp

PowerCLI> $vc_b = Connect-VIServer infra-vc-01.go-lab.jp

 

今回は、vCenter のバージョンがそろっています。

PowerCLI> $vc_a | select Name,Version,Build

 

Name                       Version Build

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

lab-nsxt-vcsa-01.go-lab.jp 6.7.0   10244857

 

 

PowerCLI> $vc_b | select Name,Version,Build

 

Name                  Version Build

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

infra-vc-01.go-lab.jp 6.7.0   10244857

 

 

vMotion 先として指定するため、ESXi、データストア、ポートグループを取得して、

それぞれ1件ずつ取得できていることを確認しておきます。

確実に移行先 vCenter から取得するため「-Server」で vCenter を明示的に指定しています。

 

データストアを取得します。

PowerCLI> $ds = Get-Datastore -Server $vc_b -Name "vsanDatastore"

PowerCLI> $ds | select Name,Type

 

Name          Type

----          ----

vsanDatastore vsan

 

 

今回の宛先ポートグループは、vDS の分散仮想スイッチです。

PowerCLI> $pg = Get-VDPortgroup -Server $vc_b -Name "dvpg-infra-0000"

PowerCLI> $pg | select Name

 

Name

----

dvpg-infra-0000

 

 

宛先のESXi です。

ちなみに Cross vCenter vMotion の宛先(Move-VM の -Destination)には、

ESXi(VMHost)かリソースプールを指定できます。

PowerCLI> $hv = Get-VMHost -Server $vc_b -Name "infra-esxi-01.go-lab.jp"

PowerCLI> $hv | select Name

 

Name

----

infra-esxi-01.go-lab.jp

 

 

VM「vm05」の現在の配置を確認しておきます。

「-Server」では、移行元の vCenter を指定しています。

PowerCLI> Get-VM -Server $vc_a -Name vm05 | select Name,PowerState,VMHost,@{N="vCenter";E={$_.Uid -replace ".*@|:.*",""}}| fl

 

Name       : vm05

PowerState : PoweredOn

VMHost     : lab-esxi-21.go-lab.jp

vCenter    : lab-nsxt-vcsa-01.go-lab.jp

 

 

それでは vm05 を vMotion します。

オプションで、あらかじめ取得した ESXi、データストア、ポートグループを指定しています。

PowerCLI> Get-VM -Server $vc_a -Name vm05 | Move-VM -Destination $hv -Datastore $ds -PortGroup $pg

 

vMotion 完了後に VM の配置を確認すると、期待通り vCenter 間で移動されたことがわかります。

PowerCLI> Get-VM -Name vm05 | select Name,PowerState,VMHost,@{N="vCenter";E={$_.Uid -replace ".*@|:.*",""}} | fl

 

Name       : vm05

PowerState : PoweredOn

VMHost     : infra-esxi-01.go-lab.jp

vCenter    : infra-vc-01.go-lab.jp

 

 

今回の処理を vSphere Client から見た様子。

ちなみに vMotion タスクの進捗は、PowerCLI で実行した場合でも

vSphere Client から確認することができます。

 

vMotion 実行中の、移行元 vCenter です。

xvc-vmotion-04.png

 

ほぼ同じタイミングでの、移行先 vCenter です。

タスク ステータスの進捗%は、移行元 / 先で一致するわけではありません。

xvc-vmotion-05.png

 

vCenter をまたいで、指定したホストに vMotion されました。

xvc-vmotion-06.png

 

このように、仮想マシンの vNIC や VMDK の構成がシンプルであれば、

対話的に PowerCLI を利用したとしても(PowerCLI スクリプトを作りこむことをしなくても)

簡単に Cross vCenter vMotion できます。

 

またそれぞれの vCenter / ESXi では、従来の vMotion と同様に

vmkポートでの vMotion トラフィックの有効化や、通信経路でのポート解放などを

済ませておく必要があります。

 

以上、PowerCLI で Cross vCenter vMotion を実行してみる話でした。

近年の日本では、クリスマスのアドベントカレンダーに見立てて

12月に1日1回、ブログ投稿するイベントが流行しています。

そこで今年は、さまざまな ネステッド vSAN 6.7 U1 を構成してみました。

 

Nested vSAN Advent Calendar 2018

https://adventar.org/calendars/3712

 

今回のネステッド vSAN は、下記のように構築しています。

PowerCLI スクリプトなどを利用しています。

図解 ネステッド vSAN ラボ。

ネステッド vSAN ラボを構築するための工夫 Part.1。(物理 マシン ESXi ~ VCSA デプロイ)

ネステッド vSAN ラボを構築するための工夫 Part.2。(物理マシン ESXi と ESXi VM の準備)

ネステッド vSAN ラボを構築するための工夫 Part.3。(vSAN クラスタ構築)

ネステッド vSAN ラボを構築するための工夫 Part.4。(スクリプトでの簡素化)

 

 

各日の投稿です。

 

スタンダードな 4ノード、ハイブリッド構成。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-01

 

3ノード。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-02

 

vCenter 配下に、2つの vSAN。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-03

 

オールフラッシュ構成。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-04

 

複数のキャパシティ層ディスク。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-05

 

複数のキャパシティ層ディスク。(さらにディスクを増やす)

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-06

 

複数のキャパシティ層ディスク。(構成の上限)

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-07

 

キャパシティ層ディスクのサイズ調整。VSAN.ClomMaxComponentSizeGB

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-08

 

RAID5。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-09

 

RAID6。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-10

 

2ノード。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-11

 

2ノードと WTS。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-12

 

2ノード → 3ノード。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-13

 

vSAN プロアクティブ テスト。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-14

 

ストレッチ クラスタでのネットワーク遅延テスト。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-15

 

vSAN とラック障害対策。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-16

 

vSAN と DC / サイト障害対策。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-17

 

ディスクグループがない vSAN ノード。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-18

 

重複排除・圧縮。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-19

 

vSAN iSCSI ターゲット。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-20

 

暗号化。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-21

 

1ノード。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-22

 

複数ディスクグループ構成。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-23

 

VCSA インストーラによる 1ノード vSAN。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-24

 

細かい手順までは触れていませんが、今月時点で最新バージョンの vSAN 6.7 U1 が

HTML5 Client(新 vSphere Client)で利用可能になった様子が俯瞰できるのではないかと思います。

 

以上、ネステッド vSAN を 1台の物理 PC で試してみる話でした。

今月は1日1回くらい、さまざまな ネステッド vSAN 6.7 U1 を構成してみています。

 

一連の投稿へのリンクは下記をどうぞ。

ネステッド vSAN 6.7 U1 を楽しむ。まとめ

 

昨日はこちら。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-23

 

24日目は、22日にも構成した 1ノードの vSAN です。

今回は、vCenter を vSAN 内部に配置しています。

構築の過程で、vCenter(VCSA)のデプロイと同時に配置先 vSAN を構成することで、

一時的に 1ノードの vSAN になるケースがあります。

 

vSAN-Cluster-20181224 クラスタ

  • ESXi は 1ノード
  • vCenter は vSAN 内部に配置

 

vCenter Server Appliance インストーラでの vSAN 構成。

vCenter Server を自身が管理する vSAN データストアに配置する場合に、

以前は、どこか一時的なデータストアに vCenter Server Appliance(VCSA)をデプロイして、

後から vSAN データストアに移動していました。

これは、vSAN の構成に vCenter が必要だったためです。

 

vSphere 6.7 では、VCSA のインストーラで仮想アプライアンスのデプロイと同時に

vSAN データストアを構成できるようになっています。

Deploying vSAN with vCenter Server Appliance

 

データストアの選択をする画面で、デプロイ先の ESXi に 1ノード vSAN クラスタを構成できます。

vsan-adv-d24-39.png

 

インストーラの画面遷移のなかで、vSAN データストアを構成するデバイスを指定できます。

このデプロイ先の ESXi は、今回は ネステッド ESXi です。

 

ちなみに、この環境の物理 ESXi には SSD が搭載されており、その上の VMDK による

「mpx.vmhba0:C0:T2:L0」(400GBの方)もフラッシュ デバイスとして認識されています。

このようなケースで、もし HDD として見せたい場合は、

ESXi の Host Client では HDD としてマーク付けができないようなので

ネステッド ESXi に SSH でログインして、esxcli コマンドで SATP ルールを設定します。

vsan-adv-d24-40.png

 

一連の VCSA のセットアップ処理が完了すると、

1ノード vSAN には、さらに構成(ノード追加や設定変更)が必要であると表示されます。

vsan-adv-d24-53.png

 

vCenter Server Appliance インストーラによる 1ノード vSAN。

インストーラで VCSA がデプロイされた直後の vSAN クラスタです。

  • デプロイした vCenter(VCSA): 192.168.1.39
    • 下スクリーンショットの vSphere Client は、この VCSAのもの。
  • VCSA が稼働する ESXi:  192.168.1.31

 

VCSA が稼働する ESXi ホストだけで、1ノード vSAN クラスタが構成されています。

相互通信する vSAN ノード(の ESXi ホスト)がいないため、

VMkernel ポートに「vSAN」トラフィックのタグが設定されていない状態でも vSAN として成り立っています。

そこでノード追加をする前に、このホストでも vSAN トラフィックのタグ設定が必要です。

vsan-adv-d24-02.png

 

VCSA の VM を見ると、vSAN データストア(vsanDatastore)に配置されていることがわかります。

しかし、仮想マシン ストレージ ポリシーは割り当てられていないようです。

この VM は、ノード追加後に、しかるべき仮想マシン ストレージ ポリシーを適用して

データの冗長性がある状態にする必要があります。

vsan-adv-d24-04.png

 

ただし、「vSAN Default Storage Policy」は作成されていて、

vsanDatastore にはデフォルトのポリシーとして設定されています。

vsan-adv-d24-06.png

 

ネスト環境での、VCSA インストーラによる 1ノード vSAN。

今回の ESXi ホストは、新規デプロイした vCenter(192.168.1.39)で管理されていますが、

それに対応する ESXi VM は、昨日までの vCenter(192.168.1.30)で管理されています。

 

ネスト環境で今回の構成を試す場合は、ネストの外側の物理 ESXi ではそれなりに高いスペックが要求されます。

VCSA のデプロイでは最低でも 10GB メモリが必要となるので、

デプロイ先の ネステッド ESXi でも、それを搭載できる容量が必要です。

今回は ESXi VM には 16GB のメモリを割り当てています。

 

ESXi VM(VCSA デプロイ先の ESXi にする)に割り当てる仮想ディスクも、

そこそこ大容量が必要で、まずシン プロビジョニングにすると思います。

VCSA のデプロイでは、ただテスト VM を作成するよりも容量を多めに消費するので

物理ホスト側のデータストア消費容量には要注意です。

(VCSA のデプロイ処理が途中で失敗すると特に悲しいため)

vsan-adv-d24-07.png

 

1ノード vSAN の動作確認をする場合、そもそも 1台は物理マシンがあるので、

2つ以上の物理ディスクが搭載されているのであれば、

あえてネステッド ESXi 上に構成する必要はありません。

それでもネスト環境を利用する場合は、下記のような事情がある場合かと思います。

  • 検証のために占有できる物理マシンがない。
  • 物理マシンに、搭載ディスク数がたりない。(キャッシュ層 / キャパシティ層むけ)

 

ただ個人的には、vSAN データストア上に vCenter を配置する場合には

VCSA インストーラを利用するよりも、一時的に vSAN 外部のデータストア

(ESXi をインストールするローカルディスクなど)にデプロイして、

複数ノード の vSAN を構成後に Storage vMotion で移動してしまうことが多いです。

 

まとめに、つづく。

ネステッド vSAN 6.7 U1 を楽しむ。まとめ