[VMware] vRealize Automation 7.4 へのアップデート

 

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まではなかったタブが追加されていることが分かります。

  • Orchestrator : vROのサービス、Control Centerのサービスを有効/無効にできます。
  • SW Agent : SW Agentの管理ができます。
  • Patches : vRA関連のパッチの適用ができます。ここだけなぜかHTML 5です。 🙂

 

⑥ 事前インストールが完了すると続けて事後インストールが開始されます。

 

⑦ 事後インストール途中で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で色々紹介ができそうです。:)

 

広告

[VMware] vSANアップグレードガイド

先日vSphere 6.5 Update 1のリリースと同時にvSANの6.6.1に若干(!)バージョンが上がりました。

vSAN 6.6.1は、まあ〜マイナーバージョンアップ(しかも0.0.1)ですので”バグ修正版”かと思いきや新しいライセンス体系や機能改善がしっかりと含まれていました。

  • vSphere Update Managerとの統合:VUMを利用しvSAN関連パッチを適用できるようなりました。
  • vSANパフォーマンス診断機能改善:バージョン6.6でCEIPを通じてvSANクラスタのヘルス状態や情報をVMware社に転送できるようになりまたが、6.6.1ではその情報を基にディスクのスループットやレイテンシーなどのベンチマーキングが可能になりました。
  • ストレージデバイスのメンテナンス改善:vSANで使用しているディスク以外のストレージデバイスに関してもvCenterよりLEDを点滅させることができます。w
  • 新しいライセンス体系の追加:”vSAN Enterprise for ROBO”エディションでも”暗号化”と”拡張クラスタ”が構成できるようになります。また”Horizon Advanced”や”Horizon Enterprise”に”vSAN Advanced”エディションが含まれるようになりました。

 

で、数日前に今度は”vSANアップグレードガイド”が公開されました。

正確には古いバージョンのvSAN(vSAN 6.6を含む)から6.6.1にアップグレードする際に考慮すべき以下の内容で構成されています。

  • vSANアップグレード時のディスクフォーマットバージョンとバージョンアッププロセス
  • ネットワーキング(6.6以前のマルチキャストからユニキャストへの変更に伴う考慮点)

上記以外にアップグレードには必須であるvCenterのアップグレード方法やvSANアップグレード時のトラブルシューティングの内容も含まれています。

 

1世代のVirtual SAN 5.5のリリースから4年が過ぎました。5.5を含む古いバージョンを導入している方の中ではバージョンアップを検討される方もいるんじゃないでしょうか。アップグレードを検討している方は是非お読みください。

 

[Nutanix] 4.6 CEを 5.0 CEにアップグレード

2016年12月23日、遂にAOS 5.0のGAがリリースされましたね。

メジャーバージョンアップということで45以上の新しい機能が追加されたとのことしたが、これらの機能はもちろんCommunity Editionでも全て検証ができます。

ということで、自分の検証環境である4.6を5.0にアップグレードすることにしました。

(5.0のCEも2017年1月3日、リリースされましたー)

 

upgrade-00upgrade-15

まずは、ここから最新のCEのアップグレードファイルをダウンロードします。

upgrade-03

それではCVMからアップグレードをします。管理メニューより[Upgrade Software] → [Acropolis] タブよりダウンロードしたメタデータファイル”ce-2016.12.22-metadata.json”とバイナリファイル”nutanix_installer_package.tar.gz”をアップロードします。

upgrade-10

アップロード後は、[Upgrade Now]をクリック、アップグレードを実施します。[Upgrade Now]でも一応[Pre-Upgrade]が走るので問題ありませんが、気になる方はアップグレード前に[Pre-Upgrade]を実施してみてください。

upgrade-13

アップグレードが完了し、Acropolisのバージョンが上がりました。CVMからも最新のバージョンにアップグレードされたことが確認できます。

upgrade-21

今度は、CVMと同様、ダウンロードした”host-bundle-e7l.nutanix.20161118.100427-metadata.json”と”host-bundle-e7l.nutanix.20161118.100427.tag.gz”をアップロードし、Acropolisハイパーバイザーをアップグレードします。

upgrade-23

アップグレードが完了し、Acropolisのバージョンが上がりました。

アップグレードの対象は、Nestedの3ノードでした。アップグレードにかかった時間は、CVMとAcropolisハイパーバイザー合わせておよそ40分ほどかかりました。

バージョンも上がったことだし、色々試してみたいと思います。

[VMware] VSANのアップグレード時の注意点

12月7日、VSANアップグレードに関して気になるKBが公開されました。

VSANを構成しているESXiノードを5.5から6.0にアップグレードの際に、VSANデータがロストする恐れがあるとのことです。具体的には以下のような条件が揃った場合、発生するとのことです。

  • ESXi 5.5、6.0が混在してるVSANクラスタの場合
  • ESXi 5.5、6.0が混在してるVSANクラスタでオブジェクトの再構成された場合
  • 再構成されたオブジェクトのコンポーネントが格納されている複数のESXi 5.5が6.0にアップグレードされる前に再起動した場合

今のところ、事象の解決策はないため、VMware社では有効な解決方法が公開されるまでVSANノードのESXi 5.5から6.0へのアップグレードは行わないよう強く推奨しています。

が、どうしてもVSANのアップグレードが必要な場合のワークアラウンドも提示されています。

  • 仮想マシンをVSAN以外のストレージにStorage vMotionしてから実施
  • VSANクラスタ内のすべてのESXiノードのディスク空き容量を20%(ディスク使用率が80%を超えると自動的にオブジェクトの再構成が実施されるため)以上確保
  • ESXiノードアップグレード時、Storage Policyなどのオブジェクト再構成が必要な操作を行わない
  • ESXiノードアップグレード時、アップグレードプロセスで必要な再起動以外のESXi 5.5の再起動はしない(障害発生時でも含む)

 

詳細な内容はここをご確認ください。

まあ、VSANをアップグレードはマッテ!ということですな。。。 🙂