Jaa

SAP on Azure のデプロイに関する 14 の更新と新しいテクノロジ

  • Artikkeli

執筆者: Cameron (MSFT SAP Program Manager)

このポストは、2016 年 12 月 4 日に投稿された Top 14 Updates and New Technologies for Deploying SAP on Azure の翻訳です。

 

このブログでは、お客様が SAP アプリケーションを Azure に移行する場合に役立つ更新、推奨事項、新しいテクノロジをご紹介します。

このブログの最後には、SAP on Azure のデプロイを計画しているすべてのお客様に推奨するチェックリストも掲載しています。

1. HighPerformance Gateway と UltraPerformance Gateway

UltraPerformance Gateway がリリースされました。

このゲートウェイは ExpressRoute 接続のみをサポートし、最大スループットが大幅に向上しています。

UltraPerformance Gateway は、大量の R3load ダンプ ファイルやデータベースのバックアップを Azure にアップロードする必要のあるプロジェクトでとても有用です。

https://azure.microsoft.com/ja-jp/documentation/services/vpn-gateway/

2. Accelerated Networking

同一の VNET 上で実行される複数の DS15v2 VM 間の帯域幅 (英語) を大幅に向上させる新機能がリリースされました。Accelerated Networking により、VM 間のレイテンシが大幅に削減されます。

この機能は、既に大部分のデータセンターで利用可能で、SRIO-V の概念がベースとなっています。

Accelerated Networking は、SAP のアップグレードを実行する場合や、R3load で移行を行う場合に特に有効です。DB サーバー、SAP アプリケーション サーバーの両方で Accelerated Networking を構成することをお勧めします。

多数の SAP アプリケーション サーバーから成る大規模な 3 層システム (英語) でも、データベース サーバーに Accelerated Networking を構成することでメリットが得られます。

たとえば、DS15v2 データベース サーバー (SQL Server 2016 を実行、バッファー プール拡張域を有効化、Accelerated Networking を構成) と、D13v2 アプリケーション サーバー 6 台の高いスケーラビリティの構成を作成できます。

データベース サーバー: DS15v2 データベース サーバー。SQL Server 2016 SP1 を実行します。バッファー プール拡張域を有効化し、Accelerated Networking を構成します。SQL Server キャッシュ (SQL 最大メモリ) に 110 GB のメモリを割り当て、バッファー プール拡張域に 200 GB 前後のメモリを割り当てます。

アプリケーション サーバー: D13v2 x 6 台。それぞれに 2 つの SAP インスタンス、各インスタンスに 50 個のワーク プロセスを設定し、PHYS_MEMSIZE を 50% に設定します。これで、合計 600 個のワーク プロセス (D13v2 VM 6 台 x ワーク プロセス 50 個 (インスタンスあたり) x インスタンス 2 個 (VM あたり) = 600) となります。

このような 3 層構成の SAPS 値は、DB レイヤー (DS15v2) が 30,000 SAPS、アプリケーション レイヤー (D13v2 x 6 台) が 70,000 SAPS で、合計 100,000 SAPS となります。

3. 1 つの Internal Load Balancer への複数の ASCS または SQL Server 可用性グループの割り当て

1 つの ILB に複数のフロントエンド IP アドレスを割り当てる機能がリリースされる以前は、SAP ASCS ごとに専用の 2 ノード クラスターが必要でした。

例: SAP ECC、BW、SCM、EP、PI、Solution Manager、GRC、NWDI を実行する場合、SAP ASCS レイヤーには、2 ノード クラスターが 8 つ、合計 16 台の小さな VM が必要でした。

ILB の複数のフロントエンド IP アドレス機能のリリースにより、今後必要となるのは小さな VM 2 台のみとなります。

今回、1 つの Internal Load Balancer で複数のフロントエンド IP アドレスをバインドできるようになりました。これらのフロントエンド IP アドレスは、それぞれ異なるポート (各 AlwaysOn 可用性グループ リスナーに割り当てられた一意のポートなど) をリッスンすることも、同一のポート (Windows ファイル共有用のポート 445 など) をリッスンすることもできます。

PowerShell コマンドを使用して ILB 構成を設定するスクリプトについては、こちらのドキュメントをご覧ください。

