NSX-T 3.2.0 以降における NSX UI アラームでのEdge VM の設定の「不一致」アラームのトラブルシューティング
search cancel

NSX-T 3.2.0 以降における NSX UI アラームでのEdge VM の設定の「不一致」アラームのトラブルシューティング

book

Article ID: 422329

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

免責事項：これは英文の記事「Troubleshooting Edge VM Configuration "Mismatch" Alarm(s) in NSX UI Alarm in NSX-T 3.2.0 and Onwards」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。

 

NSX-T 3.2.0 以降では、Edge 管理プレーン (MP) インテントの動作が変更されました。ユーザーが Edge CLI または vCenter 経由で一部の Edge ノード設定を直接更新した場合、これらの変更は Edge ノードの MP インテントに直接更新されません。このような場合、Edge ノード不一致(Mismatch)アラームがユーザーに通知されます。このアラームは、Edge CLI または vCenter で一部の Edge ノード設定が直接変更されたことをユーザーに通知します。NSX-T/NSX UI の Edge ノードの「設定」もこの不一致(Mismatch)に基づいて更新されます。Edge ノード不一致(Mismatch)アラームには、以下の 4 種類があります。

アラーム1: Edgeノードの設定が一致しません

EdgeノードCLIとEdgeノードMPインテントにおけるEdgeノードのパラメータが異なることが検出された場合、アラームが発生します。以下のEdgeノード設定フィールドのいずれかがEdgeCLIから直接変更された場合、このアラームが発生します。

Edgeノードの設定

  1. "Enable SSH"
  2. "DNS Servers"
  3. "Search domains"
  4. "NTP servers"
  5. "Host name"
  6. "Syslog Servers"
  7. "UPT_MODE" <<<< NSX 4.1.0以降、実現エラーとして追加されました

アラーム2: Edge VM vSphere設定の不一致(Mismatch)

vCenter内のEdgeノードのvSphereパラメータとEdgeノードのMPインテントが異なることが検出された場合、アラームが生成されます。ユーザーがvCenterを介してvSphere内で以下のいずれかのEdge設定を変更した場合、このアラームが生成されます。

EdgeVM vSphere設定

  1. "Display Name"
  2. "Compute Id"
  3. "Storage Id"
  4. "Management Network Id"
  5. "Data Networks Ids"
  6. "Form Factor"
  7. "CPU Reservation in shares"
  8. "CPU Reservation in MHz"
  9. "Memory Reservation percentage"

アラーム3: Edgeノード設定とvSphere設定が変更されました

vCenter の Edge ノード vSphere パラメータと Edge ノード CLI パラメータが Edge ノード MP の意図と異なることが検出された場合、アラームが生成されます。ユーザーが Edge CLI と vCenter の両方で「Edge ノード設定」と「Edge VM vSphere 設定」の両方から Edge フィールドを直接変更した場合、このアラームが生成されます。

アラーム4: EdgeとvSphereの設定の不一致(Mismatch)

ユーザーがvMotionを使用してEdge VMを移動すると、アラームが発生します。Edge VMを移動すると、vSphere内のEdge Nodeのデータストア（「ストレージID」）および／またはコンピューティングクラスタID（「コンピューティングID」）パラメータが変更されます。したがって、vCenterとEdge Node MPインテントにおけるこれらのEdge Node vSphere設定パラメータが異なることが判明した場合、アラームが発生します。したがって、以下のフィールドのいずれか（またはすべて）が変更された場合、このアラームが発生します。

  1. "Compute Id"
  2. "Storage Id"

「コンピューティング ID」と「ストレージ ID」以外に、「Edge VM vSphere 設定」または「Edge ノード設定」フィールドが変更された場合、変更されたフィールドに基づいて「Edge VM vSphere 設定の不一致(Mismatch)」アラームまたは「Edge ノード設定と vSphere 設定が変更されました」アラームが発生します。

NSX-T UI での不一致(Mismatch)アラームの表示

  • Edge不一致(Mismatch)アラームは、システム、ノード、Edge トランスポート ノードページに以下のように表示されます。
  • Edge不一致(Mismatch)アラームは、  NSX-T UI ホーム ページにも表示されます。

