Avere vFXT システムの計画

  • [アーティクル]

この記事では、ニーズに合わせて配置されてサイズが設定される新しい Avere vFXT for Azure クラスターを計画する方法について説明します。

Azure Marketplace への移動、または任意の VM の作成を行う前に、次の点を検討してください。

  • クラスターと他の Azure リソースとのやり取りはどのように行われるのか。
  • クラスター要素は、プライベート ネットワークとサブネット内のどの位置に配置する必要があるのか。
  • どのような種類のバックエンド ストレージを使用するのか。また、どのようにしてクラスターからアクセスするのか。
  • ワークフローをサポートするためにクラスター ノードがどの程度強力である必要があるのか。

詳細については、後の説明を参照してください。

システムのコンポーネントについて学習する

計画の策定を開始するとき、Avere vFXT for Azure システムのコンポーネントについて理解しておくと役立つ場合があります。

  • クラスター ノード - クラスターは、クラスター ノードとして構成された 3 つ以上の VM で構成されます。 ノードが増えると、システムのスループットが向上し、キャッシュも大きくなります。

  • キャッシュ - キャッシュ容量は、クラスター ノード間で均等に分割されます。 クラスターを作成するときに、ノードごとのキャッシュ サイズを設定します。キャッシュの合計サイズになるように、ノードのサイズが追加されます。

  • クラスター コントローラー - クラスター コントローラーは、クラスター ノードと同じサブネット内に配置される追加の VM です。 このコントローラーは、クラスターの作成および継続的な管理タスクに必要です。

  • バックエンド ストレージ - キャッシュするデータは、ハードウェア ストレージ システムまたは Azure Blob コンテナーに長期間格納されます。 Avere vFXT for Azure クラスターを作成したら、ストレージを追加できます。または、BLOB ストレージを使用する場合、クラスターを作成しながらコンテナーを追加して構成することができます。

  • クライアント - キャッシュされたファイルを使用するクライアント コンピューターは、ストレージ システムに直接アクセスするのではなく、仮想ファイル パスを使用してクラスターに接続します (詳細については 「Avere vFXT クラスターをマウントする」を参照してください)。

サブスクリプション、リソース グループ、ネットワーク インフラストラクチャ

ご利用の Avere vFXT for Azure のデプロイの要素を配置する場所を検討してください。 以下の図は、Avere vFXT for Azure コンポーネントに対して可能な配置を示しています。

Diagram showing the cluster controller and cluster VMs within one subnet. Around the subnet boundary is a vnet boundary. Inside the vnet is a hexagon representing the storage service endpoint; it is connected with a dashed arrow to a Blob storage outside the vnet.

Avere vFXT クラスターのネットワーク インフラストラクチャを計画する場合、次のガイドラインに従います。

  • Avere vFXT for Azure デプロイごとに新しいサブスクリプションを作成します。 このサブスクリプション内のすべてのコンポーネントを管理します。

    デプロイごとに新しいサブスクリプションを使用する利点は次のとおりです。

    • コストの追跡がより簡単 - 1 つのサブスクリプションに含まれるリソース、インフラストラクチャ、およびコンピューティング サイクルから発生するすべてのコストを表示および監査します。
    • クリーンアップがより容易 - プロジェクトが終了したらサブスクリプション全体を削除できます。
    • リソース クォータのパーティション分割が便利 - 起きる可能性があるリソース調整からその他の重要なワークロードを保護するために、Avere vFXT クライアントとクラスターを 1 つのサブスクリプション内に分離します。 この分離により、高パフォーマンス コンピューティング ワークフロー用に多数のクライアントを稼働する際の競合を回避することができます。

  • ご利用のクライアント コンピューティング システムを vFXT クラスターの近くに配置します。 バックエンド ストレージは、さらにリモートである可能性があります。

  • vFXT クラスターとクラスター コントローラー VM を一緒に配置します。具体的には、次のようにする必要があります。

    • 同じ仮想ネットワーク内
    • 同じリソース グループ内
    • 同じストレージ アカウントの使用

    ほとんどの場合、この構成はクラスター作成テンプレートによって処理されます。

  • このクラスターは、IP アドレスがクライアントまたは他のコンピューティング リソースと競合することを避けるために、独自のサブネットに配置する必要があります。

  • クラスター作成テンプレートを使用することで、リソース グループ、仮想ネットワーク、サブネット、およびストレージ アカウントなど、クラスターに必要なインフラストラクチャのほとんどを作成できます。

    既に存在するリソースを使用する場合は、それらのリソースが以下の表の要件を満たしていることを確認してください。

    リソース 既存のリソースを使用するか 必要条件
    リソース グループ 空の場合、はい 空でなければならない
    ストレージ アカウント クラスターの作成後、既存の BLOB コンテナーを接続する場合は、はい
    クラスター作成中に新しい BLOB コンテナーを作成する場合は、いいえ    		 既存の Blob コンテナーは空でなければならない
     
    Virtual Network はい 新しい Azure Blob コンテナーを作成する場合は、ストレージ サービス エンドポイントを含める必要がある
    Subnet はい 他のリソースを含めることはできない

