Uutiset:

13.10.2024
PALAUTUMISTIEDOTE

FinWX:n palvelut katkesivat hetkellisesti 13.10.2024. FinWX:n web-serveri palautettu vuorokautta aikaisempaan tilanteeseensa.
Lue häiriötilanteesta lisää täältä.

FinWX:n ylläpito pahoittelee katkoksen aiheuttamaa häiriötä.

Main Menu

Dedi nurin

Aloittaja weatherc, sunnuntai, 12.01.2020, 12:57

« edellinen - seuraava »

0 Jäsenet ja 1 Vieras katselee tätä aihetta.

iccb

Ei muutakun tilaukseen ja kovaa ajoa!  ;D
Ei näköää KVM/qemu ole muuttunut niin paljoa, että olis yhteensopivuus rikottu vanhemman version kanssa...

weatherc

Lainaus käyttäjältä: iccb - maanantai, 20.04.2020, 12:23
Ei muutakun tilaukseen ja kovaa ajoa!  ;D
Ei näköää KVM/qemu ole muuttunut niin paljoa, että olis yhteensopivuus rikottu vanhemman version kanssa...

Jeps  ;D

Sen kummemmin vielä ajankohdasta mutta suunnitelma voisi olla tämän tapainen

Dedillä on 500 GB backuptila/storagebox jonne nuo backupit menevät. Tämä ei ole serverikohtainen vaan käyttäjäkohtainen eli siihen pääsee käsiksi myös uudelta purkilta :)

Ensin Proxmox 6 sisään ja kokeilla noiden KVM:ien sisäänsaamista. Tässä kohtaa nähtäneen myös vähän kuin kauan tuohon menee aikaa. Veikkaan että hetki jos toinenkin.
Kun ne ovat sisällä niin kokeilu noiden virtuaalien kokojen kasvattamisesta. 
Kun nuo sujunut ok niin voidaan suunnitella tarkemmin sitä varsinaista asennusta :)

Koska datakatkoa tulee olemaan (snapshotin teko - asennus - serverin siirto) niin varsinaiseen asennukseen otetaan tietty mahdollisimman tuoreet snapshotit. Jos samalla kun kerraan ollaan vauhdissa siivotaan tuota myslin ibdata1-filua niin myslistä myös tuore dumppi sopivassa kohtaa. Tämän voisi ottaa juuri ennenkuin siirtää serverin jolloin dumpin data olisi tuoreempaa mitä snapshotissa oleva.

weatherc

#32
2-2.5 viikon jono näyttää olevan sakemanneilla. Tuusulassa rauhallisempaa kun vain 1-3 päivän jono.
Tai sit johtuu Toyota-nuhasta. Selittänee myös hintaeron Tuusulan ja Saksan välillä (joka näkys vasta tilaussivulla siinä kohtaa kun olisi pitänyt valita sijanti). 

https://wiki.hetzner.de/index.php/Auftragsbearbeitung/en

weatherc

#33
Tuli sellainenkin aatos että tekisikö kolmannella levyllä jotain, niitäkin kun on saatavilla?
Meinaan kun tuo dedihän kirjoittaa levylle aika reilusti kun myslit, kartat sun muut (tosin iso osa karttaserverin jutuista kirjoitetaan ramiin). Hmm..
Eli vaikka 2 x 500 GB (raid1) + 1 x 250 GB.
Esim webbivirtuaali 500:lla ja karttavirtuaali 250:lla (jos tuo on Proxmoxissa edes mahdollista), tai mysli 250:lla.

weatherc

Laastarina tehty myslin ibdata1-filun tyhjennys.
Myslin käyttämä levytila tippui 87G:stä 15G:hen  :)

Dumpin teko oli helppoa ja nopeaa, kesti n 5 min. Dumpin koko 5.5G
Stackoverflowsta löytyi bash-häkkyrä jolla sai kannat poistettua. Juju tässä oli se että 3 kantaa piti säästää (mysql,performance_schema,informtaion_schema) mutta kaikki muut poistaa ja niitä on sen verran että nopeampi keino oli tehdä häkkyrä joka hoitaa homman looppina.
ibdata1- sekä ib_logfile*-filujen poisto sekä my.cnf tarkistus että tarvittavat asetukset kohdallaan (olivat)
Myslin uudelleenkäynnistys ja tarkitus että nuo äskeiset filut generoitui uudelleen..
Kantojen sisäänajo dumpista joka oli se hitain tuossa, kesti yli pari tuntia. Hitaimmat tuossa luonnollisesti EWN:än käppyrätaulukot joissa rapiat 66M riviä  :P

