Azure 仮想マシンのスケーリングに関する考慮事項を確認する
SAP アプリケーション サーバーとセントラル サービス クラスターは、インスタンスを追加することでスケールアップ/スケールダウンまたはスケールアウトできます。 AnyDB データベースはスケール アップまたはスケール ダウンできますが、スケール アウトはできません。AnyDB の SAP データベース コンテナーでは、シャーディングはサポートされていません。
SAP HANA のスケールアウト
Microsoft は、SAP HANA のスケールアウト構成として認定されている M シリーズ VM SKU を提供しています。 VM の種類である M128 は、最大 16 ノードのスケールアウトに対して認定を取得済みです。 16 ノードのスケールアウト認定の場合:
- 1 つのノードが先頭ノード
- 最大 15 個のノードがワーカー ノード
Azure VM でスケールアウト構成をデプロイするための最小の OS リリース要件は、次の通りです。
- SUSE Linux 12 SP3
- Red Hat Linux 7.4
Azure VM スケールアウト デプロイでは、サード パーティ ソリューションによって実装された NFS 共有を使用するスタンバイ ノードはサポートされていません。 なぜなら、現時点では、Azure にデプロイされたサード パーティのソリューションによって SAP HANA のストレージ待機時間の条件を満たすことができないためです。 つまり、/hana/data ボリュームと /hana/log ボリュームは共有できません。よって、SAP HANA のスタンバイ ノードはスケールアウト構成では使用できません。
SAP HANA スケールアウトにおける SUSE Linux VM ノードの基本的な構成には、次の特性があります。
- /hana/shared については、SUSE Linux 12 SP3 を基盤とした高可用性 NFS クラスターを構築します。 このクラスターは、スケールアウト構成と SAP NetWeaver または BW/4HANA セントラル サービスの /hana/shared NFS 共有をホストします。
- その他のディスク ボリュームはすべて、異なるノード間では共有されず、NFS に基づきません。
ノードのボリュームのサイズ調整は、/hana/shared 以外ではスケールアップと同じです。 M128 の VM SKU の場合、推奨されるサイズと種類は次の通りです。
VM の SKU
RAM
最大 VM の I/O スループット
/hana/data
/hana/log
/root ボリューム
/usr/sap
hana/backup
M128s
2000 GiB
2000 MB/秒
3 x P30
2 x P20
1 x P6
1 x P6
2 x P40
HANA 固有ボリュームのストレージ スループットが、実行するワークロードの要件を満たしていることを確認します。 ワークロードで、より大きなボリュームを /hana/data および /hana/log に必要とする場合は、Azure Premium Storage ディスクの数を増やす必要があります。 ディスクを追加すると、Azure VM のサイズに応じた制限内で、IOPS と I/O スループットが向上します。 また、/hana/log ボリュームを構成するディスクで、Azure 書き込みアクセラレータが有効になっていることを確認します。
SAP では、4 つのワーカー ノードそれぞれについて、1 つのワーカー ノードのメモリ サイズの倍数でスケールアウトするために、/hana/shared ボリュームのサイズを定義する数式が提供されています。 約 2 TB のメモリを備えた SAP HANA スケールアウト認定 M128s Azure VM を使用する場合の、SAP の推奨事項は以下のようにまとめることができます。
- 4 個以下のワーカー ノードに対しては、2 TB サイズの /hana/shared ボリューム
- 5 から 8 個のワーカー ノードに対しては、4 TB サイズの /hana/shared ボリューム
- 9 から 11 個のワーカー ノードに対しては、6 TB サイズの /hana/shared ボリューム
- 12 から 15 個のワーカー ノードに対しては、8 TB サイズの /hana/shared ボリューム
SAP では、ネットワークの観点から、HANA ノード間の通信からクライアント/アプリケーションの通信トラフィックを分離することを強くお勧めしています。 これは、2 つの異なる vNIC を VM に接続することで実現できます。 これらの vNIC は異なるサブネットにあり、異なる IP アドレスを持つようにします。 次に、NSG とユーザー定義のルートを使用してトラフィックのフローを制御します。
Azure では、特定の vNIC にサービス品質とクォータを適用する機能は提供していません。 よって、クライアント/アプリケーションの通信とノード内通信を分離しても、1 つのトラフィック ストリームを他のストリームに優先して処理するメカニズムはありません。 その代わりに、分離によって、スケールアウト構成のノード内通信の不可視化によりセキュリティ レベルが向上します。 ネットワーク パフォーマンスを最適化するには、以下の点も考慮する必要があります。
- /hana/shared へのトラフィックは中程度であるため、最小構成でクライアント ネットワークに割り当てられている vNIC を通してこれをルーティングします。
- 最終的に、/hana/shared へのトラフィックに対しては、SAP HANA スケールアウト構成をホストする仮想ネットワーク内で 3 番目のサブネットを作成し、そのサブネット内でホストされる 3 番目の vNIC を割り当てます。 NFS 共有へのトラフィックでは、その第 3 の vNIC と、関連付けられている IP アドレスを使用します。 これで、別個のアクセス規則とルーティング規則を適用できるようになります。
SAP HANA 構成間で高可用性 NFS クラスターを共有したい場合は、これらすべての HANA 構成を同じ仮想ネットワーク内に移動します。