SAP ワークロード用の Azure 仮想マシン DBMS デプロイに関する考慮事項

このガイドは、Microsoft Azure 上で SAP ソフトウェアを実装およびデプロイする方法に関するドキュメントの一部です。 このガイドを読む前に、計画および実装ガイドと、計画ガイドに記載されている記事をお読みください。 このドキュメントでは、Azure サービスとしてのインフラストラクチャ (IaaS) 機能を使用した Microsoft Azure 仮想マシン (VM) での SAP 関連のデータベース管理システム (DBMS) の一般的なデプロイの側面について説明します。

特定のプラットフォームに SAP ソフトウェアをインストールしてデプロイするときの主要なリソースである SAP インストール ドキュメントと SAP Note を補足する内容となっています。 このドキュメントでは、Azure VM で SAP 関連 DBMS システムを実行する際の考慮事項について説明します。 このドキュメントでは、特定の DBMS システムについてはほとんど言及していません。 その代わり、特定の DBMS システムについては、他のデータベース システム固有のドキュメントで扱います。

Azure 上の SAP ワークロードに関するさまざまな記事があります。 Azure 上の SAP ワークロードの作業の開始に関するページをまず確認してから、興味のある領域を選択してください。

次の SAP Note は、このドキュメントで扱う領域に関する SAP on Azure に関連したものです。

Linux に関するすべての SAP Note については、SAP コミュニティ wiki を参照してください。

Microsoft Azure のアーキテクチャと Microsoft Azure 仮想マシンのデプロイおよび操作方法に関する実用的な知識が必要です。 詳細については、Azure のドキュメントを参照してください。

一般的に、Windows、Linux、および DBMS のインストールと構成は、オンプレミスに設置する仮想マシンまたはベア メタル マシンと本質的に同じです。 Azure IaaS を使用する場合、アーキテクチャおよびシステム管理の実装の決定については異なる部分があります。 このドキュメントでは、Azure IaaS を使用する場合に知っておくべき特定のアーキテクチャおよびシステム管理の相違について説明します。

RDBMS デプロイ用の VM のストレージ構造

この章に従うには、次に示す情報をお読みください。

• SAP NetWeaver のための Azure Virtual Machines の計画と実装
• SAP ワークロードの Azure Storage の種類
• Azure デプロイでサポートされている SAP ソフトウェア
• Azure 仮想マシンの SAP ワークロードでサポートされるシナリオ

Azure ブロック ストレージの場合、Azure Managed Disks の使用は必須です。 Azure Managed Disks の詳細については、Azure VM のマネージド ディスクの概要に関する記事を参照してください。

基本的な構成では、通常、オペレーティング システム、DBMS、および最終的に導入する SAP バイナリとデータベース ファイルとを分けたデプロイ構造にすることをお勧めしています。 以下に Azure ディスクを別に用意することをお勧めします。

• オペレーティング システム (ベース VHD または OS VHD)
• データベース管理システムの実行可能ファイル
• /usr/sap のような SAP 実行可能ファイル
• DBMS データ ファイル
• DBMS 再実行ログ ファイル

これらのコンポーネントを 5 つの異なるボリュームに分離する構成では、回復性が高くなる可能性があります。 VM ストレージのクォータと制限を超えない限り、1 つのボリュームでの過剰な使用が他のボリュームの使用を妨げるわけではありません。

DBMS データ、トランザクション、再実行ログ ファイルは、Azure でサポートされているブロック ストレージまたは Azure NetApp Files に格納されます。 Azure Files または Azure Premium Files は、SAP ワークロードの DBSM データや再実行ログ ファイルのストレージとしてサポートされていません。 これらは別個のディスクに格納され、元の Azure オペレーティング システム イメージ VM に論理ディスクとして接続されます。 Linux のデプロイでは、異なる推奨事項がドキュメント化されています。 シナリオのさまざまな ストレージの種類 (特に SAP HANA) の機能とサポートについては、SAP ワークロード用の Azure Storage の種類に関する記事を参照してください。 SAP HANA Azure 仮想マシンのストレージ構成に関するページを参照してください。

ディスクのレイアウトを計画するときは、次の項目間で最適なバランスを取る必要があります。

• データ ファイルの数。
• ファイルが含まれているディスクの数。
• 1 つのディスクまたは NFS 共有の IOPS クォータ。
• ディスクまたは NFS 共有ごとのデータ スループット。
• VM サイズごとに可能な追加データ ディスクの数。
• VM が提供できるストレージまたはネットワークの全体的なスループット。
• さまざまな種類の Azure Storage で考えられる待機時間。
• VM ストレージの IOPS とスループット クォータ。
• NFS を使用している場合の VM ネットワーク クォータ - NFS 共有へのトラフィックは、ストレージ クォータ ではなく VM のネットワーク クォータに対してカウントされます。
• VM の SLA。

