第10章 MTV パフォーマンスに関する推奨事項


ネットワークとストレージのパフォーマンス、コールド移行とウォーム移行、複数の移行または単一の移行に関する推奨事項を確認します。

10.1. MTV パフォーマンスに関する推奨事項

このセクションの目的は、テストで確認できた結果に基づいて、Migration Toolkit for Virtualization (MTV) を使用して仮想マシン (VM) を効率的かつ効果的に移行するための推奨事項を共有することです。

ここで提供されるデータは Red Hat Labs でのテストから収集されたもので、参考目的でのみ提供されています。 

全体として、これらの数値は最良のシナリオを示すものと考えるべきです。

確認できた移行のパフォーマンスは、これらの結果と異なる場合があり、いくつかの要因に依存します。

10.1.1. 高速なストレージとネットワーク速度を確保する

VMware 環境と Red Hat OpenShift (OCP) 環境の両方で、高速なストレージとネットワーク速度を確保します。

  • 高速移行を実行するには、VMware がデータストアへの読み取りアクセスが高速でなければなりません。VMware ESXi ホスト間のネットワークは高速で、10 GiB のネットワーク接続を確保し、ネットワークのボトルネックを回避する必要があります。

    • VMware ネットワークを OCP Workers Interface ネットワーク環境に拡張します。
    • 受信速度が ESXi データストアの読み取り速度と一致するように、VMware ネットワークが高スループット (10 ギガビットイーサネット) と高速ネットワークを提供することが重要です。
    • 移行プロセスでは大量のネットワーク帯域幅が使用され、移行ネットワークが利用されることに注意してください。他のサービスがそのネットワークを使用する場合、それらのサービスとその移行率に影響を及ぼす可能性があります。
    • たとえば、OCP インターフェイスへのデータ転送に関連する各 ESXi ホストの vmnic からの平均ネットワーク転送速度は 200 - 325 MiB/秒でした。

データストアの読み取り速度は合計転送時間に影響するため、ESXi データストアから ESXi ホストへの高速読み取りをできるようにすることが重要です。  

数字での例: 単一の ESXi サーバーの vSphere エンドポイントと ESXi エンドポイントの両方の平均読み取り速度は 200 - 300 MiB/秒でした。複数の ESXi サーバーを使用すると、データストアの読み取り速度が向上します。

10.1.3. エンドポイントの種類 

MTV 2.6 では、以下の vSphere プロバイダーオプションを使用できます。

  • ESXi エンドポイント (ESXi からのインベントリーおよびディスク転送)、MTV 2.6 で導入
  • vCenter Server エンドポイント。ESXi ホスト用のネットワークはありません (vCenter からのインベントリーおよびディスク転送)
  • vCenter エンドポイント。ESXi ネットワークが利用できます (vCenter からのインベントリー、ESXi からのディスク転送)。

複数の ESXi ホストに登録されている多数の仮想マシンを転送する場合は、vCenter エンドポイントと ESXi ネットワークを使用することを推奨します。

注記

vSphere 7.0 以降、ESXi ホストは、Network Block Device (NBD) トランスポートに使用するネットワークにラベルを付けることができます。これは、目的の仮想ネットワークインターフェイスカード (NIC) に適切な vSphereBackupNFC ラベルをタグ付けすることによって実現されます。これが完了すると、ワーカーと ESXi ホストインターフェイスにアクセスできる場合、MTV は ESXi インターフェイスを使用して OpenShift へのネットワーク転送を行うことができます。これは、移行ユーザーが ESXi 認証情報にアクセスできない可能性があるにもかかわらず、移行に使用する ESXi インターフェイスを制御する必要がある場合に特に便利です。 

詳細は、(MTV-1230) を参照してください。

NBD バックアップ用にインターフェイス vmk2 を指定する次の ESXi コマンドを使用できます。

esxcli network ip interface tag add -t vSphereBackupNFC -i vmk2
Copy to Clipboard Toggle word wrap

可能であれば、移行に使用されるホストが、パフォーマンスが最大の BIOS プロファイルに設定されていることを確認します。vSphere 内で制御されるホスト電源管理を使用するホストでは、High Performance が設定されていることを確認する必要があります。

