Home > Blogs > Japan Cloud Infrastructure Blog > 月別アーカイブ: 2016年6月

月別アーカイブ: 2016年6月

VSAN 6.2 監視ホスト(Witness)の再配置

VSAN 6.2 監視ホスト(Witness)の再配置

この操作は、VSANストレッチクラスタ環境/2ノードVSAN環境で監視ホストを変更する際に行います。具体的には、VSANストレッチクラスタ環境/2ノードVSAN環境を、VSAN 6.1からVSAN 6.2 にアップグレードする際に必要な手順となります。1点気を付けなければいけないのは、クラスタ内のディスクグループとして、オンディスクフォーマットと同一バージョンの監視ホストを使用しなければいけないことです。タスクを要約すると以下のようになります。

1.新しい監視ホストの展開
2.VSANストレッチクラスタ/2ノードVSAN環境を管理しているvCenterに登録されているESXiホストに監視ホストを追加
3.現在のVSANストレッチクラスタ、2ノードVSANを無効化
4.同じ2台のホスト(優先フォールトドメイン、セカンダリフォールトドメイン)、および新しい監視ホストを選択しストレッチクラスタ/2ノードVSAN環境の再構成
5.健全性画面からデータを選択し、オブジェクトをただちに修復するをクリック(そうしないと、新しい監視ホストによるリビルド処理が実行されるまで、60分(デフォルト値)待たなければいけなくなる。)

以下はより詳細なステップです。

・新しい監視ホストの展開

VSANストレッチクラスタ環境では、L3を超えて監視ホストとVSANを構成する物理ホストが通信する必要があり、そのために監視ホストと物理ホスト間の通信のために静的ルートを追加する必要があります。この手順はVSANストレッチクラスタガイドで記載されています。

・VSANを管理しているvCenterに監視ホストを新たに追加

インベントリ内に2台の監視ホストを確認できます。(オリジナルと新しいもの)
.19の監視ホストが新しく展開されたもので、.26が置き換えられる現在のものです。

・既存構成を無効化

監視ホストを削除するために、Cluster>Manage>Virtual SAN>Fault Domain and Stretched Cluster(日本語UIでは、クラスタ>管理>Virtual SAN>フォールトドメインおよび拡張クラスタ)を選択します。
現在の監視ホストである.26を選択します。右側のウインドにあるDisableボタンをクリックします。その後、
Yesをクリックすることで監視ホストを削除することができます。

disable-stretched-cluster

ここでのポイントは、一旦監視ホストを削除すると、全ての監視ホストコンポーネントがAbsent状態となり、何らかのオブジェクトに対するクエリ、もしくは健全性チェックが実行されると、それらの操作は失敗します。

witness-health-issues

・新しい監視ホストの再構成

新しい監視ホストを選択して、ストレッチクラスタ/2ノードVSAN構成の再構成を行います。最初のステップはフォールトドメインの再構成です。元のフォールトドメイン構成が確認可能であるため、単にセカンダリという名前で作成されているフォールトドメインを、セカンダリフォールトドメインに移動すれば良いだけの簡単な手順です。

3.-reconfigure-DFs

次に、新しい監視ホストを選択します。ここでは.26ではなく、新たに展開した.19の監視ホストを選択します。残りのステップでは、ディスクグループを作成するなど、最初に監視ホストの設定を行うのと同じ作業を行います。

4.-new-witness

・オブジェクトをただちに修復

構成が完了した後は、健全性のテストを行います。デフォルトでは60分後にオブジェクトは自動的に修復されますが、その間はリスクが高い状態である(他の問題が発生すると、VMにアクセスできなくなる可能性がある)ため、オブジェクトをただちに修復を行うことをお勧めします。これによりAbsent状態の監視ホストの修復を迅速に行うことができます。再度テストを実行すると、可用性が低くなっているオブジェクトの数は減少し、健全なオブジェクトは増加します。

5.-repair-objects-immediately

全てのオブジェクトが健全な状態となったら、監視ホストの置き換えプロセスは完了です。

原文:Replacing the witness appliance
VMware Storage and Availability Business Unitの シニアスタッフエンジニアCormac Horganの個人ブログを翻訳したものになります。VSANの詳細に関しては弊社マニュアル 、KBをご確認ください。また本記事は VSAN 5.5ベースに記載しております。予めご了承ください

VSANにおける SSDの役割

本blogは VMware Storage Business UnitのCormac Hogan Blog の翻訳になります。VSANをより深く知っていただき活用していただく為、本記事の翻訳がお役に立てば幸いです。
最新のVSAN 6.2では「ハイブリッド」と「オールフラッシュ」2つの方式のがありますが、本記事はハイブリッド方式の記事となります。

★SSDにおける役割

VSAN 内における SSD は、リードキャッシュとライトバッファとして作用します。これは VSAN データストア上で実行される仮想マシンのパフォーマンスが向上させます。

VSAN はストレージ市場における SSD と HDD を備えた”ハイブリッド”ストレージと比較されますが、パフォーマンス向上だけでなく、キャパシティのスケールアウトも特徴として兼ね備えています。それでは VSANにおけるリードキャッシュとライトバッファについて話を進めていきましょう。

★リードキャッシュ★

リードキャッシュは、頻繁にアクセスするディスクブロックのリストを保持します。これは、キャッシュヒット時に、I/Oリード遅延を削減することができます。

VSAN において興味深いのは、アプリケーションが読み取られている実際のブロックが、仮想マシンが実行されているESXiホストにないかもしれない、ということです。

言いかえると、仮想マシン自体はあるESXiホスト上で動いておりますが、その仮想マシンのストレージオブジェクトは、それとは異なるESXiホスト上にあってもよい、ということです。

ストレージオブジェクトが異なる ESXi 上に分散している際、該当するブロックが VSAN クラスタ内の別 ESXi ホストのリードキャッシュにあるかどうか探します。キャッシュミスがある場合、データは HDD から直接取り出されます。

VSAN はリードキャッシュがヒットしやすいように常に同じレプリカを読み取るようにします。つまり、クラスタ内どこか1つのノードでキャッシュされます。キャッシュスペースは比較的高価ですので、このメカニズムがキャッシュ利用効率を最適化してます。

★ライトバッファリング★

ライトキャッシュは、不揮発性ライトバッファとして動作します。アプリケーションからの書き込みは、SSDに書き込まれた際 ACKを返します。 もちろんこの動きは書き込み時の遅延予防となります。

SSDに書き込むので、 ハード障害時に備えて VSAN クラスタ内のどこかにデータコピーがある必要があります。

ポリシーによって、VSANに展開される仮想マシンはコピーを持たせることができます。これは、ライトキャッシュコンテンツも含みます。

アプリケーションによって書き込みが開始されると、”オーナー”であるホストのライトキャッシュに書き込むのと同時に、レプリカのあるリモートホストのライト キャッシュにも書き込まれます。

書き込まれたキャッシュデータは、他のホストでもコピーを保持しているので、ホスト障害が起きた際も安心です。その後、SSDに書き込まれたキャッシュデータは、一定の間隔で、HDDにデステージされます。

他のフラッシュソリューションと同様、VSANは可能な限り最高のパフォーマンスを提供します。

原文:The role of the SSD
VMware Storage and Availability Business Unitの シニアスタッフエンジニアCormac Horganの個人ブログを翻訳したものになります。VSANの詳細に関しては弊社マニュアル 、KBをご確認ください。また本記事は VSAN 5.5ベースに記載しております。予めご了承ください

VSAN Cormac Blog 〜 障害が発生したディスクのコンポーネントのメタデータ健全性 〜

〜 障害が発生したディスクのコンポーネントのメタデータ健全性 〜

最近、VSANの健全性チェックでコンポーネントのメタデータ健全性障害が発生するケースがあります。
以下のようなメッセージが表示される現象です。

component-metadata-health

最初に確認すべきことは、KB2108690に記載されている以下の内容です。

ノート:この健全性チェックテストは、デステージングのプロセスが遅い(多くの場合はVSANがストレージデバイス上に物理ブロック割り当てを行う必要があるような高負荷状態)場合に、この事象が断続的に発生することがあります。この事象に対するワークアラウンドは、ディスク負荷が高くなるようなアクティビティ(複数の仮想マシンを展開する等)が完了した後に、再度健全性チェックを実行することです。

もし健全性チェックで再度障害が表示されるようであれば、表示される情報は正しく物理ディスクに何らかの問題があるのかもしれません。もし健全性チェックが成功するようであれば、上記アクティビティが原因で発生していた事象でありメッセージは無視しても問題ないでしょう。

それを念頭おいて、どの物理ディスクが潜在的な問題を抱えているのかを確認していきましょう。
上記の障害では、コンポーネントのUUIDを表示していますが、顧客がUUIDと物理ディスクを引き合わせるのは非常に困難です。
現時点で、この確認をするにはRVC(Ruby vSphere Console)を利用する必要があります。では、障害として表示されたコンポーネントのUUIDが、どの物理ディスクに対応しているのかを確認する方法を見ていきましょう。

最初に、健全性チェックで障害と表示されたコンポーネントのUUIDを引数に指定してvsan.cmmds_findコマンドを実行します。いくつかの先行して表示されるカラムは見やすくするために削除して表示しています。コマンドは、クラスタオブジェクト(0を指定)に対して実行しています。

vsan.cmmds_find-1

ここでディスクUUIDを確認できたので、それを次に実行するコマンドの引数として使用します。
ここでもいくつかのカラムを見やすくするために削除して表示しています。

vsan.cmmds_find-2

上記出力結果のdevNameフィールドで、該当物理ディスクのNAA ID(SCSI ID)を確認できました。
健全性チェックテストで問題が発生した際に、上記手順を参考にして物理ディスクの特定を行って下さい。

※現在、この情報をKBとして掲載するためのリクエストを行っています。

原文:Component Metadata Health – Locating Problematic Disk
VMware Storage and Availability Business Unitの シニアスタッフエンジニアCormac Horganの個人ブログを翻訳したものになります。VSANの詳細に関しては弊社マニュアル 、KBをご確認ください。また本記事は VSAN 6.2ベースに記載しております。予めご了承ください。