[VMware] vRealize Automationの導入 (21)

 

(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であれば参照できます。

 

(21) Health Serviceの構成

 

① [管理]タブより[Health]を選択し、[NEW CONFIGURATION]をクリックします。

※このHealth Serviceは、複数vRAまたはvROを登録できるため、まずは健全性をチェックする環境のテストカード(プロファイルのようなもの)を作成します。

 

② ウィザードが表示されるので、以下のテストカードの概要を構成します。

  • Name:健全性チェックのテストカード名
  • Product:健全性をチェックするプロダクト(vRAかvROか選択可能)
  • Schedule:健全性チェックを実施するスケジュール

 

③ 健全性をチェックする項目を選択します。vRAを選択した場合は”システム”か”テナント”が選択できます。

 

④ 対象vRA環境の情報を入力します。

  • Public Web Server Address:vRAアプライアンスのURL
  • SSH Console Address:vRAアプライアンスのFQDN
  • SSH Console Password:vRAアプライアンスのrootパスワード
  • System Tenant Password:vRAデフォルトテナント(vsphere.local)のパスワード
  • Tenant Under Test:健全性チェックを実施するテナント
  • Fabric Administrator Username:健全性チェックを実施するテナントのファブリック管理者
  • Fabric Administrator Password:健全性チェックを実施するテナントのファブリック管理者パスワード

※入力が必要な項目だけ明記しています。

 

⑤ [Finish]をクリックして、テストカードの作成を完了します。

 

⑥ 作成したテストカードの[RUN]をクリックし、健全性チェックを実行します。環境の規模にもよると思いますが、小規模ですと1分程度でチェックが完了します。

 

⑦ 結果は、まず視覚的に分かりやすい円グラフで表示され、各色をクリックすると詳細が確認できます。

 

⑧ 詳細は健全性チェック結果をはじめ、失敗した場合はその原因と修正方法が参照できます。

※修正方法と言ってもクリックするとドキュメンテーションページに飛ぶだけですけどね。;)

 

⑨ 複数のvRA環境やテナント、vROまでテストカードが構成できるのですべての環境を1つの画面で直感的に健全性が分かります。

 

vRSLCMもそうですけど、テストカードの配置もできるようにしてほしいですね。:)

 

広告

[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] vCenter 6.7の拡張リンクモードについて

 

大規模な環境や複数の拠点があり、それぞれに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へのアップグレードはサポートされませんのでご注意くださいな。

 

 

[VMware] VCSAのバックアップとリストア

 

VCSA 6.5からVCSAの可用性を高める機能が2つ追加されました。”vCenter High Availability(VCHA)”と”ネイティブバックアップ”です。VCHAについては過去に紹介しましたので今回は”ネイティブバックアップ(ファイルベースバックアップ)”について紹介したいと思います。

 

VCSA 6.0まではファイルベースのバックアップやDB(vPostgres)のみのバックアップはサポートしていなかったため、VDPや3rd partyのバックアップソリューションを使い、VCSA丸ごとイメージバックアップを取る必要がありました。これがVCSA 6.5ではファイルベースのバックアップができ、簡単に必要なデータだけをバックアップできるようになりました。

さらにVCSA 6.7では、バックアップを定期的に実行できるようになり、管理者はバックアップの悩みから解放されました!  🙂

 

(1) VCSAのバックアップ

まず、手動でバックアップを実行してみます。

① VCSAの管理ページから[バックアップ]を選択、[今すぐバックアップ]をクリックします。

 

② 以下の情報を入力し、[起動]をクリックします。

  • バックアップの場所 : バックアップデータの保存先です。踏み台サーバにFTPを構築しました。FTP以外にHTTP、HTTPS、SCP、FTPSがサポートされています。
  • バックアップサーバの認証情報 :  バックアップデータの保存先認証情報
  • 暗号化バックアップ(オプション) : バックアップデータの暗号化パスワード
  • データ : バックアップするデータ(設定情報とインベントリ、イベント、タスクなどの履歴)

 

③ バックアップが実行されます。

 

④ バックアップタスクが完了したことが確認できれば終わりです。;)

 

