次の方法で共有

Azure における SAP HANA インフラストラクチャの構成と運用

  • [アーティクル]

このドキュメントは、Azure インフラストラクチャの構成と Azure のネイティブ仮想マシン (VM) にデプロイされている SAP HANA システムの運用に関するガイダンスを提供します。 また、ドキュメントには、M128 の VM SKU 向けの SAP HANA スケールアウトの構成情報が含まれます。 このドキュメントは、以下の内容を含む標準の SAP ドキュメントを代替するものではありません。

前提条件

このガイドを使用するには、次の Azure コンポーネントに関する基本的な知識が必要です。

Azure 上の SAP NetWeaver や他の SAP コンポーネントについて詳しくは、Azure のドキュメント に関するページの Azure 上の SAP に関するセクションをご覧ください。

基本設定の考慮事項

次のセクションでは、Azure VM に SAP HANA システムをデプロイする際の基本的なセットアップの考慮事項について説明します。

Azure 仮想マシンに接続する

Azure 仮想マシンの計画ガイドのページで説明しているように、Azure VM に接続するには 2 つの基本的な方法があります。

  • ジャンプ VM または SAP HANA を実行する VM 上で、インターネットとパブリック エンドポイントを介して接続します。
  • VPN または Azure ExpressRoute 経由で接続します。

VPN または ExpressRoute 経由でのサイト対サイト接続は運用環境シナリオでは必須です。 このタイプの接続は、SAP ソフトウェアが使用されている場合に運用環境シナリオにフィードする非運用環境シナリオでも必要です。 次の図に、サイト間接続の例を示します。

サイト間接続

Azure VM の種類を選択する

SAP では、運用シナリオに使用できる Azure VM の種類が一覧表示されています。 運用環境以外のシナリオでは、さまざまなネイティブの Azure VM の種類が使用できます。

Note

運用環境以外のシナリオでは、SAP ノート #1928533 に記載されている VM の種類を使用します。 運用環境シナリオで Azure VM を使用する場合は、SAP が公開している認定 IaaS プラットフォームの一覧で SAP HANA 認定 VM を確認してください。

以下を使用して VM を Azure にデプロイします。

  • Azure Portal
  • Azure PowerShell コマンドレット
  • Azure CLI

SAP Cloud platform を使って Azure VM サービスに完全にインストールされた SAP HANA プラットフォームをデプロイすることもできます。 インストール プロセスについては、Azure での SAP S/4HANA または BW/4HANA のデプロイに関するページをご覧ください。

重要

M208xx_v2 VM を使用するには、慎重に Linux イメージを選択する必要があります。 詳しくは、「メモリ最適化済み仮想マシンのサイズ」をご覧ください。

SAP HANA のストレージ構成

Azure の SAP HANA に使用するストレージ構成とストレージの種類については、「SAP HANA Azure virtual machine storage configurations (SAP HANA Azure 仮想マシンのストレージ構成)」のドキュメントを参照してください。

Azure 仮想ネットワークをセットアップする

VPN または ExpressRoute を介して Azure に対するサイト対サイト接続がある場合は、最低 1 つの Azure 仮想ネットワークが仮想ゲートウェイ経由で VPN または ExpressRoute 回線に接続されている必要があります。 シンプルなデプロイでは、Virtual Gateway は、SAP HANA インスタンスもホストしている Azure 仮想ネットワーク (VNet) のサブネットにデプロイできます。 SAP HANA をインストールするには、Azure 仮想ネットワーク内に 2 つのサブネットを追加作成します。 1 つのサブネットは、SAP HANA インスタンスを実行する VM をホストします。 もう 1 つのサブネットは、ジャンプボックスまたは管理 VM を実行し、SAP HANA Studio、他の管理ソフトウェア、またはお使いのアプリケーション ソフトウェアをホストします。

重要

