大変光栄なことに今年もvExpert VSAN 2018を受賞しました。
vExpert VSAN 2018 Announcement
vExpert VSANはvExpertのサブプログラムでvExpertの中からの応募者をvExpertチームとStorage & Availability部門(SABU)が審査し受賞者を決めます。同様のvExpertのサブプログラムはNSX、Cloudがあります。ちなみにNSXとCloudはそれぞれ8月、10月に発表されましたね。去年は。
まあ、とにかく嬉しいです。;)
日本から4名の方が受賞されたようで、同僚も受賞して嬉しい限りです。:)
あ、Horizon関連もありますが、なんかHorizonの場合はvExpertのサブプログラムではなく独立したプログラムのようです。正式名称はVMware EUC Championsです。
Here They Are: VMware 2018 EUC Champions
※少し溜め込んだ内容です。
去年、vSAN関連tipsを投稿したことがあります。その中で、vSAN導入後の障害テストとして稼働中のディスクを抜くのではなく”vsanDiskFaultInjection.pyc”を使うようにと、紹介しました。このスクリプトを実行するとキャッシュ/キャパシティディスクに対して疑似障害を起こすことができます。
で、私自身もvSANを導入した際には”vsanDiskFaultInjection.pyc”でディスク障害テストを実行していますが、vSAN 6.5から想定外の実行結果になります。
何が想定外って、キャッシュディスクに疑似障害を起こすと、ディスクグループが見えなくなります。これはヨロシクありません。ディスクグループが見えなくなると何が問題かというと、そのディスクグループ内のキャパシティディスクを削除できないからです。キャパシティディスクを削除できないと、仮にキャッシュディスクを交換してディスクグループを再作成しようとしてもキャパシティディスクが表示されません。なぜならキャパシティディスクのメタデータは古いディスクグループに紐付いているままのためです。(もちろんキャパシティディスクは疑似障害を起こしてもディスクグループはちゃんと見えます。)
この事象、vSAN 6.5〜6.6.1のバグのようです。vSAN 6.2までは本バグの影響はなく、キャッシュディスクに疑似障害を起こしてもディスクグループは見えるため、Web Clientでキャパシティディスクまたはディスクグループを削除できます。そしてvSAN 6.7では本バグの解消(回避策？)されています。
検証環境で確認してみましょう。
上図は、vSAN 6.6.1の検証環境です。3ノード構成で最初のノード(n-esxi65-15)のキャッシュディスクに疑似障害を起こします。
“vsanDiskFaultInjection.pyc”スクリプトで”永続的なディスク失敗”状態にしました。
見えますか？最初のノード(n-esxi65-15)からディスクグループが見えなくなりました。ただキャッシュディスクとキャパシティディスクは見えます。でもでもでも… キャパシティディスクを削除する方法がありません。(；´Д`)
今度は、本バグが解消されたとされるvSAN 6.7の検証環境です。3ノード構成で最初のノード(n-esxi67-21)のキャッシュディスクに疑似障害を起こします。
“vsanDiskFaultInjection.pyc”スクリプトで”永続的なディスク失敗”状態にしました。
にゃ？解消されているはずのバージョンですがvSAN 6.6.1と同じく、ディスクグループが見えなくなり、しかもキャパシティディスクを削除するメニューが見当たりません。(･_･?)
HTML5 Clientで先程vSAN 6.7のクラスタを見てみます。するとHTML5 Clientにはきちんと[Remove Disk(s)]のボタンがありました。(ﾟ∀ﾟ) ご存知のとおり、Flash ClientはvSphere 6.7で非推奨に、次期バージョンでは非サポートになる予定のため、Flash Clientはこの機能が実装されてないわけです。
[Remove Disk(s)]をクリックするとキャパシティディスクを削除できるようなります。
綺麗に(?)削除されました。;)
ちなみに本バグに影響を受けているvSAN 6.5 〜 vSAN 6.6.1を使用している環境でもしキャパシティディスクに障害が起きた場合は、下記の手順で、ESXiから直接キャパシティディスクを削除します。
まずは、削除するキャパシティディスクのデバイス名を確認します。
esxcli vsan storage list
デバイス名を確認したら、下記のコマンドをキャパシティディスクごとに実行し削除します。
esxcli vsan storage remove –evacuation-mode=noAction –disk=デバイス名
4月 AOS 5.6がリリースされたタイミングでサポートポリシーも変更されました。中にはAOSの命(EOL)についても明記されていて、今回は簡単にNutanix AOSのライフサイクルについて紹介しようと思います。
AOSのライフサイクルの前に、AOSのバージョンの付け方について説明しますと、AOSは4桁のバージョンで定義されています。
各桁はそれぞれ”メジャーバージョン”、”マイナーバージョン”、”メンテナンスバージョン”、”パッチバージョン”を表しています。
Nutanix EOL Bulletin AOS Versionsでは基本的に”マイナーバージョン”で分かれています。
Nutanix EOL Bulletin AOS Versions
で、このEOL Informationを確認すると一覧の下に”LTS”っつうのが付いているのに気づきましたでしょうか？しかも何だか5.5だけ付いてます。
“LTS”はLong Term Support、即ち長期間サポートするバージョンでGAリリースから最大18ヶ月後にEOLになります。この”LTS”は12ヶ月ペースで新しいバージョンがリリースされる予定とのことです。
長期間があれば短期間もあり、それが”STS”、Short Term Supportです。”STS”はGAリリースから6ヶ月後にEOLを迎える6ヶ月間の命なのです。(゜Д゜) ハア?? と思うかもしれませんが(自分もそうでしたが)、”STS”は新機能追加のお試し版のようなバージョンです。となると短い命でも納得です。;) ちなみに4月にリリースされたAOS 5.6は”STS”で今年10月がEOLです。
既にNutanix環境を利用中の管理者はAOSの新しいバージョンが頻繁にリリースされていることをご存知かと思います。新しいバージョンがリリースされた際には、そのバージョンのEOL確認を心かけましょう。
サポートポリシーについてより詳しく知りたい方は、サポートポリシーページをご確認ください。
(0) vRAの概要
(1) vRAのコンポーネント
(2) vRAのインストール
(3) テナント作成
(4) Active Directoryの追加
(5) エンドポイントの作成
(6) ファブリックグループの作成
(7) マシンプリフィックス/ネットワークプロファイルの作成
(8) ビジネスグループの作成
(9) 予約/予約ポリシーの作成
(10)ブループリント作成
(11)サービスカタログの作成
(12)ブループリントのリクエスト
(13)承認ポリシーの作成
(14)カスタムプロパティの作成
(15)vROエンドポイントの作成
(16)イベントブローカーの設定
(17)NSXとの統合
(18)仮想マシンのインポート
(19)仮想マシンの解除
(20)vROpsの統合 – vRA側
(21)Health Serviceの構成
久しぶりのvRAシリースです。;)
vRA 7.3でいくつか追加された機能があり、vRA環境の健全性を確認できるHealth Serveiceもその一つです。このHealth Serviceはシングル/マルチvRA環境とvROの健全性をチェックするものでスケジューリングが可能なため、定期的に環境の健全性を確認することができます。
Health Serviceを構成できるのはIaaS管理者で、構成したHealth Serviceはテナント管理者やHealth Consumerであれば参照できます。
① [管理]タブより[Health]を選択し、[NEW CONFIGURATION]をクリックします。
※このHealth Serviceは、複数vRAまたはvROを登録できるため、まずは健全性をチェックする環境のテストカード(プロファイルのようなもの)を作成します。
② ウィザードが表示されるので、以下のテストカードの概要を構成します。
③ 健全性をチェックする項目を選択します。vRAを選択した場合は”システム”か”テナント”が選択できます。
④ 対象vRA環境の情報を入力します。
※入力が必要な項目だけ明記しています。
⑤ [Finish]をクリックして、テストカードの作成を完了します。
⑥ 作成したテストカードの[RUN]をクリックし、健全性チェックを実行します。環境の規模にもよると思いますが、小規模ですと1分程度でチェックが完了します。
⑦ 結果は、まず視覚的に分かりやすい円グラフで表示され、各色をクリックすると詳細が確認できます。
⑧ 詳細は健全性チェック結果をはじめ、失敗した場合はその原因と修正方法が参照できます。
※修正方法と言ってもクリックするとドキュメンテーションページに飛ぶだけですけどね。;)
⑨ 複数のvRA環境やテナント、vROまでテストカードが構成できるのですべての環境を1つの画面で直感的に健全性が分かります。
vRSLCMもそうですけど、テストカードの配置もできるようにしてほしいですね。:)
3月末待ちに待ったvRA 7.4がリリースされましたが、中々確認ができず、GWでやっと検証環境を7.4にアップデートしました。:) 計画としてはvRSLCMを使って検証環境をアップグレードしようとしましたが、vRAとvRBがどうしても上手くアップグレードができなくて結局の仮想アプライアンスの管理UIからアップデートを実施しました。(一応ね、vRLIとvROpsはvRSLCMからアップグレードができましたね…)
※vRAもvRBも正確にはアップデートレベルですが、vRSLCMではアップグレードというメニューですので、ちょいと紛らわしいです。:)
vRAのアップデートは、「vRAアプライアンス」→「vRA IaaSサーバ」→「vRO」→「vRB」順になりますが、Embedded vROを使っていてvRBはインストールしてない環境であればおそらく以下の手順でアップデートは完了するかと思います。
では、簡単にアップデートの流れを紹介したいと思います。
アップデートする前に、必ずvRAアプライアンス、vRA IaaSサーバのスナップショット作成、IaaS DBのバックアップは取ってくださいね。
① vRAアプライアンスの管理UIにログインし、[Update]タブから[Check Updates]をクリックします。vRAアプライアンスがインターネットへのアクセスができるのであれば、デフォルトのレポジトリからアップデート可能なバージョンがヒットするはずです。
② [Install Updates]をクリックし、アップデートを開始します。まずデフォルトレポジトリからファイルをダウンロードするので、上の画面の状態がしばらく(10分以上)続きます。
③アップデート用ファイルのダウンロードが完了するとアップデートが開始されます。アップデートの前にまずは事前チェックが行われます。
④ 事前チェックの結果、アップデートの条件を満たしていれば、自動的に事前インストールが開始されます。まずはvRAアプライアンスからです。
⑤ vRAアプライアンスの事前インストールが完了したタイミング(?)でログインし直してみると7.3まではなかったタブが追加されていることが分かります。
⑥ 事前インストールが完了すると続けて事後インストールが開始されます。
⑦ 事後インストール途中でvRAアプライアンスの再起動が必要になります。再起動するとvRAアプライアンスのアップデートは完了です。
⑧ vRAアプライアンスのアップデートが終わると自動的にvRA IaaSサーバのアップデートが開始されます。vRAアプライアンスは既に7.4にアップデートされています。
⑨ 自分の検証環境は全部で5ステップに分かれています。最初のステップはIaaSサーバコンポーネントのアップデートが実行されます。
⑩ 次はDEM関連コンポーネントです。
⑪ DEMの次はProxy Agentがアップデートされます。
⑪ Proxy Agentのアップデートが続きます。検証環境はvCenter以外にHyper-VにもAgentをインストールしたため、Hyper-V用Proxy Agentのアップデートが実行されます。
⑫ 最後のステップはModel Manager関連コンポーネントのアップデートが実施されます。すべてのアップデートが完了し”Upgrade completed successfully”が表示されれば、めでたしめでたし♫ 😉
検証環境とはいえ、かかった時間は1時間ほどでした。
次からは7.4で色々紹介ができそうです。:)
大規模な環境や複数の拠点があり、それぞれにvSphereの環境があると運用が煩雑になります。それぞれの環境を管理するためにはそれぞれのvCenterに接続しなければならないからです。これを解消しようとしているのが”拡張リンクモード”です。
拡張リンクモードは、複数のvCenterを一つの管理UI(Web Client)で管理できるようにします。拡張リンクモードを構成するとPSC間でSSO情報はもちろんロールと権限、ポリシーなどが同期されます。
この拡張リンクモード、vCenter 5では”リンクモード”と呼ばれていました。このリンクモードがPSCとvCenterという構成に変わったvCenter 6からADAMに依存しなくなって、VCSAでも構成が可能な”拡張リンクモード”に改善されたわけです。
vCenter 6.5まではこの拡張リンクモードを構成するためには、PSCをEmbeddedではなく外部PSCとして構成する必要がありました。これはこれでややこしいのが、外部PSCはVCHAを構成できないことです。vCenterはVCHAを使えば簡単に可用性を確保できましたが、外部PSCは簡単には行かず、NSXや3rd Partyのロードバランサーに頼らざるを得ませんでした。
6.7からはEmbedded PSCでも拡張リンクモードを構成できるようになり、簡単に拡張リンクモードを構成できるようになっています。VCHAを構成するだけでPSCもvCenterも可用性を確保できます。
拡張リンクモードを構成するのは非常に簡単です。まず最初のVCSA(Embedded PSC)をデプロイします。(自分は以前マイグレーション＆アップグレードしたVCSA 6.7を使いました)
最初のVCSAが用意できたら、今度は2番目のVCSA(Embedded PSC)をデプロイします。ステージ2の[SSO設定]設定で[既存のSSOドメインの参加]を選択し、最初にデプロイしたVCSAを指定するだけです。
2番目VCSAのデプロイが完了し、どっちかのHTML5 Clientに接続してみるとインベントリには2つのvCenterが表示されます。この状態でSSOとしてActive Directoryを構成すると両方ともに同じADドメインアカウントで管理ができます。
先日、vSphere 6.5 Update 2がリリースされました。vCenter 6.5 U2はvCenter 6.7の機能がそのまま移植されていてEmbedded PSCでも拡張リンクモードが構成できるようになりました。
※ただし、現時点(2018年5月6日)ではvSphere 6.5 Update 2からvSphere 6.7へのアップグレードはサポートされませんのでご注意くださいな。
Nutanix AOSでサポートしているアフィニティルールが以下の2つがあります。
仮想マシンを特定のノード上でのみ稼働するように制限するポリシーです。このポリシーにより、仮想マシンは紐付いたノード上でしか稼働しません。
このポリシーは、Prismから仮想マシン単位で設定でき、設定したい仮想マシンの[Update]の[Set Affinity]から稼働を制限したいノードを選択するだけです。
1点、注意が必要なのは、このポリシーが設定された仮想マシンはVMHAやADS(Acroplois Dynamic Scheduling)の影響を受けません。ノードに障害が発生しても仮想マシンはフェールオーバーされませんし、ADSによるマイグレーションもされません。そのため、ノード障害によるフェイルオーバー先を考慮し2ノード以上で構成することを推奨しています。
このポリシーが設定されている仮想マシンをクローンした場合、ポリシーはクローンされませんが、DRなどでリストアした場合はポリシーが引き継がれます。
ちなみにこのポリシーを設定したあとにマイグレーションをしようと、アフィニティポリシーを設定したノードしか表示されません。
特定の仮想マシンを同じノード上で稼働しないようにします。このポリシーはPrismからは設定ができず、aCLIから設定する必要があります。
① Acropolis CLIを起動します。
② まず、VMグループを作成します。
③ 作成したVMグループに仮想マシンを追加します。
④ 作成したVMグループに仮想マシンを確認します。
⑤ 作成したVMグループに対してアンチーアフィニティルールをセットします。
ポリシー設定後、手動で仮想マシンをライブマイグレーションしてポリシーを違反しても、しばらくすると自動的にポリシーが適用されるようになります。 🙂
このポリシーは、VM-Host Affinity Policyとは違いADSやVMHAに影響を受けます。
ちなみに、このポリシーとは反対に特定の仮想マシンを同じノード上で稼働するVM-VM Affinity Policyは現在(AOS 5.7)サポートされません。
