移行パターン
SAP などの基幹システムのクラウド移行は、他のシステムの移行と比べてチャレンジングな作業になることが多くあります。それは、データサイズの大きさや、システムの複雑性、許容されるダウンタイムが短いことや、複数のチームを跨いだ検証が必要、など多くの事象に起因します。本節では、SAP システムの移行について解説をします。
デザイン パターン詳細
オンプレミスから Google Cloud への移行
解決する課題・使い所
本項では、SAP 移行の中でも特にキーとなる、SAP HANA の移行方法について整理をしていきます。SAP HANA の移行ツールの特性を見極め、適切な方法で移行作業を計画 / 実施するための情報を提供します。
Google Cloud への移行方法
“仮想マシンの Google Compute Engine（GCE）への移行”にて、一般的な仮想マシンの移行方法について記載をしました。SAP HANA の移行においても、基本的な考え方は同じですが、ここではもう少し踏み込んで、移行方法を具体的に解説します。
1. Google Cloud の VM 移行機能を使用した移行
Migrate for Compute Engine や OVF / OVA インポート、 仮想ディスクインポート機能などを使用して、VM を丸ごと移行します。 既存の環境を丸ごと Export / Import を行うことで、変化を最小限に抑えつつ移行を実現できます。OS の中身も含めて、既存の構成の多くが引き継がれるため、テストの工数などを最小化しつつクラウド化したい場合に、こちらの方法を選択されることあります。
また、クラウド環境での検証は、移行作業完了後に始めることになるため、その作業時間も含めて、必要なダウンタイムを事前に見積もっておく必要があります。
2. SAP HANA の機能を使用した移行:
GCE に SAP HANA を新規構築し、SAP HANA System Replication や System Copy などを使用してデータのコピーを行います。 1 とは異なり、クラウド側にまずは SAP HANA を構築し、その後 SAP HANA のデータを SAP HANA の機能である SAP HANA System Replication を使用して転送するやり方です。この方法の利点は、SAP HANA を構築したタイミングで、Google Cloud 側の検証などを開始することができるため、ダウンタイムの要件に検証の計画が影響されないことです。また、1 と比べてダウンタイムも短縮することができます。
3. その他ソリューションを使用した移行:
SAP やサードパーティー のソリューションを使用した移行方法です。 詳細は割愛しますが、SAP Landscape Transformation （SAP LT） や SAP Database Migration Option （SAP DMO）や、 SNP 社などサードパーティーのソリューションを使用して、データの変換や、移行を実現することができます。1, 2 と違い、HANA 以外のデータベースからの SAP HANA への移行もサポートしているツールも存在します｡
また、クラウド環境での検証は、移行作業完了後に始めることになるため、その作業時間も含めて、必要なダウンタイムを事前に見積もっておく必要があります。
アーキテクチャ / 移行のステップ
ここでは上述の 2 の中の SAP HANA System Replication を使用した方法で、SAP HANA を GCE に移行するアーキテクチャ / 移行のステップを記載します。なお、SAP HANA System Replication については、SAP HANA の機能のため、詳細や最新の手順については SAP 社の公式情報を参照ください。
なお、Netweaver 側は、VM インポートなどを使って移行を行い、必要に応じて追い付き移送などを行ってオンプレと同じ状態にしておきます。HANA 移行が完了したタイミングで、DB 接続 IP や DNS の変更などを行い、本番利用を開始します。
1. Secondary SAP HANA を構築
GCE に SAP HANA を構築します。なお、HANA の構築については、Deployment Manager などの機能を使用して自動化することもできます。
2. Replication の有効化
移行元の SAP HANA 環境で、System Replication を有効化し、GCE 側の SAP HANA を Replication 先として登録します。
3. フェイルオーバーの実施
フェイルオーバーを実施し、Primary を GCE 側に切り替えます。
4. Replication の解除
必要に応じて、Replication を解除します。
利点
- 既存のワークロードと完全に独立した環境でテストを行うことができるため、ダウンタイムの要件に縛られずにテストを計画することができます。
- ダウンタイムは、切り替えに要する時間だけのみなので、他のやり方と比べて少ないダウンタイムで移行を完了することができます。
注意事項
ダウンタイムをとる必要がある場合は、トラブル発生時のリトライ時間や、切り戻し計画も含めて作業を計画します。特に数 TB 級のデータを扱う場合、データ転送や起動だけで数時間要する可能性もあるので、十分な時間を確保する必要があります。また、机上の計算だけではなく、必要に応じて移行リハーサルなどを行います。 SAP HANA だけではなく、NetWeaver や SolutionManager , その他周辺システムなども含めて移行や検証の時間軸を決める必要があります。 “Google Cloud の VM 移行機能を使用した移行”を行う場合、移行後にライセンス情報を再度入力する必要があります。すぐに失効しないものの、数週間以内にはライセンスを投入し直す必要があるため、注意が必要です。
関係するデザインパターン
仮想マシンの Google Compute Engine（GCE）への移行 （準備中）