OpenShift Virtualization 上の単一インスタンスの Oracle Database

この記事では、Red Hat OpenShift Virtualization 上での単一インスタンス Oracle Database 19c の実行をサポートする Red Hat のエンジニアリングの取り組みについて詳しく説明します。包括的なリファレンスアーキテクチャや、機能性、パフォーマンス、スケーラビリティ、ライブマイグレーションを含む検証の結果、また GitHub でホストされているアーティファクトのテストへのリンクを提供します。

ここでは、OpenShift Virtualization が Oracle データベースなどの要求の厳しいプロダクション・ワークロードに対して堅牢なパフォーマンスを提供し、パフォーマンスを犠牲にすることなく実行可能な仮想化の代替手段を提供することを実証します。これは、とくに OpenShift Virtualization 上の単一インスタンスの Oracle Database の評価と導入に関わるテクノロジーリーダー、アーキテクト、エンジニアリングチーム、プロジェクトマネージャー向けです。

アーキテクチャ設計の原則は、リソースの割り当て、パーティショニング、およびコンピュート、ネットワーク、ストレージにおける抽象化レイヤーの最適化に焦点を当てています。HammerDB を使用した TPC-C ベンチマークによるパフォーマンステストでは、Oracle Database がローカル NVMe ストレージを使用して OpenShift Virtualization 上で正常に実行され、Red Hat OpenShift Data Foundation のパフォーマンスを上回ることが実証されています。この記事では、可観測性と監視にも焦点を当て、Prometheus と Grafana を使用してインフラストラクチャおよび Oracle 固有の知見を提供します。

背景

多くのお客様が、パフォーマンスを犠牲にせずに仮想化に代わる選択肢を利用したいと考えています。OpenShift Virtualization は、エンタープライズ・データベースなど、要求の厳しいプロダクション・ワークロードに対して堅牢なパフォーマンスを提供します。

従来のソフトウェア・アーキテクチャで最も一般的なコンポーネントの 1 つは、Oracle Database です。OpenShift Virtualization 上での Oracle Database の評価および導入に関心のあるお客様を支援するため、Red Hat は専用のエンジニアリングリソースを確保し、OpenShift Virtualization 上での Oracle Database の運用を最適化する環境を提供しています。

この記事では、読者が Red Hat OpenShift Container Platform を理解していることを前提としています。また、ここでは、Oracle Database の一般的なアーキテクチャやパフォーマンスチューニングについては説明しません。代わりに、Oracle Database が最高のパフォーマンスを実現できるように OpenShift Virtualization をセットアップし、構成するためのアーキテクチャのオプションについて説明します。

この記事は、OpenShift Virtualization 上の単一インスタンスの Oracle Database の導入の評価、検証、決定に関わる、以下のような専門家を対象としています。

• テクノロジーリーダー (VP、CTO など)：ハイブリッドまたはオンプレミスのクラウド環境における Oracle Database ワークロードの日常的な運用において、投資対効果 (ROI) と TCO (総所有コスト) を最適化する責任を担うステークホルダー。
• アーキテクト：お客様のアーキテクトは、リファレンスアーキテクチャとテスト結果を確認して、OpenShift Virtualization が自社組織における Oracle Database ワークロードのホスティングに適切なプラットフォームであるかどうかを評価できます。この記事ではアーキテクチャの要件を提供し、アーキテクトが独立した検証を実行できるようにします。
• エンジニアリングチーム：エンジニアリングチームは、Red Hat がこの評価で実施したパフォーマンステストと、GitHub で入手可能な再利用可能な成果物を活用することで、テスト環境の構築と自動化を加速し、検証プロセスを効率化できます。
• プロジェクトマネージャー：プロジェクトマネージャーはリファレンスアーキテクチャを使用して、影響を受けるコンポーネントや担当チームを特定できます。標準化されたテストを使用することもできます。 

OpenShift Virtualization アーキテクチャの概要

