-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
node2a prave startuje,
umrel tam disk, ze ktereho RAID1 aktivne cetl data, takze se to
odporoucelo na kernel oops.
Aktualne server bezi tedy jenom s jednim diskem, novy disk tam dame v
pondeli-utery - to by nemelo znamenat zadny vypadek a kdyz, tak to
udelam po jedne v noci -> doufam, ze nebude vadit, kdyz to neoznamim,
prave jste byli varovani :)
- --
Pavel Snajdr
+420 720 107 791
http://vpsfree.cz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iF4EAREIAAYFAk79BIYACgkQdh+64ds5DaacNAD8DGOFpb2MQq30AB2BryyRsGVw
RBVNv+4IDYFAePPZe2MBAMZQ5COtVe55dMR+Zgc0sztMaM/dHYqrAZfKlQm0y2HC
=EwXf
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Ahoj clenove,
omlouvam se, ze jsem nedal vedet driv, jaksi mi to v tom svatecnim shonu
vypadlo - dnes v noci (po jedenacte vecer) se chystame do datacentra v
Praze, budeme predelavat nastaveni site ze single sitovky na bonding 2
interfaces pres 2 switche - eliminujeme tim SPOF v podobne switchu.
Vypadky budou doufam bez restartu a kratsi nez 5 minut / server, takze
by si toho asi ani nikdo nevsimnul, ale je lepsi dat vedet.
Preju vsem hodne stesti v nadchazejicim roce a co nejmin segfaultu :)
Pavel Snajdr
+420 720 107 791
http://vpsfree.cz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iF4EAREIAAYFAk75ruUACgkQdh+64ds5DaYxkQEAo5+nAAafnwEDxf+cX9cjSmfX
xyVG+RUNxcdvZBUFAhYBAJ0eWbvc7v0EEzDsuwKbpUegmHW8qKoRoJLdtzXPsGzU
=eHmL
-----END PGP SIGNATURE-----
Dobry den
Zvykli sme pravidelne citat tento mailinglist a aj ked sme sa citili
castokrat dotknuti roznymi vyjadreniami, vzdy sme to ignorovali. Dnes
sme vsak boli nazvani "banda neschopnych hovad", tak uz reagovat musime.
So serverom Epsilon bol za posledne mesiace castokrat problem. Niekto
ten server zrejme pretazuje a to tak, ze je nutny restart. Tento restart
sme robili pravidelne na dialku. Problem bol/je, ze server skoro nikdy
nenabehol, ostal na FSCK a bola teda nutna navsteva serverovne.
Tuto navstevu sme vykonavali my (firma Platon). Nie su to nase servery
a nemame k nim administratorsky pristup, pomahali sme vsak vpsFree a to
aj napriek tomu, ze tieto (caste) zasahy nikdy neboli oficialne
dohodnute (tazko sa pracuje so serverom, ktory sami nespravujeme).
Rovnaka situacia nastala aj dnes. Bohuzial celkom dobre nechapem preco
boli nutne tieto invektivy na nasich ludi.
Chronologia - ako som si ju vyziadal od zamestnancov:
17:45 - vypadok servera (podla mailinglistu outage-list)
18:00 - nahlaseny problem u nas (priblizny cas)
18:45 - nas zamestnanec v serverovi zistuje situaciu a posiela prvy
e-mail zakaznikovi (vpsFree)
Nasledne sa zakaznik stazuje, ze nema pristup na remote management.
V tejto chvili som ako konatel postavil do pozoru celu firmu (aj ked je
sobota), ze ako je mozne, ze tato vec, ktoru tam zakaznik osobne
doniesol a nefunguje! Fakt som bol nastvany, za taketo lajdactvo!
Lenze ukazalo sa, ze tento pristup bol nakonfigurovany dna 27-Oct-2011.
To co nebolo nakonfigurovane bol samotny remote management device. Mame
vsetky switche v SVN, takze vieme presne kedy ktora zmena nastala, vieme
kedy bol dany port otvoreny:
+! Last configuration change at 11:36:16 CEST Thu Oct 27 2011 by miquel
+! NVRAM config last updated at 11:36:26 CEST Thu Oct 27 2011 by miquel
+ description zeta.vpsFree.cz - MNG
+ switchport access vlan 201
Nasledne teda zacali nasi ludia na zaklade instrukcii od zakaznika
konfigurovat toto zariadenie na remote pristup. Samozrejme to je vec,
s ktorou my nemame ziadne skusenosti, ani taketo zariadenie nevlastnime,
ani sme nikdy nepredpokladali, ze s tym budeme musiet robit. Mysleli
sme, ze dane zariadenie je nakonfigurovane, ved to bol primarny ciel
pred niekolkymi mesiacmi.
Aj po oprave remote managementu server stale nestartoval kvoli chybnemu
filesystemu. Ten bol po cca hodine opraveny a nasledne server funkcny.
Cely tento cas boli zamestnanci firmy osobne pritomni v datovom centre
pre pripad, ze by zakaznik vyzadoval este dalsi zasah.
Nemame problem remote management zariadenie nakonfigurovat ak treba, ale
mohli sme tak urobit za posledne dva mesiace kedykolvek. Neprisel vsak
ziadny e-mail ohladom toho, ze s tym treba cokolvek robit. To naozaj nik
za 2 mesiace neotestoval ten remote management pristup ci funguje? Aky
zmysel ma nefunkcny remote management? Ved to je akoby tam ziadny nebol.
Mrzi nas vzniknuta situacia a sposobeny vypadok, ktory sa dotkol urcite
mnohych ludi, kedze virtualnych serverov tam bezi vela. Z nasej strany
sme ale spravili maximum, alebo aspon sme sa o to pokusili.
Urcite nie sme dokonala firma, mame svoje chyby a muchy, na ktorych
musime pracovat. Kazdopadne moji zamestnaci si nezasluzia oznacenie
"banda neschopnych hovad". Zvlast nie po dnesnej sobote.
Este raz sa opravedlnujem za vypadok. Plynie z toho pre nas ponaucenie
do buducnosti pro-aktivne pristupovat aj k veciam, ktore su mimo nasej
spravy, aby vzniknute emergency situacie neboli takto stresujuce.
Dakujem za precitanie
S pozdravom
Ondrej Jombik
konatel spolocnosti
--
Ondrej JOMBIK
Platon Technologies Ltd., Hlavna 3, Sala SK-92701
+421 903 PLATON - info(a)platon.org - http://platon.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
$subj, netusim pricinu, resetoval jsem to (nedalo se prihlasit)
za nedlouho by mel byt up.
- --
Pavel Snajdr
+420 720 107 791
http://vpsfree.cz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iF4EAREIAAYFAk7jjBoACgkQdh+64ds5DaZj5QD/TW1Ax80PGuoEnm0oYqpV1fa/
FhzPDtcz/QORbF63rAMA/inDz0W5YtIa+abspONCCpHjlKAkZ0twQnAOe9bvNOfU
=1mtX
-----END PGP SIGNATURE-----
