次の方法で共有

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

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

この参照アーキテクチャには、Azure 上の Oracle Database を使用した高可用性 SAP NetWeaver を実行するための一連の実証済みプラクティスが示されています。 アーキテクチャは、原則として OS に依存しません。ただし、特に指定がない限り、Linux に基づいたアーキテクチャが想定されています。

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

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

"このアーキテクチャおよび関連アーキテクチャの Visio ファイルをダウンロードします。"

Note

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

Components

この参照アーキテクチャは、システムの可用性を最大限に引き出すための高可用性のデプロイにおいて Azure の Oracle Database で実行される一般的な SAP 運用システムを示しています。 このアーキテクチャとそのコンポーネントは、ビジネス要件 (目標復旧時間 (RTO)、目標復旧時点 (RPO)、稼働時間の予測、システム ロール) に基づいてカスタマイズでき、VM を 1 つにまで減らせる可能性があります。 このネットワーク レイアウトはこのような SAP 環境のアーキテクチャの原則を示すように簡略化されています。そのため、エンタープライズ ネットワークを完全に示すものではありません。

ネットワーク

Virtual networks. Azure Virtual Network サービスは Azure リソースと相互に接続されており、セキュリティが強化されています。 In this architecture, the virtual network connects to on-premises via a virtual private network (VPN) gateway deployed in the hub of a hub-spoke topology. SAP アプリケーションとデータベースは、独自のスポーク仮想ネットワークに組み込まれています。 この仮想ネットワークは、階層アプリケーション (SAP NetWeaver)、データベース、共有サービス (Azure Bastion など) ごとに個別のサブネットに分割されます。

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

仮想ネットワーク ピアリング。 This architecture uses a hub-and-spoke networking topology with multiple virtual networks that are peered together. このトポロジは、Azure にデプロイされたサービスのためのネットワークのセグメント化と分離を提供します。 ピアリングにより、ピアリングされた仮想ネットワーク間で、Microsoft のバックボーン ネットワークを介した透過的な接続が可能になります。

Zone-redundant gateway. ゲートウェイは個々のネットワークを接続し、オンプレミス ネットワークを Azure 仮想ネットワークに拡張します。 We recommend that you use ExpressRoute to create private connections that don't go over the public internet, but you can also use a site-to-site connection. ゾーン冗長 Azure ExpressRoute または VPN ゲートウェイを使用して、ゾーン障害から保護します。 ゾーン デプロイとゾーン冗長デプロイの違いについては、ゾーン冗長仮想ネットワーク ゲートウェイに関する記事をご覧ください。 ここでは、使用する IP アドレスがゲートウェイのゾーン デプロイの Standard SKU である必要があることに注意してください。

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

アプリケーション セキュリティ グループ。 ワークロードに基づき、アプリケーションを中心にして、NSG 内で詳細なネットワーク セキュリティ ポリシーを定義するには、明示的な IP アドレスではなくアプリケーションのセキュリティ グループを使用します。 これにより、VM を名前でグループ化できるため、ネットワークの信頼できるセグメントからのトラフィックをフィルタリングしてアプリケーションのセキュリティを確保するのに役立ちます。

ネットワーク インターフェイス カード (NIC)。 ネットワーク インターフェイス カードを使用すると、仮想ネットワーク上の仮想マシン間のすべての通信が有効になります。 従来のオンプレミスの SAP デプロイでは、管理トラフィックとビジネス トラフィックを切り離すために、マシンごとに複数の NIC が実装されます。

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

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

Virtual machines

このアーキテクチャでは、仮想マシン (VM) を使用します。 SAP アプリケーション層の場合、VM は、中央サービス SAP (A)SCS と ERS の両方に加え、アプリケーション サーバー (PAS、AAS) も含め、すべてのインスタンス ロール (Web ディスパッチャーとアプリケーション サーバー) にデプロイされます。 仮想マシンの数は要件に基づいて調整します。 Azure Virtual Machines の計画と実装ガイドに関するページには、仮想マシンでの SAP NetWeaver の実行について詳しく説明されています。

