ZStack ネットワーク R&D ディレクターの Wang Wei 氏: プライベート クラウドのコンテキストで VPC をカスタマイズする方法

[51CTO.com からのオリジナル記事] 最近、ZStack はネットワーク アーキテクチャ VPC 2.0 の新しいバージョンをリリースしました。 ZStack 2.3.0 の主要機能として、VPC 2.0 は、柔軟なネットワーク構成、安全で信頼性の高い論理分離、分散ルーティング機能の有効化、東西ネットワーク トラフィックの最適化、クラウド ルーターを経由しない異なるサブネットの直接相互接続など、包括的で強力なネットワーク機能サポートを提供します。高度な戦略により、さまざまなネットワーク シナリオの実装に対応できます。

長年にわたる市場教育と実践を経て、ほとんどのパブリック クラウド ユーザーは、VPC がパブリック クラウドの重要な基本コンポーネントであることを認めています。しかし、プライベート クラウドやハイブリッド クラウドの場合、ビジネス セキュリティをどのように確保すればよいのでしょうか?クラウドの可能性を最大限に活用するにはどうすればよいでしょうか?過去の仮想化設計の経験が活用されるかどうかはまだ不明です。

ZStack はプライベート クラウドとハイブリッド クラウドのテクノロジーと製品においてどのような試みを行ってきましたか? VPC2.0 は、ネットワークの柔軟性と拡張性に関するビジネス ニーズをどのように解決するのでしょうか?プライベート クラウドのコンテキストで VPC をどのように定義しますか?

導入

[[221284]]

ZStack ネットワーク R&D ディレクター、Wang Wei 氏

Youyun の元 OpenStack R&D ディレクター。彼はYouyunと中国科学院計算技術研究所で多くの国内大規模クラウドコンピューティング構築プロジェクトに参加しました。彼はネットワーク R&D チームを率いてネットワーク診断プロジェクト Steth を OpenStack コミュニティに提供し、OpenStack、MidoNet、buildbot などの多くのオープンソース プロジェクトに貢献しました。 2016 年に ZStack に入社し、主に ZStack 上での SDN と NFV の実践と調査を担当しています。

Q1: ネットワーク分野のベテラン専門家として、VPC2.0について簡単に紹介してください。プライベート クラウドやハイブリッド クラウドの構築において、どのような問題や問題点が解決され、最適な適用シナリオは何でしょうか。

ZStack VPC1.0 では、VPC の概念と設計は主にパブリック クラウドの分離設計から派生しています。既存のネットワーク アクセスやネットワークの柔軟性など、多くの面で欠陥があります。複雑なプライベート クラウドやハイブリッド クラウドのシナリオでは、ニーズを完全に満たすことはできません。そのため、ZStack は柔軟性、使いやすさ、パフォーマンスの向上に重点を置いて、ネットワーク モデルに多くの変更を加えました。

現在、ほとんどの IaaS 製品 VPC は、セキュリティと分離に重点を置いたパブリック クラウドから提供されています。 ZStack VPC 2.0 は、セキュリティと分離に基づいて、ユーザーの実際の使用シナリオ、ソフトウェアとハ​​ードウェアの組み合わせの使用シナリオ、再利用シナリオなどを考慮します。既存の VPC1.0 をベースに、機能が豊富で使いやすい VPC2.0 を実現します。数十台の仮想マシンの小規模アプリケーションから数万台の仮想マシンの大規模展開まで、企業のニーズを満たすことができ、ハイブリッド クラウド VPC に完全に接続して、プライベート クラウド VPC の新しい定義を完成させます。

Q2: VPC2.0 がユーザーにもたらす主な価値は何ですか?

• 柔軟なネットワーク構成
• 安全で信頼性の高い隔離
• 豊富なネットワークシナリオ
• 管理コストの削減
• より高いネットワークパフォーマンス

Q3: VPC テクノロジーはどのような方向に発展し、次にどのようなネットワーク最適化が行われるとお考えですか?

次のステップは、まずネットワーク機能を開放することです。私たちはネットワーク機能をオープンプラットフォームにしたいと考えています。当社が提供するネットワークサービスだけでなく、NFV、ファイアウォール、モニタリングなど、さまざまなメーカーの製品をZStackクラウドプラットフォームにシームレスに接続できます。これにより、効率がさらに向上し、ユーザーの使用および運用・保守コストが削減されます。現在、OPNFV などの組織や OpenDaylight などのプロジェクトがいくつかの作業を行っていますが、ユーザーに提供できるまでにはまだ遠い状態です。

2つ目はさらなる自動化です。現在、ハイブリッド クラウドの有効化とトンネルの確立には、必然的に手動のプロセスが存在します。これは、ユーザーが最も長く待つ必要があるステップであり、エラーが最も発生しやすいステップでもあります。今後は、SD-WANなどの技術を導入することでこのプロセスをより効率化し、現在のネットワークの状態や品質を詳細かつ直感的にお客様に提示し、ユーザーが「確実に」エラーチェックや管理を行えるようにしたいと考えています。

次に、セキュリティ、柔軟性、パフォーマンスという 3 つの側面に焦点を当てて、ZStack VPC 2.0 の設計思想とアーキテクチャについて詳しく説明します。

安全性

ユーザーがパブリック クラウドを使用する場合、最初に考慮するのは多くの場合セキュリティです。過去1年間、さまざまなセキュリティインシデントが継続的に発生し、ユーザーの不安を募らせています。このような問題はプライベート クラウドでは発生しません。キャビネットから電源装置まですべてが企業自体の管理下にあり、出口には高価なネットワーク セキュリティ機器が配備されることがよくあります。他者と共有するネットワーク ケーブル上でデータを実行する場合と比較して、このアプローチでは、当然ながら、企業専用のネットワークとデータがより適切に保護されますが、ユーザーには相当な運用および保守コストも発生します。

そのため、安全性を確保しながら、ユーザーのセキュリティ運用・保守コストをいかに削減するかを第一に考えます。ネットワーク分離とエラスティック コンピューティングは当然矛盾することに注意してください。分離が詳細になるほど、容量を迅速に拡張したり、サービスを調整したり、リソースをリサイクルしたりすることが難しくなり、この困難さは企業の数が増えるにつれて指数関数的に増大します。

かつては、出口にファイアウォールを展開すれば、あらゆる攻撃に耐えられると信じられていたかもしれません。それは、嵐の真っ只中に城を建てる場合、あらゆる攻撃に耐えようとして外壁をどんどん高くしていくのと同じです。

しかし、現実には、SaaS サービスの増加、企業インターネットと企業イントラネットに関係するデバイスの数の増加により、この設計を維持することがますます困難になっています。

企業には、Web サイト、従業員の VPN、購入した SaaS サービス、外部 API サービス、開発された Web サイト アプリやモバイル アプリに提供されるデータ チャネル、さらには従業員が独自に接続する携帯電話など、外部データとネットワークの入り口がますます増えています。これらはセキュリティ上のリスクをもたらす可能性があるため、企業はより多くの、より高い外壁を設置する必要があります。

アプリケーションの爆発的な成長。以前は、アプリケーションの拡張は月単位、あるいは四半期単位で計算されることもありました。アプリケーションがリリースされると、数か月間はビジネスの成長をサポートするのに十分な場合があります。しかし、インターネットの急速な普及により、一度アプリケーションが好評を博すと、急速に普及する可能性があります。これにより、コンピューティング能力の拡張に対する要求が非常に高くなり、ネットワーク変更の手動調整ではエラーや漏洩が発生しやすくなります。

データの爆発的な増加により、ハイブリッド クラウドの需要が高まっています。ビジネスの成長と並行して、ストレージ需要も増加し、データ価値も継続的に増加しています。ストレージに対する要求がますます広範になってきています。従来の SAN や NAS に加えて、一部のビジネスでは超高性能が求められ、一部のビジネスではオブジェクト ストレージが求められ、ホットとコールドの分離、大量のログの保存などの要件もあります。現時点では、すべての機器を自分で購入するのは費用対効果が高くありません。パブリック クラウドに接続してハイブリッド クラウドを形成することは間違いなく実現可能なオプションですが、ネットワーク要件はより複雑になります。

このような状況で、Google は BeyondCorp セキュリティ アーキテクチャを提案しました。その基本的な考え方は次のとおりです。

セキュリティ分離は、IP と MAC ではなく、アプリケーションとアカウントに基づいて行われます。アクセス制御は静的ではなく動的になり、企業間の相互アクセスを制限するための権限やプロトコルに自動的に従います。

しかし、この高度なセキュリティ アーキテクチャを企業にどのように適用できるのでしょうか?プライベート クラウドは、顧客がこれらのセキュリティ目標を達成するのにどのように役立ちますか? ZStack アーキテクチャに基づくネットワーク設計を見てみましょう。

