サイバーエージェント様 発表「OpenStackのNWと物理の話」
Download as PPTX, PDF17 likes14,456 views
OpenStackのNWと物理の話 十場 裕、島貫 稔之 (株式会社サイバーエージェント) アジェンダ - ネットワーク --- NWの論理構成 --- Compute Node/物理サーバの構成 --- セキュリティ - 事業部間の通信の制御 ------ 仮想マシンに対する通信の制御 --- L3 DSR導入の経緯と注意点 - ベアメタルプロビジョニング --- Ironicについて --- 弊社における利用例 --- 運用上の工夫 --- Availability Zone対応 --- ネットワーク構成 --- 管理ツールの開発 --- 運用して気づいた事
Ad
More Related Content
What's hot (20)
Similar to サイバーエージェント様 発表「OpenStackのNWと物理の話」 (20)
Ad
More from VirtualTech Japan Inc. (20)
Ad
サイバーエージェント様 発表「OpenStackのNWと物理の話」
- 2. 自己紹介 名前: 十場 裕 (ネットワークエンジニア) - 2015年4月 株式会社サイバーエージェント入社 - NW運用、OpenStack検証･構築、管理ツール開発 名前: 島貫 稔之 (ソフトウェアエンジニア) - 2015年4月 株式会社サイバーエージェント入社 - OpenStack検証・構築、管理ツール開発
- 3. アジェンダ ネットワーク NWの論理構成 Compute Node/物理サーバの構成 セキュリティ - 事業部間の通信の制御 - 仮想マシンに対する通信の制御 L3 DSR導入の経緯と注意点
- 4. アジェンダ • Ironicについて • 弊社における利用例 • 運用上の工夫 - Availability Zone対応 - ネットワーク構成 - 管理ツールの開発 • 運用して気づいた事
- 6. CN/物理サーバの構成 スペック（CN/物理サーバ） CPU: 40Core Memory: 256GB NW帯域幅: 10G x 2 構築・設定 Ironicで構築 Linux Bridge Agent（Type: VLAN）
- 7. Rack Stiwch#1 Rack Stiwch#2 Compute Node eth0 eth1 bond0 Management Switch eth2 bond0.xxxx bond0.yyyy brqxxxxxxxx-xx brqyyyyyyyy-yy VM VM VMVM Linux Bridge Linux Bridge tap tap tap tap
- 9. セキュリティ 事業部間の通信の制御 Core RouterのACLで実現 同一の会社に属するVLAN間は通信可能 異なる会社に属するVLAN間の通信は不可能 仮想マシンに対する通信の制御 Security Groupで実現 Linux Bridgeに対するiptables 詳細なルールは利用者が定義
- 11. Rack Stiwch#1 Rack Stiwch#2 Compute Node eth0 eth1 bond0 bond0.xxxx bond0.yyyy brqxxxxxxxx-xx brqyyyyyyyy-yy VM VM VMVM Linux Bridge Linux Bridge tap tap tap tap physdev-inああ - StateがINVALIDな通信の拒否 ああ - DHCPサーバへの通信の許可ああ - VMに割り当てられたIPアドレスを許可 ああ - RELATED、ESTABLISHEDな通信の許可 ああ - 利用者が定義したSecurity Group ああ - 暗黙の拒否 physdev-outあ - RELATED、ESTABLISHEDな通信の許可 ああ - DHCPサーバへの通信の許可 ああ - 利用者が定義したSecurity Group ああ - 暗黙の拒否 ここで言う「State」は Compute NodeでみたState physdev-in physdev-out
- 12. L3 DSR導入の経緯と注意点 L3 DSR導入の経緯 Internal VIP経由の通信を行う際に、 送信元IPアドレスを知るため。 L3 DSR導入時の注意点 Security Groupが通信を阻害する場合がある 特に、利用者定義以外の部分で設定されてい る 暗黙のルールに該当する可能性がある
- 13. Rack Stiwch#1 Rack Stiwch#2 Compute Node eth0 eth1 bond0 bond0.xxxx bond0.yyyy brqxxxxxxxx-xx brqyyyyyyyy-yy VM VM VMVM Linux Bridge Linux Bridge tap tap tap tap physdev-inああ - StateがINVALIDな通信の拒否 ああ - DHCPサーバへの通信の許可ああ - VMに割り当てられたIPアドレスを許可 ああ - RELATED、ESTABLISHEDな通信の許可 ああ - 利用者が定義したSecurity Group ああ - 暗黙の拒否 physdev-outあ - RELATED、ESTABLISHEDな通信の許可 ああ - DHCPサーバへの通信の許可 ああ - 利用者が定義したSecurity Group ああ - 暗黙の拒否 ここで言う「State」は Compute NodeでみたState physdev-in physdev-out
- 14. Rack Stiwch#1 Rack Stiwch#2 Compute Node eth0 eth1 bond0 bond0.xxxx bond0.yyyy brqxxxxxxxx-xx brqyyyyyyyy-yy VM VM VMVM Linux Bridge Linux Bridge tap tap tap tap physdev-inああ - StateがINVALIDな通信の拒否 ああ - DHCPサーバへの通信の許可ああ - VMに割り当てられたIPアドレスを許可 ああ - RELATED、ESTABLISHEDな通信の許可 ああ - 利用者が定義したSecurity Group ああ - 暗黙の拒否 physdev-outあ - RELATED、ESTABLISHEDな通信の許可 ああ - DHCPサーバへの通信の許可 ああ - 利用者が定義したSecurity Group ああ - 暗黙の拒否 ここで言う「State」は Compute NodeでみたState physdev-in physdev-out
- 17. Rack Stiwch#1 Rack Stiwch#2 Compute Node eth0 eth1 bond0 bond0.xxxx bond0.yyyy brqxxxxxxxx-xx brqyyyyyyyy-yy VM VM VMVM Linux Bridge Linux Bridge tap tap tap tap physdev-inああ - StateがINVALIDな通信の拒否 ああ - DHCPサーバへの通信の許可ああ - VMに割り当てられたIPアドレスを許可 ああ - RELATED、ESTABLISHEDな通信の許可 ああ - 利用者が定義したSecurity Group ああ - 暗黙の拒否 physdev-outあ - RELATED、ESTABLISHEDな通信の許可 ああ - DHCPサーバへの通信の許可 ああ - 利用者が定義したSecurity Group ああ - 暗黙の拒否 ここで言う「State」は Compute NodeでみたState physdev-in physdev-out
- 19. アジェンダ • Ironicについて • 弊社における利用例 • 運用上の工夫 - Availability Zone対応 - ネットワーク構成 - 管理ツールの開発 • 運用して気づいた事
- 22. 弊社における利用例 • Ironicで管理しているもの • Amebaサービス提供用の物理サーバ - 現状：200台以上 • ComputeNode用の物理サーバ - 現状：200台以上 管理用マシンを除く 全ての物理サーバをIronicで管理
- 23. 運用上の工夫
- 24. 運用上の工夫 • Availability Zoneの対応 • ネットワーク構成 • WebUIの開発
- 25. AZ対応 • 「サービス提供するのでAZ毎に物理マシン を配置したい」 - 物理マシンをAZ毎に分散させることで、物理的 障害に対応 • しかし… - Ironicノードを各AZに組み込むことができない なぜAZへIronicノードを 組み込むことができないか
- 26. AZ2 Nova-compute Nova-compute Nova-compute AZ / nova-compute / 物理マシ ン AZ1 Nova-compute Nova-compute Nova-compute Nova-compute 物理マシン 物理マシン 物理マシン 物理マシン 物理マシン 物理マシン Nova-computeの配下に物理マシンが ぶら下がるイメージ
- 28. 運用上の工夫 • Availability Zone • ネットワーク構成 • WebUIの開発
- 30. ネットワーク分離は実装途中 • https://blueprints.launchpad.net/ironic/+s pec/network-provider - Openstack Mitakaでリリース予定 - 2016年4月
- 32. 運用上の工夫 • Availability Zone • ネットワーク構成 • 管理ツールの開発 なぜ管理ツールが必要なのか
- 33. 運用上の問題 • 構築/運用で必要なもの - シリアルナンバー - AZの選択 - フレーバ(物理マシンの種別)の選択 • 参考 - https://github.com/openstack/ironic-inspector
- 34. Ironic, Nova, Neutronの関係 Ironic Neutron Nova インスタンス情報 ネットワーク情報 物理ノード情報 コンポーネントの垣根を超えて 一元的に状態を把握できるツールの必要性
- 35. Ironicman • 役割 - 情報収集 ラッキング〜ノード登録まで半自動化 • 一元的な状態把握 物理的状態 インスタンスの状態
- 36. ラッキングフロー 0. ラッキング 1. 電源ON 2. PXEブートするように設定変更 3. PXEブート 4. 物理ノード登録用イメージがブート 5. AZ、物理マシンの種類等を選択 手動 手動 手動 自動 自動 手動
- 37. ラッキングフロー(続き) 6. ohaiでマシン情報取得 – シリアルナンバー – NICのMACアドレス – ディスク, RAM, CPUコア数等 7. 6.で取得した情報をIronicmanへ送信 8. ipmitoolでネットワーク、認証情報設定 9. シャットダウン ※シリアルナンバーとラック位置の紐付けは今のところ別管理 自動 自動 自動 自動
- 40. Ironicを運用してみて
- 41. Ironicを運用してみて(1) • 突然マシンがshutdown - ハードウェア故障？ →ironicが原因でした - force_power_state_during_sync デフォルト設定はTrue DBが保持する物理サーバの電源状態と、実際の電源 状態が異なるときに、DBを優先するオプション
- 42. Ironicを運用してみて(2) • インスタンス作成に失敗する - スケジューリングでタイムアウトしていた スケジューリング自体は成功している - scheduler_tracks_instance_change Ironicの公式ドキュメントによればFalse Trueにしたらスケジューリングが劇的に速く終わる ようになりました
- 43. 最後に • Ironicを運用するには - ネットワーク構成の把握 - 物理マシンに関する知識 - Pythonのコードを読んで理解する
Editor's Notes
- #5: 詳しい設定や、パラメータについては紹介しない。ドキュメント通り。
- #20: 詳しい設定や、パラメータについては紹介しない。ドキュメント通り。
- #22: ざっくり
- #24: 400台以上を管理する上で、必要になった「工夫」について紹介
- #26: AZを分ければ、ラックが落ちても、全台死ぬことはない」
- #27: イメージなので、正確には異なる。 ただ、ほぼ正解に近い。
- #30: 左側 仮想マシンがまさにこの状態 それを意識した設計？
- #34: 今までシリアルナンバーベースでの運用だったため Ironic-inspectorは弊社環境の要件に合わず検討から外した
- #35: ・コンポーネントは役割ごとに疎結合 ・実際には密結合
- #36: 半自動：Availability ZoneやプロビジョニングネットワークのVLAN設定などはラッキング時に手入力 ラッキング
- #39: 仮想マシンについては扱わない
- #40: APIだと取得できない項目がある。 なので、ビューを作って対応