【VMware Cloud Director】ビルド番号とバージョン
Build NumberやInstaller Build NumberとVCDバージョンとの対応
https://kb.vmware.com/s/article/2143847?lang=ja
各バージョンのリリースノートでも対応は確認できる
VMware Cloud Director 10.5 リリース ノート
マイナーバージョンが異なる10.3.3/10.3.3.1/10.3.3.2/10.3.3.3/10.3.3.4などのova名は以下のようになるため、ova名から正確なバージョンを判断できないため有用な対応表となる
VMware_Cloud_Director-10.3.3.8153-20030439_OVF10.ova
上記の場合、20030439がInstaller Build Numberであるため、10.3.3.2のovaと識別できる
【VMware Cloud Director】GUIとAPIでのLDAP設定の差異
GUIにてLDAPを設定する際は「ベースの識別子名」が1つしか表示されず、ユーザーとグループにて共通の「ベースの識別子名」しか設定できない
しかし、APIから設定する際はユーザーとグループに対して個別の「ベースの識別子名」を設定できる
利用API
PUT /admin/org/{id}/settings/ldap
VMware Cloud Director API - VMware API Explorer
VMware Cloud Director API - PUT-OrgLdapSettings
"IsGroupSearchBaseEnabled"をtrueに設定し、"GroupSearchBase"にて指定することで、グループ用の設定が可能となる
(例)リクエストbody
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OrgLdapSettings xmlns="http://www.vmware.com/vcloud/v1.5" xmlns:vmext="http://www.vmware.com/vcloud/extension/v1.5" xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData" xmlns:common="http://schemas.dmtf.org/wbem/wscim/1/common" xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData" xmlns:vmw="http://www.vmware.com/schema/ovf" xmlns:ovfenv="http://schemas.dmtf.org/ovf/environment/1" xmlns:ns9="http://www.vmware.com/vcloud/versions" href="https://172.16.20.20/api/admin/org/4b756104-e74e-4143-a622-6e4f5e0ea789/settings/ldap" type="application/vnd.vmware.admin.organizationLdapSettings+xml">
<OrgLdapMode>CUSTOM</OrgLdapMode>
<CustomOrgLdapSettings>
<HostName>172.16.20.1</HostName>
<Port>389</Port>
<IsSsl>false</IsSsl>
<SearchBase>OU=users,DC=env,DC=lab</SearchBase>
<UserName>administrator@env.lab</UserName>
<AuthenticationMechanism>SIMPLE</AuthenticationMechanism>
<GroupSearchBase>OU=groups,DC=env,DC=lab</GroupSearchBase>
<IsGroupSearchBaseEnabled>true</IsGroupSearchBaseEnabled>
<ConnectorType>ACTIVE_DIRECTORY</ConnectorType>
<UserAttributes>
<ObjectClass>user</ObjectClass>
<ObjectIdentifier>objectGuid</ObjectIdentifier>
<UserName>sAMAccountName</UserName>
<Email>mail</Email>
<FullName>displayName</FullName>
<GivenName>givenName</GivenName>
<Surname>sn</Surname>
<Telephone>telephoneNumber</Telephone>
<GroupMembershipIdentifier>dn</GroupMembershipIdentifier>
<GroupBackLinkIdentifier>tokenGroups</GroupBackLinkIdentifier>
</UserAttributes>
<GroupAttributes>
<ObjectClass>group</ObjectClass>
<ObjectIdentifier>objectGuid</ObjectIdentifier>
<GroupName>cn</GroupName>
<Membership>member</Membership>
<MembershipIdentifier>dn</MembershipIdentifier>
<BackLinkIdentifier>objectSid</BackLinkIdentifier>
</GroupAttributes>
</CustomOrgLdapSettings>
</OrgLdapSettings>'
以下の順序で行うとリクエストbodyを作成するのが楽になる
①GUIから設定を投入
②"GET /admin/org/{id}/settings/ldap"にて設定を取得
https://developer.vmware.com/apis/1245/doc/operations/GET-OrgLdapSettings.html
③②で取得した内容のうちグループ用箇所のみ変更
④”PUT /admin/org/{id}/settings/ldap”にて設定変更
【VMware Cloud Director】postgreのレプリケーション挙動とフェイルオーバー時の注意点
・環境
3ノード構成であり、プライマリノードは「20-vcd-11」
・レプリケーション設定
確認対象ファイル：/var/vmware/vpostgres/current/pgdata/postgresql.conf
セル3台が正常に稼働している時は以下のような設定となっている
wal_level = replica
max_wal_senders = 10
synchronous_commit = on
synchronous_standby_names = 'ANY 1 ("20-vcd-13","20-vcd-12")'
・スタンバイセルのリストア時のレプリケーション設定(synchronous_standby_names )について
①正常時
synchronous_standby_names = 'ANY 1 ("20-vcd-13","20-vcd-12")'
②セル「20-vcd-12」削除時
synchronous_standby_names = 'ANY 1 ("20-vcd-13","20-vcd-12")'
削除したセルの情報が設定から削除されていない
③セル「20-vcd-12」リストア時
synchronous_standby_names = 'ANY 1 ("20-vcd-13","20-vcd-12","20-vcd-12")'
リストアしたセルが2重に登録されてしまう
④数分経過後
synchronous_standby_names = 'ANY 1 ("20-vcd-13","20-vcd-12")'
重複していた登録が削除される
古いセルを削除してから120分経過後に登録が削除される
・2重登録による懸念点
synchronous_standby_names = 'ANY 1 ("20-vcd-13","20-vcd-12","20-vcd-12")'
といった状態のときに、２重登録されている「20-vcd-12」へフェイルオーバーすると、プライマリへ昇格する「20-vcd-12」が削除され以下のようになる
synchronous_standby_names = 'ANY 1 ("20-vcd-13","20-vcd-12")'
スタンバイとしてプライマリとなっているセル「20-vcd-12」も指定されてしまっている構成になり、GUIアクセスが不可になるなどの挙動がみられた
【VMware Cloud Director】スタンバイセルのリストア手順
・クラスター構成
リストア対象：「20-vcd-12」
・手順
1.「20-vcd-12」を強制終了
statusが変更される
2.API Unregister メソッドを使用して、repmgr 高可用性クラスタから停止した「20-vcd-12」を削除
どちらか1つのセル向けに実施すればよい
①「20-vcd-11」向け
# curl -k -X DELETE -H "Accept: application/json" -H "Authorization: Basic cm9vdDpWTXdhcmUxIQ==" "https://172.16.20.120:5480/api/1.0.0/nodes/20-vcd-12"
②「20-vcd-13」向け
# curl -k -X DELETE -H "Accept: application/json" -H "Authorization: Basic cm9vdDpWTXdhcmUxIQ==" "https://172.16.20.124:5480/api/1.0.0/nodes/20-vcd-12"
セルの管理画面から「20-vcd-12」が表示されなくなる
セルが消えていることはAPIでも確認可能
# curl -k -X GET -H "Accept: application/json" -H "Authorization: Basic cm9vdDpWTXdhcmUxIQ==" "https://172.16.20.125:5480/api/1.0.0/nodes"
3.プロバイダー画面から「20-vcd-12」を削除
クラウドセルにて「20-vcd-12」を選択し、「登録解除」を実施
「20-vcd-12」が表示されなくなる
4.同一IP、ホスト名にてリストアするため、「20-vcd-12」を削除する
5.「20-vcd-12」を再デプロイ
「20-vcd-12」が追加されていることを確認
プロバイダー画面においても追加されている
※参考ドキュメント
データベース高可用性クラスタ内の障害の発生した VMware Cloud Director アプライアンスのプライマリ セルまたはスタンバイ セルの登録解除
【VMware Cloud Director Availability】挙動について
VCDAの挙動を説明している以下の翻訳
Disaster Recovery technologies discussed; Journal or Delta? - VMware Cloud Provider Blog
・スナップショットとは
スナップショットは、特定時点の仮想マシンの状態とデータであり、バックアップとはみなされない
状態にはVMの電源状態が含まれ、データにはVMを構成するすべてのファイルやフォルダ(メモリやvNIC、vmdkなど)が含まれる
そして、これらはVMを静止することによって取得することができる
OSが静止をサポートしていない場合、アプリケーションの種類の継続性を確保するために災害発生時の回復プロセスを慎重に検討する必要がある
・なぜバックアップとみなされるべきではないか
スナップショットはオリジナルソースからの差分を記録するため、素早いロールバックを実現する
そして、それを実現するにはオリジナルディスクと差分ディスクが同一ストレージインフラストラクチャーに存在する必要がある
バックアップは個別にVM情報をすべて保有する必要があり、障害からの保護対象VMと同じインフラストラクチャーに存在する必要はない
そのため、スナップショット機能はバックアップとみなされない
・VCDAがスナップショットを利用するか
送信元ではデルタvmdkを使用し、宛先ではPoint in Time(PIT) インスタンスを使用するため、スナップショットは利用しない
複数のPoint in Time(PIT)、mPIT はソース ディスクからの差分に基づいており、これらはESXiホスト上のHost Based Replication agent(HBR) IOフィルターを介して送信される
VCDAはソースVMを静止させない点もスナップショットとは異なる
vSphere ReplicationにはVCDAが使用するコンポーネントである、ESXiホスト上のData MoverとHost Based Replicator（HBR）サービスが含まれている
これらはVMの差分同期を軽量化するためにIOをフィルタリングし、Replicator Applianceを介して宛先にレプリケートされる
vSphere ReplicationはmPITSを使用でき、24個のインスタンスをサポートする
これは、初期同期が上書きされずに23個の軽量デルタを保有できることに相当する
初期同期では、VM の「ベース」ディスクの書き込み領域のみが”ダーティ”としてマークされ、vmdk 全体がコピーされる
ディスクがレプリケートされるため、IOがわずかに増加し、かかる時間はソースとターゲットのデータストアのタイプに大きく依存する
この時点から、デルタ変更のみがコピーが必要である”ダーティ”とマークされる
・初期完全同期とは何か
パワーオン状態の仮想マシンに対してレプリケーションが設定されると、はじめにソース仮想ディスク (VMDK)の内容全体が、ターゲットの空の仮想ディスクにコピーされ、チェックサムを使用して比較される
それによりソース仮想ディスクとターゲット仮想ディスクの差異が特定され、新規レプリケーションにおける差異はゼロとなる
その比較処理において必要なCPUリソースはとても少ない
チェックサムが比較されている間、vSphere Replicationは発見された差分を定期的に送信する
完全な同期を完了するのにかかる時間は、主に仮想マシンを構成する仮想ディスクのサイズ、レプリケー ションされるデータ量、およびレプリケーションに利用可能なネットワーク帯域幅によって異なる
・軽量デルタ同期とは
完全同期が完了すると、vSphereに組み込まれたvSphere Replication agent は、レプリケーションが設定された仮想マシンの仮想ディスクの変更を追跡する
軽量デルタ同期は、仮想マシンのレプリケーションにて設定されたRPOに応じて、これらの変更を定期的にレプリケートする
たとえば、RPOが4時間の仮想マシンで変更されたデータは、4時間ごとにレプリケートされる
4時間のデータは軽量デルタvmdkに入るため、4時間以内に追加・削除されたものはデルタに含まれない
RPO間隔内に同じブロックに複数回書き込みを行っても、同期時に最後の値のみが送信されるため、ネットワークトラフィックが削減できる
このスケジュールは、データ変更率、各レプリケーションサイクルにかかる時間、同じ vSphere ホスト上でレプリケーション用に構成されている仮想マシンの数など、さまざまな要因に基づいて変更される可能性がある
vSphere Replication は、これらの要因を考慮したアルゴリズムを使用してレプリケーションをスケジュールすることで、レプリケートされた各仮想マシンの RPO が違反されないようにしている
・パフォーマンスについて
軽量デルタ同期vmdkを持てば持つほど、デルタ間の潜在的な変更データが増え、リストアにかかる時間が長期化し、すべての差異を統合するために必要なコンピュートとストレージが増える。
宛先データストアの空き容量がなくなると、新しいデルタインスタンスは作成できなくなるが、既存のインスタンスは影響を受けない。
空き領域が利用可能になると再同期は行われず、新しい増分インスタンスの作成が行われる
VCDAではSLAポリシーを使用して、レプリケーション保持ポリシー（PITインスタンスの数）とRPOを制御する
PITは軽量デルタ同期、つまりvmdkのデルタレコードですが、それはスタニングやクローニングされたvmdk全体ではなく、ベースディスクから指定インスタンスまでのチェーンのサブセットであり、独立したフラットvmdkであることを認識しておく必要がある
軽量vmdkデルタ同期は、カスケード的かつ相互依存的で、インスタンスが期限切れになるたびにディスク領域が解放される。
明示的にインスタンスを削除するか、VCDA保持ポリシーを調整することにより、異常に大きなインスタンスが作成された際にスペースをすぐに開放することができる。
スペースが解放された後に、リテンションポリシーをもとに戻すこともできる。 プロバイダはIAAS消費のあらゆる側面の監視と、テナント組織に割り当てられたストレージ量と使用されたストレージ量を確認できる
・保存されたインスタンスとは
VCDAにて保存されているインスタンスはデルタvmdkである
これらは保持サイクルから「取り出された」デルタであるため、リストアには親ディスクを使用する必要がある
VCDAのレプリケーションは、保存されたインスタンスとローテートされたインスタンス（mPITS）の両方を持つことができ、ポリシーによって制御される これらは、時間の経過とともに増加する継続的なデルタ（ソース親ディスクに近くなる）と比較して、リストアが比較的高速になる
※内容、翻訳に誤りがある際はご了承ください。
【vRLI】ログデータの移行について
vRLIの新バージョンを利用するにあたり、既存vRLIをアップグレードするのではなく新規vRLIを立てる場合などに、ログデータの移行が必要となる。
以下ドキュメントを実行することでアーカイブデータの移行はできる。
vRealize Log Insight アーカイブの vRealize Log Insight へのインポート
しかし、これのみではNFSにコピーされていない、書き込み中バケットのログが移行されない。
【vRLI】ログデータのアーカイブについて - いんふらブログ
そのため、全データを移行するためには以下のような手順が必要になる。
パターン1.
①既存vRLIにて新vRLIへのログ転送設定を追加
②最低500MB分のログが転送されるまで待機
③アーカイブを新vRLIにてインポート
パターン2.
①新vRLIへもログが送られるようにvCenter/ESXi/各種サーバーなどを設定
②最低500MB分のログが転送されるまで待機
③アーカイブを新vRLIにてインポート
上記手順における詳細設定方法
・ログ転送設定
新vRLIを指定した「ログの転送」を設定
・新vRLIへもログが送られるように設定
(例：ESXi)新vRLIにて統合設定するのみで可能
ESXi側でもsyslogの宛先が2台分になっていることが確認できる
[root@20-esxi-01:~] esxcli system syslog config get Allow Vsan Backing: false Check Certificate Revocation List: false Dropped Log File Rotation Size: 100 Dropped Log File Rotations: 10 Enforce SSLCertificates: true Local Log Output: /scratch/log Local Log Output Is Configured: false Local Log Output Is Persistent: true Local Logging Default Rotation Size: 1024 Local Logging Default Rotations: 8 Log Level: error Log To Unique Subdirectory: false Message Queue Drop Mark: 90 Remote Host: udp://172.16.20.100:514,udp://172.16.20.110:514 ←vRLI2台 Remote Host Connect Retry Delay: 180 Remote Host Maximum Message Length: 1024 Strict X509Compliance: false
・アーカイブのインポート
1.アーカイブ済みデータが保存された NFS サーバ上の共有フォルダをマウント # mount -t nfs 192.168.11.38:/share/vrli-imp /tmp/import/ 2.アーカイブ済み vRealize Log Insight ログのディレクトリをインポート # /usr/lib/loginsight/application/bin/loginsight repository import /tmp/import SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/usr/lib/loginsight/application/lib/lib/log4j-slf4j-impl-2.17.1.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/usr/lib/loginsight/application/lib/lib/ph-client-3.0.502006-all.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory] The operation is in progress and it may take some time. Added one-shot task for '/tmp/import' with filter list:'[]' with parser: default-imported
