Home > Blogs > Japan Cloud Infrastructure Blog > 作成者別アーカイブ: Kazuhiro Umetani

作成者別アーカイブ: Kazuhiro Umetani

VSAN Cormac Blog ~ VSAN 6.2 パート3 – ソフトウェアチェックサム ~

~ VSAN 6.2 パート3 – ソフトウェアチェックサム ~

本 blog は VMware Storage Business Unit の Cormac Hogan Blog の翻訳になります。 VSAN をより深く知っていただき活用していただく為、本記事の翻訳がお役に立てば幸いです。

次のVSAN 6.2に関する記事として、沢山のお客様がリクエストされていた重要な機能の一つである、”end-to-end software checksum”についてご紹介します。この機能は、基盤となる物理ストレージのメディア上で起こるエラーのために、整合性問題が発生することを回避することが出来ます。VSAN 6.2ではチェックサム機能がデフォルトで有効な設定になっています。また、VMストレージポリシーから、仮想マシン/オブジェクト単位で有効化、無効化することが可能です。お客様は常にこの素晴らしい新しい機能を活用したいと思われていると、我々は考えているので、チェックサム機能をデフォルトで有効にしています。ただし、アプリケーション側で同等の機能が実装されている場合は、この機能を無効化することがあります。

このチェックサム機能に関するポリシールールは、”Disable object checksum”と呼ばれています。以下に示す様に、VMストレージポリシーを作成する際に選択され、無効になります。それ以外の場合は常に有効になっております。

vsan_umetanisan01

 

VSAN上のチェックサムの概要について

VSAN上のチェックサムは、Intelプロセッサ上で特殊なCPU命令を利用して、最高のパフォーマンスを得る為に、とても一般的な巡回冗長性チェックCRC−32C(Castagnoli)を使用して実装されています。全ての4KBブロックは、それに関連付けられたチェックサムを持ちます。そのチェックサムは5バイトです。データが書かれた時にチェックサムは、万が一データがネットワーク通信中に任意の破損がある場合に、データを同じホスト上で検知することを保証します。チェックサムはデータで保持されます。

データの後続読み取りがされる過程で、もしチェックサムが有効な設定であれば、チェックサムデータもリクエストされます。もしたった今読まれたデータブロックが破損していることをチェックサムが検知した場合、RAID−1オブジェクトのケースにおいては、正しいデータを他のレプリカ/ミラーデータから読み込まれます。RAID−5, RAID−6のオブジェクトのケースでは、データブロックは、RAIDストライプの他のコンポーネントから再構成されます。エラーは、VMが稼働するホストだけでなく、コンポーネントがエラーを出力した機器を含んでいるホスト上のvmkernel.log ファイルにログされます。以下の例では、ランダムパターンのデータ上に、意図的にゼロデータを上書きして、ゲストOSからデータを読み込んでいます。

2016-02-16T07:31:44.082Z cpu0:33075)LSOM: RCDomCompletion:6706: \
Throttled: Checksum error detected on component \
a3fbc156-3573-4f2c-f257-0050560217f4 \
(computed CRC 0x6e4179d7 != saved CRC 0x0)

2016-02-16T07:31:44.086Z cpu0:33223)LSOM: LSOMScrubReadComplete:1958: \
Throttled: Checksum error detected on component \
a3fbc156-3573-4f2c-f257-0050560217f4, data offset 524288 \
(computed CRC 0x6e4179d7 != saved CRC 0x0)

2016-02-16T07:31:44.096Z cpu1:82528)WARNING: DOM: \
DOMScrubberAddCompErrorFixedVob:327: Virtual SAN detected and fixed a \
medium or checksum error for component \
a3fbc156-3573-4f2c-f257-0050560217f4 \
on disk group 521f5f1b-c59a-0fe2-bdc0-d1236798437c

スクラバーメカニズム

リード処理上でのチェックサム検証と並行して、VSANは、ディスク上のデータが如何なるサイレントコラプションも発生していないということをチェックする為のスクラバー機能を実装しています。このスクラバー機能は、年に一度全てのデータをチェックするように設計されています。しかしより頻繁に実行する為には、アドバンスドセッティングのVSAN.ObjectScrubsPerYear設定にて変更することが出来ます。もし全てのデータを毎週チェックしたい場合は、このパラメータを”52”に設定することで実現できます。しかしこの設定を行うことにより、いくつかのパフォーマンスのオーバーヘッドが発生することに気にしておく必要があります。

まとめ

チェックサムは、RAID−5/RAID−6, 重複排除、圧縮、ストレッチクラスタ構成といった、VSANの新しい機能すべてをフルサポートしています。上記の通り、それはデフォルトで有効設定になるので、お客様は設定を追加することなく、簡単にそのメリットを得られます。そして、もし何らかの理由により、チェックサム機能を利用したくない場合には、上記の通りVMストレージポリシーで簡単に無効化することが出来ます。この機能はVSANを利用するお客様に対して、一般的な物理ディスク障害による潜在的なセクターエラーや、その他サイレントデータコラプションによるデータ破損を検出することが出来ます。

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

VSAN Cormac Blog 〜 管理クラスタを含んだVSANデータストアの復旧シナリオ〜

〜管理クラスタを含んだVSANデータストアの復旧シナリオ〜

こちらのポストでは、管理クラスタが含まれているVSANデータストアに障害が発生した際の復旧方法についてご紹介させて頂きます。