Oracle がすべてにおいて目標としているように、Oracle Database と Oracle オブザーバー VM の両方に仮想マシンを使用します。 このアーキテクチャのオブザーバー VM は、実際のデータベース サーバーと比較すると、小さくなります。

  • 制約付き vCPU VM。 Oracle ライセンスのコストを節約するには、vCPU 制約付き VM の利用を検討してください。
  • SAP 用認定 VM ファミリ。 Azure 仮想マシンの種類とスループットのメトリック (SAPS) に対する SAP サポートの詳細については、SAP ノート 1928533 をご覧ください。 (SAP Notes にアクセスするには、SAP Service Marketplace アカウントが必要です)。

近接配置グループ (PPG)。 仮想マシンが可用性ゾーンにデプロイされている場合、通常、ゾーン内の待機時間は SAP アプリケーションに最適です。 まれに、データベースとアプリケーションの仮想マシン間の待機時間を短縮する必要がある場合は、 proximity 配置グループを使用できます。 このような状況では、PPG はコロケーションを確保します。つまり、アプリケーションの待機時間を最小限に抑えるために、仮想マシンが同じデータセンターに存在します。 PPG による制限の可能性があるため、SAP システムの PPG へのデータベース AvSet の追加は、必要な場合にのみ、疎に行う必要があります。 PPG の詳しい使用シナリオについては、リンク先のドキュメントを参照してください。

第 2 世代 (Gen2) 仮想マシン。 Azure では、VM をデプロイする際に、第 1 または第 2 世代である必要がある場合は、選択できます。 第 2 世代 VM では、第 1 世代 VM では使用できない主要な機能がサポートされています。 Particularly for very large Oracle databases this is of importance since some VM families such as Mv2 or Mdsv2 are only supported as Gen2 VMs. 同様に、一部の新しい 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 ファミリにのみサイズ変更できます。

Storage

このアーキテクチャは、仮想マシンには、Azure Managed Disks を、sapmnt および SAP トランスポート NFS ボリュームなどの共有ストレージなどの Network File System (NFS) には、Azure ファイル共有 または Azure NetApp ファイル を使用します。 SAP on Azure を使用したストレージ デプロイのガイドラインについては、『Azure Storage types for SAP workload』ガイドをご覧ください。

  • SAP 用認定ストレージ。 SAP の使用に認定された VM の種類と同様に、SAP Note 2015553 と SAP Note 2039619 で詳細を確認してください。
  • SAP on Oracle のストレージ設計。 Azure の SAP on Oracle のストレージ設計の推奨事項に関しては、「SAP ワークロード用 Azure Virtual Machines Oracle database management system (DBMS) デプロイ」を参照してください。 この記事では、ファイル システムのレイアウト、ディスクのサイズ設定に関する推奨事項、およびその他のストレージ オプションに関する具体的なガイダンスを提供します。
  • Oracle Database ファイルの保存。 Linux では、データベースに ext4 または xfs ファイル システムを、Windows デプロイの場合は NTFS を使用する必要があります。 Oracle Automatic Storage Management (ASM) は、Oracle Database 12c Release 2 以降の Oracle デプロイでもサポートされています。
  • Azure Premium SSD v2 は、SAP などのパフォーマンスが重要なワークロード向けに設計されています。 このストレージ ソリューションの利点と現在の制限事項については、「Premium SSD v2 をデプロイする」を参照してください。
  • マネージド ディスクの代替手段。 代わりに、Oracle のデータベースに Azure NetApp Files を使用することもできます。 詳細については、SAP Note 2039619 および Oracle on Azure に関するドキュメントを参照してください。 Azure Files NFS ボリュームは Azure NetApp Files とは異なり、Oracle Database ファイルを格納できません。

High availability

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

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

Load balancers.Azure Load Balancer is used to distribute traffic to virtual machines in the SAP subnets. SAP のゾーン デプロイに Azure Load Balancer を組み込む場合は、必ず Standard SKU ロード バランサーを選択してください。 Basic SKU バランサーでは、ゾーン冗長はサポートされていません。