weatherc

#35
No niin, nyt kerkee vähän raporttiakin tekemään :)

Tosin, on tässä muutakin tehty (kuten käyty merenrantarehveillä ;D). Oman mausteen soppaan antoi tuo Telian katko, meni jokunen tunti keskiä varayhteys jolla päästä nettiin....

Lyhyesti: Nyt tiedetään miksi noita backuppeja tehdään, vaikka ne sit kestäisi 12h tehdä. Nyt tiedetään myös vähän kuin kauan webbivirtuaalin palauttaminen kestää (pakattu backuppi 140G, virtuaalilevy 280G), tunteja.

Eilen illalla hajosi virtuaali aika totaalisesti. Tai ei ainakaan vastannut, eikä käynnistynyt. Dead, kaputt. Ei auttanut kuin hakea backuppi kehiin.
Tämän avaaminen kesti parisen tuntia. Ei paha, mutta se perkele avasi sen backuptilaan. Ja sieltä 280G:n filun hakeminen ei ollutkaan niin vaan "muutaman minuutin nakki" koska Hetznerin sisäverkon nopeus oli kaikkea muuta kuin gigoja sekunnissa, jojoili 5 Mbit ja 400 Mbit väliä. Eikä yhdellä yrityksellä onnistunutkaan. Toisella yrityksellä siinä vaiheessa kun rsync alkoi kertoilemaan 5+ tunnin latausaikoja tämä meni nukkumaan.
Toisaalta, pakatun levyn hakeminen dedille ja avaaminen paikallisesti ei olisi onnistunut sen tilanpuutteen takia. 140G filua on vaikea laittaa 60G tilaan...

Aamulla katsoin että haettu levyn koko oli ok 280G ja painoin käynnistysnamiskaa. Tiesin että käynnistykseen mennee tovi jos toinenkin ja aatteelinkin antaa käynnistyä rauhassa ja myöhemmin katsoa mikä tilanne.
Tilanne oli se että sivut latautui mutta myslistä ei tietoakaan ja loadit huiteli jossain 40:in paremmalla puolella (piikki kävi yli 120:in). Palttiralla 4:hän olisi se hyvä maksimi...Komentorivillä tuuppasi seuraavanlaista erroria alvariinsa (tuo "kworker" oli mikä milloinkin prosessi):
kernel:NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:3:7639]
Kiva...
Uudelleenkäynnistys ei auttanut asiaa joten eikun koittamaan saada nuo loppumaan ja loadit alas. Eli seis niin Nginxit (estääkseen sisääntulevan liikenteen) kuin FTP:t ja cronit. Ja CSF:än (palomuuri). Tosin Cpanel tuuppaa tahtoa käynnistelemään noita muita paitsi Nginxiä uudelleen jos pois pelistä, ja niin myös tekikin.
Nyt päästään siihen mielenkiintoiseen...
Loadit lähti kyllä tippumaan, mutta aivan tolkuttoman hitaasti. Meni 3-4 tuntia että päästiin alle 10:in. Myslin käynnistyskin kesti melkein tunnin, kun InnoDB palautteli jotain. Kun alkoi näyttää suht hyvältä käynnistin Nginxin ja sivut alkoi lataumumaan ihan ok.
Mielenkiintoinen seikka tässä kohtaa oli se, että vaikka sivut toimis ja haki myslidataa ihan ok, niin esim EWN:n päivitykset eivät toimineet kuin osittain, mutta siten että pikkuhiljaa alkoivat toimimaan. Tämä on todella outoa.
Noh, tässä kohtaa piti lähteä rehveille :D Sieltä kotiuduttua niin EWN-päivityksetkin näyttävät toimivan ok. Mutta se että homman normalisoituminen, siitä kun käynnistää => toimii normisti, kestää yli 6h on kyllä outoa.


weatherc

Tuosta backuptilasta ja sen hitaudesta tuli mieleen että tuonhan vois korvata kolmannella levyllä. Voisi olla vaikka vanha kunnon HDD. Sen vain mounttais tarvittaessa kun backuppia päivittää. Tällöin myös niiden teko todennäköisesti nopeuttuis huomattavasti.

einari

