[VMware] vSAN 6.2 Essentials 無料公開

vSAN界では有名な人物が2人います。Cormac HoganさんとDuncan Eppingさんがその2人です。

お2人ともにVMware社のSABU(Storage & Availability Business Unit)のCTOでありながらvSphere Clustering関連やストレージ、vSAN関連の有益な情報を数多く紹介しています。いつもお世話になっております! 🙂

 

この2人が執筆したEssential Virtual SAN (VSAN): Administrator’s Guide to VMware Virtual SANのvSAN 6.2対応版であるこの本を無料で公開してくれました。

Holiday gift: vSAN Essentials book available for free

vSAN Essentials e-book is now free

 

300ページに渡りアーキテクチャーをはじめインストール、ストレージポリシー、管理・運用、そしてトラブルシューティングまでvSANのすべてをカバーしています。vSAN 6.2版ではありますが、殆どの部分は現在でも十分活用できる内容ですのでvSANの管理者やこれからvSANを導入しようとする方には必読かもしれません。:)

 

改めてCormac HoganさんとDuncan Eppingさんに感謝の気持ちを伝えたいですね。:)

 

広告

[Nutanix] Acropolis Block Services(ABS)について

 

※このエントリーは、Nutanix Advent Calendar 2017に参加しています。

 

先日vSANのiSCSI Target (VIT) サービスについて投稿しました。その際にNutanixも同じ機能があることも紹介しました。今回はそのNutanixのiSCSI Targetサービスについて紹介しようと思います。

 

NutanixのiSCSI Targetサービスの名所はAcropolis Block Services (ABS)です。実はvSANよりも先の 2016年6月に発表されました。

このABSもコンテナー内にvDsikをLUNとして提供します。このABSを利用することで仮想マシンにiSCSI Targetサービスを提供します。しかもVITとは違い、共有ボリュームとして利用が可能なため、Windows Server Failover Clusteringのようなゲストクラスタリングが構成でき、ハイパーバイザーからの利用も可能です。また作成したLUN(ボリューム)をSSD層に固定できるFlash Mode(pinning)も利用できます。正直VITはまだまだ発展段階で、ABSの方が実用的と言えます。

 

Starter以上のエディションであれば利用が可能で、これもまた非常に簡単に構成できます。ということで簡単な構成方法を”より簡単に”紹介してみようと思います。 🙂

 

① Prismに接続後[管理]より[Cluster Details]をクリックします。

 

② [External Data Services IP Address]を指定します。この”エクスターナルデータサービス IPアドレス”が言わば、iSCSI Targetのアドレスになります。

 

③ iSCSI Targetアドレスを指定したら、次はiSCSI Targetボリュームを設定します。メインメニューより[Storage]をクリックします。

 

④ iSCSI Targetのボリュームは[Volume Group]より作成します。まずiSCSI Targetボリューム名を指定してからボリュームサイズを指定します。

 

⑤ iSCSI Initiaterを追加します。また作成したボリュームをSSD上から提供する場合、”Enable Flash Mode”を選択します。他、ボリュームをクラスタ外のサーバに提供する場合は”Enable external client access”を指定します。

 

⑥ これで提供するiSCSI Targetボリューム作成が終わりました。作成したボリュームは[Volume Group]から確認できます。

 

⑦ では、今回はiSCSI Initiaterからです。まずiSCSI Targetを指定します。ここでは簡単にWindows Serverを使いました。iSCSIイニシエーター設定で手順②で設定した”External Data Services IP Address”を指定します。

 

⑧ 正常にiSCSI Targetが追加されるとあとは、他のiSCSIストレージ接続と同じです。[ディスクの管理]よりマウントしたボリュームが確認できます。マウントされたボリュームをオンライン、有効化、フォーマットすればドライブとして利用ができます。

 

⑨  追加したドライブに大量のファイルをコピーしPrismよりiSCSI Targetの状態を確認すると、Read/Write latencyはもちろんIOPS、SSDとHDDへのRead状態も確認できます。

 

ちなみにvSAN iSCSI Target(VIT)についてはここの投稿をご確認くださいねー

 

[VMware] vSAN関連Tipsいくつか

 

※このエントリーは、vExperts Advent Calendar 2017に参加しています。

 

既に10,000社以上で導入されていて、なおその勢いが衰えないvSANですが、お客様と話をしてみると意外とまだまだ知られてないんだぁと感じます。というのはvSANというプロダクトやその特徴は知っていても実際に導入や導入後の運用での注意点についてはあまり認識してないような気がしました。

ということで導入や運用で少し気をつけた方が良い内容を紹介したいと思います。(既に知っているかも内容かもしれませんが…)

