AWS SMSを使用したSAPワークロードのAWSクラウド移行

この記事は、Amazon Web Services (AWS)のソリューションアーキテクト、Harpreet SinghとDevendra Singhによるものです。

AWS Server Migration Service (AWS SMS)は、オンプレミスのVMware vSphereあるいはMicrosoft Hyper-Vの仮想マシンをAWSクラウドに移行するためのエージェントレスサービスです。このブログ記事では、AWS SMSの主な利点を説明し、このサービスを使用して仮想化されたオンプレミス（またはプライベートクラウド）のSAPワークロードをAWSクラウド上のAmazon Elastic Compute Cloud (Amazon EC2) インスタンスに移行する方法を説明します。

AWS SMSを使用することの利点を以下にいくつか記載します：

簡略化された移行: ソース環境を設定した後、AWSマネジメントコンソールからレプリケーションジョブをスケジュールすることで、仮想マシンを簡単に移行できます。レプリケーションからAmazon Machine Image (AMI)の作成は、レプリケーションジョブを実行した時に自動的に処理される4段階のプロセスから成ります。
増分移行: AWS SMSはライブ環境を増分的にレプリケーションすることができ、移行プロセスを大幅にスピードアップすることができます。本稼働環境がAWSクラウドにレプリケーションされている間も、本稼働環境を利用し続けることができます。
ダウンタイム最小化: 増分レプリケーション中は本稼働運用に影響ありません。ただし、最終的なレプリケーション（カットオーバー）にはダウンタイムが必要です。
並列移行: AWS SMSでは、複数の仮想マシンを並行して移行できます。この機能を使用すると、ランドスケープ全体を移行することができます（例えば、すべての開発システムを一度に移行し、それから品質保証システムを移行するなど）。

AWS SMSは無償で使用できます。ただし、レプリケーション中は、Amazon Elastic Block Store (Amazon EBS) スナップショットが作成され、Amazon Simple Storage Service (Amazon S3)にこれらのスナップショットが保存されるため、これらのリソースに関連するコストが発生します。料金についての情報は、AWSウェブサイトを参照してください。

このブログ記事では、AWS SMSの一般的なレプリケーションプロセスについて説明し、次にAWS SMSを使用したSAPワークロードの移行方法について説明します。

レプリケーションプロセス

AWS SMSのためのオンプレミスの仮想化環境とAWSアカウントの設定について、詳細な手順はAWSウェブサイトのVMwareとHyper-Vを参照するか、AWS Partner Network (APN) ブログの記事「AWS Server Migration Service – クラウドへのサーバー移行が簡単に！」を参照してください。設定の一環として、仮想化環境にAWS Server Migration Connectorを導入します。設定が完了したら、日時と頻度を指定してレプリケーションジョブを作成します。ジョブを作成すると、AWS SMSをによる仮想マシンのレプリケーションが自動的に開始され、4つのステップに従います。これらの4つのステップ、スケジュール化、アップロード、変換、そしてAMIの作成は、各レプリケーションジョブの開始ごとに順次実行されます。

図 1: AWS SMSのレプリケーションプロセスのステージ

スケジュール化

このステップでは、設定したレプリケーションジョブを特定の時刻に実行するか、またはすぐに実行するようにスケジュールされています。

図 2: レプリケーションジョブのスケジュール状況

アップロード

これは複数のステップで処理されます。

仮想マシンのVMwareまたはHyper-Vスナップショットがトリガーされます。スナップショットは、VMDKファイル（VMware用）またはAVHDファイル（Hyper-V用）を作成します。
Open Virtualization Format (OVF) ファイルが仮想マシン用に作成されます。これは、仮想マシンに関するメタデータを含むXMLファイルです。
スナップショットによって作成されたVMDKまたはAVHDファイルは、あるS3バケットにアップロードされます。このS3バケットは、AWS Server Migration Connectorを設定したAWSリージョンで自動的に作成されます。
スナップショットファイルがS3にアップロードされると、スナップショットファイルはソース環境から削除されます。

図 3: アップロードされたVMDKファイルを格納するS3バケット

変換

このステップは、2つのタスクを処理します。

AWS SMSは、アップロードされたVMDKまたはAVHDファイルからEBSスナップショットを作成します。
AWS SMSは、S3バケットからVMDKまたはAVHDファイルを削除します。

AMIの作成

このステップでは、変換ステップで生成されたEBSスナップショットからAmazon Machine Image (AMI)を作成します。このステップが完了したら、作成したAMIからAmazon EC2インスタンスを起動できます。

