クラウドインフラ トラブルシュートのすゝめ

OpenStackやKubernetesといったソフトウェアの登場によって、近年ではユーザが、サーバ等の物理インフラを気にすることなく、簡単にVMやコンテナをデプロイできるようになっています。
一方で、インフラ自体の動作・構成は複雑化・隠蔽されているため、トラブルが発生した際の原因特定などが困難になっていることも事実です。
本セッションでは、OpenStackを題材として、実際のトラブルシュートでの経験を元に、クラウドインフラにおけるトラブルシュート時の考え方やTipsをご紹介します。

Cloud Operator Days Tokyo 2020 講演資料です。https://cloudopsdays.com/archive/2020/program/
@masayukig さんと共同の講演です。

Transcript

1. クラウドインフラ トラブルシュートのすゝめ Cloud Operator Days Tokyo 2020 梶波　崇　　井川　征幸 Red Hat
2. アジェンダ 1. 自己紹介 2. 今回のテーマに至るまで 3. クラウドインフラとは 4. トラブルシュートを効率化する 4つの原則 5. 番外編 6. まとめ
3. 自己紹介 はじめに 名前: 梶波　崇 (Takashi KAJINAMI) 所属・役職: Senior Software Maintenance Engineer @ Red Hat OpenStack/NFVに関するサポート OpenStack Storlets PTL OpenStack Puppet Core Reviewer 趣味: 　料理 3 名前: 井川　征幸 (Masayuki IGAWA) 所属・役職: Software Maintenance Engineer @ Red Hat OpenStack/NFVに関するサポート OpenStack QA PTL 趣味: 　ジョギング、自転車
4. 今回のテーマに至るまで (1/2) はじめに • 運用から遠い職種にはハードルが高い ◦ インフラを運用していない • 「TripleOで効率化するDay 2 Operation」は ニッチすぎる ◦ OpenStack Days Tokyo 2019でさえ ニッチ枠*1 • 今回の応募は難しそう・・・とテーマを眺めて いたが・・・ *1. TripleO Deep Dive　OpenStack Days Tokyo 2019 4 CFSより抜粋 運用設計、理論系（ Operational Design） ◦ システム・制御理論、品質、設計、非機能運用、大規 模運用設計 事例、Tips系（Use Case, Case Study） ◦ 実運用においての話題、やらかした話、うまくいった 話、トラブルシューティング、匿名セッションでも OK 組織論、人材育成系（ Team Building, HR Development） ◦ チーム作り、教育、評価、採用
5. 今回のテーマに至るまで (2/2) はじめに • トラブルシューティングは経験している ◦ トラブル解決が仕事の一つ ◦ OpenStackは 結構 稀にトラブる • トラブルシューティングの経験をネタにでき ないか？と思い至る 5 CFSより抜粋 運用設計、理論系（ Operational Design） ◦ システム・制御理論、品質、設計、非機能運用、大規 模運用設計 事例、Tips系（Use Case, Case Study） ◦ 実運用においての話題、やらかした話、うまくいった 話、トラブルシューティング 、匿名セッショ ンでもOK 組織論、人材育成系（ Team Building, HR Development） ◦ チーム作り、教育、評価、採用
6. 今回のテーマ はじめに クラウドインフラ　トラブルシュートのすゝめ • 話すこと ◦ トラブルシュートにあたって日頃注意していること ◦ (なるべく)クラウドインフラ全般に渡って共通的な内容 • 話さないこと ◦ トラブルシュートの全て (語り尽くせない...) ◦ OpenStackに超特化した話 (ただし題材はOpenStack) 6
7. クラウドインフラの定義 クラウドインフラとは？ • クラウド ◦ API等を通してインフラ等を必要に応じて提供するもの ▪ IaaS : Infrastructure as a Service : レンタルサーバ ▪ PaaS : Platform as a Service : マネージドサービス ▪ SaaS : Software as a Service : メールサービス • クラウドインフラ ◦ クラウドサービスを提供するためのインフラ ◦ ユーザは物理的なリソースをもたず、クラウド提供側に物理的なリソースが集約さ れる 7
8. クラウドインフラの複雑性 クラウドインフラとは？ • 2つのプレーンの存在 : データプレーンとコントロールプレーン →インフラを２方面から捉える必要がある • 仮想化の利用 : 仮想サーバ、仮想ネットワーク、仮想ストレージ、 etc… →リソースの実態が捉えづらい • 分散システム: 複数ノード、複数プロセス、冗長化 →調査対象を絞りづらい 　⇨　複雑なインフラのトラブルシュートを、いかに ”効率的に”行うか 8
9. トラブルシュートを効率化するの4つの原則 トラブルシュートを効率化する 4つの原則 クラウドインフラのトラブルシュートを効率化するための考え方 1. マクロから捉える 2. コンポーネントの役割を捉える 3. 影響範囲を明らかにする 4. リソース監視を怠らない 9
10. 1. マクロから捉える 10
11. 例題1. 仮想マシンにsshログインできない - 事象 1. まずはマクロから捉える 11 Network node x3 Client Compute node x10 br-tun qr br-int br-ex eth1 eth0 eth0 br-tun br-int VM qbr 「OpenStack上の仮想マシンにsshログインできない」という連絡を受けた ⇨　何から情報収集・調査する？
12. 例題1. 仮想マシンにsshログインできない - 対処 1. まずはマクロから捉える • まずはマクロ(概要)から問題を捉え、調査対象を絞ってから詳細を調査する ◦ 一般に概要として捉えるべきもの ▪ 問題となっている操作 ▪ 仮想マシンなどのリソースの定義状況等 ▪ 動作レベルでの簡単な切り分け結果 (ping疎通) • 原因特定までのロジックを説明できるか、を常に意識して調査する 12
13. 2. コンポーネントの役割を捉える 13
14. 例題2. 仮想マシンが起動できない - 事象 2. コンポーネントの役割を捉える 14 Controller node x3 Client Compute node x10 VM nova-api nova-conductor nova-scheduler MariaDB RabbitMQ nova-placement nova-compute libvirt OpenStack上の仮想マシンが起動できない。エラーが出力されていて、 Novaの内で問題が起 きているように見える。 　⇨　何を調査する？ Nova: OpenStackで仮想マシンを管理するコンポーネント
15. 例題2. 仮想マシンが起動できない - 対処 2. コンポーネントの役割を捉える • コンポーネントの役割を元に、調査対象を絞り込む ◦ 今回の例では、nova-apiのnova-computeの2プロセスがまず重要。 • 全てを正確に把握するには時間がかかるが、理解を蓄積していけば効率は上がる ◦ まずは概要レベルから推測する ▪ nova-api => APIリクエストには必ず関与する ◦ 詳細は実機やドキュメントなどで学ぶ • 絞り込み後のステップとして、各コンポーネントの調査方法を知ることも有用 ◦ 情報収集のためのコマンド ◦ ログファイルのパス 15
16. 3. 影響範囲を明らかにする 16
17. 例題3. DB接続のエラーが発生する - 事象 3. 影響範囲を明らかにする 17 「OpenStack上のあるサービスプロセスが Galera/MariaDBに接続出来ないことがある」という 連絡を受けた ⇨　何から調査・情報収集する？ Controller node-2 Controller node-1 Controller node-0 Galera DB Gnocchi app HA-Proxy Galera DB Gnocchi app HA-Proxy Galera DB Gnocchi app HA-Proxy Switch Client
18. 例題3. DB接続のエラーが発生する - 対処 3. 影響範囲を明らかにする 18 どこのノードに問題があるのか特定、 HW/SWそれぞれ多くの被疑箇所 →切り分けが必要 • どの程度の頻度発生するのか → 恒常的に発生している方が原因解析しやすい • どこの通信に問題があるのかを特定する • クライアント・サーバのプロセスの稼働状況を調べる ◦ 障害発生当時のログ ◦ 継続してるなら、実際にアクセス • 該当のネットワークデバイス (NIC、Switch、Router等)の状況を調べる • ノードの負荷状況を記録し、パケットドロップなど発生する状況でなかったか確認 ◦ CPU、メモリ、ネットワーク等のリソース使用量が高騰していないか ◦ ディスク負荷の影響度は大きい (最悪OSレベルのハングなど )
19. 4. リソース監視を怠らない 19
20. 例題4. ボリューム作成に失敗する - 事象 4. リソース監視を怠らない 20 Controller node cinder-api Block storage Shared storage LUN Image cinder-volume glance-api RabbitMQ Timeout ! ボリュームの作成に失敗した。ログを調査したら RabbitMQ経由の通信タイムアウト (rpc_response_timeout)が記録されていた ⇨どうやって原因を特定する？
21. 例題4. ボリューム作成に失敗する - 対処 4. リソース監視を怠らない どの処理でどういうエラーとなってるのか？何待ちでタイムアウトなのか？ 発生する可能性にはどのようなものがあるのか？ • 分散系でよく起きるタイムアウト • タイムアウトの理由をログから追うのは困難 ◦ 「遅い」理由はログメッセージに現れない (ことが多い) ◦ その瞬間に物理サーバ上で実行されていた全処理を網羅することは困難 • ノードの負荷状況を記録し、確認することが大事 ◦ CPU、メモリ、ネットワーク等のリソース使用量が高騰していないか ◦ ディスク負荷の影響度は大きい (最悪OSレベルのハングなど ) 21
22. 番外. その他のTips 22
23. 番外. その他のTips 番外. その他のTips • トラブルシュート論は奥が深い • 今回選考に漏れたTipsも多い ◦ DBの直接編集は最後の手段 ▪ 誤った編集は新しい不具合の原因になる ◦ ログよく見よ ▪ 英語でもちゃんと読もう、前後も見よう ◦ 障害が発生している対象を確認しよう ▪ 見てる情報は本当に障害が発生したノード？ ◦ 回避策が見つかっても評価環境でちゃんとテストしよう ◦ HW故障が原因のこともある ◦ GUIよりもCLIの方がトラブルシュート向き 23
24. まとめ まとめ • トラブルシュートを効率化する 4つの原則 1. マクロから捉える 2. コンポーネントの役割を捉える 3. 影響範囲を明らかにする 4. リソース監視を怠らない • 他にもたくさん→番外、その他Tips • トラブルシュートノウハウを蓄積・整理して活かしていく 24
25. linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat Thank you!