Environment

VMware NSX

Resolution

この問題は、 Broadcom ダウンロードから入手できる VMware NSX 4.2.1 で解決されています。

NSX 4.2.1 では自動更新機能が導入され、NSX Manager は Edge のインテント構成を実際の構成と一致するように自動的に更新します。不一致アラームは生成されません。

注: NSX 4.2.0 から 4.2.1.x へのアップグレードでは、自動更新機能が有効にならず、不一致アラームが生成されるという既知の問題があります。
この場合、API 経由でこの機能を有効にする必要があります。

この機能が有効になっているかどうかを確認します。
GET https://{manager-ip}/policy/api/v1/system-config?key=auto_refresh_edge_transport_nodes

この機能を有効にします。
PATCH https://{manager-ip}/policy/api/v1/system-config
{
    "keyValuePairs": [
        {
            "key": "auto_refresh_edge_transport_nodes",
            "value": "true"
        }
    ]
}

NSX 4.2.1より前のリリースでは、アラームを解決(Resolve)するためのアクションを実行する必要があります。

オプション1（推奨）

  •  以下に示すように、Edge ノードの 設定の不一致(Mismatch)を選択します 。
  • すると、以下に示すようなポップアップ ウィンドウが開きます。
  • ソース として 「vSphere/Edge Appliance」を選択し 、  「解決(Resolve)」をクリックします。これにより、不一致アラームが解消されます。この操作は、Edgeノード更新APIを内部的に実行します。Edgeノード更新APIは、Edgeノードからの最新データでEdgeノードのMPインテントを更新し、不一致アラームを解消します。
  • この方法でアラームを解決(Resolve)すると、実際の Edge ノード構成 (CLI または vCenter 上) が Edge ノード MP インテントへコピーされます。

オプション2（あまり好ましくない） 

  •  以下に示すように、Edge ノードの 設定の不一致(Mismatch)を選択します 。
  •  すると、以下に示すようなポップアップ ウィンドウが開きます。
  • ソース として 「NSX」を選択し 、  「解決(Resolve)」をクリックします。これにより、不一致アラームが解消されます。この操作は、Edgeノード更新APIを内部的に実行します。このAPIは、MPからEdgeノードへのEdgeノード構成を実現します。 警告：コンピューティングID/ストレージIDフィールドに不一致がある場合、ソースとして「NSX」を選択すると、Edgeノードが再デプロイされ、トラフィックが中断されます。トラフィック中断に関する警告メッセージが表示されます。




  • この場合、vSphere 内の Edge VM は、その構成が NSX によって認識され、展開時に定義された意図の構成と一致するように更新されます。

特定のコーナーケース

特定のコーナーケースでは、上記のアプローチ 1 またはアプローチ 2 ではアラームが解決されない場合があります。このような場合は、以下の手順に従ってアラームを手動で解決してください。

ケース1: Edge-MPの管理コンポーネントからアラームが解決されない

  • Edgeトランスポートノード状態APIの出力を確認します: GET https://<manager-ip>/api/v1/transport-nodes/<edge-uuid>/state
  • Edgeトランスポートノード状態APIの「node_deployment_state」が不一致の場合、以下のように表示されます。この場合、不一致は依然として存在します。  
{
  "node_deployment_state": {
    "state": "EDGE_VM_VSPHERE_SETTINGS_MISMATCH_RESOLVE",
    "details": [
      {
        "sub_system_id": "EDGE_TRANSPORT_NODE_MISMATCH_ALARMS",
        "state": "EDGE_VM_VSPHERE_SETTINGS_MISMATCH_RESOLVE",
        "failure_message": " configuration on vSphere : {\"CPU Reservation in shares\":\"NORMAL_PRIORITY\",\"Storage Id\":\"datastore-14\"}, intent vSphere configuration :{\"CPU Reservation in shares\":\"LOW_PRIORITY\",\"Storage Id\":\"datastore-50\"}",
        "failure_code": 16087
      }
    ],
    "failure_message": "",
    "failure_code": 0
  }
}
  • この不一致を解決するには、リフレッシュ API を実行します (リフレッシュ API にはリクエスト本文は必要ありません)。POST https://<manager-ip>/api/v1/transport-nodes/<edge-uuid>?action=refresh_node_configuration&resource_type=EdgeNode
  • 次に、Edge トランスポート ノード状態 API の出力を再度確認します: GET https://<manager-ip>/api/v1/transport-nodes/<edge-uuid>/state この Edge トランスポート ノード状態 API で、Edge トランスポート ノードの "node_deployment_state" が NODE_READY の場合、Edge-MP の管理コンポーネントから不一致が解決されたと言えます。
{
  "node_deployment_state": {
    "state": "NODE_READY",
    "details": []
  }
}
  • 「node_deployment_state」が依然として不一致の場合、Edge ノード MP の意図と CLI または vCenter で実現された Edge ノード構成の間に不一致が実際に存在します。