Consider the decision factors when deploying VMs between availability zones for SAP. 可用性ゾーンのデプロイで近接配置グループを使用するには、アプリケーション層の VM に対してのみ評価して使用する必要があります。

Note

Availability Zones は、リージョン内の高可用性 (HA) をサポートしていますが、障害復旧 (DR) には影響しません。 ゾーン間の距離が短すぎます。 一般的な DR リージョンは、プライマリ リージョンから少なくとも 100 マイル離れている必要があります。

Oracle-specific components. 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 のデプロイの詳細については、Azure での 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 tier. すべての高可用性 SAP のデプロイでは、回復性がある NFS 層を使用する必要があるため、SAP トランスポート ディレクトリ用の NFS ボリューム、SAP バイナリ用の sapmnt ボリューム、および (A)SCS インスタンスと ERS インスタンス用の追加ボリュームが提供されます。 NFS 層を提供するオプションは次のとおりです。

  • ゾーン冗長ストレージ (ZRS) を備えた Azure Files NFS- SLES ガイドと RHEL ガイド
  • Azure NetApp Files NFS ボリュームのデプロイ - SLES ガイドと RHEL ガイド
  • VM based NFS cluster - two additional VMs with local storage, replicated between VMs with DRBD (Distributed Replicated Block Device) - SLES and RHEL guides

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

選択したクラスター ソリューションには、ソフトウェアまたはインフラストラクチャが利用できない場合に、それぞれのサービスを提供する VM を決定するメカニズムが必要です。 この SAP on Azure では、STONITH の Linux ベースの実装に対して、応答しない VM またはアプリケーションを処理する方法の 2 つのオプションを使用できます。

  • SUSE-Linux-onlySBD (STONITH Block Device) - using one or three additional VMs which serve as iSCSI exports of a small block device, which is accessed regularly by the actual cluster member VMs, two (A)SCS/ERS VMs in this cluster pool. VM は、これらの SBD マウントを使用して投票し、クラスターの決定に対してクォーラムを実現します。 このページに示されているアーキテクチャには、追加の 1 つまたは 3 つの SBD VM は含まれていません。
  • 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 にワークロードが追加されるため、適切なサイズ設定を考慮する必要があります。

For internet-facing communications, we recommend a stand-alone solution in the perimeter network (also known as DMZ) to satisfy security concerns.

Windows deployments. 最初に説明したとおり、このドキュメントは主に Linux ベースのデプロイに重点を置いています。 Windows で使用する場合、同じアーキテクチャの原則が適用されるため、Linux と Windows 間で Oracle でのアーキテクチャの違いはありません。

SAP アプリケーションのパートについては、アーキテクチャ ガイド『Run SAP NetWeaver in Windows on Azure』をご覧ください。

Considerations

Disaster recovery

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

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

"このアーキテクチャおよび関連アーキテクチャの Visio ファイルをダウンロードします。"

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

Backup

Azure での Oracle のバックアップは、いくつかの方法で実現できます。

  • Azure Backup.Scripts provided and maintained by Azure for Oracle Database and Azure Backup for Oracle address backup requirements.
  • Azure Storage. SAP の BR ツールでスケジュールするなど、ファイル ベースのデータベース バックアップを使用しして、Azure BLOB NFS、Azure BLOB、または Azure Files のストレージ サービスにファイル/ディレクトリとして保存およびバージョン管理します。 See Documented details how to achieve both Oracle data and log backups.
  • サードパーティ製のバックアップ ソリューション。 Azure での Oracle をサポートしているバックアップ ストレージ プロバイダーのアーキテクチャを参照してください。

データベース以外の VM の場合は、 Azure Backup for VM を使用して SAP アプリケーション VM や SAP Web Dispatcher のような周辺のインフラストラクチャを保護することをお勧めします。

Contributors

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

Principal author:

Next steps

Communities

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

同じテクノロジの一部を使用する SAP ワークロードの詳細と例については、次の記事を参照してください。