レプリケーションジョブはスケジュールされた頻度で実行され続け、実行ごとにこれらのステップが繰り返されます。レプリケーションジョブを実行するたびに、AWSクラウドへの増分変更だけが行われます。レプリケーションが完了し、サーバを稼働させる準備ができたら、本稼働環境のサーバ（オンプレミス）を停止して以降の変更を防止し、最後に実行した差分をインポートするジョブを最後に実行します。最終的な変更がAWSクラウドにレプリケーションされたら、AMIからEC2インスタンスを作成できます。

AWS SMSを使ったSAPワークロードの移行

レプリケーションプロセスについて説明したので、続いてAWS SMSを使用して仮想化されたSAP環境をAWSクラウドに移行する方法について説明します。

リフト・アンド・シフト、またはSAP HANAへの移行の2つの移行オプションがあります。

リフト・アンド・シフト移行

このシナリオでは、Windows、Red Hat Linux、SUSE Linux、あるいはOracle Linuxで稼働する仮想化されたSAP環境を、オペレーティングシステムやデータベースに変更を加えることなくそのままAWSクラウドに移行できます。このプロセスは、次のステップで構成されます。

データベースおよびアプリケーション(SAP ASCS / SCS、PAS、AAS)、またはSAP NetWeaverベース以外のアプリケーション(BusinessObjects BIなど)を含む様々な仮想マシンに対して、定期的にレプリケーションジョブをスケジュールします。データベースの場合は12時間、データベース以外の仮想マシンの場合は24〜48時間の間隔をお勧めします。
レプリケーションジョブの最初の実行を完了します。このジョブは、初期レプリケーションかつ完全レプリケーションであるため、事前にスケジュールする必要があります。完了するまでに時間がかかります。実行時間は、仮想マシンのサイズによって異なります。
増分実行が正常終了できるかレプリケーションジョブを監視し（少なくとも2回実行することをお勧めします）、各連続したレプリケーションジョブが完了するのにかかる時間に注目してください。これにより、最終的なカットオーバーに必要な停止時間の見積もりもできます。後続の実行には差分の変更のみが必要であり、最初の完全レプリケーション後の後続のジョブを完了するまでに要する時間は非常に短くなるため、少なくとも2回の増分実行を完了することをお勧めします。例えば、次の図に示すレプリケーションでは、完全レプリケーションは約8時間かかり、増分実行は約1.5時間で完了しました。

図 4: 初期レプリケーション後の実行時間の短縮
最終的なカットオーバーを計画します。カットオーバーの場合は、社内での本稼働運用を停止し（例えば、SAPアプリケーションを停止します）、最後のレプリケーションジョブを実行して差分の変更をAWSクラウドに移行します。また、最終的なカットオーバーの前にモックカットオーバーをステージングで実施することをお勧めします。
最後のレプリケーションジョブによって作成されたAMIからEC2インスタンスを作成します。
DNS（またはホストファイル）の更新、検証、連携などの移行後の手順を完了します。
本稼働します。

次の図 5は、レプリケーションプロセスを説明しています。

図 5: SAPワークロードをそのままAWSクラウドにレプリケーションするステップ

SAP HANAへの移行

SAP HANAをオンプレミスで稼働しておらず、SAP HANA化しつつAWSクラウドに移行したい場合は、AWS SMSを使用することでダウンタイムを大幅に短縮できます。このアプローチでは、次の2つのステップになります。

前述のリフト・アンド・シフトの移行手順に従って、Windows、Red Hat Linux、SUSE Linux、あるいはOracle Linuxで稼働している仮想マシンをそのままAWSに移行します。
AWS上でSAP HANAに移行します。既にAWS上でSAPアプリケーションを実行していて、ソースとターゲット両方のSAPシステムがAWS上にあるため、大規模なデータベースの場合であってもSAP HANAへの移行が非常に高速にできます。
- エクスポートとインポートのプロセスを最適化するためのリソースの利用に制約はなくなります。
- SAP Database Migration Option (DMO)を使えば、ユニコード変換、アップグレード、および移行を一度に実行できます。詳細については、このブログで以前に公開したDMOの記事を参照してください。

このブログ記事では、AWS SMSを使用してSAPワークロードをAWSクラウドに簡単に移行し、さらに移行に必要なダウンタイムを削減する方法を説明しました。

AWSプロモーションクレジットを使用して、SAPシステムをAWSに移行することができます。その方法とクレジットの申請方法については、こちらまでお問い合わせください。

翻訳はPartner SA 河原が担当しました。原文はこちらです。

Amazon Web Services ブログ