注: Windows クラスターの内部クラスター IP アドレス (クラスター自体が使用する IP アドレス) のフロントエンド IP アドレスを ILB に割り当てることができます。クラスターの IP アドレスを ILB に割り当てると、クラスター管理ツールなどのユーティリティをリモートで実行できます。

1 つの ILB に最大 30 個のフロントエンド IP アドレスを割り当てられます。Azure の既定のサービスの制限は 5 個です。この制限を引き上げるには、サポート要求を作成します。

以下の PowerShell コマンドが使用されます。

New-AzureRmLoadBalancer

Add-AzureRmLoadBalancerFrontendIpConfig

Add-AzureRmLoadBalancerProbeConfig

Add-AzureRmLoadBalancerBackendAddressPoolConfig

Set-AzureRmNetworkInterface

Add-AzureRmLoadBalancerRuleConfig

4. ストレージ アカウントの暗号化、Azure Key Vault での SQL TDE キーの保管、Advanced Disk Encryption (ADE)

SQL Server では、透過的なデータベース暗号化 (TDE) をサポートしています。SQL Server のキーは Azure Key Vault 内に安全に保管できます。SQL Server 2014 以前では、Azure Key Vault からキーを取得するために、無料のコネクタ ユーティリティを使用できます。SQL Server 2016 以降は、Azure Key Vault をネイティブにサポートしています。一般的に、R3load でデータを読み込む前にデータベースを暗号化することが推奨されます。この場合のオーバーヘッドはわずか 5% 程度です。インポート後に TDE を適用することも可能ですが、データベースが大きい場合には時間がかかります。推奨される暗号化方式は AES-256 です。TDE システムではバックアップも暗号化されます。

Advanced Disk Encryption は、「Bitlocker」に類似したテクノロジです。DBMS データ ファイル、一時ファイル、ログ ファイルを保存しているディスクには ADE を使用しないことが推奨されます。SQL Server (または他の DBMS) の保存データ ファイルの保護に推奨されるテクノロジは TDE (またはネイティブの DBMS 暗号化ツール) です。

SQL Server TDE と ADE ディスクは併用しないことが強く推奨されます。併用した場合、オーバーヘッドが大きくなる可能性があり、このシナリオは検証されていません。ADE は、OS ブート ディスクの暗号化に適しています。

Azure プラットフォームでは、ストレージ アカウントの暗号化がサポートされました。この機能により、ストレージ アカウントの保存データを暗号化できます。

5. Windows Server 2016 クラウド監視

現在の計画では、SAP のお客様に向けた Windows Server 2016 の一般提供開始は、2017 年第 1 四半期を予定しています。

特に有用な機能の 1 つがクラウド監視 (英語) です。

Azure 上に Windows クラスターをデプロイする場合の一般的な推奨事項は以下のとおりです。

1. ノードおよびファイル共有監視マジョリティ (英語) とダイナミック クォーラムを使用します。

2. ファイル共有監視 (FSW) は、プライマリ サイトや DR サイトとは異なる第 3 の場所 (英語) に配置します。

3. 3 つの場所 (プライマリ、DR、ファイル共有監視) のすべてを個別の冗長ネットワーク リンクで接続します。

4. SLA がきわめて高いシステムでは、ファイル共有監視を高可用性構成にする必要があります (もう 1 つクラスターが必要になります)。

Windows Server 2016 より前のバージョンでは、このアプローチには複数の問題がありました。

1. 多くのお客様は、DR ソリューションを妥協し、FSW をプライマリ サイトに配置しています。

2. 多くの場合、FSW が高可用性構成になっていません。

3. FSW を使用する場合には 1 台以上の VM を追加する必要があるため、コストが増加します。

4. FSW を高可用性構成にするには、2 台の VM と、SIOS などのソフトウェア共有ディスク ソリューションが必要になります。これも、コストの増大になります。

Windows Server 2016 では、クラウド監視を導入することにより、このような問題を解決します。

1. FSW は、サービスとしてのプラットフォーム (PaaS) の役割となりました。

2. VM は必要ありません。

3. FSW は自動的に高可用性構成となります。

