仮想基盤を設計・構築した時のメモ

目次

• はじめに
• 設計・構築した項目
  • ホスト
  • ネットワーク
  • ストレージ
  • OMSA
• おわりに

はじめに

すでにvCenter Server が存在する既存の環境に追加で構築する仮想基盤の設計・構築・導入までを今回初めて担当してよい経験となったので，その際学んだことを本記事にまとめていくため筆を取った．

構築・設計対象は下記の通り

• サーバー機はPowerEdge R640
• OSはVMware ESXi 6.7
• iSCSI で共有ストレージ上に仮想マシンをインストールする

設計・構築した項目

実際に設計した項目は主に4項目ある．その中でも特に大変だったのは，ネットワークとストレージであった．（ネットワークは既存環境をよく理解して設計する必要があり，ストレージは初めて導入するストレージだったので，用心深く製品調査を行ったから）

ホスト

ホストの設計は主に，IPアドレスとVLAN，どのvmnic をManagement Network に割り当てるかとRAID の設計が対象である．IPアドレスとVLAN は既存に倣う形で設定するので特に難しいことはない．vmnic はネットワークで説明する．
残るはRAID だが，業務に用いる仮想基盤ということと，ストレージが2枚あるということもあり，可用性に長けるRAID 1 を選択した．

RAID 1は，最低2台以上のディスクで実現可能なRAID 方式であり，RAID 1はミラーリングと呼ばれている．ミラーリングはその名の通りRAID を構成しているディスクに同じデータを書き込むことで，データの信頼性を高めている．
同じデータを複数のディスク上に書き込むため，書き込みスピードの面ではオーバーヘッドになってしまうが，RAID を組んでいるディスクのうち1つでもディスクが残存していれば，データやシステムに影響が出ない．

今回はESXi のインストールディスクということもあり，オーバーヘッドもあまり気にならず，システムの稼働持続が重要であるということもあり，RAID 1を選択した．

ネットワーク

仮想基盤のネットワークの設計図は以下のとおりである．

表にまとめると下記になる．vmnic を分解した理由は，vmnic0-3 までが一つのモジュール，vmnic4-5 が一つのモジュールになっており，モジュールで障害があったときのことを考えて割り当てを分散したかったためである．

仮想スイッチ	vmnic	vmk	ポートグループ	説明
vSwitch0	vmnic0	vmk0, vmk4	Management Network,	ESXi管理アクセス用，
	vmnic4	vmk0, vmk4	仮想マシンポートグループ	仮想マシン用
vSwitch1	vmnic1	vmk1, vmk5	iSCSI-1, vMotion	ストレージアクセス用 (vMotion含む)
	vmnic2	vmk2, vmk5	iSCSI-2, vMotion
	vmnic3	vmk3, vmk5	iSCSI-3, vMotion
	vmnic5	vmk4, vmk5	iSCSI-4, vMotion

仮想スイッチのロードバランシングについて，vSwitch1 は，vmk がそれぞれ異なるセグメントを持ち，それぞれ一つずつのvmnic を使用するようにしているため，ロードバランシングは必要ない．しかし，vSwitch0 については，vmnic0 とvmnic4 でチーミングを組んでいるため，ロードバランシングの設定が必要になる．今回は3つのロードバランシングが選択できるが，VMware 社も適切にロードバランシングされるといっている「IPハッシュに基づくルート」にすることにした．3つのロードバランシングそれぞれの説明は下記に示している．

図を描いてみると，IPハッシュに基づいたルートが適切にロードバランシングされるという説明にも納得できた．
※IPハッシュに基づくルートを利用するには，対抗スイッチのポートにLGA (リンクアグリゲーション)が設定されている必要がある

ストレージ

ストレージも設計項目が結構あった．

• VMFS のバージョン

今回作成する共有ストレージのVMFS のバージョンを5 か 6のどちらにするか．
VMFS 5 は既存の環境で使われていたが，VMFS 5から6への直接のバージョンアップはできないこと，また今回のストレージに直接アクセスするのが新しい基盤のみであるということを考慮し，VMFS 6 にした．

• 遅延ACK の無効化

遅延ACK はデフォルトで有効になっており，TCP/IP のACK 応答を意図的に遅らせることで，NW帯域を効率よく使用する設定であるという認識の設定だ．

デフォルトで有効になっているので，有効にしておくものかと最初考えたが，調べてみると遅延ACK は所々で悪さをしており，かつストレージベンダーからも「無効が推奨です」といわれたため，無効にすることにした．実際，遅延ACK が有効になっていると，下記図の通り送受信側で待機時間が発生してしまい，通信のリアルタイム性に影響が出る．