Azure によってデータ ディスクまたは NFS 共有ごとに IOPS クォータが適用されます。 これらのクォータは、別の Azure ブロック ストレージ ソリューションまたは共有でホストされているディスクでは異なります。 また、I/O 待機時間は、これらの異なる種類のストレージ間でも異なります。

VM の種類ごとに、接続できるデータ ディスクの数が制限されています。 もう 1 つの制限は、Azure Premium Storage など、特定の VM の種類のみを使用できることです。 通常は、CPU とメモリの要件に基づいて、使用する特定の VM の種類を決定します。 また、通常はディスクの数または Azure Premium Storage ディスク v1 の種類でスケーリングされる IOPS、待機時間、ディスク スループットの要件も考慮する必要があります。 各ディスクで達成される IOPS とスループットの数によって、ディスク サイズが決まる場合があります (特に Azure Premium Storage v1 の場合)。 Azure Premium Storage v2 または Ultra Disk では、ディスク容量に関係なく、プロビジョニングされた IOPS とスループットを選択できます。

DBMS デプロイでは、データ、トランザクション ログ、または再実行ファイルに対して、Azure Premium Storage (v1 および v2)、Ultra Disk、または Azure NetApp Files ベースの NFS 共有を強くお勧めします。 デプロイするシステムが運用環境システムか非運用システムかは重要ではありません。 Azure Standard HDD または SSD の待機時間は、どの種類の運用システムでも受け入れられません。

IOPS、待機時間、スループットの要件によって、データベース ファイル、ログ、再実行ファイルが配置される場所と、使用される Azure ストレージの種類が決まります。 特に Azure Premium Storage v1 では、十分な IOPS を実現するために、複数のディスクを使用するか、より大きな Azure Premium Storage ディスクを使用する必要があります。 複数のディスクを使用する場合は、データ ファイルか、ログおよび redo ファイルが含まれるディスク全体にソフトウェア ストライプを構築します。 このような場合、ストライプ セットは、Premium ディスクの IOPS とスループットの保証を組み合わせたものです。 Standard ディスクの場合、使用可能な合計最大 IOPS が使用されます。

IOPS 要件が 1 つの VHD で提供できる要件を超える場合は、複数の VHD 間でデータベース ファイルに必要な IOPS のバランスを取ります。 IOPS 負荷を複数のディスクに分散する最も簡単な方法は、異なるディスク間でソフトウェア ストライプを構築することです。 次に、ソフトウェア ストライプから切り出された LUN に SAP DBMS のいくつかのデータ ファイルを配置します。 ストライプ内のディスクの数は、必要な IOPS、スループット、ボリュームの合計容量によって異なります。

Windows

Windows 記憶域スペースを使用して複数の Azure VHD にわたってストライプ セットを作成することをお勧めします。 Windows Server 2012 R2 または Windows Server 2016 以上を使用してください。

Linux

Linux 上でのソフトウェア RAID の構築がサポートされているのは、MDADM および論理ボリューム マネージャー (LVM) のみです。 詳細については、次を参照してください。

• MDADM を使用して Linux 上にソフトウェア RAID を構成する
• LVM を使用して Azure 内の Linux VM 上に LVM を構成する

Azure Premium Storage v2 と Ultra Disk の場合、ディスクのサイズに関係なく IOPS とディスク スループットを定義できるため、ストライピングは必要ない場合があります。

マネージド ディスクとアンマネージド ディスク

Azure ストレージ アカウントは、管理の構成要素であり、制限の対象でもあります。 機能と制限については、Azure Storage のスケーラビリティとパフォーマンスのターゲットに関するページをご覧ください。 Standard Storage の場合、ストレージ アカウントごとに IOPS の制限があることに注意してください。 Azure Storage のスケーラビリティとパフォーマンスのターゲットに関する記事で、合計要求レートを含む行を参照してください。 Azure サブスクリプションあたりのストレージ アカウント数には初期制限もあります。

2017 年の時点で、Azure は Azure Disk Storage の概念を導入しました。この概念により、ストレージ アカウントの管理を軽減できます。 Azure Managed Disks の使用は、Azure で SAP ワークロードにデプロイするための既定の設定です。

マネージド ディスクをまだ使用していない SAP ワークロードがある場合、アンマネージド ディスクからマネージド ディスクに変換するには、以下を参照してください。

• Windows 仮想マシンをアンマネージド ディスクからマネージド ディスクに変換する。
• Linux 仮想マシンをアンマネージド ディスクからマネージド ディスクに変換する。

VM とデータ ディスクのキャッシュ

ディスクを VM にマウントする場合、Azure ストレージに配置されたこれらのディスクと VM 間の I/O トラフィックをキャッシュするかどうかを選択できます。