OpenShift Virtualization は、オープンソースの KubeVirt プロジェクトを Red Hat が実装したものです。これは、標準の OpenShift プラットフォーム上に構築されています。仮想マシン (VM) はコンテナ化された Pod 内で実行され、OpenShift Container Platform は通常の Pod と同様に VM を管理します。VM インスタンスは、通常のコンテナアプリケーションと同様、セキュリティ、ネットワーク、ストレージなど、同じプラットフォームサービスにアクセスできます。唯一の違いは、VM がコンテナ内で実行される通常のワークロード・アプリケーションとは異なり、Pod レベルで直接管理されることです。

アーキテクチャ・コンポーネント：

• カーネルベースの仮想マシン (KVM)：OpenShift の VM ハイパーバイザーは Linux カーネルの一部です。
• 仮想マシンインスタンス (VMI)：VMI で表される各 VM は、QEMU が KVM を使用してハードウェアをエミュレートすることで作成され、QEMU はユーザー空間レベルでの分離を実現します。
• KubeVirt：VM を Kubernetes リソースとして管理する Kubernetes アドオンで、VM が Pod のように認識されるようにします。
  • virt-operator：KubeVirt コンポーネントのインストールと更新を管理します。
  • virt-controller：VM のライフサイクル管理を処理します (障害発生時の再起動、スケーリングなど)。
  • virt-handler：KubeVirt 対応ノードのデーモン。KVM/QEMU を使用してホスト上の VM を管理できるようにします。
  • virt-launcher：VM Pod ごとに 1 つ存在し、Pod 内の QEMU/KVM 仮想マシンプロセスを管理するオーケストレーターとして機能します。
  • カスタムリソース (CR)：VM 定義を表し、VM インスタンス、スケジューリング/ポリシーを実行します。
• Pod ラッパー：QEMU プロセスのラッパーとして機能します。VMI は、仮想化されたゲスト OS として Pod 内で実行されます。
• ストレージ：OpenShift Virtualization は、OpenShift Data Foundationや Portworx などのさまざまな Kubernetes ネイティブオプション、iSCSI やファイバーチャネル (FC) SAN ストレージなどの従来のエンタープライズ・ソリューションなど、さまざまなストレージ・ソリューションをサポートします。オープンソースの Ceph プロジェクトをベースに構築された、Kubernetes ネイティブのストレージ・ソリューションである OpenShift Data Foundation は、Kubernetes 環境向けに最適化された抽象化レイヤーで、スケーラブルで冗長なストレージを提供します。また、OpenShift Data Foundation は、永続ボリューム (PV) と永続ボリューム要求 (PVC) の動的プロビジョニングをサポートしているため、ストレージ管理が単純化されます。

この Oracle Database 検証プロジェクトでは、複数のストレージの選択肢を検討します。ただし、OpenShift Data Foundation は Kubernetes とシームレスに統合可能なため、この記事ではこの製品にとくに注目しています。Oracle Database ワークロードをデプロイする場合は、パフォーマンス要件と運用上のニーズに最適なストレージ・ソリューションを評価し、選択することが重要です。

ネットワーク：VM は Multus (CNI メタプラグイン) またはシングルルート I/O 仮想化 (SR-IOV) を介してネットワークにアクセスします。Multus は Pod レベルで定義されます。

Oracle Database の設計原則

Oracle Database が仮想化されたオペレーティングシステム上で実行されている場合、VM はデータベースが効率的に動作し、回復力を維持するのに適切なシステムリソースを受け取れるようにします。実際のインフラストラクチャ・リソースは限られているため、インフラストラクチャ・アーキテクチャはリソースをバランスよく割り当て、さまざまなワークロードのあらゆる要求に対応できるよう設計されている必要があります。

インフラストラクチャ・レベルで Oracle Database のパフォーマンスを向上させる一般的なアーキテクチャのアプローチには、次の原則が含まれます。

