ハイパーコンバージェンス？クラウドネットワーク統合?統合に関する考察

[[405083]]

この記事はWeChatの公開アカウント「zartbot」から転載したもので、著者はZartbotのネットワークケーブルプライヤーです。この記事を転載する場合はzartbot公式アカウントまでご連絡ください。

数年前のハイパーコンバージェンスから今日のクラウドネットワークコンバージェンスまで、誰もがコンバージェンスについて話しているようですが、最も基本的な観点からコンバージェンスとは何かについて考えている人は誰もいません。

昨日、他の統合について説明した PPT のページを見ましたが、この要約は非常に良かったです。

次に、これらのトピックを徐々に拡張して、デジタルトランスフォーメーションにおける統合をどのように行うべきかについて説明します。統合全体は、ビジネス中心の視点でトップダウンで行われる必要があります。

ビジネス統合

ビジネス コンバージェンスは、多くの MBA コースで議論されるトピックであり、情報技術を使用して企業の研究開発設計、生産と製造、運用管理、マーケティング、リスク管理などのさまざまなビジネス ラインを統合する、いわゆるデジタル トランスフォーメーションです。より代表的なものとしては、新しいサプライチェーン管理、オンラインマーケティング、デジタルリスク管理などのシステムの出現が挙げられます。

サービス統合

次に、ビジネス統合から始めて、ビジネスラインをサポートするための実現可能なサービス アーキテクチャを提供する必要があります。これが、ミドルプラットフォームアーキテクチャの出現の理由です。本質は、ミドルプラットフォームの出現はビジネスニーズであるが、ミドルプラットフォームが合理的であるかどうかは、実はその逆であるということです。ビジネスの観点から、サービス統合が必要かどうか。そのため、多くの企業では長年にわたり大規模なミドルプラットフォームの開発を行ってきましたが、それが企業全体の発展のボトルネックとなっていました。これは、多くのマネージャーが盲目的に中間プラットフォームに権限を与えていることが原因です。もちろん、技術的な観点からもそのような傾向はあります。マイクロサービスとサービスメッシュ アーキテクチャの出現は、本質的にはサービス統合の結果です。

インフラストラクチャの統合

次はインフラストラクチャの統合です。SDN からハイパーコンバージェンス、いわゆる SD-Storage、最近の IaC (Infra as Code)、そしてソフトウェア定義インフラストラクチャへと進化しました。しかし、この時点で、サーバー (コンピューティングまたはアプリケーション) とネットワークの統合に大きなギャップが生じています。ハイパーコンバージェンスの成功は、コンピューティングとストレージがサーバー上で行われることとして理解できますが、これはチームの内部的な問題です。ネットワークとサーバーの統合は非常に面倒なプロセスです。スマートネットワークカードやDPUを製造している企業の多くは売上が振るわず、スマートネットワークカードを導入しているクラウドもさまざまな内部対立に直面しています。ビジネス統合要件とサービス統合要件はよく一致していますが、MPLS などの古いドライバーがほぼ覆される可能性もあります... 問題は何でしょうか?

ACI の成功は、TOR オーバーレイがホストとネットワーク間の適切な分割ポイントを見つけたことにあります。 HostOverlay の後、スマート ネットワーク カードを誰が制御するのでしょうか?クラウド上の VPC を制御するのは誰ですか?これは組織構造によって引き起こされる問題であり、ネットワーク チームとアプリケーション チーム間の対立がさらに悪化し、互いに対立し始めます。たとえば、ネットワーク チームが NFV を構築し、クラウド上に SDWAN を展開する必要がある場合、通常、ネットワーク チームはコンピューティング チームからリソースを申請する必要があります。結局のところ、クラウド上のアカウントと課金はコンピューティング チームに属します。したがって、コンピューティング チームは通常、クラウドによって提供される SDWAN ソリューションを選択し、ネットワーク チームはプライベート クラウド ネットワーク アーキテクチャと同型のソリューションを選択します。マルチクラウドの相互接続で問題が発生すると、コンピューティング チームはネットワーク チームの支援を必要とし、特に事故が発生すると、両者の間の対立が徐々に増加し、相互非難も増えます。

