SDS-SDS　クラウドVDC：複数クラウド管理のゴールデンキー

SDS　クラウドVDC：複数クラウド管理のゴールデンキー

2020-01-06

2020年1月7日（火）午後、北京新雲南皇冠假日酒店で、TF中文コミュニティーが主催者となる「複数クラウドでコネクトし、オープンソースでオープンする」TF　Meetup大会において、上海数訊信息技術有限公司は、TF中文コミュニティーの初会員で国内TF応用のリーダーとし、SDSクラウドVDC複数クラウド管理サービス（CMP）の開発及び調査研究であった問題点とエスカレートの道を共有した。

下記の文章は、SDSクラウド事業部の銭誉総経理の講演から抜粋されたものであり、ここ数年の、SDS　VDC開発の経緯及び成果を紹介している。SDS　クラウドVDCは、応用シーンが複雑な企業のために、技術の実施とサービス管理を行なう。この講演で、オープンソースSDNの技術的なストームをもたらしてきた。

講演実況の初発信はTF中文コミュニティーより

Tungsten Fabric：に接続するゴールデンキー（原文のリンク先）

上海数訊クラウドコンピューティング事業部の銭誉総経理

SDSは、伝統的なデータセンターを主要な業務とする会社であり、なぜクラウドコンピューティングに転身するのか。2011年以降、データセンター業界は不動産業界のようで、競争が益々激しくなってきた。2013年になって、OpenStackのような技術が開発され、爆発的な成長ぶりを見せている。そしてSDSは2014年からクラウドコンピューティングに転身しようと決めた。

当初は複数のプラットフォームで発展しようと考えていた。実際の応用シーンから見れば、仮想機と容器とどっちがよいかという問題ではなく、この二つは違うシーンに使われ、どっちも置き換えられることがない。しかし、この二つのプラットフォームで事業を展開するには、厄介なことに合った。つまり、仮想機のネットワークと容器のネットワークは完全に畑違うのである。

途中に、当社は10個くらいのSDN技術を見つけた。ビジネス用からオープンソース用、国産の小範囲のアプリケーションまで、いろいろあった。その時、Tungsten FabricはまだOpenContrailと言われていた。当時のバージョンはOpenStackにしか対応しなかった。

CMPはここ数年できたものであるが、やり始めた時からCMPの考えがあったのである。

SDS　VDCは、一種の機能が優れる企業レベルハイブリッドクラウドプラットフォームであり、企業のクラウド能力を増強させることができる。

SDS　VDCは、企業に協力してデジタル業務に必要なスマート機能プラットフォームを構築でき、内部配置のIT環境に信頼性と安全性を提供することができる。

SDS　クラウドコンピューティングは、クラウドコンピューティングのコア技術があり、完全で自主的な知的財産権がある。
SDSのコア研究開発チームは2014年からクラウドコンピューティング技術の研究と開発作業に取り掛かった。

すべてのPortalと比較してみれば、OpenStackでもオリジナルのK8sでも、運転保守の角度から出発したものであり、対外に業務を提供するcaseではない。だから、これは使用者から見れば、非常に苦しいことである。だから、当社は当時から、二つのプラットフォームを一つにし、Webで完全でユーザーのインターフェースに基づくプラットフォームを作ると決定した。

その時に、SDSクラウドプラットフォームとSDNの方向付けをした。当時に主にOpenStackとK8sであった。K8sはPaaSプラットフォームではなく、docker管理を解決しただけであると発見した。小さい環境なら、使っても使わなくても構わない。必ずしもSDNにするとは限らない。OpenStackでもそうである。業務環境が複雑すぎでなければ、伝統的なVLANにして、量を制御してラジオストームが無かったら、何ら問題がない。

しかし、業務シーンが複雑で、前は仮想機に収納し、現在は容器の収納するようだったら、このような業務はネットワークにとって難しく、各回線の業務のために対策を講じることができない。業務移転或いはtrouble shootingの場合、運転保守者にとって非常に難しく、調整することができない。前はPBRを作成する時に、静態ルーターを作成し、多くともハブルーターをつけたらよかった。クラウドネットワーク環境では、状況が全然違って、一つのレンタル先の下に無数の仮想機があって、中で無数のアプリケーションが運転され、すべての流れの方向がめちゃくちゃである。この場合、伝統的な方式で行くと、どうしようもない。だから、SDNにする必要がある。

TungstenFabric（以下、TFという）は確かに優秀である、一部の問題がある。OVSDB交換機を完全にサポートし、TFとの互換性もよい。Openflowがだめだというわけではなく、流表の方法でも行けるが、そうするとちょっとややこしい。

SDSのOpenStackとK8sは、底層でTFを通じるSDN技術サポートラインである。2015年、OpenContrail時代の時、K8sは開放されたばかりで、我々は容器に基づく方法を提案した。仮想機の方法で運転保守、容量拡張、移転にデメリットがあったら、以降の業務はなかなか保証できない。その時、OpenStackは早い段階のもので、基本的に自分で統一して配置していた。Juniper　networksと連携して開発する時、OpenContrailと一緒に配置していた。

