パート１では、ネットワークコントローラー、SDNコントローラー、およびブロードキャストコントローラーの違いと、オーケストレーション・プラットフォームが必要な理由についてお話ししました。
オーケストレーションをプロジェクトに効果的に展開するには、様々な観点から対処する必要があります：
1. オンボード
2. プラン
3. 制御
4. 監視
このブログでは、ステップ1：オンボーディングについて見ていきます。
何をする必要がありますか？
機器を本番環境で使用する前に、すべてのリソースを自動化された安全な方法でオンボード*¹することが最も効率的です。
*¹オンボーディングとは、システムやネットワークに新しいリソース（例えば、デバイスやサービス）を登録し、利用できるように準備するプロセスを指します。特に「安全なオンボーディング」とは、新しいリソースがセキュリティを確保した状態でシステムに接続され、正しく認証・設定されることを意味します。これにより、不正アクセスやセキュリティリスクを防ぎ、システム全体の信頼性を高めることができます。
まず、スイッチ、メディアエッジデバイス、およびその他の物理的およびバーチャル・インフラストラクチャを検出する必要があります。これには、ネットワークスキャンやサードパーティのCMDBデータベースとのインターフェース、さらにはNMOS IS-04レジストリを利用することが考えられます。また、ソリューションがインフラストラクチャを検出するだけでなく、LLDPプロトコルを介してネットワーク接続を抽出することも重要です。
次に、オーケストレーターが初期の基本設定を適用し、各リソースが正しいファームウェアとソフトウェアを実行していることを確認します。このプロセスでは、データソースの標準認証情報が更新されているかどうかを確認するなど、いくつかの自動チェックを実行することも可能です。
オンボーディングプロセスの結果、オーケストレーターは使用可能（“使用準備完了”）なリソースのリストを管理します。オンボーディングプロセスが成功した後でも、リソースの使いやすさに影響を及ぼす要因が多く存在することは重要なポイントです。 オーケストレーション・プラットフォームはこのコンテキストを保持し、各リソースのステータスを常に更新します。
「使用準備完了」ステータスに影響を与える要素の例をいくつか挙げます：
・健康状態（例：故障したデバイス）
・計画されたメンテナンスの時間帯（例：予定されたファームウェアの更新）
・デバイスの接続状態（例：接続断）
・セキュリティ侵害（例：アプリケーションの脆弱性）
・権限（例：信号に対する時間制限）
・ライセンス状況（例：従量課金型のインフラ）
・健康状態（例：故障したデバイス）
・予測されたアラーム（例：AI予測エンジンによる）
・検出された異常（例：AI行動異常検知アルゴリズムによる）
これらの要因が、「使用準備完了」状態に影響を及ぼす可能性があります。
なぜこれが必要なの？
1. すべてのリソースに対する情報が一つの信頼できるソースから取得するため
*単一の信頼できる取得源を持つことは、業務の効率化やリスク管理において非常に重要です。
2. オンボーディングプロセスを自動化することで、一貫性を実現するため
3. 自動化によりセキュリティが向上し、人的エラーが減るため
ブログのパート１でご覧いただいたように、オーケストレーションプラットフォームは多くの役割を担うことができます。時には、SDNコントローラーおよび／またはブロードキャストコントローラーの役割を同時に果たすこともありますし、他のSDNコントローラーやBCコントローラーとインターフェースすることも可能です。どの組み合わせが最適かは、プロジェクトやニーズによって異なります。
SDNおよびBCコントローラとのスムーズな統合を実現するには
まず、オーケストレーターは使用可能なリソースリストと（オプションで）ネットワークトポロジーをAPIを介してブロードキャストコントローラーおよびSDNコントローラーと共有する必要があります。
次に、IPアドレスの管理も重要です。オーケストレーターはIPアドレスおよびマルチキャストIPアドレスのレンジを管理できる必要があり、それらをコントローラーと共有することで、SDNコントローラーやBCコントローラーが直接管理する機器（例えば、IPマルチキャスト送信アドレスを必要とするソースデバイス）に対して、それらのアドレスを使用し適用できるようになります。
次回、パート3では、ステップ2：プランについて取り上げていきます。
Skyline Communications 『DataMiner』製品ページは[こちら]
デモや見積もりのご依頼、製品に関するお問い合わせは [こちら]
