ESXi ストレージ パスの見え方, 考え方(Dell Storage MD編)
前回のDell Storage SC編に続き、今回はDell Storage MDのESXiのパスの見え方を紹介してみたいと思います。
前回の記事を参照したい人は、こちらのリンクから閲覧が可能です。
さて、まずは恒例の物理トポロジーの確認からです。
ホワイトボードの左側が192.168.40.x/24で、右側が192.168.41.x/24です(中央の点線が境目)
今回は、イニシエーターとターゲット間のスイッチが冗長化されていない構成です。
勿論、エンタープライズの環境では高可用性は重要なポイントですから、スイッチも二重化することで、よりこの環境の可用性は高まると言えますね。
※今回はテスト環境のため1つのスイッチでストーリーをこのまま進行します。
※遠隔地にある環境を利用したのですが、Cisco Discovery Protocolを利用したおかげで、2つのNICポート(vmnic0と1)が同じスイッチに接続されている事が分かりました。
イニシエーター側が使うIPアドレス
- 192.168.40.76/24
- 192.168.41.76/24
ターゲット側が使うIPアドレス(各色は、ホワイトボード上の色と対応しています)
- 192.168.40.36/24(ストレージプロセッサ上段の左側ポート)
- 192.168.40.37/24(ストレージプロセッサ下段の左側ポート)
- 192.168.41.36/24(ストレージプロセッサ上段の右側ポート)
- 192.168.41.37/24(ストレージプロセッサ下段の右側ポート)
この環境に対し、ランタイム名によってこのシステムを見てみると、ランタイム名の各項目は次のような意味合いを持ちます。
- vmhba - iSCSIアダプターを示す
今回はソフトウェアiSCSIアダプターであり、複数の物理ポートが存在してもvmhbaは1個となっている。
ハードウェアiSCSIアダプターを搭載しているシステムの場合は、デュアルポートならvmhbaが2つ、クァッドポートならvmhbaが4つ登場します。 - Channel - ストレージIOの送信元物理ポートから送信先物理ポートを示す
イニシエーターからDell Storage MDのiSCSI IOポートまでのパス
チャネルでは、送信元と送信先のポート毎にナンバリングがされています。
Channel = Source IPとDestination IPの組み合わせによるPathである。 - Target - Dell Storage MD システムそのものを示す
この事例では、本システムはTarget ID 0として、ESXiが認識しています。
複数のDell Storage MDにアクセスをするESXiの場合は、Target番号を使い、物理的なストレージシステムを差別化します。
ターゲットナンバーで製品が違いますね(T0=MD3200i / T1=MD3000i) - LUN - Dell Storage MD内のLUN(ボリューム)を示す
これは、他のストレージシステムとも同様で、ストレージ内部のボリューム(ホストにマウントする単位)の識別子である。
これらを総括して見ますと、次のようなレイヤー構造が見えてきます。
特に右側の紫のvmhba/Channel/Target/LUNを意識してご覧頂くと、上図の解説がわかりやすいと思います。
物理ストレージシステム自体が単一のターゲットとして振る舞うため、そこまでの道筋の番号をチャネルで表現しているのがDell Storage MDと言えます。
今回は以上となります。そのうちDell Storage PSシリーズでも同じ内容を掲載したいと思います。
vSAN アーキテクチャ ー Distributed Object Manager（DOM）
vSAN アーキテクチャー編始めてみました。
vSANは実は複数のソフトウェアの集合体、と考えていただくことが可能です。
今回は、Distributed Object Manager (略称DOM)の紹介です。
<役割と紹介>
- オブジェクトの可用性の制御と初期IOのリクエストを担当している
- オブジェクトはDOMレイヤーに存在しており、LSOMオブジェクトコンポーネントにDOMがvSANオブジェクトまたはVMDKを展開している
- DOMは全てのミラー化されたコンポーネントに対しIOが同期されていることを保証する
- DOM Clientにて受け取ったIOは、DOM Ownerに転送される
- オブジェクトごとにDOM Ownerは1つであり、必ずオブジェクトのローカルに存在しているとは限らない
- DOMはカーネルスペースに存在しており、監視用デーモンはなく、動作の再起動にはホストの再起動が必要である
- 動作ログはvmkernel.logで追うことが出来る
前回紹介をしました、”CLOM(Cluster Level Object Manager)”と名前が似ており、今回もオブジェクトにまつわるソフトウェアです。
前回のCLOMがポリシー通りの配置になるようにオブジェクトのケアをしていたのに対し、DOMはストレージIOを司ると理解すれば、違いは明確だと言えます。
DOMは全てのvSANノード上で動作をしており、4ノードvSANだったとすれば、4ノード全てでDOMは動作しているといえます。
また、DOMには細かく言えば3つのロールがあり、次の通りです。
- DOM Client
仮想マシンからのストレージIOを受信し、オブジェクトにそれを渡す際に、DOM Ownerに対し渡す役割を行う（DOM Ownerにとっての仮想マシンサイドのインターフェース役） - DOM Owner
オブジェクトごとに存在するオーナーであり、ストレージパスやオブジェクトの再同期など、オブジェクトの管理を行う役目を果たす
DOM Ownerがダウンする、あるいはネットワーク的に他ノードと疎通不可になる場合は、即座に他のDOMが新しいDOM Ownerとして選定される
また、DOM Ownerは、CLOMと通信を行うためのインターフェースを/dev/dom(左記のものは、/dev/char/vmkdriver/domのシンボリックリンク)として持っている。
例えば、仮想マシンの新規作成時には、CLOMがポリシー遵守出来るかをチェックし、其の結果問題無い場合は、CLOMがDOM Ownerに仮想マシン作成指示を出すが、その際の動きが、/var/log/clomd.logに記録される。
（イベント事例としては、CLOMFetchDOMEventなどで検索をすれば表示されます） - DOM Component Manager - LSOMに対するフロントエンドの役割であり、DOM OwnerからのIOを受信し、LSOMにそれを渡す役目を果たす。
これらの位置関係としては、以下のようなイメージである。
[仮想マシン]→[vSCSI]→[DOM Client]→[DOM Owner]→[DOM Component Manager]→[LSOM]→[Physical Drives]
esxtopコマンドでxオプションを使えばDOMの上記3種のストレージアクティビティも関しが出来ますので、IOを司っている、と言われても至極当然な気がします。
vSAN Observerで見た場合には、次のように各DOMとLSOMに対するタブが存在します。
以上となります。やや難しめの記載もあったかもしれませんが、”オブジェクトレベルでのIO担当”がDOMと考えれば概要としてはバッチリかなと思います。
この役割ってハードウェアレイヤーではRAIDコントローラーのような役割とも表現が出来そうですね(パス提示と再同期およびIO担当という点より)
------------------------------------------------------------------------------------------------------------
<備考：本記事で参考にした資料>
https://blogs.vmware.com/vsphere/files/2014/08/Monitoring-with-VSAN-Observer-v1.2.pdf
ESXi ストレージ パスの見え方, 考え方(Dell Storage SC編)
久しぶりにDell Storage SCの講義を行いましたが、その中でvSphere ESXiに対するLUNマウントを実施しまして、パスの見え方について解説をしたので、記事にしてみたいと思います。
まず、今回の環境は次のようなトポロジーです。
ストレージの世界では、IOを発行する側がイニシエーター(Initiator)、IOを受けてデータを保持する側がターゲット(Target)と呼びますよね。
また、ファイバーチャネルの世界では、イニシエーターとターゲット間の接続にWorld Wide Name(ワールドワイドネーム、以下WWN)にて相互に識別をしますが、上図では緑色でそれを簡単に示しました。
本来WWNは、以下のように大変長いため、上図では末尾の文字だけを緑で書きました。
上記の環境を、vSphere Web ClientとDell Storage Manager(Dell Storage SC/PS用の管理ツール)で見た際には次のように見えます。
Dell Storage SCでは、１つのシステム内にストレージコントローラーが2つ存在し、冗長性とロードバランシングを提供します。
単一のボリュームは、この2つのコントローラーのうた1つをアクティブコントローラーと呼ばれるIOを提供してくれる役割に選定します。
同一ストレージシステム内に複数のボリュームが存在する場合は、ボリュームごとにアクティブコントローラーが異なります。（これによりIOの負荷が分散されます）
上図では、ボリューム名"VMware ESXiボリューム1"は、コントローラー”21106”がアクティブコントローラーであり、このコントローラーがダウンした場合はコントローラー”21105”がIO提供をするためのセカンダリコントローラーとなっています。
ご覧を頂くと、アクティブコントローラー側が持つ全てのWWNが、ターゲットWWNとして見えていることが確認出来ますね。
ちなみに、アクティブコントローラーを再起動し、コントローラーの疑似障害を発生させました。
Dell Storage SCは、ターゲットWWNをNPIVによって”仮想WWN”を生成し、コントローラーの障害が発生した場合に、仮想WWNをバックアップコントローラーに移動させ、IOパスをフェイルオーバーさせます。
以上です。ストレージの見え方というのは製品の仕様によっても少々異なることがありますので、その点ご容赦ください。
ちなみにイニシエーターWWNは次のようにトポロジーと紐付いています。
加えて、4つのパスも上記オレンジで表現していますので、参考に頂ければ幸いです。
以上です、よい週末をお過ごしください。
----------------------------------------------------------------------------------------------------
<補足>
フェイルオーバーした仮想WWNは、”ポートリバランス(再調整)”にて、フェイルバックします。
仮想WWNがフェイルオーバーしているよう場合には、次の警告が出ますので、”ポートの再調整”をクリックすれば、ポートのフェイルバックが完了します。
仮想WWNポートが無事戻りました。
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などの管理インターフェース接続が用意されていないため、実際の仮想マシンとの接続性テストが出来ませんでしたが、本サービス固有のインターフェースを理解するのには大変有用なラボだったと言えます。
