SAS 分析ソフトウェアは、データから分析情報を引き出し、インテリジェントな意思決定を行うサービスとツールのスイートを提供します。 SAS のソリューションは、分析、人工知能、ビジネス インテリジェンス、カスタマー インテリジェンス、データ管理、不正行為とセキュリティのインテリジェンスを提供します。
Azure に SAS Grid をデプロイする場合、Azure NetApp Files は実現可能なプライマリ ストレージ オプションです。 Azure NetApp Files のスケーラブルなサービスを使用する場合は、サービスを中断することなく、ストレージ割り当てをいつでもスケールアップまたはスケールダウンできます。 さらに、ストレージ サービス レベルをパフォーマンス要件に合わせて動的に調整することもできます。
SAS は、Microsoft が検証した次の主要プラットフォームを提供します。
- SAS Grid 9.4
- SAS Viya
SAS Grid 9.4 は Linux で検証されました。
この記事では、SASDATA ストレージに Azure NetApp Files を使用して、Azure で SAS Grid 9.4 を実行するための一般的な情報を提供します。 また、SASWORK のストレージ オプションに関するガイダンスも提供します。 これらのガイドラインでは、独自の SAS ソリューションを、独自のテナント内で Azure 上でホストすることを前提としています。 SAS では、Azure 上の SAS Grid のホスティングは提供されません。
アーキテクチャ
"この記事のすべての図の PowerPoint ファイルをダウンロードします。"
データフロー
コンピューティング レベルでは、SASDATA (および必要に応じて SASWORK) ボリュームを使用して、グリッド全体でデータを共有します。 SASDATA は、Azure NetApp Files 上の NFS 接続ボリュームです。
- コンピューティング ノードは SASDATA から入力データを読み取り、結果を SASDATA に書き戻します。
- 分析ジョブの後続の部分は、コンピューティング レベルの別のノードによって実行できます。 同じ手順を使用して、処理する必要がある情報を取得して格納します。
考えられるユース ケース
Azure NetApp Files を使用するスケーラブルな SAS Grid デプロイは、次のユース ケースに適用できます。
- 財務分析
- 不正行為の検出
- 絶滅危惧種の追跡と保護
- 科学と医療
- 分析と AI
ストレージ パフォーマンスの要件
Azure 上の SAS 9.4 (SAS Grid または SAS Analytics Pro) デプロイの場合、Azure NetApp Files は、限られたサイズの SAS Grid クラスターに対して実行可能なプライマリ ストレージ オプションです。 SAS では、物理コアあたり 100 MiB/秒のスループットを推奨しています。 この推奨を考慮すると、SASDATA (永続 SAS データ ファイル) に Azure NetApp Files ボリュームを使用する SAS Grid クラスターは、2 つ以上の Azure 仮想マシンで 32 から 48 個の物理コアにスケーラブルです。 SAS クラスターのサイズは、SAS クラスターごとに 1 つの SASDATA 名前空間のアーキテクチャ上の制約と、使用可能な単一の Azure NetApp Files ボリューム帯域幅に基づいています。 コア カウントのガイダンスは、Azure インフラストラクチャ (コンピューティング、ネットワーク、ファイル システムごとのストレージ帯域幅) が時間の経過と同時に増加するにつれて再検討されます。
Azure NetApp Files ボリュームのタイプ
Azure NetApp Files には、ネットワーク接続ストレージ (NAS) ワークロード用の 2 種類のボリュームが用意されています。
通常のボリュームでは、次の内容が提供されます。
- 最大 4,500 MiB/秒の読み取り。
- 最大 1,500 MiB/秒の書き込み。
- 1 秒あたり 460,000 の入出力操作 (IOPS)。
- 最大 100 TiB の合計容量。
- 最小サイズ 100 GiB。
2024 年 5 月に一般提供に達した大規模なボリュームでは、次の情報が提供されます。
- 最大 10,000 GiB/秒のスループット。
- 最大 800,000 IOPS。
- 合計容量 1,000 TiB。
- 最小容量 50 TiB。
詳細については、「大きなボリュームに関する要件と考慮事項」を参照してください。
Azure NetApp Files の通常のボリューム パフォーマンスの期待値
1 つの Azure NetApp Files の通常ボリュームでは、最大で約 4,500 MiB/秒の読み取りと 1,500 MiB/秒の書き込みを処理できます。 十分なエグレス帯域幅を持つ Azure インスタンスのタイプを指定すると、1 つの仮想マシン (VM) で 1 つの Azure NetApp Files の通常のボリュームのすべての書き込み帯域幅を使用できます。 ただし、Azure で使用可能な最大の単一 VM のみが、1 つのボリュームのすべての読み取り帯域幅を消費できます。 ワークロードの帯域幅を増やす場合は、Azure NetApp Files の大容量の使用を検討してください。
SAS 9.4 の主な共有ワークロードである SASDATA の読み取り/書き込み比率は 80:20 です。 64 KiB の読み取り/書き込みを伴う 80:20 ワークロードのボリュームあたりの重要な数値は次のとおりです。
- 2,400 MiB/秒の読み取りスループットと 600 MiB/秒の書き込みスループットを同時に実行します。 合計スループットは約 3,000 MiB/秒です。
詳細については、「Azure NetApp Files の Linux 用パフォーマンス ベンチマーク」を参照してください。
SAS Grid の大容量パフォーマンス
1 つの Azure NetApp Files の大容量は、最大 10 GiB/秒の合計スループットを処理できます。つまり大きなスケールに対処する場合、SAS Grid のパフォーマンスの可能性がはるかに大きくなる可能性があります。
次の表に、さまざまな VM サイズの例を含む Azure NetApp Files の大容量ボリュームで SAS Grid を使用するワークロードのパフォーマンス結果を示します。 この一覧の例には、Red Hat Enterprise Linux (RHEL) 8.4 を使用するインスタンス数、インスタンスあたりのスレッド数、nconnect 値が含まれています。
| VM インスタンス | インスタンス数 | インスタンスあたりのスレッド数 | nconnect 値 |
スレッドあたりの読み取り MiB/秒 | スレッドあたりの書き込み MiB/秒 | 合計読み取り MiB/秒 | 合計書き込み MiB/秒 |
|---|---|---|---|---|---|---|---|
| E32s_v5 | 1 | 16 | 8 | 465 | 113 | 7,440 | 1,808 |
| E32s_v5 | 2 | 16 | 8 | 411 | 113 | 13,152 | 3,616 |
| E32s_v5 | 3 | 16 | 8 | 223 | 113 | 10,704 | 5,424 |
| E32s_v5 | 6 | 16 | 8 | 117 | 107 | 11,232 | 10,272 |
| E104id_v5 | 1 | 52 | 8 | 161 | 47 | 8,372 | 2,444 |
| E104id_v5 | 1 | 52 | 16 | 192 | 50 | 9,984 | 2,600 |
Note
SASDATA ボリュームまたは SASWORK ボリュームのパフォーマンスを高める必要がある場合は、Azure NetApp Files の大容量を使用します。 詳細については、「大きなボリュームに関する要件と考慮事項」を参照してください。
容量に関する推奨事項
Azure NetApp Files パフォーマンス計算ツールでは、SASDATA ボリュームのサイズ設定に関するガイダンスを得られます。
次の理由から、適切なサービス レベルを選択することが重要です。
- ボリューム帯域幅はボリューム容量に基づきます。
- 容量コストはサービス レベルに基づきます。
- サービス レベルの選択は、容量と帯域幅のニーズに基づきます。
計算ツールで [advanced] を選択し、リージョンを選択して、次の値を入力します。
- ボリューム サイズ: 必要な容量
- スループット: 必要なスループット (コアあたり 100 MiB/秒を考慮)
- 読み取り率: 80%
- IOPS: 0
- I/O サイズ: 64KiB シーケンシャル
画面下部の出力で、選択したリージョンの価格に基づいて、各サービス レベルで推奨される容量要件と 1 か月あたりのコストが示されます。
- スループット。 ワークロードの組み合わせに基づく、ボリュームの帯域幅。 80% の 64-KiB シーケンシャル読み取りワークロードの場合、3,096 MiB/秒が予想される最大値です。
- IOPS。 指定したスループットでボリュームにより提供される IOPS の数値。
- ボリューム サイズ。 必要なスループットを実現するために、特定のサービス レベルでボリュームに必要な容量。 ボリューム容量 (GiB で報告) は、容量プールのサイズと同じかそれより小さい場合があります。 この推奨事項は、自動 QoS 容量プールの種類を使用していることを前提としています。 容量プール内のボリューム間のスループット分散に対して容量をさらに最適化するには、手動の QoS 容量プールの種類を検討してください。
- 容量プール サイズ。 プールのサイズです。 ボリュームの容量は、容量プールから取られます。 容量プールのサイズは 1 TiB 単位です。
- 容量プール コスト (米ドル/月)。 指定されたサイズとサービス レベルでの容量プールの 1 か月あたりのコスト。
- ボリューム ショーバック (米ドル/月)。 指定した容量でのボリュームの容量の 1 か月あたりのコスト。 料金は、割り当てられた容量プールのサイズに基づいています。 ボリューム ショーバックは、ボリュームの量を示します。
注意
十分な帯域幅がプロビジョニングされている限り、サービス レベルに関係なく、ユーザー エクスペリエンスは同じです。
Azure NetApp Files のボリューム シェイプを使用して、必要に応じてコストを制御します。 パフォーマンスとコストに影響を与えるために、次の 2 つの動的オプションを使用できます。
Azure NetApp Files コスト モデルの詳細を確認してください。
データの保護
Azure NetApp Files では、スナップショットを使用してデータを保護します。 スナップショットを使用すると、スペース効率が高く、クラッシュ整合性があり、ほぼ瞬時の Azure NetApp Files ボリュームのイメージが提供されます。 スナップショットは任意のタイミングで手動で作成することも、ボリュームのスナップショット ポリシーを使用してスケジュールすることもできます。
スナップショット ポリシーを使用して、ボリュームに自動データ保護を追加します。 スナップショットの復元を使用することで、スナップショットをすぐに復元できます。 または、スナップショットを新しいボリュームに復元して、高速なデータ復旧を行うことができます。 また、新しいボリュームへの復元機能を使用して、テスト/開発環境に現在のデータを提供することもできます。
追加レベルのデータ保護のために、Azure NetApp Files バックアップまたはパートナー バックアップ ソフトウェアを使用するデータ保護ソリューションを使用できます。
コンポーネント
Azure Virtual Machines: SAS Grid には、コア数に対して適切な比率で、ハイ メモリ、ストレージ、I/O 帯域幅が必要です。 Azure には、メモリ量、ストレージ、I/O 帯域幅に対して必要なコア数のバランスを取るのに役立つ、vCPU の数が少ない定義済みの仮想マシン (VM) サイズが用意されています。
詳細については、「制約付き vCPU 対応の VM サイズ」を参照してください。 "各" インスタンスで使用できるコンピューティング リソースを十分に理解することが重要です。 Azure NetApp Files を使用して Azure 上で SAS Grid を実行するには、次のインスタンスの種類をお勧めします。
- Standard_E64-16ds_v4 または Standard_E64-16ds_v5
- Standard_E64-32ds_v4 または Standard_E64-32ds_v5
コメントの更新を含め、Azure で SAS を使用するためのベスト プラクティスを確認してください。
Azure NetApp Files: SASDATA は、Azure NetApp Files ボリュームに格納し、コンピューティング クラスター全体で共有できます。
必要に応じて、Azure NetApp Files NFS ボリュームを SASWORK に使用することもできます。
Azure NetApp Files は、次の 3 つのパフォーマンス サービス レベルで使用できます。
- Standard
- Premium
- Ultra
ボリュームのパフォーマンスは、主にサービス レベルによって定義されます。 取得可能なスループットはサービス レベルとボリュームのサイズによって決まるため、ボリュームのサイズも要因になります。
SASDATA のストレージ オプション
Azure NetApp Files はストレージへの高スループットと待機時間の短いアクセスを提供できるため、実現可能で高速な、Premium Disk の代替手段です。 ネットワーク接続ストレージは、マネージド ディスクのように VM レベルでは調整されないため、ストレージへのスループットが高くなります。
SASDATA 容量に必要なレベルを見積もるには、Azure NetApp Files パフォーマンス計算ツールを使用します。 (必ず [advanced] を選択してください)。
Azure NetApp Files NFS ボリュームは共有されるため、この記事の後半で説明する適切なサイズの VM インスタンスのタイプと RHEL ディストリビューションと共に使用すると、SASDATA をホストするのに適した候補になります。
SASWORK のストレージ オプション
次の表は、Azure に SASWORK をデプロイするための最も一般的なストレージ オプションを示しています。 サイズ (容量) と速度 (帯域幅) の要件に応じて、一時ストレージ、マネージド ディスク、Azure NetApp Files の 3 つのオプションがあります。
| 一時ストレージ | マネージド ディスク | Azure NetApp Files | |
|---|---|---|---|
| サイズ | Small | 大 | 特大 |
| 速度 | 特大 | Small | Medium |
オプションを選択するときは、次の事項を考慮してください。
- 一時ストレージ ("エフェメラル ストレージ") は最も高い帯域幅を提供しますが、より小さいサイズでのみ使用できます。 (サイズは VM SKU によって異なります)。使用可能な容量と必要な容量によっては、このオプションが最適な場合があります。
- 必要な SASWORK 容量が、選択した VM SKU の一時ストレージ サイズを超える場合は、Azure マネージド ディスクを使用して SASWORK をホストすることを検討してください。 ただし、マネージド ディスクへのスループットは設計上 VM のアーキテクチャによって制限され、VM SKU によって異なることに注意してください。 そのため、このストレージ オプションは、SASWORK のパフォーマンス要件が低い環境でのみ有効です。
- SASWORK の容量要件が最も高く、Azure マネージド ディスクで提供できる以上の平均的なパフォーマンス要件の場合は、SASWORK で Azure NetApp Files を検討してください。 これにより、より大きなサイズと高速スループットが提供されます。
重要
いずれのシナリオでも、SASWORK は VM コンピューティング ノード間で共有できないことに注意してください。そのため、コンピューティング ノードごとに個別の SASWORK ボリュームを作成する必要があります。 ボリュームは、1 つのコンピューティング ノードにのみ NFS マウントする必要があります。
前の表を使用して、ニーズが小、大、中、または特大のいずれであるかを特定するときは、デプロイの規模、VM とコアの数、および関連する容量とパフォーマンスの要件を考慮します。 デプロイごとにこれらの評価を行う必要があります。
表のオプションは、その後のアーキテクチャで説明されているデプロイに対応しています。 すべてのシナリオで、SASDATA は Azure NetApp Files の NFS ボリュームでホストされ、コンピューティング ノード間で共有されています。 一部の RHEL ディストリビューションでは、NFS の nconnect オプションを使用して、ボリュームへの複数のネットワーク フローを作成することをお勧めします。 詳細については、この記事の 「NFS マウント オプション」セクションを参照してください。
一時ストレージのアーキテクチャ
SASWORK の容量要件がより小さい場合、Azure VM の一時ストレージが高速でコスト効率の高いソリューションとなります。 このアーキテクチャでは、コンピューティング レベルの各 VM に何らかの一時ストレージが備わっています。 使用する VM の一時ストレージ サイズを特定するには、Azure VM のドキュメントを参照してください。
データフロー
- コンピューティング ノードは SASDATA から入力データを読み取り、結果を SASDATA に書き戻します。
- 分析ジョブの後続の部分は、コンピューティング レベルの別のノードによって実行できます。 同じ手順を使用して、処理する必要がある情報を取得して格納します。
- 一時作業ディレクトリ SASWORK は共有されません。 これは、各コンピューティング ノードの一時ストレージに格納されます。
マネージド ディスクのアーキテクチャ
SASWORK の容量要件が一時ストレージで使用可能な容量を超える場合は、Azure マネージド ディスクを使用することをお勧めします。 マネージド ディスクは、さまざまなサイズとパフォーマンス レベルで提供されています。 詳細については、「VM ディスクのスケーラビリティおよびパフォーマンスの目標」を参照してください。
データフロー
- コンピューティング ノードは SASDATA から入力データを読み取り、結果を SASDATA に書き戻します。
- 分析ジョブの後続の部分は、コンピューティング レベルの別のノードによって実行できます。 同じ手順を使用して、処理する必要がある情報を取得して格納します。
- 一時作業ディレクトリ SASWORK は共有されません。 これは、各コンピューティング ノードに接続されているマネージド ディスクに格納されます。
Azure NetApp Files のアーキテクチャ
SASWORK の容量が大きい場合や中程度のパフォーマンス要件がある場合は、Azure NetApp Files の使用を検討してください。 Azure NetApp Files では、通常のボリュームで最大 100 TiB、大容量ボリュームで 1 PiB のボリューム容量が提供されます。 コンピューティング レベルの各ノードには、独自の SASWORK ボリュームが必要です。 ボリュームは共有しないでください。
データフロー
- コンピューティング ノードは SASDATA から入力データを読み取り、結果を SASDATA に書き戻します。
- 分析ジョブの後続の部分は、コンピューティング レベルの別のノードによって実行できます。 同じ手順を使用して、処理する必要がある情報を取得して格納します。
- 一時作業ディレクトリ SASWORK は共有されません。 これは、各コンピューティング ノードに接続されている個々の Azure NetApp Files ボリュームに格納されます。
スケールと構成に関する推奨事項
- SAS クラスター内のインスタンス間のデータ トラフィックで最適かつ最も一貫性のある待機時間を実現するには、すべての VM が同じ近接配置グループに作成されるようにします。
- Azure で SAS を使用するためのベスト プラクティスに関するページで「General Tuning Guidance (一般的なチューニング ガイダンス)」セクションを確認してください。
- ネットワーク帯域幅を最適化するには、高速ネットワークを有効にします。
RHEL ディストリビューションと NFS 設定
RHEL ディストリビューション
Linux で SAS 9 を実行する場合は、RHEL が推奨されるディストリビューションです。 Red Hat でサポートされる各カーネルには、独自の NFS 帯域幅制約があります。
Azure での SAS の実行に関する詳細については、Azure での SAS の使用に関するベスト プラクティスに関する記事を参照してください。
SAS には、Azure Standard_E64 16ds_v4 VM と Standard_E64 32ds_v4 VM、または v5 のこれらに相当するものをお勧めします。 このセクションでは、これらの推奨事項を考慮に入れて、Azure NetApp Files で SAS を使用するためのガイドラインをいくつか示します。
RHEL 7 を使用する場合は、SASDATA の物理コア ターゲットあたり 100 MiB/秒に基づいて、Standard_E64-16ds_v4 または Standard_E64-16ds_v5 が最適な選択肢です。
- Standard_E64-16ds_v4: コアあたり 90 から 100 MiB/秒
- Standard_E64-32ds_v4: コアあたり 45 から 50 MiB/秒
RHEL 8.2 を使用する場合は、Standard_E64-16ds_v4 または Standard_E64-32ds_v4、または v5 の同等のものが、考えられるオプションとなります。 SASDATA のコア ターゲットあたり 100 MiB/秒とすると、Standard_E64-16ds_v4 が推奨されます。
- Standard_E64-16ds_v4: コアあたり 150 から 160 MiB/秒
- Standard_E64-32ds_v4: コアあたり 75 から 80 MiB/秒
RHEL 8.3 を使用する場合、コアごとのスループット ターゲットを考慮して、Standard_E64-16ds_v4 と Standard_E64-32ds_v4 の両方、またはその v5 に相当するものが完全に許容できます。
- 検証では、3,200 MiB/秒の読み取りを示しています。
- これらの結果は、NFS の
nconnectマウント オプションを使用して実現されています。
テストでは、単一の RHEL 7 インスタンスは、単一の Azure NetApp Files ストレージ エンドポイントに対して (つまり、ネットワーク ソケットに対して) 約 750 から 800 MiB/秒以下の読み取りスループットしか達成できないことを示しています。 64 KiB の rsize と wsize NFS マウント オプションを使用する場合、同じエンドポイントに対して 1,500 MiB/秒の書き込みを実現できます。 いくつかの証拠は、前述の読み取りスループットの上限が 3.10 カーネルの副作用であることを示唆しています。 詳細については、「RHEL CVE-2019-11477」を参照してください。
テストでは、4.18 カーネルを使用する 1 つの RHEL 8.2 インスタンスには、3.10 カーネルで注記されている制限が適用されないことが示されています。 そのため、64 KiB rsize と wsize NFS マウント オプションを使用する場合、1,200 から 1,300 MiB/秒の読み取りトラフィックを実現できます。 大規模なシーケンシャル書き込みの場合、RHEL 7 と同じ 1500 MiB/秒の達成可能なスループットが期待できます。
nconnect マウント オプション (RHEL 8.3 ディストリビューションの新機能) を使用した単一の RHEL 8.3 インスタンスでは、1 つの Azure NetApp Files ボリュームから約 3,200 MiB/秒の読み取りスループットを実現できます。 nconnect を適用する場合でも、1 つの Azure NetApp Files ボリュームに対して 1,500 MiB/秒を超える書き込みは期待できません。
カーネルのチューニング
スロット テーブルのエントリ
NFSv3 には、クライアントとサーバーの間のコンカレンシーをネゴシエートするメカニズムがありません。 クライアントとサーバーにはそれぞれ、他方を認識せずに制限が定義されています。 最高のパフォーマンスを得るには、クライアント側の sunrpc スロット テーブル エントリの最大数を、サーバー側でプッシュバックなしでサポートされているものと合わせる必要があります。 クライアントがサーバーのネットワーク スタックがワークロードを処理する能力を超えた場合、サーバー側は接続のウィンドウ サイズを減らすことで応答しますが、これはパフォーマンスにとって理想的ではありません。
最近の Linux カーネルでは、既定で、接続ごとの sunrpc スロット テーブルのエント サイズ sunrpc.max_tcp_slot_table_entries が 65,536 個の未処理操作をサポートするように定義されています。 これらのスロット テーブル エントリに同時実行の制限が定義されています。 Azure NetApp Files の既定値は 128 個の未処理操作であるため、このような高い値は不要です。
クライアントを同じ数値に調整することをお勧めします。
- カーネル チューニング (/etc/sysctl.conf を使用)
sunrpc.tcp_max_slot_table_entries=128
ファイル システム キャッシュのチューニング
ファイルシステム キャッシュのチューニングに関する次の要素も理解する必要があります。
- ダーティ バッファーをフラッシュすると、データがクリーンな状態となり、メモリ不足により削除されることになるまで、将来の読み取りで使用できるようになります。
- 非同期フラッシュ操作には、3 つのトリガーがあります。
- 時間ベース: vm.dirty_expire_centisecs または vm.dirty_writeback_centisecs 設定値によって定義された期間に達したバッファーは、クリーニング (フラッシュまたはストレージへの書き込み) 対象としてマークされる必要があります。
- メモリ不足: 詳細については、「vm.dirty_ratio | vm.dirty_bytes」を参照してください。
- 閉じる: ファイル ハンドルが閉じられると、すべてのダーティ バッファーがストレージに非同期的にフラッシュされます。
これらの要因は、4 つの設定値によって制御されます。 各チューニング値は、/etc/sysctl.conf ファイルで tuned または sysctl を使用して、動的かつ永続的にチューニングできます。 これらの変数をチューニングすると、SAS Grid のパフォーマンスが向上します。
- カーネルのチューニング (カスタム チューニング プロファイルを使用)
include = throughput-performancevm.dirty_bytes = 31457280vm.dirty_expire_centisecs = 100vm.dirty_writeback_centisecs = 300
NFS マウント オプション
永続的な SASDATA ファイルに使用される NFS 共有ファイル システムには、次の NFS マウント オプションをお勧めします。
RHEL 7 および 8.2
bg,rw,hard,rsize=65536,wsize=65536,vers=3,noatime,nodiratime,rdirplus,acdirmin=0,tcp,_netdev
RHEL 8.3
bg,rw,hard,rsize=65536,wsize=65536,vers=3,noatime,nodiratime,rdirplus,acdirmin=0,tcp,_netdev,nconnect=8
SASWORK ボリュームには次のマウント オプションを使用することをお勧めします。ここでは、該当ボリュームは SASWORK 専用に使用され、ノード間では共有されません。
RHEL 7 および 8.2
bg,rw,hard,rsize=65536,wsize=65536,vers=3,noatime,nodiratime,rdirplus,acdirmin=0,tcp,_netdev,nocto
RHEL 8.3
bg,rw,hard,rsize=65536,wsize=65536,vers=3,noatime,nodiratime,rdirplus,acdirmin=0,tcp,_netdev,nocto,nconnect=8
nocto マウント オプションの利点とコストの詳細については、「クローズツーオープンの整合性とキャッシュ属性タイマー」を参照してください。
また、「Azure NetApp Files: MS Azure 上の SAS Grid で使用する共有ファイル システム」 (コメント内のすべての更新を含む) も確認してください。
NFS 先読み設定
すべての RHEL ディストリビューションで NFS 先読みチューニング値を 15,360 KiB に設定することをお勧めします。 詳細については、「NFS マウントの先行読み取り永続的に設定する方法」を参照してください。
代替
上記のアーキテクチャのストレージ ソリューションは、Azure NetApp Files サービス レベル アグリーメントで示されているとおり、高可用性があります。 保護と可用性を向上させるために、Azure NetApp Files のリージョン間レプリケーションを使用してストレージ ボリュームを別の Azure リージョンにレプリケートできます。
ストレージ ソリューションを使用したボリュームのレプリケートには、次の 2 つの主な利点があります。
- アプリケーション VM に追加の負荷は発生しない。
- このソリューションにより、通常の操作中にターゲット リージョンで VM を実行する必要がなくなる。
ストレージの内容は、コンピューティング インフラストラクチャ リソースを使用せずにレプリケートされ、コピー先リージョンで SAS ソフトウェアを実行する必要はありません。 このシナリオをサポートするために、コピー先の VM を実行する必要はありません。
次のアーキテクチャは、Azure NetApp Files 上のストレージ コンテンツが 2 つ目のリージョンにレプリケートされる方法を示しています。そこのストレージには、運用データのレプリカが設定されます。 フェールオーバーが発生すると、セカンダリ リージョンがオンラインになり、2 番目のリージョンで運用を再開できるように VM が開始されます。 図に示されていないロード バランサーを再構成して、2 番目のリージョンにトラフィックを再ルーティングする必要があります。
このソリューションの一般的な RPO は、リージョン間レプリケーションの更新間隔が 10 分に設定されている場合、20 分未満です。
データフロー
- コンピューティング ノードは SASDATA から入力データを読み取り、結果を SASDATA に書き戻します。
- 分析ジョブの後続の部分は、コンピューティング レベルの別のノードによって実行できます。 同じ手順を使用して、処理する必要がある情報を取得して格納します。
- 一時作業ディレクトリ SASWORK は共有されません。 これは、各コンピューティング ノードに接続されている個々の Azure NetApp Files ボリュームに格納されます。
- Azure NetApp Files のリージョン間レプリケーションでは、リージョンの障害が発生した場合のフェールオーバーを容易にするために、すべてのスナップショットを含む SASDATA ボリュームが DR リージョンに非同期的にレプリケートされます。
考慮事項
これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
[信頼性]
信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。
Azure NetApp Files では、すべてのレベルとサポートされているすべてのリージョンについて、標準的な 99.99% の可用性の SLA を提供します。 Azure NetApp Files では、選択した可用性ゾーンでのボリュームのプロビジョニングと、ゾーン間の HA デプロイもサポートされます。
RPO/RTO の SLA を強化するために、スナップショットとバックアップを使用した統合データ保護がサービスに含まれています。 リージョン間レプリケーションにより、Azure リージョン全体で同じ利点を得られます。
セキュリティ
セキュリティは、重要なデータやシステムへの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
Azure NetApp Files では、ボリュームがプロビジョニングされ、データ トラフィックが仮想ネットワーク内に留まるため、一定レベルのセキュリティが提供されます。 パブリックにアドレス指定可能なエンドポイントはありません。 すべてのデータは常に保存時に暗号化されます。 必要に応じて、転送中のデータを暗号化できます。
Azure Policy は、組織の標準を適用してコンプライアンスを大規模に評価するのに役立ちます。 Azure NetApp Files では、カスタムと組み込みのポリシー定義により Azure Policy がサポートされています。
パフォーマンス効率
パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。
パフォーマンス
スループットと容量の要件に応じて、次の考慮事項に注意してください。
- Azure NetApp Files のパフォーマンスに関する考慮事項。
- SASDATA に必要な Azure NetApp Files の容量とサービス レベル。
- SASWORK のストレージの種類を選択するためのこの記事のガイダンス。
注意
Azure NetApp Files の大規模ボリューム機能が利用可能になりました。 この機能により、ボリュームあたりのスループットが、通常の Azure NetApp Files ボリュームよりも高くなります。 この機能は、SASDATA (または SASWORK) ボリュームに対してより高いパフォーマンスが必要とされる場合に考慮できます。 詳細については、このドキュメントを参照してください。
スケーラビリティ
SAS ソリューションの 3 つの層を実行するスケール セットに VM を追加することで、コンピューティング パフォーマンスを簡単にスケーリングできます。
Azure NetApp Files ボリュームのストレージは動的にスケーリングできます。 自動 QoS を使用すれば、パフォーマンスが同時にスケーリングされます。 各ボリュームをより細かく制御する場合は、容量プールに手動 QoS を使用して、各ボリュームのパフォーマンスを個別に制御することもできます。
Azure NetApp Files のボリュームは、Ultra、Premium、Standard の 3 つのパフォーマンス レベルで使用できます。 使用可能なパフォーマンス帯域幅がボリュームのサイズに応じてスケーリングされることを考慮して、パフォーマンス要件に最適なレベルを選択します。 ボリュームのサービス レベルはいつでも変更できます。 Azure NetApp Files のコスト モデルの詳細については、これらの価格の例を参照してください。
Azure NetApp Files パフォーマンス計算ツールを使用して、作業を開始できます。
コスト最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させることです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
コスト モデル
Azure NetApp Files のコスト モデルを理解すると、経費を管理するのに役立ちます。
Azure NetApp Files の料金は、プロビジョニングされた容量プールに基づいており、これは容量プールを作成することによって割り当てます。 容量プールは、1 時間あたりの割り当て済み GiB あたりの設定コストに基づいて毎月課金されます。
(容量やパフォーマンスのニーズの変動などにより) 容量プールのサイズ要件が変動する場合は、容量およびパフォーマンスのニーズとバランスが取れたコストになるように、ボリュームと容量プールの動的なサイズ変更を検討してください。
容量プールのサイズ要件は同じままだがパフォーマンス要件が変動する場合は、ボリュームのサービス レベルを動的に変更することを検討してください。 1 か月を通じてさまざまなタイプの容量プールをプロビジョニングおよびプロビジョニング解除することで、Just-In-Time のパフォーマンスを提供し、ハイ パフォーマンスが必要でない期間のコストを削減することができます。
価格
容量とパフォーマンスの要件に基づいて、必要な Azure NetApp Files サービス レベル (Standard、Premium、Ultra) を決定します。 次に、Azure 料金計算ツールを使用して、これらのコンポーネントのコストを評価します。
- Azure 上の SAS コンポーネント
- Azure NetApp Files
- マネージド ディスク (必要に応じて)
- 仮想ネットワーク
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスの重要な要素の概要」を参照してください。
Azure 上の SAS Grid は、柔軟性と迅速なデプロイを提供します。 いくつかの利点を次に示します。
- 動的なワークロード バランスを使用して変化するビジネスニーズに対応する
- 可用性の高い SAS コンピューティング環境を作成する
- 既存の IT インフラストラクチャからより迅速に結果を得る
- コンピューティング リソースを段階的かつコスト効率よく拡張する
- すべての分析ワークロードを管理する
- サイロ化されたサーバーまたは複数の PC 環境から SAS グリッド環境に簡単に移行する
このシナリオのデプロイ
コードとしてのインフラストラクチャ (IaC) プロセスを使用してワークロードをデプロイするのが最適です。 SAS ワークロードは、手動デプロイで発生することがよくある設定によって影響を受けやすく、生産性が低下する可能性があります。
Azure 上の SAS Grid ソリューションの設計を開始するには、「Azure 上の SAS アーキテクチャ」と、GitHub Actions を使用した Azure での SAS デプロイの自動化に関するページを参照してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- Geert van Teylingen | グループ プロダクト マネージャー
- Arnt de Gier | テクニカル マーケティング エンジニア
その他の共同作成者:
- Mick Alberts | テクニカル ライター
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
- Azure の使用開始に関するクイックスタート ウェビナー
- Azure NetApp Files: Azure 上の SAS Grid で使用する共有ファイル システム
- Azure NetApp Files パフォーマンス計算ツール
- Azure NetApp Files のドキュメント
- トレーニング: Azure NetApp Files の概要
- 大きなボリュームに関する要件と考慮事項