1つのデータセンターの物理サーバーと仮想サーバー間でインターネット経由で接続する場合の一般的なトラフィックルートスキーム。
このような問題を回避するには、内部ネットワークに個別のチャネルを使用することをお勧めします。 物理サーバーが1つのデータセンターにある場合、またはすべてが1つのクラウドにある場合、これは問題ではありません。 容量がクラウドと物理サーバーの両方にある場合、プロジェクトが1つのデータセンターにあるか、複数のデータセンターにあるかに関わらず、問題が発生する可能性があります。 パブリッククラウドが1つのデータセンターにあり、物理機器が別のデータセンターにある場合 さらに複雑です。
異なるデータセンターの物理サーバーと仮想サーバー間でインターネット経由で接続する場合の一般的なトラフィックルートスキーム。
同様の問題の解決策を見つけ、モスクワの卸売および小売商社のインフラストラクチャに問題なく適用しました。 さらに説明します。
はじめに、なぜ必要な場合があるのかを判断しましょう。
- 同社はデータセンターに物理的な機器を配置しており、それを引き続き使用する意向がありますが、すでに十分な容量がなく、どこかで開発する必要があります。 クラウドは素晴らしいソリューションです！
- プロジェクト全体は物理サーバー（レンタルまたは当社のもの）でホストされており、会社の経営陣はクラウドを信頼していませんが、試してみる準備ができています。
- 障害が発生した場合に、物理サーバーでホストされているプロジェクトの完全なコピーを保持する必要性または要望があります。 クラウドレプリケーションは優れたソリューションです。
- バックアップをクラウドに保存する必要性または要望があります。
- プロジェクトを完全に仮想化できない場合や、クラウドサーバーの能力を超える場合があります。 この場合、インフラストラクチャの一部を物理サーバーに配置し、一部をクラウドに配置することができます。
これらは考えられるすべての理由とはほど遠いものであり、実際に遭遇した主で最も一般的なものをリストしています。
1つのデータセンターでも、クラウド仮想サーバーと物理サーバーを結合する際の問題は一般的です。 原則として、これはクラウドがデータセンターのネットワークコアから分離された別個のネットワークコアを持っているという事実によるものです。 これにはいくつかの理由があります。
- 法的 クラウド開発会社には独自のデータセンターがなく、1つ以上のデータセンターで通常のコロケーションクライアントとしてホストされています。 この場合、同社はクラウドパワーのみを販売できますが、ネットワークコアをデータセンターのコアに接続する機会はありません。
- テクニカル クラウド開発会社には独自のデータセンターがありますが、クラウドを開発する際には、クラウド用に別のネットワークコアが作成され、データセンターコアとの統合の可能性は考慮されませんでした。 技術的な制限により、これは後で行うのが困難です（ネットワーク機器、ソフトウェア、ハードウェアモデルなどのさまざまなメーカー）
- 組織的。 クラウド開発会社には独自のデータセンターがありますが、組織の問題により、データセンターとクラウドは2つの独立したチームによって実行される2つの異なるプロジェクトです。 たとえば、ネットワークコアの差別化は、企業のセキュリティポリシーによって整理できます。
クラウドと物理機器が異なるデータセンターにある場合、この場合のように、さらに多くのニュアンスがあります。 ただし、クラウドが元々正しく設計されていれば、すべての問題は解決されます。 どうやってやったか教えてあげましょう。
最初は、クラウド用に別のネットワークコアを構築することは意味がないと判断されました。 これは、データセンターの物理機器のインフラストラクチャの一部と、クラウドのプロジェクトリソースのネットワークサービスの統合を最大限にしたかったためです。 実際、DDoS攻撃からの保護、トラフィックバランシング、VPN組織、インターネットアクセスバンド、専用通信チャネルなどのサービスは、物理的な機器であろうとクラウドであろうと、同じ方法でプロジェクトのフレームワークで提供されます。
ネットワークコアの説明については説明しませんが、写真と説明を含む別の投稿があります。 クラウドに関する決定についてのみ説明します。
クラウドリソースが個別のラックに配置され、独自のスイッチを持っていることは明らかですが、コアは共有されています。 クラウドが配置されているラックには、Cisco Catalyst 3750Xシリーズスイッチが積み重ねられています。 4つのアップリンクがコアから1つのラックの2つのスイッチにスクロールされます。 当然、これらのアップリンクは互いに予約し、スイッチの1つ、カーネルの一部、またはアップリンクに障害が発生した場合、クライアントはこれに気付きません。
スタック内のスイッチは、iSCSIトラフィックを除き、プロジェクトクラウド内のすべての着信および発信トラフィックを処理します。 つまり、インターネットアクセス、仮想サーバー間の内部トラフィック、および仮想サーバーと物理機器間の内部トラフィックは、これらのスイッチとアップリンクを通過します。 チャネルボリュームは、すべてのトラフィックが遅延なく静かに通過するように配置されているため、リンクの1つに障害が発生しても、快適なネットワーク運用に十分な容量が確保されます。 トラフィック量が特定のしきい値に近づくと、十分な量のカーネル容量と障害のあるチャネルがあるため、アップリンクを追加します。
当然、すべてのクライアントトラフィックは、異なるVLANで分離された異なるサブネット上で実行されます。 仮想サーバー間のプロジェクトの内部ネットワークは完全に隔離されており、クライアント以外は誰もアクセスできません。 すべてのVLANはネットワークコアにあり、これが単一ネットワークアーキテクチャの主な利点です。 実際、ネットワークコアはこれらのVLANを正確に使用して、ルーティング、マーク、フィルターなどを行うことができます。 各VLAN内のトラフィック。
同時に、ホストにインストールされているHyper-V仮想化システムは、トラフィックのVLANへの分離を完全に理解しています。 アーキテクチャは非常に単純です。
- トラフィックは、物理サーバーのネットワークアダプターに到着します。
- ネットワークアダプターは、Hyper-V仮想スイッチまでのVLANに「注意を払わずに」ネットワークトラフィックを完全に渡します（VLAN無差別機能）。
- 次に、Hyper-V仮想スイッチはトラフィックをVLANに分割し、必要なトラフィックを目的の仮想ネットワークアダプターに渡します。
- 仮想サーバーのオペレーティングシステムは、仮想ネットワークアダプターを介して「タグなし」として必要なトラフィックを受信します。
仮想サーバーが複数の分離VLANからトラフィックを受信する必要がある場合、複数の仮想ネットワークアダプターが追加され、それぞれに特定のVLANが割り当てられます。
このプロジェクトの物理サーバーと仮想サーバー間の内部ネットワークを編成するスキームの例。
これはこのプロジェクトでどのように実装されていますか？ 接続プロセスは次のとおりです。
- クライアントには、サブネットが巻き上げられた2つのVLANが割り当てられました。 たとえば、VLAN1 10.1.1.0/24およびVLAN2 10.1.2.0/24。
- VLAN1に接続された仮想ネットワークアダプターが仮想サーバーに追加されました。
- 物理サーバーは、別のネットワークポートによってラック内のスイッチに接続されます。 ポートにはVLAN2が提供されます。
- カーネルでは、VLAN1のネットワーク10.1.1.0/24とVLAN2の10.1.2.0/24の間のルーティングが構成されます（サーバー間の接続はL3を経由することを理解する必要があります）。
- 新しいネットワークアダプター上の仮想サーバーには、サブネット10.1.1.0/24からのIPアドレスが割り当てられます（これが唯一のネットワークアダプターである場合、このサブネットのゲートウェイも登録されます。別のゲートウェイが他のネットワークアダプターに既に登録されている場合、ネットワーク10.1のルートは単に登録されます） 2.0 / 24）。
- 物理サーバーでは、すべてが同じでしたが、10.1.2.0 / 24ネットワークのみでした。
- できた！ これで、サーバー間に内部分離ネットワークが存在し、トラフィックはネットワークコアを通過します。
この例の物理サーバーと仮想サーバー間の内部ネットワークの組織の簡略図。
これらの作業は、クライアントの要求に応じてエンジニアが行います。 明日午前中に同様のサービスを今日注文するなど、夜間のみそのような作業を行うという規制があるため、クライアントはすでに既成の構成を受け取っています。
このスキームは非常にシンプルであり、最も重要なことは普遍的です。 クラウドにもコアにも松葉杖はありませんでした。
その結果、クライアントは、新しいプラットフォームに切り替えたり、物理的な機器を放棄したりすることなく、単一のネットワークに統合されたインフラストラクチャを受け取りました。 それははるかに費用対効果が高いことが判明しました。
物理機器が別のデータセンターにある場合、この問題も解決されます。 この場合、クラウド側からは何も変更されません。すべて同じ追加のネットワークアダプター、VLANがフックされます。 しかし、物理的な機器の部分では、チャネルをさらに整理する必要があります。 パートナーの電気通信事業者を介してMPLSチャネルを編成するか、テレコム事業者とMPLSチャネルを個別に交渉してポイントオブプレゼンスにすることができます。
したがって、クラウドと物理的な機器を単一のネットワークとして接続できるだけでなく、オフィス、データセンター、モバイルユーザー、パートナーなど、すべてのサイトを接続できます。 実際、これにより、クラウド内に仮想サーバールームを編成し、既存のすべてのサブネットに接続できます。
ご覧のとおり、ソリューションに包括的にアプローチすれば、クライアントの希望を実現できます。 当然、発生する主な問題の1つは、ソリューションのコストです。 しかし、これは別の会話です。 ;）