編集

Azure における Linux 仮想マシンでの SAP BW/4HANA の実行

Azure Bastion
Azure Managed Disks
Azure Virtual Machines
Azure Virtual Network
SAP HANA on Azure Large Instances

次の例では、特に SAP BW/4HANA アプリケーション層に焦点を当てています。 高可用性が優先される SAP BW/4HANA on Azure の小規模な運用環境に適しています。

アーキテクチャ

リファレンス アーキテクチャには、Azure でディザスター リカバリーをサポートする、可用性の高いスケールアップ環境で SAP HANA を実行するための一連の実証済みプラクティスが示されます。

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

コンポーネント

このアーキテクチャでは、次のテクノロジを利用します。

  • Azure Virtual Network (VNet) により、Azure リソースが相互およびオンプレミス環境に安全に接続されます。 このアーキテクチャでは、複数の VNet がピアリングされています。

  • Linux 仮想マシンは、次のようなアプリケーション層に使用されます。

    • SAP BusinessObjects (BOBJ) サーバー プール。
    • SAP Web Dispatcher プール。
    • アプリケーション サーバー プール。
    • SAP セントラル サービス クラスター。

  • ロード バランサーは、アプリケーション サブネット内の仮想マシンにトラフィックを転送します。 高可用性を実現するために、この例では SAP Webディスパッチャと Azure Standard Load Balancer を使用しています。 この 2 つのサービスでは、スケールアウトによる容量拡張もサポートされています。また、トラフィックの種類と必要な機能 (Secure Sockets Layer (SSL) 終了や SSL 転送など) に応じて、Azure Application Gateway や他のパートナー製品を使用できます。

  • ネットワーク セキュリティ グループ (NSG) は、仮想マシン上のサブネットまたはネットワーク インターフェイス カード (NIC) にアタッチされます。 NSG は、仮想ネットワークで受信トラフィック、送信トラフィック、およびサブネット間トラフィックを制限するために使用されます。

  • Azure Bastion は、ジャンプボックスとそれに関連付けられているパブリック IP アドレスを使用せずに、Azure portal から Azure で実行される仮想マシンへのセキュリティで保護されたアクセスを提供します。 このメカニズムによって、インターネットに接続されている露出が制限されます。

  • Azure Managed Disks。 Premium または Ultra ストレージ ディスクが推奨されます。 これらの種類のストレージにより、SAP ワークロードを使用する仮想マシンのデータを永続化できます。

  • クラスターを使用する場合、Azure NetApp Files は共有記憶域をサポートします。 また、SAP HANA のデータとログ ファイルをホストできる高パフォーマンスの記憶域が必要な場合は、共有記憶域もサポートします。 Azure NetApp Files はフル マネージドであり、ほとんどのアプリケーションの要求を十分に満たすことができるスケーラビリティを備えています。 次の複雑なエンタープライズ ワークロードに対して、ベアメタルのパフォーマンス、ミリ秒未満の待機時間、統合データ管理を実現します。

    • SAP HANA。
    • ハイ パフォーマンス コンピューティング。
    • LOB アプリケーション。
    • 高パフォーマンスのファイル共有。
    • 仮想デスクトップ インフラストラクチャ。

  • Power BI を使用すると、ユーザーは Windows デスクトップから SAP BW/4HANA データにアクセスし、データを視覚化できます。 インストールには SAP BW Connector (Implementation 2.0) が必要です。

    Microsoft Power BI Desktop は、分析と視覚化のために、SAP BW/4HANA などのさまざまな SAP ソースからデータをインポートします。 また、Power BI は、生の情報に対してビジネス コンテキストまたはセマンティクス レイヤーを提供することによって、SAP BusinessObjects Universe を補完します。

  • Azure Backup は、単一インスタンスおよびスケールアップ デプロイの SAP HANA 用の SAP Backint 認定データ保護ソリューションです。 Azure Backup は、一般的なワークロードを使用する Azure Virtual Machines も保護します。

  • Azure Site Recovery は、多層 SAP NetWeaver アプリケーション デプロイの自動ディザスター リカバリー ソリューションの一部として推奨されます。 このソリューションの機能と制限事項の詳細については、サポート マトリックスをご覧ください。

