次の方法で共有

SAP ワークロードのための Azure Virtual Machines 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 に関連したものです。

Note 番号 タイトル
1928533 SAP applications on Azure: Supported products and Azure VM types (Azure 上の SAP アプリケーション: サポートされる製品と Azure VM の種類)
2015553 SAP on Microsoft Azure:Support prerequisites (Microsoft Azure 上の SAP: サポートの前提条件)
1999351 Troubleshooting enhanced Azure monitoring for SAP (強化された Azure Monitoring for SAP のトラブルシューティング)
2178632 Key monitoring metrics for SAP on Microsoft Azure (Microsoft Azure 上の SAP 用の主要な監視メトリック)
1409604 Virtualization on Windows:Enhanced monitoring (Azure を使用した Linux 上の SAP: 拡張された監視機能)
2191498 SAP on Linux with Azure:Enhanced monitoring (Azure を使用した Linux 上の SAP: 拡張された監視機能)
2039619 SAP applications on Microsoft Azure using the Oracle database:Supported products and versions (Oracle データベースを使用した Microsoft Azure 上の SAP アプリケーション: サポートされている製品とバージョン)
2233094 DB6:SAP applications on Azure using IBM DB2 for Linux, UNIX, and Windows: 関連情報
2243692 Linux on Microsoft Azure (IaaS) VM:SAP license issues (Microsoft Azure (IaaS) VM 上の Linux: SAP ライセンスの問題)
2578899 SUSE LINUX Enterprise Server 15: インストールに関する注記
1984787 SUSE LINUX Enterprise Server 12:インストールに関する注記
2772999 Red Hat Enterprise Linux 8.x: インストールと構成
2002167 Red Hat Enterprise Linux 7.x:インストールとアップグレード
2069760 Oracle Linux 7.x SAP installation and upgrade (Oracle Linux 7.x SAP のインストールとアップグレード)
1597355 Linux のスワップ領域に関する推奨事項
2799900 Oracle Database 19c のセントラル テクニカル ノート
2171857 Oracle Database 12c: File system support on Linux (Oracle Database 11g: Linux でのファイル システムのサポート)
1114181 Oracle Database 11g: File system support on Linux (Oracle Database 11g: Linux でのファイル システムのサポート)
2969063 Azure 上の HCMT でのマイクロコード検証の失敗
3246210 Azure - 一部のディスク パフォーマンス テストでの HCMT の失敗

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

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

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

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

この章に進むにあたって、以下に記載されている情報を読んで理解しておいてください。

Azure ブロック ストレージについては、Azure マネージド ディスクの使用が必須です。 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 ワークロードの Azure Storage の種類」を参照してください。 特に SAP HANA については、「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 つの制限は、たとえば Premium Storage を使用できるのは、特定の種類の VM のみであることです。 通常は、CPU とメモリの要件に基づいて、使用する特定の VM の種類を決定します。 また、通常、Premium Storage ディスク v1 のディスク数や種類に応じてスケーリングされる IOPS、待ち時間、およびディスク スループットの要件も考慮する必要があります。 特に Premium Storage v1 では、各ディスクで実現する必要がある IOPS とスループットの値によってディスクのサイズも決まる場合があります。 Premium Storage v2 または Ultra ディスクでは、ディスク容量に関係なく、プロビジョニングされた IOPS とスループットを選択できます。

注意

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

注意

Azure の単一 VM の SLA を最大化するには、接続されているすべてのディスクの種類が Azure Premium Storage (v1 または v2) または Azure Ultra ディスクである必要があります。これには、ベース VHD (Azure Premium Storage) が含まれます。

注意

SAP データベースが配置されているストレージ ハードウェアが、Azure データセンターに隣接して併置されているサードパーティ データセンター内にある場合は、その SAP データベースのメイン データベース ファイル (データ ファイルやログ ファイルなど) をホストすることはできません。 Azure VM でホストされているソフトウェア アプライアンスを通じて提供されるストレージも、このユース ケースではサポートされていません。 SAP DBMS ワークロードの場合、SAP データベースのデータおよびトランザクション ログ ファイル用にサポートされるストレージは、一般的にはネイティブ Azure サービスとして表現されるストレージに限られます。 異なる DBMS では、それぞれ異なる種類の Azure Storage がサポートされる場合があります。 詳細については、「SAP ワークロードの Azure Storage の種類」の記事を参照してください。

