Azure 上の Linux での SAP S/4HANA

2025-04-30

このガイドでは、Azure 上のディザスターリカバリー (DR) をサポートする高可用性 (HA) 環境で S/4HANA と Suite on HANA を実行するための一連の実証済みプラクティスについて説明します。 Fiori の情報は、S/4HANA アプリケーションにのみ適用されます。

アーキテクチャ

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

注

このアーキテクチャをデプロイするには、SAP 製品およびその他の Microsoft 以外のテクノロジに必要なライセンスがあることを確認します。

このガイドでは、一般的な運用システムについて説明します。このアーキテクチャでは、さまざまな仮想マシン (VM) サイズを使用します。組織のニーズに対応するために、サイズを調整するか、この構成を 1 つの VM に減らすことができます。

このガイドでは、アーキテクチャの原則を示すためにネットワークレイアウトが簡略化されています。完全なエンタープライズネットワークを表すわけではありません。

このアーキテクチャは、次のコンポーネントを使用します。一部の共有サービスは省略可能です。

Azure Virtual Network。 Virtual Network サービスは、セキュリティが強化された Azure リソースを相互に接続します。このアーキテクチャでは、仮想ネットワークは、ハブスポークトポロジのハブにデプロイされたゲートウェイ経由でオンプレミス環境に接続されます。このスポークは、SAP アプリケーションおよびデータベース層に使用される仮想ネットワークです。

仮想ネットワーク接続。 このアーキテクチャでは、ピアリングされた複数の仮想ネットワークが使用されます。このトポロジでは、Azure にデプロイされたサービスのためのネットワークのセグメント化と分離が提供されます。ピアリングは、Microsoft バックボーンネットワークを介してネットワークを透過的に接続し、1 つのリージョン内に実装されている場合、パフォーマンスの低下は発生しません。アプリケーション層 (SAP NetWeaver) とデータベース層を含む各層、ジャンプボックスや Windows Server Active Directory などの共有コンポーネントには、個別のサブネットが使用されます。

VM。 このアーキテクチャでは、Linux を実行する VM を、次の方法でアプリケーション層とデータベース層のグループに編成します。

アプリケーション層。 このアーキテクチャ層には、Fiori Front-end Server プール、SAP Web Dispatcher プール、アプリケーションサーバープール、および SAP セントラルサービスクラスターが含まれます。 Linux VM で実行される Azure 上のセントラルサービスの HA の場合、Azure Files、Azure NetApp Files、クラスター化 NFS サーバー、SIOS Protection Suite for Linux のネットワークファイルシステム (NFS) ファイル共有など、高可用性ネットワークファイル共有サービスが必要です。 Red Hat Enterprise Linux (RHEL) のセントラルサービスクラスター用に高可用性ファイル共有を設定するには、RHEL を実行する Azure VM で GlusterFS を構成できます。 SUSE Linux Enterprise Server (SLES) 15 SP1 以降のバージョンまたは SLES for SAP Applications では、Pacemaker クラスター上の Azure 共有ディスクをフェンスデバイスとして使用して HA を実現できます。
SAP HANA。 データベース層では、クラスター内の 2 つ以上の Linux VM を使用して、スケールアップデプロイで HA を実現します。 HANA システムレプリケーション (HSR) を使用して、プライマリ HANA システムとセカンダリ HANA システムの間でコンテンツがレプリケートされます。 Linux クラスタリングは、システム障害を検出し、自動フェールオーバーを容易にするために使用されます。パーティション分割されたクラスターを回避するために、障害が発生したシステムを確実に分離またはシャットダウンするには、ストレージベースまたはクラウドベースのフェンスメカニズムを使用する必要があります。 HANA スケールアウトデプロイでは、次のいずれかのオプションを使用してデータベース HA を実現できます。
- Linux クラスタリングコンポーネントを使用せずに Azure NetApp Files を使用して HANA スタンバイノードを構成します。
- Azure Premium Storage を使用して、スタンバイノードなしでスケールアウトします。フェールオーバーには Linux クラスタリングを使用します。
Azure Bastion。 このサービスを使用すると、ブラウザーと Azure portal を使用するか、ローカルコンピューターにインストールされているネイティブ Secure Shell (SSH) またはリモートデスクトッププロトコル (RDP) クライアントを使用して VM に接続できます。管理に RDP と SSH のみを使用する場合は、 Azure Bastion の使用を検討してください。 SQL Server Management Studio や SAP フロントエンドなどの他の管理ツールを使用する場合は、自己デプロイ済みの従来のジャンプボックスが使用されます。

プライベート DNS サービス。Azure プライベート DNS は、仮想ネットワークのための、信頼性が高く安全な DNS サービスとなります。カスタムの DNS ソリューションを構成しなくても、Azure プライベート DNS によって、仮想ネットワークにおけるドメイン名の管理と解決が行われます。

ロードバランサー。 SAP アプリケーション層サブネット内の VM にトラフィックを分散して可用性を向上するには、 Azure Standard Load Balancer を使用します。 Standard Load Balancer では、既定でセキュリティレイヤーが提供されます。 Standard Load Balancer の背後にある VM には、送信インターネット接続はありません。 VM で送信インターネットを有効にするには、Standard Load Balancer の構成を更新する必要があります。 Azure NAT Gateway を使用して送信接続を取得することもできます。 SAP Web ベースのアプリケーション HA の場合は、組み込みの SAP Web Dispatcher または他の市販のロードバランサーを使用します。次の基準に基づいて選択します。

トラフィックの種類 (HTTP や SAP グラフィカルユーザーインターフェイス (GUI) トラフィックなど)。
必要なネットワーク機能 (Secure Sockets Layer (SSL) ターミネーションなど)。

