înregistrare Logare
Puncte:1
avatar Server

Echilibratorul de încărcare marchează „nesănătos” instanță nouă de membru al grupului (ubuntu) după dist-upgrade

drapel tl
Ivan Buttinoni

Am câteva VM (care funcționează ca server web) în spatele unui grup de instanțe pe GCloud-ul meu.

Ca de obicei întreținerea am actualizat (apt dist-upgrade) "vm-source-image" mea, a creat un nou șablon și adaugă-l în grupul meu.

Noii membri care folosesc acest șablon nu primesc niciodată nicio cerere de lucru reală de la echilibrator de încărcare și este în funcțiune dar şomerii.

Patch temporar

Fac doar o actualizare parțială (the cele de securitate) de:

sudo nesupravegheat-upgrade -d

Iată lista pachetelor rămase care creează problema:

Lista de # apt --upgradable

cloud-init/bionic-updates 21.3-1-g6803368d-0ubuntu1~18.04.4 toate [upgradabil de la: 21.2-3-g899bfaa9-0ubuntu2~18.04.1]
dnsmasq-base/bionic-updates 2.79-1ubuntu0.5 amd64 [actualizat de la: 2.79-1ubuntu0.4]
gce-compute-image-packages/bionic-updates 20210629.00-0ubuntu1~18.04.0 toate [upgradabil de la: 20201222.00-0ubuntu2~18.04.0]
google-compute-engine/bionic-updates 20210629.00-0ubuntu1~18.04.0 toate [upgradabil de la: 20201222.00-0ubuntu2~18.04.0]
google-compute-engine-oslogin/bionic-updates 20210728.00-0ubuntu1~18.04.0 amd64 [actualizat de la: 20210429.00-0ubuntu1~18.04.0]
google-guest-agent/bionic-updates 20210629.00-0ubuntu1~18.04.1 amd64 [upgradabil de la: 20210414.00-0ubuntu1~18.04.0]
libgnutls30/bionic-updates 3.5.18-1ubuntu1.5 amd64 [actualizat de la: 3.5.18-1ubuntu1.4]
libnetplan0/bionic-updates 0.99-0ubuntu3~18.04.5 amd64 [actualizat de la: 0.99-0ubuntu3~18.04.4]
libpcre2-8-0/bionic 10.39-1+ubuntu18.04.1+deb.sury.org+1 amd64 [upgradabil de la: 10.36-2+ubuntu18.04.1+deb.sury.org+2]
netplan.io/bionic-updates 0.99-0ubuntu3~18.04.5 amd64 [upgradabil de la: 0.99-0ubuntu3~18.04.4]
nplan/bionic-updates 0.99-0ubuntu3~18.04.5 toate [upgradabil de la: 0.99-0ubuntu3~18.04.4]
snapd/bionic-updates 2.51.1+18.04 amd64 [actualizat de la: 2.49.2+18.04]
ubuntu-advantage-tools/bionic-updates 27.3~18.04.1 amd64 [actualizat de la: 27.2.2~18.04.1]

O SOLUȚIE ADEVĂRATĂ

Deoarece nu am niciun pachet „personalizat” pe mașină și originea acestei probleme vine de la o actualizare a sistemului, nu văd nicio soluție, cu excepția semnalării problemei prin această postare.

Desigur, monitorizez noile actualizări în speranța că o nouă versiune a acestor pachete rezolvă problema, dar este posibil să nu existe opțiuni mai bune?

Mai multe informatii

  • Grupul este backend-ul unui „echilibrator de încărcare TCP intern”.
  • Adresa IP frontală a echilibratorului de încărcare este 10.0.0.116
  • Adresa IP veche (și funcțională) a membrului este 10.0.0.48 (se pot vedea jurnalele)
  • Adresa IP a noului membru (și șomerului) este 10.0.0.54 (se pot vedea jurnalele)
  • Echilibratorul de încărcare are o simplă verificare de sănătate HTTP cunoscută ca HTTPHC1.
  • Grupul de instanțe are o altă verificare simplă a sănătății HTTP cunoscută ca HTTPHC2.

Compararea jurnalului de acces al unui membru vechi (și funcțional) cu cel nou:

Jurnalul unui vechi membru VM

