Azure 上の Oracle Database Enterprise Edition のアーキテクチャ
適用対象: ✔️ Linux VM
Azure は、Oracle を使用して Azure で最適に実行し続ける必要があるワークロードを含め、すべての Oracle ワークロードのホームです。 Oracle Diagnostic Pack または Automatic Workload Repository (AWR) がある場合は、ワークロードに関するデータを収集できます。 このデータを使用して Oracle ワークロードを評価し、リソースのニーズのサイズを設定し、Azure に移行します。 これらのレポートで Oracle から提供されるさまざまなメトリックによって、アプリケーションのパフォーマンスとプラットフォームの使用状況を把握できます。
この記事は、Azure で実行する Oracle ワークロードを準備し、最適なクラウド パフォーマンスを提供するベストのアーキテクチャ ソリューションを模索する上で役に立ちます。 Oracle の Statspack とそれをさらに進化させた AWR から提供されるデータは、明確な予想を立てる上で役に立ちます。 これらの予想には、アーキテクチャを介した物理的なチューニングの制限、データベース コードの論理的なチューニングのメリット、およびデータベース全体の設計などがあります。
2 つの環境の違い
オンプレミス アプリケーションを Azure に移行する場合は、2 つの環境の重要な違いを念頭に置いておきます。
重要な違いの 1 つは、Azure 実装では、VM、ディスク、仮想ネットワークなどのリソースが他のクライアントとの間で共有される点です。 また、要件に基づいてリソースをスロットルできます。 Azure では、失敗の回避に焦点を当てる代わりに、失敗の克服に重点を置いています。 最初の方法では、平均故障間隔 (MTBF) を増やそうとし、2 番目の方法では 平均復旧時間 (MTTR) を減らそうとしています。
オンプレミスの実装と Oracle データベースの Azure 実装の違いの一部を次の表に示します。
| オンプレミスの実装 | Azure 実装 | |
|---|---|---|
| ネットワーク | LAN/WAN | ソフトウェアによるネットワーク制御 (SDN) |
| セキュリティ グループ | IP/ポートの制限ツール | ネットワーク セキュリティ グループ (NSG) |
| 回復力 | MTBF | MTTR |
| 定期的なメンテナンス | 修正/更新プログラム | 可用性セット (修正/更新プログラムは Azure によって管理) |
| リソース | 専用 | 他のクライアントと共有 |
| リージョン | データ センター | リージョンのペア |
| Storage | 記憶域ネットワーク/物理ディスク | Azure 管理のストレージ |
| スケール | 垂直スケール | 水平スケール |
必要条件
移行を開始する前に、次の要件を考慮します。
- 実際の CPU 使用率を確認します。 Oracle はコアによってライセンス供与されるため、vCPU で必要とされるサイズの設定は、コストを削減するために不可欠である場合があります。
- データベース サイズ、バックアップ ストレージ、増加率を確認します。
- I/O 要件を決定します。これは、Oracle Statspack と AWR レポートに基づいて見積もることができます。 また、オペレーティング システムから使用できるストレージ監視ツールから要件を見積もる方法もあります。
構成オプション
AWR レポートを生成し、そこから構成に関する決定を行うのに役立ついくつかのメトリックを取得することをお勧めします。 さらに、Azure 環境でのパフォーマンスを向上させるために調整できる領域は 4 つあります。
- 仮想マシンのサイズ
- ネットワーク スループット
- ディスクの種類と構成
- ディスク キャッシュの設定
AWR レポートの生成
Azure への移行を予定している既存の Oracle Enterprise Edition データベースがある場合は、選択肢がいくつかあります。 Oracle インスタンス用の Diagnostics Pack がある場合は、Oracle AWR レポートを実行して、メトリック (IOPS、Mbps、GiB など) を取得することができます。 Diagnostics Pack ライセンスのないデータベースまたは Oracle Standard Edition データベースの場合は、手動スナップショットが収集された後に Statspack レポートを使用して同じ重要なメトリックを収集できます。 これら 2 つのレポート方法の主な違いは、AWR は自動的に収集され、Statspack よりもデータベースに関する情報がより多く提供される点です。
比較できるように、通常とピーク時の両方のワークロード時に AWR レポートを実行することを検討してください。 より正確なワークロードを収集するには、1 日ではなく 1 週間の拡張ウィンドウ レポートを検討してください。 AWR では、レポートでの計算の一部として平均が示されます。 既定で、AWR リポジトリでは 8 日分のデータが保持され、1 時間間隔でスナップショットが取得されます。
データセンターの移行の場合は、運用システムのサイズ設定に関するレポートを収集する必要があります。 ユーザー テスト、テスト、開発に使用される残りのデータベース コピーをパーセンテージで見積もります。 たとえば、運用のサイズ設定の 50% と見積もります。
コマンド ラインから AWR レポートを実行するには、次のコマンドを使用します。
sqlplus / as sysdba
@$ORACLE_HOME/rdbms/admin/awrrpt.sql;
主要なメトリック
このレポートでは、次の情報を入力するよう求められます。
- レポートの種類: HTML またはテキスト。 HTML の種類は、より詳細な情報を提供します。
- 表示するスナップショットの日数。 たとえば、1 時間間隔の場合、1 週間のレポートでは 168 のスナップショット ID が生成されます。
- レポート ウィンドウの開始
SnapshotID。 - レポート ウィンドウの終了
SnapshotID。 - AWR スクリプトで作成されるレポートの名前。
Real Application Cluster (RAC) で AWR レポートを実行する場合、コマンド ラインのレポートは awrrpt.sql ではなく awrgrpt.sql です。 この g レポートでは、RAC データベース内のすべてのノードについてのレポートが 1 つのレポートに作成されます。 このレポートを使用すると、RAC ノードごとに 1 つずつレポートを実行する必要がなくなります。
AWR レポートから次のメトリックを取得できます。
- データベース名、インスタンス名、およびホスト名
- Oracle によるサポート可能性のためのデータベース バージョン
- CPU またはコア
- SGA または PGA、およびサイズが不足している場合に通知するアドバイザー
- メモリの合計 (GB)
- CPU ビジーのパーセント
- DB の CPU
- IOPS (読み取り/書き込み)
- Mbps (読み取り/書き込み)
- ネットワーク スループット
- ネットワーク待機時間の割合 (高/低)
- 上位の待機イベント
- データベースのパラメーター設定
- データベースが RAC であるか、Exadata であるか、高度な機能または構成を使用しているかどうか
仮想マシンのサイズ
最適なパフォーマンスを実現する仮想マシンのサイズを構成するために実行できる手順を次に示します。
AWR レポートの CPU、メモリ、I/O 使用率に基づき、VM のサイズを見積もる
システムのボトルネックの場所を示す、合計待機時間が長かった上位 5 つのフォアグラウンドのイベントを確認します。 たとえば、次の図では、ログ ファイルの同期が最上位にあります。 これは、ログ ライターから REDO ログ ファイルにログ バッファーを書き込むまでに必要な待機回数を示しています。 これらの結果は、パフォーマンスの高いストレージまたはディスクが必要なことを示します。 また、この図には、CPU コアの数とメモリの量も表示されています。
次の図は、読み取りと書き込みの I/O の合計数を示しています。 レポート期間中に、59 GB の読み取りと 247.3 GB の書き込みが行われました。
VM の選択
AWR レポートから収集した情報に基づき、次のステップでは要件を満たすサイズの VM を選択します。 使用可能な VM について詳しくは、「メモリ最適化済み仮想マシンのサイズ」をご覧ください。
ACU に基づき、同様の VM シリーズで VM のサイズを細かく調整する
VM を選択した後に、VM の Azure コンピューティング ユニット (ACU) に注意を向けてください。 お客様の要件に合うように、ACU の値に基づいて別の VM を選択することもできます。 詳細については、「Azure コンピューティング ユニット」をご覧ください。
ネットワーク スループット
次の図は、スループットと IOPS の関係を示します。
ネットワーク スループットの合計は、次の情報に基づいて見積もられます。
- SQL*Net トラフィック
- Mbps × サーバー数 (Oracle Data Guard などの送信ストリーム)
- その他の要因 (アプリケーションのレプリケーションなど)
ご利用のネットワーク帯域幅の要件に基づいて、多彩な種類からゲートウェイを選択できます。 これらの種類には、Basic、VpnGw、Azure ExpressRoute が含まれます。 詳細については、「VPN Gateway の価格」を参照してください。
推奨事項
- オンプレミスのデプロイと比べて、ネットワーク待機時間が比較的長くなります。 ネットワークのラウンド トリップ数を削減すると、パフォーマンスが大幅に向上します。
- ラウンドトリップ数を削減するには、同じ仮想マシン上のトランザクション数が多いアプリケーション、つまり おしゃべりな アプリを統合します。
- ネットワーク パフォーマンスを向上させるには、高速ネットワークで仮想マシンを使用してください。
- 特定の Linux ディストリビューションについては、TRIM/UNMAP サポートを有効にすることを検討してください。
- 個別の仮想マシン上に Oracle Enterprise Manager をインストールします。
- Linux では、既定では大型のページは有効になっていません。 大型のページを有効にすることを検討し、Oracle DB で
use_large_pages = ONLYを設定します。 この方法は、パフォーマンスの向上に役立つ場合があります。 詳細については、「USE_LARGE_PAGES」を参照してください。
ディスクの種類と構成
ディスクを検討する際のヒントを次に示します。
"既定の OS ディスク": このディスクの種類は、永続データとキャッシュを提供します。 これらのディスクは起動時のオペレーティング システム アクセス用に最適化されており、トランザクション ワークロードやデータ ウェアハウス (分析) のワークロード向けには設計されていません。
"マネージド ディスク": Azure により、VM ディスクに使用するストレージ アカウントが管理されます。 必要とするディスクの種類とディスクのサイズを指定します。 種類は、ほとんどの場合で、Oracle ワークロード用の Premium (SSD) です。 Azure により自動的にディスクが作成、管理されます。 Premium SSD マネージド ディスクは、メモリ最適化および設計済みの VM シリーズでのみ使用できます。 特定の VM サイズを選択した後のメニューには、その VM サイズに基づいて使用可能な Premium Storage の SKU のみが表示されます。
VM でストレージを構成した後に、データベースを作成する前にディスクのロード テストを行うことができます。 待機時間とスループットの観点から I/O 率を知ることは、仮想マシンが待機時間の目標値を達成し、期待されるスループットをサポートしているかを把握するのに役立ちます。 アプリケーションのロード テスト用ツールは、いくつか提供されています (Oracle Orion、Sysbench、SLOB、Fio など)。
Oracle データベースをデプロイした後に、再度ロード テストを実行します。 通常とピーク時のワークロードを開始すると、結果には、お使いの環境内のベースラインが表示されます。 現実的なワークロード テストを行ってください。 実際に VM で実行する予定の内容と大きく異なっているワークロードを実行しても意味がありません。
Oracle は IO 集中型データベースである場合があるため、ストレージ サイズではなく IOPS レートに基づいてストレージのサイズを設定することが重要です。 たとえば、必要な IOPS 値が 5,000 でも、200 GB しか必要でない場合、提供されるストレージ サイズが 200 GB を超えても、P30 クラスの Premium ディスクを利用することになります。
AWR レポートから IOPS レートを取得できます。 REDO ログ、物理読み取りと書き込みの速度によって、IOPS の速度が決まります。 選択した VM シリーズがワークロードの I/O 要求を処理できることを必ず確認してください。 VM の I/O 制限がストレージよりも低い場合は、VM によって制限の最大値が設定されます。
例: REDO のサイズは 12,200,000 バイト/秒で、これは 11.63 Mbps と等しく、 IOPS 値は 12,200,000 / 2,358 = 5,174 です。
I/O 要件を明確に把握した後に、これらの要件に最適なドライブの組み合わせを選択できます。
ディスクの種類に関する推奨事項
- DATA 表領域では、管理ストレージまたは Oracle Automatic Storage Management (ASM) を使用して、複数のディスク全体に I/O ワークロードが分散されます。
- Oracle の高度な圧縮を使用して、データとインデックスの両方で I/O を削減します。
- REDO ログ、TEMP および UNDO 表領域は、それぞれ別のデータ ディスクに分離します。
- 既定のオペレーティング システム ディスクにアプリケーション ファイルを保存しないでください。 これらのディスクは VM の高速起動用に最適化されていないため、アプリケーションに適切なパフォーマンスが提供されない可能性があります。
- Premium Storage で M シリーズの VM を使用する場合は、REDO ログ ディスクで書き込みアクセラレータを有効にします。
- 待機時間が長い REDO ログを Ultra ディスクに移動することを検討します。
ディスク キャッシュの設定
ホスト キャッシュには 3 つのオプションがありますが、Oracle データベースのデータベース ワークロードに対しては、読み取り専用キャッシュのみをお勧めします。 読み取り/書き込みを使用すると、データ ファイルに重大な脆弱性が生じるおそれがあります。データベース書き込みの目的は、情報をキャッシュすることではなく、データ ファイルに記録することにあるためです。 読み取り専用にすると、今後の読み取りのためにすべての要求がキャッシュされます。 すべての書き込みは、引き続きディスクに書き込まれます。
ディスク キャッシュに関する推奨事項
スループットを最大化するには、可能な限りホスト キャッシュの読み取り専用から開始します。 Premium Storage では、読み取り専用オプションを使用してファイル システムをマウントするときに、バリアを無効にする必要があることに注意してください。 ディスクに汎用一意識別子を使用して /etc/fstab ファイルを更新します。
- オペレーティング システム ディスクの場合は、Premium SSD と読み取り/書き込みホスト キャッシュを使用します。
- Oracle データ ファイル、一時ファイル、制御ファイル、ブロック変更追跡ファイル、BFILE、外部テーブル用のファイル、フラッシュバック ログを含むデータ ディスクの場合は、Premium SSD と読み取り専用ホスト キャッシュを使用します。
- Oracle オンライン REDO ログ ファイルを含むデータ ディスクの場合は、ホスト キャッシュなし ([なし] オプション) で Premium SSD または UltraDisk を使用します。 アーカイブされた Oracle REDO ログ ファイルと Oracle Recovery Manager のバックアップ セットは、オンラインの REDO ログ ファイルと一緒に置くこともできます。 ホスト キャッシュは 4,095 GiB に制限されているので、ホスト キャッシュを使って P50 より大きい Premium SSD を割り当てないでください。 4 TiB を超えるストレージが必要な場合、RAID-0 で複数の Premium SSD をストライプします。 Linux LVM2 または Oracle 自動ストレージ管理を使用します。
ワークロードが日中と夜間で大きく異なり、I/O ワークロードでそれをサポートできる場合は、バーストを備えた P1-P20 Premium SSD により、夜間のバッチ読み込みや限られた I/O 要求の間に必要とされるパフォーマンスが得られる可能性があります。
セキュリティ
Azure 環境をセットアップし、構成した後に、ネットワークをセキュリティ保護する必要があります。 以下に、推奨事項をいくつか示します。
NSG ポリシー: NSG は、サブネットまたはネットワーク インターフェイス カードで定義できます。 セキュリティと強制ルーティング アプリケーション ファイアウォールの両方について、サブネット レベルではアクセスをより簡単に制御できます。
Jumpbox: アクセスの安全性を高めるために、管理者がアプリケーション サービスやデータベースに直接接続することは推奨されません。 管理者のコンピューターと Azure リソース間で Jumpbox を使用します。
管理者のコンピューターでは、Jumpbox にしかアクセスできないように、IP 制限をかける必要があります。 Jumpbox では、アプリケーションとデータベースにアクセスできる必要があります。
プライベート ネットワーク (サブネット): NSG ポリシーできめ細かく制御を設定できるように、アプリケーション サービスとデータベースを別個のサブネット上に配置することお勧めします。
