1. BeeGFSパラレル・ファイル・システムのデプロイ
  2. BeeGFSパラレル・ファイル・システムのデプロイ

BeeGFSパラレル・ファイル・システムのデプロイ

BeeGFSは、入出力パフォーマンスに重点を置いて開発されたパラレル・クラスタ・ファイル・システムで、インストールと管理が容易になるように設計されています。BeeGFSを使用すると、Oracle Cloud Infrastructure上にハイパフォーマンス・コンピューティング(HPC)ファイル・サーバーを構築できます。

BeeGFSは、ユーザー・データを複数のサーバーに透過的に分散します。システム内のサーバーおよびディスクの数を増やすことで、小規模なクラスタから数千のノードを持つエンタープライズ・クラスのシステムまで、ファイルシステムのパフォーマンスおよび容量をスケーリングできます。

アーキテクチャ

この参照アーキテクチャでは、単一の可用性ドメインおよびリージョナル・サブネットを持つリージョンを使用します。複数の可用性ドメインを持つリージョンで同じ参照アーキテクチャを使用できます。可用性ドメインの数に関係なく、デプロイメントにリージョナル・サブネットを使用することをお薦めします。

次の図は、この参照アーキテクチャを示しています。

architecture-deploy-beegfs.pngの説明が続きます
図architecture-deploy-beegfs.pngの説明

アーキテクチャには、次のコンポーネントがあります。

  • リージョン

    1つのリージョンは、1つ以上の可用性ドメインで構成される、ローカライズされた地理的領域です。地域は他の地域から独立しており、広大な距離で(複数の国または大陸にわたって)分離できます。

  • 可用性ドメイン

    可用性ドメインは、1つのリージョン内のスタンドアロンの独立したデータ・センターです。各可用性ドメインの物理リソースは、フォルト・トレランスを提供する他の可用性ドメインのリソースから分離されます。可用性ドメインは、電源や冷却などのインフラストラクチャや、内部の可用性ドメイン・ネットワークを共有しません。したがって、ある可用性ドメインでの障害が、そのリージョン内の他の可用性ドメインに影響を与える可能性はほとんどありません。

  • フォルト・ドメイン

    フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループです。各可用性ドメインには、独立した電源とハードウェアを持つ3つのフォルト・ドメインがあります。コンピュート・インスタンスを複数のフォルト・ドメインに配置すると、アプリケーションは物理サーバー障害、システム・メンテナンス、および可用性ドメイン内の多くの一般的なネットワーキングと電源障害を許容できます。

  • 仮想クラウド・ネットワーク(VCN)およびサブネット

    VCNは、Oracle Cloud Infrastructureリージョンで設定するソフトウェア定義ネットワークです。VCNは、リージョンまたは可用性ドメインに固有のサブネットにセグメント化できます。リージョン固有のサブネットと可用性ドメイン固有のサブネットの両方を同じVCNに共存させることができます。サブネットはパブリックまたはプライベートにできます。

  • セキュリティ・リスト

    サブネットごとに、サブネット内外で許可する必要があるトラフィックのソース、宛先およびタイプを指定するセキュリティ・ルールを作成できます。

  • ルート表

    仮想ルート表には、通常はゲートウェイを介して、サブネットからVCN外部の宛先にトラフィックをルーティングするルールが含まれます。

  • インターネット・ゲートウェイ

    インターネット・ゲートウェイでは、VCNとパブリック・インターネット間のトラフィックが許可されます。

  • クライアント・ノード

    クライアントは、BeeGFSファイル・システムにアクセスするコンピュート・インスタンスです。

  • 管理サーバー

    管理サーバー(MGS)は、BeeGFSのメタデータ、ストレージおよびクライアント・サービスの会議ポイントです。MGSは、1つ以上のファイル・システムの構成情報を格納し、この情報を他のホストに提供します。このグローバル・リソースは、複数のファイル・システムをサポートできます。

  • メタデータ・サービス

    メタデータ・サービス(MDS)には、ディレクトリ情報、ファイルおよびディレクトリの所有権、ストレージ・ターゲット上のユーザー・ファイルの内容の場所など、データに関する情報が格納されます。メタデータ・サービスはスケールアウト・サービスです。つまり、BeeGFSファイル・システムで1つ以上のメタデータ・サービスを使用できます。

    メタデータ・コンテンツは、メタデータ・ターゲット(MDT)と呼ばれるボリュームに格納されます。

  • オブジェクト・ストレージ・サービス

    オブジェクト・ストレージ・サービス(OSS)は、ユーザー・ファイルの内容またはデータ・チャンク・ファイルを格納するためのメイン・サービスです。オブジェクト・ストレージ・サーバーは、ストレージ・サーバーとも呼ばれます。

    メタデータ・サービスと同様に、オブジェクト・ストレージ・サービスもスケールアウト設計に基づいています。OSインスタンスには、1つ以上のオブジェクト・ストレージ・ターゲットがあります。

    各ストレージ・サーバーは、オブジェクト・ストレージ・ターゲット(OST)と呼ばれるストレージ・ボリュームのセットへのアクセスを提供します。各OSTには、ファイルのデータを表す複数のバイナリオブジェクトが含まれています。

