次の方法で共有


Oracle ワークロードを Azure Virtual Machines に移行するための容量計画

この記事は、Azure クラウド導入フレームワークのガイダンスに基づいており、Microsoft Azure での Oracle ワークロードのインフラストラクチャ容量計画に関する考慮事項について説明します。 この記事には、この計画プロセスを支援するための推奨事項とツールが含まれています。

容量計画は、Azure で Oracle データベース ワークロードを実行する際の効率的なパフォーマンスとコスト管理に不可欠です。 この記事では、リソースを正確に割り当て、パフォーマンスニーズのバランスを取り、コストを最適化するためのガイドライン、方法、ツールについて説明します。 特定の容量要件は、データベース ワークロードのパフォーマンス特性によって異なります。 これらの特性は、トランザクション、分析、または混合です。 Oracle データベース ワークロードの制約要因は、通常、処理能力、メモリ、スループットです。

容量計画は、Azure 上の Oracle アーキテクチャに適したインフラストラクチャを選択するのに役立ちます。 このプロセスを効果的に実装するには、データベースストレージ容量を理解する必要があります。

容量計画に関する考慮事項

Azure サービスとしてのインフラストラクチャ (IaaS) での Oracle ワークロードの容量計画は、ワークロード要件と使用可能な Azure リソースを深く理解する必要があるプロセスです。

全体的なパフォーマンスに関する考慮事項

  • 既存の環境は、Azure 上の Oracle データベース ワークロード要件の正確なサイズ設定メジャーとして機能しない場合があります。 Oracle 自動ワークロード リポジトリ (AWR) レポートを使用して、移行のワークロードまたはワークロードのパフォーマンス特性を理解します。 AWR レポートには、Oracle データベース ワークロードのパフォーマンス統計が含まれています。

  • AWR パフォーマンス統計情報が使用できない場合は、既存の環境をアプリケーション サーバーのサイズ設定メジャーとして使用できます。 アプリケーション サーバーとサービスとしてのプラットフォーム (PaaS) ソリューションのサイズが適切に設定されるように、アプリケーション サーバーからパフォーマンス メトリックを収集する必要があります。

    AWR レポートを収集するには、データベース ワークロードの Oracle 診断パック ライセンスを購入する必要があります。 統計パック レポートは、AWR レポートの代わりに使用できます。 Statspack レポートは AWR レポートのサブセットであり、診断パック ライセンスは必要ありません。

  • データベース ワークロードの AWR レポートを収集します。

    • ワークロードでピーク時の負荷が発生したとき。 ピーク時の読み込み時間がわからない場合は、busiest_awr スクリプト を使用して、最も負荷の高い AWR を特定します。

    • ピーク時の負荷を代表する期間。 たとえば、ピーク時の負荷が月末プロセスの場合は、月末プロセス中に AWR レポートを生成します。 期間には、ピーク負荷時間のみを含め、長期間の低負荷を除外する必要があります。 AWR レポートに低負荷期間を含める場合、パフォーマンス統計は実際のワークロードパフォーマンス要件ではなく平均を表します。

    • バッチ プロセスなどのアクティビティ、またはデータベースに対する大きな負荷を構成するその他のアクティビティの場合。

  • ピーク時の負荷と同様のシナリオで AWR レポートを収集します。 適切な仮想マシン (VM) SKU とストレージ構成を決定するには、Oracle AWR レポート に基づく Azure リソースのサイズ設定に関するページを参照してください。 複数の Oracle データベース ワークロードを管理し、複数のワークロードを同じ VM に統合することを検討している場合は、Oracle Migration Assistant Tool (OMAT)を使用します。 OMAT は、AWR レポートに基づいてインフラストラクチャ評価を生成し、可能な VM とストレージの構成に関する提案を提供する、自動サイズ設定評価ツールです。

コンピューティングに関する考慮事項

