vRealize Automationを構築する Part3: Cloud Account & Cloud Zoneの作成
今回、vRealize Automation8.1(vRA)を検証する必要がありましたので、デプロイしてテストしてみました。その構築メモになります。
vRealize Automationを構築する Part1: vRAのデプロイ
vRealize Automationを構築する Part2: vIDMの設定
vRealize Automationを構築する Part3: Cloud Account & Cloud Zoneの作成
vRealize Automationを構築する Part4: Projectの作成
vRealize Automationを構築する Part5: Flavor Mapping & Image Mappingの作成
vRealize Automationを構築する Part6: Blueprintの展開
vRealize Automationを構築する Part7: Content & Catalogの展開
vRealize Automationを構築する Part8: vRealize Orchestratorとの連携
前回、ADユーザーとグループをインポートしましたので、vRAの権限を割り当てていきます。その後Cloud AccountとCloud Zoneを作成します。
vIDMのデフォルト構成管理者でvRAにログインします。
"Identity&Access Management"をクリック
ADユーザーとグループに権限を付与します。今回は"kamev"というADユーザーに各サービスの管理者権限を付与します。
"EDIT ROLES"
Assign Organization Rolesに"Organization Owner"を選択します。
Assign Service Rolesに各サービスを追加し、保存します。
これでADユーザーに対してロールを割り当てることができましたので、設定したADユーザーでログインできる事を確認します。
ログインできました。
ここからCloud AccountとCloud Zoneを作成していきます。
"Cloud Assembly"を選択します。
Infrastructure > Connections > Cloud Accounts > "Add Cloud Account"をクリック
Cloud Account Typeから"vCenter"を選択
Cloud Account名と接続先のvCenter情報を入力し、"VALIDATE"をクリック
ValidationをPassすると管理下のDatacenterが見えてくるので、チェック、"ADD"します。
Cloud Accountが正常に作成されました。
続いてCloud Zoneを作成します。
Configure > Cloud Zones > "NEW CLOUD ZONE"をクリックします。
先ほど作成したCloud Accountを選択し、Cloud Zone名を入力します。
Placement Policyはデフォルトのまま、Folderを選択し、"CREATE"をクリックします。
Cloud Zoneが作成されました。
以上でCloud AccountとCloud Zoneの作成は完了です。
vRealize Automationを構築する Part2: vIDMの設定
今回、vRealize Automation8.1(vRA)を検証する必要がありましたので、デプロイしてテストしてみました。その構築メモになります。
vRealize Automationを構築する Part1: vRAのデプロイ
vRealize Automationを構築する Part2: vIDMの設定
vRealize Automationを構築する Part3: Cloud Account & Cloud Zoneの作成
vRealize Automationを構築する Part4: Projectの作成
vRealize Automationを構築する Part5: Flavor Mapping & Image Mappingの作成
vRealize Automationを構築する Part6: Blueprintの展開
vRealize Automationを構築する Part7: Content & Catalogの展開
vRealize Automationを構築する Part8: vRealize Orchestratorとの連携
前回の投稿でvRSLCM/vIDM/vRAをデプロイしました。
今回はvIDMのActive Directoryとの統合手順について紹介します。
vIDMはvRAに認証機能を提供していますが、デプロイした直後の現時点では、ローカルユーザーのみがログインできます。ADユーザーがログインできるように設定をしていきます。
vIDMにローカルユーザーでログインします。
ユーザーアカウント名をクリック > 管理コンソール
vIDMのダッシュボードが表示されますので、"IDとアクセス管理"をクリック
現在は"システムディレクトリ"のみが表示されている状態です。
ディレクトリを追加 > "LDAP/IWA経由のActive Directoryを追加"をクリック
ディレクトリ名を入力
ドメイン管理者のユーザー名/Passとバインドユーザーの情報を入力し、"保存して次へ"をクリック
ドメインが選択されている事を確認して、"次へ"をクリック
こちらはデフォルトのまま"次へ"をクリック
ADのグループを追加するためには、+アイコンをクリックします。
ADグループをDN名で指定します。
C:\Users\Administrator> dsquery group -name CloudAdmin
"CN=CloudAdmin,CN=Users,DC=lab,DC=local"
次へ
"ディレクトリ同期"をクリック
同期済みグループとユーザーが追加されている事を確認します。
以上でvIDMのAD統合は終了です。
vRealize Automationを構築する Part1: vRAのデプロイ
今回、vRealize Automation8.1(vRA)を検証する必要がありましたので、デプロイしてテストしてみました。その構築メモになります。
vRealize Automationを構築する Part1: vRAのデプロイ
vRealize Automationを構築する Part2: vIDMの設定
vRealize Automationを構築する Part3: Cloud Account & Cloud Zoneの作成
vRealize Automationを構築する Part4: Projectの作成
vRealize Automationを構築する Part5: Flavor Mapping & Image Mappingの作成
vRealize Automationを構築する Part6: Blueprintの展開
vRealize Automationを構築する Part7: Content & Catalogの展開
vRealize Automationを構築する Part8: vRealize Orchestratorとの連携
vRAの検証をするにあたって、以下をまとめてデプロイします。
- vRealize Suite Lifecycle Manager(vRSLCM)
- VMware Identity Manager(vIDM)
- vRealize Automation(vRA)
vRSLCMがアップグレードやパッチの管理、vIDMが認証機能の提供やADとの連携などを行います。そのためvRA単体をデプロイしても使用できません。
My VMwareからvRSLCMのEasy Installerをダウンロード
vrlcm-ui-installer\win32のパスからinstaller.exeファイルを起動します。
Install
NEXT
EULAとCEIPのチェックを確認
vCenterの情報を入力
デプロイ先のデータセンターを選択します。
※今回はvRealizeというフォルダを作成しました。
デプロイ先のクラスタを選択します。
データストアを選択します。
今回はvSANデータストアにデプロイします。
ネットワーク設定を入力
今回デプロイする3台の共通のパスワードを入力します。
vRSLCMのパラメータを入力します。
Identity Managerのパラメータを入力します。
vRAの設定を入力します。
入力値を確認してSUBMITします。
3台の仮想マシン(vRSLCM,vIDM,VRA)のデプロイが開始されます。
vRAのデプロイが失敗しています。
vRSLCMのGUIからエラーを確認してみます。
com.vmware.vrealize.lcm.common.exception.EngineException: vRA VA deployment Failed at First Boot check on HostName vra.lab.local at com.vmware.vrealize.lcm.plugin.core.vra80.task.VraVaPostInstallCheckTask.execute(VraVaPostInstallCheckTask.java:104) at com.vmware.vrealize.lcm.automata.core.TaskThread.run(TaskThread.java:45) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)
vRAのホストネームを確認せよ。と表示されているものの、DNSには事前に登録済みで正引き・逆引きができる事は確認済みです。
先に結論から。今回、私の場合はvRAのrootユーザーにログインできない事が原因でした。そのため、以下を参考にvRAのシングルユーザーモードでパスワードを再設定します。
vRealize Automation の root パスワードをリセットする方法
rootユーザーで起動後は、passwdコマンドで再設定します。
再起動
再起動後、仮想コンソールからrootユーザーでログインできる事を確認します。
再度vRSLCMからRetryします。
Submit
無事Passしました。
vRAのURLにアクセスします。
vRAのGUIにアクセスできましたので、今後ここから設定していきます。
次回はデプロイしたvIDMをADと連携する方法について記載します。
以上です。
簡易的なメールサーバーを立てて、vCenterのメールアラートテストをする Part2
前回の記事で、メールサーバーを構築して、メールの送受信ができる事を確認しました。今回はそのメールアドレスを使用してvCenterのアラートメールテストを行います。
2.vCenter上でテスト用のアラームを作成して、メールが飛ぶかテストをする。
まずは、vCenter側の設定を行います。
vSphere Clientにログイン > vCenter > 設定 > 全般 > 編集をクリック
メール > メールサーバーとメール送信者の項目を入力します。
vCenter側の設定を行った所で、次はテスト用のアラートを作成します。
今回はメール通知テストを行うだけなので、簡単にアラートが発生するようにします。
内容としては、VMを作成した際にアラートを発生させます。
アラーム名を入力し、ターゲットのタイプを"仮想マシン"にします。
"仮想マシンが作成されました"
アラームトリガーは重大
Eメール通知を送信をOnにし、件名はデフォルト、Eメールの宛先を入力
このアラームを有効にするがOnになっている事を確認して、"作成"をクリックします。
新規アラームが作成できたところで、次は新規に仮想マシンを作成します。
新規仮想マシンの作成が完了後にアラートが記録されている事を確認します。
Thunderbird側でメールが受信されているか確認をします。
正しく受信ができている事を確認できました。
vCenter側のログも確認してみます。
/var/log/vmware/messages
2021-05-05T07:46:44.613771+00:00 vcenter01 sendmail[30731]: 1457ki5g030731: from=<kamev@lab.local>, size=1138, class=0, nrcpts=1, msgid=<202105050746.1457ki5F030730@vcenter01.lab.local>, proto=ESMTPS, daemon=MTA, relay=vcenter01.lab.local [127.0.0.1]
2021-05-05T07:46:44.621118+00:00 vcenter01 sendmail[30730]: 1457ki5F030730: to=kamev@lab.local, ctladdr=kamev@lab.local (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30913, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (1457ki5g030731 Message accepted for delivery)
以上です。
簡易的なメールサーバーを立てて、vCenterのメールアラートテストをする Part1
日々サポート業務をしていると、障害が発生した際に、メールでアラート通知をしたい。という問い合わせが入る事があります。今回はテストを行うために簡易的なメールサーバーを立てて、メールアラートを飛ばす検証を行いましたので、記録として残しておきます。
1.Windows Server上にhMailServerというソフトをインストールしてメールサーバーを立てる。
今回はhMailServerというソフトを使用しますので、以下URLからダウンロードします。
https://www.hmailserver.com/download
ダウンロードが完了したら実行します。
Full instalationを選択します。
今回はMySQLを使用しますので、Use external database engineを選択します。
Installを実行します
メールサーバーのパスワードを設定します。
インストールが完了したら、次はデータベースの設定を行いますが
先にMySQLのインストールと設定を行います。
以下のサイトからMySQLをダウンロードします。
https://www.mysql.com/jp/downloads/
Archivesをクリック
今回はProduct Version: 5.7.21をダウンロードします。
"mysql-installer-web-community-5.7.21.0.msi"のファイルがダウンロードできたら、実行してインストールウィザードを起動します。
Server Computerを選択
Excuteを実行
Finishをクリック
次はhMailServerのデータベースのセットアップを行います。
Create a new hMailServer databaseを選択
MySQLを選択します。
データベースのアドレスとPort、データベースの名前、認証情報を入力します。
MySQLのサービスと関連付けをします。
libmysql.dllが見つからない旨のエラーメッセージが表示されます。
32bit版のlibmysql.dllが必要なので以下のURLを参考にC:\Program Files (x86)\hMailServer\Binへコピーします。
http://dim5.net/windows-server/hmailserver-install.html
コピー後にNextをクリックすると、インストールが先に進むのでCloseをクリックして設定を終了します。
DBの設定が完了したら、管理画面にアクセスします。
Connectをクリックします。
パスワードを入力します。
Add domainをクリック
ドメインを入力して、Saveを押します。
作成したドメインの配下のAccountsをクリックして、アカウントを作成します。
アドレスとパスワードの設定を行い、Saveをクリックします。
今回は、テスト用に二つのアドレスを作成しました。
メールサーバーの設定が完了したので、送受信のテストを行います。
今回はメールソフトにThunderbirdを使います。
以下は、"接続する上での危険性を理解しました"にチェックを入れて、完了をクリックします。
作成した二つのメールアドレス間でテストメールを送信します。
テストメールの送信と受信が確認できました。
次回はこのアドレスを使用して、vCenterのアラートメールテストを行います。
SDDC ManagerのProxy設定について
今回は、VMware Cloud Foundation(VCF)ネタです。
SDDC Managerは、VCFのコンポーネントを管理、デプロイ、アップグレードするためのツールです。
例えば、アップグレードなどをする時は、VCFのアップグレードバンドルをダウンロードする必要がありますが、MyVMwareの資格情報を入力するだけで、簡単にダウンロードが可能です。ダウンロード後はSDDC Manager GUI経由で、SDDC Manager/vCenter(PSC)/NSX/ESXiなどのコンポーネントが簡単にアップグレードできます。
しかし、環境によってはProxyを経由させる必要がある場合があると思います。その場合はSDDC Managerの設定を変更させる必要がありますので、今回はその変更手順について記載します。
SSHクライアントを使用してSDDCManagerに接続します
vcfユーザー資格情報を使用してSDDCマネージャーにログインします。 次に、権限をrootに昇格させる必要があります
Configファイルを変更します。
VCF 2.3以降では、Configファイルは以下です。
/opt/vmware/vcf/lcm/lcm-app/conf/application-prod.properties
Configファイルのapplication-prod.propertiesを編集します。
LCM DEPOT PROPERTIES項目の以下3つを修正します。
lcm.depot.adapter.proxyEnabled=false
lcm.depot.adapter.proxyHost=proxy.vmware.com
lcm.depot.adapter.proxyPort=3128
以下のように修正します。
lcm.depot.adapter.proxyEnabled=true
lcm.depot.adapter.proxyHost=<Proxy Server Hostname or IP>
lcm.depot.adapter.proxyPort=Port番号
編集後、サービスを再起動します。
systemctl restart lcm
以上です。
NSX-T 2.5から3.0へのアップグレードについて
今回は、検証でLabのNSX-T 2.5.2からNSX-T 3.0へアップグレードを実施します。
NSX-T 3.0にアップグレードする前に、vCenterとの互換性を確認します。
次にMy VMwareからNSX-Tのアップグレードバンドルをダウンロードします。
現在のNSX-T Managerのバージョンは2.5.1です。
※Lab環境のリソースの都合上、NSX-T Managerは1台のみデプロイしています。
NSX Manager GUIにログインし、アップグレードを実施します。
システム > アップグレード > アップグレードバンドルのアップロード > MUBファイルのアップロード > 参照ボタンからダウンロードしたMUBファイルを選択します。
アップロードをクリックします。
アップロードと、バンドルの展開に少し時間がかかります。
Upgrade Coordinatorのアップグレード
アップロードが成功したら、アップグレードの開始をクリックします。
EULAの内容を確認の上、同意ボタンにチェックを入れます。
続行をクリックして、Upgrade Coordinatorをアップグレードします。
Upgrade Coordinatorのアップグレードが完了すると、NSX-Tのすべてのコンポーネントの事前チェックが実行できます。
"事前チェックの実行"をクリックすると、アップグレードの事前チェックが実行されます。
事前チェックが完了すると、全てのNSX-Tコンポーネントの事前チェックの状態が表示されます。問題が見つからなければ、緑にチェックマークがつきますが、問題がある場合は、赤のビックリマークが表示されます。それぞれのコンポーネントで事前チェックの結果を確認します。
エラーはNSX-T 3.0の要件に関するものです。NSX-T Data Center 3.0 より前のバージョンからアップグレードする場合は、すべての NSX Manager アプライアンスで、100 GB の容量のセカンダリ ディスクをプロビジョニングします。セカンダリ ディスクが Upgrade Coordinator に検出されない場合は、アプライアンスを再起動します。
vCenterにログインし、NSX-T ManagerのVMを右クリック > 設定の編集 > 新規デバイスを追加 > ハードディスク
新規ハードディスクのサイズを100GBに指定して、OKをクリックします。
全てのNSX-T Managerに対して同様に実施します。
100GBのディスクを追加後に事前チェックを実行したところ、エラーは表示されなくなりました。
警告は、過去2日間にNSX-Tマネージャーのバックアップが取られていない事による警告です。 NSX-TManagerをアップグレードする前にバックアップを取得する事を推奨します。方法はNSX-T Managerのバックアップを参照してください。
"次へ"をクリックして、NSX-T Edgeクラスターのアップグレードを開始します。
NSX-T Edge Clusterのアップグレード
エッジクラスターグループをクリックすると、グループの下のエッジノードの詳細なステータスを確認できます。 NSX Edgeノードはシリアルモードでアップグレードされるため、アップグレードノードがダウンしても、NSXEdgeクラスター内の他のノードはアクティブなままでトラフィックを継続的に転送します。
私の場合、エッジクラスターでの可用性を確保するために、「md-edge-01」でのアップグレードが最初に開始されます。
最初のエッジノードが正常にアップグレードされたら。 2番目のエッジノードでアップグレードが開始されます。 進行状況オプションの下にある"詳細"をクリックすると、アップグレード中に実行されたすべてのアクティビティの詳細情報が表示されます。
エッジクラスターのアップグレードが完了すると、ステータスが"成功 100%"と表示されます。 "事後チェックの実行"をクリックして、アップグレード後のチェックを実行し、アップグレード後にすべてのエッジノードが正常であることを検証することもできます。 "次へ"をクリックして、ホストのアップグレードを続行します。
ESXiホストのアップグレード
このプロセスでは、VMをホストから移行し、ホストをメンテナンスモードにすることで、ホストを1つずつアップグレードします。ホストでアップグレードが完了すると、ホストはメンテナンスモードを終了し、クラスター内の他のホストで同じプロセスを続行します。このホストのアップグレードでは、ESXiの再起動は発生しません。
"開始"をクリックして、ホストのアップグレードを開始します。
グループ名をクリックして、ホストのアップグレードの詳細なステータスを確認します。 各ホストのアップグレードステータスを確認できます。 クラスター内のホストを1つずつアップグレードします。
アップグレードが完了すると、"成功 100%"が表示されます。
NSX-T 管理ノードのアップグレード
このプロセスにより、NSX-T Managerがアップグレードされます。 アップグレードシーケンスは、管理プレーンを最後にアップグレードします。 管理プレーンのアップグレードが進行中の場合は、どのノードも構成を変更しないでください。
アップグレードを開始すると、NSXManagerのユーザーインターフェイスに一時的にアクセスできなくなります。 その後、アップグレードが完了して管理プレーンが再起動されるまで、NSX Managerのユーザーインターフェイス、API、およびCLIにアクセスできません。
"開始"をクリックして、NSX-TManagerでアップグレードを開始します。
"開始"をクリックして、NSX-T Managementノードのアップグレードを開始します。
アップグレードが完了しました。
アップグレード後のNSX-T Managerのバージョンはシステム > アプライアンスから、確認可能です。