このガイドでは、高可用性を備えた Azure の Windows 環境で SAP NetWeaver を実行するための実証済みプラクティスについて説明します。 データベースは AnyDB (SAP HANA を除く、サポートされている任意のデータベース管理システム (DBMS) を表す SAP 用語) です。
アーキテクチャ
次の図は、Windows 環境の SAP NetWeaver を示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
注意
このアーキテクチャをデプロイするには、SAP 製品と Microsoft 以外の他のテクノロジに適したライセンスが必要です。
このガイドでは、運用システムについて説明します。 このシステムは特定の仮想マシン (VM) サイズでデプロイされ、お客様の組織のニーズに合わせて変更できます。 このシステムは、単一の VM にまで減らすことができます。 ネットワーク レイアウトは、アーキテクチャの原則を示すために大幅に簡素化されています。 これは、完全なエンタープライズ ネットワークを示すものではありません。
ワークフロー
仮想ネットワーク。 Azure Virtual Network サービスは Azure リソースと相互に接続されており、セキュリティが強化されています。 このアーキテクチャの仮想ネットワークは、ハブスポーク トポロジのハブにデプロイされた Azure ExpressRoute ゲートウェイ経由でオンプレミス ネットワークに接続します。 このスポークは、SAP アプリケーションおよびデータベース層に使用される仮想ネットワークです。 ハブ仮想ネットワークは、Azure Bastion やバックアップなどの共有サービスに使用されます。
仮想ネットワーク ピアリング。 このアーキテクチャでは、ピアリングされている複数の仮想ネットワークを含むハブ アンド スポーク ネットワーク トポロジが使用されます。 このトポロジでは、Azure にデプロイされたサービスのためのネットワークのセグメント化と分離が提供されます。 ピアリングにより、ピアリングされた仮想ネットワーク間で、Microsoft のバックボーン ネットワークを介した透過的な接続が可能になります。 単一のリージョン内にデプロイされている場合、パフォーマンスが低下することはありません。 この仮想ネットワークは、アプリケーション (SAP NetWeaver)、データベース、および共有サービス (Bastion や サードパーティ製バックアップ ソリューションなど) といった階層ごとに個別のサブネットに分割されます。
VM。 このアーキテクチャでは、アプリケーション層とデータベース層に VM が使用され、次の方法でグループ化されます。
SAP NetWeaver。 アプリケーション層では Windows VM を使用して、SAP セントラル サービスと SAP アプリケーション サーバーが実行されます。 高可用性を実現するために、セントラル サービスを実行する VM は、Windows Server フェールオーバー クラスター内に構成されています。 これらは Azure ファイル共有または Azure 共有ディスクのいずれかでサポートされています。
AnyDB。 このデータベース層では、AnyDB (Microsoft SQL Server、Oracle、IBM Db2 のいずれか) がデータベースとして実行されます。
Bastion サービス。 管理者は、bastion ホストと呼ばれるセキュリティが強化された VM を使用して、他の VM に接続します。 これは通常、バックアップ サービスなどの共有サービスの一部です。 サーバーの管理に使用されるサービスが Secure Shell プロトコル (SSH) とリモート デスクトップ プロトコル (RDP) だけの場合は、Azure Bastion ホストが適切なソリューションです。 SQL Server Management Studio や SAP Frontend などの他の管理ツールを使用する場合は、自己デプロイ済みの従来のジャンプ ボックスが使用されます。
プライベート DNS サービス。Azure プライベート DNS は、仮想ネットワークのための、信頼性が高く安全な DNS サービスとなります。 カスタムの DNS ソリューションを構成しなくても、Azure プライベート DNS によって、仮想ネットワークにおけるドメイン名の管理と解決が行われます。
ロード バランサー。 高可用性のために SAP アプリケーション層サブネット内の VM にトラフィックを分散するには、Azure Standard ロード バランサーの使用をお勧めします。 Standard ロード バランサーでは、既定で一定レベルのセキュリティが提供されることに注意してください。 Standard ロード バランサーの背後にある VM には、送信インターネット接続はありません。 VM で送信インターネットを有効にするには、Standard ロード バランサーの構成を更新する必要があります。 SAP Web ベースのアプリケーションの高可用性を実現するには、組み込みの SAP Web Dispatcher または他の購入可能なロード バランサーを使用します。 次の基準に基づいて選択します。
- トラフィックの種類 (HTTP や SAP GUI など)。
- 必要なネットワーク サービス (Secure Sockets Layer (SSL) ターミネーションなど)。
インターネットに接続する受信/送信の設計例については、SAP on Azure の受信および送信インターネット接続を参照してください。
Standard Load Balancer では、複数のフロントエンド仮想 IP がサポートされています。 このサポートは、次のコンポーネントを含むクラスターの実装に最適です。
- Advanced Business Application Programming (ABAP) SAP Central Service (ASCS)
- エンキュー レプリケーション サーバー (ERS)
Standard SKU では、マルチシステム識別子 (マルチ SID) SAP クラスターもサポートされています。 つまり、Windows 上の複数の SAP システムでは、共通の高可用性インフラストラクチャを共有してコストを削減できます。 コスト削減を評価し、1 つのクラスターにシステムを配置しすぎないようにします。 Azure でサポートされている SID は、クラスターごとに 5 つ以下です。
アプリケーション ゲートウェイ。 Azure Application Gateway は、Web アプリケーションへのトラフィック管理に使用できる Web トラフィック ロード バランサーです。 従来のロード バランサーは、トランスポート層 (OSI レイヤー 4 - TCP と UDP) で動作します。 トラフィックは送信元 IP アドレスとポートに基づいて送信先 IP アドレスとポートにルーティングされます。 Application Gateway によるルーティングの決定は、URI パス、ホスト ヘッダーのような HTTP 要求の追加属性に基づいて行うことができます。 この種類のルーティングは、アプリケーション レイヤー (OSI レイヤー 7) の負荷分散と呼ばれます。
ネットワーク セキュリティ グループ。 仮想ネットワーク内の受信、送信、およびサブネット間のトラフィックを制限するには、ネットワーク セキュリティ グループを作成します。
アプリケーション セキュリティ グループ。 アプリケーションを中心にして、ワークロードに基づいた詳細なネットワーク セキュリティ ポリシーを定義するには、明示的な IP アドレスではなくアプリケーションのセキュリティ グループを使用します。 アプリケーション セキュリティ グループにより、VM を名前でグループ化できるため、ネットワークの信頼できるセグメントからのトラフィックをフィルタリングしてアプリケーションのセキュリティを確保するのに役立ちます。
ゲートウェイ。 ゲートウェイは個々のネットワークを接続し、オンプレミス ネットワークを Azure 仮想ネットワークに拡張します。 ExpressRoute を使用してパブリック インターネットを経由しないプライベート接続を作成することをお勧めしますが、サイト間接続を使用することもできます。 待機時間を短縮したり、スループットを向上させたりするには、この記事で後述しているように、ExpressRoute Global Reach および ExpressRoute FastPath を検討してください。
Azure Storage です。 Storage では、VM のデータの永続化が仮想ハード ディスクの形式で提供されます。 Azure マネージド ディスクをお勧めします。
推奨事項
このアーキテクチャでは、小規模な運用レベルのデプロイについて説明します。 デプロイはビジネス要件によって異なるため、これらの推奨事項を開始点として検討してください。
VM
アプリケーション サーバーのプールおよびクラスターで、それぞれの要件に基づいて VM の数を調整します。 VM での SAP NetWeaver の実行の詳細については、「SAP NetWeaver のための Azure Virtual Machines の計画と実装」を参照してください。
Azure VM の種類とスループットのメトリック (SAPS) に対する SAP サポートの詳細については、SAP ノート 1928533 をご覧ください。 SAP ノートにアクセスするには、SAP Service Marketplace アカウントが必要です。
SAP Web Dispatcher
Web Dispatcher コンポーネントは、SAP アプリケーション サーバー間の SAP トラフィックの負荷分散に使用されます。 Web Dispatcher コンポーネントの高可用性を実現するには、Load Balancer を使用して Web Dispatcher インスタンス のフェールオーバー クラスターまたは並列 Web Dispatcher セットアップを実装します。 ソリューションの詳細については、SAP Web Dispatcher の高可用性に関するページをご覧ください。
アプリケーション サーバー プール
通常、SAP SMLG トランザクションは、ABAP アプリケーション サーバーのログオン グループの管理や、ログオン ユーザーの負荷分散に使用されます。 その他のトランザクション (バッチ サーバー グループの SM61、リモート関数呼び出し (RFC) グループの RZ12 など) でも、ログオン ユーザーの負荷分散が行われます。 これらのトランザクションでは、SAP セントラル サービスのメッセージ サーバー内の負荷分散機能を使って、SAP GUI および RFC トラフィック用の SAP アプリケーション サーバー プール間で受信セッションまたはワークロードを分散させます。
SAP セントラル サービス クラスター
このアーキテクチャでは、アプリケーション層の VM でセントラル サービスが実行されます。 セントラル サービスは、1 つの VM にデプロイすると単一障害点 (SPOF) になる可能性があります。 高可用性ソリューションを実装するには、ファイル共有クラスターまたは共有ディスク クラスターのいずれかを使用します。
高可用性ファイル共有には複数のオプションがあります。 Azure Files共有は、フル マネージドのクラウドネイティブ サーバー メッセージ ブロック (SMB) またはネットワーク ファイル システム (NFS) 共有として使用することをお勧めします。 Azure Files の代替手段として Azure NetApp Files があります。これは、ハイ パフォーマンスの NFS および SMB 共有を提供します。
また、Azure Files で Windows サーバー フェールオーバー クラスターを使用することで、Central Services インスタンスに高可用性ファイル共有を実装することもできます。 このソリューションは、クラスター共有ボリュームとして Azure 共有ディスクを使用することで、共有ディスクを使用する Windows クラスターもサポートします。 共有ディスクを使用する場合は、Azure 共有ディスクを使用して、SAP セントラル サービス クラスター用の Windows Server フェールオーバー クラスターを設定することをお勧めします。
SIOS Technology Corp. 製の SIOS DataKeeper Cluster Edition などのパートナー製品もあります。このアドオンは、ASCS クラスター ノードにアタッチされている独立したディスクの内容をレプリケートし、その後、それらのディスクをクラスターの共有ボリュームとしてクラスター ソフトウェアに提供します。
クラスター ネットワークのパーティション分割を使用する場合、クラスター ソフトウェアはクォーラム投票により、断片化されているクラスターの頭脳として機能するネットワークのセグメントと関連付けられているサービスを選択します。 Windows には、多くのクォーラム モデルが用意されています。 このソリューションでは、計算ノード監視よりも簡単で可用性が高いクラウド監視を使用します。 Azure ファイル共有監視は、クラスター クォーラム投票を提供するもう 1 つの方法です。
Azure デプロイでは、アプリケーション サーバーは、ASCS または ERS サービスの仮想ホスト名を使用して高可用性のセントラル サービスに接続します。 これらのホスト名は、ロード バランサーのクラスター フロントエンド IP 構成に割り当てられます。 Load Balancer では複数のフロントエンド IP をサポートしているので、ASCS と ERS の両方の仮想 IP (VIP) を 1 つのロード バランサーにバインドできます。
ネットワーク
このアーキテクチャでは、ハブスポーク トポロジを使用します。 ハブ仮想ネットワークは、オンプレミス ネットワークへの接続の中心点として機能します。 スポークは、ハブとピアリングし、SAP ワークロードを分離する仮想ネットワークです。 トラフィックは、ゲートウェイ接続を経由してオンプレミスのデータセンターとハブの間を流れます。
ネットワーク インターフェイス カード (NIC)
NIC を使用すると、仮想ネットワーク上の VM 間のすべての通信が有効になります。 従来のオンプレミスの SAP デプロイでは、管理トラフィックとビジネス トラフィックを切り離すために、マシンごとに複数の NIC が実装されます。
Azure では、仮想ネットワークは、すべてのトラフィックを同じネットワーク ファブリック経由で送信するソフトウェア定義ネットワークです。 そのため、パフォーマンス上の理由から複数の NIC を使用する必要はありません。 ただし、お客様の組織でトラフィックを分離することが必要な場合は、VM ごとに複数の NIC をデプロイして、各 NIC をそれぞれ異なるサブネットに接続することができます。 このようにすると、ネットワーク セキュリティ グループを使用して、さまざまなアクセス制御ポリシーを適用できるようになります。
Azure NIC は、複数の IP をサポートしています。 このサポートは、インストールに仮想ホスト名を使用する、SAP 推奨のプラクティスに準拠しています。 全体的な概要については、SAP Note 962955 を参照してください。 SAP ノートにアクセスするには、SAP Service Marketplace アカウントが必要です。
サブネットとネットワーク セキュリティ グループ
このアーキテクチャでは、仮想ネットワーク アドレス空間がサブネットに分割されます。 各サブネットは、そのサブネットのアクセス ポリシーを定義するネットワーク セキュリティ グループに関連付けることができます。 アプリケーション サーバーは別個のサブネットに配置します。 そうすることにより、個別のサーバーではなくサブネット セキュリティ ポリシーを管理することによって、それらをセキュリティで保護しやすくなります。
ネットワーク セキュリティ グループをサブネットに関連付けている場合、ネットワーク セキュリティ グループはそのサブネット内のすべてのサーバーに適用され、それらのサーバーに対するきめ細かな制御を提供します。 ネットワーク セキュリティ グループは、Azure portal、PowerShell、または Azure CLI を使用して設定できます。
ExpressRoute Global Reach
ネットワーク環境に 2 つ以上の ExpressRoute 接続が含まれている場合は、ExpressRoute Global Reach がネットワーク ホップを減らし、待機時間を短縮するのに役立ちます。 このテクノロジは、2 つの ExpressRoute ルーティング ドメインをブリッジするために 2 つ以上の ExpressRoute 接続間に設定される、Border Gateway Protocol (BGP) ルート ピアリングです。 Global Reach は、ネットワーク トラフィックが 2 つ以上の ExpressRoute 接続を経由する場合、待機時間を短縮します。 これは、現在は、ExpressRoute 回線のプライベート ピアリングでのみ使用できます。
現時点では、Global Reach で変更できるネットワーク アクセス制御リストや他の属性はありません。 つまり、(オンプレミスと Azure からの) 特定の ExpressRoute 回線によって学習されたルートはすべて、その回線ピアリング経由で他方の ExpressRoute 回線にアドバタイズされます。 リソースへのアクセスを制限するために、ネットワーク トラフィックのフィルター処理をオンプレミスで確立することをお勧めします。
ExpressRoute FastPath
FastPath は、お使いのオンプレミス ネットワークと仮想ネットワークの間のデータ パスのパフォーマンスを向上させるように設計されています。 FastPath が有効になっていると、ゲートウェイはバイパスされ、ネットワーク トラフィックが仮想ネットワーク内の仮想マシンに直接送信されます。
Azure へのすべての新しい ExpressRoute 接続では、FastPath が既定の構成です。 既存の ExpressRoute 回線で FastPath をアクティブにするには、Azure サポートにお問い合わせください。
FastPath では、仮想ネットワーク ピアリングはサポートされていません。 他の仮想ネットワークが、ExpressRoute に接続されているものとピアリングされている場合、ユーザーのオンプレミス ネットワークから他のスポーク仮想ネットワークに向かうネットワーク トラフィックは、仮想ネットワーク ゲートウェイに送信されます。 回避策として、すべての仮想ネットワークを ExpressRoute 回線に直接接続します。 現在、この機能はパブリック プレビュー段階にあります。
ロード バランサー
SAP Web Dispatcher では、SAP アプリケーション サーバー プールへの HTTP(S) トラフィックの負荷分散が処理されます。 このソフトウェア ロード バランサーでは、SSL ターミネーションやその他のオフロード機能を実行できるアプリケーション層サービス (ISO ネットワーク モデルではレイヤー 7 と呼ばれます) が提供されます。
Azure Load Balancer は、データ ストリームからの 5 組のハッシュを使用してトラフィックを負荷分散するネットワーク転送層サービス (レイヤー 4) です。 ハッシュは、ソース IP、ソース ポート、接続先 IP、接続先ポート、プロトコルの種類に基づいています。 Azure での SAP のデプロイでは、障害発生時にプライマリ サービス インスタンスまたは正常なノードにトラフィックを転送するためにクラスターのセットアップで Load Balancer が使用されます。
すべての SAP シナリオで Standard Load Balancer を使用することをお勧めします。 バックエンド プール内の VM でパブリック送信接続が必要となる場合、または Azure ゾーンのデプロイでそれらが使用される場合、既定でセキュリティ保護されているため、Standard Load Balancer には 追加の構成が必要になります。 それらでは、ユーザーが明示的に構成しない限り、送信接続は許可されません。
DIAG プロトコルまたは RFC を使用して SAP サーバーに接続している SAP GUI クライアントからのトラフィックについては、セントラル サービスのメッセージ サーバーでは、SAP アプリケーション サーバーのログオン グループを使用して負荷が分散されます。 このタイプの設定の場合、別のロード バランサーは必要ありません。
ストレージ
一部の組織では、アプリケーション サーバーに標準ストレージを使用しています。 標準マネージド ディスクはサポートされていません。 SAP Note 1928533 を参照してください。 SAP ノートにアクセスするには、SAP Service Marketplace アカウントが必要です。 すべてのケースでプレミアム Azure マネージド ディスクを使うことをお勧めします。 SAP ノート 2015553 の最近の更新では、いくつかの特定のユース ケースで Standard HDD ストレージと Standard SSD ストレージの使用が除外されています。
アプリケーション サーバーでは、ビジネス データはホストされません。 それで、コストを最小限に抑えるために、さらに小さい P4 および P6 Premium ディスクを使用することもできます。 そうすることにより、セントラル SAP スタックがインストールされている場合に、単一インスタンス VM SLA のメリットを得ることができます。
高可用性シナリオでは Azure ファイル共有と Azure 共有ディスクを使用できます。 Azure Premium SSD マネージド ディスク と Azure Ultra Disk Storage は Azure 共有ディスクで利用できます。Premium SSD は Azure ファイル共有でも利用できます。
Storage はクラウド監視で も使用されます。これにより、クラスターが存在するプライマリ リージョンから離れた場所にあるリモート Azure リージョンのデバイスで、クォーラムが保持されます。
バックアップ データ ストアでは、Azure のクールおよびアーカイブ アクセス層をお勧めします。 これらのストレージ層では、アクセス頻度が低い長期保管データを、コスト効果の高い方法で保存できます。
Azure Premium SSD v2 ディスク ストレージ は、高い IOPS とスループットを組み合わせたミリ秒未満の待機時間を常に必要とするオンライン トランザクション処理システムなど、パフォーマンス クリティカルなワークロード向けに設計されています。
Ultra Disk Storage を使用すると、ディスクの待機時間が大幅に短縮されます。 そのため、SAP データベース サーバーなどのパフォーマンスが重要なアプリケーションにとって有益です。 Azure のブロック ストレージ オプションを比較するには、「Azure マネージド ディスクの種類」を参照してください。
高可用性のハイ パフォーマンス共有データ ストアには、Azure NetApp Files を利用します。 このテクノロジは、Oracle を使用する場合、およびアプリケーション データをホストする場合に、データベース層で特に役立ちます。
パフォーマンスに関する考慮事項
SAP アプリケーション サーバーは、データベース サーバーと常時通信します。 データベース プラットフォームで実行されているパフォーマンス クリティカルなアプリケーションについては、Premium SSD v1 を使用している場合、ログ ボリュームの書き込みアクセラレータを有効にします。 これにより、ログ書き込みの待機時間を短縮できます。 書き込みアクセラレータは、M シリーズの VM で使用できます。
サーバー間の通信を最適化するには、高速ネットワークを使用します。 高速ネットワークは、2 つ以上の vCPU を備えた、汎用目的およびコンピューティングに最適化されたインスタンス サイズのほとんどでサポートされています。 ハイパースレッディングをサポートするインスタンスでは、高速ネットワークは 4 つ以上の vCPU を持つ VM インスタンスでサポートされています。
高い IOPS とディスク スループットを達成するために、ストレージ ボリュームのパフォーマンス最適化の共通プラクティスに従います。これは、Azure Storage レイアウトに適用されます。 たとえば、複数のディスクをまとめて配置してストライピングされたディスク ボリュームを作成すると、I/O パフォーマンスを向上できます。 変更が頻繁に行われないストレージ コンテンツの読み取りキャッシュを有効にすると、データ取得の速度が向上します。
Premium SSD v2 は、Premium SSD よりも高いパフォーマンスを提供し、通常はコストも低くなります。 Premium SSD v2 ディスクは、サポートされている任意のサイズに設定し、ダウンタイムなしでパフォーマンスに合わせて細かい調整を行うことが可能です。
Ultra Disk Storage は、I/O 集中型のアプリケーションに使用できます。 このようなディスクが使用可能な場合は、書き込みアクセラレータ Premium Storage よりもこれらをお勧めします。 IOPS や Mbps などのパフォーマンス メトリックは、再起動しなくても個別に増減できます。
SQL Server で SAP ワークロード用に Azure Storage を最適化する方法については、「SAP NetWeaver のための Azure Virtual Machines の計画と実装」を参照してください。
SAP アプリケーション スタックのアプリケーション層とデータベース層の間に、ネットワーク仮想アプライアンス (NVA) を配置することはサポートされていません。 そのようにすると、データ パケットの処理時間が大幅に増加し、許容できないアプリケーション パフォーマンスにつながります。
近接通信配置グループ
一部の SAP アプリケーションでは、データベースと頻繁に通信する必要があります。 アプリケーション層とデータベース層の物理的な近接はネットワークの待機時間に影響し、それによってアプリケーションのパフォーマンスに悪影響を及ぼす可能性があります。
ネットワークの待機時間を最適化するために、近接通信配置グループを使用できます。これにより、可用性セット内にデプロイされた VM に対して論理的な制約が設けられます。 近接配置グループでは、スケーラビリティ、可用性、コストよりもコロケーションとパフォーマンスが優先されます。 それらを使用すると、大半の SAP アプリケーションでユーザー エクスペリエンスを大幅に向上できます。 SAP デプロイ チームによる、GitHub で使用できるスクリプトについては、「スクリプト」を参照してください。
可用性ゾーン
可用性ゾーン には、複数のデータセンター (特定の Azure リージョン内で物理的に分離された場所) に VM をデプロイする方法が用意されています。 これらは、サービスの可用性を強化することを目的としています。 ただし、複数のゾーンにリソースをデプロイすると待機時間が長くなる可能性があるため、パフォーマンスに関する考慮事項に留意してください。
管理者がゾーン間の待機時間が最小となるようなリソースの配置を決める前に、ターゲット リージョンのすべてのゾーン間の明確なネットワーク待機時間プロファイルが必要です。 このプロファイルを作成するには、各ゾーンにテスト用の小規模の VM をデプロイします。 これらのテストに推奨されるツールとして、PsPing と Iperf があります。 テストが完了したら、テストに使用した VM を削除します。 別の方法として、Azure のゾーン間待機時間チェック ツールの使用を検討してください。
スケーラビリティに関する考慮事項
SAP アプリケーション レイヤーについては、Azure では、スケールアップおよびスケールアウトのための幅広い VM サイズが用意されています。詳細な一覧については、SAP ノート 1928533 の「SAP Applications on Azure: Supported Products and Azure VM Types (Azure 上の SAP アプリケーション: サポートされる製品と Azure VM の種類)」を参照してください。 SAP ノートにアクセスするには、SAP Service Marketplace アカウントが必要です。
SAP アプリケーション サーバーとセントラル サービス クラスターは、スケールアップやスケールダウンが行えます。 また、使用するインスタンスの数を変更することで、スケール アウトまたはスケールインすることもできます。 AnyDB データベースは、スケールアップとスケールダウンはできますが、スケールアウトはできません。AnyDB の SAP データベース コンテナーでは、シャーディングがサポートされていません。
可用性に関する考慮事項
リソースの冗長性は、高可用性インフラストラクチャ ソリューションの一般的なテーマです。 さまざまなストレージの種類向けの単一インスタンス VM 可用性 SLA については、「仮想マシンの SLA」を参照してください。 Azure でのサービスの可用性を高めるには、柔軟なオーケストレーションを備えた Virtual Machine Scale Sets、可用性ゾーン、または可用性セットを使用して VM リソースをデプロイします。
Azure では、SAP ワークロードのデプロイは、SAP アプリケーションの可用性と回復性の要件に応じて、リージョンまたはゾーンのいずれかにできます。 Azure には、リソースの可用性を高めるために、柔軟なオーケストレーション (FD=1) を備えた Virtual Machine Scale Sets、可用性ゾーン、可用性セットなど、さまざまなデプロイ オプションが用意されています。 さまざまな Azure リージョン (ゾーン間、単一ゾーン内、またはゾーンのないリージョンを含む) での利用可能なデプロイ オプションとその適用性を包括的に理解するには、「SAP NetWeaver のための高可用性のアーキテクチャとシナリオ」を参照してください。
このように SAP アプリケーションを分散してインストールした場合、高可用性を実現するために基本のインストールがレプリケートされます。 高可用性の設計は、アーキテクチャのレイヤーごとに異なります。
アプリケーション サーバー層の Web Dispatcher
Web Dispatcher コンポーネントは、SAP アプリケーション サーバー間の SAP トラフィックのロード バランサーとして使用されます。 SAP Web Dispatcher の高可用性を実現するには、Load Balancer でフェールオーバー クラスターまたは並列 Web Dispatcher セットアップを実装します。
インターネットに接続する通信の場合は、セキュリティ上の懸念事項に対応するために、境界ネットワーク (DMZ とも呼ばれます) のスタンドアロン ソリューションをお勧めします。
ASCS の Embedded Web Dispatcher は特別なオプションです。 このオプションを使用する場合は、ASCS で余分なワークロードが発生するため、適切なサイズ設定を検討してください。
アプリケーション サーバー層のセントラル サービス
セントラル サービスの高可用性は、Windows Server フェールオーバー クラスターで実装されます。 フェールオーバー クラスター用のクラスター ストレージが Azure にデプロイされている場合は、それを 2 つの方法 (クラスター共有ディスクまたはクラスター化されたファイル共有) で構成できます。
推奨されているのは、Azure Files をフル マネージドのクラウドネイティブ SMB または NFS 共有として使用することです。 別の方法として、Azure NetApp Files を使用することもできます。これは、ハイ パフォーマンスでエンタープライズ クラスの NFS および SMB 共有を提供します。
Azure で共有ディスクを使用してクラスターを設定するには、2 つの方法があります。 まず、Azure 共有ディスクを使用して SAP セントラル サービス用の Windows Server フェールオーバー クラスターを設定することをお勧めします。 実装例については、Azure 共有ディスクを使用した SAP ASCS クラスターに関するページを参照してください。 クラスター化された共有ディスクを実装するもう 1 つの方法は、SIOS DataKeeper を使用して次のタスクを実行することです。
- クラスター ノードにアタッチされている独立したディスクの内容をレプリケートする。
- それらのドライブをクラスター マネージャー用のクラスターの共有ボリュームして抽象化する。
実装の詳細については、SIOS を使用した Azure での SAP ASCS のクラスタリングに関するページをご覧ください。
Standard Load Balancer を使用する場合は、高可用性ポートを有効にできます。 これにより、複数の SAP ポートに対して負荷分散規則を構成する必要がなくなります。 また、Azure ロード バランサーを設定するときは、Direct Server Return (DSR) ("フローティング IP" とも呼ばれます) を有効にします。 これにより、サーバーの応答がロード バランサーをバイパスする方法が提供されます。 この直接接続により、ロード バランサーがデータ転送のパスでボトルネックになることはありません。 ASCS およびデータベース クラスターについては、DSR を有効にすることをお勧めします。
アプリケーション サーバー層のアプリケーション サービス
SAP アプリケーション サーバーの高可用性は、アプリケーション サーバーのプール内のトラフィックを負荷分散することによって実現します。 クラスター ソフトウェア、SAP Web Dispatcher、または Azure ロード バランサーは必要ありません。 SAP メッセージ サーバーは、トランザクション SMLG によって ABAP ログオン グループで定義されているアプリケーション サーバーへのクライアント トラフィックを負荷分散できます。
データベース層
このアーキテクチャでは、ソース データベースは AnyDB (SQL Server、SAP ASE、IBM DB2、Oracle などの DBMS) で実行されます。 データベース層のネイティブのレプリケーション機能では、レプリケートされたノード間でのフェールオーバーを手動または自動で行うことができます。
特定のデータベース システムの実装の詳細については、「SAP NetWeaver のための Azure Virtual Machines DBMS のデプロイ」を参照してください。
可用性ゾーンをまたいでデプロイされる VM
可用性ゾーンは、1 つ以上のデータセンターで構成されます。 ワークロードの可用性を向上させ、アプリケーション サービスと VM をデータセンターの障害から保護するように設計されています。 1 つのゾーン内の VM は、1 つの障害ドメインに存在するかのように扱われます。 ゾーン デプロイを選択すると、同じゾーン内の VM は、ベストエフォート方式で障害ドメインに分散されます。
複数のゾーンをサポートする Azure リージョンでは、少なくとも 3 つのゾーンを使用できます。 ただし、これらのゾーン内のデータセンター間の最大距離は保証されません。 ゾーンをまたいで多層 SAP システムをデプロイするには、あるゾーン内のネットワーク待機時間と対象となる複数のゾーン間のネットワーク待機時間を知る必要があります。 また、ユーザーがデプロイするアプリケーションがネットワーク待機時間にどの程度影響されるかも知っている必要があります。
可用性ゾーンをまたいでリソースをデプロイすることに決める場合は、次の考慮事項を考慮に入れる必要があります。
- 1 つのゾーン内の VM 間の待機時間
- 選択されたゾーン全体の VM 間の待機時間
- 選択されたゾーンでの同じ Azure サービス (VM の種類) の可用性
注意
可用性ゾーンはリージョン内の高可用性をサポートしていますが、ディザスター リカバリー (DR) には効果がありません。 ゾーン間の距離が短すぎます。 一般的な DR サイトは、プライマリ リージョンから少なくとも 100 マイル離れている必要があります。
アクティブ/非アクティブのデプロイ例
このデプロイ例では、アクティブ/パッシブ ステータスは、ゾーン内のアプリケーション サービスの状態を表します。 アプリケーション層では、SAP システムの 4 つのアクティブなアプリケーション サーバーすべてがゾーン 1 にあります。 4 つのパッシブなアプリケーション サーバーからなるもう 1 つのセットは、ゾーン 2 に構築されていますが、シャットダウンされています。 それらは、必要な場合にのみアクティブ化されます。
セントラル サービスとデータベース サービスの 2 ノード クラスターは、2 つのゾーンにわたって拡張されます。 ゾーン 1 で障害が発生すると、セントラル サービスとデータベース サービスがゾーン 2 で実行されます。 ゾーン 2 のパッシブなアプリケーション サーバーがアクティブになります。 この SAP システムのすべてのコンポーネントが同じゾーンに併置されている状態では、ネットワーク待機時間が最小限に抑えられます。
アクティブ/アクティブのデプロイ例
アクティブ/アクティブ のデプロイでは、2 つのアプリケーション サーバー セットが 2 つのゾーンにわたって構築されます。 各ゾーン内では、それぞれのサーバー セットのうちの 2 つのアプリケーション サーバーは、シャットダウンされているため、非アクティブになっています。 その結果、通常の操作時には、両方のゾーンにアクティブなアプリケーション サーバーが存在します。
セントラル サービスとデータベース サービスは、ゾーン 1 で実行されます。 ゾーン 2 のアプリケーション サーバーは、ゾーン間の物理的な距離が原因で、セントラル サービスとデータベース サービスへの接続時にネットワーク待機時間が長くなる可能性があります。
ゾーン 1 がオフラインになった場合、セントラル サービスとデータベース サービスはゾーン 2 にフェールオーバーされます。 休止中のアプリケーション サーバーをオンラインにして、アプリケーション処理のための十分な容量を確保することができます。
DR に関する考慮事項
SAP アプリケーション スタックの各レベルでは、DR 保護を提供するために別のアプローチを使用します。 DR 戦略と実装の詳細については、「SAP ワークロードのディザスター リカバリーの概要とインフラストラクチャのガイドライン」および「SAP アプリケーションに関するディザスター リカバリーのガイドライン」を参照してください。
注意
1 つのリージョンの多くの Azure ユーザーに影響を及ぼす大規模なフェールオーバー イベントの原因となる地域的災害が発生した場合、そのターゲット リージョンのリソースの容量は保証されません。 すべての Azure サービスと同様に、Site Recovery は引き続き機能を追加します。 Azure から Azure へのレプリケーションに関する最新情報については、サポート マトリックスをご覧ください。
管理と操作に関する考慮事項
運用環境でシステムの動作を維持するために、次の点を考慮してください。
Azure Center for SAP solutions
Azure Center for SAP solutions は、SAP システムを Azure 上の統合ワークロードとして作成して実行できるようにするとともに、イノベーションのためのよりシームレスな基盤を提供する、エンド ツー エンドのソリューションです。 また、Azure Center for SAP solutions のガイド付きデプロイ エクスペリエンスでは、SAP システムを実行するために必要なコンピューティング、ストレージ、およびネットワーク コンポーネントを作成します。 これにより、Microsoft のベスト プラクティスに従って SAP ソフトウェアのインストールを自動化できます。 新規と既存の両方の Azure ベースの SAP システムに対して管理機能を利用できます。 詳しくは、「Azure Center for SAP solutions」を参照してください。
パフォーマンス上またはコンプライアンス上の理由で、メンテナンス イベントやハードウェアの分離に対する制御がさらに必要な場合は、使用する VM を専用ホストにデプロイすることを検討してください。
バックアップ
データベースは、低い回復ポイントの目標値 (RPO) と長期リテンション期間を必要とする重要なワークロードです。
SQL Server 上の SAP の場合、1 つの方法としては、Azure Backup を使用して、VM で実行されている SQL Server データベースをバックアップすることができます。 別の方法としては、Azure Files のスナップショットを使用して、SQL Server のデータベース ファイルをバックアップすることもできます。
Oracle/Windows 上の SAP については、SAP のための Azure VM DBMS のデプロイに関する記事の「Backup/restore (バックアップ/復元)」をご覧ください。
その他のデータベースについては、データベース プロバイダーのバックアップに関する推奨事項を参照してください。 そのデータベースが Windows ボリューム シャドウ コピー サービス (VSS) をサポートしている場合、アプリケーション整合性バックアップに VSS スナップショットを使用します。
ID 管理
Microsoft Entra ID や Active Directory Domain Services (AD DS) などの一元化された ID 管理システムを使用して、すべてのレベルでリソースへのアクセスを制御します。
Azure のロールベースのアクセス制御 (Azure RBAC) を使用して、Azure リソースへのアクセスを提供します。
LDAP (Lightweight Directory Access Protocol)、Microsoft Entra ID、Kerberos、または別のシステムを使用して、Azure VM へのアクセスを許可します。
SAP が提供するサービスを使用して、それらのアプリケーション自体の内部のアクセスをサポートします。 または、OAuth 2.0 と Microsoft Entra ID を使用します。
監視
Azure 上のアプリケーションとサービスの可用性とパフォーマンスを最大化するには、クラウドおよびオンプレミス環境からテレメトリを収集、分析し、操作するための包括的なソリューションを提供する Azure Monitor を使用します。 Azure Monitor では、アプリケーションの実行状況を示し、それらに影響する問題やそれらが依存しているリソースを事前に特定します。 SAP HANA およびその他の主要なデータベース ソリューションで実行される SAP アプリケーションについては、「Azure Monitor for SAP Solutions」を参照して、Azure Monitor for SAP が SAP サービスの可用性とパフォーマンスの管理にどのように役立つかをご確認ください。
セキュリティに関する考慮事項
SAP には、SAP アプリケーションおよびデータベース内でロールベースのアクセスと認可を制御する独自のユーザー管理エンジン (UME) があります。 アプリケーションのセキュリティ ガイダンスの詳細については、SAP NetWeaver のセキュリティ ガイドを参照してください。
追加のネットワーク セキュリティについては、NVA を使用する境界ネットワークを使用して、Web Dispatcher のサブネットの前面にファイアウォールを作成することを検討してください。
NVA をデプロイして仮想ネットワーク間のトラフィックをフィルター処理することはできますが、SAP アプリケーションとデータベースの間には NVA を配置しないでください。 また、サブネット上に構成されているルーティング規則を確認し、単一インスタンスの NVA にトラフィックを送信しないようにします。 これは、メンテナンスのダウンタイムおよびネットワークやクラスター ノードの障害の原因となるおそれがあります。
インフラストラクチャ セキュリティでは、データは転送時および保存時に暗号化されます。 ネットワークのセキュリティについては、「SAP NetWeaver のための Azure Virtual Machines の計画と実装」の「セキュリティに関する推奨事項」セクションを参照してください。 また、この記事では、アプリケーション通信を許可するために、ファイアウォールで開く必要があるネットワーク ポートも指定しています。
Azure Disk Encryption を使用して、Windows VM ディスクを暗号化できます。 このサービスでは、Windows の BitLocker 機能によって、オペレーティング システムおよびデータ ディスクのボリュームが暗号化されます。 また、このソリューションは Azure Key Vault と共に動作するため、お使いのキー コンテナー サブスクリプションのディスク暗号化キーとシークレットの制御および管理にも役立ちます。 VM ディスク上のデータは暗号化され、お使いの Azure ストレージに保存されます。
保存データの暗号化の場合、SQL Server の Transparent Data Encryption (TDE) によって、SQL Server、Azure SQL Database、および Azure Synapse Analytics のデータ ファイルが暗号化されます。 詳細については、SAP NetWeaver のための SQL Server Azure Virtual Machines DBMS のデプロイをご覧ください。
ファイアウォールの内部と外部からの脅威を監視するには、Microsoft Sentinel (プレビュー) のデプロイを検討してください。 このソリューションでは、Azure、他のクラウド、またはオンプレミスにデプロイされた SAP システムに対する継続的な脅威検出と分析を提供します。 デプロイ ガイダンスについては、「Microsoft Sentinel の Threat Monitoring for SAP をデプロイする」を参照してください。
これまでと同様、お客様ご自身の情報資産を保護するため、セキュリティ更新プログラムとパッチを管理してください。 このタスクのために、エンド ツー エンドの自動化アプローチの使用をご検討ください。
コストに関する考慮事項
コストの見積もりには、Azure 料金計算ツールをご利用ください。
詳細については、「Microsoft Azure Well-Architected Framework」のコストのセクションを参照してください。
ワークロードにさらに多くのメモリが必要で、CPU が少なくて済む場合は、制約付き vCPU VM サイズのいずれかを使用して、vCPU ごとに課金されるソフトウェア ライセンス コストを削減することを検討してください。
VM
このアーキテクチャでは、アプリケーション層とデータベース層に VM を使用します。 SAP NetWeaver 層では、Windows VM を使用して SAP サービスとアプリケーションが実行されます。 データベース層では、SQL Server、Oracle、IBM DB2 などの AnyDB がデータベースとして実行されます。 VM は、管理のジャンプボックスとしても使用されます。
VM には支払いオプションがいくつかあります。
完了時間またはリソース消費が予測できないワークロードの場合は、従量課金制オプションをご検討ください。
VM の 1 年または 3 年間での使用をコミットできる場合は、Azure の予約を使用することを検討してください。 VM の予約により、コストを大幅に削減できます。 支払いは、従量課金制サービスのコストのわずか 72% になる場合があります。
中断が可能であり、事前に設定された期間または SLA 内に完了する必要のないワークロードを実行するときは、Azure スポット VM を使用します。 Azure によって、利用可能な容量がある場合はスポット VM がデプロイされ、容量を戻す必要がある場合はそれらが無効にされます。 スポット VM に関連付けられているコストは、他の VM よりも低くなります。 次のワークロードには、スポット VM を検討します。
- ハイ パフォーマンス コンピューティングのシナリオ、バッチ処理ジョブ、またはビジュアルなレンダリング アプリケーション
- 継続的インテグレーションと継続的デリバリー ワークロードを含むテスト環境
- 大規模なステートレス アプリケーション
Azure Reserved Virtual Machine Instances では、Azure Reserved Virtual Machine Instances の料金と従量課金制サブスクリプションを組み合わせることで総保有コストを削減できるため、予測可能および変動するワークロード全体のコストを管理できます。 詳細については、「Azure Reserved Virtual Machine Instances」を参照してください。
Load Balancer
このシナリオでは、Load Balancer は、アプリケーション層サブネット内の VM にトラフィックを分散させるときに使用されます。
構成された負荷分散規則とアウトバウンド規則の数と、ロード バランサーを介して処理されたデータに対してのみ課金されます。 受信ネットワーク アドレス変換 (NAT) 規則は無料です。 規則が構成されていない場合、Standard Load Balancer に対する時間あたりの料金は発生しません。
ExpressRoute
このアーキテクチャでは、ExpressRoute は、オンプレミス ネットワークと Azure 仮想ネットワークの間にプライベート接続を作成するために使用されるネットワーク サービスです。
受信データ転送はすべて無料です。 送信データ転送はすべて、事前に決められた料金に基づいて課金されます。 詳細については、「Azure ExpressRoute の価格」をご覧ください。
コミュニティ
コミュニティは質問に答え、デプロイを正常に完了できるよう支援します。 次のリソースを考慮してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は次のとおりです。
プリンシパル作成者:
- Ben Trinh | プリンシパル アーキテクト
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次の手順
このアーキテクチャと同じテクノロジの一部を使用する SAP ワークロードの詳細と例については、次の記事を参照してください。