Azure 操作員 Nexus 實例整備測試 （IRT）

實例整備測試 （IRT） 架構是 Nexus 平台的選擇性/附加元件工具。 它可讓操作員確認工作負載部署的 Azure 操作員 Nexus 實例成功部署和整備程度。 此驗證同時適用於初始部署和後續的 Nexus 升級。 它會執行一系列測試，並以 HTML 報表的形式提供測試結果。

重點優勢

• 自助式
  • IRT 可讓用戶獨立起始和執行測試。
• 重複
  • 使用者可以多次在 Nexus 實例上執行 IRT，以確認測試結果的可靠性與一致性。
• 能力
  • IRT 提供所有運算符可以使用的泛型功能。
  • 它會啟用新 Nexus 部署和升級后狀態的驗證。
  • 它允許測試網路函式基礎結構元件。
  • 它有助於工作負載部署。
  • 使用者會使用命令列和輸入檔來執行 IRT 測試架構。 架構接著會在客戶的訂用帳戶中建立 Azure 容器實例。

使用 IRT 執行的測試

• 驗證網狀架構訂用帳戶和資源群組中的 l3 網域存在於測試中資源的所有測試完成之後。
• 驗證在測試資源群組中建立 l3 網路之後，測試資源群組中的所有測試都已完成。
• 驗證裸機的 NodeOsInfo 計量數據是否出現在過去 10 分鐘內。 每個計數計量都應該大於 0。
• 驗證 IdracPowerOn 計量數據在最近 10 分鐘內是否存在。 每個計數計量都應該大於 0。
• 驗證 CorednsDnsRequestsTotal 計量數據是否出現在過去 10 分鐘內。 每個平均計量都應該大於 0。
• 驗證 FelixClusterNumHosts 計量數據是否出現在過去 10 分鐘內。 每個平均計量都應該大於 0。
• 驗證 Typha 連線 ionsAccepted 計量數據出現在過去 10 分鐘內。 每個平均計量都應該大於 0。
• 驗證 KubeDaemonsetStatusCurrentNumberScheduled 計量數據在過去 10 分鐘內是否存在。 每個平均計量都應該大於 0。
• 驗證 EtcdServerIsLeader 計量數據是否出現在過去 10 分鐘內。 每個平均計量都應該大於 0。
• 驗證 ApiserverAuditRequestsRejectedTotal 計量數據在過去 10 分鐘內是否存在。 至少應該有一次次數據輸入。
• 驗證 KubevirtInfo 計量數據在過去 10 分鐘內是否存在。 每個平均計量都應該大於 0。
• 驗證 ContainerMemoryUsageBytes 計量數據是否出現在過去 10 分鐘內。 每個平均計量都應該大於 0。
• 驗證 KubeletRunningPods 計量數據是否出現在過去 10 分鐘內。 每個平均計量都應該大於 0。
• 驗證網狀架構網路裝置的 CpuUtilizationMax 計量數據是否在過去 10 分鐘記憶體在。 至少應該有一個非零的計量存在。
• 驗證 MemoryAvailable 計量數據是否出現在過去 10 分鐘內。 至少應該有一個非零的計量存在。
• 使用 iPerf3 和 ARM 範本中的親和性設定，測試兩部虛擬機器之間的 IPv4 TCP 數據傳輸。 測試可確保數據輸送量超過 60 Mbps。
• 使用 iPerf3 和 ARM 範本中的同質設定，測試兩部虛擬機之間的 IPv6 TCP 資料傳輸。 測試可確保數據輸送量超過 60 Mbps。
• 使用 iPerf3 和 ARM 範本中的親和性設定，測試兩部虛擬機之間的 IPV4 UDP 數據傳輸。 測試可確保數據輸送量超過 1 Mbps。
• 使用 iPerf3 和 ARM 範本中的親和性設定，測試兩部虛擬機之間的 IPV6 UDP 數據傳輸。 測試可確保數據輸送量超過 1 Mbps。
• 使用 ARM 範本中的 iPerf3 和反親和性設定，測試兩部虛擬機之間的 IPV4 TCP 數據傳輸。 測試可確保數據輸送量超過 60 Mbps。
• 使用 IPerf3 和 ARM 範本中的反親和性設定，測試兩部虛擬機之間的 IPV6 TCP 數據傳輸。 測試可確保數據輸送量超過 60 Mbps。
• 使用 ARM 範本中的 iPerf3 和反親和性設定，測試兩部虛擬機之間的 IPV4 UDP 數據傳輸。 測試可確保數據輸送量超過 1 Mbps。
• 使用 IPerf3 和 ARM 範本中的反親和性設定，測試兩部虛擬機之間的 IPV6 UDP 數據傳輸。 測試可確保數據輸送量超過 1 Mbps。
• 測試兩部已啟用大型畫面格的虛擬機之間的IPv4 Ping。 Stderr 應該是空的，而且不應觀察到封包遺失。
• 在兩部已啟用大型畫面格的虛擬機之間測試 IPv6 ping。 Stderr 應該是空的，而且不應觀察到封包遺失。
• 驗證 IPV4 路由已正確設定。
• 驗證 IPV6 路由已正確設定。
• 驗證網路介面是否如預期般設定。
• 使用 nslookup 驗證 DNS 解析 Azure 入口網站 端點的能力。
• 針對 vlan 在 NAKS 叢集內的 L2 介面上驗證 dpdk-testpmd。
• 在 NAKS 叢集內的 L2 介面上驗證 dpdk-testpmd，並針對 vlan 擷取的數據。
• 在 NAKS 叢集內主幹介面上驗證 dpdk-testpmd，並針對主幹擷取的數據。
• 在 NAKS 叢集內的 L3 介面上驗證 dpdk-testpmd，並針對 L3 網路擷取的數據。
• 驗證 NAKS 叢集中所有 Pod 的狀態，以處於「已完成」或「執行中」狀態。
• 測試 NAKS 叢集 Pod 與已啟用巨型畫面格的 VM 之間的 IPv4 Ping。 Stderr 應該是空的，而且不應觀察到封包遺失。
• 在已啟用大型畫面格的 NAKS 叢集 Pod 與 VM 之間測試 IPv6 ping。 Stderr 應該是空的，而且不應觀察到封包遺失。
• 驗證 PersistentVolumeClaim 已成功建立。
• 驗證 PersistentVolume 已成功建立。
• 測試使用 volumeMode Block 和 accessMode RWO 建立PVC。
• 驗證已新增的所有 nexus 共用和 nexus-volume 磁碟區都掛接在 sts 0 中。
• 驗證已新增的所有 nexus 共用和 nexus-volume 磁碟區都掛接在 sts 1 中。
• 驗證掛接在 sts 0 上的 nfs 記憶體是否可寫入。
• 驗證寫入 sts 0 的 nfs 記憶體檔案是否可讀取。
• 驗證 sts 0 上掛接的共用 nfs 記憶體是否可寫入。
• 驗證寫入 sts 0 的共享 nfs 檔案是否可讀取。
• 驗證掛接在 sts 1 上的 nfs 記憶體是否可寫入。
• 驗證寫入 sts 0 的共享檔案是否可以在 sts 1 中讀取。
• 驗證 sts 1 上掛接的共用 nfs 記憶體是否可寫入。
• 驗證寫入 sts 0 和 sts 1 的共享檔案可以從 sts 1 讀取。
• 驗證以 sts 0 和 sts 1 寫入的共用檔案是否可以從 sts 0 讀取。
• 驗證已掛接並寫入區塊記憶體。
• 驗證已掛接區塊記憶體，而且可以讀取。
• 驗證已掛接並寫入區塊記憶體。
• 驗證已掛接區塊記憶體，而且可以讀取。
• 先驗證刪除PVC，再使用它移除 Pod（相應減少 sts），移除 Pod naks-storage-statefulset-1。
• 驗證可以刪除封鎖 儲存體 PVC。