推奨事項

実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。開始点として次の推奨事項を使用します。

  • VCN

    VCNを作成するときに、各サブネットのクラウド・リソースに必要なIPアドレスの数を決定します。クラスレス・ドメイン間ルーティング(CIDR)表記を使用して、必要なIPアドレスに十分な大きさのサブネット・マスクおよびネットワーク・アドレス範囲を指定します。標準のプライベートIPアドレス空間内のアドレス範囲を使用します。

    オンプレミス・ネットワークと重複しないアドレス範囲を選択して、必要に応じてVCNとオンプレミス・ネットワーク間の接続を設定できるようにします。

    VCNを作成した後は、そのアドレス範囲を変更できません。

    サブネットを設計する際には、トラフィック・フローとセキュリティ要件を考慮してください。同じ層またはロール内のすべてのコンピュート・インスタンスを、セキュリティ境界として機能できる同じサブネットにアタッチします。

  • セキュリティ・リスト

    セキュリティ・リストを使用して、サブネット全体に適用されるイングレス・ルールおよびエグレス・ルールを定義します。

  • 要塞ホスト

    ベース・ホストは、プライベート・サブネット内の任意のノードにアクセスするために使用されます。VM.Standard.E2.1シェイプを使用します。

  • 管理サーバー(MGS)

    MGSはリソース集中型ではないため、MDSサーバーとともにデプロイすることを選択できます。個別にデプロイする場合は、VM.Standard2.2シェイプで十分です。

    50 GBのバランスのとれたパフォーマンス層ブロック・ボリュームを使用します。追加の領域が必要な場合は、ブロック・ボリュームのサイズを変更できます。

  • メタデータ・サービス(MDS)サーバー

    VM.Standard2.8以上のシェイプを使用します。要件は、ワークロードがメタデータ集中型かどうか(小さいファイル・ワークロードの場合)、ノードごとに実行されているメタデータ・インスタンスの数などによって異なります。

    最高のパフォーマンスを得るには、BM.Standard2.52などのベア・メタル・シェイプをお薦めします。これは、それぞれに25 Gbpsのネットワーク速度を持つ2つの物理NICがあるためです。すべてのトラフィックに1つのNICを使用してストレージをブロックし、もう1つのNICを使用してクライアント・ノードからMDSノードへのデータを受信します。

    ブロック・ボリューム・ストレージを使用します。記憶域を増やすには、デプロイメント要件ごとにサイズと数を変更します。さらに領域が必要な場合は、ブロック・ボリュームのサイズを変更できます。

  • オブジェクト・ストレージ・サービス(OSS)サーバー

    VM.Standard2.8以上を使用します。要件は、ファイル・システムで必要なGBpsの集計IOスループットによって異なります。

    最高のパフォーマンスを得るには、BM.Standard2.52などのベア・メタル・シェイプをお薦めします。これは、それぞれに25 Gbpsのネットワーク速度を持つ2つの物理NICがあるためです。すべてのトラフィックに1つのNICを使用してストレージをブロックし、もう1つのNICを使用してクライアント・ノードからOSSノードへのデータを受信します。

  • クライアント・ノード

    デプロイメント・プランに基づいてVMシェイプを選択します。シェイプによって、インスタンスがファイル・システムに対して読取りおよび書込みに使用できるネットワーク帯域幅が決まります。たとえば、VM.Standard2.16シェイプの最大ネットワーク帯域幅は16.4 Gbpsで、これは最大IOスループットが2.05 GBpsであることを意味します。

    IntelとAMD VMおよびベア・メタル・コンピュート・シェイプの両方をクライアントに使用できます。

注意事項

  • パフォーマンス

    最適なパフォーマンスを得るには、適切な帯域幅を持つ正しいコンピュート・シェイプを選択します。

  • 可用性

    デプロイメント要件に基づいて高可用性オプションを使用することを検討してください。

  • コスト

    ベア・メタル・サービスは、より高いネットワーク帯域幅を提供しますが、コストは高くなります。要件を評価して、適切なコンピュート・シェイプを選択します。

  • モニタリングとアラート

    MGS、MDSおよびOSSノードのCPUおよびメモリー使用率の監視およびアラートを設定して、必要に応じてVMシェイプをスケール・アップまたはスケール・ダウンします。

デプロイ

このリファレンス・アーキテクチャのTerraformコードは、GitHubで入手できます。

Terraformスクリプトを直接使用するか、Oracle Cloud Infrastructure Resource Managerサービスを介してデプロイできます。

  1. GitHubに移動します。
  2. リポジトリをローカル・コンピュータにクローニングまたはダウンロードします。
  3. Terraformスクリプトを使用するには、READMEドキュメントの手順に従います。
  4. Oracle Cloud Infrastructure Resource Managerを使用するには、リポジトリのormディレクトリ内のREADMEの手順に従います。

詳細情報