集羣有200餘臺虛擬機，運行在分佈式文件系統mfs上。
現象：
1、每天凌晨0:10 ，出現批量虛擬機分區出現readonly問題，導致用戶無法正常寫入。
原因分析：
1、之前偶爾也會出現個別readonly的情況，沒有深入排查，只是推測和chunkserver磁盤壞道有關，當vm讀寫正好在chunkserver壞道的塊上時，可能出現報錯，導致異常。
2、此次出現大批量readonly，且監控和日誌顯示均是在凌晨出現，故排除磁盤壞道問題。
3、如果虛擬機上承載docker 、mysql 等可能造成大併發的業務，也可能造成此類問題。但是虛擬機鏡像在mfs上是連續的空間，正常的mysql讀寫並不會有問題。有出現在vm上進行批量docker容器刪除時，出現異常的情況。
4、推測有vm用戶提交了大量併發的讀寫任務，而我們並未對虛擬機讀寫進行限制，也有可能造成此類問題。前期有vm出現load 90+ 報警,緊接着就有chunkserver出現load 100+的報警，和此問題非常類似。
排查定位：
1、檢查宿主機負載、網絡等，未發現異常情況。
2、檢查mfschunkserver ，發現有部分磁盤出現raid errro。
3、檢查mfschunkserver ，發現有一臺chunkserver出現load +100，iowait達到90%以上的情況，帶寬未見異常，寫入的數據量也很低，現象大概持續3分鐘左右。
4、檢查vm在凌晨的監控情況，發現批量機器出現iowait達到100%，流量、load均未見明顯異常。有部分vm上有大量的sendmail進程。
5、檢查虛擬機上凌晨的crontab、進程等，沒有發現異常。
6、檢查mfs上的讀寫情況，未見在凌晨有大量的 chunk create 和replica，但是 max operations in queue 值特別高。
7、檢查虛擬機備份程序，發現正好是在凌晨0:10進行備份，執行了snapshot操作，而且每臺vm備份間隔僅1s，初步確認此備份爲導致異常的主要原因。
由於snapshot操作並未帶來大量的讀寫，之前並未關注到。在深入剖析了snapshot的原理，發現是執行了類似linux 系統的硬鏈接操作，此時批量的snapshot虛擬機，200臺vm大概20TB，按照mfs的每個chunk塊 64MB的劃分，換算下來執行一次操作，會產生 2010241024/64 = 327680 創建鏈接的操作，每臺vm備份也會產生1600次操作，如果在1s內沒有完成，那麼cpu隊列就會越來越大，從而產生了load和iowait都非常高的現象。由於鏡像備份並不是十分緊急的任務，故將間隔時間修改到60s執行一臺。
可能造成虛擬機readonly故障的原因：
1、虛擬機備份進程的批量操作產生大量的併發，導致chunkserver 的cpu隊列擁塞，產生vm讀寫出現iowait過高超時的情況，從而造成了磁盤remount爲readonly的情況。故有此類批量操作的動作，一定要考慮併發負載的問題。 因爲chunkserver是存儲型服務器，cpu配置都比較低。
2、個別vm用戶大量的提交任務導致後端異常。針對此現象，使用cgroug 進行io限制。可避免此類問題發生。
3、mfschunkser 規格建議配置一致，避免讀寫負載出現不均衡的情況。
此次定位問題耗時一週：
1、監控不到位，由於zabbix 進行大批量機器對比時，效率很低，臨時部署了openfalcon和grafana，耗時較長。
2、沒有關注到備份任務，之前一致以爲是vm用戶的問題，但是通過監控定位並不是用戶的問題。
3、對mfs的snapshot未深入理解。
歡迎交流： QQ: 249016681