vSAN アーキテクチャ ー Cluster-Level Object Manager（CLOM）
vSAN アーキテクチャー編始めてみました。
vSANは実は複数のソフトウェアの集合体、と考えていただくことが可能です。
今回は、Cluster Level Object Manager (略称CLOM)の紹介です。
<役割と紹介>
- オブジェクトの取りまとめを担当している
（オブジェクトの作成時の配置やコンポーネントがストレージポリシーに準じてオブジェクトを保護しているかを確認する） - オブジェクトのリビルドの実行をスケジュールする
（障害発生時に空きのディスク容量を確認し、十分にそれがあることを確認し操作をスケジュールする） - オブジェクトは新しいポリシーが関連付けられた際に、新しいコンポーネント配置が必要であればそれをハンドルする
- ホスト上のCLOMデーモン間でコミュニケーションを行い、相互の空き状態を確認する
- CLOMはユーザースペースデーモンであり、各ホスト上で動作している
サービスステータスは、/etc/init.d/clomd <status/restart>で操作確認ができる
ログ情報は/var/log/clomdに表示される
名前の通り、クラスターレベルでオブジェクトがストレージポリシーのルール通り保護されているかを管理するのがCLOMの役割です。
例えば、仮想マシンを作成する際には、ポリシーに準拠した構成であるかを判定してくれます。(3ノードしか無いホストで、FTT=2を構成しようとするとエラーが出るのは、CLOMがこれを判断しているからである)
この際、各コンポーネントの初期配置も、CLOMが決めてくれます。
また、メンテナンスモードやリバランスなどに伴うデータの移行をスタートさせてくれるなどもCLOMの担当ですので、この点においても”ポリシーをいかにして忠実に守るか”、というCLOMらしい動きだと言えますね。
CLOMサービスは全てのESXiホスト上で動作をしており、相互通信をすることによってクラスター全体でワークロードも含めた均一化を図ることもまた、CLOMのミッションと言えます。(Nutanixで言う、Curatorみたいな役割のようにも見えます)
関連KBとしては、以下の情報からも、上記の内容が想像し易いと言えます。
vSAN 健全性サービス - クラスタの健全性 - CLOMD 稼動状態チェック (2148715)
また、ログとしても/var/log配下に"clomd.log"があります。
vSANが構成されたばかりのclomd.logを見てみますと、”esx-01a.corp.local”が"vmhba4:C0:T0:L0"のディスクを使い、ディスクグループを組んでいる様子が分かります（勿論、他のホスト、他のディスクも、この行の前後でこれに組み込まれていますね）
オブジェクトの配置場所を考える上で、ディスク配置の情報などを把握するためにこれらの情報を読み取っているように見えます。ログの解説もしたい所ですが、詳細情報をこれから集めますので、情報が集まり次第別回で紹介したいと思います。
vSAN アーキテクチャ ー Local-Log Structured Object Manager (LSOM)
vSAN アーキテクチャー編始めてみました。
vSANは実は複数のソフトウェアの集合体、と考えていただくことが可能です。
今回は、Local-Log Structured Object Manager (略称LSOM)の紹介です。
<役割と紹介>
- ディスクIOの制御及びローカルディスク内の整合性の保証を行う
- コンポーネントはLSOMレイヤーに存在する
- LSOMはDOMよりIOを受信するとWriteオペレーションが終わるとDOMにAckを返します
- LSOMはRead時のデータ提供やWriteバッファリング、Readキャッシュ化、キャッシュTierからキャパシティ Tierへのでステージも担当している
- LSOMは分散、クォーラムやIOの同期などは把握しておらず、単純にIOのみを担当している
- LSOMはカーネルスペースに存在している
- ログはvmkernel.logを使うことで動作を把握できる
LSOM自体が直接物理的なドライブにアクセスが出来るレイヤーにいるため、次のようにハードウェアの認識系の情報をLSOMがハンドルしているように見えます。
次のログはvSAN Diagnostics and Troubleshooting Reference Manualより抜粋しております。(Page 63)
例えば、ディスクを抜いてみた際には次のようなイベントが発生する
- vmkernel.log -
2014-09-30T09:44:55.312Z cpu20:32849)WARNING: ScsiPath: 7028: Path lost for adapter vmhba0 target 1 channel 0 pun 0
2014-09-30T09:44:55.312Z cpu22:33441)WARNING: LSOMCommon: IORETRY_NotifyAPD:1647: Got APD event 1 on 0x410c0285ca90
2014-09-30T09:44:55.312Z cpu20:32849)WARNING: ScsiDevice: 8820: PDL set on VSAN device path "vmhba0:C0:T1:L0" [...]
2014-09-30T09:44:59.317Z cpu22:33506)WARNING: LSOM: LSOMEventNotify:4581: VSAN device 527cfbf5-ae7a-33f6-78bc-beed2f1730dd has gone offline.
1行目ではvmhba0のtarget1のchannel0のpun0でパスのロスト発生を検出し、
2行目ではLSOMはこの症状をAPD(All Path down)として認識し
3行目ではLSOMはこの症状をPDL(Permanent Device Loss)として再評価している
4行目ではこれを受けて、デバイスがオフラインになったことを記載している
- vobd.log -
2014-09-30T09:44:59.317Z: [VsanCorrelator] 59865017530us: [vob.vsan.pdl.offline] VSAN device 527cfbf5-ae7a-33f6-78bc-beed2f1730dd has gone offline.
2014-09-30T09:44:59.317Z: [VsanCorrelator] 59867627549us:[esx.problem.vob.vsan.pdl.offline] VSAN device 527cfbf5-ae7a-33f6-78bc-beed2f1730dd has gone offline.
同時刻にディスクがオフラインになったことを示すイベントが出ています。
ちなみに、”527cfbf5-ae7a-33f6-78bc-beed2f1730dd”という値は、vSANに参加をしている物理ドライブのUUIDです。
またログ以外にもKBの内容からも、LSOMが物理ドライブのIOのリトライなどを制御しているように伺えます。
LSI 3108 チップセット ベースのコントローラに必要な vSAN および ESXi の構成 (2145639)
本KBでは、特定の条件のストレージコントローラーを利用してる場合は、LSOMが既定で持つタイムアウト値を修正するか、パッチ適用が必要ということが記載されています。
vSAN Observerでは、"VSAN Disks (deep-dive)"が、LSOMによってレポートされている情報です。
以上です。今後も追加情報があれば記載をしたいと思います。
vSphere HAとvSphere FTの違い(vSphere FT編)
過去の記事の続編記事です。特に今回はのような記事はvSphere入門者向けの記事だと言えます。
以下の記事と本記事をセットで読んで頂ければ、vSphereが提供する”冗長性のためのクラスター”についての基本的な理解が出来ます。
vSphereビギナーに多い疑問は”vSphere HAとvSphere FT”の違いがよくわからない、と言うものです。
- vSphere HAは、ホスト停止などにより仮想マシンが停止する場合は、別の正常なホスト上に仮想マシンを再起動によってサービス継続を維持します。
つまり、仮想マシンが再起動している間は、サービス提供が停止します。
この機能のコンセプトは”自動化されたフェイルオーバー”です。 - vSphere FTは、RAID1のように二重化された仮想マシンを保持し、片方がダウンした場合、シームレスにセカンダリ仮想マシンがサービス提供を継続します。
この機能のコンセプトは”自動化されたフェイルオーバー＋無停止フェイルオーバー”です。
つまり、フェイルオーバーにかかるダウンタイム時間の差が違いです。
これだけを見てみれば、"vSphere FT"の方がフェイルオーバーについては優秀です。
では、vSphere FTの特徴を前項のvSphere HAのように並べてみます。
vSphere FTの特徴
- 二重化された仮想マシンを保持しており、仮想マシンの停止に対し、シームレスなフェイルオーバーを提供する
- メリットは、無停止のフェイルオーバーのためサービス提供を起こさず自動化されたフェイルオーバーを提供する
- 仕組みとしてはRAID1のようなもので、2つの物理ホスト上に同じ仮想マシンを動作させ、片方をプライマリ仮想マシン、もう1台をセカンダリ仮想マシンと呼び、プライマリがセカンダリに同期データを常時送信している
- 保護出来る仮想マシンのサイズには、機能性質上制限がある
FTの構成に必要なものは次の通りです
- vCenter Serverは必要
- ESXiホスト(2～64台)
- vSphere HAが有効になっていること
- ESXiのライセンスはStandard以上
但し、ライセンスのエディションによりFTで保護出来る仮想マシンのvCPU数が決まります。StandardまたはEnterpriseの場合はvCPU2個、Enterprise Plusの場合はvCPU4個の仮想マシンをFTで保護可能です。 - FT保護される仮想マシンのメモリ容量：64GB(構成の上限より抜粋)
- HAクラスターノード間での通信用のvmkernel portが最低1つ(各ホストごとに)、且つ速度は10Gbpsを専用で使うことが望ましい
- 共有データストア(仮想マシン保存領域、HAクラスターノードからアクセスが可能であること)
まだもう少し細かい話もありますが、今回はここまでとしておきます。
本記事のまとめとしましては、次の通りです。
まとめ：vSphere FTはHAと比べ、シームレスなフェイルオーバーが魅力であるが、
構成をする上では、仮想マシンはvCPU4個まで、64GBまでの構成上限がある。
またホストに対しても10Gbpsのネットワークを専用で準備することが推奨。
保護対象がユーザーによっては収まらない場合はvSphere HAを利用するか、サードパーティーのクラスターソリューションが必要になると言えますね。
Read moreVMware Cloud on AWSの使い方（その6）仮想マシンネットワークの設定
今回は、仮想マシンのためのネットワーク接続に関する設定を本記事で纏めたいと思います。
まず、前回までの設定は全て、”管理接続用ネットワーク”に関するものでした。
今回は、仮想マシンのサービス提供用ネットワーク側の設定です。
まず次の6項目が設定値としてあることを確認出来ます。
<Logical Networks>
仮想マシンが所属するネットワークの情報です。ここでは2つのネットワークが表示されています。
特に上の方はDHCPが構成されており、"10.0.0.0/24"のIPアドレスが配布されるネットワークであることを示しています。
<Firewall Rules>
ここでは仮想マシンに対するファイアウォールルールを構成出来ます。
勿論仮想マシン内のゲストOS内でファイアウォールを構成しても良いですが、ゲストOS毎にインターフェースや操作感が異なる環境を個別に管理するのは大変です。
そこで、共通のインターフェースを使い、WindowsもLinuxもファイアウォール環境が管理出来てしまえばとても楽ですね。
上図では、10.0.0.10というIPアドレスを持つ仮想マシンが存在する場合、其のマシンへの接続は”HTTPプロトコル”での接続のみであれば誰でも接続を許可する、というルールが設定されています。
インターフェースが英語であることを除けば、誰でも管理をし易いと感じるのでは無いでしょうか？
<Public IPs>
Public IPを利用した接続が必要な仮想マシンを用意する場合は、ここからPublic IPを用意出来ます。(例えばホームページなどがわかりやすい例ですね)
”Request Public IP”をクリックすると、以下のようにIP発行時にコメントを追加することも出来ます。
Public IP発行後の様子はこちら
”56.56.56.6”というIPアドレスが表示されました。画面右側の”EDIT”からコメントは後から変更することも出来ます。
<NAT>
ここでは、WANからVMware Cloud on AWS内部にある仮想マシンに対しての接続のNAT設定を行っています。
緑のIPアドレスは先程の”Public IPs”にて発行したIPであり、これにアクセスをすると”10.0.0.10”のIPアドレスを持つ仮想マシンにリダイレクトされるという設定です。
"80"という数字は、HTTP接続のためのポート番号ですね。
以上です。1画面でシンプルなウィザードを使って複数のレイヤーのネットワーク設定が簡単にできてしまうのは魅力ですね。
最後にですが、本ハンズオンラボ環境ではvSphere Web Clientなどの管理インターフェース接続が用意されていないため、実際の仮想マシンとの接続性テストが出来ませんでしたが、本サービス固有のインターフェースを理解するのには大変有用なラボだったと言えます。
vForum 資料 ダウンロード 入手手順
本日2017/11/07より、vForum 2017 Tokyoの2日間の資料がダウンロード出来るようになりました。
ダウンロード、入手に際しては、vForum Online用のアカウントが必要となりますのでアカウントをお持ちでない方は、アカウントを作成後に入手が可能となります。
ページ移動後、Day1, Day2のスケジュールシートが表示されますので、
入手したいセッションのタイトルをクリックします。
ページ移動後は、次のようにセッションに参加ができなかった方にもわかるように
セッションのコンセプト紹介もあります:)
ブラウザによって表示形式も異なりますが、Chromeの場合は次の赤枠箇所クリックでダウンロード完了ですね！
以上です。
VMware Cloud on AWSの使い方（その5）DNS 設定手順
今回はVMware Clound on AWSにおけるDNS設定です。
前回、前々回と同じく、ファイアウォール設定、VPN設定の設定箇所の下にDNS設定があります。
ここから、オンプレミス環境に対する名前解決用DNSを設定します。
プライマリとセカンダリDNSサーバーのIPアドレスを入力します。
ハンズオンラボガイドでは、Google Public DNSが指定されていました。勿論、利用するDNSサーバーはユーザー次第となりますので、以下の値はあくまでも参考です。
せっかくなのでnslookupで名前解決が出来ている様子まで紹介したかったのですが、
ハンズオンラボの環境は一部ネットワーク接続が制御されているようでしたので今回は割愛致します。
vSAN 6.6に於けるディスク要求モードについて
vSANについて、あることがきっかけで"ディスク要求モード"について実環境検証をしようとした所、あることに気が付きました。
あるはずの、"ディスク要求モード変更メニュー"が6.6の環境では存在しないのです。
これはvSAN 6.2環境でのvSAN設定のメニュー画面です。(HOL-1708-SDC-1-HOLより抜粋)
これはvSAN 6.6環境でのvSAN設定のメニュー画面です。
この理由を調査した所、vSAN 6.6からはこのモードをリタイアさせたことが次の記事に記載がありました。
本来のディスク要求モードの”自動(Automatic)”はvSAN構成時に、自動的に各ホストに搭載されたドライブを使い、ディスクグループを構成してくれるという機能でした。
コンセプトとしては、ユーザーに変わってディスクグループをデザインすることで、ミス構成を減らす、作業タスク短縮などがあります。
しかしこの点はユーザーが意図しないディスクグループ構成になってしまうという点が課題であり、多くのユーザーは”手動”でディスクグループを構成することが多かったようです。
時代はオールフラッシュストレージは”特別な存在”から”身近で標準的な存在”となってきています。加えて、Software Defined Storageの搭乗により、x86サーバーのシャーシデザインも、いかに大量のストレージデバイスを搭載するか、というコンセプトを持ったものも搭乗してきており、ユーザーサイドではディスクサイジングと選択肢が多くある状況です。
Dell EMC PowerEdge R740xdはストレージ拡張性が高い、代表的なサーバーノードですが、いよいよ2Uシャーシで最大で32本の2.5インチドライブを搭載出来るようになりました。
こうした時代の流れが、今回の機能変更に至ったものである、というのがVMwareからのアナウンスとなっています。