ストレージにアクセスして仮想マシンを動作させる仮想基盤との相性は最悪で，仮想マシンの動作が遅くなってしまうことが考えられる．

• login timeout 値の変更

ESXi のiSCSI イニシエータがストレージにログインする場合の，ログインに失敗したと判断する時間 (秒)の値の設定である．デフォルトは5秒に設定されているが，これだと短すぎてログイン試行の通信が大量発生するログインストームが発生し，NW帯域を圧迫してしまう懸念があったため，60秒に値を変更した．
※60秒が適切な値かどうかは未検証．検証したという経験などあれば教えてください

ちなみにVMware のソフトウェアiSCSI のiqn値は，事前にホスト名が設定されていれば，前半部分はホスト名が自動的に設定される．

• ポートバインドの設定
  ESXi では，vmk のIPアドレスのセグメントが同じ場合は，ポートバインドの設定を入れることが推奨されているが，今回はセグメントが異なるため，ポートバインドの設定をする必要はない．加えて，セグメントが異なる場合にポートバインドの設定を入れてしまうと，ストレージデバイスの再スキャンに時間がかかってしまうらしい．

そのため今回は，ポートバインドの設定をしなかった．

最後に，ストレージベンダーからマルチパスのラウンドロビンのiops値を1に変更するのが推奨であるといわれたため，以下の手順にてiops値を変更した．

1 naa id を確認する
まず初めに，iops 値を変更したいストレージのnaa id を確認する．確認する方法はいろいろあるが，ここでは以下の方法を実施した．

• ESXi のWeb UI にログインする
• 「ストレージ」>「データストア」>「【データストア名】」>「エクステント 0」を選択し，表示されたnaa id をメモ帳などにコピーする．

2 ESXi にssh でログインする
ESXi にteraterm などを用いてログインする．その後，現在のiops 値を確認する．

実行コマンド

# esxcli storage nmp device list

デフォルトであると，以下の結果が想定される．

実行結果例

...
Path Selection Policy: VMW_PSP_RR
Path Selection Policy Device Config:
{policy=iops,iops=1000,bytes=10485760,useANO=0;lastPathIndex=1:
NumIOsPending=0,numBytesPending=0}
Path Selection Policy Device Custom Config:
...

iops=1000 とiops値がデフォルトの値になっていることが確認できる．

3 iops 値を変更する

naa idに1で取得した値を指定して，以下のコマンドを実行しiops 値を変更する．

実行コマンド

# esxcli storage nmp psp roundrobin deviceconfig set --type=iops --iops=1 --device=【naa id】

再度iops 値を参照し，値が変更されているか確認する．

実行結果例

...
Path Selection Policy: VMW_PSP_RR
Path Selection Policy Device Config:
{policy=iops,iops=1,bytes=10485760,useANO=0;lastPathIndex=1:
NumIOsPending=0,numBytesPending=0}
Path Selection Policy Device Custom Config:
...

最終的にストレージ部分の設計図は下記の通りになった．

OMSA

最後に，OMSA によるハードウェアのSNMPトラップの通知を設定した．トラップのレベルや送信先は既存と同じであったため，特に困ることはなかった．
困ったこととしては，

• OMSA へのアクセスの仕方が分からなかった

Linux などにインストールするとhttpsのポート1311でアクセスできるのだが，ESXi においては1311ポートでは待ち受けていない．OpenManage Server Administrator Managed Node というソフトウェアをWindows OS にインストールし，そこからホストのIPアドレスとクレデンシャル情報を指定してアクセスする．その際，「証明書の警告を無視する」に✔をいれること．

• バージョンが合わなかった

既存のアラート監視サーバーにインストールされているOpenManage Server Administrator Managed Node のバージョンが古く，今回インストールされたOMSA が対応していなかった．対応バージョンをインストールしたサーバを新たに用意することで対処することにした．

おわりに

今回初めて一から仮想基盤の設計を，しかも既存基盤に結合させる形で設計→構築→単体試験→導入→結合試験→障害試験 までワンストップで実施したため，今まで知らなかった部分の知識をこうして得ることができた．
非常に良い経験だったので，今後も自分の未経験の領域にどんどんチャレンジしていきたい．

自分の家の環境もvCenter Server やiSCSI までは費用が掛かるので多分やらないが，仮想基盤は構築するつもりなので，どんどん仕事とプライベートの間でチャレンジした結果のアウトプットをしていきたい．