Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to エンタープライズにおけるOpen flowユースケースを考える
Similar to エンタープライズにおけるOpen flowユースケースを考える (20)
More from cloretsblack
エンタープライズにおけるOpen flowユースケースを考える
- 2. 自己紹介 ▸ Clorets8lack ▸ 某ユーザー企業の情シス担当（何でも屋） ▸ ネットワークを中心とした国際インフラ全般を担当 ▸ WEBアプリ開発を個人的に始めて2年くらい
- 3. エンタープライズ運用担当者の目線 ▸ 既存のネットワークを置き換えるという発想は無い ▸ 現在動いている環境にアドオンするのが前提 ▸ 何かあったら元に戻せると素晴らしい(物理/論理) ▸ 「可視化」がキーワード ▸ 問題発生時に上司、役員等に説明する機会が多いため、 説明しやすい、理解しやすいことは重要 ▸ 運用定量化と効果計測のため数値化を常に考えている
- 4. SDNで目指していること ▸ プログラミングは問題解決手段の一つ ▸ 泥臭い現場運用に改善の余地がありそう ▸ 細かすぎて誰も解決してくれない問題を独 自に取り組んでみたい
- 7. 冗長システムの問題 ▸ 切替がうまくできない事がある ▸ ハングアップ等、ダウン検知が難しい障害がある ▸ 情シス担当者にとっては最悪の事態 ▸ 事前に行った切替試験が役に立たない ▸ 抜線試験と実際の状況は異なる ▸ 障害の原因究明がやりにくい ▸ 復旧優先で機器の再起動が行われるケースが多く、停止 状況の検分が難しい OpenFlowで解決
- 8. 具体例 ▸ システムの冗長機能に依存しない構成を独自に実装 ▸ ソフトウェアによる高度な死活監視 ▸ ネットワーク側の制御により障害状態を保存しつつ待機 系に切り替える ③切り替え指令 ②高度な機能診断 ①障害 KEEP OUT KEEP OUT KEEP OUT KEEP OUT ④正常な機器へ 切替 現場を保存
- 9. 監視と切替 ▸ サービス監視を高度化 ▸ 自動テストを書く ▸ 切替処理を単純/確実化 ▸ OpenFlowでEthernetポートをup/down ▸ 抜線テストと同様の結果が得られる ▸ 結果的に止まらないシステムを作ることが狙い
- 10. 当社の事例 ▸ OpenFlowスイッチ自身の冗長に活用中 ▸ ARP処理の切替等、細々したフローも一緒に制御 ▸ 何故フロー制御でなくポートStateの制御なのか ▸ 現時点での状態が取得しやすい（外見/内部から） ▸ 他の担当者に動作を説明しやすい ▸ 抜/結線というアナログな手段で容易に再現可能
- 11. 具体的な切替手順 ▸ NICチーミングを使う ▸ 優先Interfaceを予めダウンさせておき、切替実行時 にUpさせる方式で切替（障害状態保存のため） ▸ esxcli やシェル、PHPを組み合わせて実装 ▸ ポートが上がるまでの時間を事前に把握しておく ▸ 手元の環境では切替に約2秒を要する
- 12. 使いどころ ▸ 冗長機能の無い製品をムリヤリ冗長化する時に使う ▸ OpenFlowスイッチ周りの冗長をデザインした ▸ 一般のHAクラスタ製品がフェイルオーバー時に、切 り替わらないケースを想定した「ダメ押し」として 使ってはどうか ▸ ARPとか細かい処理はHAにオフロードさせる ▸ 製品依存が大きいので個別に細かい検討が必要
- 13. やってみた感想 ▸ インターフェースの初期化を伴うので、障害状態の 保存という観点では、ポートDownが使いづらい ▸ フェイルオーバー条件をユーザー自身の手で書ける のはかなり気持ちいい ▸ 導入時、OpenFlowスイッチ自体の信頼性を懸念す る意見に対しては、かなり説得力があった模様
- 15. 海外情シスあるある ▸ 「エラーログが出ていないのでこちらに問題はあり ません」 ▸ 「ログが無いのでこれ以上調べられません」 障害時の現地業者のリアクションｗ まじで言われる ▸ ログをきちんと出力するのは結構難しい（経験が必 要）
- 16. そもそも論 ▸ MS , Oracleでさえも適切なエラーメッセージやロ グを出力するとは限らない ▸ 適切なログを出すという行為は本質的にエラーの先 回りであり、想定していないエラーでは適切なメッ セージにならない ▸ ログ機能にも機能の多寡、品質が存在し、あまり過 度な期待をすべきではない
- 17. とりあえず、現場はどうするか ▸ パケットキャプチャで証拠を突き付けて短く会話す る。（推測や仮定を極力入れない） ▸ 詳しそうなオーラを出して押し切る ▸ 責任範囲が明確化する ▸ 分かる人が窓口に出てくるという効果も
- 18. 運用上の問題 ▸ 肝心な時に欲しいパケットが手に入らない ▸ 障害対応で欲しいのは正常時(何日か前)のパケットだっ たりする ▸ 例：昨日インドでヘンな時間に発生している、このトラ フィックのピーク何？ ▸ 目的のパケットを探すのに手間取る ▸ 大容量のキャプチャファイルを遠隔地から転送しにくい
- 19. パケットキャプチャの取り方を工夫する ▸ 容量大きめのリングバッファで常にキャプチャを取 り続ける（常設監視カメラ） ▸ Syslogと連携して障害が起きたらその時点のキャプ チャを上書きされない場所に退避する ▸ Web画面からキャプチャをダウンロードしたり、リング バッファの切替や容量管理が出来ると便利かも… そこで
- 21. エラー検知と連携 ▸ 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"
- 22. ミラーポートの制御 ▸ OpenFlowでミラーポートを制御 ▸ インターネットVPNのWAN側をキャプチャしたりし ている ▸ IPSecのESP,AHが経路上で落とされてしまう某国用 ▸ どのポートから入った通信なのかを識別するために Vlanタグを付けており、意外と便利 （Windowsでキャプチャしてはダメ） 現場の結線が本当に正しいかを追う時に役立つ
- 23. 3行でまとめ ▸ 泥臭く書くことで見えてくることもある ▸ 運用を可視化しつつ、現状維持バイアスと上手く付 き合う ▸ 情シス部門のネットワーク内製は凝りすぎると引き 継ぎで死の予感がする てな感じでやってます。ご参考になれば