機能やパフォーマンス上の理由から、SAP アプリケーションと、SAP NetWeaver、Hybris、または S/4HANA ベースの SAP システムの DBMS レイヤー間の通信パスで Azure ネットワーク仮想アプライアンス を構成することはサポートされていません。 SAP アプリケーション レイヤーと DBMS レイヤー間の通信は直接的な通信である必要があります。 Azure ASG および NSG の規則で直接通信が許可されている限り、この制限にこれらの ASG および NSG の規則は含まれません。 NVA がサポートされないその他のシナリオが、Linux Pacemaker クラスター ノードを表す Azure VM と SBD デバイス間の通信パス内にあります (「SUSE Linux Enterprise Server for SAP Applications 上の Azure VM での SAP NetWeaver の高可用性」を参照)。 また、Azure VM と Windows Server SOFS セットアップ間の通信パス内にもあります (「Azure のファイル共有を使用して Windows フェールオーバー クラスター上の SAP ASCS/SCS インスタンスをクラスター化する」を参照)。 通信パスに NVA があると、2 つの通信パートナー間のネットワーク待ち時間が倍増し、SAP アプリケーション レイヤーと DBMS レイヤー間のクリティカル パスのスループットが制限される場合があります。 顧客に見られる一部のシナリオでは、Linux Pacemaker クラスター ノード間の通信で NVA を通じて SBD デバイスと通信する必要がある場合、NVA が原因で Pacemaker Linux クラスターが失敗することがあります。

重要

サポートされていないもう 1 つの設計は、SAP アプリケーション レイヤーと DBMS レイヤーを、相互にピアリングされていない異なる Azure 仮想ネットワークに分離することです。 異なる Azure 仮想ネットワークを使用するのではなく、Azure 仮想ネットワーク内のサブネットを使用して、SAP アプリケーション レイヤーと DBMS レイヤーを分離することをお勧めします。 推奨事項に従わず、代わりに 2 つのレイヤーを異なる仮想ネットワークに分離する場合は、2 つの仮想ネットワークをピアリングする必要があります。 2 つのピアリングされた Azure 仮想ネットワーク間のネットワーク トラフィックは転送コストの影響を受ける点に注意してください。 SAP アプリケーション レイヤーと DBMS レイヤー間で交換されるデータが膨大でテラバイト規模であり、SAP アプリケーション レイヤーと DBMS レイヤーが 2 つのピアリングされた Azure 仮想ネットワーク間で分離されている場合、相当のコストが蓄積される可能性があります。

ジャンプボックス VM または管理 VM を別のサブネットにデプロイした場合は、HANA VM に対して複数の仮想ネットワーク インターフェイス カード (vNIC) を定義し、各 vNIC を異なるサブネットに割り当てることができます。 複数の vNIC を使用できると、必要に応じてネットワーク トラフィックの分離を設定できます。 たとえば、クライアント トラフィックはプライマリ vNIC 経由でルーティングし、管理トラフィックは 2 つ目の vNIC 経由でルーティングすることができます。
また、両方の仮想 NIC にデプロイされる静的プライベート IP アドレスを割り当てます。

Note

Azure を使用して個々の vNIC に静的 IP アドレスを割り当てる必要があります。 ゲスト OS 内の静的 IP アドレスを vNIC に割り当てないでください。 Azure Backup Service のような一部の Azure サービスは、少なくともプライマリ vNIC が、静的 IP アドレスではなく、DHCP に設定されていることに依存します。 「Azure 仮想マシンのバックアップのトラブルシューティング」というドキュメントも参照してください。 複数の静的 IP アドレスを VM に割り当てる必要がある場合は、複数の vNIC を VM に割り当てる必要があります。

ただし、永続的なデプロイの場合は、Azure に仮想データセンター ネットワークを作成する必要があります。 このアーキテクチャでは、オンプレミスを別個の Azure VNet に接続する Azure VNet Gateway を切り離すことが推奨されています。 この別個の VNet では、オンプレミスまたはイントラネットのどちらかに流れるすべてのトラフィックがホストされます。 この手法によって、この別個のハブの VNet で Azure の仮想データセンターに流入するトラフィックの監査とログ記録を行うソフトウェアをデプロイすることが可能になります。 そこで、Azure のデプロイに送受信されるトラフィックに関連するすべてのソフトウェアと構成をホストする VNet を 1 つ配置します。

