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

Backup
Bastion
Linux Virtual Machines
Managed Disks
Azure NetApp Files
Site Recovery
Virtual Machines
Virtual Network

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 アプリケーション層のデプロイ

Architecture

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

コンポーネント

このアーキテクチャでは、次のコンポーネントを利用します。

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

  • Linux 仮想マシンは、SAP BusinessObjects (BOBJ) サーバープール、SAP Web ディスパッチャ プール、アプリケーション サーバー プール、SAP セントラル サービス クラスターを含むアプリケーション層に使用されます。

  • 可用性セットは、Azure ホスト クラスターで 2 つ以上の仮想マシンをグループ化して、高可用性とより高いサービス レベル アグリーメント (SLA) を実現します。

  • Availability Zones は、Azure リージョン内の複数のデータセンターにサーバーを分散することで、ワークロードの可用性を向上させます。

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

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

  • Azure Bastion は、Azure portal を使用して、Azure で実行されている仮想マシンへのセキュリティで保護されたアクセスを提供します。ジャンプボックスとそれに関連付けられたパブリック IP アドレスを使用しないため、インターネットに公開されるリスクを抑えることができます。

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

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

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

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

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

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

代替

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

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

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

Recommendations

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

仮想マシン

SAP でサポートされる Azure 仮想マシンの種類とスループットのメトリック (SAPS) の詳細については、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 を使用する高可用性クラスターを示しています。 セントラル サービス クラスターの高可用性には共有ストレージが必要です。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 クラスターへのデプロイの詳細については、WindowsRed Hat Linux、または SUSE Linux の Azure マルチ SID のドキュメントをご覧ください。

近接通信配置グループ

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

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

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

データベース

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

  • SAP HANA のスケールアップ デプロイでは、データベース層はクラスターで 2 つ以上の Linux 仮想マシンを使用して高可用性を実現します。

  • SAP HANA のスケールアウト デプロイは、仮想マシンの一部の種類でサポートされています。

  • Azure Large Instances for SAP HANA Revision 4 は、SAP HANA Tailored Datacenter Integration (TDI) 標準を満たしていることが認定された特殊用途の物理サーバーであり、Microsoft Azure データセンターに配置されています。

ストレージ

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

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

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

ネットワーク

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

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

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

パフォーマンス

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

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

アプリケーションとデータベース間の物理的な距離を短くしてパフォーマンスを向上させるには、前述の近接配置グループを使用します。 スクリプトとユーティリティは 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 Standard Load Balancer は、設計によるセキュリティ実装を提供し、パブリック エンドポイントへの送信接続を有効にしていない限り、バックエンド プールからの送信トラフィックをブロックするため、すべての SAP シナリオでこれを使用することをお勧めします。

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

Web ディスパッチャ

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

Web ディスパッチャは、ソフトウェア ロード バランサーとして、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 を使用します。

SAP インフラストラクチャのリソースとサービス パフォーマンスの SAP ベースでの監視を提供するには、Azure SAP Enhanced Monitoring 拡張機能を使用します。 詳細については、SAP ノート 2191498 の「SAP on Linux with Azure: Enhanced Monitoring (Azure を使用した Linux 上の SAP: Enhanced Monitoring)」を参照してください。

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

SAP インフラストラクチャのリソースとサービス パフォーマンスの SAP ベースでの監視を提供するには、Azure SAP Enhanced Monitoring 拡張機能を使用します。 この拡張機能では、Azure 監視統計情報をオペレーティング システムの監視と DBA Cockpit 機能のための SAP アプリケーションにフィードします。 SAP の拡張された監視機能は、Azure で SAP を実行するうえで必須の前提条件です。 詳細については、SAP ノート 2191498 の「SAP on Linux with Azure:Enhanced Monitoring (Azure を使用した Linux 上の SAP: 拡張された監視機能)」を参照してください。 (SAP ノートにアクセスするには、SAP Service Marketplace アカウントが必要です。)

SAP BW/4HANA を対象とするエンドツーエンドのAzure ネイティブ監視ソリューションの今後の方向性は、Azure Monitor for SAP です。 現在、これはパブリック プレビュー段階にあり、一連の限られたリージョンでのみ利用可能であるため、要件を満たしているかどうかを慎重に評価する必要があります。

Azure Monitor for SAP は、監視用のメトリックとテレメトリの包括的な初期セットを提供します。メトリック定義は SQL クエリとして JSON に保存され、要件に合わせて変更できます。 メトリックの初期セットは、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 にも適用されるインフラストラクチャのセキュリティに関するその他の考慮事項を提供します。