Oracle データベースを使用したAzureへの SAP デプロイ

Azure ExpressRoute
SAP HANA on Azure Large Instances
Azure Virtual Machines
Azure Virtual Network
Azure NetApp Files

この参照アーキテクチャでは、高可用性 (HA) 構成で oracle Database on Azureで SAP NetWeaver を実行するための実証済みのプラクティスについて説明します。 アーキテクチャの基本原則は、サポートされているオペレーティング システムに適用されます。 特に指定がない限り、このアーキテクチャでは Linux が使用されていると仮定します。

Note

この参照アーキテクチャをデプロイするには、SAP 製品と Microsoft 以外の他のテクノロジに適したライセンスが必要です。

Architecture

次の図は、Azureの SAP on Oracle の参照アーキテクチャを示しています。 2 つの可用性ゾーンにデプロイすることをお勧めします。

Azureの Oracle 上の運用 SAP システムのアーキテクチャの図。

このアーキテクチャと関連するアーキテクチャのVisio ファイルをダウンロードします <>

Workflow

次のワークフローは、上記のダイアグラムに対応しています。

  1. ユーザーとエンタープライズ システムは、ハブ ネットワークを介してオンプレミスまたはピアリングされたAzure ネットワークから SAP スポーク仮想ネットワークに接続します。

  2. SAP Web Dispatcher と SAP アプリケーション サーバーは、アプリケーション層で要求を処理し、Oracle プライマリ ノードにデータベース呼び出しを送信します。

  3. Oracle Data Guard は同期されたスタンバイ データベースを別の可用性ゾーンに保持し、Oracle Data Guard オブザーバー仮想マシン (VM) はレプリケーションとフェールオーバーの準備を監視します。

  4. データベース ノードまたはゾーンの障害が発生した場合、Oracle Data Guard の高速開始フェールオーバーによってスタンバイ ノードがプライマリに昇格され、SAP アプリケーション サーバーが新しいプライマリ ノードに再接続されます。

  5. sapmntボリュームやtransportボリュームなどの共有 SAP ファイル システムは、選択した回復性のあるネットワーク ファイル システム (NFS) 層を通じて引き続き使用できます。 バックアップ サービスは、データベースとアプリケーションの VM を保護します。

Components

この参照アーキテクチャでは、システムの可用性を最大化するために、高可用性セットアップでAzure Oracle Database で実行される一般的な SAP 運用システムについて説明します。 目標復旧時間 (RTO)、目標復旧ポイント (RPO)、アップタイムの期待、システムの役割など、ビジネス要件に基づいてアーキテクチャとそのコンポーネントを調整できます。 HA を必要としない非運用環境またはワークロードの場合は、1 つの VM にシステムをデプロイできます。 ネットワーク レイアウトは、SAP 環境の主要なアーキテクチャ原則を示すために簡略化され、エンタープライズ ネットワーク全体を表すわけではありません。

ネットワーク

  • 仮想ネットワーク:Azure Virtual Networkは、セキュリティが強化されたAzureリソースを相互に接続します。 このアーキテクチャでは、仮想ネットワークは、 ハブスポーク トポロジのハブにデプロイする ExpressRoute ゲートウェイを介してオンプレミスに接続します。 このアーキテクチャには、独自のスポーク仮想ネットワーク内の SAP アプリケーションとデータベースが含まれており、仮想ネットワークは、アプリケーション (SAP NetWeaver)、データベース、および共有サービス (Azure Bastion など) ごとに個別のサブネットに分割されます。

    このアーキテクチャでは、仮想ネットワーク アドレス空間がサブネットに分割されます。 アプリケーション サーバーとデータベース サーバーはそれぞれ別のサブネットに配置しています。 この方法を使用すると、個々のサーバーではなくサブネット セキュリティ ポリシーを管理することで、サーバーをより簡単にセキュリティで保護できます。 また、データベースに適用されるセキュリティ規則をアプリケーション サーバーからクリーンに分離することもできます。

  • 仮想ネットワーク ピアリング: このアーキテクチャでは、 ピアリングされた複数の仮想ネットワークを持つハブアンドスポーク ネットワーク トポロジを使用します。 このトポロジは、Azureにデプロイされたサービスのネットワークのセグメント化と分離を提供します。 ピアリングにより、ピアリングされた仮想ネットワーク間で、Microsoft のバックボーン ネットワークを介した透過的な接続が可能になります。

  • ゾーン冗長ゲートウェイ:ゲートウェイは個別のネットワークを接続し、オンプレミス ネットワークをAzure仮想ネットワークに拡張します。 Azure ExpressRouteを使用して、パブリック インターネットを経由しないプライベート接続を作成することをお勧めしますが、サイト間接続を使用することもできます。 ゾーン障害から保護するには、ゾーン冗長 ExpressRoute または VPN ゲートウェイを使用します。 ゾーン展開とゾーン冗長デプロイの違いの詳細については、「Azure仮想ネットワーク ゲートウェイの信頼性」を参照してください。 ゾーンデプロイ内のゲートウェイには、Standard SKU の IP アドレスが必要です。

  • ネットワーク セキュリティ グループ (NSG): 仮想ネットワーク内の受信、送信、およびサブネットワーク内のトラフィックを制限するには、 NSG を 作成し、特定のサブネットに割り当てます。 ワークロード固有の NSG は、データベースとアプリケーションのサブネットをセキュリティで保護します。

  • アプリケーション セキュリティ グループ (ASG): アプリケーション ロールに基づいて NSG 内できめ細かなネットワーク セキュリティ ポリシーを定義するには、明示的な IP アドレスの代わりに ASG を 使用します。 VM ネットワーク インターフェイスを ASG に割り当て、それらのグループを NSG ルールのソースまたは宛先として使用します。

  • Nic： ネットワーク インターフェイス コントローラー (NIC) は、仮想ネットワーク上の VM 間のすべての通信を有効にします。 従来のオンプレミスの SAP デプロイでは、ビジネス トラフィックから管理トラフィックを分離するために、マシンごとに複数の NIC を実装しています。

    Azureでは、仮想ネットワークは、同じネットワーク ファブリック経由ですべてのトラフィックを送信するソフトウェア定義ネットワーク (SDN) です。 そのため、パフォーマンス上の理由から複数の NIC を使用する必要はありません。 ただし、組織でトラフィックを分離する必要がある場合は、VM ごとに複数の NIC をデプロイし、各 NIC を別のサブネットに接続できます。 その後、NSG を使用して、各サブネットに異なるアクセス制御ポリシーを適用できます。

    Azure NIC では、複数の IP アドレスがサポートされます。 このサポートは、インストールに仮想ホスト名を使用するための SAP 推奨プラクティスに準拠しています。 全体的な概要については、SAP Note 962955 を参照してください。 SAP ノートにアクセスするには、SAP Service Marketplace アカウントが必要です。

VM

このアーキテクチャでは、VM が使用されます。 SAP アプリケーション層の場合、デプロイではすべてのインスタンス ロールに VM が使用されます。 これらのロールには、SAP Web Dispatcher と SAP アプリケーション サーバー、セントラル サービス インスタンスの SAP ASCS とエンキュー レプリケーション サーバー (ERS)、アプリケーション サーバーのプライマリ アプリケーション サーバー (PAS) と追加アプリケーション サーバー (AAS) が含まれます。 要件に基づいて VM の数を調整します。 VM で SAP NetWeaver を実行する方法の詳細については、「Plan」を参照し、Azure に SAP デプロイを実装します。

同様に、このアーキテクチャでは、Oracle Database と Oracle オブザーバー VM を含むすべての Oracle コンポーネントに VM が使用されます。 このアーキテクチャのオブザーバー VM は、データベース サーバーよりも小さいです。

  • 制約付き仮想 CPU (vCPU) VM: Oracle ライセンスのコストを節約する可能性がある場合は、 vCPU の制約付き VM を検討してください。

  • SAP の認定 VM ファミリ:AZURE VM の種類とスループット メトリック (SAPS) に対する SAP サポートの詳細については、SAP Note 1928533を参照してください。

  • 近接配置グループ (PPG): ほとんどのゾーン展開では、ゾーン内のレイテンシは SAP アプリケーションにとって十分に低くなっています。 アプリケーション層とデータベース層の間の測定された待機時間がワークロードに影響する場合は、SAP ASCS/SCS およびアプリケーション層 VM に PPG を 使用します。 データベース VM のサイズ変更と SKU の変更の柔軟性を維持するために、データベース VM を PPG から除外します。

  • 第 2 世代 (Gen2) VM:Azureに VM をデプロイする場合は、第 1 世代 (Gen1) または Gen2 のいずれかを選択できます。 Gen2 VM では 、Gen1 で提供されない機能がサポートされます。 Mv2 や Mdsv2 などの一部の VM ファミリは Gen2 VM としてのみ実行されるため、これらの機能は大規模な Oracle データベースにとって重要です。 一部の新しい VM に対する sap on Azure 認定では、Azureがそれらの VM で両方の世代をサポートしている場合でも、完全なサポートのために Gen2 が必要になる場合があります。 詳細については、「SAP Note 1928533 - Supported products and Azure VM types」を参照してください。

    SAP をサポートする他のすべての VM は、Gen2 のみ、または Gen1 と Gen2 の両方をサポートします。 メモリ要件が低い場合でも、すべての SAP VM を Gen2 としてデプロイすることをお勧めします。 一度 Gen2 としてデプロイされた最小の Gen2 VM を、単純な割り当て解除とサイズ変更操作を使用して、使用可能な最大の VM にスケーリングできます。 Gen1 VM は、Gen1 をサポートAzure VM ファミリにのみスケーリングできます。

Storage

このアーキテクチャでは、VM には Azure マネージド ディスク を使用し、sapmnt や SAP transport NFS ボリュームなどのあらゆる NFS 共有ストレージ要件には Azure ファイル共有 または Azure NetApp Files を使用します。 sap on Azure でのストレージのデプロイの詳細については、SAP ワークロード ガイドのAzure Storageの種類を参照してください。

  • SAP の認定ストレージ: SAP 使用状況の認定 VM の種類と同様に、詳細 は SAP ノート 2015553 と SAP ノート 2039619に表示されます。

  • SAP ワークロード用の SAP on Oracle:Azure VM Oracle データベース管理システム (DBMS) デプロイのストレージ設計では、Azureの SAP on Oracle に推奨されるストレージ設計について説明します。 この記事では、ファイル システムのレイアウト、ディスクのサイズ設定に関する推奨事項、およびその他のストレージ オプションに関する具体的なガイダンスを提供します。

  • Oracle データベース ファイルを格納する: Linux では、データベースに ext4 または XFS ファイル システムを使用します。 Windowsで、新しいテクノロジ ファイル システム (NTFS) を使用します。 Oracle 自動ストレージ管理 (ASM) 機能は、Oracle Database 12c リリース 2 以降でもサポートされています。

  • ストレージ ソリューションの利点:Azure Premium SSD v2 は、SAP などのパフォーマンスクリティカルなワークロード向けに設計されています。 このストレージ ソリューションの利点と制限の詳細については、「 Premium SSD v2 のデプロイ」を参照してください。

  • マネージド ディスクの代替手段:または、Oracle データベースにAzure NetApp Filesを使用することもできます。 詳細については、SAP Note 2039619 および SAP ワークロード向け Azure VMs Oracle データベースのデプロイ を参照してください。 Azure NetApp Filesとは異なり、Azure Files NFS は Oracle Database ファイルではサポートされていません。

高可用性

前のアーキテクチャでは、高可用性のデプロイが示され、各アプリケーション レイヤーは 2 つ以上の VM に含まれています。 次のコンポーネントを使用します。

Azureでは、SAP ワークロードのデプロイは、SAP アプリケーションと選択したリージョンの可用性と回復性の要件に応じて、リージョンまたはゾーンのいずれかにできます。 Azureには、柔軟なオーケストレーション (FD= 1) を使用したAzure Virtual Machine Scale Sets、可用性ゾーン、リソースの可用性を向上させる可用性セットなど、さまざまなデプロイ オプションが用意されています。 デプロイ オプションと、異なるAzure リージョン (ゾーン間、単一ゾーン内、ゾーンのないリージョンを含む) での展開オプションとその適用性の詳細については、SAP NetWeaver の HA アーキテクチャとシナリオを参照してください。

  • ロード バランサー:内部Azureロード バランサーは、SAP サブネット内の VM にトラフィックを分散します。 Azure Load Balancerでは、SAP のゾーン デプロイのゾーン冗長分散がサポートされます。

    SAP の可用性ゾーン間で VM をデプロイする場合は 、決定要因 を考慮してください。 可用性ゾーンのデプロイで PPG を 検討し、アプリケーション層の VM にのみ使用します。

    Note

    可用性ゾーンはリージョン内 HA を提供しますが、ゾーン間 DR は地理的に広範囲にわたる災害に対する回復性の要件を満たしていない可能性があります。 ビジネスと規制の距離の要件、サービスの可用性、待機時間、および RPO/RTO ターゲットに基づいて DR リージョンを選択します。

  • Oracle 固有のコンポーネント:ゾーン リージョンでは、障害ドメイン数が 1 (FD=1) に設定された SAP 推奨Virtual Machine Scale Setsデプロイ モデルを使用して、さまざまな可用性ゾーンに Oracle Database VM をデプロイします。 可用性ゾーンのないリージョンでは、 リージョン HA デプロイ オプションを使用します。 各 VM には、データベース ソフトウェアと VM ローカルのデータベース ストレージの独自インストールが含まれています。 データベース間で Oracle Data Guard を使用して同期データベース レプリケーションを設定して、一貫性を確保し、個々の障害が発生した場合の RTO と RPO のサービス時間を短縮します。 データベース VM に加えて、Oracle Data Guard の高速開始フェールオーバーのセットアップには、Oracle Data Guard オブザーバーを備えた追加の VM が必要です。 Oracle オブザーバー VM は、データベースとレプリケーションの状態を監視し、クラスター マネージャーなしで、自動化された方法でデータベースのフェールオーバーを容易にします。 Oracle Data Guard Broker を使用してデータベース レプリケーション管理を実行できます。 詳細については、「Azure 仮想マシン 上の Oracle データベースのアーキテクチャ」を参照してください。

    このアーキテクチャでは、クラスター ソフトウェアやデータベース層のロード バランサーを必要とせずに、ネイティブの Oracle ツールを使用します。 Oracle Data Guard の高速開始フェールオーバーと SAP 構成により、フェールオーバー プロセスが自動化され、フェールオーバーが発生した場合、SAP アプリケーションは新しいプライマリ データベースに再接続されます。

    SIOS Protection Suite や Veritas InfoScale など、さまざまな非Microsoft クラスター ソリューションが代替として存在し、各ベンダーのドキュメントでデプロイの詳細を確認できます。

  • Oracle RAC:Azure VM では、Oracle Real Application Clusters (RAC) はサポートされていません。 Oracle AI Database@Azureは Exadata での RAC デプロイをサポートしていますが、そのサービスはこのアーキテクチャの一部ではありません。 この VM ベースの設計では、Oracle Data Guard は、ラック、データセンター、またはリージョンのサービス中断に対して HA と保護を提供できます。

  • NFS 層: 高可用性 Linux ベースの SAP デプロイでは、SAP トランスポート ディレクトリ用の NFS ボリューム、SAP バイナリ用の sapmnt ボリューム、および (A)SCS インスタンスと ERS インスタンス用の追加ボリュームを提供する回復性のある NFS 層を使用する必要があります。

    NFS 層を提供するオプションは次のとおりです。

  • SAP セントラル サービス クラスター: この参照アーキテクチャは、個別の VM 上でセントラル サービスを実行します。 セントラル サービスは、単一の VM にデプロイすると、単一障害点 (SPoF) になる可能性があります。 高可用性ソリューションを実装するには、(A)SCS インスタンスと ERS インスタンスの各 VM へのフェールオーバーを自動化するクラスター管理ソフトウェアが必要です。 このセットアップは選択した NFS ソリューションによって異なるため、構成はそのソリューションの要件に従います。

    クラスター ソリューションでは、ソフトウェアまたはインフラストラクチャが使用できなくなったときに各サービスにサービスを提供する VM を決定する必要があります。 SAP on Azure には、応答しない VM またはアプリケーションを処理するための Linux ベースの STONITH 実装用の 2 つのオプションが用意されています。

    • STONITH ブロック デバイス (SBD): SBD では、2 つのフォームがサポートされています。 iSCSI 形式では、小さな共有ブロック デバイスの iSCSI ターゲットとして機能する 1 つまたは 3 つの追加 VM をデプロイします。 クラスター メンバー VM (このクラスター プール内の 2 つの (A)SCS/ERS VM) はこのデバイスに定期的にアクセスし、SBD マウントを使用して投票を行い、クラスターの決定のためのクォーラムを達成します。 このアーキテクチャには、追加の SBD VM は含まれません。 Azure共有ディスク形式では、Azure共有ディスクによって iSCSI ターゲット VM が置き換えられるため、追加の VM は必要ありません。 ゾーン展開の場合は、ZRS 共有ディスクを使用して、ゾーン間でディスクの可用性を維持します。

    • Azureフェンス エージェント: このオプションでは、Azure Management API を使用して、障害が発生したノードをAzureコンピューティング API を介して停止して再起動することでフェンスを設定します。 追加の VM は必要ありません。

    構成手順と設計の詳細については、「 NFS 層」セクションでリンクされているガイドを参照してください。 Microsoft Azure認定されていないクラスター マネージャーは、SAP セントラル サービスに HA を提供できます。

  • SAP アプリケーション サーバー プール: 2 つ以上のアプリケーション サーバーをデプロイします。 HA を実現するために、SAP メッセージ サーバーまたは Web ディスパッチャーが要求を負荷分散します。 各アプリケーション サーバーは個別に動作し、この VM のプールではネットワーク負荷分散は必要ありません。

  • SAP Web ディスパッチャー プール: Web Dispatcher コンポーネントは、SAP アプリケーション サーバー間で SAP トラフィックのバランスを取ります。 SAP Web Dispatcher の HA を実現するには、フェールオーバー クラスターまたは並列 Web Dispatcher セットアップを使用し、ディスパッチャー インスタンスをLoad Balancerの背後に配置します。

    (A)SCS の Embedded Web Dispatcher は特別なオプションです。 (A)SCS で余分なワークロードが発生するため、適切なサイズ設定を考慮してください。

    インターネットに接続する通信では、セキュリティ上の問題に対処するために、境界ネットワーク ( DMZ とも呼ばれます) のスタンドアロン ソリューションをお勧めします。

  • Windowsデプロイ: この記事では、主に Linux ベースのデプロイについて説明します。 Windowsにも同じアーキテクチャ原則が適用されます。 Oracle アーキテクチャは、Linux とWindowsで異なるわけではありません。

    SAP アプリケーションの詳細については、AzureのWindowsでの SAP NetWeaver の実行に関するページを参照してください。

