Azure NetApp Files アプリケーション ボリューム グループ FAQ

  • [アーティクル]

この記事では、Azure NetApp Files アプリケーション ボリューム グループに関してよく寄せられる質問 (FAQ) にお答えします。

一般的な FAQ

このセクションでは、Azure NetApp Files アプリケーション ボリューム グループに関する一般的な質問に回答します。

すべてのデータベース ボリュームに手動 QoS 容量プールを使用する必要があるのはなぜですか?

手動 QoS 容量プールは、データベースのニーズに合わせて容量とスループットの最適なバランスを提供します。 ログ ボリュームやデータ ボリュームなどのパフォーマンスに到達するオーバー プロビジョニングが回避されます。 また、ニーズに適した値にパフォーマンスを維持しながら、ログバックアップ用の大きな領域を予約することもできます。 全体的に、手動 QoS 容量プールを使用すると、コスト上の利点が得られます。

Note

アプリケーション ボリューム グループの作成中に、選択対象の一覧に表示されるのは手動 QoS 容量プールのみです。

アプリケーション ボリューム グループを使用して作成されたボリュームを複製できますか?

はい。アプリケーション ボリューム グループによって作成されたボリュームを複製できます。 これは、スナップショットを選択し、これを新しいボリュームに復元して行うことができます。 複製は、アプリケーション ボリューム グループ ワークフローの外部のプロセスです。 そのため、次の制限事項を考慮してください。

  • 1 つのボリュームを複製する場合、ボリューム グループに固有の依存関係はチェックされていません。
  • 複製されたボリュームは、ボリューム グループの一部ではありません。
  • 複製されたボリュームは、常にソース ボリュームと同じストレージ エンドポイントに配置されます。
  • 複製されたボリュームの待機時間を最も短くするには、ソース ボリュームと同じ IP アドレスでマウントする必要があります。

ボリューム グループの作成にはどれくらいの時間がかかりますか?

ボリューム グループの作成には多くの異なる手順が含まれており、それらすべてを並列で実行できるわけではありません。 特に、特定の場所の最初のボリューム グループを作成する場合、完了まで 9 分から 12 分かかることがあります。 それ以降のボリューム グループの作成にかかる時間は短くなります。

デプロイが失敗し、ボリュームが 1 つも作成されませんでした。 なぜでしょうか。

これは正常な動作です。 アプリケーション ボリューム グループは、いずれかのコンポーネントがデプロイに失敗した場合に備えて、アトミックな方法でボリュームをプロビジョニングし、デプロイをロールバックします。 通常、指定された場所に、要件に対応するのに使用できる十分なリソースがないためにデプロイは失敗します。 デプロイ ログで詳細を確認し、必要に応じて容量プールの構成を修正します。

ボリューム グループの説明を編集できないのはなぜですか?

現在の実装の場合、アプリケーション ボリューム グループでは、ボリューム グループの最初の作成と削除にのみ重点が置かれています。

データベース ボリュームにはどのようなスナップショット ポリシーを使用する必要がありますか?

データベース環境のアプリケーション整合性バックアップに AzAcSnap や Commvault などの製品を使用できます。 一貫性のあるデータ保護のために、Azure NetApp Files の組み込みスナップショット ポリシーによってスケジュールされた標準スナップショットを使用することはできません。

データベース環境内のスナップショットに関する一般的な推奨事項は次のとおりです。

  • データ ボリューム スナップショットを注意深く監視します。 スナップショットを長時間保持すると、容量のニーズが増える可能性があります。 使用済み容量と割り当て済み容量を必ず監視してください。
  • プライマリ データ保護のためにスナップショットを自動で作成する場合は、予測されていないボリューム容量の消費を避けるために、その保有期間を必ず監視してください。

SAP HANA のアプリケーション ボリューム グループに関する FAQ

このセクションでは、SAP HANA の Azure NetApp Files アプリケーション ボリューム グループに関する質問に回答します。

ボリュームのマウント手順には、IP アドレスの一覧が含まれます。 どの IP アドレスを使用すればよいですか?

