SDS　PaaSクラウドプラットフォームは、DockerとK8Sに基づいて構築され、OKDを基礎として二次開発されたプラットフォームです。このなかに内部アプリケーション市場が構築されており、ミドルウェア、データベース、自動化プロセスを提供し、高速にアプリケーションの構築、アプリケーションの開発から、テスト、オンラインプロセスまでを容器化・配置貫通することができます。

直観で見える化プラットフォームサービスを利用し、

お客様に未曾有の簡単さ、便利さと効率をもたらしてきます。

一　見える化デスクトッププラットフォーム

❶ 開発、テスト、運転保守は、一つのプラットフォームで協力し合って行ない、効率向上できます▼

❷ pod、service、deploymesの構築にしても、状態があるデータベースに基づくstateful setsにしても、気軽で便利にできます▼。

❸ なお、モニタリングコンポーネントはgrafana及びログPrometheusを提供し、ユーザーに運転保守及びモニタリング管理を提供します▼。

❹なお、モニタリングコンポーネントはgrafana及びログPrometheusを提供し、ユーザーに運転保守及びモニタリング管理を提供します▼。

 ❺ 当社は比較的に完全なcatalogを提供し、お客様にお選びの上、使っていただけます。▼。

二 SaaSレベルネットワークサポート

従来のPaaSプラットフォームと違うところは、最下層ネットワークのサポートにあります。SDSは2014年から、opencontrailというSDN技術に触れ始め、目下、LinuxのCNCFにインキュベーションプロジェクトとして傘下に収められて、tungsten fabricと名付けられ、商業版はjuniper contrailと言います。SDSが目下使っているのはtungsten fabricのR2003.1.40バージョンです。

❶ PaaSネットワーク▼。

❷ 完全なトポロジー関係▼。

❸ モニタリングがはっきりしている▼。

❹ 細かいところが完全です▼。

❺PaaSの一部の応用シーンは、ネットワークに対し、高い要求があり、複雑なアプリケーションの機能が求められていますが、これらはSDNにとって簡単に実現できます。▼。

❻ 当社はネットワークによって完全に違う機能を提供することができます。例えば、共有、外部ルーターモード、パススルー、複数サービスチェーン、モニタリング及びリバースパス検出などの機能があり、また、一部の特別な環境、例えばマルチキャストについても、特別なサポートがあります。▼。

❼ 当社のクラウドコンピューティングネットワークで使われているのがIP-CLOSアーキテクチャーで、つまりunderlayとoverlayに分かれているネットワーク構造なので、Undelayにおいて、BGPプロトコルを使って相互接続します。この方式を使うメリットとし、下層ネットワークがどのように変わっても、上層のoverlayネットワークにとって、いかなる感知がないので、テナントのネットワークのセキュリティーと安定を十分に保障でき、データ、ルーターからの漏れなどを心配する必要がありません。但し、お客様は業務シーンの必要な場合、強制的にルーターからの漏れを行なうことができます。▼。

三 L2＆L3ネットワーク

Overlayネットワークにおいて、L2とL3の転送モードを提供し、パッケージモードは、VXLAN、mpls over udp、mpls over GREを提供します。二層ネットワークで、VXLAN東西方向モードを使い、三層の場合、VXLANの上にMPLSプロトコルの南北方向のUDP或いはGREをパッケージすると理解できます。UDPモードはどっちかというとECMPに基づく複数パス負荷環境に適します。

❶ モニタリングルーター▼。

 

❷ モニタリングプロトコル▼。

 

❸ BGP隣り関係▼。

 

クラウドコンピューティングネットワークのトラブルシューティングは往々して辛いこととなりますが、われわれのクラウド環境で、ネットワークの問題の判定は非常に正確にできます。PaaS或いはK8S環境で、network或いはnamespaceによってきわめて細かいルーター情報及びフロー情報を表示できます。

やさしいPortalインターフェース

使用者がより簡単に操作できるように、SDSは、中間層とフロント再開発を積み重ねることによって、特色がある誘導式プラットフォームのportalインターフェースを作り、お客様にPaaS能力サービスを提供します。そしてお客様が、効率的な管理を実現し、よりよい体験ができるようにさせます。

なお、overlay層で、IaaSとPaaSの間で通信する必要がある場合、ネットワークに非常に高い要求がありますが、どのように実現させるのでしょうか。

1. 策略ルーターで相互アクセスを実現

黙認のPodネットワークそのものがVNです。だから、TFVNとして、Openstackで使えます。だから、当該ネットワークで仮想機を新規作成し、当該仮想機は明らかにPodに接続できます。これは可能なことですが、もちろん、理知がない者はこれを追求することがあります。反対に、VMにサービスと「対話」させるのがより有意義なことです。一番目の例にTFネットワーク策略が使われています。転換ネットワーク策略で、（L4のところで）どういうトラフィックがVNの間で伝達できるかを定義しました。例えば、策略はいかなるudp / tcp / icmpトラフィックしかを許さないかもしれません……全部許します。それから、この策略で同時にVNAとVNBに応用する可能性があります。この結果、VNAとVNBは相互通信できます。この種類の通信を許すために、ネットワーク策略は二つのVNの間のルーターからの漏れを引き起こすことがあります。こうして、VNAはVNBに到達するかを知り、Openstack Routerのようなほかの対象が必要ではありません。これは一種の可能な状況です。

 