「Azure 仮想データセンター: ネットワークの観点」および「Azure 仮想データセンターとエンタープライズ コントロール プレーン」の記事に、仮想データセンターの手法と関連する Azure VNet 設計に関する詳細な情報が示されています。

Note

Azure VNet ピアリングを使用してハブの VNet とスポークの VNet 間を流れるトラフィックによって、追加のコストという課題が生じます。 これらのコストを基に、VNet ピアリングをバイパスするために、状況に応じて厳格なハブ/スポークのネットワーク設計の実行と、 'スポーク' に接続する複数の Azure ExpressRoute ゲートウェイの実行の間に、妥協点を見出すことを検討する必要があります。 ただし、Azure ExpressRoute ゲートウェイも、追加のコストを発生させます。 また、ネットワーク トラフィックのログ記録、監査、および監視に使用するサードパーティ製のソフトウェアでも、追加のコストが発生する場合があります。 一方の側で生じる VNet ピアリングを通じたデータ交換のコストと、追加の Azure ExpressRoute ゲートウェイおよび追加のソフトウェア ライセンスによって生じるコストに応じて、VNet の代わりにサブネットを分離単位として使用して、1 つの VNet 内でマイクロセグメント化するという判断も可能です。

IP アドレスを割り当てるさまざまな方法の概要については、「Azure における IP アドレスの種類と割り当て方法」をご覧ください。

SAP HANA を実行している VM では、割り当てられた静的 IP アドレスを使用する必要があります。 これは、HANA の一部の構成属性が IP アドレスを参照するためです。

Azure ネットワーク セキュリティ グループ (NSG) を使用して、SAP HANA インスタンスまたはジャンプボックスにルーティングされたトラフィックの送信先を示します。 NSG および今後はアプリケーションのセキュリティ グループも、SAP HANA サブネットと管理サブネットに関連付けられます。

サイト対サイト接続を利用せずに Azure に SAP HANA をデプロイするために、パブリック インターネットから SAP HANA インスタンスをシールドして、転送プロキシの背後に隠しておきたい場合があります。 この基本のシナリオでは、デプロイは Azure の組み込み DNS サービスに依存して、ホスト名を解決します。 公開 IP アドレスが使用されるより複雑なデプロイの場合には、Azure 組み込み DNS サーバーが特に重要です。 Azure NSG と Azure NVA を使用して、Azure でインターネットから Azure VNet アーキテクチャへのルーティングを監視します。 次の図は、SAP HANA をデプロイする場合の大まかなスキーマを示しています。ハブとスポークの VNet アーキテクチャに、サイト対サイト接続はありません。

サイト対サイト接続を使用しない SAP HANA のデプロイ スキーマの概要

「高可用性のネットワーク仮想アプライアンスをデプロイする」の記事に、Azure NVA を使用して、ハブとスポークの VNet アーキテクチャを利用せずに、インターネットからのアクセスを制御および監視する方法に関する別の説明があります。

Azure VM のクロック ソース オプション

SAP HANA が最適に動作するには、信頼性の高い正確なタイミング情報が必要です。 従来、Azure ハイパーバイザーで実行されている Azure VM は、既定のクロック ソースとして Hyper-V TSC ページのみを使用していました。 ハードウェア、ホスト OS、Linux ゲスト OS カーネルにおけるテクノロジの進歩により、一部の Azure VM SKU でクロック ソース オプションとして "インバリアント TSC" を提供できるようになりました。

Hyper-V TSC ページ (hyperv_clocksource_tsc_page) は、すべての Azure VM でクロック ソースとしてサポートされています。 基本となるハードウェア、ハイパーバイザー、ゲスト OS Linux カーネルがインバリアント TSC をサポートしている場合、Azure VM 上のゲスト OS で使用可能でサポートされているクロック ソースとして tsc が提供されます。

SAP HANA スケールアウト用に Azure インフラストラクチャを構成する

OLAP スケールアウトまたは S/4HANA スケールアウトのいずれかで認定されている Azure VM の種類を調べるには、SAP HANA ハードウェア ディレクトリを確認してください。 列 "Clustering" のチェックマークは、スケールアウトがサポートされていることを示します。 "Application Type" は、OLAP スケールアウトまたは S/4HANA スケールアウトがサポートされているかどうかを示します。 スケールアウトで認定されたノードの詳細については、SAP HANA ハードウェア ディレクトリに記載されている特定の VM SKU のエントリを確認してください。

