Azure のスケールアップ アーキテクチャで Linux 仮想マシンの SAP HANA を実行する

この参照アーキテクチャは、Azure でディザスター リカバリーをサポートする、可用性の高いスケールアップ環境で SAP HANA を実行するための一連の実証済みプラクティスを示しています。 この実装では、データベース レイヤーのみに重点を置いています。

Architecture

この参照アーキテクチャでは、一般的な運用システムについて説明します。 組織のニーズに合わせて仮想マシンのサイズを選択できます。 ビジネス要件に応じて、この構成を単一の仮想マシンに縮小することもできます。

次の図は、SAP HANA on Azure の参照アーキテクチャを示しています。

この記事の図を含むVisio ファイルをダウンロードしてください。

Workflow

この参照アーキテクチャは、システムの可用性を最大限に引き出すための高可用性のデプロイにおいて Azure で実行される一般的な SAP HANA データベースを示しています。 このアーキテクチャとそのコンポーネントは、ビジネス要件 (RTO、RPO、稼働時間の予測、システム ロール) に基づいてカスタマイズでき、VM を 1 つにまで減らせる可能性があります。 このネットワーク レイアウトはこのような SAP 環境のアーキテクチャの原則を示すように簡略化されています。そのため、エンタープライズ ネットワークを完全に示すものではありません。

ネットワーク

仮想ネットワーク。 Azure Virtual Network サービスは Azure リソースと相互に接続されており、セキュリティが強化されています。 このアーキテクチャでは、仮想ネットワークは 、ハブスポーク トポロジのハブにデプロイされた ExpressRoute ゲートウェイを介してオンプレミス環境に接続します。 SAP HANA データベースは、独自のスポーク仮想ネットワークに含まれています。 スポーク仮想ネットワークには、データベース仮想マシン (VM) 用のサブネットが 1 つ含まれています。

SAP HANA に接続するアプリケーションが VM 上で実行されている場合、そのアプリケーションの VM は同じ仮想ネットワーク内の専用のアプリケーション サブネットに配置する必要があります。 または、SAP HANA 接続がプライマリ データベースでない場合は、アプリケーションの VM を他の仮想ネットワークに配置できます。 ワークロードごとにサブネットに分離すると、ネットワーク セキュリティ グループ (NSG) を簡単に有効にして、SAP HANA VM にのみ適用できるセキュリティ規則を設定できます。

ゾーン冗長ゲートウェイ。 ゲートウェイは個々のネットワークを接続し、オンプレミス ネットワークを Azure 仮想ネットワークに拡張します。 ExpressRoute を使用してパブリック インターネットを経由しないプライベート接続を作成することをお勧めしますが、サイト間接続を使用することもできます。 ゾーン冗長 Azure ExpressRoute または VPN ゲートウェイを使用して、ゾーン障害から保護します。 ゾーン デプロイとゾーン冗長デプロイの違いについては、ゾーン冗長仮想ネットワーク ゲートウェイに関する記事をご覧ください。 ここでは、使用する IP アドレスがゲートウェイのゾーン デプロイの Standard SKU である必要があることに注意してください。

ネットワーク セキュリティ グループ (NSG)。 仮想ネットワークの送受信のネットワーク トラフィックを制限するには、ネットワーク セキュリティ グループを作成して特定のサブネットに割り当てます。 DB サブネットとアプリケーション サブネットは、ワークロード固有の NSG を使用して保護されます。

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

ネットワーク インターフェイス カード (NIC)。 ネットワーク インターフェイス カードを使用すると、仮想ネットワーク上の仮想マシン間のすべての通信が有効になります。 従来のオンプレミスの SAP デプロイでは、管理トラフィックとビジネス トラフィックを切り離すために、マシンごとに複数の NIC が実装されます。

Azure では、パフォーマンス上の理由から複数の NIC を使用する必要はありません。 複数の NIC は、VM の同じネットワーク スループット制限を共有します。 ただし、お客様の組織でトラフィックを分離することが必要な場合は、VM ごとに複数の NIC をデプロイして、各 NIC をそれぞれ異なるサブネットに接続することができます。 このようにすると、ネットワーク セキュリティ グループを使用して、さまざまなアクセス制御ポリシーを各サブネットに適用できます。

