ネットワークの自動化。 人生からの事例

おい、ハブル！

今回はネットワークインフラの自動化についてお話したいと思います。小さいながらも誇り高い 1 つの会社で運用されているネットワークの動作図を示します。実際のネットワーク機器との一致はすべてランダムです。このネットワークで発生した、長期にわたる事業停止と深刻な経済的損失につながる可能性のある事例を見ていきます。このケースの解決策は、「ネットワーク インフラストラクチャの自動化」という概念に非常によく当てはまります。自動化ツールを使用して、複雑な問題を短時間で効果的に解決する方法を示し、これらの問題をこの方法で解決する必要があり、他の方法では解決しない理由を (コンソール経由で) 考察します。

免責事項

弊社が主に使用している自動化ツールは、Ansible（自動化エンジンとして）とGit（Ansibleプレイブックのリポジトリとして）です。まず最初に断っておきたいのは、この記事はAnsibleやGitの背後にあるロジックについて解説したり、基本的な概念（例えば、Ansibleにおけるロールタスク、モジュール、インベントリファイル、変数とは何か、git pushコマンドやgit commitコマンドを実行するとどうなるかなど）を説明したりする入門記事ではないということです。また、Ansibleの練習方法や、機器へのNTPやSMTPの設定方法についても解説していません。この記事は、ネットワークの問題を迅速かつ、できればエラーなく解決する方法について解説するものです。さらに、ネットワークの仕組み、特にプロトコルスタックとは何かをよく理解しておくと役立ちます。 TCP/IPOSPF、BGPなど。AnsibleとGitはここでは除外します。具体的なソリューションを検討中の場合は、Jason Edelman、Scott S. Lowe、Matt Oswalt共著の「Network Programmability and Automation: Skills for the Next-Generation Network Engineer」を読むことを強くお勧めします。

さてポイントに。

問題の定式化

状況を想像してみましょう。午前 3 時に、あなたはぐっすり眠っていて夢を見ています。 電話。 テクニカルディレクターは次のように呼びかけています。

- はい？
— ###、####、#####、ファイアウォール クラスターが停止し、起動していません。
あなたは目をこすって何が起こっているのかを理解しようとし、どうしてこんなことが起こり得るのか想像しようとします。 電話では局長の頭髪が裂ける音が聞こえ、将軍が二番線で電話をかけているので折り返してほしいと頼んだ。

XNUMX分後、あなたは勤務シフトから最初の導入メモを集め、起こせる全員を起こしました。 その結果、テクニカルディレクターは嘘をつかず、すべてが現状のままであり、ファイアウォールのメインクラスターが崩壊し、基本的な体の動きで正気に戻りませんでした。 会社が提供するすべてのサービスが機能しません。

好みに合わせて問題を選択してください。誰もが違うことを思い出すでしょう。 たとえば、重い負荷がかかっていない状態で一晩更新した後は、すべてがうまく機能し、全員が満足して就寝しました。 ネットワーク カード ドライバーのバグにより、トラフィックが流れ始め、インターフェイス バッファーがオーバーフローし始めました。

ジャッキー・チェンは状況をうまく説明できます。

ありがとう、ジャッキー。

あまり好ましい状況ではありませんね。

ネットワーク仲間の悲しい思いをしばらく忘れておきましょう。

イベントがさらにどのように発展するかについて話し合いましょう。

資料の提示順序は次のとおりです。

1. ネットワーク図を見て、それがどのように機能するかを見てみましょう。
2. Ansible を使用して、あるルーターから別のルーターに設定を転送する方法について説明します。
3. ITインフラ全体の自動化についてお話しましょう。

ネットワーク図と説明

スキーム

私たちの組織の論理図を考えてみましょう。 特定の機器メーカーの名前は挙げませんが、この記事の目的にとっては重要ではありません。 （注意深い読者なら、どのような種類の機器が使用されているか推測できるでしょう）。 これは Ansible を使用することの良い利点の XNUMX つにすぎません。通常、セットアップ時には、それがどのような種類の機器であるかは気にされません。 理解していただくために、これは Cisco、Juniper、Check Point、Fortinet、Palo Alto などの有名なベンダーの機器です。独自のオプションで置き換えることもできます。

トラフィックを移動するには、次の XNUMX つの主なタスクがあります。

1. 会社の事業であるサービスを確実に公開する。
2. 支店、リモート データ センター、サードパーティ組織 (パートナーおよびクライアント) との通信、および中央オフィスを介したインターネットへの支店のアクセスを提供します。

基本的な要素から始めましょう。

1. 01 台の境界ルーター (BRD-02、BRD-XNUMX)。
2. ファイアウォール クラスター (FW-CLUSTER)。
3. コアスイッチ (L3-CORE);
4. ライフラインとなるルータ（問題解決に伴い、ネットワーク設定をFW-CLUSTERからEMERGENCYに移行します）（EMERGENCY）。
5. ネットワーク インフラストラクチャ管理用のスイッチ (L2-MGMT)。
6. Git と Ansible を使用した仮想マシン (VM-AUTOMATION);
7. Ansible (ラップトップ オートメーション) のプレイブックのテストと開発が実行されるラップトップ。

ネットワークは、次の領域を持つ動的 OSPF ルーティング プロトコルで構成されます。

• エリア 0 – EXCHANGE ゾーン内のトラフィックの移動を担当するルーターを含むエリア。
• エリア 1 – 企業サービスの運用を担当するルーターを含むエリア。
• エリア 2 – 管理トラフィックのルーティングを担当するルーターを含むエリア。
• エリア N – ブランチ ネットワークのエリア。

境界ルータでは、仮想ルータ (VRF-INTERNET) が作成され、その上に eBGP フル ビューが対応する割り当て AS とともにインストールされます。 iBGP は VRF 間に設定されます。 同社は、これらの VRF-INTERNET で公開されているホワイト アドレスのプールを持っています。 ホワイト アドレスの一部は FW-CLUSTER (会社のサービスが動作するアドレス) に直接ルーティングされ、一部は EXCHANGE ゾーン (外部 IP アドレスを必要とする社内サービス、およびオフィスの外部 NAT アドレス) を介してルーティングされます。 次に、トラフィックは、ホワイト アドレスとグレー アドレス (セキュリティ ゾーン) を持つ L3-CORE 上に作成された仮想ルーターに送信されます。

管理ネットワークは専用スイッチを使用し、物理的に専用のネットワークを表します。 管理ネットワークもセキュリティ ゾーンに分割されています。
EMERGENCY ルータは、FW-CLUSTER を物理的および論理的に複製します。 管理ネットワークを参照するインターフェースを除き、その上のすべてのインターフェースが無効になります。

自動化とその説明

私たちはネットワークがどのように機能するかを理解しました。 次に、トラフィックを FW-CLUSTER から EMERGENCY に転送するために何をするかを段階的に見てみましょう。

1. FW-CLUSTER に接続するコア スイッチ (L3-CORE) 上のインターフェイスを無効にします。
2. L2-MGMT カーネル スイッチを FW-CLUSTER に接続するインターフェイスを無効にします。
3. EMERGENCY ルーターを構成します (デフォルトでは、L2-MGMT に関連付けられているインターフェースを除くすべてのインターフェースが無効になっています)。

• 緊急時にインターフェースを有効にします。
• FW クラスター上にあった外部 IP アドレス (NAT 用) を構成します。
• gARP リクエストを生成して、L3-CORE arp テーブル内のポピー アドレスが FW-Cluster から EMERGENCY に変更されるようにします。
• デフォルト ルートを静的として BRD-01、BRD-02 に登録します。
• NAT ルールを作成します。
• 緊急 OSPF エリア 1 に引き上げます。
• 緊急 OSPF エリア 2 に引き上げます。
• エリア 1 から 10 のルートのコストを変更します。
• エリア 1 のデフォルト ルートのコストを 10 に変更します。
• 私たちは変わります IPアドレス、L2-MGMT に関連（FW-CLUSTER にあったもの）
• L2-MGMT arp テーブル内のポピー アドレスが FW-CLUSTER から EMERGENCY に変更されるように、gARP リクエストを生成します。

もう一度、問題の元の定式化に戻ります。 午前XNUMX時、多大なストレス、どの段階でもミスをすると新たな問題につながる可能性があります。 CLI 経由でコマンドを入力する準備はできましたか? はい？ オーケー、少なくとも顔をすすぎ、コーヒーを飲み、意志力を奮い立たせてください。
ブルース、みんなを助けてください。

そうですね、私たちは自動化の改善を続けています。
以下は、Playbook が Ansible の観点からどのように機能するかを示す図です。 このスキームは上で説明した内容を反映しており、Ansible の特定の実装にすぎません。


この段階で、何をする必要があるかを認識し、プレイブックを開発し、テストを実施しました。そして今、それを立ち上げる準備が整いました。

もう一つの小さな叙情的な余談。 話の簡単さから誤解を招いてはいけません。 プレイブックを作成するプロセスは、思ったほど単純でも迅速でもありませんでした。 テストにはかなりの時間がかかり、仮想スタンドが作成され、ソリューションが何度もテストされ、約 100 回のテストが実行されました。

起動しましょう...すべてが非常に遅く起こっているという感覚があり、どこかにエラーがあり、最終的には何かが機能しません。 パラシュートでジャンプしたいのに、パラシュートがすぐに開かない…これは正常です。

次に、Ansible プレイブックの実行された操作の結果を読み取ります (IP アドレスは機密保持のために置き換えられています)。

[xxx@emergency ansible]$ ansible-playbook -i /etc/ansible/inventories/prod_inventory.ini /etc/ansible/playbooks/emergency_on.yml 

PLAY [------->Emergency on VCF] ********************************************************

TASK [vcf_junos_emergency_on : Disable PROD interfaces to FW-CLUSTER] *********************
changed: [vcf]

PLAY [------->Emergency on MGMT-CORE] ************************************************

TASK [mgmt_junos_emergency_on : Disable MGMT interfaces to FW-CLUSTER] ******************
changed: [m9-03-sw-03-mgmt-core]

PLAY [------->Emergency on] ****************************************************

TASK [mk_routeros_emergency_on : Enable EXT-INTERNET interface] **************************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Generate gARP for EXT-INTERNET interface] ****************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Enable static default route to EXT-INTERNET] ****************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Change NAT rule to EXT-INTERNET interface] ****************
changed: [m9-04-r-04] => (item=12)
changed: [m9-04-r-04] => (item=14)
changed: [m9-04-r-04] => (item=15)
changed: [m9-04-r-04] => (item=16)
changed: [m9-04-r-04] => (item=17)

TASK [mk_routeros_emergency_on : Enable OSPF Area 1 PROD] ******************************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Enable OSPF Area 2 MGMT] *****************************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Change OSPF Area 1 interfaces costs to 10] *****************
changed: [m9-04-r-04] => (item=VLAN-1001)
changed: [m9-04-r-04] => (item=VLAN-1002)
changed: [m9-04-r-04] => (item=VLAN-1003)
changed: [m9-04-r-04] => (item=VLAN-1004)
changed: [m9-04-r-04] => (item=VLAN-1005)
changed: [m9-04-r-04] => (item=VLAN-1006)
changed: [m9-04-r-04] => (item=VLAN-1007)
changed: [m9-04-r-04] => (item=VLAN-1008)
changed: [m9-04-r-04] => (item=VLAN-1009)
changed: [m9-04-r-04] => (item=VLAN-1010)
changed: [m9-04-r-04] => (item=VLAN-1011)
changed: [m9-04-r-04] => (item=VLAN-1012)
changed: [m9-04-r-04] => (item=VLAN-1013)
changed: [m9-04-r-04] => (item=VLAN-1100)

TASK [mk_routeros_emergency_on : Change OSPF area1 default cost for to 10] ******************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Change MGMT interfaces ip addresses] ********************
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})

TASK [mk_routeros_emergency_on : Generate gARPs for MGMT interfaces] *********************
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})

PLAY RECAP ************************************************************************

完了！

実際、まだ完全に準備が整っているわけではありません。動的ルーティング プロトコルの収束と、FIB への多数のルートのロードを忘れないでください。 私たちはこれにいかなる影響も与えることはできません。 待ってる。 それはうまくいきました。 これで準備完了です。

そして、ビラバホ村（ネットワーク設定の自動化を望まない）では、皿洗いを続けています。 Bruce 氏 (確かに、すでに変わっていますが、それでもクールなわけではありません) は、機器の手動による再構成がどの程度必要になるかを理解しようとしています。

また、一つ重要な点についてお話ししたいと思います。 どうすればすべてを取り戻すことができるでしょうか? しばらくしてから、FW-CLUSTER を復活させます。 これはバックアップではなくメインの機器であり、ネットワークはその上で稼働する必要があります。

ネットワーカーがいかに燃え尽き始めているかを感じますか? テクニカルディレクターは、なぜこれをすべきではないのか、なぜ後からできるのか、何千もの議論を聞くことになるでしょう。 残念なことに、これはネットワークが、かつての豪華さのパッチ、断片、残骸の束からどのように機能するかです。 パッチワークキルトになります。 この特定の状況ではなく、原則として、IT スペシャリストとしての私たちの一般的なタスクは、ネットワークの仕事を美しい英語の「一貫性」という言葉で表現することです。これは非常に多面的で、「一貫性」と訳せます。 、一貫性、論理性、首尾一貫性、体系性、比較可能性、首尾一貫性。 それはすべて彼に関するものです。 この状態でのみネットワークは管理可能となり、何がどのように機能するかを明確に理解し、何を変更する必要があるかを明確に理解し、必要に応じて問題が発生した場合にどこに問い合わせるべきかを明確に理解します。 そして、そのようなネットワークでのみ、今説明したようなトリックを実行できます。

実は設​​定を元に戻す別のPlaybookが用意されていました。 操作のロジックは同じです (タスクの順序が非常に重要であることを覚えておくことが重要です)。すでにかなり長い記事を長くしないために、プレイブックの実行のリストを投稿しないことにしました。 このような演習を行った後、将来的にははるかに穏やかになり、自信が持てるようになります。さらに、そこに積み上げた松葉杖はすぐに明らかになります。

誰でも私たちに手紙を書くことができ、書かれたすべてのコードのソースとすべての palybook を受け取ることができます。 プロフィールの連絡先。

所見

私たちの意見では、自動化できるプロセスはまだ具体化されていません。 私たちが遭遇したこと、そして西側の同僚が議論していることに基づいて、これまでのところ次のテーマが見えてきます。

• デバイスのプロビジョニング。
• データ収集;
• 報告;
• トラブルシューティング;
• コンプライアンス。

興味があれば、指定されたトピックの XNUMX つについてディスカッションを続けることができます。

自動化についても少しお話したいと思います。 私たちの理解では、それは次のようにあるべきです。

• システムは人なしでも存続し、人によって改良されなければなりません。 システムは人間に依存すべきではありません。
• 操作は専門家でなければなりません。 日常的なタスクを実行するスペシャリストのクラスはありません。 ルーチン全体を自動化し、複雑な問題だけを解決する専門家もいます。
• 日常的な標準タスクは「ボタンを押すだけ」で自動的に実行され、リソースが無駄になることはありません。 このようなタスクの結果は常に予測可能であり、理解可能です。

そして、これらの点は次のことにつながるはずです。

• IT インフラストラクチャの透明性 (運用、最新化、実装のリスクが少ない。年間のダウンタイムが少ない)。
• IT リソースを計画する機能 (キャパシティ計画システム - 単一システムでどれだけのリソースが消費されているか、どれだけのリソースが必要かを確認できます。手紙やトップ部門への訪問によってではありません)。
• ITスタッフの数を削減できる可能性。

記事の著者: Alexander Chelovekov (CCIE RS、CCIE SP) および Pavel Kirillov。 私たちは、IT インフラストラクチャの自動化をテーマとしたソリューションについて議論し、提案することに興味があります。


出所： habr.com