我々のLabにあるサーバの一台で興味深い事象が発生しました。4ノードのクラスタの1台のホストで、そのホスト上のストレージがVSANデータストアとして利用出来なくなるというトラブルです。VSANには自動復旧させる機能が実装されているので、障害が発生した際には可能な限り多くのVMを再保護しようとします。しかしVSANデータストアの容量が限界になった時に発報されるWarningを無視したことによって、VSANデータストアを失う羽目になりました。このVSAN環境は私たちの管理クラスタとしての機能も含まれていて、vCenter Server、DNS/AD及び、VDPやView等の他のアプリケーションも配置されています。

こちらがその際に出力されたWarningです。
注:ホスト障害を対処する為に十分な容量がないことを示しています – 全てのVMを再保護する為には、120%の利用可能なストレージ容量が必要。(今後、この警告を無視してはいけない)

limits-failure

掻い摘んでお話しますと、容量を増やして当初のVSANの問題は解消され、次に仮想マシンを起動させる必要がありました。vCenterサーバやDNS/ADサーバなどの仮想マシンのvmware.logを調査することによって、仮想ディスクが容量不足になっていることを確認できました。もちろん、その仮想マシンがディスクを使い果たした時にはサスペンドされますが、これはデータストア上の仮想マシンの通常の動きであり、VSANに限ったお話ではありません。

2016-04-17T09:50:05.280Z| vmx| I120: Msg_Question:
2016-04-17T09:50:05.280Z| vmx| I120: [msg.hbacommon.outofspace] There is no \
more space for virtual disk mgmt-vc01.rainpole.com_6.vmd
2016-04-17T09:50:05.280Z| vmx| I120: ----------------------------------------
2016-04-17T09:50:25.278Z| vcpu-0| I120: Tools: Tools heartbeat timeout.
2016-04-17T09:54:05.650Z| vmx| I120: Timing out dialog 1510834
2016-04-17T09:54:05.651Z| vmx| I120: Vigor_MessageRevoke: message \
'msg.hbacommon.outofspace' (seq 1510834) is revoked
2016-04-17T09:54:05.651Z| vmx| I120: MsgQuestion: msg.hbacommon.outofspace reply=0
2016-04-17T09:54:05.687Z| vmx| I120: Msg_Question:
2016-04-17T09:54:05.687Z| vmx| I120: [msg.hbacommon.outofspace] There is no \
more space for virtual disk mgmt-vc01.rainpole.com_6.vmd
2016-04-17T09:54:05.687Z| vmx| I120: ----------------------------------------
2016-04-17T09:58:06.664Z| vmx| I120: Timing out dialog 1510835

その時点でvCenterにアクセスすることが出来ませんでしたので、このメッセージに対してどのように対応すればいいのかを検討し、CLIコマンドである、”vim-cmd”コマンドを実行してみることにしました。AD/DNSサーバ(dc01.rainpole.com)から始めてみます。最初にVM idが必要になりますので、ESXi上に配置されているVM idを以下のコマンドで確認します。

[root@esxi-hp-01:~] vim-cmd /vmsvc/getallvms
Vmid            Name                                                 
15     vVNX                     [vsanDatastore] ...
16     vdp-01.rainpole.com      [vsanDatastore] ...
20     dc01.rainpole.com        [vsanDatastore] ...
22     appvolmgr.rainpole.com   [vsanDatastore] ...
24     HCIBench                 [vsanDatastore] ...

次に、以下のコマンドでVMにメッセージが表示されていないか確認します。

[root@esxi-hp-01:~] vim-cmd /vmsvc/message 20 
Virtual machine message 6034178:
There is no more space for virtual disk \
dc01-rainpole.com.vmdk. You might be able to continue this \
session by freeing disk space on the relevant volume, \
and clicking Retry. Click Cancel to terminate this session. 
   0. button.retry (Retry) [default]
   1. button.abort (Cancel)

次のコマンドで、出力されているメッセージを対処します。注:メッセージ id 6034178に対して、”0″(0. button.retry (Retry) [default])を実行。問題なく処理できたことが確認出来ます。

[root@esxi-hp-01:~] vim-cmd /vmsvc/message 20 6034178 0
[root@esxi-hp-01:~]

引続き、メッセージが残されているか確認してみます。もしメッセージが表示された場合は新しいメッセージidを使い、もう一度同じコマンドを実行する必要があります。注:必要に応じて何回か繰り返します

[root@esxi-hp-01:~] vim-cmd /vmsvc/message 20
Virtual machine message 6034179:
There is no more space for virtual disk \
dc01-rainpole.com.vmdk. You might be able to continue this \
session by freeing disk space on the relevant volume, and \
clicking Retry. Click Cancel to terminate this session. 
   0. button.retry (Retry) [default]
   1. button.abort (Cancel)
[root@esxi-hp-01:~] vim-cmd /vmsvc/message 20 6034179 0
[root@esxi-hp-01:~] vim-cmd /vmsvc/message 20 
Virtual machine message 6034180:
There is no more space for virtual disk \
dc01-rainpole.com.vmdk. You might be able to continue this \
session by freeing disk space on the relevant volume, and \
clicking Retry. Click Cancel to terminate this session. 
   0. button.retry (Retry) [default]
   1. button.abort (Cancel)
[root@esxi-hp-01:~] vim-cmd /vmsvc/message 20 6034180 0
[root@esxi-hp-01:~] vim-cmd /vmsvc/message 20 
No message.
[root@esxi-hp-01:~]

全てのメッセージに対処し、最終的にはメッセージが出力されなくなります(”No message.”)。次は同様の方法でvCenterサーバを起動させます。vCenterサーバが起動したら各種クライアントから接続し、未解決の問題に対応します。

 

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