Azure 上の Linux での SAP S/4HANA

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

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

アーキテクチャ

Azure 可用性セットの Linux 仮想マシンにおける SAP S/4HANA を示すアーキテクチャの図。

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

注意

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

このガイドでは、共通運用システムについて説明します。 このアーキテクチャは仮想マシン (VM) サイズでデプロイされ、お客様の組織のニーズに合わせて変更できます。 ビジネス ニーズに合わせて、この構成を 1 つの VM に減らすことができます。

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

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

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

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

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

  • アプリケーション層。 このアーキテクチャ層には、Fiori Front-end Server プール、SAP Web Dispatcher プール、アプリケーション サーバー プール、および SAP セントラル サービス クラスターが含まれます。 Linux VM で実行されている Azure のセントラル サービスの高可用性を実現するには、Azure Files の NFS ファイル共有Azure NetApp Files、クラスター化されたネットワーク ファイル システム (NFS) サーバー、Linux 用 SIOS Protection Suite などの高可用性ネットワーク ファイル共有サービスが必要です。 Red Hat Enterprise Linux (RHEL) のセントラル サービス クラスター用に高可用性ファイル共有を設定するには、RHEL を実行する Azure VM で GlusterFS を構成できます。 SUSE Linux Enterprise Server (SLES) 15 SP1 以降のバージョンまたは SLES for SAP Applications の場合、Pacemaker クラスターで Azure 共有ディスクを使用して、高可用性を実現できます。

  • SAP HANA。 データベース層では、スケールアップ配置で高可用性を実現するために、クラスターで複数の Linux VM が使用されます。 HANA システム レプリケーション (HSR) を使用して、プライマリ HANA システムとセカンダリ HANA システムの間でコンテンツがレプリケートされます。 システム障害の検出と自動フェールオーバーの促進には Linux クラスタリングが使用されます。 また、ストレージ ベースまたはクラウド ベースのフェンス メカニズムを採用し、障害が発生したシステムを確実に分離またはシャットダウンし、クラスターのスプリット ブレイン状態を回避する必要があります。 HANA スケールアウト デプロイでは、次のいずれかのオプションを使用してデータベースの高可用性を実現できます。

    • Linux クラスタリング コンポーネントを使用せずに Azure NetApp Files を使用して HANA スタンバイ ノードを構成します。
    • Azure Premium Storage を使用して、スタンバイ ノードなしでスケールアウトします。 フェールオーバーには Linux クラスタリングを使用します。
  • Azure Bastion。このサービスは、ブラウザーと Azure portal を使って、またはローカル コンピューターに既にインストールされているネイティブ SSH か RDP クライアントを介して仮想マシンに接続できるようにするものです。 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 ベースのアプリケーションの高可用性を実現するには、組み込みの SAP Web ディスパッチャまたは他の購入可能なロード バランサーを使用します。 次の基準に基づいて選択します。

  • HTTP や SAP GUI などのトラフィックの種類。
  • 必要なネットワーク サービス (Secure Sockets Layer (SSL) ターミネーションなど)。

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

  • Advanced Business Application Programming (ABAP) SAP Central Service (ASCS)
  • エンキュー レプリケーション サーバー (ERS)

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

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

アプリケーション ゲートウェイ。 Azure Application Gateway は、Web アプリケーションへのトラフィック管理に使用できる Web トラフィック ロード バランサーです。 従来のロード バランサーは、トランスポート層 (OSI レイヤー 4 - TCP と UDP) で動作します。 トラフィックは送信元 IP アドレスとポートに基づいて送信先 IP アドレスとポートにルーティングされます。 Application Gateway によるルーティングの決定は、URI パス、ホスト ヘッダーのような HTTP 要求の追加属性に基づいて行うことができます。 この種類のルーティングは、アプリケーション レイヤー (OSI レイヤー 7) の負荷分散と呼ばれます。 S/4HANA では、Fiori を通じて Web アプリケーション サービスを提供しています。 この Fiori フロント エンドは、Web アプリで構成され、Application Gateway を使用して負荷分散できます。

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

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

近接通信配置グループ。 この論理グループでは、可用性セットまたは仮想マシン スケール セットにデプロイされた VM に制約が設けられます。 近接配置グループではコロケーションが優先されます。これにより、VM は同じデータセンターに配置されるので、アプリケーションの待機時間を最小限に抑えることができます。

注意

