[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への移行を検討した方が良いかと思います。

 

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

 

 

 

 

 

 

広告

[Nutanix] Acropolis File Services(AFS)について-③

 

今回はAFSの共有フォルダで利用できる次の機能について紹介したいと思います。

  • ABE (アクセスベースの列挙)
  • SSR (セルフサービスリストア)

 

これらの機能はファイルサーバサービスを提供するためには必須不可欠な機能です。てか、じゃないと管理者は地獄を見ることになります。 🙂

この機能を利用するためには、共有フォルダ作成時、機能を有効にするだけです。簡単です。ただし、実際に使うためには別途作業が必要です。

 

ABE(Access Based Enumeration)

ご存知のとおり、この機能はアクセス権がないファイル/フォルダは見せないというものです。なので設定方法は一般的な(?) ABE設定と同じです。;)

フォルダの”セキュリティの詳細設定”で許可するユーザまたはグループを追加、他はアクセス許可から削除するだけです。

 

ABEが正常に設定されると権限のないユーザは見えません(左)が、権限のあるユーザにはきちんと”Human Resources”というフォルダが見えます(右)。 当たり前なことを偉そうに言ってしまいましたね。汗

 

SSR(Self Service Restore)

SSRもご存知の通り、管理者を介さず、ユーザ自身がバックアップから必要なデータを復旧する機能です。ただこのSSRは、仮想マシンにNGTをインストールして利用できるSSRではありませんのでご注意を… 🙂

 

AFS構成ウィザードの最後にProtection Domain名を設定したことを覚えてますでしょうか?AFSを構成すると自動的にバックアップジョブも作成されます。それは作成したファイルサーバの[Protect]から確認できます。

[Protect]をクリックすると、”時間”、”日”、”週”、”月”単位で既にスケージュルが組まれています。このスケジュールは必要に応じて変更できますが、変更はここの[Protect]から行います。Protection Domainからはこのスケジュールは表示されません。

 

バックアップジョブは自動的に実施されます。SSRを有効にした共有フォルダのプロパティを開き、[以前のバージョン]タブを確認するとちゃんとバックアップ(スナップショット)を取れていることが確認できます。試しにスナップショットのデータを一つ開いてみます。

 

スナップショットが作成された日時が確認でき、簡単に必要なデータを復元することができます。

 

ここまでがAFSによるファイルサーバサービス構成についての紹介でした。

 

[VMware] vRealize Automationの導入 (14)

 

(0) vRAの概要
(1) vRAのコンポーネント
(2) vRAのインストール
(3) テナント作成
(4) Active Directoryの追加
(5) エンドポイントの作成
(6) ファブリックグループの作成
(7) マシンプリフィックス/ネットワークプロファイルの作成
(8) ビジネスグループの作成
(9) 予約/予約ポリシーの作成
(10)ブループリント作成
(11)サービスカタログの作成
(12)ブループリントのリクエスト
(13)承認ポリシーの作成
(14)カスタムプロパティの作成

 

今回は”カスタムプロパティ”について紹介します。

カスタムプロパティとはサービスや仮想マシンをプロビジョニングする際に指定てきるパラメータのことです。なので管理者が任意で定義が可能で、その定義に対してユーザが入力したりシステム側で別の値で上書きしたりすることができます。

このカスタムプロパティを利用するためには、まず”プロパティディクショナリ”から”プロパティ”を定義します。定義したプロパティを個別にブループリントやビジネスグループなどのソース(レベル)に指定することもグループ化することも可能です。

 

ブループリントに指定されたプロパティは、既存設定を上書きできます。例えばブループリントでは、プロビジョニングする仮想マシン名をマシンプリフィックスから自動的に割り当てれるように設定されたとしても、ユーザに仮想マシン名を入力するようなプロパティで上書きすることができます。

 

カスタムプロパティは複数ソース(レベル)で指定が可能で、もし複数のレベルに渡り同じカスタムプロパティが指定されている場合は、下図のような順番で適用されます。

 

(14)カスタムプロパティの作成

※ここでは、ユーザに”ホスト名”を入力させ、ネットワークもプルダウンメニューから選ばせるようにカスタムプロパティとWeb Clientにビジネスグループ単位のフォルダを作成、仮想マシンを配置するカスタムプロパティを定義してみます。

 

