SAP HANA on Azure (Large Instances) を検証する

  • 5 分

HANA のインストールを開始する前に、以下について検証する必要があります。

  • HLI ユニット
  • オペレーティング システムの構成
  • ネットワークの構成
  • ストレージの構成

  1. HANA Large Instance を受け取って、インスタンスへのアクセスと接続を確立した後の最初の手順は、そのインスタンスの OS を OS プロバイダーに登録することです。 SUSE または Red Hat のどちらを使うかによって、この手順では、HANA Large Instance からアクセスできる仮想ネットワークの Azure VM サブネット内の Azure VM にインストールされた SUSE SMT (Subscription Management Tool) または Red Hat Subscription Manager を使ってインスタンスを登録します。 この手順は、OS に修正プログラムを適用する際に必要で、ユーザー側で実行する必要があります。

  2. 手順 2: 特定の OS リリース/バージョンに関する新しいパッチと修正プログラムの有無をチェックします。 HANA L インスタンスのパッチ レベルが最新の状態になっていることを確認してください。 最新のパッチが含まれていない場合があります。 HANA L インスタンス ユニットを引き継いだら、修正プログラムを適用する必要があるかどうかを必ず確認してください。

  3. 3 番目の手順では、特定の OS のリリースやバージョンで SAP HANA をインストールして構成するために、関連する SAP Note を確認します。 推奨事項の変更や、個々のインストール シナリオに依存する SAP Note または構成の変更により、Microsoft では常に HANA Large Instance ユニットを完全に構成できるわけではありません。 そのため、お客様は実際の Linux リリースの SAP HANA に関連する SAP Note をお読みください。 また、OS のリリースやバージョンの構成を確認し、まだ構成設定を適用していない場合は適用します。 具体的には、以下のパラメーターを確認し、最終的に次のように調整してください。

    • net.core.rmem_max = 16777216
    • net.core.wmem_max = 16777216
    • net.core.rmem_default = 16777216
    • net.core.wmem_default = 16777216
    • net.core.optmem_max = 16777216
    • net.ipv4.tcp_rmem = 65536 16777216 16777216
    • net.ipv4.tcp_wmem = 65536 16777216 16777216

    SLES12 SP1 および RHEL 7.2 以降では、これらのパラメーターを /etc/sysctl.d ディレクトリにある構成ファイルで設定する必要があります。 たとえば、91-NetApp-HANA.conf という名前の構成ファイルを作成する必要があります。 それより前にリリースされた SLES と RHEL では、これらのパラメーターを /etc/sysctl.conf で設定する必要があります。 RHEL 6.3 以降のすべての RHEL リリースでは、/etc/modprobe.d/sunrpc-local.conf で、 sunrpc.tcp_slot_table_entries = 128 パラメーターを設定する必要があることに注意してください。 ファイルが存在しない場合は、そのファイルを最初に作成してから、sunrpc tcp_max_slot_table_entries=128 というエントリ オプションを追加する必要があります。

  4. 手順 4: HANA L インスタンス ユニットのシステム時刻をチェックします。 インスタンスは、システムのタイム ゾーンでデプロイされます。 このタイム ゾーンは、HANA L インスタンスのスタンプが位置する Azure リージョンの場所を表します。 インスタンスのシステム時刻やタイム ゾーンは、ユーザーが自由に変更できます。 テナントにインスタンスを追加注文する場合は、新たに提供されるインスタンスのタイム ゾーンを調整する必要があります。 Microsoft では、提供後にお客様がインスタンスに設定したシステム タイム ゾーンについては情報を持っていません。 したがって、新たにデプロイされたインスタンスのタイム ゾーンは、お客様が変更したタイムゾーンと異なる場合があります。 必要に応じて、お客様は渡されたインスタンスのタイム ゾーンを調整する必要があります。

  5. 手順 5: etc/hosts をチェックします。 ブレードが提供されるときには、さまざまな目的のために割り当てられた、さまざまな IP アドレスが設定されています。 etc/hosts ファイルを確認します。 既存のテナントにユニットが追加されるときには、新しくデプロイされたシステムの etc/hosts が、以前に提供されたシステムの IP アドレスを指定して正しく管理されていると思わないでください。 お客様は新しくデプロイされたインスタンスが、テナントで以前にデプロイしたユニットの名前を操作して解決できるようにする必要があります。

オペレーティング システム

重要

Type II ユニットの場合、現在は SLES 12 SP2 OS バージョンのみがサポートされています。

SAP Note #1999997 - FAQ: SAP HANA メモリに従って、配信される OS イメージのスワップ領域は 2 GB に設定されます。 異なる設定が必要な場合は、お客様ご自身で設定する必要があります。

SAP アプリケーション用の SUSE Linux Enterprise Server 12 SP1 は、SAP HANA on Azure (L インスタンス) 用にインストールされる Linux ディストリビューションです。 このディストリビューションでは、SAP 特有の機能を "そのままで使う" ことができます (SAP on SLES を効果的に実行するための事前設定されたパラメーターを含む)。

