サイバーエージェント様 発表「openstackのnwと物理の話」
TRANSCRIPT
自己紹介
名前 : 十場 裕 ( ネットワークエンジニア ) - 2015 年 4 月 株式会社サイバーエージェント入社
- NW 運用、 OpenStack 検証 構築、管理ツール・開発
名前 : 島貫 稔之 ( ソフトウェアエンジニア ) - 2015 年 4 月 株式会社サイバーエージェント入社
- OpenStack 検証・構築、管理ツール開発
Internet
EdgeRouter
EdgeRouter
Load Balancer
FirewallLoad
Balancer
Firewall
CoreRouter
CoreRouter
VLANXXXX
VLANYYYY
VLANZZZZ
ManagementNetwork
CN/ 物理サーバの構成
スペック( CN/ 物理サーバ)CPU: 40CoreMemory: 256GBNW 帯域幅 : 10G x 2構築・設定Ironic で構築Linux Bridge Agent ( Type: VLAN )
RackStiwch#1
RackStiwch#2
Compute Node
eth0 eth1bond0
ManagementSwitch
eth2
bond0.xxxx
bond0.yyyy
brqxxxxxxxx-xx
brqyyyyyyyy-yy
VM VM VMVM
Linux Bridge Linux Bridge
tap tap tap tap
セキュリティ
事業部間の通信の制御Core Router の ACL で実現同一の会社に属する VLAN 間は通信可能異なる会社に属する VLAN 間の通信は不可能
仮想マシンに対する通信の制御Security Group で実現Linux Bridge に対する iptables詳細なルールは利用者が定義
Internet
EdgeRouter
EdgeRouter
Load Balancer
FirewallLoad
Balancer
Firewall
CoreRouter
CoreRouter
VLANXXXX
VLANYYYY
VLANZZZZ
事業部 A 事業部 B
RackStiwch#1
RackStiwch#2
Compute Node
eth0 eth1bond0
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
L3 DSR 導入の経緯と注意点
L3 DSR 導入の経緯Internal VIP 経由の通信を行う際に、送信元 IP アドレスを知るため。
L3 DSR 導入時の注意点
Security Group が通信を阻害する場合がある
特に、利用者定義以外の部分で設定されている暗黙のルールに該当する可能性がある
RackStiwch#1
RackStiwch#2
Compute Node
eth0 eth1bond0
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
RackStiwch#1
RackStiwch#2
Compute Node
eth0 eth1bond0
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
Load Balancer
Server
CoreRouter
Client
GRE トンネル
Compute Node
1
2
3
4
5
6
Compute Node から見ると④で GRE のパケットが入り、⑤で SYN + ACK のパケットが出るように見える。
RackStiwch#1
RackStiwch#2
Compute Node
eth0 eth1bond0
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
弊社における利用例
• Ironic で管理しているもの• Ameba サービス提供用の物理サーバ
- 現状: 200 台以上
• ComputeNode 用の物理サーバ- 現状: 200 台以上
管理用マシンを除く全ての物理サーバを Ironic で管理
AZ 対応
• 「サービス提供するので AZ 毎に物理マシンを配置したい」- 物理マシンを AZ 毎に分散させることで、物理
的障害に対応
• しかし…- Ironic ノードを各 AZ に組み込むことができな
い
なぜ AZ へ Ironic ノードを組み込むことができないか
AZ2
Nova-computeNova-computeNova-compute
AZ / nova-compute / 物理マシン
AZ1
Nova-computeNova-computeNova-compute
Nova-compute
物理マシン物理マシン
物理マシン物理マシン
物理マシン物理マシン
Nova-compute の配下に物理マシンがぶら下がるイメージ
現在の様子
ironic-conductorironic-api
nova-compute
ironic-conductorironic-api
nova-compute
ironic-conductorironic-api
nova-compute
物理マシン 物理マシン 物理マシン物理マシン
物理マシン物理マシン
物理マシン
物理マシン物理マシン
物理マシン物理マシン
物理マシン
AZ 毎に必要なコンポーネントを設置
AZ3AZ2AZ1
ネットワーク構成による問題
物理マシン
eth0
L2SW
Ironic が想定しているであろう
ネットワーク構成
物理マシン
eth0 eth1
eth2
L2SW
L2SW
弊社ネットワーク構成
サービス用とプロビジョニング用ネットワークが異なる
プロビジョニング用ネットワークとサービス用ネット
ワークが同じ
サービス用
プロビジョニング用
プロビジョニング用ネットワークとサービス用ネットワークの分離ができない
ネットワーク分離は実装途中
• https://blueprints.launchpad.net/ironic/+spec/network-provider- Openstack Mitaka でリリース予定
- 2016 年 4 月
解決策
インスタンス作成 Nova-computeサービス用 Neutron
ポートを作成
物理マシン
デプロイ
Ironic-conductorpxelinux.cfg を作成
Nova-hookプロビジョニング用 Neutronポートを作成
※pxe_ipmitool を利用しています
運用上の問題
• 構築 / 運用で必要なもの- シリアルナンバー
- AZ の選択
- フレーバ ( 物理マシンの種別 ) の選択
• 参考- https://github.com/openstack/ironic-
inspector
Ironic, Nova, Neutron の関係
Ironic
Neutron Nova
インスタンス情報
ネットワーク情報
物理ノード情報
コンポーネントの垣根を超えて一元的に状態を把握できるツールの必要性
ラッキングフロー
0. ラッキング
1. 電源ON2. PXEブートするように設定変更
3. PXEブート
4. 物理ノード登録用イメージがブート
5. AZ 、物理マシンの種類等を選択
手動
手動
手動
自動
自動
手動
ラッキングフロー (続き )6. ohai でマシン情報取得
– シリアルナンバー– NIC の MAC アドレス– ディスク , RAM, CPU コア数等
7. 6. で取得した情報を Ironicman へ送信
8. ipmitool でネットワーク、認証情報設定
9. シャットダウン
※シリアルナンバーとラック位置の紐付けは今のところ別管理
自動
自動
自動
自動
Ironic を運用してみて (1)• 突然マシンが shutdown
- ハードウェア故障? →ironic が原因でした
- force_power_state_during_sync デフォルト設定は True DB が保持する物理サーバの電源状態と、実際の電源状態が異なるときに、 DB を優先するオプション
Ironic を運用してみて (2)• インスタンス作成に失敗する
- スケジューリングでタイムアウトしていた スケジューリング自体は成功している
- scheduler_tracks_instance_change Ironic の公式ドキュメントによれば False True にしたらスケジューリングが劇的に速く終わ
るようになりました