① テナント管理者としてポータルにログインし、[管理] → [プロパティディクショナリ]をクリックします。

 

② [プロパティ定義]を選択し、[新規]をクリックします。

 

③ まず”ホスト名”のカスタムプロパティを作成しましょう。定義するプロパティはVMware社で公開ししているカスタムプロパティのレファレンスを利用します。(英語版は2017年12月に更新されています)

  • 名前 : Hostname ※ここはカスタムプロパティ名を正確に指定します。
  • ラベル : ユーザに表示されるラベル名
  • データタイプ : 文字列
  • 必須 : はい
  • 選択方法 : テキストボックス

上記の項目の他にはオプションで、定義するカスタムプロパティをすべてのテナントで共有するのか、ブループリントでの表示順序は何番目にするのかなども決められます。一先ず必須項目を指定したら[OK]をクリックします。

 

④ 今度はネットワークを選択できるカスタムプロパティを作成しましょう。もう一度[新規]をクリックします。

 

⑤ 今回の必要項目のみ指定します。

  • 名前 : VirtualMachine.Network0.Name ※ここはカスタムプロパティ名を正確に指定します。
  • ラベル : ユーザに表示されるラベル名
  • データタイプ : 文字列
  • 必須 : はい
  • 選択方法 : ドロップダウン
  • 値 : 事前定義
    • 名前 : ドロップダウンに表示するネットワーク名
    • 値 : 仮想マシンの割り当てるポートグループ名  ※Web ClientのNetworkからコピーしてくださいね。

[OK]をクリックし、カスタムプロパティを作成します。

 

⑥ 作成した2つのカスタムプロパティをグループ化してみます。[プロパティグループ]を選択し、[新規]をクリックします。

 

⑦ 以下の情報を設定し、[OK]をクリックします。

  • 名前 : プロパティグループ名
  • ID : 自動的に入力されます。
  • プロパティ : 作成したカスタムプロパティを追加します。また[申請に表示]にチェックを入れ、ユーザがブループリントをリクエストする際にカスタムプロパティが表示されるようにします。

 

⑧ プロパティグループが作成されました。

 

⑨ それではブループリントに作成したプロパティグループを指定します。[設計] → [ブループリント]からプロパティグループを指定するブループリントの[編集]をクリックします。

 

⑩ まず、既存のネットワークオブジェクトを削除しましょう。削除する理由はカスタムプロパティにて仮想マシンがプロビジョニングされる時に割り当てられるためです。

 

⑪ 続いて仮想マシンのオブジェクトを選択し、[プロパティ] → [プロパティグループ]から[追加]をクリックします。

 

⑫ 手順⑦で作成したプロパティグループを選択します。

 

⑬ プロパティグループ追加後、[マージされたプロパティ]をクリックすると指定されたカスタムプロパティの内容が確認できます。

 

⑭ [完了]をクリックし、ブループリントの編集を終了します。

 

⑮ 動きを確認しましょう。プロパティグループを指定したブループリントから仮想マシンをリクエストしてみます。ちゃんと”マシン名”と”利用ネットワーク”が選べられるようになっています。

 

⑯ プロビジョニングされた仮想マシンを確認してもちゃんとユーザが入力したホスト名と選択したネットワークが割り当てられていることが分かります。

 

⑰ では、今度は仮想マシンの配置フォルダを決めるカスタムプロパティを設定します。ここではビジネスグループ毎にフォルダを作成し、その配下に仮想マシンを配置するようにします。[管理] → [ユーザおよびグループ]を選択します。

 

※基本的にvSphere エンドポイントにプロビジョニングされる仮想マシンはすべてWeb Clientの”VRM”というフォルダ配下に配置されます。これだとテナントやビジネスグループが複数ある場合、管理しづらくなります。なので配置フォルダを決めるカスタムプロパティを設定し、フォルダ分けした方が管理しやすいと思います。

 

⑱ [ビジネスグループ]を選択し、カスタムプロパティを設定するビジネスグループの[編集]をクリックします。

 

⑲ [全般]タブのカスタムプロパティから以下の情報を入力し、[OK]をクリックします。

  • 名前 : VMware.VirtualCenter.Folder
  • 値 : 配置するフォルダ名 例)VRM/Kiiro <-仮想マシンはKiiroというフォルダに配置されます。

 