如何執行 IRT

IRT 需要存取 GitHub Nexus-Samples 存放庫中裝載的軟體套件。 用戶應該流覽至 [發行] 區段，然後選擇具有 [最新] 卷標的發行。 此自述文件複本也可在發行套件內取得，以便於執行環境中方便參考。

要求存取 nexus-samples GitHub 存放庫

---

若要存取 nexus-samples GitHub 存放庫

1. 將您的 GitHub 帳戶連結至 Microsoft GitHub 組織 https://repos.opensource.microsoft.com/link

2. 加入 Microsoft 組織 https://repos.opensource.microsoft.com/orgs/Microsoft/join

3. 傳送要新增至 nexus-samples GitHub 存放庫的電子郵件要求 afoncamalgamatesall@microsoft.com

環境需求

• 能夠呼叫 Azure API 的 Linux 環境（建議使用 Ubuntu）。
• 支援其他Linux散發版本，例如 RedHat、Mariner 等，取決於能夠安裝必要的工具。 請參閱 安裝相依性 一節。
  • 已安裝必要套件的任何計算機都應該能夠使用腳本。
• 要用於測試的網路知識。
  • 要用於測試的網路是在「networks-blueprint.yml」檔案中指定，請參閱 輸入組態。
• 下載 IRT 發行套件的方式，例如 curl、wget 等。
• 能夠建立具有正確角色的服務主體。
• 從 KeyVault 讀取秘密的能力，請參閱 服務主體 一節以取得詳細數據。
• 能夠在 Active Directory 租使用者中建立安全組。

