これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
今回からは、2021年に公開された論文「Orion: Google's Software-Defined Networking Control Plane」に基づいて、Googleのデータセンターに導入された分散型のSDNコントローラー「Orion」を紹介していきます。Googleのネットワークシステムでは、ネットワーク機器をソフトウェアで制御するSDNの技術が用いられており、Orionは、データセンターネットワーク「Jupyter」とグローバルネットワーク「B4」を制御する第2世代のSDNコントローラーになります。
はじめに、「Jupyter」と「B4」の概要を説明しておきます。Jupyterは、Googleのデータセンター内のサーバーを相互接続するL2レイヤーのネットワークシステムです。クラスター内のサーバーをメッシュ状のネットワークで接続して、複数経路による負荷分散を行う「Closトポロジー」を採用しており、サーバー間の接続経路をソフトウェアで計算して最適化します。詳しくは、第13回からの記事を参照してください。一方、B4は、世界各地にあるGoogleのデータセンターを相互接続するグローバルネットワークのシステムです。インターネットからは独立した、Google専用のプライベートなネットワーク回線を利用しています。トラフィックの優先度に応じてグローバルな経路を最適化する、トラフィックエンジニアリングの仕組みが導入されており、ここでもまた、ソフトウェアによる経路の最適化が行われます。こちらは、第17回の記事に詳しい解説があります。
これらのネットワークを制御するSDNコントローラーは、当初は、すべての機能を1つのソフトウェアで実装するモノリシックなアプリケーションとして開発されていました。しかしながら、モノリシックなアプリケーションは、一般に、機能追加に時間がかかるというデメリットがあります。そこで、Orionでは、より迅速に機能追加ができるよう、独立した複数のサービスが連携するマイクロサービスアーキテクチャーによる実装が行われました。冒頭の論文によると、JupyterとB4の新しいSDNコントローラーとしてOrionが導入されてから4年以上が経過しており、2週間に1度の頻度でのソフトウェアのアップデートを実現しただけではなく、ソフトウェアの継続的な改善の結果として、16倍のスケーラビリティの向上と、50倍（Jupyterの場合）、もしくは、100倍（B4の場合）の可用性の向上（停止時間の削減）を実現したということです。
Orionの最大の特徴は、「インテントベースの管理システム」にあります。Orionを構成するマイクロサービスは、NIB（Network Information Base）と呼ばれる構成情報データベースを介して連携するようになっており、あるサービスが「希望する状態」をNIBに書き込むと、他のサービスがその状態を実現するための処理を行います。この時、Orionを利用する最上位のアプリケーションは、個々のネットワーク機器の状態を個別に指定するのではなく、「クラスターAをドレインする（クラスターAに対する新規のネットワークパケットの流入を停止する）」と言ったハイレベルな状態をNIBに書き込みます。すると、Orionを構成するサービスにより、このために必要な経路変更が決定されて、新しい経路情報がNIBに書き込まれます。続いて、この新しい経路を実現するために必要な個々のネットワーク機器の設定がNIBに書き込まれます。最後に、これらの設定が実際のネットワーク機器に反映されて、「クラスターAをドレインする」という処理が完了します。
このように、複数のサービスが連携して段階的に処理を進めていきますが、個々のサービスは、NIBに書き込まれた「あるべき状態」と実際のネットワークの状態を比較して、その差異を埋めるように動作するので、具体的な設定手順をアプリケーション側で指定するよりも、より安全に状態変更ができます。論文の中では、「クラスターAをドレインする」という処理と「クラスターAに新たなリンクを追加する」という処理が同時に行われる例が紹介されています。ドレインの処理中（もしくはドレインが完了した後）にリンクの追加が行われた場合、手続きベースの処理では、追加されたリンクからのパケットの流入が停止されない恐れがあります。しかしながら、インテントベースのシステムであれば、追加されたリンクからパケットが流入できる状態に対して、「クラスターAをドレインする」という「あるべき状態」との差異が検出されて、このリンクも自動的にドレイン処理の対象に追加されることになります。
Orionのアーキテクチャーは、図1のように整理することができます。最上段の「Orion App」、および、「Routing Engine」が、Orionを使用するアプリケーションになります。これらのアプリケーションがNIBに「希望する状態」を書き込むと、その下にあるFlow Managerが対応する変更処理を進めます。図の最下段にあるネットワーク機器の実際の設定変更は、OpenFlowプロトコルを用いて行われます。Topology Managerは、個々のネットワーク機器の上で稼働するOpenFlow Agentから情報を収集して、現在のネットワークの状態を把握した上で、その情報をNIBに反映します。NIBは、Publish-Subscribe方式の通知機能を持っており、それぞれのサービスは、自身が把握するべきNIBの項目に対してSubscribeしておき、該当の項目に変更があると、NIBからの通知を受け取ります。
図1 Orionのアーキテクチャー概要（論文より抜粋）
論文内では、図1のRouting Engine（RE）による経路設定の処理の流れが、図2のように紹介されています。REは、L3の経路設定を行うアプリケーションで、より上位のクライアントアプリケーションからの依頼を受けて、ネットワークスイッチに対する経路設定などの処理を行います。この時、クライアントアプリケーションは、物理的な個々のスイッチを意識する必要はありません。複数のスイッチを集めてグループ化した「Supernode」が定義されており、Supernode間でのパケットの転送経路を指定します。Supernode間は、複数のスイッチを介して接続されているので、具体的にどのスイッチを経由するかは、REが判断して、複数経路による負荷分散を自動で行います。
図2 NIBを介したサービス連携の例（論文より抜粋）
図2の例では、サブネット「1.2.3.0/24」に対する経路情報をSupernode-1から外部のドメインに通知するという処理の例が記載されています。まず、クライアントアプリケーションは、上記の処理を依頼するメッセージをNIBに書き込みます。この書き込みの通知を受けたREは、Supernodeに含まれる個々のスイッチに対する設定変更の内容をNIBに書き込みます。そして、この書き込みの通知を受けたFlow Manager（FM）は、OpenFlowプロトコルで実際の設定変更を行い、その結果を再びNIBに書き込みます。この書き込みの通知を受けたREは、必要な処理が終わったことをNIBに書き込み、最後に、大元のクライアントアプリケーションは、この書き込みの通知を受けて、依頼した処理が完了したことを理解します。
この様に、抽象度の高い要求をより実装に近いレベルの要求へと段階的に変換することで、処理が進みます。それぞれの処理は、NIBによる情報の伝達を介して非同期に行われます。また、具体的な設定変更の順序は、各サービスが適切に判断するため、設定変更の途中で一時的にネットワークが切断するようなことはありません。従来の自立分散型のネットワークアーキテクチャーでは、ネットワークの構成変更を行うと、新しい構成情報がネットワーク全体に伝搬するのに時間がかかるため、一時的に通信が途切れることがありました。一方、Orionでは、ネットワーク全体の構成情報がNIBに集約されているため、各サービスは、それぞれの変更が及ぼす影響を事前に把握して、安全な手順で変更を進めることができるのです。
今回は、2021年に公開された論文「Orion: Google's Software-Defined Networking Control Plane」に基づいて、分散型のSDNコントローラー「Orion」について、アーキテクチャーの概要と、NIBを用いたインテントベースの管理システムの特徴を紹介しました。次回は、Orionの設計ポリシー、および、Jupyter、B4とのより詳しい関係を説明していきたいと思います。
Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
