Technology
OpenNaEFの技術的特徴と
アドバンテージを説明します
Advantage of Naef
-
約15年各種システムで利用されていますMany actual usage
-
広域イーサネットサービス用VLAN設計システムのベースとして導入
-
MPLS/VLAN設計・監視システムとして稼働中
-
クラウドDC向け設計・管理システム
-
-
Multivendor , multi protocol and multi service support
主要テクノロジーを網羅し、エンド・エンドの完全なトポロジーを検出が可能です。-
特定のネットワークテクノロジーだけ表現するのではなく, End to End の connectivity を表現するために必要なすべての要素をモデル化し, 作成・変更・削除が各種APIにて実施できます.
-
物理構成から Ethernet/VLAN/MPLS, IP 等の複数レイヤの情報を統合して管理できる。レイヤ間の依存関係も表現できます。
-
-
すべてのネットワークモデルオブジェクトは2次元の時間軸を持ち、過去から将来予定までのネットワークトポロジのライフサイクル管理が可能
-
物理構成から Ethernet/VLAN/MPLS, IP 等の複数レイヤの情報を統合して管理できる。レイヤ間の依存関係も表現できます。
-
実際の装置から収集した結果および設計情報をもとに、物理トポロジーおよび論理トポロジーを生成し、NaEFに格納されたネットワークトポロジモデルと比較し、その差分を提示することが可能です。
-
openNaEF ではSDNの様な即時反映するネットワーク構成操作に加え、モデル情報をすべて実際のネットワーク機器・サーバ等の設定に変換し、ジョブ単位での設定投入が可能です。
OPEN
NETWORK
A*
Engineering
Framework
Technical features of NaEF
-
NaEF は, 物理配線から装置, プロトコル, ユーザサービスまで、管理構成要素をすべてオブジェクト化している. 拡張も非常に容易となっています
-
NaEFは、ネットワークの設計、実機への反映、実機から各種設計情報を収集することでネットワークのライフサイクル全体を管理することができます。これを実現するためにネットワークテクノロジのナレッジや機器固有のナレッジ、ネットワーク機器OSのコマンドナレッジ、ディスカバリに必要なMIBのナレッジ等を備えています。
-
VOSS モデルでは, モデルの変更は実機に対する構成変更要求に変換できる.
-
ネットワークミニチュアモデルのおかげで, 変換が極めて容易である.
-
-
VOSS は, モデルから Config を生成するための標準変換ロジックを提供している.
-
モデル変更点を複数の意味的に完結する断片に分解し (assemble), さらにそれを必要な単位で合成し (composition), 最終的な Config を得る. (Assemble/Composition translation architecture)
-
-
マルチベンダー・マルチテクノロジーを実現するための重要な構造.
-
断片をテンプレートエンジンにかけて実機の制御コマンドに変換し, それを装置単位で合成する.
-
-
テンプレートエンジンは VOSS 標準実装以外に切り替え可能
-
OpenFlow protocol に変換して openflow device を直接制御することも可能.
-
-
投入も自動化可能
-
openNaEF.activationパッケージには、独自エンジン (Universal Configurator)があります
-
投入エンジンは切り替え可能で、アプリケーションによって各種ツールと連携可能です
-
2axis Time-series
Database
-
OpenNaEFではネットワークサービスモデルのオブジェクトの永続化を、簡潔なコードで実現できる軽量なオブジェクト・データベースです
-
OpenNaEFは独自のオンメモリオブジェクトDBにて動作し、トランザクション処理が可能です
-
OpenNaEFはバージョニングと時間軸の2次元時間軸を持たせることができ、スケジュールに基づくネットワークサービスの設計を可能にします
-
データレプリケーション、冗長化の機能を持ちます
MVO= Multiple Versioning Object
-
オブジェクトデータベースであり、Java 言語から POJO のように簡単に永続化オブジェクトを管理できる
-
日時とともに状態が変化するオブジェクトを自然に扱うことができる
-
変化をトランザクショナルに管理できる
-
複数のデータベースインスタンス間でトランザクションを実施可能 (分散トランザクション)
-
データベースのリアルタイム複製が可能
MVO Database Engine 概要
-
Object Database
-
Java のオブジェクトを透過的に永続化できる
-
-
O/R Mapper のような余計な仕組みが一切不要
-
Time Engineering Support
-
オブジェクトに履歴 (version) を持たせることができる
-
オブジェクトにスケジュール (time) を持たせることができる
-
任意のバージョン、任意のスケジュール時点のオブジェクト状態を取り出すことができる
-
-
Transaction Support
-
オブジェクトに対する変更をトランザクショナルに処理可能
-
複数のデータベースインスタンス間での分散トランザクションをサポート可能 (2PC)
-
-
High Reliability
-
Object Database を複数箇所にリアルタイムで複製可能
-
MVO の時系列管理方式
-
時系列管理したい対象を MVO Entitiy として定義する
-
MVO Entity に MVO Field を与える
-
MVO Field は UML でいう関連/集約
-
-
MVO Field に時間軸を持たせることができる
-
1次元時間軸 (Version 軸) を持つ MVO Field は、バージョンを指定して内容を取り出せる
-
2次元時間軸 (Version 軸× Schedule 軸)を持つ MVO Field は、バージョンないし日時を指定して内容を取り出せる
-
-
MVO は関連をスケジュールに基づき操作するエンジンである
MVO トランザクション
-
アイソレーションレベルは “Serializable”
-
変更不可
-
-
2 つのトランザクションモードをサポート
-
更新トランザクション (read write transaction)
-
データベースインスタンスで同時に 1 スレッドだけ実施される
-
-
参照トランザクション (read only transaction)
-
データベースインスタンスで同時に複数スレッド実施される
-
-
-
Global Transaction
-
Transaction Coordinator が必要。(標準添付)
-
Global Transaction を宣言すると、分散トランザクションが開始される
-
Global Transaction は関係する全データベースインスタンス上で同時に 1 スレッドのみ実施される
-
アプリケーションのバグ等により Global Transaction 処理にデッドロックが発生すると、全データベースインスタンスが事実上停止する。
-
-
スケジュールの競合
-
Overwrite モードと not overwrite モード
-
指定されたスケジュールと conflict を起こすスケジュールが存在したときの振る舞いを規定
-
スケジュールが重複しても TEF は受け入れる
-
-
スケジュール重複チェックはアプリケーションの仕事
-
Overwrite モード
-
指定されたスケジュールで、conflict を起こすスケジュールを上書き
-
-
Not overwrite モード
-
Conflictを起こすスケジュールを変えない
-
-
MVO は Overwrite モードのみサポート
TEF= Time Engineering Framework
TEF とは、MVO Database Engine 上に構築された、時系列管理システムを構築しやすくするための汎用的なアプリケーションフレームワーク。Logic/Shell/HTTP Plugin インターフェースを持ち、動的更新可能。
TEF のメリット
-
MVO 上に構築されている
-
時系列管理システムを容易に構築可能
-
-
開発生産性が高い
-
MVO は Object Database である = 永続化のための特別な仕組みや文法、非本質的な手続きが一切不要
-
Java の言語仕様を活用し、Java の生産性の高さを引き出す
-
標準で shell/HTTP プラグインを持ち、アプリケーションを短時間で構築可能
-
-
連続運用能力が高い
-
動的に差し替え可能なプラグインをサポート、無停止で機能の変更や追加が可能
-
-
障害追跡能力がきわめて高い
-
あらゆる変更をバージョンとして保持、ログとあわせて解析することで、問題が発生したときに原因を 100% 追跡可能
-
100% の障害再現性
-
RDBMS はもとより、他の Object Database にも存在しないメリット
-
更新可能なプラグイン
-
3 種類のプラグインをサポート
-
どのプラグインも動的に差し替え可能
-
-
Logic Plugin
-
動的に差し替え可能なロジックライブラリ
-
サーバを停止せずに機能の追加変更が可能
-
-
インターフェースの追加および変更は不可、インターフェースの実装のみ更新可能
-
Shell Plugin
-
telnet を用いたコマンドラインインターフェースを実装するためのプラグインフレームワーク
-
TEF の機能を利用するコマンドを簡単に記述できる
-
-
HTTP Plugin
-
HTTP リクエストを処理するためのプラグインフレームワーク
-
TEF の機能を利用する WEB アプリケーションを簡単に記述でき
-
Servlet 仕様には対応せず (独自仕様)
-
-
Servlet エンジンと連携することは可能
NaEF= Network A* Engineering Framework
TEF 上にネットワーク管理アプリを迅速に開発できる、ネットワークの様々なロジックを実装したライブラリ。
NAEF Concept
-
ネットワークを素直にモデル化
-
プロトコルモデルをそのままモデルとして表現.
-
-
特殊構成 (Q-in-Q や Virtual Router) も素直に表現.
-
プロトコルを追加するのが容易.
-
-
ネットワークを高度に抽象化
-
あらゆるプロトコルモデルに共通する特徴を抽出して 4 パターンですべてのネットワークを表現.
-
-
新プロトコルも, 既存プロトコルと同じ方法で扱える.
-
素直なモデル化と高度な抽象化を同時に実現している点に NAEF の特徴がある.
超基本要素
-
NAEF には言ってしまえば 6 つしか要素がない.
-
Node
-
Port を束ねる存在.
-
厳密な定義としては「1つのConfigurationで制御される全体」となる.
-
-
Port (If)
-
プロコトルのエンドポイント.
-
物理ポート, 論理ポートを区別しない.
-
-
Link
-
2 つの Port 間を接続する存在.
-
-
Network
-
Port, Link を束ねてネットワーク全体を表現する存在.
-
-
Pool (Optional)
-
Network のグループ. ID 管理を行う. インベントリ管理用.
-
バリエーション
-
Node
-
普通の Node
-
Virtual Node (VM, VR=Virtual Router etc.)
-
Redundant Node (Cluster)
-
-
Port
-
物理ポート (eth-if, atm-if, pos-if etc.)
-
論理ポート (lag-if, atm-pvc-if, ip-if, vpls-if, vlan-if etc.)
-
-
Link
-
物理リンク (eth-link, atm-link etc.)
-
論理リンク (eth-lag-link, vlan-link etc.) ※あまり使わない
-
-
Network
-
VLAN, VPLS, VRF, PseudoWire, IP-Subnet
-
-
Pool
-
VLAN Pool, VPLS Pool, VRF Pool, PseudoWire Pool
-
組み合わせ
-
仮想ノード対応のために特別な組み合わせ方法を追加.
-
Alias
-
-
仮想ノードが持つポートが, 実ノードのあるポートそのものである場合に, 仮想ノード側に Alias を作成し実ポートと接続することで, その関係を表現する.
-
Ex. Fortigate 上の仮想 FW は、親ノードが持つイーサネットポートや VLAN サブインターフェースを, 自身のポートとして管理することができる. この場合, NAEF 上は親ノードの持つ Port に対応する Alias を仮想ノード上に作成することになる.
-
-
動作上の特徴
-
Alias に対する set/get 等の操作は実ポートに対するものとして扱われる.
-
Alias を削除しても実ポートは削除されない.
-
実ポートにつき, それを参照する Alias が存在する限り実ポートは削除できない.
-
-
組み合わせ方法は 4 種類
-
Cross Connection
-
-
横に連結する.
-
Ex. イーサネットポートと VLAN I/F を Untagged VLAN として接続する.
-
-
プロトコルエンドポイントと出口ポートを接続する一般的な方法.
-
Containment
-
-
包含する.
-
Ex. イーサネットポートを LAG にまとめる.
-
-
LAG (APS) しか使っていない.
-
Stack
-
-
重ねる.
-
Ex. イーサネットポート上に VLAN I/F を Tagged VLAN として重ねる.
-
-
プロトコル階層を作る最も一般的な方法.
-
Owner (Children)
-
-
依存関係を作る. (Stack の強い表現)
-
Ex. イーサネットポート上に VLAN I/F (サブインターフェース) を作る.
-
-
依存関係は非常に強い制約となるため, 乱用は危険.
-
仮想ノード対応のために特別な組み合わせ方法を追加.
-
Alias
-
-
仮想ノードが持つポートが, 実ノードのあるポートそのものである場合に, 仮想ノード側に Alias を作成し実ポートと接続することで, その関係を表現する.
-
Ex. Fortigate 上の仮想 FW は、親ノードが持つイーサネットポートや VLAN サブインターフェースを, 自身のポートとして管理することができる. この場合, NAEF 上は親ノードの持つ Port に対応する Alias を仮想ノード上に作成することになる.
-
-
動作上の特徴
-
Alias に対する set/get 等の操作は実ポートに対するものとして扱われる.
-
Alias を削除しても実ポートは削除されない.
-
実ポートにつき, それを参照する Alias が存在する限り実ポートは削除できない.
-
Build a miniature model of
your infrastructure inside NaEF
-
OpenNaEFは管理対象となるネットワーク/インフラのミニチュアモデルを構築することができます。
-
ミニチュア粘土細工を加工する感覚で, ネットワークを加工できる.
-
必要に応じて情報の粒度を変更できる
-
詳細を知りたい場合には, ズームインできる
-
概要を知りたい場合には, ズームアウトできる
-
-
-
VOSS モデルでは, モデルの変更は実機に対する構成変更要求に変換できる.
-
ネットワークミニチュアモデルのおかげで, 変換が極めて容易である.
-
VOSS は, モデルから Config を生成するための標準変換ロジックを提供している.
-
-
モデル編集
-
GUI による編集 (設計先行、将来設計)
-
実機情報を用いた編集 (構成情報収集)=Discoveryサブシステム
-
-
モデル変更通知
-
変更点を config として出力し投入
-
変更点を他システムに通知
-
-
モデルはユーザーの用途に合わせて必要なところは細かく・必要のないところは粗く管理することが可能 (解像度を変えることが可能です)