4. 継続的な保守、修正プログラムの適用、HA などの作業は発生しません。

5. クラウド監視のセットアップ後はマネージド サービスとなります。

6. クラウド監視は、任意の Azure データセンター (第 3 の場所) に配置できます。

7. クラウド監視には標準のインターネット リンク経由で到達できます (FSW に個別の冗長リンクで接続するという要件が解消されます)。

6. Azure Site Recovery Azure-2-Azure (ASR A2A)

Azure Site Recovery は、Azure 内で VM をレプリケートする既存のテクノロジ (英語) です。

第 1 四半期に新しいシナリオがリリースされます。新しいシナリオは、Azure 間の ASR です。

Hyper-V、物理的ワークロード、VMWare から Azure にレプリケートするシナリオは既に一般提供が開始されています。

Azure Site Recovery (ASR) と競合テクノロジの主な違いは以下のとおりです。

Azure Site Recovery により、DR ソリューションのコストを大幅に削減できます。実際の DR イベント (火災、洪水、停電、テスト フェールオーバーなど) が発生しない限り、Virtual Machines の料金は請求されません。Azure に同期される VM に関して、Azure のコンピューティング コストは発生しません。ストレージ コストのみが請求されます。

Azure Site Recovery では、サービスを中断せずに DR テストを実行できます。ASR のテスト フェールオーバーでは、すべての ASR リソースをテスト リージョンにコピーし、保護されたすべてのインフラストラクチャをテスト用のプライベート ネットワーク内で起動します。これにより、Windows コンピューター名の重複による問題を回避できます。もう 1 つの重要な機能は、テスト フェールオーバーによってオンプレミスから Azure への VM レプリケーションが停止、妨害、中断されないという点です。テスト フェールオーバーは、特定の時点におけるすべての VM とその他のオブジェクトの「スナップショット」を取得します。

Azure に組み込まれた回復性と冗長性は、ほとんどのお客様やホストが提供できるレベルを大きく上回ります。Azure BLOB ストレージには、データのコピーを最低でも 3 つ個別に保存しています。このため、1 つのストレージ ノードで障害が発生した場合にもデータ損失のリスクを防止できます。

ASR の「復旧計画」では、DR フェールオーバーまたはフェールバックの一連の手順 (ランブック) を作成しておくことができます。たとえば、ASR 復旧計画を作成して、次のような処理を行うことができます。最初に Active Directory サーバーを起動し (認証と DNS サービスを提供するため)、次に DB サーバーの復旧を行う PowerShell スクリプトを実行します。その後、SAP セントラル サービスを開始し、最後に SAP アプリケーション サーバーを起動します。これで、「プッシュ ボタン」式の DR が可能になります。

Azure Site Recovery は異種混在環境に対応したソリューションで、Windows と Linux で実行できるほか、SQL Server、Oracle、Sybase、DB2 と連携します。

補足情報

1. ASCS を 3 つ以上のノードにセットアップする場合は、「Note 1634991 – How to install (A)SCS instance on more than 2 cluster nodes」を参照してください。

2. DR サイトの SAP アプリケーション サーバーは実行されません。そのため、コンピューティング コストは発生しません。

3. DR の SQL Server のサイズを小さくすることで、コストをさらに削減できます。低コストの VM SKU を使用して、DR イベントが発生した場合に大きな VM にアップグレードします。

4. DR では、Active Directory などのサービスを利用できるようにする必要があります。

5. Azure に共有ディスクを作成する場合には、SIOS または BNW AFSDrive を使用できます。2016 年 11 月時点では、SAP ASCS には共有ディスクが必要です。

6. DR サイトから HA を削除する (1 つの DB と ASCS ノードのみにする) ことでコストを削減できます。

7. クラスター クォーラム モデルと投票に関しては、慎重に計画します。クラスター モデルを運用チームに説明します。ダイナミック クォーラムを使用します。

DR サイトを HA 構成にした場合

7. ストレージの固定

Azure ストレージ アカウントは、特定のストレージ スタンプに「関連付ける」または「固定する」ことができます。スタンプとは、個々のストレージ デバイスと考えることができます。

各データベース レプリカの DBMS ファイルには個別のストレージ アカウントを使用することを強くお勧めします。