輸入組態

從建置您的輸入檔案開始。 IRT tarball 提供 irt-input.example.yml 作為範例。 依照 指示下載 tarball。 範例值 不適用於您的實例。 您必須手動變更它們，並將檔案重新命名為 irt-input.yml。 我們會提供範例輸入檔作為存根，以協助您設定新的輸入檔。 此範例概述可覆寫的值及其使用方式。 「一次性設定」會藉由在組態檔執行時，將機碼/值組寫入組態檔，協助您設定輸入值。

您可以在檔案中 networks-blueprint.yml 提供網路資訊，類似於 networks-blueprint.example.yml 我們提供的網路資訊，或將它附加至 irt-input.yml 檔案。 networks-blueprint.example.yml定義 IRT 的架構。 測試會建立網路，因此請提供未使用中的網路詳細數據。 目前，IRT 具有下列網路需求：

• 三 （3） L3 網路
  • 其中兩個 （2） 與 MTU 1500
  • 其中一個 （1） 具有 MTU 9000，不應該有fabric_asn屬性
• 一個 （1） 主幹網路
• 所有 VLAN 都應該大於 500

一次性設定

下載 IRT

IRT 會透過 tarball 從 nexus-samples GitHub 存放庫的發行區段散發。

1. 尋找標示為「最新」的發行套件、加以下載、解壓縮並瀏覽至 irt 目錄。
2. 將 tarball 解壓縮到本機文件系統： mkdir -p irt && tar xf nexus-irt.tar.gz --directory ./irt。
3. 切換到新的目錄 cd irt。
4. 如需任何值得注意的更新或變更，請參閱 RELEASE-CHANGELOG.md。

安裝相依性

執行期間應該有多個相依性可供使用。 檢閱這份清單;

• jq 1.6 版或更新版本
• yq 4.33 版或更新版本
• azcopy 版本 10 或更新版本
• az Azure CLI，保持最新狀態。 最低預期版本：2.11.0（支援自我升級）
• elinks - 用於在命令列上檢視 HTML 檔案 （選擇性）
• tree - 用於檢視目錄結構
• moreutils - 用於檢視 Azure 容器實例 （ACI） 容器的進度