• リソースの配置：ボトルネックを解消するために、コンピュート、ストレージ、ネットワークの観点から十分なリソースを割り当てます。
• リソースのパーティショニング：リソースが限られている場合は、リソース要件を分割し、特定のニーズを満たすようにカスタマイズされたソリューションを実装します。
• 抽象化レイヤーの最適化：柔軟性を犠牲にして、不要な抽象化レイヤーや価値の低い抽象化レイヤーを使用することを避けて、パフォーマンスを向上させます。

Oracle Database は、次の 3 種類の主要なシステムリソースに大きく依存しています。

• コンピュート：これには、vCPU、IOThread、メモリー、ノード間でのスケーリングする機能が含まれます。
• ネットワーク：Oracle Database は I/O パフォーマンスの影響を非常に受けやすくなっています。クライアントアクセスとストレージアクセスでは、スループットとレイテンシーの要件が異なります。そのため、Oracle Database アーキテクチャでは、トラフィックの種類ごとに個別のネットワークを使用することがよくあります。
• ストレージ：REDO ログ、データベーステーブル、バックアップにはそれぞれ異なる読み取り/書き込みパフォーマンスのニーズがあります。最適な I/O パフォーマンスを確保するには、可能な限り、これらを別々の物理ストレージに配置する必要があります。

OpenShift Virtualization は、システムリソースのパーティショニングのニーズに基づくリソース割り当てについての各種アプローチをサポートするために必要な機能と柔軟性を提供します。

リファレンスアーキテクチャ

このセクションでは、OpenShift Virtualization の設計に関連した Oracle Database のアーキテクチャに関する考慮事項とソリューションの選択肢について説明します。

コンピュート

Oracle Database が十分なコンピュートリソースを確保していることを確認し、OpenShift Virtualization プラットフォームが以下の機能を直接制御できるようにします。

• リソースの垂直スケーリングのための vCPU と RAM の割り当てを設定する
• 水平方向のスケーラビリティを向上させる OpenShift Virtualization クラスタの拡張性
• VM IO スレッドカウントの割り当てを制御して、Pod レベルの I/O ボトルネックを排除する
• Oracle Database ワークロードをホストする仮想マシンに対して、システム上の物理リソースを超える仮想化 CPU やメモリーを割り当てるなど、リソースのオーバーコミットを回避する

ネットワーク

Oracle Database のトラフィックには、ネットワークレイテンシー、スループット、信頼性の面で異なるパフォーマンス要件があります。OpenShift Container Platform Pod Multus は、ネットワークトラフィックを分割し、複数のネットワークプロトコルを仲介する機能です。以下の点を検討しましょう。

• OpenShift SDN、ストレージ、仮想マシンにさまざまなネットワークパスを実装する。
• Oracle RAC Database インストールでは、RAC のインスタンス間の相互接続通信と「パブリック」ネットワーク通信用のネットワークトラフィックをさらに分離する。
• レイテンシーやスループットの影響を受けやすいミッションクリティカルなワークロードの場合は、仮想ネットワーク・インタフェースに SR-IOV を活用し、VM から基盤となる物理リソースへの直接パスを構築することを検討する。

ストレージ

前述のとおり、OpenShift Virtualization は、OpenShift Data Foundation や Portworx などの Kubernetes ネイティブオプションから、iSCSI やファイバーチャネル (FC) SAN などの従来のエンタープライズシステムまで、幅広いストレージ・ソリューションをサポートします。この柔軟性により、ユーザーはパフォーマンスと運用上のニーズに最適なストレージを選択できます。

適切なストレージオプションを選択するための普遍的なルールはありませんが、次の原則をガイドラインとして使用できます。

• 運用上の柔軟性 (プロビジョニングの容易さ、プラットフォームとの統合) の必要性とパフォーマンス (IO レイテンシー、スループット) の要件のバランス
• Oracle RAC データベースに必要な場合があるマルチ書き込みオプション (2 つ以上の VM による共有ボリューム) のサポート