35.191.1.148 „/” - - - [04/Nov/2021:10:34:59 +0000] 10.0.0.48 „GET /?id=HTTPHC2 HTTP/1.1” 200 612 „-” „GoogleHC/1.0”
35.191.1.144 „/” - - - [04/Nov/2021:10:35:00 +0000] 10.0.0.48 „GET /?id=HTTPHC2 HTTP/1.1” 200 612 „-” „GoogleHC/1.0”
35.191.1.154 „/” - - - [04/Nov/2021:10:35:00 +0000] 10.0.0.48 „GET /?id=HTTPHC2 HTTP/1.1” 200 612 „-” „GoogleHC/1.0”
35.191.1.147 „/” - - - [04/Nov/2021:10:35:01 +0000] 10.0.0.48 „GET /?id=HTTPHC1 HTTP/1.1” 200 612 „-” „GoogleHC/1.0”
35.191.1.145 „/” - - - [04/Nov/2021:10:35:01 +0000] 10.0.0.48 „GET /?id=HTTPHC1 HTTP/1.1” 200 612 „-” „GoogleHC/1.0”
35.191.1.151 „/” - - - [04/Nov/2021:10:35:02 +0000] 10.0.0.48 „GET /?id=HTTPHC1 HTTP/1.1” 200 612 „-” „GoogleHC/1.0”
35.191.1.153 „/” - - - [04/Nov/2021:10:35:02 +0000] 10.0.0.48 „GET /?id=HTTPHC1 HTTP/1.1” 200 612 „-” „GoogleHC/1.0”

Jurnalul unui nou membru VM

35.191.1.152 „/” - - - [04/Nov/2021:10:31:01 +0000] 10.0.0.54 „GET /?id=HTTPHC2 HTTP/1.1” 200 612 „-” „GoogleHC/1.0”
35.191.1.154 „/” - - - [04/Nov/2021:10:31:02 +0000] 10.0.0.54 „GET /?id=HTTPHC2 HTTP/1.1” 200 612 „-” „GoogleHC/1.0”
35.191.1.148 „/” - - - [04/Nov/2021:10:31:02 +0000] 10.0.0.54 „GET /?id=HTTPHC2 HTTP/1.1” 200 612 „-” „GoogleHC/1.0”

Diferența arată lipsa buștenilor de HTTPHC1.

Deci noul nou nu răspunde la verificarea de sănătate a load-balancer (HTTPHC1) și nu primește solicitări și asta este problema.

Alte defecțiuni Noua mașină este, de asemenea, inaccesibilă prin browser-window-SSH introduceți descrierea imaginii aici

ADAUGĂ tcpdump

Între HTTPHC1 verificator de sănătate și membru șomer:

# tcpdump -n gazdă 35.191.1.151
tcpdump: ieșirea verbosă a fost suprimată, utilizați -v sau -vv pentru decodarea completă a protocolului
ascultare pe ens4, tip link EN10MB (Ethernet), dimensiunea capturii 262144 octeți
11:30:35.109469 IP 35.191.1.151.61838 > 10.0.0.116.80: steaguri [S], win 65535, opțiuni [mss 1420,sackOK,TS ecr 0,nop,wscale 08]
11:30:36.119470 IP 35.191.1.151.61838 > 10.0.0.116.80: steaguri [S], win 65535, opțiuni [mss 1420,sackOK,TS ecr 0,nop,wscale 08]
11:30:38.167436 IP 35.191.1.151.61838 > 10.0.0.116.80: steaguri [S], win 65535, opțiuni [mss 1420,sackOK,TS ecr 0,nop,wscale 08]
11:30:40.110784 IP 35.191.1.151.59900 > 10.0.0.116.80: steaguri [S], win 65535, opțiuni [mss 1420,sackOK,TS ecr 0,nop,wscale 08]
11:30:41.111176 IP 35.191.1.151.59900 > 10.0.0.116.80: steaguri [S], win 65535, opțiuni [mss 1420,sackOK,TS ecr 0,nop,wscale 08]
11:30:43.159164 IP 35.191.1.151.59900 > 10.0.0.116.80: steaguri [S], win 65535, opțiuni [mss 1420,sackOK,TS ecr 0,nop,wscale 08]
11:30:45.112162 IP 35.191.1.151.36064 > 10.0.0.116.80: steaguri [S], win 65535, opțiuni [mss 1420,sackOK,TS ecr 0,nop,wscale 08]

Rețineți că destinația este IP-ul frontal al echilibrului de încărcare: 10.0.0.116 și, desigur, sunt doar pachete de sincronizare.

Între HTTPHC2 verificator de sănătate și membru șomer:

# tcpdump -n gazdă 35.191.1.148
tcpdump: ieșirea verbosă a fost suprimată, utilizați -v sau -vv pentru decodarea completă a protocolului
ascultare pe ens4, tip link EN10MB (Ethernet), dimensiunea capturii 262144 octeți
10:46:12.475724 IP 35.191.1.148.64638 > 10.0.0.54.80: steaguri [S], câștig 65535, opțiuni [mss 1420,sackOK,TS ecr 0,nop,wscale 08]
10:46:12.475788 IP 10.0.0.54.80 > 35.191.1.148.64638: steaguri [S.], câștig 64768, opțiuni [mss 1420,sackOK,TS,nop,wscale 7], lungime 0
10:46:12.476239 IP 35.191.1.148.64638 > 10.0.0.54.80: steaguri [.], confirmare 1, câștig 256, opțiuni [nop,nop,TS], lungime 0
10:46:12.476239 IP 35.191.1.148.64638 > 10.0.0.54.80: Flags [P.], seq 1:117, ack 1, win 256, options [nop,nop,TS], lungime 116: HTTP: /?id=HTTPHC2 HTTP/1.1
10:46:12.476301 IP 10.0.0.54.80 > 35.191.1.148.64638: Flags [.], ack 117, win 506, options [nop,nop,TS], lungime 0
10:46:12.476546 IP 10.0.0.54.80 > 35.191.1.148.64638: Flags [P.], seq 1:867, ack 117, win 506, options [nop,nop,TS]: HTTP: HTTP 866 /1,1 200 OK
10:46:12.476659 IP 35.191.1.148.64638 > 10.0.0.54.80: Flags [.], ack 867, win 267, options [nop,nop,TS], lungime 0
10:46:12.476679 IP 35.191.1.148.64638 > 10.0.0.54.80: Flags [F.], secv 117, ack 867, win 267, options [nop,nop,TS], lungime 0
10:46:12.476707 IP 10.0.0.54.80 > 35.191.1.148.64638: Flags [F.], secv 867, ack 118, win 506, options [nop,nop,TS], lungime 0
10:46:12.476879 IP 35.191.1.148.64638 > 10.0.0.54.80: Flags [.], ack 868, win 267, options [nop,nop,TS], lungime 0

Aici totul este bine.

ADAUGĂ 2021-11-16

După câteva cercetări, am găsit un alias IP lipsă în local tabel, nu este surprinzător să văd că aceasta este adresa IP a echilibrului de încărcare frontală, vizibilă ca gazdă DST în tcpdump!

Aici mașina de lucru:

# ip route show dev ens4 table local
local 10.0.0.48 proto kernel scope host src 10.0.0.48 
gazdă locală 10.0.0.116 proto 66 
# uname -r
5.4.0-1056-gcp

Și aici mașina complet actualizată:

# ip route show dev ens4 table local
local 10.0.0.54 proto kernel scope host src 10.0.0.54
# uname -r
5.4.0-1057-gcp

ADAUGĂ 2021-11-20

Acum a devenit o problemă cunoscută: [Rețea în cloud] Problemă potențială cu serviciul: Investigare

Echilibratoarele de încărcare proxy Google Cloud Global TCP ar putea să nu poată fi difuzate trafic peste regulile de redirecționare configurate cu IP-uri în 34.111.0.0/17 gamă. O remediere permanentă pentru intervalul IP este în curs

