Share via

超大規模データベースの Azure 移行 - パートナー向け推奨事項とガイドライン

  • Article

執筆者: Cameron - MSFT SAP Program Manager

このポストは、2018 年 4 月 10 日に投稿された Very Large Database Migration to Azure – Recommendations & Guidance to Partners の翻訳です。

 

近年、Azure クラウドに移行される SAP システムにおいて、複数の国にまたがる大規模な「シングル グローバル インスタンス」が珍しくなくなってきました。数年前に Azure プラットフォームが SAP認定を受けた当初と比較すると、システムの規模は何倍にもなっています。

現在では、超大規模データベース (VLDB) の Azure 移行も珍しくありません。しかしながら、20 TB を超える規模のオンプレミス データベースを、ダウンタイムやリスクを抑えながら Azure に移行するには、特別な技術や手順が必要になります。

下の図は、SQL Server をターゲットDBMSとする VLDB マイグレーションを示しています。元のDBMSはOracleまたはDB2を想定しています。

Azure 上の HANA への移行 (DMO) については、今後のブログ記事でご紹介する予定です。今回ご説明する内容の多くは、HANAへの移行でも有効ものとなります。

このBlog記事は既存の SAP のシステムコピーに関するガイドや SAP Note を置き換えるものではありません。併せてご確認ください。

概要

完全に最適化された VLDB の移行では、1 時間あたりのスループットは 2 TB 以上になります。

つまり、20 TB のデータ転送処理については約10時間で完了することができます。その後、さまざまな後処理や検証を別途行う必要があります。

一般論として、準備とテストに十分な時間を掛ければ、どのような規模のシステムでも Azure に移行することができると言えます。

VLDB の移行では、高度なスキル、細かい点への配慮と分析が必要となります。例えば、テーブル分割による**実際の影響を測定し、分析する必要があります。大規模なテーブルを 50 以上に分割して並列処理でエクスポートすることで、エクスポート時間を大幅に短縮することができる一方、分割数が多すぎるとインポートに長い時間がかかる可能性があります。このため、作業の実際**の処理を測定し、テストしておく必要があります。エキスパート ライセンスを保有する OS / DB マイグレーションのコンサルタントが、移行の概念やツールを熟知していることを前提に、VLDB のAzure 移行に特化した内容を中心にお伝えします。

この記事では、R3load や Migmon などのツールを使用し、異種混在環境（ヘテロジニアス環境）の OS ・ DB を Azure 上の SQL Server に移行します。以下の手順は、同種のシステムのみの環境（ホモジニアス環境）―DBMS とプロセッサ アーキテクチャ (バイト オーダー) が同一などー を想定したものではありません。一般に、同種システム間のコピーでは、ログシッピングを使用することでデータベースのコピーをAzure 上に同期できるため、DBMS のサイズにかかわらずダウンタイムは非常に短くできます。

下の図で、典型的な VLDB の AzureへのOS/DB マイグレーション を説明します。この図の主なポイントは以下のとおりです。

  1. 移行元の OS は AIX、HPUX、Solaris、Linux 、DB は DB2 またはOracle であることがほとんどです。
  2. 移行先の OS は Windows、Suse 12.3、Redhat 7.x、Oracle Linux 7.x のいずれかです。
  3. 移行先の DB は SQL Server または Oracle 12.2 が一般的です。
  4. IBM pSeries、Solaris SPARC のハードウェア、HP Superdome などは、より低価格な 新しいIntel CPUの汎用サーバーに比べスレッド パフォーマンスが非常に低いため、R3load の実行は、別にIntelサーバーを用意して行います。
  5. VMWare 上で安定して高いネットワーク パフォーマンスを実現するには、特殊なチューニングや構成が必要です。通常、R3load サーバーには VM ではなく物理サーバーを使用します。
  6. サーバー台数に関する制限はありませんが、エクスポート用 R3load サーバーとして 4 台用意することが一般的です。典型的な構成は以下のとおりです。

- エクスポート用サーバー #1 – 特に規模が大きい１～４のテーブル専用に割り当て (個数は移行元データベースのデータの分散具合によって異なる)

- エクスポート用サーバー #2 – テーブル分割の対象テーブル用に割り当て

- エクスポート用サーバー #3 – テーブル分割の対象テーブル用に割り当て