提供 setup.sh 腳本來協助安裝列出的相依性。 它會安裝PATH中未提供的任何相依性。 它不會升級不符合最低必要版本的任何相依性。

注意

setup.sh 假設非根用戶並嘗試使用 sudo

All-In-One 安裝程式（建議）

all-in-one-setup.sh 會提供 來建立執行 IRT 所需的所有 Azure 資源。 此程式包括建立服務主體、安全組和隔離網域。 中呼叫 all-in-one-setup.sh 的每個腳本都可以個別執行。 這些腳本會使用您建立的資源所需的機碼/值組，將更新寫入檔案 irt-input.yml 。 irt-input.example.yml不論您選擇的方法為何，檢閱一或多個腳本所需的輸入檔案。 所有腳本都是等冪的，並可讓您視需要使用現有的資源。

逐步設定

注意

只有在您未使用 all-in-one.setup.sh 時，才使用本節

如果您的工作流程與 all-in-one-setup.sh不相容，可以使用每個補充腳本手動建立 IRT 所需的每個資源。 如同 all-in-one-setup.sh，執行這些文稿會將索引鍵/值組寫入您的 irt-input.yml ，以供您在執行期間使用。 這四個 all-in-one-setup.sh 腳本構成腳本。

IRT 會針對您的資源發出命令，而且需要執行此動作的許可權。 IRT 需要服務主體才能執行。 它也要求服務主體是 Azure AD 安全組的成員，也提供做為輸入。

驗證和運行時間許可權

IRT 需要具有正確許可權的服務主體，才能與各種 Azure 和 NetworkCloud 資源互動。

建立服務主體和安全組

補充腳本會建立具有自定義角色NRT Roles的服務主體，create-service-principal.sh或將角色NRT Roles與現有的服務主體產生關聯。

此外，腳本會建立必要的安全組，並將服務主體新增至安全組。 如果安全組存在，它會將服務主體新增至現有的安全組。

執行 create-service-principal.sh 需要輸入 yaml 具有下列值。 您可以藉由設定對應的環境變數來覆寫所有值：

SERVICE_PRINCIPAL:
  NAME: "<name>" # env: SERVICE_PRINCIPAL_NAME
  AAD_GROUP_NAME: "<aad-group-name>" # env: SERVICE_PRINCIPAL_AAD_GROUP_NAME
  SUBSCRIPTION: "<subscription>" # env: SERVICE_PRINCIPAL_SUBSCRIPTION
  KV_NAME: "<keyvault>" # env: SERVICE_PRINCIPAL_KV_NAME
  KV_ID: <keyvault-secret> # env: SERVICE_PRINCIPAL_KV_ID

• SERVICE_PRINCIPAL.NAME - 使用 命令建立 az ad sp create-for-rbac 的服務主體名稱。
• SERVICE_PRINCIPAL.AAD_GROUP_NAME - 安全組的名稱。
• SERVICE_PRINCIPAL.SUBSCRIPTION - 服務主體的訂用帳戶。
• SERVICE_PRINCIPAL.KV_NAME - 用來儲存服務主體密碼的 KeyVault。
• SERVICE_PRINCIPAL.KV_ID - 儲存服務主體密碼的 KeyVault 秘密。

注意

在執行 之前 create-service-principal.sh，請確定您已使用虛擬值建立 KeyVault （KV_NAME） 和/或秘密 （KV_ID）。 az login使用者（執行 IRT 的人員）也應該獲授與此 KeyVault 的存取權，以便在運行時間提取秘密。

# Example execution of the script
./create-service-principal.sh irt-input.yml

注意

如果 yaml 中設定所有 SP_ID、SP_OBJECT_ID、SP_TENANT_ID、、ADMIN_GROUP_OBJECT_ID，KV_NAME則KV_ID 腳本會略過建立它們。

