アフィリエイト広告を利用しています

vSAN vmkernelの移行方法について考えてみる

自宅lab環境を10G化するに伴い、これまで1Gで運用していたvSAN環境を10G環境に移行する必要がありました。 ある程度のVMが存在しているvSAN Clusterのネットワーク環境を、1Gから10Gのuplinkに変更する事に伴い、どの様な作業が必要だったのか、どのような点を考慮しないといけなかったのか、書き残したいと思います。

自宅lab 10G化

これまで自宅環境は1Gのonboard NICでvSANを運用していました。10G Switch, 10G NIC導入に伴い、vSANのトラフィックを10Gに流すためにvSphere上でどのような構成にするか考えてみました。
※後日10G化に伴いvSANのパフォーマンスや機器についても紹介したいと思います。

vDS構成

当初、1Gの既存vDSと10G用の追加vDSとしてvDSを分けて構成を組んでいました。というのも1GのSwitchはtag vlanなどを喋らずに構成しており、10G Switch側ではvlan設定も想定していたのでvDSを分けて構成していました。

自宅NW構成

vSANトラフィックを10G環境で流すには、既存の1G vDSから10G vDSにvmkernelを移行する必要が発生します。

vSAN vmkernelの移行

vSAN vmkernelの移行は以下のブログが参考になります。
Migrating vSAN vmkernel ports to a new subnet | Blah, Cloud

(単一のvSAN vmkernelを別ポートグループに移行させる方法もありますが、従来の1G 構成のvmkernelがvSANとManagementのトラフィックをまとめていたので、これを機にvSANトラフィックとManagementを分離させるようにしました。)

vSANのvmkernelは複数存在することはサポートされます。ただし同じサブネットではなく、異なるサブネットである必要があります。上記のブログではdata accesibilityを維持させるために、 vSAN データを移行する手順になっていますが、自分の環境では

  • vSAN上で稼働しているVMは停止する事を許容
  • 出来る限り作業を早期に終えたいのでvSAN データは移行させない

と考えていたので、以下のような手順で実施しました。

  1. vSAN上のVMは全台パワーオフ
  2. vSAN Clusterのホストはすべてメンテナンスモードに変更
  3. vSAN用のvmkernelを1G vDSのvmkernelに加え、新たに10G vDSのportgroupで別サブネットのvSAN vmkernelを作成
  4. esxcli vsan cluster unicastagent list で追加した2つのvmkernelでホスト間で通信出来ている事を確認
  5. 既存の1G vDSのvSAN vmkernelを削除
  6. vSAN health Serviceで問題が出ていない事を確認
  7. vSAN Clusterのホストのメンテナンスモードを終了

ハマったポイントとしては10G Switch側のMTUが9000設定ではなかったのでvSAN health Serviceでエラーが出たこと。 以下のkbの通りvmkpingで疎通確認しましょう

という事で上記の手順を踏むことでvSAN Datastoreのデータに影響なく、vSAN vmkernelの移行が出来ました。

vSAN vmkernelの冗長化

冒頭記載した通り、vSAN vmkernelは1台のホスト内で別サブネットであれば複数存在していてもサポートされます。 仮に10G Switchのファームウェアアップデートなどで機器の再起動が発生する場合、vSAN vmkernelを冗長化する必要が発生します。このため冗長化する方法として複数のvSAN vmkernelを1G vDSと10G vDSにそれぞれ共存させておくのも1つの手かなと思いました。いわゆるvSAN air-gap構成です。

vSAN air-gap構成とは

vSANトラフィックを物理的かつ論理的に分離する構成。つまり物理NICだけではなく、vmkernel(論理)まで分離する今回の構成です。メリットデメリットについては以下のVMware Docsに記載されています。

ただUplinkが1G のvDSと10G Uplink vDSそれぞれにvSAN vmkernelが存在する場合、平常時は10G vDSにトラフィックが流れることを期待したいのですが、実際はどうなのか調べてみました。

上記tweetのリンクとvSAN による air gap ネットワーク構成の長所と短所の短所に記載の通り、vSANには複数のvmknicを区別するロードバランシングメカニズムがないので、air gap構成だと平常時に10G Uplinkを優先せず、1G UplinkにvSANトラフィックが流れてしまう可能性があるのでこの構成は選ばないことにしました。

一応1G Switch側でもtag vlanの設定は行えたので、最終的には以下のような構成となりました。

最終的な構成

vDSのUplinkポリシーで10GをActive, 1GをStandbyに設定して単一のvSAN vmkernel構成にしました。この構成であれば10G Switchのファームウェアアップデートなどでlink downした場合に、自動的にStandbyで設定している1GのUplinkに切り替えて通信を行う形になります。

まとめ

今回vSAN vmkernelの移行方法および、ネットワーク構成について考えてみました。こうしてみるとvSANのワークロードを走らせたままSwitch側のファームウェアアップデートを考えると10G Switchがもう一台あったほうがいいなとか、1G Switch tag vlan喋れて良かったなとか色々思うところがあります😅1G Switchでtag vlan対応必要かなぁ🤔と思いがちですが、今回の様に一時的な10G Switchのファームウェアアップデート時にトラフィックを逃がしたり、Wifiルーターなどtag vlanを喋らない機器との同時接続を考えると、ポート毎にtag vlan設定が出来るととても便利でした。

自分の利用用途では以下の機器がおススメです!

Share Comments こ>のエントリーをはてなブックマークに追加
comments powered by Disqus