Hetzner cloud anomália

Közösségi kerekasztal

Sziasztok,

történt egy nagyon érdekes, bár már több alkalommal visszatérő hiba a tárgyban szereplő szolgáltatással:

Adott egy olcsó cloud instance, 1-2% általános CPU kihasználtsággal. Erre a gépre szökőévenként egyszer lépek be, talánm konfig módosítás miatt. A gép maga egy szimpla nginx -en szolgál ki statikus parkoló oldalakat; lokális írás (logok) sincsenek. Két héttel ezelőtt, egy hétvégén kérésnek megfelelően módosítottam egy hibás konfigot az nginx -ben, emit követően én, és az issue -t nyitó is nyugtáztuk, hogy alles in ordnung.
Ma pedig jött a meglepetés: az issue ujranyílt, ugyanazzal a hibajelenséggel. Beléptem ( miközben az járt a fejemben, hogy  a delikvens nem törölte ki a böngésző cache -t ) és az nginx pontosan ugyanazzal  a konfig állománnyal köszöntött, mint az említett módosítás előtt.
Az uptime 329 nap, tehát csak arra tudok gondolni, hogy az alacsony terhelésű gépen csináltak egy freeze -t és átmozgatták máshova; de az image, ami megjelent alatta még valami régebbi volt. Ez az elmúlt fél évben már a 4. alkalom különféle gépeken és lokációkban; közös pontok pedig:

  • alacsony terhelés/kihasználtság; ~0 diszk írás
  • nincs backup beállítva
  • nincs snapshot a gépről
  • 1-3 héttel azelőtti állapot "töltődik vissza"
     

Találkoztatok már hasonlóval, esetleg ugyanennél a szolgáltatónál? Kicsit aggaszt a dolog, mert jelezhették volna (akár kieséssel is); és akár azt is, hogy egy régi verzióra tudnak csak visszaállni; 100+ instance van náluk a részünkről...

  • 1145 megtekintés

( ibenny v | 2022. 04. 28., cs – 11:07 )

Szerkesztve: 2022. 04. 28., cs – 11:11

Soha semmi hasonlót nem tapasztaltam.

( gabrielakos v | 2022. 04. 28., cs – 11:08 )

simán lehet h bugzik náluk valami, én bejelenteném hibára

zászló, zászló, szív

Bizonyitekod annyi azert van, hogy jott egy uj ticket, amelyet ugyanugy kellett megoldani. Az ugyet pedig lehet eszkalalni, lassan es megfontoltan is, nem rogton az asztalt csapkodva. Altalaban eleg melyre tudjak asni magukat onalloan is a szerzodeses felek, nem kell a fejuket utni hozza :)

Ha meg megy a remote log, akkor azert ratehetnel egy audit logot is (ha meg nincs) a rendszerre, hogy kicsit jobban kepben legyetek mi tortenik ott.

Ha azt gyanitod, hogy a VM-et fagyasztottak, mozgattak, stb., akkor egy heartbeat, watchdog vagy steal counter-hez hasonlo megoldassal (lasd meg CPU steal time, de nyilvan itt nem az orejelciklusokat tartanad szamon) tudsz mar valamit kezdeni.

Egyebkent van barmi szolgaltatasminosegi vallalasuk feletek, vagy csak olcso?

( p2pking | 2022. 04. 28., cs – 11:29 )

pont azert mert nincs iras es dobjak egy olyan gepre amin olcsobb es ugysem veszed eszre, hogy nem ssd van mar.

Regen is csinaltuk a regi hdd storagere atment es nem a flash en foglalt helyet, kliens orult ugyanugy, a flasht meg eladhattad ujra.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

Lehet újracsinálnám az instance-ot, hogy megint kezdje ssd-n.

aztán csinálnék minden nap 1 file-t cronból valahova (nem /tmp)

abból elég jól kiderül hogy mikori a snapshot ami átkerült, innen lehet nyomozgatni.

de mondjuk a mostani logjaidat is visszanézheted h mikori az utolsó (ami nem mai)

zászló, zászló, szív

- szerintem lehet mar nincs is HDD naluk, csak flash,

