8. ネットワークの自動化
7.5. ネットワーク仮想化(SDN)
7.5.1. ルータやスイッチの構造
ルータやスイッチの処理の種類や機能は大きくデータプレーン、コントロールプレーン、マネジメントプレーンの3つに分類される。
| 分類 | 機能 |
|---|---|
| データプレーン | ルーティングテーブル/MACアドレステーブルの検索, パケットカプセル化非カプセル化, IEEE802.1Qタグ追加削除, NAT変換, フィルタリングなど |
| コントロールプレーン | ルーティングテーブル/MACアドレステーブルの作成, ARPのアドレス解決など |
マネジメントプレーンはネットワーク機器の構成/設定の管理を行う部分となる。 ユーザに機器の操作/管理の機能を提供する。
7.5.2. SDNの概要
SDNはソフトウェアによりネットワークを管理/制御、構成するための技術/考え方。 SDNではデータプレーンの処理とコントロールプレーンの処理を分けて考える。 SDNコントローラでコントロールプレーンの処理を一括で行う特徴がある。
SDN構成では各ネットワーク機器上ではデータプレーンのみが動作する。
7.5.2.1. SDNのアーキテクチャ
インフラストラクチャ層はデータ転送を実際に行うネットワーク機器のレイヤ。 これらの機器の制御には、OpenFlowやNETCONFなどの標準プロトコルや、機器ごとに設定されたAPIを利用する。 この部分のAPIはSouthbound APIと呼ばれる。 SBIにはOpenFlow、OpFlex、Telnet、SSH、SNMP、NETCONF、RESTCONFなどがある。
コントロール層はSouthboundのプロトコル(SBI)やAPIを使用した機器の制御をするレイヤ。 同時にインフラストラクチャ層のネットワーク機器のネットワーク機能を抽象化したAPIをアプリケーション層に提供する。 この部分のAPIはNorthbound API(NBI)を呼ばれる。
アプリケーション層はSDNコントローラに設定するアプリケーションが該当するレイヤ。 SDNを操作するアプリケーションはSDNコントローラとセットで提供される。 APIを通じてネットワークの様々な処理をSDNコントローラへ指示する層となる。
7.5.3. OpenFlow
OpenFlowはSDNを実現する技術の1つでONFにより規定されたSouthbound APIに相当するプロトコル。 この技術ではコントロールプレーンとデータプレーンの処理を分離させることができる。
OpenFlowではSDNコントローラのOpenFlowコントローラ、機器側のOpenFlowスイッチにより実現される。
7.5.3.1. OpenFlowの特徴
OpenFlowではOpenFlowコントローラでフローテーブルと呼ばれるデータ転送の通信ルールを規定したテーブルを作成し、ネットワーク上のOpenFlowスイッチに配布する。 各OpenFlowスイッチはそのフローテーブルに従ってデータ転送/通信を行い、これはホップバイホップ方式と呼ばれる。
OpenFlowの特徴は以下の通り。
- フローテーブルの設定により柔軟なネットワークが構築可能
- フローテーブルの維持/設定/管理が難しい
- すべての機器がOpenFlowに対応している必要がある
7.5.3.2. OpenDaylight
OpenDaylightはOSSのSDNコントローラでベンダー機器の垣根を超えることを目標に作られたもの。
7.6. ネットワークの自動化
7.6.1. ネットワーク自動化/プログラマビリティ
クラウドサービスやネットワークの複雑化により従来のネットワーク管理者が手動で機器を設定するのは非常に手間がかかるようになってきた。
こうした背景からネットワーク自動化とプログラマビリティが重要視されている。
7.6.2. REST API
REST APIはREST思想に基づいて作成されたAPIで、ネットワーク自動化のための設定にも利用されている。
7.6.2.1. REST
RESTは以下項目を満たすAPIと定義されている。
- クライアント/サーバ構成
- ステートレス
- キャッシュの可否の制御が可能
- 統一されたインターフェイス
- 階層化されたシステム構成
- コードオンデマンド
7.6.2.2. HTTP
多くのREST APIはHTTPプロトコルを使用している。 リソース操作はリソースを識別するURIとリソース命令のHTTPメソッドで行われる。
- URI ...
https://hogehoge.com/api/v1/のようなリソース位置を示す文字列 - HTTPメソッド ... リソースに対して行いたいアクション(CRUD)
| CRUD | HTTPメソッド | 説明 |
|---|---|---|
| Create | POST/PUT | 作成 |
| Read | GET | 読み取り |
| Update | PUT | 更新 |
| Delete | DELETE | 削除 |
7.6.2.3. JSON
REST APIでやりとりされるデータ形式にはJSON, XML, YAMLなどがある。 最近はJSONが使われることが多い。
7.6.3. 構成管理ツール
7.6.3.1. 従来の構成管理の問題
従来の構成の問題は以下手順を全ての機器に行う必要がある点にある。 そのため構成管理を手動で行うのは困難となっていた。
- 対象デバイスにログインする
- 設定コマンドの実行
- 設定した内容をファイルに保存して保管
- 修正を行ったらファイルを更新して保管
上記の問題や構成ドリフトが発生しないように、構成管理ツールが開発された。
7.6.3.2. 構成管理ツールの概要
構成管理ツールを用いたアーキテクチャでは各機器の設定ファイルを共有フォルダで一元管理する。 そのためネットワーク管理者は共有ファイル上の設定ファイルを編集するだけで機器に変更を加えることができる。
7.6.3.3. Ansible/Puppet/Chef
構成管理ツールにはAnsibleやPupper, Chefなどがある。
AnsibleはRedHatが開発するOSSの構成管理ツール。 構成管理サーバから各ネットワーク機器に設定を送るPush型の通信形態となっている。 各機器にエージェントをインストールしなくても設定を送れるエージェントレスな構造となっている。 また構成ファイルはYAMLを使って記述する。
PuppetはPuppet Labsが開発するOSSの構成管理ツール。 ネットワーク機器が構成管理サーバから設定を取得するPull型の通信形態となっている。 クライアント側にもソフトウェアのインストールが必要なエージェントモデルとなっている。 なお設定の取得の際はHTTP/HTTPSでTCP8140番ポートを使用して接続を行う。
ChefはChef社が開発するOSSの構成管理。 管理対象がChefに対応している必要があるため通信機器の管理にはあまり使われないPull型の形式。 制御ファイルはRubyで記述される。
| 構成管理ツール | 制御ファイル | 構成ファイル形式 | サーバ待ち受けポート | プロトコル | アーキテクチャ | 通信形態 |
|---|---|---|---|---|---|---|
| Ansible | PlayBook | YAML | なし | SSH,NETCONF | エージェントレス | Push型 |
| Puppet | Manifest | 独自形式 | TCP8140番 | HTTP/HTTPS | エージェント | Pull型 |
| Chef | Recipe/Runlist | Ruby | TCP 10002番 | HTTP/HTTPS | エージェント | Pull型 |