アプリケーション ボリューム グループを使用すると、1 つのホストのデータ ボリュームとログ ボリュームで、異なる IP アドレスを持つ個別のストレージ エンドポイントを常に持ち、パフォーマンスを最大限に高めることができます。 Azure NetApp Files ストレージ リソース全体でデータ、ログ、および共有ボリュームをホストするには、使用される Azure NetApp Files ストレージ リソースごとに最大 6 つのストレージ エンドポイントを作成できます。 このため、委任されたサブネットのサイズを適宜変更することをお勧めします。 「SAP HANA のアプリケーション ボリューム グループの要件と考慮事項」を参照してください。 一覧表示されているすべての IP アドレスはマウントに使用できますが、最初に表示される IP アドレスが最も短い待機時間を提供します。 常に最初の IP アドレスを使用することをお勧めします。

マウント オプションとして nconnect を使用できますか?

Azure NetApp Files では、NFSv4.1 に対して nconnect はサポートされますが、次の Linux OS バージョンが必要です。

  • SLES 15SP2 以上
  • RHEL 8.3 以上

nconnect マウント オプションを使用する場合、読み取り制限は最大 4500 MiB/s であり (「Azure NetApp Files 用の Linux NFS マウント オプションのベスト プラクティス」を参照)、データ ボリュームに対して提案されているスループット制限を適宜、調整する必要がある場合があります。

{Hostid} プレースホルダーを削除した場合でも、hostid (00001 など) が自分の名前に追加されるのはなぜですか?

アプリケーション ボリューム グループでは、プレースホルダー {Hostid} が名前の一部である必要があります。 削除された場合、hostid は指定された文字列に自動的に追加されます。

[確認と作成] を選択した後、各ボリュームの最終的な名前を確認できます。

SAP HANA のアプリケーション ボリューム グループでデータ ボリュームに対して提案される最大スループット値が 1500 MiB/s であるのはなぜですか?

NFSv4.1 は、SAP HANA と Oracle でサポートされているプロトコルです。 そのため、1 つのボリュームをマウントする際に、1 つの TCP/IP セッションがサポートされます。 1 つのボリュームに対して 1 つの TCP セッション (つまり、1 つのホストから) を実行する場合、識別される一般的な I/O 制限は 1500 MiB/s です。 このため、SAP HANA のアプリケーション ボリューム グループにより、実際に実現できるよりも多くのスループットが割り当てられるのが回避されます。 特に大規模な (たとえば、12 TiB の) HANA データベースでより多くのスループットが必要な場合は、複数のパーティションを使用するか、nconnect マウント オプションを使用する必要があります。

最適なパフォーマンスとコスト効率を実現するために、SAP HANA で使用する Azure NetApp Files ボリュームのサイズを設定するにはどうすればよいですか?

最適なサイズ設定を行うためには、スナップショットやバックアップを含む完全なランドスケープのサイズ設定を行うことが重要です。 運用環境、HA、およびデータ保護のためのボリューム レイアウトを決定し、「SAP HANA デプロイ用の Azure NetApp Files サイズ設定計算ツール」を使用してサイズ設定を実行します。

警告メッセージ "Not enough pool capacity" が表示されます。 どうすればよいですか?

アプリケーション ボリューム グループでは、HANA メモリの入力に基づいて、すべてのボリュームの容量とスループットの需要を計算します。 容量プールを選択すると、その容量プールで使用できる十分な容量とスループットがあるかどうかがすぐに確認されます。

最初の SAP HANA 画面で、このメッセージを無視し、[次へ] ボタンをクリックしてワークフローを続行できます。 また、後で各ボリュームに対して提案された値を個別に調整して、すべてのボリュームが容量プールに収まるようにすることができます。 このエラー メッセージは、すべてのボリュームが容量プールに収まるまで、個々のボリュームを変更すると再び表示されます。

この警告メッセージを回避するために、プールのサイズを増やすこともできます。

システムまたはシステム全体のサイズを設定する方法を理解するにはどうすればよいですか?

SAP システム全体のサイズ設定の計画を支援する SAP Azure NetApp Files のサイズ設定エキスパートにお問い合わせください。

各システムに提供する必要がある重要な情報には、SID、ロール (運用、開発、運用前および QA)、HANA メモリ、スナップショット予約 (パーセント単位)、ローカル スナップショットの保有日数、ファイルベース バックアップの数、単一ホストおよび複数ホスト (ホストの数を含む)、および HSR (プライマリ、セカンダリ) などの項目が含まれます。