レイヤー2分離

すべてのネットワーク分離の中で最も徹底したものは、レイヤー 2 ネットワーク分離です。ただし、従来のレイヤー 2 ネットワーク分離は、VLAN または 802.1ad に基づいています。前者は利用できるドメインが少なく、後者は設定が複雑すぎます。幸いなことに、ZStack は 2.0 以降、ネットワーク分離テクノロジーとして VXLAN を提供しています。

市場にあるほとんどの IaaS とは異なり、ZStack は VXLAN ネットワークを構成するための非常に柔軟で豊富な方法を提供します。 ZStack は、VXLAN のアンダーレイ ネットワークとオーバーレイ ネットワークを VXLAN プールと VXLAN ネットワークとして記録します。前者は、クラスターへのロード、VNI 範囲のロードなどに使用され、ロード時に VTEP アドレス セグメントを選択できます。 ZStack は適切な VTEP アドレスを自動的に検出し、ロードします。

各クラスターは異なる VTEP アドレス セグメントを使用できます。管理者は、VNI 範囲を任意に定義し、このプールをエンド ユーザーまたは部門の運用保守管理者と共有し、その上に VXLAN ネットワークを作成できます。プロセス全体は高度に自動化され、柔軟性があります。サーバー上の VTEP に必要なアドレスが何らかの理由で変更された場合でも、ZStack インターフェイス上の物理マシンに再接続するだけで自動的に同期されます。

実際の運用では、VXLAN を必要なサービスごとに個別に展開するか、VXLAN をビジネス部門に分割して自由に構成し、ネットワーク分離の最低レベルを確保することができます。基盤となる ARP スプーフィングも高レベルのサービス スニッフィングもこのレベルを突破することはできません。

カスタムルート

ZStack 2.1 から、カスタム ルーティングの機能を提供します。一見すると、この機能はセキュリティとは関係ないように思えますが、そうではありません。

まず、パブリック クラウドでは、パブリック ネットワークはインターネットであると定義するのが簡単な場合が多くあります。唯一の違いは、通信ネットワーク、Unicom ネットワーク、BGP ネットワークなどである可能性があることです。これはプライベート クラウドには当てはまりません。プライベート クラウドでは、イントラネットはサービスが展開されるネットワークですが、パブリック ネットワークは必ずしもインターネットではありません。たとえば、次の図のアーキテクチャ:

3 つのサービスがデプロイされた 2 つの VPC があるとします。パフォーマンス上の理由から、アプリケーションとデータベースは 1 つの VPC に配置されますが、Web サービスは別の VPC 内のパブリック サービスです。この場合、アプリケーション サービスはクラウド ルーティングとカスタム ルーティングを介して VPC2 に移動できます。ここで、VPC2 はクラウド ルーティング機能を使用して複数のパブリック ネットワークをサポートします。この機能はカスタム ルーティングと組み合わせて使用​​する必要があります。

さらに、データベースのセキュリティをどのように確保するのでしょうか?侵入されたり、発見されたりしないように？セキュリティグループは 1 つです。一方、検出トラフィックや予期しないルーティングによってデータベースが外部に発見されるのを防ぐために、ZStack でブラック ホール ルーティングを指定することもできます。

これにより、データベース サービスのアドレス セグメントが VPC 外に漏洩しないことが完全に保証されます。

複雑なネットワークのルーティングの複雑さを考慮して、ZStack は、クラウド ルーティング内のどのルーティング エントリが有効であるか、およびどのルーティング エントリが構成されているが実際には有効ではないかを管理者が確認するための API も提供します。

ソースベースのセキュリティグループ

従来のセキュリティ グループは、IP、プロトコル、ポートに基づいています。ポリシーの遵守（仮想マシンの恣意的なドリフトはセキュリティ ポリシーの有効性に影響しません）を除けば、このようなセキュリティ グループが従来の ACL に比べてどれほど優れているかを判断するのは困難です。また、ゾーンベースのファイアウォールと比較すると、やや弱いです。

ただし、ZStack は 2.1 以降、ソースベースのセキュリティ グループを提供しており、セキュリティ グループをセキュリティ ドメインとして使用できます。 ZStack は、異なるセキュリティ グループからのトラフィックを自動的に識別できるため、IP またはネットワーク セグメントを繰り返し設定することなく柔軟なアクセス制御を実現し、エラーを減らして効率を向上できます。

