u-ichi

twiter: u1

mail: yuichi.u@gmail.com

自己紹介

名前 u-ichi/u1

植村優一

twitter

http://twitter.com/u1

所属 NTTコミュニケーションズ

今年7月まで大規模ネットワーク(非OCN)の運用を5年やってました。 7月からホスティングサービスを提供する側へ異動・・・

今回はネットワーク運用の現場でRuby使って闘ってきた時に大事だと感じた点を共有します。

なぜRubyでネットワーク運用なのか？

ネットワークを監視しようとした場合・・・

ネットワーク監視だけなら汎用製品使う場合が多いです Hinemos,ZABBIX,JP1,NNM,Tiboli,Cm2,BMC,WebN

MS,etc…

装置の死活監視したり、リソース見たり

でも監視以上の事はあまり得意ではありません

×外部の死活監視の仕組みと連携して自動切替をさせたりとか

×帯域の空きが無くなってきたら、空いてるところにトラフィックを自動で逃がすとか

ネットワーク装置単体の運用ではなく、1つのシステムとして運用をするためには

運用システムの作り込みが必要

もう一つのアプローチとして、システムにあわせる形でネットワークを作り上げるというのもあるけど、今回は割愛

でも最初からどう使うのかを全て想定して運用システムを作り込むのって難しい

特にネットワークをサービスとして提供する立場だと、ユーザ数の増加/ユーザ要望の変化によって

ネットワーク構成/要件が変化するのはよくあること

変化を受け入れる事が重要

変化を受け入れられる力が欲しい

そこでruby！

ネットワーク運用(主に保守側)に欲しい事

通常時

ログ監視(swatch等)

装置の定期的な正常性確認(ping,snmpwalk等)

故障/トラブル発生時

装置状態/ログの取得

取得した情報の解析

装置の操作(復旧作業)

etc…

←本LTでのカバー範囲

装置状態を取得するには

情報取得の方法 snmpget,snmpwalk,snmpbulkwalk

telnet/ssh

取得する上で大変な点装置台数は数百台以上、時には数千台でも1台の取得だけで1分以上かかる時も

処理プロセスのマルチスレッド化は必須！

装置をコントロールするには

基本的にコントロールはtelnet/ssh経由でコマンドで実施

装置種別/OS毎にclassライブラリを作成

よく使う命令はテストを十分に施してメソッド化

装置のコントロールは検証がとれたメソッドを組み合わていく形で実施する

router = Cisco.login(“rubykaigi01_router”)

router.interface(“Gi0/1”).shutdown

routers = [Cisco.login(“rubykaigi01_router”),

Cisco.login(“rubykaigi02_router”)]

threads = Array.new

routers.each do |router|

threads << Thread.new do

router.get_interfaces_counter

router.interfaces.each do |interface|

if interface.rx_counter == 0

interface.shutdown

end

end

end

end

threads.each do |thread|

thread.join

end

例として、rxカウンタが0なインタフェースを全てshutdownさせてみる

ルータのインタフェースとトラフィック値を取得するメソッド

該当カウンタ値が0ならば、イ

ンタフェースをシャットダウンさせる

各装置毎に平行して処理を実施

スレッドの処理終了待ち・・・

作ったシステムのテストは凄く重要

でも・・・ 他装置との試験は時間がかかるし、準備も大変

装置のOSが新しくなる度に再試験が必要

そもそも柔軟な対応を現場でやりたいからシステムを内製してる

必要なのは・・・

「テストを管理/自動化出来る仕組み」「単体テストが可能な設計」

テストを管理/自動化出来る仕組み テストケースの記述にrspecを利用

ラボでの試験もrspecで記述

日本語でケース書けるので後から凄く見やすい

describe "xxx構成の場合" do

before(:each) do

# ラボのネットワーク構成を作成するスクリプトを書くend

describe “100回繰り返して負荷試験を実施する場合" do

before(:all) do

# 繰り返し処理をする内容を書く。ネットワークの切替とか。end

it "装置状態が正常な事" do

# 実際はもっと細かい精度で。(トラフィックカウンタとか)

end

end

end

単体テストが可能な設計

装置アクセス部と結果解析部を分割 装置アクセス部のテストはラボのみで実施させる

結果解析部のテストはautospecを用いて自動テスト

○ 時間がかかる装置アクセス部のテストを実行している時間で結果解析部の開発が出来る

開発時間の大幅短縮に繋がる

まとめ

急激な変化に対応しなくてはいけない運用の現場でRubyはすごく役に立つ！

現場でコードを書く時も、テストの自動化は大事

rspec使ってネットワーク(サーバも)装置の検証も書くと後から読みやすいのでオススメ！

運用現場でコーディングをもっとして、エンジニアの価値を高めよう！