2017年12月29日 10:18 ~ 11:00 左右，由于整個 docker swarm 集群宕機，造成我們遷移至 .net core 跑在 docker swram 上的所有站點無法正常訪問，由此給您帶來很大很大的麻煩，請您諒解。受這次故障影響的站點有 閃存，博問，班級，園子，短信息，招聘，小組，openapi ...
2017年，隨著將一個一個項目從 .net framework 遷移至 .net core ，我們興奮地在部署上邁出了重要的一步——終于可以進行 docker 部署了。對于 docker 集群的選型，我們最終選擇了 docker swarm ，因為 docker swarm 的簡單，因為 docker swarm 與 docker 結合的天衣無縫，因為 docker swarm 已經經歷了多年的磨練與發展，因為阿里云對 docker 支持的與時俱進，我們想應該不會有什么大坑。
但是，我們錯了，大錯特錯。一次一次的 docker swarm 集群的不穩定讓我們痛苦不堪，不管是開發環境，還是生產環境，有時少數節點宕機，有時多數節點宕機造成整個集群宕機，有時節點看似正常而實際節點的overlay網絡無法進行正常通信。。。當出現節點宕機時，多數情況下通過阿里云控制臺1次或多次重啟服務器可以恢復正常，但有時多數 manager 節點出現宕機，重啟后集群無法恢復，只有重建整個集群，我們今天遇到的故障就屬于這種情況。
從我們一次次遇到的生產集群宕機情況看，宕機發生的概率可能與集群中節點的持續運行時間有關，當我們將集群中的所有節點通過阿里云控制臺重啟后的一段時間內，不會出現宕機問題。這次故障是發生在集群持續運行25天之后。接下來，我們會每隔2周重啟一下集群中的所有節點，看是否還會出現節點宕機的問題。
我們的 docker swarm 集群節點使用了 5 臺阿里云 2 核 4 G的獨享服務器（VPC網絡），3 個 manager 節點，2 個 worker 節點，運行的容器在 50 個之內，docker 版本是 Docker version 17.10.0-ce, build f4ffd25 。
我們真的不知道這是 docker swarm 的問題，還是阿里云的問題，但是我們知道這是我們選擇的問題，我們要為我們的選擇負責，想盡一切辦法避免再次出現整個集群宕機的問題。再次請大家諒解這次故障給您帶來的麻煩。
文章列表
留言列表
