本ブログはSAP標準のアップグレードツールである、Software Update Manager (通称SUM)を使ったアップグレードおよびコンバージョンプロジェクトのダウンタイム削減について紹介するページとなります。
ブログは以下3回を予定しており、本ブログはその２回目となります。
2．SUMダウンタイム削減（計画編） ← ここ
記事の目的
前回のブログではコンバージョンやアップグレードにおけるSUMのダウンタイム削減概要について紹介しました。本ブログではプロジェクト計画時に、ダウンタイム削減の観点で考慮が必要な事項の紹介を目的としています。
対象読者
本記事の対象読者は前回のブログと同様、SAPのアップグレードやコンバージョンプロジェクトに関わることとなったSAP Basis担当者またプロジェクト管理者を想定しています。
SUMの実行時間削減の大前提
前回のブログでご紹介した通り、SUMが提供するダウンタイム削減手法はいずれもTechnical Downtimeの削減を目指した手法となります。
図：SUMフェーズにおけるUptimeとDowntimeの分類について
そのため、Shadow Systemによって本番業務処理とSUMのコンバージョン・アップグレード処理が並行で実施されるUptimeフェーズを、業務ユーザがシステムアクセスができない状態としてしまうと、SUMの処理全体がシステムダウンとなり、SUMが提供するダウンタイム削減手法の効果が得られなくなります。このような状況となる具体的なケースは
- SAP S/4HANA コンバージョンの前提であるシステムのユニコード化が未実施のため、SUMの実行前にシステムコピーによるユニコードコンバージョンが必要
- OS、DBのバージョンアップをSUMの実行と同じタイミングで行うため、SUMの実行前にOS、DBのバージョンアップが必要
- コンバージョンやアップグレードの実施に合わせて、システムをクラウドにマイグレーションをするため、SUM実行前にシステムコピーが必要
などが考えれます。
いずれも、SUMの実行の前にシステムダウンが必要な処理があるため、SUMの開始時点から業務ユーザへのシステム解放を制限する方式となっています。
このような状態を回避するには、ユニコードコンバージョンやOS、DBのアップグレード、システムコピーなどの作業をSUMの実行とは別日に計画し、事前に完了させておく等の検討が必要となります。こうなると、SUMによるコンバージョン・アップグレードの他にもシステム停止日を設ける必要があるため、複数回の短いシステム停止日が取得しやすいのか、長いシステム停止が可能だが1度のシステム停止にする必要があるか、などを事前にシステムオーナーとご検討いただく必要があります。
SUMの実行時間短縮に最も効果のある方法
SUMの実行時間の短縮に最も効果のある方法は、強力なハードウェアを使用してSUM実行時のプロセス数を高く設定することになります。
SUMの処理では、ABAPプロセス、SQLプロセス、R3Transプロセス、R3Loadプロセス で処理がなされますが、それぞれの並列度はSUMのConfigurationフェーズで指定することが可能です。
図：Configurationフェーズで設定するプロセス数について
それぞれのプロセスがSUM処理におけるどのような処理を担当するのか、また並列度の設定は何を元に決定すれば良いのかについては、以下のSAP Noteに記載されています。
SAP Note 1616401 – Parallelism in the Upgrades, EhPs and Support Packages implementations
たとえば、R3TransプロセスはSUMの処理の中でも、サポートパッケージのインポート処理に使用され、DDIC_UPG、SHADOW_IMPORT、TABIM_UPGといった処理で使用されるプロセスになります。
R3transプロセスの並列度の推奨値はCPUの数と同じ数となるため、なるべくCPUの数が多い強力なハードウェアを用いて並列度を高く設定することが推奨されます。これにより、R3Transプロセスを使うSUM処理の実行時間削減が可能です。その他のプロセスについても、同SAP Noteに推奨となる数値が記載されているためご確認ください。
なお、ハードウェア拡張やプロセス数の拡張によってSUMの実行処理時間を大幅に短縮されたケースが以下のブログで紹介されています。こちらも参考にしてください。
How we reduced the “dreaded” Software Update Manager Technical Downtime without NZDT
SUMの処理プロセスはSUMの実行を開始したアプリケーションサーバで稼働しますが、SAP Netweaver ABAPのPrimary Application Serverで必ずしも実行する必要はありません。SAP Netweaver ABAPのAdditional Application ServerでSUMを実行した場合でも、そのサーバマシン上にASCS インスタンスが存在しない場合には、SUMがASCS インスタンスの移動の要否を確認します。そのため、1台 のAdditional Application Serverを強力なハードウェアにスケールアップした後、SUMを実行いただくことも検討可能です。SUM実行中のASCS インスタンスの移動については以下のブログをご確認ください。
ASCS instance move: use SUM to switch your ASCS
https://blogs.sap.com/2019/04/12/ascs-instance-move-use-sum-to-switch-your-ascs/
上記の通り、SUMの実行時間の短縮に最も効果のある方法は、強力なハードウェアを使用してSUM実行時のプロセス数を高く設定することであるため、計画時にSUM実行マシンのスペックを一時的に拡張することを推奨します。
プロジェクト計画
SUMを使ったSAPシステムのコンバージョン・アップグレードプロジェクトにおいては、サンドボックスシステムを利用したコンバージョン・アップグレードのテスト実行を早いタイミングで計画することが推奨されます。またサンドボックスシステムは本番環境の1：１のコピーとし、本番環境と同等のハードウェアで準備することも推奨されています。このテスト実行により、プロジェクト早期に必要なダウンタイム時間の目安や必要な作業ステップについて情報を得る事が可能となります。
またサンドボックスシステムを利用したコンバージョン・アップグレードのテスト実行では、SUＭが提供するダウンタイム削減の手法（nZDM、ZDO、downtime-optimized Conversion）を活用するのか否か、活用するのであればその前提Noteの確認なども合わせて行うようにしてください。
出典：SAP Activate Methodology for Transition to SAP S/4HANA
なお、コンバージョン・アップグレードのテスト実行は複数実行を計画し、それぞれのテスト実行で作業手順の精緻化やSUMのプロセス数のチューニングによる処理時間短縮を行い、本稼働時にスムーズに移行できるようにご準備ください。
このように、プロジェクト計画を立てる際には、早期のタイミングでサンドボックスシステムを使ったコンバージョン・アップグレードを実施して、ダウンタイム削減手法の選定を行ってください。また、コンバージョン・アップグレードのイテレーション実施を必ず組み込むようにご検討ください。
計画時に確認すべきSAP Note
SUM実行によるコンバージョン・アップグレードのテクニカルダウンタイム削減に向けた情報提供を行うSAP NoteやSUMのダウンタイム削減手法（near-Zero Downtime Maintenance、Zero Downtime Option）の前提SAP Noteは、プロジェクト計画時に確認することを推奨致します。各SAP Noteについて以下に提示します。
2351294 – SAP S/4HANA System Conversion / Upgrade: Measures to reduce technical downtime
2707731 – Prerequisites and restrictions of Zero Downtime Option of SUM for SAP S/4HANA
まとめ
本ブログでは、SUMダウンタイム削減の計画を行う際に考慮すべき事項を紹介させていただきました。SUMダウンタイム削減を実現するために重要な要素は、SUM作業の前にシステムダウンの時間を作らない事、強力なハードウェアでSUMを実行する事になります。次のブログでは、SUM実行後の結果ファイルをもとに、SUM実行時間の分析やチューニングを行う手法について紹介します。
最後に、本ブログについてのコメントや実プロジェクトでのフィードバックをコメント欄にいただけると非常にありがたいです。ぜひよろしくお願い致します。また、関連する情報の収集のために、ソフトウェアロジスティクスのブログフィードやコミュニティリソースをぜひフォローください。