Azure NIC は、複数の IP をサポートしています。 このサポートは、インストールに仮想ホスト名を使用する SAP 推奨プラクティスに準拠しています。 全体的な概要については、SAP Note 962955 を参照してください。 (SAP Note にアクセスするには、SAP Service Marketplace アカウントが必要です。)

仮想マシン

このアーキテクチャでは、仮想マシン (VM) を使用します。 Azure では、仮想マシン上で最大 32 テビバイト (TiB) のメモリを単一ノードでスケールアップできます。 SAP 認定およびサポート対象の SAP HANA ハードウェア ディレクトリには、SAP HANA データベース用に認定された仮想マシンが示されています。 仮想マシンの種類とスループット メトリック (SAPS) に対する SAP サポートの詳細については、「 SAP Note 1928533 - SAP Applications on Microsoft Azure: Supported Products and Azure VM types」を参照してください。 (SAP ノートにアクセスするには、SAP Service Marketplace アカウントが必要です)。

Microsoft と SAP は、SAP HANA ワークロードに対応するさまざまな仮想マシン サイズを共同で認定しています。 たとえば、小規模なデプロイは、160 GiB 以上の RAM を搭載した Edsv4 または Edsv5 仮想マシンで実行できます。 仮想マシンで最大の SAP HANA メモリ サイズ (最大 30 TiB) をサポートするには、 Mv3 シリーズの 仮想マシンを使用できます。

第 2 世代 (Gen2) 仮想マシン。 VM をデプロイするときは、第 1 世代または第 2 世代の VM を使用できます。 第 2 世代 VM では、第 1 世代 VM では使用できない主要な機能がサポートされています。 SAP HANA では、Mv2、Mdsv2、Msv3、Mdsv3 などの一部の VM ファミリは Gen2 VM としてのみサポートされるため、この考慮事項は特に重要です。 同様に、Azure で Gen1 と Gen2 の両方が許可されている場合でも、SAP on Azure 認定では新しい VM を Gen2 にする必要がある場合があります。 詳細については、「 SAP Note 1928533 - SAP Applications on Microsoft Azure: Supported Products and Azure VM types」を参照してください。

SAP HANA をサポートする他のすべての VM では、Gen2 のみ、または Gen1 と 2 の併用を選択できるため、すべての SAP VM を Gen2 のみとしてデプロイすることをお勧めします。 これは、メモリ要件が低い VM にも適用されます。 最小の SAP HANA VM でも Gen2 VM として実行でき、割り当てを解除すると、リージョンで使用可能な最大の VM にサイズ変更できます。

近接通信配置グループ。 ネットワーク待ち時間を最適化するために、コロケーション 優先する近接通信配置グループを使用できます。 VM は、SAP HANA と接続アプリケーション VM 間の待機時間を最小限に抑えるために、同じデータセンターに配置されます。 SAP HANA アーキテクチャ自体では、近接通信配置グループは必要ありませんが、それらを使用するとパフォーマンスを最適化できます。 近接通信配置グループでは制限が生じる可能性があるため、SAP アプリケーションとデータベース トラフィックの間の待機時間に必要な場合にのみ、データベース可用性セットを SAP システムの近接通信配置グループに追加する必要があります。 近接通信配置グループの使用シナリオの詳細については、「構成オプション」を参照して、SAP アプリケーションのによるネットワーク待ち時間を最小限に抑えます。 近接通信配置グループはワークロードを 1 つのデータセンターに制限するため、近接配置グループを複数の可用性ゾーンにまたがることはできません。 近接通信配置グループを参照する大量のデプロイには、リソース割り当ての制限が適用される場合があります。

Components

• Azure Disk Storage は、Azure 仮想マシン用の高パフォーマンスで耐久性のあるブロック ストレージ ソリューションです。 このアーキテクチャでは、SAP HANA のデータボリュームとログ ボリュームに永続的なストレージを提供し、厳密な待機時間とスループットの要件を満たす構成をサポートします。