以下に示す推奨事項は、次のような標準 DBMS の I/O 特性を前提にしています。

• これは、ほとんどの場合、データベースのデータ ファイルに対する読み取りワークロードです。 これらの読み取りは、DBMS システムのパフォーマンスにとって重要です。
• データ ファイルに対する書き込みは、チェックポイントまたは一定のストリームに基づいてバーストで実行されます。 1 日の平均書き込み量は、読み取り量よりも少なくなります。 データ ファイルからの読み取りとは反対に、これらの書き込みは非同期で実行され、ユーザー トランザクションに悪影響を与えません。
• トランザクション ログまたは再実行ファイルからの読み取りはほとんどありません。 例外は、トランザクション ログ バックアップを実行するときのサイズの大きな I/O です。
• トランザクションまたは redo ログ ファイルに対する主な負荷は、書き込みです。 ワークロードの性質に応じて、I/O サイズを 4 KB まで小さくしたり、1 MB 以上にしたりできます。
• すべての書き込みを信頼性の高い方法でディスク上に保存する必要があります。

Azure Premium Storage v1 には、次のキャッシュ オプションがあります。

• なし
• 読む
• 読み取り/書き込み
• なし + 書き込みアクセラレータ (Azure M シリーズ VM の場合のみ)
• 読み取り + 書き込みアクセラレータ (Azure M シリーズ VM の場合のみ)

Azure Premium Storage v1 の場合は、SAP データベースの データ ファイルに対して読み取りキャッシュを 使用し、 ログ ファイルのディスクにキャッシュなしを選択することをお勧めします。

M シリーズのデプロイでは、ログ ファイルのディスクにのみ Azure 書き込みアクセラレータを使用することをお勧めします。 Azure 書き込みアクセラレータの詳細、制限、およびデプロイについては、「書き込みアクセラレータを有効にする」を参照してください。

Azure Premium Storage v2、Ultra Disk、Azure NetApp Files の場合、キャッシュ オプションは提供されません。

Azure 非永続的ディスク

Azure VM は、VM のデプロイ後に非永続的ディスクを提供します。 VM が再起動すると、それらのドライブ上のすべてのコンテンツを消去できます。データベースのデータ ファイルとログ ファイルとやり直しファイルは、それらの非永続ドライブに配置しないでください。 一部のデータベースでは例外が発生する可能性があり、これらの非永続ドライブは tempdb と一時テーブルスペースに適している可能性があります。

詳細については、Azure の Windows VM 上の一時ドライブの解説に関するページを参照してください。

Windows

ドライブ D: Azure VM 内の非永続的ドライブは、Azure コンピューティング ノード上の一部のローカル ディスクによってサポートされます。 非永続的であるため、ドライブ D: のコンテンツに加えられた変更は、VM の再起動時に失われます。 "変更" には、保存されたファイル、作成されたディレクトリ、インストールされたアプリケーションが含まれます。

Linux

Linux Azure VM は、Azure コンピューティング ノード上のローカル ディスクによってサポートされる非永続的ドライブである /mnt/resource にドライブを自動的にマウントします。 非永続的であるため、 /mnt/resource 内のコンテンツに加えられた変更は、VM の再起動時に失われます。 "変更" には、保存されたファイル、作成されたディレクトリ、インストールされたアプリケーションが含まれます。

Microsoft Azure Storage の回復性

Microsoft Azure Storage は、ベース VHD を、OS のほか、接続されているディスクまたは BLOB と共に、3 つ以上の別個のストレージ ノードに格納します。 この種類のストレージは、ローカル冗長ストレージ (LRS) と呼ばれます。 LRS は、Azure 内のすべての種類のストレージの既定値です。

これ以外にも冗長化の方法があります。 詳細については、「Azure Storage のレプリケーション」をご覧ください。

VM ノードの回復性

Azure では、VM に複数の異なる SLA を提供しています。 詳細については、「Virtual Machines の SLA」の最新リリースを参照してください。 DBMS レイヤーは、SAP システムにおける可用性にとって非常に重要であるため、さまざまなデプロイの種類とメンテナンス イベントについて理解しておく必要があります。 これらの概念の詳細については、Azure での仮想マシンの可用性の管理に関する記事を参照してください。

SAP ワークロードを含む運用 DBMS シナリオの最小推奨事項は、次のとおりです。

• 選択したデプロイの種類を使用して、2 つの VM を同じ Azure リージョンにデプロイします。
• これら 2 つの VM を同じ Azure 仮想ネットワーク内で実行し、同じサブネットの NIC を接続します。
• 2 つ目の VM のホット スタンバイを維持するためにデータベース方法を使用します。 方法としては、SQL Server Alwayson、Oracle Data Guard、または HANA システム レプリケーションを使用することができます。

