VMwareな日々

VMware環境関連の管理者/導入/トラブルシュートなどに役立ちそうな情報を備忘録として掲載とその他を少々投稿していくブログ

ESXi ストレージ パスの見え方, 考え方(Dell SC Storage編)

久しぶりにDell SC Storageの講義を行いましたが、その中でvSphere ESXiに対するLUNマウントを実施しまして、パスの見え方について解説をしたので、記事にしてみたいと思います。

 

まず、今回の環境は次のようなトポロジーです。

ストレージの世界では、IOを発行する側がイニシエーター(Initiator)、IOを受けてデータを保持する側がターゲット(Target)と呼びますよね。

f:id:instructor8010:20171117184454p:plain

また、ファイバーチャネルの世界では、イニシエーターとターゲット間の接続にWorld Wide Name(ワールドワイドネーム、以下WWN)にて相互に識別をしますが、上図では緑色でそれを簡単に示しました。

本来WWNは、以下のように大変長いため、上図では末尾の文字だけを緑で書きました。

f:id:instructor8010:20171117184912p:plain

Adapterがサーバー側 / TargetがDell SC Storage側

上記の環境を、vSphere Web ClientとDell Storage Manager(Dell Storage SC/PS用の管理ツール)で見た際には次のように見えます。

f:id:instructor8010:20171117184810p:plain

左側がDell Storage Manager、右側がvSphere Client

Dell SC Storageでは、1つのシステム内にストレージコントローラーが2つ存在し、冗長性とロードバランシングを提供します。

単一のボリュームは、この2つのコントローラーのうた1つをアクティブコントローラーと呼ばれるIOを提供してくれる役割に選定します。

同一ストレージシステム内に複数のボリュームが存在する場合は、ボリュームごとにアクティブコントローラーが異なります。(これによりIOの負荷が分散されます)

 

上図では、ボリューム名"VMware ESXiボリューム1"は、コントローラー”21106”がアクティブコントローラーであり、このコントローラーがダウンした場合はコントローラー”21105”がIO提供をするためのセカンダリコントローラーとなっています。

 

ご覧を頂くと、アクティブコントローラー側が持つ全てのWWNが、ターゲットWWNとして見えていることが確認出来ますね。

f:id:instructor8010:20171117185207p:plain

色がそれぞれのWWNに対応しています。

ちなみに、アクティブコントローラーを再起動し、コントローラーの疑似障害を発生させました。

Dell SC Storageは、ターゲットWWNをNPIVによって”仮想WWN”を生成し、コントローラーの障害が発生した場合に、仮想WWNをバックアップコントローラーに移動させ、IOパスをフェイルオーバーさせます。

f:id:instructor8010:20171117190252p:plain

以上です。ストレージの見え方というのは製品の仕様によっても少々異なることがありますので、その点ご容赦ください。

ちなみにイニシエーターWWNは次のようにトポロジーと紐付いています。

f:id:instructor8010:20171117191346p:plain

加えて、4つのパスも上記オレンジで表現していますので、参考に頂ければ幸いです。

以上です、よい週末をお過ごしください。

----------------------------------------------------------------------------------------------------

<補足>

フェイルオーバーした仮想WWNは、”ポートリバランス(再調整)”にて、フェイルバックします。

仮想WWNがフェイルオーバーしているよう場合には、次の警告が出ますので、”ポートの再調整”をクリックすれば、ポートのフェイルバックが完了します。

f:id:instructor8010:20171117192040p:plain

仮想WWNポートが無事戻りました。

f:id:instructor8010:20171117192142p:plain

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"があります。

f:id:instructor8010:20171109161531p:plain

clomd.logがあります。(勿論ホストごとにあります)

vSANが構成されたばかりのclomd.logを見てみますと、”esx-01a.corp.local”が"vmhba4:C0:T0:L0"のディスクを使い、ディスクグループを組んでいる様子が分かります(勿論、他のホスト、他のディスクも、この行の前後でこれに組み込まれていますね)

f:id:instructor8010:20171109170140p:plain

オブジェクトの配置場所を考える上で、ディスク配置の情報などを把握するためにこれらの情報を読み取っているように見えます。ログの解説もしたい所ですが、詳細情報をこれから集めますので、情報が集まり次第別回で紹介したいと思います。



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が既定で持つタイムアウト値を修正するか、パッチ適用が必要ということが記載されています。

f:id:instructor8010:20171109142534p:plain

ディスクタイムアウト時間とIOリトライ回数を再設定しているようです。

vSAN Observerでは、"VSAN Disks (deep-dive)"が、LSOMによってレポートされている情報です。

f:id:instructor8010:20171109143616p:plain

ここでは物理ドライブ単位の遅延、IOPSなども閲覧が出来ます

以上です。今後も追加情報があれば記載をしたいと思います。

vSphere HAとvSphere FTの違い(vSphere FT編)

過去の記事の続編記事です。特に今回はのような記事はvSphere入門者向けの記事だと言えます。

 

以下の記事と本記事をセットで読んで頂ければ、vSphereが提供する”冗長性のためのクラスター”についての基本的な理解が出来ます。

instructor8010.hatenablog.jp

 

vSphereビギナーに多い疑問は”vSphere HAとvSphere FT”の違いがよくわからない、と言うものです。

 

