Azure のファイル共有を使用して Windows フェールオーバー クラスター上の SAP ASCS/SCS インスタンスをクラスター化する
Windows
Windows Server フェールオーバー クラスタリングは、Windows での高可用性の SAP ASCS/SCS インストールと DBMS の基盤です。
フェールオーバー クラスターとは、アプリケーションとサービスの可用性を高めるために連携する、1 + n 台の独立したサーバー (ノード) のグループです。 ノード障害が発生した場合、Windows Server フェールオーバー クラスタリングは、アプリケーションとサービスを提供するクラスターを正常な状態で維持するうえで許容できるエラーの数を計算します。 フェールオーバー クラスタリングを実現するために、さまざまなクォーラム モードを選択できます。
前提条件
この記事で説明するタスクを開始する前に、以下の記事および SAP Note を確認してください。
- SAP NetWeaver のための Azure Virtual Machines 高可用性のアーキテクチャとシナリオ
- SAP Note 1928533、これには次が含まれます。
- SAP ソフトウェアのデプロイでサポートされる Azure VM サイズの一覧
- Azure VM サイズの容量に関する重要な情報
- サポートされる SAP ソフトウェア、およびオペレーティング システム (OS) とデータベースの組み合わせ
- Microsoft Azure 上の Windows に必要な SAP カーネル バージョン
- SAP Note 2015553: SAP でサポートされる Azure 上の SAP ソフトウェア デプロイの前提条件が記載されています。
- SAP Note 2178632: Azure 上の SAP について報告されるすべての監視メトリックに関する詳細情報が記載されています。
- SAP Note 1999351: Azure Enhanced Monitoring Extension for SAP に関するその他のトラブルシューティング情報が記載されています。
- SAP Note 2287140 は、SMB 3.x プロトコルの SAP でサポートされている CA 機能の前提条件を一覧表示しています。
- SAP Note 2802770 には、Windows 2012 および 2016 で低速で実行されている SAP トランザクション AL11 のトラブルシューティング情報が含まれています。
- SAP Note 1911507 には、SMB 3.0 プロトコルを使用した Windows Server 上のファイル共有の透過的なフェールオーバー機能に関する情報が含まれています。
- SAP Note 662452 には、データ アクセス中のファイル システムのパフォーマンスやエラーの低さに対処するための推奨事項 (8.3 名前の生成を非アクティブ化) があります。
- Windows フェールオーバー クラスターへの SAP NetWeaver 高可用性のインストールおよび Azure 上での SAP ASCS/SCS インスタンスのファイル共有
Note
ファイル共有を使用した SAP ASCS/SCS インスタンスのクラスタリングは、SAP Kernel 7.22 (以降) を使用する SAP システムでサポートされています。 詳細については、SAP Note 2698948 を参照してください
Azure での Windows Server フェールオーバー クラスタリング
ベア メタル デプロイやプライベート クラウド デプロイと比較すると、Azure Virtual Machines では Windows Server フェールオーバー クラスタリングを構成するための追加手順が必要となります。 クラスターを構築するときは、SAP ASCS/SCS インスタンスに複数の IP アドレスと仮想ホスト名を設定する必要があります。
Azure での名前解決とクラスターの仮想ホスト名
Azure クラウド プラットフォームには、フローティング IP アドレスのような仮想 IP アドレスを構成するオプションは用意されていません。 クラウド内のクラスター リソースに到達するために仮想 IP アドレスを設定する別のソリューションが必要となります。
Azure Load Balancer サービスは、Azure に "内部ロード バランサー" を提供します。 内部ロード バランサーでは、クライアントはクラスターの仮想 IP アドレスを使用してクラスターにアクセスします。
クラスター ノードを含むリソース グループに、内部ロード バランサーをデプロイします。 その後、内部ロード バランサーのプローブ ポートを使って、必要なすべてのポート フォワーディング規則を構成します。 クライアントは仮想ホスト名を使用して接続できます。 DNS サーバーは、クラスターの IP アドレスを解決します。 内部ロード バランサーは、クラスターのアクティブ ノードへのポート フォワーディングを処理します。
図 1: 共有ディスクを使用しない Azure の Windows Server フェールオーバー クラスタリング構成
ファイル共有を使用する SAP ASCS/SCS HA
SAP によって、共有ディスクをクラスター化する方法に代わり、Windows フェールオーバー クラスター上の SAP ASCS/SCS インスタンスをクラスター化する新しい方法が開発されました。 クラスター共有ディスクを使う代わりに、SMB ファイル共有を使って SAP グローバル ホスト ファイルをデプロイできます。
Note
SMB ファイル共有は、SAP ASCS/SCS インスタンスのクラスタリングにクラスター共有ディスクを使う方法に代わるものです。
このアーキテクチャには次のような固有機能があります。
- SAP セントラル サービス (独自のファイル構造、およびメッセージとエンキュー プロセスを含む) が、SAP グローバル ホスト ファイルから分離されます。
- SAP セントラル サービスが、SAP ASCS/SCS インスタンスで実行されます。
- SAP ASCS/SCS インスタンスがクラスター化され、<ASCS/SCS 仮想ホスト名> 仮想ホスト名を使ってアクセスできます。
- SAP グローバル ファイルは SMB ファイル共有に配置され、<SAP グローバル ホスト> ホスト名: \\<SAP グローバル ホスト>\sapmnt\<SID>\SYS を使ってアクセスされます。
- SAP ASCS/SCS インスタンスは、両方のクラスター ノード上のローカル ディスクにインストールされます。
- <ASCS/SCS 仮想ホスト名> ネットワーク名は、<SAP グローバル ホスト> とは異なります。
図 2: SMB ファイル共有を使う新しい SAP ASCS/SCS HA のアーキテクチャ
SMB ファイル共有の前提条件:
- SMB 3.0 (またはそれ以降) プロトコル。
- Active Directory ユーザー グループと
computer$
コンピューター オブジェクトに Active Directory アクセス制御リスト (ACL) を設定する機能。 - ファイル共有で HA が有効になっている必要があります。
- ファイルの格納に使われるディスクが単一障害点にならないこと。
- サーバーまたは VM のダウンタイムによってファイル共有にダウンタイムが発生しないこと。
SAP <SID> のクラスター ロールには、クラスター共有ディスクまたは汎用ファイル共有クラスター リソースは含まれません。
図 3: ファイル共有を使うための SAP <SID> クラスター ロール リソース
SAPMNT ファイル共有として Azure の記憶域スペース ダイレクトを使うスケールアウト ファイル共有
スケールアウト ファイル共有を使って、SAP グローバル ホスト ファイルのホストと保護を行うことができます。 また、スケールアウト ファイル共有は、高可用性の SAPMNT ファイル共有サービスも提供します。
図 4: SAP グローバル ホスト ファイルの保護に使われるスケールアウト ファイル共有
重要
スケールアウト ファイル共有は、Microsoft Azure クラウドおよびオンプレミス環境で完全にサポートされています。
スケールアウト ファイル共有は、高可用性および水平方向にスケーラブルな SAPMNT ファイル共有を提供します。
記憶域スペース ダイレクトは、スケールアウト ファイル共有のための共有ディスクとして使われます。 記憶域スペース ダイレクトを使うと、ローカル記憶域を含むサーバーを使って高可用性でスケーラブルな記憶域を構築できます。 SAP グローバル ホスト ファイルのようなスケールアウト ファイル共有に使われる共有記憶域は、単一障害点ではありません。
記憶域スペース ダイレクトを選択する場合は、次のユースケースを検討してください。
- 記憶域スペース ダイレクト クラスターを構築するために使用する仮想マシンは、Azure 可用性セットにデプロイする必要があります。
- 記憶域スペース ダイレクト クラスターのディザスター リカバリーには、Azure Site Recovery Services を使用できます。
- 記憶域スペース ダイレクト クラスターを異なる Azure Availability Zones に拡張することはサポートされていません。
Azure でのスケールアウト ファイル共有に対する SAP の前提条件
スケールアウト ファイル共有を使うには、システムが次の要件を満たしている必要があります。
- 1 つのスケールアウト ファイル共有に対して少なくとも 2 つのクラスター ノード。
- 各ノードには、少なくとも 2 つのローカル ディスクが必要です。
- パフォーマンス上の理由から、"ミラーリング回復性" を使う必要があります。
- 2 つのクラスター ノードによるスケールアウト ファイル共有の双方向ミラーリング。
- 3 つ以上のクラスター ノードによるスケールアウト ファイル共有の 3 方向ミラーリング。
- スケールアウト ファイル共有には 3 方向ミラーリングを行う 3 つ以上のクラスター ノードをお勧めします。 このセットアップにより、2 つのクラスター ノードと 2 方向ミラーリングを使うスケールアウト ファイル共有のセットアップより、拡張性や回復性が向上します。
- Azure Premium ディスクを使う必要があります。
- Azure Managed Disks を使うことをお勧めします。
- Resilient File System (ReFS) を使ってボリュームをフォーマットすることをお勧めします。
- 詳しくは、「SAP Note 1869038 - SAP による ReFS ファイル システムのサポート」および「記憶域スペース ダイレクトのボリュームの計画」記事の「ファイル システムの選択」をご覧ください。
- Microsoft KB4025334 の累積的な更新プログラムを必ずインストールします。
- DS シリーズまたは DSv2 シリーズの Azure VM サイズを使うことができます。
- 記憶域スペース ダイレクトのディスク同期に必要な VM 間の高いネットワーク パフォーマンスを得るには、少なくとも "高" ネットワーク帯域幅の VM タイプを使う必要があります。 詳しくは、DSv2 シリーズおよび DS シリーズの仕様をご覧ください。
- 記憶域プールに未割り当ての容量を若干確保しておくことをお勧めします。 記憶域プールに未割り当て容量を残しておくと、ドライブで障害が発生した場合に "その場で" 修復するためのボリューム領域が用意されます。 これにより、データの安全性とパフォーマンスが向上します。 詳しくは、「ボリュームのサイズの選択」をご覧ください。
- スケールアウト ファイル共有のネットワーク名 (<SAP グローバル ホスト> など) に対して、Azure 内部ロード バランサーを構成する必要はありません。 これは、SAP ASCS/SCS インスタンスの <ASCS/SCS 仮想ホスト名> または DBMS に対して行われます。 スケールアウト ファイル共有は、すべてのクラスター ノード間に負荷をスケールアウトします。 <SAP グローバル ホスト> は、すべてのクラスター ノードのローカル IP アドレスを使います。
重要
<SAP グローバル ホスト> を指し示している SAPMNT ファイル共有の名前を変更することはできません。 SAP は、共有名 "sapmnt" のみをサポートします。
詳しくは、「SAP Note 2492395 - Can the share name sapmnt be changed?」 (SAP Note 2492395 - 共有名 sapmnt を変更できますか) をご覧ください。
2 つのクラスターで SAP ASCS/SCS インスタンスとスケールアウト ファイル共有を構成する
別々のクラスターに SAP ASCS/SCS インスタンスをデプロイする必要があります。専用の SAP <SID> クラスター ロールを設定します。 この場合は、別のクラスターに別のクラスター ロールでスケールアウト ファイル共有を構成します。
重要
セットアップでは、SAP ASCS/SCS インスタンスと SOFS 共有は別々のクラスターにデプロイしてあるという要件を満たしていなければなりません。
重要
このシナリオの SAP ASCS/SCS インスタンスは、UNC パス \\<SAP グローバル ホスト>\sapmnt\<SID>\SYS を使って SAP グローバル ホストにアクセスするように構成されます。
図 5: 2 つのクラスターにデプロイされた SAP ASCS/SCS インスタンスとスケールアウト ファイル共有
オプションの構成
次の図は、VM の総数を減らすために Microsoft Windows フェールオーバー クラスターを実行している Azure VM 上の複数の SAP インスタンスを示しています。
これは、SAP ASCS/SCS クラスター上のローカル SAP アプリケーション サーバーとすることも、Microsoft SQL Server Always On ノード上の SAP ASCS/SCS クラスター ロールとすることもできます。
重要
ローカル SAP アプリケーション サーバーを SQL Server Always On ノードにインストールすることはサポートされていません。
SAP ASCS/SCS と Microsoft SQL Server データベースは両方とも単一障害点 (SPOF) です。 これらの SPOF を Windows 環境内で保護するために、WSFC が使用されます。
SAP ASCS/SCS のリソース消費量はかなり小さいものの、SQL Server または SAP アプリケーション サーバーのどちらかのメモリ構成を、2 GB 削減することをお勧めします。
Windows SOFS を使用した WSFC ノード上の SAP アプリケーション サーバー
Note
この図では、追加のローカル ディスクの使用を示しています。 OS ドライブ (C:) 上にアプリケーション ソフトウェアをインストールしないお客様の場合、これは省略可能です
Windows SOFS を使用した SQL Server Always On ノード上の SAP ASCS/SCS
Note
この図では、追加のローカル ディスクの使用を示しています。 OS ドライブ (C:) 上にアプリケーション ソフトウェアをインストールしないお客様の場合、これは省略可能です
重要
Azure クラウドでは、SAP およびスケールアウト ファイル共有に使われる各クラスターを、専用の Azure 可用性セットまたは Azure Availability Zones をまたいでデプロイする必要があります。 このようにすると、クラスターの VM が基になっている Azure インフラストラクチャ全体に分散して配置されます。 可用性ゾーンのデプロイは、このテクノロジでサポートされています。
クラスター共有ディスクとして SIOS DataKeeper を使う汎用ファイル共有
汎用ファイル共有は、高可用性ファイル共有を実現するためのもう 1 つのオプションです。
この場合は、クラスター共有ディスクとして、サード パーティの SIOS ソリューションを使うことができます。