可能な状況：

•     我々のサービスで、外部VNから外部IPを取得する
•     お客様が構築された仮想ネットワークでVMが発生する
•     二つのVNはすべてネットワークを使った（通す必要があるトラフィックが許される）
•     この結果、VMは当該サービスにアクセスできる。

 

2. L3VPNルーターで相互アクセスする

外部ネットワークで外部IPが分配されています。だから、VMを同じネットワークに接続しないわけです。

 

VMは、同じVNのサービスにアクセスできます。簡単だということは、ベストチョイスではないかもしれませんが、VNとVMが同じ汎用の仮想ネットワーク層を持つために、どのようにして柔軟性とオプションをもたらしてくるかを説明しました。

仮想ネットワークは、VRFにすぎません。つまりL3VPNから知ったそのVRFです。vRouterはよく知られているPEとみなされると意味します。この例えは現実と別にかけ離れていません。VRF（VN）をロードするPEとして、vRouterは、ルーター目標をこれらのVRF（VN）に分配できます。ネットワーク策略を制定することを除き、我々はただ、前の例で見た二つのVNのために同じルーター目標を分配したいだけかもしれません。こうして、我々はルーターからの漏れを実現します。vRouterはPEで、VRFは、ルーター目標でルーターを導入します。よい古いルーターです。

 

3. 外部Gatewayハードウェイ（PNF）で相互アクセスする

この状況下で実行可能ですが、時には理想的ではないかもしれません。例えば、あなたはSDN　GWでVM VNを外部転換に転換する場合。SDN　GWもPEです。だから、マッチルーター目標があるVRFがあります。この状況下にXです。この設定で、SDN　GWで、私は、VN、外部fipネットワークとVMネットワークからのルーターがあります。これらのルーターは同じRTがあります。これは、SDN　GWのVRFで見たもので、bgpからルーターを導入/コピーします。l3vpn.0表。隠して、我々は外部fipネットワークを外に持っていきます。たとえ最初にVMネットワークだけほしかったでも。

これは、あくまでも凡例にすぎなく、用例が一個或いはもう一個のシーンに適合するかを表示します。よいことに、柔軟性があることです。だから、状況によって適切なソリューションを出せます。さっき言ったように、この用例は現在はっきりしています。外部ネットワークVNにルーター目標を分配し、SDN　GWにマッチするVRFがあるのがコツです。

可能な状況：

•     SDN GWとTF制御器が対話するBGP
•     TF制御器からルーター目標Xがあるfipネットワークルーターを送信する
•     SDN　GWはルーターをbgp.l3vpn.0表に取付け、ルーター目標によってVRFにコピーする
•     SDN　GWは運営サービスPodのコンピューティングノードへ動態MPLSoUDPトンネルを構築する

 

複数のMPLSoUDPトンネルは、サービスの後ろのPodが違うプロセス（コンピューティングノード）で運転しているという意味ですが、複数のECMPパスがあるのを望みますか。これらはすべて可能な用例ですか。

もちろん違います。しかし、われわれは多くのキーコンセプトを見ました。例えば、空間隔離、カスタマイズPodネットワーク、カスタマイズサービスネットワーク、外部ネットワーク、ネットワーク策略或いはルーター目標で行うルーター漏れなど。今になって、これらの部分を結び付け、私たちの必要な難題が得られると意識しました。新しい用例を作って我々が面する違う状況を支持するのを試してみます。

最後に、SDSはクラウドコンピューティング市場で、コツコツとする追随者ですが、オペレーターとデータセンタープロバイダーの出身なので、ネットワークに対する理解が、クラウド企業より深いから、SDSのクラウドプラットフォームは、各優秀なオープンソースプラットフォームをベースに、ちょっと違うところを付け加えており、企業の皆様に複雑な環境で少しでも便利になるようにさせようと思うと強調したいです。

 

作者についての紹介：銭誉　　SDSクラウドコンピューティング事業部総経理

 

クラウドコンピューティング事業部について

SDSクラウドコンピューティング事業部は2020年1月2日に設立。事業部は、SDSの元のクラウドコンピューティング開発部の過去五年間の研究成果を踏襲し、先進的な資源と優秀な人材を導入し、自主開発の革新型クラウドサービスを迅速に上げ、「企業マルチクラウド管理、簡単で効率的な運転保守」のクラウド管理プラットフォームの構築に力を入れます。

事業部で研究開発された、知的財産権があるSDSクラウドは、ビッグデータ、人工知能、企業のデジタル化モデルチェンジなどの多くの分野の発展に寄与しています。