ハードウェア構成

最初のパフォーマンステストの範囲は、現在利用可能なハードウェアリソースのセットに限定されています。 

クラスタの仕様：

• Dell R660 サーバー × 4
  • 128 CPU スレッド (Intel Xeon Gold 6430 の 2 ソケット)
  • 256 GB のメモリー
  • 1 TB のルートディスク
  • 1.5 TB NVME ドライブ × 4
  • 25 Gbps Broadcom NIC × 4
  • 25 Gbps インテル 810 NIC × 2

OpenShift Virtualization の構成

OpenShift Virtualization と OpenShift Data Foundation ストレージのデフォルト構成でも良好なパフォーマンスを実現できますが、データベースに特有の IO を多用するワークロード用のテスト・プラットフォームを最適化するために、追加の構成変更を実施しました。

• パフォーマンス・プロファイルを使用するように OpenShift Data Foundation を設定しました。
• OpenShift Data Foundation のストレージトラフィックを一般的なソフトウェア・デファインド・ネットワーク (OpenShift Container Platform SDN) トラフィックから分離するように、OpenShift Data Foundation と OpenShift Virtualization を設定しました。(第 8 章：ネットワーク要件 |デプロイメントの計画 | Red Hat OpenShift Data Foundation | 4.18)
• OpenShift Data Foundation ストレージと OpenShift Container Platform SDN から仮想マシン (Oracle Database および HammerDB テストハーネス) へのトラフィックを、別個の物理ネットワーク・インタフェースを使用して分離しました。レイテンシーを短縮してスループットを向上させるため、シングルルート I/O 仮想化 (SR-IOV) を使用して、影響を受ける仮想マシンにネットワーク・インタフェースを導入しました (図 2)。

クラスタの仕様：

• OpenShift バージョン：4.18.9
• OpenShift Virtualization：OperatorHub で有効化
• ノード：
  • ハイブリッド (コントロールプレーン/ワーカー/ストレージ) ノード × 3
  • ワーカーノード × 1
• ネットワーク (Oracle Database VM 専用)：
  • OpenShift SDN、OpenShift Data Foundation ストレージクライアント、OpenShift Data Foundation ストレージ・レプリケーション・トラフィックを分離するためにパーティション化された、4 つの Broadcom 25Gbps NIC を持つLACP ボンディング。
  • 仮想マシントラフィック用の 2 つの Intel x810 25 GB NIC。2 つの異なるサブネット (パブリックとプライベート) があり、SR-IOV を使用して仮想マシンに提示されるように構成されています。
• ストレージ (Oracle Database VM 専用)：パフォーマンス・プロファイルで構成され、別個のストレージネットワークを使用する、OpenShift Data Foundation ストレージ (1.5 TB NVMe ドライブ × 4 を搭載)。

Oracle Database の構成

Oracle Database をホストする仮想マシンは、リソースのオーバーコミットを回避し、さまざまなハードウェアオプションでのテスト結果を比較できるよう、中程度のサイズに設定されています。Oracle Database は Transaction Processing Performance Council Benchmark C (TPC-C) テスト用に特別に調整されておらず、ベストプラクティスに基づいた一般的なチューニングの変更がいくつかある以外は、ほとんどがデフォルト構成で使用されます。

仮想マシンのサイズ、ベンチマークテストのワークロードの仕様、およびモニタリング情報に基づいてチューニングパラメーターを選択しました。それぞれの変更の有効性を、テスト結果をベースラインの数値と比較して評価しました。Oracle Database の構成は、データベース・パフォーマンス・チューニング・ガイドの推奨事項に従ってさらに最適化できます。

図 3 は、Oracle Database と HammerDB クライアントアクセスが同じネットワーク上にあったことを示しています。仮想マシンのデータボリュームは、書き込み操作を改善するためにディスク容量を事前に割り当てるように設定されています。 