代替

  • SAP セントラル サービスの SAP グローバル ホスト ファイルと SAP トランスポート ディレクトリを保護するために、フェールオーバー クラスター構成でネットワーク ファイル システム (NFS) サーバーをデプロイできます。

  • NFS または Azure NetApp Files の代わりに、Azure Marketplace で入手できる SIOS Protection Suite を使用して、セントラル サービスのグローバル ホスト ファイルを保護できます。

  • Azure Application Gateway は、Web トラフィック ロード バランサーです。 1 つのサービスで SSL 終端、Azure Web Application Firewall (WAF) サービス、およびその他の便利な高可用性とスケーラビリティの機能を提供します。 一部の SAP デプロイでは、運用ランドスケープで SAP Fiori フロントエンドのゲートウェイとして使用しています。

シナリオの詳細

SAP BW/4HANA は、クラウド向けに設計され、SAP HANA プラットフォームに最適化されたエンタープライズ データ ウェアハウス ソリューションです。 次の例では、特に SAP BW/4HANA アプリケーション層に焦点を当てています。 高可用性が優先される SAP BW/4HANA on Azure の小規模な運用環境に適しています。

このサンプル ワークロードでは、仮想マシン上の AnyDB 向け SAP NetWeaver (Windows) および Azure の Linux 仮想マシン向け SAP S/4HANA の一組の SAP on Azure リファレンス アーキテクチャの基礎も利用しています。 同様のデプロイ方法が SAP BW/4HANA ワークロードに使用されます。 アプリケーション層は、組織のニーズに合わせてサイズを変更できる仮想マシンを使用してデプロイされます。

ネットワーク レイアウトは、ハブスポーク トポロジに基づく Azure エンタープライズ デプロイの推奨されるアーキテクチャ原則を示すために簡素化されています。

注意

SAP ワークロードを Azure にデプロイするときは、デプロイに関する多くの考慮事項が適用されます。 その他のアイデアや詳細については、SAP on Azure の計画とデプロイのチェックリストに関する記事をご覧ください。

データ永続化レイヤーの詳細については、次の記事をご覧ください。

考えられるユース ケース

このシナリオは、次のユース ケースに関連があります。

  • DBMS 層から分離した SAP アプリケーション層のデプロイ

  • ディザスター リカバリー (DR) のシナリオ

  • SAP アプリケーション層のデプロイ

推奨事項

このアーキテクチャは、高可用性、スケーラビリティ、回復性を実現するように設計されています。 Azure で最良の結果を得るために、このセクションの推奨事項を検討してください。 また、SAP S/4HANA on Azure の実行に関する推奨事項の多くは、SAP BW/4HANA デプロイにも適用されます。 SAP S/4HANA on Azure の詳細については、リファレンス アーキテクチャを参照してください。

仮想マシン

Azure 仮想マシンの種類とスループットのメトリック (SAPS) に対する SAP サポートの詳細については、SAP ノート 1928533 の「SAP Applications on Azure: Supported Products and Azure Virtual Machine Types (Azure 上の SAP アプリケーション: サポート対象の製品と Azure 仮想マシンの種類)」を参照してください (これと、その他の SAP ノートにアクセスするには、SAP Service Marketplace アカウントが必要です)。

SAP HANA のスケールアウト デプロイで仮想マシンの種類が認定されているかどうかについては、SAP HANA ハードウェア ディレクトリの "Scale-out (スケールアウト)" 列をご覧ください。

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

アプリケーション サーバー プールでは、要件に基づいて仮想マシンの数を調整できます。 Azure は、Red Hat Enterprise Linux および SUSE Linux Enterprise 上で SAP BW/4HANA を実行するための認定を受けています。

ABAP アプリケーション サーバーのログオン グループを管理するには、SMLG トランザクションを使用して、次のような異なるグループを負荷分散するのが一般的です。

  • ログオン ユーザー。
  • バッチ サーバー グループの SM61。
  • RFC グループの RZ12。

これらのトランザクションでは、セントラル サービスのメッセージ サーバー内の負荷分散機能を使用して、SAP GUI および RFC トラフィック用の SAP アプリケーション サーバー プールに受信セッションまたはワークロードを分散させます。

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

この例は、共有ファイル ストレージ ソリューションとして Azure NetApp Files を使用する高可用性クラスターを示しています。 セントラル サービス クラスターの高可用性には、共有記憶域が必要です。 Azure NetApp Files は、Linux クラスター インフラストラクチャをデプロイしなくて済むようにシンプルな高可用性オプションを提供します。 別の方法として、高可用性 NFS サービスを設定します。

Premium マネージド ディスクを使用する単一の仮想マシンにセントラル サービスをデプロイし、99.9% の可用性 SLA を実現することもできます。