Azure VM にスケールアウト構成をデプロイするための最小 OS リリースは、SAP HANA ハードウェア ディレクトリに一覧表示されている特定の VM SKU のエントリの詳細を確認してください。 N ノードの OLAP スケールアウト構成では、1 つのノードがメイン ノードとして機能します。 その他のノード (最大数は証明書の上限まで) は、ワーカー ノードとして機能します。 追加のスタンバイ ノードは、認定されたノードの数にカウントされません

Note

スタンバイ ノードで SAP HANA の Azure VM スケールアウト デプロイができるのは、Azure NetApp Files ストレージを使用した場合のみです。 他の SAP HANA 認定 Azure ストレージでは SAP HANA スタンバイ ノードの構成はできません

/hana/shared では、Azure NetApp Files または Azure Files を使うことをお勧めします。

/hana/shared が Azure NetApp Files にデプロイされている、スケールアウト構成での単一ノードの一般的な基本設計は次のようになります。

スケールアウト構成における単一ノードの一般的な基本設計を示す図。

SAP HANA スケールアウトの VM ノードの基本構成は、次のようになります。

  • /hana/shared では、Azure NetApp Files または Azure Files を通じて提供されるネイティブ NFS サービスを使います。
  • その他のディスク ボリュームはすべて、異なるノード間では共有されず、NFS に基づきません。 非共有の /hana/data および /hana/log を使用したスケールアウト HANA インストールのインストール構成と手順については、このドキュメントで後述します。 使用できる HANA 認定ストレージについては、記事「SAP HANA Azure 仮想マシンのストレージ構成」を確認してください。

ボリュームまたはディスクのサイズを設定するときに、ワーカー ノードの数によって決まる必要なサイズについて、SAP HANA TDI ストレージ要件に関するドキュメントを確認する必要があります。 このドキュメントには、ボリュームの必要な容量を把握するために適用する必要がある数式が記載されています。

スケールアウト SAP HANA VM の単一ノード構成の図に示されているその他の設計基準として、VNet またはそれ以上に優れたサブネット構成があります。 SAP では、HANA ノード間の通信から、クライアント/アプリケーションに向かうトラフィックを分離することを強く推奨しています。 図に示すように、2 つの異なる vNIC を VM にアタッチすることで、この目的が達成されます。 2 つの vNIC は別々のサブネットにあり、2 つの異なる IP アドレスを備えています。 NSG またはユーザー定義のルートを使用して規則をルーティングすることで、トラフィックの流れを制御します。

特に Azure には、特定の vNIC にサービスおよびクオータの品質を適用する手段や方法がありません。 その結果、クライアントやアプリケーションに対する通信とイントラノード通信を分離することで、一方のトラフィック ストリームがもう一方よりも優先されることはありません。 代わりに、分離によってスケールアウト構成のイントラノード通信がシールドされる点で、依然としてセキュリティ対策にはなります。

Note

このドキュメントで説明しているように、SAP では、クライアント/アプリケーション側へのネットワーク トラフィックとイントラノード トラフィックを分離することを推奨しています。 そのため、先ほどの図に示したアーキテクチャを導入することが推奨されます。 この推奨から逸脱する要件については、セキュリティとコンプライアンスのチームに問い合わせてください

ネットワークの観点で最低限必要なネットワーク アーキテクチャは、次のようになります。

単一ノードのスケールアウトの基本設計

SAP HANA スケールアウトの Azure へのインストール

スケールアウト SAP 構成をインストールするには、次のおおまかな手順を実行する必要があります。

  • 新しい Azure VNet インフラストラクチャをデプロイするか、または既存のものを適用する。
  • Azure マネージド Premium Storage ボリューム、Ultra ディスク ボリューム、ANF に基づく NFS ボリュームを使用して新しい VM をデプロイする。
    • たとえば、VM 間のイントラノード通信などが NVA 経由でルーティングされないようにネットワーク ルーティングを適用する。
  • SAP HANA メイン ノードをインストールする。
  • SAP HANA メイン ノードの構成パラメーターを調整する。
  • SAP HANA ワーカー ノードのインストールを続行する。