• Azure Load Balancer は、仮想マシン間でネットワーク トラフィックを分散するレイヤー 4 ロード バランサーです。 このアーキテクチャでは、SAP HANA の仮想 IP エンドポイントとして機能し、アクティブなデータベース ノードにトラフィックを送信し、必要に応じて読み取りが有効なセカンダリ ノードをサポートします。

• Azure NetApp Files は、エンタープライズ ワークロード向けに構築された高パフォーマンスのファイル ストレージ サービスです。 このアーキテクチャでは、SAP HANA のデータ ファイルとログ ファイルを格納し、スナップショット ベースのバックアップをサポートし、リージョン間での高速復旧とディザスター レプリケーションを可能にします。

• Azure Virtual Machines は、Azure でワークロードを実行するためのスケーラブルなコンピューティング リソースです。 このアーキテクチャでは、SAP HANA データベースを認定された高メモリ構成でホストし、高可用性のためのシステム レプリケーションを使用したスケールアップ デプロイをサポートします。

• Azure Virtual Network は、Azure の基本的なネットワーク サービスです。 このアーキテクチャでは、スポーク ネットワーク内の SAP HANA VM を接続し、ExpressRoute を使用してハブ ネットワーク経由でオンプレミス システムにリンクします。これにより、階層間のセキュリティで保護されたセグメント化された通信が可能になります。

• ExpressRoute は、オンプレミスインフラストラクチャと Azure の間のプライベート接続サービスです。 このアーキテクチャでは、ゾーン冗長ゲートウェイを使用して SAP HANA 環境をオンプレミス システムに接続し、パブリック インターネットをバイパスするセキュリティで保護された信頼性の高い通信を確保します。

Considerations

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

Reliability

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性設計レビューチェックリスト」を参照してください。

Backup

SAP HANA データは、さまざまな方法でバックアップできます。 Azure への移行後も、パートナーの既存のバックアップ ソリューションを引き続き使用できます。 Azure には、2 つのネイティブ アプローチが用意されています。SAP HANA のファイルレベルのバックアップと、Backint インターフェイスを介した SAP HANA 用 Azure Backup です。

SAP HANA のファイルレベルのバックアップでは、hdbsql や SAP HANA Studio などの任意のツールを使用し、バックアップ ファイルをローカル ディスク ボリュームに保存できます。 このバックアップ ボリュームの一般的なマウント ポイントは /hana/backup です。 バックアップ ポリシーによって、ボリュームのデータ保持期間を定義します。 バックアップが作成されたらすぐに、スケジュールされたタスクによってバックアップ ファイルを Azure Blob Storage にコピーし、安全に保管する必要があります。 ローカル バックアップ ファイルは、適切な回復のために保持されます。

Azure Backup は、仮想マシンで実行されるワークロードのための、シンプルなエンタープライズ レベルのソリューションを提供します。 SAP HANA 用 Azure Backup は、SAP HANA バックアップ カタログと完全に統合され、データベースの整合性が維持された完全復旧または特定時点への復旧が保証されます。 Azure Backup は、SAP によって BackInt 認定を受 けます。 Azure Backup FAQ とサポート マトリックスも参照してください。

Azure NetApp Files では、スナップショット ベースのバックアップがサポートされます。 アプリケーション整合性スナップショットの SAP HANA との統合は、Azure アプリケーション整合性スナップショット ツール (AzAcSnap) を使用して行います。 作成されたスナップショットは、システムの復元または SAP HANA データベースのコピーのために、新しいボリュームへの復元に使用できます。 作成されたスナップショットは、ディザスター リカバリーに使用できます。これは、別の NFS ボリュームに保存された SAP HANA ログとともに復元ポイントとして機能します。

障害復旧

次のアーキテクチャは、ディザスター リカバリーが提供されている Azure 上の運用 HANA 環境を示しています。 このアーキテクチャには可用性ゾーンが組み込まれています。