⑤ バックアップサーバからもバックアップしたデータが確認できます。

 

(2) VCSAのリストア

今度はリストアをしてみます。リストアといってもVCSAそのものを復元するわけではありません。空のVCSAをデプロイして、そこのバックアップデータをコピーする流れになります。

 

① VCSAのインストールウィザードを起動し、[リストア]をクリックします。

 

② ステージ1の構成を開始します。

 

③ EULAに同意後、バックアップ情報を入力します。

  • 場所またはIPアドレス/ホスト名 : バックアップデータの絶対パス(backup-metadata.jsonが格納されているフォルダ)
  • ユーザ名 : バックアップサーバの認証アカウント
  • パスワード : バックアップサーバの認証アカウントのパスワード

 

④ 取得したバックアップデータの情報を確認し、[次へ]をクリックします。

 

⑤ ここからは空のVCSAのデプロイに必要な情報を入力します。ここはVCSAの新規デプロイと同じ手順なので割愛します。

 

⑥ ネットワークの情報は、バックアップデータからの情報が反映されますが、ネットワークポートグループだけは正しく指定する必要があります。

 

⑦ [完了]をクリックし、VCSAのデプロイを開始します。

 

⑧ HTML5 Clientからも新しいVCSAがデプロイされることを確認できます。

 

⑨ VCSAのデプロイが終わったら、続けてステージ2に進みましょう。

 

⑩ 再度バックアップサーバの認証情報を入力し、[次へ]をクリックします。

 

⑪ リストア対象のVCSAがまだ起動中であれば、停止し[終了]をクリックします。

 

⑫ リストアが開始されます。

 

⑬ VCSAのリストアが完了しました。

 

⑭ VCSAの管理ページにログインし、健全性に異常がないことを確認します。

 

⑮ HTML5 Clientに接続し、正常にリストアされたことを確認します。

 

(3) バックアップスケジュールの作成

VCSA 6.5には、このスケジューリング機能がありませんでした。なので一々手動で実行するか頑張って定期的に実行するスクリプトを組むしかありませんでしたが、VCSA 6.7では待望(?)のスケジューリングができるようになりました。

 

① バックアップスケジュールの[編集]をクリックします。

 

② 手動バックアップ実施の際に入力した情報に加え、”スケジュール”と”保持するバックアップの数”を設定し、[作成]をクリックします。ちなみにバックアップの”スケジュール”は日、週、曜日単位で設定ができます。

 

 

③ バックアップスケジュールが作成されたことを確認します。

 

もうvCenterのバックアップで悩む必要がありません。 🙂

 

 

[VMware] Windows版 vCenterからVCSAへの移行

 

先日vSphere 6.7がリリースされました。

Introducing VMware vSphere 6.7!

 

今回のバージョンはvCenter Serverでは特別なバージョンになります。というのも今回のバージョン6.7は、Windows版vCenterをサポートする最後のバージョンになるためです。正確にはサポートはするがWindows版vCenterは”非推奨”になったバージョンです。(この内容については以前に投稿しましたので、そちらをご確認くださいな)

 

ということはですよ、Windows版vCenterを利用している環境はいつかはVCSAに移行が必要ということになります。おそらく18ヶ月〜24ヶ月ぐらいでしょうか。もちろん6.5以下のバージョンを使い続ければしばらくはWindows版vCenterの延命にはなるかもしれませんが、vSphere環境を使い続けるのであればいつかはVCSAへの引っ越しが必要です。

特にvSphere 5.5を運用中の環境だと今年9月18日でgeneral Supportが終了するので結構(?)真剣にVCSAへのマイグレーションを検討しないとなりません。

 

自分の検証環境にもWindows版vCenterがありまして、6.7リリース記念(?)にVCSAに移行してみました。;)
ちなみにWindows版vCenter 6.0 U2からVCSA 6.7にアップグレードしつつ、移行を実施します。

 

では…

 

まずマイグレーションをするためには”事前チェック”を実施しておく必要があります。

 

① 移行元であるWindows版vCenterにVCSA 6.7のisoイメージをマウントし、ファイルの中から”migration-assistant\VMware-Migration-Assistant.exe”ファイルを実行します。

 

