段階的なクラウドへのインフラストラクチャの移行：どのような問題が発生し、どこで

顧客のビジネスがクラウドに移行するのを頻繁に支援しています。 これは完全に通常のリクエストであり、ほとんどの大企業は何らかの形で能力を移転しています。 ケースの約80％は、既に仮想化されたインフラストラクチャの「ホーム」サーバーからデータセンターへの転送を占め、残りの20％はハードウェア（ユーザーワークステーションを含む）から仮想環境への直接転送とコンピューティングノード自体の「クラウド」への転送です。



これがどのように発生するかをステップごとに説明しましょう。 そもそも、すべてのサービスで誰もがすぐに移動することはほとんどありません。 通常、重要でないものは最初に消えて、数か月間監視してから、他のすべてを翻訳します。

準備する

したがって、最初に行われるのは、容量とインフラストラクチャの評価です。 ハイパーバイザーの選択と技術的な詳細については、 こちらをご覧ください 。



実際、サービスのリストを用意し、サービスに必要な容量と必要なものを知る必要があります。 顧客側の優れた管理者の仕事は、何が動いているかの正確なリストを作成することです。 つまり、どのプロセスが何のためにどれだけのリソースを消費するのかが明確になるレベルまでサービスを「引き裂く」ことです。



わずかなマージンで容量を割り当てます。



次に、移動手段の評価を開始します -原則として、データを転送し、仮想マシンを目的のハイパーバイザーの形式に変換するという質問が発生します。



その後、実際には、いくつかのサービスの再配置：最初に、私が言ったように、重要ではないものは取り除かれます。 ほとんどの場合、それらはユーザー仮想マシンから、または開発に関してはテスト環境から開始します。 新しい「クラウド」でテスト環境を数か月実行した後、生産ラインが来ます。 たとえば、逆の例もありましたが、1つの銀行が重いデータベースをほぼゼロから「クラウド」に転送しました（IaaSを提供し、「クラウド」への適応を支援しました）。 彼らは本当に迅速に移動する必要がありました-彼らのコンピューティングリソースは十分ではなく、すべてのリスクを考慮した後、彼らはそれが優れていると判断しました。



しかし、通常はすべてが簡単です。 移行方法に応じて、サービスを移行する時期を計画します。 移動中にサービスに完全にアクセスする必要がある場合は、少なくとも4〜6時間のダウンタイムでこれを行うのが最も簡単で簡単です。 サービスの完全な可用性と顧客のチャネルの両方が同時に低速である場合があり、データを迅速に転送することはできません。

移転

オフライン転送では、ほとんどの場合、情報はClonezilla製品を使用して取得されます。 さらに簡単な方法は、製品をオフにして、ファイルストレージに全体的にアップロードし（これについてはこちら ）、変換します。 すべてのタイプの仮想化をサポートしています。



オンラインに移動する必要がある場合、ほとんどの場合、次のように動作します。Double-Takeエージェントを両側（つまり、顧客のサーバーと「クラウド」内の仮想マシン）に加え、制御マシンに配置します。 最も安価なのは、数分のダウンタイムで切り替えることですが、Visionにはインスタントスイッチングのライセンスがあります（桁違いに高価です）。 オラクルベースの場合、ダウンタイムは2秒でした。



アプリケーションによって移動できます-これは、OSのイメージ全体を作成するのではなく、直接必要な部分を作成する場合です。 ほとんどの場合、MS SQLについて話しますが、それは優れた「ネイティブ」レプリケーションを備えています。



さらに、画像は専用チャネルまたはVPNを介してドラッグされます。 一部の顧客は、単に大きなインターネット上で転送します。 原則として、サーバーノードを「クラウド」に移動することについて話している場合、顧客はプロバイダーに対して独自のチャネル権を持っています。 仮想化せずに「動物園」を転送する場合、状況はより複雑になることがあります。VPNトンネルを構築するか、疎外されたメディアに画像をアップロードする必要があります。 一般に、多くの場合、プロバイダーの通常のVPNは、純粋にテクノロジーの機能に応じて最大20メガビットに制限されます。 そのため、プロバイダーL2VPNが絶対に必要です。そうでない場合は、自分の責任とリスクでインターネット上でそれを実行する必要があります。 または、暗号化を使用して直接交換を行うには、プロバイダーへのパッチコードが必要です。 専用チャンネルは問題ではなく、多くの人々が「クラウド」を取得します-物理的接続：ウラジオストクの鉄製サーバーと仮想サーバーを静かに接続します。 「クラウド」を介したVPN：意図的には何も必要ありません。基本的なサービスがあります。



