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

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

ソフトウェア定義ネットワーク (SDN: Software-defined Networking) により、エンジニアは仮想ルーターやスイッチを OpenStack または RHEV ベースの仮想化環境にデプロイすることができるようになります。また、SDN は、コンピューター間でデータパケットを移動していた作業を不慣れな領域にシフトすることになります。以前は、これらのルーターやスイッチは、各デバイス間を各種ケーブルで接続された物理デバイスでしたが、SDN があるとボタンを数回クリックするだけでデプロイして稼働させることができます。

大規模な仮想化環境では、ソフトウェア定義ネットワーク (SDN) を採用すると、組織内で意見が相違して社内ポリティクスが発生する可能性がありました。高度なネットワーク概念を把握していない仮想化エンジニアは突如、クラウドデプロイメントで仮想ルーターやスイッチの管理を迫られ、IP アドレスの割り当て、VLAN の分離、サブネット化など思慮深く設定していく必要があります。仮想化エンジニアがこのような作業を行っている反面、ネットワークエンジニアは他のチームが以前は専門のドメインであった技術について話し合っているところを目の当たりにするため、動揺や仕事の保証の点で懸念が浮かぶ可能性があります。このような境界があると、トラブルシューティングもかなり複雑になります。システムがダウンしてシステム間で接続ができない場合には、物理スイッチにパケットが到達していることが確認できたらすぐに、仮想化エンジニアからネットワークエンジニアにトラブルシューティングを引き継ぐ必要があるのでしょうか。

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

この件を公平に管理する方法がどのようなものであっても、対処するための技術的な手段が存在します。たとえば、Cisco の Nexus 製品を使用することで、OpenStack オペレーターは使い慣れている Cisco NX-OS を実行する仮想ルーターをデプロイすることができます。こうすることで、ネットワークエンジニアは、今まで既存の物理 Cisco ネットワーク装置で行なってきた方法で、ネットワークポートにログインし、管理することができます。または、ネットワークエンジニアが仮想ネットワークを管理しなくなった場合でも、初期の段階からネットワークエンジニアを交えて進めていくことが件名です。OpenStack のノードには、物理ネットワークのインフラストラクチャーや IP アドレスの割り当て、VLAN のトランク化が必要なうえ、スイッチポートが VLAN をトランク化できるように設定する必要があります。トラブルシューティング以外には、両チームから幅広く協力を得る必要があり、たとえば、仮想マシンの MTU サイズを調整する場合には、全仮想/物理スイッチおよびルーターなど、エンドツーエンドで実行する必要があり、両チーム間で慎重に分担の変更を行っていく必要があります。

ネットワークエンジニアは、SDN の導入後もさらに、仮想化デプロイメントの重要な部分を担当することになります。複雑性が増したため、もちろんネットワークエンジニアのスキルを活用していく必要があります。特に問題が発生した場合などは知識が必要になります。