GlusterFSを使用したスケーラブルな分散ファイル・システムのデプロイ
スケーラブルな分散ネットワーク・ファイル・システムは、イメージ処理やメディア・ストリーミングなどのデータ集中型のタスクに適しています。ハイパフォーマンスコンピューティング(HPC)環境で使用する場合、GlusterFSは、大規模なデータセット(特に不変ファイル)への高パフォーマンスのアクセスを提供します。
アーキテクチャ
この参照アーキテクチャには、分散ネットワーク・ファイル・システムに必要なインフラストラクチャ・コンポーネントが含まれます。これには、GlusterFSの高可用性を設定するために必要な最小限のベア・メタル・インスタンスが含まれています。
3つのサーバー構成では、クラスタへの書込み操作を可能にするために、少なくとも2つのサーバーをオンラインにする必要があります。図に示すように、データはすべてのノード間でレプリケートされます。
図glusterfs-oci.pngの説明
- リージョン
Oracle Cloud Infrastructureリージョンは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含む、ローカライズされた地理的領域です。リージョンは他のリージョンから独立しており、広大な距離を(複数の国または複数の大陸にまたがる)分離できます。
- 可用性ドメイン
可用性ドメインは、リージョン内のスタンドアロンの独立したデータ・センターです。各可用性ドメインの物理リソースは、フォルト・トレランスを提供する他の可用性ドメインのリソースから分離されます。可用性ドメインは、電源や冷却、内部の可用性ドメイン・ネットワークなどのインフラストラクチャを共有しません。したがって、あるアベイラビリティ・ドメインでの障害が、リージョン内の他のアベイラビリティ・ドメインに影響を及ぼすことはほとんどありません。
- フォルト・ドメイン
フォルト・ドメインは、アベイラビリティ・ドメイン内のハードウェアおよびインフラストラクチャのグループです。各可用性ドメインには、独立した電源とハードウェアを持つ3つのフォルト・ドメインがあります。複数のフォルト・ドメインにリソースを分散する場合、アプリケーションでは、フォルト・ドメイン内の物理サーバー障害、システム・メンテナンスおよび電源障害を許容できます。
- 仮想クラウド・ネットワークおよびサブネット
VCNは、Oracle Cloud Infrastructureリージョンで設定するカスタマイズ可能なソフトウェア定義のネットワークです。従来のデータ・センター・ネットワークと同様に、VCNではネットワーク環境を完全に制御できます。VCNには、VCNの作成後に変更できる複数の重複しないCIDRブロックを含めることができます。VCNは、リージョンまたは可用性ドメインにスコープ指定できるサブネットにセグメント化できます。各サブネットは、VCN内の他のサブネットと重複しない連続したアドレスの範囲で構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックまたはプライベートにできます。
このアーキテクチャでは、DMZを作成して要塞サーバーをホストするパブリック・サブネットと、GlusterFSノードをホストするプライベート・サブネットの2つのサブネットを使用します。
- ネットワーク・セキュリティ・グループ(NSG)
NSGは、クラウド・リソースの仮想ファイアウォールとして機能します。Oracle Cloud Infrastructureのゼロ信頼セキュリティ・モデルでは、すべてのトラフィックが拒否され、VCN内のネットワーク・トラフィックを制御できます。NSGは、単一のVCN内の指定した一連のVNICにのみ適用される一連のイングレスおよびエグレス・セキュリティ・ルールで構成されます。
- セキュリティ・リスト
サブネットごとに、サブネット内外で許可する必要があるトラフィックのソース、宛先およびタイプを指定するセキュリティ・ルールを作成できます。
- GFS - nodes
これらはGlusterFSヘッドエンドで、各インスタンスに1 TBのブロック・ストレージがアタッチされています。
- /gfs - data
リファレンス・アーキテクチャでは、クライアントは、アプリケーションがファイル・システムにアクセスするために使用するマウント・ポイント
/gfs-dataにGlusterFSボリュームをマウントします。複数のサーバーが同時にヘッドエンド・ノードにアクセスできます。 - 要塞ホスト
要塞ホストは、クラウド外部からトポロジへのセキュアで制御されたエントリ・ポイントとして機能するコンピュート・インスタンスです。要塞ホストは通常、非武装地帯(DMZ)でプロビジョニングされます。これにより、クラウドの外部から直接アクセスできないプライベート・ネットワークに機密リソースを配置することで、機密リソースを保護できます。トポロジには、定期的に監視および監査できる単一の既知のエントリ・ポイントがあります。したがって、トポロジのより機密性の高いコンポーネントへのアクセスを損なうことなく、公開を回避できます。
お薦め
実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。開始点として次の推奨事項を使用します。
- GlusterFSアーキテクチャ
このアーキテクチャでは、レプリケートされたGlusterFSボリュームが使用され、データはすべてのノード間でレプリケートされます。この構成では、データの可用性は最も高くなりますが、最大容量の領域も使用されます。アーキテクチャ・ダイアグラムに示すように、
File1が作成されると、ノード間でレプリケートされます。GlusterFSは、次のアーキテクチャをサポートしています。要件に合ったアーキテクチャを選択します。- 分散ボリューム
このアーキテクチャはデフォルトのGlusterFS構成で、最大ボリューム・サイズおよびスケーラビリティを取得するために使用されます。データ冗長性はありません。したがって、ボリューム内のレンガに障害が発生すると、データが完全に失われます。
- レプリケートされたボリューム
このアーキテクチャは、高可用性が重要な場合に最も使用されます。複数のレンガ間でデータをレプリケートすることで、レンガの障害によるデータ損失の問題を回避できます。このリファレンス・アーキテクチャでは、レプリケートされたボリューム構成を使用します。
- 分散レプリケートされたボリューム
このアーキテクチャは、分散ボリュームとレプリケートされたボリュームの組合せで、レプリケートされたボリュームより大きいボリューム・サイズおよび分散ボリュームより高い可用性を取得するために使用されます。この構成では、データは合計レンガ数のサブセットにレプリケートされます。レンガの数は、レプリカ数の倍数である必要があります。たとえば、1 TBの4つのレンガは、それぞれ2倍レプリケーションを使用して2 TBの分散領域を提供します。
- ストライプ・ボリューム
このアーキテクチャは、小さいチャンクに分割され、各チャンクがレンガに格納される大きいファイルに使用されます。負荷はレンガ全体に分散され、ファイルはより高速にフェッチできますが、データ冗長性は使用できません。
- 分散ストライプボリューム
このアーキテクチャは、多数のレンガに分散している大規模ファイルに使用されます。この構成のトレードオフは、ボリューム・サイズを増やす場合、ストライプ数の倍数でレンガを追加する必要があることです。
- 分散ボリューム
- コンピュート・シェイプ
このアーキテクチャでは、すべてのGlusterFSノードにベア・メタル・シェイプ(BM.Standard2.52)を使用します。これらのベア・メタル・コンピュート・インスタンスには、それぞれ25 Gbpsでトラフィックをプッシュできる2つの物理NICがあります。もう一方の物理NICは、GlusterFSトラフィック専用です。
- ブロック・ストレージ
このアーキテクチャでは、1 TBのブロック・ストレージを使用します。より多くの領域が必要な場合は、ボリュームを拡張できるように論理ボリューム・マネージャ(LVM)を構成することをお薦めします。各ブロック・ボリュームは、バランスのとれたパフォーマンスを使用するように構成され、35,000 IOPSおよび480 MB/sのスループットを提供します。
- 仮想クラウド・ネットワーク(VCN)
VCNを作成する場合、VCNのサブネットにアタッチする予定のリソースの数に基づいて、必要なCIDRブロックの数と各ブロックのサイズを決定します。標準のプライベートIPアドレス空間内にあるCIDRブロックを使用します。
プライベート接続を設定する予定の他のネットワーク(Oracle Cloud Infrastructure、オンプレミス・データ・センターまたは別のクラウド・プロバイダ内)と重複しないCIDRブロックを選択します。
VCNを作成した後、CIDRブロックを変更、追加および削除できます。
サブネットを設計する際には、トラフィック・フローとセキュリティ要件を考慮してください。特定の層またはロール内のすべてのリソースを、セキュリティ境界として機能する同じサブネットにアタッチします。
- ネットワーク・セキュリティ・グループ(NSG)
NSGを使用して、特定のVNICに適用されるイングレス・ルールおよびエグレス・ルールのセットを定義できます。NSGでは、VCNのサブネット・アーキテクチャをアプリケーションのセキュリティ要件から分離できるため、セキュリティ・リストのかわりにNSGを使用することをお薦めします。リファレンス・アーキテクチャでは、すべてのネットワーク通信はNSGを介して制御されます。
- セキュリティ・リスト
セキュリティ・リストを使用して、サブネット全体に適用されるイングレス・ルールおよびエグレス・ルールを定義します。
注意事項
- パフォーマンス
最適なパフォーマンスを得るには、アプリケーションからユーザーおよびGlusterFSヘッドエンドへの通信に専用のNICを使用します。アプリケーションとユーザー間の通信にプライマリNICを使用します。GlusterFSヘッドエンドとの通信にセカンダリNICを使用します。ブロック・ストレージのボリューム・パフォーマンスを変更して、ディスクのIOPSおよびスループットを増減することもできます。
- 可用性
フォルト・ドメインは、可用性ドメイン内で最高のリジリエンシを提供します。可用性を高める必要がある場合は、複数の可用性ドメインまたは複数のリージョンの使用を検討してください。ミッションクリティカルなワークロードの場合は、分散ストライプ化されたGlusterFSボリュームの使用を検討してください。
- コストGlusterFSデプロイメントのコストは、ディスクのパフォーマンスと可用性の要件によって異なります。
- 高パフォーマンス、バランスの取れたパフォーマンスおよび低コストのパフォーマンス・オプションから選択できます。
- 可用性を高めるには、より多くのGlusterFSノードおよびボリュームが必要です。
デプロイ
この参照アーキテクチャのデプロイに必要なコードは、GitHubで入手できます。シングルクリックでコードをOracle Cloud Infrastructure Resource Managerにプルし、スタックを作成してデプロイできます。または、GitHubからコンピュータにコードをダウンロードし、Terraform CLIを使用してコードをカスタマイズし、アーキテクチャをデプロイします。
- Oracle Cloud Infrastructure Resource Managerを使用してデプロイします。
をクリックします。まだサインインしていない場合は、テナンシおよびユーザー資格証明を入力します。
- 条件を確認し、受け入れます。
- スタックをデプロイするリージョンを選択します。
- 画面に表示されるプロンプトと指示に従ってスタックを作成します。
- スタックの作成後、「Terraformアクション」をクリックし、「プラン」を選択します。
- ジョブが完了するまで待機し、プランをレビューします。
変更するには、「Stack Details」ページに戻り、「Edit Stack」をクリックして、必要な変更を行います。次に、プラン処理を再実行します。
- これ以上変更が必要ない場合は、「Stack Details」ページに戻り、「Terraform Actions」をクリックして「Apply」を選択します。
- Terraform CLIを使用してデプロイします。
- GitHubに移動します。
- リポジトリをローカル・コンピュータにクローニングまたはダウンロードします。
READMEドキュメントの指示に従います。