Considerations

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「 Well-Architected Framework」を参照してください。

Reliability

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。

障害復旧

次の図は、Azureの Oracle 上の運用 SAP システムのアーキテクチャを示しています。 このアーキテクチャでは DR が提供され、可用性ゾーンが使用されます。

Azureの Oracle 上の運用 SAP システムのアーキテクチャを示す図。

このアーキテクチャと関連するアーキテクチャのVisio ファイルをダウンロードします <>

SAP アプリケーション スタックの各アーキテクチャ レイヤーでは、DR 保護を提供するために別のアプローチを使用します。 DR 戦略と実装の詳細については、 SAP ワークロードの DR の概要とインフラストラクチャのガイドラインと SAPアプリケーションの DR ガイドラインを参照してください。

Backup

Azure での Oracle のバックアップには、いくつかのオプションがあります。

  • Azure Backup:Oracle Database のAzureによって提供および保守され、Oracle のAzure Backupによって提供および保守されるスクリプトは、バックアップ要件に対応します。

  • ストレージ: SAP の BR ツールを使用してスケジュールするバックアップなどのファイルベースのデータベース バックアップを使用し、それらを Azure Blob NFS、Azure Blob、または Azure Files ストレージ サービスにファイルまたはディレクトリとして保存し、バージョン管理します。 Oracle データ バックアップとログ バックアップの両方については、Azure Linux VM 上の Oracle Database のバックアップ戦略に関する記事を参照してください。

  • 外部バックアップ ソリューション:Azureで Oracle をサポートするバックアップ ストレージ プロバイダーのアーキテクチャ ガイダンスを参照してください。

データベース以外の VM の場合は、SAP アプリケーション VM と SAP Web Dispatcher などのサポート インフラストラクチャを保護するために VM にAzure Backupすることをお勧めします。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。

このアーキテクチャの主なコスト 要因は次のとおりです。

  • Oracle と SAP 認定の VM SKU と、アプリケーション層、データベース層、オブザーバー ノード全体の VM の数。

  • OS およびデータベース ソフトウェアの Oracle ライセンス モデルの決定。 vCPU に制約のある VM SKU を使用して、必要に応じてライセンス可能なコアを減らすことを検討してください。

  • Oracle データ、ログ、バックアップ、および共有 NFS ボリューム向けのストレージ パフォーマンス レベルとプロビジョニング済み容量。

  • ネットワークサービスと HA サービス、特に ExpressRoute または VPN ゲートウェイ、ロード バランサー、クロスゾーンまたはリージョン間のレプリケーション トラフィック。

選択したトポロジと SKU のコストを見積もるための中規模の Oracle 高可用性アーキテクチャについては、Azure料金計算ツール の構成済みの見積もりを参照してください。 支出を制御するには:

  • VM のメモリと CPU を、測定された SAPS 値と Oracle スループット要件に合わせて適切なサイズに調整します。

  • 待機時間と 1 秒あたりの入出力操作 (IOPS) 要件で必要な場合にのみ、高コストのストレージ層を使用します。

  • 運用とライセンスの柔軟性を検証した後、安定した状態のコンピューティングの予約または節約計画を評価します。

Contributors

Microsoft では、この記事を保持しています。 この記事を書いたのは、以下の寄稿者です。

主要著者:

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

コミュニティは質問に答え、デプロイを正常に完了できるよう支援します。 次のリソースを考慮してください。