⑳ [完了]をクリックし、ビジネスグループの編集を終了します。これでDevGrp-01というビジネスグループユーザのリクエストでプロビジョニングされる仮想マシンはKiiroというフォルダの配下に配置されます。

 

㉑ 仮想マシンをプロビジョニングすると”VRM\Kiiro”フォルダ配下に仮想マシンが配置されることが確認できます。

 

ここまでがカスタムプロパティを作成し、指定する手順は終わりです。vRAで利用可能なカスタムプロパティは機能別、アルファベット別にグループ化されています。このカスタムプロパティを利用すると、より柔軟なブループリントを作成できると思います。

 

次回はvRO(vRealize Orchestrator)のエンドポイント作成について紹介したいと思います。

 

[VMware] vRealize Automationの導入 (13)

 

(0) vRAの概要
(1) vRAのコンポーネント
(2) vRAのインストール
(3) テナント作成
(4) Active Directoryの追加
(5) エンドポイントの作成
(6) ファブリックグループの作成
(7) マシンプリフィックス/ネットワークプロファイルの作成
(8) ビジネスグループの作成
(9) 予約/予約ポリシーの作成
(10)ブループリント作成
(11)サービスカタログの作成
(12)ブループリントのリクエスト
(13)承認ポリシーの作成

 

さて、去年(!)まででユーザがブループリントをリクエストし仮想マシンがプロビジョニングできました。その際、ブループリントをリクエストしても特にプロセスが止まらず進んだかと思います。それは承認ポリシーが適用されていないためでした。

 

承認ポリシーは管理者がユーザのブループリントリクエストに対してリソースの利用を許可するかしないかを決めるプロセスになります。正直なところ、この承認ポリシーはなくてもvRAインフラを運用するのに何の問題もありません。むしろ管理者(または承認管理者)は一々、ユーザのリクエストに対して承認/却下をしないとならないので面倒かもしれません。:)  承認ポリシーが必要なシーンとしてはライセンス関連でのコスト管理やインフラに影響を及ぼすアイテムやアクションを提供する場合か、きっちりとインフラ管理部門がコントロールしたい場合などが考えられます。

 

承認ポリシーは”資格”と紐付きます。なので承認ポリシーは”サービスカタログ”、”アイテム”、”アクション”に対して適用が可能です。

承認ポリシーは”事前承認ポリシー”と”事後承認ポリシー”があります。

  • 事前承認ポリシー : 承認されない限りアイテムはプロビジョニングされません
  • 事後承認ポリシー : プロビジョニングはされますが、承認されない限りユーザに渡りません

 

※今回はマシンブループリントで仮想マシンをプロビジョニングする場合に承認ポリシーを利用する手順を紹介します。

 

(13)承認ポリシーの作成

① [管理] → [承認ポリシー]を選択し、[新規]をクリックします。

 

② 新規承認ポリシーとして”承認ポリシーのタイプを選択”を選択、対象タイプでは”サービスカタログ – カタログアイテム申請”を選び、[OK]をクリックします。

 

③ 承認ポリシーの名前とステータスを設定します。[事前承認]タブを選択し、承認レベルの追加をクリックします。

 

④ 承認レベル名と承認条件、そして承認者を設定し、[OK]をクリックします。[システムプロパティ]と[カスタムプロパティ]タブは特に設定しなくても大丈夫です。

※承認ポリシーはマルチレベルの承認ポリシー構成も可能です。が、今回は1回のみにします。

 

⑤ 事前承認のレベルが設定されたことを確認し、[OK]をクリックします。

 

⑥ 承認ポリシーが作成されたことを確認します。ちなみに手順①〜⑤を繰り返し、”事後承認ポリシー”も作りました。 🙂

 

⑦ 次は作成した承認ポリシーを紐付けます。[管理] → [カタログ管理] → [資格]順に選択し、承認ポリシーを提供する資格の[編集]をクリックします。

 

⑧ [アイテムおよび承認]タブからアイテムの[ポリシーの変更]で承認ポリシーを指定します。

 