SAP HANA sizing estimator を使用して、サイジング プロセスを最適化できます。

(以前に HANA を実行していて) システムがわかっている場合は、これらの一般的な前提内容ではなく、実際のデータを手動で提供できます。

複数パーティションの新しい SAP HANA 機能を使用できますか?

SAP HANA のアプリケーション ボリューム グループは、複数パーティションに特に重点を置いて構築されていませんが、入力を調整しながら SAP HANA のアプリケーション ボリューム グループを使用できます。

複数パーティションの基本は次のとおりです。

  • 複数パーティションは、1 つの SAP HANA ホストで、永続性を保つために複数のボリュームを使用しているという意味です。
  • 複数のパーティションを異なるパスにマウントする必要があります。 たとえば、最初のボリュームが /hana/<SID>/data1/mnt00001 にあり、2 番目のボリュームには別のパス (/hana/<SID>/data2/mnt00002) が必要です。 この結果を得るには、名前付け規則を手動で調整する必要があります。 つまり、条件 <SID>-DATA1-MNT00001; <SID>-DATA2-MNT00002, ...を満たします。
  • メモリは、SAP HANA のアプリケーション ボリューム グループで容量とスループットのサイズを設定する際の鍵となります。 そのため、パーティションの数に合わせてサイズを調整する必要があります。 2 つのパーティションの場合、メモリの 50% を使用する必要があります。 3 つのパーティションの場合、メモリの 33% を使用する必要があります。

作成するホストとパーティションごとに、SAP HANA のアプリケーション ボリューム グループを再実行する必要があり、上記の推奨事項を満たすように名前付けの提案を調整する必要があります。

このトピックの詳細については、「Azure NetApp Files AVG for SAP HANA を使用して複数のパーティションで HANA をデプロイする」を参照してください。

HANA のデータとログ ボリュームについて提案されたスループットの根拠となったのは、どのような計算方法ですか?

SAP では、HANA ボリュームの主要業績評価指標 (KPI) を、データについては 400 MiB/秒、ログ ボリュームについては 250 MiB と定義しています。 この定義は、HANA データベースのサイズやワークロードとは関係がありません。 アプリケーション ボリューム グループでは、最小のデータベースであっても SAP HANA KPI が満たされるような方法でスループット値がスケーリングされます。大規模なデータベースでは、より高いスループット レベルの恩恵を受けるので、入力された HANA データベース サイズに基づいて提案がスケーリングされます。

次の表では、HANA データ ボリュームのメモリの範囲と提案されるスループットについて説明します。

メモリ範囲 (TB)提案されるスループット (MB/秒)
最小最大値
01400
12600
24800
461000
681200
8101400
10無制限1500

次の表では、HANA ログ ボリュームのメモリの範囲と提案されるスループットについて説明します。

メモリ範囲 (TB)提案されるスループット (MB/秒)
最小最大値
04250
4無制限500

データベース ボリュームのスループットは、ほとんどの場合、データベースの起動時にデータをメモリに読み込むのにかかる時間に影響します。 ただし、実行時には、ほとんどの I/O は書き込み I/O であり、KPI でもより低い値が示されます。 ユーザー エクスペリエンスでは、小規模なデータベースの場合、HANA KPI の値は、ほとんどの場合に必要な値よりも高くなる可能性があることが示されています。

各ボリュームの Azure NetApp Files のパフォーマンスは、実行時に調整できます。 そのため、データとログ ボリュームのスループットを特定の要件に合わせて調整することによって、いつでもデータベースのパフォーマンスを調整できます。 たとえば、起動時に高いスループットを許可し、一方で通常運用時では KPI を減らすことで、パフォーマンスを微調整してコストを削減することができます。

すべてのボリュームは SAP HANA サーバーに近接してプロビジョニングされますか?

SAP HANA サーバー用に作成した近接配置グループ (PPG) を使用すると、データ、ログ、および共有ボリュームが確実に SAP HANA サーバーの近くに作成され、最適な待機時間とスループットが実現されます。 ただし、ログバックアップ ボリュームとデータバックアップ ボリュームでは、低待機時間は必要ありません。 保護の観点からは、これらのバックアップ ボリュームをデータ、ログ、および共有ボリュームとは異なる場所に格納することが理にかなっています。 そのため、アプリケーション ボリューム グループでは、使用可能な十分な容量とスループットを持つ、リージョン内の別のストレージの場所にバックアップ ボリュームを配置します。

