[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] Web Client接続時[400] Single Sign-Onエラーが発生する

 

先日、検証環境のvCenterに接続できなくなりました。外部PSCとVCSAの構成ですがWeb Clientで接続すると以下のようなエラーが表示され、もちろんHTML5 Clientでもダメでした。

[400] Single Sign-On サーバへの認証要求の送信中にエラーが発生しました – null

 

エラーコードとメッセージからSSOに問題があるようで少々調べましたが中々解決できませんでした。このようなSSO関連エラーはVCSAとPSC間の時刻ズレが原因の場合が少なくないのでそれぞれ時刻を確認してみましたが同じでした。色々試しましたが埒が明かず、バックアップデータもありませんでしたので’もうインストールし直しか’と諦めかけてましたが以下の方法で何とか復旧できました。

 

まず新たにPSCをデプロイしました。デプロイ時のSSO構成は、問題(があるように思われる)のPSCのSSOに参加するオプションで。

新PSCデプロイ後、VCSAから以下のコマンドでre-pointを実施。

root@k-vc02 [ ~ ]# cmsso-util repoint –repoint-psc k-psc04.kiiro.local
Validating Provided Configuration …
Validation Completed Successfully.
Executing repointing steps. This will take few minutes to complete.
Please wait …
Stopping all the services …
All services stopped.
Starting all the services …
Started all the services.
The vCenter Server has been successfully repointed to the external Platform Services Controller k-psc04.kiiro.local.

 

再度Web Clientにアクセスしたところ、復活!

VCSA上でPSC情報を確認したところ、表示されるのは新しくデプロイしたPSCのみでした。

root@k-vc02 [ ~ ]# /usr/lib/vmware-vmafd/bin/vmafd-cli get-ls-location –server-name localhost
https://k-psc04.kiiro.local:443/lookupservice/sdk

 

インベントリ情報など問題ないことを確認し、問題(?)のPSCを停止して一件落着みたいな…

色々とイジりまくってた時におかしくなったんですかね。 汗

 

ちなみに以前から同僚からもお客さんからも”組み込みPCS”と”外部PSC”の使い分けは?って聞かれますがこちらの「Platform Services Controller (PSC) FAQ」に明記されています。

If you want/need Enhanced Linked Mode (e.g. multiple vCenter Servers in the same vSphere SSO Domain) you have to use an external PSC.

要は”拡張リンク モード”を使う場合は”外部PSC”ということです。さらに…

There could be a product that recommends and external PSC for some reason. But outside of that there is really no benefit to running an External PSC without Enhanced Linked Mode.

“拡張リンク モード”を使わないと”外部PSC”はあまりメリットがないとのことです。 🙂

 

 

[VMware] vCenter関連ニュース

来週から開催されるVMworld 2017に先立ってvCenter関連のニュースが発表されました。

 

まず、FlashベースのWeb Clientが無くなります。

Goodbye, vSphere Web Client

 

上記の公式ブログによると次期バージョンのvSphereではFlashベースのWeb Clientが”非推奨”となり、サポートする最後のバージョンになるということです。ということはHTML5 Clientがいよいよ主役になります。

HTML5 Clientは現在の最新バージョン(vSphere 6.5 Update 1)でFlashベースのWeb Clientの約90%の機能をカバーしていると言われていますが、次期バージョンのvSphereでは完全にFlashベースのWeb Clientの代わりとして利用できると思いますね。

 

もう一つのニュースは、Windows版vCenterも無くなるとのことです。

Farewell, vCenter Server for Windows

VCSAが登場した最初の頃からこのような結末を予想していた方も多いでしょうが、小職はまさか、完全に追い出すとまでは思いませんでしたよ。最初はね。しかしVCSAを使っているうちにWindows版vCenterを使う理由がないことに気づいたわけです。正直VCSAを提案すると”Linuxになれていない”とか”Windows版に比べてパフォーマンスが劣る”とかでWindows版vCenterを好む顧客が未だに多いのも事実ですが“Linuxエクスパートである必要もありませんし、パフォーマンスも劣りません!” と叫びたい!:) OSとSQL Serverのライセンスコストも要らない、Update Managerも統合されましたし、SyslogもDumpも中に溜め込めます。VCHAもサポートしているし、ネーティブバックアップもサポートしています。悩むことも迷うこともありません。:)

FlashベースのWeb Clientと同様、次期バージョンのvSphereで”非推奨”となり、サポートする最後のバージョンになるとのことです。Windows版vCenterからVCSAへの移行は公式的にサポートしていますし、案外に簡単かつ安全に移行できます。移行を検討している方はここをご参照ください。

 

[VMware] vCenter HAについて

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用クローンを作成します。
※ クローン作成方法は割愛しますが、クローン作成用”カスタマイズ仕様”を定義する必要があります。定義の際には以下の項目設定に注意が必要です。

  • ホスト名:Active VCSAのホスト名
  • タイムゾーン:Active VCSAと同じタイムゾーン
  • NIC#1:Active VCSAのIPアドレス(管理ネットワーク)
  • NIC#2:手順②で設定したPassive VCSAのハートビート用IPアドレス(デフォルトゲートウェイは設定しません)

上記の項目以外はVCHA特有の設定はありません。すべて設定したらクローンを作成し、正常に起動するまで待ちます。

 

⑧ 今度はWintness用VCSAのクローンを作成します。
基本、Passive VCSA用クローン作成と同じですが、こちらも”カスタマイズ仕様”を定義する必要があります。定義の際には以下の項目設定に注意が必要です。

  • ホスト名:Active VCSAのホスト名
  • タイムゾーン:Active VCSAと同じタイムゾーン
  • NIC#1:DHCP
  • NIC#2:手順②で設定したWitness VCSAのハートビート用IPアドレス(デフォルトゲートウェイは設定しません)

上記の項目以外は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

 

 

[VMware] VCSAリファレンスポスター

VMware社では今まで何度もプロダクトのリファレンスを奇麗にポスターにまとめて公開していますが、今回またもや素晴らしいリファレンスポスターを公開しました。

Introducing the vCenter Server Appliance 6.0 Reference Poster

このリファレンスポスターにはvCenter Server仮想アプライアンスに関する次の情報がよくまとまっています。

・ハードウェア要求仕様
・ファイアウォールポーと一覧
・最大構成数
・主要KB一覧
・ログの種類と格納場所
・サービス種類
・操作コマンド一覧
・PSC/vCenter Serverの推奨デプロイトポロジーと非推奨トポロジーからの移行方法

vcsa-6-0-poster

ダウンロードはこちらから。

 

こういう奇麗にまとまった資料を見る度に作成者の才能が羨ましい限りです。。。 🙂