Yandex.Cloud が Virtual Private Cloud とどのように連携するか、またユーザーが便利な機能の実装をどのように支援するか

こんにちは、私の名前は Kostya Kramlikh です。Yandex.Cloud の Virtual Private Cloud 部門の主任開発者です。 私は仮想ネットワーカーです。ご想像のとおり、この記事では Virtual Private Cloud (VPC) デバイス全般と、特に仮想ネットワークについて説明します。 また、サービスの開発者である私たちがユーザーからのフィードバックを重視する理由もわかります。 しかし、まず最初に。

VPCとは何ですか?

現在、サービスを導入するにはさまざまなオプションがあります。 今でも誰かが管理者の机の下にサーバーを保管していると思いますが、そのような話が減ることを願っています。

現在、サービスはパブリック クラウドに移行しようとしていますが、ここで VPC と衝突します。 VPC はパブリック クラウドの一部であり、ユーザー、インフラストラクチャ、プラットフォーム、その他の容量を、クラウド内外のどこにいても結び付けます。 同時に、VPC を使用すると、これらの容量を不必要にインターネットに公開せず、隔離されたネットワーク内に留めることができます。

仮想ネットワークは外から見るとどのように見えるのでしょうか?

VPC とは、主に、VPNaaS、NATaas、LBaas などのオーバーレイ ネットワークとネットワーク サービスを意味します。そして、これらすべては、すでに構築されているフォールト トレラントなネットワーク インフラストラクチャ上で動作します。 素晴らしい記事 ここ、ハブレで。

仮想ネットワークとそのデバイスを詳しく見てみましょう。

XNUMX つのアベイラビリティ ゾーンについて考えてみましょう。 私たちは、仮想ネットワーク (VPC と呼ばれるもの) を提供します。 実際、これは「グレー」アドレスの一意性の空間を定義します。 各仮想ネットワーク内で、コンピューティング リソースに割り当てることができるアドレス空間を完全に制御できます。

ネットワークはグローバルです。 同時に、サブネットと呼ばれるエンティティの形で各アベイラビリティ ゾーンに投影されます。 各サブネットに、サイズ 16 以下の CIDR を割り当てます。 各アベイラビリティ ゾーンにはそのようなエンティティが複数存在する可能性があり、それらの間には常に透過的なルーティングが存在します。 これは、同じ VPC 内のすべてのリソースが、異なるアベイラビリティーゾーンにある場合でも、相互に「通信」できることを意味します。 インターネットにアクセスせずに内部チャネルを介して「通信」し、同じプライベート ネットワーク内にあると「考え」ます。

上の図は、アドレスのどこかで交差する XNUMX つの VPC という典型的な状況を示しています。 どちらもあなたのものになることができます。 たとえば、XNUMX つは開発用、もう XNUMX つはテスト用です。 単に異なるユーザーが存在する可能性もありますが、この場合は問題ありません。 そして、各 VPC には XNUMX 台の仮想マシンが接続されます。

計画をさらに悪化させましょう。 XNUMX つの仮想マシンが同時に複数のサブネットに固定されるようにすることができます。 そして、それだけではなく、さまざまな仮想ネットワークでも同様です。

同時に、マシンをインターネットに公開する必要がある場合は、API または UI を通じて実行できます。 これを行うには、「グレー」の内部アドレスから「ホワイト」のパブリック アドレスへの NAT 変換を設定する必要があります。 「ホワイト」アドレスを選択することはできません。アドレスのプールからランダムに割り当てられます。 外部 IP の使用を停止すると、その外部 IP はすぐにプールに戻されます。 「ホワイト」アドレスを使用したときのみ料金がかかります。

NAT インスタンスを使用してマシンにインターネットへのアクセスを許可することもできます。 静的ルーティング テーブルを通じてトラフィックをインスタンスにルーティングできます。 ユーザーがそれを必要とする場合があり、私たちもそのことを知っているため、このようなケースを提供しました。 したがって、イメージ カタログには、特別に構成された NAT イメージが含まれています。

ただし、準備ができた NAT イメージがある場合でも、セットアップは難しい場合があります。 一部のユーザーにとって、これは最も便利なオプションではないことを理解していたため、最終的には、ワンクリックで目的のサブネットに対して NAT を有効にできるようにしました。 この機能はまだクローズド プレビュー アクセスの段階にあり、コミュニティ メンバーの協力を得てテストされています。

仮想ネットワークが内部からどのように配置されるか