なお、SDSはデータセンターで、提供するのが伝統的なhostingで、クラウドに移転することを考えた。クラウドコンピューティングで当社は伝統的なVLANよりSDN技術を使った。では、ユーザーがクラウドサービスを利用する時にどのようにつなげるか。VLANをもう一つ開設し、マッピングするわけにはいかない。それは難しい。

また、ユーザーのサーバー機室の複数の業務シーンを、ある独立のサービスで試す形を取らずに、クラウドコンピューティングのoverlayネットワークにつなげるか。

ここで、VLANマッピングの問題を解決した。ユーザーに特別ラインを提供できない前提で、VLANネットワークを変える必要がある。これは不現実的でない。だから、大量の二次開発を行なった。OpenStackでもOpenShiftでも、オープンコミュニティーのバージョンはシングルノードであり、本格に実際シーンに応用するなら、少なくとも複数ノードを保証する必要がある。コミュニティー版のものは生産環境に使うには、TFとのつながりを含め、多くの二次開発をしなければならない。

開発及び調査研究においてあった8類のネットワーク問題

下記は開発と調査研究であった実際の問題点で、当社自身のものもあれば、ユーザーの応用シーンのものもある。

1、OpenstackNeutron OVSの拡張性が悪く、安定性が低い。Neutronは安定性が悪く、実測したことがあるが、2500個の仮想機をオンにすると、わけわからない振れが出て、すべてクラッシュを引き起こしてしまうと分かる。オリジナルのNeutronに対し、慎重な態度を取っている。

2、K8sのFannel&Calcioは完全にUser Case及び複数regionの設計に適応するわけではない。K8sはシングル業務のみを実現するなら、オリジナルのFlannel或いはCalicoで解決できる。Calicoは複数データセンターの複数任務にサポートを提供しない。Calicoは現在、K8sオープンソース環境でもっとも多く使われている。

3、OKD（openshift Origin）のOVSがOpenstackに通じるかに対し、疑問がある。またVNFとCNFと共存できるかは、不明である。OpenShiftにはOVSがあるが、OpenStackに通じるかは疑問がある。最後に検証してみた結果、通じなくて、まったくの二つのシステムだと分かった。

4、仮想機ネットワークと容器ネットワークと、二重相互アクセスし、効率を高めるか。またVNF とCNFと共存できるかは、不明である。なぜ、仮想機ネットワークが容器ネットワークにアクセスする必要があるのか。我々から見れば、極めて不合理である。しかし、金融業界或いは電子商取引業界では、一部の業務は仮想機で行われており、一部のユーザーはすでに商業ソフトウェアを買っており、或いは一部のユーザーは開発能力があって、一部の業務を容器に入れている。

前は、我々は仮想機で負荷分散をしていた。しかし、容器で一つのNodeで無数のportを解決できる。多くの登録機メカニズムでportalできなく、ネットワークを区分に分けて代理アクセスするわけにはいかなく、彼らは、これは非常に難しく思っており、この問題を解決できる可能性があるかどうかをやってみた。試行錯誤して、VNFとCNFがOpenStack仮想機での相互アクセスの問題を解決できた。管理ネットワークで相互アクセスを実現したのである。

5、データセンター内のユーザーにとって、クラウドサービスのHostingとBMSをネットワーク平面でアクセス管理させるか。仮想機ネットワークと容器ネットワークの二重相互アクセスは、TF4.0バージョンの時に、ラベルに基づく方式で行われていた。使えるが、不便であった。5.1バージョンになって、Portalでこれを選択肢として取り上げていなく、毎回仮想機と容器を調べて、対応させ、この操作は非常に面倒くさい。二次開発を試したことがあるが、しんどい。可能であれば、この二つを一緒にすると、便利に管理できるだろう。

6．ソフトウェアで定義されているFW、LBは、どのようにしてシーンを跨ぐ環境で業務実行できるか（特にこれを統一のinternetとする）。ソフトウェアで定義されているFW、LBは、どのようにしてシーンを跨ぐ環境で業務実行できるか。大部分のユーザーシーンで、商業ソフトウェアが使われている。いろんなブランドがある。自分もimageを提供している。仮想機に入れる場合、それぞれのfeatureがある。どのようにしてTFに通じさせるか。二次開発しなければならないに違いない。しかし、現在の状況から見れば、TFだけが可能性があるが、ほかは難しそうである。

7、各メーカーから提供されたそれぞれ違うVPCに対し、統一アクセス管理を行なうか。VPCという問題は、我々の理解では、TFのVPCは現在国内のSDNwebと理解して合理的で、二区分のVPNでトンネルを作る。しかし、パブリッククラウドの仮想機をコントロールするには、不可能そうである。たとえもらっても、結局やめるだろう。バージョンの更新問題が解決できないからである。こんなことをやる人がいないからである。メリットとして、Portalがあって、業務全体の実際状況が見られるのである。

