SAP ホスティング変更の経験: 耐え難いほどの苦痛を伴わずにシステムを移行する方法

それとも可能でしょうか？もちろん、SAP システムの移行は複雑で骨の折れるプロセスであり、これを成功させるには、すべての参加者がよく調整された作業が必要です。また、移行を短期間で実行すると、作業はさらに複雑になります。誰もがこれを行うことに決めているわけではありません。理由はいくつか考えられます。たとえば、プロセス自体は時間がかかり、組織的に複雑です。さらに、計画外のシステムダウンタイムのリスクもあります。あるいは、クライアントは、そのような手術を受けても、費やした労力に見合った利益が得られるかどうか確信がありません。ただし、例外もあります。

このカットの下では、SAP システムの移行と保守のプロセスでお客様が直面する困難について説明し、ステレオタイプが必ずしも現実と一致しない理由について説明し、お客様のシステムを SAP システムにどのように移行できたのかについてのケース スタディを共有します。新しいインフラストラクチャをわずか 3 か月強で完成させます。

SAP システムのホスティング

わずか 5 年前には、顧客が SAP アプリケーション用のホスティング リソースを大規模に使用し始めるとは想像するのが困難でした。ほとんどの場合、それらはオンプレミスで実装されました。しかし、アウトソーシングモデルやクラウドサービス市場の発展により、顧客の世界観が変わり始めました。 SAP のクラウドを支持する選択に影響を与える議論は何ですか?

• SAP の導入を計画したばかりの初心者にとって、システムの現在のニーズに合わせたリソースの拡張性と、非コア コンピテンシーの開発にリソースを転用したくないという理由から、クラウド インフラストラクチャはほぼ標準的な選択肢になります。
• 大規模なシステムランドスケープを持つ企業では、ホスティング SAP システムの助けを借りて、CIO は質的に異なるレベルのリスク管理に到達します。パートナーは SLA に対して責任を負います。
• 3 番目に一般的な議論は、高可用性と DR シナリオを実装するためのインフラストラクチャの構築にコストがかかるということです。
• ファクター 2027 – ベンダーは、レガシー システムのサポートが 2027 年に終了すると発表しました。これはデータベースを HANA に移行することを意味し、最新化と新しいコンピューティング能力の購入にコストがかかります。

ロシアの SAP ホスティング市場は現在、かなり成熟していると考えられます。これは、ホスティング プラットフォームを変更したい顧客に十分な機会を提供します。ただし、このようなプロジェクトは、移行手順が複雑であるため、当然のことながら企業間で懸念を引き起こす可能性があります。このため、顧客はサービス プロバイダーに対してますます多くの要求を課すことになります。サービス プロバイダーには、SAP システムのホスティングと保守に関する優れた能力だけでなく、移行の分野での成功経験も必要です。

SAP ホスティングを変更する際の難しさは何ですか?

ホスティングは異なります。宣言されたサービスレベルとの矛盾、多くの「ただし」と小さな文字での予約のアスタリスク、ホスティングプロバイダーの限られたリソースと能力、クライアントとのコミュニケーションに関する柔軟性の欠如、官僚主義、技術的制限、技術サポートの能力の低さこれは、クライアントがアウトソーシング インフラストラクチャでビジネス システムを運用するときに遭遇する可能性のある落とし穴のほんの一部です。多くの場合、クライアントにとって、これらはすべて影の中に、複数ページにわたる契約のジャングルの中に残り、サービスを使用する過程で現れます。

ある時点で、顧客は、受けているサービスのレベルが期待とはかけ離れていることに気づきます。これは、状況を修正するための解決策を見つけるための一種の触媒であり、失敗した場合、問題が限界まで蓄積して非常に苦痛になると、サービスプロバイダーを変更する方向で代替オプションを開発するための積極的な行動に移ります。 。

なぜ彼らは最後の瞬間まで待つのでしょうか？理由は簡単です。クライアントのシステム移行プロセスは、必ずしも透明で理解できるものではないからです。クライアントが移行プロセスに関連する実際のリスクを評価することは困難です。クライアントにとって移行は一種のブラックボックスであると言えます。価格、システムのダウンタイム、リスクとそれらを軽減する方法が不透明で、一般に暗くて怖いものです。それがうまくいかなかったら、トップとパフォーマーの両方で首が回るようなものです。

SAP はエンタープライズ レベルのシステムであり、複雑で、控えめに言っても安価ではありません。適切な予算が実装、変更、保守に費やされており、企業の寿命はその可用性と適切な運用にかかっています。ここで、大規模な生産を停止した場合の結果を想像してみてください。これらは、多数のゼロを含む数字で計算できる経済的損失と、風評リスクおよびその他の同様に重大なリスクです。