178
0 + 0
apt
Wojtek_B avatar
drapel jp
Wojtek_B
Sunt noile VM accesibile de la alte VM din același VPC? Cum te-ai conectat la noul tău VM?
0
Răspunde
drapel tl
Ivan Buttinoni
@Wojtek_B VM-ul este bine accesibil prin IP-ul său (10.0.0.54). este LB (IMO componenta frontend) care nu cunoaște IP-ul real al mașinii.
0
Răspunde
Wojtek_B avatar
drapel jp
Wojtek_B
Am o suspiciune că de vină aici este [Netplan](https://netplan.io/) cu care nu sunt familiarizat, dar din moment ce este o caracteristică de utilitate de rețea și după o actualizare ați pierdut IP-ul extern al VM-ului și unul dintre controalele de sănătate eșuează. Verificați fișierele dvs. `/etc/netplan/*.yaml` înainte și după o actualizare - sunt modificate?
0
Răspunde
Wojtek_B avatar
drapel jp
Wojtek_B
Puteți încerca oricând să creați o altă verificare a stării de sănătate care să funcționeze și să o modificați în setările load-balancer.
0
Răspunde
drapel tl
Ivan Buttinoni
@Wojtek_B dacă scopul de a găsi pachetul vinovat, da, verificarea `/etc/netplan/*.yaml` ar putea fi o soluție, dar scopul meu este să rezolv problema păstrând posibilă abordarea curată, de exemplu: creați o nouă mașină cu ubuntu-20 (ar trebui să fie mai bine dacă ubuntu-22) sau dezinstalați pachetul neutil XYZK, care este originea reală a problemei.
0
Răspunde
drapel tl
Ivan Buttinoni
@Wojtek_B Nu cred că este posibil să ocoliți lipsa de cunoaștere a „IP-ului membru al grupului” din interiorul echilibrantului cu orice verificare reală a stării de sănătate. :(
0
Răspunde
Wojtek_B avatar
drapel jp
Wojtek_B
Puteți încerca să faceți upgrade, dar să păstrați versiunile vechi ale pachetelor `libnetplan0`, `netplan.io` și `nplan`?
0
Răspunde
drapel tl
Ivan Buttinoni
Bună @Wojtek_B, am făcut upgrade la sistem, cu excepția pachetelor `*netplan*`, din păcate am problema, ei nu sunt "făcătorii de probleme"
0
Răspunde
Wojtek_B avatar
drapel jp
Wojtek_B
Poate încercați să le instalați unul câte unul și să verificați dacă acest lucru „rupe” configurația. Pare o soluție destul de rapidă, deoarece sunt doar câteva dintre ele.
0
Răspunde
drapel tl
Ivan Buttinoni
Nu atât de rapid, implică procesul complet de implementare: pornire-> actualizare -> oprire-> imagine->disc->șablon->deploy + sau - 15/20 minute un pachet. Ok, nu construiesc Roma, dar nu atât de repede
0
Răspunde
Wojtek_B avatar
drapel jp
Wojtek_B
Puteți încerca oricând să instalați prima jumătate și dacă după repornire totul funcționează, știți deja că trebuie să căutați vinovatul în cealaltă jumătate. Împărțiți-l din nou în două și repetați procesul.
0
Răspunde
drapel tl
Ivan Buttinoni
@Wojtek_B abordarea b-tree întotdeauna bună :D O să încerc mâine
0
Răspunde
drapel tl
Ivan Buttinoni
@Wojtek_B ce părere ai despre ultimul meu *add*?
0
Răspunde
Wojtek_B avatar
drapel jp
Wojtek_B
Bună treabă în cuie - ai adăugat traseul? `IP route add to local IP_HERE dev ens4 proto 66`
0
Răspunde
drapel tl
Ivan Buttinoni
@Wojtek_B Tocmai am citit răspunsul lui EthanWang și acum prefer să știu răspunsul la întrebarea lui: „de ce google-guest-agent nu rulează automat” ;)
0
Răspunde
Wojtek_B avatar
drapel jp
Wojtek_B
Aceasta arată ca problema cu agentul de înregistrare și cel mai bine ar fi să o raportați pe [Google's IssueTracker](issuetracker.google.com). Am încercat să-l reproduc cu o instanță simplă Ubuntu 16.04 și am rulat sudo apt upgrade fără probleme.
0
Răspunde
Puncte:3
Ethan Wang avatar Server
drapel gb
Ethan Wang

După testare, cloud-init este cauza principală.

Conform cu aceasta cometariu, disable_network_activation: adevărat ar trebui setat pentru a evita conflictul cu google-guest-agent serviciu.

Soluția este adăugarea setării în cloud-init config.

cat > /etc/cloud/cloud.cfg.d/99-disable-network-activation.cfg <<EOF
# Dezactivați activarea rețelei pentru a împiedica \`cloud-init\` să facă rețea
# modificări care intră în conflict cu \`google-guest-agent\`.
# Vezi: https://github.com/canonical/cloud-init/pull/1048

disable_network_activation: adevărat
EOF

Acest fișier există în imaginea oficială ubuntu-1804-bionic-v20211103.

După adăugarea acestui fișier, fișierul google-guest-agent rulează normal.

0 + 0
drapel tl
Ivan Buttinoni
Cred că te-ai descurcat foarte bine, ai găsit soluția și ai creat calea bash (funcționează ca un farmec). Loc de muncă bun!
0
Răspunde
Puncte:0
avatar Server
drapel cn
Ethan Wang

Am o mașină care rulează Ubuntu 18.04.5, am întâlnit aceeași problemă după ce am rulat apt dist-upgrade, de asemenea, upgrade google-guest-agent 20210629.00-0ubuntu1~18.04.1 (actualizat de la: 20210414.00-0ubuntu1~18.04.0).

Găsind asta google-guest-agent nu rulează după upgrade. Când execut /usr/bin/google_guest_agent manual, problema este rezolvată.

Inca nu stiu de ce google-guest-agent nu rulează automat.

0 + 0
drapel tl
Ivan Buttinoni
Mulțumesc @Ethan, voi trimite informațiile dvs. către asistența Google și vă voi ține la curent
0
Răspunde
drapel tl
Ivan Buttinoni
Mă întreb de ce această problemă nu este omniprezentă. Ar putea fi pentru că se întâmplă doar pe sistemul „personalizat”, deci, de exemplu, am dezactivat „apt-daily.service”. Aceeași pentru tine?
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.