SAP アプリケーションを使用した最適なネットワーク待機時間の構成オプション」の記事には、最新の構成戦略が含まれています。 特に、最適なネットワーク待機時間がある SAP システムをデプロイする場合は、この記事をお読みください。

ネットワーク セキュリティ グループ。 仮想ネットワークの受信トラフィック、送信トラフィック、およびサブネット間トラフィックを制限するために、ネットワーク セキュリティ グループを作成できます。

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

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

推奨事項

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

VM

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

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

SAP Web Dispatcher

Web Dispatcher コンポーネントは、SAP アプリケーション サーバー間の SAP トラフィックの負荷分散に使用されます。 SAP Web Dispatcher の高可用性を実現するには、Azure Load Balancer でフェールオーバー クラスターまたは並列 Web Dispatcher セットアップを実装します。 インターネット接続による通信の場合、セキュリティ上の懸念に対応するために、境界ネットワークのスタンドアロン ソリューションが推奨アーキテクチャです。 ASCS の Embedded Web Dispatcher は特別なオプションです。 このオプションを使用する場合は、ASCS で余分なワークロードが発生するため、適切なサイズ設定を検討してください。

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

このアーキテクチャは、多くの基本要件に対応しており、埋め込みの Fiori FES モデルが使用されていることを前提としています。 すべてのテクノロジ コンポーネントは S/4 システム自体にインストールされています。つまり、各 S/4 システムには、独自の Fiori Launchpad があります。 このデプロイ モデルの高可用性のセットアップは、S/4 システム用のものです。追加のクラスタリングや VM は必要ありません。 そのため、アーキテクチャ図には FES コンポーネントは表示されません。

シナリオに応じた、埋め込みまたはハブの主要なデプロイ オプションの説明については、「SAP Fiori Deployment Options and System Landscape Recommendations (SAP Fiori のデプロイ オプションとシステム ランドスケープの推奨事項)」を参照してください。 簡素化とパフォーマンスのために、Fiori テクノロジ コンポーネントと S/4 アプリケーション間のソフトウェア リリースは密結合されています。 このセットアップにより、ハブのデプロイ フィッティングは少数の限られたユース ケースに対してのみ適用されます。

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

2 つの仮想ネットワーク (一方が SAP Fiori、もう一方が SAP S/4HANA) とインターネット間のデータ フローを示すアーキテクチャの図。

インターネットに接続する受信/送信の設計例については、SAP on Azure の受信および送信インターネット接続を参照してください。

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

ABAP アプリケーション サーバーのログオン グループを管理するには、一般に、ログオン ユーザーの負荷分散に SMLG トランザクションを使用し、バッチ サーバー グループに SM61 を使用し、リモート関数呼び出し (RFC) グループに RZ12 を使用するなどをします。 これらのトランザクションでは、セントラル サービス メッセージ サーバー内の負荷分散機能を使って、SAP GUI および RFC トラフィックを処理する SAP アプリケーション サーバー プール間で受信セッションまたはワークロードを分散させます。

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

Azure 単一インスタンス VM 可用性サービス レベル アグリーメント (SLA) が要件を満たしている場合は、セントラル サービスを 1 つの VM にデプロイできます。 ただし、VM は、SAP 環境の単一障害点 (SPOF) になる可能性があります。 高可用性のセントラル サービスのデプロイでは、Azure Files 経由の NFS または Azure NetApp Files サービスとセントラル サービス クラスターのいずれかを使用します。

もう 1 つの方法は、Azure 共有ディスクを使用して高可用性を実現することです。 SLES 15 SP1 または SLES for SAP Applications の場合、Linux 用 Azure 共有ディスクを使用することにより、Pacemaker クラスターをセットアップできます。

または、Linux クラスターの共有ストレージに NFS ファイル共有を使用することもできます。

Azure デプロイでは、アプリケーション サーバーは、セントラル サービスまたは ERS サービスの仮想ホスト名を使用して高可用性のセントラル サービスに接続します。 これらのホスト名は、ロード バランサーのクラスター フロントエンド IP 構成に割り当てられます。 Load Balancer は複数のフロントエンド IP をサポートしているので、セントラル サービスと ERS 仮想 IP (VIP) の両方を 1 つのロード バランサーに構成できます。

Azure での ASCS マルチ SID のインストールの Linux クラスター サポートの一般提供が開始されました。 複数の SAP システム間で可用性クラスターを共有すると、SAP ランドスケープが簡素化されます。

ネットワーク

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

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

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

