-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Ahojte,
v nasledujicich dnech mam v planu zbavit konecne vpsFree EXT4 filesystemu pro ukladani dat VPS. Uz jsme si s nim vytrpeli svoje - rsync na neustale kynoucich VPS zacina bejt neunosny.
S tim souvisi, ze z node8, node2 a node*.pgnd musim odsouvat VPS na takove, ktere maji uz ZFS.
Migraci musim volit "off-line", tzn. VPS se to projevi jako stop-downtime-start.
Ten restart zavisi tedka na vice vecech, podle toho, co delame - ale pokud jde zrovna o migraci, tak ta probiha nasledovne:
1. pre-sync za behu 2. stop VPS na originalnim nodu 3. finalni sync zmen co se stihly udelat za behu pred stopem 4. start VPS na novem nodu
Misto 2+4 se da pouzit suspend/resume, ale VPS nesmi mit "enabled features" ve vpsAdminu (VPS s NFS/NFSd vevnitr neni migrovatelna, neda se dumpnout ten context NFS+RPC) - rikame tomu online migrace (i kdyz je tam chvilicku downtime, ale ta VPS neztrati kontext). Nicmene jak rikam, potencialne jsou tam problemy napr. pri prechodu mezi verzemi jadra - ktere se teda snazim drzet konzistentni v celem clusteru, ale zatim se to jeste nedari a proto online migraci radeji nepouzivame. Ta nekompatibilita se totiz projevi az po suspendu pri pokusu o resume, coz znamena, ze pak ten dump muzu zahodit a pro VPS je to, jak kdyby ji nekdo vytrhl ze zasuvky, coz je min libiva varianta, nez clean shutdown.
Dokud ted pouzivame rsync misto posilani snapshotu filesystemu pres ZFS, je to pomalejsi, obzvlast, kdyz mas ve VPS cca nad 0.5M souboru, pak uz se to pozna. Pak muze bejt downtime peknejch par minut pri tom bodu 3.
Ale jakmile se konecne zbavime tech po***** nodu s ext4, tak to pujde mnohem rychleji - ZFS send/recv nezajima, kolik je to souboru, nejsou to metadata operace, je to proste serializovany stream bloku filesystemu. Pak se dostaneme prave na ty rady desitek sekund downtime max.
Nicmene tohle se nedeje moc casto, ty skatulata-batulata se dejou ted prave proto, ze zbavuju vpsFree nodu s ext4 - aka. musi byt nejdriv hur, aby mohlo byt lip :(
+ omluva vsem na node8: omylem jsem blbec nedomyslel side-effects pkill -f tar, coz s sebou vzalo i procesy typu: /usr/sbin/apache2 -k start Za to se vazne omlouvam, skolacka chyba, co by se dit nemela.
S pozdravem / Best regards,
Pavel Snajdr
+421 948 816 186 | +420 720 107 791 | 110-010-956 CTO of Relbit | Predseda vpsFree.cz, o.s. | RHCE http://relbit.com | http://vpsfree.cz | https://www.redhat.com - -- S pozdravem / Best regards,
Pavel Snajdr
+421 948 816 186 | +420 720 107 791 | 110-010-956 CTO of Relbit | Predseda vpsFree.cz, o.s. | RHCE http://relbit.com | http://vpsfree.cz | https://www.redhat.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Ahoj vespolek,
takze pokracujeme dal, migrujeme node2 -> node10.
To uz je nastesti posledni produkcni node s ext4.
Pak uz akorat playground.
S pozdravem
Pavel Snajdr
+421 948 816 186 | +420 720 107 791 | 110-010-956 CTO of Relbit | Predseda vpsFree.cz, o.s. | RHCE http://relbit.com | http://vpsfree.cz | https://www.redhat.com
On 04/11/2014 02:10 PM, Pavel Snajdr wrote:
Ahojte,
v nasledujicich dnech mam v planu zbavit konecne vpsFree EXT4 filesystemu pro ukladani dat VPS. Uz jsme si s nim vytrpeli svoje
- rsync na neustale kynoucich VPS zacina bejt neunosny.
S tim souvisi, ze z node8, node2 a node*.pgnd musim odsouvat VPS na takove, ktere maji uz ZFS.
Migraci musim volit "off-line", tzn. VPS se to projevi jako stop-downtime-start.
Ten restart zavisi tedka na vice vecech, podle toho, co delame - ale pokud jde zrovna o migraci, tak ta probiha nasledovne:
- pre-sync za behu 2. stop VPS na originalnim nodu 3. finalni sync
zmen co se stihly udelat za behu pred stopem 4. start VPS na novem nodu
Misto 2+4 se da pouzit suspend/resume, ale VPS nesmi mit "enabled features" ve vpsAdminu (VPS s NFS/NFSd vevnitr neni migrovatelna, neda se dumpnout ten context NFS+RPC) - rikame tomu online migrace (i kdyz je tam chvilicku downtime, ale ta VPS neztrati kontext). Nicmene jak rikam, potencialne jsou tam problemy napr. pri prechodu mezi verzemi jadra - ktere se teda snazim drzet konzistentni v celem clusteru, ale zatim se to jeste nedari a proto online migraci radeji nepouzivame. Ta nekompatibilita se totiz projevi az po suspendu pri pokusu o resume, coz znamena, ze pak ten dump muzu zahodit a pro VPS je to, jak kdyby ji nekdo vytrhl ze zasuvky, coz je min libiva varianta, nez clean shutdown.
Dokud ted pouzivame rsync misto posilani snapshotu filesystemu pres ZFS, je to pomalejsi, obzvlast, kdyz mas ve VPS cca nad 0.5M souboru, pak uz se to pozna. Pak muze bejt downtime peknejch par minut pri tom bodu 3.
Ale jakmile se konecne zbavime tech po***** nodu s ext4, tak to pujde mnohem rychleji - ZFS send/recv nezajima, kolik je to souboru, nejsou to metadata operace, je to proste serializovany stream bloku filesystemu. Pak se dostaneme prave na ty rady desitek sekund downtime max.
Nicmene tohle se nedeje moc casto, ty skatulata-batulata se dejou ted prave proto, ze zbavuju vpsFree nodu s ext4 - aka. musi byt nejdriv hur, aby mohlo byt lip :(
- omluva vsem na node8: omylem jsem blbec nedomyslel side-effects
pkill -f tar, coz s sebou vzalo i procesy typu: /usr/sbin/apache2 -k start Za to se vazne omlouvam, skolacka chyba, co by se dit nemela.
S pozdravem / Best regards,
Pavel Snajdr
+421 948 816 186 | +420 720 107 791 | 110-010-956 CTO of Relbit | Predseda vpsFree.cz, o.s. | RHCE http://relbit.com | http://vpsfree.cz | https://www.redhat.com _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
community-list@lists.vpsfree.cz