アプリケーション サーバーに使用される仮想マシンでは、NIC ごとに複数の IP アドレスをサポートします。 この機能では、SAP ノート 962955 に記載されている、インストールに仮想ホスト名を使用するという SAP 推奨プラクティスがサポートされています。 仮想ホスト名は、SAP サービスを物理ホスト名から切り離し、物理ホスト間でサービスを簡単に移行できるようにします。 この原則は、クラウド仮想マシンにも適用されます。

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

マルチ SID インストール

Azure では、セントラル サービス (ASCS/SCS) をホストする Linux および Windows クラスターのマルチ SID インストールでの高可用性もサポートしています。 Pacemaker クラスターへのデプロイの詳細については、Azure マルチ SID のドキュメントをご覧ください。

近接通信配置グループ

このアーキテクチャ例では、仮想マシン間のネットワーク待機時間を短縮するために、近接配置グループも使用しています。 この種類のグループは、仮想マシンのデプロイに場所の制約を課し、それらの間の物理的な距離を最小限に抑えます。 グループの配置は次のように異なります。

  • 単一 SID インストールでは、SAP HANA データベースによってアンカーが設定された近接配置グループに、すべてのセントラル サービスとアプリケーション サーバーを配置する必要があります。

  • マルチ SID インストールでは、さまざまな SID の SAP HANA コンテナーによってアンカーが設定された任意の単一の近接配置グループに、セントラル サービスとアプリケーション サーバーを自由に関連付けることができます。

データベース

SAP BW/4HANA は、SAP HANA データベース プラットフォーム向けに設計されています。 Azure には、スケーラビリティとデプロイの 3 つのオプションがあります。

ストレージ

この例では、Premium マネージド ディスクをアプリケーション サーバーの非共有ストレージに使用します。 また、クラスター共有ストレージに Azure NetApp Files を使用します。

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

Ultra Disk Storage を使用すると、ディスクの待機時間が大幅に短縮されます。 そのため、SAP データベース サーバーなどのパフォーマンスが重要なアプリケーションにとって有益です。 Azure のブロック ストレージ オプションを比較するには、「Azure マネージド ディスクの種類」を参照してください。

SAP ノート 1928533 に記載されているように、Standard マネージド ディスクはサポートされていません。 Standard ストレージの使用は、どの SAP インストールでも推奨されません。

バックアップ データ ストアでは、Azure のクールおよびアーカイブ アクセス層を使用することをお勧めします。 これらのストレージ層により、コスト効果の高い方法で、有効期間が長くアクセスの少ないデータを格納できます。

ネットワーク

必須ではありませんが、SAP ランドスケープを論理的に分離し、セキュリティ境界を提供するために、通常、ハブスポーク トポロジがデプロイされます。 ネットワークのその他の詳細については、SAP S/4HANA リファレンス アーキテクチャを参照してください。

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

ほとんどの顧客実装には、オンプレミス ネットワークを Azure に接続する 1 つ以上の ExpressRoute 回路が含まれています。 ネットワーク帯域幅の要求が少ない場合は、VPN が低コストの代替手段となります。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

パフォーマンス効率

パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。

SAP BW/4HANA は、リアルタイムのデータ ウェアハウス タスク用に設計されています。 SAP アプリケーション サーバーはデータベース サーバーと常に通信しているため、アプリケーション仮想マシンからデータベースへの待機時間を最小限に抑えることで、アプリケーションのパフォーマンスを向上させることができます。 ディスク キャッシュとサーバー配置は、この 2 つのコンポーネント間の待機時間を短縮するのに役立つ 2 つの戦略です。

SAP HANA など、任意のデータベース プラットフォーム上で実行されているパフォーマンスが重要なアプリケーションでは、Premium マネージド ディスクを使用し、ログ ボリュームの書き込みアクセラレータを有効にします。 書き込みアクセラレータは、M シリーズ仮想マシンで使用でき、書き込み待機時間を短縮します。 ただし、使用可能な場合は、書き込みアクセラレータなしで、Premium ディスクの代わりに Ultra マネージド ディスクを使用してください。 Ultra Disk の機能は進化を続けています。 これらのディスクが要件を満たしていることを確認するには、Ultra Disk のサービス スコープに関する最新情報を確認してください。 特に、可用性セット、Azure Availability Zones、リージョン間レプリケーションなどの Azure 回復性機能が実装に含まれている場合に確認してください。