- エクスポート用サーバー #4 – 残りのすべてのテーブル用

  1. エクスポート ダンプ ファイルは、AzCopy によってパブリック インターネット経由で Intel R3load サーバーのローカル ディスクから Azure に転送します (この方式は、通常のケースでは ExpressRoute 経由よりも高速となることが多いです)。
  2. エクスポート パッケージごとの完了時に生成されるシグナル ファイル (SGN) に従って、インポートの制御とシーケンス処理が行われるため、エクスポートとインポートをほぼ並列実行できます。
  3. SQL Server や Oracle へのインポートはエクスポートと同様の構造で、インポート用サーバーを4台使用し、 Accelerated Networkingを有効化します。この処理には、SAP アプリケーション サーバーを流用しないことが推奨です。
  4. VLDB データベースには、E64v3、M64、M128 の VM をPremium Storageとあわせて使用するのが一般的です。トランザクション ログをローカル SSD に配置することで、ログの書き込みを高速化可能です。またVMごとに割り当てられたIOPSおよびと I/O 帯域幅の制限を回避することもできます。移行が終了したら、トランザクション ログを永続ディスクに配置しなおします。

 

移行元システムの最適化

以下は、移行元の VLDB システムをエクスポートする手順です。

  1. テクニカル テーブルや不要なデータを消去します。詳しくは「SAP Note 2388483 – How-To: Data Management for Technical Tables」をお読みください。
  2. エクスポート処理のパフォーマンス最大化のため、R3load プロセスの DBMS サーバーからの分離は必須です。
  3. R3load は、高速な最新 Intel CPU で実行しましょう。UNIX サーバー上で R3load を実行することは、パフォーマンスが劇的に低下するため推奨しません。128 GB RAM を搭載した 2 ソケットの Intel 汎用サーバーは、非常に安価なうえ、チューニング、最適化、コンサルティングに要する期間を数日から数週間短縮できます。
  4. 移行元の DB サーバーと Intel R3load サーバーの間は、ネットワーク ホップ数を最小限に抑えた高速ネットワーク (10 Gbps が理想) を使用しましょう。
  5. エクスポート用 R3load サーバーには、物理サーバーを採用することを推奨します。仮想の R3load サーバーを使用したあるお客様では、高いネットワーク スループットを実現する安定したパフォーマンスを得られないケースがありました (ただし、熟練した VMWare エンジニアがいれば、高パフォーマンスの VMWare を構成可能と想定されます)。
  6. 大規模なテーブルを Orderby.txt の最初に記載します。
  7. シグナル ファイルを使用しエクスポートとインポートを並列で実行するように構成します。
  8. 大規模なエクスポート処理では、サイズの大きいテーブルをソートなしでエクスポートすることが有効な場合があります。ただし、クラスター化インデックスをプライマリ キーとするDBの場合では、ソートなしでエクスポートされたデータのインポート処理は遅くなるため、ソートなしでのエクスポートによる全体的な影響を事前に確認しておくことが重要です。
  9. 移行元 DB サーバーと Intel R3load サーバーの間でジャンボ フレームを構成します。詳しくは、この後の「ネットワークの最適化」のセクションをお読みください。
  10. 移行元 DB サーバーのメモリ設定を調整して、読み込みおよびエクスポートのシーケンシャル処理を最適化します。詳しくは、「SAP Note 936441 – Oracle settings for R3load based system copy」をお読みください。

移行元システムの高度な最適化

  1. Oracle の ROWID によるテーブル分割

SAP Note 1043380 で、WHR ファイルの WHERE 句を ROWID の値に変換するスクリプトが公開されています。また最新バージョンの SAPInst では、Oracle to Oracleの R3load での移行を SWPM で構成している場合、ROWID 分割の WHR ファイルが自動生成されます。SWPM で生成された STR ファイルと WHR ファイルは OS/DB に依存していません。（またOS/DB マイグレーションプロセスにも一切影響しません。）

SAP Note によると、移行先のデータベースが Oracle ではない場合、ROWID によるテーブル分割は使用できないとされています。技術的にはR3load のダンプ ファイルは DB / OS には依存しないのですが、ROWIDによる分割を行った場合SQL Server へのインポートでパッケージの再開ができなくなるという制限があります。回避策としては、テーブル全体を削除後に、対象テーブルの全パッケージを再実行する必要があります。なお、そもそもテーブル分割の対象テーブルへのR3load タスクを中止する場合、対象テーブルのTRUNCATE を実行し、インポート プロセスを最初から再実行することを推奨します。R3load に組み込まれている回復プロセスでは、1 行ごとに DELETE ステートメントを実行して、中止した R3load プロセスのレコードを削除します。この処理はきわめて遅く、DB上でのブロックおよびロックの原因となります。つまり、対象テーブルのインポートを最初からやり直した方が早く、結果としてSAP Note 1043380 にある制限を受けることもなくなるというわけです。