結果：此腳本會列印 、SP_ID、SP_OBJECT_ID、SP_TENANT、 KV_NAME和 KV_ID的值ADMIN_GROUP_OBJECT_ID。 腳本會將值設定回輸入 yaml。 請參閱 輸入組態。

SP_ID: "<generated-sp-id>"
SP_OBJECT_ID: "<generated-sp-object-id>"
SP_TENANT_ID: "<generated-sp-tenant-id>"
ADMIN_GROUP_OBJECT_ID: "<generated-aad-group-id>"
KV_NAME: "<provided-key-vault-name>" # If SP already exists please fill it in to retrieve the SP Password.
KV_ID: "<provided-key-vault-secret>" # If SP already exists please fill it in to retrieve the SP Password.

建立自定義角色以執行

如果您有現有的服務主體，而且想要只指派一個角色來執行 IRT 的便利性，您可以遵循本節中的指示。

必要條件

• Azure 訂用帳戶
  • 請確定您有 Azure 訂用帳戶的存取權。
• Azure CLI
  • 確定您的本機計算機上存在 Azure CLI

步驟

1. 準備您的環境

   1. 開啟 Bash 殼層：
   2. 您可以使用任何支援 Bash 的終端機

2. 登入 Azure

   1. 執行下列命令以登入您的 Azure 帳戶：

   # Start az CLI session
   az login
   
   # Set active subscription using the UUID
   az account set --subscription "<your-subscription-id>"
   

3. 部署範本

   執行下列命令來部署ARM範本。 將範例變數值取代為您的實際值：

   # Set our variable values, these values are for the sake of example. Replace these values with your own as needed.
   location="eastus"
   deploymentName="IRTRoleDefinitionDeployment"
   templatePath="framework-templates/service-principal-roles.jsonc" # Path to the template file assuming the PWD is the root of the artifact tar
   roleName="Nexus Instance Readiness Tester"
   
   # run deployment
   az deployment sub create \
       --name "$deploymentName" \
       --location "$location" \
       --template-file "$templatePath" \
       --parameters roleName="$roleName"
   

4. 將角色指派給用於測試的應用程式服務主體

   透過一對一設定建立的天氣，或使用您自己的設定，將新建立的角色指派給您的身分識別。 此單一角色提供執行實例整備測試所需的所有授權。

    # The Application ID of your Service Principal for your application
    appId="00001111-aaaa-2222-bbbb-3333cccc4444"
    # this MUST match the deployment name used above.
    deploymentName="IRTRoleDefinitionDeployment"
   
    # This command gets the name of GUID of the role
    # az role definition list --name "$roleName" --query "[0].id" --output tsv | awk -F'/' '{print $NF}'
   
    # This command gets the GUID of the subscription
    # az account show --query id --output tsv --only-show-errors
   
    # Put together we create the role assignment;
    az role assignment create \
      --assignee "$appId" \
      --subscription "$(az account show --query id --output tsv --only-show-errors)" \
      --role "$(az role definition list --name "$roleName" --query "[0].id" --output tsv | awk -F'/' '{print $NF}')" \
      --scope "/subscriptions/$(az account show --query id --output tsv --only-show-errors)"
   
   

建立 L3 隔離網域

測試架構不會建立、終結或操作隔離網域。 因此，現有的隔離網域可用於執行。 每個隔離網域至少需要一個外部網路。 補充文稿 create-l3-isolation-domains.sh 例如，L3、主幹等內部網路會透過測試課程建立、操作和終結。

執行 create-l3-isolation-domains.sh 需要一個 參數，這是包含網路需求的檔案路徑。 您可以根據工作流程選擇獨立network-blueprint.yml或input.yml，也可以包含所需的資訊。

# Example of the script being invoked using networks-blueprint.yml:
./create-l3-isolation-domains.sh networks-blueprint.yml

# Example of the script being invoked using irt-input.yml:
# the network-blueprint should exist under NETWORK_BLUEPRINT node.
./create-l3-isolation-domains.sh irt-input.yml