データベース ファイル、ログおよび再実行ファイルの配置と、使用する Azure Storage の種類は、IOPS、待ち時間、スループットの要件に従って決まります。 特に Azure Premium Storage v1 で十分な IOPS を確保するには、複数のディスクを使用するか、大容量の Premium Storage ディスクを使用しなければならない場合があります。 複数のディスクを使用する場合は、データ ファイルか、ログおよび redo ファイルが含まれるディスク全体にソフトウェア ストライプを構築します。 この場合、結果のストライプ セットでは、基になる Premium Storage ディスクの IOPS およびディスク スループット SLA、または Standard Storage ディスクの達成可能な最大 IOPS が累積的になります。

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

Windows ストレージ ストライピング Windows

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

Linux ストレージ ストライピング Linux

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

Azure Premium Storage v2 および Ultra ディスクの場合、ディスクのサイズに依存しない IOPS およびディスク スループットを定義できるため、ストライピングは必要ありません。

注意

Azure Storage には VHD の 3 つのイメージが保存されるため、ストライプ化するときに冗長性を構成することには意味がありません。 必要なのは、I/O が異なる VHD に分散されるようにストライピングを構成することだけです。

マネージド ディスクか非マネージド ディスクか

Azure ストレージ アカウントは、管理の構成要素であり、制限の対象でもあります。 機能と制限については、Azure Storage のスケーラビリティとパフォーマンスのターゲットに関するページをご覧ください。 Standard Storage の場合、ストレージ アカウントごとに IOPS の制限があることに注意してください。 Azure Storage のスケーラビリティとパフォーマンスのターゲットに関する記事で、合計要求レートを含む行を参照してください。 Azure サブスクリプションあたりのストレージ アカウント数には初期制限もあります。 2017 年、Azure では、ストレージ アカウントの管理を軽減する Azure Managed Disks の概念が導入されました。 Azure マネージド ディスクの使用は、Azure へ SAP ワークロードをデプロイする既定の手段です。

重要

Azure Managed Disks の利点を考えると、一般の DBMS デプロイと SAP デプロイには Azure Managed Disks を使用することが必須です。

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

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

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

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

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

Azure Premium Storage v1 については、次のキャッシュ オプションが存在します。

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

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

Note

一部の新しい M(b)v3 VM の種類では、読み取りキャッシュ Premium SSD v1 ストレージを使用すると、読み取りキャッシュを使用しない場合よりも読み取りと書き込みの IOPS レートとスループットが低下する可能性があります。

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

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

Azure の非永続的ディスク

Azure VM は、VM がデプロイされた後に非永続ディスクを提供します。 VM が再起動された場合、これらのドライブ上のすべてのコンテンツが消去される可能性があります。データ ファイルのほか、データベースのログおよび再実行ファイルは、どんな状況でもこれらのドライブに保存してはいけません。 例外として、データベースによっては、tempdb や temp テーブルスペースなどにこれらの非永続ドライブが適している場合があります。

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

Windows の非永続ディスク Windows

Azure VM の D ドライブは、Azure の計算ノード上のいくつかのローカル ディスクによってサポートされる非永続ドライブです。 これは非永続的であるため、ドライブ D の内容に加えられた変更は、VM を再起動すると失われます。 "変更" には、保存されたファイル、作成されたディレクトリ、インストールされたアプリケーションが含まれます。

Linux の非永続ディスク 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 のレプリケーション」をご覧ください。

注意

