編集

次の方法で共有

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

Azure
Azure Virtual Machines

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

アーキテクチャ

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

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

リージョン デプロイ アーキテクチャを示す図。

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

注意

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

ワークフロー

この参照アーキテクチャは、システムの可用性を最大限に引き出すための高可用性のデプロイにおいて 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 アカウントが必要です。)

注意

SAP ノート 2731110 に示されているように、SAP アプリケーション スタックのアプリケーション層とデータベース層の間に、ネットワーク仮想アプライアンス (NVA) を配置しないでください。 これを行うと、データ パケットの処理時間が大幅に増加し、アプリケーションのパフォーマンスが許容できないほど低下します。

仮想マシン

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

Microsoft と SAP は、SAP HANA ワークロードに対応するさまざまな仮想マシン サイズを共同で認定しています。 たとえば、小規模なデプロイは、Edsv4 または Edsv5 仮想マシンで実行でき、160 GiB 以上の RAM を使用することができます。 仮想マシンで最大の 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

考慮事項

このセクションでは、SAP HANA on Azure の実行に関する主な考慮事項について説明します。

スケーラビリティ

このアーキテクチャは、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 の証明書の詳細を確認して、構成が確実にサポートされていることを確認します。

ストレージ

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

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

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

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

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

SAP HANA のパフォーマンス要件の詳細については、SAP ノート 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 データベースの最適なパフォーマンスも保証されます。 このプロセスを続行する方法の詳細を確認できます。 これには、手動による介入が必要です。 作成にはしばらく時間がかかります。

高可用性

前述のアーキテクチャは、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 クラスター ノードでは、単一の共有ディスクにアクセスします。 共有ディスクは、ローカル (LRS) 冗長またはゾーン (ZRS) 冗長 (Azure リージョンで ZRS が使用可能な場合) にすることができます。

障害復旧

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

ディザスター リカバリーを使用したアーキテクチャを示す図。

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

注意

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

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 データは、さまざまな方法でバックアップできます。 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 上のワークロードを監視するために、Azure Monitor を使用すると、クラウドとオンプレミスの環境からテレメトリを包括的に収集、分析、および操作できます。

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

セキュリティ

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」を参照してください。

注意

同じストレージ ボリュームで、SAP HANA のネイティブな暗号化テクノロジと、Azure Disk Encryption またはホスト ベースの暗号化を組み合わせないでください。 また、Linux 仮想マシンのオペレーティング システム起動ディスクでは、Azure Disk Encryption はサポートされません。 代わりに、SAP HANA のネイティブな暗号化を使用する場合は、自動的に有効になるサーバー側の暗号化と組み合わせます。 カスタマー マネージド キーの使用は、ストレージ スループットに影響を及ぼす可能性があることに注意してください。

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

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

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

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

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

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

セキュリティに関する推奨事項の詳細については、Microsoft および SAP の記事を参照してください。

コミュニティ

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

共同作成者

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

プリンシパル作成者:

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

次のステップ

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

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