アプリケーションとデータベース間の物理的な距離を短くしてパフォーマンスを向上させるには、前述の近接配置グループを使用します。 スクリプトとユーティリティは GitHub で入手できます。

サーバー間の通信を最適化するには、高速ネットワークを使用します。これは、サポートされている仮想マシン (D/DSv2、D/DSv3、E/ESv3、F/FS、FSv2、Ms/Mms など) で利用できます。 特に、Azure NetApp Files を使用する場合は、すべての SAP 実装で高速ネットワークが必要です。

高い IOPS とディスク帯域幅のスループットを達成するために、ストレージ ボリュームのパフォーマンス最適化の一般的なプラクティスが、Azure Storage レイアウトに適用されます。 たとえば、ストライピングされたディスク ボリュームを作成するために複数のディスクを結合すると、IO パフォーマンスが向上します。 変更が頻繁に行われないストレージ コンテンツの読み取りキャッシュを有効にすると、データ取得の速度が向上します。

スケーラビリティ

このアーキテクチャ例は、要件に基づいてスケーリングできる柔軟性を備えた小規模な運用レベルのデプロイを示しています。

SAP アプリケーション レイヤーでは、Azure は、スケールアップおよびスケールアウトのための幅広い仮想マシン サイズを提供しています。包括的な一連については、SAP ノート 1928533 をご覧ください。 認定済み仮想マシンの種類が引き続き増えていくことで、ユーザーは同じクラウド デプロイでスケールアップまたはスケールダウンできます。

可用性

リソースの冗長性は、高可用性インフラストラクチャ ソリューションの一般的なテーマです。 組織の SLA がそれほど厳しくない場合は、アップタイム SLA を提供する Premium ディスクを使用した単一インスタンスの仮想マシンを使用します。

アプリケーションの可用性を最大限に高めるには、可用性セットまたは Availability Zones に冗長リソースをデプロイします。 詳細については、SAP S/4HANA リファレンス アーキテクチャを参照してください。

このアーキテクチャでは、同じロールを実行する仮想マシンを可用性セットに配置しています。 この構成を使用すると、Azure インフラストラクチャのメンテナンスや計画外の停止によるダウンタイムを防ぐことによって、SLA を満たすことができます。 さらに高い SLA を実現するには、可用性セットごとに 2 つ以上の仮想マシンが必要です。

Azure Load Balancer

Azure Load Balancer は、ネットワーク転送レイヤー サービス (レイヤー 4) です。 クラスターの構成では、Azure Load Balancer により、プライマリ サービス インスタンスまたは正常なノード (障害が発生した場合) にトラフィックが送信されます。 すべての SAP シナリオで Azure Standard Load Balancer を使用することをお勧めします。 これは、パブリック エンドポイントへの送信接続を有効にしない限り、設計上のセキュリティ実装を提供し、バック エンド プールからの送信トラフィックをブロックします。 また、Azure NAT Gateway を使用して送信接続を取得することもできます。

また、SAP ワークロードを Azure Availability Zones にデプロイする場合、Standard Load Balancer はゾーンを認識します。

Web ディスパッチャ

このサンプル設計では、SAP アプリケーション サーバー間の SAP トラフィックの HTTP(s) 負荷分散メカニズムとしての SAP Web Dispatcher を使用しています。 Web Dispatcher コンポーネントの高可用性は、Azure Load Balancer でフェールオーバー クラスターまたは並列 Web Dispatcher セットアップを実装することで実現します。 SAP ドキュメントの「SAP Web Dispatcher」を参照してください。

Web Dispatcher は、ソフトウェア ロード バランサーとして、SSL 終端や他のオフロード機能を実行できる追加のレイヤー サービスを提供します。 これらのレイヤー サービスは、ISO ネットワーク モデルではレイヤー 7 と呼ばれます。

DIAG プロトコルまたはリモート関数呼び出し (RFC) を介して SAP サーバーを接続する SAP GUI クライアントからのトラフィックには、他のロード バランサーは必要ありません。 セントラル サービス メッセージ サーバーは、SAP アプリケーション サーバーのログオン グループを介して負荷を分散します。

Web Dispatcher コンポーネントは、SAP アプリケーション サーバー間の SAP トラフィックのロード バランサーとして使用されます。 SAP Web Dispatcher の高可用性を実現するには、Azure Load Balancer でフェールオーバー クラスターまたは並列 Web Dispatcher セットアップを実装します。

