仮想スイッチ"スイッチへの通知"について(2)
<著者からのお願い>
本記事の改訂版として以下のリンク内に更新記事を掲載しております。最新の情報をご確認頂くため、こちらのリンクをご覧ください。
なお、はてなブログ上の本記事については今後更新は行いませんので、ブックマークなどをされている読者様は、恐れ入りますが新ブログを改めてブックマーク頂くようお願い致します。
さて、前回こちらの記事で、”スイッチへの通知”という設定の意味合いとその動作について図解で説明を致しました。
設定値としてはYesとNoがありますが、基本的にはYesで使うことがほとんどです。
※本図はvSphere ネットワークのドキュメントより抜粋
リンクとしては、こちらのリンク上に同様の記載があります。
今回のテーマは、”スイッチへの通知”をNoにするユースケースは？というものですが、
既に答えは出ていますね。
ESXi上の仮想マシンにて、Microsoft NLBを利用するケースでは、その設定内容によっては、本項をNoにすることで正常な動作をさせることが出来ると記載があります。
Microsoft NLB がユニキャスト モードで適切に機能しない (2078469)
Microsoft NLBでは、ロードバランシング提供時に、仮想的なMACアドレスをNIC間で同一のものを利用する手法とそうでないものがあります。
それぞれのユースケースについては今回割愛しますが、ユニキャストモードの場合が上述しているとおり、複数のvNIC間で仮想MACアドレスをシェアします。
ここから、2つの図を用いて、”スイッチへの通知”が”No”の時と”Yes”の時を比べてみたいと思います。
Read morevExpert 2017を頂きました
大変光栄なことに、vExpert 2017を頂くことになりました😄
vExpert 2017 Second Half Announcement - VMTN Blog - VMware Blogs
これでようやくVMware製品のエバンジェリストを名乗れるようになったかな？と言う感じです。
この半年は本当にvSphereとvSANのテクニカルトレーニングだけにフォーカスして来ましたので、こうした貴重な機会をセット頂いた皆様には感謝をしております
今後ともこれを継続し、2年3年とは言わず行けるところまでvExpertを名乗れるように尽力していこうと思います
このブログはまだ初めて半年程ですが、既にDailyで50-100名ほどがコンスタントに閲覧頂いております
今後はより多くの方の仮想化ライフに役立つ情報、かつ新たな気づきになるブログを目指して今後も投稿をしていきますのでどうぞよろしくお願い致します
vSphere HAとvSphere FTの違い(vSphere HA編)
vSphere環境における仮想マシンの保護の手法として、vSphereがネイティブに提供する機能としては、次の2つが有名です。
- vSphere HA(High Availability)
- vSphere FT(Fault Tolerance)
いずれもドキュメントから抜粋をしてみました。
公式な情報ソースとしては、次のPDFガイドが細かな内容が書かれていて大変便利です。
https://docs.vmware.com/jp/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-65-availability-guide.pdf
具体的な面での違いをもう少し知りたいという方も多くおられると思いますので、様々な点でこれについて比較をしてみたいと思います。
Read more仮想マシンと仮想ポートの関係性
今回も仮想スイッチのちょっとだけ深い話
仮想マシンと仮想スイッチの関係性についての記事です。
まず次の図は、ESXi上にデプロイされた仮想マシンと、そのネットワーク接続についての図です。
単一の仮想マシンが、1つの仮想NICを持っており、既存の仮想スイッチに接続された図です。
通常であれば、"仮想マシンポートグループ"に対し、仮想NICは関連付けられますが、今回はあえてそれを記述しておりません。
今回のテーマは・・・
”仮想マシンは、仮想スイッチとどのように接続されているか”です。
今回の記事の発端は、チーミングポリシーの”発信元の仮想ポートIDに基づいたルート”というルールの解釈をわかりやすくしたいというのが目的です。
まず、vSphere ESXiの環境に於いて、NICの負荷分散ポリシーは全5種類存在します。
その中で、既定値として”発信元の仮想ポートIDに基づいたルール”と言うものが設定されていますが、その内容についての詳細は、以下のようにマニュアルに記述があります。
ここで言う、仮想ポートと言うのは、上図で言う"Virtual Port"です。
実際には存在しないスイッチ、つまり仮想スイッチには1つ1つポートが定義されており、そのポートとと言うのはこちらのキャプチャの赤枠にあるように、次の条件で、仮想NICとの関連付けが解除されます。
つまり、仮想NICは上記の3つの操作を実行された場合に於いては、通信に使う物理NICを変更すると言えます。逆に言えば上記のイベント以外では物理NICを変更しないといえます。
もちろん、物理NICの障害に伴うフェールオーバーも、仮想NICが利用する物理NICの変更トリガーの1つと言えます。
以上です。今回の内容のソースは、以下のリンクからも確認が出来ますのでもし興味がある方は是非こちらのドキュメントをご覧ください。
仮想スイッチ"スイッチへの通知"について(1)
<著者からのお願い>
本記事の改訂版として以下のリンク内に更新記事を掲載しております。最新の情報をご確認頂くため、こちらのリンクをご覧ください。
なお、はてなブログ上の本記事については今後更新は行いませんので、ブックマークなどをされている読者様は、恐れ入りますが新ブログを改めてブックマーク頂くようお願い致します。
今回は自分のための備忘録です。
仮想スイッチのセッティング内で、”スイッチへの通知”という設定項目があります。
既定値はYesです。
スイッチの設定と言えば、チーミングポリシーやアクティブ、スタンバイvmnicの指定などの方がメジャーであり、あまり普段注目をされることがない設定項目です。
この設定って何？そもそもスイッチへの通知とはどういうことか？
今回はそんな内容に迫ります。
まず次のような環境を用意しました。
・2台のホストがいます(vmkernel 01, vmkernel 02というホスト名)
・2台の間でvMotionが出来る状況だとします。
・この後、VMという仮想マシンが、vmkernel 02側にvMotionされます。
この場合、”スイッチへの通知”により、vMotion後に移動先ホストがRARPプロトコルを利用し、接続スイッチに対し、vNICのアドレスに関するMACアドレステーブル更新を促します。
例えば次のようなケースで、RARPによるMACアドレステーブルの変更が発生します。
- vMotionによる仮想マシンの移動
- vmnicのフェールオーバーによる切り替え
いずれも、仮想マシンが利用するvmnicが変更されるケースだと言えます。
これらの話を総括すると、”じゃあいつこの設定をNoにするのか？”という疑問が生まれます。
この点についてはまた別記事にて取り扱いたいと思います。特殊な環境でない限り、基本的にはYesから変更することは無いと考えていただいて良いと言えます。
■2017/08/15追記
ちなみに、以下の情報は物理スイッチのMACアドレステーブルを実際にコマンド出力してみた様子です。
ご覧頂きますと、単一のポート"gi1/0/46"に対し、vmnic(物理NIC)1つ分と、5つのvNICのMACアドレスがMACアドレステーブルに学習されていることが確認出来ます。
※本検証にお付き合い頂いたKさん、ありがとうございました。
■2017/08/18追記
Part 2も投稿済みです。是非合わせてご覧ください！
VMware vSAN まとめ(2017/08/11更新)
<vSAN ドキュメント>
- VMware® Virtual SAN Diagnostics and Troubleshooting Reference Manual
- VMware® Ruby vSphere Console Command Reference for Virtual SAN
- VMware® vSAN™ Design and Sizing Guide
- VMware® vSAN™ Network Design
- vSAN Stretched Cluster & 2 Node Guide
- vSAN Stretched Cluster Bandwidth Sizing
- iSCSI Target Usage Guide
- Update Guide for Dell PERC9 H730 Controller
<Ruby vSphere Console>
- vsan.cluster_info
- vsan.host_info
- vsan.vm_object_info
- vsan.disks_info
- vsan.disks_stats
- vsan.check_limits
- vsan.check_state
- vsan.lldpnetmap
- vsan.obj_status_report
- vsan.resync_dashboard
- vsan.disk_object_info
<検証レポート>
- vSphereインターフェース上からのディスクの物理ロケーションIDを考える(1) パススルーモード編
- vSphereインターフェース上からのディスクの物理ロケーションIDを考える(2) RAID 0モード編
- vSAN環境に於いて、ドライブ交換時はメンテナンスモードを利用する必要があるか？
- 巨大なVMDKをvSAN環境上でデプロイする場合
- vSANのストレージポリシー：Flash Read Cache Reservationを考える
- vSANのパフォーマンス統計データはどのように保存されるか
- ディスク要求モードの変更について
- vSAN クラスターの破壊手順
- vSANでの障害処理(vSphere HAとの連携とコンポーネント総数50%未満でのVMの動作状況について)
<投稿記事>
vSAN クラスターの破壊手順
今回は今週のトレーニングで要望があった内容から一つ記事を書いてみました。
vSANクラスターを構成する手順については記載は多くあるものの、それを完全に削除する手順については情報が少ないというご相談でした。
vSANの導入意欲が高いお客様も大変多く、購買前の実環境での動作検証を行った後、環境をリセットして返却をする際にその方法がわからずに困っているというケースがあるようです。
ですので、今回はそうしたユーザーの方向けに記事をご用意してみました。
まず、手順としては次のような流れです。
基本的にこの流れになると言えます。
もちろん、場合によってはクラスターノード上の仮想マシンを停止したり、ホストの停止も含める場合は各ホストのメンテナンスモード化も必要です
1. vSANデータストア上にあるデータを退避する
こちらについては具体的には次の通りです
もし、vSANデータストアから別データストアへ仮想マシンを動かす場合は、上のパターンとなります。
もし、検証などの目的で一時的に作成したvSANであり、内部データが削除されて良い場合は、下のパターンとなります。
こちらの図はvSANデータストア上にデータが何もない状況を示しています。
vSANデータストアをナビゲーターペインで選択し、”関連するオブジェクト”にて、仮想マシンを選択しており、何も表示されていません。
2. vSANクラスターノードのディスクグループを削除する
こちらについては具体的な操作としては、vSANクラスターをクリックし、"ディスクの管理"から"ディスクグループ"を削除します。
この作業により、vSANデータストアから、ストレージデバイスが開放されます。
以降は、それらのデバイスでRAIDを組んだり、単一のVMFSとして再フォーマットして利用が出来るようになるわけです。
似たような画面としては、各ホスト単位でのストレージデバイスの管理画面からも、認識しているストレージデバイスを取り外すアクションはあります。
vSANに組み込まれているドライブ(ディスクグループ参加済みのドライブ)に対しこれを行うと上記のようにエラーが発生してしまい、オペレーションは失敗します。
また、上図のパーティション情報を拡大して見てみますと、vSANの情報を保持したディスクであることが分かります。
ちなみにVirstoとは、VMware社が買収をしたVirsto社の名前ですね。
vSANは元々Virsto社のテクノロジーがベースになっているのでその名残ですね。
ディスクグループ削除後は、先程までvSANデータストアの一部であったドライブも、
vSANのファイルシステムに関連する情報が削除され、空っぽの状態になります。
ランタイム名で見て頂ければ、上記の写真にあった同一のドライブであることが分かりますね。
試しに、ディスクグループの削除ではなく、”パーティションの削除”をディスクグループに参加しているドライブに実行してみたいと思います。
本当に消してしまうの？と質問されますが、ここはOKで進めてみます。
結論としては、NGでした。素直にディスクグループの削除が良いですね。
この後全ノードのディスクグループを削除し、vSANクラスター自体は存在するものの、ディスクキャパシティが0GBという状態になったことを確認します。
これにより、vSANクラスターに参加しているドライブが存在しないことが確認出来ました。
3.vSANクラスターの機能の無効化をする
さて、後はvSANクラスターの機能を無効化します。
クラスターのセッティング画面にて、vSANの機能のチェックを外します。
vSANのデータストアにアクセスができなくなります、と警告が出ます。
今回はクラスターの破壊なので、気にせずOKで行きます。もちろん本番環境ではチェックを外す事は大変危険です。
vSANの機能がOFFになりました。
後は、vSANのディスクIO用のvmkernelポートも削除してしまっても良いでしょう。vSAN用のvmkernelポートは、以下のようにVirtua SANと書かれた項目で、Enabledになっているかどうかで確認しましょう。
削除は、該当のvmkernelポートを選択し、上図の赤バツボタンをクリックします。
以上となります。あとは、このままクラスター自体を停止する場合は、全ホストをメンテナンスモードにし、シャットダウンで完了となります。
なお、今回の環境は、vSAN 6.2にて操作を行い画面キャプチャを行いました。
vSphere Web Clientのインターフェースは、vCenter Server 6.5ではタブ名や配置が異なりますのでこの点はご留意の上操作ください。