また、ROWID には、分割を計算する際にダウンタイムが必要となるというデメリットがあります。詳しくは SAP Note 1043380 をご確認ください。

  1. 移行元データベースの「クローン」を複数作成してエクスポートを並列実行

データベースのコピーを複数作成してからエクスポートを実行すると、エクスポートのパフォーマンスが向上します。サーバー、ネットワーク、ストレージなどの基盤インフラストラクチャがスケーラブルであれば、この効果はさらに大きくなります。2 つのデータベースからエクスポートすればパフォーマンスは 2 倍に、4 つのデータベースでは 4 倍になります。移行モニターは、データベースの各「クローン」から指定したテーブル数をエクスポートするように構成されています。以下の例では、エクスポート処理は 4 つの DB サーバーで約 25% ずつに分散されます。

- DB サーバー 1 および エクスポート用サーバー #1 – 特に規模が大きい１～４のテーブル専用に割り当て (個数は移行元データベースのデータの分散具合によって異なる)

- DB サーバー 2 およびエクスポート用サーバー #2 – テーブル分割の対象テーブル用に割り当て

- DB サーバー 3 およびエクスポート用サーバー #3 – テーブル分割の対象テーブル用に割り当て

- DB サーバー 4 およびエクスポート用サーバー #4 – 残りのすべてのテーブル用

このとき、データベースが正確に同期されていることに細心の注意を払う必要があります。同期されていない場合、データ損失や整合性が失われる可能性があります。データの整合性を保つには、以下の手順を厳密に守る必要があります。

この手法は、標準的な Intel 汎用ハードウェアを使用すると簡単かつ安価に実現できますが、UNIX 専用ハードウェアでも実施可能です。サンドボックス、開発環境、品質保証システム、トレーニング環境、DR システムが既に Azure に移行されていれば、OS と DB の移行プロジェクトに必要なハードウェア リソースは十分に確保できます。「クローン」サーバーのハードウェア リソースは、完全に同一である必要はありません。CPU、RAM、ディスク、ネットワークのパフォーマンスが適切であれば、クローンの数に比例してパフォーマンスも向上します。

エクスポートのパフォーマンスをさらに向上したい場合は、BC-DB-MSS の SAP インシデントから追加手順を申請します (高度なコンサルタント向け)。

以下は、複数のエクスポート処理を並列で実行する手順です。

  1. プライマリ データベースをバックアップし、クローン数分の復元を行います。ここでは、3 つのクローンを作成して合計 4 つの DB サーバーを使用しています。
  2. バックアップを 3 つのサーバーに復元します。
  3. 移行元のプライマリ DB サーバーから、移行先の 3 つの「クローン」サーバーへのログシッピングを構成します。
  4. ログシッピングを数日間監視して、確実に動作していることを確認します。
  5. ダウンタイム開始時に、プライマリ アプリケーション サーバー (PAS) を除くすべての SAP アプリケーション サーバーを停止します。バッチや RFC トラフィックがすべて停止していることを確認します。
  6. SM02 トランザクションで「Checkpoint PAS Running」というテキストを入力し、TEMSG テーブルを更新します。
  7. PAS を停止します。これで SAP は完全にシャットダウンされ、移行元の DB への更新ができなくなります。SAP 以外のアプリケーションが移行元の DB に接続されていないことを確認します (念のため、DB レベルで SAP 以外のセッションをすべて確認します)。
  8. プライマリ DB サーバーで「SELECT EMTEXT FROM <スキーマ名>. TEMSG」というクエリを実行します。
  9. ネイティブ DBMS レベルで「INSERT INTO <スキーマ名>. TEMSG “CHECKPOINT R3LOAD EXPORT STOP dd:mm:yy hh:mm:ss”」というステートメントを実行します (正確なコマンドは移行元 DBMS により異なります)。
  10. トランザクション ログの自動バックアップを停止します。プライマリ DB サーバーで最後のトランザクション ログのバックアップを手動で 1 回実行し、バックアップがクローン サーバーにコピーされたことを確認します。
  11. 3 つのノードすべてで最後のトランザクション ログのバックアップを復元します。
  12. 3 つの「クローン」ノードでデータベースを復元します。
  13. 4 つのノード「すべて」で「SELECT EMTEXT FROM <スキーマ名>. TEMSG」というステートメントを実行します。
  14. 4 つの DB サーバー (プライマリと 3 つのクローン) の上記の SELECT ステートメントの出力を、スマートフォンやカメラで撮影します。クローン DB とプライマリが同一であり、データに差がないことを証明するため、それぞれのホスト名が見えるように撮影します。これを保管し、DB レプリケーション ステータスからサインオフするようにユーザーに依頼します。
  15. 各 R3load エクスポート サーバーで export_monitor.bat を起動します。
  16. Azure へのダンプ ファイルのコピーを開始します (AzCopy または Robocopy を使用)。
  17. R3load Azure VM で import_monitor.bat を起動します。