ストレージがデータベースのパフォーマンスに与える影響を評価するため、ローカルストレージ Operator を使用して NVMe ストレージを追加し、別のアドホックテストを行いました。

仮想マシンの仕様：

• OS：RHEL 8.10
• VM 数：1
• vCPU：16
• メモリー：48 GB
• ストレージ：RH ODF のブロックデバイスとして 250 GB (ルートと DB データが同一ボリューム上に存在)
• DataVolume：「preallocation: true」を使用して作成 (シックプロビジョニング)
• ネットワーク：SR-IOV を使用してパブリックサブネットに接続

Oracle Database シングルインスタンスの設定：

Oracle Database のバージョン：19c Enterprise Edition と Release Update 26 (バージョン 19.26)

• データベースは、OMF (Oracle Managed Files) を使用して、データファイル (OpenShift Data Foundation 対応ストレージのルートボリューム) のターゲットとしてファイルシステムでセットアップしました。
• 将来のバージョンの Oracle Database とのテストの互換性を確保するために、データベースは Container Database (CDB) アーキテクチャを使用して作成されました。
• メモリーの割り当てでは、DB 作成ウィザードの入力として 32 GB の totalMemory を使用しました (Oracle Database のインストールで SGA/PGA の分割を自動的に評価できるようになります)。
• 追加のチューニングパラメーター：
  • 4 つのデータファイルを手動で 32 GB に拡張
  • REDO ログのサイズを 4 GB に調整
  • 4 つの REDO ログディスクグループ
  • FILESYSTEMIO_OPTIONS：SETALL (非同期 IO と直接 IO を可能にする)
  • USE_LARGE_PAGES：AUTO (大きなサイズの SGA での CPU 使用率を最適化するため)

注：NVME 対応ストレージを使用するパフォーマンステストのために、NVME デバイスを使用して別のファイルシステムがマウントされ、データファイルのターゲット先として割り当てられています。

可観測性と監視

OpenShift は、インフラストラクチャとアプリケーションの両方のレイヤーでの監視を統合する、強力で統合された可観測性プラットフォームを提供します。メトリクスの収集、ロギング、アラート処理をネイティブにサポートし、Oracle Database などの外部アプリケーションからの可観測性データを含めるように拡張できます。この統一されたアプローチにより、エンドツーエンドの可視性が実現するとともに、運用の複雑さが軽減されます。

OpenShift Virtualization の可観測性は同じプラットフォームにシームレスに統合されているため、仮想マシン、システムリソース、ワークロード (単一の一貫した監視スタック内の Oracle Database など) を監視できます。

OpenShift 内にデプロイされた Oracle Database Observability Exporter は、Prometheus に公開される Oracle Database のパフォーマンス・メトリクスとメタデータを収集します。Grafana はこれらのメトリクスを可視化し、Oracle Database と VM のレイヤー全体で異常なパターン、リソースの負荷、パフォーマンスの問題を検出するためのリアルタイム・ダッシュボードを提供します。

データベースレベルの分析を強化するために、パフォーマンステスト中に HammerDB を活用してスナップショットを取得し、AWR (自動ワークロードリポジトリ) レポートを生成することができます。Prometheus や Grafana のメトリクスと組み合わせることで、これらのレポートはワークロードの動作や潜在的なボトルネックについて、より豊富で多面的な情報を提供できます。

さらに、Oracle Database Enterprise Manager は補完的なツールとしての機能を果たし、Oracle Database に合わせた詳細な診断と特殊な監視機能を提供します。OpenShift の統合可観測性プラットフォームと併用することで、インフラストラクチャや Oracle Database 固有の運用上の知見を包括的にカバーできます。

図 5 は、OpenShift Virtualization プラットフォームの可観測性および監視のセットアップの一部としてデプロイされた Grafana ダッシュボードの例を示しています。

図 6 は、OpenShift Virtualization プラットフォームにデプロイされた Oracle Database Grafana ダッシュボードの例を示しています。

システムパフォーマンス評価

このパフォーマンステストは、OLTP (オンライン・トランザクション処理) ワークロードにおけるデータベース・トランザクションのスループットとクエリのレイテンシーを測定するために設計されました。オープンソースのデータベース・パフォーマンス・テスト・ソフトウェアである HammerDB を使用して、前述のシステム詳細に基づいて単一インスタンス Oracle Database に対して TPC-C ベンチマークを使用し、OLTP のワークロードをシミュレートしました。TPC-C テストでは、頻繁に発生する顧客の注文、支払い、在庫確認、バッチ処理など、80% の書き込み操作と 20% の読み取り操作を含む実際の注文管理システムをシミュレートします。このテストの実行により、HammerDB が OpenShift Virtualization 内にある Oracle Database 上で TPC-C ワークロードを生成します。

テスト範囲の概要

HammerDB テストハーネスでは、スケール実行プロファイルを構成し、仮想ユーザー数が 20 から 100 までスケールアップする、意味のあるワークロードをシミュレートしました。また、500 のウェアハウスを使用して各テストを 20 分間実行しました。この設定は、現実的なプロダクションのシナリオを反映し、拡張するトランザクションの負荷下でのシステムのパフォーマンスを評価できるように設計されました。

リファレンスアーキテクチャ構成に基づくテスト結果では、OpenShift Data Foundation ストレージを使用した単一インスタンスの Oracle Database について、1 分あたりの新規注文数 (NOPM) および 1 分あたりのトランザクション数 (TPM) の指標が非常に高いことが確認されました。しかし、ローカル NVMe ストレージを備えた単一インスタンスの Oracle Database の方が、OpenShift Data Foundation のセットアップよりも優れたパフォーマンスを発揮しました。平均レイテンシーは比較的安定していますが、時折急上昇することが確認されました。

結論

OpenShift Virtualization は、Oracle Database 19c ワークロードをデプロイするための実行可能なプラットフォームです。OpenShift Virtualization はセットアップが簡単で、仮想マシンの作成の堅固なサポートを提供します。これらの要素を考慮すると、OpenShift Virtualization は強力な候補であり、競合する仮想化テクノロジーに代わる選択肢になります。Oracle Database 19c の現在のパフォーマンス検証は、OpenShift Virtualization プラットフォームでのエンタープライズグレードのパフォーマンスを示しています。

ローカルの NVMe ストレージを使用したアドホックテストにより、高性能ストレージオプションの影響を評価し、その結果、FC SAN のような高性能ストレージ・ソリューションへのアップグレードによって全体的なパフォーマンスが大幅に向上する可能性があることを示す強力な兆候が確認されました。

高性能ワークロードについては、以下のことを検討してください。

• Oracle Database データファイルおよび redo ログ用の FC SAN など、パフォーマンスを最適化する高性能ストレージオプション
• 仮想マシン、OpenShift SDN、およびストレージネットワーク用にネットワークをセグメント化する (OpenShift Virtualization ノード上で個別の物理デバイスを使用することを推奨)
• SR-IOV (シングルルート I/O 仮想化)(Oracle Database ワークロードをホストする仮想マシンの仮想ネットワーク・インタフェースのパフォーマンスを最適化するハードウェアによってサポートされている場合)
• ワークロードの要件に基づく Oracle Database 設定 USE_LARGE_PAGES を使用した HugePages。この構成はメモリーページサイズを調整します。とくに、デフォルト設定よりも大きな SGA を使用する場合にパフォーマンスを向上させるために推奨されます。

HammerDB のテストスクリプトは、この GitHub リポジトリにあります。

oracle-db-appdev-monitoring GitHub プロジェクトは、Oracle Database についての可観測性を提供して、ユーザーがアプリケーションやデータベース全体でパフォーマンスを把握し、問題を簡単に診断できるようにすることを目的としています。OpenShift プラットフォームでプロジェクトをセットアップする手順をご覧ください。