スケールアウト構成での SAP HANA のインストール

Azure VM インフラストラクチャがデプロイされ、他のすべての準備が完了したら、次の手順に従って SAP HANA スケールアウト構成をインストールする必要があります。

  • SAP のドキュメントに従って SAP HANA メイン ノードをインストールします。
  • /hana/data および /hana/log の非共有のディスクで Azure Premium Storage または Ultra Disk Storage を使用する場合は、パラメーター basepath_shared = no を global.ini ファイルに追加する必要があります。 このパラメーターを使用すると、ノード間で共有される /hana/data および /hana/log ボリュームがなくてもスケールアウトで SAP HANA を実行できます。 詳細については、SAP ノートの #2080991 を参照してください。 ANF に基づく NFS ボリュームを /hana/data と /hana/log に使用している場合は、この変更を行う必要はありません
  • global.ini のパラメーターの最後の変更後、SAP HANA インスタンスを再起動します
  • ワーカー ノードを追加します。 詳細については、「Add Hosts Using the Command-Line Interface (コマンドライン インターフェイスを使ったホストの追加)」を参照してください。 インストール中またはローカル hdblcm などの使用後に、SAP HANA インターノード通信の内部ネットワークを指定します。 詳細なドキュメントについては、SAP ノートの #2183363 を参照してください。

スタンバイ ノードを使用して SAP HANA スケールアウト システムを設定するには、SUSE Linux のデプロイ手順または Red Hat のデプロイ手順を参照してください。

Azure Virtual Machines 用の SAP HANA Dynamic Tiering 2.0

Microsoft Azure では、Azure M シリーズ VM の SAP HANA 認定だけでなく、SAP HANA Dynamic Tiering 2.0 もサポートされています。 詳細については、DT 2.0 ドキュメントへのリンクを参照してください。 製品のインストールまたは操作に違いはありません。 たとえば、Azure VM 内に SAP HANA Cockpit をインストールできます。 ただし、Azure の公式サポートのために、次のセクションで説明するように、いくつかの必須要件があります。 記事中では、Dynamic Tiering 2.0 というフル ネームの代わりに、"DT 2.0" という省略形が使用されます。

SAP BW や S4HANA では、SAP HANA Dynamic Tiering 2.0 はサポートされていません。 現在、主なユース ケースはネイティブの HANA アプリケーションです。

概要

次の図に、Microsoft Azure での DT 2.0 サポートに関する概要を示します。 公式認定に準拠するために従う必要がある、一連の必須要件があります。

  • DT 2.0 は専用の Azure VM にインストールする必要があります。 SAP HANA が実行されているのと同じ VM では実行されない場合があります
  • SAP HANA VM と DT 2.0 VM は同じ Azure Vnet 内にデプロイする必要があります
  • Azure 高速ネットワークを有効にして SAP HANA VM と DT 2.0 VM をデプロイする必要があります
  • DT 2.0 VM のストレージの種類は Azure Premium Storage である必要があります
  • DT 2.0 VM に複数の Azure ディスクをアタッチする必要があります
  • Azure ディスク全体でストライピングを使用し、(lvm または mdadm で) ソフトウェア RAID/ストライプ ボリュームを作成する必要があります

詳細については、以降のセクションで説明します。

SAP HANA DT 2.0 のアーキテクチャの概要

SAP HANA DT 2.0 専用の Azure VM

Azure IaaS では、専用の VM でのみ DT 2.0 がサポートされます。 HANA インスタンスが実行されている同じ Azure VM で、DT 2.0 を実行することはできません。 最初は以下の 2 つの VM の種類を使用して、SAP HANA DT 2.0 を実行できます。

  • M64-32ms
  • E32sv3

VM の種類の説明については、「Azure VM のサイズ - メモリ」を参照してください。

コストを節約するために "ウォーム" データをオフロードするというのが、DT 2.0 の基本的な考え方の場合、対応する VM のサイズを使用するのが妥当です。 可能な組み合わせに関する厳密な規則はありません。 特定の顧客のワークロードによって異なります。