② migration assistantが起動したら、administrator@vsphere.localのパスワードを入力します。migration assistantが正常にvCenterに接続したら自動的に移行のための”事前チェック”が開始されます。”事前チェック”結果、移行の条件を満たし、プロンプトに”Waiting for migration to start…”が表示されたら準備完了です。

※このmigration assistantは移行が完了するまで閉じないようにします。

 

③ 今度は移行作業を実施する端末にVCSA 6.7のisoイメージをマウントし、”vcsa-ui-installer\win32\installer.exe”ファイルを実行します。インストールウィザードが表示されたら、「Migrate」をクリックします。

※VCSAのインストールウィザードは、Windows版vCenterでは実行しないでください。当たり前ですが移行中、Windows版vCenterは停止されるため、移行作業が続けられません。

 

④ 最初に話しましたとおり、”移行”も”新規インストール”と同じプロセスです。ステージ1でVCSAをデプロイし、ステージ2でVCSAを構成する流れになります。[NEXT]をクリックします。

 

⑤ EULAを同意します。

 

⑥ 移行元のWindows版vCenterの情報を入力し、[NEXT]をクリックします。

 

⑦ 信頼されてないvCenterの自己証明書を受け入れます。

 

⑧ migration assistant上ではネットワークの構成が確認されます。

 

⑨ VCSAのデプロイ先の情報を入力し、[NEXT]をクリックします。

 

⑩ 自己証明書の警告を受け入れます。

 

⑪ VCSAをデプロイするデータセンターを選択し、[NEXT]をクリックします。

 

⑫ VCSAをデプロイするクラスタを選択し、[NEXT]をクリックします。

 

⑬ デプロイするVCSAの名前、rootのパスワードを設定し、[NEXT]をクリックします。

 

⑭ VCSAのサイズを決めます。

 

⑮ VCSAをデプロイするデータストアを選択し、[NEXT]をクリックします。

 

⑯ 移行に必要なテンポラリなネットワークを設定し、[NEXT]をクリックします。

 

⑰ 設定内容を確認し、問題なければ、[FINISH]をクリックします。

 

⑱ ステージ1が開始され、VCSAが新たにデプロイされます。

 

⑲ ステージ1が完了し、VCSAがデプロイされました。ここでステージ2に進むか、あとで進めるかはアナタシダイデス ことができます。ここではそのまま進めましょう。:)

※ステージ1が終わっても移行元Windows版vCenterに影響はありません。ただここで一旦移行作業を中止するのであれば、再開する時には手順①のmigration assistantを再度実行する必要があります。

 

⑳ ステージ2のウィザードを開始します。

 

㉑ ステージ2のウィザードを開始すると”事前チェック”を再度実行され、ネットワーク構成を再度確認するとともにmigration assistantのログがVCSAにコピーされます。

 

㉒ Active Directoryの情報を入力します。移行元Windows版vCenterがADドメインに参加していたため、新規VCSAもADドメインに参加させます。

 

㉓ 移行するデータを決めます。なおここでは移行によるダウンタイムが確認できます。

  • Configuration : 構成情報のみ移行します。
  • Configuration and historical data (events and tasks) : 構成情報、イベント、タスクの履歴も移行します。
  • Configuration and historical data (events, tasks and performance metrics) : 構成情報、イベント、タスク、パフォーマンスメトリックの履歴も移行します。

更に選択したデータは、VCSAのスタートを優先するのかデータインポートを優先するか選択できます。

せっかくなので、すべてのデータインポートを優先するように選択しました。40分ぐらいダウンタイムが発生しますね。 😉

 

㉔ CEIPは選択しませんでした。

 

㉕ 移行元/移行先のバージョン、移行するデータ量を確認します。内容に間違いがなければ、データベースをバックアップ後[FINISH]をクリックします。

 

㉖ ここで警告が表示されます。[OK]をクリックすると、移行元Windows版vCenterがシャットダウンされます。[OK]をクリックします。

 

㉗ 移行が開始されます。

 

㉘ migration assistantからもデータの移行が開始されたことが確認できます。

