サポートコンソール開発者トライアルの開始お問い合わせ

12.2. OpenShift Virtualization クラスター検査フレームワーク

OpenShift Virtualization には、クラスターのメンテナンスとトラブルシューティングに使用できる以下の定義済みのチェックアップが含まれています。

遅延チェック
ネットワーク接続を確認し、セカンダリーネットワークインターフェイスに接続されている 2 つの仮想マシン間の遅延を測定します。
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.1.1. 遅延チェックの実行

定義済みのチェックアップを使用して、ネットワーク接続を確認し、セカンダリーネットワークインターフェイスに接続されている 2 つの仮想マシン (VM) 間の待機時間を測定します。レイテンシーチェックアップでは ping ユーティリティーを使用します。

次の手順でレイテンシーチェックアップを実行します。

  1. サービスアカウント、ロール、ロールバインディングを作成して、レイテンシーチェックアップへのクラスターアクセス権を提供します。
  2. config map を作成し、チェックアップを実行して結果を保存するための入力を行います。
  3. チェックアップを実行するジョブを作成します。
  4. config map で結果を確認します。
  5. オプション: チェックアップを再実行するには、既存の config map とジョブを削除し、新しい config map とジョブを作成します。
  6. 完了したら、レイテンシーチェックアップリソースを削除します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • クラスターには少なくとも 2 つのワーカーノードがあります。
  • namespace のネットワーク接続定義を設定しました。

手順

  1. レイテンシーチェックアップ用の 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

  2. ServiceAccount、Role、RoleBinding マニフェストを適用します。 

    $ oc apply -n <target_namespace> -f <latency_sa_roles_rolebinding>.yaml 1
    1
    <target_namespace> は、チェックアップを実行する namespace です。これは、NetworkAttachmentDefinition オブジェクトが存在する既存の namespace である必要があります。

  3. チェックアップの入力パラメーターを含む ConfigMap マニフェストを作成します。

    入力 config map の例

    apiVersion: v1
kind: ConfigMap
metadata:
  name: kubevirt-vm-latency-checkup-config
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

    1
    NetworkAttachmentDefinition オブジェクトの名前。
    2
    オプション: 仮想マシン間の必要な最大待機時間 (ミリ秒単位)。測定されたレイテンシーがこの値を超えると、チェックアップは失敗します。
    3
    オプション: レイテンシーチェックの継続時間 (秒単位)。
    4
    オプション: 指定すると、このノードからターゲットノードまでの待ち時間が測定されます。ソースノードが指定されている場合、spec.param.targetNode フィールドは空にできません。
    5
    オプション: 指定すると、ソースノードからこのノードまでの待ち時間が測定されます。

  4. ターゲット namespace に config map マニフェストを適用します。 

    $ oc apply -n <target_namespace> -f <latency_config_map>.yaml

  5. チェックアップを実行する Job マニフェストを作成します。

    ジョブマニフェストの例

    apiVersion: batch/v1
kind: Job
metadata:
  name: kubevirt-vm-latency-checkup
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.14.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

  6. Job マニフェストを適用します。 

    $ oc apply -n <target_namespace> -f <latency_job>.yaml

  7. ジョブが完了するまで待ちます。 

    $ oc wait job kubevirt-vm-latency-checkup -n <target_namespace> --for condition=complete --timeout 6m

  8. 以下のコマンドを実行して、レイテンシーチェックアップの結果を確認します。測定された最大レイテンシーが 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>
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
    測定された最大レイテンシー (ナノ秒)。

  9. オプション: チェックアップが失敗した場合に詳細なジョブログを表示するには、次のコマンドを使用します。 

    $ oc logs job.batch/kubevirt-vm-latency-checkup -n <target_namespace>

  10. 以下のコマンドを実行して、以前に作成したジョブおよび config map を削除します。 

    $ oc delete job -n <target_namespace> kubevirt-vm-latency-checkup
    $ oc delete config-map -n <target_namespace> kubevirt-vm-latency-checkup-config

  11. オプション: 別のチェックアップを実行する予定がない場合は、ロールマニフェストを削除します。 

    $ oc delete -f <latency_sa_roles_rolebinding>.yaml

12.2.1.2. DPDK チェックアップ

事前定義されたチェックアップを使用して、OpenShift Container Platform クラスターノードが Data Plane Development Kit (DPDK) ワークロードがある仮想マシン (VM) をパケット損失ゼロで実行できるか確認します。DPDK チェックアップは、トラフィックジェネレーターと、テスト DPDK アプリケーションを実行している仮想マシン間でトラフィックを実行します。