以下の例では、次のような構成がデプロイされます。

1. SQL Server AlwaysOn ノード 1 は、ストレージ アカウント 1 を使用します。

2. SQL Server AlwaysOn ノード 2 は、ストレージ アカウント 2 を使用します。

3. サポート要求が発行され、ストレージ アカウント 1 はスタンプ 1 に固定され、ストレージ アカウント 2 はスタンプ 2 に固定されます。

4. この構成では、基盤のストレージ インフラストラクチャで障害が発生しても、サービスの停止につながることはありません。

8. Windows クラスターのタイムアウト パラメーターの引き上げ

Azure VM で Windows クラスターを実行する場合、Windows Server 2012 R2 には修正プログラムを適用して、クラスター タイムアウト値を Windows Server 2016 に設定されている既定値に引き上げることが推奨されます。

Windows Server 2012 R2 のクラスター タイムアウト値を Windows Server 2016 の既定値に引き上げる方法については、サポート技術情報の記事 https://support.microsoft.com/ja-jp/kb/3153887 を参照してください。

Windows Server 2016 では、対応は不要です。正しい値が既に設定されています。

詳細については、こちらのブログ記事 (英語) を参照してください。

9. ARM デプロイメントの使用、Dv2 VM の使用、単一 VM の SLA、DBMSのみでのPremium Storage の使用

このブログでご説明した機能強化の多くは、ARM のみの機能です。これらの機能は、以前の ASM デプロイメントでは利用できません。そのため、ARM ベースのシステムのみをデプロイし、ASM システムを ARM に移行することが強く推奨されます。

Azure D シリーズ v2 VM タイプは、高速かつ高性能の Haswell プロセッサを搭載し、最初の D シリーズと比較して大幅な高速化を実現しています。

すべてのお客様は、Premium Storage を運用環境および非運用環境システムの DBMS サーバーのみに使用することをお勧めします。

Premium Storage の使用は、Content Server、TREX、LiveCache、BusinessObjects、その他の I/O 負荷の高い Netweaver 以外のファイル ベースまたは DBMS ベースのアプリケーションにも適しています。

SAP アプリケーション サーバーの場合、Premium Storage を使用するメリットはありません。

データベースのバックアップ、アーカイブ ファイルやインターフェイス ファイルの保存には、Standard Storage を使用できます。

詳細については、「SAP Note 2367194 – Use of Azure Premium SSD Storage for SAP DBMS Instance」を参照してください。

Azure において、単一の VM に対する返金制度付きの SLA が提供されるようになりました。以前は、複数の VM を含む可用性セット単位でのみ SLA が提供されていました。オンラインパッチ適用と信頼性テクノロジの強化により、この機能が提供されました。

10. Azure でのサイジング: 現行 VM の CPU と RAM のサイジングをそのまま使用しない

SAP on Azure のサイジング方法を確立するにあたっては、以下の点を考慮する必要があります。

1. オンプレミス デプロイメントとは異なり、ハードウェアのライフタイム期間中の拡大や要件の変更を考慮してバッファーを大きくとる必要はありません。たとえば、オンプレミス システム用に新しいハードウェアを購入する場合は通常、3 ～ 4 年間はそのハードウェアを稼働できるように十分なリソースを購入します。Azure では、そのような必要はありません。6 か月後に CPU、RAM、ストレージの追加が必要になった場合は、その時点で即座にプロビジョニングできます。

2. Intel サーバー上の多くのオンプレミス デプロイメントとは異なり、Azure VM ではハイパースレッディングを使用しません (2016 年 11 月時点)。そのため、Azure VM のスレッド パフォーマンスは、多くのオンプレミス デプロイメントよりも大幅に高くなります。D シリーズ v2 の場合、スレッドあたりの SAPS 値は 1,500 以上です。

3. 現行のオンプレミス SAP アプリケーション サーバーの CPU が 8、RAM が 56 GB の場合でも、必ずしも D13v2 が必要になるわけではありません。以下の手順を実行することが推奨されます。

a. CPU、RAM、ネットワーク、ディスクの使用量を測定します。

b. オンプレミスの CPU の世代を確認します。Azure インフラストラクチャは多くのお客様のデプロイメントよりも頻繁に更新されています。