次の図では、既存の本番環境の DB サーバーのログを「クローン」データベースにログシップしています。それぞれの DB サーバーに 1 つ以上の Intel R3load サーバーが割り当てられます。

ネットワーク アップロードの最適化

既定の 1,500 バイトよりも大きい Ethernet フレームは、ジャンボ フレームと呼ばれ、平均的に 9,000 バイトほどのサイズになります。移行元の DB サーバーのフレーム サイズを大きくすることで、スイッチや R3load サーバーなどのネットワーク上のデバイスの CPU 消費が抑えられるため、ネットワーク スループットが向上します。フレーム サイズは、すべてのデバイスで同一である必要があります。これが揃っていないと、リソースを大量に消費する変換処理が発生します。

Receive Side Scaling (RSS、英語) などの高度なネットワーク機能を有効化して、ネットワーク処理を複数のプロセッサに分散するように構成することができます。ただしVMWare で R3load サーバーを実行する場合、ジャンボ フレームと RSS を使用したネットワーク チューニングは非常に複雑になるため、きわめて高いスキルを持つエキスパートの方以外にはお勧めしません。

R3load サーバーは DBMS テーブルからデータをエクスポートし、依存関係を持たない生データを圧縮してダンプ ファイルにします。このダンプ ファイルは Azure にアップロードして、移行先の SQL Server データベースにインポートする必要があります。

ダンプ ファイルのコピーと Azure へのアップロードのパフォーマンスは、移行プロセスにおける重要な要素となります。

R3load のダンプ ファイルをアップロードする方法は、主に 2 つあります。
 

  1. AzCopy を使用してパブリック インターネット経由でオンプレミスのエクスポート用 R3load サーバーから Azure Blob Storage にコピーする

それぞれの R3load サーバーでは、以下のコマンド ラインで AzCopy のコピーを実行します。
 

AzCopy /source:C:\ExportServer_1\Dumpfiles /dest:https://<storage_account>/ExportServer_1/Dumpfiles /destkey:xxxxxx /S /NC:xx /blobtype:page

/NC: の値は、ファイル転送時の並列セッション数です。一般に、AzCopy は小規模なファイルを多く扱う場合に高いパフォーマンスを発揮します。/NC の値は 24 ～ 48 に設定します。高性能のサーバーや高速インターネット接続の場合は、この値を上げることもできます。ただし、値が大きすぎるとネットワークが飽和してエクスポート用 R3load サーバーへの接続が切断される可能性があるため、Windows タスク マネージャーでネットワーク スループットを監視する必要があります。エクスポート用 R3load サーバー 1 台のコピー スループットは 1 Gbps 以上で、サーバーの数を増やすことでさらにスケーリングすることができます (上の図では 4 台)。

Blob のファイルを R3load がアクセスできるファイル システムにコピーする際にも、Azure 内のインポート用 R3load サーバーで類似のスクリプトを実行する必要があります。
 

  1. AzCopy や Robocopy を使用して専用の ExpressRoute 接続経由でオンプレミスのエクスポート用 R3load サーバーから Azure VM または Blob Storage にコピーする

Robocopy C:\Export1\Dump1 \\az_imp1\Dump1 /MIR /XF *.SGN /R:20 /V /S /Z /J /MT:8 /MON:1 /TEE /UNILOG+:C:\Export1\Robo1.Log
 
下の図では、4 台の Intel R3load サーバーで R3load を実行しています。バックグラウンドでは、ダンプ ファイルのアップロード時に Robocopy が起動します。分割テーブルとパッケージのコピーがすべて完了したら、手動またはスクリプトで SGN ファイルをコピーします。パッケージの SGN ファイルがインポート用 R3load サーバーに送られると、該当するパッケージのインポート処理が自動的にトリガーされます。