ケース2: アラームはEdge-MPの管理コンポーネントから解決されるが、アラームフレームワーク側からは解決されない

  • Edgeトランスポートノード状態 API の出力を確認します: GET https://<manager-ip>/api/v1/transport-nodes/<edge-uuid>/state
  • このAPI出力では、Edgeトランスポートノードの「node_deployment_state」がNODE_READYになっています。これは、Edge-MPの設定の不一致が解決されたことを意味します。
{
  "node_deployment_state": {
    "state": "NODE_READY",
    "details": []
  }
}
  • 次に、アラーム API を使用して、不一致アラームがまだ OPEN かどうかを確認します:  GET https://<manager-ip>/api/v1/alarms?status=OPEN
  • このアラームAPIが不一致アラームを「OPEN」と表示した場合、この不一致アラームを手動で解決する必要があります。Edge-MP設定は不一致を解決しましたが、アラームフレームワークはアラームを解決できなかったためです。
  • アラームを手動で解決するには、「アラーム」から「Edge設定の不一致(Mismatch)」を選択し「アクション(Actions)」→「確認(Acknowledge)」を選択します。これは、システム、ファブリック、ノード、またはホーム、アラームから実行できます（以下の画像を参照）。
 
 

ケース3: NSX Edge VMがvCenter内で手動で編集/移行され、その後、古いクラスタ/データストア/ポートグループ（NSX Managerが認識しているもの）が削除された場合

  • このシナリオでは、NSX Edge を再デプロイする必要があります。
    1. NSX UI で正しい設定を使用して新しい NSX Edge VM を展開します。NSX Edge ノードを展開します。
    2. Edge クラスタ内の障害のある NSX Edge VM を新しい VM に置き換えます。NSX Manager UI を使用して NSX Edge トランスポート ノードを置き換えます。
    3. 元の FQDN と IP アドレスを保持する場合は、障害のある NSX Edge VM を削除した後、手順 1 に従って元の設定で新しい NSX Edge VM を作成し、手順 2 に従ってそれを一時的な Edge VM に置き換えることができます。

Additional Information

注: 「Edgeノード MP インテント」という用語は、NSX-T Manager データベースに存在するEdgeトランスポートノードの構成データを指します。このEdgeトランスポートノードに対して GET 呼び出しを実行すると、ペイロードと同じデータが取得されます（例: GET https://<manager-ip>/api/v1/transport-nodes/<edge-tn-id>）。

NSX 4.1.1 以降では、Edge メンテナンス モードが有効になっている場合でも、UPT モードを編集できます。

UPT モード実現の一環として、Edge VM でメンテナンス モードが切り替えられます。

メンテナンスモードが有効になっているEdgeでUPTモードを編集した場合、UPTの実現が完了する前にメンテナンスモードを無効にする必要があります。Edgeでメンテナンスモードが有効になっている場合、UPTが部分的に実現されると不一致アラームが発生します。このアラームは、ユーザーがEdgeでメンテナンスモードを無効にすると、NSX値を使用して解決されます。 

関連するKB記事

Powered by Wolken Software