Standard Load Balancer では、複数のフロントエンド仮想 IP アドレスがサポートされます。このサポートは、次のコンポーネントを含むクラスター実装に最適です。

高度なビジネスアプリケーションプログラミング (ABAP) SAP セントラルサービス (ASCS)
レプリケーションサーバーをキューに追加する

これら 2 つのコンポーネントでは、ロードバランサーを共有してソリューションを簡略化できます。

Standard Load Balancer では、複数システム識別子 (マルチ SID) SAP クラスターもサポートされています。この機能により、 SLES または RHEL 上の複数の SAP システムで共通の HA インフラストラクチャを共有して、コストを削減できます。コスト削減を評価し、1 つのクラスターにシステムを配置しすぎないようにすることをお勧めします。 Azure では、クラスターごとに最大 5 つの SID がサポートされています。

アプリケーションゲートウェイ。 Azure Application Gateway は、Web アプリケーションへのトラフィック管理に使用できる Web トラフィックロードバランサーです。従来のロードバランサーは、伝送制御プロトコルとユーザーデータグラムプロトコルを使用して、オープンシステム相互接続 (OSI) レイヤー 4 と呼ばれるトランスポート層で動作します。トラフィックは送信元 IP アドレスとポートに基づいて送信先 IP アドレスとポートにルーティングされます。 Application Gateway では、均一なリソース識別子パスやホストヘッダーなど、HTTP 要求の追加属性に基づいてルーティングの決定を行うことができます。この種類のルーティングは、アプリケーション層、または OSI レイヤー 7 の負荷分散と呼ばれます。 S/4HANA は、Fiori を介して Web アプリケーションサービスを提供します。この Fiori フロントエンドは、Web アプリで構成され、Application Gateway を使用して負荷分散できます。パブリック IP アドレスを使用する場合は、それらが Standard IP アドレス SKU を使用していることを確認します。 Basic IP アドレス SKU は、2025 年 9 月 30 日に非推奨となる予定であるため、避けてください。

ゲートウェイ。 ゲートウェイは個々のネットワークを接続し、オンプレミスネットワークを Azure 仮想ネットワークに拡張します。 Azure ExpressRoute は、パブリックインターネットを経由しないプライベート接続を作成するために推奨される Azure サービスです。サイト間接続を使用することもできます。待機時間を短縮するには、 ExpressRoute Global Reach または ExpressRoute FastPath を使用します。

ゾーン冗長ゲートウェイ。 ExpressRoute または仮想プライベートネットワーク (VPN) ゲートウェイをゾーン全体にデプロイして、ゾーンの障害から保護することができます。このアーキテクチャでは、同じ可用性ゾーンに基づくゾーン展開ではなく、回復性のためにゾーン冗長仮想ネットワークゲートウェイを使用します。

近接通信配置グループ。 この論理グループでは、可用性セットまたは仮想マシンスケールセットにデプロイされた VM に制約が設けられます。近接通信配置グループは、VM が確実に同じデータセンターにデプロイされるようにすることで、コロケーションを強制するのに役立ちます。この構成により、アプリケーションの待ち時間を最小限に抑えるために、リソース間の物理的な距離が短縮されます。

注

更新された構成戦略については、 SAP アプリケーションでのネットワーク待ち時間を最小限に抑えるための構成オプションを参照してください。この記事では、ネットワーク待ち時間のために SAP システムを最適化する場合の、デプロイの柔軟性における潜在的なトレードオフについて説明します。

ネットワークセキュリティグループ (NSG)。 仮想ネットワーク内の受信、送信、サブネット内のトラフィックを制限するには、 NSG を作成します。

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

Azure Storage です。 Storage では、VM のデータの永続化が仮想ハードディスクの形式で提供されます。 Azure マネージドディスクを使用することをお勧めします。

推奨事項

このアーキテクチャでは、小規模な運用レベルのデプロイについて説明します。デプロイはビジネス要件によって異なるため、これらの推奨事項を開始点として検討してください。

VM

アプリケーションサーバーのプールおよびクラスターで、それぞれの要件に基づいて VM の数を調整します。 VM で SAP NetWeaver を実行する方法の詳細については、 Azure Virtual Machines の計画と実装ガイドを参照してください。このガイドは、SAP S/4HANA デプロイにも適用されます。

Azure VM の種類とスループットメトリックに対する SAP サポートの詳細については、 SAP Note 1928533を参照してください。 SAP ノートにアクセスするには、SAP Service Marketplace アカウントが必要です。 HANA データベースの認定済み Azure VM の一覧については、 SAP 認定およびサポートされている SAP HANA ハードウェアディレクトリに関するページを参照してください。

SAP Web Dispatcher

Web Dispatcher コンポーネントは、SAP アプリケーションサーバー間の SAP トラフィックの負荷分散に使用されます。 SAP Web Dispatcher の HA を実現するために、Azure Load Balancer はフェールオーバークラスターまたは並列 Web Dispatcher セットアップを実装します。インターネットに接続する通信の場合、境界ネットワーク内のスタンドアロンソリューションは、セキュリティ要件に対処するための推奨アーキテクチャです。 ASCS 上の埋め込み Web ディスパッチャーは、高度な構成です。この構成を使用する場合は、ASCS で追加のワークロードが発生するため、適切なサイズ設定を検討してください。

Fiori フロントエンドサーバー (FES)

このアーキテクチャは複数の要件を満たし、埋め込み Fiori FES モデルを使用することを前提としています。すべてのテクノロジコンポーネントは S/4 システムに直接インストールされるため、各 S/4 システムには独自の Fiori スタートパッドがあります。 S/4 システムは、このデプロイモデルの HA 構成を管理します。この方法では、追加のクラスタリングまたは VM が不要になります。このため、アーキテクチャ図には FES コンポーネントは含まれません。

