はじめに
今回のブログポストは、以下3回シリーズのPart 3となります。
Part 1: 概要とデザインアプローチ (1)
Part 2: デザインアプローチ (2)
Part 3: 移行アプローチ
前回はデザインアプローチとしてサイジング要素の後半以降を記載しましたが、今回は移行アプローチについて記載したいと思います。
移行アプローチ
Hyperscalerに移行するためのSAP標準アプローチについて、4つのシナリオに沿って解説いたします。
4つのシナリオ
Lift & Shift (Re-host、Re-platform、Re-architect) など同じようなアプローチやまとめ方がありますが、ここではお客様のシステムで想定されるイベントベースで移行シナリオを挙げさせて頂き、それぞれ利用できるツールやサービスの観点で話をさせて頂きます。
まず最初に「Transition to SAP S/4HANA」ですが、現行のシステムをS/4HANAへ移行するというミッションに対して、これと併せてHyperscalerへの移行についても完了させる場合のシナリオになります。
既存のSAP ERP on anyDBから移行するケースを考えると、スタンダードアプローチとしてはDMO with System MoveでIaaS上にSAP S/4HANAとして移行する方式があります（下図上段）。ダウンタイム要件が許容されるのであれば、フォールバックを考慮して、既存のオンプレミスランドスケープ環境はそのまま残しておき、HyperscalerのIaaS上に一度システムコピーしてから、DMO with System Moveを実行するという手もあります。Hyperscalerであれば中間状態のハードウェアリソースを一時的に増大させる柔軟な対応も比較的容易に可能ですので、現行システム側にDMO実行のための十分なリソース・パワーがない場合には有効です。
ダウンタイムミニマイズドアプローチとしては、コンサルティングベースでの有償サービスとなりますが、NZDTを使用し、ダウンタイムを大幅に短くすることも可能です（下図下段）。
SAP ERP on HANA (SOH)から移行するケースを考えますと、スタンダードアプローチとしてはSUMでS/4HANAコンバージョンしてから、Hyperscalerにバックアップ・リストアもしくはHSRによって移行する方式があります（下図上段）。このケースですと最初のステップとしてS/4HANAコンバージョンがあるため、HSRによる移行方式はあまり使われていないかと思いますが、ダウンタイムの要件などにより、一旦オンプレミスで稼働させてから別スケジュールでHyperscalerに移行するというプランも取り得ます。バックアップ・リストア方式ですとバックアップファイルをネットワーク転送するという時間が膨大になってしまう場合がありますので、HSRを組んで、極力ダウンタイムを少なくするという観点で有効な方式です。
ダウンタイムミニマイズドアプローチとしては、Downtime-optimized ConversionでSAP S/4HANA化してから、上記同様にバックアップ・リストアもしくはHSRによって移行する方式があります（下図下段）。なお、Downtime-optimized Conversionは現時点ではSAPサービスベースでのみ利用が可能となります。 (SAP Note 2293733)
次に「SAP Upgrades」ですが、既にSAP S/4HANAもしくはSAP ERPをご使用頂いているお客様で、それぞれSAP S/4HANAのバージョンをアップグレードもしくはSAP ERPをアップグレードするとともにHyperscalerへの移行についても完了させたい場合のシナリオになります。
既存のSAP S/4HANAをアップグレードするケースを考えますと、スタンダードアプローチとしてはSUM、もしくはSUMのnZDMオプションを使用してSAP S/4HANAアップグレードを行い、バックアップ・リストアもしくはHSRでHyperscalerに移行する方式（下図上段）と、ZDOを利用してSAP S/4HANAのアップグレードを行い、その後バックアップ・リストアもしくはHSRでHyperscalerに移行するパターンがあります（下図下段）。ZDOは現時点ではSAPサービスベースでのパイロットプロジェクトとしてのみ利用が可能となります。 (SAP Note 2707731)
既存のSAP ERPをアップグレードするケースについては、SAP S/4HANAのケースとほぼ同様となります（下図）が、この場合ZDOはサービスベースやパイロットプロジェクトのような制限はありません。 (SAP Note 2163060)
次に「Platform Migration」ですが、既にSAP S/4HANAもしくはSAP ERPをご使用頂いているお客様で、それぞれSAPアプリケーションとしてはそのままの状態でHyperscalerへ移行させたい場合のシナリオになります。いわゆるRe-hostやRe-platformと同じことを差しています。
このケースの場合、一例として現行がSAP ERP on anyDBで、ターゲットがSAP ERP on HANAの場合、スタンダードアプローチとしてはDMO with System Moveの中でシステムアップデートを伴わないオプションでのDMOを利用することでHyperscalerへ移行する方式（下図上段）の他、この例の場合極端な手法と映ってしまいがちですが、超巨大なシステムなどについてはダウンタイムミニマイズドアプローチとして、コンサルティングサービスであるNZDTでダウンタイムを極小化して移行する方式（下図下段）なども考えられます。
いわゆるRe-hostのような単純なプラットフォームマイグレーションでDBを変更しないという場合ですと、SWPMや各DBで用意されているバックアップ・リストア手法などを利用してHyperscalerへ移行することも可能です。
4つめの「SAP HANA & Ad-hocs」は、Hyperscalerへの移行のタイミングで行うかどうかはややニッチなところですが、SAP HANAのアップグレードやリビジョンアップを実行するシナリオであったり、あるいはSAP HANAをシングル構成からスケールアウト構成へ移行するシナリオ、その他Ad-hocに変更が入るイベントについて、同時にHyperscalerへ移行する契機として想定されるシナリオとして考えられます。下図はスケールアウト構成への変更例となります。
以上、Hyperscalerに移行するためのSAPの標準アプローチを4つのシナリオに沿ってご紹介いたしましたが、これらはあくまでもSAPの立場でご紹介できるものとなります。Hyperscalerなどのクラウドベンダ含むSAPパートナー各社で展開されている最新情報も併せてご確認頂き、お客様にとってよりよい方法についてご検討頂ければと思います。
まとめ
今回のブログポストでご説明した内容は、Hyperscalerへの移行を検討する際の一般的な考え方や考慮すべきポイントについて技術的な視点でまとめたものになります。個々のお客様のビジネス要件や環境要因などによっては考慮すべき要素が変わってくる部分もありますし、Hyperscaler自体が日進月歩の世界ですので、新しく出てきた技術要素がSAPでは使用可能か、効果があるのかといった懸念や確認ポイントが常に出てくるものであります。弊社としてはパートナーの皆様と協力しながらお客様の懸念を解決し、いち早くクラウドの世界へ導いていけるようにと考えております。
弊社のプレミアムエンゲージメントサービスでは、今回ご紹介した内容について、SAPのベストプラクティスとしてはどうなっているか、Globalではどのように対応しているかといった問い合わせに対応することも可能ですので、こちらもご活用頂ければ幸いです。
参考情報
https://blogs.sap.com/2020/10/15/upcoming-migrate-and-operate-sap-landscape-on-hyperscalers-sap-inno...
今回のブログポストは、以下3回シリーズのPart 3となります。
Part 1: 概要とデザインアプローチ (1)
Part 2: デザインアプローチ (2)
Part 3: 移行アプローチ
前回はデザインアプローチとしてサイジング要素の後半以降を記載しましたが、今回は移行アプローチについて記載したいと思います。
移行アプローチ
Hyperscalerに移行するためのSAP標準アプローチについて、4つのシナリオに沿って解説いたします。
4つのシナリオ
- Transition to SAP S/4HANA
- SAP Upgrades
- Platform Migration
- SAP HANA & Ad-hocs
Lift & Shift (Re-host、Re-platform、Re-architect) など同じようなアプローチやまとめ方がありますが、ここではお客様のシステムで想定されるイベントベースで移行シナリオを挙げさせて頂き、それぞれ利用できるツールやサービスの観点で話をさせて頂きます。
- Transition to SAP S/4HANA
まず最初に「Transition to SAP S/4HANA」ですが、現行のシステムをS/4HANAへ移行するというミッションに対して、これと併せてHyperscalerへの移行についても完了させる場合のシナリオになります。
既存のSAP ERP on anyDBから移行するケースを考えると、スタンダードアプローチとしてはDMO with System MoveでIaaS上にSAP S/4HANAとして移行する方式があります（下図上段）。ダウンタイム要件が許容されるのであれば、フォールバックを考慮して、既存のオンプレミスランドスケープ環境はそのまま残しておき、HyperscalerのIaaS上に一度システムコピーしてから、DMO with System Moveを実行するという手もあります。Hyperscalerであれば中間状態のハードウェアリソースを一時的に増大させる柔軟な対応も比較的容易に可能ですので、現行システム側にDMO実行のための十分なリソース・パワーがない場合には有効です。
ダウンタイムミニマイズドアプローチとしては、コンサルティングベースでの有償サービスとなりますが、NZDTを使用し、ダウンタイムを大幅に短くすることも可能です（下図下段）。
SAP ERP on HANA (SOH)から移行するケースを考えますと、スタンダードアプローチとしてはSUMでS/4HANAコンバージョンしてから、Hyperscalerにバックアップ・リストアもしくはHSRによって移行する方式があります（下図上段）。このケースですと最初のステップとしてS/4HANAコンバージョンがあるため、HSRによる移行方式はあまり使われていないかと思いますが、ダウンタイムの要件などにより、一旦オンプレミスで稼働させてから別スケジュールでHyperscalerに移行するというプランも取り得ます。バックアップ・リストア方式ですとバックアップファイルをネットワーク転送するという時間が膨大になってしまう場合がありますので、HSRを組んで、極力ダウンタイムを少なくするという観点で有効な方式です。
ダウンタイムミニマイズドアプローチとしては、Downtime-optimized ConversionでSAP S/4HANA化してから、上記同様にバックアップ・リストアもしくはHSRによって移行する方式があります（下図下段）。なお、Downtime-optimized Conversionは現時点ではSAPサービスベースでのみ利用が可能となります。 (SAP Note 2293733)
- SAP Upgrades
次に「SAP Upgrades」ですが、既にSAP S/4HANAもしくはSAP ERPをご使用頂いているお客様で、それぞれSAP S/4HANAのバージョンをアップグレードもしくはSAP ERPをアップグレードするとともにHyperscalerへの移行についても完了させたい場合のシナリオになります。
既存のSAP S/4HANAをアップグレードするケースを考えますと、スタンダードアプローチとしてはSUM、もしくはSUMのnZDMオプションを使用してSAP S/4HANAアップグレードを行い、バックアップ・リストアもしくはHSRでHyperscalerに移行する方式（下図上段）と、ZDOを利用してSAP S/4HANAのアップグレードを行い、その後バックアップ・リストアもしくはHSRでHyperscalerに移行するパターンがあります（下図下段）。ZDOは現時点ではSAPサービスベースでのパイロットプロジェクトとしてのみ利用が可能となります。 (SAP Note 2707731)
既存のSAP ERPをアップグレードするケースについては、SAP S/4HANAのケースとほぼ同様となります（下図）が、この場合ZDOはサービスベースやパイロットプロジェクトのような制限はありません。 (SAP Note 2163060)
- Platform Migration
次に「Platform Migration」ですが、既にSAP S/4HANAもしくはSAP ERPをご使用頂いているお客様で、それぞれSAPアプリケーションとしてはそのままの状態でHyperscalerへ移行させたい場合のシナリオになります。いわゆるRe-hostやRe-platformと同じことを差しています。
このケースの場合、一例として現行がSAP ERP on anyDBで、ターゲットがSAP ERP on HANAの場合、スタンダードアプローチとしてはDMO with System Moveの中でシステムアップデートを伴わないオプションでのDMOを利用することでHyperscalerへ移行する方式（下図上段）の他、この例の場合極端な手法と映ってしまいがちですが、超巨大なシステムなどについてはダウンタイムミニマイズドアプローチとして、コンサルティングサービスであるNZDTでダウンタイムを極小化して移行する方式（下図下段）なども考えられます。
いわゆるRe-hostのような単純なプラットフォームマイグレーションでDBを変更しないという場合ですと、SWPMや各DBで用意されているバックアップ・リストア手法などを利用してHyperscalerへ移行することも可能です。
- SAP HANA & Ad-hocs
4つめの「SAP HANA & Ad-hocs」は、Hyperscalerへの移行のタイミングで行うかどうかはややニッチなところですが、SAP HANAのアップグレードやリビジョンアップを実行するシナリオであったり、あるいはSAP HANAをシングル構成からスケールアウト構成へ移行するシナリオ、その他Ad-hocに変更が入るイベントについて、同時にHyperscalerへ移行する契機として想定されるシナリオとして考えられます。下図はスケールアウト構成への変更例となります。
以上、Hyperscalerに移行するためのSAPの標準アプローチを4つのシナリオに沿ってご紹介いたしましたが、これらはあくまでもSAPの立場でご紹介できるものとなります。Hyperscalerなどのクラウドベンダ含むSAPパートナー各社で展開されている最新情報も併せてご確認頂き、お客様にとってよりよい方法についてご検討頂ければと思います。
まとめ
今回のブログポストでご説明した内容は、Hyperscalerへの移行を検討する際の一般的な考え方や考慮すべきポイントについて技術的な視点でまとめたものになります。個々のお客様のビジネス要件や環境要因などによっては考慮すべき要素が変わってくる部分もありますし、Hyperscaler自体が日進月歩の世界ですので、新しく出てきた技術要素がSAPでは使用可能か、効果があるのかといった懸念や確認ポイントが常に出てくるものであります。弊社としてはパートナーの皆様と協力しながらお客様の懸念を解決し、いち早くクラウドの世界へ導いていけるようにと考えております。
弊社のプレミアムエンゲージメントサービスでは、今回ご紹介した内容について、SAPのベストプラクティスとしてはどうなっているか、Globalではどのように対応しているかといった問い合わせに対応することも可能ですので、こちらもご活用頂ければ幸いです。
参考情報
https://blogs.sap.com/2020/10/15/upcoming-migrate-and-operate-sap-landscape-on-hyperscalers-sap-inno...
- SAP Managed Tags:
