By
Translated by
ネットワーク機器の分野で最もホットなマーケティング用語は「分離型（ディスアグリゲーション）」と「クラウド」であることは間違いありませんが、よく言われるように口は災いの元です。実際、ほとんどのベンダーがこの2つの言葉を使用していますが、それを本当に実現しているベンダーは DriveNets だけなのです。DriveNets の特徴はオーケストレーションというコンセプトにあります。
「分離型」ネットワークには、さまざまな意味があります。 ルーター・ベンダーは、ソフトウェアとハードウェアを別々に販売し、ソフトウェアを定期的なサブスクリプションによる収益ストリームに変えられた場合に分離という言葉を用います。しかしこれだけではユーザーにとってあまりメリットは感じられません。より価値の高い「分離」とは、既製のホワイトボックス・スイッチのクラスタを用いて、エッジからコアまでのルーター「ファミリー」を作ることであり、DriveNets Network Cloud はそれが可能です。
ドライブネッツ ネットワーク オペレーティング システム (DNOS)
このような分離における最初のステップは、すべてのホワイトボックスを個別のモノリシックルーターのように見せないことです。また、それらを様々なルーター「モデル」に集約するプロセスは、多くの特別なスキルと多くの運用オーバーヘッドを必要としないことが望ましいです。我々が提供する分離されたクラスタ、すなわちホワイトボックス・スイッチの集合体は、クラウドコンピューティングのリソースプールのように、一種のクラスタリソースプールとなります。
しかし、実際はクラウドのリソースプールは一纏まりに接続されたサーバー群に過ぎないのに、なぜ統合された単一の仮想ホストとなることが可能なのでしょうか。クラウドコンピューティングのような分離型ネットワークを可能にするキーは具体的にはオーケストレーションです。クラウドコンピューティングでは、コンテナ化されたソフトウェアのマイクロ機能をハードウェアホストに割り当てる作業をオーケストレーションと言いますが、「分離されたルーター」の編成に必要なのもまたオーケストレーションなのです。
DriveNetsにおけるオーケストレーション
DriveNets の「ネットワーク・クラウド・アーキテクチャ」では、オーケストレーションは「DNOR(DriveNets Network Orchestrator)」が担い、DriveNets はオーケストレーションを文字通り次のレベルに引き上げるために DNOR のバージョン 2.0 をリリースしたばかりです。はじめに、DriveNets のネットワーククラウドでは、ネットワーク事業者がホワイトボックスのハードウェアとマイクロ機能のソフトウェアから特定のルーターを構成することを可能にしました。これは最初のステップであり、DNOR 2.0 は今、2番目のステップを踏み出しています。
DNORオ ーケストレーターがなければ、分離された「クラスタ」ルータはファブリックで接続された一連のホワイトボックス・スイッチとソフトウェアコンポーネントに過ぎません。すべてのハードウェアとソフトウェアの要素は個別に管理されなければならず、すべてのハードウェア/ソフトウェアルータ インスタンスは、他のルータや管理システムからは別個のルータのように見えます。言うまでもなく、システムの複雑さは、その中の相互に接続し合う要素数に比例するので、これでは運用面で拡張性がありません。設備投資の削減よりも、運用コストの削減を優先させることになるでしょう。
DNOR オーケストレーターにおいては、分離されたクラスタである DriveNets Network Cloud はあらゆる点で単一のルーターのように見えるようになります。さらに、これは分離された要素の追跡を失うことなく行われ、オーケストレーションはクラスタやサードパーティのサービス要素にさえも拡張することができます。オーケストレーションは DNOR によってホワイトボックスのクラスタをマイクロ機能で編成された中央制御インテリジェンスを持つラインカードのシャーシに見せかけます。DriveNets Network Cloud の構成がどれほど大きく、複雑であっても、またホワイトボックスがいくつ使われていても、クラスタは1台のデバイスのように接続され管理されます。
DriveNets Network Cloudで は、コントロールプレーンとデータプレーンが分離されており、コントロールプレーンはクラウドネイティブなマイクロ機能ビスによって実装されています。 これらは DNOR オーケストレーターによって協調動作し、トランク/ポートインターフェースの制御プロトコルと管理インターフェースを作成します。そのため、たとえば 12 台のホワイトボックス・スイッチを12台のルーターとして見せるのではなく、DriveNets はそれを1台のルーターとしてネットワーク内で見せることができるのです。
コントロールプレーンのマイクロ機能のオーケストレーションを通じて、DNOR は Network Cloud がどのように機能するかだけでなく、どのように見えるかも管理します。DNOR の中核を成すのは、クラウドの初期構成を定義し、追加、拡張、交換が行われるたびに維持されるクラスタモデルです。このモデルではクラスタは仮想センターである DNOR によって制御されることになります。初期構成から負荷のかかるスケーリングや障害対応まで、Network Cloud のライフサイクルのあらゆるステージが DNOR によって管理されます。
クラスターモデル・ビューからのネットワーク管理
クラスターモデル・ビューにより、DNOR はすべてのインターフェイスを統合し、ネットワーク内の他のすべてのルータが Network Cloud クラスタを単一のデバイスとして認識し、単一のデバイスとして管理できるようにすることができます。このモデルにより、管理者は Network Cloud を解析し、単一のルータ・ビューから、すべてのマイクロ機能、すべてのコンテナ、すべてのホワイトボックス、すべてのインターフェイスに至るまで理解することができます。ソフトウェアとハードウェア、機能とサービス間の関係は、このように深く掘り下げていくことで完全に見えてきますが、ハイレベルな管理ツールやプラクティスに干渉することは決してありません。
Network Cloud d内の細部にまで潜ることができるのと同様に、単一クラスターのビューからネットワーク内のすべての Network Cloud のビューまで登っていくこともできます。これにより、ネットワーク全体の動作に関する相関的なインサイトや、従来の管理ビューと並行してリソースと状態をクラウドのように統合したリソース状態のビューを提供することができます。一つのビューがすべてを支配する―正真正銘の事実。
目を引くネットワークのインサイト
ハードウェアとソフトウェアの状態の詳細、SLA に関連する KPI、アラームと障害表示、障害の相関と根本原因の分析、さらには是正措置の提案まで、DNOR と関連する DNOS オペレーティングシステムから得られるインサイトは目を見張ります。これらのインサイトにより、従来のモノリシックなルーターと比較して、実際的に信頼性と可用性を向上させ、運用コストを削減することができます。
DNOR オーケストレーションは、各 Network Cloud が独自の SLA に準拠するように管理し、新しいファームウェア、オペレーティングシステムソフトウェア、DriveNets Network Cloud ソフトウェア、さらにはDriveNets の豊富な API を介して Network Cloud と対話するサードパーティの拡張機能の展開も管理します。つまり、コンテンツ配信機能や 4G/5G ユーザープレーン インターフェース機能など、基本的な接続サービスの拡張を各 Network Cloud に密結合し、ネットワーク内のすべてのNetwork Cloud にわたって調整することができるのです。
オーケストレーションによるクラウドネイティブの実現
オーケストレーションがなければ、クラウドネイティブ・コンピューティングは効率的であるどころか、使い物にさえなりません。オーケストレーションがなければ、分離されたネットワークは、分離されたソフトウェアとハードウェアから作られたネットワークに過ぎません。しかし、DriveNets Network Cloud はDNOR 2.0 オーケストレーションによって、すでに大規模なキャリアネットワークでそれを実現しています。それはディスアグリゲーションを次のレベルだけでなく、正しいレベルまで引き上げているのです。