大量のデータが存在する場合があり、顧客側のギガビットチャンネルでさえ適さない場合があります。 次に、製品からハードドライブにすべてをアップロードし、それを持ち込み、「クラウド」にアップロードします。 巨大なハードドライブを搭載したラップトップをドラッグしたこともあります。 ちなみに、すべてのプロバイダーに電話するのは簡単です。顧客にとっての主な質問は、必要に応じて後で退出する方法です。 私たちにはまったく同じ問題があります。たとえば、顧客がS3のようなストレージで私たちから移動すると（より正確には、個人データの処理方法の特性のために、S3互換からサイトにすべてをドラッグしました）。 彼らはすべての仮想マシンをVMDKのS3にアップロードするように要求しました。 サーバーに接続された2 TBのハードドライブが2台付属し、画像をコピーしました。 VMDKまたは別の形式で安全に提供できます。



顧客が適切なバックアップまたは緊急復旧スキームを持っている場合、自然な移動の別の方法は、新しいサイトでのバックアップと復旧です。



顧客は、移行の順序が重要であることにしばしば驚かされます。 これは次のように発生します。移動が始まると、サービスの1つが他のサービスが機能するために必要であったことがわかります。 したがって、依存関係スキームは常に作成され、移行計画は何のために作成されます。



多くの場合、鉄のプラットフォームから移行する場合、ソースサーバーのOSもアップグレードする必要があります。これも問題ありませんが、計画する必要があります。

プラットフォーム機能

多くの場合、サーバーノードの顧客は1つの仮想化プラットフォームを使用しており、さまざまな理由で別の仮想化プラットフォームに移行します。 特に、VMwareからKVMへの移行が頻繁にあります。 ここで重要なのは、KVMには2種類の仮想化があるということです。 最初の、そしてより生産的なのはvirtioであり、動作させるにはプリインストールされたドライバーが必要です。 2番目のケースでは、IDEディスクとIntel E1000ネットワークアダプターを使用すると、レガシーの生産性が低下します。 ただし、このタイプの仮想化は互換性の問題を解決する場合があります。



それから、クエストはゲストOSのさまざまな範囲で始まります -2003年と2008年（それもありました）。 すべてがスムーズに起きたわけではないため、2003年以来最も困難でした。 特に、ドライバーは通常、オペレーティングシステムにあるデバイスにインストールされますが、移行の場合は、デバイスが存在しないデバイスに移動されるマシンにもfireがインストールされます。 展開時に、すべてがすぐに起動するはずです。 クラウドで実行する前に、そのようなマシンにはネットワークアダプターがなく、仮想マシンには独自のHDDとイーサネットがあるため、これは重要です。 「クラウド」内のマシンには、独自のHDDドライバーと独自のネットワークがあります。 その結果、レガシーモードでは、古いIDEディスクとアダプターが彼女に投げられます。 しかし、すべての場合に機能したわけではありません。 その結果、2003年のWindowsでは、スナップショットを中間環境（Proxmoxy）にアップロードすることに決めたので、最初のディスクに「古い」IDEがあり、2番目に仮想IDEがあるように仮想マシンを起動できます。 Windowsは既存のデバイスとして認識します。 最初に、ドライバーがProxmox仮想化環境のVMにインストールされ、KVMの肩で動作し、それからVMが「クラウド」にアップロードされました。 次に、仮想マシンが「クラウド」にロードされ、離陸しました。 Ubunta-8シャギーもありましたが、それでも2003th Windowsよりも新しいです。 最も面白いのは、これらのOSを顧客側で更新することができないことです。たとえば、一部の古いシステムでは、Consultant Plusを購入したライセンスは一般に触れるのが怖い遺産です。



次の機能はクラスターです。 顧客が自分のサイトでそれを使用した場合、「クラウド」に移行するとき、このようなアーキテクチャは通常、再作業が必要です。 より正確には、古典的なクラスターを「クラウド」にドラッグすることは、最も合理的なアプローチではありません。 これには常に困難が伴います。ドラッグする方法は？ クラスターソフトウェア自体は追加のレイヤーになります。 しかし、生産性からそれを引き出すことはしばしば不可能です。 ここでは、クラスターの専門家を集めて考えます。ほとんどの場合、クラスターは顧客側で事前に削除されます。



多くの場合、CiscoをKVMに移行するとき、またはMikroTikを移行するときに、互換性の問題が発生します。 一般に、起動します。MikrotikはKVMで直接サポートされていませんが、セットアップの経験があります。 私たちの「雲」から、リャザン、カザン、ポドルスクへの靭帯がありました。実際、ミクロティックはそこに立ち、植物の間にすべてのトンネルを建設しました。



