Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
OpenStackのNWと物理の話
十場 裕
島貫 稔之
自己紹介
名前: 十場 裕 (ネットワークエンジニア)
- 2015年4月 株式会社サイバーエージェント入社
- NW運用、OpenStack検証・構築、管理ツール開発
名前: 島貫 稔之 (ソフトウェアエンジニア)
- 2015年4月 株式会...
アジェンダ
ネットワーク
NWの論理構成
Compute Node/物理サーバの構成
セキュリティ
- 事業部間の通信の制御
- 仮想マシンに対する通信の制御
L3 DSR導入の経緯と注意点
アジェンダ
• Ironicについて
• 弊社における利用例
• 運用上の工夫
- Availability Zone対応
- ネットワーク構成
- 管理ツールの開発
• 運用して気づいた事
Internet
Edge
Router
Edge
Router
Load
Balancer
Firewall
Load
Balancer
Firewall
Core
Router
Core
Router
VLAN
XXXX
VLAN
YYYY...
CN/物理サーバの構成
スペック(CN/物理サーバ)
CPU: 40Core
Memory: 256GB
NW帯域幅: 10G x 2
構築・設定
Ironicで構築
Linux Bridge Agent(Type: VLAN)
Rack
Stiwch#1
Rack
Stiwch#2
Compute Node
eth0 eth1
bond0
Management
Switch
eth2
bond0.xxxx bond0.yyyy
brqxxxxxxxx-xx brqyy...
Rack
Stiwch#1
Rack
Stiwch#2
物理サーバ(Ironic)
eth0 eth1
bond0
Management
Switch
eth2
bond0.xxxx
セキュリティ
事業部間の通信の制御
Core RouterのACLで実現
同一の会社に属するVLAN間は通信可能
異なる会社に属するVLAN間の通信は不可能
仮想マシンに対する通信の制御
Security Groupで実現
Linux Brid...
Internet
Edge
Router
Edge
Router
Load
Balancer
Firewall
Load
Balancer
Firewall
Core
Router
Core
Router
VLAN
XXXX
VLAN
YYYY...
Rack
Stiwch#1
Rack
Stiwch#2
Compute Node
eth0 eth1
bond0
bond0.xxxx bond0.yyyy
brqxxxxxxxx-xx brqyyyyyyyy-yy
VM VM VMVM
Li...
L3 DSR導入の経緯と注意点
L3 DSR導入の経緯
Internal VIP経由の通信を行う際に、
送信元IPアドレスを知るため。
L3 DSR導入時の注意点
Security Groupが通信を阻害する場合がある
特に、利用者定義以外の部...
Rack
Stiwch#1
Rack
Stiwch#2
Compute Node
eth0 eth1
bond0
bond0.xxxx bond0.yyyy
brqxxxxxxxx-xx brqyyyyyyyy-yy
VM VM VMVM
Li...
Rack
Stiwch#1
Rack
Stiwch#2
Compute Node
eth0 eth1
bond0
bond0.xxxx bond0.yyyy
brqxxxxxxxx-xx brqyyyyyyyy-yy
VM VM VMVM
Li...
Load
Balancer
Server
Core
Router
Client
GREトンネル
Compute Node
1
2
3
4
5
6
Load
Balancer
Server
Core
Router
Client
GREトンネル
Compute Node
1
2
3
4
5
6
Compute Nodeから見ると
④でGREのパケットが入り、
⑤でSYN+ACKのパケットが出...
Rack
Stiwch#1
Rack
Stiwch#2
Compute Node
eth0 eth1
bond0
bond0.xxxx bond0.yyyy
brqxxxxxxxx-xx brqyyyyyyyy-yy
VM VM VMVM
Li...
物理(Ironic)の話
島貫 稔之
アジェンダ
• Ironicについて
• 弊社における利用例
• 運用上の工夫
- Availability Zone対応
- ネットワーク構成
- 管理ツールの開発
• 運用して気づいた事
Ironicについて
仮想インスタンスを作る手順で
物理マシンにOSをインストールする事を
可能にするコンポーネント
Ironicについて
仮想マシン 物理マシン
Nova
Ironic
弊社における利用例
• Ironicで管理しているもの
• Amebaサービス提供用の物理サーバ
- 現状:200台以上
• ComputeNode用の物理サーバ
- 現状:200台以上
管理用マシンを除く
全ての物理サーバをIronicで管理
運用上の工夫
運用上の工夫
• Availability Zoneの対応
• ネットワーク構成
• WebUIの開発
AZ対応
• 「サービス提供するのでAZ毎に物理マシン
を配置したい」
- 物理マシンをAZ毎に分散させることで、物理的
障害に対応
• しかし…
- Ironicノードを各AZに組み込むことができない
なぜAZへIronicノードを
組み込む...
AZ2
Nova-compute
Nova-compute
Nova-compute
AZ / nova-compute / 物理マシ
ン
AZ1
Nova-compute
Nova-compute
Nova-compute
Nova-comp...
現在の様子
ironic-conductor
ironic-api
nova-compute
ironic-conductor
ironic-api
nova-compute
ironic-conductor
ironic-api
nova-c...
運用上の工夫
• Availability Zone
• ネットワーク構成
• WebUIの開発
ネットワーク構成による問題
物理マシン
eth0
L2SW
Ironicが想定しているであろう
ネットワーク構成
物理マシン
eth0 eth1
eth2
L2SW
L2SW
弊社ネットワーク構成
サービス用と
プロビジョニング用
ネットワーク...
ネットワーク分離は実装途中
• https://blueprints.launchpad.net/ironic/+s
pec/network-provider
- Openstack Mitakaでリリース予定
- 2016年4月
解決策
インスタンス作成 Nova-compute
サービス用Neutron
ポートを作成
物理マシン
デプロイ
Ironic-conductor
pxelinux.cfgを作成
Nova-hook
プロビジョニング
用Neutronポート
を...
運用上の工夫
• Availability Zone
• ネットワーク構成
• 管理ツールの開発
なぜ管理ツールが必要なのか
運用上の問題
• 構築/運用で必要なもの
- シリアルナンバー
- AZの選択
- フレーバ(物理マシンの種別)の選択
• 参考
- https://github.com/openstack/ironic-inspector
Ironic, Nova, Neutronの関係
Ironic
Neutron Nova
インスタンス情報
ネットワーク情報
物理ノード情報
コンポーネントの垣根を超えて
一元的に状態を把握できるツールの必要性
Ironicman
• 役割
- 情報収集
ラッキング〜ノード登録まで半自動化
• 一元的な状態把握
 物理的状態
 インスタンスの状態
