SDN 時代におけるネットワーク自動化の 5 つの課題

人間の次元

「ネットワーク自動化」と聞くと、多くの場合、次の XNUMX つの反応のいずれかが起こります。 「価値がない」と言うか、「私の仕事を奪おうとしている」と思うかのどちらかです。 最初のケースでは、ネットワーク管理者は、多額の費用を費やしても、投資に対する利益はあまり得られないと考えています。 彼らは、さらに別のソリューションを購入したり、新しい方法を見つけたり、別のスクリプトを書いたりすることを考えたくありません。 一方、一部のネットワーク エンジニア (通常は第 XNUMX レベルの NOC 担当者) は、「自動化」という言葉を聞くと「仕事の削減」と聞きます。

しかし自動化 is それだけの価値があり、あなたの仕事を奪うことはありません。 自動化によって、価値のない仕事が奪われます。 自動化によって人々の仕事がなくなることはありません。 しかし、誰もやりたくない行き止まりの作業をすべて排除します。 全員の時間を解放して、よりやりがいのある仕事に取り組むことができます。

スクリプト

今日のネットワークでは、スクリプトだけでは十分ではありません。 Python や Java スクリプトを書いたことがある人なら誰でも、スクリプトに関するネットワーク自動化の最大の課題はスクリプトを書くことではないことを知っています。 それはそれらを維持することです。 一度スクリプトを作成したものの、ネットワークが変化すると、多くのデバッグが必要になってしまいます。 そして、そのスクリプトを他の人と共有するのはそれほど簡単ではありません。

今日でも、ネットワーク担当者がプログラマーになる必要があるという話をよく耳にします。 私たちがネットワーク エンジニアから開発者、またはネットワーク自動化のソリューションに移行することが自然な動きであるとは思えません。

いつボタンを押すか？

「いつボタンを押すか」とはどういう意味でしょうか。自動化では、一度書いてプッシュすれば、すべてが自動的に処理されると考える人がいます。しかし、現実の世界では、そのようには機能しません。トラブルシューティング、変更管理、セキュリティなど、どこかの誰かが自動化をトリガーする必要があります。夜中に停電が発生した場合、誰が問題を診断する自動化を起動するのでしょうか。そして、いつ起動するのでしょうか。今日、これは私たちが解決しなければならない大きなネットワーク自動化の課題です。

ハイブリッド ネットワークへの適応

We 　 ハイブリッドになります。 好むと好まざるとにかかわらず、ACI、NSX、およびその他の SDN データ センターがさらに増える予定です。 さらに SD-WAN が登場します。 私たちが慣れ親しんだ従来のネットワークは、頭を抱えたばかりで、もはや十分ではありません。 従来のネットワークでの自動化のほとんどについて、「XNUMX 回作成したら XNUMX 回使用」しますか? それは今日、私たちが常に直面していることです。 「よし、従来のネットワークの自動化を新しいネットワークから分離しよう」と言うかもしれません。 しかし、交通の流れはどうですか？ 従来のネットワークから SDN への移行が遅い場合、どのように対処しますか? そのため、ハイブリッド ネットワーク内で自動化する方法を理解する必要があります。これは、マルチベンダー ネットワークでも同じことです。

すでに多くのツール (またはソリューション) があります。 しかし、各ツールは独自の言語を話します。 それらは独自の「データ アイランド」です。 侵入検知システムと通信しないイベント管理ツールなどと通信しないパフォーマンス監視ツールがあります。 必要なすべての重要な情報は、まとめて、データ サイロ内で互いに分離されています。

では、これらの課題をどのように克服するのでしょうか? ハードウェアのアップグレード、ソフトウェアの変更、人員の入れ替えを試みましたが、これらは解決策ではありません。 異なる考え方の自動化が必要です。 アダプティブ オートメーションが必要です。

アダプティブ オートメーション

アダプティブ オートメーションの概念は何も新しいものではありません。 機械工学の分野には、コンピューター支援設計 (CAD) ソリューションがあります。 エレクトロニクス業界には EDA (電子設計自動化) があります。 ネットワーキングにも同様のものがあります。私たちはそれをアダプティブ オートメーションと呼んでいます。 その背後にある考え方は、複雑なネットワーク内で実行する必要があり、さまざまなデータ アイランドを統合する必要があるタスクが多数ある場合、問題を解決するには XNUMX つのことが必要であるということです。

XNUMXつは地図です。 CAD または EDA では、ダイアグラム (またはマップ) は実際には、物事を視覚的な形式で抽象化するデータ モデルです。 したがって、タスクを抽象化するにはマップが必要です。 マップを使用すると、 スコープ あなたの仕事の。

パズルのもう XNUMX つのピースは、 runbook – スクリプトではありません – 必要なことを整理できるようにします。 の runbook 定義することができます ステップ あなたの仕事の。

一緒に、マップはネットワークを文書化するという考えを実現し、ネットワークの単一のガラスのビューを作成します。 runbook 「ジャスト イン タイム」の自動化と「一度書けばどこでも実行」機能を実現します。

このアダプティブ オートメーションは、上記の 5 つの課題に対して、一度に XNUMX つのタスク、一度に XNUMX つのステップで、ネットワークの自動化に対処します。 これがどのように見えるかの例を見てみましょう。

アダプティブ オートメーションでのワークフローのトラブルシューティング

イベント コンソールで通知を受け取ったとします。たとえば、アプリが遅いという ServiceNow のチケットです。 アダプティブ オートメーション フレームワークでは、最初に「ジャスト イン タイム」の自動化が API を介してトリガーされ、 Dynamic Map その遅さ。 そして「レベル0診断」 runbook は自動的に動作を開始して、パフォーマンス データ、CLI コマンド データ、またはパフォーマンス管理ツールからのデータを収集し、その情報を ServiceNow チケットに添付します。 これらはすべて、速度の低下が検出されたとき (たとえば、真夜中に) イベントが作成された瞬間に自動的に行われ、人間による介入は必要ありません。 (これが「レベル 0 診断」と呼ばれる理由です。) これがステップ 1 です。

ステップ 2: 朝、会社に着くと、真夜中に作成された ServiceNow があります。 ここで、さまざまな速度低下パフォーマンスまたは QoS トラブルシューティングを実行します runbookNS。 これらは Runbookは、上級ネットワーク エンジニアによって、ドメイン知識と主題の専門知識の両方のノウハウに基づいて作成されました。 必要に応じて、レベル 1 エンジニアは問題をレベル 2 または 3 エンジニアにエスカレーションできます。 チケットがエスカレーションされると、レベル 1 エンジニアが行ったすべての内容が runbook そのため、次のレベルのエンジニアが一からやり直して、同じ基本的な診断を再実行する必要はありません。 問題をより深く掘り下げるために、24 つの画面を活用して、他のすべてのツール (Splunk、ログ ファイル、7 時間 XNUMX 日パフォーマンス監視ソリューション) からの情報を確認できます。

問題を特定したら (これがトラブルシューティング時間の約 80% を占めています)、問題を修正できます。 修正は非常に簡単です。おそらく QoS 設定を変更し、トラフィックを再ルーティングします。 また、変更をプッシュするだけでなく、それらの変更の影響を自動的に検証できる自動化ツールもあります。 これは実際には、変更を自動的にプッシュするよりも重要です。

その後、アダプティブ オートメーションを使用すると、この問題の進行をプロアクティブに監視できるため、問題が再び発生した場合 (おそらく発生する可能性があります)、対処方法について誰かが決定するのを待つことなく、すぐに問題を把握できます。 レベル 2 エンジニア ツールを成文化できる手順は、 runbook 24時間年中無休の実行で自動的に実行するようにトリガーできます。