テストの結果、BIOS とホスト電源管理の両方を適切に設定した状態で 10 個を超える仮想マシンを転送すると、移行によって平均データストア読み取り速度が 15 MiB 増加することがわかりました。

10.1.5. VMware ネットワークへの追加のネットワーク負荷を回避する

ESXi エンドポイントを使用するときに移行ネットワークを選択すると、VMware ネットワークのネットワーク負荷を軽減できます。

MTV は仮想化プロバイダーを組み込むことで、仮想マシンを OpenShift に移行する目的で、ESXi ホスト上でアクセス可能な特定のネットワークを選択できるようになります。MTV UI の ESXi ホストからこの移行ネットワークを選択すると、選択したネットワークを ESXi エンドポイントとして使用して転送が実行されるようになります。

選択したネットワークが OCP インターフェイスに接続できること、移行に十分な帯域幅があること、およびネットワークインターフェイスが飽和していないことを確認することが不可欠です。

10GbE ネットワークなどの高速ネットワークを備えた環境では、データの移行時に発生するネットワークの負荷が、ESXi データストアの読み取り速度と同じくらいになると予想されます。

10.1.6. ESXi ホストあたりの最大同時ディスク移行を制御する

MAX_VM_INFLIGHT MTV 変数を設定して、ESXi ホストで対応できる同時仮想マシン転送の最大数を制御します。 

MTV では、この変数を使用して同時実行性を制御できます。デフォルトでは 20 に設定されています。

MAX_VM_INFLIGHT を設定するときは、ESXi ホストに必要な最大同時仮想マシン転送の数を考慮してください。 同時に転送する移行の種類を考慮することが重要です。ウォームマイグレーション: スケジュールされた時間内に移行される実行中の仮想マシンの移行によって定義されます。

ウォームマイグレーションでは、スナップショットを使用して、ディスクの以前のスナップショット間の差異のみを比較して移行します。スナップショット間の差異の移行は、実行中の仮想マシンから OpenShift への最終的な切り替えが行われる前に、特定の間隔で行われます。 

MTV 2.6 では、特定のスナップショットの現在の移行アクティビティーや単一の仮想マシンに属するディスクの数に関係なく、MAX_VM_INFLIGHT は仮想マシンごとに 1 つの転送スロットを予約します。 MAX_VM_INFLIGHT によって設定された合計は、ESXi ホストごとに許可される同時仮想マシン転送の数を示すために使用されます。

  • MAX_VM_INFLIGHT = 20 で、プロバイダーに 2 つの ESXi ホストが定義されている場合、各ホストは 20 台の仮想マシンを転送できます。

10.1.7. 複数の仮想マシンを同時に移行する場合の移行時間を短縮する

特定の ESXi ホストから複数の仮想マシンを移行する場合、複数の仮想マシンの同時移行を開始すると、移行時間が短縮されます。 

テストでは、1 台のホストから 10 個の仮想マシン (それぞれ 35 GiB のデータを含み、合計サイズは 50 GiB) を移行する方が、同じ数の仮想マシンを 1 つずつ順番に移行するよりも大幅に高速であることが実証されました。 

単一のホストから 10 台を超える仮想マシンへの同時移行を増やすことは可能ですが、大幅な改善は見られません。 

  • 1 台のディスク仮想マシンは 6 分、移行速度は 100 MiB/秒でした
  • 10 枚の単一ディスク仮想マシンは 22 分、移行速度は 272 MiB/s でした
  • 20 台の単一ディスクの仮想マシンは 42 分、移行速度は 284 MiB/s でした。
注記

前述の例から、10 台の仮想マシンを同時に移行すると、同一の仮想マシンを順番に移行するよりも 3 倍高速になることがわかります。

10 台または 20 台の仮想マシンを同時に移行する場合の移行率はほぼ同じでした。

10.1.8. 複数のホストを使用する場合の移行時間を短縮する

移行に使用する ESXi ホスト間で均等に分散された登録済み仮想マシンが含まれるホストを複数使用すると、移行時間が短縮されます。

テストの結果、合計 50 G のデータのうちそれぞれ 35 GiB を含む 10 個以上の単一ディスク仮想マシンを転送する場合、追加のホストを使用すると移行時間を短縮できることが示されました。

  • 1 台のホストを使用して、それぞれ 35 GiB のデータを含む 80 台の単一ディスク仮想マシンを移行するのに 2 時間 43 分、移行速度は 294 MiB/秒でした。
  • 8 台の ESXi ホストを使用して、それぞれ 35 GiB のデータを含む 80 個の単一ディスク仮想マシンを移行するのに 41 分、移行速度は 1,173 MiB/秒でした。
