この参照アーキテクチャには、Azure 上の Oracle Database を使用した高可用性 SAP NetWeaver を実行するための一連の実証済みプラクティスが示されています。 アーキテクチャは、原則として OS に依存しません。ただし、特に指定がない限り、Linux に基づいたアーキテクチャが想定されています。
最初の図は、Azure での SAP on Oracle の参照アーキテクチャを示しています。 このアーキテクチャでは、可用性セットが使用されています。
"このアーキテクチャおよび関連アーキテクチャの Visio ファイルをダウンロードします。"
注意
この参照アーキテクチャをデプロイするには、SAP 製品と Microsoft 以外の他のテクノロジに適したライセンスが必要です。
コンポーネント
この参照アーキテクチャは、システムの可用性を最大限に引き出すための高可用性のデプロイにおいて Azure の Oracle Database で実行される一般的な SAP 運用システムを示しています。 このアーキテクチャとそのコンポーネントは、ビジネス要件 (RTO、RPO、稼働時間の予測、システム ロール) に基づいてカスタマイズでき、VM を 1 つにまで減らせる可能性があります。 このネットワーク レイアウトはこのような SAP 環境のアーキテクチャの原則を示すように簡略化されています。そのため、エンタープライズ ネットワークを完全に示すものではありません。
ネットワーク
仮想ネットワーク。 Azure Virtual Network サービスは Azure リソースと相互に接続されており、セキュリティが強化されています。 このアーキテクチャでは、仮想ネットワークは、ハブスポーク トポロジのハブにデプロイされた仮想プライベート ネットワーク (VPN) ゲートウェイ経由でオンプレミス環境に接続されます。 SAP アプリケーションとデータベースは、独自のスポーク仮想ネットワークに組み込まれています。 この仮想ネットワークは、階層アプリケーション (SAP NetWeaver)、データベース、共有サービス (Azure Bastion など) ごとに個別のサブネットに分割されます。
このアーキテクチャでは、仮想ネットワーク アドレス空間がサブネットに分割されます。 アプリケーション サーバーとデータベース サーバーはそれぞれ別のサブネットに配置しています。 これにより、個々のサーバーではなくサブネットのセキュリティ ポリシーを管理しすることでそれらの保護が容易になり、データベースに適用されるセキュリティ規則をアプリケーション サーバーから明確に切り離すことができます。
仮想ネットワーク ピアリング。 このアーキテクチャでは、ピアリングされている複数の仮想ネットワークを含むハブ アンド スポーク ネットワーク トポロジが使用されます。 このトポロジは、Azure にデプロイされたサービスのためのネットワークのセグメント化と分離を提供します。 ピアリングにより、ピアリングされた仮想ネットワーク間で、Microsoft のバックボーン ネットワークを介した透過的な接続が可能になります。 単一のリージョン内にデプロイされている場合、パフォーマンスが低下することはありません。
ゾーン冗長ゲートウェイ。 ゲートウェイは個々のネットワークを接続し、オンプレミス ネットワークを Azure 仮想ネットワークに拡張します。 ExpressRoute を使用してパブリック インターネットを経由しないプライベート接続を作成することをお勧めしますが、サイト間接続を使用することもできます。 Azure ExpressRoute または VPN ゲートウェイをゾーン全体に展開して、ゾーンの障害から保護することができます。 ゾーン デプロイとゾーン冗長デプロイの違いについては、ゾーン冗長仮想ネットワーク ゲートウェイに関する記事をご覧ください。 ここでは、使用する IP アドレスがゲートウェイのゾーン デプロイの Standard SKU である必要があることに注意してください。
ネットワーク セキュリティ グループ。 仮想ネットワーク内の受信、送信、サブネット内トラフィックを制限するには、ネットワーク セキュリティ グループを作成して特定のサブネットに割り当てます。 DB サブネットとアプリケーション サブネットは、ワークロード固有の NSG を使用して保護されます。
アプリケーション セキュリティ グループ。 ワークロードに基づき、アプリケーションを中心にして、NSG 内で詳細なネットワーク セキュリティ ポリシーを定義するには、明示的な IP アドレスではなくアプリケーションのセキュリティ グループを使用します。 これにより、VM を名前でグループ化できるため、ネットワークの信頼できるセグメントからのトラフィックをフィルタリングしてアプリケーションのセキュリティを確保するのに役立ちます。
ネットワーク インターフェイス カード (NIC)。 ネットワーク インターフェイス カードを使用すると、仮想ネットワーク上の仮想マシン間のすべての通信が有効になります。 従来のオンプレミスの SAP デプロイでは、管理トラフィックとビジネス トラフィックを切り離すために、マシンごとに複数の NIC が実装されます。
Azure では、仮想ネットワークは、すべてのトラフィックを同じネットワーク ファブリック経由で送信するソフトウェア定義ネットワークです。 そのため、パフォーマンス上の理由から複数の NIC を使用する必要はありません。 ただし、お客様の組織でトラフィックを分離することが必要な場合は、VM ごとに複数の NIC をデプロイして、各 NIC をそれぞれ異なるサブネットに接続することができます。 このようにすると、ネットワーク セキュリティ グループを使用して、さまざまなアクセス制御ポリシーを各サブネットに適用できます。
Azure NIC は、複数の IP をサポートしています。 このサポートは、インストールに仮想ホスト名を使用する SAP 推奨プラクティスに準拠しています。 全体的な概要については、SAP Note 962955 を参照してください。 (SAP Note にアクセスするには、SAP Service Marketplace アカウントが必要です。)
仮想マシン
このアーキテクチャでは、仮想マシン (VM) を使用します。 SAP アプリケーション層の場合、VM はすべてのインスタンス ロール (Web ディスパッチャーとアプリケーション サーバー) に対して、つまり、SAP (A)SCS と ERS の両方のセントラル サービスとともに、アプリケーション サーバー （PAS、AAS） にデプロイされます。 仮想マシンの数は要件に基づいて調整します。 Azure Virtual Machines の計画と実装ガイドに関するページには、仮想マシンでの SAP NetWeaver の実行について詳しく説明されています。
Oracle がすべてにおいて目標としているように、Oracle Database と Oracle オブザーバー VM の両方に仮想マシンを使用します。 このアーキテクチャのオブザーバー VM は、実際のデータベース サーバーと比較すると、小さくなります。
- 制約付き vCPU VM。 Oracle ライセンスのコストを節約するには、vCPU 制約付き VM の利用を検討してください。
- SAP 用認定 VM ファミリ。 Azure 仮想マシンの種類とスループットのメトリック (SAPS) に対する SAP サポートの詳細については、SAP ノート 1928533 をご覧ください。 (SAP Note にアクセスするには、SAP Service Marketplace アカウントが必要です。)
近接配置グループ (PPG)。 ネットワーク待機時間を最適化するには、近接配置グループを使用します。これは、併置を優先します。つまり、仮想マシンが同じデータセンター内にあるため、アプリケーション待機時間を最低限に抑えることができます。 それらを使用すると、大半の SAP アプリケーションでユーザー エクスペリエンスを大幅に向上できます。 PPG では潜在的な制限があるため、SAP システムの PPG にデータベース AvSet を追加する必要があるのは、SAP アプリケーションとデータ トラフィック間に待機時間が必要な場合だけです。 PPG の詳しい使用シナリオについては、リンク先のドキュメントを参照してください。
第 2 世代 (Gen2) 仮想マシン。 Azure では、VM をデプロイする際に、第 1 または第 2 世代である必要がある場合は、選択できます。 第 2 世代 VM では、第 1 世代 VM では使用できない主要な機能がサポートされています。 特に非常に大規模な Oracle データベースの場合、Mv2 や Mdsv2 などの一部の VM ファミリは Gen2 VM としてのみサポートされるため、これは重要です。 同様に、一部の新しい VM に対する SAP on Azure 認定では、Azure で両方が許可されている場合でも、完全なサポートのために Gen2 のみが必要になる場合があります。 詳細については、「SAP ノート 1928533 - Microsoft Azure 上の SAP アプリケーション: サポート対象の製品と Azure VM の種類」を参照してください。
SAP をサポートする他のすべての VM では、Gen2 のみ、または Gen1 と 2 の併用を選択できるため、メモリ要件が非常に低い場合でも、すべての SAP VM を Gen2 としてデプロイすることをお勧めします。 Gen2 としてデプロイされた最小の VM でも、簡単な割り当て解除とサイズ変更により、最大の VM にスケールアップできます。 Gen1 VM は、Gen1 VM の実行が許可されている VM ファミリにのみサイズ変更できます。
ストレージ
このアーキテクチャでは、仮想マシンには Azure マネージド ディスク、sapmnt や SAP トランスポート NFS ボリュームなどの NFS 共有ストレージには Azure Files NFS または Azure NetApp Files を使用します。 SAP on Azure を使用したストレージ デプロイのガイドラインについては、『Azure Storage types for SAP workload』ガイドをご覧ください。
- SAP 用認定ストレージ。 SAP の使用に認定された VM の種類と同様に、SAP Note 2015553 と SAP Note 2039619 で詳細を確認してください。
- SAP on Oracle のストレージ設計。 「SAP ワークロードのための Azure Virtual Machines Oracle DBMS のデプロイ」で、Azure での SAP on Oracle に推奨されるストレージ設計を参照できます。 この記事では、ファイル システムのレイアウト、ディスクのサイズ設定に関する推奨事項、その他のストレージ オプションに関する具体的なガイダンスが提供されています。
- Oracle Database ファイルの保存。 Linux では、データベースに ext4 または xfs ファイル システムを、Windows デプロイの場合は NTFS を使用する必要があります。 ORACLE ASM は Oracle Database 12C Release 2 以降の Oracle デプロイでもサポートされています。
- マネージド ディスクの代替手段。 代わりに、Oracle のデータベースに Azure NetApp Files を使用することもできます。 詳細については、SAP Note 2039619 および Oracle on Azure に関するドキュメントを参照してください。 Azure Files NFS ボリュームは Azure NetApp Files とは異なり、Oracle Database ファイルを格納できません。
- Azure Premium SSD v2 は、SAP などのパフォーマンスが重要なワークロード向けに設計されています。 このストレージ ソリューションの利点と現在の制限事項については、「Premium SSD v2 をデプロイする」を参照してください。
高可用性
前述のアーキテクチャは、各アプリケーション レイヤーが 2 つ以上の仮想マシンに含まれる、高可用性デプロイを示しています。 次のコンポーネントが使用されます。
Azure では、SAP ワークロードのデプロイは、SAP アプリケーションの可用性と回復性の要件に応じて、リージョンまたはゾーンのいずれかにできます。 Azure には、リソースの可用性を高めるために、柔軟なオーケストレーション (FD=1) を備えた Virtual Machine Scale Sets、可用性ゾーン、可用性セットなど、さまざまなデプロイ オプションが用意されています。 さまざまな Azure リージョン (ゾーン間、単一ゾーン内、またはゾーンのないリージョンを含む) でのデプロイ オプションとその適用性を包括的に理解するには、「SAP NetWeaver のための高可用性のアーキテクチャとシナリオ」を参照してください。
ロード バランサー。Azure Load Balancer は、SAP サブネット内の仮想マシンにトラフィックを分配するために使用されます。 SAP のゾーン デプロイに Azure Load Balancer を組み込む場合は、必ず Standard SKU ロード バランサーを選択してください。 Basic SKU バランサーでは、ゾーン冗長はサポートされていません。
SAP の可用性ゾーン間に VM をデプロイする場合は、決定要因を検討してください。 可用性ゾーンのデプロイで近接配置グループを使用するには、アプリケーション層の VM に対してのみ評価して使用する必要があります。
Note
Azure Availability Zones はリージョン内の高可用性をサポートしていますが、DR には影響しません。 ゾーン間の距離が短すぎます。 一般的な DR リージョンは、プライマリ リージョンから少なくとも 100 マイル離れている必要があります。
Oracle 固有のコンポーネント。 Oracle Database の VM は、可用性セットまたは異なる可用性ゾーンにデプロイされます。 各 VM には、データベース ソフトウェアと VM ローカルのデータベース ストレージの独自インストールが含まれています。 整合性を確保し、個別の障害が発生した場合に備えて RTO と RPO のサービス時間を短縮できるように、Oracle Data Guard を介してデータベース間に同期データベース レプリケーションを設定します。 Oracle Data Guard Fast-Start フェールオーバーには、データベース VM の他に Oracle Data Guard オブザーバーを備えた追加の VM が必要です。 Oracle オブザーバー VM は、データベースとレプリケーションの状態を監視し、クラスター マネージャーを必要とせずに、自動化された方法でデータベースのフェールオーバーを促進します。 これにより、データベース レプリケーションの管理は、Oracle Data Guard Broker を使用すると簡単に実行できます。
Oracle Data Guard のデプロイの詳細については、以下をご覧ください。
このアーキテクチャでは、実際にクラスターを設定したり、データベース層でロード バランサーを必要としたりすることなく、ネイティブ Oracle ツールを利用します。 Oracle Data Guard Fast-Start フェールオーバーと SAP 構成を使用するとフェールオーバー プロセスが自動化され、フェールオーバーが発生した場合に SAP アプリケーションが新しいプライマリ データベースに再接続されます。 SIOS Protection Suite や Veritas InfoScale などの代替手段として、さまざまなサードパーティ クラスター ソリューションが存在します。各サードパーティ ベンダーのドキュメントで、それぞれのデプロイの詳細を確認できます。
Oracle RAC。 Oracle Real Application Cluster (RAC) は現在、Azure の Oracle では認定またはサポートされていません。 ただし、高可用性のための Oracle Data Guard のテクノロジとアーキテクチャでは、ラック、データセンター、またはリージョンでのサービスの中断に対する保護を備え、回復性の高い SAP 環境を提供できます。
NFS 層。 すべての高可用性 SAP のデプロイでは、回復性がある NFS 層を使用する必要があるため、SAP トランスポート ディレクトリ用の NFS ボリューム、SAP バイナリ用の sapmnt ボリューム、および (A)SCS インスタンスと ERS インスタンス用の追加ボリュームが提供されます。 NFS 層を提供するオプションは次のとおりです。
- ゾーン冗長ストレージ (ZRS) を備えた Azure Files NFS- SLES ガイドと RHEL ガイド
- Azure NetApp Files NFS ボリュームのデプロイ - SLES ガイドと RHEL ガイド
- VM ベースの NFS クラスター - DRBD (分散レプリケート ブロック デバイス) を使用して VM 間でレプリケートされるローカル ストレージを持つ 2 つの追加の VM - SLES ガイドと RHEL ガイド
SAP セントラル サービス クラスター。 この参照アーキテクチャでは、個別の VM 上でセントラル サービスが実行されます。 セントラル サービスは、1 つの VM にデプロイすると単一障害点 (SPOF) になる可能性があります。 高可用性ソリューションを実装するには、(A)SCS インスタンスと ERS インスタンスの各 VM へのフェールオーバーを自動化するクラスター管理ソフトウェアが必要です。 これは、選択した NFS ソリューションと強く結び付いているためです。
選択したクラスター ソリューションには、ソフトウェアまたはインフラストラクチャが利用できない場合に、それぞれのサービスを提供する VM を決定するメカニズムが必要です。 この SAP on Azure では、STONITH の Linux ベースの実装に対して、応答しない VM またはアプリケーションを処理する方法の 2 つのオプションを使用できます。
- SUSE-Linux のみSBD (STONITH ブロック デバイス) - 小さなブロック デバイスの iSCSI エクスポートとして機能する 1 つ、または 3 つの追加の VM を使用します。これには、実際のクラスター メンバー VM (このクラスタープールでは 2 つの (A)SCS/ERS VM) が定期的にアクセスします。 VM は、これらの SBD マウントを使用して投票し、クラスターの決定に対してクォーラムを実現します。 このページに示されているアーキテクチャには、追加の 1 つまたは 3 つの SBD VM は含まれていません。 RedHat は Azure での SBD 実装をサポートしていないため、このオプションは SUSE SLES オペレーティング システムでのみ使用できます。
- Azure Fence Agent。 Azure Management API を使用し、追加の VM を利用せずに VM の可用性を定期的にチェックします。
NFS 層のセクション内にリンクされているガイドには、それぞれのクラスターの選択に必要な手順と設計が含まれています。 サード パーティ製の Azure 認定クラスター マネージャーを利用して、SAP セントラル サービスの高可用性を実現することもできます。
SAP アプリケーション サーバー プール。 SAP メッセージ サーバーまたは Web ディスパッチャーを介した要求の負荷分散によって高可用性が実現される 2 つ以上のアプリケーション サーバー。 各アプリケーション サーバーは独立しているため、この VM のプールにはネットワーク負荷分散は必要ありません。
SAP Web Dispatcher プール Web Dispatcher コンポーネントは、SAP アプリケーション サーバー間の SAP トラフィックのロード バランサーとして使用されます。 SAP Web Dispatcher の高可用性を実現するには、Azure Load Balancer でフェールオーバー クラスターまたは並列 Web Dispatcher セットアップを実装します。
(A)SCS の Embedded Web Dispatcher は特別なオプションです。 (A)SCS にワークロードが追加されるため、適切なサイズ設定を考慮する必要があります。
インターネットに接続する通信の場合は、セキュリティ上の懸念事項に対応するために、境界ネットワーク (DMZ とも呼ばれます) のスタンドアロン ソリューションをお勧めします。
Windows デプロイ。 最初に説明したとおり、このドキュメントは主に Linux ベースのデプロイに重点を置いています。 Windows で使用する場合、同じアーキテクチャの原則が適用されるため、Linux と Windows 間で Oracle でのアーキテクチャの違いはありません。
SAP アプリケーションのパートについては、アーキテクチャ ガイド『Run SAP NetWeaver in Windows on Azure』をご覧ください。
考慮事項
障害復旧
次の図は、Azure での SAP on Oracle 運用システムのアーキテクチャを示しています。 このアーキテクチャでは DR が提供され、可用性ゾーンが使用されます。
"このアーキテクチャおよび関連アーキテクチャの Visio ファイルをダウンロードします。"
SAP アプリケーション スタックの各アーキテクチャ レイヤーでは、DR 保護を提供するために別のアプローチを使用します。 DR 戦略と実装の詳細については、「SAP ワークロードのディザスター リカバリーの概要とインフラストラクチャのガイドライン」および「SAP アプリケーションに関するディザスター リカバリーのガイドライン」を参照してください。
Backup
Azure での Oracle のバックアップは、いくつかの方法で実現できます。
- Azure Backup。Azure では、Oracle Database 用のスクリプトが提供され、保守されています。そのため、バックアップの実行前と後の Oracle アクションを容易に行うことができます。
- Azure Storage です。 SAP の BR ツールでスケジュールするなど、ファイル ベースのデータベース バックアップを使用しして、Azure BLOB NFS、Azure BLOB、または Azure Files のストレージ サービスにファイル/ディレクトリとして保存およびバージョン管理します。 Oracle データとログ バックアップの 両方を実現する方法については、ドキュメントに記載されている詳細を参照してください。
- サードパーティ製のバックアップ ソリューション。 Azure での Oracle をサポートしているバックアップ ストレージ プロバイダーのアーキテクチャを参照してください。
データベース以外の VM の場合は、 Azure Backup for VM を使用して SAP アプリケーション VM や SAP Web Dispatcher のような周辺のインフラストラクチャを保護することをお勧めします。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Robert Biro |シニア アーキテクト
次のステップ
- Azure VM での SAP NetWeaver の高可用性
- SAP NetWeaver のための Azure Virtual Machines の計画と実装
- Azure を使用して SAP ワークロード シナリオをホストして実行する
コミュニティ
コミュニティは質問に答え、デプロイを正常に完了できるよう支援します。 次のリソースを考慮してください。
関連リソース
同じテクノロジの一部を使用する SAP ワークロードの詳細と例については、次の記事を参照してください。