CLIベースのNW自動化に伴う情報管理あれこれ

memo

しばらく blog かいてなかったですな…。ちょっとお仕事的に過去のあれこれを思い出したので書いておきます。

従来のネットワーク機器、ネットワークシステムに対して、いろいろと操作を自動化したい場合

  • 現在のステータスを自動的に取得して整理・整形・可視化したい
  • 物理的・論理的な構成変更要求に対して、一部または全部の操作を自動実行したい

みたいなことがありますよね。よくやるのが、設定情報やコマンド塔をあらかじめ用意して(テンプレート化して)、実行時にパラメータを埋め込んでコマンドを生成し、telnet/ssh などで機器へ自動投入する、みたいな話じゃないかと思います。

こういう話について、設定(コンフィグ)生成のための情報をどう持ってどう管理するか……というのはまあ状況によりけりだとは思いますが……形はどうあれ、何らかのデータストアを持つようにしたりしますよね。たとえば私が過去にやったことがあるのだと、Excel でネットワーク機器のパラメータシートを作ったら、記入されたパラメタを元に L2/L3 スイッチのコンフィグを生成するマクロを作ってみたりとかをやったことがあります。もうちょっと頑張って、Excel をパラメタ一覧として作って、それに機材の情報(コンフィグ生成のためのメタデータ)も含めておいて、コンフィグテンプレートを自動的に組み合わせ、もうちょっといろんなコンフィグを自動生成する……というのも見たことがあります。大きなシステムを扱っているところだと、構成管理データベース(CMDB)みたいなのを用意して、そこの情報を元に操作の自動化(そのためのコマンドやコンフィグの生成)なんてことをやってたり、というのもあるでしょう。

で。

こうした「人にとってわかりやすい台帳情報(情報形式、インタフェース)」あるいは「人にとってわかりやすいポリシ定義」を「実際に機材に入れるコマンドや設定情報」に変換・デプロイするようなケースでは、たいていこういう問題点がくっついてきます。

  • 元のポリシデータ → 設定情報生成 → 実機(ネットワーク実体)へのデプロイという操作フローについて
    • フローが一方校で固定されなければいけない(これ以外の設定フローを例外として認められない)
    • 設定情報の配布によって生じるエラーハンドリングが正しく実行できなければいけない

「一方向」も「エラーハンドリング」もどちらも似たような話なんですが。

  • 誰かが実機を直接操作する、みたいなことをしちゃった瞬間に、元のポリシ・台帳・インベントリ情報と「実体」との内容に乖離が生じてしまう。
    • トラブル対応とか緊急性が高いような状況でのオペレーションってどうするの?
      • 手でいじれないほど複雑だったり大規模だったりするようなシステムなら、必ず「設定自動化システム」を通して操作を行うというのは守るかもしれないけど…
      • でも「一方向」を常に厳守していたのにトラブルが起きたとしたらどうだろう? 明確に台帳上の設定パラメータがおかしいみたいな原因が見当たらなかったとしたら? どこかでその自動化システムまで含めたところに問題がある…「設定自動化システム」自体にバグがある、みたいなところも疑うよね。となると緊急時の手動・直接操作対応って選択肢はやっぱり出るんじゃないか?
      • 「設定自動化システム」自体のテストはパーフェクトに行えていて通常のオペレーションではバグがあり得ない…というところまでやれてたりする? 「自動化システム」のテストやデバッグ作業って何をどうやって、どこまでやる?
  • 投入したい設定情報が全部確実に設定できるか・設定ロールバック問題
    • ネットワーク機器の場合、たとえば ssh session 落ちちゃって、処理が中断しちゃうとか、そういったエラーが発生するなんてことが考え得る。実際、何かしらの都合で処理が完全に終わらない・エラーが起きて中断する・みたいな状況が起きることがある。
    • 実際のシステムに対するオペレーションを考えれば、複数の機材をまたいで「やりたいことの業務フロー」が構成されているわけで、じゃあ複数のネットワーク機器のうち一つでこうした問題が起きたらどうしたらいいのだろう? というのを考えないといけない。
    • 多くのネットワーク実機操作において、そうしたエラー処理を適切にハンドルさせるのは非常に難しい。CLI なら終了ステータスとか見ればいい? 本当にそのコマンドが適切に終了ステータスやエラー状態を入れてくれてる? 結局エラーメッセージを正規表現で引っかけてごにょごにょやったりするんだよね…。これはものすごく面倒くさいし、エラーハンドリング実装がさっぱり拡張性がない。
    • 実際問題、CLI操作のほとんどがステートレスだし、DBクエリみたいにエラーが起きたらロールバックできる、みたいな話もない。トランザクション処理とかできたらいいなあと思うんだけどね…実体操作の中でそうした処理を入れるのはすごく難しい。コマンド投げればそれで動いちゃうしね。よくても特定の機器に対する操作(一つのデバイスに対する操作)だけで、複数の機器を順に設定変えていくような、もうちょっとシステム全体に関わるような操作についてだとさらに難しい。
      • netconf/YANG とか REST とかへの期待にはこの辺の観点があるよね。Command transport の信頼性、送受信データ(エラー情報含む)の構造化と処理…

