サイバーエージェント様 発表「OpenStackのNWと物理の話」
•Download as PPTX, PDF•
17 likes•14,351 views
OpenStackのNWと物理の話 十場 裕、島貫 稔之 (株式会社サイバーエージェント) アジェンダ - ネットワーク --- NWの論理構成 --- Compute Node/物理サーバの構成 --- セキュリティ - 事業部間の通信の制御 ------ 仮想マシンに対する通信の制御 --- L3 DSR導入の経緯と注意点 - ベアメタルプロビジョニング --- Ironicについて --- 弊社における利用例 --- 運用上の工夫 --- Availability Zone対応 --- ネットワーク構成 --- 管理ツールの開発 --- 運用して気づいた事
Recommended
More Related Content
What's hot
What's hot (20)
Similar to サイバーエージェント様 発表「OpenStackのNWと物理の話」
Similar to サイバーエージェント様 発表「OpenStackのNWと物理の話」 (20)
More from VirtualTech Japan Inc.
More from VirtualTech Japan Inc. (20)
Recently uploaded
Recently uploaded (15)
サイバーエージェント様 発表「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
- 詳しい設定や、パラメータについては紹介しない。ドキュメント通り。
- 詳しい設定や、パラメータについては紹介しない。ドキュメント通り。
- ざっくり
- 400台以上を管理する上で、必要になった「工夫」について紹介
- AZを分ければ、ラックが落ちても、全台死ぬことはない」
- イメージなので、正確には異なる。 ただ、ほぼ正解に近い。
- 左側 仮想マシンがまさにこの状態 それを意識した設計？
- 今までシリアルナンバーベースでの運用だったため Ironic-inspectorは弊社環境の要件に合わず検討から外した
- ・コンポーネントは役割ごとに疎結合 ・実際には密結合
- 半自動：Availability ZoneやプロビジョニングネットワークのVLAN設定などはラッキング時に手入力 ラッキング
- 仮想マシンについては扱わない
- APIだと取得できない項目がある。 なので、ビューを作って対応