VMware Global Community
nitta0814
Enthusiast
Enthusiast

vSAN4台環境でのEVCクラスタ有効化について

vSAN4台環境でのEVCクラスタ有効化についてご教示頂けると幸いです。

ESXi6.7U2 4台でvSANクラスタを構築しております。

本環境は、移行前のため仮想マシンは「vCSA6.7U2」が1台のみ存在します。

EVCクラスタを有効化するためには、仮想マシンを全て停止する必要があると思います。

しかし、「vCSA6.7U2」を停止するとEVCクラスタを有効化する手段が無くなってしまいます。

何か良い方法をご存知の方がいらっしゃいましたら、アドバイス頂けないでしょうか。

※環境はvDSとなります。

宜しくお願いいたします。

Reply
0 Kudos
8 Replies
nkaneda
Enthusiast
Enthusiast

こちらのKBは確認済みでしょうか。

How to enable EVC if vCenter Server Virtual Machine is part of the same cluster (1013111)

https://kb.vmware.com/s/article/1013111https://kb.vmware.com/s/article/1013111 

Reply
0 Kudos
kawaman
Leadership
Leadership

前提を伺いたいのですが、

今回の新規 vSAN クラスタの EVC モードを現在のホスト CPU のバージョンより「下げたい」のが今回の要望でしょうか?

「下げたい」のではなく、今後の追加ホストで新しい CPU バージョンのホストを追加するために、「現在のホストの CPU バージョンで EVC を有効化する」場合はそのまま有効化できます。

「下げたい」場合は、現行の別環境から Cross vCenter vMotion でクラスタ間で仮想マシンのライブマイグレーションでの移行を行いたいなどの背景がありますか?

その場合、nkaneda さんが挙げられた様な KB に沿って絡め手の設定を入れる必要がありますが、

もし、既存環境に vCenter をデプロイできるのであれば、既存環境上の vCenter (または既存環境上に新規にvCSAをデプロイして)から新規 vSAN クラスタを EVC モード下げて構成し(既存と合わせる)、

vCenter 自身を Cross vCenter vMotion で移行するという事も可能かもしれません(すみません、ここまで試したことはないので既存情報からの想定です)

ちなみに、nkaneda さんが参照先として挙げられた KB ですが、現行バージョン用は以下で別 KB が用意されておりますため、念のため

How to enable EVC in vCenter Server 6.5 or 6.7 if vCenter Server Virtual Machine is part of the same...

KB 上では vDS 環境では非推奨で vSS を別途作成とありますが、以前試した時は vDS 上で短期バインドのポートグループで管理ネットワークを用意しておき移行できました。

ただ、この手順は vSAN を前提としていないので、試す場合は失敗時は再構築含めて必要になるかもしれませんのでご注意を。

Reply
0 Kudos
nitta0814
Enthusiast
Enthusiast

皆様 ご回答頂きありがとうございます。

私の記載した質問内容の記載が悪く、

現時点での直面の問題を記載出来ておりませんでした。申し訳ございません。

また、今回の背景としては、vCenter間の移行を無停止で行うため、

既存のCPUレベルに合わせたEVCクラスタの作成が必要なっております。

旧環境に新vCSAに作成するのは私も良いと考えているため、並行して検討したいと思います。

現在の状況を以下に記載いたします。

1.新ESXi#1をメンテナンスモードにし、vSANクラスタから何もないクラスタに移動

2.新vCSAを停止

3.新vCSA(元:停止中)のVMデータをvSANストレージからダウンロード

4.新vCSA(元:停止中)のVMデータを新ESXi#1のローカルディスクにアップロード

5.新ESX#1のvSphere Host Clientから手順4でアップロードしたVMデータをインベントリに登録

6.新vCSA(再登録:起動)を起動させる。

※この時点で起動後、新vCSA(再登録:起動)は自分のIPにはICMPで通信可能ですが、

 同じポートグループに存在する新ESXi#1のvmk0とゲートウェイ(仮想基盤用NW機器)に疎通出来ません。

 また、他の新ESXi#2~4にも疎通できません。

上記により、vSphere Clientにアクセス出来ず、続きの手順が実施出来なくなりました。

現在は、新vCSA(元:停止中)を再度起動させ、原因究明を行っている最中となります。

私の認識では、vCSAの管理ネットワークをvDSを使用していた場合でも、

ホストがvCSAの管理下にある限りvDSが機能するものだと考えております。

そのため、そもそもの新環境のネットワーク構成のどこかに原因があるのではと思っております。

宜しくお願いいたします。

Reply
0 Kudos
gowatana
Leadership
Leadership

こんにちは。

vSSの標準ポートグループとは異なり、vDSの分散ポートグループでは、分散ポートが作成されます。

おそらくvCSAのインベントリ削除→追加によって分散ポートへの接続がリセットされ、

vCenter起動前のため新しい分散ポートに接続できない状態だと考えられます。