インターネット接続による通信の場合、セキュリティ上の懸念に対応するために、DMZ のスタンドアロン ソリューションが推奨アーキテクチャになります。

ASCS の Embedded Web Dispatcher は特別なオプションであり、ASCS の追加のワークロードに起因する適切なサイズ設定を考慮する必要があります。

セントラル サービス

Azure Linux 仮想マシン上の SAP セントラル サービス (ASCS) の可用性を保護するには、選択した Linux ディストリビューションに適した High Availability Extension (HAE) を使用する必要があります。 HAE は、実装用の Linux クラスタリング ソフトウェアと OS 固有の統合コンポーネントを提供します。

クラスターのスプリット ブレインの問題を回避するために、この例に示す iSCSI STONITH Block Device (SBD) を使用して、クラスター ノード フェンシングを設定できます。 または、代わりに Azure Fence Agent を使用することもできます。 強化された Azure Fence Agent により、Red Hat および SUSE 環境向けの以前のバージョンのエージェントと比較して、サービスのフェールオーバーが大幅に高速化されます。

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

SAP プライマリ アプリケーション サーバーとその他のアプリケーション サーバーの高可用性を実現するために、アプリケーション サーバーのプール内でトラフィックが負荷分散されます。

障害復旧

Azure では、要件に応じて、さまざまなディザスター リカバリー オプションがサポートされています。 SAP アプリケーション サーバーにはビジネス データが含まれていないため、SAP アプリケーション サーバーをシャットダウンする前にセカンダリ リージョンに作成できます。 SAP アプリケーション サーバー ソフトウェアの更新と構成の変更は、手動でまたはスケジュールに従って、ディザスター リカバリー側にレプリケートする必要があります。 ディザスター リカバリー リージョンで仮想マシンを作成して、セントラル サービス ロールを実行できます。この場合もビジネス データは保持しません。 詳細については、SAP S/4HANA リファレンス アーキテクチャを参照してください。

監視

アプリケーションとサービスの可用性とパフォーマンスを最大限に高めるには、Azure Monitor を使用します。これには、Azure Log Analytics と Azure Application Insights が含まれており、テレメトリを収集して分析するための高度なツールが用意されています。 これは、クラウドとオンプレミスのリソースおよびアプリケーションのパフォーマンスと可用性を最大限に高めるのに役立ちます。 Azure Monitor を使用すると、インフラストラクチャやアプリケーションの異常を監視して管理者にアラートを送信したり、定義済みの状態への対応を自動化したりすることができます。

SAP HANA およびその他の主要なデータベース ソリューションで実行される SAP アプリケーションについては、「Azure Monitor for SAP Solutions」を参照して、Azure Monitor for SAP が SAP サービスの可用性とパフォーマンスの管理にどのように役立つかをご確認ください。 Azure Monitor for SAP には、監視用のメトリックとテレメトリの包括的な初期セットが用意されています。 メトリック定義は、JSON で SQL クエリとして保存され、要件に合わせて変更できます。 メトリックの初期セットは、GitHub のこちらで入手できます。

バックアップ

SAP ASCS およびアプリケーション サーバーでは、Azure Backup を使用して仮想マシンの内容を保護することをお勧めします。 Azure Backup では、元のデータが誤って破壊されるのを防ぐために、独立して分離されたバックアップを提供します。 バックアップは、復旧ポイントの管理が組み込まれた Recovery Services コンテナーに格納されます。 構成とスケーラビリティは単純で、バックアップは最適化され、必要に応じて簡単に復元することができます。

データベース層のバックアップは、SAP HANA が仮想マシンと Azure Large Instances のどちらにデプロイされているかによって異なります。 Linux 仮想マシン上の SAP HANA の管理と運用に関する考慮事項をご覧ください。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

SAP には、SAP アプリケーションおよびデータベース内でロールベースのアクセスと承認を制御する独自のユーザー管理エンジン (UME) があります。 詳細については、「Security Guide SAP BW∕4HANA (SAP BW∕4HANA のセキュリティ ガイド)」をご覧ください。

SAP S/4HANA リファレンス アーキテクチャでは、SAP BW/4HANA にも適用されるインフラストラクチャのセキュリティに関するその他の考慮事項を提供します。

共同作成者

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

プリンシパル作成者:

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

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

次のステップ

コンポーネント テクノロジの詳細については、次を参照してください。

次の関連するアーキテクチャを確認してください。