プライベートクラウド管理のすゝめ② - 其の参

Hinemosで真に効率化されたネットワーク運用の実現を
技術情報
関連情報
採用事例
お問い合わせ

作成日	2014/6/20
更新日	-

ネットワーク管理者編 - 其の参

Hinemosで真に効率化されたネットワーク運用の実現を

OpenFlowを積極的に活用することにより、従来のネットワーク機器では実現困難なレベルのネットワーク設計・管理のシンプル化、機械的なフローの自動化による運用効率化が実現されることをお伝えしました。その実現手段の一つとして、Hinemosが提供するオプション製品の一つである「Hinemos仮想ネットワーク管理オプション」にて実現されるネットワーク運用を説明します。

ネットワークの物理設計書のアップデート作業を不要に

ネットワーク管理者は、AスイッチのX番ポートとBスイッチのY番ポートをUTPケーブルで接続するといった構成情報を物理設計書としてこれまで記録してきました。しかしながら、担当者間での認識違いなどといった様々な要因の結果として、ネットワーク物理設計書のアップデート作業が漏れてしまい、実際の環境と異なっていたというケースを耳にすることがあります。このようなネットワーク管理者が抱える課題に対して、Hinemos仮想ネットワーク管理オプションは強力にサポートします。

ネットワークトポロジの自動検出

OpenFlowコントローラはネットワークを構成するOpenFlowスイッチの一覧情報とともに、OpenFlowスイッチ間がどのように接続されているのかを自動的に検出します。まず、OpenFlowスイッチは設定されたOpenFlowコントローラのIPアドレスに接続しますが、その時点でOpenFlowコントローラは自身が管理するネットワークを構成するOpenFlowスイッチの存在を把握します。

そして、OpenFlowコントローラはOpenFlowプロトコルを利用して、管理している全スイッチの全ポートからリンク検出用のパケット(送信元のスイッチIDおよびポート情報を埋め込んだLLDPパケット)を定期的に送出します。

送出したポートの対向に異なるOpenFlowスイッチが存在していた場合は、受信したOpenFlowスイッチが自身のスイッチIDに加えてリンク検出用のパケットおよび受信したポート番号をOpenFlowコントローラへ通知します。この通知情報により、OpenFlowコントローラは送信元のスイッチ・ポート番号、受信したスイッチ・ポート番号を得られるため、各スイッチ間がどのように接続されているのかを把握できます。

リンク検出用のパケットを定期的に送信することで、スイッチ間の全リンクのヘルスチェックが可能となり、OpenFlowコントローラはリンクダウンを検知可能となるとともに、常に最新のネットワークトポロジを把握することが可能になります。Hinemos仮想ネットワーク管理オプションでは、最新のネットワークトポロジをGUI上にマップ表示可能な上、ネットワークトポロジの状態変化（スイッチの起動・停止、新たなスイッチの増設、既存のスイッチの撤去、スイッチ間のリンクダウン、スイッチ間のリンクの増設など）を検知し、ネットワーク管理者へメールなどで通知できます。

ネットワークに接続される機器の自動学習

OpenFlowスイッチで構成されるネットワークの周囲に存在する機器の配置も自動的に検出します。従来のL2スイッチが保有するFDB（Forwarding Database）と同様の仕組みにより、各機器から送信されたパケットのヘッダに含まれる送信元MACアドレスをOpenFlowコントローラが学習し、どのスイッチのどのポートに対してどのような機器が配置されているのかを自動学習します。

この情報およびネットワークトポロジに基づき、ネットワークに接続される機器間の経路を探索することが可能になります。

物理・論理の分離でトラフィック設計をシンプルに