注記

前述の例から、8 台の ESXi ホストから 80 個の仮想マシン (各ホストから 10 個ずつ) を同時に移行すると、単一の ESXi ホストから同じ仮想マシンを実行するよりも 4 倍高速になることがわかります。 

8 台を超える ESXi ホストから多数の仮想マシンを同時に移行すると、パフォーマンスが向上する可能性があります。ただし、テストされていないため、推奨されません。

10.1.9. 単一の大規模な移行計画と比較した複数の移行計画

1 つの移行計画で参照できるディスクの最大数は 500 です。詳細は (MTV-1203) を参照してください。 

単一の移行計画で多数の仮想マシンを移行しようとすると、すべての移行が開始されるまでに時間がかかることがあります。 1 つの移行計画を複数の移行計画に分割することで、移行を同時に開始することが可能になります。

移行の比較:

  • 1 つの計画で、8 台の ESXi ホストを使用する 500 台の仮想マシンを、max_vm_inflight=100 を指定して移行したところ、5 時間 10 分かかりました。
  • 8 つの計画で、8 台の ESXi ホストを使用する 800 台の仮想マシンを、max_vm_inflight=100 を指定して移行したところ、57 分かかりました。

テストの結果、1 つの大規模な計画を複数の中規模の計画 (例: 計画ごとに 100 台の仮想マシンを使用) に分割すると、移行の合計時間を短縮できることが示されました。

10.1.10. コールドマイグレーションでテストされた最大値

  • テスト済みの ESXi ホストの最大数: 8
  • 1 つの移行計画内の仮想マシンの最大数: 500
  • 1 回のテストで移行した仮想マシンの最大数: 5000
  • 同時に実行した移行計画の最大数: 40
  • 移行したディスクの最大サイズ: 6 TB ディスク (3 TB のデータを含む)
  • 移行した単一の仮想マシン上のディスクの最大数: 50
  • 単一の ESXi サーバーでの単一のデータストアの最高読み取り速度: 312 MiB/秒
  • 8 台の ESXi サーバーと 2 つのデータストアを使用した場合の最高マルチデータストア読み取り速度: 1,242 MiB/秒
  • OpenShift ワーカーへの仮想 NIC 転送速度の最高値: 327 MiB/秒
  • 単一ディスクの最大移行転送速度: 162 MiB/秒 (1.5 TB の使用データの非同時移行を転送するときに確認できた速度)
  • 単一の ESXi ホストからの複数の仮想マシン (単一ディスク) の最大コールドマイグレーション転送速度: 294 MiB/秒 (単一の ESXi から 30 台の仮想マシンを同時に移行、35/50 GiB 使用)
  • 複数の ESXi ホストからの複数の仮想マシン (単一ディスク) の最大コールドマイグレーション転送速度: 1173 MB/秒 (8 台の ESXi サーバーから 80 台の仮想マシンを同時に移行、35/50 GiB 使用、各 ESXi から 10 台の仮想マシン)

10.1.11. ウォームマイグレーションの推奨事項

以下の推奨事項はウォームマイグレーションに特有のものです。

  • 最大 400 ディスクを並行して移行する

テストでは、8 台の ESXi ホストを使用してそれぞれ 2 つのディスクを持つ 200 台の仮想マシンを並行して移行し、合計 400 台のディスクを使用しました。400 台を超えるディスクを並行して移行する移行計画はテストが実行されていないため、この数のディスクを並行して移行することは推奨されません。

  • 最大 200 台のディスクを並行して移行し、最速の速度を実現する

200、300、400 台のディスクを使用した並列ディスク移行のテストが正常に実行されました。200 台のディスクを移行するテストと 300 台および 400 台のディスクを移行するテストでは、プレコピー移行率が約 25% 減少しました。

したがって、プレコピーの速度が 25% 低下してもカットオーバー計画に影響がない限り、300 - 400 個のディスクではなく、200 個以下のディスクのグループで並列ディスク移行を実行することを推奨します。

  • 移行計画の開始直後にカットオーバー時間を設定する (可能な場合)

