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ではタブ名や配置が異なりますのでこの点はご留意の上操作ください。
vSphere Replication まとめ(2017/08/09時点)
vSphere Replicationに関する情報ソースまとめと簡単なFAQ集です。
本記事では、VMware社公式なソース、私の検証に基づく情報が掲載されます。
公式ソースの情報更新や製品のバージョンアップなどによる仕様、動作変更なども将来的にありえるため、タイムリーなキャッチアップが出来ていない場合も想定されます。
この点はご容赦の上、本記事をお読み頂けますと幸いです。
公式ドキュメント、ソース集
VMware vSphere Replicationのドキュメント
便利なリンク集
vSphere Replicationの基本的な動作や設定、レプリケーションの基本的な考え方を学べるリンク
RPOやRTOなど、レプリケーションの基本も学べます。
vSphereがネイティブに提供するデータ保護ソリューションには、2種類があります。
vSphere Data ProtectionとvSphere Replicationです。その違いを、わかりやすく説明頂いているページです。
内容が難しすぎずシンプルなのでとても読みやすいです。
FAQ
- vSphere Replication自体はどのように導入するのか?
アプライアンスがVMware社より提供されているため、それを入手し既存のvSphere基盤上にデプロイをします。こちらがアプライアンスのダウンロードリンクです。
- 今までvSphere Replicationを利用していなかったが、興味がある。
導入には追加コストはかかるか?
お手持ちのライセンスが、vSphere Essential Plusであれば、導入に必要なライセンスを持っていることになります。Enterprise Plus、ではありません。Essential Plusです。 - vSphere Replicationにはバージョンがあるが、既存環境に対し適切なバージョン、導入ができるバージョンがわからない
VMware相互運用ガイドを確認すれば、一目瞭然です。
以下のように、vSphere ReplicationとvCenter Serverという名称をプロダクト名の入力箇所に入れます。
VMware Product Interoperability Matrices
そうすると次のような一覧が表示されます。
例えばvCenter Server 6.0.0のお客様はvSphere Replicationの6.1または6.0がサポートバージョンとなるわけです。
- レプリケーションと言えば、ディザスタリカバリーサイトなどの、別サイトに対する印象があるが、同一サイト内でのレプリケーションも可能か?
可能です。以下のドキュメントを参照ください。なお、レプリケーション元、先はいずれもクラスタであることが前提です。
https://docs.vmware.com/jp/vSphere-Replication/6.5/vsphere-replication-65-install.pdf
- ストレージ側のレプリケーションとどう違うのか?また利点は?
例えば次のような点が利点だと言えます。
1. ベンダー依存無しでのレプリケーションが可能(A社、B社間ストレージでレプリケーションを実現)
2. LUN単位ではなく、仮想マシン単位でのレプリケーションが出来るため、高粒度、容量効率が良いレプリケーションとなる
3. vSphere Web Clientなどを始め、vSphereネイティブなインターフェースで操作が一元化される
4. サポートが、VMwareサポート窓口となる。(OEMライセンスの場合はOEMベンダー内のVMwareサポートという意味合いも含みます)
ストレージ側の機能でレプリケーションを利用する場合は、サポート窓口がストレージベンダーになります。 - レプリケーションのスケジューリング時間設定は可能か?
現状は、RPO(Recovery Point Object)をベースにスケジュールはセットされる。
* RPO=データに問題が生じた場合に、どれくらい前のデータがあればよいかという意味です。
例えば、RPOを1時間とした場合は、1時間前のデータがレプリカとして保存されるよう定期的にデータが同期される形となる
レプリケーションの定期実行タイミングはvSphere Replicationによって内的に保持され、
RPOに基づいた継続的なレプリケーションが実行されます - 時間帯に対するレプリケーションの帯域幅調整機能はあるか?
一般的なハードウェアストレージには、上位機能などで午前や午後、曜日などの指定で、レプリケーションに利用する帯域幅を調整する機能がありますが、vSphere Replication自体が、ネイティブにこの機能は保持していません。
ESXiのインストール先の選び方
5分でわかるvSAN 6.6.1
しばらくぶりの更新となりました、お待たせしました皆様、お待ち頂きありがとうございます
現在早めの夏休みを頂いており、その間も出来るだけ情報を配信していきたいと思います
まずは、vSphere 6.5 update 1がリリースされましたが、それに伴いvSAN 6.6.1がそれに含まれる形でリリースされました😄
https://blogs.vmware.com/virtualblocks/2017/07/27/introducing-hci-powered-by-vsan-6-6-1/
まさかの6.6.1と3桁目突入でやや驚きました
肝心な内容については次の通りでした
- vSphere Update Managerを利用したvSANのバージョン管理が可能となる
- CEIP(カスタマーエクスペリエンス改善プログラム)に参加をしていれば、パフォーマンス診断機能を利用した場合に、その結果に対しVMwareからの情報を比較し、フィードバックを受けることができる
- 一部のパススルーモードのコントローラーにて、ドライブのロケーターLEDが利用可能となりました
以上です。今回は管理面での機能強化ですね。
また、1, 2についてはクラスターに対し、インターネット接続が必要となるそうです
<参考情報>
- VMware vSAN 6.6.1 Release Notes
- vSphere 6.5 U1 is out... and it comes with vSAN 6.6.1 - Yellow Bricks
EVCに関する基本設定と考察と検証
<著者からのお願い>
本記事の改訂版として以下のリンク内に更新記事を掲載しております。最新の情報をご確認頂くため、こちらのリンクをご覧ください。
なお、はてなブログ上の本記事については今後更新は行いませんので、ブックマークなどをされている読者様は、恐れ入りますが新ブログを改めてブックマーク頂くようお願い致します。
vSANクラスターの理想形、推奨とは?
本日はvSphere 6.5 ICMコースのDay4です。
昨日はvSANのレッスンで、少し話し過ぎて受講生の方と白熱してしまいました(笑)
さて、しばらくvSANネタは封印しようかなとも思いましたが、また質問が出ましたので備忘録として記載します
お題: vSANって、ノードの構成は揃えるべきなのか?VMwareからの視点ではどうなのか?
回答はこちら、vSAN 6.2 Design and Sizing Guideより抜粋
近いまたは同一な構成にするようにと記載がされています
これはvSANに限ったことではありませんね。
クラスターのコンセプトは、障害が起きてもファールオーバーにより、サービスの継続性を保持することにあります
例えばこんな構成のクラスターがあるとします
- ノード数は2, 仮想マシンが各ノード上で一台ずつ起動している
- 物理メモリは左側のホストは20GB, 右側のホストは10GB
- 仮想マシンのメモリ構成はいずれも10GBです
- スペースの兼ね合いで記載してませんが、共有ストレージに、2台の仮想マシンは保存されていて、両ホストからそれらはアクセス可能とします
- スマホで通勤中に書いたので、絵のクオリティはご容赦ください(笑)
この場合、ノードダウン時のシナリオは次のように異なります
- 右のノードがダウンした際は、その結果その上で動いていたVMは、左側のノード上で起動が出来ると言えます。理由としては左のノードが持つ物理メモリの搭載量が20GBであり、2台の仮想マシンを受け入れるリソースがあります
- 左のノードがダウンした際は、その結果その上で動いていたVMは、右側のホスト上で起動が出来ません。理由としては右のノードが持つ物理メモリの搭載量が10GBであり、2台の仮想マシンを受け入れるリソースがありません。
以上です。なお、今回のvSANのソースは6.2ですので、先々のバージョンアップでこれらの考え方は変化するかもしれませんので、最新の情報も是非皆様合わせてご確認ください。
と言うことで、今日は通勤の間だけでスマホ一つで0から書いて見ました。
今日もトレーニング頑張ります😄
Read more