移行パターン  

SAP などの基幹システムのクラウド移行は、他のシステムの移行と比べてチャレンジングな作業になることが多くあります。それは、データサイズの大きさや、システムの複雑性、許容されるダウンタイムが短いことや、複数のチームを跨いだ検証が必要、など多くの事象に起因します。本節では、SAP システムの移行について解説をします

オンプレミスから Google Cloud への移行

解決する課題・使い所

本項では、SAP 移行の中でも特にキーとなる、SAP HANA の移行方法について整理をしていきます。SAP HANA の移行ツールの特性を見極め、適切な方法で移行作業を計画 / 実施するための情報を提供します。 


Google Cloud への移行方法

“仮想マシンの Google Compute Engine(GCE)への移行”にて、一般的な仮想マシンの移行方法について記載をしました。SAP HANA の移行においても、基本的な考え方は同じですが、ここではもう少し踏み込んで、移行方法を具体的に解説します。


アーキテクチャ / 移行のステップ

ここでは上述の 2 の中の SAP HANA System Replication を使用した方法で、SAP HANA を GCE に移行するアーキテクチャ / 移行のステップを記載します。なお、SAP HANA System Replication については、SAP HANA の機能のため、詳細や最新の手順については SAP 社の公式情報を参照ください。

なお、Netweaver 側は、VM インポートなどを使って移行を行い、必要に応じて追い付き移送などを行ってオンプレと同じ状態にしておきます。HANA 移行が完了したタイミングで、DB 接続 IP や DNS の変更などを行い、本番利用を開始します

利点


注意事項

ダウンタイムをとる必要がある場合は、トラブル発生時のリトライ時間や、切り戻し計画も含めて作業を計画します。特に数 TB 級のデータを扱う場合、データ転送や起動だけで数時間要する可能性もあるので、十分な時間を確保する必要があります。また、机上の計算だけではなく、必要に応じて移行リハーサルなどを行います。 SAP HANA だけではなく、NetWeaver や SolutionManager , その他周辺システムなども含めて移行や検証の時間軸を決める必要があります。 “Google Cloud の VM 移行機能を使用した移行”を行う場合、移行後にライセンス情報を再度入力する必要があります。すぐに失効しないものの、数週間以内にはライセンスを投入し直す必要があるため、注意が必要です


関係するデザインパターン


参照ドキュメント