次に、すべてのサービスとアプリケーションソフトウェアが実行されている物理サーバーと仮想サーバーを転送します。 エンドユーザーが移行する最も効果的で目に見えないオプションを検討します。これは、クラウドインフラストラクチャへのスケーリングの原則に基づいて行われ、その後に物理的な機器が拒否されます。
しかし、これは理想的なオプションです。そのため、インスタントまたは非常に短期的な動きについて説明します。 それを「ねじ込む」簡単な方法-たとえば、予備テストなしでシステムのコンポーネントを交換または更新します。
「クラウド」へのインフラストラクチャの各転送は、個別のイベントです。 特定の各ケースで転送を実行する方法を考慮することは意味をなさないので、ITシステム、サービス、およびコンポーネントの長期または完全なダウンタイムにつながる典型的なエラーについて話します。 ミスは教育プログラムのレベルで少しですが、私はそれらがどのように作られるのかを何度も見ます。
在庫
まず、移行を決定する前に、インフラストラクチャのインベントリを作成して、システムの構成要素とそれらの相互関係を明確に理解する必要があります。 これは、現在のすべてのインフラストラクチャドキュメントを整理するのに役立ちます。 そして、おそらく、特に高度なケースでは-作成します。 しかし、最も重要なことは、避けられない機能エラーをデバッグする際の時間を節約することです。 インベントリをスキップします-サポートサービスからの期限とインシデントの準備をします。
テストスタンド
何らかの理由で移行する決定が下され、多くの潜在的なクラウドプロバイダーが選択されたとします。 この段階では、時間をかけてクラウドプロバイダーの両方をテストし、転送メカニズムを部分的に解決することが重要です。 特に、仮想データセンター管理インターフェースの利便性と直観性、サポートサービスの価格、妥当性、迅速な対応、特定のクラウド環境だけでなく、そこからの移行の可能性（エスケープルートも必要）、バックアップ方法に注意して、すべてを評価します、およびプロバイダーが提供し決定するインフラストラクチャの復元条件。 仮想サーバー、ディスクのクローンを作成する方法、仮想サーバーのパフォーマンスを向上させる方法など、特定の各プロバイダーと連携する特定の機能に注意してください（そして、一般的にこれにより可能になりますか？それとも毎回水平に拡張する必要がありますか？）、仮想ネットワークでの作業を忘れないでください。
テストしないと、すべてが問題なく転送できると感じるかもしれません。 多くの場合、この感覚は間違っており、「新たな」困難の規模は不愉快な驚きになる可能性があります。
安全性
少なくとも、DDOS攻撃に対する保護の可能性を明確にし、通信チャネルのスループットと侵入検知システムの存在を評価する必要があります。 多くのお客様にとって、これらのオプションは時間と神経を大幅に節約できます。 私と同僚は、たとえばこのチェックリストにあるように、企業ブログでセキュリティについて詳しく説明します。
良い計画
移行プロセスを開始する前の最後の手順は、移行計画を作成することです。移行計画には、何をどの順序で、いつ移行するかを記述する必要があります。 推奨事項は1つだけです。計画は、すべての移行手順と、インベントリフェーズで特定された特定のコンポーネントの転送の機能を反映するのに十分正確でなければなりません。 説明のために遠くに行く必要はありません。大企業では、相互に依存する別々のサービスで構成されるインフラストラクチャの移行を組織する場合、特定の順序でいくつかの段階でそれらを転送する必要がありました。 明確な行動計画がないため、1週間半の追加作業が必要でした。
適切なタイミング
もちろん、繰り返しますが、理想的なオプションは仮想インフラストラクチャに拡張することですが、何らかの理由でこれが不可能な場合、最良のオプションはハードドライブのスナップショットを転送することです。 さらに、物理システムのバックアップを介した転送と、仮想環境での物理システムのその後の復元が可能です。最後に、システムで許可されている場合、新しく起動した仮想サーバーへのクリーンインストールが可能です。 「いつ？」という質問に対する答えは、インフラストラクチャへの負荷が最小の瞬間に非常に明白です。 インフラストラクチャは、その中で実行および機能している特定のサービスによって決定されます。つまり、いくつかの最も重要なサービスが選択され、それらの負荷に関する情報が分析され、特定の一時的な「病院の平均気温」移行間隔。
移行プロセス
移行プロセス中に情報システムのソフトウェアコンポーネントを変更しないでください。 たとえば、比較的最近では、ApacheをNginxに置き換えると、訪問した1つのポータルで4時間のダウンタイムが発生しました。テスト移行後もすべての書き換えルールが正しく機能しませんでした。 一般に、IMHOでは、移行がITインフラストラクチャまたは情報システムをクラウドに拡張する方法でない場合、手順の最後まで何も変更しないことが最善です。 もちろん、情報システムの特定のコンポーネントを更新すると技術的な問題の解決に役立ったときに移行があったため、この声明は議論の余地があります。 最終的に、最終的な選択は、顧客側の特定のエンジニアが行います。エンジニアは、彼に転送されるシステムまたはサービスの知識と彼に伝えられるリスクに基づいて、すべての長所と許しを比較検討します。
別のサブ項目は互換性の問題です。 たとえば、クラウドプロバイダーがソリューションのコンポーネントのライセンススキームをサポートしていないため、すべてのオペレーティングシステムをクラウドに「簡単に」転送できない場合がよくあります。
これが、緊急の移動中のインフラストラクチャのもう少し組織的な移転に役立つことを願っています。 移動中に「熊手」があった場合は、コメントで共有してください。