AVset、VM、PPG、Azure NetApp Files ボリューム間のリレーションシップはどのようなものですか?

近接配置グループ (PPG) には、直接または AVset 経由で、少なくとも 1 つの VM が割り当てられている必要があります。 PPG の目的は、VM の正確な場所を抽出し、この情報をアプリケーション ボリューム グループに渡して、まったく同じデータ センター内の Azure NetApp Files リソースを検索することです。 この設定は、PPG 内の少なくとも 1 つの VM が起動されている場合にのみ機能します。 通常は、PPG にデータベース サーバーを追加できます。

PPG には、すべての VM がシャットダウンされた場合、VM の再起動後に、以前と同じデータ センターで起動することが保証されないという副作用があります。 この状況にならないようにするには、すべての VM と PPG が関連付けられた AVset を使用し、HANA のピン留めワークフローを使用することを強くお勧めします。 このワークフローを使うと、再起動しても VM が移動しないようになるだけでなく、十分なコンピューティング リソースと Azure NetApp Files リソースを使用できる場所が確実に選択されるようになります。

複数ホストの SAP HANA システムの場合、HANA ホストをさらに追加すると共有ボリュームのサイズが変更されますか?

不正解です。 このシナリオは現在、サイズを手動で調整する必要があるまれなケースの 1 つです。 SAP では、4 つの HANA ホストごとに共有ボリュームのサイズを 1 x RAM に設定することが推奨されます。 共有ボリュームは最初の SAP HANA ホストの一部として作成されるため、既に 1 TB としてサイズ設定されています。 SAP HANA 用に共有ボリュームのサイズを適切に設定するための 2 つのオプションがあります。

  • たとえば、6 つのホストが必要であることが事前にわかっている場合、SAP HANA のアプリケーション ボリューム グループによる最初の作成時に 1 TB の提案を変更できます。 その時点で、スループット (つまり、QoS) を増やして、6 つのホストに対応することもできます。
  • 共有ボリュームをいつでも編集し、ボリュームの作成後にサイズとスループットを個別に変更できます。 この作業は、ボリューム配置グループ内で、あるいは Azure リソース プロバイダーまたは GUI を使用してボリューム内で直接行うことができます。

1 つのインスタンスだけでなく、複数の SAP HANA データベースに対してデータバックアップ ボリュームを作成したいと考えています。 どうすればよいですか?

ログバックおよびデータバックアップ ボリュームは省略可能であり、これらを近くに配置する必要はありません。 意図した結果を得る最善の方法は、SAP HANA のアプリケーション ボリューム グループから最初のボリュームを作成するときに、データバックアップまたはログバックアップ ボリュームを削除することです。 その後、標準のボリューム プロビジョニングを使用し、ニーズを満たす適切な容量とスループットを選択して、1 つの独立したボリュームとして独自のボリュームを作成できます。 データバックアップ ボリュームを示し、複数の SID に使用される名前付け規則を使用する必要があります。

Oracle のアプリケーション ボリューム グループに関する FAQ

このセクションでは、Oracle の Azure NetApp Files アプリケーション ボリューム グループに関する質問に回答します。

すべてのボリュームは、Oracle のデータベース サーバーと同じ可用性ゾーンにプロビジョニングされますか?

デプロイ ワークフローでは、すべてのボリュームが作成時に選択した可用性ゾーンに配置されます。これは、Oracle 仮想マシンの可用性ゾーンと一致する必要があります。 可用性ゾーンをサポートしていないリージョンの場合、ボリュームはリージョン スコープを使用して配置されます。

最適なパフォーマンスとコスト効率を実現するために、Oracle で使用する Azure NetApp Files ボリュームのサイズを設定するにはどうすればよいですか?

最適なサイズ設定を行うためには、HA、スナップショット、バックアップを含む完全なデータベース ランドスケープのサイズ設定を行うことが重要です。 運用環境、HA、およびデータ保護のためのボリューム レイアウトを決定し、「パフォーマンスやスケーラビリティを犠牲にせずに Azure で最も要求の厳しい Oracle ワークロードを実行する」、「Azure IaaS VM に対する Oracle ワークロードのサイズを設定するための見積もりツール」に従ってサイズ設定を実行します。 [Add Single Volume] 入力オプションを使用して、SAP on Azure NetApp Files Sizing Estimator を使用することもできます。