当社では、お客様の SAP システムを移行する場合に各段階で発生する可能性のある問題を分析します。

準備と設計

移行は、さまざまな部分から構成される公式です。そして最も重要なことの 1 つは、ターゲット (新しい) インフラストラクチャを設計および準備する段階です。

私たちは、システムの既存の実装とそのアーキテクチャを詳しく調べる必要がありました。対象となるインフラストラクチャでは、どこかで既存のソリューションを繰り返し、ある箇所で補完・改善し、どこかでやり直し、耐障害性と可用性を確保するためのソリューションを熟考して選択し、すべてのリソースも可能な限り統合しました。

設計プロセス中にさまざまな演習が実行され、最終的には移行に向けて可能な限り準備を整え、あらゆる種類のニュアンスや落とし穴を考慮できるようになりました (詳細は後ほど)。

私たちが最終的に完成したのは、データセンターに基づいて個別に設計されたプライベート クラウド インフラストラクチャです。

• SAP HANA 専用の物理サーバー。
• アプリケーション サーバーおよびインフラストラクチャ サービス用の VMware 仮想化プラットフォーム。
• L2 VPN のデータセンター間の二重通信チャネル。
• 製品と「その他すべて」を分離するための 2 つのメイン保管システム。
• SRC は、独立したサーバー、ディスク シェルフ、およびテープ ライブラリを備えた Veritas Netbackup に基づいています。

ここでは、技術的な観点からこれらすべてをどのように実装したかを示します。

SAP

• 生産的な HANA にストレージを効果的に使用するために、SAP を使用したシステム的なデータベース レプリケーションを行わずに共有ディスクを使用しました。これらすべては、Pacemaker に基づくアクティブ/スタンバイ SUSE HAE クラスターにラップされています。はい、復元時間はレプリケーションの場合よりも少し長くなりますが、ストレージ容量が半分に節約され、結果としてお客様の予算が節約されます。
• 実稼働前環境では、HANA クラスターは放棄されましたが、技術的には実稼働構成が繰り返されました。
• テスト環境と開発環境は、MCOS 構成のクラスターを使用せずにさらにいくつかのサーバーに分散されました。
• すべてのアプリケーション サーバーは仮想化され、VMware でホストされました。

Сети

• 私たちは、制御ネットワークと生産ネットワークの輪郭をスイッチのスタックで物理的に分離し、生産ネットワークを顧客のデータセンターに向けました。
• 大きなトラフィック フローが混在しないように、十分な数のネットワーク インターフェイスを設置しました。
• ストレージ システムからデータを転送するために、従来の FC SAN ファクトリーを作成しました。

SHD

• SAP の本稼動負荷と本稼動前負荷はオールフラッシュ アレイ上に残されました。
• 開発者テスト環境とインフラストラクチャ サービスは、別のハイブリッド アレイに配置されました。

IBS

• Veritas Netbackup を使用して作成されました。
• MCOS 設定をバックアップするための組み込みスクリプトを少し追加しました。
• 迅速なリカバリのために運用コピーをディスク シェルフに置き、長期保管にはテープを使用します。

監視

• すべてのハードウェア、OS、SAP は Zabbix の下にインストールされました。
• Grafana には便利なダッシュボードがたくさんあります。
• アラートが発生すると、Zabbix はインシデント管理システムでリクエストを作成でき、それを Jira に実装しました。この情報は Telegram チャネルにも複製されます。

Telegram

HANA の一般的な健康状態

SAP アプリケーション サーバーのステータス:

インフラストラクチャサービス

• 内部名前空間にサービスを提供するために、DNS サーバーのクラスターが構築され、顧客のサーバーと同期されます。
• データ交換用に別のファイル サーバーを作成しました。
• さまざまな設定を保存するために、Gitlab が追加されました。
• さまざまな機密情報については、HashiCorp Vault を使用しました。

移行プロセス

一般に、移行プロセスは次の段階で構成されます。

• 必要なすべてのプロジェクト文書の準備。
• 現在のプロバイダーとの交渉 - 組織上の問題の解決。
• プロジェクト用の新しい機器の購入、配送、設置。
• テスト移行とプロセスのデバッグ。
• システム移転、戦闘移行。

2019年XNUMX月末に契約を締結し、アーキテクチャを設計し、お客様と合意の上、必要な設備を発注しました。