そこで、kawaman さんの返信にもある「短期バインドのポートグループ」を作成してvCSAを接続すると、

インベントリ再登録後のvCSAがネットワーク接続できるようになると思います。

「短期バインドのポートグループ」とは、下記ドキュメントでの「短期 - バインドなし」ポートグループです。

分散ポート グループの追加 

以上です。ご参考まで。

Reply
0 Kudos
nitta0814
Enthusiast
Enthusiast

gowatana

いつもご回答頂きありがとうございます。

私の知識不足で「短期バインドのポートグループ」について存じておりませんでした。

原因切り分けとして実施してみたいと思います。

「短期バインドのポートグループ」とは、vDS内の分散ポートグループですが

vSSのポートグループような動作をするような理解でよろしいでしょうか。

また、今回は「新vCSA(元:停止中)」をインベントリから削除せずに

新vCSA(再登録:起動)をインベントリ登録と起動を実施しておりますが、

新vCSA(元:停止中)」をちゃんとインベントリから削除した方がよろしいでしょうか。

宜しくお願いいたします。

Reply
0 Kudos
gowatana
Leadership
Leadership

こんにちは。

「短期バインドのポートグループ」は、一般的なvSSのポートグループと同様に使用できます。

また、「新vCSA(元:停止中)」は、ちゃんとインベントリから削除した方が安全だと思います。

Reply
0 Kudos
nitta0814
Enthusiast
Enthusiast

ご回答頂きありがとうございます。

以下のことを実施した状況です。

7.新vCSA(元:起動中)が繋がっているvDS内に新規に「短期バインドのポートグループ」を作成しました。

 ※新vCSA(元:起動中)は起動し直しました。

8.新vCSA(元:起動中)に手順7で作成した短期バインドのポートグループ」を設定しました。

※この段階で新たな問題が発生しました。

 新vCSA(元:起動中)にpingが飛ばなくなり、vSphere Clientにもアクセス出来なくなりました。

 また、元の分散ポートグループに戻すため、vSphere Host Clientにログインし、

 仮想マシンの編集からネットワークラベルの変更を実施したところ以下のエラーが発生しました。

エラー:

非短期の分散仮想ポートグループ「元のNWラベルXXX」に接続されているネットワークアダプタの追加または再構成はサポートされておりません。

このような状況になってしまうとvCenterを復帰させる方法はもうないでしょうか。

宜しくお願いいたします。

Reply
0 Kudos
nkaneda
Enthusiast
Enthusiast

> 8.新vCSA(元:起動中)に手順7で作成した短期バインドのポートグループ」を設定しました。

名称が複雑なのできちんと理解できていないかもしれませんが、この作業の意図がよくわかりませんでした。

新vCSA(再登録:停止中)に、手順7で作成した短期バインドのポートグループ」を設定するべき手順だったと想定しています。

新vCSA(元:起動中) に短期バインドポートグループを設定したことで疎通が失われてしまったのは、ポートグループ設定に問題があったと思われますので(vlanやuplinkなど)、手順の問題とは少し別の要因になると思います。

しかしながら、少なくとも新vCSA(再登録:停止中)  だけに短期ポートグループを適用していればリカバリも容易でしたので、VCSAのポートグループなどを変更される際は、より安全な手順で実施されることをお勧めいたします。

(例:別途VMを作成し、そのVMに短期PGをアサインした後に、作業用端末からPingが通ることを確認したうえで、VCSAに設定するなど)

現在の状況が明確にはわかりませんが、Host Clientから分散PGを扱うことはできませんので、VSSを一時的に作成する必要があります。

VSSにはUplinkが必要ですので、VDSから一つUplinkを剥がしてVSSに割り当てる必要があります。

手順としては以下のブログが参考になるかと思います。

https://community.emc.com/community/support/japanese/blog/2018/07/04/vxrail-%E7%AE%A1%E7%90%86%E7%B3...

もしくは、以下のブログで紹介されているDell EMC KB#504380にあるような、既存のVMから作成済みの分散仮想スイッチポートを借用する方法も可能かもしれません。

https://community.emc.com/people/naoyukikaneda/blog/2018/09/29/vdp%E3%81%A7vcsa%E3%82%92%E3%83%AA%E3...

詳細は上記KBに譲りますが、概要は以下です。

  1. 対象の分散PGにポートを持つ、既存のVMをShutdownする
  2. 既存のVMのvmxファイルからdvs.portIdとdvs.connectedIdをメモする
  3. VCSA VMをShutdownする
  4. VCSAのvmxファイルを編集してdvs.portIdとdvs.connectedIdを既存のVMのものと書き換える
  5. VCSA VMを起動する
  6. 起動後VCSA VMを別のHostにvMotionする。vMotionすることでdvs.portId情報が更新されます。

私自身はラボでやらかしてVCSAと疎通が取れなくなったときの上記の方法で復旧できたことがありますが、お使いのVersionでも適用可能かはやってみないとわかりません。

Reply
0 Kudos