データベース ワークロードの基本的なパフォーマンス要件を決定したら、VM 計画に関する次の推奨事項を検討してください。

  • 制約付きコアを使用して、Oracle のライセンス コストを最適化します。 制約付きコアは、より大きな VM SKU のメモリとスループット容量を提供しながら、vCPU 容量をより小さな VM SKU に制限します。 この構成により、Oracle のライセンス コストが削減されます。ライセンスはプロセッサ コアに基づいているのでです。 詳細については、 クラウド コンピューティング環境での Oracle ソフトウェアのライセンス制約付きコア サイズに関するページを参照してください。

  • Oracle ワークロード用のメモリ最適化 VM を選択します。 メモリ最適化 VM は、汎用 VM と比較してメモリ対 vCPU 比が高いため、メモリを集中的に使用する Oracle ワークロードに最適です。 詳細については、 M シリーズ VM を参照してください。

  • パフォーマンスと互換性を向上させるには、最新の VM SKU を使用します。** Mdsv3Edsv6 などの最新の VM SKU には、堅牢なメモリ最適化オプションが用意されています。 サイズ設定の評価に基づいて、中メモリと高メモリのバリアントを選択します。

  • 高可用性とディザスター リカバリーのための追加の VM を含めます。 運用上の回復性を維持するために、高可用性、ディザスター リカバリー、非運用環境に必要な VM のアーキテクチャ アカウントを確保します。

ストレージに関する考慮事項

Oracle データベース ワークロードのパフォーマンスと信頼性は、基になるストレージ インフラストラクチャの設計と構成に大きく依存します。 ストレージ計画については、次のガイダンスを検討してください。

  • ワークロードの要件に基づいて、適切なマネージド ディスクの種類を選択します。 信頼性の高いパフォーマンスを確保するには、オペレーティング システム関連のアクティビティに Azure Premium SSD を使用します。 データ ディスクの場合は、パフォーマンス機能を強化するために Azure Premium SSD v2 をお勧めします。 Azure Ultra Disk Storage は、非常に高いスループットと低待機時間を必要とするワークロードに適しています。 運用環境の Oracle ワークロードには、Azure Standard SSD または Azure Standard HDD を使用しないでください。 詳細については、 Azure マネージド ディスクに関するページを参照してください。 その他のストレージ オプションには、 Azure Netapp FilesESAN が含まれます。

  • ワークロードの特性によっては、ディスク待機時間が問題になる場合があります。 ディスク待ち時間の詳細については、「Azure マネージド ディスクの種類」を参照してください。

  • OS 関連のアクティビティで 4 TB を超える必要がある場合は、複数の Premium SSD ディスクを使用し、RAID-0 にストライプします。 ホスト ディスク キャッシュは、4,095 GB を超えるディスクではサポートされていません。

  • Premium SSD v1 と Premium SSD v2 の違いについて説明します。 Premium SSD v1 は、他の VM トラフィックと帯域幅を共有し、パフォーマンスに影響を与える可能性がある Azure の元のアーキテクチャを使用します。 Premium SSD v2 では、Direct Drive アーキテクチャを利用してパフォーマンスを向上させ、待機時間を短縮します。 詳細については、 Premium SSD と Premium SSD v2 の違いを参照してください。

  • マネージド ディスクを使用する場合は、累積ディスク スループットを検討してください。 VM に接続されているすべてのディスクの累積スループットは、VM SKU によって制限されます。 詳細については、「仮想マシンとディスクパフォーマンス 」を参照してください。

  • スループット要件が 1 つの VM の最大スループットを超える場合は、このような構成のディスク スループットではなく、VM がネットワーク スループットまたはエグレスに制限されるため、Azure NetApp Files などのネットワーク ストレージの使用を検討してください。

  • Oracle 一時ファイルを頻繁に使用する場合は、一時ディスクを含む VM SKU を選択し、一時ファイルを一時ディスクに配置することを検討してください。 この構成により、データ ディスクの入出力 (I/O) の負荷が軽減されます。

次のステップ

  • Azure での Oracle の移行計画
  • Azure VM での Oracle のパフォーマンスに関するベスト プラクティス