推奨される構成は次のとおりです。

SAP HANA VM の種類 DT 2.0 VM の種類
M128ms M64-32ms
M128s M64-32ms
M64ms E32sv3
M64s E32sv3

SAP HANA 認定の M シリーズ VM とサポート対象の DT 2.0 VM (M64-32ms および E32sv3) のすべての組み合わせが可能です。

Azure のネットワークと SAP HANA DT 2.0

専用の VM 上に DT 2.0 をインストールするには、DT 2.0 VM と、最小 10 Gb の SAP HANA VM の間にネットワーク スループットが必要です。 そのため、同じ Azure Vnet 内にすべての VM を配置し、Azure 高速ネットワークを有効にすることが必須です。

Azure 高速ネットワークの詳細については、Azure CLI での高速ネットワークを使用する Azure VM の作成に関するページを参照してください。

SAP HANA DT 2.0 用の VM ストレージ

DT 2.0 のベスト プラクティス ガイダンスに従い、ディスク IO スループットを物理コアあたり最小 50 MB/秒にする必要があります。

DT 2.0 でサポートされている 2 つの Azure VM の種類の仕様によると、VM の最大ディスク IO スループット制限は次のとおりです。

  • E32sv3: 768 MB/秒 (キャッシュなし)。これは、物理コアあたり 48 MB/秒という比率を意味します
  • M64-32ms: 1000 MB/秒 (キャッシュなし)。これは、物理コアあたり 62.5 MB/秒という比率を意味します

DT 2.0 VM に複数の Azure ディスクをアタッチし、OS レベルでソフトウェア RAID (ストライピング) を作成して、VM あたりのディスク スループットの上限に達するようにする必要があります。 この点に関しては、単一の Azure ディスクで VM の上限に達するスループットを提供することはできません。 DT 2.0 を実行するには、Azure Premium Storage が必須です。

サイズの要件に応じて、VM の最大スループットに達するようにするためのさまざまなオプションがあります。 ここでは、VM スループットの上限に達するように DT 2.0 VM の種類ごとに可能なデータ ボリューム ディスク構成を示します。 E32sv3 VM は、より小規模なワークロードのエントリ レベルと見なす必要があります。 十分な速度でないことがわかった場合、VM のサイズを M64-32ms に変更する必要がある可能性があります。 M64-32ms VM のメモリは多いため、IO 読み込みでは、特に読み取り集中型のワークロードの上限に達しない場合があります。 そのため、顧客固有のワークロードによっては、ストライプ セット内の少ないディスクで十分な場合があります。 しかし、安全策として、最大スループットを保証するために次のディスク構成が選択されています。

VM の SKU ディスク構成 1 ディスク構成 2 ディスク構成 3 ディスク構成 4 ディスク構成 5
M64-32ms 4 x P50 -> 16 TB 4 x P40 -> 8 TB 5 x P30 -> 5 TB 7 x P20 -> 3.5 TB 8 x P15 -> 2 TB
E32sv3 3 x P50 -> 12 TB 3 x P40 -> 6 TB 4 x P30 -> 4 TB 5 x P20 -> 2.5 TB 6 x P15 -> 1.5 TB

特に読み取り負荷の高いワークロードの場合、IO パフォーマンスを高め、データベース ソフトウェアのデータ ボリュームに関する推奨事項に従って、Azure ホスト キャッシュの "読み取り専用" を有効にすることができます。 一方、トランザクション ログの場合は、Azure ホスト ディスク キャッシュを "なし" にする必要があります。

ログ ボリュームのサイズについては、データ サイズの 15% のヒューリスティックを開始点とすることをお勧めします。 コストとスループットの要件に応じて、さまざまな Azure ディスクの種類を使用してログ ボリュームを作成できます。 ログ ボリュームの場合、高い I/O スループットが必要です。

VM の種類として M64-32ms を使用している場合は、書き込みアクセラレータを有効にすることが必須です。 Azure 書き込みアクセラレータにより、トランザクション ログに最適なディスク書き込み待ち時間が提供されます (M シリーズでのみ利用可能)。 VM の種類ごとのディスクの最大数など、考慮すべきいくつかの項目があります。 書き込みアクセラレータの詳細については、「Azure 書き込みアクセラレータ」ページを参照してください