デプロイオプションの詳細については、 SAP Fiori デプロイオプションとシステムランドスケープの推奨事項を参照してください。簡素化とパフォーマンスのために、Fiori テクノロジコンポーネントと S/4 アプリケーション間のソフトウェアリリースは密結合されています。このセットアップにより、ハブのデプロイは、少数の特定のユースケースにのみ適しています。

FES ハブのデプロイを使用する場合、FES はクラシック SAP NetWeaver ABAP スタックのアドオンコンポーネントです。クラスター化または複数ホスト機能を備えた 3 層 ABAP アプリケーションスタックを保護するのと同じ方法で HA を設定します。スタンバイサーバーデータベースレイヤー、共有ストレージ用の HA NFS を含むクラスター化 ASCS レイヤー、および少なくとも 2 つのアプリケーションサーバーを使用します。トラフィックは、クラスター化または並列にできる Web Dispatcher インスタンスのペアを介して負荷分散されます。インターネットに接続する Fiori アプリの場合は、境界ネットワークに FES ハブをデプロイすることをお勧めします。脅威を回避するための重要なコンポーネントとして、Application Gateway 上の Azure Web Application Firewall を使用します。ユーザー認証と SAP Fiori のシングルサインオンには、セキュリティアサーションマークアップ言語と共に Microsoft Entra ID を使用します。

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

詳細については、「 SAP on Azure の受信および送信インターネット接続」を参照してください。

アプリケーションサーバープール

ABAP アプリケーションサーバーのログオングループを管理するには、次のトランザクションコードを使用します。

SMLG: ログオンユーザーの負荷を分散します。
SM61: バッチサーバーグループを管理します。
RZ12: リモート関数呼び出し (RFC) グループを管理します。

これらのトランザクションは、セントラルサービスメッセージサーバーの負荷分散機能に依存して、SAP GUI と RFC トラフィックを管理する SAP アプリケーションサーバーのプール全体に受信セッションとワークロードを分散します。

SAP セントラルサービスクラスター

SAP セントラルサービスには、メッセージサーバーとエンキューレプリケーションサービスの 1 つのインスタンスが含まれています。アプリケーションサーバーの作業プロセスとは異なり、これらのコンポーネントは SAP アプリケーションスタックの単一障害点です。 Azure 単一インスタンス VM 可用性サービスレベルアグリーメント (SLA) が要件を満たしている場合は、セントラルサービスを 1 つの VM にデプロイできます。 SLA で高可用性が必要な場合は、HA クラスターにこれらのサービスをデプロイする必要があります。詳細については、アプリケーション・サーバー層のセントラル・サービスを参照してください。

ネットワーキング

このアーキテクチャでは、ハブスポークトポロジが使用されます。ハブ仮想ネットワークは、オンプレミスネットワークへの接続の中心点として機能します。スポークは、ハブとピアリングされる仮想ネットワークです。スポークを使用してワークロードを分離できます。トラフィックは、ゲートウェイ接続を経由してオンプレミスのデータセンターとハブの間を流れます。

ネットワークインターフェイスカード

従来のオンプレミス SAP デプロイでは、管理トラフィックをビジネストラフィックから分離するために、コンピューターごとに複数のネットワークインターフェイスカード (NIC) が実装されています。 Azure では、仮想ネットワークは、すべてのトラフィックを単一のネットワークファブリック経由でルーティングするソフトウェア定義ネットワークです。その結果、パフォーマンス上の理由から、複数の NIC は必要ありません。組織でトラフィックを分離する必要がある場合は、VM ごとに複数の NIC をデプロイし、各 NIC を異なるサブネットに接続してから、NSG を使用してさまざまなアクセス制御ポリシーを適用できます。

Azure NIC では、複数の IP アドレスがサポートされています。このサポートは、SAP がノート 962955で推奨するインストール時の仮想ホスト名の使用を実践することと一致しています。

サブネットと NSG

このアーキテクチャでは、仮想ネットワークアドレス空間がサブネットに分割されます。各サブネットを、サブネットのアクセスポリシーを定義する NSG に関連付けることができます。アプリケーションサーバーは別個のサブネットに配置します。この方法では、個々のサーバーではなくサブネットセキュリティポリシーを管理することで、アプリケーションサーバーを簡単にセキュリティで保護できます。

NSG をサブネットに関連付けると、NSG はサブネット内のすべてのサーバーに適用され、サーバーをきめ細かく制御できます。 Azure portal、Azure PowerShell、または Azure CLI を使用して NSG を設定します。

ExpressRoute Global Reach

ネットワーク環境に 2 つ以上の ExpressRoute 回線が含まれている場合、 ExpressRoute Global Reach は、ネットワークホップの削減と待機時間の短縮に役立ちます。このテクノロジは、2 つの ExpressRoute ルーティングドメインをブリッジするために 2 つ以上の ExpressRoute 回線間で設定される Border Gateway Protocol ルートピアリングです。 Global Reach は、ネットワークトラフィックが複数の ExpressRoute 回線を通過するときの待機時間を短縮します。 ExpressRoute 回線でのプライベートピアリングでのみ使用できます。

Global Reach では、ネットワークアクセス制御リストやその他の属性の変更はサポートされていません。 ExpressRoute 回線によって学習されるすべてのルートは、オンプレミスと Azure のどちらからでも、回線ピアリングを介して他の ExpressRoute 回線にアドバタイズされます。リソースへのアクセスを制限するために、オンプレミスでネットワークトラフィックフィルターを設定することをお勧めします。

ファストパス