注: NFS または Windows SMB などのプロトコルでのコピー処理は、AzCopy ほどの速度や堅牢性を得られません。いずれの方法も、ファイルのアップロード テストを実施してパフォーマンスを確認することをお勧めします。きわめて高いスループットのネットワーク操作は DoS 攻撃と誤認されるおそれがあるため、VLDB を移行する旨をマイクロソフト サポートに連絡しておくことをお勧めします。

移行先システムの最適化

  1. 最新の修正プログラムが適用された OS を使用します。
  2. 最新の修正プログラムが適用された DB を使用します。
  3. 最新の修正プログラムが適用された SAP カーネル (例. バージョン 7.45 を 7.49 または 7.53 にアップグレード) を使用します。
  4. 可能な限り大きなサイズの Azure VM を使用します。VM は、インポート プロセス完了後に下位の VM に変更することができます。
  5. 複数のトランザクション ログ ファイルを作成します。最初のファイルは非永続的なローカル SSD に、それ以降のファイルは P50 ディスクに作成します。VLDB の移行では、トランザクション ログの容量が 5 TB を超える場合もあります。常にトランザクション ログ用の空き容量を十分に確保 (20% 程度) しておくことを強くお勧めします。インポート中にトランザクション ログ ファイルを拡張するのは、パフォーマンス低下などの影響があるため、お勧めしません。
  6. 通常、SQL Server の max degree of parallelism オプションの値は 1 に設定します。この値を大きくしても、特定のテーブルの限られたインデックス作成処理でしかメリットが得られません。
  7. DB サーバーと R3load サーバーでは、Accelerated Networking が必須です。
  8. DB サーバーには 3.8 TB のストレージを搭載した M128 VM、R3load サーバーには E64v3 を推奨します (2018 年 3 月時点)。
  9. リソース ガバナーを使用して、1 回の SQL Server クエリで要求可能な最大メモリ容量を制限します。非常に大きなメモリ要求によってインデックス作成処理が中断されるのを防止します。
  10. 大規模テーブルのセカンダリ インデックスを STR ファイルから削除し、主なインポート処理後の STMS 構成などの後処理の実行中に、スクリプトを使用してオンラインで作成することができます。
  11. SQL Server TDE を使用する場合、データベースとトランザクション ログ ファイルを事前に作成し、インポートの開始前に TDE を有効化しておくことを推奨します。DB の容量が大きい場合でも空の場合でも、TDE の有効化の実行時間は同じです。しかし、VLDB 上での TDE 有効化処理ではブロックやロックが発生する可能性があるため、一般には TDE 有効化済みのデータベースへのインポートをお勧めします。TDE データベースへのインポート処理のオーバーヘッドは、それほど大きくありません。
  12. OS / DB マイグレーションに関する最新の FAQ を確認しましょう。

移行プロジェクトで推奨されるドキュメント

VLDB の OS / DB マイグレーションでは、高い技術スキルに加え、詳細なドキュメントと手順が必要となります。このドキュメントはダウンタイムを短縮しデータ損失のリスクを回避するためのもので、最低限、以下の内容を記載する必要があります。

  1. 使用中の SAP アプリケーションの名称、バージョン、修正プログラム、DB のサイズ、容量の大きい上位 100 テーブル、DB の圧縮の使用状況、移行元のサーバー ハードウェアの CPU、RAM 容量、ディスク容量
  2. 完了済みのデータのアーカイブ/消去作業と削減された容量
  3. 移行中に適用するアップグレード、Unicode 変換、サポート パックなどの詳細
  4. 移行先の SAP アプリケーションのバージョン、サポート パックのレベル、DB の予想サイズ (圧縮後)、容量の大きい上位 100 テーブル、DB のバージョンと修正プログラム、OS のバージョンと修正プログラム、VM の SKU、VM の構成オプション (ディスク キャッシュ、Write Accelerator、Accelerated Networking、ディスクの種類と容量など)、データベース ファイルのサイズとレイアウト、DBMS の構成オプション (メモリ、トレースフラグ、リソース ガバナーなど)
  5. 通常、セキュリティに関しては別途記載するものですが、ネットワーク セキュリティ グループ、ファイアウォールの設定、グループ ポリシー、DBMS の暗号化設定については記載しましょう。
  6. HA/DR の方式とテクノロジ、初回インポート終了後に適用する HA/DR の設定手順
  7. OS/DB の移行設計に関するアプローチ