DR 戦略と実装の詳細については、「SAP ワークロードのディザスター リカバリーの概要とインフラストラクチャのガイドライン」および「SAP アプリケーションに関するディザスター リカバリーのガイドライン」を参照してください。

HSR では、ローカルの 2 ノードの高可用性実装に加えて、 多層 レプリケーションと マルチターゲット レプリケーションがサポートされています。 そのため、HSR ではゾーン間およびリージョン間のレプリケーションがサポートされます。 マルチターゲット レプリケーションは、SAP HANA 2.0 SPS 03 以降で使用できます。

ターゲット リージョンの リソース容量を確認してください。

Azure NetApp Files。 オプションとして、Azure NetApp Files を使用して、SAP HANA のデータ ファイルおよびログ ファイル用のスケーラブルで高パフォーマンスのストレージ ソリューションを提供することもできます。 Azure NetApp Files では、高速バックアップ、回復、ローカル レプリケーションのためのスナップショットがサポートされています。 リージョン間でのコンテンツのレプリケーションの場合は、Azure NetApp Files のリージョン間レプリケーションを使用して、2 つのリージョン間でスナップショット データをレプリケートできます。 リージョン間レプリケーションの詳細と、Azure NetApp Files を使用したディザスター リカバリーのすべての側面を説明するホワイトペーパーを利用できます。

高可用性

前述のアーキテクチャは、SAP HANA が 2 つ以上の仮想マシンに含まれる高可用性デプロイを示しています。 次のコンポーネントが使用されます。

ロード バランサー。Azure Load Balancer は、SAP HANA 仮想マシンにトラフィックを分散するために使用されます。 SAP のゾーン デプロイに Azure Load Balancer を組み込む場合は、必ず Standard SKU ロード バランサーを選択するようにしてください。 Basic SKU バランサーはゾーン冗長をサポートしていないため、 非推奨です。 このアーキテクチャでは、Load Balancer が SAP HANA の仮想 IP アドレスとして機能します。 ネットワーク トラフィックは、プライマリ データベース インスタンスを使用してアクティブな VM に送信されます。 必要に応じて、SAP HANA のアクティブ/読み取り対応アーキテクチャ (SLES/RHEL) を使用できます。ロード バランサーでアドレス指定された 2 つ目の仮想 IP を使用して、読み取り負荷の高いワークロードのために別の VM 上のセカンダリ SAP HANA インスタンスにネットワーク トラフィックを送信します。

Standard Load Balancer では、既定でセキュリティ層が提供されることに注意してください。 Standard Load Balancer の背後にある仮想マシンには、送信インターネット接続はありません。 これらの仮想マシンで送信インターネットを有効にするには、Standard Load Balancer の構成を更新する必要があります。 また、Azure NAT Gateway を使用して送信接続を取得することもできます。

SAP HANA データベース クラスターの場合は、フローティング IP とも呼ばれる Direct Server Return (DSR) を有効にする必要があります。 この機能により、サーバーはロード バランサー フロントエンドの IP アドレスで応答できます。

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

SAP HANA。 高可用性を実現するために、SAP HANA は 2 つ以上の Linux 仮想マシンで実行されます。 SAP HANA システム レプリケーション (HSR) を使用して、プライマリとセカンダリ (レプリカ) の SAP HANA システム間でデータがレプリケートされます。 HSR は、リージョン間またはゾーン間のディザスター リカバリーにも使用されます。 仮想マシン間の通信の待機時間によっては、リージョン内で同期レプリケーションを使用できます。 ディザスター リカバリー用のリージョン間の HSR は、ほとんどの場合、非同期的に実行されます。

Linux Pacemaker クラスターでは、どのクラスター フェンス メカニズムを使用するかを決定する必要があります。 クラスター フェンスは、障害が発生した VM をクラスターから分離して再起動するプロセスです。 RedHat Enterprise Linux (RHEL) の場合、Azure 上の Pacemaker でサポートされるフェンス メカニズムは、Azure フェンス エージェントのみです。 SUSE Linux Enterprise Server (SLES) の場合は、Azure フェンス エージェントまたは STONITH ブロック デバイス (SBD) を使用できます。 各ソリューションのフェールオーバー時間を比較して、違いがある場合は、目標復旧時間 (RTO) のビジネス要件に基づいてソリューションを選択します。

