5.7. Arbitrated Replicated ボリュームの作成

Arbitrated Replicated ボリュームには、ボリューム内のファイルの完全コピーが 2 つ含まれています。Arbitrated ボリュームには、ボリューム内の 2 つのデータブリックごとに追加の arbiter ブリックがあります。Arbiter ブリックはファイルデータを格納しません。ファイル名、構造、メタデータのみを格納します。Arbiter ブリックは、クライアントクォーラムを使用して arbiter のメタデータを他のノードのメタデータと比較し、ボリューム内の一貫性を確保し、スプリットブレインの条件を防ぎます。

Arbitrated Replicated ボリュームの利点

一貫性の向上
arbiter が設定されると、判別ロジックはクライアント側のクォーラムを auto モードで使用して、スプリットブレイン状態を引き起こすファイル操作を防ぎます。
必要なディスク容量が少なくなる
arbiter ブリックはファイル名とメタデータのみを保存するため、arbiter ブリックはボリューム内の他のブリックよりもはるかに小さくすることができます。
必要なノード数が少なくなります
あるボリュームの arbiter ブリックが含まれるノードは、別のボリュームのデータブリックを使用して設定できます。この「チェーン」の設定により、ストレージ全体の要件を満たすために、少ないノードを使用できます。
非推奨の双方向複製ボリュームからの容易な移行
Red Hat Gluster Storage は、Arbiter ブリックなしで双方向の複製ボリュームを、Arbitrated Replicated ボリュームに変換できます。詳細は、「判別ボリュームへの変換」 を参照してください。

Arbitrated Replicated ボリュームの制限

  • Arbitrated Replicated ボリュームは、arbiter ブリックのない双方向複製ボリュームよりも優れたデータの一貫性を提供します。ただし、Arbitrated Replicated ボリュームはメタデータのみを格納するため、arbiter ブリックのない双方向複製ボリュームと同じレベルの可用性を提供します。高可用性を実現するには、Arbitrated Replicated ボリュームの代わりに、3 方向の複製ボリュームを使用する必要があります。
  • 階層化は、仲裁された複製ボリュームと互換性がありません。
  • 判別ボリュームは、一度に 3 つのブリックのセットでのみ設定できます。Red Hat Gluster Storage は、arbiter ブリックをそのボリュームに追加することで、既存の双方向複製ボリュームを、Arbitrated Replicated ボリュームに変換できます。詳細は、「判別ボリュームへの変換」 を参照してください。

5.7.1. 判別ボリューム要件

本項では、サポートされる任意のボリュームデプロイメントの要件について説明します。

5.7.1.1. Arbiter ブリックをホストするノードのシステム要件

arbiter ブリックを含むノードの最低システム要件は、管理者が行う設定の選択によって異なります。専用 arbiter と連鎖的な Arbiter 設定の違いに関する詳細は、「複数の Arbitrated Replicated ボリュームの作成」 を参照してください。

表5.1 物理マシンでの任意設定の要件

設定タイプ最小 CPU最小 RAMNICArbiter ブリックサイズ最大レイテンシー
専用 arbiter64 ビットクアッドコアプロセッサー (ソケット 2 つ)8 GB[a]ストレージプールの他のノードに一致1 TB から 4 TB[b]5 ミリ秒[c]
チェーン abiterストレージプールの他のノードに一致1 TB から 4 TB[d]5 ミリ秒[e]
[a] ノード上の arbiter ブリックの数を組み合わせた容量によっては、RAM を増やす必要がある場合があります。
[b] arbiter およびデータブリックは、データと arbiter ブリックが異なるレプリカセットに属することであれば、同じデバイスに設定できます。Arbiter ボリュームのサイジングについての詳細は、「Arbiter 容量の要件」 を参照してください。
[c] これは、aribiter ノードに関係なくすべてのノード間の最大ラウンドトリップレイテンシー要件です。ノード間のレイテンシーを確認するには、KCS#413623 を参照してください。
[d] 1 つの RAIDed 物理デバイスに複数のブリックを作成できます。以下の製品ドキュメントを参照してください。 「ブリック設定」
[e] これは、aribiter ノードに関係なくすべてのノード間の最大ラウンドトリップレイテンシー要件です。ノード間のレイテンシーを確認するには、KCS#413623 を参照してください。
仮想マシンでの任意設定の要件は次のとおりです。
  • 最低 4 vCPU
  • 最低 16 GB RAM
  • 1 TB から 4 TB の仮想ディスク
  • 最大 5 ミリ秒レイテンシー

5.7.1.2. Arbiter 容量の要件

arbiter ブリックはファイル名とメタデータのみを保存するため、arbiter ブリックはボリュームまたはレプリカセット内の他のブリックよりもはるかに小さくすることができます。arbiter ブリックに必要なサイズは、ボリュームに格納されているファイルの数によって異なります。
推奨される最小 arbiter ブックサイズは、以下の式で計算できます。
minimum arbiter brick size = 4 KB * ( size in KB of largest data brick in volume or replica set / average file size in KB)
たとえば、2 つの 1 TB のデータブリックがあり、ファイルの平均サイズが 2 GB の場合は、以下の例のように arbiter ブリック 2 MB が最小サイズとして推奨されます。
minimum arbiter brick size  = 4 KB * ( 1 TB / 2 GB )
                            = 4 KB * ( 1000000000 KB / 2000000 KB )
                            = 4 KB * 500 KB
                            = 2000 KB
                            = 2 MB
シャードが有効で、shard-block-size が KB の平均ファイルサイズよりも小さい場合は、各シャードにもメタデータファイルが含まれるため、代わりに以下の式を使用する必要があります。
minimum arbiter brick size = 4 KB * ( size in KB of largest data brick in volume or replica set / shard block size in KB )
ボリュームに保存するファイルの数がわかる場合は、推奨される最小 Arbiter ブリックサイズは 4 KB のファイルの最大数になります。たとえば、ボリュームに 200,000 個ファイルを割り当てることが想定される場合は、Arbiter ブリックのサイズは 800,000 KB または 0.8 GB である必要があります。
また、Red Hat は、arbiter ブリックのサイズを増やす短期の必要性をなくすためにも、可能な場合はオーバープロビジョニングを推奨しています。また、maxpct の使用方法は、「 ブリック設定 」を参照してください。