8、それぞれ機能しているネットワークは、どのようにして有効に運営し、故障排除するか。ちょっと不満を言うが、TFはOpenStackのネットワーク拡張と安定性の問題を解決できたが、ランカードに厳しい。一部の特殊な応用シーンで、例えばVDIに適用するIDPプロトコルで、IntelとBroadcomのランカードがそうやさしくないと気付いた。

OpenStackに比べ、いまでは、TFとOpenShiftを接続するのがより難しい。OpenShiftオープンソースのOKD自身に一部の問題がある。なお、TFとOpenShift或いはK8sだけと一緒にインストールして、簡単な応用ではなんら問題がないが、ラベル、応用、ルーターゲート、業務編集などと、複数の業務チェーンを運転すると、全プロセスで問題が出てくる。

確かに、TFは上記で言ったように、OpenShiftに対するサポートがほかのオープンソースソフトウェア或いは商業ソフトウェアよりずっとよく、少なくとも、TFで二次開発する曙光が見える。

サービスチェーンについて、ポートとマッチできたら、よりよくなる。ネットワークのプロパティに干渉しない。ある特定のシーンで比較的に複雑になる。

複数クラウド環境で、すでにAWSとAzureにマッチできた。国際化企業の実際の応用シーンにもマッチできる。一部VPC仮想プライベートクラウドチャンネルがある国内のパブリッククラウドにもマッチできる。この進歩が取れて、業界で初である。

DPDK及びsmartNICに対応する環境で、実測したことがあるが、OpenStackの黙認のkernel環境で、セキュリティメーカーのソフトウェア基準にほぼ達成できない。DPDKを使用してこそ、標準値を達成できる。しかし、DPDKはIntelの専属物であり、実際シーンで一部の問題に遭うと、運転できるアプリもあれば、運転できないものもある。だから、DPDKを使うなら、自己の使用シーンに合わせて検討する必要がある。

TFはRESTのようなAPIを提供する。だから、たとえ自分でCMPを作っても、バックエンドのパラメーターを呼び出すのが比較的にやさしいが、APIに関するファイルがちょっと乱れである。

今まで当社は真剣にクラウドコンピューティングに取り組んできている。2014年からいままで磨いており、SDS　VDCクラウドプラットフォームはユーザーの立場に立ってユーザーの実例を現している。

TFバックエンドのAPIをフロントエンドに移す。

　　● 各ユーザーは自分の策略で調整することができる。

　　● 複数クラウドでCMPを管理する時代に入って、応用シーンで15分間以内に立ち上がらない場合、失敗である。むろん第三者の力を借りるとは想像できない。

　　● 多くの権限をユーザーにオープンする。

我々のPaaSバックエンドはOpenShiftで、PaaSプラットフォームに基づくすべての業務はフロントエンドでやり直されている。TFのOpenShiftに対する機能を含め、フロントエンドに置いてある。TF内部は監視でき、非常に原始的なSNMPの方式で収集するのが完全に必要でない。

いま、SDSのプラットフォームはここまでできている。TFを選んだのはプロトコルが比較的に標準である。BGPVPNで解決できる。プライベートプロトコルには抵抗がある。一部の同業他社はいつもなんでも一つにまとめようとしているが、結局は不可能で、やはりオープン式が人気があるのである。

VXLANについて、実際使ってみて、kernel方式にすると、量が大きいと、ロスが非常に大きい。特にVXLANで特別に最適化されていない交換機或いはネットワークカードに対し、直接性能のロスが約30％くらいである。

TF全体から見れば、違うプラットフォーム、違うネットワークの特性をまとめて管理できているが、容器と仮想機には一定の手動作業量がある。TFでこの問題をも解決できたら何よりである。なお、TFはOpenStackとOpenShiftの認証システムでちょっと食い違いがある。

ここ数年、悩まされているのがサポートが少ないことである。オープンソースでも公式でも、インストールに偏っており、trouble shootingが一部あるが、実際の応用シーンに対するものが乏しい。クラウドコンピューティングをやる場合、仮想機と違って、OpenStackを使っても使わなくても構わないが、KVMで解決できる。だから、クラウドコンピューティングは仮想化ではなく、中には一定の業務ロジックがあり、プラットフォームで、実際利用するユーザーの業務に多くのサポートを提供しないといけないと意味する。

我々がTFを使い始めたのは早かった。3.2版から使い始め、4.0版で正式につなぎ始めた。自分の業務ロジックがあって、一定の開発能力があって、TFに基づいて自分に属する良い製品を作ることができると信じている。TFのプログラミング可能性が強く、汎用性も強い。100点満点なら、TFに80点を付ける。残りの20点はサポート面にある。

以上は私が実際の応用シーンから、開発まであった各種のことを紹介し、問題提起をさせていただいた。

ご清聴ありがとうございました（終わり）