ウォームマイグレーションにかかる時間を短縮するには、移行計画の開始直後にカットオーバーが発生するように設定することを推奨します。これにより、MTV は仮想マシンごとに 1 つのプレコピーのみ を実行します。この推奨事項は、移行計画に含まれる仮想マシンの数に関係なく有効です。

  • スナップショット間のプレコピー間隔を増やす

単一の仮想マシンで多数の移行計画を作成し、移行の開始とカットオーバーの間に十分な時間がある場合は、controller_precopy_interval パラメーターの値を 120 分から 240 分の範囲に増やします。設定を長くすると、カットオーバー前の仮想マシンあたりのスナップショットとディスク転送の合計数が減ります。

10.1.12. ウォームマイグレーションでテストされた最大値

  • テスト済みの ESXi ホストの最大数: 8
  • ワーカーノードの最大数: 12
  • 1 つの移行計画内の仮想マシンの最大数: 200
  • 並列ディスク転送の最大数: 400、仮想マシン 200 台、ESXi 6 台、転送速度 667 MB/秒
  • 移行したディスクの最大サイズ: 6 TB ディスク (3 TB のデータを含む)
  • 移行される単一の仮想マシン上のディスクの最大数: 3
  • ESXi ホストあたりの並列ディスク転送の最大数: 68
  • 同時移行のない単一ディスクの最大転送速度: 76.5 MB/秒
  • 単一の ESXi ホストから複数のディスクで確認された最大転送速度: 253 MB/秒 (10 台の仮想マシン、各ディスク 1 台、ディスクあたり 35/50 GiB 使用)
  • 8 台の ESXi ホストからの複数のディスク (210) で確認された合計転送速度: 802 MB/秒 (70 台の仮想マシン、各 3 台のディスクの同時移行、ディスクあたり 35/50 GiB 使用)

10.1.13. 大容量ディスクを使用する仮想マシンの移行に関する推奨事項

各ディスクのディスク上のデータ総量が 1 TB 以上になる仮想マシンの場合は、次の推奨事項を考慮してください。

  • 大容量ディスクの仮想マシン (VM) を移行するための適切なメンテナンス期間をスケジュールしてください。このような移行は繊細な操作です。特にストレージやネットワークのアクティビティーが少ない期間中に、メンテナンス期間とダウンタイムを慎重に計画する必要がある場合があります。
  • 大規模な仮想マシン (VM) の移行中に、他の移行アクティビティーや、他の負荷の高いネットワークまたはストレージアクティビティーが実行されないことを確認してください。このような大規模な仮想マシンの移行は特別なケースとして扱う必要があります。移行中は、MTV のアクティビティーを優先します。大規模な仮想マシンおよび関連するデータストアでのアクティビティーが少なくなる期間に、仮想マシンを移行するように計画します。
  • データの更新頻度が高く、スナップショット間で 100 GB 以上のデータが頻繁に変更される大規模な仮想マシンの場合は、ウォームマイグレーションの controller_precopy_interval をデフォルトの 60 分から短縮することを検討してください。 このプロセスは、複数回のプレコピースナップショットが正常に完了できるように、計画されているカットオーバーの少なくとも 24 時間前に開始することが重要です。 カットオーバーをスケジュールする際は、必ずメンテナンス期間中に余裕を持って変更の最後のスナップショットをコピーできるようにします。また、そのメンテナンス期間の開始時にカットオーバープロセスを始めてください。
  • きわめて大きな単一ディスクの仮想マシンで、ダウンタイムが発生する可能性がある場合、特に仮想マシンスナップショットが大きくなる場合は、ウォームマイグレーションではなくコールドマイグレーションを選択してください。
  • きわめて大きなディスク上のデータを複数のディスクに分割することを検討してください。そうすることで、ウォームマイグレーションの使用時に MTV による並列ディスク移行が可能になります。
  • ダウンタイムや仮想マシンスナップショットが不可能な、大量のデータが継続的に書き込まれる大きなデータベースディスクがある場合は、MTV 外での特殊な移行を見据えて、データベースベンダー固有のデータベースデータのレプリケーション方法を検討する必要がある可能性があります。このケースが当てはまる場合は、データベースのベンダー固有のオプションを確認してください。

