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 アプリケーションにのみ適用されます。

アーキテクチャ

このアーキテクチャの 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 を使います。

インターネットに接続する受信/送信の設計例については、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 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 は、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 をデプロイしてテストを実行します。テストに推奨されるツールには PsPing と Iperfがあります。テスト後に、これらの 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 では、SLES と RHEL の両方の高可用性ファイル共有がサポートされるようになりました。このソリューションは、SAP インストールにおける /sapmnt や /saptrans のような高可用性ファイル共有に適しています。

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

強化された Azure フェンスエージェントは、SUSE と Red 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 にパブリック送信接続が必要な場合は、追加の構成が必要になります。

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

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

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 ワークロードの詳細と例については、次の記事を参照してください。

Azure での Oracle Database を使用した SAP 運用環境ワークロードの実行

次の方法で共有