Azure フェンス エージェント。 このフェンスメソッドは Azure ARM API に依存し、Pacemaker はクラスター内の両方の SAP HANA VM の状態について ARM API にクエリを実行します。 1 つの VM が失敗した場合 (たとえば、OS が応答しない場合や VM がクラッシュした場合)、クラスター マネージャーは ARM API をもう一度使用して VM を再起動し、必要に応じて SAP HANA データベースを他のアクティブ ノードに失敗させます。 このため、VM のクエリと再起動を行うカスタム ロールを持つサービス名プリンシパル (SPN) を使用して、ARM API に対する承認が行われます。 他のインフラストラクチャは必要ありません。 アーキテクチャ図の SBD VM は、Azure フェンス エージェントが使用されている場合はデプロイされません。

SBD. STONITH ブロック デバイス (SBD) では、クラスター マネージャーによってブロック デバイス (RAW、ファイル システムなし) としてアクセスされるディスクを使用します。 このディスクは投票として機能します。 SAP HANA を実行している 2 つのクラスター ノードでは、それぞれ SDB ディスクにアクセスし、状態に関する少量の情報をそこから定期的に読み取り/書き込みします。 そのため、各クラスター ノードでは、VM 間のネットワークのみに依存することなく、他のノードに関する状態を認識します。

できれば、可用性セットまたは可用性ゾーンのセットアップのいずれかに、3 つの小さい VM をデプロイします。 各 VM では、2 つの SAP HANA クラスター ノードによってアクセスされるブロック デバイスとしてディスクの小さな部分をエクスポートします。 3 つの SBD VM により、SBD VM の計画的または計画外のダウンタイムが発生した場合に、十分な投票メンバーが確保されます。

SBD VM を使用する代わりに、Azure 共有ディスクを使用することもできます。 その後、SAP HANA クラスター ノードでは、単一の共有ディスクにアクセスします。 AZURE リージョンで ZRS を使用できる場合、共有ディスクはローカル (LRS) またはゾーン (ZRS) 冗長にすることができます。

セキュリティ

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

SAP ランドスケープの機密性、整合性、可用性を保護するために、多くのセキュリティ対策が使用されています。 ユーザー アクセスをセキュリティで保護するには、SAP には、SAP アプリケーションおよびデータベース内でロールベースのアクセスと承認を制御する独自のユーザー管理エンジン (UME) などがあります。 詳細については、SAP HANA セキュリティ - 概要に関するページを参照してください。

保存データの場合は、次のように、さまざまな暗号化機能がセキュリティを提供します。

• SAP HANA ネイティブ暗号化テクノロジに加えて、顧客が管理するキーをサポートする、パートナーの暗号化ソリューションを使用することを検討してください。

• 仮想マシンのディスクを暗号化するには、「ディスク暗号化の概要」で説明されている機能を使用できます。

• SAP データベース サーバー: DBMS プロバイダーによって提供される Transparent Data Encryption ("SAP HANA ネイティブ暗号化テクノロジ" など) を使用して、データとログのファイルのセキュリティ保護をサポートし、バックアップも暗号化されるようにします。

• Azure の物理ストレージ内のデータ (サーバー側の暗号化) は、Azure マネージド キーを使用して保存時に自動的に暗号化されます。 Azure マネージド キーの代わりにカスタマー マネージド キー (CMK) を選択することもできます。

• 特定の Linux ディストリビューション、バージョン、イメージでの Azure Disk Encryption のサポートの詳細については、「Linux VM に対する Azure Disk Encryption」を参照してください。

ネットワーク セキュリティの場合は、ネットワーク セキュリティ グループ (NSG) と Azure Firewall またはネットワーク仮想アプライアンスを次のように使用します。

• NSG を使用して、サブネットとアプリケーション/データベース レイヤー間のトラフィックを保護および制御します。 NSG はサブネットにのみ適用します。 NSG を NIC とサブネットの両方に適用すると、トラブルシューティング中に問題が発生することが非常に多いため、使用しないようにしてください。