⑨ ここでは作成した承認ポリシー2つをそれぞれ”CentOS 7-Minimum”と”Linux-Generic”に設定しました。承認ポリシーの指定が終わりましたら[完了]をクリックします。これで完了です。

 

⑩ では、動きを見てみましょう。ビジネスグループユーザでログインし、[カタログ]を選択します。承認ポリシーを指定したアイテム、2つをリクエストしました。

 

⑪ アイテムのリクエスト後、[申請]タブを確認すると、”事後承認ポリシー”を適用したアイテムは”処理中”で”事前承認ポリシー”を適用したアイテムは”承認待ち”であることが分かります。

 

⑫ 今度はテナント管理者としてログインします。[受信箱] → [承認]を選択すると手順⑪で”承認待ち”状態の申請ID ‘9’が追加されていることが分かります。[詳細表示]をクリックします。

 

⑬ 承認理由を入力し、[承認]か[却下]をクリックします。この承認ポリシーは[承認]をクリックします。

 

⑭ [申請]タブを確認すると、今度は”処理中”にステータスが変わっています。

※ちなみにテナント管理者やビジネスグループマネージャーは画面右上の[送信者]からビジネスグループユーザの申請内容も確認できます。

 

⑮ vSphere Web Clientから確認してみるとちゃんと2つの仮想マシンがプロビジョニングされています。

 

⑯ 再びテナント管理者のポータルを確認すると、今度は”事後承認ポリシー”を適用したアイテムのステータスが”承認待ち”になっていることが分かります。Web Clientで確認した時にはきちんと仮想マシンが作成されていましたが、事後承認ポリシーを指定したことによりユーザにはまだ渡されてない状態です。

 

⑰ これは[却下]をクリックしてみましょう。

 

⑱ するとステータスは”却下済み”に変わります。却下されたら、既にプロビジョニングされた仮想マシンはどうなるんでしょうかね?

 

⑲ はい。予想通り削除されます。 🙂

⑳ アイテムをリクエストしたユーザでログインして確認してみてもプロビジョニングされた仮想マシンは1つだけでした。

 

せっかくプロビジョニングしたのに、承認ポリシーで削除するのは無駄な気がしませんか? なので事後承認ポリシーを提供する場合はちゃんと考えましょう。:)

 

ここまでが承認ポリシーを作成し適用する手順でした。

次回はカスタムプロパティを作成し、ブループリントに適用する手順を紹介します。

 

 

[VMware] vRealize Automationの導入 (16)

 

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

 

(0) vRAの概要
(1) vRAのコンポーネント
(2) vRAのインストール
(3) テナント作成
(4) Active Directoryの追加
(5) エンドポイントの作成
(6) ファブリックグループの作成
(7) マシンプリフィックス/ネットワークプロファイルの作成
(8) ビジネスグループの作成
(9) 予約/予約ポリシーの作成
(10)ブループリントの作成 — 公開予定
(11)サービスカタログの作成 — 公開予定
(12)ブループリントのリクエスト — 公開予定
(13)承認ポリシーの設定 — 公開予定
(14)カスタムプロパティの設定 — 公開予定
(15)vROエンドポイントの作成 — 公開予定
(16)イベントブローカーの設定(Advent Calendar参加のため、先に公開します)
(17)NSXとの統合 — 公開予定
(18)仮想マシンのインポート — 公開予定
(19)仮想マシンの解除 — 公開予定
(20)Nutanixエンドポイントの作成 — 公開予定
(21)vROpsとの統合 — 公開予定

 

(16)イベントブローカーの設定

 

今回はvRA 7.0から新しくなった”イベントブローカー(Event Broker、ライフサイクルの拡張性=Life Cycle Extensibilityともいう)”について紹介しようと思います。

 

“イベントブローカー”は6.xまで利用されていたWorkflow Stubに代わり、今後仮想マシンのライフサイクルを管理する方法です。

“イベントブローカー”を簡単にまとめると、ユーザのリクエストによりプロビジョニングされる(された)仮想マシンのライフサイクルに対してvROを連動させることになります。

この”イベントブローカー”を活用することで単なる仮想マシンのプロビジョニングやユーザ任せではなくより柔軟なサービスが提供できるようになります。

