ネットワークガイド

ソフトウェア定義ネットワーク (SDN: Software-defined Networking) は、下層の機能を抽象化することでネットワーク管理者がネットワークサービスを管理できるようにするコンピューターネットワーキングの方法の 1 つです。サーバーのワークロードを仮想環境に移行しても、それらのサーバーがデータの送受信のためのネットワーク接続を必要とすることに変わりありません。SDN は、ルーターやスイッチなどのネットワーク装置を同じ仮想化領域に移動することで、このニーズに対応します。すでにネットワークの基本概念に精通している場合には、SDN によって接続されるサーバーと同様に、ネットワークが仮想化されていると考えても飛躍ではありません。

本書は、パート 1 で管理者が基本的な管理およびトラブルシューティングタスクについて理解するための内容を紹介し、パート 2 で OpenStack Networking の高度な機能についてクックブック形式で解説しています。ネットワークの一般概念をすでに把握している場合には、本書の内容は理解しやすいはずです (ネットワークに精通されていない場合には、パート 1 のネットワークの一般的な概要が役立ちます)。

ソフトウェア定義ネットワーク (SDN: Software-defined Networking) により、エンジニアは仮想ルーターやスイッチを OpenStack または RHV ベースの仮想化環境にデプロイすることが可能です。また、SDN により、コンピューター間におけるデータパケット転送は従来とは異なる領域に移行されます。これらのルーターやスイッチは、以前はさまざまなケーブルで接続された物理デバイスでしたが、SDN を使用するとボタンを数回クリックするだけでデプロイして稼働させることができます。

大規模な仮想化環境では、ソフトウェア定義ネットワーク (SDN) を採用すると、組織内政治の緊張を生む可能性があります。高度なネットワーク概念に精通していない仮想化エンジニアは、クラウドデプロイメントの仮想ルーターやスイッチの管理を突然迫られ、IP アドレスの確保、VLAN の分離、サブネット化について合理的に判断する必要があります。仮想化エンジニアがこのような状況に直面している一方で、ネットワークエンジニアは、かつて自分たちの独占領域であった技術について他のチームが協議しているのを目の当たりにするため、動揺したり、雇用の先行き不安が生じたりする可能性があります。このような境界があると、トラブルシューティングもかなり複雑になります。システムがダウンして相互接続できない場合には、仮想化エンジニアはパケットが物理スイッチに到達していることを確認した時点で、そのトラブルシューティングをネットワークエンジニアに引き継ぐべきでしょうか。

このような緊張は、仮想ネットワークを物理ネットワークの延長と考えると、容易に緩和することができます。デフォルトゲートウェイ、ルーター、サブネットには、物理ネットワークと同じ概念が適用され、ネットワークはすべて TCP/IPを使用して稼働することには変わりありません。

この問題に対して、どのような政治的対応を図るとしても、技術的な手段で対処することもできます。たとえば、Cisco の Nexus 製品を使用することで、OpenStack オペレーターは精通した Cisco NX-OS を実行する仮想ルーターをデプロイすることができます。これにより、ネットワークエンジニアは、これまで既存の物理 Cisco ネットワーク装置で行なってきた方法で、ネットワークポートにログインし、管理することができます。または、ネットワークエンジニアが仮想ネットワークを管理しない場合でも、初期の段階からネットワークエンジニアを交えて進めていくことが賢明です。OpenStack のノードには、物理ネットワークのインフラストラクチャーが必要な点は変わりなく、IP アドレスの割り当て、VLAN のトランク接続、VLAN をトランク接続するためのスイッチポートの設定を行う必要があります。トラブルシューティングに加えて、両チーム間での広範囲にわたる連携が要求されます。たとえば、仮想マシンの MTU サイズを調整する場合には、全仮想/物理スイッチおよびルーターなど、エンドツーエンドで実行する必要があり、両チーム間で慎重に準備して変更を行っていく必要があります。

ネットワークエンジニアは、引き続き、仮想化デプロイメントにおける極めて重要な役割を果たします。SDN の導入後にはその重要性はさらに高まります。業務が複雑化するため、ネットワークエンジニアのスキルを確実に活用していかなければなりません。特に問題発生時には、ネットワークエンジニアの知識が必要になります。