• Azure Firewall または Azure ネットワーク仮想アプライアンスを使用して、ハブ仮想ネットワークから SAP アプリケーションがあるスポーク仮想ネットワークへのトラフィックのルーティングを検査および制御し、送信インターネット接続を制御します。

ユーザー承認の場合は、次のように Azure ロールベースのアクセス制御 (Azure RBAC) とリソース ロックを実装します。

• Azure で SAP ソリューションをホストする IaaS レベルのリソースで管理特権を割り当てるために Azure RBAC を 使用して、最小限の特権の原則に従います。 Azure RBAC の基本的な目的は、ユーザー/グループの職務の分離と制御です。 Azure RBAC は、ユーザーが自分のジョブを実行できるようにするために必要なリソースへのアクセス権のみを付与するように設計されています。

• リソース ロックを使用して、偶発的または悪意のある変更を防ぎます。 リソース ロックは、管理者が SAP ソリューションが配置されている重要な Azure リソースを削除または変更するのを防ぐのに役立ちます。

セキュリティに関するその他の推奨事項については、 Microsoft と SAP の記事を参照してください。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、アプリケーションをデプロイし、運用環境で実行し続ける運用プロセスを対象としています。 詳細については、「オペレーショナル エクセレンス設計レビュー チェックリスト」を参照してください。

Monitoring

Azure Monitor では、Azure でワークロードを監視するために、クラウドおよびオンプレミス環境からのテレメトリを包括的に収集、分析、および操作できます。

SAP HANA およびその他の主要なデータベース ソリューションで実行される SAP アプリケーションについては、「Azure Monitor for SAP Solutions」を参照して、Azure Monitor for SAP が SAP サービスの可用性とパフォーマンスの管理にどのように役立つかをご確認ください。

パフォーマンス効率

パフォーマンス効率は、ユーザーの要求を効率的に満たすワークロードの機能です。 詳細については、「パフォーマンス効率 設計レビュー チェックリスト」を参照してください。

Scalability

このアーキテクチャは、1 つのインスタンスで最大 32 TiB までスケールアップできる仮想マシン上で SAP HANA を実行します。

ワークロードが仮想マシンの最大サイズを超える場合は、マルチノード HANA スケールアウト構成を使用します。 オンライン トランザクション処理 (OLTP) アプリケーションの場合、スケールアウト メモリの合計容量は最大 4 x 23 TiB になります。 オンライン分析処理 (OLAP) アプリケーションの場合、スケールアウト メモリ容量は最大 16 x 7.6 TiB にすることができます。 たとえば、Red Hat Enterprise Linux または SUSE Linux Enterprise Server を実行している仮想マシンでスタンバイ状態のスケールアウト構成で SAP HANA をデプロイし、共有ストレージ ボリューム Azure NetApp Files を使用できます。 スケールアウト構成をサポートする認定 VM SKU を特定するには、認定済みおよびサポートされている SAP HANA ハードウェア ディレクトリのを参照してください。 各 VM SKU の証明書の詳細を確認して、構成が確実にサポートされていることを確認します。

Storage

このアーキテクチャでは、仮想マシンまたは Azure NetApp Files 上のストレージに Azure マネージド ディスクを使用します。 マネージド ディスクを使用したストレージのデプロイのガイドラインについては、「SAP HANA Azure 仮想マシンのストレージ構成」のドキュメントを参照してください。 マネージド ディスクの代わりに、Azure NetApp Files NFS ボリュームを SAP HANA のストレージ ソリューションとして使用することもできます。

1 秒あたりの高い入出力操作 (IOPS) とディスク ストレージのスループットを実現するために、ストレージ ボリュームの パフォーマンス最適化 の一般的なプラクティスは、Azure ストレージ レイアウトにも適用されます。 たとえば、LVM を使用して複数のディスクを結合してストライピングされたディスク ボリュームを作成すると、IO パフォーマンスが向上します。 Azure ディスクのキャッシュも、必要な IO パフォーマンスを実現する上で重要な役割を果たします。