c. CPU の世代と、平均的なリソース使用量を考慮したうえで、より小さい VM を使用できないか検討します。

4. 2 層から 3 層の構成に切り替える場合は、こちらのブログ記事 (英語) を参照してください。

5. SAP on Azure のサイジング方法については、こちらのブログ記事 (英語) を参照してください。

6. 運用開始後は、DB サーバーとアプリケーション サーバーを監視し、サイズの増減が必要かどうかを確認します。

11. SAP on Azure デプロイメント ガイドの確認

プロジェクトを開始する前に、プロジェクト チームの技術メンバー全員が SAP on Azure のデプロイメント ガイドを十分に確認することをお勧めします。

このガイドでは、推奨されるデプロイ方法や、その他の重要な情報を紹介しています。

「Note 2015553 – SAP on Microsoft Azure Support prerequisites」の説明に従って、ST06 の Azure VM 監視エージェントの設定を確認してください。

この SAP Note の内容が完全に適用されないと、Azure 上での SAP システムはサポートされません。

12. AzCopy、RoboCopy、FTP を使用した R3load ダンプ ファイルのアップロード

以下の図は、既存のデータセンターから Azure にシステムをインポートする場合の推奨トポロジを示したものです。

SAP Migration Monitor には、ダンプ ファイルを FTP 経由で転送する機能が組み込まれています。

一部のお客様やパートナー様は、Robocopy を使用してダンプ ファイルをコピーするスクリプトを独自に開発しています。

AzCopy も使用できます。このツールは、ストレージ アカウントに対して直接実行されるため、VPN または ExpressRoute を必要としません。

13. 最新の Windows Server イメージ、SQL Server サービス パック、累積更新プログラムの使用

最新の Windows Server イメージには重要な更新プログラムや修正プログラムがすべて含まれています。Azure ギャラリーから入手可能な最新の Windows Server OS を使用することが推奨されます。

DBMS についても、最新のバージョンと修正プログラムが推奨されます。

一般的に、SAP システム用に SQL Server 2008 R2 以前のバージョンをデプロイすることは推奨されません。SQL Server 2012 は、それ以降の SQL Server リリースをサポートすることができない場合に限り、システムに修正プログラムを適用して使用することをお勧めします。

SQL Server 2014 は、以前から SAP でサポートされており、既に多くの SAP のお客様がオンプレミスや Azure にデプロイしています。

SQL Server 2016 は、SAP_BASIS 7.31 以上のリリースでサポートされており、世界的な大手エネルギー企業をはじめ、複数の大規模企業のお客様が既に運用環境で正常にデプロイしています。SQL Server 2016 での BASIS 7.00 ～ 7.30 のサポートも近いうちに予定されています。

最新の SQL Server サービス パックと累積更新プログラムは、こちらのページ (英語) からダウンロードできます。

増分サービス ポリシーの変更 (英語) に伴い、最新の SQL Server の累積更新プログラムのみをダウンロードできるようになりました。

以前の累積更新プログラムは、こちらのページからダウンロードできます。

1966681 – Release planning for Microsoft SQL Server 2014

2201059 – Release planning for Microsoft SQL Server 2016

Azure プラットフォームでは、Windows、SUSE 12 以上、RHEL 7 以上を完全にサポートしています。Oracle、DB2、Sybase、MaxDB、HANA はすべて Azure でサポートされます。

多くのお客様が、オンプレミスからクラウドへの移行の機会を利用して、サポート ベンダーを 1 社に絞り込んだり、Windows と SQL Server に切り替えたりしています。

マイクロソフトは、Database Trade In Program をリリースしました。このプログラムでは、DB2、Oracle、その他の DBMS から移行した場合に、SQL Server のライセンスを無償で取得できます (各種条件 (英語) が適用されます)。

2015 年度の Magic Quadrant for Operational Database Management Systems (英語)
では、SQL Server が「Leader」の中で最も高い評価を獲得しました。2016 年度の同じ Magic Quadrant (英語) では、他製品との差がさらに広がりました。

14. Azure への移行-事前チェックリスト