実際のところ、本質は、管理ドメインにおける既存のスマート ネットワーク カードと SDWAN ソリューションが、2 つのチームを統合するための適切な分割ポイント、または 3 番目のブリッジ チームを構築する可能性を提供していないことです。

これらの問題はプロトコルに統合する必要があります。

プロトコルの統合

2 つのチームの統合は通常、両チーム間のプロトコルとインターフェースの標準化によって実現されます。 JSON および gRPC プロトコルは、アプリケーション層で優れた API 統合を実現していますが、ネットワークについてはどうでしょうか? yang/netconf Openflow のようなものはありますが、SDX は最終的にはアプリケーションとうまく統合されません。基本的に、ネットワーク チームはレイヤー 3 より下の問題について考え、アプリケーション チームはレイヤー 7 より上の問題について考えます。それぞれに独自のドメイン固有言語があり、アプリケーションは P4 および BGP TLV 拡張を記述でき、ネットワーク開発者は C を記述して Service-Mesh に取り組むことができます。これらはすべてある種のスケールアップ手法ですが、スケールアウトのアプローチはあるのでしょうか?これはプロトコルの融合であり、それぞれが一歩後退してレイヤー 4 上に伝送ネットワークを構築することを意味します。

最も典型的な例は、さまざまな人気のあるオンライン会議サービスです。通常、アプリケーションは RTN と CDN を実行するために独自のチームを形成します。これが進化の傾向です。管理面では、アプリケーションの DevOps と連携する小規模なアプリケーション中心の SecOps および NetOps チームが徐々に登場します。このような小規模なチームは、アプリケーションとネットワークの融合点となりますが、同時に、このようなチームにはハンドルが必要であり、つまり、対応するプロトコル スタックに対する権限を付与される必要があります。

目標は当然トランスポート層に設定されます。どのクラウドもいわゆる高性能ネットワーク部門を設置していますが、この上位レベルの要求に応えるには、より独立したチームが必要だと考えた人は誰もいません。トランスポートプロトコルはSwiftですか? NDP? HPCC? RoCE?クイック？それともSRv6?アプリケーションの場合、Socket を呼び出す方法しか知りません...

したがって、すべてはソケット上でのみ発生します。これは、Ruta を設計する際に優先的に考慮した問題でもあります。コントロール プレーンが BGP を使用する場合、ネットワーク リソースを抽象化してアプリケーションに公開したり、アプリケーションに適した方法でスケジュールしたりすることはできません。したがって、コントロール プレーンは、アプリケーションの使いやすさに対応するために ETCD を使用します。データ側では、デフォルト ゲートウェイに加えて、ペイロードにいくつかのソケット配列 (つまり、セグメント リスト) を追加することによっても構築できることをアプリケーションに知らせます。これにより、アプリケーションはネットワークに適応し、パスを計算してトラフィックを制御するためにいくつかの変更を加え、セグメント ルーティングを学習できるようになります。

ただし、ネットワークではアプリケーションの観点も考慮し、複雑な uSID および gSID エンコード方式ではなく、アプリケーションが理解できる方法でエンコードする必要があります。

ソフトウェアとハ​​ードウェアの統合

最後のステップは、インフラストラクチャ統合の鍵でもあります。結局のところ、ソフトウェア定義インフラの中核は、遅かれ早かれソフトウェアとハ​​ードウェアの統合に触れることになるでしょう。 P4 が業界で大きな注目を集め、最終的に Barefoot が成功裏に導入された理由は、P4 が本質的に Verilog と C 間の DSL であるためです。また、ソフトウェアとハ​​ードウェアのバランスも良好です。しかし、ここで疑問が生じます。アプリケーション開発者が gcc を使用する前に NDA に署名するのを見たことがありますか?彼らはただトラブルを招いているだけです...

不満はさておき、プログラム可能なハードウェア自体の需要は今後も増加し続けるでしょう。必ずしも FPGA または P4 MAU である必要はありません。解決策は多数ありますが、最終的には同型性の問題を考慮する必要があります。エッジとクラウドの基盤レベルで同型性をどのように実現するかが、統合の鍵となります。