FastPath は、Azure ネットワークのエントリポイントで Microsoft Edge 交換を実装しています。 FastPath を使用すると、ほとんどのデータパケットのネットワークホップが減少します。その結果、FastPath はネットワーク待ち時間を短縮し、アプリケーションのパフォーマンスを向上させ、Azure への新しい ExpressRoute 接続の既定の構成になります。

既存の ExpressRoute 回線で FastPath をアクティブにするには、Azure サポートにお問い合わせください。

FastPath では、仮想ネットワークピアリングはサポートされていません。 ExpressRoute に接続されている仮想ネットワークが他の仮想ネットワークとピアリングされている場合、オンプレミスネットワークから他のスポーク仮想ネットワークへのトラフィックは、仮想ネットワークゲートウェイを介してルーティングされます。この問題に対処するには、すべての仮想ネットワークを ExpressRoute 回線に直接接続します。

ロードバランサー

SAP Web Dispatcher は、SAP アプリケーションサーバーのプールへの HTTP トラフィックと HTTPS トラフィックの負荷分散を処理します。このソフトウェアロードバランサーは、SSL 終端やその他のオフロード機能が可能な、ISO ネットワークモデルのレイヤー 7 と呼ばれるアプリケーション層サービスを提供します。

Load Balancer は、データストリームからの 5 組のハッシュを使用してトラフィックを負荷分散するネットワーク転送層サービス (レイヤー 4) です。ハッシュは、送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポート、プロトコルの種類に基づいています。クラスターのセットアップで Load Balancer が使用され、プライマリサービスインスタンスまたは正常なノード (障害が発生した場合) にトラフィックを送信します。すべての SAP シナリオで Standard Load Balancer を使用することをお勧めします。 Standard Load Balancer は既定でセキュリティで保護されており、Standard Load Balancer の背後にある VM には送信インターネット接続がありません。 VM でインターネットへの送信を有効にするには、Standard Load Balancer の構成を調整する必要があります。

動的情報アクションゲートウェイ (DIAG) プロトコルまたは RFC を介して SAP サーバーに接続する SAP GUI クライアントからのトラフィックの場合、セントラルサービスメッセージサーバーは、SAP アプリケーションサーバーログオングループを介して負荷を分散します。追加のロードバランサーは必要ありません。

ストレージ

一部のお客様は、アプリケーションサーバーに Standard Storage を使用しています。 Standard マネージドディスクはサポートされていないため、すべてのシナリオで Azure Premium SSD または Azure NetApp Files を使用することをお勧めします。 SAP Note 2015553 の最近の更新では、いくつかの特定のユースケースで Azure Standard HDD ストレージと Azure Standard SSD ストレージの使用が除外されています。

アプリケーションサーバーではビジネスデータがホストされないため、小さいサイズの P4 および P6 Premium ディスクが、コストを管理するうえで役に立つこともあります。 SAP アプリケーションの場合は、Azure SSD v1、SSD v2、または Ultra Disks を使用することを強くお勧めします。ストレージの種類が VM 可用性 SLA にどのように影響するかを理解するには、オンラインサービスの SLA を参照してください。 HA シナリオでは、Azure Premium SSD と Azure Ultra Disk Storage で Azure 共有ディスク機能を使用できます。詳細については、 Azure マネージドディスクと Azure マネージドディスクの種類に関するページを参照してください。

Windows Server、SLES 15 SP1 以降、または SLES for SAP で Azure 共有ディスクを使用できます。 Linux クラスターで Azure 共有ディスクを使用する場合、Azure 共有ディスクは障害が発生したノードブロックデバイスのフェンスとして機能します。クラスターネットワークのパーティション分割シナリオでクォーラム投票が提供されます。この共有ディスクにはファイルシステムがないため、複数のクラスターメンバー VM からの同時書き込みをサポートしていません。

Azure NetApp Files には、NFS と SMB のファイル共有機能が組み込まれています。

NFS 共有シナリオの場合、 Azure NetApp Files は、 /hana/shared、 /hana/data、および /hana/log ボリュームに使用できる NFS 共有の HA を提供します。可用性の保証については、オンラインサービスの SLA を参照してください。 /hana/dataボリュームと/hana/log ボリュームに Azure NetApp Files ベースの NFS 共有を使用する場合は、NFS v4.1 プロトコルを使用する必要があります。 /hana/shared ボリュームでは、NFS v3 プロトコルがサポートされています。

バックアップデータストアでは、Azure のクールおよびアーカイブアクセス層を使用することをお勧めします。これらのストレージ層により、コスト効果の高い方法で、有効期間が長くアクセスの少ないデータを格納できます。また、バックアップターゲットとして Azure NetApp Files Standard レベルを使用するか、 Azure NetApp Files バックアップオプションを使用することを検討してください。マネージドディスクの場合、推奨されるバックアップデータ層は Azure クール層またはアーカイブアクセス層です。

Ultra Disk Storage と Azure NetApp Files Ultra レベルでは、ディスク待機時間が大幅に短縮され、重要なアプリケーションと SAP データベースサーバーのパフォーマンスが向上します。

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

パフォーマンスに関する考慮事項

SAP アプリケーションサーバーは、データベースサーバーと常時通信します。 SAP HANA を含む任意のデータベースプラットフォームで実行されるパフォーマンスが重要なアプリケーションの場合、Premium SSD v1 を使用する場合は、ログボリュームの書き込みアクセラレータを有効にします。この方法では、ログ書き込みの待機時間を短縮できます。 Premium SSD v2 では、書き込みアクセラレータは使用されません。書き込みアクセラレータは、M シリーズの VM で使用できます。