※データ移行が完了すると、自動的にシャットダウンされます。

 

㉙ データの移行が終わり、Windows版vCenterが停止されました。くれぐれも間違って起動しないようにしてくださいな。 🙂

 

㉚ マイグレーションは手順㉓で表示されてた時間より早く30分ほどで完了しました。

 

㉛ VCSAに移行されたので、仮想アプライアンス管理ページにもアクセスできます。ログインして健全性を確認します。VCSA 6.7からはGUIで各サービスを起動/停止できる[サービス]が追加されています。楽ですね。

 

㉜ HTML5 Clientにもアクセスしてみます。問題なくデータセンター、クラスタ、ホストなどのオブジェクトの情報が表示されることを確認します。ちなみにvSANも操作できるようになっています。;)

 

意外と簡単に終わります。かかった時間はほぼ移行ウィザードで表示された時間とおりでした。
移行後、一通り動作を確認してみましたが問題なく移行されていました。

長くWindows版vCenterを運用してきた管理者(特にLinux運用にあまり慣れてない)としては、急にハードルが上がったように思えるかもしれませんが、そんなことありません。基本、VCSAをコンソールやSSHでイジることはありませんし、Windows版vCenterでもvCenter関連サービスは”services.msc”ではなく、”service-control”コマンドを使うようになるなど、6.0あたりからWindows版vCenterとVCSAの運用の境界は大分なくなっています。しかもVCHAやネイティブバックアップなど新しい機能がVCSAのみ提供されていて、移行しない理由が見つかりません。

 

Windows版vCenterを運用中の管理者はそろそろVCSAへの移行を検討した方が良いかと思います。

 

あと、マイグレーション前にはバックアップをお忘れなく! 🙂

 

 

 

 

 

 

[VMware] vSAN 6.7 リリース

 

昨日、vSphere 6.7がリリースされました。合わせてvSANもバージョン6.7がリリースされました。 😉

簡単に新しく追加または改善されました機能をまとめますと…

  • vSANの操作のHTML5 Client対応。新しい機能はこのHTML5 Clientでのみ操作可能です。
  • vROpsのプラグインが統合。これでHTML5 Client上でvSphereはもちろんvSANのモニタリングが可能になりました。
  • iSCSIサービスがWSFCをサポート。Failover Clusterの共有ディスクとしてvSANを利用できるようになります。
  • 再同期のパフォーマンスが向上。再同期帯域として、最低20%を保証すると共に再同期トラフィックない場合はVMへのIOに帯域を100%利用するように動的に調整するとのことです。
  • VM swapのシンプロビジョニング。デフォルトでVM swapフィ要るはシンプロビジョニングで作成されるようになりました。
  • vSANネットワークの冗長機能の改善。マルチvsan vmkernelを構成した場合、即時でネットワークのフェールオーバーが行われます。
  • Proxy Owner。拡張クラスタのPrimary-Secondary間レプリカの部分的同期を行い、残りのデータはProxy Ownerによってローカルコピーを行い、ネットワークのトラフィックを最小限に抑えられるとのことです。
  • 健全性チェック項目の追加および新しいesxcliコマンド追加。
  • USB/SDカードのコアダンプパーティションの動的拡張が可能になり、コアダンプとログを恒久的に保存可能。
  • 4Kデバイスのサポート。
  • アメリカ国立標準技術研究所(NIST)の暗号モジュールに関するセキュリティ要件(FIPS 140-2)に準拠。
  • アプリケーションレベルで同期しているVMとそのデータを同じESXiホストにおけるHost Pinning。

 

詳細な内容とバグフィックス情報はリリースノートをご参照ください。

 

[VMware] VMware構成の上限確認サイト

 

なんか、こういうサイトが公開されましたね。

VMware Configuration Maximums

 

要はVMwareプロダクトの構成の制限を確認、バージョン間で確認できるサイトです。

 

まだ対応しているプロダクトはvSphereのみでバージョンも6.0以降なので”これから〜”という感じではありますが、バージョン別の上限比較は中々良い機能かもしれません。

 

バージョンを選択して簡単に機能と上限値が確認できます。

 

提案や設計で活用できそうです。 🙂