私たちはまともなサイズのサーバー資産を持っています:いくつかのProLiantsに加えて、VMWare環境を実行しているIBMBladeCentreとSAN。建物の移転が差し迫っているため、サーバールーム用の十分なスペースがないため、すべてをコロに移動することを検討してきました。私の上司は、トラフィックの多い2つのWebサイト(月間約900万ページビュー)、Exchangeサーバー(月間約100万通のクリーンな電子メールの送受信)を含む、すべてをクラウドホスティングするというアイデアにもっと熱心です。 file/print/AD /すべての通常のもの。これは私には良い考えとは思えませんが、私はクラウドの方法に慣れていません。誰かアドバイスはありますか?
ここには十分な詳細がありません。クラウドベースのホスティングで考慮すべき問題は次のとおりです。
プライバシー/所有権の問題-他の誰かがあなたのデータの法的所有権を持っていても大丈夫ですか?現在(電話会社や他のサービスプロバイダーと同様に)そのデータに対して召喚状が発行された場合、通知を受けたり、申し立てを破棄したりする権利がないことを意味します。
パフォーマンスSLAなし-可用性に利用できるSLAはありますが、パフォーマンスSLAを提供するクラウドプロバイダーはありません。
コスト-非常に一般的にTCO(最も安いものから最も高いものまで)は自己所有です-自己ホスト型、同じ場所に配置された、VPS、クラウドベース。すべてのルールには例外がありますが、entoerインフラストラクチャの場合、費用効果の高いクラウドはまだ見ていません。
クラウドには1つの実際の引き分けがあり、それは、0の費用の展開/プロビジョニングと組み合わせたモデルを使用するための支払いです。ラボ、サーバーはすばやく頻繁に作成および破棄されるため、クラウドに勝るものはありません。
クラウドホスティングは一般的に非常に柔軟性があり、プロバイダーによってさまざまな方法があります。より大きなサーバーが必要な場合は、通常、ハードウェアを自分で追加するか、大きな変更のために別のボックスに切り替える必要があります。クラウドホスティングでは、通常、シンプルなインターフェースを介して実行され、システムによっては、サイズ変更に数分から数秒かかる場合があります。
クラウドホスティングは元々高可用性を目的として設計されていたため、ハードウェア障害が発生した場合のダウンタイムは非常に短く、システムによっては通常1分未満です。ただし、今日では通常、非常にスケーラブルであり、専用サーバーの優れた代替手段です。
クラウドホスティングは従量制モデルでは高額になる可能性があるため、通常はパッケージを購入するか、何らかの契約や予約をして低価格にする必要があります。非常に優れたサービスを提供する、調査したい2つの特定のホストがあります。
私は物理サーバーを使用したことがないため、コロケーションについては何も言えません。そのため、他の回答を調べて情報を入手することをお勧めします。
ハイブリッドソリューションを検討することをお勧めします。トラフィックに応じてスケールアップおよびスケールダウンできるため、クラウド上で大規模なWebサイトをホストすることは機能する可能性があります。
交換など、おそらくコロ施設に保管したいと思うでしょう。
ウェブホスティングのためのクラウドの主な利点はスケーラビリティであり、障害のあるハードウェアを交換するためにコロにドライブする必要があることを心配する必要はありません。ノードを削除し、新しいノードを作成して、ロードバランサーに追加するだけです。
スプリットモデルはどうですか? Webホスティングはクラウドソース化しますが、LDAPインフラストラクチャ、Exchangeなどはクラウドソース化しません。内部アプリはケースバイケースです。 Co-Loに関しては、冗長性の一部をCoLoに移動することを検討します(たとえば、ADサーバーの一部。DCが3つある場合は、1つをCoLoに移動しますが、それ以上の場合は、CoLoにもっと高い割合を送信したいと思います)が、それは完全にインフラストラクチャに依存します。 ESXを使用していてV-Motionを使用している場合は、サイトに問題が発生した場合のフェイルオーバーにESXを使用できると価値がある場合があります。これは、現在のインフラストラクチャのallの余地がない場合に、輻輳の問題に役立つ可能性があります。
私にとって最も厄介なことは、私が管理の失敗であると認識していることです。計画されたサイトの移転ですが、十分なインフラストラクチャスペースの計画に失敗しましたか?!本当に?!それが誰かのアウトソーシングアジェンダ(政治的操作を叫ぶ)をプッシュする動きでない限り、このような動きで問題を強制することは無責任です。
私はあなたの特定の状況についてのすべての事実を知ることができないことを念頭に置いて、私の見解:
あなたの前に差し迫った物理的な動きがある場合、あなたは絶対にしないでください敷地外にいる必要があるという不変の期限にシステムを別のプラットフォームに移行したいと思っています。 1つは、強要の下で問題が発生する可能性が高く、2つは、問題が発生してタイムスケールがずれた場合(そして、いつ発生しなかったのか)、移行の途中で移動し、データセンターのスペースが必要になることです。あなたのキット。クラウドが提供するはずのエレガントなコストと手間のかからない万能薬というよりは、災害のための高価なレシピのように聞こえます。いいえ、回避できる可能性がある場合は、2つのプロジェクトをこのような1つにマッシュアップしないでください。
クラウドホスティング(あなたの上司がそれを想定していると私が思う意味で)は素晴らしく、その場所があります、それはあなたがすることにぴったりかもしれません。しかし、今のところ、インフラストラクチャを移動する必要があるので、十分な余裕があると思います現状のままなので、すべてのハードウェアを廃棄することはできないという明確なメッセージで上司にプッシュバックしますとシステムはすぐに利用できますが、インフラストラクチャの少なくとも一部をクラウドホスティングに移行することは、施設の移転からほこりが落ち着いた後、次の大きなプロジェクトとして実際に実現可能かもしれません。
「クラウド」自体について。すでにローカル/内部クラウドソリューション(VMWare/SAN環境)を実行しています。ラックをレンタルして独自のキットを管理し続けるホスト型データセンターに移動すると、リモートで提供されるプライベートクラウドソリューションを利用できるようになります。
多くの非技術的な上司は流行語で生きており、クラウドコンピューティングも例外ではありません(実際、現時点ではおそらく「でたらめなビンゴ」カテゴリで最大の犯罪者です)。これを有利に活用し、すでに行っていること(仮想環境を実行していること)を上司のクラウドのアイデアに結び付けることで、物事をより賢明な方向に導くことができます。レポートを作成するときはいつでも、VMを「インスタンス」と呼び、ESXホストを「ノード」と呼ぶのと同じくらい簡単です。
バックアップと持続可能性/フェイルオーバーの目的で、「あまり使用されていない」データのほとんどをクラウドに移動しています。プライマリデータまたはミッションクリティカルなデータはローカルでホストされ、その一部でさえクラウドベースのストレージと自動的に同期されるため、ハードウェア全体に障害が発生しても、ある程度の遅延が発生してもクラウドデータで実行できます。
私はこのアイデアを、通常のサーバー/ PCでストレージ/メモリを実行する方法として説明するのが好きです。
ローカルストレージとクラウドベースのストレージについても同じことが言えます。データ/ストレージを優先度の高いグループに分割します。
しかし、私のポイントは、1つの解決策がすべての問題に適合するとは思わないということです。ハイブリッド複合ソリューションは、最大限に活用できる場所です。
現時点でのクラウドホスト環境に対する私の個人的な選択はAmazonAWSですが、MicrosoftのAzureは注意を払う価値があるかもしれません-Amazonは当分の間まだリードしています。 Google Apps Engineも興味深いものですが、本番環境に不可欠なデータはまだ載せていません。