例えば…

  • 仮想マシンがプロビジョニングされたあとにDNSサーバにレコードを作成し、仮想マシンが削除されたらそのレコードを削除する
  • 特定のブループリントから仮想マシンがプロビジョニングされたら特定アプリケーションをインストールし、仮想マシンのリース期間が満了しらそのアプリケーションを削除する
  • 特定の仮想マシンを再起動する前にバックアップやスナップショットを作成する

などといった、より自動化に近いレベルになります。

 

この”イベントブローカー”を実現するためには、”イベントサブスクリプション”を利用します。
イベントサブスクリプションとは、vRAのイベントをトリガーにvROのワークフローを実行する定義です。定義というと難しそうに聞こえますが要は、あるイベントが発生したらvROのワークフローを実行するということです。 🙂

イベントサブスクリプションを作成するため、まず”イベントトピック”を指定します。”イベントトピック”は発生するイベントのことです。vRA 7.3では約20個のイベントを用意されていて下記のイベントが代表的なイベントトピックと言えます。

  • Machine lifecycle
  • Machine provisioning

 

各イベントトピックは複数のスキーマ(プロパティ)で構成されています。このプロパティを必要に応じて条件として組み立てます。あとはいつの段階でトリガーとしてvROのワークフローに渡すのかを決めたらとイベントサブスクリプションの作成が終わります。

 

“WinSvr”という名前のブループリントからデプロイされる仮想マシンはデプロイ後、DNSサーバにレコードを追加するvROワークフローを実行する作業を例としてみてみると下図のようなイメージです。

 

それでは簡単に手順を紹介します。

※このイベントブローカー機能を利用する場合は、vROが必要でエンドポイントとして作成されていること、そしてサブスクリプションで実行するvROのワークフローが作成されている必要があります。

 

① [管理]から[イベント]をクリックします。

 

② [サブスクリプション]を選択し、[新規]をクリックします。

 

③ まず[イベントトピック]からサブスクリプションで利用するイベントトピックを選びます。利用可能なイベントトピックの種類についてはここをご確認ください。この例では仮想マシンのデプロイ後DNSサーバにAレコードを登録する方法を紹介したいので、”マシンプロビジョニング”を選びました。イベントトピックを選択し、[次へ]をクリックします。

 

④ [条件]タブでは以下の条件を指定しました。

  • ブループリント名にLinuxという文字が含まれている。
  • ライフサイクルイベントが仮想マシンのプロビジョニグ(VMPSMasterWorkflow32.BuildingMachine)
  • ライフサイクルの段階はプロビジョニングのあと(POST)

上記の3つの条件をすべて満たした場合が条件です。

 

⑤ [ワークフロー]タブを選択し、手順④の条件を満たした時に実行するvROのワークフローを選択します。

※入力パラメータとして”payload”となっています。このpayloadはイベントトピックで生成されたスキーム(プロパティ)をvROに渡すプロパティです。イベントブローカーを使う場合は、これがほぼ100%必要になります。vROのワークフローの最初にこのpayloadを実装しないとワークフローは動作しません。

 

⑥ [詳細]タブで必要な情報を入力し、[完了]をクリックします。

  • 名前 : 作成するサブスクリプション名です。分かりやすいものにしましょう。
  • 優先順位 : 複数のサブスクリプションが存在する場合の実行順番です。
  • タイムアウト : ワークフローの実行タイムアウト値です。何らかの理由でワークフローの実行が完了せずこのタイムアウト値に達した場合、サブスクリプションの実行は失敗します。
  • ブロック : 複数のサブスクリプションを順に実行するようにします。このブロックを有効にしないと”優先順位”と”タイムアウト”は活性化されません。

 

※”ブロッキング”について少し補足です。サブスクリプションはその実行に対して”ブロッキング”と”ノンブロッキング”を指定します。単一イベントトピックに複数のサブスクリプションが存在する場合、各サブスクリプションは同時に実行されます。これを防ぐため、各サブスクリプションには”ブロッキング”を設定、優先順位を決めるわけです。”ノンブロッキング”は”ブロッキング”を指定したサブスクリプションが実行されたあと、またはタイムアウトで失敗した場合実行されます。

 

⑦ 作成したサブスクリプションは、ブループリント同様”ドラフト”状態のため、[公開]をクリックします。

 

