サイバーエージェント様 発表「OpenStackのNWと物理の話」

サイバーエージェント様 発表「OpenStackのNWと物理の話」

1. 1. OpenStackのNWと物理の話 十場 裕 島貫 稔之
2. 2. 自己紹介 名前: 十場 裕 (ネットワークエンジニア) - 2015年4月 株式会社サイバーエージェント入社 - NW運用、OpenStack検証･構築、管理ツール開発 名前: 島貫 稔之 (ソフトウェアエンジニア) - 2015年4月 株式会社サイバーエージェント入社 - OpenStack検証・構築、管理ツール開発
3. 3. アジェンダ ネットワーク NWの論理構成 Compute Node/物理サーバの構成 セキュリティ - 事業部間の通信の制御 - 仮想マシンに対する通信の制御 L3 DSR導入の経緯と注意点
4. 4. アジェンダ • Ironicについて • 弊社における利用例 • 運用上の工夫 - Availability Zone対応 - ネットワーク構成 - 管理ツールの開発 • 運用して気づいた事
5. 5. Internet Edge Router Edge Router Load Balancer Firewall Load Balancer Firewall Core Router Core Router VLAN XXXX VLAN YYYY VLAN ZZZZ Management Network
6. 6. CN/物理サーバの構成 スペック（CN/物理サーバ） CPU: 40Core Memory: 256GB NW帯域幅: 10G x 2 構築・設定 Ironicで構築 Linux Bridge Agent（Type: VLAN）
7. 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
8. 8. Rack Stiwch#1 Rack Stiwch#2 物理サーバ（Ironic） eth0 eth1 bond0 Management Switch eth2 bond0.xxxx
9. 9. セキュリティ 事業部間の通信の制御 Core RouterのACLで実現 同一の会社に属するVLAN間は通信可能 異なる会社に属するVLAN間の通信は不可能 仮想マシンに対する通信の制御 Security Groupで実現 Linux Bridgeに対するiptables 詳細なルールは利用者が定義
10. 10. Internet Edge Router Edge Router Load Balancer Firewall Load Balancer Firewall Core Router Core Router VLAN XXXX VLAN YYYY VLAN ZZZZ 事業部A 事業部B
11. 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. 12. L3 DSR導入の経緯と注意点 L3 DSR導入の経緯 Internal VIP経由の通信を行う際に、 送信元IPアドレスを知るため。 L3 DSR導入時の注意点 Security Groupが通信を阻害する場合がある 特に、利用者定義以外の部分で設定されてい る 暗黙のルールに該当する可能性がある
13. 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. 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
15. 15. Load Balancer Server Core Router Client GREトンネル Compute Node 1 2 3 4 5 6
16. 16. Load Balancer Server Core Router Client GREトンネル Compute Node 1 2 3 4 5 6 Compute Nodeから見ると ④でGREのパケットが入り、 ⑤でSYN＋ACKのパケットが出るように 見える。
17. 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
18. 18. 物理(Ironic)の話 島貫 稔之
19. 19. アジェンダ • Ironicについて • 弊社における利用例 • 運用上の工夫 - Availability Zone対応 - ネットワーク構成 - 管理ツールの開発 • 運用して気づいた事
20. 20. Ironicについて 仮想インスタンスを作る手順で 物理マシンにOSをインストールする事を 可能にするコンポーネント
21. 21. Ironicについて 仮想マシン 物理マシン Nova Ironic
22. 22. 弊社における利用例 • Ironicで管理しているもの • Amebaサービス提供用の物理サーバ - 現状：200台以上 • ComputeNode用の物理サーバ - 現状：200台以上 管理用マシンを除く 全ての物理サーバをIronicで管理
23. 23. 運用上の工夫
24. 24. 運用上の工夫 • Availability Zoneの対応 • ネットワーク構成 • WebUIの開発
25. 25. AZ対応 • 「サービス提供するのでAZ毎に物理マシン を配置したい」 - 物理マシンをAZ毎に分散させることで、物理的 障害に対応 • しかし… - Ironicノードを各AZに組み込むことができない なぜAZへIronicノードを 組み込むことができないか
26. 26. AZ2 Nova-compute Nova-compute Nova-compute AZ / nova-compute / 物理マシ ン AZ1 Nova-compute Nova-compute Nova-compute Nova-compute 物理マシン 物理マシン 物理マシン 物理マシン 物理マシン 物理マシン Nova-computeの配下に物理マシンが ぶら下がるイメージ
27. 27. 現在の様子 ironic-conductor ironic-api nova-compute ironic-conductor ironic-api nova-compute ironic-conductor ironic-api nova-compute 物理マシン 物理マシン 物理マシン 物理マシン 物理マシン 物理マシン 物理マシン 物理マシン 物理マシン 物理マシン 物理マシン 物理マシン AZ毎に必要なコンポーネントを設置 AZ3AZ2AZ1
28. 28. 運用上の工夫 • Availability Zone • ネットワーク構成 • WebUIの開発
29. 29. ネットワーク構成による問題 物理マシン eth0 L2SW Ironicが想定しているであろう ネットワーク構成 物理マシン eth0 eth1 eth2 L2SW L2SW 弊社ネットワーク構成 サービス用と プロビジョニング用 ネットワークが異なる プロビジョニング用 ネットワークと サービス用ネット ワークが同じ サービス用 プロビジョ ニング用 プロビジョニング用ネットワークと サービス用ネットワークの分離ができない
30. 30. ネットワーク分離は実装途中 • https://blueprints.launchpad.net/ironic/+s pec/network-provider - Openstack Mitakaでリリース予定 - 2016年4月
31. 31. 解決策 インスタンス作成 Nova-compute サービス用Neutron ポートを作成 物理マシン デプロイ Ironic-conductor pxelinux.cfgを作成 Nova-hook プロビジョニング 用Neutronポート を作成 ※pxe_ipmitoolを利用しています
32. 32. 運用上の工夫 • Availability Zone • ネットワーク構成 • 管理ツールの開発 なぜ管理ツールが必要なのか
33. 33. 運用上の問題 • 構築/運用で必要なもの - シリアルナンバー - AZの選択 - フレーバ(物理マシンの種別)の選択 • 参考 - https://github.com/openstack/ironic-inspector
34. 34. Ironic, Nova, Neutronの関係 Ironic Neutron Nova インスタンス情報 ネットワーク情報 物理ノード情報 コンポーネントの垣根を超えて 一元的に状態を把握できるツールの必要性
35. 35. Ironicman • 役割 - 情報収集 ラッキング〜ノード登録まで半自動化 • 一元的な状態把握  物理的状態  インスタンスの状態
36. 36. ラッキングフロー 0. ラッキング 1. 電源ON 2. PXEブートするように設定変更 3. PXEブート 4. 物理ノード登録用イメージがブート 5. AZ、物理マシンの種類等を選択 手動 手動 手動 自動 自動 手動
37. 37. ラッキングフロー(続き) 6. ohaiでマシン情報取得 – シリアルナンバー – NICのMACアドレス – ディスク, RAM, CPUコア数等 7. 6.で取得した情報をIronicmanへ送信 8. ipmitoolでネットワーク、認証情報設定 9. シャットダウン ※シリアルナンバーとラック位置の紐付けは今のところ別管理 自動 自動 自動 自動
38. 38. Ironicmanと周辺要素の関係 Ironic Neutron Nova Ironicman オペレータ 物理マシン
39. 39. 物理ノードの状態一覧 Nova Neutron IronicIronicman DBにビューを作成して対応
40. 40. Ironicを運用してみて
41. 41. Ironicを運用してみて(1) • 突然マシンがshutdown - ハードウェア故障？  →ironicが原因でした - force_power_state_during_sync  デフォルト設定はTrue  DBが保持する物理サーバの電源状態と、実際の電源 状態が異なるときに、DBを優先するオプション
42. 42. Ironicを運用してみて(2) • インスタンス作成に失敗する - スケジューリングでタイムアウトしていた  スケジューリング自体は成功している - scheduler_tracks_instance_change  Ironicの公式ドキュメントによればFalse  Trueにしたらスケジューリングが劇的に速く終わる ようになりました
43. 43. 最後に • Ironicを運用するには - ネットワーク構成の把握 - 物理マシンに関する知識 - Pythonのコードを読んで理解する