1. IBM Spectrum Scaleを使用した高パフォーマンスのストレージ・クラスタの導入
  2. IBM Spectrum Scaleを使用した高パフォーマンスのストレージ・クラスタのデプロイ

IBM Spectrum Scaleを使用した高パフォーマンスのストレージ・クラスタのデプロイ

IBM Spectrum Scaleは、複数のノードから1つ以上のファイル・システムへの同時アクセスを提供するクラスタ・ファイル・システムです。ノードは、SAN接続、ネットワーク接続、SAN接続とネットワーク接続の混在、または共有なしのクラスタ構成にすることができます。Spectrum Scaleを使用すると、スケールアウトのソリューションをサポートしたり、高可用性プラットフォームを提供したりするために、共通のデータ・セットに高パフォーマンスでアクセスできます。

アーキテクチャ

Spectrum Scaleのユースケースの1つは、堅牢なI/Oサブシステムを必要とするSASグリッド・アプリケーションのデプロイです。このリファレンス・アーキテクチャでは、Oracle Cloud InfrastructureでIBM Spectrumファイル・システムを使用して高I/Oスループット・ソリューションをデプロイする方法について説明します。

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

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

specter-oci.pngの説明が続きます
図specter-oci.pngの説明

Spectrum Scaleのファイル・システム・アーキテクチャには、次のコンポーネントがあります。

  • CESノード

    Cluster Export Services (CES)ノードは、統合プロトコル機能を提供できます。これらのノードは、IBM Spectrum Scaleファイルシステム内のデータへのSMB、NFS、またはオブジェクトアクセスを提供します。このノードはオプションです。スループットを向上させるために、VM.Standard2.8以上のシェイプ(2つ以上のVNIC)を使用することをお薦めします。

  • 管理GUIノード

    このノードは、Spectrum Scaleファイル・システムを監視するためのGUIインタフェースを提供します。このノードはオプションです。十分なOCPUおよびメモリーを提供するには、VM.Standard2.16以上のシェイプを使用することをお薦めします。

  • クライアント・ノード

    これらのノードはSpectrum Scaleファイル・システムを使用します。これらは、ネットワーク共有ディスク(NSD)サーバーによって提供されるディスク・データです。

  • NSDサーバー

    これらのサーバーはNSDプロトコルを使用して、クライアントサーバープロトコルモデルのクライアントノードにデータを提供します。NSDサーバーは、ローカル・ブロック・デバイスとしてサーバーに表示されるストレージへのアクセスを提供します。

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

    Oracle Cloud Infrastructure Object Storageは、耐久性が高くスケーラブルなインターネット規模のストレージ・サービスです。

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

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

  • セキュリティ・リスト

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

  • 可用性ドメイン

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

推奨事項

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

  • コンピュート・シェイプ、ベース・ホスト

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

  • コンピュート・シェイプ、CESノード

    スループットを向上させるには、VM.Standard2.8以上のシェイプ(2つ以上のVNIC)を使用します。

  • コンピュート・シェイプ、管理GUIノード

    VM.Standard2.16以上のシェイプを使用して、十分なOCPUおよびメモリーを提供します。

  • コンピュート・シェイプ、クライアント・ノード

    ユーザーは複数のクライアント・ノードを持つことができます。VM.Standard2.24シェイプから開始し、必要に応じてスケール・アップまたはスケール・ダウンします。

  • コンピュート・シェイプ、NSDサーバー

    NSDサーバには、高いスループットと処理能力が必要です。BM.Standard2.52またはBM.Standard.E2.64シェイプを使用します。また、少なくとも2つのNSDサーバー・ノードを使用します。

  • VCN

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

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

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

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

    リージョナル・サブネットを使用します。

  • セキュリティ・リスト

    セキュリティ・リストを使用して、サブネット全体に適用されるイングレス・ルールおよびエグレス・ルールを定義します。たとえば、このアーキテクチャでは、プライベート・サブネット全体に対してICMPを内部的に使用できます。

注意事項

  • パフォーマンス

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

  • 可用性

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

  • コスト

    ベア・メタル・インスタンスを使用すると、I/O操作のパフォーマンスが向上し、コストが高くなります。要件を評価して、適切なコンピュート・シェイプを選択します。

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

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

デプロイ

この参照アーキテクチャをデプロイするTerraformコードは、GitHubで入手できます。

  1. GitHubに移動します。
  2. リポジトリをローカル・コンピュータにクローニングまたはダウンロードします。
  3. READMEドキュメントの手順に従います。