Quality Control of OpenStack as Ops
1 like1,192 views
日本OpenStackユーザ会 第29回勉強会 での発表資料です http://openstack-jp.connpass.com/event/39051/
Quality Control of OpenStack as Ops
- 1. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights ReservedCopyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved Quality Control of OpenStack as Ops Ikuo Kumagai – Bit-‐‑‒isle Equinix Inc.
- 2. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved 2011年年 • 9⽉月 Midokura との実証実験 2012年年/2013年年 • 社内 実証実験(Essex) • Swift 社内β • 総研クラウド(Folsom) • Ceph検証 2014年年 •総研クラウド (Havana) •社内 OpenStack研修開始 •Interop インタークラウド検証参加 2015年年 •ユーザ向けテスト環境(Juno) •OpenStack 社外向けトレーニング •OpenStack Days Tokyo 2015 環境提供 •ユーザプロダクション環境(Kilo) 2016年年 •OpenStack Days Tokyo 2016 参加 ビットアイルとOpenStack の取り組みの歩み 2
- 4. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved OpenStack is Software 4
- 5. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved Quality Control of OpenStack Software •Tox •Tempest •Rally •Zuul 5
- 6. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved Is Infrastructure Software Dead!? 6 https://www.mirantis.com/blog/infrastructure-‐‑‒software-‐‑‒is-‐‑‒dead/
- 7. What do we provide using Openstack? 7
- 8. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved Is Infrastructure Software Dead!? 8 http://www.publickey1.jp/blog/16/openstackmirantisrackspace.html ” OpenStack as a product is dead! Long live OpenStack as a Service!” The product of today is a combination of software and, more importantly, a service to operate that software,
- 9. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved Todayʼ’s ｍain theme 9 サービスサポート インシデント管理理 問題管理理 構成管理理 変更更管理理 リリース管理理 サービスデスク サービスレベル管理理 ITサービス財務管理理 可⽤用性管理理 ITサービス継続性管理理 キャパシティ管理理
- 10. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved •OpenStackでIaaSを⾏行行うとき管理理する対象は OpenStack以外の部分が圧倒的に多い Environment stack of OpenStack IaaS 10 OpenStack ネットワーク機器 デプロイ ラック・電源・ネットワーク回線 ストレージ SDS 監視 運⽤用 開発SDN ハイパーバイザ サーバーOS 物理理サーバ
- 11. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved 例例えば、、 • コンピュートノード/コントローラノードの増設や復復旧(物理理サーバ管理理) • インスタンス起動はうまくいく。でもssh接続できない(ハイパーバイザ) • cirossイメージの登録、インスタンス起動、スナップショット起動はう まくいく。でもWindowsイメージはNG(ハイパーバイザ？イメージ？) • ネットワーク作成はうまくいく。でもDHCP起動していない(SDN) • VMのIO遅延(ストレージ) このような話はOpenStackソフトウェアの 品質管理理では担保できない 11
- 12. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved サービスの品質管理理 (ITILより) •品質のレベルは UserとProviderの間の 合意によって決定 (SLA : Service Level Agreement) •Service Providerに属するOpsは SLAを実現するための内部合意をする (OLA : Operation Level Agreement) •Service Provider は外部プロバイダと UCを結ぶ 12 User Service Provider DevVender Ops Distributer SLA OLA UC
- 13. Service Level Agreement and Availability 13 ・各種プロバイダのSLA
- 14. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved AWSにおける可⽤用性の考え⽅方 http://d36cz9buwru1tt.cloudfront.net/jp/architecturecenter/RefArch_FaultToleranceHighAvailability_5Ar.pdf
- 15. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved AWSにおける可⽤用性の考え⽅方 ・AWSでは「サーバは落落ちるもの、データセンタは⽌止まるもの」 ・「各リージョンは完全に独⽴立立しています。各アベイラビリティーゾーンは独⽴立立していますが、同じリージョン内のアベイラビリ ティーゾーンどうしは低レイテンシーのリンクで接続されています。次の図に、リージョンとアベイラビリティーゾーンの関係を⽰示し ます。」 AWSの説明より 15 参考：http://dev.classmethod.jp/cloud/aws/high-availability-on-aws/ AZ間ロードバランス リージョン内に複数のアベイラリティゾーンを設け 分散配置しロードバランサを設定することで冗長性を確保する リージョン間ロードバランス リージョン間のロードバランスについてはRoute53を用いて GSLBすることによりフェイルオーバーを実現することが可能です。 http://aws.typepad.com/aws_japan/2013/05/ebs-snapshot-copy-is-now-incremental-1-1.html
- 16. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved AWS EC2のSLA • ⼀一⽉月の間にリージョン内で 複数のAZが使⽤用不不能 となる状態が99.95%未満 • 使⽤用不不能とは 利利⽤用者の実⾏行行する全ての インスタンスの外部との 接続性がない状態 =複数AZの全てのインスタンス への接続が21.6分以上不不可 •Azure, GCPも ほぼ同じ 16
- 17. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved 国内のIaaSのSLA ‣概ねサーバー単体の稼働率率率としている • 障害状態とは ‣電源が⼊入らない ‣接続ができない ‣ディスクアクセス不不可 17
- 18. Our Case 18
- 19. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved SLA •サービス仕様書(ユーザ毎に作成)により定義(下記は例例) 19
- 20. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved OLAを考えるときに重要なこと •L1/L2サポート(全部/⼀一部機能障害) ‣HW/NW障害 • 耐障害性設計と障害時運⽤用で担保する(各種HA機能) ‣ソフトウェア障害 • ⼀一時対応(暫定復復旧)までは⾃自前で調査、対応することが基本 • 外部ベンダへの対応依頼は根本解決対応メイン •L3/L4サポート(問い合わせ対応) ‣原因調査と解消 • パッチ適⽤用とメンテナンス時間の調整 ‣再現性の乏しい問題への対処 •問題対応パッチ適⽤用などのメンテナンス時間の想定 20
- 21. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved Tools 21 deploy テストrepository E-‐‑‒MAIL 通知 監視 管理
- 22. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved How does it work 22 NOTIFY DEPLOY TEST RESULT OS OS OS OpenStack VM VM VM VM VM VM Staging Environment NOTICE USE UPDATE OS OS OS OpenStack VM VM VM VM VM VM Production Environment
- 23. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved •テスト⾃自動化の対象 ‣インフラ テスト ‣OpenStack テスト ‣インスタンス動作確認 Auto Test of OpenStack environment 23 OS OS OS OS OpenStack VM VM VM VM VM VM VM VM INFRA TEST CLI TEST INSTANCE CHECK
- 24. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved Auto Deploy and Manage Repositoly 24 OS OS OS OS OpenStack •リポジトリ/ソースの統⼀一と⾃自動デプロイ ‣パッケージ/リポジトリの管理理 ‣デプロイの⾃自動化 INSTALL CONFIG
- 25. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved •デプロイ/テスト/監視結果の通知 ‣検知と通知 ‣問題の記録 ‣状態確認 Communicate between Team and Machine 25 OS OS OS OS OpenStack VM VM VM VM VM VM VM VM NOTIFY STATUS CHECK
- 26. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved Rally 【機能テスト/APIベンチマーク】 •OpenStack APIの レスポンスグラフ が⽣生成される •利利⽤用実績 ‣構築当初機能テスト ‣運⽤用中API ベンチマーク(予定) 26
- 27. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved ServerSpec 【基盤確認】 •定期的なサーバ構成確認 ‣サーバ種別 毎にspec確認 •利利⽤用実績 ‣サーバスペックテスト ‣VMパフォーマンス テストの定常化(予定) 27
- 28. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved Jenkins 【ジョブ実⾏行行】 •定期正常性確認ジョブ実⾏行行 •作業後の デグレ確認⾃自動化 28
- 29. 今後に向けて 29
- 30. Copyright © 2016 Bit-‐‑‒isle Equinix Inc. All Rights Reserved 継続的な改善が可能なOpenStack IaaS の提供 • OpenStack 環境におけるよくある開発要求 ‣パッケージのバージョンアップ ‣コンピュートノードを追加 ‣新しいOpenStackコンポーネントを使ってみたい ‣Computeノードを減らしてCephノードにしたい ‣動作の重いコンポーネントを停⽌止したい ‣コントローラノードに機能を追加したい ‣ダッシュボードに⼿手を⼊入れたい 30
Editor's Notes
- #4: Sierの方 運用をしている方 大規模 小規模 HWベンダーの方 今日私が話すのは小規模なOpenStack運用者向けだと思います。
- #7: 顧客はソフトウェアのことなど気にしない。顧客が気にするのは、何がそこから得られるのかだ。そしてMirantisが成功してきた理由は、顧客にその得られるものを提供してきたからだ。バグの多いOpenStackのソフトウェアを有能なインフラのハッカーたちによって補完してきたのだ。 繰り返す。クラウドは「プロダクト」を再定義したのだ。ソフトウェアはもう過去のプロダクトだ。今日のプロダクトとは、ソフトウェアと、より重要なそのサービスの運用サービスを組み合わせたものなのだ。 ーーーーー Mirantisが私たちと同じ考えに至ったことはとても満足だ。Rackspaceははじめから、クラウドで成功するには適切なソフトウェアだけでなく、適切な運用とサービスモデルが関わることを知っていた。 複雑さはOpenStackが成熟するにつれ軽減されるだろう。けれど現実にはそうでありつづけるだろうし、誰もが自分のクラウドを運用できるようになるほど簡単にはならないだろう。 ーーーー Rackspaceにおいて、私たちが最初に開拓したOpenStackデリバリモデルを利用されるお客様を歓迎する。Borisやほかの方々も「プロダクトとしてのOpenStackは死んだ。サービスとしてのOpenStackよ永遠に！」ということに渋々ながら同意してくれるだろう。
- #9: 顧客はソフトウェアのことなど気にしない。顧客が気にするのは、何がそこから得られるのかだ。そしてMirantisが成功してきた理由は、顧客にその得られるものを提供してきたからだ。バグの多いOpenStackのソフトウェアを有能なインフラのハッカーたちによって補完してきたのだ。 繰り返す。クラウドは「プロダクト」を再定義したのだ。ソフトウェアはもう過去のプロダクトだ。今日のプロダクトとは、ソフトウェアと、より重要なそのサービスの運用サービスを組み合わせたものなのだ。 ーーーーー Mirantisが私たちと同じ考えに至ったことはとても満足だ。Rackspaceははじめから、クラウドで成功するには適切なソフトウェアだけでなく、適切な運用とサービスモデルが関わることを知っていた。 複雑さはOpenStackが成熟するにつれ軽減されるだろう。けれど現実にはそうでありつづけるだろうし、誰もが自分のクラウドを運用できるようになるほど簡単にはならないだろう。 ーーーー Rackspaceにおいて、私たちが最初に開拓したOpenStackデリバリモデルを利用されるお客様を歓迎する。Borisやほかの方々も「プロダクトとしてのOpenStackは死んだ。サービスとしてのOpenStackよ永遠に！」ということに渋々ながら同意してくれるだろう。
- #12: ポテンヒットゾーン
- #25: OpenStack 環境はソフトウェアだけじゃ無し