次の手順で DPDK チェックアップを実行します。

  1. DPDK チェック用のサービスアカウント、ロール、およびロールバインディングを作成します。
  2. config map を作成し、チェックアップを実行して結果を保存するための入力を行います。
  3. チェックアップを実行するジョブを作成します。
  4. config map で結果を確認します。
  5. オプション: チェックアップを再実行するには、既存の config map とジョブを削除し、新しい config map とジョブを作成します。
  6. 完了したら、DPDK チェックリソースを削除します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • クラスターは DPDK アプリケーションを実行するように設定されています。
  • プロジェクトは DPDK アプリケーションを実行するように設定されています。

手順

  1. DPDK チェック用の ServiceAccount、Role、および RoleBinding マニフェストを作成します。

    例12.2 サービスアカウント、ロール、ロールバインディングマニフェストファイルの例

    ---
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

  2. ServiceAccount、Role、RoleBinding マニフェストを適用します。 

    $ oc apply -n <target_namespace> -f <dpdk_sa_roles_rolebinding>.yaml

  3. チェックアップの入力パラメーターを含む ConfigMap マニフェストを作成します。

    入力 config map の例

    apiVersion: v1
kind: ConfigMap
metadata:
  name: dpdk-checkup-config
data:
  spec.timeout: 10m
  spec.param.networkAttachmentDefinitionName: <network_name> 1
  spec.param.trafficGenContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.2.0 2
  spec.param.vmUnderTestContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-vm:v0.2.0" 3

    1
    NetworkAttachmentDefinition オブジェクトの名前。
    2
    トラフィックジェネレーターのコンテナーディスクイメージ。この例では、アップストリームの Project Quay Container Registry からイメージをプルしています。
    3
    テスト対象の仮想マシンのコンテナーディスクイメージ。この例では、アップストリームの Project Quay Container Registry からイメージをプルしています。

  4. ターゲット namespace に ConfigMap マニフェストを適用します。 

    $ oc apply -n <target_namespace> -f <dpdk_config_map>.yaml

  5. チェックアップを実行する Job マニフェストを作成します。

    ジョブマニフェストの例

    apiVersion: batch/v1
kind: Job
metadata:
  name: dpdk-checkup
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.14.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

  6. Job マニフェストを適用します。 

    $ oc apply -n <target_namespace> -f <dpdk_job>.yaml

  7. ジョブが完了するまで待ちます。 

    $ oc wait job dpdk-checkup -n <target_namespace> --for condition=complete --timeout 10m

  8. 次のコマンドを実行して、検査の結果を確認します。 

    $ oc get configmap dpdk-checkup-config -n <target_namespace> -o yaml

    出力 config map の例 (成功)

    apiVersion: v1
kind: ConfigMap
metadata:
  name: dpdk-checkup-config
data:
  spec.timeout: 10m
  spec.param.NetworkAttachmentDefinitionName: "dpdk-network-1"
  spec.param.trafficGenContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.2.0"
  spec.param.vmUnderTestContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-vm:v0.2.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 アプリケーションから破棄された出力トラフィックパケット。

  9. 以下のコマンドを実行して、以前に作成したジョブおよび config map を削除します。 

    $ oc delete job -n <target_namespace> dpdk-checkup
    $ oc delete config-map -n <target_namespace> dpdk-checkup-config

  10. オプション: 別のチェックアップを実行する予定がない場合は、ServiceAccount、Role、RoleBinding マニフェストを削除します。 

    $ oc delete -f <dpdk_sa_roles_rolebinding>.yaml
12.2.1.2.1. DPDK チェックアップ config map パラメーター

次の表は、クラスター DPDK 準備状況チェックを実行するときに、入力 ConfigMap マニフェストの data スタンザに設定できる必須パラメーターとオプションパラメーターを示しています。

表12.1 DPDK チェックアップ config map の入力パラメーター
パラメーター説明必須かどうか

spec.timeout

チェックアップが失敗するまでの時間 (分単位)。

True

spec.param.networkAttachmentDefinitionName

接続されている SR-IOV NIC の NetworkAttachmentDefinition オブジェクトの名前。

True

spec.param.trafficGenContainerDiskImage

トラフィックジェネレーターのコンテナーディスクイメージ。デフォルト値は quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:main です。

False

spec.param.trafficGenTargetNodeName