執行

• 此範例假設irt-input.yml與 irt.sh 位於相同的位置。如果您的檔案位於不同的目錄中，請提供完整的檔案路徑。

./irt.sh irt-input.yml

如何讀取 IRT 摘要結果

IRT 摘要頁面是在 IRT 執行之後產生的 HTML 頁面，可從任何瀏覽器檢視。

IRT 摘要頁面包含三個主要區段，可展開以提供更多詳細數據。

• 測試結果

• 偵錯區段

• Extras 區段

[摘要結果] 頂端會顯示 IRT 測試套件中執行的 [測試總計]、[額外] 區段數目和通過和失敗的測試總數，以及百分比值。

注意

測試總數取決於所執行的 IRT 版本、不同的必要條件測試命令，因此總計不一定相同。

如果測試中有任何失敗，則值會據以表示。

測試結果

[測試結果] 區段提供 IRT 執行的所有測試（判斷提示）。 [判斷提示程式] 區段會展開以檢視執行且可用的測試清單。 每個判斷提示可以進一步展開，以載入雅閣窗格，其中提供判斷提示的詳細數據，包括測試的描述，以及要針對之測量和判斷提示的任何臨界值。

顯示測試結果

顯示具有所有成功測試的 [測試結果] 區段：

如果有任何失敗，則判斷提示會以紅色反白顯示。

解譯判斷提示

每個判斷提示者都會提供測試的重要標題，以及標準記錄檔下的描述。

Asserter 的範例：

判斷提示者 [It] res-test-dpdk-naks-84f5b - network： 'l3network-704' （PMD） 平均 Rx-pps [17668558] 應大於 800000。

上述判斷提示範例會讀取為 l3network-704 的 Rx（receive）-pps（每秒封包數）17668558，大於預期的 8000000。

失敗的判斷提示會以紅色顯示，且 Rx-pps 值應該小於收到的 8000000 pps 值。 錯誤會顯示在 [錯誤訊息] 索引標籤底下。

偵錯區段

偵錯區段可用來找出判斷提示/測試失敗的原因以進行偵錯。 它包含四個測試套件，每個套件都包含擴充以提供詳細數據的套件相關測試。 任何特定測試的失敗會以紅色反白顯示。

• 安裝套件：

  • 設定測試執行，並部署 Nexus 資源，如架構和測試所需的 ARM 範本中所定義。

• 插入套件：

  • 插入必要的環境變數和測試數據，以支援 NAKS 資源的測試

• 收集套件：

  • 收集套件會收集安裝程式套件所發行的數據。

• 清除套件：

  • 刪除收集數據之後針對測試建立的 Nexus 資源。

Extras 區段

本節僅供參考，可提供 Nexus 實例的額外詳細數據。 沒有代表本節的判斷提示/測試。 其目的是要協助使用者在 IRT 執行 IRT 之後，檢查基礎叢集資源和租用戶資源的狀態。

Extras 區段是由分別執行兩個不同的腳本檔案所顯示的結果所組成。

• 平台驗證結果：

  • 顯示雲端部署資源詳細數據及其目前狀態下的 Nexus，包括叢集管理員詳細數據及其延伸模組、網狀架構相關詳細數據、Nexus 叢集及其擴充功能、BareMetal Machines、Arc 相關，以及 儲存體 設備。

• 租使用者工作負載驗證結果：

  • 顯示 Nexus 租使用者資源詳細數據及其在 Nexus 叢集上執行的目前狀態，包括顯示 L2 和 L3 隔離網域、雲端服務網路、預設 cni 網路、L2 和 L3 網路、主幹網路、可用的 VM 清單。

疑難排解

具有失敗的判斷提示和偵錯區段是解決失敗和技術問題的有效疑難解答方法。

如果您仍有問題， 請連絡支持人員。 如需支援方案的詳細資訊，請參閱 Azure 支援方案。