Upload
taiji-tsuchiya
View
1.097
Download
1
Embed Size (px)
Citation preview
なぜネットワーク運用自動化が進まないのか
Whitebox Switch編
BIGLOBE Inc.
Taiji Tsuchiya
ホワイトボックススイッチユーザ会 第一回勉強会 1 2015/5/13
Introduction
• 土屋 太二(Taiji Tsuchiya)– 28歳– Twitter:@taijijiji
• お仕事– ネットワークエンジニア– 2011年 : DCネットワークの運用– 2012年 : 自社SDNシステムの開発– 2013年〜現在: コアネットワークの運用
2 2015/5/13
ネットワーク運用のお仕事
• ルータの設定• 設定手順書の作成• トラフィック制御• ネットワーク資源や構成情報の管理• 機器の増強、廃止、リプレイス• 回線やDCラックの調達
3 2015/5/13
ネットワークの自動化事情
• サーバインフラと比べて自動化が進んでない
• Immutable InfrastructureやInfrastructure as codeとは別世界
• 今日は「どうしてこうなった?」話をします
4 2015/5/13
Manufacturer OS
Cisco
IOS (IOS-‐XE) IOS-‐XR NX-‐OS
Juniper JUNOS
Brocade NetIron
Network OS Arista EOS
_人人人人人人人人人_ > メーカー独自のCLI <  ̄Y^Y^Y^Y^Y^Y^Y^Y ̄
6 2015/5/13
Manufacturer OS API
Cisco
IOS (IOS-‐XE) • OnePK(*) • NETCONF
IOS-‐XR • OnePK(*) • NETCONF
NX-‐OS • OnePK(*) • NX-‐API(*) • NETCONF
Juniper JUNOS • JUNOS XML Protocol(*) • REST API • NETCONF
Brocade NetIron • NETCONF
• REST API Network OS Arista EOS • eAPI(REST API )
(*) メーカ独自API ※1 最新OSの対応状況ですが、Versionによって大きく異なります。 ※2 ネットワーク装置の場合「バグの枯れ」を重視するため 最新OS versionを導入するケースはほとんどありません。
8 2015/5/13
さくらインターネット 湯澤 民浩さん資料より引用 Internet Week 2014 ようこそ、ネットワーク運用自動化の世界へ! https://www.nic.ad.jp/ja/materials/iw/2014/proceedings/s4/
結果的に、装置ごとに異なる制御モジュールが必要になる
9 2015/5/13
影響範囲
• サーバ : 数サービス 通信断
• DC系スイッチ : 数十サービス 通信断
• コア系ルータ : エリア 全断
_人人人人人人人人人人_ > 失敗したら総務省 <  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y ̄
11 2015/5/13
エンジニアの得意領域
ネットワーク屋• ルータCLIマスター• Cisco/Juniperなんでも来い
• パケットに強い• トラフィック制御が得意
サーバ屋• Linux/Unixマスター• Ubuntu/FreeBSDなんでも来い
• DBやWebサーバに強い• LL言語が得意
自動化開発に 必要なスキルはこちら
13 2015/5/13
ネットワークエンジニアの文化
• 染み付いたCLI文化• インフラの分業化によって、入社時からCiscoスペシャリストを目指しがち
• 技術革新がとても遅く、実装はメーカ次第• 開発者 = メーカの人
15 2015/5/13
作業量• サーバ:
– 数千〜数万台– 1台あたりの作業頻度: 週に1-2度
• ネットワーク機器:– コア: 数十台– データセンタ 数百〜数千台– 1台あたりの作業頻度: 数ヶ月に1度
17 2015/5/13
自動化しやすい作業もある
• ルータ操作以外の運用業務もたくさん– ルータを設定– 設定を入れるための手順書を作成– トラフィック制御– ネットワーク資源や構成情報を管理– 機器の増強、廃止、リプレイス– 回線やDCラックの調達
• ルータの自動操作は難しいが状態取得はSNMPを使えば比較的容易
21 2015/5/13
開発の敷居が下がってきた
• Webフレームワーク– Python : Django, Flask– Ruby : Rails
• 構成管理ツール– Chef– Ansible– Fabric
• テストツール– Serverspec– Infrataster
22 2015/5/13
NETCONF(Network Configuration Protocol)
• XMLを利用したルータ管理プロトコル
• RFC6241で標準化• 業界の標準的なAPIを作る目的
• 現時点ではメーカごとにXML記述が異なる– YANGモデル対応が一つの鍵
24 2015/5/13
Open Daylight
• Linux FoundationのOSSプロジェクト• SDNコントローラプラットフォームを協業開発• 主要なネットワーク機器メーカやサーバメーカが参加
25 2015/5/13
Whitebox Switch
• ODMベンダ製スイッチ– ソフトウェアOSはユーザ自ら選ぶ
• クラウドやコンテンツ屋のニーズから登場
• 実態は、ネットワーク機能のあるLinuxサーバ• サーバと同様の管理ツールを利用可能
26 2015/5/13
Whitebox Switchに期待していないこと
• 既存装置をすべてWhitebox Switchに置き換える、というアイディアは全く無い。
• 数台の購入だとそこまで安くない。運用コスト、開発コストも考慮
• 今導入しても、制御モジュールが増えるのでそこまでうれしくない
27
管理 サーバ
IOS JUNOS IOS-‐XR Arista EOS NetIron Whitebox Switch
IOS用 SSH
JUNOS用 Netconf
IOS-‐XR用 Netconf
REST API NetIron用 Netconf
Ansible ?
2015/5/13
• Whitebox登場によるメーカの変革に期待– ネットワーク装置の全機能を外部サーバから制御できること
– メーカ間で差分のない制御方法があること– 標準的なサーバ用ツールが流用できること
• 業界標準の制御方法が確立されれば対応可否が、機器選定基準になり得る
28
Whitebox Switchに期待していること
2015/5/13
想定シナリオ(架空)
• 運用チーム5名から、2名を開発に• 運用チーム補強のため1名を助っ人増員• 開発期間は1年間• 開発が完了すれば運用工数が2/3に• 開発終了後、保守が0.5人月が発生• 1人月100万円で計算
30 2015/5/13
開発コスト vs 運用コスト
31
0
20
40
60
80
100
120
140
160
180
200
0 6 12 18 24 30 36
運用5名体制の場合
運用4名+開発2名体制の場合
百万円
ヶ月
期間
費用
開発期間(12ヶ月)
損益分岐点
運用:3+1名 開発:2名
運用:3名 保守:0.5名
開発:1.5名
• 工数削減 • 納期改善 • オペミス削減
2015/5/13
• 顧客ニーズにあったネットワーク機能を開発する
• 新しいネットワーク機能やOSSツールを積極的に試して導入していく
• ネットワーク運用のかゆいところに手の届くツールを自分たちで開発していく
32
開発:1.5名 で新しいことを始める
2015/5/13
BIGLOBE コアネットワークチームの取り組み
• 2014年からチーム内でのPython勉強会を週一で開催
• 全運用メンバがツール開発をマスター• 外注ゼロの内製開発でノウハウを蓄積中• 成果物の公開できる部分を切り出してOSS化を検討中
33 2015/5/13