Bugün senin için bir gizem var. Azure'da CoreOS (2023.5.0 / Linux 4.19.25-coreos) tabanlı küçük, üç düğümlü bir Elasticsearch kümesi çalıştırıyoruz. Elasticsearch, ana bilgisayar ağ modunda bir docker konteynerinin içinde çalıştırılır. Bir yıldan uzun süredir neredeyse tamamen bakım gerektirmeden çalıştıktan sonra makinelerin çok ilginç bir duruma girdiğini görüyoruz.
Güncelleme
Bu sorun Linux çekirdeğindeki bir sürücüye yönelik bir düzeltme ile çözüldü . Aşağıdaki cevaba bakınız.
belirtiler
Temel olarak, etkilenen makine ile diğer iki düğüm arasındaki ağ ölür. Hepsi aynı sanal ağda ve aynı alt ağdadır ve diğerleriyle normal olarak iletişim kurabilir. Etkilenen düğüme hala diğer alt ağlardan (içine ssh olabilirim) ve farklı bir eşleştirilmiş sanal ağdan erişilebilir. Makine ayrıca internete (çok sivilceli) bağlantı vardır, ancak çoğu istek sadece zaman aşımı.
Etkilenen bir düğümde, bildirilen "kullanılan soket" sayısının /proc/net/sockstatçok yüksek olduğunu gözlemledik (sağlıklı bir düğümde ~ 300 yerine ~ 4.5k). İzleme, bu numaranın düğümün kullanılamadığı andan itibaren hızla arttığını göstermektedir.
Eğlenceli olan şey, bu kullanılan soketlerin kaynağını tanımlayamayacağımızdır:
# cat /proc/net/sockstat
sockets: used 4566
TCP: inuse 2 orphan 0 tw 2 alloc 98 mem 4
UDP: inuse 1 mem 0
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
# cat /proc/net/sockstat6
TCP6: inuse 98
UDP6: inuse 1
UDPLITE6: inuse 0
RAW6: inuse 1
FRAG6: inuse 0 memory 0
Bunun dışında makine iyi görünüyor. Çalışan şüpheli işlem yoktur, CPU kullanımı minimum düzeydedir ve yeterli miktarda bellek vardır.
Aynı alt ağda "erişilemeyen" bir VM'ye ping EAGAINatmak birkaç yanıta neden olur recvmsgve ardından ENOBUFSgeri dönmeye geçer sendmsg. burada strace ping çıkışı
Bazı ek çıktılar topladım (sistemde herhangi bir değişiklik yapılmadan önce) ve bu özette yayınladım: https://gist.github.com/privatwolke/e7e2e7eb0272787765f5d3726f37107c
analiz
Sunucuda düşünebileceğimiz her şeyi kapatmayı denedik, elasticsearch ilk şüpheli oldu. Ancak, elasticsearch kapsayıcısının kapatılması, kullanılan soketleri serbest bırakmaz. CoreOS ile ilgili tüm işlemler (güncelleme motoru, çilingir, ...) veya Docker çalışma zamanının tamamı veya Azure'a özgü şeyler için aynı şey. Hiçbir şey yardımcı görünmüyordu.
Ama şimdi daha da garip: tcpdumpNeler olduğunu görmek için makineye koşmaya çalıştık . Ve bakın: Sorun kendi kendine çözüldü, bağlantı yeniden sağlandı. Teorimiz, tcpdump'ın onu çözen bir tür sistem çağrısı yapmasıydı. Tcpdump'ı gdb ile çalıştırdık ve tüm sistem çağrılarında kesme noktaları belirledik. Bir sürü kesme noktasından geçtikten sonra, yakalama soketinde (özellikle libpcap'ta bu satır ) karışık mod ayarlama eyleminin, kullanılan soketleri sıfırlayan ve bizi normal bir duruma döndüren şey olduğunu gördük .
Ek Bulgular
- Bayrakla çalışmanın
tcpdump,-p/--no-promiscuous-modekullanılan sayacı temizlemediğini ve makineyi kullanılabilir bir duruma döndürmediğini doğruladık . - Koşu
ifconfig eth0 txqueuelen 1001sıfırlanır prizler kullanılan sayaç ancak bağlantı olduğunu değil restore. - Promisc modunu manuel olarak ayarlamak
ip link set eth0 promisc onda bağlantıyı geri yüklemez.net.ipv4.xfrm4_gc_thresh32768 olarak ayarlanmış ve biraz arttırmak sorunu çözmez.
Bu kadar şaşırmış Azure ile temas halindeyiz. Bunun muhtemelen sorun değil, sadece bir semptom olduğunu anlıyorum. Ama şimdiye kadar bulduğum tek somut şey. Umudum, belirtiyi anlayarak kök nedene yaklaşabileceğimdir. Azure'daki ağ arabirimleri bu ağ sürücüsü ile çalıştırılır .
Belki CoreOS / Kernel sorumludur?
Zaman çizelgesi açısından, problemler CoreOS'un otomatik olarak en son sürüme güncellendiği 2019-03-11'de başladı. Sürüm notlarına göre , bu güncelleştirme 4.15.23'ten 4.19.25'e kadar bir çekirdek güncelleştirmesi içeriyordu . Ben hala orada bir şey olup olmadığını görmek için changelogs geçiyorum. Şimdiye kadar, sadece hiperv ağ sürücüsünün son aylarda 4.19.25'in bir parçası gibi görünmeyen birkaç güncelleme aldığını keşfettim. CoreOS'un 4.19.25'e uyguladığı yama seti o kadar etkileyici değil , ancak sahte bir nf_conntrack_ipv4 modülünü tanıtan yama yeni.
Güncelleme: Gelen çekirdek yamasıyla ilgili?
Yardım!
Şimdiye kadar sahip olduğumuz sorular şunlardır:
Bu "kullanılan soketlerin" metriğinin havaya uçmasına ne sebep olabilir? Bu metrik için çekirdek kaynaklarını okudum ve gerçekte ne tür soketler olduğuna ya da onları ne yarattığına atıfta bulunmayan bir sayaç gibi görünüyor .
Sayı neden yaklaşık 4,5k. Hangi sınır buna neden olur?
4.14.96 ve 4.19.25 çekirdeği arasında önemli bir değişiklik oldu mu?
Neden
setsockopt()libpcap'taki çağrı durumu sıfırlar?
İlgili CoreOS hatası: https://github.com/coreos/bugs/issues/2572