ネットワーク管理者は、ある機器Aと別の機器Bを通信させるために、機器間に存在するスイッチを把握して、通信させるために必要なトラフィック制御ルールを設計し、各スイッチに手動で実装してきました。しかしながら、経由するスイッチのベンダが異なっていることはごく当たり前であり、各スイッチごとに必要な設定あるいはコマンドが異なってくることから、ネットワーク管理者の負担および運用コストは非常に大きいものでした。時として、外部のスイッチ有識者に設計・実装をアウトソースすることもあり、多大なコストを要することもあります。このようなネットワーク管理の複雑性を解消し、シンプルなネットワーク運用を実現するため、Hinemos仮想ネットワーク管理オプションは強力にサポートします。

機器間のトラフィック制御定義のシンプル化、スイッチへの設定の自動化

OpenFlowスイッチで構成されるネットワークの周囲に存在する機器間をどのように通信させるのかを定義するのもシンプルです。例えば、単一のL2セグメント上で機器間を接続させるような仮想ネットワークを定義する例を紹介します。シンプルで直感的な論理ネットワークマップを編集するエディタ上で、仮想的なL2スイッチ（L2スイッチを通過するようにトラフィックを制御する仮想的なデバイス）を作成し、その周囲に同一のL2セグメントに所属させる機器情報としてMACアドレスやIPアドレス・サブネットマスクを定義します。最後に、仮想L2スイッチアイコンと機器アイコン間のリンクをDrag&Dropで定義すれば完了です。

そして、論理ネットワークの定義に従い、OpenFlowコントローラが実際の物理配置に基づいてトラフィック制御ルールを各スイッチに対して自動的に配布します。例えば、Apache VMからTomcat VMへの通信に対して、OpenFlowコントローラは論理ネットワークの定義上で通信の流れをシミュレートします。今回の場合は、仮想L2スイッチのみを経由する通信であることからパケットのヘッダ加工などを行わず、Apache VMからTomcat VMへ転送すればよいことが確認されます。その後、Apache VMおよびTomcat VMが接続するポートの位置を把握し、OpenFlowコントローラは自身が保持するネットワークトポロジ情報に基づいてその両端を結ぶ最適（最小コスト）となる経路を算出します。その経路情報に基づき、経由する全てのOpenFlowスイッチに対してトラフィック制御ルールとなるフローエントリを設定します。

業務変化や故障に対してネットワークを柔軟に

ネットワーク管理者は、システムの増設・撤去の繰り返しに伴い、スイッチや周辺機器との配置の最適化に悩まされてきました。また、次々に拡張されるネットワークにおいてスイッチの台数は増大し、スイッチやUTPケーブルなどの故障への対応は避けられない状況になりつつあり、ループなどを意識しながらのネットワークの冗長設計などの負担は増大する一方です。このようなネットワーク管理者が抱える機器配置や冗長設計の負担を最小化するため、Hinemos仮想ネットワーク管理オプションは強力にサポートします。

サーバ仮想化に最適な柔軟なネットワークの実現

OpenFlowスイッチの周囲に存在する機器の配置が自動学習されるため、ラック上の機器や仮想サーバの物理配置に柔軟性が生まれます。例えば、システムの増設・撤去の繰り返しに伴い、企業内のマシン室に設置されているラックに機器が偏って配置された状態となることがあります。このような機器配置の偏りは新たなシステムの増設におけるコストを増大させます。このような場合、サーバ配置を再編成したいと考えますが、従来のネットワークだとサーバが接続できるスイッチやポートが物理的に制約されてしまうため、単にサーバの配置を変更するだけでは対応できず、ネットワーク自体の再設計が必要となりました。

しかしながら、OpenFlowコントローラにより集中制御されたネットワークの場合、全てのスイッチは等価と扱うことが可能になります。そのため、システムメンテナンスのタイミングでサーバを移設し、移設先のラックに設置されたスイッチに接続し直すだけで、新たな配置を自動的に学習し、ネットワークが有機的に順応します。

この柔軟なネットワークはサーバ仮想化の技術との親和性も高いです。サーバ仮想化技術により、物理サーバと仮想サーバを分離して管理可能となったことから、仮想サーバをマイグレーションして片寄せすることで、物理サーバのメンテナンス（ハードウェアの交換、ハイパーバイザへのパッチ適用、BIOSの更新など）が容易となりました。ただし、マイグレーションしても業務継続可能な状態を実現するためには、別の物理サーバおよびスイッチを経由しても外部との通信が継続可能であることが前提となります。ハイパーバイザ上の仮想スイッチについては、各ハイパーバイザが提供する管理機能によって通信継続性を担保することが可能となりますが、その外部に存在する物理スイッチについてはこの通信継続性を担保するために複雑な設計が必要となります。

この課題についてもOpenFlowで制御されたネットワークは有効に機能します。ハイパーバイザが動作する物理サーバをOpenFlowスイッチで構成されたネットワークに接続させることで、仮想マシンのマイグレーションが行われたとしても、その配置変更を自動学習し、通信継続性も担保することが可能となります。

耐障害性・スケーラビリティを備えたエンタープライズ用途のネットワーク

ネットワークトポロジがOpenFlowコントローラにより常に監視されていることから、一部のリンクで故障が発生したとしても、最新のネットワークトポロジに基づいた最適な経路にトラフィックがリルートされます。従来のSTPに比べて非常に短い時間で切り替えが完了するため、システムによるサービス提供の影響も極小化されます。また、この障害の発生およびトラフィック変化は自動的にネットワーク管理者にメールなどにより通知できることから、その通知に基づいてネットワーク管理者は障害箇所を把握し、障害の復旧作業を開始できます。

さらに、すべてのリンクを有効活用できるため、帯域の拡張も非常にシンプルに行えます。まず、同一のコストとなる経路が複数存在していた場合、ECMP（Equal Cost Multi Path）として通信を振り分けることが可能です。

また、LAG(Link Aggregation Group)のような帯域拡充も容易です。帯域が不足し始めたリンクと並列に、スイッチ間のリンクの本数を増やすだけで拡充できます。スイッチに設定を追加したり、ネットワークを停止する必要もありません。OpenFlowコントローラが新たなリンクを自動検出し、新たなネットワークトポロジに基づいて帯域を有効活用します。

既存のネットワークとの接続も容易に実現

OpenFlowで制御されたネットワークがどんなに魅力的であっても、既存のネットワークを残しつつ、段階的にネットワーク更改を進めていくことが現実的です。その際、OpenFlowに対応していないスイッチとOpenFlowスイッチをどのように接続すればよいのでしょうか？この課題に対しても、Hinemos仮想ネットワーク管理オプションは役に立つ機能を提供しています。特定のOpenFlowスイッチの物理ポートを制御範囲の境界とみなして、既存の非OpenFlowのネットワークとOpenFlowスイッチで構成されたネットワークを接続させることが可能です。そのための機能がアクセスポートと呼ばれます。

例えば、L2スイッチとOpenFlowスイッチを接続させる場合、以下のようなトラフィック制御定義を論理ネットワーク内に定義すればシームレスにお互いのネットワークを接続できます。

アクセスポートを2系統用意することにより、冗長接続も可能となります。L2スイッチ側の設定としては、STPあるいはLAG（*1)が利用できます。

このアクセスポートを2系統用意する方法は、L3スイッチとの冗長接続も利用可能です。L3スイッチ側の冗長方式としては、VRRP/HSRPなどが利用できます。

(*1) Link Aggregation Groupの略。OpenFlowスイッチとはLACPによるネゴシエーションが行えないため、スタティック設定にて送信元MACアドレスで分散させる必要があります。

「プライベートクラウド管理のすゝめ③ 応用編」では、このようなネットワークにハイパーバイザを接続して仮想サーバをソフトウェア制御することにより、様々なコントローラをオーケストレーションすることでSoftware-Defined Infrastructureを実現し、インフラ全体の運用の効率化につながることをご紹介します。

< 1 2 3