Geçtiğimiz günlerde bir elasticsearch cluster kurarken başımızı ağrıtan bir durum oldu, gerçekten ilginç bir durumdu işletim sistemleri üzerine otomatik bir şekilde gerekli kurulumları yaptık ve haliyle makineleri docker swarm’a dahil ettik, bu noktada başımız ağrımaya başladı.
Sorun neydi?
Makineler birbiri ile doğru bir şekilde haberleşmiyordu, aşağıdaki gibi bir uyarı vermeye başladı
[WARN ][o.e.c.c.ClusterFormationFailureHelper] master not discovered yet
Ardından biraz gözlemleyelim belki master elasticsearch birşeyler yapıyordur ve yayına geçmemiştir dedik bir kaç dakika bekledik. Tabii bu sırada aşağıdaki gibi bir uyarı daha gözümüze ilişti
[WARN ][o.e.d.SeedHostsResolver ] [elasticsearch-master-1] failed to resolve host [elasticsearch-master.local]
Tam olarak olay burada koptu, biz her şekilde ip üzerinden erişiyorduk icmp
paketleri vs her şekilde ulaşıyordu ve sorun gözükmüyordu. hostname ile curl
atamıyorduk ama ip adresi ile curl
atabiliyorduk. Bu durum haliyle bizi DNS’i kontrol etmeye itti ama konunun DNS ile hiç bir alakası yoktu.
Nelere bakıldı?
- Makinelerin bir biri arasında network erişimlerini kontrol ettik
telnet
aracılığı ile portların açık olup olmadığına baktıktraceroute
ile trafiğin nereden geçtiği bizim yanlışlıkla bir firewall kuralı ile iletişimlerini kesmiş olabilir miyiz ona baktık.- DNS tarafını kontrol ettik, acaba swarm düzgün mü işlemiyor diye uzunca bir süre baktık.
- Makinelerin firewall durumlarına baktık
- Kurulumları otomatik yaptığımız için yanlış network kartını mı dinletiyoruz diye iki kez yapılandırmamızı kontrol ettik.
Nasıl Çözdük?
Her şeyi denemiştik, başladık internete araştırma yapmaya uzunca bir süre arama yaptıktan sonra bir makalede gözümüze bir şey ilişti giden paketlerde checksum kontrolünü kapattığında birisinin sorunu çözdüğünü gördük bende direk gittim aşağıdaki komutu çalıştırdım.
ethtool -K <interface> tx off
Bir baktık ki hakikaten sorun çözülüyor, erişim geliyordu buraya kadar bir sorun yoktu ancak kararlı çalışmıyordu. 1 saat kadar bu şekilde çalıştırdık ve biraz gözlemledik. Bazı makalelerde çözümün sanal makinelerde ağ kartını değiştirmek olduğunu önermişler, lakin ESXi’da VMXNET3 dışında kullanmak pek önerilmez çünkü vmware zaten bu network kartını tüm sistemler düzgün ve performanslı çalışsın diye yapıyor o sebeple hiç değiştirmedik bile.
Kesin çözüme ise ulaşmamız bu aşamadan sonra zor olmadı, araştırmaya devam ettiğimizde konuyla ilgili bir çözüm karşıladı bizi evet bulmamız biraz zaman aldı ancak nihayetinde çözdük sorunu.
docker swarm init --data-path-port=3888
VMware ortamınızda NSX çalıştırıyorsanız ki çoğu zaman çalışır “overlay networking” varsayılan olarak UDP port 4789‘u kullanır ve bu da VMware NSX’in VXLAN için iletişim portu ile çakışır sorunda işte burada başlar. Bu portu değiştirince her şey haliyle zart diye çözülmüş oldu.