多くの場合、顧客は「クラウド」自体が事前にDRを想定していることを期待しています（2つのデータセンターに配置されているため）。 これはすぐに使用できるものであり、すぐにインフラストラクチャを設計して、移動できるようにする必要があります。 私たちは手助けをしようとしています。引っ越しの可能性を評価し、アドバイスをします。 成熟した顧客はこれに対応し、すぐにそのような機会に喜んでいます（サービスのメリットはこれに対応しています）。 また、ハイパーバイザーを使用してこれを行う必要はまったくありません。仮想マシン内からレプリケーションを構成できます。



実際に、1つの大きな「クラウド」のリソースをお客様に提供します。そこでは、3つの異なるプラットフォームを選択できます。1つのインフラストラクチャをホストするKVMの肩、別のインフラのVMwareのクラウドの肩（Cisco Poweredプラットフォーム）、およびHyper-VベースのMSの肩それぞれ3番目。 たとえば、ある大規模な銀行は、テスト環境を用意して、ドッカーが回転している独自の鉄と交差させたいと思っていました。 私たちのWebサイトはFIGのドッカーには落ちませんでしたが、開発者はクラウドAPIが本当に好きでした。彼らは異なるデータセンターのすべてのテストサイトに独自のWebベース環境を持っています。 APIを選択した後、ドッカーマージはうまくいきました（KVMの機能と柔軟性のおかげで、多くのねじれが可能になりました）。 別の機能：PDを保護するためにHyper-Vのクラウドショルダーを特別に設計しました。 このアプローチにはいくつかの制限があり、Hyper-Vのクラウドショルダーに任意の要件を持つ顧客を「上陸」させることはできません。



ワークステーションは個別のマシンとしてドラッグされません-多くの場合、1つのイメージとファイル共有が転送されるか、顧客がCitrixファームをセットアップします。 理論的には、このようなファームを備えたサーバーを「クラウド」に持ち込んで配置できますが、この機能はほとんど必要ありません。 2つのボタン-そして今、あなたはあなたの鉄片の設定をコピーすることができます。 さらに、データセンター内のさまざまなハイパーバイザーの肩を含む「クラウド」をうまく組み合わせることができます。



多くの場合、パフォーマンスミスが発生します。 チャンネル、ホイール-車の要件を過小評価する可能性があります。 たとえば、多くの場合「鉄」の再配置では、仮想化なしで作業することに慣れている人は、生産性の数パーセントをハイパーバイザーの作業に充てる必要があることを忘れています。 サーバーにグラフィックカードがあった場合、クラウドにはグラフィックカードがありません。 混乱がありました。顧客は仕様を読まず、ビデオ編集、32コア、200ギガバイトのRAMの仮想化を行いました。 ただし、このマシンはクラウドサーバーのように動作し、コンソールのみにデスクトップを提供すると想定されていました（このような交換には1.5 FPSの制限がありました）。 しかし、非常に優れたパフォーマンスを備えたストレージ：1つまたは別のニーズに応じて、配送時の支払いの数を選択できます。



一部のお客様は、クラウドでホストされている製品のライセンスに関する制限を認識していません。 たとえば、Windows仮想マシンは、IaaSサービスプロバイダー（物理サーバーの所有者）によって独占的にライセンスされています。



多くの場合、長年にわたるネットワークエラーが移行中に発生します。 たとえば、ある困難な動きの中で、MSSの構成が正しくないことが判明しました。2007年以来松葉杖があり、その結果、誰も触れませんでした。 その結果、RDPセッションが切断されました。



外部アドレス指定の機能もあります。 マシンはNATを介してインターネットに入ることができ、静的な変換があることがわかります。



顧客の1人は、特定のプロバイダーからの「ホワイト」IPアドレスのサブネットを「クラウド」に入れたいと考えていました。 お金と時間を節約するために、次のスキームを思いつきました。

1. お客様のルーターからクラウドへのVPNトンネルが構築されましたが、AS CROCはありませんでした。
2. 顧客はプロバイダーであるため、彼は自分に必要な「白い」IPアドレスのサブネットを割り当てました。
3. VPNを介したトラフィックはプロバイダーの機器に到達し、独自のASを介してBGPを介してインターネットにブロードキャストされました。

つまり、単に外部サーバーを介してインターネットにアドレスをブロードキャストします。つまり、「クラウド」の出力ではなく、工場のルーターを経由しました。 チャンネルが許可したので、彼らは気にしませんでした。



このように。 「クラウド」の詳細については、こちらをご覧ください。

• CEPHクラスター
• オールフラッシュの物語
• ハイブリッドクラウドFAQ
• 5日間の転送
• Infiniband 56Gに切り替える