IP アドレスの要件

ご利用のクラスターのサブネットに、クラスターをサポートするために十分な IP アドレスの範囲があることを確認してください。

Avere vFXT クラスターでは、次の IP アドレスを使用します。

  • 1 つのクラスターの管理 IP アドレス。 このアドレスは、必要に応じてクラスター内のノード間を移動できるため、常に使用することができます。 このアドレスを使用して、Avere コントロール パネル構成ツールに接続します。
  • クラスター ノードごと
    • 少なくとも 1 つのクライアント側の IP アドレス。 (クライアント側のアドレスはすべて、クラスターの vserver によって管理されます。これによって、必要に応じて IP アドレスをノード間で移動できます。)
    • クラスター通信用に 1 つの IP アドレス
    • (VM に割り当てられている) 1 つのインスタンスの IP アドレス

Azure BLOB ストレージを使用する場合、ご利用のクラスターの仮想ネットワークからの IP アドレスを必要とする可能性もあります。

  • Azure BLOB ストレージ アカウントには、少なくとも 5 つの IP アドレスが必要です。 BLOB ストレージをご利用のクラスターと同じ仮想ネットワークに配置する場合、この要件に留意してください。
  • クラスターの仮想ネットワークの外側にある Azure BLOB ストレージを使用する場合、仮想ネットワークの内側にストレージ サービス エンドポイントを作成します。 このエンドポイントでは、IP アドレスを使用しません。

クラスターとは別のリソース グループにネットワーク リソースと BLOB ストレージ (使用する場合) を配置するオプションがあります。

vFXT ノードのサイズ

クラスター ノートとして機能する VM によって、要求のスループットと自分のキャッシュのストレージ容量が決定されます。

それぞれの vFXT ノードは同一になります。 つまり、3 ノード クラスターを作成する場合、同じ種類とサイズの VM が 3 つ用意されます。

インスタンスの種類 vCPU 数 メモリ ローカル SSD ストレージ 最大データ ディスク数 キャッシュされていないディスク スループット NIC (数)
Standard_E32s_v3 32 256 GiB 512 GiB 32 51,200 IOPS
768 Mbps		 16,000 Mbps (8)

1,000 GB から 8,000 GB の範囲で、ノードごとのディスク キャッシュを構成することができます。Standard_E32s_v3 ノードの推奨キャッシュ サイズは、ノードあたり 4 TB です。

これらの VM の詳細については、Microsoft Azure のドキュメント: 「メモリ最適化仮想マシンのサイズ」を参照してください

アカウント クォータ

ご利用のサブスクリプションに、Avere vFXT クラスターおよび使用されている任意のコンピューティング システムまたはクライアント システムを実行する容量があることを確認してください。 詳細については、「vFXT クラスターのクォータ」を参照してください。

バックエンドのデータ ストレージ

バックエンドのストレージ システムでは、クラスターのキャッシュにファイルを提供するだけでなく、キャッシュからも変更されたデータを受信します。 ワーキング セットを、新しい BLOB コンテナーに長期的に保存するか、既存のストレージ システム (クラウドまたはードウェア) に保存するかを決定します。 このようなバックエンドのストレージ システムは、"コア ファイラー" と呼ばれます。

ハードウェア コア ファイラー

vFXT クラスターを作成したら、そのクラスターにハードウェア ストレージ システムを追加します。 クラスターのサブネットからストレージ システムに到達できる限りは、オンプレミスのシステムなど、さまざまな一般的なハードウェア システムを使用できます。

既存のストレージ システムを Avere vFXT クラスターに追加する方法の詳細な手順については、「ストレージの構成」を参照してください。

クラウド コア ファイラー

Azure システムの Avere vFXT では、バックエンドのストレージとして空の BLOB コンテナーを使用できます。 クラスターに追加するとき、コンテナーは空である必要があります - vFXT システムでは、既存のデータを保持しなくても、そのオブジェクト ストアを管理できる必要があります。