次の SAP サポート ノートは、SLES 12 に SAP HANA を実装する場合に適用されます。

あるいは、HANA Large Instances 上で Red Hat Enterprise Linux for SAP HANA (リリース 6.7 と 7.2) を実行する選択肢もあります。

次の SAP サポート ノートは、Red Hat 上で SAP HANA を実装する場合に適用されます。

時刻同期

SAP NetWeaver アーキテクチャを基盤として構築された SAP アプリケーションは、SAP システムを構成するさまざまなコンポーネントの時刻のずれの影響を受けやすくなっています。 このような違いについては、エラー タイトルが ZDATE_LARGE_TIME_DIFF の SAP ABAP ショート ダンプで示されています。

SAP HANA on Azure (L インスタンス) の場合、Azure で行われる時刻同期は、L インスタンス スタンプ内のコンピューティング ユニットには適用されません。 Azure ではシステム時刻が正しく同期されるため、ネイティブの Azure VM で SAP アプリケーションを実行する場合、この同期は適用されません。

そのため、Azure VM 上で実行されている SAP アプリケーション サーバーと、HANA Large Instances で実行されている SAP HANA データベース インスタンスで使用できるタイム サーバーを個別に設定する必要があります。 L インスタンス スタンプ内のストレージ インフラストラクチャの時刻は NTP サーバーと同期されます。

ネットワーク

どの HANA L インスタンス ユニットにも 2 ～ 3 個の IP アドレスが備わっており、それらのアドレスは 2 ～ 3 個の NIC ポートに割り当てられています。 HANA スケールアウト構成と HANA システム レプリケーション シナリオでは、3 つの IP アドレスが使用されます。

2 つの IP アドレスが割り当てられているユニットの区分は次にようになっています。

  • イーサネット "A" には、お客様が Microsoft に提出したサーバー IP プールのアドレス範囲から IP アドレスが割り当てられます。 OS の /etc/hosts には、この IP アドレスが記述されます。
  • イーサネット "C" には、NFS への通信に使用される IP アドレスが割り当てられます。 したがって、テナント内でインスタンスからインスタンスへのトラフィックを許可するために、これらのアドレスを etc/hosts で管理する必要はありません。

HANA システム レプリケーションまたは HANA スケールアウトのデプロイの場合、2 つの IP アドレスが割り当てられたブレード構成は適していません。 IP アドレスを 2 つだけ割り当てたうえで、そのような構成をデプロイする場合は、SAP HANA on Azure サービス管理に連絡して、3 つ目の VLAN で 3 つ目の IP アドレスを割り当ててください。 3 つの NIC ポートに 3 つの IP アドレスが割り当てられている HANA L インスタンス ユニットでは、次の使用規則が適用されます。

  • イーサネット "A" には、お客様が Microsoft に提出したサーバー IP プールのアドレス範囲から IP アドレスが割り当てられます。 そのため、この IP アドレスを OS の /etc/hosts で管理するために使ってはいけません。
  • イーサネット "B" だけが etc/hosts に記述され、さまざまなインスタンス間の通信に使用されます。 これらのアドレスは、HANA がノード間の構成に使用する IP アドレスとして、スケールアウト HANA 構成で保持する必要がある IP アドレスでもあります。
  • イーサネット "C" には、NFS ストレージへの通信に使用される IP アドレスが割り当てられます。 そのため、この種類のアドレスは、etc/hosts で管理することはできません。
  • イーサネット "D" は、ペースメーカー用 STONITH デバイスにアクセスするためにのみ使用する必要があります。 このインターフェイスは、HANA System Replication (HSR) を構成し、SBD ベースのデバイスを使用してオペレーティング システムで自動フェールオーバーを実現する場合に必要です。

ストレージ

SAP HANA on Azure (Large Instances) のストレージ レイアウトは、SAP が推奨するガイドラインに従う SAP HANA on Azure Service Management によって構成されます。 次の表に、ストレージ ボリュームの名前付け規則を示します (SID は HANA インスタンスの System ID であり、Tenant はテナントをデプロイするときの操作の内部列挙型です)。

ストレージの使用状況

マウント名

数量

HANA データ

/hana/data/SID/mnt0000<m>

Storage IP:/hana_data_SID_mnt00001_tenant_vol

HANA ログ

/hana/log/SID/mnt0000<m>

Storage IP:/hana_log_SID_mnt00001_tenant_vol

HANA ログ バックアップ

/hana/log/backups

Storage IP:/hana_log_backups_SID_mnt00001_tenant_vol

HANA 共有

/hana/shared/SID

Storage IP:/hana_shared_SID_mnt00001_tenant_vol/shared

usr/sap

/usr/sap/SID