- nem hiszem, hogy csinalnanak ilyet, (overselling nyilvan van, de ilyen "stikliket" szerintem nem csinalnak)

- amugy is storage cluster van, ha a VM migralodik is masik vasra, a storage marad alatta.

( _Franko_ v | 2022. 04. 28., cs – 14:41 )

Szerkesztve: 2022. 04. 28., cs – 14:42

1, Szerintem nincs náluk live migration, egy szimpla storage bővítéshez is le kell állni teljesen és kaptam már értesítést, hogy relocation miatt le fog állni a VPS.

2, Mi lenne, ha megkérdeznéd tőlük, hogy náluk mi történt?

3, Nem lehet, hogy te használsz valamit, ami időnként elszabadul nem tervezett módon (configuration management, etckeeper vagy egyéb)?

https://iotguru.cloud

1) passz, volt már lerohadt host-rol migráció, uptime ment tovább. 

2) bizonyíték nélkül nem akarok ilyenbe belemenni, a cloud bevezetése idején is volt sok probléma, de addig tagadták, amig lehet. Hivatalosan tuti nem történik ilyen, arról jönne notification. 

3) semmi ilyen tool nincs használatban 

Error: nmcli terminated by signal Félbeszakítás (2)

( sibike | 2022. 04. 29., p – 21:33 )

Ha visszaállnának egy korábbi állapotba, akkora logokból ennek egyértelműen ki kellene derülni, pl hiányzik x idő belőle, vagy rosszul jár a szerver órája.

Sajnos előbb cselekedtem, utána gondolkodtam. A logok nem tartalmaznak releváns információkat, az ntp meg teszi a dolgát (systemd-timesyncd nem logol itt) Nem forgalmas környezet, akár 4-5 min. is lehet két request között. 

Error: nmcli terminated by signal Félbeszakítás (2)

A log fileok gyakran módosulnak, és ha az egész gép korábbi állapotba kerül, az érintené a logfile-okat is.

Szerk: Lehet nem értjük meg egymást. Tegyük fel, hogy te kijavítottad a konfig file április 10. 18:00-kor (fiktív dátum)

Szerinted:

- melyik időpontban állították vissza a vm-et?

- melyik időpontRA állították vissza a vm-et?

(svn-ben is látszik; konfigurációs állományok abban vannak tárolva).

Három napja semmi ilyesmi nem volt még, most meg kiderül, hogy mégis van valamilyen verziókezelő a rendszerben? :)

Továbbra is ez a legerősebb tippem, hogy ez a jelenség a te oldaladon keletkezik... a Hetzner egy kutyaközönséges olcsó VPS szolgáltató, a legolcsóbbak egyike, a nagyok (sem) adnak olyan űrtechnikát, amire gyanakszol, hogy megtörtént.

https://iotguru.cloud

Hát, náluk csak a Contabo olcsóbb, akik KVM-et adnak. Annál olcsóbban már csak OpenVZ van. És közvetlen tapasztalatom szerint nincs live migration, mint írtam, kaptam már relocation értesítést, hogy leállás lesz, illetve egy szimpla disk átméretezést se tudnak online megcsinálni, ahhoz is leállás kell... és mindez érthető, mert a local storage RAID10 SSD a host gépen.

https://iotguru.cloud

Várj, tehát a módosítás utáni svn commit alapján kimondod, hogy ezt én basztam el? Ez komoly? Figy, még systemd is van, erről sem beszéltem! Sőt, asszem valahol fut sshd is, erről sem volt szó.

Komolyra fordítva:

Nem derült meg ki, mi történt; Hetzner úgy nyilatkozott, hogy ők soha nem csinálnak ilyet ( vártam is), nem tudnak ilyen hibáról, majd közölték, mennyi az SLA; ezután Matthias elkoszont, az issue ezzel resolved.  Szerintük.

Error: nmcli terminated by signal Félbeszakítás (2)

Várj, tehát a módosítás utáni svn commit alapján kimondod, hogy ezt én basztam el? Ez komoly?