⑧ 公開されたらサブスクリプションの作成は完了です。

 

⑨ 次へブループリントの[カスタムプロパティ]にサブスクリプションに渡すライフサイクルイベント用のカスタムプロパティを追加します。ここでは以下のプロパティと値をしてしました。

  • プロパティ名 : Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.BuildingMachine
  • 値 : __*,*

 

この設定によって、仮想マシンがプロビジョニングされた時の各種プロパティがサブスクリプションに渡ることになります。ちないに値の__*,*(アンダースコアアンダースコア*,*)ですが__*は非表示(hidden)値を、*は表示値のすべてを渡すとことになります。

 

これで準備完了です。

 

⑩ では、ちゃんと動作するのか確認してみます。名前がLinux6のブループリントで仮想マシンをプロビジョニングしてみます。

 

⑪ 無事リクエストが処理されています。

 

⑫ vSphere Web Clientを見てみます。”LX-VM-018″という仮想マシンがプロビジョニングされていてIPアドレスは”192.168.205.153″がネットワークプロファイルより割り当てられました。

 

⑬ 仮想マシンのプロビジョニングが完了し、”Add DNS-Host”というワークフローが正常に完了したことが確認できます。この”Add DNS-Host”は手順⑤で指定したvROのワークフローです。

 

⑭ DNSサーバを見てみるとちゃんと”LX-VM-018″が”192.168.205.153″で登録されていることが確認できます。

 

⑮ 今度はvROを覗いてみましょう。ワークフローが正常に完了したことが分かります。その際に仮想マシン名とIPアドレスがちゃんとvRAから受け渡ったことも確認できます。

 

これでイベントブローカーの利用手順は終わりです。次回からは順番とおりに紹介していきます。

 

 

[VMware] vRealize Automationの導入 (6)

 

(0) vRAの概要
(1) vRAのコンポーネント
(2) vRAのインストール
(3) テナント作成
(4) Active Directoryの追加
(5) エンドポイントの作成
(6) ファブリックグループの作成

 

前回までの構成を図で表すとこんな状態になります。

 

この状態からファブリックグループを作成し、利用可能なリソースを割り当てることになります。

 

ファブリック(fabric)は、簡単に言うと前回作成したエンドポイントによって収集されるすべてのコンピュートリソースのことです。このファブリックを”ファブリック管理者”が特定グループ(ここではビジネスグループ)が利用できるよう定義(グループ化)したのが「ファブリックグループ」です。

 

ファブリックグループは大きく4つがあります。

  • コンピュートリソース
  • マシンプリフィックス
  • ネットワークプロファイル
  • 予約と予約ポリシー

 

「コンピュートリソース」は、このブログの例だと”リソースとして利用可能なvSphere クラスタ”になります。「マシンプリフィックス」、「ネットワークプロファイル」、「予約と予約ポリシー」は次回紹介することとし、今回はファブリックグループの作成とエンドポイントよりデータを収集する手順について紹介します。

 

(6) ファブリックグループの作成

の前に一つやっておきたいことがあります。

vRAは今まで登場した”テナント管理者”や”IaaS管理者”、”ファブリック管理者”以外に、いくつものロールが存在します。このロールは主にサービスを提供または提供を準備する機能毎に分かれています。例えばマシンブループリントを作成するためには”インフラストラクチャアーキテクト”というロールが必要ですし、XaaSブループリントをを作成するためには”XaaSアーキテクト”というロールが必要です。このロールはユーザまたはグループ単位で割り当てができます。

  • Health Consumer – テナントヘルス状態を参照
  • インフラストラクチャアーキテクト – マシンブループリントの作成・管理
  • XaaSアーキテクト – XaaSブループリントの作成・管理
  • ソフトウェアアーキテクト – ソフトウェアブループリントの作成・管理
  • アプリケーションアーキテクト – 複合ブループリントの作成・管理
  • コンテナアーキテクト – ブループリントに対しコンテナやネットワークコンポーネントを追加・管理
  • カタログ管理者 – カタログサービスの作成・管理
  • コンテナ管理者 – コンテナ関連の作成・管理
  • 承認管理者 – 承認ポリシーの作成・管理
  • セキュアなエクスポートのコンシューマ – 暗号化されたカスタムプロパティやコンテンツをクリア形式でエクスポート可能

 

