ブログ GES ネットワークの謎を解明
ネットワークの謎を解明する: リバース エンジニアリングの技術 ネットワークにおいて、リバース エンジニアリングとは、何かがどのように構築されたかを調べてそれをコピーしようとすることではありません (ドイツのエニグマ マシンのように...)
先日、ビジネス要件と CIO の期待を満たすために設けられた厳格な SLA を満たすことについて友人が懸念していることについて、友人と興味深い会話をしました。 私の友人は、グローバル企業のネットワーク インフラストラクチャを管理する IT アウトソーシング会社で働いており、SLA が満たされない場合は多額の罰金に対処しなければなりません。 SLA には、オープン チケットの受け入れ、ネットワークの問題への対応と解決に関する特定のサービス応答時間が記載されています。 アウトソーシングされた IT チームは、計画外のダウンタイムを発生させずにインフラストラクチャのアップグレードとプロジェクトを実装する責任もあります。
同じ古いトラブルシューティング アプローチで今日の SLA を満たすことができますか?
SLA は、従来のトラブルシューティング手法に挑戦する迅速なターンアラウンド タイムに基づいています。 時間の経過とともに、ネットワーク エンジニアは限られた証拠に基づいて仮説を立てなければならないことがよくあります。 通常、トラブルシューティングを開始する場所を決定するためだけに、データの収集と分析にかなりの時間を費やします。 プロセスを自動化して高速化するツールがなければ、エンジニアは多くの場合、問題が切り分けられるまで多くのデバイスにログインするなど、時間のかかる手動の手順を使用することを余儀なくされます。
実際に問題を解決することは、トラブルシューティングの 20% にすぎません。 残りの 80% は、そもそも何が問題を引き起こしているのかを突き止めています。
これらと同じ手動の手順とトラブルシューティングの取り組みは、特に何か問題が発生した場合に、インフラストラクチャのアップグレードとプロジェクトの実装にも適用できます。 ネットワーク チームは、必要で高価なテスト ラボ機器を使用せずに複雑なアップグレードをテストする必要があるだけでなく、提案された変更の影響と、アップグレード中に何が問題になる可能性があるかを理解する必要もあります。 アップグレードまたはプロジェクトの実装の前に、さまざまなシナリオを実行できることは非常に貴重です。
塹壕からの物語: vPC 構成の問題を手動でトラブルシューティングする
私の友人との会話の中で、彼は彼らがデータセンターに実装した最近のスイッチ更新プロジェクトの詳細について話しました. 彼らは、新しい Cisco Nexus スイッチの複数のラックを展開し、仮想ポート チャネル (vPC) を構成していました。 vPC を使用すると、XNUMX つの異なる Nexus スイッチに接続された XNUMX つのリンクが、XNUMX 番目のデバイスには単一のポート チャネルとして表示されます。 多くのメリットがあります。 使用可能なすべてのアップリンク帯域幅を使用し、ループのないトポロジを使用し、スパニング ツリー プロトコルでブロックされたポートを使用しないものもあります。
変更ウィンドウの夜、チームは設計されたソリューションを実装しましたが、運用環境に実装する前にソリューションをテストする能力は限られていました。 設計には、Nexus 9K スイッチのペアごとに異なる vPC ドメイン ID の設定、多数の vPC、およびスイッチの各ペアのポート チャネルの設定が含まれていました。 実装はうまくいったようで、全員が夕方に家に帰りました。
翌日、彼らはチケットで殺到しました。 前日に機能していたものが機能しなくなりました。 彼らは何が変わったのか、どこに力を注ぐべきかを知っていたとしても、前夜に行われた変更の範囲のために、見なければならない変数が非常に多かった.
エンジニアがすべてのスイッチに対して一連のコマンドを実行するために必要な手作業は、何時間もかかることもありました。 NetBrain トラブルシューティング ワークフロー全体を最適化し、タスクを数秒で完了することができます。
これは大規模なデータ センターであり、多くの手動のトラブルシューティング、すべての新しいスイッチへのログイン、および一連のコマンドの実行が必要でした。 彼らはいくつかの構成上の問題を発見しました。 Nexus スイッチの 1 つのペアには同じ vPC ドメイン ID が設定されておらず、スイッチの別のペアにはタイプ XNUMX の設定の一貫性の問題がありました。
実行構成 vpc を表示 すべての仮想ポート チャネルの実行コンフィギュレーションを表示します。 vpc ブリーフを表示 vPC ドメイン ID、ピア リンク ステータス、設定の一貫性チェックなど、仮想ポート チャネルに関する簡単な情報を表示します。 vpc ロールを表示 ピア デバイスの vPC ロールを表示します。 vpc 整合性パラメータを表示 は、仮想ポート チャネル インターフェイス間で互換性がなければならないパラメータを表示します。 キーワード 全体的な ピア リンクの両側にあるすべてのタイプ 1 グローバル パラメータを表示するために使用できます。 すべてのタイプ 1 設定は、vPC ピア リンクの両側で同一である必要があります。そうでないと、アップしません。 ポート チャネルの概要を表示 ポート チャネルに関する情報を表示します。
自動化による vPC の問題のトラブルシューティング
ネットワークの複雑さと規模により、トラブルシューティングと新しいインフラストラクチャの展開の両方に自動化を適用することで、この会社がどのように利益を得ることができるかがわかりました. この XNUMX つの更新プロジェクトでは、多くの問題を特定するために、多くの手動のトラブルシューティングと労力が必要でした。 NetBrain 提案された変更の影響をより適切にテストするためにラボ環境を指すために使用でき、予期しない問題を特定できた可能性があります。
NetBrainの自動化プラットフォームは、ネットワークをインテリジェントに検出し、 Dynamic Map秒。 彼らの runbook このテクノロジーは、Qapps と呼ばれるアクションを実行して構成の問題を見つけることにより、トラブルシューティングを高速化します。 runbook から動作します Dynamic Map. エンジニアがすべてのスイッチに対して一連のコマンドを実行するために必要な手作業は、何時間もかかることもありました。 NetBrain トラブルシューティング ワークフロー全体を最適化し、タスクを数秒で完了することができます。
以下のスクリーンショットでは、 Dynamic Map 発見されたネットワークの runbook vPC 構成情報を収集するために使用されます。
A Dynamic Map vPC 設定全体を数秒で自動的に取得して視覚化します。
以下に、実行された CLI コマンドの XNUMX つの結果と、すべてのスイッチに対して実行する追加の CLI コマンドを簡単に追加できることを示します。
一度に XNUMX つのコマンドで CLI データを収集する代わりに、スイッチごとに、vPC 構成情報を即座に自動的に収集できます。
ここでは、vPC ステータスの結果が表示され、他の関連チャートを開いて追加情報を表示できます。
また、自動化された CLI コマンドの結果をコンテキスト内でマップ上に視覚化し、ワンクリックで他の関連データにリンクできます。
まとめ
SLA は日に日に厳しくなっています。 これらの厳格な SLA を脅かすネットワークの問題が発生した場合、文字通り一分一秒が重要です。 しかし、トラブルシューティングに費やす時間の大部分は、問題を「手動で」特定して切り分けることにいまだに費やされています。 現在、問題の解決を開始できる自動化ソリューションが存在します。これは、必要な深い CLI インテリジェンスを数時間ではなく数秒で提供するソリューションです。
方法を知りたい NetBrain インフラストラクチャ内で使用または適用できますか? 無料を利用してみませんか デモ 自分で見るには？ それでは、時間を節約し、人為的エラーを排除し、最も重要なこととして収益を削減しませんか?
また、次の関連ブログもご覧ください。