お客様やパートナー様が SAP アプリケーションを Azure に移行する場合、以下のチェックリストを確認することをお勧めします。

1. 現行の SAP ランドスケープを調査し、インベントリを作成します。SAP サポート パックのレベルを確認し、移行後の DBMS をサポートするために修正プログラムの適用が必要かどうかを判断します。通常、オペレーティング システムの互換性は SAP カーネルによって決まり、DBMS の互換性は SAP_BASIS の修正プログラムのレベルによって決まります。

移行前のシステムに適用する必要のある SAP Note (SMIGR_CREATE_DDL の更新など) の一覧を作成します。Azure への移行中の大規模な変更を回避するために、移行前システムの SAP カーネルのアップグレードを行うことを検討します (たとえば、移行前システムで古い 7.41 カーネルを実行している場合は、最新の 7.45 にアップグレードすることで、移行中の大規模な変更を回避できます)。

2. 高可用性および災害復旧ソリューションを策定します。PowerPoint を作成して、HA と DR の概念について詳しく説明します。DB レイヤー、ASCS レイヤー、SAP アプリケーション サーバー レイヤーにソリューションを分割した図を作成します。TREX や Livecache などのスタンドアロン ソリューションには、個別のソリューションが必要になる場合もあります。

3. サイジングと構成を文書化し、Azure VM のタイプとストレージの構成を詳述します。Premium ディスクの数、データ ファイルの数、ディスク間のデータ ファイルの分散方法、ストレージ スペースの使用量、NTFS フォーマット サイズ (64 KB) などを記録します。また、バックアップと復元、DBMS 構成 (メモリの設定、並列処理の最大限度、トレース フラグなど) についても文書化します。

4. ネットワーク設計書を作成し、VNET、サブネット、NSG、UDR の構成を記録します。

5. セキュリティと保護機能の概念を検討します。Internet Explorer を削除し、SAP のサービス アカウントとサーバー用に Active Directory コンテナーを作成します。さらに、少数の必要なポート以外のすべてのポートをブロックするファイアウォール ポリシーを適用します。

6. OS と DB の移行設計書を作成します。パッケージおよびテーブルの分割方法、R3load の数、SQL Server のトレース フラグ、ソートの有無、Oracle RowID 設定、SMIGR_CREATE_DDL 設定、Perfmon カウンター (BCP 行/秒、BCP スループット KB/秒、CPU、メモリなど)、RSS 設定、Accelerated Networking 設定、ログ ファイルの構成、BPE 設定、TDE 構成について記録します。

7. テスト サイクルごとに R3load のエクスポートとインポートの進行状況を示した「フライト プラン」グラフを作成します。移行コンサルタントは、このグラフに基づいて、R3load のエクスポートまたはインポートのパフォーマンス向上のために調整や変更が必要かどうかを判断します。X 軸は完了したパッケージの数、Y 軸は時間を表します。このフライト プランは、運用環境への移行時にも重要な役割を果たします。計画した進行状況と実際の進行状況を比較することで、問題を早期に発見できます。

8. パフォーマンス テスト計画を策定します。上位 20 個のオンライン レポート、バッチ ジョブ、インターフェイスを確認します。移行前システムの入力パラメーター (日付範囲、営業所、工場、会社コードなど) と実行時間を文書化します。Azure の実行時間と比較します。パフォーマンスの差がある場合は、SAT、ST05、他の SAP ツールを実行して不十分なステートメントを特定します。

9. SQL Server 上の SAP BW に関して、列ストアなどの BW システムの新機能については、このブログ サイトを定期的にチェックしてください。

10. デプロイメントと構成の監査を行い、クラスター タイムアウト、カーネル、ネットワーク設定、NTFS フォーマット サイズがすべて設計書と一致していることを確認します。重要なサーバーに Perfmon カウンターを設定し、基本的な正常性パラメーターを 90 秒ごとに記録します。さらに、各 SAP サーバーが個別の AD コンテナーに格納され、ファイアウォールの構成によってコンテナーにポリシーが適用されていることを確認します。

第三者の Web サイト、SAP、その他のソースからのコンテンツは、Fair Use (英語) の規定する目的 (批評、論評、報道、教育、学問、研究) に従うものとして複製されています。