Storage IP:/hana_shared_SID_mnt00001_tenant_vol/usr_sap

HANA usr/sap では同じボリュームが共有されます。 マウント ポイントの命名には、HANA インスタンスのシステム ID とマウント番号が含まれます。 スケールアップ配置には、mnt00001 のように、マウントは 1 つしか存在しません。 一方、スケールアウト配置では、ワーカー ノードと先頭ノードの数と同じ数のマウントがあります。

スケールアウト環境では、データ、ログ、ログ バックアップの各ボリュームが共有され、スケールアウト構成の各ノードに接続されます。 複数の SAP インスタンスである構成の場合、異なるボリューム セットが作成され、HANA L インスタンス ユニットに接続されます。

HANA Large Instance ユニットを確認すると、HANA/data 用の大容量のディスク ボリュームがユニットにあり、HANA/log/backup というボリュームがあることがわかります。 HANA/data が大きいのは、顧客に用意されるストレージ スナップショットで同じディスク ボリュームが使われているためです。 ストレージ スナップショットの実行が多いほど、割り当てられたストレージ ボリュームでスナップショットに使われる領域が増えます。

HANA/log/backup ボリュームは、データベース バックアップ用のボリュームになることは想定されていません。 そのサイズは、HANA トランザクション ログ バックアップ用のバックアップ ボリュームとして使用される設定となっています。 詳細については、「Azure での SAP HANA (L インスタンス) の高可用性とディザスター リカバリー」をご覧ください。

用意されているストレージに加えて、追加のストレージ容量を 1 TB 単位で購入することができます。 この追加ストレージは、新しいボリュームとして HANA L インスタンスに追加できます。

Azure Service Management で SAP HANA をオンボードしている際に、sidadm ユーザーと sapsys グループのユーザー ID (UID) とグループ ID (GID) を指定します (例: 1000、500)。 SAP HANA システムのインストール時には、これらと同じ値を使用する必要があります。 1 つのユニットに複数の HANA インスタンスをデプロイするために、複数のボリューム セット (インスタンスごとに 1 セット) を取得します。 そのため、デプロイ時には以下を定義する必要があります。

  • 各 HANA インスタンスの SID (sidadm はそれからから派生されます)。
  • 各 HANA インスタンスのメモリ サイズ。 インスタンスごとのメモリ サイズによって、個々のボリューム セットのボリュームのサイズが定義されます。

ストレージ プロバイダーの推奨事項に基づいて、マウントされるすべてのボリューム (ブート LUN を除く) に対して次のマウント オプションが構成されます。

nfs rw, vers=4, hard, timeo=600, rsize=1048576, wsize=1048576, intr, noatime, lock 0 0

これらのマウント ポイントは /etc/fstab で設定されます

L インスタンス スタンプ内のストレージ コントローラーとノードは NTP サーバーに同期されます。 SAP HANA on Azure (L インスタンス) のユニットと Azure VM を NTP サーバーに対して同期するときには、Azure と L インスタンス スタンプのインフラストラクチャやコンピューティング ユニットの間に大きな時間のずれがあってはいけません。

内部で使用されているストレージに対して SAP HANA を最適化するため、以下の SAP HANA 構成パラメーターを設定する必要があります。

  • max_parallel_io_requests 128
  • async_read_submit on
  • async_write_submit_active on
  • async_write_submit_blocks all

SAP Note #2267798 で説明されているように、SPS12 までの SAP HANA 1.0 バージョンでは、これらのパラメーターは、SAP HANA データベースのインストール時に設定できます。 SAP HANA データベースのインストール後に、hdbparam フレームワークを使ってパラメーターを構成することもできます。

HANA L インスタンスで使用されるストレージには、ファイル サイズの制限があります。 ファイルごとのサイズの制限は 16 TB です。 EXT3 ファイル システムのファイル サイズ制限とは異なり、HANA は、HANA L インスタンスのストレージによって強制されるストレージ制限を暗黙的に認識しません。 そのため、HANA では、ファイル サイズの上限である 16 TB に達しても、新しいデータ ファイルは自動的には作成されません。 HANA は 16 TB を超えるサイズへファイルを拡大しようとするため、HANA でエラーが報告され、最終的にはインデックス サーバーがクラッシュします。

HANA が HANA Large Instance のストレージにおける 16 TB のファイル サイズ制限を超えてデータ ファイルを拡張しないようにするには、SAP HANA の global.ini 構成ファイルで次のパラメーターを設定する必要があります

SAP HANA 2.0 では、hdbparam フレームワークが非推奨となりました。 この結果、これらのパラメーターは SQL コマンドを使用して設定する必要があります。 詳細については、SAP Note #2399079 を参照してください。

Note

SAP HANA on Azure (Large Instances) をデプロイする場合は、「SAP HANA (Large Instances) ネットワーク アーキテクチャ」に記載されている例外を考慮してください