サーバー間の通信を最適化するには、高速ネットワークを使用します。高速ネットワークは、2 つ以上の vCPU を備えた、汎用目的およびコンピューティングに最適化されたインスタンスサイズのほとんどでサポートされています。ハイパースレッディングをサポートするインスタンスでは、4 つ以上の vCPU を持つ VM インスタンスが高速ネットワークをサポートします。

一貫したパフォーマンスを実現するには、ネットワークインターフェイスの Linux TCP/IP スタックとバッファーを最適化する必要があります。 Microsoft の推奨設定に従います。たとえば、次のような項目を調整します。

読み取りと書き込みのメモリバッファーを最適化するためのカーネルパラメーター
ボトルネック帯域幅とラウンドトリップ伝達時間 (BBR) 輻輳制御
TCP パラメーターを調整して一貫性とスループットを向上させる
TX/RX の NIC リングバッファー

SAP HANA のパフォーマンス要件の詳細については、 SAP Note 1943937を参照してください。

1 秒あたりの高い入出力操作 (IOPS) とディスク帯域幅のスループットを実現するには、ストレージボリュームのパフォーマンス最適化に関する一般的なプラクティスに従います。たとえば、複数のディスクを組み合わせてストライプディスクボリュームを作成すると、入出力 (I/O) のパフォーマンスが向上します。変更頻度の低いストレージコンテンツで読み取りキャッシュを有効にすると、データの取得が高速化される可能性もあります。詳細については「SAP HANA Azure 仮想マシンのストレージ構成」を参照してください。

Premium SSD v2 は、SAP などのパフォーマンスクリティカルなワークロード向けに設計されています。その利点、制限事項、最適な使用シナリオの詳細については、 Azure マネージドディスクの種類に関するページを参照してください。

Ultra Disk Storage は、大量の IOPS と、SAP HANA などのアプリケーションの転送帯域幅の要求を満たすための新しい世代のストレージです。 ULTRA ディスクのパフォーマンスを動的に変更し、VM を再起動せずに IOPS や MBps などのメトリックを個別に構成できます。可能な場合は、書き込みアクセラレータの代わりに Ultra Disk Storage を使用することをお勧めします。

一部の SAP アプリケーションでは、データベースと頻繁に通信する必要があります。距離があるため、アプリケーションレイヤーとデータベース層の間のネットワーク待ち時間は、アプリケーションのパフォーマンスに悪影響を与える可能性があります。 Azure 近接通信配置グループは、可用性セットにデプロイされた VM の配置の制約を設定します。グループの論理構造内では、スケーラビリティ、可用性、コストよりもコロケーションとパフォーマンスが優先されます。近接配置グループを使用すると、大半の SAP アプリケーションでユーザーエクスペリエンスを大幅に向上できます。

SAP アプリケーションスタックのアプリケーション層とデータベース層の間に、ネットワーク仮想アプライアンス (NVA) を配置することはサポートされていません。 NVA では、データパケットの処理にかなりの時間が必要です。その結果、許容できないほどアプリケーションのパフォーマンスが低下します。

また、可用性ゾーンを使用してリソースをデプロイする場合は、サービスの可用性を向上させる可能性があるパフォーマンスを考慮することをお勧めします。ターゲットリージョンのすべてのゾーン間に明確なネットワーク待機時間プロファイルを作成することを検討してください。このアプローチは、ゾーン間の最小待機時間のリソースの配置を決定するのに役立ちます。このプロファイルを作成するには、各ゾーンに小規模の VM をデプロイしてテストを実行します。テストに推奨されるツールには PsPing と Iperfがあります。テスト後に、これらの VM を削除します。代わりに使用できるパブリックドメインネットワーク待機時間テストツールについては、「可用性ゾーンの待機時間テスト」を参照してください。

Azure NetApp Files には、最も要求の厳しい SAP 環境のニーズを満たすためにリアルタイムチューニングを可能にする独自のパフォーマンス機能があります。 Azure NetApp Files を使用する場合のパフォーマンスに関する考慮事項については、「 Azure NetApp Files での HANA データベースのサイズ変更」を参照してください。

スケーラビリティに関する考慮事項

SAP アプリケーションレイヤーでは、Azure はスケールアップとスケールアウトのためのさまざまな VM サイズを提供します。包括的な一覧については、「 Azure 上の SAP アプリケーション: SAP Note 1928533でサポートされている製品と Azure VM の種類 」を参照してください。より多くの VM の種類が継続的に認定されるため、同じクラウドデプロイでスケールアップまたはスケールダウンできます。

データベースレイヤーでは、このアーキテクチャは、1 つのインスタンスで最大 24 テラバイト (TB) までスケールアップできる Azure VM 上で SAP S/4HANA アプリケーションを実行します。ワークロードが最大 VM サイズを超える場合は、オンライントランザクション処理アプリケーションに対して最大 96 TB (4 つの 24 TB インスタンス) のマルチノード構成を使用できます。詳細については、「認定済みおよびサポートされている SAP HANA ハードウェアディレクトリ」を参照してください。

可用性に関する考慮事項

リソースの冗長性は、高可用性インフラストラクチャソリューションの一般的なテーマです。さまざまなストレージの種類の単一インスタンス VM 可用性 SLA については、オンラインサービスの SLA を参照してください。 Azure でのサービスの可用性を高めるために、柔軟なオーケストレーション、可用性ゾーン、可用性セットを提供する Azure Virtual Machine Scale Sets を使用して VM リソースをデプロイします。

Azure リージョンの可用性セットデプロイモデルは、サポートされているオプションです。ただし、可用性を強化し、デプロイの柔軟性を高めるために、新しい SAP デプロイに可用性ゾーンモデルを備えた仮想マシンスケールセットを採用することをお勧めします。

