編集

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 の仮想マシンでは、単一ノードのメモリが最大 23.5 テビバイト (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 の最大メモリ サイズ (最大 23 TiB) をサポートするには、Mv2 シリーズ の仮想マシンを使用できます。 M208 仮想マシンは約 260,000 SAPS を達成し、M832ixs 仮想マシンは約 795,900 SAPS を達成しています。

第 2 世代 (Gen2) 仮想マシン。 VM をデプロイするときは、第 1 世代または第 2 世代の VM を使用できます。 第 2 世代 VM では、第 1 世代 VM では使用できない主要な機能がサポートされています。 SAP HANA の場合、これは特に重要です。Mv2、Mdsv2 などの一部の VM ファミリは Gen2 VM としてのみサポートされるためです。 同様に、一部の新しい VM に対する SAP on Azure 認定では、Azure で両方が許可されている場合でも、完全なサポートのために Gen2 のみが必要になる場合があります。 詳細については、「SAP ノート 1928533 - Microsoft Azure 上の SAP アプリケーション: サポート対象の製品と Azure VM の種類」を参照してください。

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

近接配置グループ (PPG)。 ネットワーク待機時間を最適化するには、近接配置グループを使用します。これは、併置を優先します。つまり、仮想マシンが同じデータセンター内にあるため、SAP HANA と接続するアプリケーション VM の間の待機時間を最低限に抑えることができます。 SAP HANA アーキテクチャ自体の場合、PPG は必要ありません。SAP HANA とアプリケーション層 VM を併置するためのオプションにすぎません。 PPG では潜在的な制限があるため、SAP システムの PPG にデータベース AvSet を追加する必要があるのは、SAP アプリケーションとデータベース トラフィック間に待機時間が必要な場合だけです。 PPG の使用シナリオの詳細については、リンク先のドキュメントを参照してください。 PPG ではワークロードが 1 つのデータセンターに制限されるため、PPG は複数の可用性ゾーンにまたがることができません。

Components

考慮事項

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

スケーラビリティ

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

ワークロードが仮想マシンの最大サイズを超える場合は、マルチノード HANA 構成を使用することをお勧めします。 オンライン トランザクション処理 (OLTP) アプリケーションの場合、スケールアウト メモリの合計容量は最大で 4 x 23 TiB とすることができます。 オンライン分析処理 (OLAP) アプリケーションの場合、スケールアウト メモリ容量は最大で 16 x 7.6 TiB とすることができます。 たとえば、共有ストレージ ボリュームに Azure NetApp Files を使用して、Red Hat Enterprise Linux または SUSE Linux Enterprise Server を実行している仮想マシンに、スタンバイを使用したスケールアウト構成の SAP HANA をデプロイできます。

ストレージ

このアーキテクチャでは、仮想マシンまたは 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 データベース クラスターの場合、Direct Server Return (DSR) (Floating IP とも呼ばれます) を有効にする必要があります。 この機能により、サーバーはロード バランサーのフロントエンドの 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 に対する認可を行います。 他のインフラストラクチャは必要ありません。Azure フェンス エージェントが使用されている場合、アーキテクチャ図の SBD VM はデプロイされません。

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 にサインインします。

次のステップ

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

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