Nézd, én direkt rákérdeztem, hogy van-e használatban bármilyen tool, amivel az inkriminált fájlok kezelve vannak. Azt írtad, hogy semmi ilyesmi nincs, most meg kiderült, hogy mégis van egy subversion, ahol és amivel a fájlok kezelve vannak, amelyek változtak. A leírtak és hozzáírtak alapján még mindig úgy gondolom, hogy a legerősebb lábakon az a feltételezés áll, hogy a te oldaladon van valami bug vagy side-effect a környezetben, ami időnként megszopat.

hogy ők soha nem csinálnak ilyet ( vártam is), nem tudnak ilyen hibáról

De most komolyan, mi előnyük származik belőle, hogy miközben csak törekednek 99,9 százalékos rendelkezésre állásra, vagyis ennyit se kell biztosítaniuk és nincs semmi következménye, ha elveszítik a teljes storage tartalmat, akkor is ilyen fondorlatos hülyeségekkel szopatják az ügyfeleket, hogy visszaállnak a fájlrendszerrel vagy egy részével egy 1-3 héttel korábbi állapotra és a virtuális gép ebből nem vesz észre semmit? Eközben pedig minden szarért le kell állítani a gépeket: ha bővítenél, le kell állni; ha korrekt snapshot kell, le kell állni; ha módosítasz a placement group beállításokon, le kell állni; ha hozzáadnál volume-ot, le kell állni; ha törölnél volume-ot, le kell állni; hardver csere miatt relocation van, le kell állni; és a többi.

Meg ezen felül az is gyanús, hogy más se tud ilyen hibáról... nyilván nem zárható ki, hogy ők basztak el valamit, de minden jel arra mutat, hogy a hiba inkább nálad van.

https://iotguru.cloud

Tudom, hogy minden ellenem szól. Pont ezért indítottam ezt a diskurzust. 2012 óta vagyunk hetzner ügyfelek; nem általános, ami történt, de ez a negyedik hasonló.

Az, ami most jött elő, kétféleképpen idézhető elő a mi esetünkben:

  1. Elszabott konfig. Ez azért kizart, mert az ügyfél vissvisszajelzes alapján előző alkalommal javítottam a hibát. Ezt követően nem történt login a gépre.  Az svn nem automatizáltan commitol; adott gépre visszaallitas pedig root interakcióval működik. 
  2. Más dolog történt. Mivel nem lépett be senki, így vagy átjáróhaz az nginx ( egy db PHP script, http_host az egyetlen elem, amivel dolgozik, str_replace és readfile erejéig)
  3. Mas dolog történt, a szolgáltató infrastruktúrájában. Én ezt gyanítom. A helyemben te is ezt tennéd. Nem azért, mert hibátlan, amit teszek, hanem mert ez a jelenlegi logikus magyarázat - ami persze logikátlan. 

Error: nmcli terminated by signal Félbeszakítás (2)

( VincentV | 2022. 04. 29., p – 22:14 )

Szerkesztve: 2022. 04. 29., p – 22:18

Szerk.: sztornó, nem releváns amit írtam.

Ez érdekelne pl. engem is. Az unfreeze nem feltétlenül hoz magával sighup - ot, pláne nem szelektíven. De megtörtent.

Szerk: nem írtál hülyeséget, ez egy anomália. Ezért is akarok normális bugreportot. Jól jött itt pár ötlet. 

Error: nmcli terminated by signal Félbeszakítás (2)

Attól volt hülyeség szerintem (csak a küldés megnyomása után jöttem rá), hogy ha ezt egy olyan belsős snapshottal csinálják aminél memóriát is mentenek, akkor az egészet el tudják indítani úgy, hogy az előző futó állapotot kapod a hibás Nginx-el. Persze nem szándékosan, de ha ilyesmi megoldás áll a háttérben, és annak a környékén van valami bug, akkor észre se veszed, a gép elindul snapshotból pár sec kieséssel, az ntp syncel egyet, aztán ennyi. Ha nincs annyira érzékeny monitoringod vagy szerencséd, hogy elkapja azt a kis kiesést, vagy az ntp sync előtti időszakot (már ha figyeli a rendszeridőt), akkor tényleg csak onnét tudod meg, hogy szól újra az ügyfél hogy nem jó (ahogy az történt is).