Azure Premium SSD v1 で実行される SAP HANA ログ ディスクの場合は、運用用に /hana/log を保持する場所で次のいずれかのテクノロジを使用します。

• 書き込みアクセラレータ (M シリーズ VM 上)
• Ultra ディスク (M または E シリーズ VM 上)
• Azure NetApp Files (M または E シリーズの VM 上)

これらのテクノロジは、必要なストレージ待機時間を常に 1 ミリ秒未満で実現するために必要です。

Azure Premium SSD v2 は、SAP などのパフォーマンスが重要なワークロード向けに設計されています。 /hana/log が Premium SSD v2 で実行されている場合、書き込みアクセラレータは必要ありません。 このストレージ ソリューションの利点と現在の制限事項の詳細については、「Premium SSD v2 をデプロイする」を参照してください。

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

• 非運用システム向けのコスト志向のストレージ設計。 すべての状況で最大のストレージ パフォーマンスが必要となるわけではない SAP HANA 環境では、コストに合わせて最適化されたストレージ アーキテクチャを使用できます。 このストレージ最適化の選択は、ほとんど使用されていない運用システムや一部の非運用の SAP HANA 環境に適用できます。 コスト最適化のストレージ オプションでは、運用環境に使用される Premium SSD または Ultra SSD ではなく、Standard SSD の組み合わせが使用されます。 また、 /hana/data および /hana/log ファイル システムを 1 つのディスク セットに結合します。 ガイドラインとベスト プラクティスは、ほとんどの VM サイズで使用できます。 SAP HANA に Azure NetApp Files を使用する場合は、サイズを減らしたボリュームを使用して同じ目標を達成できます。

• スケールアップ時のストレージのサイズ変更。 ビジネスのニーズの変化やデータベース サイズの増大により、仮想マシンのサイズを変更する場合は、ストレージ構成を変更できます。 Azure では、サービスを中断せずに、オンラインでディスク拡張することがサポートされています。 SAP HANA に使用されるようなストライピングされたディスクのセットアップでは、ボリューム グループ内のすべてのディスクにサイズ変更操作が均一に行われる必要があります。 ボリューム グループにさらにディスクを追加すると、ストライピングされたデータが不均衡になる可能性があります。 ストレージ構成にさらにディスクを追加する場合は、新しいディスクに新しいストレージ ボリュームを作成することをお勧めします。 次に、ダウンタイム中に内容をコピーし、マウント ポイントを変更します。 最後に、以前のボリューム グループと基となっているディスクを破棄します。

• Azure NetApp Files アプリケーション ボリューム グループ。 Azure NetApp Files の NFS ボリュームに含まれている SAP HANA ファイルのデプロイの場合、アプリケーション ボリューム グループを使用すると、ベスト プラクティスに従ってすべてのボリュームをデプロイできます。 このプロセスにより、SAP HANA データベースの最適なパフォーマンスも保証されます。 このプロセスを続行する方法の詳細を確認できます。 これには、手動による介入が必要です。 作成にはしばらく時間がかかります。

Communities

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

• Azure コミュニティ サポート

• SAP コミュニティ

• Stack Overflow 上の SAP

Contributors

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

主要著者:

• ロバート・ビロ |シニア アーキテクト

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

次のステップ

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

• Azure ExpressRoute とは
• Azure Bastion とは
• Power BI とは?
• Power BI Desktop で SAP Business Warehouse コネクタを使用する
• Azure Availability Zones での SAP ワークロードの構成
• Azure Backup サービスとは
• Site Recovery の概要
• Azure Load Balancer の概要
• Power BI で SAP HANA データベースに接続する
• Azure NetApp Files とは
• Azure マネージド ディスクの概要
• Azure の Linux 仮想マシン
• Azure Virtual Machines への SAP HANA のインストール
• Azure Virtual Network とは
• ネットワーク セキュリティ グループ
• Azure NetApp Files を使用した SAP HANA のディザスター リカバリー

関連リソース

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

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