ナレッジセンター
匠コラム

Windows 10 HomeとDockerでBGP/MPLSを学ぶ①

匠コラム: ネットワーク; 仮想化

2020.08.06

ビジネス開発本部
第3応用技術部第3チーム
平河内竜樹

本記事では、WSL 2とDockerを利用し、Windows端末上でBGP/MPLSに関する検証環境の常設を目指します。

このページでは、仮想化・クラウド関連の技術を活用したネットワークの検証環境において、使いたいと思った時には既に稼働している状態を実現するための構成案を紹介します。

はじめに

突然ですが、工程の早い段階で「検証で確認したいな…」「でも必要な時間を確保できるかな…」という悩み、ネットワークに携わる技術者であれば多くの方が経験されているのではないでしょうか？

そんなときに強い味方になってくれるアイテムが“自分専用の検証環境”です。私自身、社会人の一年目においては給与の何分の一かを投じて、この環境をゲットしていました。振り返ると、何か気になったことがあった時にすぐ実践で確かめられるという環境は、効率や品質の面で大いにプラスへ働いていたと思います。

昨今ではメーカー各社より、仮想化・クラウドを用いた検証環境が数多く提供されており、個人でもより気軽に商用のネットワーク環境を調達できる時代になっていると言えます。提供形態は、手元の仮想化ソフトウェア上にインストールするものもあればクラウド越しで物理アプライアンスを利用できる形態のものもあり、様々です。

一方これらの環境を利用する際には、仮想化ソフトウェア用のリソースを確保する・クラウドへ接続するといったステップが発生することも確かです。弊社内では“何時でも誰でも利用できる”という指針で常に稼働している検証用の機器があり、これには一定の需要があると感じています。このような事情から仮想化・クラウド関連の技術を活用した環境においても『使いたいと思った時には既に稼働している』という状態を実現することができれば、検証環境の良い選択肢になるのではないだろうか？と考えました。

汎用的なデスクトップ環境の活用

専用の常設環境を用意するためには、まずハードウェアリソースが必要となります。これについては、常時占有可能なサーバが割り当てられているという方は稀でしょうし、それを専用のコンピュータやクラウドで賄おうとすると手間やコストに跳ね返ります。そこで注目される対象が普段使いのデスクトップ端末です。例えばVDIクライアントの専用機と化している様な端末であればマシンスペックはそれほど要求されず、メモリに関しては多めに積んでいる場合ギガバイト単位で常に遊休していることも十分に有り得ます。

留意点として、商用OSの利用を想定すると、仮想マシン（以下、VM）に対応した仮想アプライアンスは相応のリソースを要求する傾向にあります（ホントにネットワークは仮想されるのか！？②）。製品開発の進展によってfootprintは上下していますし、組み方にも依存するのですが、例えば4GB-16GB程度のマシンにネットワークノードを10台以上配置しようとすればリソースがボトルネックとなってきます。

話は変わりまして、デスクトップOSのシェアは今どのようになっているでしょうか。図1はNetMarketShareを情報源として、2019年10月から2020年3月の期間を対象に、月単位のデータを整理したものになります。これを参照すると、利用場面や利用者の内訳も気になるところですが、デスクトップOSのシェアは半数以上がWindows 10という結果になっています。

図1：デスクトップOSのシェア（NetMarketShareより筆者作成）

そのように高いシェアを有するWindows 10に関して、2020年の5月下旬に大型アップデートの配信が開始され、この中でWSL 2がGAとなりました。

WSL 2 と WSL 1 の比較

https://docs.microsoft.com/ja-jp/windows/wsl/compare-versions

WSL 2はアーキテクチャとしてLinuxアプリケーションに対してより親和する様になり、特にDockerの利用に関しては開発や試験の環境として重要なアップデートに位置付けられていると言えます。

また、ネットワーク分野における仮想アプライアンスの動向として、コンテナを単位として配置できる製品のリリースが相次いで行われています。これはCloud Native環境におけるネットワーク機能の提供が典型的な用途となりますが、footprintの軽さから、テスト／トレーニングの用途でも有効に活用することができます。先に挙がったWSL 2環境のDockerと組み合わせれば、汎用的なデスクトップ環境で大規模適性のある検証環境の実現も期待できます。

構成概要

WindowsやmacOSに対してはDocker Desktopと呼ばれるソフトウェアが提供されており、デスクトップOS上でDocker環境を簡便な手順で整える手段は以前より存在していました。Docker Desktopはインストーラを実行するだけでセットアップが完了し、またKubernetesも統合されているなど、何より手軽にコンテナを試したい際にはうってつけの方法です。

一方、Docker Desktopでは、ホストOSとは独立したVM上に実行環境が用意される形式になっています。Docker Desktopのインストールや利用にあたっては実行環境となるVMの存在が特段意識されない様になっている反面、Dockerの操作によって作成されたコンテナネットワークをホストOSから直接認識することはできません。

Docker Desktop for Windowsは、実行基盤としてHyper-Vに加えてWSL 2をサポートしたことによりWindows Homeでも利用可能となりましたが、先のネットワークの挙動に関してはWSL 2を利用する際も同様に該当します。これは、ネットワークの検証環境としてみると、パケットキャプチャの難易度に影響します。

インストールや利用が容易であったとしても、パケットキャプチャが自由にできないとあっては、ネットワークの検証環境としては果たしてどうでしょうか？

今回は『Windows 10 Homeを基盤に仮想アプライアンスを実行し、且つその間で任意のパケットキャプチャを可能にする』という条件を満たすために、Ubuntuで利用されるWSL 2の領域にDockerのインストールを行い、さらにRPCAPプロトコルを経由してホストOS上からリモートキャプチャを行う構成を検討しました（図2）。

図2：今回想定する構成の概要

この構成に対し、ホストOSの起動時にWSL 2上で稼働するデーモンとコンテナを自動で実行するように設定することで、「外部のリソースを使わない」「スケールする」ネットワークの検証環境を『使いたいと思った時には既に稼働している』『以前に構成したトポロジや設定の情報が維持されている』状態で提供可能となることが想定されます。

上記の環境でどのような機能が利用できるかは、仮想アプライアンス次第です。コンテナ型の仮想アプライアンスにおける留意点として、仮想マシン向けに提供されているものと同じ系統のソフトウェアであったとしても、実情としてその間で機能のギャップは存在する傾向にあります。逆に対応しているものが用意できれば、BGP/MPLSの検証を行うことも可能となります。

以降では、想定する検証環境の実現を通じて、ネットワークの利用者から見てもっとも近いノード（デスクトップ端末）上でもっとも奥まったところで使われているプロトコル（BGP/MPLS）が存分に走り回る光景を目指したいと思います。

～続く～