miert veszitek biztosnak, hogy a futo vm-et is visszallitottak, memoriaval egyutt (azt meg ki szokta lementeni egyaltalan?)

irtak fentebb hogy ceph-et hasznalnak, meg hogy vps, tehat vszinu egy nagy kozos storage-n van a data. boven eleg sztem ha a storagen tortent visszalllitas (tehat csak a fileok valtoztak), a futo vm-ekhez nem nyultak kozben. ha csak par percenkent van request, fel se tunik a vm-nek ha kozbe megvaltozott a data...

Én sem gondolnám, viszont ha nem mentették a memóriát, akkor nem a Hetzner szúrta el. Máshogy ezt szerintem nem lehet megcsinálni az ő oldalukon, a Nginx ugyanis nem olvassa újra a configot csak úgy magától, a vm pedig nem indult újra. Tehát ha csak a storage-ot cserélik ki alatta, akkor ügyfél oldalon ebből az egészből a mai napig nem tűnt fel volna semmi, még mindig futna a Nginx process a javított config opcióval, a disken meg lenne egy régebbi file, ami majd rebootnál vagy service restartnál lépne életbe, és akkor derülne csak ki a turpisság.

Olyanokat ebbe az érvelésbe nem számoltam bele, hogy van valamilyen default-tól eltérő megoldás a rendszeren, ami újraindítgatja az Nginx-et (pl. certbot?). De erről nem volt infó.

( bkil | 2022. 05. 12., cs – 21:50 )

Nekem nagyságrenddel olcsóbb VM-em is fut máshol (több heti napi mentéssel ingyen) évek óta és az sem csinál ilyet. Én is osztom azok álláspontját akik szerint a szolgáltató ilyet nem csinál.

Megjegyzem, hogy a certbot is átírja az nginx konfigurációt, és akkor pont csak pár havonta futsz ebbe bele.

Sikerült belőni az ellenőrzést? Tényleg csak ennyi volna nagyjából (bár nem tudom mennyiben segítene ez):

printf "%s\n" '#!/bin/sh' 'touch /var/local/$(date +%Y%m%d)' > /etc/cron.daily/napi
chmod +x /etc/cron.daily/napi

Egy fokkal hasznosabb volna cron.hourly-ból futtatni valamit ami legalább a config fájlok md5sum-ját illetve utolsó módosítási idejét kiszolgálja valami eldugott HTTP útvonal alatt amit kívülről monitorolsz (vagy akár RSS-ben), vagy akár gpg titkosítva. Tartalmazza a generálás időbélyegét is, hogyha befagy ez az állomány akkor is lehessen riasztani!

Itt nem a változások elmentésén van a hangsúly (az etckeeper is volt itt említve ha végigolvastad a beszélgetést), hanem az érzékelésén. Azaz rájönni, hogy melyik saját automatizmusa rontja el aminek felderítésén sokat segítene egy efféle monitoring. Vagy arra gondolsz, hogy cron.hourly vagy sűrűbben hívjon etckeeper commit + push-ra és a távoli (privát) tárolón kövesse az új változáscsomagokat RSS-ben? Ez is megoldás lehet mondjuk.

Ha a gyanított eset forog fenn, akkor a git status kevés lesz, mert az csak a local módosításokat veti össze a local repository tartalommal, ami nyilván egyformán változik.

Szóval a gyanított esetben az következik be, hogy az egész storage időben visszautazik pár hetet, miközben a virtuális gép minden más tranziens része időben előre megy. Ezt úgy tudod detektálni, hogy valami remote dologgal kell összevetni a storage állapotát, erre egy `git pull` jobb, mert az észre fogja venni, hogy a local repository is időben visszautazott.

De továbbra is úgy gondolom, hogy ha ilyen mutatványra képes a Hetzner szimpla fillérbaszásból, akkor miért ne adná akár pénzért ezt a dolgot, mert csak le kell állítanom a virtuális gépet ahhoz, hogy másik fizikai gépre tegyék (spread placement group), pedig az tényleg faék egyszerű dolog lenne egy ilyenhez képest. De le kell állítanom és pénzért sincs olyan feature, hogy leállás nélkül áttegyék másik fizikai vasra.

https://iotguru.cloud