別の Azure リージョンに 3 番目の VM をデプロイし、同じデータベース方式を使用して別の Azure リージョンに非同期レプリカを提供することもできます。

Azure ネットワークに関する考慮事項

大規模な SAP のデプロイでは、Azure 仮想データセンターのブループリントを使用します。 これを、仮想ネットワークの構成や、組織のさまざまな部分に対するアクセス許可とロールの割り当てに使用します。

これらのベスト プラクティスは、数千件もの顧客デプロイの結果です。

• SAP アプリケーションがデプロイされている仮想ネットワークは、インターネットにアクセスできません。
• データベース VM は、アプリケーション層と同じ仮想ネットワーク内で実行され、SAP アプリケーション層とは別のサブネットに分離されます。
• 仮想ネットワーク内の VM には、プライベート IP アドレスが静的に割り当てられます。 詳しくは、「Azure における IP アドレスの種類と割り当て方法」をご覧ください。
• DBMS VM を出入りする際のルーティングの制限は、ローカルの DBMS VM にインストールされているファイアウォールでは設定 "されません"。 代わりに、トラフィック ルーティングはネットワーク セキュリティ グループ (NSG) を使用して定義されます。
• DBMS VM へのトラフィックを分離および隔離するには、異なる NIC を VM に割り当てます。 各 NIC は異なる IP アドレスを取得し、異なる仮想ネットワーク サブネットに割り当てられます。 サブネットごとに異なる NSG ルールがあります。 ネットワーク トラフィックの分離または分離はルーティングの尺度であり、ネットワーク スループットのクォータの設定には使用されません。

Azure Load Balancer を使用してトラフィックをリダイレクトする

SQL Server Always On または HANA システム レプリケーションなどの機能でプライベート仮想 IP アドレスを使用するには、Azure Load Balancer の構成が必要です。 ロード バランサーは、プローブ ポートを使用して、アクティブな DBMS ノードを特定し、そのアクティブなデータベース ノードにのみトラフィックをルーティングします。

データベース ノードでフェールオーバーが発生した場合、SAP アプリケーションを再構成する必要はありません。 代わりに、最も一般的な SAP アプリケーション アーキテクチャにより、プライベート仮想 IP アドレスに再接続されます。 その一方で、ロード バランサーはノードのフェールオーバーに反応して、プライベート仮想 IP アドレスへのトラフィックを 2 番目のノードにリダイレクトします。

Azure には、Basic SKU と Standard SKU という 2 つの異なる ロード バランサー SKU が用意されています。 セットアップと機能の利点に基づいて、Azure ロード バランサーの Standard SKU を使用する必要があります。 Standard バージョンのロード バランサーの大きな利点の 1 つは、データ トラフィックがロード バランサー自体を経由してルーティングされないことです。

内部ロード バランサーを構成する方法の例については、「 チュートリアル: Azure Virtual Machines で SQL Server 可用性グループを手動で構成する」を参照してください。

ホスト監視のデプロイ

Azure 仮想マシンの運用環境で SAP アプリケーションを使用する場合、SAP には Azure 仮想マシンを実行している物理ホストからホスト監視データを取得する機能が必要です。 SAPOSCOL および SAP Host Agent でこの機能を有効にする、特定の SAP Host Agent パッチ レベルが必要になります。 正確なパッチ レベルは SAP Note 1409604に記載されています。

ホストのデータを SAPOSCOL および SAP Host Agent に配信するコンポーネントのデプロイと、それらのコンポーネントのライフサイクル管理の詳細については、SAP ソリューション用 Azure VM 拡張機能の実装に関する記事を参照してください。

次のステップ

特定の DBMS については、以下を参照してください。

• SAP ワークロードのための SQL Server Azure Virtual Machines DBMS のデプロイ
• SAP ワークロードのための Oracle Azure Virtual Machines DBMS のデプロイ
• SAP ワークロードのための IBM DB2 Azure Virtual Machines DBMS のデプロイ
• Pacemaker による SUSE Linux Enterprise Server 上の Azure VM での IBM Db2 LUW の高可用性
• Red Hat Enterprise Linux Server 上の Azure VM での IBM Db2 LUW の高可用性
• SAP ワークロードのための SAP ASE Azure Virtual Machines DBMS のデプロイ
• Azure での SAP MaxDB、Live Cache、Content Server のデプロイ
• SAP HANA on Azure 運用ガイド
• SAP HANA Azure 仮想マシンのストレージ構成
• Azure 仮想マシンの SAP HANA の高可用性
• Azure 仮想マシン上の SAP HANA のバックアップ ガイド
• Azure 上で SAP IQ を使用した SAP BW NLS の実装ガイド