ユーザーは仮想ネットワークとどのように対話するのでしょうか? Web は API によって外側に目を向けています。 ユーザーは API にアクセスし、ターゲットの状態を操作します。 API を介して、ユーザーはすべてがどのように配置および設定されるべきかを確認すると同時に、実際の状態が望ましい状態とどの程度異なっているかを確認します。 こちらはユーザー様の写真です。 中で何が起こっているのでしょうか？

望ましい状態を Yandex データベースに書き込み、VPC のさまざまな部分を構成します。 Yandex.Cloud のオーバーレイ ネットワークは、最近 Tungsten Fabric と呼ばれるようになった OpenContrail の選択されたコンポーネントに基づいています。 ネットワーク サービスは単一の CloudGate プラットフォーム上に実装されます。 CloudGate では、多数のオープン ソース コンポーネントも使用しました。制御情報にアクセスするための GoBGP と、データ パスの DPDK 上で実行されるソフトウェア ルーターを実装するための VPP です。

Tungsten Fabric は GoBGP 経由で CloudGate と通信します。 オーバーレイ ネットワークで何が起こっているかを示します。 CloudGate は、オーバーレイ ネットワークを相互に接続し、またインターネットと接続します。

次に、仮想ネットワークがスケーリングと可用性の問題をどのように解決するかを見てみましょう。 簡単なケースを考えてみましょう。 アベイラビリティーゾーンが XNUMX つあり、その中に XNUMX つの VPC が作成されます。 XNUMX つの Tungsten Fabric インスタンスをデプロイし、数万のネットワークをプルしました。 ネットワークは CloudGate と通信します。 すでに述べたように、CloudGate は相互およびインターネットとの接続を保証します。

XNUMX 番目のアベイラビリティーゾーンが追加されたとします。 最初のものとは完全に独立して失敗するはずです。 したがって、XNUMX 番目のアベイラビリティ ゾーンには、別の Tungsten Fabric インスタンスをインストールする必要があります。 これはオーバーレイを処理する別のシステムとなり、最初のシステムについてはほとんど知りません。 そして、仮想ネットワークがグローバルであるという可視性が、実際に VPC API を作成します。 これが彼の任務だ。

VPC1 にプッシュされるリソースがアベイラビリティーゾーン B にある場合、VPC1 はアベイラビリティーゾーン B にマップされます。 アベイラビリティーゾーン B に VPC2 のリソースがない場合、このゾーンでは VPC2 は実体化されません。 次に、VPC3 のリソースはゾーン B にのみ存在するため、VPC3 はゾーン A には存在しません。すべてが単純かつ論理的です。

もう少し詳しく見て、特定の Yandex.Cloud ホストの構造を確認してみましょう。ここで特に注目したいのは、すべてのホストが同一の構造になっているということです。ハードウェア上では必要最低限​​のサービスのみが実行され、その他すべては 仮想マシン私たちは、コアインフラストラクチャサービスの上に高次のサービスを構築するとともに、クラウドを活用して継続的インテグレーションなどの特定のエンジニアリング上の課題に対処しています。

特定のホストに注目すると、ホスト OS 上で XNUMX つのコンポーネントが実行されていることがわかります。

• コンピューティング - ホスト上のコンピューティング リソースの配布を担当する部分。
• VRouter は、オーバーレイを構成するタングステン ファブリックの一部です。つまり、アンダーレイを介してパケットをトンネリングします。
• VDisk はストレージ仮想化のチャンクです。

これに加えて、 仮想マシン 以下のサービスが開始されました：クラウドインフラストラクチャサービス、プラットフォームサービス、および顧客容量。顧客容量とプラットフォームサービスは、常にVRouterを介してオーバーレイにアクセスします。

インフラストラクチャ サービスはオーバーレイに固執することができますが、基本的にはアンダーレイで動作することを望んでいます。 これらは SR-IOV の助けを借りてアンダーレイに貼り付けられます。 実際、パフォーマンスが低下しないように、カードを仮想ネットワーク カード (仮想機能) に分割し、インフラストラクチャ仮想マシンにプッシュします。 たとえば、同じ CloudGate がこれらのインフラストラクチャ仮想マシンの XNUMX つとして起動されます。

仮想ネットワークのグローバル タスクとクラウドの基本コンポーネントの構造について説明したので、仮想ネットワークのさまざまな部分がどのように正確に相互作用するかを見てみましょう。

私たちのシステムでは XNUMX つの層を区別します。