まあ~よく分かりませんね。 🙂 検証環境だし使うユーザに対してすべての権限を割り当てることにします。:)

※本番環境ではきちんとロールを使い分けて使うことをオススメします。

① [管理]メニューより[ユーザおよびグループ]を選択します。

 

② [ディレクトリユーザとディレクトリグループ]を選択、”検索フォーム”からロールを追加したいユーザまたはグループを検索します。ユーザまたはグループが表示されたら、ユーザ名をクリックするか[詳細表示]をクリックします。

 

③ [全般]タブから”ロールを追加するユーザ”すべてにチェックを入れ、[完了]をクリックします。

※追加するユーザが”テナント管理者”と”IaaS管理者”であれば、そのロールはチェックされているはずです。

 

④ ログイン中のユーザのロールを変更した場合は、上図のように割り当てられて権限を確認するためにはログインし直す必要があります。

 

これで完璧です。すべて権限で何でも検証できます。 🙂

 

▶▶▶ファブリックグループの作成

それでは本題のファブリックグループを作成してみましょう。

⑤ [インフラストラクチャ] → [エンドポイント] → [ファブリックグループ]順に選択し、[New]をクリックします。

 

⑥ ファブリックグループ作成に必要な情報を入力し、[OK]をクリックします。

  • Name – ファブリックグループ名
  • Fabric Administrators – ファブリック管理者
  • Compute resources – ファブリックグループで利用するコンピュートリソース

※ ファブリック管理者は必須項目ではありませんが、必ず追加しましょう。

※ Compute resourcesが表示されない場合は、”エンドポイント”が正常に作成されてない可能性があります。

 

⑦ ファブリックグループが作成されたこと確認し、一旦ログインし直しましょう。

 

⑧ 再度ログインすると、なんかメニューが増えていることが分かります。 🙂 これはファブリックグループ管理に必要な権限がユーザに追加されたためです。

 

▶▶▶データコレクションの実行

作成したエンドポイントは定期的に接続している環境の情報を更新します。このブログの例だとvSphereクラスタのインベントリ情報が定期的に更新され常に最新状態を維持します。vSphere関連で収集される情報は以下の3つです。

  • Inventory – vSphere環境のインベントリ情報、デフォルト1日間隔
  • State – vSphere環境の仮想マシンの起動状態、デフォルト15分間隔
  • Performance – vSphere環境の仮想マシンのCPU、メモリ、ストレージ、ネットワークのパフォーマンス状態、デフォルト1日間隔

上記のようにほっといても1日1回は情報が最新に更新されますが、例えばブループリント用仮想マシンのテンプレート作成したのに1日待つのは時間が勿体無いですよね。なので手動でデータコレクションを実施します。

 

⑨ [インフラストラクチャ] → [コンピュートリソース]をクリックします。

 

⑩ [コンピュートリソース]を選択、Compute resourceの[Data Collection]をクリックします。

 

⑪ “Inventory”、”State”、”Performance” それぞれ[Request now]をクリックします。

 

⑫ 環境にもよりますが、データコレクションは数十秒から数分で完了します。データ収集結果が’Succeeded’であれば無事vSphere環境の情報が更新されたことを意味します。 [OK]をクリックし、Data Collectionを終了します。

 

ここまでがファブリックグループ作成とData Collectionの手動実施方法の紹介でした。次回は引き続きファブリックグループのコンポーネントを作成する手順について紹介したいと思います。

 

[VMware] vRealize Automationの導入 (4)

 

(0) vRAの概要
(1) vRAのコンポーネント
(2) vRAのインストール
(3) テナント作成
(4) Active Directoryの追加

 

前回でテナントを作成しました。その際にローカルユーザを作成しましたが、もちろんローカルユーザだけで構成することもできます。ただvRAローカルユーザを使う場合は、テナント毎にユーザを作成やユーザ作成時に設定したパスワードが変更不可などの運用面であまり推奨できません。ということでvRAでもActive Directoryと統合しADドメインユーザを利用者または管理者として指定し、またユーザおよびグループの管理もDomain Controllerで一括で管理できるようにしましょう。

 

(4) Active Directoryの追加