まず注意しなければならないのは、機器の納期です。ハードウェア プラットフォームに対するソフトウェア メーカーの要件を満たす SAP NAHA の認定ハードウェアの納品には、平均して 10 ～ 12 週間かかります。また、季節性を考慮すると (プロジェクトの実施はちょうど新年でした)、この期間はさらに XNUMX か月延長された可能性があります。したがって、プロセスをできる限りスピードアップする必要がありました。私たちは流通業者と協力し、（陸路と海路の代わりに）飛行機による迅速な配達に同意しました。

11 月と 12 月は移行の準備と一部の機器の受け取りに費やされました。私たちはパブリック クラウドのテストベンチで準備を実行し、すべての主要な手順を実行して、起こり得る困難や問題を発見しました。

• プロジェクト チームのメンバー間のやり取りについて、分刻みのタイミングで詳細な計画を作成しました。
• ターゲットインフラストラクチャとほぼ同じ方法でデータベースとアプリケーションサーバーのテストベンチを構築しました。
• 統合の動作をテストするために必要な通信チャネルとインフラストラクチャ サービスを構成します。
• カットオーバーシナリオを練り上げた。
• クラウドは、事前構成された仮想マシン テンプレートの作成にも役立ち、その後、それをインポートしてターゲット ランドスケープにデプロイするだけで済みました。

新年の休暇の少し前に、機器の最初のバッチが私たちに到着しました。これにより、一部のシステムを実際のハードウェアに展開できるようになりました。すべてが到着したわけではないため、交換用の機器を接続し、その供給についてベンダーおよび販売代理店となんとか合意しました。最終段階で対象インフラの残骸を受け取りました。
締め切りに間に合わせるために、当社のエンジニアは年末年始の休暇を犠牲にし、休暇真っ只中の 2 月 XNUMX 日からターゲット インフラストラクチャの準備作業を開始しなければなりませんでした。はい、これは火が燃えていて他に選択肢がないときに起こることがあります。企業の存続がかかっているシステムのパフォーマンスが危機に瀕していました。

移行の一般的な順序は次のようになります。最初に、最も重要性の低いシステム (開発環境、テスト環境)、次に生産的なシステムです。移行の最終段階は 1 月下旬から 2 月上旬に行われました。

移行プロセスは分単位まで計画されました。これは、すべてのタスク、完了時間、責任者のリストを含むカットオーバー計画です。テスト マイグレーションではすべての手順がすでに解決されていたため、ライブ マイグレーションでは、計画に従ってプロセスを調整するだけで済みました。

移行はいくつかの段階に分けて計画的に実行されました。各ステージには 2 つのシステムがあります。

3 か月のスプリントの結果、CROC データセンターで完全に稼働するシステムが完成しました。一般に、チームワークを通じて肯定的な結果が達成され、プロセスにおける参加者全員の貢献と献身が最大限に発揮されました。

プロジェクトにおける顧客の役割

クライアントが退職するプロバイダーとの連絡は簡単ではありませんでした。これは当然のことであり、彼らはプロジェクトの成功裡の完了に興味を持っていた人々のリストの中で最後でした。お客様は、すべてのコミュニケーションの問題をエスカレートして処理するというタスクを引き受け、この 100500% に対処しました。これについては彼に特に感謝します。このような実現可能なプロセスへの参加がなければ、プロジェクトの結果はまったく異なるものになっていたかもしれません。

「元」プロバイダー側​​のプロセスが形式化されたため、インフラストラクチャのサポートは文字通り問題から遠く離れた専門家、当時はまだ顧客であった専門家によって実行されました。たとえば、同じデータベースをエクスポートするプロセスには 1 時間から 5 時間かかる場合があります。すると、これはある種の魔法であり、私たちには決して明らかにされなかった秘密であるように思えました。おそらくテクニカルサポートエンジニアはその間、遠いロシアのどこかで締め切りがあることを忘れて瞑想に耽り、エンジニアは正月サラダを食べず、顧客は泣きながら苦しんでいる…。

プロジェクトの結果

移行の最後のステップは、メンテナンスのためのシステムの移行でした。

現在、当社は顧客のリクエストに単一窓口サービスを提供し、パートナーである itelligence と協力してインフラストラクチャ コンポーネントと SAP ベースのサポートに関連するタスクの全範囲をカバーしています。クライアントは 6 か月間プライベート クラウドに住んでいます。この期間のサービスケースの統計は次のとおりです。

• 90 件のインシデント (20% は顧客の関与なしで解決)
• SLA 内で解決 – 100%
• 予定外のシステムシャットダウン – 0

当社のクライアントと同様の問題があり、その解決方法について詳しく知りたい場合は、次の宛先までご連絡ください。 [メール保護]

出所： habr.com