- エクスポート用 Intel R3load サーバーの数

- インポート用 R3load VM の数

- R3load VM 1 台あたりのプロセッサ数

- テーブル分割の設定

- パッケージ分割の設定

- エクスポート/インポートの監視の設定

- STR ファイルから削除して手動で作成するセカンダリ インデックスのリスト

- エクスポート前に実行するタスクのリスト (更新の消去など)

  1. 最後に実行したエクスポート/インポート の分析。設定の変更、「フライトプラン」に影響する項目、承認および拒否された構成変更、次回のテストで計画しているチューニングや構成など
  2. 回復手順と例外処理 – ロールバックの手順、最後のテストで発生した例外や問題の処理方法

このドキュメントは、一般に OS/DB マイグレーションを担当するリード コンサルタントが作成します。セキュリティ、HA/DR、ネットワークなど、一部の内容については他のコンサルタントが担当する場合もあります。プロジェクト チームのスキル レベルや能力、ユーザーに対するプロジェクトのリスク レベルが、このドキュメントの品質に如実に表れます。

移行の監視

VLDB の移行において特に重要なのが、移行の開発、テスト、「ドライ ラン」の際に構成する、監視、ログ記録、診断です。

お客様がこのセクションの手順の実施や活用を検討する際には、必ず OS/DBマイグレーションのコンサルタントにご相談ください。適切に実施しないと、大きなリスクとなるおそれがあります。

移行の最適化とカットオーバー計画の策定には、監視機能をデプロイし、各サイクル完了後の監視結果や診断結果を確認することが重要です。また、実際の運用環境の移行がテストと同じパターンとスケジュールで実施できるかどうかを判断するには、テスト結果を把握する必要があります。お客様は、チェックポイントとなる定期的なプロジェクトレビューを SAP パートナーと実施すべきです。マイクロソフトでは、プロジェクトの遂行に必要な技術および運用スキルを持つコンサルタントを紹介しています。必要なお客様はお問い合わせください。

包括的な監視やログ記録なしでは、安全で再現性がある、不整合がなく短いダウンタイムの、データロスなしでの移行は困難です。パッケージの実行に時間かかるなどの問題発生時に、監視データや移行設計書なしではマイクロソフトや SAP がピンポイントでコンサルティングを行うことはほぼ不可能です。

OS/DB マイグレーションでは、以下の値を監視します。

DB および R3load のホストで OS レベルのパラメーター (スレッドごとの CPU 使用率、スレッドごとのカーネル時間、空きメモリ (GB)、1 秒あたりのページ イン数、1 秒あたりのページ アウト数、1 秒あたりのディスク読み込み数、1 秒あたりのディスク書き込み数、1 秒あたりのディスク読み込みデータ量、1 秒あたりのディスク書き込みデータ量)。

移行先の SQL Server で DB レベルのパラメーター (1 秒あたりの BCP 実行行数、1 秒あたりの BCP 実行データ量、トランザクション ログのパーセンテージ、メモリ割り当て、保留中のメモリ割り当て、ロック、ロック メモリ、ロックやブロックの発生)。

通常、ネットワークの監視はネットワーク チームが担当します。ネットワークの監視の構成は、お客様の環境により異なります。

DB のインポート処理中は、以下の SQL ステートメントを数分おきに実行し、何らかの異常があった場合 (待機時間が長いなど) にはスクリーンショットを取得することをお勧めします。
 

select session_id, request_id,start_time,
status, command, wait_type, wait_resource, wait_time, last_wait_type, blocking_session_id from sys.dm_exec_requests
where session_id >49 orderby wait_time desc;

移行テストの各サイクルでは、X 軸に時間、Y 軸にエクスポートまたはインポートされたパッケージ数がプロットされた「フライト プラン」というグラフが必ず作成されます。これにより、最終カットオーバーのプロジェクトの進行速度を予測することができます。テスト環境または運用環境の移行における「フライト プラン」の期待値との差 (良い場合と悪い場合の両方) を簡単に把握できます。CPU、ディスク、1 秒あたりの R3load の実行行数などの他のパラメーターを「フライト プラン」に重ねてプロットすることも可能です。

エクスポート/インポートの終了時には、次の記事を参考に移行時間のレポート (export_time.html および import_time.html) を収集します。https://blogs.sap.com/2016/11/17/time-analyzer-reports-for-osdb-migrations/ (英語)

推奨手順と禁止事項