上記のように、ソース セキュリティ グループに対してセキュリティ グループ ルールを設定できます。たとえば、セキュリティ グループ 1 では、ソースがセキュリティ グループ 2 から来る場合に開くポートと、ソースがセキュリティ グループ 3 から来る場合に開くポートを構成できます。

他の

さらに、ZStack には、IP アドレスや MAC アドレスのスプーフィングを防ぐためのソース アドレス フィルタリング、ユーザーが間違ったサーバーからアドレスを取得するのを防ぐための DHCP サーバー アンチスプーフィングなど、他の多くのセキュリティ テクノロジがあります。これらのテクノロジを効果的に使用することで、管理者は独自のニーズと実際の環境に基づいて、安全で信頼性の高いネットワークを構成できます。

プライベートクラウドやパブリッククラウドとは異なり、これらのシステムの設定や使用はユーザー自身が構成して使用することができます。同時に、ユーザーは WAF、ファイアウォール、トラフィッククリーニングなどの既存のセキュリティデバイスにアクセスできます。次の内容を参照してください。

フレキシブル

パブリック クラウドの場合、すべてのルールはベンダーによって決定されます。ベンダーは独自の考慮事項や技術的な制限に基づいてこれらのルールを定義することがよくあります。一方で、クラウド ネットワークの使用方法と従来の使用方法には多くの違いが生じ、管理操作が不便になることもあります。たとえば、パブリック クラウド データベースは拡張性の利便性をもたらしますが、デバッグの不便さももたらします。一方、リソースの使用に関してはオールインのアプローチを形成することが容易です。たとえば、パブリック クラウド上のデータベースのみを使用したい場合でも、そのためにはビジネス仮想マシンをクラウドに移行する必要があり、さらにストレージ システム、バックアップ システム、さらにはサポート コンテンツ セットも移行する必要があり、非常に不便です。

プライベート クラウドを設計する際には、「顧客はクラウド ネイティブを設計する必要がある」という言い訳で顧客のニーズが不合理であると決めつけるのではなく、これらすべてを考慮する必要があります。特に、ZStack は製品化されたプライベート クラウドであり、古い設計や用途、さらにはユーザーによる無理な使用にも対応しながら、継続的にアップグレードされ、新しい機能やシナリオが追加されます。

ZStack VPC 2.0 は、柔軟性の面で次の特長を備えています。

複数のネットワーク サービス アドレス

中小規模のプライベート クラウドでは、パブリック ネットワークがインターネット上の実際の IPv4 アドレスである場合に特に、パブリック ネットワークの IP アドレスが不十分であることが一般的な要件となります。

ZStack は、Elastic IP、負荷分散、IPSec VPN、ポート転送、SNAT などを含む豊富なネットワーク サービスをユーザーに提供します。同時に、ユーザーの IP アドレスが制限される場合があります。たとえば、ユーザーはアドレスを 1 つしか持っていないが、SNAT を使用して仮想マシンをパブリック ネットワークに公開し、ハイブリッド クラウドに接続するための IPSec アドレスとしても使用したいとします。

この要件はデータ プレーンでは実現可能ですが、クラウド プラットフォームのコントロール プレーンにとっては大きな課題となります。クラウド プラットフォームは、各サービスの IP 要件を適切に調整し、クラウド ルーティング上で適切に構成する必要があります。 ZStack 2.3.0 以降では、ロード バランシング、IPSec、ポート転送、SNAT、および専用 IP を必要としないその他すべてのサービスに 1 つの IP を使用することがサポートされています。さらに、ユーザーはポートの使用を任意に定義できるため、VIP がネットワーク属性からプールされたリソースに完全に開放され、プライベート クラウドによる IP の使用が大幅に解放されます。

さらに、各サービスが異なるポート（SNAT 外）を使用することを考慮して、ZStack はポートごとに異なる QoS を提供することもできるため、VIP 自体と異なるサービスの両方に同時に QoS を提供することができます。

物理ネットワークアクセス

プライベート クラウドでは、既存のデバイスや既存のネットワークへのアクセスも避けられない問題です。まず、企業は投資の無駄を避ける必要があります。第二に、短期間で、多くのソフトウェア実装は、アプリケーション配信コントローラ ADC、トラフィッククリーニング装置などのハードウェアのパフォーマンスや機能に匹敵することができません。