Azure Premium Storage v1 と v2、Ultra ディスク、および Azure NetApp Files は、DBMS VM と、データベース、ログ、および再実行のファイルを格納するディスクに推奨される種類のストレージです。 Premium Storage v1 を除き、これらの種類のストレージで使用できる冗長化の方法は LRS のみです。 そのため、別の Azure リージョンまたは可用性ゾーンへのデータベース データのレプリケーションを有効にするようにデータベースの方式を構成する必要があります。 データベースの方式には、SQL Server Always On、Oracle Data Guard、および HANA システム レプリケーションがあります。

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 ルールがあります。 ネットワーク トラフィックを分離または隔離するのは、ルーティングのための 1 つの手段です。 ネットワーク スループットのクォータを設定するためには使用されません。

注意

Azure を介して静的 IP アドレスを割り当てるということは、それらを個々の仮想 NIC に割り当てるということです。 ゲスト OS 内の静的 IP アドレスを仮想 NIC に割り当てないでください。 Azure Backup のような一部の Azure サービスは、少なくともゲスト OS のプライマリ仮想 NIC が静的 IP アドレスではなく DHCP に設定されているという事実に依存します。 詳細については、「Azure 仮想マシンのバックアップのトラブルシューティング」を参照してください。 複数の静的 IP アドレスを 1 つの VM に割り当てるには、複数の仮想 NIC を VM に割り当てます。

警告

SAP NetWeaver、Hybris、または S/4HANA ベースの SAP システムの DBMS レイヤーと SAP アプリケーションの間の通信パスにネットワーク仮想アプライアンスを構成することはサポートされていません。 この制限は、機能およびパフォーマンス上の理由からです。 SAP アプリケーション レイヤーと DBMS レイヤーの間の通信パスは、直接的なものである必要があります。 アプリケーション セキュリティ グループ (ASG) および NSG ルールで直接通信パスが許可されている場合、この制限にこれらの Azure ASG および NSG ルールは含まれません。 これには、DBMS データと再実行ログ ファイルをホストする NFS 共有へのトラフィックも含まれます。

ネットワーク仮想アプライアンスがサポートされないその他のシナリオは次のとおりです。

通信パスにネットワーク仮想アプライアンスがあると、2 つの通信パートナー間のネットワーク待ち時間が容易に倍増する可能性があります。 また、SAP アプリケーション レイヤーと DBMS レイヤーの間のクリティカル パスのスループットが制限される場合もあります。 一部の顧客シナリオでは、ネットワーク仮想アプライアンスが原因で Pacemaker Linux クラスターに障害が発生することがあります。 Linux Pacemaker クラスター ノード間の通信において、ネットワーク仮想アプライアンス経由で SBD デバイスと通信する場合があります。

重要

サポートされて "いない" もう 1 つの設計は、SAP アプリケーション レイヤーと DBMS レイヤーを、相互にピアリングされていない異なる Azure 仮想ネットワークに分離することです。 異なる Azure 仮想ネットワークを使用するのではなく、Azure 仮想ネットワーク内のサブネットを使用して SAP アプリケーション レイヤーと DBMS レイヤーを分離することをお勧めします。

推奨事項に従わず、代わりに 2 つのレイヤーを異なる仮想ネットワークに分離する場合は、2 つの仮想ネットワークをピアリングする必要があります。

2 つのピアリングされた Azure 仮想ネットワーク間のネットワーク トラフィックは転送コストの影響を受ける点に注意してください。 SAP アプリケーション レイヤーと DBMS レイヤーの間で、数テラバイトもの膨大な量のデータが交換されます。 SAP アプリケーション レイヤーと DBMS レイヤーが 2 つのピアリングされた Azure 仮想ネットワーク間で分離されている場合、相当なコストが蓄積される可能性があります。

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

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

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

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

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

注意

パブリック IP アドレスのアクセスに関連する Basic SKU と Standard SKU の動作には違いがあります。 パブリック IP アドレスにアクセスするために Standard SKU の制限事項を回避する方法については、「SAP の高可用性シナリオにおける Azure Standard Load Balancer を使用した Virtual Machines のパブリック エンドポイント接続」のドキュメントを参照してください。

ホスト監視のデプロイ

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

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

次のステップ

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