Azure NetApp Files を使用するタイミング
ここでは、Azure NetApp Files を共有ファイル ストレージとして使用して、クラウドで実行するオンプレミスのファイルベースのワークロードを移行することが適切な場合を示すいくつかのシナリオについて確認してみましょう。 ここでは、Azure NetApp Files がクラウドで組織のファイルベースのワークロードを実行するのに適したストレージの選択肢かどうかを判断するのに役立つ基準を示します。
- デプロイまたは移行の容易さ
- ワークロードの規模
- 柔軟性
- ストレージのテクノロジ
意思決定の基準
Azure NetApp Files は、再構成をほとんどまたはまったく必要とせず、デプロイの柔軟性を必要とするエンタープライズ規模のファイルベースのワークロードを管理できます。 Azure NetApp Files が適切な選択でない可能性のあるユースケースには、通常、ブロックベースまたはオブジェクトベースのストレージを必要とする小規模で静的なワークロードなどがあります。 決定基準の詳細を確認しましょう。
| 条件 | 分析 |
|---|---|
| デプロイまたは移行の容易さ | ワークロードを「リフトアンドシフト」する必要がありますか。 つまり、アプリケーションのコンポーネント、構成、またはコードを変更することなく、ワークロードを Azure クラウドに移行する必要がありますか。 リフトアンドシフトの移行により、ワークロードがクラウドで実行を開始するときに問題が発生するリスクを最小限に抑えることができます。 また、新しいデプロイや移行を実行するために必要なコスト、労力、時間が最小限に抑えられます。 |
| ワークロードの規模 | ワークロードの全体的な規模はどのくらいですか。 Azure NetApp Files は、最高のパフォーマンスと可用性を必要とするエンタープライズ規模のワークロードに最適です。 例としては、大規模なデータベースのデプロイ、大規模な VDI、ハイパフォーマンスのコンピューティング アプリケーションなどがあります。 Azure NetApp Files は、比較的小規模でパフォーマンスの低いワークロードを簡単にサポートできます。 |
| 柔軟性 | ワークロードには、パフォーマンス、容量、スケーラビリティの観点から柔軟性が必要ですか? Azure NetApp Files を使用すると、Standard、Premium、Ultra の間でボリュームのサービス レベルを変更でき、必要なサービス レベルでボリュームを容量プールに移動することで、サービスが中断されることがありません。 また、現在の需要に合わせて、いつでも容量プールまたはボリュームのサイズを増減させることができます。 容量プールをマニュアル QoS に設定している場合は、Azure NetApp Files を使用して、ワークロードの必要に応じてボリュームのスループットを個別に変更することもできます。 |
| ストレージのテクノロジ | ブロックベースまたはファイルベースのストレージが必要ですか? Azure NetApp Files は、共有ファイル ストレージを使用できる POSIX と互換性のあるワークロードに対して機能します。 ただし、一部のワークロードには、ブロックベースと直接接続の両方のストレージに対する厳密な依存関係または要件があります。 Azure NetApp Files では仮想 NAS を提供するため、そのワークロードの種類には適していません。 従来の多くのワークロードでは、直接接続されたブロックベースのストレージを使用していましたが、これは厳密な依存関係や要件ではありません。 このような場合、Azure NetApp Files を使うと、Azure 仮想マシンはブロックベース (SSD) インフラストラクチャよりもネットワーク レートの制限が緩く、Azure Network Files ボリュームがネットワークに接続されているため、パフォーマンスとスケーラビリティが向上する可能性があります。 |
基準を適用する
Azure NetApp Files は、ファイルベースでエンタープライズ規模の、柔軟なワークロードを Azure に「リフトアンドシフト」する必要がある場合の、共有ネットワーク ストレージに適した選択肢です。 これらの基準はすべての用途に等しく適用されるわけではありません。 これらの基準がここでのシナリオのユース ケースにどのように適用されるかを調べてみましょう。
Oracle Database チームで Azure NetApp Files を使用する必要はありますか?
最も要求の厳しい Oracle Database ワークロードでは、高い I/O 容量とストレージへの低待機時間アクセスが必要です。 このソリューションは、ネットワーク ファイル システム (NFS) プロトコルによる共有ファイル アクセスを提供します。 アーキテクチャでは、共有ファイル ストレージ サービスである Azure NetApp Files が使用されます。 Azure NetApp Files には、次の利点があります。
- 仮想マシン (VM) レベルで適用されるアクセス レートに関するディスク I/O 制限は、Azure NetApp Files には影響しません。 その結果、パフォーマンスを低下させることなく、ディスク ストレージでの場合よりも小さい VM SKU を使用できます。 この方法では、コストを大幅に削減できます。
- Azure NetApp Files には柔軟性があります。 必要に応じてデプロイを拡大または縮小して、構成のコスト効率を保つことができます。
Azure データセンター環境内では、簡単に利用できる Azure ネイティブ サービスとして Azure NetApp Files が実行されます。 Azure NetApp Files は、他の Azure ストレージと同じようにプロビジョニング、利用、スケーリングすることができます。 Azure NetApp Files では、オールフラッシュ ストレージのベアメタル フリートが使用されます。 Azure NetApp Files では、スケーラビリティに優れた共有ストレージが使用され、その待機時間は 1 ミリ秒未満です。 このような要因により、このサービスは、NFS プロトコルを使用して、ネットワーク上で Oracle Database ワークロードを実行するのに適しています。
次の図は、考えられるアーキテクチャを示したものです。 コンポーネントは、次のようにやり取りします。
- Oracle サブネット内の Azure VM 上で Oracle Database が実行されます。
- Azure NetApp Files サブネット内では、Azure NetApp Files が、データ ファイルとログ ファイルへの NFS アクセスを提供します。
- 接続プロトコル Oracle Direct NFS (dNFS) によりパフォーマンスとスループットが向上します。
Azure Virtual Desktop (AVD) チームで Azure NetApp Files を使用する必要はありますか?
Azure NetApp Files は、最大 450,000 IOPS とミリ秒未満の待機時間を提供します。これは、大規模な Azure Virtual Desktop (AVD) のデプロイのストレージになることを意味します。 Azure NetApp Files の機能を利用することにより、AVD のデプロイの規模をすばやく簡単に最適化してコストを管理できます。 Azure NetApp Files を使用すると、スループットを変更し、サービスを中断せずにオンデマンドでボリュームに別のサービス レベルを選択できます。 また、頻繁に手動または自動ボリューム スナップショットを作成することにより、必要に応じて個々の FSLogix ユーザー プロファイル コンテナーをロールバックするだけでなく、ボリューム全体を元に戻すこともできます。
複数の従業員が AVD デプロイ内で作業し、各ユーザーが仮想パーソナル デスクトップを操作しているシナリオを考えてみましょう。 この大規模なデプロイは、Azure にリフトアンドシフトされ、必要に応じてスループットのために最適化することができます。
次の図は、個人のデスクトップベースの AVD のデプロイに会社が使用できる考えられるアーキテクチャの 1 つを示しています。 ユーザーは特定のデスクトップ ポッドにマップされます。 "ポッド" は、仮想マシンのプールと、Azure NetApp Files の容量プール全体のボリュームを使用する Azure NetApp Files 指定のサブネットを備えたスポーク仮想ネットワークです。 各プールには、1,000 個 (ユーザーごとに 1 つずつ) 弱の仮想マシンがあります。 Azure NetApp Files では、シングルセッションのホスト プール VNet ごとに、その多数の個人用デスクトップを簡単に処理できます。 さらに個人用デスクトップが必要な場合は、ポッドを簡単に追加できます。
研究および開発チームで Azure NetApp Files を使用する必要がありますか?
ほとんどの R&D チームでは、コンピューター支援設計、3D モデリング、詳細なシミュレーションなど、コンピューティング集中型およびデータ集中型の操作が必要となります。 そのため、IOPS が高く、待機時間が短く、高可用性が必要です。 これらのタスクは、極端な使用量の変動を引き起こすことがよくあります。たとえば、複雑なシミュレーションの間は使用率が高く、シミュレーションが終了するとほとんどゼロになります。 R&D チームのメンバーには、POSIX 準拠の SMB および NFS プロトコル混合のアクセスが必要です。 これらのすべての考慮事項は、R&D チームのアプリケーションを Azure に移行し、共有ストレージ サービスとして Azure NetApp Files を使用することに有利に働きます。
次の図は、Azure 仮想ネットワークでハイパフォーマンスのコンピューティング アプリケーションを実行するための可能なセットアップを示しています。 このセットアップでは、アプリケーションの共有ストレージとして Azure NetApp Files が使用されます。 R&D チームのメンバーは、Windows または Linux 仮想マシンを介してフロント エンドにアクセスします。 HPC アプリケーションは、Linux 仮想マシンのスケール セットで構成されるコンピューティング サブネットで実行されます。 このスケール セットの共有ストレージは、Azure NetApp Files ボリュームを含む指定されたサブネットから得られます。