続きを読む

[VMware] vSAN iSCSI Target (VIT)について

 

※このエントリーは、vExperts Advent Calendar 2017に参加しています。

 

※今年6月に作成した内容なので少し古いかもしれません。

 

vSAN 6.5よりiSCSI Target機能が追加されました。このvSAN iSCSI Target(VIT)はvsanDatastore上にiSCSI Target用LUNを作成しリモートサーバに提供できる機能です。簡単に言えば、vsanDatastoreの一部をiSCSIボリュームとして利用することができます。この機能はNutanixのような他のHCIでも提供している機能です。

 

vsanDatastoreは、NutanixのStorage Containerとは 異なり、vSANクラスタメンバー以外はアクセスができません。なのでこのVITを利用するとvSANクラスタメンバーでないサーバからもvsanDatastoreを利用することができます。要はvSANを構成するとただのiSCSIストレージも使えるということです。しかもストレージポリシーよってしっかりと可用性を確認しながらです。 🙂

 

それでは簡単にVITを構成する方法について紹介します。

① iSCSI Targetサービスを利用するためには、まずサービスを有効にする必要があります。サービスの有効はクラスタの[構成]の[iSCSI Targets]を選択し、[編集]をクリックします。

 

② サービスの有効化にチェックし、次の情報を設定します。

  • Default iSCSI Network : iSCSI通信で利用するvmkernelを選択します。
  • Default TCP port : デフォルトiSCSIポートの3260を利用します。(もちろん環境によって変更も可能です)
  • Default authentication : iSCSI targetとinitiator間の認証方法を指定します。(検証環境のため、認証は設定していません)
  • Storage policy for the home object : 作成するiSCSI target情報(メタデータ)を保護するストレージポリシーを選択します。

 

③ サービスが有効化されたらiSCSI Targetを作成します。

 

④ iSCSI Targetの情報を指定、 iSCSI Targetを作成します。

  • Alias : 分かりやすいiSCSI Targetのエイリアス
  • Storage Policy : iSCSI Targetを保護するストレージポリシー

 

その他の項目はiSCSI Targetサービス有効化の際に指定した値が自動的に反映されます。

  • LUN ID : 作成する論理ボリュームIDを指定します。(デフォルトの0をそのまま使ってもOKです)
  • Alias : ボリュームのエイリアスを指定します。
  • Storage policy : LUNを保護するストレージポリシーを選択します。
  • Size : LUNのサイズを指定します。

 

⑤ iSCSI TargetとLUNが作成されたことが確認できます。上図ではiSCSI Targetのオーナーノードが”n-esxi65-09″であることも確認できます。

 

⑥ 接続させるiSCSI initiatorを追加します。initiatorとしてはWindows Serverを用意し、”iscsi initiator”と”MPIO”機能を追加しました。

 

⑦ iSCSI initiatorからiSCSI Targetを追加すると普通のiSCSIストレージと変わらず、ボリュームが追加されます。追加したボリュームをオンラインしてフォーマットしたら完了です。:)

 

⑧ [監視]タブの[vSAN]→[iSCSIターゲット]よりiSCSI Targetがストレージポリシーによって保護されていることが確認できます。

 

⑨ vsanDatastoreを参照すると仮想マシンと同様、ディレクトリが作成されLUN用仮想ディスクも作成されていることが確認できます。

このVITは、他のiSCSIストレージを構成するのと同じ設定で構成します。なので簡単に構成し、利用できます。
6.5では次の制限事項があります。
まず作成したLUNを共有ボリュームとして利用することができません。ということはWSFCのようなゲストクラスタリングのように複数のサーバによる共有ストレージ領域としての利用は残念ながらサポートされません。(NutanixのABSの場合は共有ストレージ領域としての利用もサポートされています)
ただし共有ストレージを使用しないExchange ServerのDAG構成やSQL Server AlwaysOn Availability Groups 、DFS-Rといったアプリケーション側でクラスタリング構成が可能な場合はサポートされます。
またESXiホストからの接続もサポートされません。

 

iSCSI Targetのオーナーノードの”メンテナンスモード切り替え”時、IOが自動的にリダイレクトされません。(おそらくこれが一番致命的かと…) オーナーノードをメンテナンスモードに切り替えるとiSCSI Targetと切断されます。残念ながら今のところ… 汗 ただしメンテナンスモードではなく”再起動”の場合は他のESXiホストにオーナーノードが変更されます。

 

まあ、結論… まだまだ本番環境での利用には時期早々ということですな…

検証される方は以下のガイドをご参照ください。

iSCSI target usage guide

 

ちなみにNutanixのABS(Acropolis Block Services)ついてはここの投稿をご確認くださいねー

[VMware] vSANクラスタに仮想マシンではなくレプリカが表示される

 

2017/12/05 Updated

コミュニティの知り合いから関連がありそうなKBの情報をいただきました。ありがとうございます!

vSAN がアクセス不能になると vSAN データストア上の仮想マシンの名前が変更されることがある

今度同じ事象が起きたら試してみます。

 


 

この間、導入した顧客のvSANクラスタに障害が発生しました。

 

4ホスト構成の小規模でしたが運悪く1時間以内で2ホストが停止しまったようです。(FTT=1にもかかわらず一部仮想マシンが”アクセス不可”状態でした。

障害発生後、ホストは復旧されました。vSANクラスタのヘルス状態やオブジェクトのヘルス状態もすべて正常でしたし、すべての仮想マシンにも正常でした。

数時間後顧客から連絡がありました。一部Linux OSの仮想マシンのレスポンスが障害前より遅くなったことと一部コマンドを実行できないということでした。

 

翌日現地で確認してみました。確かに顧客の言うとおりでした。仮想マシンへのSSH接続も’遅い’と感じるほど時間がかかりましたし、やっと接続できてコマンド(例えばsudoやifconfig、rebootなど)を実行すると”バスエラー”が表示されました。あまりLinuxに詳しくないのでググってみたところ、”バスエラー”は一般的に①リソースが足りない②一部ライブラリが破損していると起きるようでした。仮想マシンのリソースは障害発生前と後で変更してませんので、もしかしたらホスト障害によるHA発動でゲストOSに何らかの影響があったのでは?という結論の雰囲気でした。(ただその結論(?)はどうも腑に落ちない…)

 

幸い(?)なことに対象仮想マシンは数日前に新規作成したもので、まだデータはなく最悪の場合テンプレートから作り直せるとのことでしたので、OSブートから少し確認をすることになり、一先ず仮想マシンを強制終了したところ…

仮想マシンがインベントリから消えました。代わりにFTT=1で生成されたレプリカが表示されていました。

ふむ。HA発動のタイミングでレプリカが登録されたんでしょうか?それとも元の仮想マシンの情報が見つからずレプリカの情報が表示されているんでしょうか?詳しい内容は確認できませんでしたが、レプリカが表示されるのは正常ではありませんので、一旦レプリカをインベントリから削除しました。そのあとは元の仮想マシンを再度インベントリに登録したところ、仮想マシンの起動やレスポンスも良くなり、すべてのコマンドが実行できるようになりました。

 

まあ〜結果的にすべて復旧というこのにはなりましたが、原因が特定できず歯がゆい対応でしたね。

(´・ω・`) 推測ですが、HA発動の影響でレプリカを認識するようになった、レプリカは基本’read-only’のはずのため仮想マシンのOS側にも書き込みが正常にできずコマンドが受け付けられなかったのではないかと… 状況をもう少し早く把握してログを採集しサポートチームにエスカレーションしてないのが残念でした。

 

反省…

 

 

[VMware] 既存ストレージからvSANへの移行ガイド

先日、グローバルでvSANを導入した顧客が10,000社と超えたという発表がありました。

 

最近は開発環境や検証環境ではない本番環境として導入する事例が増えてます。しかもSSDの低価格もありハイブリッドよりはAll Flashモードが主流になっていますし、新規環境よりは既存環境のリプレースとしてvSANを採択する企業も増えています。

 

こういう時期に非常に役に立つガイドが公開されました。

 

 

Migrating to vSAN“というタイトルのこのガイドは既存環境からvSANへの移行方法を紹介しています。紹介されている移行シナリオは以下の通りです。

  • VMFSからの移行
  • NFSからの移行
  • non-shared RDMからの移行
  • Shared RDMからの移行
  • 物理サーバの移行

 

ほぼすべての環境をシナリオとして扱っているのでvSANの導入や移行を検討中の管理者必読のガイドかと!!! :)

 

[VMware] !!! vSAN All Flashモードの緊急修正パッチ公開 !!!

10月5日、vSNA All Flashモードの重要なパッチが公開されました。

 

内容は、チェックサムエラーにより、特定な操作やIOパターンが発生した場合、仮想マシンへのアクセス不可、ホスト失敗、再同期失敗などの致命的な状態に陥る可能性があるとのことです。

 

条件はESXi 6.0 Patch 4 (build number 4558694)以上のvSAN、すなわちvSANバージョン6.2, 6.5, 6.6, 6.6.1のAll Flashモードで重複排除が有効化されている場合で、この条件を満たしている場合は、直ちに下記修正パッチを適用することを推奨しています。