10.1.14. NBD トランスポートモードの AIO サイズとバッファー数の増加

Migration Toolkit for Virtualization (MTV) で Asynchronous Input/Output (AIO) バッファリングを使用する場合、Network Block Device (NBD) トランスポート Network File Copy (NFC) パラメーターを変更して、移行のパフォーマンスを向上させることができます。

警告

AIO バッファリングの使用は、コールドマイグレーションのユースケースにのみ適しています。

ウォームマイグレーションを初期化する前に、AIO 設定を無効にします。詳細は、AIO バッファー設定の無効化 を参照してください。

10.1.14.1. 主な調査結果

  • 次の値を使用して、複数 (10) の仮想マシン (VM) を単一の ESXi ホストに移行することで、最高の移行パフォーマンスが達成されました。

    • VixDiskLib.nfcAio.Session.BufSizeIn64KB=16
    • vixDiskLib.nfcAio.Session.BufCount=4
  • AIO バッファー設定 (非同期バッファー数) を使用すると、次の改善が見られました。

    • 移行時間は 0:24:32 から 0:16:54 になり、31.1% 短縮されました。
    • 読み取り速度は 347.83 MB/秒から 504.93 MB/秒に向上しました。
  • 単一の仮想マシンで AIO バッファー設定を使用した場合、大きな改善は見られませんでした。
  • 複数のホストからの複数の仮想マシンで AIO バッファー設定を使用した場合、大きな改善は見られませんでした。

10.1.14.2. AIO サイズとバッファー数のサポートに関する主な要件

サポートは、次のバージョンを使用して実行されたテストに基づいています。

  • vSphere 7.0.3
  • VDDK 7.0.3

10.1.15. AIO バッファリングの有効化と設定

Migration Toolkit for Virtualization (MTV) で使用するために、Asynchronous Input/Output (AIO) バッファリングを有効にして設定できます。

手順

  1. openshift-mtv namespace の forklift-controller Pod が AIO バッファー値をサポートしていることを確認します。Pod 名の接頭辞は動的であるため、次のコマンドを実行して Pod 名を確認します。

    oc get pods -n openshift-mtv | grep forklift-controller | awk '{print $1}'
    Copy to Clipboard Toggle word wrap

    たとえば、Pod 名の接頭辞が "forklift-controller-667f57c8f8-qllnx" の場合、出力は次のようになります。

    forklift-controller-667f57c8f8-qllnx
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、Pod の環境変数を確認します。

    oc get pod forklift-controller-667f57c8f8-qllnx -n openshift-mtv -o yaml
    Copy to Clipboard Toggle word wrap
  3. 出力で次の行を確認します。

    ...
    \- name: VIRT\_V2V\_EXTRA\_ARGS
    \- name: VIRT\_V2V\_EXTRA\_CONF\_CONFIG\_MAP
    ...
    Copy to Clipboard Toggle word wrap
  4. openshift-mtv namespace で、次の手順を実行して ForkliftController カスタムリソース (CR) を編集します。

    1. 次のコマンドを実行して、ForkliftController CR にアクセスし、編集します。

      oc edit forkliftcontroller -n openshift-mtv
      Copy to Clipboard Toggle word wrap
    2. ForkliftController CR の spec セクションに次の行を追加します。

      virt_v2v_extra_args: "--vddk-config /mnt/extra-v2v-conf/input.conf"
      virt_v2v_extra_conf_config_map: "perf"
      Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行して、必要な config map perf を作成します。

    oc -n openshift-mtv create cm perf
    Copy to Clipboard Toggle word wrap
  6. 目的のバッファー設定値を Base64 に変換します。たとえば、16/4 の場合は、次のコマンドを実行します。

    echo -e "VixDiskLib.nfcAio.Session.BufSizeIn64KB=16\nvixDiskLib.nfcAio.Session.BufCount=4" | base64
    Copy to Clipboard Toggle word wrap

    出力は次のようになります。

    Vml4RGlza0xpYi5uZmNBaW8uU2Vzc2lvbi5CdWZTaXplSW42NEtCPTE2CnZpeERpc2tMaWIubmZjQWlvLlNlc3Npb24uQnVmQ291bnQ9NAo=
    Copy to Clipboard Toggle word wrap
  7. config map perf で、binaryData セクションに Base64 文字列を入力します。次に例を示します。

    apiVersion: v1
    kind: ConfigMap
    binaryData:
      input.conf: Vml4RGlza0xpYi5uZmNBaW8uU2Vzc2lvbi5CdWZTaXplSW42NEtCPTE2CnZpeERpc2tMaWIubmZjQWlvLlNlc3Npb24uQnVmQ291bnQ9NAo=
    metadata:
      name: perf
      namespace: openshift-mtv
    Copy to Clipboard Toggle word wrap
  8. 新しい設定を適用するには、forklift-controller Pod を再起動します。
  9. VIRT_V2V_EXTRA_ARGS 環境変数が更新された設定を反映していることを確認します。
  10. 移行計画を実行し、移行 Pod のログを確認します。AIO バッファー設定、特に --vddk-config 値がパラメーターとして渡されていることを確認します。

    たとえば、次のコマンドを実行するとします。

    exec: /usr/bin/virt-v2v … --vddk-config /mnt/extra-v2v-conf/input.conf
    Copy to Clipboard Toggle word wrap

    debug_level = 4 の場合、ログには次のようなセクションが含まれます。

    Buffer size calc for 16 value:
    (16 * 64 * 1024 = 1048576)
    nbdkit: vddk[1]: debug: [NFC VERBOSE] NfcAio_OpenSession:
    Opening an AIO session.
    nbdkit: vddk[1]: debug: [NFC INFO] NfcAioInitSession:
    Disabling
    read-ahead buffer since the AIO buffer size of 1048576 is >=
    the read-ahead buffer size of 65536. Explicitly setting flag
    '`NFC_AIO_SESSION_NO_NET_READ_AHEAD`'
    nbdkit: vddk[1]: debug: [NFC VERBOSE] NfcAioInitSession: AIO Buffer Size is 1048576
    nbdkit: vddk[1]: debug: [NFC VERBOSE] NfcAioInitSession: AIO Buffer
    Count is 4
    Copy to Clipboard Toggle word wrap
  11. 移行 Pod に正しい config map 値があることを確認します。これを行うには、移行 Pod にログインし、次のコマンドを実行します。

    cat /mnt/extra-v2v-conf/input.conf
    Copy to Clipboard Toggle word wrap

    出力例は次のとおりです。

    VixDiskLib.nfcAio.Session.BufSizeIn64KB=16
    vixDiskLib.nfcAio.Session.BufCount=4
    Copy to Clipboard Toggle word wrap
  12. オプション: 次のコマンドを実行してデバッグログを有効にします。このコマンドは、高いログレベルを含む設定を Base64 に変換します。

    echo -e
    "`VixDiskLib.nfcAio.Session.BufSizeIn64KB=16\nVixDiskLib.nfcAio.Session.BufCount=4\nVixDiskLib.nfc.LogLevel=4`"
    | base64
    Copy to Clipboard Toggle word wrap
    注記

    高いログレベルを追加するとパフォーマンスが低下しますが、これはデバッグ目的のみに使用されます。

10.1.16. AIO バッファリングの無効化

Migration Toolkit for Virtualization (MTV) を使用して、コールドマイグレーションの AIO バッファリングを無効化できます。MTV を使用したウォームマイグレーションでは、AIO バッファリングを無効にする必要があります。

注記

次の手順では、AIO バッファリングの有効化と設定 の手順に従って、AIO バッファリングが有効化および設定されていることを前提としています。

手順

  1. openshift-mtv namespace で、次の手順を実行して ForkliftController カスタムリソース (CR) を編集します。

    1. 次のコマンドを実行して、ForkliftController CR にアクセスし、編集します。

      oc edit forkliftcontroller -n openshift-mtv
      Copy to Clipboard Toggle word wrap
    2. ForkliftController CR の spec セクションから次の行を削除します。

      virt_v2v_extra_args: "`–vddk-config /mnt/extra-v2v-conf/input.conf`"
      virt_v2v_extra_conf_config_map: "`perf`"
      Copy to Clipboard Toggle word wrap
  2. perf という名前の config map を削除します。

    oc delete cm perf -n openshift-mtv
    Copy to Clipboard Toggle word wrap
  3. オプション: 変更が有効になったことを確認するには、forklift-controller Pod を再起動します。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat