Oracle の Azure NetApp Files アプリケーション ボリューム グループについて

  • [アーティクル]

Oracle のアプリケーション ボリューム グループを使用すると、最適なパフォーマンスの、ベスト プラクティスに従った Oracle データベースを、エンタープライズ規模でインストールして運用するために必要なすべてのボリュームを、1 回のワンステップの最適化されたワークフローでデプロイできます。 アプリケーション ボリューム グループ機能は、Azure NetApp Files 機能を使用して、すべてのボリュームを VM と同じ可用性ゾーンに配置して、待機時間が最適化された自動デプロイを実現します。

Oracle のアプリケーション ボリューム グループには、プロセス全体を簡素化して標準化する多くの技術的改良が実装されているため、Oracle のボリューム デプロイの効率化に役立ちます。 最大 8 個のデータ ボリューム、オンライン再実行ログとアーカイブ再実行ログ、バックアップとバイナリなどの必要なボリュームはすべて、単一の "アトミック" 操作で (Azure portal、RP、または API を使用して) 作成されます。

Azure NetApp Files アプリケーション ボリューム グループを使用すると、Oracle データベースのデプロイ時間が短縮され、複数のストレージ エンドポイントの使用を含め、アプリケーション全体のパフォーマンスと安定性が向上します。 アプリケーション ボリューム グループ機能は、単一のボリュームを持つ小規模なデータベースから、最大 100 TiB サイズの複数のデータベースまで、幅広い Oracle データベース レイアウトをサポートします。 この機能は、待機時間が最適化されたパフォーマンスで最大 8 個のデータ ボリュームをサポートし、データベース VM のネットワーク機能によってのみ制限されます。

Oracle のアプリケーション ボリューム グループによってデプロイされているように、複数のストレージ エンドポイントを介して接続された複数のボリュームを使用すると、「複数のボリューム上の Oracle データベース」の記事で説明しているようにパフォーマンスが向上します。

Oracle のアプリケーション ボリューム グループは、Azure NetApp Files が対応しているすべてのリージョンでサポートされます。

主な機能

Oracle のアプリケーション ボリューム グループには、次の機能が用意されています。

  • ボリューム数 2 個の小規模なデータベースから、数百 TiB までの最大ボリューム数 12 個の巨大なデータベースまで、変異の大きい Oracle 構成をサポート。
  • 次のボリューム レイアウトを作成。
    • データ: 1 から 8 個のデータ ボリューム
    • ログ: オンライン再実行ログ ボリューム (log) と、必要に応じて 2 番めのログ ボリューム (log-mirror)
    • バイナリ: Oracle バイナリのボリューム (省略可能)
    • バックアップ: ログ バックアップをアーカイブするログ ボリューム (省略可能)
  • 手動 QoS 容量プール内にボリュームを作成
    ボリューム サイズおよび必要なパフォーマンス (MiB/秒) は、データベース サイズとデータベースのスループット要件に対するユーザーによる入力に基づいて提案されます。
  • アプリケーション ボリューム グループ GUI および Azure Resource Manager (ARM) テンプレートにより、サイズ管理とボリュームの作成を簡略化するためのベスト プラクティスが提供されます。 例:
    • システム ID (SID) とボリュームの種類に基づいてボリュームの名前付け規則を提案
    • ユーザーによる入力に基づいてサイズとパフォーマンスを計算

Oracle のアプリケーション ボリューム グループを使用すると、デプロイ プロセスを簡素化し、Oracle ワークロードのストレージ パフォーマンスを向上させることができます。 新機能の一部を次に示します。

  • 可用性ゾーンの配置を使用して、ボリュームがコンピューティング VM と同じゾーンに配置されるようにします。
    要求に応じて、可用性ゾーンのないリージョンで PPG ベースのボリューム配置を使用できます。これには手動プロセスが必要です。
  • データ ボリュームとログ ボリューム用に個別のストレージ エンドポイントを (異なる IP アドレスで) 作成。
    このデプロイ方法により、Oracle データベースのパフォーマンスとスループットが向上します。

アプリケーション ボリューム グループのレイアウト

Oracle のアプリケーション ボリューム グループは、次の規則に従って、入力と選択したリージョンおよびゾーンのリソースの可用性に基づいて複数のボリュームをデプロイします。

  • AVG は、同じネットワーク機能設定 (Standard または Basic) と同じ NFS バージョン (NFSv4.1 または NFSv3) を使用して、選択したゾーンに 1 から 8 個のデータ、ログ (および必要に応じてログ ミラー)、バックアップ、およびバイナリの各ボリュームをデプロイできます。
  • ホスティング容量プールには、手動 QoS を構成する必要があります。
  • データ ボリュームは、選択したゾーン内のできるだけ多くの Azure NetApp Files ストレージ エンドポイントに分散されるように、アンチアフィニティ規則に従ってデプロイされます。 ボリュームには、可能な限り最適な待機時間を実現するために DirectStorage エンドポイントも割り当てられます。
  • 容量とスループットの要件が許容する場合は、リソースに制約があるゾーン内の同じストレージ エンドポイントに最大 3 個のデータ ボリュームをデプロイできます。
  • ログ、ログ ミラー、およびバックアップ ボリュームは、グループ化しない規則に従ってデプロイされます。これらのボリュームはいずれもストレージ エンドポイントを共有できません。 これらのボリュームには、DirectStorage エンドポイントが割り当てられます。
  • バイナリ ボリュームは、ストレージ エンドポイントをバックアップ ボリュームと共有でき、DirectStorage エンドポイントを必要としません。

高可用性デプロイは、2 つの可用性ゾーンにボリュームを含めます。両方のゾーンに Oracle のアプリケーション ボリューム グループを使用してボリュームをデプロイできます。 Data Guard などのアプリケーション ベースのデータ レプリケーションを使用できます。 デュアルゾーン ボリューム レイアウトの例:

高可用性デプロイは、2 つの可用性ゾーンにボリュームを含めます。両方のゾーンに Oracle のアプリケーション ボリューム グループを使用してボリュームをデプロイできます。 Data Guard などのアプリケーション ベースのデータ レプリケーションを使用できます。 デュアルゾーン ボリューム レイアウトの例:

デュアルゾーン ボリューム レイアウトの図。

十分なリソース可用性がある 1 つのゾーン内に 8 個のデータ ボリュームとすべてのオプション ボリュームを持つ完全に構築されたデプロイは、次のようになります。

Oracle デプロイの図。

リソースに制約があるゾーンでは、前述のアンチアフィニティ アルゴリズムとグループ化しないアルゴリズムにより、ボリュームが共有ストレージ エンドポイントにデプロイされる可能性があります。 リソースに制約があるゾーンのボリューム レイアウトの例を次の図に示します。

8 個のデータ ボリューム レイアウトの図。

リソースに制約があるゾーンでは、アンチアフィニティ規則とグループ化しない規則を維持する間、ボリュームが共有ストレージ エンドポイントにデプロイされます。 結果のレイアウトでは、ログ ボリュームとログ ミラー ボリューム上にプライベート ストレージ エンドポイントがある一方、データ ボリュームはストレージ エンドポイントを共有していることが示されています。 ログ ボリュームとログ ミラー ボリュームは、ストレージ エンドポイントを共有しません。

次のステップ