このガイドラインは、実際のお客様の過去のプロジェクト事例に基づいて作成されています。エクスポート用 R3load サーバーには UNIX サーバーや仮想サーバーを使用しないようにするなど、過去に経験したうまく行かなかった事例に基づいて、特定のシナリオを回避するようアドバイスしています。

  1. ダウンタイム全般におけるボトルネックは、ほとんどがエクスポートのパフォーマンスです。ハードウェアは4 ～ 5 年以上前のものであることが多く、その更新はコストが高すぎて事実上不可能であることもあります。
  2. このような場合、現実的な方法でエクスポートのパフォーマンスを最大化することが重要です。
  3. あるプロジェクトでは、Intel R3load サーバーを採用する前に、UNIX や仮想環境での R3load サーバーのエクスポートのパフォーマンス チューニングに数人週または数人月の労力をかけていました。
  4. 2 ソケットの Intel 汎用サーバーは、非常に手頃な価格でありながら即座に高いパフォーマンスを発揮できるため、UNIX サーバーや仮想サーバーでのチューニングよりもずっと高い効果を得られる可能性があります。
  5. 既に VM ファームをお持ちのお客様でも、最新のオフロード テクノロジや SR-IOV テクノロジに対応しておらず、VMWare のバージョンが古い、修正プログラムが適用されていない、超高スループットや低レイテンシに適していないといったことが少なくありません。エクスポート用 R3load サーバーでは、非常に高いスレッド パフォーマンスとネットワーク スループットが必要とされます。エクスポート用 R3load サーバーの実行中は、10 ～ 15 時間、CPU とネットワークの使用率がほぼ 100% となります。これは VMWare ファームの使用方法として一般的ではなく、ほとんどの VMWare システムはこのようなワークロードを想定した設計にはなっていません。

推奨事項: UNIX や仮想プラットフォームでエクスポート用 R3load サーバーを最適化するよりも、安価な Intel サーバーを購入することで、時間を浪費することもなく大幅にコストを削減できます。VLDB の移行では、エクスポート用 R3load サーバーには必ずプロジェクト開始時点で最新の高速サーバーを採用してください。これにより、プロジェクトの総コストとリスクを抑えることができます。

推奨手順

  1. 移行前の SAP 環境を調査して記録します。現在の SAP サポート パックのレベルを確認し、移行先 DBMS への対応に修正プログラムを適用する必要があるかどうかを判断します。一般的な互換性は、オペレーティング システムの場合は SAP カーネル、DBMS の場合は SAP_BASIS の修正プログラムのレベルによって決まります。