まず、一番の違いは”仮想マシンリカバリー手法です”

  • vSphere HAは、ホスト停止などにより仮想マシンが停止する場合は、別の正常なホスト上に仮想マシンを再起動によってサービス継続を維持します。
    つまり、仮想マシンが再起動している間は、サービス提供が停止します。
    この機能のコンセプトは”自動化されたフェイルオーバー”です。

  • vSphere FTは、RAID1のように二重化された仮想マシンを保持し、片方がダウンした場合、シームレスにセカンダリ仮想マシンがサービス提供を継続します。
    この機能のコンセプトは”自動化されたフェイルオーバー+無停止フェイルオーバー”です。

    f:id:instructor8010:20171008104233p:plain

つまり、フェイルオーバーにかかるダウンタイム時間の差が違いです。

これだけを見てみれば、"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を利用するか、サードパーティークラスターソリューションが必要になると言えますね。

続きを読む

VMware Cloud on AWSの使い方(その6)仮想マシンネットワークの設定

今回は、仮想マシンのためのネットワーク接続に関する設定を本記事で纏めたいと思います。

 

まず、前回までの設定は全て、”管理接続用ネットワーク”に関するものでした。

今回は、仮想マシンのサービス提供用ネットワーク側の設定です。

 

まず次の6項目が設定値としてあることを確認出来ます。

f:id:instructor8010:20171009162653p:plain

 

<Logical Networks>

f:id:instructor8010:20171009162943p:plain

仮想マシンが所属するネットワークの情報です。ここでは2つのネットワークが表示されています。

特に上の方はDHCPが構成されており、"10.0.0.0/24"のIPアドレスが配布されるネットワークであることを示しています。

<Firewall Rules>

f:id:instructor8010:20171009163553p:plain

ここでは仮想マシンに対するファイアウォールルールを構成出来ます。

勿論仮想マシン内のゲストOS内でファイアウォールを構成しても良いですが、ゲストOS毎にインターフェースや操作感が異なる環境を個別に管理するのは大変です。

そこで、共通のインターフェースを使い、WindowsLinuxファイアウォール環境が管理出来てしまえばとても楽ですね。

上図では、10.0.0.10というIPアドレスを持つ仮想マシンが存在する場合、其のマシンへの接続は”HTTPプロトコル”での接続のみであれば誰でも接続を許可する、というルールが設定されています。

インターフェースが英語であることを除けば、誰でも管理をし易いと感じるのでは無いでしょうか?

<Public IPs>

Public IPを利用した接続が必要な仮想マシンを用意する場合は、ここからPublic IPを用意出来ます。(例えばホームページなどがわかりやすい例ですね)

f:id:instructor8010:20171009164558p:plain

”Request Public IP”をクリックすると、以下のようにIP発行時にコメントを追加することも出来ます。

f:id:instructor8010:20171009164951p:plain

Public IP発行後の様子はこちら

f:id:instructor8010:20171009165211p:plain

”56.56.56.6”というIPアドレスが表示されました。画面右側の”EDIT”からコメントは後から変更することも出来ます。

 

<NAT>

f:id:instructor8010:20171009165725p:plain

ここでは、WANからVMware Cloud on AWS内部にある仮想マシンに対しての接続のNAT設定を行っています。

緑のIPアドレスは先程の”Public IPs”にて発行したIPであり、これにアクセスをすると”10.0.0.10”のIPアドレスを持つ仮想マシンにリダイレクトされるという設定です。

"80"という数字は、HTTP接続のためのポート番号ですね。

 

以上です。1画面でシンプルなウィザードを使って複数のレイヤーのネットワーク設定が簡単にできてしまうのは魅力ですね。

 

最後にですが、本ハンズオンラボ環境ではvSphere Web Clientなどの管理インターフェース接続が用意されていないため、実際の仮想マシンとの接続性テストが出来ませんでしたが、本サービス固有のインターフェースを理解するのには大変有用なラボだったと言えます。

f:id:instructor8010:20171009170342p:plain

 

vForum 資料 ダウンロード 入手手順

本日2017/11/07より、vForum 2017 Tokyoの2日間の資料がダウンロード出来るようになりました。

ダウンロード、入手に際しては、vForum Online用のアカウントが必要となりますのでアカウントをお持ちでない方は、アカウントを作成後に入手が可能となります。

 

資料ライブラリ | vFORUM ONLINE

f:id:instructor8010:20171107091636p:plain

赤矢印の箇所をクリックします

ページ移動後、Day1, Day2のスケジュールシートが表示されますので、

入手したいセッションのタイトルをクリックします。

f:id:instructor8010:20171107091857p:plain

例えば、次のセッションの資料をダウンロードしたい場合はこちらをクリックします。

ページ移動後は、次のようにセッションに参加ができなかった方にもわかるように

セッションのコンセプト紹介もあります:)

f:id:instructor8010:20171107092137p:plain


ブラウザによって表示形式も異なりますが、Chromeの場合は次の赤枠箇所クリックでダウンロード完了ですね!

f:id:instructor8010:20171107093520p:plain

以上です。

VMware Cloud on AWSの使い方(その5)DNS 設定手順

今回はVMware Clound on AWSにおけるDNS設定です。

 

前回、前々回と同じく、ファイアウォール設定、VPN設定の設定箇所の下にDNS設定があります。

ここから、オンプレミス環境に対する名前解決用DNSを設定します。

f:id:instructor8010:20171009154836p:plain

プライマリとセカンダリDNSサーバーのIPアドレスを入力します。

f:id:instructor8010:20171009160332p:plain

ハンズオンラボガイドでは、Google Public DNSが指定されていました。勿論、利用するDNSサーバーはユーザー次第となりますので、以下の値はあくまでも参考です。

 

せっかくなのでnslookupで名前解決が出来ている様子まで紹介したかったのですが、

ハンズオンラボの環境は一部ネットワーク接続が制御されているようでしたので今回は割愛致します。