① 前回作成したテナントにアクセスします。

  • URL – https://vRAアプライアンス FQDN/vcac/org/テナントURL
  • ログインアカウント – テナント作成時、作成したローカル管理者

 

② [管理]タブの[ディレクトリ管理]をクリックします。

 

③ [ディレクトリを追加]から[LDAP/IWP経由のActive Directoryを追加]を選択します。

 

④ ディレクトリ名を入力し、[LDAP経由のActive Directory]を選択します。他の設定項目は一先ずデフォルトのままでも問題ありません。

※[Active Directory(統合Windows認証)]を選択すると、うまくDomain Controllerに接続できない場合があります。その場合は一旦追加されたドメインを削除して、新たにディレクトリを追加する必要があります。

 

⑤ 追加するドメインからアカウントを検索するためのバインドユーザ情報を入力し、[接続テスト]をクリックします。

  • ベースDN – アカウントを検索する場所(ここでは検証なのでtopレベルを指定しました)
  • バインドDN – アカウント検索に使用するアカウント(ここでは検証なのでドメイン管理者を指定しました)

 

⑥ 接続テストに成功したら、[保存して次へ]をクリックします。

 

⑦ 追加されたドメインを確認後、[次へ]をクリックします。

 

⑧ 今度はユーザの属性をマッピングします。要はActive DirectoryとvRAのユーザ属性は全く同じではないのでお互いの属性をマッピングする必要があります。ただここは自動的にマッピングされるのでやることは殆どありません。一つだけあるとすれば、リソースのリクエストに対する”承認”を構成する場合、AD側にmanager属性がないため、カスタム入力でmanager属性を追加し、マッピングすることです。

 

⑨ グループを同期する場所を指定します。グループ指定はDN形式で’ネストグループ’も追加することができます。

 

⑩ グループDNが正しく指定されていれば、同期可能なグループがヒットします。この例では8つのグループがヒットしました。このヒットしたグループを全部同期することも、特定のグループだけを同期することも可能です。ここでは全部同期しようと思います。

 

⑪ ヒットした8つのグループすべてを同期するよう追加しました。[次へ]をクリックします。

 

⑫ 今度はユーザを同期するんですが、同期するグループメンバーのみ利用する場合はあえてユーザ単位で追加する必要はないかと思います。[次へ]をクリックします。

 

⑬ 同期するグループとユーザのレビューを行います。おそらく殆どの場合、上図のようなエラーが表示されるかと思います。これは同期するグループやユーザが同期のため追加したグループ以外のグループにも所属しているためです。例えば手順⑪で追加したグループメンバーの中にドメイン管理者権限を持っているユーザがいてAdministratorsやDomain Adminsなどのグループも同期対象に追加する必要があるということです。言われたので追加しましょう。:) [グループDNを編集]をクリックします。

※エラーの中のグループDNをメモ帳などにコピーしておくと追加がスムーズに行きます。

 

⑭ 足りないグループを追加し、[保存]をクリックします。

 

⑮ 追加したグループやユーザは、デフォルト週1回間隔で自動的に同期の更新が実行されます。間隔は時間、日、週、手動で調整が可能です。ここでは日次間隔で同期を実行するように設定を変更しました。[ディレクトリ同期]をクリックすると最初の同期が実行されます。

 

⑯ 失敗なく同期が行われたことが確認できたら、’テナント管理者’と’IaaS管理者’にADドメインユーザを追加するため一旦テナントページからログアウトします。

 

⑰ 今度はvRAの管理者ページにアクセスします。

 

⑱ [テナント]メニューから作成したテナントを選択、[編集]をクリックします。

 

⑲ [管理者]タブから’テナント管理者’と’IaaS管理者’として追加したいADドメインユーザ(またはグループ)を追加し、vRA管理者ページから[ログアウト]します。

 

⑳ もう一度、テナントにアクセスします。

今度はドメインを選択できるようなっているはずです。なのでディレクトリで追加したドメインを指定します。

 

㉑ 手順⑲でIaaS管理者に追加したADドメインユーザでログインします。

 

㉒ 無事ADドメインユーザでログインできました。

 

ここまでがActive Directoryを追加する手順でした。次回はEndpointを作成する手順を紹介します。