ソフトウェアによりネットワークを動的に制御する技術、SDN(Software-Defined Networking)。
よりダイナミックに構成されるネットワーク上でHULFTはどのように動作するのか、その検証結果をレポートします。
よりダイナミックに構成されるネットワーク上でHULFTはどのように動作するのか、その検証結果をレポートします。
ごあいさつ
こんにちは、セゾン情報システムズ HULFT事業部の杉本です。
最近、IT情報誌や情報サイトにて、ネットワークの仮想化技術の記事や事例を目にすることが多くなってきました。それらの技術はSDN(Software-Defined Networking)と呼ばれ、ネットワークのメンテナンス時間が限られている鉄道駅構内への採用がニュースになるなど、新たなITインフラとして注目を集めています。
そのようなインフラ技術に対してHULFTがどのような連携が取り得るか、検証を行ってみました。今回は、その検証結果を記事に纏めてみたいと思います。
最近、IT情報誌や情報サイトにて、ネットワークの仮想化技術の記事や事例を目にすることが多くなってきました。それらの技術はSDN(Software-Defined Networking)と呼ばれ、ネットワークのメンテナンス時間が限られている鉄道駅構内への採用がニュースになるなど、新たなITインフラとして注目を集めています。
そのようなインフラ技術に対してHULFTがどのような連携が取り得るか、検証を行ってみました。今回は、その検証結果を記事に纏めてみたいと思います。
SDNとは
今回の検証では、NEC製のSDN対応製品(UNIVERGE PF6800/PF5240)を使用しました。下記は、SDN環境について作業メンバーへ情報共有する際に纏めた文章です。
■ 構成
■ メリット
SDN環境
■ サポートするレイヤ(OSI階層モデル)- L1(物理層)、L2(データリンク層)、L3(ネットワーク層)、L4(トランスポート層)
つまりL1のLANケーブル接続、L2 HUB、L3-L4 ルーターを仮想的に作ることができます。 - SDNはL5(セッション層)以降に関与しません。
■ 構成
- 物理構成
- 1台のコントローラ(PFC :ProgrammableFlow Controller)と1台以上のスイッチ(PFS :ProgrammableFlow Switch)で構成されます。
- コントローラでネットワークの設計を行い、スイッチ側で設定を参照し動作します。
- コントローラとスイッチをつなぐ専用ネットワークが2つ(OpenFlow Channel/Manage Net)必要あります。
- 論理構成
- L1～L4まではほぼ制限なく作成可能です。
ただし、物理的にスイッチにポートがあるためこの制限は発生します。
- L1～L4まではほぼ制限なく作成可能です。
■ メリット
- 管理がコントローラで一元的に行え、ネットワークの可視化と運用効率を向上させます。
自動化の対応も簡単です。 - ネットワーク通信の設定変更が一瞬で行えます。
社会インフラなどメンテナンス時間の制約が厳しい分野で、より効果を発揮します。 - システム初期段階からSDNを導入すれば、トータルコストは「物理構成」より安価になります。
検証の概観
今回の検証では、下記のような業務シーンを想定して、SDNおよびHULFTの動作検証を計画しました。
HULFT単体では帯域の制御機能は持っておりません。SDNの機能を駆使して業務要件を実現することとなります。
そこで、今回検証した内容は下記の2点です。
業務シーン
- 事業拡大に伴い、夜間のデータ処理量が増加。
夜間のHULFT転送バッチが翌朝定時までに完了しなくなってきた。 - 夜間、HULFT以外にも多くのデータ通信がある。
HULFT単体では帯域の制御機能は持っておりません。SDNの機能を駆使して業務要件を実現することとなります。
そこで、今回検証した内容は下記の2点です。
検証内容
- SDNのWebAPI(REST)を通して、HULFT通信の帯域優先度を変更することができる。
- 変更した帯域優先度通りにHULFT通信が優先される。
検証環境
物理的な検証環境は下図のとおりです。
物理環境ではイメージしにくいと思いますので、論理的なイメージも書いてみました。
なお、帯域優先度の制御ジョブの呼出しについては、処理の自動化を考慮して、SDN側のWebAPIをHULFT Scriptのトリガーから実行する構成としました。HULFT ScriptにはRESTアダプタはないので、curlコマンドを仕込んだバッチファイルを外部アプリケーションとして呼び出しています。
物理環境ではイメージしにくいと思いますので、論理的なイメージも書いてみました。
なお、帯域優先度の制御ジョブの呼出しについては、処理の自動化を考慮して、SDN側のWebAPIをHULFT Scriptのトリガーから実行する構成としました。HULFT ScriptにはRESTアダプタはないので、curlコマンドを仕込んだバッチファイルを外部アプリケーションとして呼び出しています。
検証内容
結論から言いますと、WebAPIを利用した帯域優先度の制御、および制御結果通りにHULFT通信が優先されることは本検証で確認できました。
WebAPIによる帯域優先度の制御は、そもそもSDN側で保証、クローズできる要件でしたので、本稿では、HULFTファイル転送への優先度制御がどのような挙動を見せたのか、そちらの内容についてお話したいと思います。
通信の制御方式は最低保証帯域の幅を直接指定する方法や、各通信に優先度の順位付けを行う方法など、全部で6項目あります。急に細かい仕様の説明となってしまいますが、その6項目の概要を表にまとめておきました。
全項目の検証を行いましたが、もっとも分かりやすく効果が見られたPQ(完全優先度制御)方式の結果をお見せしたいと思います。この方式は、優先度の高い設定を持つ通信を優先する仕様となっています。
今回は下図のように、FTPによるファイル転送通信を「その他の通信」と見立てて、HULFTとFTPによるファイル転送を同時に実施する検証を行いました。検証前の仮説としては、HULFTの通信優先度を上げるほど、より速い転送時間でファイル転送が終了すると考えていました。FTP通信の優先度制御は未設定としています。
WebAPIによる帯域優先度の制御は、そもそもSDN側で保証、クローズできる要件でしたので、本稿では、HULFTファイル転送への優先度制御がどのような挙動を見せたのか、そちらの内容についてお話したいと思います。
通信の制御方式は最低保証帯域の幅を直接指定する方法や、各通信に優先度の順位付けを行う方法など、全部で6項目あります。急に細かい仕様の説明となってしまいますが、その6項目の概要を表にまとめておきました。
| 項目名 | 制御方法 | 動作説明 |
|---|---|---|
| PQ | 完全優先制御 | 優先度の高いキューから常にフレームを送出 |
| RR | ラウンドロビン | 順番にキューを見ながら1フレームずつ送出 |
| WRR | 重み(フレーム数)付きラウンドロビン | 順番にキューを見ながら重みに応じてフレームを送出 |
| 2PQ+6DRR | 最優先キュー＋重み(バイト数)付きラウンドロビン | 最優先キューを2つ確保 残り6つのキューは重みに応じてフレームを送出 |
| 2PQ+6WRR | 最優先キューと重み(フレーム数)付きラウンドロビン | 最優先キューを2つ確保 残り6つのキューは重みに応じてフレームを送出 |
| WFQ | 重み付き均等保証 | キュー毎に最低保証帯域分を送出 |
全項目の検証を行いましたが、もっとも分かりやすく効果が見られたPQ(完全優先度制御)方式の結果をお見せしたいと思います。この方式は、優先度の高い設定を持つ通信を優先する仕様となっています。
今回は下図のように、FTPによるファイル転送通信を「その他の通信」と見立てて、HULFTとFTPによるファイル転送を同時に実施する検証を行いました。検証前の仮説としては、HULFTの通信優先度を上げるほど、より速い転送時間でファイル転送が終了すると考えていました。FTP通信の優先度制御は未設定としています。
検証結果
下記の表は、HULFT通信の通信優先度を変えて計測したHULFTとFTPによるファイル転送時間／スループットです。HULFT通信の優先度が上がるにつれて、HULFTのファイル転送のスループットも向上していることが分かります。HULFT通信に帯域が優先して割り当てられているため、他の通信であるFTPのスループットは逆に下がっていっています。
※転送ファイルサイズ4GB、データ圧縮・コード変換なし
| HULFT通信の優先度設定 | HULFT | FTP | ||
|---|---|---|---|---|
| 転送時間(秒) | Mbit/s | 転送時間(秒) | Mbit/s | |
| HULFT 優先度0(最低) | 93 | 352.3 | 49.8 | 658.0 |
| HULFT 優先度3(中間) | 78 | 420.1 | 75.48 | 434.1 |
| HULFT 優先度7(最高) | 59 | 555.4 | 80.34 | 407.9 |
| 制御なし | 78 | 420.1 | 75.67 | 433.0 |
余談
実は前述の検証の前に一度、別の方式によるHULFTの帯域制御の検証を別日程で行っていました。その際は、「任意の帯域(例えば50Mbps)を超過した場合はパケットをdropする」という設定を採用していました。結果、その設定ではHULFT通信のスループットが大きく低下することが分かりました。調査の結果、その原因は、パケットがdropされることでHULFT通信データの再送が多発していたこととわかりました。その結果をNEC社のSDN担当者へ問い合わせた結果、採用した設定の改良点が判明し、後日、前述の再検証に臨むこととなりました。
物理ネットワーク機器にしても、SDNにしても、通信の制御設定次第で思わぬアプリケーションの挙動が出てしまいますので、読者の皆様もご留意いただければと思います。
物理ネットワーク機器にしても、SDNにしても、通信の制御設定次第で思わぬアプリケーションの挙動が出てしまいますので、読者の皆様もご留意いただければと思います。
おわりに
SDN上でのHULFTの動作が可能であることは明らかではありましたが、今回、実際に機材を用意して実機検証を行えた実績を作ることができ良かったと思います。
さらに、HULFT通信の帯域優先制御の実現性も確認できましたので、SDN上で大容量データを効率的に伝送したいお客様のご要望に対応できる裏付けを取ることが出来ました。
この記事を書いている期間中も、HULFTの帯域制御でお問合せを頂くことがありました。今後、SDNの普及に伴い、より柔軟で効率的なHULFTの運用方法をお客様へ提供できると期待しています。
さらに、HULFT通信の帯域優先制御の実現性も確認できましたので、SDN上で大容量データを効率的に伝送したいお客様のご要望に対応できる裏付けを取ることが出来ました。
この記事を書いている期間中も、HULFTの帯域制御でお問合せを頂くことがありました。今後、SDNの普及に伴い、より柔軟で効率的なHULFTの運用方法をお客様へ提供できると期待しています。
コメント