トラフィックジェネレーター仮想マシンがスケジュールされるノード。DPDK トラフィックを許可するようにノードを設定する必要があります。

False

spec.param.trafficGenPacketsPerSecond

1 秒あたりのパケット数 (キロ (k) または 100 万 (m) 単位)。デフォルト値は 8m です。

False

spec.param.vmUnderTestContainerDiskImage

テスト対象の仮想マシンのコンテナーディスクイメージ。デフォルト値は quay.io/kiagnose/kubevirt-dpdk-checkup-vm:main です。

False

spec.param.vmUnderTestTargetNodeName

テスト対象の仮想マシンがスケジュールされるノード。DPDK トラフィックを許可するようにノードを設定する必要があります。

False

spec.param.testDuration

トラフィックジェネレーターが実行される期間 (分単位)。デフォルト値は 5 分です。

False

spec.param.portBandwidthGbps

SR-IOV NIC の最大帯域幅。デフォルト値は 10Gbps です。

False

spec.param.verbose

true に設定すると、検査ログの詳細度が上がります。デフォルト値は false です。

False

12.2.1.2.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) がインストールされている。

手順

  1. RHEL 8.7 イメージをビルドできることを確認します。 

    # composer-cli distros list
    注記

    非 root として composer-cli コマンドを実行するには、ユーザーを weldr または root グループに追加します。 

    # usermod -a -G weldr user
    $ newgrp weldr

  2. 次のコマンドを入力して、インストールするパッケージ、カーネルのカスタマイズ、起動時に無効化するサービスを含むイメージブループリントファイルを TOML 形式で作成します。 

    $ cat << EOF > dpdk-vm.toml
name = "dpdk_image"
description = "Image to use with the DPDK checkup"
version = "0.0.1"
distro = "rhel-87"

[[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=8 isolcpus=2-7"

[customizations.services]
disabled = ["NetworkManager-wait-online", "sshd"]
EOF

  3. 次のコマンドを実行して、ブループリントファイルを Image Builder ツールにプッシュします。 

    # composer-cli blueprints push dpdk-vm.toml

  4. ブループリント名と出力ファイル形式を指定して、システムイメージを生成します。作成プロセスを開始すると、イメージのユニバーサル一意識別子 (UUID) が表示されます。 

    # composer-cli compose start dpdk_image qcow2

  5. 作成プロセスが完了するまで待ちます。作成ステータスが FINISHED になると次のステップに進めます。 

    # composer-cli compose status

  6. 次のコマンドを入力し、UUID を指定して qcow2 イメージファイルをダウンロードします。 

    # composer-cli compose image <UUID>

  7. 次のコマンドを実行して、カスタマイズスクリプトを作成します。 

    $ cat <<EOF >customize-vm
echo  isolated_cores=2-7 > /etc/tuned/cpu-partitioning-variables.conf
tuned-adm profile cpu-partitioning
echo "options vfio enable_unsafe_noiommu_mode=1" > /etc/modprobe.d/vfio-noiommu.conf
EOF
    $ cat <<EOF >first-boot
driverctl set-override 0000:06:00.0 vfio-pci
driverctl set-override 0000:07:00.0 vfio-pci

mkdir /mnt/huge
mount /mnt/huge --source nodev -t hugetlbfs -o pagesize=1GB
EOF

  8. virt-customize ツールを使用して、Image Builder ツールによって生成されたイメージをカスタマイズします。 

    $ virt-customize -a <UUID>.qcow2 --run=customize-vm --firstboot=first-boot --selinux-relabel

  9. コンテナーディスクイメージのビルドに必要なすべてのコマンドを含む Dockerfile を作成するには、次のコマンドを入力します。 

    $ cat << EOF > Dockerfile
FROM scratch
COPY <uuid>-disk.qcow2 /disk/
EOF

    ここでは、以下のようになります。

    <uuid>-disk.qcow2
    カスタムイメージの名前を qcow2 形式で指定します。

  10. 次のコマンドを実行し、コンテナーをビルドしてタグを追加します。 

    $ podman build . -t dpdk-rhel:latest

  11. 次のコマンドを実行して、クラスターからアクセスできるレジストリーにコンテナーディスクイメージをプッシュします。 

    $ podman push dpdk-rhel:latest
  12. DPDK チェックアップ config map の spec.param.vmContainerDiskImage 属性で、コンテナーディスクイメージへのリンクを指定します。

12.2.2. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.