ログ ボリュームのサイズ変更に関するいくつかの例を次に示します。

データ ボリュームのサイズとディスクの種類 ログ ボリュームとディスクの種類の構成 1 ログ ボリュームとディスクの種類の構成 2
4 x P50 -> 16 TB 5 x P20 -> 2.5 TB 3 x P30 -> 3 TB
6 x P15 -> 1.5 TB 4 x P6 -> 256 GB 1 x P15 -> 256 GB

SAP HANA のスケール アウトの場合と同様に、SAP HANA VM と DT 2.0 VM の間で /hana/shared ディレクトリを共有する必要があります。 高可用性 NFS サーバーとして機能する、専用の VM を使用する SAP HANA スケール アウトの場合と同じアーキテクチャをお勧めします。 共有バックアップ ボリュームを提供するために、同じ設計を使用することができます。 しかし、HA が必要であるか、または、バックアップ サーバーとして機能するために十分なストレージ容量がある専用の VM を使用するだけで十分であるかは、お客様が判断する必要があります。

Azure VM 上に SAP HANA をデプロイするための操作

次のセクションでは、Azure VM 上での SAP HANA システムのデプロイに関連する操作の一部について説明します。

Azure VM でのバックアップおよび復元操作

次のドキュメントで、SAP HANA デプロイをバックアップおよび復元する方法を説明しています。

SAP HANA を含む VM の起動および再起動

Azure パブリック クラウドの特長は、コンピューティングを利用した時間分しか課金されないということです。 たとえば、SAP HANA を実行している VM をシャットダウンすると、その間はストレージのコストのみが請求されます。 もう 1 つの特長は、初期デプロイで VM の静的な IP アドレスを指定すると使用できます。 SAP HANA を含む VM を再起動すると、その VM は以前の IP アドレスを使用して再起動します。

SAP リモート サポートのために SAProuter を使用する

オンプレミスの場所と Azure の間にサイト対サイト接続があり、SAP コンポーネントを実行している場合は、既に SAProuter を実行している可能性があります。 その場合は、リモート サポートのために次の条件を満たしてください。

  • SAP HANA をホストする VM のプライベート IP アドレスと静的 IP アドレスを SAProuter 構成で管理します。
  • TCP/IP ポート 3299 を介したトラフィックを許可するように、HANA VM をホストするサブネットの NSG を構成します。

インターネット経由で Azure に接続しているときに、SAP HANA を実行する VM 用の SAP ルーターがない場合は、このコンポーネントをインストールする必要があります。 管理サブネット内の別の VM に SAProuter をインストールします。 次の図は、SAP HANA をデプロイする場合の大まかなスキーマです。サイト対サイト接続はなく、SAProuter があります。

サイト対サイト接続と SAProuter を使用しない SAP HANA のデプロイ スキーマの概要

SAProuter はジャンプボックス VM ではなく、個別の VM にインストールする必要があります。 個別の VM には静的 IP アドレスが必要です。 ご使用の SAProuter を SAP でホストされる SAProuter に接続するには、IP アドレスについて SAP にお問い合わせください。 (SAP でホストされる SAProuter は、VM にインストールした SAProuter インスタンスの相手側になります。)SAP に問い合わせた IP アドレスを使用して、ご使用の SAProuter インスタンスを構成します。 構成設定で必要なポートは TCP ポート 3299 のみです。

SAPRouter 経由でリモート サポート接続をセットアップし維持する方法について詳しくは、SAP ドキュメントをご覧ください。

Azure のネイティブ VM での SAP HANA の高可用性

SUSE Linux Enterprise Server または Red Hat を実行している場合は、フェンス デバイスを使用して Pacemaker クラスターを確立できます。 このデバイスを使用して、HANA システム レプリケーションによる同期レプリケーションと自動フェールオーバーを使用する SAP HANA 構成をセットアップできます。 詳細については、「次の手順」セクションに記載されています。

次の手順

一覧表示されている記事について理解を深めます