ヒント

バック エンドで Azure BLOB ストレージを使用する必要がある場合は、vFXT クラスターを作成する一環として、新しいコンテナーを作成します。 クラスター作成テンプレートによって新しい BLOB コンテナーを作成および構成すれば、クラスターが使用可能になったらすぐに使用できるようになります。 コンテナーを後で追加する場合は、より複雑になります。

詳細については、Azure 用の Avere vFXT を作成することに関するページを参照してください。

空の BLOB ストレージ コンテナーをコアフィルターとして追加したら、クラスターを介してデータをそれにコピーすることができます。 並列のマルチスレッド コピー メカニズムを使用します。 クライアント マシンと Avere vFXT のキャッシュを使用することで、データをクラスターの新しいコンテナーに効率的にコピーする方法については、「vFXT クラスターへのデータの移動」を参照してください。

クラスターへのアクセス

Azure クラスターの Avere vFXT は、プライベート サブネット内に置かれ、クラスターにパブリック IP アドレスはありません。 クラスター管理とクライアント接続のために、プライベート サブネットにアクセスする方法をいくつか用意する必要があります。

以下のようなアクセス オプションがあります。

  • ジャンプ ホスト - プライベート ネットワーク内の独立した VM にパブリック IP アドレスを割り当てて、それを使用してクラスター ノードへの TLS トンネルを作成します。

    ヒント

    クラスター コントローラーにパブリック IP アドレスを設定した場合は、それをジャンプ ホストとして使用できます。 詳細については、「ジャンプ ホストとしてのクラスター コントローラー」を参照してください。

  • 仮想プライベート ネットワーク (VPN) - Azure 内のプライベート ネットワークと企業ネットワーク間に、ポイント対サイトまたはサイト間 VPN を構成します。

  • Azure ExpressRoute - ExpressRoute パートナーを通じてプライベート接続を構成します。

これらのオプションの詳細については、インターネット通信に関する Azure Virtual Network のドキュメントを参照してください。

ジャンプ ホストとしてのクラスター コントローラー

クラスター コントローラーにパブリック IP アドレスを設定した場合は、それを、プライベート サブネット外から Avere vFXT クラスターにアクセスするジャンプ ホストとして使用できます。 ただし、コントローラーはクラスター ノードを変更するアクセス特権を持っているため、これによって小さなセキュリティ リスクが生じます。

パブリック IP アドレスを使用するコントローラーのセキュリティーを向上させるために、デプロイ スクリプトは、インハウンド アクセスをポート 22 のみに制限するネットワーク セキュリティー グループを自動的に作成します。 さらに、IP ソース アドレスの範囲にアクセスをロック ダウン (つまり、クラスター アクセスに使用するつもりのマシンからの接続のみを許可) することで、システムを保護できます。

クラスターの作成時には、クラスター コントローラーにパブリック IP アドレスを作成するかどうかを選択できます。

  • 新しい仮想ネットワークまたは新しいサブネットを作成する場合は、クラスター コントローラーにパブリック IP アドレスが割り当てられます。
  • 既存の仮想ネットワークとサブネットを選択すると、クラスター コントローラーはプライベート IP アドレスのみを持つことになります。

VM アクセス ロール

Azure では、Azure ロールベースのアクセス制御 (Azure RBAC) を使用してクラスターの VM を承認し、特定のタスクを実行します。 たとえば、クラスター コントローラーは、クラスター ノード VM を作成して構成するための承認を必要とします。 クラスター ノードでは、IP アドレスを他のクラスター ノードに割り当てたり、再割り当てしたりできる必要があります。

Avere vFXT 仮想マシンでは、次の 2 つの組み込み Azure ロールが使用されます。

  • クラスター コントローラーには、組み込みロール Avere Contributor が使用されます。
  • クラスター ノードには、組み込みロール Avere Operator が使用されます。

Avere vFXT コンポーネントのアクセス ロールをカスタマイズする必要がある場合は、独自のロールを定義して、VM に対しその作成時に割り当てる必要があります。 Azure Marketplace ではデプロイ テンプレートを使用できません。 「お使いのシステムでサポートを受ける」の説明に従って Azure portal からサポート チケットを開き、マイクロソフト カスタマー サービスおよびサポートに相談してください。

次のステップ

デプロイの概要に関するページでは、Avere vFXT for Azure システムを作成し、データを使用する準備をするために必要な手順の全体像を示します。