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

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 ボリュームの作成」 を参照してください。
Expand
表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)
Copy to Clipboard Toggle word wrap
たとえば、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
Copy to Clipboard Toggle word wrap
シャードが有効で、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 )
Copy to Clipboard Toggle word wrap
ボリュームに保存するファイルの数がわかる場合は、推奨される最小 Arbiter ブリックサイズは 4 KB のファイルの最大数になります。たとえば、ボリュームに 200,000 個ファイルを割り当てることが想定される場合は、Arbiter ブリックのサイズは 800,000 KB または 0.8 GB である必要があります。
また、Red Hat は、arbiter ブリックのサイズを増やす短期の必要性をなくすためにも、可能な場合はオーバープロビジョニングを推奨しています。また、maxpct の使用方法は、ブリック設定を参照してください。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat