本ブログはSAP標準のアップグレードツールである、Software Update Manager (通称SUM)を使ったアップグレードおよびコンバージョンプロジェクトのダウンタイム削減について紹介するページとなります。
ブログは以下3回を予定しており、本ブログはその1回目となります。
1．SUMダウンタイム削減概要 ← ここ
2．SUMダウンタイム削減（計画編）
3．SUMダウンタイム削減（分析編）
SUMのアップグレードおよびコンバージョン処理におけるダウンタイム削減についてはboris.rubarthさんを筆頭に多くの記事があります。今回、それらを参考にしながらダウンタイム削減の手法や分析の仕方について整理し、紹介することを目的としています。
各ダウンタイム削減手法はTechnical Downtimeの削減に焦点を当てたものとなっております。そのためTechnical Downtimeとは何かを理解することがSUMによるダウンタイム削減を考える上での最重要なポイントとなるため、この点についても紹介をしております。
本記事の対象読者はSAPのアップグレードやコンバージョンプロジェクトに関わることとなったSAP Basis担当者またプロジェクト管理者を想定し、SUMを使用したアップグレード/コンバージョンのダウンタイム削減にどのような対応がとれるかを理解していただくことを目標としています。
Software Update Manager (通称SUM) はSAPシステムのUpdateやUpgrade、S/4 Conversionを行うためのSAP標準ツールです。SUMのバージョンは現在1と2があり、バージョン1はSAP NetweaverのJavaスタック、デュアルスタック、ターゲットバージョンが750以下のABAPスタックに使用され、バージョン2はターゲットバージョンが750以上のABAPスタックに使用されます。
参考情報：https://support.sap.com/en/tools/software-logistics-tools.html
Software Update Managerが扱うSAPシステムメンテナンスの範囲は多岐にわたり、SAP ECC 6.0のサポートパッケージスタック (SPS) の適用、エンハンストメントパッケージ (EHP) の適用、SAP ECC 6.0からSAP S/4HANAへのシステムコンバージョン、SAP S/4 HANAのバージョンアップグレード、SAP S/4 HANAのSPS適用、Non-HANADBからSAP HANA DBへの移行を伴ったアップグレードやシステムコンバージョンなど様々な用途で使用します。
また、標準で利用できるダウンタイム削減のオプションも複数存在しており、near-Zero Downtime Maintenance (通称nZDM)、Zero Downtime Option (通称ZDO)、Database Migration Option (通称DMO)、downtime-optimized Conversionなどがあります。
上述のように、Software Update Managerを使用するメンテナンスのシナリオは多く、またダウンタイム削減手法も複数存在するため、アップグレード及びコンバージョンプロジェクトにおけるダウンタイム削減を議論するためには、どのようなシナリオのプロジェクトで、どのダウンタイム削減手法が利用できるのかを整理して理解する必要があります。
まず、Software Update Managerが取り扱うメンテナンスシナリオについては下記の表でご確認ください。ソースシステムからターゲットシステムの変更箇所とその変更がどのようなメンテナンスシナリオとして定義されているかが記載されています。
出典：ADM328 SAP S/4HANA Conversion and SAP System Upgrade
次に、Software Update Managerで利用できるダウンタイム削減の手法とそれが実施できるメンテナンスシナリオを以下の表からご確認ください。SUMの標準機能で利用できるダウンタイム削減手法は各メンテナンスシナリオによって異なっています。（例：Zero Downtime Option for SAP S/4HANAはS/4のUpdateとUpgradeのみに活用できる等）
出典：https://support.sap.com/en/tools/software-logistics-tools/software-update-manager.html#section
それぞれのメンテナンスシナリオに対して利用できるダウンタイム削減手法について、以下の図が分かりやすく表現されているため、合わせてご確認ください。
なお、Software Update Managerが提供する、上述のダウンタイム削減手法は、SUMのTechnical Downtimeの削減に焦点を当てたものとなります。ここで、SUMにおけるTechnical Downtimeとは何か、またSUMの処理全体に占めるTechnical Downtimeの位置づけについて理解する必要があるため、次に説明します。
Software Update Managerの処理フェーズは Extraction、Configuration、Checks、Preprocessing、Execution、Postprocessingの6つのフェーズがあります。その中でも、Extraction から Preprocessing までのフェーズは、Uptime フェーズと呼ばれエンドユーザがシステムにログインでき、業務利用できるフェーズとなっています。
SUMによるアップグレード処理実行中にも、エンドユーザがシステムを利用できる理由は、Shadow instanceという仕組みにあります。
Shadow instanceはSUMのPreprocessingフェーズの開始前に作られる追加のインスタンスおよびリポジトリで、エンドユーザが業務アクセスする通常のインスタンス/リポジトリとは別に作られます。通常の業務アクセスはオリジナルのインスタンスで処理され、アップグレード処理をShadow instanceで処理することで、業務処理とアップグレード処理を並行で実施することが可能となります。
Shadow instanceについて詳細を確認したい場合は以下の記事を参照してください。
SUM: introduction to shadow system
このように、Shadow instanceでアップグレード処理をすることで、PreprocessingフェーズまではUptimeフェーズと呼ばれるエンドユーザの業務利用が可能なフェーズとなります。そして、後続のExecutionフェーズでSAPシステム停止が必要となる処理（テーブルの構造変更やアプリケーションデータインポート等）が実行されます。このExecutionフェーズ以降は業務ユーザの利用が不可能となり、Technical Downtimeと定義されるフェーズとなります。なお、Shadow instanceを活用したSAPのアップグレードは、現在はSoftware Update Managerのデフォルトの手法となっています。
ここまでの内容を纏めると、Software Update ManagerによるSAPシステムのアップグレードおよびコンバージョンでは、Shadow instanceという仕組みを使う事でSUMによる処理をUptimeとTechnical Downtimeのフェーズに分け、Technical Downtimeフェーズのみを業務ユーザが利用できないダウンタイムにすることで、ダウンタイム削減を実現している、と言えます。
さらに、上で紹介したダウンタイム削減手法であるnear-Zero Downtime Maintenance (通称nZDM)、Zero Downtime Option (通称ZDO)、downtime-optimized Conversionなどは、標準手法ではTechnical Downtimeに実施される処理をUptimeフェーズに移動させることでTechnical Downtimeを削減する手法となります。
それでは、Technical Downtimeについての説明ができたので、各ダウンタイム削減の手法がTechnical Downtime を削減する仕組みについて、次に説明します。
near-Zero Downtime Maintenance (通称nZDM) はSAP S/4HANAのUpdate、UpgradeまたすでにSAP HANA DBで稼働しているSAP ECC 6.0をSAP S/4HANAにシステムコンバージョンする際に利用できる、SUM標準のダウンタイム削減手法となります。
nZDMは標準手法であればTechnical Downtime中に処理される、以下のアップグレード処理をUptime中に実施することで、Technical Downtimeの時間を削減する手法です。これはnZDMが持つRecord & Replayの機能を活用して実現しています。
nZDMを利用してSUMの実行を行う場合は、SUMのConfigurationフェーズでDontime-optimized（high configuration）→ Near-Zero Downtime Maintenanceを選択してSUM実行を進めてください。
なお、nZDMの利用にはDBのバージョンなどに前提条件がありますので以下のSAP Noteもご確認下さい。
1678564 - Restrictions, Database-specific Settings, and Troubleshooting of nZDM (near-Zero Downtime ...
Zero Downtime Option (通称ZDO) はSAP S/4HANAのUpdate、Upgradeの際に利用できる、SUM標準のダウンタイム削減手法になります。SAP S/4HANA1909以前のバージョンでZDOを利用するには、パイロットプロジェクトの登録とSAPの有償サポートが必要でしたが、SAP S/4HANA 2020以降は 「Zero Downtime Option for SAP S/4HANA Updates and Upgrades（ADM330e）」のトレーニング受講と、ADM330k のアセスメントに合格した 技術者であれば誰でも活用できる一般リリースの機能となりました。
ZDOは標準手法ではTechnical Downtimeとなるフェーズの処理をBridgeサブシステムという本番環境のクローン環境で行う事により、ダウンタイムをアプリケーションサーバの再起動時間 (5分～15分) のみにするという手法になります。
SAP S/4HANAアップグレードの処理では、テーブル構造変換 (PARCONV_UPG) やSAP名称領域のデータインポート (TABIM_UPG) 、アプリケーション固有データの変換や統合 (XPRA_AMING) の処理があり、これらはデータ構造の変換であるため、本来は業務ユーザアクセスとのデータ整合性の担保が難しい処理です。そこを解決する仕組みがBridgeサブシステムという機能で、裏側ではテーブルのクローンやDBトリガーによるデータのレプリケートが行われています。
しかしながら、ZDOの手法ではBridgeサブシステム起動中に一部のアプリケーションテーブルの更新が不可になり、BWの一部機能も利用できないなど、実施時に制限が発生するため、ZDOを活用したアップグレードが可能かどうかの影響分析の労力が多く必要とされます。下記の図のように標準手法からnZDM、ZDOと、ダウンタイムをより削減する手法になるに従い、プロジェクトの労力が増加する点にご注意ください。
ZDOについて更に確認したい場合は、以下のBlogやSAP Noteをご確認ください。
SAP S/4HANAのUpgrade downtimeを極小化するZDO（Zero Downtime option）
2707731 - Prerequisites and restrictions of Zero Downtime Option of SUM for SAP S/4HANA
downtime-optimized ConversionはSAP ECC 6.0からSAP S/4HANAへシステムコンバージョンを行うときに利用できるSUM標準のダウンタイム削減手法になります。以前はdowntime-optimized Conversionを実施するために、パイロットプロジェクトの申請とSAPの有償サポートが必要でしたが、現在は「SAP S/4HANA Downtime-optimized Conversion（ADM329）」のトレーニング受講と、これに関連するアセスメントに合格した 技術者が利用できる一般リリースの機能となりました。
downtime-optimized Conversionは 標準手法では Technical Downtimeで実行されるテーブルコンバージョン処理を、Uptimeに移動することでTechnical Downtimeを削減する手法となっております。さらに、SUMの実行完了後に会計領域の後処理として実行する会計データ変換の処理も、Uptime中に移動することが可能となるため、Technical Downtimeの削減だけではなく、SUM実行後の会計データ変換処理のダウンタイムも削減することが可能となっております。
しかしながら、downtime-optimized Conversionの手法も標準手法と比較すると、コンバージョンの事前実行やUptime中の制約事項の確認、影響分析の実施など、プロジェクトの推進に労力を要するダウンタイム削減手法となります。
downtime-optimized Conversionについては以下のBlogやSAP Noteもご確認ください。
System Conversion to SAP S/4HANA: downtime-optimized Conversion
3155695 - Executing and Monitoring Downtime-Optimized Conversion to SAP S/4HANA with SUM 2.0 SP 14
本ブログでは、SUMダウンタイム削減概要について紹介してきました。SUMが提供するダウンタイム削減手法はいずれもTechnical Downtimeの削減を目指した手法である点を理解いただいたかと思います。そのため、SAPのアップグレードおよびコンバージョンプロジェクトでダウンタイムを削減するためには、SUMのUptimeがビジネスダウンタイムとならないような移行パスでプロジェクトを実施する必要があります。次のブログではSUMダウンタイム削減（計画編）として、アップグレード/コンバージョンプロジェクトのダウンタイムを削減するために必要な事前準備やシステム移行パス検討などについて紹介したいと考えております。
最後に、本ブログについてのコメントや実プロジェクトでのフィードバックをコメント欄にいただけると非常にありがたいです。ぜひよろしくお願い致します。また、関連する情報の収集のために、ソフトウェアロジスティクスのブログフィードやコミュニティリソースをぜひフォローください。
ブログは以下3回を予定しており、本ブログはその1回目となります。
1．SUMダウンタイム削減概要 ← ここ
2．SUMダウンタイム削減（計画編）
3．SUMダウンタイム削減（分析編）
記事の目的
SUMのアップグレードおよびコンバージョン処理におけるダウンタイム削減についてはboris.rubarthさんを筆頭に多くの記事があります。今回、それらを参考にしながらダウンタイム削減の手法や分析の仕方について整理し、紹介することを目的としています。
各ダウンタイム削減手法はTechnical Downtimeの削減に焦点を当てたものとなっております。そのためTechnical Downtimeとは何かを理解することがSUMによるダウンタイム削減を考える上での最重要なポイントとなるため、この点についても紹介をしております。
対象読者
本記事の対象読者はSAPのアップグレードやコンバージョンプロジェクトに関わることとなったSAP Basis担当者またプロジェクト管理者を想定し、SUMを使用したアップグレード/コンバージョンのダウンタイム削減にどのような対応がとれるかを理解していただくことを目標としています。
Software Update Managerについて
Software Update Manager (通称SUM) はSAPシステムのUpdateやUpgrade、S/4 Conversionを行うためのSAP標準ツールです。SUMのバージョンは現在1と2があり、バージョン1はSAP NetweaverのJavaスタック、デュアルスタック、ターゲットバージョンが750以下のABAPスタックに使用され、バージョン2はターゲットバージョンが750以上のABAPスタックに使用されます。
参考情報：https://support.sap.com/en/tools/software-logistics-tools.html
Software Update Managerが扱うSAPシステムメンテナンスの範囲は多岐にわたり、SAP ECC 6.0のサポートパッケージスタック (SPS) の適用、エンハンストメントパッケージ (EHP) の適用、SAP ECC 6.0からSAP S/4HANAへのシステムコンバージョン、SAP S/4 HANAのバージョンアップグレード、SAP S/4 HANAのSPS適用、Non-HANADBからSAP HANA DBへの移行を伴ったアップグレードやシステムコンバージョンなど様々な用途で使用します。
また、標準で利用できるダウンタイム削減のオプションも複数存在しており、near-Zero Downtime Maintenance (通称nZDM)、Zero Downtime Option (通称ZDO)、Database Migration Option (通称DMO)、downtime-optimized Conversionなどがあります。
Software Update Managerにおけるダウンタイム削減手法について
上述のように、Software Update Managerを使用するメンテナンスのシナリオは多く、またダウンタイム削減手法も複数存在するため、アップグレード及びコンバージョンプロジェクトにおけるダウンタイム削減を議論するためには、どのようなシナリオのプロジェクトで、どのダウンタイム削減手法が利用できるのかを整理して理解する必要があります。
まず、Software Update Managerが取り扱うメンテナンスシナリオについては下記の表でご確認ください。ソースシステムからターゲットシステムの変更箇所とその変更がどのようなメンテナンスシナリオとして定義されているかが記載されています。
出典：ADM328 SAP S/4HANA Conversion and SAP System Upgrade
次に、Software Update Managerで利用できるダウンタイム削減の手法とそれが実施できるメンテナンスシナリオを以下の表からご確認ください。SUMの標準機能で利用できるダウンタイム削減手法は各メンテナンスシナリオによって異なっています。（例：Zero Downtime Option for SAP S/4HANAはS/4のUpdateとUpgradeのみに活用できる等）
出典：https://support.sap.com/en/tools/software-logistics-tools/software-update-manager.html#section
それぞれのメンテナンスシナリオに対して利用できるダウンタイム削減手法について、以下の図が分かりやすく表現されているため、合わせてご確認ください。
なお、Software Update Managerが提供する、上述のダウンタイム削減手法は、SUMのTechnical Downtimeの削減に焦点を当てたものとなります。ここで、SUMにおけるTechnical Downtimeとは何か、またSUMの処理全体に占めるTechnical Downtimeの位置づけについて理解する必要があるため、次に説明します。
Software Update ManagerにおけるShadow instance およびTechnical Downtimeについて
Software Update Managerの処理フェーズは Extraction、Configuration、Checks、Preprocessing、Execution、Postprocessingの6つのフェーズがあります。その中でも、Extraction から Preprocessing までのフェーズは、Uptime フェーズと呼ばれエンドユーザがシステムにログインでき、業務利用できるフェーズとなっています。
SUMによるアップグレード処理実行中にも、エンドユーザがシステムを利用できる理由は、Shadow instanceという仕組みにあります。
Shadow instanceはSUMのPreprocessingフェーズの開始前に作られる追加のインスタンスおよびリポジトリで、エンドユーザが業務アクセスする通常のインスタンス/リポジトリとは別に作られます。通常の業務アクセスはオリジナルのインスタンスで処理され、アップグレード処理をShadow instanceで処理することで、業務処理とアップグレード処理を並行で実施することが可能となります。
Shadow instanceについて詳細を確認したい場合は以下の記事を参照してください。
SUM: introduction to shadow system
このように、Shadow instanceでアップグレード処理をすることで、PreprocessingフェーズまではUptimeフェーズと呼ばれるエンドユーザの業務利用が可能なフェーズとなります。そして、後続のExecutionフェーズでSAPシステム停止が必要となる処理（テーブルの構造変更やアプリケーションデータインポート等）が実行されます。このExecutionフェーズ以降は業務ユーザの利用が不可能となり、Technical Downtimeと定義されるフェーズとなります。なお、Shadow instanceを活用したSAPのアップグレードは、現在はSoftware Update Managerのデフォルトの手法となっています。
ここまでの内容を纏めると、Software Update ManagerによるSAPシステムのアップグレードおよびコンバージョンでは、Shadow instanceという仕組みを使う事でSUMによる処理をUptimeとTechnical Downtimeのフェーズに分け、Technical Downtimeフェーズのみを業務ユーザが利用できないダウンタイムにすることで、ダウンタイム削減を実現している、と言えます。
さらに、上で紹介したダウンタイム削減手法であるnear-Zero Downtime Maintenance (通称nZDM)、Zero Downtime Option (通称ZDO)、downtime-optimized Conversionなどは、標準手法ではTechnical Downtimeに実施される処理をUptimeフェーズに移動させることでTechnical Downtimeを削減する手法となります。
それでは、Technical Downtimeについての説明ができたので、各ダウンタイム削減の手法がTechnical Downtime を削減する仕組みについて、次に説明します。
near-Zero Downtime Maintenance
near-Zero Downtime Maintenance (通称nZDM) はSAP S/4HANAのUpdate、UpgradeまたすでにSAP HANA DBで稼働しているSAP ECC 6.0をSAP S/4HANAにシステムコンバージョンする際に利用できる、SUM標準のダウンタイム削減手法となります。
nZDMは標準手法であればTechnical Downtime中に処理される、以下のアップグレード処理をUptime中に実施することで、Technical Downtimeの時間を削減する手法です。これはnZDMが持つRecord & Replayの機能を活用して実現しています。
- コンバージョンを含むテーブル構造の変更処理
- メインインポート
nZDMを利用してSUMの実行を行う場合は、SUMのConfigurationフェーズでDontime-optimized（high configuration）→ Near-Zero Downtime Maintenanceを選択してSUM実行を進めてください。
なお、nZDMの利用にはDBのバージョンなどに前提条件がありますので以下のSAP Noteもご確認下さい。
1678564 - Restrictions, Database-specific Settings, and Troubleshooting of nZDM (near-Zero Downtime ...
Zero Downtime Option
Zero Downtime Option (通称ZDO) はSAP S/4HANAのUpdate、Upgradeの際に利用できる、SUM標準のダウンタイム削減手法になります。SAP S/4HANA1909以前のバージョンでZDOを利用するには、パイロットプロジェクトの登録とSAPの有償サポートが必要でしたが、SAP S/4HANA 2020以降は 「Zero Downtime Option for SAP S/4HANA Updates and Upgrades（ADM330e）」のトレーニング受講と、ADM330k のアセスメントに合格した 技術者であれば誰でも活用できる一般リリースの機能となりました。
ZDOは標準手法ではTechnical Downtimeとなるフェーズの処理をBridgeサブシステムという本番環境のクローン環境で行う事により、ダウンタイムをアプリケーションサーバの再起動時間 (5分～15分) のみにするという手法になります。
SAP S/4HANAアップグレードの処理では、テーブル構造変換 (PARCONV_UPG) やSAP名称領域のデータインポート (TABIM_UPG) 、アプリケーション固有データの変換や統合 (XPRA_AMING) の処理があり、これらはデータ構造の変換であるため、本来は業務ユーザアクセスとのデータ整合性の担保が難しい処理です。そこを解決する仕組みがBridgeサブシステムという機能で、裏側ではテーブルのクローンやDBトリガーによるデータのレプリケートが行われています。
しかしながら、ZDOの手法ではBridgeサブシステム起動中に一部のアプリケーションテーブルの更新が不可になり、BWの一部機能も利用できないなど、実施時に制限が発生するため、ZDOを活用したアップグレードが可能かどうかの影響分析の労力が多く必要とされます。下記の図のように標準手法からnZDM、ZDOと、ダウンタイムをより削減する手法になるに従い、プロジェクトの労力が増加する点にご注意ください。
ZDOについて更に確認したい場合は、以下のBlogやSAP Noteをご確認ください。
SAP S/4HANAのUpgrade downtimeを極小化するZDO（Zero Downtime option）
2707731 - Prerequisites and restrictions of Zero Downtime Option of SUM for SAP S/4HANA
downtime-optimized Conversion
downtime-optimized ConversionはSAP ECC 6.0からSAP S/4HANAへシステムコンバージョンを行うときに利用できるSUM標準のダウンタイム削減手法になります。以前はdowntime-optimized Conversionを実施するために、パイロットプロジェクトの申請とSAPの有償サポートが必要でしたが、現在は「SAP S/4HANA Downtime-optimized Conversion（ADM329）」のトレーニング受講と、これに関連するアセスメントに合格した 技術者が利用できる一般リリースの機能となりました。
downtime-optimized Conversionは 標準手法では Technical Downtimeで実行されるテーブルコンバージョン処理を、Uptimeに移動することでTechnical Downtimeを削減する手法となっております。さらに、SUMの実行完了後に会計領域の後処理として実行する会計データ変換の処理も、Uptime中に移動することが可能となるため、Technical Downtimeの削減だけではなく、SUM実行後の会計データ変換処理のダウンタイムも削減することが可能となっております。
しかしながら、downtime-optimized Conversionの手法も標準手法と比較すると、コンバージョンの事前実行やUptime中の制約事項の確認、影響分析の実施など、プロジェクトの推進に労力を要するダウンタイム削減手法となります。
downtime-optimized Conversionについては以下のBlogやSAP Noteもご確認ください。
System Conversion to SAP S/4HANA: downtime-optimized Conversion
3155695 - Executing and Monitoring Downtime-Optimized Conversion to SAP S/4HANA with SUM 2.0 SP 14
まとめ
本ブログでは、SUMダウンタイム削減概要について紹介してきました。SUMが提供するダウンタイム削減手法はいずれもTechnical Downtimeの削減を目指した手法である点を理解いただいたかと思います。そのため、SAPのアップグレードおよびコンバージョンプロジェクトでダウンタイムを削減するためには、SUMのUptimeがビジネスダウンタイムとならないような移行パスでプロジェクトを実施する必要があります。次のブログではSUMダウンタイム削減（計画編）として、アップグレード/コンバージョンプロジェクトのダウンタイムを削減するために必要な事前準備やシステム移行パス検討などについて紹介したいと考えております。
最後に、本ブログについてのコメントや実プロジェクトでのフィードバックをコメント欄にいただけると非常にありがたいです。ぜひよろしくお願い致します。また、関連する情報の収集のために、ソフトウェアロジスティクスのブログフィードやコミュニティリソースをぜひフォローください。
Software Logistics - System Maintenance
- SAP Managed Tags:
