2.6. ストレージ

ハイパーコンバージドホストは、設定、ログ、およびカーネルダンプを保存し、そのストレージをスワップ領域として使用します。このセクションでは、ハイパーコンバージドホストのディレクトリーの最小サイズを一覧表示します。Red Hat は、この最小値よりも多くのストレージ容量を使用するデフォルトの割り当てを使用することを推奨します。

  • / (root): 6GB
  • /home: 1GB
  • /tmp: 1GB
  • /boot: 1GB
  • /var: 15GB
  • /var/crash: 10GB
  • /var/log: 8GB

    重要

    Red Hat では、/var/log のサイズを 15 GB 以上に増やして、Red Hat Gluster Storage の追加ロギング要件に十分な領域を提供することを推奨します。

    オペレーティングシステムのインストール後にこのパーティションのサイズを増やすには 、Web コンソールを使用した論理ボリュームの拡張 の手順に従ってください。

  • /var/log/audit: 2GB
  • swap: 1 GB(詳細は 推奨のスワップサイズ を参照)
  • Anaconda では、将来のメタデータ拡張用に、ボリュームグループ内のシンプールサイズの 20% が確保されます。これは、通常の使用条件においてデフォルト設定でストレージを使い果たすのを防ぐためです。インストール中のシンプールのオーバープロビジョニングもサポートされていません。
  • 最小合計 - 55GB

2.6.1. ディスク

Red Hat では、最適なパフォーマンスを得るために、SSD(Solid State Disks) を推奨します。ハードドライブのディスク (HDD) を使用する場合は、SSD を LVM キャッシュボリュームとしてさらに小さく設定する必要があります。

Red Hat Virtualization では 512 バイトエミュレーション (512e) のサポートが必要なため、4K ネイティブデバイスは Red Hat Hyperconverged Infrastructure for Virtualization ではサポートされていません。

2.6.2. RAID

RAID5 および RAID6 の設定がサポートされます。ただし、RAID 設定制限は、使用中のテクノロジーによって異なります。

  • SAS/SATA 7k ディスクは、RAID6 でサポートされています (ほとんどの場合 10+2)
  • SAS 10k および 15k のディスクは以下でサポートされます。

    • RAID5(ほとんどの 7+1)
    • RAID6(最大 10+2)

RAID カードは、フラッシュでサポートされる書き込みキャッシュを使用する必要があります。

Red Hat は、各サーバーに少なくとも 1 つのホットペアドライブを提供することを推奨します。

2.6.3. JBOD

Red Hat Hyperconverged Infrastructure for Virtualization 1.6 の時点で、JBOD 設定は完全にサポートされ、アーキテクチャーレビューが不要になりました。

2.6.4. 論理ボリューム

エンジン gluster ボリュームを設定する論理ボリュームは、プロビジョニングする必要があります。これにより、Hosted Engine が領域不足、破壊的なボリューム設定の変更、I/O オーバーヘッド、および移行アクティビティーから保護されます。

vmstoreとオプションのdataGluster ボリュームを設定する論理ボリュームはシンプロビジョニングされている必要があります。これにより、基礎となるボリューム設定で柔軟性が向上します。シンプロビジョニングされたボリュームがハードディスク (HDD) にある場合は、パフォーマンスを向上させるために、小規模かつ高速な Solid State Disk(SSD) を lvmcache として設定します。

2.6.5. Red Hat Gluster Storage ボリューム

Red Hat Hyperconverged Infrastructure for Virtualization には、Red Hat Gluster Storage のボリュームが 3 から 4 個搭載される予定です。

  • ホステッドエンジン用のエンジンボリューム 1 個
  • 仮想マシンのオペレーティングシステムディスクイメージ用のvmstoreボリューム 1 個
  • 他の仮想マシンのディスクイメージ用のオプションの データ ボリューム 1 つ
  • ジオレプリケーションメタデータ用のshared_storageボリューム 1 個

バックアップに必要なストレージ容量を最小限に抑えるために、vmstoredataボリュームを分けることをお勧めします。オペレーティングシステムイメージから分離されている仮想マシンデータを保存すると、vmstore ボリュームのオペレーティングシステムイメージをより簡単に再構築できるため、ストレージ領域がプレミアムにあるときに data ボリュームのみのバックアップを作成する必要があります。

Red Hat Hyperconverged Infrastructure for Virtualization デプロイメントには、geo レプリケーションされたボリュームを最大 1 つ含めることができます。

2.6.6. ボリュームタイプ

Red Hat Hyperconverged Infrastructure for Virtualization(RHHI for Virtualization) は、デプロイ時に以下のボリューム種別のみをサポートします。

  • レプリケートされたボリューム (3 つのノードにわたる 3 つのブリック上の同じデータの 3 つのコピー)。

    これらのボリュームは、デプロイメント後に分散レプリケーションボリュームに拡張できます。

  • 調停されたレプリケートボリューム (3 つのノードにわたる 2 つのブリック上の同じデータの 2 つの完全なコピーと、メタデータを含む 1 つの調停ブリック)。

    これらのボリュームは、デプロイメント後に調停された分散複製ボリュームに拡張できます。

  • 分散ボリューム (データの 1 コピー、他のブリックへのレプリケーションなし)。

判定ブリックは、ファイル名、構造、およびメタデータのみを保存することに注意してください。つまり、3 方向の判別複製ボリュームは、同じレベルの一貫性を実現するために、3 方向の複製ボリュームが 75 % である必要があることを意味します。ただし、arbiter ブリックはメタデータのみを格納するため、3 方向の判別複製ボリュームは双方向複製ボリュームのみを提供します。

調停レプリケートボリュームのレイアウトの詳細については、Red Hat Gluster Storage 管理ガイドより少ない合計ノードにわたる複数の調停レプリケートボリュームの作成を 参照してください。