などなど。

どうしても実体(実機)と管理している情報…台帳? CMDB? 各種インベントリ情報? の不整合が問題になる。だからたいてい <台帳→実体> というだけでなくて <実体→台帳> という双方向の操作が必要になる。ということで、実機の config 集めてきて、parse して、パラメータシート(CSVとか)に落とすみたいなスクリプトを書いたりしたこともある。

ただ、双方向にやれるようにしても、これはこれでやっぱりいろいろやっかいなところがあるんですよね。

  • 情報同期タイミングをどう設定するか。マスターデータをどれにするか。
    • 誰が、どのタイミングで、どっちの情報を参照すべきなのか? 今この機材に設定されているこの情報は「正しい」のか?
    • 結局取れる情報が機材(ハードウェア)ごと、バージョンごととかで違ったりするので、そうしたバリエーションをどうやって吸収していくか…
  • ビュー/汎用性の選択肢と実装コスト
    • 同じような情報が、違う見方で、異なるドキュメントにあり、相互に情報の整合性がとれていなければならないというものがある。
    • 使う機材・機能・設定などそれぞれに合わせて、input/output したい情報が変わるわけで、案件ごととかシステムごととかで作ってそれで終わりになってしまいがち。汎用的な話にしにくい。
      • 汎用性を考えようとすると、そもそもベンダごと・製品ごとに使える機能や管理情報(情報モデル)がことなるわけで、個別の管理データの話をたくさん集めて積み上げていかないといけない。異なるベンダの製品を共通のデータモデルでやりとりできる…というところも実際できていないし、特定製品の特定機能を使うケースだと、どちらにしろ個別にどうにかしないといけないだろうし。
      • いろんな情報を扱える管理用の市販製品(CMDB etc)もあるけど、たいていすごく高額で、見合うようなシステム規模がないと採用しにくい。(製品機能の何割もつかえてないとかになりがち。効果とコストのバランス取るのが難しい。)
  • 物理実体の管理情報ってそもそも電気的・ネットワーク上で情報取れないって話が出てくる。
    • どのラックに何がおいてあるみたいな話を自動的で取れるかというと難しいよね。台帳上機材があるからって見に行ったらだいぶ前に故障して撤去されてた…とか。(→ マスターデータ問題、情報同期タイミング問題)
    • ネットワークケーブルのパッチパネルの情報とかもね。(高いパッチパネルだとパッチ間の接続情報取れるようになってるのもあるけどねえ)
      • ケーブルラベルはがれてる…とかあると泣きそうになるよね。あげくオペミスして断線・障害発生、とか。私は過去パッチ接続をミスってDCでアラート飛ばしたことがありますね。
    • ファシリティ系とか、通信回線系とかの情報管理とかね。

まあぐだぐだ書いてみましたが特に結論があるわけでもないです。なかなか一筋縄ではいかないですよね、という話でした。