光栄なことにvExpert 2017 VSANを受賞することになりました。
vExpert 2017 VSAN Announcement
vExpert 2017 VSANは、その年に選ばれたvExpertの中から特定プロダクト普及に貢献したvExpertに授与するサブプログラムです。サブプログラムには今回選ばれましたvSAN以外にNSXとHorizon View(確か…)があります。
vExpert 2017 VSANプログラムが開始された2016年にはグローバルで20名ほどだったと思いますが今年は87名まで増えました。うち日本からの受賞者は2名でした。
個人的には第1世代のVirtual SAN 5.5から案件に携わっているのでどのプロダクトより愛着(?)があって今回の受賞は非常に光栄で嬉しい限りです。
これからもvSANを広めるべく色々と情報を共有して行きますので引き続き、よろしくお願いします。
PS>ふむ。確かvExpert Horizon Viewがあったと記憶していますが、調べてみても出てきませんね。なくなったんですかね。。。
先日vSphere 6.5 Update 1のリリースと同時にvSANの6.6.1に若干(!)バージョンが上がりました。
vSAN 6.6.1は、まあ〜マイナーバージョンアップ(しかも0.0.1)ですので”バグ修正版”かと思いきや新しいライセンス体系や機能改善がしっかりと含まれていました。
で、数日前に今度は”vSANアップグレードガイド”が公開されました。
正確には古いバージョンのvSAN(vSAN 6.6を含む)から6.6.1にアップグレードする際に考慮すべき以下の内容で構成されています。
上記以外にアップグレードには必須であるvCenterのアップグレード方法やvSANアップグレード時のトラブルシューティングの内容も含まれています。
1世代のVirtual SAN 5.5のリリースから4年が過ぎました。5.5を含む古いバージョンを導入している方の中ではバージョンアップを検討される方もいるんじゃないでしょうか。アップグレードを検討している方は是非お読みください。
※同僚から質問された内容を基に確認した内容です。
オフィシャルにvsanDatastore上へのvCenterインストールはサポートされています。（推奨はvCenterのような管理系仮想マシンはコンピュートクラスタとは別のクラスタ上で稼働させることです）
しかし実際にvsanDatastore上にvCenterを構成するのはやや面倒です。vSANを構成するためにはvCenterが必要ですが、vSAN用サーバだと大体インターナルSDカードにESXiをインストールしているはずなので、ローカルデータストアがありません。よってvCenterがインストールできません。要するに”鶏が先か卵が先か”です。そのため1台のESXiのディスクの一部をローカルデータストアとして構成、vCenterをインストールします。vCenterがあればvSANを構成できるのでvSANを構成したあとにvCenterをローカルデータストアからvsanDatastoreにStorage vMotion。vCenterがvsanDatastoreに移ったらローカルデータストアを削除、そのディスクをディスクグループに追加…みたいな方法を使う必要あります。もちろん最初からローカルデータストア用ディスクを用意しておく…というのもありかもですね。:)
ただしこういう面倒な方法もvSAN 6.5までです。vSAN 6.6からは面倒な方法を使わなくても簡単にvCenterをインストールすることができます。その名も”Easy Install”！
Easy InstallはVCSA 6.5d以降のバージョンで利用できます。VCSAデプロイ時、最初のESXiに一時的なvsanDatastoreを構成し、VCSAをインストールします。上の図のようにデプロイするデータストアを選択する際に”新しいvSANクラスタに含まれるESXiホストにインストール”オプションを選択するだけです。
”新しいvSANクラスタに含まれるESXiホストにインストール”オプションを選んだ後はディスクグループとして使用するディスクを指定します。あとは普通のVCSAインストールと同じです。
インストール後、動作を確認している中で下の図のようなことを発見しました。
ご覧のとおり、”使用済み-予約超過仮想マシン”のサイズが446GBにもなっていました。”使用済み-予約超過仮想マシン”はストレージポリシーの”オブジェクトスペースの予約”によって予約された容量になります。vSAN構成時、作成されるVirtual SAN Default Storage Policyの”オブジェクトスペースの予約”は0%、即ち”予約はしない”なので予約サイズが446GBにもなってしまったということはストレージポリシーが適用されていないことになります。
デプロイしたVCSAを確認しましたところ、ストレージポリシーは適用されてない状態でした。もちろんeasy installでVCSAをインストール後、2台のESXiを追加して必要ノード数を満たしたあとです。
てか… 当たり前のことですよね。そもそも1台で一時的にvSANを構成しているのでVirtual SAN Default Storage Policyの条件をみたしてないし、条件を満たしたとしてもあとから自動的にストレージポリシーが適用されませんので。:)
とりあえず、ストレージポリシーを適用しました。結果…
”使用済み-予約超過仮想マシン”のサイズは20GBまで減りました。
Easy InstallでVCSAをインストールした場合は、vSAN構成後忘れずにVCSAにもストレージポリシーを適用してくださいなー。
他のプロダクトより短い間隔で新しいバージョンがリリースされているvROpsの新しい6.6バージョンが6月上旬リリースされました。このvROpsはVMware社のSDDC戦略のコアプロダクトの一つとして、バージョンを重ねるに連れて他のプロダクトのモニタリング機能が追加されつつあります。
今年3月にリリースされた6.5まではある意味バグ修正と性能安定が中心でしたが、本6.6は見た目から大きく変更されています。
まず、UIが大きく変わりました。遂にvROpsもHTML5対応になりました！祝！
よって画面遷移はもちろん全体的に操作が非常に軽いです。
※ご覧ください！このシンプルでキレイなUIデザイン！
HTML5化に伴いメニューも変更されました。プロダクト中心だったダッシュボードも操作、容量、パフォーマンスやトラブルシューティングにカテゴライズされ、より簡単にインフラのヘルス状態の確認できるようになりました。
※パフォーマンスのトラブルシューティングダッシュボードではプロダクトの種類と関係なく、仮想マシンを始めvSAN、クラスタ、データストアなどカテゴリでその状態が確認できます。
もう一つ大きい変更はvSANのモニタリング機能が統合されたことです。6.5まではvSANの環境をモニタリングｓるためにはMPSD(Management Pack for Storage Devices)を別途インストールする必要がありました。6.6ではこのモニタリング機能が統合されMPSDをインストールする必要がなくなっています。（もちろん他のストレージをモニタリングするためにはMPSDをインストールする必要があります）
※ No more MPSD for vSAN! 🙂
以外にも仮想インフラ上の負荷状況を分析、vRAでデプロイする仮想マシンを最適なホストに位置させる自動ロードバランス機能やvSphereのハードニングコンプライアンス状態が確認できるダッシュボードも追加されました。
※パフォーマンスだけではなくコンプライアンス準拠状態も確認できます。
VMwareの技術、ソリューションを広めたユーザへ表彰するvExpertプログラムの2017年後半の応募が開始されました。2014年から1年に2回応募ができるようになりました。
ご存知の通り、このvExpertプログラムはブログやコミュニティは、勿論セミナーのプレゼンテーションや執筆などVMware社プロダクトを広めてきたユーザであれば自薦他薦問いませんのでぜひ応募してみてはいかがでしょうか。
応募期間は2017年6月7日から7月7日までの1ヶ月間で受賞者の発表は8月11日です。
vSphereのバージョンが上がるにつれて、VMware社がVCSAを重要視していることが分かります。vSphere 5.1で初めてVCSAが披露された時は、殆どの管理者が見向きもしなかったかもしれませんが、現在は大分変わったんじゃないでしょうか。
まず、Windows版vCenterと同じ土俵に立つようになりましたね。5.5まではサポートするホスト数も仮想マシンの数もWindows版に劣ってましたが、6.0になりWindows版同様クラスタあたり最大64ノード、最大8,000 仮想マシンを管理できるようになりました。6.5では更に強化されUpdate Managerも統合されましたし、OSもSLESからPhoton OSに代わりより軽量化されました。今度は逆にWindows版にはない機能も追加されました。それがネイティブバックアップ機能とvCenetr HA（VCHA）機能です。
vCenter High Availability Performance and Best Practice
上図のようにVCHAは、vCenterをフェイルオーバーする機能です。一旦仮想マシンの停止が発生するvSphere HAとは異なり、VCHAはActive-Passive構成です。ActiveとPassive間ではDBではsync、その他のファイルに対してはasync同期が行われます。よってVCHAを構成するためにはPassive用VCSAとWintness用VCSAを導入する必要があります。
VCHAの構成は至って簡単で構成方法は2つあります。
●Basic
VCSAがHAを構成するクラスタ上に存在する場合、Basicオプションで構成します。この方法はハートビート用ネットワークの用意以外の事前準備はありません。HA構成ウィザードに従い進めて完了です。
●Advanced
Basicとは違って、VCSAがHAを構成するクラスタ外にある場合のオプションです。例えばVCSAが管理するクラスタと別れている場合になります。このオプションではハートビート用ネットワークの用意と手動によるVCSAへのネットワークアダプター追加が必要です。
検証環境にて、VCHAを構成してみました。小職の検証環境はVCSAが別のホスト上で稼働中のため、Advancedオプションで構成します。
① まず、Active用VCSA(vc65-ha-a)にハートビート用ネットワークアダプターを追加します。
② VCSAの管理ページより、追加したハートビート用ネットワークアダプターにIPアドレスを手動で指定します。
③ Web Clientより、VCSAを選択し、[設定]→[vCenter HA]→[構成]を選択します。
④ 構成ウィザードが表示されるので、[Advanced]を選択、[次へ]をクリックします。 
⑤ PassiveとWitnessのハートビート用IPアドレスとサブネットを設定し[次へ]をクリックします。 
⑥ この段階で一旦、構成ウィザードの操作は止めます。ウィザードは閉じないでそのままにしておき、別のウェブブラウザを起動PassiveとWitness用VCSAのクローンを作成します。 
⑦ Web ClientよりVCSAを選択し、まずはPassive VCSA用クローンを作成します。
※ クローン作成方法は割愛しますが、クローン作成用”カスタマイズ仕様”を定義する必要があります。定義の際には以下の項目設定に注意が必要です。
上記の項目以外はVCHA特有の設定はありません。すべて設定したらクローンを作成し、正常に起動するまで待ちます。
⑧ 今度はWintness用VCSAのクローンを作成します。
基本、Passive VCSA用クローン作成と同じですが、こちらも”カスタマイズ仕様”を定義する必要があります。定義の際には以下の項目設定に注意が必要です。
上記の項目以外はVCHA特有の設定はありません。すべて設定したらクローンを作成し、正常に起動するまで待ちます。
⑨ 再度、VCHA構成ウィザードのページに切り替え[完了]をクリックします。 
⑩ HAクラスタの構成が始まります。 
⑪ 構成はすぐ終わります。VCHAが構成が完了すると画面中央に各ノードのロールと状態が表示されます。VCHA構成直後はActiveの情報がPassive側にレプリケーションされるため警告が表示されます。 
⑫ 正常にActive側のDBとファイルが複製されたら”正常”状態になります。 
⑬ [監視]タブより、HAの健全性が”良好”であることが確認できます。 
VCHA構成後、failoverを試してみました。
① Active VCSAを停止します。 
② Web Clientのページを更新すると”failover”が進行中であることが分かります。failoverが完了するまで一時的にWeb Clientはエラー画面が表示されますが、数分でfailoverは完了されます。検証環境では6分ほどかかりました。 
③ Web Clientにログインし、VCHAの状態を確認するとActiveノードは切断され、Passiveノードに変更されていることが確認できます。 
④ [監視]タブからもHAの健全性が”警告”になっています。ちゃんと機能してますね。:) 
構成してみたところ、意外とfailoverに時間が必要であることが分かりました。VMware社のドキュメントではvCenterの構成とインベントリのサイズによって時間は異なるが、UIクライアントで4分でfailoverされるとしています。となると… 正直シングルクラスタ環境ではvSphere HAでfailoverされた方が早いかもです。
しかし複数のクラスタをシングルVCSAで管理する場合は、vSphere HAに加えてVCHAも構成しておけば更に強固なvCenterの冗長性が確保できるのではないでしょうか。:)
VCHA構成に伴うパフォーマンスとベストプラクティスは下記のドキュメントをご参照ください。
vCenter High Availability Performance and Best Practice
５月１日、NutanixのAOS 5.1がリリースされました。
メジャーバージョンの5.0リリース後、約5ヶ月ぶりの新しいバージョンで以下の機能が新たに追加されました。
合わせて5.0ではテクニカルプレビューだったHot-Add機能、XenServerが正式的にハイパーバイザーとして利用できるようになりました。
またAOS以外にPrism Central、AFS、ACS、Foundationもそれぞれ新しいバージョンがリリースされました。
より詳しい内容はリリースノートをご参照ください。