各ボリュームのサイズ設定に提供する必要がある重要な情報には、SID、ロール (運用、開発、運用前および QA)、スナップショット予約 (パーセント単位)、ローカル スナップショットの保有日数、ファイルベース バックアップの数、単一ホストおよび複数ホスト (ホストの数を含む)、およびデータの保護要件 (プライマリ、セカンダリ) が含まれます。 Oracle システム全体のサイズ設定の計画を支援する Oracle on Azure NetApp Files のサイズ設定エキスパートにお問い合わせください。

ボリュームのマウント手順には、IP アドレスの一覧が含まれます。 Oracle にはどの IP アドレスを使用する必要がありますか?

アプリケーション ボリューム グループを使用すると、データ、再実行ログ、アーカイブ ログ、バックアップ ボリュームでは、異なる IP アドレスを持つ個別のストレージ エンドポイントを常に持ち、パフォーマンスを最大限に高めることができます。 一覧表示されているすべての IP アドレスはマウントに使用できますが、最初に表示される IP アドレスが最も短い待機時間を提供します。 常に最初の IP アドレスを使用することをお勧めします。

Oracle ボリュームには、どのバージョンの NFS を使用する必要がありますか?

クライアントで Oracle dNFS を使用してボリュームをマウントします。 dNFS でのマウントは NFSv3 および NFSv4.1 で作成されたボリュームで動作しますが、NFSv3 を使用してボリュームをデプロイすることをお勧めします。 詳細とリリースの依存関係については、クライアントのオペレーティング システムと Oracle の注意事項を参照してください。 詳細については、「Oracle Database で Azure NetApp Files を使用する利点」と「Azure NetApp Files の複数ボリュームでの Oracle データベースのパフォーマンス」を参照してください。

大規模なデータベースで最適なパフォーマンスを実現するには、データベース サーバーで dNFS を使用してボリュームをマウントすることをお勧めします。 dNFS の構成を簡略化するには、NFSv3 を使用してボリュームを作成することをお勧めします。

Oracle ボリュームにはどのようなスナップショット ポリシーを使用する必要がありますか?

この質問は、Oracle のアプリケーション ボリューム グループに直接関連しません。 Oracle データベースのアプリケーション整合性バックアップに AzAcSnap や Commvault などの製品を使用できます。 Oracle データベースの一貫性のあるデータ保護のために、Azure NetApp Files の組み込みスナップショット ポリシーによってスケジュールされた標準スナップショットを使用することは "できません"。

Oracle 環境内のスナップショットに関する一般的な推奨事項は次のとおりです。

  • データベース対応のスナップショット ツールを使用して、データベース整合性スナップショットを作成します。
  • データ ボリューム スナップショットを注意深く監視します。 スナップショットを長時間保持すると、容量のニーズが増える可能性があります。 使用済み容量と割り当て済み容量を必ず監視してください。
  • バックアップ ボリュームのスナップショットを自動で作成する場合は、予測されていないボリュームの増加を避けるために、その保有期間を必ず監視してください。

Oracle で作成されたボリュームに対して、Oracle ASM を AVG と共に使用できますか?

Oracle 用の Azure NetApp Files アプリケーション ボリューム グループと組み合わせた Oracle ASM の使用はサポートされていますが、アプリケーション ボリューム グループ内のボリューム間のスナップショット整合性はサポートされていません。 ASM を使用する場合は、今後の通知まで、他の互換性のあるデータ保護オプションを使用することをお勧めします。

Oracle のデプロイに近接配置グループ (PPG) を必要に応じて使用できるのはなぜですか?

リソースの可用性が制限されたリージョンにデプロイする場合、最適な場所にボリュームをデプロイできない場合があります。 このような場合は、近接配置グループ機能を使用してボリュームをデプロイし、特定の条件で可能な限り最適なボリューム配置でデプロイを実現できます。 既定の設定では、PPG の使用は無効になっています。 サポート チャネルを介して近接配置グループの使用を有効にすることを要求する必要があります。

次のステップ