• Config Plane - システムの目標状態を設定します。 これは、ユーザーが API を介して設定するものです。
• コントロール プレーン - ユーザー定義のセマンティクスを提供します。つまり、データ プレーンの状態をユーザーが構成プレーンで記述した状態にします。
• データ プレーン - ユーザーのパケットを直接処理します。

上で述べたように、すべてはユーザーまたは内部プラットフォーム サービスが API にアクセスし、特定のターゲット状態を記述するという事実から始まります。

この状態はすぐに Yandex データベースに書き込まれ、API 経由で非同期操作 ID を返し、内部機構を起動してユーザーが望んだ状態を返します。 構成タスクは SDN コントローラーに送信され、オーバーレイで何を行うかを Tungsten Fabric に指示します。 たとえば、ポートや仮想ネットワークなどを予約します。

タングステン ファブリックの構成プレーンは、必要な状態をコントロール プレーンに送信します。 それを通じて、Config Plane はホストと通信し、ホスト上ですぐに何が回転するかを正確に伝えます。

それでは、ホスト上でのシステムの様子を見てみましょう。 仮想マシン VRouterにはネットワークアダプタが接続されています。VRouterは、パケットを監視するTungsten Fabricカーネルモジュールです。パケットのフローが既に存在する場合、モジュールはそのパケットを処理します。フローが存在しない場合、モジュールは「パンティング」と呼ばれる処理を実行します。これは、パケットをusermodプロセスに送信することです。プロセスはパケットを解析し、DHCPやDNSのように自身で応答するか、VRouterにパケットの処理方法を指示します。その後、VRouterはパケットを処理できます。

さらに、同じ仮想ネットワーク内の仮想マシン間のトラフィックは透過的に行われ、CloudGate には送信されません。 仮想マシンがデプロイされているホストは、相互に直接通信します。 これらはトラフィックをトンネリングし、アンダーレイを通じて相互にトラフィックを転送します。

コントロール プレーンは、別のルーターと同様に、BGP 経由でアベイラビリティ ゾーン間で相互に通信します。 これらは、XNUMX つのゾーン内の VM が他の VM と直接通信できるように、どのマシンがどこで稼働しているかを通知します。

そしてコントロールプレーンはCloudGateと通信します。 同様に、どこでどの仮想マシンが起動されているか、それらがどのようなアドレスを持っているかを報告します。 これにより、外部トラフィックとバランサーからのトラフィックをバランサーに転送できるようになります。

VPC から出たトラフィックは CloudGate のデータパスに到達し、そこでプラグインを含む VPP がすぐに消化されます。 その後、トラフィックは他の VPC または外部の、CloudGate 自体のコントロール プレーンを通じて設定された境界ルーターに送信されます。

近い将来の計画

上記のすべてをいくつかの文で要約すると、Yandex.Cloud の VPC は XNUMX つの重要なタスクを解決すると言えます。

• 異なるクライアント間の分離を実現します。
• リソース、インフラストラクチャ、プラットフォーム サービス、その他のクラウド、オンプレミスを単一のネットワークに結合します。

これらの問題を適切に解決するには、内部アーキテクチャのレベルでスケーラビリティとフォールト トレランスを提供する必要があり、これは VPC によって実現されます。

VPC は徐々に機能を獲得し、新しい機能を実装し、ユーザーの利便性の面で何かを改善しようとします。 コミュニティのメンバーのおかげで、いくつかのアイデアが表明され、優先リストに追加されます。

現在、近い将来の計画として次のリストがあります。

• VPN サービスとして。
• プライベート DNS インスタンスは、事前構成された DNS サーバーを使用して仮想マシンを迅速にセットアップするためのイメージです。
• サービスとしての DNS。
• 内部ロードバランサー。
• 仮想マシンを再作成せずに「ホワイト」IP アドレスを追加します。

バランサーと、作成済みの仮想マシンの IP アドレスを切り替える機能は、ユーザーの要望によりこのリストに追加されました。 正直に言うと、明示的なフィードバックがなければ、これらの機能をもう少し後に採用することになっていたでしょう。 それで、私たちはすでに住所の問題に取り組んでいます。

当初、「ホワイト」IP アドレスはマシンの作成時にのみ追加できました。 ユーザーがこれを忘れた場合は、仮想マシンを再作成する必要がありました。 同様に、必要に応じて外部 IP を削除します。 間もなく、マシンを再作成しなくてもパブリック IP のオンとオフを切り替えることができるようになります。

自由に表現してください アイデアやサポートの提案 他のユーザー。 クラウドを改善し、重要で便利な機能をより早く入手できるようにしてください。

出所： habr.com