エンタープライズにおけるOpenFlowユースケースを考える

自己紹介

▸ Clorets8lack

▸某ユーザー企業の情シス担当（何でも屋）

▸ ネットワークを中心とした国際インフラ全般を担当

▸ WEBアプリ開発を個人的に始めて2年くらい

エンタープライズ運用担当者の目線

▸ 既存のネットワークを置き換えるという発想は無い▸ 現在動いている環境にアドオンするのが前提▸ 何かあったら元に戻せると素晴らしい(物理/論理)

▸ 「可視化」がキーワード▸ 問題発生時に上司、役員等に説明する機会が多いため、説明しやすい、理解しやすいことは重要

▸ 運用定量化と効果計測のため数値化を常に考えている

SDNで目指していること

▸プログラミングは問題解決手段の一つ

▸泥臭い現場運用に改善の余地がありそう

▸細かすぎて誰も解決してくれない問題を独自に取り組んでみたい

本日お話しするユースケース2つ

▸ 冗長システムのコントロール

▸ パケットキャプチャによるエビデンスベースの障害対応

実際に運用して試行錯誤中

▸冗長システムのコントロール

冗長システムの問題▸ 切替がうまくできない事がある

▸ ハングアップ等、ダウン検知が難しい障害がある▸ 情シス担当者にとっては最悪の事態

▸ 事前に行った切替試験が役に立たない▸ 抜線試験と実際の状況は異なる

▸ 障害の原因究明がやりにくい▸ 復旧優先で機器の再起動が行われるケースが多く、停止状況の検分が難しい

OpenFlowで解決

具体例▸ システムの冗長機能に依存しない構成を独自に実装

▸ ソフトウェアによる高度な死活監視▸ ネットワーク側の制御により障害状態を保存しつつ待機系に切り替える

③切り替え指令

②高度な機能診断

①障害KEEP OUT KEEP OUT KEEP OUT KEEP OUT

④正常な機器へ切替

現場を保存

監視と切替▸ サービス監視を高度化

▸ 自動テストを書く

▸ 切替処理を単純/確実化▸ OpenFlowでEthernetポートをup/down▸ 抜線テストと同様の結果が得られる

▸ 結果的に止まらないシステムを作ることが狙い

当社の事例▸ OpenFlowスイッチ自身の冗長に活用中

▸ ARP処理の切替等、細々したフローも一緒に制御

▸ 何故フロー制御でなくポートStateの制御なのか▸ 現時点での状態が取得しやすい（外見/内部から）▸ 他の担当者に動作を説明しやすい▸ 抜/結線というアナログな手段で容易に再現可能

具体的な切替手順

▸ NICチーミングを使う▸ 優先Interfaceを予めダウンさせておき、切替実行時にUpさせる方式で切替（障害状態保存のため）

▸ esxcli やシェル、PHPを組み合わせて実装

▸ ポートが上がるまでの時間を事前に把握しておく▸ 手元の環境では切替に約2秒を要する

使いどころ

▸ 冗長機能の無い製品をムリヤリ冗長化する時に使う▸ OpenFlowスイッチ周りの冗長をデザインした

▸ 一般のHAクラスタ製品がフェイルオーバー時に、切り替わらないケースを想定した「ダメ押し」として使ってはどうか▸ ARPとか細かい処理はHAにオフロードさせる▸ 製品依存が大きいので個別に細かい検討が必要

やってみた感想

▸ インターフェースの初期化を伴うので、障害状態の保存という観点では、ポートDownが使いづらい

▸ フェイルオーバー条件をユーザー自身の手で書けるのはかなり気持ちいい

▸ 導入時、OpenFlowスイッチ自体の信頼性を懸念する意見に対しては、かなり説得力があった模様

▸パケットキャプチャによるエビデンスベースの障害対応

海外情シスあるある

▸ 「エラーログが出ていないのでこちらに問題はありません」

▸ 「ログが無いのでこれ以上調べられません」

障害時の現地業者のリアクションｗまじで言われる

▸ ログをきちんと出力するのは結構難しい（経験が必要）

そもそも論

▸ MS , Oracleでさえも適切なエラーメッセージやログを出力するとは限らない

▸ 適切なログを出すという行為は本質的にエラーの先回りであり、想定していないエラーでは適切なメッセージにならない

▸ ログ機能にも機能の多寡、品質が存在し、あまり過度な期待をすべきではない

とりあえず、現場はどうするか

▸ パケットキャプチャで証拠を突き付けて短く会話する。（推測や仮定を極力入れない）

▸ 詳しそうなオーラを出して押し切る

▸ 責任範囲が明確化する

▸ 分かる人が窓口に出てくるという効果も

運用上の問題

▸ 肝心な時に欲しいパケットが手に入らない▸ 障害対応で欲しいのは正常時(何日か前)のパケットだったりする

▸ 例：昨日インドでヘンな時間に発生している、このトラフィックのピーク何？

▸ 目的のパケットを探すのに手間取る▸ 大容量のキャプチャファイルを遠隔地から転送しにくい

パケットキャプチャの取り方を工夫する

▸ 容量大きめのリングバッファで常にキャプチャを取り続ける（常設監視カメラ）

▸ Syslogと連携して障害が起きたらその時点のキャプチャを上書きされない場所に退避する

▸ Web画面からキャプチャをダウンロードしたり、リングバッファの切替や容量管理が出来ると便利かも…

そこで

Sonarman (ソナーマン)を作りました【宣伝】ソースコードをGitHubで公開しましたhttps://github.com/DevelUpJapan/Sonarman

VM版を無償ダウンロードできますhttp://develup-japan.co.jp/wp/works/sonarman-free-edition/

遠隔拠点の障害対応に最適な小型HW版を販売中http://develup-japan.co.jp/wp/works/sonarman/

海外拠点におけるネットワーク運用のベストプラクティス　

詳しくはWEBで！

エクセルで描いたロゴマークw

エラー検知と連携▸ ICMPを抽出し、echo requestとreplyを抜いた結果を出力し、おかしな予兆がないか探ったりします

▸ Host unreachable▸ Port unreachable▸ Time to live exceeded in transit▸ Host administratively prohibited

▸ 現れる頻度等もチェック

エラー発見!!

tshark -r capfile -R "icmp.type!=8 && icmp.type!=0 && icmp"

ミラーポートの制御

▸ OpenFlowでミラーポートを制御

▸ インターネットVPNのWAN側をキャプチャしたりしている▸ IPSecのESP,AHが経路上で落とされてしまう某国用

▸ どのポートから入った通信なのかを識別するためにVlanタグを付けており、意外と便利

（Windowsでキャプチャしてはダメ）現場の結線が本当に正しいかを追う時に役立つ

3行でまとめ

▸ 泥臭く書くことで見えてくることもある

▸ 運用を可視化しつつ、現状維持バイアスと上手く付き合う

▸ 情シス部門のネットワーク内製は凝りすぎると引き継ぎで死の予感がする

てな感じでやってます。ご参考になれば

最後にお願い

▸ SDNの便利な使い方があればぜひ教えてください

▸ Sonarman使ってみたい人はご連絡ください