Lainaus käyttäjältä: weatherc - sunnuntai, 26.04.2020, 16:09
Tuosta backuptilasta ja sen hitaudesta tuli mieleen että tuonhan vois korvata kolmannella levyllä. Voisi olla vaikka vanha kunnon HDD. Sen vain mounttais tarvittaessa kun backuppia päivittää. Tällöin myös niiden teko todennäköisesti nopeuttuis huomattavasti.

Tuollaistahan yritin kaupata aiemmin.. kahden ( työ)levyn systeemiä..  että olisi nopeampi  tiedonsiirto levyjen välillä..   8)

weatherc

Lainaus käyttäjältä: einari - sunnuntai, 26.04.2020, 17:42
Tuollaistahan yritin kaupata aiemmin.. kahden ( työ)levyn systeemiä..  että olisi nopeampi  tiedonsiirto levyjen välillä..   8)

Tuollainen on periaatteessa nytkin, kun on tuo backuptila joka pystyy liittämään kansiona "normi kansioksi" mutta se on vaan jotenkin outo lintu tominnaltaan (väittää esim että olisi 170G tavaraa vaikkei ole ensimmäistäkään filua siellä) sekä hidas nopeudeltaaan (en tiedä onko se edes samassa datakeskuksessa). Eikä se ole tarkoitettu kuin säilytystilaksi. Siinä mielessä olisi 3:s "oma levy" parempi. Plus tietty että sitä voi käyttää muuhunkin.
Mitä nyt seurannut että mikä on se joka vetää levyt piippuun niin se on backupin kirjoitus, ei niinkään levyn lukeminen/backupin tekeminen, eikä myslikään. Tuossa aikasemmin kun tuon backuptilan mounttaus failasi, ja se kirjoitteli sitä dedin levylle niin kauan kuin tilaa riitti, niin oli myös IO:t tapissa.

weatherc

#39
Webbivirtuaali sammutetaan pikku tutkimuksen ajaksi.
Näyttää ainakin siltä että Proxmox tehnyt jotain omia säätöjä siinä kohtaa kun backuppia purettu. Pitää tarkistaa.

EDIT: Eeeehhhhh.....Ööööhhhh...aha...miten tämä on edes mahdollista???

Okei, eli, olin tekemässä backuppia "nyt kun raksuttanut ok vuorokauden" siten että pystyn itse valmomaan sitä (viime yön backupit oli pois päältä koska backuptilassa oli se purettu levy viemässä tilan. Näin oli vielä eilen ja oletin siis että on edelleenkin koska en ole mitään siivonnut sieltä, vaan ainoastaan kopsasin sen dedille rsyncillä. Samoin voisi olettaa ettei Proxmox muuttele asetuksia saatikka hardware-astuksia omin päin, eikä varsinkaan virtuaalien kovalevyjä.

Noh.
Karttavituaalin backuppi meni ihan ok. Webbivirtuaalin backuppi tyssäs heti alkuun ja tässä kohtaa osui silmään se kummajainen. Siinä luki näin:
include disk 'virtio0' 'Hetzner:101/vm-101-disk-1.qcow2' 280G
Eli että levy sijaitsee backuptilassa (jonka nimi Proxmoxissa on tuo Hetzner). Vertailu karttavirtuaaliin vahvisti asian, siinä kun tuo alku on local:. Tämä vahvistui myös kun tarkisin dedillä olevien levyjen aikaleimat. Karttavirtuaalin oli "nyt", se sinne kopioitu webbivirtuaalin se milloin se rsyncaus valmistunut.
Proxmox oli siis "viisaudessaan" kun painoin restore-namiskaa vaihtanut omin päin myös levyn sijannin backuptilaksi. Nice. Not.
Mielenkiintoista tässä oli se ettei tuo "backuptilassa oleva" vm-101-disk-1.qcow2 näkynyt missään eikä sen koko edes täsmännyt edes backuptilan väittämään "käytössä olevaan tilaan".  Varsinainen haamuleyv siis joka ei näy missään. Ei liene tässä kohtaa yllätys että kun sammutin webbivirtuaalin kyseinen haamulevy hävisi (vaikka elin toivossa että se olisi vaan ollut "varattu" eikä siten näkynyt ja että olisi ilmestynyt näkösälle sinne backuptilaan sammutuksen yhteydessä). Yhtä kysymysmerkkiä on kyllä että miten sieltä backuptilasta edes voinut hävitä tuo levy.

Noh tämähän selitti se tökkivän käynnistyksen eilen. Jos nyt jotain positiivista etsii.
Ja onneksi osui silmään nyt eikä 3 viikon päästä.