Azure NIC は、複数の IP をサポートしています。 これは、SAP note 962955 で説明されているように、インストールで仮想ホスト名を使用する SAP 推奨プラクティスと一致します。SAP note にアクセスするには、SAP Service Marketplace アカウントが必要です。

サブネットとネットワーク セキュリティ グループ

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

ネットワーク セキュリティ グループをサブネットに関連付けている場合、ネットワーク セキュリティ グループはそのサブネット内のすべてのサーバーに適用され、それらのサーバーに対するきめ細かな制御を提供します。 ネットワーク セキュリティ グループは、Azure portalPowerShell、または 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 は、Azure ネットワークのエントリ ポイントで Microsoft Edge 交換を実装しています。 FastPath を使用すると、ほとんどのデータ パケットのネットワーク ホップが減少します。 その結果、FastPath はネットワーク待機時間を短縮し、アプリケーションのパフォーマンスを向上させます。これは、Azure への新しい ExpressRoute 接続の既定の構成です。

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

FastPath では、仮想ネットワーク ピアリングはサポートされていません。 他の仮想ネットワークが、ExpressRoute に接続されているものとピアリングされている場合、ユーザーのオンプレミス ネットワークから他のスポーク仮想ネットワークに向かうネットワーク トラフィックは、仮想ネットワーク ゲートウェイに送信されます。 回避策として、すべての仮想ネットワークを ExpressRoute 回線に直接接続します。

ロード バランサー

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

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

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

ストレージ

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

アプリケーション サーバーではビジネス データがホストされないため、小さいサイズの P4 および P6 Premium ディスクが、コストを管理するうえで役に立つこともあります。 ストレージの種類が VM の可用性 SLA にどのように影響するかを理解するには、「Virtual Machines の SLA」を参照してください。 高可用性シナリオでは、Azure 共有ディスクの機能は Azure Premium SSD と Azure Ultra Disk Storage で利用できます。 詳細については、Azure Managed Disks に関する記事をご覧ください。

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

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

NFS 共有シナリオでは、Azure NetApp Files/hana/shared/hana/data/hana/log ボリュームに使用できるネイティブ NFS 共有が用意されています。 可用性の保証については、「Azure NetApp Files の SLA」をご覧ください。 ボリュームに Azure NetApp Files ベースの NFS 共有を /hana/data/hana/log に使用する場合は、NFS v4.1 プロトコルを使用する必要があります。 /hana/shared ボリュームでは、NFS v3 プロトコルがサポートされています。

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

Ultra Disk Storage と Azure NetApp Files の Ultra パフォーマンス レベルはいずれもディスク待機時間を大幅に削減し、パフォーマンスが重要なアプリケーションと SAP データベース サーバーにとって有益です。

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

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

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

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

SAP HANA のパフォーマンス要件の詳細については、SAP ノート 1943937 の Hardware Configuration Check Tool (ハードウェア構成チェック ツール) をご覧ください。 SAP Note にアクセスするには、SAP Service Marketplace アカウントが必要です。

高い IOPS とディスク帯域幅のスループットを達成するために、ストレージ ボリュームのパフォーマンス最適化の共通プラクティスが、Storage レイアウトに適用されます。 たとえば、複数のディスクを結合してストライピングされたディスク ボリュームを作成すると、I/O パフォーマンスを向上できます。 変更が頻繁に行われないストレージ コンテンツの読み取りキャッシュを有効にすると、データ取得の速度を向上させられます。 SAP HANA を実行するときのさまざまな VM サイズのストレージ構成に関する推奨事項については、「SAP HANA Azure 仮想マシンのストレージ構成」を参照してください。

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

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

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

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

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

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

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

SAP アプリケーション レイヤーについては、Azure では、スケールアップおよびスケールアウトのための幅広い VM サイズが用意されています。詳細な一覧については、SAP Note 1928533 の「SAP Applications on Azure: Supported Products and Azure VM Types (Azure 上の SAP アプリケーション: サポートされる製品と Azure VM の種類)」を参照してください。 SAP Note にアクセスするには、SAP Service Marketplace アカウントが必要です。 より多くの VM の種類が継続的に認定されているため、同じクラウド デプロイでスケールアップまたはスケールダウンできます。

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

可用性に関する考慮事項

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

このように SAP アプリケーションを分散してインストールした場合、高可用性を実現するために基本のインストールがレプリケートされます。 高可用性の設計は、アーキテクチャのレイヤーごとに異なります。

デプロイのアプローチ

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

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