この SAP アプリケーションの分散インストールでは、HA を実現するためにベースインストールがレプリケートされます。アーキテクチャのレイヤーごとに、HA の設計は異なります。

デプロイのアプローチ

Azure では、SAP ワークロードのデプロイは、SAP アプリケーションの可用性と回復性の要件に応じて、リージョンまたはゾーンのいずれかにできます。 Azure には、柔軟なオーケストレーション (1 つの障害ドメイン構成)、可用性ゾーン、可用性セットを備えた仮想マシンスケールセットなど、さまざまなデプロイオプションが用意されており、リソースの可用性が向上します。

Azure での顧客のデプロイが長年にわたって拡大するにつれて、Microsoft は、クラウドの弾力性と回復性を確保するために、仮想マシンスケールセットを含むように Azure VM デプロイモデルを強化しました。使用可能なデプロイオプションを考慮して、すべての新しいデプロイに Azure フレキシブルスケールセットゾーンデプロイを使用することを強くお勧めします。ゾーン間、単一ゾーン内、およびゾーンのないリージョンでのデプロイの詳細については、 SAP NetWeaver の HA アーキテクチャとシナリオに関するページを参照してください。

アプリケーションサーバー層の Web Dispatcher

HA は、冗長な Web ディスパッチャーインスタンスを使用して実現できます。詳細については、 SAP Web ディスパッチャーを参照してください。可用性レベルは、Web Dispatcher の背後にあるアプリケーションのサイズによって異なります。スケーラビリティの問題がほとんどない小規模なデプロイでは、Web Dispatcher を ASCS VM と併置できます。このアプローチは、独立したオペレーティングシステムのメンテナンスを節約し、同時に HA を獲得するのに役立ちます。

アプリケーションサーバー層のセントラルサービス

Azure Linux VM 上のセントラルサービスの HA の場合は、選択した Linux ディストリビューションに適切な HA 拡張機能を使用します。 SUSE Distributed Replicated Block Device または Red Hat GlusterFS を使用して、共有ファイルシステムを高可用性 NFS ストレージに配置するのが慣例です。高可用性 NFS を提供し、NFS クラスターの必要性を排除するために、 Azure Files や Azure NetApp Files 経由の NFS などのコスト効率の高い、または堅牢な他のソリューションを使用できます。 Azure NetApp Files 共有では、SAP HANA のデータファイルとログファイルをホストできます。このセットアップにより、スタンバイノードを含む HANA スケールアウトデプロイモデルが有効になりますが、Azure Files 経由の NFS は、高可用性のデータベース以外のファイル共有に適しています。

Azure Files 経由の NFS では、SLES と RHEL の両方の高可用性ファイル共有がサポートされるようになりました。このソリューションは、SAP インストールでの /sapmnt や /saptrans などの高可用性ファイル共有に適しています。

Azure NetApp Files では、 SLES 上の ASCS の HA がサポートされます。 RHEL HA 上の ASCS の詳細については、「 SIOS Protection Suite for Linux」を参照してください。

改善された Azure フェンスエージェントは、SUSE と Red Hat の両方で使用でき、以前のバージョンのエージェントよりもはるかに高速なサービスフェールオーバーを提供します。

もう 1 つのフェンシングオプションは、フェンスデバイスに Azure 共有ディスクを使用することです。 SLES 15 SP1 または SLES for SAP 15 SP1 以降では、 Azure 共有ディスクを使用して Pacemaker クラスターを設定できます。このオプションは単純であり、Azure フェンスエージェントのようなオープンネットワークポートは必要ありません。

SLES 15 以降で最近サポートされ、よりシンプルな Pacemaker 構成は、SAP アプリケーション VM の SLES に単純なマウントと NFS を備えた HA SAP NetWeaver です。この構成では、SAP ファイル共有がクラスター管理から取り出されるため、操作が簡単になります。この HA 構成は、すべての新しいデプロイに使用します。

大規模な SAP ランドスケープのコストをさらに管理するために、Linux クラスターでは Azure への ASCS マルチ SID インストールがサポートされています。複数の SAP システム間で可用性クラスターを共有すると、SAP ランドスケープが簡素化され、運用コストが削減されます。

Standard Load Balancer では、 HA ポートを有効にして、多くの SAP ポートの負荷分散規則を構成する必要を回避できます。一般に、ロードバランサーを設定するときにダイレクトサーバーリターン (DSR) 機能を有効にした場合、クライアントの問い合わせに対するサーバーの応答によってロードバランサーがバイパスされる可能性があります。この機能は、フローティング IP とも呼ばれます。ロードバランサーは、オンプレミスでも Azure でもかまいません。この直接接続により、ロードバランサーがデータ転送のパスでボトルネックになることはありません。 ASCS および HANA データベースクラスターの場合は、DSR を有効にすることをお勧めします。バックエンドプール内の VM でパブリック送信接続が必要な場合は、追加の構成が必要です。

DIAG プロトコルまたは RFC を使用して SAP サーバーに接続している SAP GUI クライアントからのトラフィックについては、セントラルサービスのメッセージサーバーでは、SAP アプリケーションサーバーのログオングループを使用して負荷が分散されます。追加のロードバランサーは必要ありません。

アプリケーションサーバー層のアプリケーションサーバー

アプリケーションサーバーのプール内のトラフィックを負荷分散することで、HA を実現できます。

データベース層

このガイドのアーキテクチャは、2 つの Azure VM で構成される高可用性 SAP HANA データベースシステムを示しています。データベース層のネイティブシステムレプリケーション機能は、レプリケートされたノード間の手動フェールオーバーまたは自動フェールオーバーを提供します。

