Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Recently uploaded
Recently uploaded (10)
Dodai勉強会#6
- 3. 背景 dodaiでは、インスタンス作成時にベアメタルの確保に失敗すると再確保処理が行 われる 確保に失敗したベアメタルのステータスはERRORとなる しかし、過去の事例から以下の様な問題があることがわかっている 最初に確保失敗したベアメタルはインスタンス返却処理が行われるまで放置される 返却処理がいつ行われるかは利用者次第なので場合によっては年単位で放置される可能性がある 台数制限が厳しい中、全く使われないマシンがあるのはリソースの無駄 インスタンスの返却処理を行うと、最初に確保失敗したベアメタルが返却され、再確保し たベアメタルは返却処理されない dodai内部でどのような処理が行われているかを確認し、問題の解決を検討したい そこで、原因分析のエントリーポイントとして、 再確保処理のコードを特定する。
- 4. 背景 dodaiでは、インスタンス作成時にベアメタルの確保に失敗すると再確保処理が行 われる 確保に失敗したベアメタルのステータスはERRORとなる しかし、過去の事例から以下の様な問題があることがわかっている 最初に確保失敗したベアメタルはインスタンス返却処理が行われるまで放置される 返却処理がいつ行われるかは利用者次第なので場合によっては年単位で放置される可能性がある 台数制限が厳しい中、全く使われないマシンがあるのはリソースの無駄 インスタンスの返却処理を行うと、最初に確保失敗したベアメタルが返却され、再確保し たベアメタルは返却処理されない dodai内部でどのような処理が行われているかを確認し、問題の解決を検討したい そこで、原因分析のエントリーポイントとして、 再確保処理のコードを特定する。
- 5. 状態遷移の確認
- 7. bm_nodes → BareMetalNode bm_nodesでgrepすると以下のファイルが見つかる。 https://github.com/dodai-compute-v2/nova/blob/dodai-compute- v2/nova/virt/baremetal/db/sqlalchemy/models.py#L33-L65 記述内容からbm_nodesテーブルにO/Rマッピングされるクラスのようだ
- 8. BareMetalNodeクラスを 使用しているメソッド BareMetalNodeでgrepすると以下のファイルが見つかる https://github.com/dodai-compute-v2/nova/blob/dodai-compute- v2/nova/virt/baremetal/db/api.py 新しくノードを作るメソッドっぽい https://github.com/dodai-compute-v2/nova/blob/dodai-compute- v2/nova/virt/baremetal/db/sqlalchemy/api.py#L172-L178 ノードを更新するメソッドっぽい https://github.com/dodai-compute-v2/nova/blob/dodai-compute- v2/nova/virt/baremetal/db/sqlalchemy/api.py#L182-L185
- 9. 推理 run instanceに成功するとresource_poolの値が‘0’に更新されるが、 これは、 bm_node_updateメソッドで行われるのでは?
- 11. task_stateの列挙型 先ほどのメソッドに以下のような記述がある https://github.com/dodai-compute-v2/nova/blob/dodai-compute- v2/nova/compute/manager.py#L4091-L4094 bm_nodeテーブルのtask_stateカラムの値はbaremetal_statesで列挙されてい るようだ。 https://github.com/dodai-compute-v2/nova/blob/dodai-compute- v2/nova/virt/baremetal/baremetal_states.py
- 12. baremetal_status run instanceでエラーが発生した際に、bm_nodesのtask_stateに書き込まれる値 baremetal_status.ERRORを使用している箇所を探せば、エラー発生時の処理が見つ かる
- 13. baremetal_states.ERROR使用箇所 Baremetal_status.ERRORでgrepすると以下のファイルが見つかった https://github.com/dodai-compute-v2/nova/blob/dodai-compute- v2/nova/virt/baremetal/driver.py 使用しているのは L317 (BareMetalDriver.spawn()の中) L369 (BareMetalDriver.destroy()の中) L603 (DodaiBareMetalDriver.spawn()の中) L650 (DodaiBareMetalDriver.spawn()の中) L708 (DodaiBareMetalDriver.destroy()の中)
- 15. DodaiBareMetalDriver.spawn() https://github.com/dodai-compute- v2/nova/blob/dodai-compute- v2/nova/virt/baremetal/driver.py#L564- L662 とりあえず、is_resycle == trueの場合を読む https://github.com/dodai-compute- v2/nova/blob/dodai-compute- v2/nova/virt/baremetal/driver.py#L578-L604 例外が発生したら_update_stateメソッドを 呼んで、task_state = ‘error’にしている
- 16. _update_stateメソッドは何している? https://github.com/dodai-compute-v2/nova/blob/dodai-compute- v2/nova/virt/baremetal/driver.py#L120-L133 → bm_nodeテーブルをアップデートしている 今回の場合ならtask_stateにerrorを書き込む
- 17. DodaiBareMetalDriver.spawn() is_resycle == falseの場合 https://github.com/dodai-compute- v2/nova/blob/dodai-compute- v2/nova/virt/baremetal/driver.py#L605-L662 例外が発生したら_update_stateメソッドを 呼んで、task_state = ‘error’にしているのは 同じ その後後始末をしてから、task_state = ‘deleted’にしている deletedになるとその後ピリオディックタスク によって回収されるはず
- 18. まとめ is_resycle == true => リソースプールに居る and 適用するイメージがデフォル トイメージ の場合、確保に失敗したらtask_state = ‘error’になる is_resycle == falseならtask_state = ‘error’のあとで後始末し、全部成功した ら’deleted’になってピリオディックタスクに回収される task_state = ‘error’になったら、人が確認しないといけない状態だからそこで止まる。という設計方針だったはずだが、上のとお り一致していない。 is_resycle == trueの場合もfalseと同じように処理すれば良いのでは？ Is_resycle == falseの場合でも後始末に失敗したらdeletedに落ちないので、解決までは今一歩 回収処理であらためて人手対応が必要か(結果的に)チェックされる？ task_state = ‘error’に落ちるタイミングでインスタンスidを消せば返却処理で正しく返却されない問題は解決するのでは？ ただし、障害時の調査が難しくなるという弊害が →uuid以外にもリレーションがあるので、難しい Destroy処理でインスタンスidを持つノードが複数あっても1個しか処理してないのでは task_state=‘error’を監視して人手作業を入れやすくしたほうが良いのでは
- 19. 次回 dodai勉強会 #7 テーマ: インスタンス確保失敗時のリトライ処理について 日時: 6/23 10:30~