物理デバイスのアクセス問題を解決するために、ZStack は複数のパブリック ネットワーク、カスタム ルーティング、複数のネットワーク カード、VXLAN ゲートウェイなどの複数のソリューションを提供します。最初の 2 つは以前に紹介されており、複数のネットワーク カードは理解しやすいです。 VXLAN ゲートウェイ ベースのソリューションは、ZStack が標準の VXLAN プロトコルを使用するためです。したがって、VXLAN プロトコルを使用する他のネットワーク デバイスは、理論的には ZStack の VTEP とネゴシエートして同じ VXLAN アンダーレイ ネットワークを形成し、仮想ネットワークと物理ネットワークを混在させる効果を実現できます。

多くの場合、クラウド ネットワーク テクノロジーは DVR を使用してトラフィックを最適化しますが、偽のゲートウェイによって一連の問題が発生し、運用と保守の複雑さが増し、一部の要件を達成できなくなることもあります。この問題は ZStack には存在せず、次の分散ルーティングで具体的に発生します。

ネットワークサービスフォロー

多くのクラウドでは、ネットワーク サービスは VPC で定義され、クラウド ルーティング上に実装されるため、クラウド ルーティングは VPC の重要な役割になります。パブリック クラウドでは、クラウド ルーティングをユーザーに直接公開することを避けることが多く、プライベート クラウドでは、クラウド ルーティング関連の操作を重要な操作としてリストすることが多く、ユーザーが任意に削除またはアンインストールすることはできません。そうしないと、ネットワーク サービスが消失する可能性があります。

しかし、ZStack では違います。ユーザーのネットワークサービス作成はビジネス指向であり、ビジネスに役立つものであると考えています（特にElastic IP、ポート転送など）。このとき、仮想マシンを別の VPC に転送したり、クラウド ルートを削除したりする場合は、ネットワーク サービスを失うことはお勧めできません。ネットワーク サービス フォローを実装することで、ネットワーク サービスが作成されると、クラウド ルートではなく仮想マシンにフォローされるようになりました。クラウド ルートが削除された場合、再作成またはロードされると、すべてのネットワーク サービスが自動的に再適用されます。これからの NAT ルールは、実際のファイアウォールに依存せず、ビジネスに直接結びつくものになります。ファイアウォールを変更または再構築した場合でも、システムは常にビジネスの回復を支援し、リソースの真のプール、依存関係の排除、完全な柔軟性を実現します。

上図のように、クラウドルーター上にネットワークサービスが定義されていますが、最終的にはVM2で使用されるため、VM2は消えません。クラウド ルーターにどのような変更が発生しても、ネットワーク サービスは最終的に VM2 に適用されます。

パフォーマンス

単一のリージョンで数百万台以上の仮想マシンを実行できるパブリック クラウドとは異なり、プライベート クラウドにはパフォーマンス要件がないわけではありません。実際、ユーザーのニーズが変化するにつれて、小規模で余分なリソースを無駄にすることなく、大規模な要件に対応できるソリューションを備えながら、小規模から大規模までのユーザー要件に適応できる必要があります。

特に、クラウド ルーターが複数のサブネットに接続されると、企業の東西トラフィックの需要により、クラウド ルーター上のトラフィックが非常に大きくなる可能性があります。クラウド ルーターがネットワーク全体のパフォーマンスのボトルネックになると、ユーザーに受け入れられなくなります。単一点の問題に加えて、パフォーマンス占有も相当なものです。

従来のネットワーク プロトコルでは、通常、DHCP サーバーやルーティング ゲートウェイなどのプロセス全体が集中管理されていると定義されており、集中管理によって実装も便利になります (特に SNAT やルーティング テーブルなどのサービスの場合)。 DHCP やゲートウェイなど、一部のサービスは分散手段によって実際に最適化でき、その重要性を考えるとそうする価値があることがわかりました。

分散DHCP

ZStack は初期の Flat ネットワークから分散 DHCP をサポートしてきましたが、クラウド ルーティング ネットワークは集中型 DHCP です。 2.1 からは、クラウド ルーティング ネットワーク DHCP を分散設計に変更し、VPC ネットワークに継承し始めました。

分散ルーティング

分散ルーティングは、ZStack VPC 2.0 の非常に重要な機能です。業界内の一部の DVR 実装は規模が限られていたり、脆弱で本番環境への適用が困難であったりしますが、ZStack VPC 2.0 は設計当初から慎重に検討されたため、次のような特徴があります。