手動フェールオーバーの場合、複数の HANA インスタンスをデプロイし、HSR を使用します。
自動フェールオーバーの場合は、Linux ディストリビューションに HSR と Linux HA 拡張機能 (HAE) の両方を使用します。 Linux HAE は、HANA リソースのクラスターサービスを提供し、障害イベントを検出し、障害のあるサービスの正常なノードへのフェールオーバーを調整します。

可用性ゾーンをまたいだ VM のデプロイ

Availability Zones によって、サービスの可用性を向上させることができます。ゾーンとは、特定の Azure リージョン内の物理的に分離された場所を指します。ワークロードの可用性を向上させ、アプリケーションサービスと VM をデータセンターの障害から保護します。 1 つのゾーン内の VM は、単一の更新ドメインまたは障害ドメイン内にあるかのように扱われます。ゾーンのデプロイを選択すると、同じゾーン内の VM が、ベストエフォート方式で障害ドメインとアップグレードドメインに分散されます。

この機能をサポートする Azure リージョンでは、少なくとも 3 つのゾーンを使用できます。これらのゾーン内のデータセンター間の最大距離は保証されません。複数層の SAP システムを複数のゾーンにデプロイするには、ゾーン内およびターゲットゾーン間のネットワーク待機時間と、デプロイされたアプリケーションがネットワーク待機時間にどの程度機密性を持っているかを把握する必要があります。

可用性ゾーンをまたいでリソースをデプロイすることに決める場合は、次の考慮事項を考慮に入れる必要があります。

1 つのゾーン内の VM 間の待機時間
選択されたゾーン全体の VM 間の待機時間
選択したゾーンでの同じ Azure サービス (VM の種類) の可用性

注

DR には可用性ゾーンは推奨されません。自然災害を考慮するには、プライマリサイトから少なくとも 100 マイル離れた場所に DR サイトを配置する必要があります。データセンター間の正確な距離を保証することはできません。

アクティブ/パッシブデプロイの例

このデプロイ例では、アクティブ/パッシブステータスは、ゾーン内のアプリケーションサービスの状態を表します。アプリケーション層では、SAP システムの 4 つのアクティブなアプリケーションサーバーすべてがゾーン 1 にあります。 4 つのパッシブなアプリケーションサーバーからなるもう 1 つのセットは、ゾーン 2 に構築されていますが、シャットダウンされています。これらは、必要な場合にのみアクティブ化されます。

セントラルサービスとデータベースの 2 ノードクラスターは、2 つのゾーンにわたって拡張されます。ゾーン 1 で障害が発生すると、セントラルサービスとデータベースサービスがゾーン 2 で実行されます。ゾーン 2 のパッシブなアプリケーションサーバーがアクティブになります。この SAP システムのすべてのコンポーネントが同じゾーンに併置されるため、ネットワーク待ち時間が最小限に抑えられます。

アクティブ/アクティブのデプロイ例

アクティブ/アクティブデプロイでは、2 つのゾーンにまたがって 2 つのアプリケーションサーバーセットが構築されます。各ゾーンでは、各セット内の 2 つのアプリケーションサーバーがアクティブです。その結果、通常の操作では、両方のゾーンにアクティブなアプリケーションサーバーが存在します。

ASCS およびデータベースサービスは、ゾーン 1 で実行されます。ゾーン 2 のアプリケーションサーバーは、ゾーン間の物理的な距離のため、ASCS およびデータベースサービスに接続するときにネットワーク待機時間が長くなる可能性があります。

ゾーン 1 がオフラインになった場合、ASCS およびデータベースサービスはゾーン 2 にフェールオーバーされます。休止中のアプリケーションサーバーをオンラインにすると、アプリケーション処理のための十分な容量を確保することができます。

DR に関する考慮事項

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

注

1 つのリージョン内の多くの Azure 顧客に対して大量フェールオーバーイベントが発生する地域障害が発生した場合、ターゲットリージョンのリソース容量は保証されません。すべての Azure サービスと同様に、Site Recovery は引き続き機能を追加します。 Azure から Azure へのレプリケーションに関する最新情報については、サポートマトリックスをご覧ください。

DR リージョンで使用可能なリソース容量を確保するには、オンデマンド容量予約を使用します。 Azure では、予約インスタンスの割引を容量予約に組み合わせてコストを削減できます。

コストに関する考慮事項

コストの見積もりには、Azure 料金計算ツールをご利用ください。

詳細については、 Azure Well-Architected Framework のコスト最適化に関するページを参照してください。

VM

このアーキテクチャでは、管理層、SAP アプリケーション層、データベース層で Linux が実行されている VM が使用されます。

VM には支払いオプションがいくつかあります。

完了時間やリソース消費量が予測できないワークロードの場合は、従量課金制オプションを検討してください。
1 年間または 3 年間にわたって VM の使用をコミットできる場合は、 Azure の予約の使用を検討してください。 VM の予約により、コストを大幅に削減できます。従量課金制のオプションと比較して、最大 72% を節約できます。
Azure スポット VM を使用して、中断される可能性があり、事前に定義された時間枠または SLA 内で完了を必要としないワークロードを実行します。 Azure によって、利用可能な容量がある場合はスポット VM がデプロイされ、容量を戻す必要がある場合はそれらが無効にされます。スポット VM のコストは、他の VM よりも低くなります。次のワークロードには、スポット VM を検討します。
- ハイパフォーマンスコンピューティングのシナリオ、バッチ処理ジョブ、またはビジュアルなレンダリングアプリケーション
- 継続的インテグレーションと継続的デリバリーワークロードを含むテスト環境
- 大規模なステートレスアプリケーション
Azure Reserved Virtual Machine Instances では、Azure Reserved Virtual Machine Instances 料金と従量課金制サブスクリプションを組み合わせることで、総保有コストを削減できます。これにより、予測可能なワークロードと変動するワークロード全体のコストを管理できます。詳細については、「Azure Reserved Virtual Machine Instances」を参照してください。

