12.2. OpenShift Virtualization クラスター検査フレームワーク
OpenShift Virtualization には、クラスターのメンテナンスとトラブルシューティングに使用できる次の定義済み検査が組み込まれています。
レイテンシー検査。ネットワーク接続を検証し、セカンダリーネットワークインターフェイスに接続された 2 つの仮想マシン (VM) 間のレイテンシーを測定します。
重要レイテンシー検査を実行する前に、まずクラスターノードに ブリッジインターフェイスを作成 して、仮想マシンのセカンダリーインターフェイスをノード上の任意のインターフェイスに接続する必要があります。ブリッジインターフェイスを作成しないと、仮想マシンが起動せず、ジョブが失敗します。
- ストレージ検査。クラスターストレージが OpenShift Virtualization に合わせて最適に設定されているかどうかを確認します。
- DPDK 検査。ノードが Data Plane Development Kit (DPDK) ワークロードを使用して仮想マシンをパケット損失なしで実行できることを確認します。
OpenShift Virtualization クラスター検査フレームワークはテクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
12.2.1. OpenShift Virtualization クラスター検査フレームワークについて
チェックアップは、特定のクラスター機能が期待どおりに機能するかどうかを確認できる自動テストワークロードです。クラスター検査フレームワークは、ネイティブの Kubernetes リソースを使用して、チェックアップを設定および実行します。
事前定義されたチェックアップを使用することで、クラスター管理者はクラスターの保守性を向上させ、予期しない動作をトラブルシューティングし、エラーを最小限に抑え、時間を節約できます。また、チェックアップの結果を確認し、専門家と共有してさらに分析することもできます。ベンダーは、提供する機能やサービスのチェックアップを作成して公開し、顧客環境が正しく設定されていることを確認できます。
既存の namespace で事前定義されたチェックアップを実行するには、チェックアップ用のサービスアカウントの設定、サービスアカウント用の Role
および RoleBinding
オブジェクトの作成、チェックアップのパーミッションの有効化、入力 config map とチェックアップジョブの作成が含まれます。チェックアップは複数回実行できます。
以下が常に必要になります。
- チェックアップイメージを適用する前に、信頼できるソースからのものであることを確認します。
-
Role
およびRoleBinding
オブジェクトを作成する前に、チェックアップパーミッションを確認してください。
12.2.2. Web コンソールを使用した検査の実行
Web コンソールを使用して初めて検査を実行する場合は、次の手順に従います。追加の検査については、いずれかの検査タブで Run checkup をクリックし、ドロップダウンメニューから適切な検査を選択します。
12.2.2.1. Web コンソールを使用したレイテンシー検査の実行
レイテンシー検査を実行して、ネットワーク接続を確認し、セカンダリーネットワークインターフェイスに接続された 2 つの仮想マシン間のレイテンシーを測定します。
前提条件
-
namespace に
NetworkAttachmentDefinition
を追加する必要があります。
手順
-
Web コンソールで Virtualization
Checkups に移動します。 - Network latency タブをクリックします。
- Install permissions をクリックします。
- Run checkup をクリックします。
- Name フィールドに検査の名前を入力します。
- ドロップダウンメニューから NetworkAttachmentDefinition を選択します。
- オプション: Sample duration (seconds) フィールドでレイテンシーサンプルの期間を設定します。
- オプション: Set maximum desired latency (milliseconds) を有効にして時間間隔を定義し、最大遅延時間間隔を定義します。
- オプション: Select nodes を有効にし、Source node と Target node を指定して、特定のノードをターゲットにします。
- Run をクリックします。
レイテンシー検査のステータスは、Latency checkup タブの Checkups リストで確認できます。詳細は、検査名をクリックしてください。
12.2.2.2. Web コンソールを使用したストレージ検査の実行
ストレージ検査を実行して、仮想マシンのストレージが正しく動作していることを確認します。
手順
-
Web コンソールで Virtualization
Checkups に移動します。 - Storage タブをクリックします。
- Install permissions をクリックします。
- Run checkup をクリックします。
- Name フィールドに検査の名前を入力します。
- Timeout (minutes) フィールドに検査のタイムアウト値を入力します。
- Run をクリックします。
ストレージチェックアップのステータスは、Storage タブの Checkups リストで確認できます。詳細は、検査名をクリックしてください。
12.2.3. コマンドラインを使用した検査の実行
コマンドラインを使用して初めて検査を実行する場合は、次の手順に従います。
12.2.3.1. コマンドラインを使用したレイテンシー検査の実行
定義済みのチェックアップを使用して、ネットワーク接続を確認し、セカンダリーネットワークインターフェイスに接続されている 2 つの仮想マシン (VM) 間の待機時間を測定します。レイテンシーチェックアップでは ping ユーティリティーを使用します。
次の手順でレイテンシーチェックアップを実行します。
- サービスアカウント、ロール、ロールバインディングを作成して、レイテンシーチェックアップへのクラスターアクセス権を提供します。
- config map を作成し、チェックアップを実行して結果を保存するための入力を行います。
- チェックアップを実行するジョブを作成します。
- config map で結果を確認します。
- オプション: チェックアップを再実行するには、既存の config map とジョブを削除し、新しい config map とジョブを作成します。
- 完了したら、レイテンシーチェックアップリソースを削除します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - クラスターには少なくとも 2 つのワーカーノードがあります。
- namespace のネットワーク接続定義を設定しました。
手順
レイテンシーチェックアップ用の
ServiceAccount
、Role
、RoleBinding
マニフェストを作成します。例12.1 ロールマニフェストファイルの例
--- apiVersion: v1 kind: ServiceAccount metadata: name: vm-latency-checkup-sa --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: kubevirt-vm-latency-checker rules: - apiGroups: ["kubevirt.io"] resources: ["virtualmachineinstances"] verbs: ["get", "create", "delete"] - apiGroups: ["subresources.kubevirt.io"] resources: ["virtualmachineinstances/console"] verbs: ["get"] - apiGroups: ["k8s.cni.cncf.io"] resources: ["network-attachment-definitions"] verbs: ["get"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: kubevirt-vm-latency-checker subjects: - kind: ServiceAccount name: vm-latency-checkup-sa roleRef: kind: Role name: kubevirt-vm-latency-checker apiGroup: rbac.authorization.k8s.io --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: kiagnose-configmap-access rules: - apiGroups: [ "" ] resources: [ "configmaps" ] verbs: ["get", "update"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: kiagnose-configmap-access subjects: - kind: ServiceAccount name: vm-latency-checkup-sa roleRef: kind: Role name: kiagnose-configmap-access apiGroup: rbac.authorization.k8s.io
ServiceAccount
、Role
、RoleBinding
マニフェストを適用します。$ oc apply -n <target_namespace> -f <latency_sa_roles_rolebinding>.yaml 1
- 1
<target_namespace>
は、チェックアップを実行する namespace です。これは、NetworkAttachmentDefinition
オブジェクトが存在する既存の namespace である必要があります。
チェックアップの入力パラメーターを含む
ConfigMap
マニフェストを作成します。入力 config map の例
apiVersion: v1 kind: ConfigMap metadata: name: kubevirt-vm-latency-checkup-config labels: kiagnose/checkup-type: kubevirt-vm-latency data: spec.timeout: 5m spec.param.networkAttachmentDefinitionNamespace: <target_namespace> spec.param.networkAttachmentDefinitionName: "blue-network" 1 spec.param.maxDesiredLatencyMilliseconds: "10" 2 spec.param.sampleDurationSeconds: "5" 3 spec.param.sourceNode: "worker1" 4 spec.param.targetNode: "worker2" 5
ターゲット namespace に config map マニフェストを適用します。
$ oc apply -n <target_namespace> -f <latency_config_map>.yaml
チェックアップを実行する
Job
マニフェストを作成します。ジョブマニフェストの例
apiVersion: batch/v1 kind: Job metadata: name: kubevirt-vm-latency-checkup labels: kiagnose/checkup-type: kubevirt-vm-latency spec: backoffLimit: 0 template: spec: serviceAccountName: vm-latency-checkup-sa restartPolicy: Never containers: - name: vm-latency-checkup image: registry.redhat.io/container-native-virtualization/vm-network-latency-checkup-rhel9:v4.16.0 securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"] runAsNonRoot: true seccompProfile: type: "RuntimeDefault" env: - name: CONFIGMAP_NAMESPACE value: <target_namespace> - name: CONFIGMAP_NAME value: kubevirt-vm-latency-checkup-config - name: POD_UID valueFrom: fieldRef: fieldPath: metadata.uid
Job
マニフェストを適用します。$ oc apply -n <target_namespace> -f <latency_job>.yaml
ジョブが完了するまで待ちます。
$ oc wait job kubevirt-vm-latency-checkup -n <target_namespace> --for condition=complete --timeout 6m
以下のコマンドを実行して、レイテンシーチェックアップの結果を確認します。測定された最大レイテンシーが
spec.param.maxDesiredLatencyMilliseconds
属性の値よりも大きい場合、チェックアップは失敗し、エラーが返されます。$ oc get configmap kubevirt-vm-latency-checkup-config -n <target_namespace> -o yaml
出力 config map の例 (成功)
apiVersion: v1 kind: ConfigMap metadata: name: kubevirt-vm-latency-checkup-config namespace: <target_namespace> labels: kiagnose/checkup-type: kubevirt-vm-latency data: spec.timeout: 5m spec.param.networkAttachmentDefinitionNamespace: <target_namespace> spec.param.networkAttachmentDefinitionName: "blue-network" spec.param.maxDesiredLatencyMilliseconds: "10" spec.param.sampleDurationSeconds: "5" spec.param.sourceNode: "worker1" spec.param.targetNode: "worker2" status.succeeded: "true" status.failureReason: "" status.completionTimestamp: "2022-01-01T09:00:00Z" status.startTimestamp: "2022-01-01T09:00:07Z" status.result.avgLatencyNanoSec: "177000" status.result.maxLatencyNanoSec: "244000" 1 status.result.measurementDurationSec: "5" status.result.minLatencyNanoSec: "135000" status.result.sourceNode: "worker1" status.result.targetNode: "worker2"
- 1
- 測定された最大レイテンシー (ナノ秒)。
オプション: チェックアップが失敗した場合に詳細なジョブログを表示するには、次のコマンドを使用します。
$ oc logs job.batch/kubevirt-vm-latency-checkup -n <target_namespace>
以下のコマンドを実行して、以前に作成したジョブおよび config map を削除します。
$ oc delete job -n <target_namespace> kubevirt-vm-latency-checkup
$ oc delete config-map -n <target_namespace> kubevirt-vm-latency-checkup-config
オプション: 別のチェックアップを実行する予定がない場合は、ロールマニフェストを削除します。
$ oc delete -f <latency_sa_roles_rolebinding>.yaml
12.2.3.2. コマンドラインを使用したストレージ検査の実行
事前定義された検査を使用して、OpenShift Container Platform クラスターストレージが OpenShift Virtualization ワークロードを実行するために最適に設定されていることを確認します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 クラスター管理者が、次の例のように、ストレージ検査のサービスアカウントと namespace に必要な
cluster-reader
権限を作成した。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: kubevirt-storage-checkup-clustereader roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-reader subjects: - kind: ServiceAccount name: storage-checkup-sa namespace: <target_namespace> 1
- 1
- 検査の実行対象の namespace。
手順
ストレージ検査用の
ServiceAccount
、Role
、およびRoleBinding
マニフェストファイルを作成します。例12.2 サービスアカウント、ロール、ロールバインディングマニフェストファイルの例
--- apiVersion: v1 kind: ServiceAccount metadata: name: storage-checkup-sa --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: storage-checkup-role rules: - apiGroups: [ "" ] resources: [ "configmaps" ] verbs: ["get", "update"] - apiGroups: [ "kubevirt.io" ] resources: [ "virtualmachines" ] verbs: [ "create", "delete" ] - apiGroups: [ "kubevirt.io" ] resources: [ "virtualmachineinstances" ] verbs: [ "get" ] - apiGroups: [ "subresources.kubevirt.io" ] resources: [ "virtualmachineinstances/addvolume", "virtualmachineinstances/removevolume" ] verbs: [ "update" ] - apiGroups: [ "kubevirt.io" ] resources: [ "virtualmachineinstancemigrations" ] verbs: [ "create" ] - apiGroups: [ "cdi.kubevirt.io" ] resources: [ "datavolumes" ] verbs: [ "create", "delete" ] - apiGroups: [ "" ] resources: [ "persistentvolumeclaims" ] verbs: [ "delete" ] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: storage-checkup-role subjects: - kind: ServiceAccount name: storage-checkup-sa roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: storage-checkup-role
ターゲット namespace に
ServiceAccount
、Role
、RoleBinding
マニフェストを適用します。$ oc apply -n <target_namespace> -f <storage_sa_roles_rolebinding>.yaml
ConfigMap
とJob
マニフェストファイルを作成します。この config map に、検査ジョブの入力パラメーターを含めます。入力 config map とジョブマニフェストの例
--- apiVersion: v1 kind: ConfigMap metadata: name: storage-checkup-config namespace: $CHECKUP_NAMESPACE data: spec.timeout: 10m spec.param.storageClass: ocs-storagecluster-ceph-rbd-virtualization spec.param.vmiTimeout: 3m --- apiVersion: batch/v1 kind: Job metadata: name: storage-checkup namespace: $CHECKUP_NAMESPACE spec: backoffLimit: 0 template: spec: serviceAccount: storage-checkup-sa restartPolicy: Never containers: - name: storage-checkup image: quay.io/kiagnose/kubevirt-storage-checkup:main imagePullPolicy: Always env: - name: CONFIGMAP_NAMESPACE value: $CHECKUP_NAMESPACE - name: CONFIGMAP_NAME value: storage-checkup-config
ターゲット namespace に
ConfigMap
とJob
マニフェストファイルを適用し、検査を実行します。$ oc apply -n <target_namespace> -f <storage_configmap_job>.yaml
ジョブが完了するまで待ちます。
$ oc wait job storage-checkup -n <target_namespace> --for condition=complete --timeout 10m
次のコマンドを実行して、検査の結果を確認します。
$ oc get configmap storage-checkup-config -n <target_namespace> -o yaml
出力 config map の例 (成功)
apiVersion: v1 kind: ConfigMap metadata: name: storage-checkup-config labels: kiagnose/checkup-type: kubevirt-storage data: spec.timeout: 10m status.succeeded: "true" 1 status.failureReason: "" 2 status.startTimestamp: "2023-07-31T13:14:38Z" 3 status.completionTimestamp: "2023-07-31T13:19:41Z" 4 status.result.cnvVersion: 4.16.2 5 status.result.defaultStorageClass: trident-nfs 6 status.result.goldenImagesNoDataSource: <data_import_cron_list> 7 status.result.goldenImagesNotUpToDate: <data_import_cron_list> 8 status.result.ocpVersion: 4.16.0 9 status.result.pvcBound: "true" 10 status.result.storageProfileMissingVolumeSnapshotClass: <storage_class_list> 11 status.result.storageProfilesWithEmptyClaimPropertySets: <storage_profile_list> 12 status.result.storageProfilesWithSmartClone: <storage_profile_list> 13 status.result.storageProfilesWithSpecClaimPropertySets: <storage_profile_list> 14 status.result.storageProfilesWithRWX: |- ocs-storagecluster-ceph-rbd ocs-storagecluster-ceph-rbd-virtualization ocs-storagecluster-cephfs trident-iscsi trident-minio trident-nfs windows-vms status.result.vmBootFromGoldenImage: VMI "vmi-under-test-dhkb8" successfully booted status.result.vmHotplugVolume: |- VMI "vmi-under-test-dhkb8" hotplug volume ready VMI "vmi-under-test-dhkb8" hotplug volume removed status.result.vmLiveMigration: VMI "vmi-under-test-dhkb8" migration completed status.result.vmVolumeClone: 'DV cloneType: "csi-clone"' status.result.vmsWithNonVirtRbdStorageClass: <vm_list> 15 status.result.vmsWithUnsetEfsStorageClass: <vm_list> 16
- 1
- 検査が成功したか (
true
)、失敗したか (false
) を示します。 - 2
- 検査が失敗した場合の失敗の理由。
- 3
- 検査が開始した時刻 (RFC 3339 時刻形式)。
- 4
- 検査が完了した時刻 (RFC 3339 時刻形式)。
- 5
- OpenShift Virtualization のバージョン。
- 6
- デフォルトのストレージクラスがあるかどうかを指定します。
- 7
- データソースの準備ができていないゴールデンイメージのリスト。
- 8
- データインポート cron が最新ではないゴールデンイメージのリスト。
- 9
- OpenShift Container Platform のバージョン。
- 10
- 10 Mi の PVC が作成され、プロビジョナーによってバインドされているかどうかを指定します。
- 11
- スナップショットベースのクローンを使用しているが、VolumeSnapshotClass が欠落しているストレージプロファイルのリスト。
- 12
- 不明なプロビジョナーを持つストレージプロファイルのリスト。
- 13
- スマートクローン (CSI/スナップショット) をサポートするストレージプロファイルのリスト。
- 14
- ストレージプロファイル仕様でオーバーライドされる claimPropertySets のリスト。
- 15
- 仮想化ストレージクラスが存在する場合に Ceph RBD ストレージクラスを使用する仮想マシンのリスト。
- 16
- GID と UID がストレージクラスに設定されていない Elastic File Store (EFS) ストレージクラスを使用する仮想マシンのリスト。
以下のコマンドを実行して、以前に作成したジョブおよび config map を削除します。
$ oc delete job -n <target_namespace> storage-checkup
$ oc delete config-map -n <target_namespace> storage-checkup-config
オプション: 別のチェックアップを実行する予定がない場合は、
ServiceAccount
、Role
、RoleBinding
マニフェストを削除します。$ oc delete -f <storage_sa_roles_rolebinding>.yaml
12.2.3.3. コマンドラインを使用した DPDK 検査の実行
事前定義されたチェックアップを使用して、OpenShift Container Platform クラスターノードが Data Plane Development Kit (DPDK) ワークロードがある仮想マシン (VM) をパケット損失ゼロで実行できるか確認します。DPDK チェックアップは、トラフィックジェネレーターと、テスト DPDK アプリケーションを実行している仮想マシン間でトラフィックを実行します。
次の手順で DPDK チェックアップを実行します。
- DPDK チェック用のサービスアカウント、ロール、およびロールバインディングを作成します。
- config map を作成し、チェックアップを実行して結果を保存するための入力を行います。
- チェックアップを実行するジョブを作成します。
- config map で結果を確認します。
- オプション: チェックアップを再実行するには、既存の config map とジョブを削除し、新しい config map とジョブを作成します。
- 完了したら、DPDK チェックリソースを削除します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - クラスターは DPDK アプリケーションを実行するように設定されています。
- プロジェクトは DPDK アプリケーションを実行するように設定されています。
手順
DPDK チェック用の
ServiceAccount
、Role
、およびRoleBinding
マニフェストを作成します。例12.3 サービスアカウント、ロール、ロールバインディングマニフェストファイルの例
--- apiVersion: v1 kind: ServiceAccount metadata: name: dpdk-checkup-sa --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: kiagnose-configmap-access rules: - apiGroups: [ "" ] resources: [ "configmaps" ] verbs: [ "get", "update" ] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: kiagnose-configmap-access subjects: - kind: ServiceAccount name: dpdk-checkup-sa roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: kiagnose-configmap-access --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: kubevirt-dpdk-checker rules: - apiGroups: [ "kubevirt.io" ] resources: [ "virtualmachineinstances" ] verbs: [ "create", "get", "delete" ] - apiGroups: [ "subresources.kubevirt.io" ] resources: [ "virtualmachineinstances/console" ] verbs: [ "get" ] - apiGroups: [ "" ] resources: [ "configmaps" ] verbs: [ "create", "delete" ] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: kubevirt-dpdk-checker subjects: - kind: ServiceAccount name: dpdk-checkup-sa roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: kubevirt-dpdk-checker
ServiceAccount
、Role
、RoleBinding
マニフェストを適用します。$ oc apply -n <target_namespace> -f <dpdk_sa_roles_rolebinding>.yaml
チェックアップの入力パラメーターを含む
ConfigMap
マニフェストを作成します。入力 config map の例
apiVersion: v1 kind: ConfigMap metadata: name: dpdk-checkup-config labels: kiagnose/checkup-type: kubevirt-dpdk data: spec.timeout: 10m spec.param.networkAttachmentDefinitionName: <network_name> 1 spec.param.trafficGenContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.4.0 2 spec.param.vmUnderTestContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-vm:v0.4.0" 3
ターゲット namespace に
ConfigMap
マニフェストを適用します。$ oc apply -n <target_namespace> -f <dpdk_config_map>.yaml
チェックアップを実行する
Job
マニフェストを作成します。ジョブマニフェストの例
apiVersion: batch/v1 kind: Job metadata: name: dpdk-checkup labels: kiagnose/checkup-type: kubevirt-dpdk spec: backoffLimit: 0 template: spec: serviceAccountName: dpdk-checkup-sa restartPolicy: Never containers: - name: dpdk-checkup image: registry.redhat.io/container-native-virtualization/kubevirt-dpdk-checkup-rhel9:v4.16.0 imagePullPolicy: Always securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"] runAsNonRoot: true seccompProfile: type: "RuntimeDefault" env: - name: CONFIGMAP_NAMESPACE value: <target-namespace> - name: CONFIGMAP_NAME value: dpdk-checkup-config - name: POD_UID valueFrom: fieldRef: fieldPath: metadata.uid
Job
マニフェストを適用します。$ oc apply -n <target_namespace> -f <dpdk_job>.yaml
ジョブが完了するまで待ちます。
$ oc wait job dpdk-checkup -n <target_namespace> --for condition=complete --timeout 10m
次のコマンドを実行して、検査の結果を確認します。
$ oc get configmap dpdk-checkup-config -n <target_namespace> -o yaml
出力 config map の例 (成功)
apiVersion: v1 kind: ConfigMap metadata: name: dpdk-checkup-config labels: kiagnose/checkup-type: kubevirt-dpdk data: spec.timeout: 10m spec.param.NetworkAttachmentDefinitionName: "dpdk-network-1" spec.param.trafficGenContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.4.0" spec.param.vmUnderTestContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-vm:v0.4.0" status.succeeded: "true" 1 status.failureReason: "" 2 status.startTimestamp: "2023-07-31T13:14:38Z" 3 status.completionTimestamp: "2023-07-31T13:19:41Z" 4 status.result.trafficGenSentPackets: "480000000" 5 status.result.trafficGenOutputErrorPackets: "0" 6 status.result.trafficGenInputErrorPackets: "0" 7 status.result.trafficGenActualNodeName: worker-dpdk1 8 status.result.vmUnderTestActualNodeName: worker-dpdk2 9 status.result.vmUnderTestReceivedPackets: "480000000" 10 status.result.vmUnderTestRxDroppedPackets: "0" 11 status.result.vmUnderTestTxDroppedPackets: "0" 12
- 1
- 検査が成功したか (
true
)、失敗したか (false
) を示します。 - 2
- 検査が失敗した場合の失敗の理由。
- 3
- 検査が開始した時刻 (RFC 3339 時刻形式)。
- 4
- 検査が完了した時刻 (RFC 3339 時刻形式)。
- 5
- トラフィックジェネレーターから送信されたパケットの数。
- 6
- トラフィックジェネレーターから送信されたエラーパケットの数。
- 7
- トラフィックジェネレーターが受信したエラーパケットの数。
- 8
- トラフィックジェネレーター仮想マシンがスケジュールされたノード。
- 9
- テスト対象の仮想マシンがスケジュールされたノード。
- 10
- テスト対象の仮想マシンで受信したパケットの数。
- 11
- DPDK アプリケーションによって破棄された入力トラフィックパケット。
- 12
- DPDK アプリケーションから破棄された出力トラフィックパケット。
以下のコマンドを実行して、以前に作成したジョブおよび config map を削除します。
$ oc delete job -n <target_namespace> dpdk-checkup
$ oc delete config-map -n <target_namespace> dpdk-checkup-config
オプション: 別のチェックアップを実行する予定がない場合は、
ServiceAccount
、Role
、RoleBinding
マニフェストを削除します。$ oc delete -f <dpdk_sa_roles_rolebinding>.yaml
12.2.3.3.1. DPDK チェックアップ config map パラメーター
次の表は、クラスター DPDK 準備状況チェックを実行するときに、入力 ConfigMap
マニフェストの data
スタンザに設定できる必須パラメーターとオプションパラメーターを示しています。
パラメーター | 説明 | 必須かどうか |
---|---|---|
| チェックアップが失敗するまでの時間 (分単位)。 | True |
|
接続されている SR-IOV NIC の | True |
| トラフィックジェネレーターのコンテナーディスクイメージ。 | True |
| トラフィックジェネレーター仮想マシンがスケジュールされるノード。DPDK トラフィックを許可するようにノードを設定する必要があります。 | False |
| 1 秒あたりのパケット数 (キロ (k) または 100 万 (m) 単位)。デフォルト値は 8m です。 | False |
| テスト対象の仮想マシンのコンテナーディスクイメージ。 | True |
| テスト対象の仮想マシンがスケジュールされるノード。DPDK トラフィックを許可するようにノードを設定する必要があります。 | False |
| トラフィックジェネレーターが実行される期間 (分単位)。デフォルト値は 5 分です。 | False |
| SR-IOV NIC の最大帯域幅。デフォルト値は 10Gbps です。 | False |
|
| False |
12.2.3.3.2. RHEL 仮想マシン用コンテナーディスクイメージのビルド
カスタムの Red Hat Enterprise Linux (RHEL) 8 OS イメージを qcow2
形式でビルドし、それを使用してコンテナーディスクイメージを作成できます。クラスターからアクセス可能なレジストリーにコンテナーディスクイメージを保存し、DPDK チェック config map の spec.param.vmContainerDiskImage
属性でイメージの場所を指定できます。
コンテナーディスクイメージをビルドするには、Image Builder 仮想マシン (VM) を作成する必要があります。Image Builder 仮想マシン は、カスタム RHEL イメージのビルドに使用できる RHEL 8 仮想マシンです。
前提条件
-
Image Builder 仮想マシンは RHEL 8.7 を実行でき、
/var
ディレクトリーに少なくとも 2 つの CPU コア、4 GiB RAM、20 GB の空き領域がある。 -
Image Builder ツールとその CLI (
composer-cli
) が仮想マシンにインストールされている。 virt-customize
ツールがインストールされている。# dnf install libguestfs-tools
-
Podman CLI ツール (
podman
) がインストールされている。
手順
RHEL 8.7 イメージをビルドできることを確認します。
# composer-cli distros list
注記非 root として
composer-cli
コマンドを実行するには、ユーザーをweldr
またはroot
グループに追加します。# usermod -a -G weldr user
$ newgrp weldr
次のコマンドを入力して、インストールするパッケージ、カーネルのカスタマイズ、起動時に無効化するサービスを含むイメージブループリントファイルを TOML 形式で作成します。
$ cat << EOF > dpdk-vm.toml name = "dpdk_image" description = "Image to use with the DPDK checkup" version = "0.0.1" distro = "rhel-87" [[customizations.user]] name = "root" password = "redhat" [[packages]] name = "dpdk" [[packages]] name = "dpdk-tools" [[packages]] name = "driverctl" [[packages]] name = "tuned-profiles-cpu-partitioning" [customizations.kernel] append = "default_hugepagesz=1GB hugepagesz=1G hugepages=1" [customizations.services] disabled = ["NetworkManager-wait-online", "sshd"] EOF
次のコマンドを実行して、ブループリントファイルを Image Builder ツールにプッシュします。
# composer-cli blueprints push dpdk-vm.toml
ブループリント名と出力ファイル形式を指定して、システムイメージを生成します。作成プロセスを開始すると、イメージのユニバーサル一意識別子 (UUID) が表示されます。
# composer-cli compose start dpdk_image qcow2
作成プロセスが完了するまで待ちます。作成ステータスが
FINISHED
になると次のステップに進めます。# composer-cli compose status
次のコマンドを入力し、UUID を指定して
qcow2
イメージファイルをダウンロードします。# composer-cli compose image <UUID>
次のコマンドを実行して、カスタマイズスクリプトを作成します。
$ cat <<EOF >customize-vm #!/bin/bash # Setup hugepages mount mkdir -p /mnt/huge echo "hugetlbfs /mnt/huge hugetlbfs defaults,pagesize=1GB 0 0" >> /etc/fstab # Create vfio-noiommu.conf echo "options vfio enable_unsafe_noiommu_mode=1" > /etc/modprobe.d/vfio-noiommu.conf # Enable guest-exec,guest-exec-status on the qemu-guest-agent configuration sed -i '/^BLACKLIST_RPC=/ { s/guest-exec-status//; s/guest-exec//g }' /etc/sysconfig/qemu-ga sed -i '/^BLACKLIST_RPC=/ { s/,\+/,/g; s/^,\|,$//g }' /etc/sysconfig/qemu-ga EOF
virt-customize
ツールを使用して、Image Builder ツールによって生成されたイメージをカスタマイズします。$ virt-customize -a <UUID>-disk.qcow2 --run=customize-vm --selinux-relabel
コンテナーディスクイメージのビルドに必要なすべてのコマンドを含む Dockerfile を作成するには、次のコマンドを入力します。
$ cat << EOF > Dockerfile FROM scratch COPY --chown=107:107 <UUID>-disk.qcow2 /disk/ EOF
ここでは、以下のようになります。
- <UUID>-disk.qcow2
-
カスタムイメージの名前を
qcow2
形式で指定します。
次のコマンドを実行し、コンテナーをビルドしてタグを追加します。
$ podman build . -t dpdk-rhel:latest
次のコマンドを実行して、クラスターからアクセスできるレジストリーにコンテナーディスクイメージをプッシュします。
$ podman push dpdk-rhel:latest
-
DPDK チェックアップ config map の
spec.param.vmUnderTestContainerDiskImage
属性で、コンテナーディスクイメージへのリンクを指定します。