冗長 Web Dispatcher インスタンスを使用して高可用性を実現できます。 詳細については、SAP ドキュメントの SAP Web ディスパッチャを参照してください。 可用性レベルは、Web Dispatcher の背後にあるアプリケーションのサイズによって異なります。 スケーラビリティに関する懸念がほとんどない小規模なデプロイでは、WEB Dispatcher と ASCS VM を併配置できます。 これにより、独立した OS メンテナンスを節約し、同時に高可用性を実現できます。

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

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

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

Azure NetApp Files は、SLES で ASCS の高可用性をサポートします。 RHEL の高可用性に関する ASCS の詳細については、「SIOS Protection Suite for Linux」を参照してください。

強化された Azure フェンス エージェントは、SUSERed Hat の両方で利用でき、以前のバージョンのエージェントと比較して、サービスのフェールオーバーが大幅に高速化されます。

もう 1 つの方法は、Azure 共有ディスクを使用して高可用性を実現することです。 SLES 15 SP 1 以降または SLES for SAP では、Azure 共有ディスクを使用して Pacemaker クラスターを設定して高可用性を実現できます。

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

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

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

高可用性は、アプリケーション サーバーのプール内の負荷分散トラフィックによって実現できます。

ASCS のレベル

アプリケーション サーバー層と同様に、Linux 用に一般的にデプロイされる HANA 高可用性ソリューションは Pacemaker です。

データベース層

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

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

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

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

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

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

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

注意

ディザスター リカバリーには可用性ゾーンは推奨されません。 ディザスター リカバリー サイトは、自然災害が発生した場合にプライマリ サイトから少なくとも 100 マイル離れた場所に配置する必要があります。 データセンター間の距離には確実性がありません。

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

このデプロイ例では、アクティブ/パッシブ ステータスは、ゾーン内のアプリケーション サービスの状態を表します。 アプリケーション層では、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 ワークロードのディザスター リカバリーの概要とインフラストラクチャのガイドライン」および「SAP アプリケーションに関するディザスター リカバリーのガイドライン」を参照してください。

注意

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

コストに関する考慮事項

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

詳細については、「Microsoft Azure Well-Architected Framework」のコストのセクションを参照してください。

VM

このアーキテクチャでは、管理層、SAP アプリケーション層、データベース層で Linux が実行されている 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 に関するページを参照してください。

価格の概要については、「Linux Virtual Machines の料金」を参照してください。

Load Balancer

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

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

ExpressRoute

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

受信データ転送はすべて無料です。 送信データ転送はすべて、事前に決められた料金に基づいて課金されます。 詳細については、「Azure ExpressRoute の価格」をご覧ください。

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

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

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 に関するページを参照してください。

Backup

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 のロールベースのアクセス制御 (Azure RBAC) を使用して、Azure リソースへのアクセスを提供します。

  • ライトウェイト ディレクトリ アクセス プロトコル (LDAP)、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 HANA Security - An Overview (SAP HANA セキュリティ - 概要)」をご覧ください。

ネットワーク セキュリティを改善するには、NVA を使用する境界ネットワークを使用して、Web Dispatcher のサブネットおよび Fiori フロントエンド サーバー プールの前面にファイアウォールを作成することをご検討ください。 Fiori アプリを実行するアクティブなフロントエンド サーバーを S/4 システムと同じ仮想ネットワークに配置するのは、データ転送のコストが理由です。 別の方法として、境界ネットワークに配置し、仮想ネットワーク ピアリングを介して S/4 に接続することもできます。

インフラストラクチャ セキュリティでは、データは転送時および保存時に暗号化されます。 Azure Virtual Machines 上の SAP NetWeaver の計画と実装に関するガイドの「セキュリティに関する考慮事項」セクションには、S/4HANA に適用されるネットワーク セキュリティの情報が含まれています。 また、このガイドでは、アプリケーション通信を許可するために、ファイアウォールで開くネットワーク ポートも指定しています。

Linux VM のディスクを暗号化するには、ディスク暗号化の概要で説明されているように、さまざまな選択肢があります。 保存されている SAP HANA データの暗号化には、SAP HANA のネイティブ暗号化テクノロジを使用することをお勧めします。 特定の Linux ディストリビューション、バージョン、イメージでの Azure Disk Encryption のサポートについては、「Linux VM に対する Azure Disk Encryption」を参照してください。

保存されている SAP HANA データの暗号化には、SAP HANA のネイティブ暗号化テクノロジを使用することをお勧めします。

注意

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

コミュニティ

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

共同作成者

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

プリンシパル作成者:

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

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次の手順

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