価格の概要については、 Linux 仮想マシンの価格に関するページを参照してください。

ロードバランサー (負荷分散装置)

このシナリオでは、Azure ロードバランサーは、アプリケーション層サブネット内の VM にトラフィックを分散させるときに使用されます。

構成された負荷分散およびアウトバウンド規則の数に対してのみ課金されます。受信ネットワークアドレス変換規則は無料です。規則が構成されていない場合、Standard Load Balancer に対する時間あたりの料金は発生しません。

ExpressRoute

このアーキテクチャでは、ExpressRoute は、オンプレミスネットワークと Azure 仮想ネットワークの間にプライベート接続を作成するために使用されるネットワークサービスです。

受信データ転送はすべて無料です。すべての送信データ転送は、所定のレートに基づいて課金されます。詳しくは、「Azure ExpressRoute の価格」を参照してください。

管理と操作に関する考慮事項

運用環境でシステムの動作を維持するために、次の点を考慮してください。

Azure センターのための SAP ソリューション

Azure Center for SAP solutions は、SAP システムを Azure 上の統合ワークロードとして作成して実行できるようにするとともに、イノベーションのためのよりシームレスな基盤を提供する、エンドツーエンドのソリューションです。 Azure Center for SAP ソリューションのガイド付きデプロイエクスペリエンスにより、SAP システムを実行するために必要なコンピューティング、ストレージ、およびネットワークコンポーネントが作成されます。その後、Microsoft のベストプラクティスに従って SAP ソフトウェアのインストールを自動化できます。新しい Azure ベースの SAP システムと既存の SAP システムの両方の管理機能を利用できます。

バックアップ

SAP HANA データは、さまざまな方法でバックアップできます。 Azure に移行した後も、既存のバックアップソリューションを引き続き使用します。 Azure では、2 つのネイティブアプローチでバックアップを行うことができます。 SAP HANA を VM にバックアップし、ファイルレベルで Azure Backup を使用することができます。 Azure Backup は、SAP によって認定された Backint です。詳細については、Azure Backup のよくあるご質問と「Azure VM 上の SAP HANA データベースのバックアップに関するサポートマトリックス」を参照してください。

注

Azure ストレージスナップショットをサポートするのは、HANA の単一コンテナーまたはスケールアップデプロイのみです。

ID 管理

一元化された ID 管理システムを使用して、すべてのレベルでリソースへのアクセスを制御します。

Azure ロールベースのアクセス制御 (RBAC) を使用して Azure リソースへのアクセスを提供します。
ライトウェイトディレクトリアクセスプロトコル、Microsoft Entra ID、Kerberos、またはその他のシステムを使用して、Azure VM へのアクセスを許可します。
SAP が提供するサービスを介してアプリ自体でアクセスをサポートするか、OAuth 2.0 と Microsoft Entra ID を使います。

モニタリング

Azure 上のアプリケーションとサービスの可用性とパフォーマンスを最大化するには、 Azure Monitor を使用します。 Azure Monitor は、クラウドおよびオンプレミス環境からのテレメトリを収集、分析して対応する、包括的なソリューションです。 Azure Monitor では、アプリケーションの実行状況を示し、それらに影響する問題やそれらが依存しているリソースを事前に特定します。 SAP HANA およびその他の主要なデータベースソリューションで実行される SAP アプリケーションについては、Azure Monitor for SAP Solutions に関するページを参照して、Azure Monitor for SAP が SAP サービスの可用性とパフォーマンスの管理にどのように役立つかをご確認ください。

セキュリティに関する考慮事項

SAP には、SAP アプリケーションとデータベース内のロールベースのアクセスと承認を制御する独自のユーザー管理エンジンがあります。詳細については、 SAP HANA のセキュリティの概要を参照してください。

ネットワークセキュリティを改善するには、NVA を使用する境界ネットワークを使用して、Web Dispatcher のサブネットおよび Fiori フロントエンドサーバープールの前面にファイアウォールを作成することをご検討ください。データ転送コストを最小限に抑えるには、S/4 システムと同じ仮想ネットワーク内で Fiori アプリケーションをホストするアクティブなフロントエンドサーバーをデプロイします。または、仮想ネットワークピアリングを利用して S/4 システムとの接続を確立する境界ネットワークでこれらのフロントエンドサーバーを構成することもできます。

インフラストラクチャセキュリティでは、データは転送時および保存時に暗号化されます。 S/4HANA に適用されるネットワークセキュリティの詳細については、「 SAP ランドスケープのセキュリティ」を参照してください。

Linux VM ディスクを暗号化するには、いくつかのオプションがあります。 SAP HANA の保存データ暗号化では、SAP HANA ネイティブ暗号化テクノロジを使用することをお勧めします。特定の Linux ディストリビューション、バージョン、イメージでの Azure ディスク暗号化のサポートについては、 Linux VM の Azure Disk Encryption に関するページを参照してください。

注

同じストレージボリュームで HANA の保存データ暗号化と Azure Disk Encryption を使用しないでください。 HANA の場合は、 Azure ディスクストレージサーバー側の暗号化経由で HANA データ暗号化を使用します。カスタマーマネージドキーを使用すると、I/O スループットに影響する可能性があります。

コミュニティ

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

貢献者

Microsoft では、この記事を保持しています。次の共同作成者がこの記事を書きました。

主要著者:

Ben Trinh | プリンシパルアーキテクト

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

次のステップ

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

Azure 上の Oracle データベースを使用して SAP 運用ワークロードを実行する