• 事前知識なし
• メッセージキューなし
• ゲートウェイスプーフィングなし
• 集中型コントローラなし
• 瞬時にオン/オフ

まず、事前の知識はありません。トラフィック最適化システム全体で ZStack データベースから情報を取得する必要はありません。なぜこれが重要なのでしょうか? ZStack の重要な設計原則の 1 つは、コントロール プレーンとデータ プレーンの分離です。コントロール プレーンの障害はデータ プレーンに広がりません。いずれにしても、ユーザー業務に影響が出ないようにすることが優先されます。

この設計原則では、当然ながら ZStack データベースから情報を取得することはできません。すべてのネットワーク情報が ZStack データベースに記録されていても、データベースがクラッシュしないことを保証することはできず、データベース データはネットワークの状態を正確に反映できません。ユーザーはいつでも IP を変更したり、仮想ネットワーク カードを作成したりできます。

第二に、メッセージ キューがありません。メッセージ キューには容量制限と信頼性の問題があるため、OpenStack でメッセージ キューを介して DVR 制御データを実行することは、最終的には不適切な設計であると見なされました。そのため、ZStack DVR ではメッセージ キューを廃止し、IP 層で直接メッセージを送信し、仮想マシンが配置されているホストの情報を知らなくてもホスト上のエージェントに直接シグナリングを届ける機能を実現する ZSNP (ZStack Network Protocol) というプライベート プロトコルを実装しました。

3番目に、ゲートウェイ詐欺はありません。従来の DVR はすべてゲートウェイデセプションに基づいて実装されています。このアイデアは非常に直接的です。ゲートウェイを作成したいので、疑似ゲートウェイを実装する必要があります。同時に、ゲートウェイ漏洩の防止、疑似ゲートウェイと実ゲートウェイの判別など一連の問題をもたらし、ユーザー定義ルーティングの実装が困難になったり、物理機器へのアクセスが困難になったりしやすくなります。

ZStack は、分散ルーティングを実行する際には信頼性が高く、ユーザーの使用習慣に影響を与えないようにすることを望んでいます。そのため、ゲートウェイを欺くことなくステートレスなトラフィック最適化を実装しており、これまでのすべての機能と完全に互換性があり、ユーザーも分散ルーティングのメリットを透過的に享受できます。

4番目に、集中型コントローラーはありません。従来の DVR 設計では、CMS データベースとのやり取りに加えて、集中型コントローラーの問題が発生することがよくあります。コントローラーに障害が発生すると、最善の場合でもトラフィックを最適化できず、最悪の場合、ネットワークが中断され、ユーザーにとって絶対に受け入れられない状況になります。

ZStack VPC では、トラフィックの最適化はクラウド ルーターのエージェントによって開始されます。各エージェントは独自のクラウド ルーター上のトラフィックのみを処理するため、システムの単一ポイントは存在しません。さらに、このようなエージェントは、直接接続ではなく、サイドハンギング メカニズムに似ています。エージェントに障害が発生しても、ネットワーク障害は発生しません。代わりに、最適化されたトラフィックは徐々に従来の集中パスに戻ります。

最後に、非常に興味深い機能は、ZStack VPC の分散ルーティングをユーザーが有効化または無効化できることです。前回の原理の紹介から、このスイッチは各クラウド ルーターに分散されていることがわかります。ユーザーは、一部のクラウド ルーターを有効にし、他のクラウド ルーターを無効にすることを選択できます。さらに、この有効化はすぐに有効になり、無効化はルールが古くなった後に完全に従来のパスに戻ります。

さらに、ZStack VPC 2.0 には、最適化されたデータに基づくネットワーク接続検出、最適化されたトラフィック統計など、まだ探求すべき多くの可能性があり、将来のバージョンで徐々に導入される予定です。

要約する

上記では、ZStack VPC 2.0 アーキテクチャの特徴であるセキュリティ、柔軟性、高パフォーマンスについて簡単に分析しました。実際、ZStack VPC には、ユーザーが探索するのを待っている機能がまだ多数あります。特に、この記事では紹介していないハイブリッドクラウドを組み合わせたシナリオは数多くあります。誰でも気軽に参加して議論してみてください。

3 月には、ZStack ハイブリッド クラウド ネットワークのメジャー リリースが予定されていますので、ご期待ください。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]