ラッキングフロー
0. ラッキング
1. 電源ON
2. PXEブートするように設定変更
3. PXEブート
4. 物理ノード登録用イメージがブート
5. AZ、物理マシンの種類等を選択
手動
手動
手動
自動
自動
手動
ラッキングフロー(続き)
6. ohaiでマシン情報取得
– シリアルナンバー
– NICのMACアドレス
– ディスク, RAM, CPUコア数等
7. 6.で取得した情報をIronicmanへ送信
8. ipmitoolでネットワーク、認証...
Ironicmanと周辺要素の関係
Ironic
Neutron
Nova
Ironicman
オペレータ
物理マシン
物理ノードの状態一覧
Nova Neutron IronicIronicman
DBにビューを作成して対応
Ironicを運用してみて
Ironicを運用してみて(1)
• 突然マシンがshutdown
- ハードウェア故障?
 →ironicが原因でした
- force_power_state_during_sync
 デフォルト設定はTrue
 DBが保持する物理サー...
Ironicを運用してみて(2)
• インスタンス作成に失敗する
- スケジューリングでタイムアウトしていた
 スケジューリング自体は成功している
- scheduler_tracks_instance_change
 Ironicの公式ド...
最後に
• Ironicを運用するには
- ネットワーク構成の把握
- 物理マシンに関する知識
- Pythonのコードを読んで理解する
Upcoming SlideShare
Loading in …5
×

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

12,203 views

Published on

OpenStackのNWと物理の話

十場 裕、島貫 稔之 (株式会社サイバーエージェント)

アジェンダ
- ネットワーク
--- NWの論理構成
--- Compute Node/物理サーバの構成
--- セキュリティ - 事業部間の通信の制御
------ 仮想マシンに対する通信の制御
--- L3 DSR導入の経緯と注意点
- ベアメタルプロビジョニング
--- Ironicについて
--- 弊社における利用例
--- 運用上の工夫
--- Availability Zone対応
--- ネットワーク構成
--- 管理ツールの開発
--- 運用して気づいた事

Published in: Technology
  • Be the first to comment

サイバーエージェント様 発表「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のコードを読んで理解する

×