SMIGR_CREATE_DDL の更新など、移行元システムに適用する必要のある SAP Notes のリストを作成します。Azure への移行中に大きな変更が発生しないように、移行元システムの SAP カーネルをアップグレードすることも検討してください (旧バージョンの 7.41 カーネルを最新の 7.45 に更新するなど)。

  1. 高可用性と災害復旧に対応したソリューションを開発します。HA/DR のコンセプトを詳細に説明する PowerPoint を作成します。図には、DB 層、ASCS 層、SAP アプリケーション サーバー層を記載します。TREX や Livecache などのスタンドアロン型ソリューションには、別途ソリューションが必要です。
  2. Azure VM の種類とストレージ構成を記述するサイジングと構成のドキュメントを作成します。ここでは、Premium Storage のディスク数、データ ファイル数、各ディスクへのデータ ファイルの分散方法、ストレージ容量の使用状況、NTFS のフォーマット サイズを 64 KB にするなどの仕様を記載します。また、バックアップと復元方法のほか、メモリ設定、Max Degree of Parallelism、トレースフラグなどの DBMS 構成も含めます。
  3. VNet、サブネット、NSG、UDR の構成など、ネットワーク設計書を作成します。
  4. Internet Explorer の削除、SAP のサービス アカウントおよびサーバー用の Active Directory コンテナーの作成、特定ポート以外のトラフィックをすべてブロックするファイアウォール ポリシーの適用など、セキュリティ強化のコンセプトを作成します。
  5. OS /DB マイグレーション設計書を作成します。これには、パッケージやテーブル分割のコンセプトの詳細、R3load サーバーの数、SQL Server のトレースフラグ、ソートの有無、Oracle の ROWID の設定、SMIGR_CREATE_DDL の設定、Perfmon カウンター (1 秒あたりの BCP の実行行数やスループット、CPU、メモリ)、RSS の設定、Accelerated Networking の設定、ログ ファイルの構成、BPE の設定、TDE の設定などを記載します。
  6. 各テスト サイクルでの R3load サーバーのエクスポート/インポートの進捗状況を示す「フライト プラン」グラフを作成します。移行コンサルタントは、これを R3load サーバーのチューニングや変更の検証に活用し、エクスポートとインポートのパフォーマンスを向上させることができます。このグラフの X 軸は時間、Y 軸は処理が完了したパッケージ数です。運用環境の移行でも、フライト プランは重要な役割を果たします。計画上の進捗状況と実際の進捗状況を比較することで、問題を早期に発見できます。
  7. パフォーマンス テスト計画を作成します。影響の大きい上位 20 個のレポート、バッチ ジョブ、インターフェイスを特定します。入力パラメーター (日付範囲や販売店、工場、企業のコードなど) と移行元システムの実行時間を記録し、Azure での実行時間と比較します。SAT や ST05 などの SAP ツールでの実行パフォーマンスの差を確認し、非効率なステートメントを特定します。
  8. SAP BW on SQL Serverを利用する場合、定期的にこのブログを参照し、列ストアなどの BW システムの新機能を確認してください。
  9. 監査機能のデプロイと構成では、クラスターのタイムアウト、カーネル、ネットワーク設定、NTFS のフォーマット サイズをすべて設計書どおりにします。重要なサーバーの Perfmon カウンターを設定し、90 秒ごとに基本的な正常性パラメーターを記録します。SAP サーバーが別の AD コンテナーに存在し、コンテナーにファイアウォール構成のポリシーが適用されているかどうかを検査します。
  10. OS / DB マイグレーションを担当するリード コンサルタントがライセンスを保有していることを確認します。コンサルタントの名前、S-User、認定日を確認します。OSS メッセージを BC-INS-MIG に発行し、コンサルタントが現在ライセンスを保有しているかどうかを SAP に確認します。
  11. 可能であれば、VLDB 移行プロジェクトに携わるプロジェクト チームが地理的に複数の大陸やタイム ゾーンにまたがることのないように、1 拠点に集まります。
  12. 必ず適切なフォールバック計画を実装し、スケジュールに組み込みます。
  13. エクスポート用 R3load サーバーには必ず高いスレッド パフォーマンスを持つ Intel CPU を使用します。「省電力」モデルの CPU は、パフォーマンスが非常に低いので使用しないでください。また、4 ソケットのサーバーも使用しないでください。Intel Xeon E5 Platinum 8158 などのプロセッサが適しています。

禁止事項

  1. VLDB の OS / DB マイグレーションには、高度な技術スキルと堅牢なプロセス、変更管理、ドキュメントが必要です。VLDB 移行では OJT などは実施しないでください。
  2. エクスポートとインポートを外部委託する場合は、別々のコンサルティング企業に依頼しないでください。移行時に、移行元のシステム保守を外部委託している企業からパートナーを変更したいという場合もありますが、エクスポートとインポートのチューニングと構成は互いに深く関係しているため、同じ担当者が行わない場合には失敗のリスクが高くなります。
  3. システムの移行中と運用開始時には、低コストの Azure のハードウェア リソースは採用しないでください。Azure VM の料金は 1 分単位で計算され、また非常に容易にサイズを変更できます。VLDB の移行中は、可能な限り高性能な VM を使用してください。過去のお客様事例では、運用開始時に安定稼働させるために、余裕を持って 200 ～ 250% のサイズを持つシステムを採用しました。その後 4 ～ 6 週間ほど監視を継続してから、VM サイズの縮小およびシャットダウンによってコストを削減しました。

役立つドキュメントとヒント

次のリンクは、このソリューションをセットアップする際に役立つ、テスト デプロイに基づいた推奨事項です。

SAP on Microsoft Azure のブログ: https://blogs.msdn.microsoft.com/saponsqlserver/ (英語)

SAP の OS / DB マイグレーションに関する最新の FAQ: https://blogs.msdn.microsoft.com/saponsqlserver/tag/migration/ (英語)

データベース移行に役立つブログ記事: https://blogs.sap.com/2017/10/05/your-sap-on-azure-part-2-dmo-with-system-move/ (英語)

データベース移行の関連情報: https://blogs.sap.com/2013/11/29/database-migration-option-dmo-of-sum-introduction/ (英語)

Content from third party websites, SAP and other sources reproduced in accordance with Fair Use criticism, comment, news reporting, teaching, scholarship, and research.