-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Ahojte,
tak je to tu znova, zase se mi nepovedlo poradne otestovat kombinaci vzkernel/ZFS v ostatnich prostredich, nez je vpsFree. A to podotykam, ze ty same verze nam v Relbitu bezi pod poradnou zatezi in production uz cca mesic. A neni tam problem.
Nicmene u nas to vypada, ze problem je, cili budeme muset downgradovat dnes v noci na ZFS 0.6.3-1 a SPL stejne verze.
Bude to obnaset vypadek rovnajici se rebootu vsech stroju, bohuzel.
- -- 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
A nebylo by lepsi delat podobne planovane upgrady v ramci VPSfree "po jednom"? Napr. v pondeli node1, utery node2, atd ..... Pokud se vyskytne problem, nemusi se pak vsechno zase hromadne downgradovat (mam pocit ze minuly upgrade taky koncil podobne, po par neuspesnych rebotech se zase downgradovalo). Nebo minimalne jeden den jeden nahodne vybrany stroj, druhy den dalsi 2 a treti den zbytek (mene pracne nez delat nody kazdy den po jednom a mensi sance ze downgrade postihne vse ...)...
Pokud se neco prvni den podela, odnese to jen jeden stroj a ne vsechny...
Takhle budu mit zase noc kdy se nevyspim, dneska rano jsem daval dohromady servery po rebootu, na jednom nenajelo vubec mysql dokud jsem nenastavil innodb_use_native_aio = 0 :(
Puvodne jsem si tu poridil jeste druhe vps (jedno mam na node5, druhe na node6), aby byl nejaky failover, t.j. slusna sance ze v jakykoliv okamzik aspon jeden pojede, ale pokud se rebootuje vsechno najednou, nebo kousek po sobe, tak obvykle je druhe vps dole driv nez najede to prvni, pripadne drv nez stihnu spravit to prvni (pokud se objevi po rebootu nejaky problem), coz ty moje predstavy o tom ze druha fyzicka masina situaci zlepsi (sice zlepsi, ale ne o moc) tak trochu bori :)
Martin
On 2014-09-16 20:52, Pavel Snajdr wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Ahojte,
tak je to tu znova, zase se mi nepovedlo poradne otestovat kombinaci vzkernel/ZFS v ostatnich prostredich, nez je vpsFree. A to podotykam, ze ty same verze nam v Relbitu bezi pod poradnou zatezi in production uz cca mesic. A neni tam problem.
Nicmene u nas to vypada, ze problem je, cili budeme muset downgradovat dnes v noci na ZFS 0.6.3-1 a SPL stejne verze.
Bude to obnaset vypadek rovnajici se rebootu vsech stroju, bohuzel.
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 SIGNATURE----- Version: GnuPG v1
iF4EAREIAAYFAlQYhuMACgkQMBKdi9lkZ6pZqQD/YuHvZwqAMWVlKSvy8Td3sCHo Q4EAY5s3BNnzIlgpfwMBAIt0GxSGsqpXosbrkLZ+YVyAVYY9PeoRiHlEJ5sVRsIM =mkDh -----END PGP SIGNATURE----- _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
To by byla fajn strategie, kdyby se to neprojevilo vzdycky jenom na jednom nahodnym nodu. Proste staci nejakej obskurnejsi workload a je to... jenze pro kazdej bug jinej specifickej workload, co ho da do kolen.
Idea je to pekna, kdyby se to dalo delat pres den, jenze to tezko.
Takhle by to upgradovani znamenalo efektivne pri poctu 12ti masin 12 dni byt vzhuru v noci. Not sure if so much of a good idea.
Chapu, co se snazis rict, ale nejsem si jistej, jestli existuje reseni.
/snajpa
On 09/16/2014 09:20 PM, Martin Petricek wrote:
A nebylo by lepsi delat podobne planovane upgrady v ramci VPSfree "po jednom"? Napr. v pondeli node1, utery node2, atd ..... Pokud se vyskytne problem, nemusi se pak vsechno zase hromadne downgradovat (mam pocit ze minuly upgrade taky koncil podobne, po par neuspesnych rebotech se zase downgradovalo). Nebo minimalne jeden den jeden nahodne vybrany stroj, druhy den dalsi 2 a treti den zbytek (mene pracne nez delat nody kazdy den po jednom a mensi sance ze downgrade postihne vse ...)...
Pokud se neco prvni den podela, odnese to jen jeden stroj a ne vsechny...
Takhle budu mit zase noc kdy se nevyspim, dneska rano jsem daval dohromady servery po rebootu, na jednom nenajelo vubec mysql dokud jsem nenastavil innodb_use_native_aio = 0 :(
Puvodne jsem si tu poridil jeste druhe vps (jedno mam na node5, druhe na node6), aby byl nejaky failover, t.j. slusna sance ze v jakykoliv okamzik aspon jeden pojede, ale pokud se rebootuje vsechno najednou, nebo kousek po sobe, tak obvykle je druhe vps dole driv nez najede to prvni, pripadne drv nez stihnu spravit to prvni (pokud se objevi po rebootu nejaky problem), coz ty moje predstavy o tom ze druha fyzicka masina situaci zlepsi (sice zlepsi, ale ne o moc) tak trochu bori :)
Martin
On 2014-09-16 20:52, Pavel Snajdr wrote: Ahojte,
tak je to tu znova, zase se mi nepovedlo poradne otestovat kombinaci vzkernel/ZFS v ostatnich prostredich, nez je vpsFree. A to podotykam, ze ty same verze nam v Relbitu bezi pod poradnou zatezi in production uz cca mesic. A neni tam problem.
Nicmene u nas to vypada, ze problem je, cili budeme muset downgradovat dnes v noci na ZFS 0.6.3-1 a SPL stejne verze.
Bude to obnaset vypadek rovnajici se rebootu vsech stroju, bohuzel.
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj, musím sa pridať. Nebudem tu mudrovať, do týchto vecí sa fakt velmi nevyznám, ale so stabilitou je to posledný mesiac fakt naprd. Neviem ako to chodí, ale potešilo by ma, keby sa dal udržať nejaký štandard, takto mi to príjde, ako by sa nejak zbytočne moc experimentovalo a potom to padá.
S pozdravom,
*Peter Bačinský* konateľ spoločnosti
*Webino, s. r. o.* Železničná 152/75 90024 Veľký Biel Slovensko
*Web stránky a internetové aplikácie pre Vaše podnikanie.*
+421 918 641 804, info@webino.sk mailto:info@webino.sk, www.webino.sk http://www.webino.sk/
------------------------------------------------------------------------
*PROSÍM ZACHOVÁVAJTE HISTÓRIU V SPRÁVE, ĎAKUJEM*
On 16.09.2014 21:20, Martin Petricek wrote:
A nebylo by lepsi delat podobne planovane upgrady v ramci VPSfree "po jednom"? Napr. v pondeli node1, utery node2, atd ..... Pokud se vyskytne problem, nemusi se pak vsechno zase hromadne downgradovat (mam pocit ze minuly upgrade taky koncil podobne, po par neuspesnych rebotech se zase downgradovalo). Nebo minimalne jeden den jeden nahodne vybrany stroj, druhy den dalsi 2 a treti den zbytek (mene pracne nez delat nody kazdy den po jednom a mensi sance ze downgrade postihne vse ...)...
Pokud se neco prvni den podela, odnese to jen jeden stroj a ne vsechny...
Takhle budu mit zase noc kdy se nevyspim, dneska rano jsem daval dohromady servery po rebootu, na jednom nenajelo vubec mysql dokud jsem nenastavil innodb_use_native_aio = 0 :(
Puvodne jsem si tu poridil jeste druhe vps (jedno mam na node5, druhe na node6), aby byl nejaky failover, t.j. slusna sance ze v jakykoliv okamzik aspon jeden pojede, ale pokud se rebootuje vsechno najednou, nebo kousek po sobe, tak obvykle je druhe vps dole driv nez najede to prvni, pripadne drv nez stihnu spravit to prvni (pokud se objevi po rebootu nejaky problem), coz ty moje predstavy o tom ze druha fyzicka masina situaci zlepsi (sice zlepsi, ale ne o moc) tak trochu bori :)
Martin
On 2014-09-16 20:52, Pavel Snajdr wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Ahojte,
tak je to tu znova, zase se mi nepovedlo poradne otestovat kombinaci vzkernel/ZFS v ostatnich prostredich, nez je vpsFree. A to podotykam, ze ty same verze nam v Relbitu bezi pod poradnou zatezi in production uz cca mesic. A neni tam problem.
Nicmene u nas to vypada, ze problem je, cili budeme muset downgradovat dnes v noci na ZFS 0.6.3-1 a SPL stejne verze.
Bude to obnaset vypadek rovnajici se rebootu vsech stroju, bohuzel.
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 SIGNATURE----- Version: GnuPG v1
iF4EAREIAAYFAlQYhuMACgkQMBKdi9lkZ6pZqQD/YuHvZwqAMWVlKSvy8Td3sCHo Q4EAY5s3BNnzIlgpfwMBAIt0GxSGsqpXosbrkLZ+YVyAVYY9PeoRiHlEJ5sVRsIM =mkDh -----END PGP SIGNATURE----- _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Mno, prijit ti to muze.
Jestli myslis, ze pro to delam malo, nech sa paci, dam ti root pristup a muzes to spravovat za mne.
Jak uz po trilionty rikam, proste to NENI jak testovat. A je to vec kterou neumim rozlousknout uz 6 let.
/snajpa
On 09/17/2014 06:10 AM, Peter Bačinský wrote:
Ahoj, musím sa pridať. Nebudem tu mudrovať, do týchto vecí sa fakt velmi nevyznám, ale so stabilitou je to posledný mesiac fakt naprd. Neviem ako to chodí, ale potešilo by ma, keby sa dal udržať nejaký štandard, takto mi to príjde, ako by sa nejak zbytočne moc experimentovalo a potom to padá.
S pozdravom,
*Peter Bačinský* konateľ spoločnosti
*Webino, s. r. o.* Železničná 152/75 90024 Veľký Biel Slovensko
*Web stránky a internetové aplikácie pre Vaše podnikanie.*
+421 918 641 804, info@webino.sk mailto:info@webino.sk, www.webino.sk http://www.webino.sk/
*PROSÍM ZACHOVÁVAJTE HISTÓRIU V SPRÁVE, ĎAKUJEM*
On 16.09.2014 21:20, Martin Petricek wrote:
A nebylo by lepsi delat podobne planovane upgrady v ramci VPSfree "po jednom"? Napr. v pondeli node1, utery node2, atd ..... Pokud se vyskytne problem, nemusi se pak vsechno zase hromadne downgradovat (mam pocit ze minuly upgrade taky koncil podobne, po par neuspesnych rebotech se zase downgradovalo). Nebo minimalne jeden den jeden nahodne vybrany stroj, druhy den dalsi 2 a treti den zbytek (mene pracne nez delat nody kazdy den po jednom a mensi sance ze downgrade postihne vse ...)...
Pokud se neco prvni den podela, odnese to jen jeden stroj a ne vsechny...
Takhle budu mit zase noc kdy se nevyspim, dneska rano jsem daval dohromady servery po rebootu, na jednom nenajelo vubec mysql dokud jsem nenastavil innodb_use_native_aio = 0 :(
Puvodne jsem si tu poridil jeste druhe vps (jedno mam na node5, druhe na node6), aby byl nejaky failover, t.j. slusna sance ze v jakykoliv okamzik aspon jeden pojede, ale pokud se rebootuje vsechno najednou, nebo kousek po sobe, tak obvykle je druhe vps dole driv nez najede to prvni, pripadne drv nez stihnu spravit to prvni (pokud se objevi po rebootu nejaky problem), coz ty moje predstavy o tom ze druha fyzicka masina situaci zlepsi (sice zlepsi, ale ne o moc) tak trochu bori :)
Martin
On 2014-09-16 20:52, Pavel Snajdr wrote:
Ahojte,
tak je to tu znova, zase se mi nepovedlo poradne otestovat kombinaci vzkernel/ZFS v ostatnich prostredich, nez je vpsFree. A to podotykam, ze ty same verze nam v Relbitu bezi pod poradnou zatezi in production uz cca mesic. A neni tam problem.
Nicmene u nas to vypada, ze problem je, cili budeme muset downgradovat dnes v noci na ZFS 0.6.3-1 a SPL stejne verze.
Bude to obnaset vypadek rovnajici se rebootu vsech stroju, bohuzel.
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Snajpo, myslim ze si to beres zbytecne osobne, nikdo nerika ze pro to delas malo, blbe, ... (ani ze by to chtel delat lip) tady kolega pouze konstatoval, ze je stabilita na prd - coz s nim musim souhlasit a byl to jeden z duvodu, proc jsem svoje vps u vpsfree zrusil.
ano, tak monstrozni vykon za takovou cenu jako vpsfree asi nikdo nenabizi, ale uprimne jsem radej, kdyz mi false positives z monitoringu, ktery mi u vpsfree bezel, klesly asi na setinu pote, co sem to presunul na podstatne mene vykonnejsi vps u digitaloceanu. Neminim ti jakoli kecat do spravy serveru, ale osobne nevidim zadny duvod, proc jet na nejnovejsich jadrech jen proto, abysme je meli. Nemam pocit, ze by nam, krome tvoji prace, a dalsich vypadku, prinesly jakakoli pozitiva.
Myslim, ze to ze nekdo neni "spokojeny" s necim neznamena, ze to musi automaticky umet delat lepe - taky nekupuju rohliky z agrofertu a nemyslim, ze bych je upekl lip, ale jdu proste do mistni pekarny, kde to lip (a podstatne draz) umej.
m
Dne 17. 9. 2014 10:39, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Mno, prijit ti to muze.
Jestli myslis, ze pro to delam malo, nech sa paci, dam ti root pristup a muzes to spravovat za mne.
Jak uz po trilionty rikam, proste to NENI jak testovat. A je to vec kterou neumim rozlousknout uz 6 let.
/snajpa
On 09/17/2014 06:10 AM, Peter Bačinský wrote:
Ahoj, musím sa pridať. Nebudem tu mudrovať, do týchto vecí sa fakt velmi nevyznám, ale so stabilitou je to posledný mesiac fakt naprd. Neviem ako to chodí, ale potešilo by ma, keby sa dal udržať nejaký štandard, takto mi to príjde, ako by sa nejak zbytočne moc experimentovalo a potom to padá.
S pozdravom,
*Peter Bačinský* konateľ spoločnosti
*Webino, s. r. o.* Železničná 152/75 90024 Veľký Biel Slovensko
*Web stránky a internetové aplikácie pre Vaše podnikanie.*
+421 918 641 804, info@webino.sk mailto:info@webino.sk, www.webino.sk http://www.webino.sk/
*PROSÍM ZACHOVÁVAJTE HISTÓRIU V SPRÁVE, ĎAKUJEM*
On 16.09.2014 21:20, Martin Petricek wrote:
A nebylo by lepsi delat podobne planovane upgrady v ramci VPSfree "po jednom"? Napr. v pondeli node1, utery node2, atd ..... Pokud se vyskytne problem, nemusi se pak vsechno zase hromadne downgradovat (mam pocit ze minuly upgrade taky koncil podobne, po par neuspesnych rebotech se zase downgradovalo). Nebo minimalne jeden den jeden nahodne vybrany stroj, druhy den dalsi 2 a treti den zbytek (mene pracne nez delat nody kazdy den po jednom a mensi sance ze downgrade postihne vse ...)...
Pokud se neco prvni den podela, odnese to jen jeden stroj a ne vsechny...
Takhle budu mit zase noc kdy se nevyspim, dneska rano jsem daval dohromady servery po rebootu, na jednom nenajelo vubec mysql dokud jsem nenastavil innodb_use_native_aio = 0 :(
Puvodne jsem si tu poridil jeste druhe vps (jedno mam na node5, druhe na node6), aby byl nejaky failover, t.j. slusna sance ze v jakykoliv okamzik aspon jeden pojede, ale pokud se rebootuje vsechno najednou, nebo kousek po sobe, tak obvykle je druhe vps dole driv nez najede to prvni, pripadne drv nez stihnu spravit to prvni (pokud se objevi po rebootu nejaky problem), coz ty moje predstavy o tom ze druha fyzicka masina situaci zlepsi (sice zlepsi, ale ne o moc) tak trochu bori :)
Martin
On 2014-09-16 20:52, Pavel Snajdr wrote:
Ahojte,
tak je to tu znova, zase se mi nepovedlo poradne otestovat kombinaci vzkernel/ZFS v ostatnich prostredich, nez je vpsFree. A to podotykam, ze ty same verze nam v Relbitu bezi pod poradnou zatezi in production uz cca mesic. A neni tam problem.
Nicmene u nas to vypada, ze problem je, cili budeme muset downgradovat dnes v noci na ZFS 0.6.3-1 a SPL stejne verze.
Bude to obnaset vypadek rovnajici se rebootu vsech stroju, bohuzel.
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iF4EAREIAAYFAlQZSN0ACgkQMBKdi9lkZ6puhgD/RIQHjqSXTjIYhXcaIor2iV5R ++dqmEY1vOWY36TfI08BAMSbNIsN7ndPVTKfGrRGYhQAtQqFGvBzI3FynrJQanmb =BM1J -----END PGP SIGNATURE----- _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Ou, dalsi odbornik.
Vyborne.
Ja jenom tak si proste updatuju, protoze mne to bavi :)
Kdyby te to chtelo zajimat, kernel 085.20 byl zranitelnej nejmin na 3 CVEcka, nefungoval systemd pod Archlinuxem a byl rozbitej accounting CPU time, to jenom tak, co si pamatuju, je tam nescetne dalsich fixu okolo.
Vypadky konektivity s timhle vubec nesouvisej, to je proste o tom, ze pri poctu VPS, co mame, uz se k nam hlasi i lidi, co s tim vubec neumi delat a hacknuta VPS je na dennim poradku. Proto jsme zavedli shaping. A rekl bych, ze je klid.
Dalsi srani bylo s primary routerem, kde se za ty 3 roky vysvitily ty Supermicro sitovky (ono se to stalo i secondary, ale jenom jednomu interfacu a prediktibilne, takze nebyl problem hodit ten port na jinou sitovku). Primary router mam ted v Relbit office a vymyslim, co s nim, no reseni by byvalo bylo vymenit sitovky, ale rozhodli jsme se prejit na podporovanou platformu Mikrotiku, proto CCR.
Jakoze, nejvetsi nedostatek, o cem tu vlastne tocime, je, ze narozdil od vetsiny fullvirt reseni, OpenVZ neumi az tak spolehlive presouvat bezici kontejnery mezi serverama - umet tohle, neni co resit a nikdo si niceho ani nevsimne, vypadek tam sice bude, ale uptime counter to nezresetuje a vsichni jsou spokojeni. No, to s OpenVZ jde sotva pro 50% kontejneru, co mame. Bohuzel.
/snajpa
On 09/17/2014 11:05 AM, Michal Krajcirovic wrote:
Snajpo, myslim ze si to beres zbytecne osobne, nikdo nerika ze pro to delas malo, blbe, ... (ani ze by to chtel delat lip) tady kolega pouze konstatoval, ze je stabilita na prd - coz s nim musim souhlasit a byl to jeden z duvodu, proc jsem svoje vps u vpsfree zrusil.
ano, tak monstrozni vykon za takovou cenu jako vpsfree asi nikdo nenabizi, ale uprimne jsem radej, kdyz mi false positives z monitoringu, ktery mi u vpsfree bezel, klesly asi na setinu pote, co sem to presunul na podstatne mene vykonnejsi vps u digitaloceanu. Neminim ti jakoli kecat do spravy serveru, ale osobne nevidim zadny duvod, proc jet na nejnovejsich jadrech jen proto, abysme je meli. Nemam pocit, ze by nam, krome tvoji prace, a dalsich vypadku, prinesly jakakoli pozitiva.
Myslim, ze to ze nekdo neni "spokojeny" s necim neznamena, ze to musi automaticky umet delat lepe - taky nekupuju rohliky z agrofertu a nemyslim, ze bych je upekl lip, ale jdu proste do mistni pekarny, kde to lip (a podstatne draz) umej.
m
Dne 17. 9. 2014 10:39, Pavel Snajdr napsal(a): Mno, prijit ti to muze.
Jestli myslis, ze pro to delam malo, nech sa paci, dam ti root pristup a muzes to spravovat za mne.
Jak uz po trilionty rikam, proste to NENI jak testovat. A je to vec kterou neumim rozlousknout uz 6 let.
/snajpa
On 09/17/2014 06:10 AM, Peter Bačinský wrote:
Ahoj, musím sa pridať. Nebudem tu mudrovať, do týchto vecí sa fakt velmi nevyznám, ale so stabilitou je to posledný mesiac fakt naprd. Neviem ako to chodí, ale potešilo by ma, keby sa dal udržať nejaký štandard, takto mi to príjde, ako by sa nejak zbytočne moc experimentovalo a potom to padá.
S pozdravom,
*Peter Bačinský* konateľ spoločnosti
*Webino, s. r. o.* Železničná 152/75 90024 Veľký Biel Slovensko
*Web stránky a internetové aplikácie pre Vaše podnikanie.*
+421 918 641 804, info@webino.sk mailto:info@webino.sk, www.webino.sk http://www.webino.sk/
*PROSÍM ZACHOVÁVAJTE HISTÓRIU V SPRÁVE, ĎAKUJEM*
On 16.09.2014 21:20, Martin Petricek wrote:
A nebylo by lepsi delat podobne planovane upgrady v ramci VPSfree "po jednom"? Napr. v pondeli node1, utery node2, atd ..... Pokud se vyskytne problem, nemusi se pak vsechno zase hromadne downgradovat (mam pocit ze minuly upgrade taky koncil podobne, po par neuspesnych rebotech se zase downgradovalo). Nebo minimalne jeden den jeden nahodne vybrany stroj, druhy den dalsi 2 a treti den zbytek (mene pracne nez delat nody kazdy den po jednom a mensi sance ze downgrade postihne vse ...)...
Pokud se neco prvni den podela, odnese to jen jeden stroj a ne vsechny...
Takhle budu mit zase noc kdy se nevyspim, dneska rano jsem daval dohromady servery po rebootu, na jednom nenajelo vubec mysql dokud jsem nenastavil innodb_use_native_aio = 0 :(
Puvodne jsem si tu poridil jeste druhe vps (jedno mam na node5, druhe na node6), aby byl nejaky failover, t.j. slusna sance ze v jakykoliv okamzik aspon jeden pojede, ale pokud se rebootuje vsechno najednou, nebo kousek po sobe, tak obvykle je druhe vps dole driv nez najede to prvni, pripadne drv nez stihnu spravit to prvni (pokud se objevi po rebootu nejaky problem), coz ty moje predstavy o tom ze druha fyzicka masina situaci zlepsi (sice zlepsi, ale ne o moc) tak trochu bori :)
Martin
On 2014-09-16 20:52, Pavel Snajdr wrote:
Ahojte,
tak je to tu znova, zase se mi nepovedlo poradne otestovat kombinaci vzkernel/ZFS v ostatnich prostredich, nez je vpsFree. A to podotykam, ze ty same verze nam v Relbitu bezi pod poradnou zatezi in production uz cca mesic. A neni tam problem.
Nicmene u nas to vypada, ze problem je, cili budeme muset downgradovat dnes v noci na ZFS 0.6.3-1 a SPL stejne verze.
Bude to obnaset vypadek rovnajici se rebootu vsech stroju, bohuzel.
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj,
trochu mimo aktuální topic: Sháním nějakého borce na PHP/JS, který si na mě mohl udělat párkrát přes týden čas – nárazově třeba 30-60 minut. Potřebuju hlavně regulární výrazy/XPath – to klidně zaškolím.
Podstatný pro mě je, abych tomu člověku mohl věřit a abych měl dojem, že je skutečně součástí našeho týmu.
Díky,
Vojtěch Knyttl | GoOut
knyttl@goout.cz +420 607 008 510 http://goout.cz
Ahoj, do produkce patri pouze security fixy, primo ohrozujici bezpecnost.
Dne 17. září 2014 11:05 Michal Krajcirovic michal@krajcirovic.cz napsal(a):
Snajpo, myslim ze si to beres zbytecne osobne, nikdo nerika ze pro to delas malo, blbe, ... (ani ze by to chtel delat lip) tady kolega pouze konstatoval, ze je stabilita na prd - coz s nim musim souhlasit a byl to jeden z duvodu, proc jsem svoje vps u vpsfree zrusil.
ano, tak monstrozni vykon za takovou cenu jako vpsfree asi nikdo nenabizi, ale uprimne jsem radej, kdyz mi false positives z monitoringu, ktery mi u vpsfree bezel, klesly asi na setinu pote, co sem to presunul na podstatne mene vykonnejsi vps u digitaloceanu. Neminim ti jakoli kecat do spravy serveru, ale osobne nevidim zadny duvod, proc jet na nejnovejsich jadrech jen proto, abysme je meli. Nemam pocit, ze by nam, krome tvoji prace, a dalsich vypadku, prinesly jakakoli pozitiva.
Myslim, ze to ze nekdo neni "spokojeny" s necim neznamena, ze to musi automaticky umet delat lepe - taky nekupuju rohliky z agrofertu a nemyslim, ze bych je upekl lip, ale jdu proste do mistni pekarny, kde to lip (a podstatne draz) umej.
m
Dne 17. 9. 2014 10:39, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Mno, prijit ti to muze.
Jestli myslis, ze pro to delam malo, nech sa paci, dam ti root pristup a muzes to spravovat za mne.
Jak uz po trilionty rikam, proste to NENI jak testovat. A je to vec kterou neumim rozlousknout uz 6 let.
/snajpa
On 09/17/2014 06:10 AM, Peter Bačinský wrote:
Ahoj, musím sa pridať. Nebudem tu mudrovať, do týchto vecí sa fakt velmi nevyznám, ale so stabilitou je to posledný mesiac fakt naprd. Neviem ako to chodí, ale potešilo by ma, keby sa dal udržať nejaký štandard, takto mi to príjde, ako by sa nejak zbytočne moc experimentovalo a potom to padá.
S pozdravom,
*Peter Bačinský* konateľ spoločnosti
*Webino, s. r. o.* Železničná 152/75 90024 Veľký Biel Slovensko
*Web stránky a internetové aplikácie pre Vaše podnikanie.*
+421 918 641 804, info@webino.sk mailto:info@webino.sk, www.webino.sk http://www.webino.sk/
*PROSÍM ZACHOVÁVAJTE HISTÓRIU V SPRÁVE, ĎAKUJEM*
On 16.09.2014 21:20, Martin Petricek wrote:
A nebylo by lepsi delat podobne planovane upgrady v ramci VPSfree "po jednom"? Napr. v pondeli node1, utery node2, atd ..... Pokud se vyskytne problem, nemusi se pak vsechno zase hromadne downgradovat (mam pocit ze minuly upgrade taky koncil podobne, po par neuspesnych rebotech se zase downgradovalo). Nebo minimalne jeden den jeden nahodne vybrany stroj, druhy den dalsi 2 a treti den zbytek (mene pracne nez delat nody kazdy den po jednom a mensi sance ze downgrade postihne vse ...)...
Pokud se neco prvni den podela, odnese to jen jeden stroj a ne vsechny...
Takhle budu mit zase noc kdy se nevyspim, dneska rano jsem daval dohromady servery po rebootu, na jednom nenajelo vubec mysql dokud jsem nenastavil innodb_use_native_aio = 0 :(
Puvodne jsem si tu poridil jeste druhe vps (jedno mam na node5, druhe na node6), aby byl nejaky failover, t.j. slusna sance ze v jakykoliv okamzik aspon jeden pojede, ale pokud se rebootuje vsechno najednou, nebo kousek po sobe, tak obvykle je druhe vps dole driv nez najede to prvni, pripadne drv nez stihnu spravit to prvni (pokud se objevi po rebootu nejaky problem), coz ty moje predstavy o tom ze druha fyzicka masina situaci zlepsi (sice zlepsi, ale ne o moc) tak trochu bori :)
Martin
On 2014-09-16 20:52, Pavel Snajdr wrote:
Ahojte,
tak je to tu znova, zase se mi nepovedlo poradne otestovat kombinaci vzkernel/ZFS v ostatnich prostredich, nez je vpsFree. A to podotykam, ze ty same verze nam v Relbitu bezi pod poradnou zatezi in production uz cca mesic. A neni tam problem.
Nicmene u nas to vypada, ze problem je, cili budeme muset downgradovat dnes v noci na ZFS 0.6.3-1 a SPL stejne verze.
Bude to obnaset vypadek rovnajici se rebootu vsech stroju, bohuzel.
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iF4EAREIAAYFAlQZSN0ACgkQMBKdi9lkZ6puhgD/RIQHjqSXTjIYhXcaIor2iV5R ++dqmEY1vOWY36TfI08BAMSbNIsN7ndPVTKfGrRGYhQAtQqFGvBzI3FynrJQanmb =BM1J -----END PGP SIGNATURE----- _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj, na tohle jsi prisel jak?
On 17.9.2014 11:26, Tomáš Valoušek wrote:
Ahoj, do produkce patri pouze security fixy, primo ohrozujici bezpecnost.
Dne 17. září 2014 11:05 Michal Krajcirovic michal@krajcirovic.cz
napsal(a):
Snajpo, myslim ze si to beres zbytecne osobne, nikdo nerika ze pro to
delas
malo, blbe, ... (ani ze by to chtel delat lip) tady kolega pouze konstatoval, ze je stabilita na prd - coz s nim musim souhlasit a byl to jeden z duvodu, proc jsem svoje vps u vpsfree zrusil.
ano, tak monstrozni vykon za takovou cenu jako vpsfree asi nikdo
nenabizi,
ale uprimne jsem radej, kdyz mi false positives z monitoringu, ktery mi u vpsfree bezel, klesly asi na setinu pote, co sem to presunul na podstatne mene vykonnejsi vps u digitaloceanu. Neminim ti jakoli kecat do spravy serveru, ale osobne nevidim zadny
duvod,
proc jet na nejnovejsich jadrech jen proto, abysme je meli. Nemam
pocit, ze
by nam, krome tvoji prace, a dalsich vypadku, prinesly jakakoli pozitiva.
Myslim, ze to ze nekdo neni "spokojeny" s necim neznamena, ze to musi automaticky umet delat lepe - taky nekupuju rohliky z agrofertu a
nemyslim,
ze bych je upekl lip, ale jdu proste do mistni pekarny, kde to lip (a podstatne draz) umej.
m
Dne 17. 9. 2014 10:39, Pavel Snajdr napsal(a):
Mno, prijit ti to muze.
Jestli myslis, ze pro to delam malo, nech sa paci, dam ti root pristup a muzes to spravovat za mne.
Jak uz po trilionty rikam, proste to NENI jak testovat. A je to vec kterou neumim rozlousknout uz 6 let.
/snajpa
On 09/17/2014 06:10 AM, Peter Bačinský wrote:
Ahoj, musím sa pridať. Nebudem tu mudrovať, do týchto vecí sa fakt velmi nevyznám, ale so stabilitou je to posledný mesiac fakt naprd. Neviem ako to chodí, ale potešilo by ma, keby sa dal udržať nejaký štandard, takto mi to príjde, ako by sa nejak zbytočne moc experimentovalo a potom to padá.
S pozdravom,
*Peter Bačinský* konateľ spoločnosti
*Webino, s. r. o.* Železničná 152/75 90024 Veľký Biel Slovensko
*Web stránky a internetové aplikácie pre Vaše podnikanie.*
+421 918 641 804, info@webino.sk mailto:info@webino.sk, www.webino.sk http://www.webino.sk/
*PROSÍM ZACHOVÁVAJTE HISTÓRIU V SPRÁVE, ĎAKUJEM*
On 16.09.2014 21:20, Martin Petricek wrote:
A nebylo by lepsi delat podobne planovane upgrady v ramci VPSfree "po jednom"? Napr. v pondeli node1, utery node2, atd ..... Pokud se vyskytne problem, nemusi se pak vsechno zase hromadne downgradovat (mam pocit ze minuly upgrade taky koncil podobne, po par neuspesnych rebotech se zase downgradovalo). Nebo minimalne jeden den jeden nahodne vybrany stroj, druhy den dalsi 2 a treti den zbytek (mene pracne nez delat nody kazdy den po jednom a mensi sance ze downgrade postihne vse ...)...
Pokud se neco prvni den podela, odnese to jen jeden stroj a ne vsechny...
Takhle budu mit zase noc kdy se nevyspim, dneska rano jsem daval dohromady servery po rebootu, na jednom nenajelo vubec mysql dokud jsem nenastavil innodb_use_native_aio = 0 :(
Puvodne jsem si tu poridil jeste druhe vps (jedno mam na node5, druhe na node6), aby byl nejaky failover, t.j. slusna sance ze v jakykoliv okamzik aspon jeden pojede, ale pokud se rebootuje vsechno najednou, nebo kousek po sobe, tak obvykle je druhe vps dole driv nez najede to prvni, pripadne drv nez stihnu spravit to prvni (pokud se objevi po rebootu nejaky problem), coz ty moje predstavy o tom ze druha fyzicka masina situaci zlepsi (sice zlepsi, ale ne o moc) tak trochu bori :)
Martin
On 2014-09-16 20:52, Pavel Snajdr wrote:
Ahojte,
tak je to tu znova, zase se mi nepovedlo poradne otestovat kombinaci vzkernel/ZFS v ostatnich prostredich, nez je vpsFree. A to podotykam, ze ty same verze nam v Relbitu bezi pod poradnou zatezi in production uz cca mesic. A neni tam problem.
Nicmene u nas to vypada, ze problem je, cili budeme muset downgradovat dnes v noci na ZFS 0.6.3-1 a SPL stejne verze.
Bude to obnaset vypadek rovnajici se rebootu vsech stroju, bohuzel.
> _______________________________________________ Community-list > mailing list Community-list@lists.vpsfree.cz > http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj,
nikdo si nemůže dovolit testovat na koncových zákaznících v produkčním prostředí. Produkční prostředí je od toho, aby bylo maximálně stabilní za cenu jisté konzervativnosti v "zastaralých" verzích aplikací.
Jediné řešení vidím v jasném rozdělení VPSfree na 2 nezávislé větve
- produkce/provoz, tj. stabilita, konzervativnost, minimum změn, pouze bezpečnostní aktualizace
- development, tj. testování nových věcí, které se po určité době přenášejí do produkce, a nebo aplikují na nové servery, které se stávají později produkcí.
Uživatelé, kterým nevadí výpadky a potřebují poslední nové věci, ať dobrovolně vstoupí do devel větve a mají např. nižší poplatek za provoz, větší disk apod.
Jiní ať pracují v produkční větvi, protože si výpadky _nemohou_ dovolit. Mohou tak získávat postupně více devítek v dostupnosti, přibližovat se postupně k 6 sigma :)
Současný stav mi přijde nešťastný.
Dne 17.9.2014 13:20, mrkva@mrkva.eu napsal(a):
Ahoj, na tohle jsi prisel jak?
On 17.9.2014 11:26, Tomáš Valoušek wrote:
Ahoj...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 01:54 PM, Vaclav Dusek wrote:
Ahoj,
nikdo si nemůže dovolit testovat na koncových zákaznících v produkčním prostředí. Produkční prostředí je od toho, aby bylo maximálně stabilní za cenu jisté konzervativnosti v "zastaralých" verzích aplikací.
Jediné řešení vidím v jasném rozdělení VPSfree na 2 nezávislé větve
- produkce/provoz, tj. stabilita, konzervativnost, minimum změn,
pouze bezpečnostní aktualizace
- development, tj. testování nových věcí, které se po určité době
přenášejí do produkce, a nebo aplikují na nové servery, které se stávají později produkcí.
Coz je strasne pekna teorie, ano.
Jak rikam, ja ty veci testuju, nez jdou do production.
Uzivatele, kterym nevadi vypadky, v drtivy vetsine skoro nic neprovozujou - cili je to jeste horsi, nez muj testing env. Opravte mne, jestli se mylim, ale kdyz uz mam nejakou zatez, vetsinou mam duvod, proc ji mam => je to production.
Jak je ostatne videt na playgroundu :)
/snajpa
Uživatelé, kterým nevadí výpadky a potřebují poslední nové věci, ať dobrovolně vstoupí do devel větve a mají např. nižší poplatek za provoz, větší disk apod.
Jiní ať pracují v produkční větvi, protože si výpadky _nemohou_ dovolit. Mohou tak získávat postupně více devítek v dostupnosti, přibližovat se postupně k 6 sigma :)
Současný stav mi přijde nešťastný.
Dne 17.9.2014 13:20, mrkva@mrkva.eu napsal(a):
Ahoj, na tohle jsi prisel jak?
On 17.9.2014 11:26, Tomáš Valoušek wrote:
Ahoj...
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:06 PM, Pavel Snajdr wrote:
On 09/17/2014 01:54 PM, Vaclav Dusek wrote:
Ahoj,
nikdo si nemůže dovolit testovat na koncových zákaznících v produkčním prostředí. Produkční prostředí je od toho, aby bylo maximálně stabilní za cenu jisté konzervativnosti v "zastaralých" verzích aplikací.
Jediné řešení vidím v jasném rozdělení VPSfree na 2 nezávislé větve
- produkce/provoz, tj. stabilita, konzervativnost, minimum změn,
pouze bezpečnostní aktualizace
- development, tj. testování nových věcí, které se po určité době
přenášejí do produkce, a nebo aplikují na nové servery, které se stávají později produkcí.
Coz je strasne pekna teorie, ano.
Jak rikam, ja ty veci testuju, nez jdou do production.
Uzivatele, kterym nevadi vypadky, v drtivy vetsine skoro nic neprovozujou - cili je to jeste horsi, nez muj testing env. Opravte mne, jestli se mylim, ale kdyz uz mam nejakou zatez, vetsinou mam duvod, proc ji mam => je to production.
Jak je ostatne videt na playgroundu :)
Ale abych Ti nekrivdil, pravda je, ze ten problem s MySQL by se nejspis projevil, jelikoz ja mam MySQL vsude uz od prvnich experimentu se ZFS s vypnutym native AIO.
Nicmene ne nestabilita, coz je nevetsi pain point IMHO.
/snajpa
/snajpa
Uživatelé, kterým nevadí výpadky a potřebují poslední nové věci, ať dobrovolně vstoupí do devel větve a mají např. nižší poplatek za provoz, větší disk apod.
Jiní ať pracují v produkční větvi, protože si výpadky _nemohou_ dovolit. Mohou tak získávat postupně více devítek v dostupnosti, přibližovat se postupně k 6 sigma :)
Současný stav mi přijde nešťastný.
Dne 17.9.2014 13:20, mrkva@mrkva.eu napsal(a):
Ahoj, na tohle jsi prisel jak?
On 17.9.2014 11:26, Tomáš Valoušek wrote:
Ahoj...
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Chapu,
ale jsou ty důvody, proc se dělají změny v produkci tak často, skutečne relevantní?
Základní poučka admina/správce přece zní:
Když ti něco funguje, tak se v tom zbytečně nehradej :D
Dne 17.9.2014 14:09, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:06 PM, Pavel Snajdr wrote:
On 09/17/2014 01:54 PM, Vaclav Dusek wrote:
Ahoj,
nikdo si nemůže dovolit testovat na koncových zákaznících v produkčním prostředí. Produkční prostředí je od toho, aby bylo maximálně stabilní za cenu jisté konzervativnosti v "zastaralých" verzích aplikací.
Jediné řešení vidím v jasném rozdělení VPSfree na 2 nezávislé větve
- produkce/provoz, tj. stabilita, konzervativnost, minimum změn,
pouze bezpečnostní aktualizace
- development, tj. testování nových věcí, které se po určité době přenášejí do produkce, a nebo aplikují na nové servery, které
se stávají později produkcí.
Coz je strasne pekna teorie, ano.
Jak rikam, ja ty veci testuju, nez jdou do production.
Uzivatele, kterym nevadi vypadky, v drtivy vetsine skoro nic neprovozujou - cili je to jeste horsi, nez muj testing env. Opravte mne, jestli se mylim, ale kdyz uz mam nejakou zatez, vetsinou mam duvod, proc ji mam => je to production.
Jak je ostatne videt na playgroundu :)
Ale abych Ti nekrivdil, pravda je, ze ten problem s MySQL by se nejspis projevil, jelikoz ja mam MySQL vsude uz od prvnich experimentu se ZFS s vypnutym native AIO.
Nicmene ne nestabilita, coz je nevetsi pain point IMHO.
/snajpa
/snajpa
Uživatelé, kterým nevadí výpadky a potřebují poslední nové věci, ať dobrovolně vstoupí do devel větve a mají např. nižší poplatek za provoz, větší disk apod.
Jiní ať pracují v produkční větvi, protože si výpadky _nemohou_ dovolit. Mohou tak získávat postupně více devítek v dostupnosti, přibližovat se postupně k 6 sigma :)
Současný stav mi přijde nešťastný.
Dne 17.9.2014 13:20, mrkva@mrkva.eu napsal(a):
Ahoj, na tohle jsi prisel jak?
On 17.9.2014 11:26, Tomáš Valoušek wrote:
Ahoj...
Ale ono to nefunguje... On 17.9.2014 11:22, Pavel Snajdr wrote:
Kdyby te to chtelo zajimat, kernel 085.20 byl zranitelnej nejmin na 3 CVEcka, nefungoval systemd pod Archlinuxem a byl rozbitej accounting CPU time, to jenom tak, co si pamatuju, je tam nescetne dalsich fixu okolo.
On 17.9.2014 14:17, Vaclav Dusek wrote:
Chapu,
ale jsou ty důvody, proc se dělají změny v produkci tak často, skutečne relevantní?
Základní poučka admina/správce přece zní:
Když ti něco funguje, tak se v tom zbytečně nehradej :DDne 17.9.2014 14:09, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:06 PM, Pavel Snajdr wrote:
On 09/17/2014 01:54 PM, Vaclav Dusek wrote:
Ahoj,
nikdo si nemůže dovolit testovat na koncových zákaznících v produkčním prostředí. Produkční prostředí je od toho, aby bylo maximálně stabilní za cenu jisté konzervativnosti v "zastaralých" verzích aplikací.
Jediné řešení vidím v jasném rozdělení VPSfree na 2 nezávislé větve
- produkce/provoz, tj. stabilita, konzervativnost, minimum změn,
pouze bezpečnostní aktualizace
- development, tj. testování nových věcí, které se po určité době přenášejí do produkce, a nebo aplikují na nové servery, které
se stávají později produkcí.
Coz je strasne pekna teorie, ano.
Jak rikam, ja ty veci testuju, nez jdou do production.
Uzivatele, kterym nevadi vypadky, v drtivy vetsine skoro nic neprovozujou - cili je to jeste horsi, nez muj testing env. Opravte mne, jestli se mylim, ale kdyz uz mam nejakou zatez, vetsinou mam duvod, proc ji mam => je to production.
Jak je ostatne videt na playgroundu :)
Ale abych Ti nekrivdil, pravda je, ze ten problem s MySQL by se nejspis projevil, jelikoz ja mam MySQL vsude uz od prvnich experimentu se ZFS s vypnutym native AIO.
Nicmene ne nestabilita, coz je nevetsi pain point IMHO.
/snajpa
/snajpa
Uživatelé, kterým nevadí výpadky a potřebují poslední nové věci, ať dobrovolně vstoupí do devel větve a mají např. nižší poplatek za provoz, větší disk apod.
Jiní ať pracují v produkční větvi, protože si výpadky _nemohou_ dovolit. Mohou tak získávat postupně více devítek v dostupnosti, přibližovat se postupně k 6 sigma :)
Současný stav mi přijde nešťastný.
Dne 17.9.2014 13:20, mrkva@mrkva.eu napsal(a):
Ahoj, na tohle jsi prisel jak?
On 17.9.2014 11:26, Tomáš Valoušek wrote:
Ahoj...
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:17 PM, Vaclav Dusek wrote:
Chapu,
ale jsou ty důvody, proc se dělají změny v produkci tak často, skutečne relevantní?
Základní poučka admina/správce přece zní:
Když ti něco funguje, tak se v tom zbytečně nehradej :D
Tobe prijde normalni updatovat jadro jednou za rok na produkcnich strojich? A to to jeste nedelame zdaleka tak casto, jak bychom meli!
/snajpa
Dne 17.9.2014 14:09, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:06 PM, Pavel Snajdr wrote:
On 09/17/2014 01:54 PM, Vaclav Dusek wrote:
Ahoj,
nikdo si nemůže dovolit testovat na koncových zákaznících v produkčním prostředí. Produkční prostředí je od toho, aby bylo maximálně stabilní za cenu jisté konzervativnosti v "zastaralých" verzích aplikací.
Jediné řešení vidím v jasném rozdělení VPSfree na 2 nezávislé větve
- produkce/provoz, tj. stabilita, konzervativnost, minimum
změn, pouze bezpečnostní aktualizace
- development, tj. testování nových věcí, které se po určité
době přenášejí do produkce, a nebo aplikují na nové servery, které se stávají později produkcí.
Coz je strasne pekna teorie, ano.
Jak rikam, ja ty veci testuju, nez jdou do production.
Uzivatele, kterym nevadi vypadky, v drtivy vetsine skoro nic neprovozujou - cili je to jeste horsi, nez muj testing env. Opravte mne, jestli se mylim, ale kdyz uz mam nejakou zatez, vetsinou mam duvod, proc ji mam => je to production.
Jak je ostatne videt na playgroundu :)
Ale abych Ti nekrivdil, pravda je, ze ten problem s MySQL by se nejspis projevil, jelikoz ja mam MySQL vsude uz od prvnich experimentu se ZFS s vypnutym native AIO.
Nicmene ne nestabilita, coz je nevetsi pain point IMHO.
/snajpa
/snajpa
Uživatelé, kterým nevadí výpadky a potřebují poslední nové věci, ať dobrovolně vstoupí do devel větve a mají např. nižší poplatek za provoz, větší disk apod.
Jiní ať pracují v produkční větvi, protože si výpadky _nemohou_ dovolit. Mohou tak získávat postupně více devítek v dostupnosti, přibližovat se postupně k 6 sigma :)
Současný stav mi přijde nešťastný.
Dne 17.9.2014 13:20, mrkva@mrkva.eu napsal(a):
Ahoj, na tohle jsi prisel jak?
On 17.9.2014 11:26, Tomáš Valoušek wrote:
Ahoj...
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
To mi prijde docela normalni, pokud to jadro nema critical security chyby...
On 17. září 2014 14:25:45 CEST, Pavel Snajdr snajpa@snajpa.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:17 PM, Vaclav Dusek wrote:
Chapu,
ale jsou ty důvody, proc se dělají změny v produkci tak často, skutečne relevantní?
Základní poučka admina/správce přece zní:
Když ti něco funguje, tak se v tom zbytečně nehradej :D
Tobe prijde normalni updatovat jadro jednou za rok na produkcnich strojich? A to to jeste nedelame zdaleka tak casto, jak bychom meli!
/snajpa
Dne 17.9.2014 14:09, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:06 PM, Pavel Snajdr wrote:
On 09/17/2014 01:54 PM, Vaclav Dusek wrote:
Ahoj,
nikdo si nemůže dovolit testovat na koncových zákaznících v produkčním prostředí. Produkční prostředí je od toho, aby bylo maximálně stabilní za cenu jisté konzervativnosti v "zastaralých" verzích aplikací.
Jediné řešení vidím v jasném rozdělení VPSfree na 2 nezávislé větve
- produkce/provoz, tj. stabilita, konzervativnost, minimum
změn, pouze bezpečnostní aktualizace
- development, tj. testování nových věcí, které se po určité
době přenášejí do produkce, a nebo aplikují na nové servery, které se stávají později produkcí.
Coz je strasne pekna teorie, ano.
Jak rikam, ja ty veci testuju, nez jdou do production.
Uzivatele, kterym nevadi vypadky, v drtivy vetsine skoro nic neprovozujou - cili je to jeste horsi, nez muj testing env. Opravte mne, jestli se mylim, ale kdyz uz mam nejakou zatez, vetsinou mam duvod, proc ji mam => je to production.
Jak je ostatne videt na playgroundu :)
Ale abych Ti nekrivdil, pravda je, ze ten problem s MySQL by se nejspis projevil, jelikoz ja mam MySQL vsude uz od prvnich experimentu se ZFS s vypnutym native AIO.
Nicmene ne nestabilita, coz je nevetsi pain point IMHO.
/snajpa
/snajpa
Uživatelé, kterým nevadí výpadky a potřebují poslední nové věci, ať dobrovolně vstoupí do devel větve a mají např. nižší poplatek za provoz, větší disk apod.
Jiní ať pracují v produkční větvi, protože si výpadky _nemohou_ dovolit. Mohou tak získávat postupně více devítek v dostupnosti, přibližovat se postupně k 6 sigma :)
Současný stav mi přijde nešťastný.
Dne 17.9.2014 13:20, mrkva@mrkva.eu napsal(a):
Ahoj, na tohle jsi prisel jak?
On 17.9.2014 11:26, Tomáš Valoušek wrote: > Ahoj...
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iF4EAREIAAYFAlQZfccACgkQMBKdi9lkZ6pPpAD/coMtX2DIUDq0EuZ7zJe00EzP EF9TZqxVZy8CQBtUGj0A/iNh6+j4QBqHWt65RQHNWqTVCsJWKP++gRsoqzgOQUu3 =ZIKf -----END PGP SIGNATURE----- _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:34 PM, semanmar@gmail.com wrote:
Bezna prax napr. v bankach. Ale aj ine firmy maju kriticke aplikacie, ktorych aj maly vypadok stoji kopu $$$, cize ak je security bug v nejakom kernel module ktory sa nepouziva, tak sa max. tak zablacklistuje... Nevravim ze je to najstastnejsia volba, predsalen ma potom admin celkom strach rebootovat masinu s 500+ dni uptime, kedze sanca ze znova nabehne je 50:50 :)
Jo, ja vim o cem mluvis - proste pokud to jde, zakaze se dana funkcionalita kouskem systemtap kodu. Nebo se resi veci jako kpatch/kGraft/Ksplice. Coz nevim, kdo by podporoval nas kernel a ani bych si to nelajznul, neco takovyho u nas zavadet...
Udelat to pri poslednich chybach, ktere jsme meli, tak by instantne ale prestala fungovat vetsina softwaru v kontejnerech (cosi s TTY kodem).
Takovyhle "hacky" misto reseni si muze dovolit admin, kterej na 100% zna workload, co mu na tom stroji bezi. Ale to, to the best of my knowledge, neni situace vpsFree.
/snajpa
Martin
Sent from my BlackBerry 10 smartphone. *From: *Michal Krajcirovic *Sent: *Mittwoch, 17. September 2014 14:29 *To: *vpsFree.cz Community list; Pavel Snajdr; Vaclav.Dusek@cz-pro.cz *Reply To: *vpsFree.cz Community list *Subject: *Re: [vpsFree.cz: community-list] Mimoradny vypadek dnes v noci
To mi prijde docela normalni, pokud to jadro nema critical security chyby...
On 17. září 2014 14:25:45 CEST, Pavel Snajdr snajpa@snajpa.net wrote:
On 09/17/2014 02:17 PM, Vaclav Dusek wrote:
Chapu,
ale jsou ty důvody, proc se dělají změny v produkci tak často, skutečne relevantní?
Základní poučka admina/správce přece zní:
Když ti něco funguje, tak se v tom zbytečně nehradej :D
Tobe prijde normalni updatovat jadro jednou za rok na produkcnich strojich? A to to jeste nedelame zdaleka tak casto, jak bychom meli!
/snajpa
Dne 17.9.2014 14:09, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:06 PM, Pavel Snajdr wrote:
On 09/17/2014 01:54 PM, Vaclav Dusek wrote:
Ahoj,
nikdo si nemůže dovolit testovat na koncových zákaznících v produkčním prostředí. Produkční prostředí je od toho, aby bylo maximálně stabilní za cenu jisté konzervativnosti v "zastaralých" verzích aplikací.
Jediné řešení vidím v jasném rozdělen í VPSfree na 2 nezávislé větve
- produkce/provoz, tj. stabilita, konzervativnost, minimum změn,
pouze bezpečnostní aktualizace
- development, tj. testování nových věcí, které se po určité době
přenášejí do produkce, a nebo aplikují na nové servery, které se stávají později produkcí.
Coz je strasne pekna teorie, ano.
Jak rikam, ja ty veci testuju, nez jdou do production.
Uzivatele, kterym nevadi vypadky, v drtivy vetsine skoro nic neprovozujou - cili je to jeste horsi, nez muj testing env. Opravte mne, jestli se mylim, ale kdyz uz mam nejakou zatez, vetsinou mam duvod, proc j i mam => je to production.
Jak je ostatne videt na playgroundu :)
Ale abych Ti nekrivdil, pravda je, ze ten problem s MySQL by se nejspis projevil, jelikoz ja mam MySQL vsude uz od prvnich experimentu se ZFS s vypnutym native AIO.
Nicmene ne nestabilita, coz je nevetsi pain point IMHO.
/snajpa
/snajpa
Uživatelé, kterým nevadí výpadky a potřebují poslední nové věci, ať dobrovolně vstoupí do devel větve a mají např. nižší poplatek za provoz, větší disk apod.
Jiní ať pracují v produkční větvi, protože si výpadky _nemohou_ dovolit. Mohou tak získávat postupně více devítek v dostupnosti, přibližovat se postupně k 6 sigma :)
Současný stav mi přijde nešťastný.
Dne 17.9.2014 13:20, mrkva@mrkva.eu napsal(a):
Ahoj, na tohle jsi prisel jak?
On 17.9.2014 11:26, Tomáš Valoušek wrote:
Ahoj...
Community-list
mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-- Send from my phone.
Pokud nejsou pro upgradde jádra či jiné komponenty _vážné_ důvody, NENÍ důvod upgradovat. Pro provoz to platí _dvojnásob_.
A že vyšla nová verze, která neřeší žádný z problémů (bezpečnostních / výkonových) _NENÍ_ důvod provádět upgrade.
Dne 17.9.2014 14:25, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:17 PM, Vaclav Dusek wrote:
Chapu,
ale jsou ty důvody, proc se dělají změny v produkci tak často, skutečne relevantní?
Základní poučka admina/správce přece zní:
Když ti něco funguje, tak se v tom zbytečně nehradej :D
Tobe prijde normalni updatovat jadro jednou za rok na produkcnich strojich? A to to jeste nedelame zdaleka tak casto, jak bychom meli!
/snajpa
Dne 17.9.2014 14:09, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:06 PM, Pavel Snajdr wrote:
On 09/17/2014 01:54 PM, Vaclav Dusek wrote:
Ahoj,
nikdo si nemůže dovolit testovat na koncových zákaznících v produkčním prostředí. Produkční prostředí je od toho, aby bylo maximálně stabilní za cenu jisté konzervativnosti v "zastaralých" verzích aplikací.
Jediné řešení vidím v jasném rozdělení VPSfree na 2 nezávislé větve
- produkce/provoz, tj. stabilita, konzervativnost, minimum
změn, pouze bezpečnostní aktualizace
- development, tj. testování nových věcí, které se po určité
době přenášejí do produkce, a nebo aplikují na nové servery, které se stávají později produkcí.
Coz je strasne pekna teorie, ano.
Jak rikam, ja ty veci testuju, nez jdou do production.
Uzivatele, kterym nevadi vypadky, v drtivy vetsine skoro nic neprovozujou - cili je to jeste horsi, nez muj testing env. Opravte mne, jestli se mylim, ale kdyz uz mam nejakou zatez, vetsinou mam duvod, proc ji mam => je to production.
Jak je ostatne videt na playgroundu :)
Ale abych Ti nekrivdil, pravda je, ze ten problem s MySQL by se nejspis projevil, jelikoz ja mam MySQL vsude uz od prvnich experimentu se ZFS s vypnutym native AIO.
Nicmene ne nestabilita, coz je nevetsi pain point IMHO.
/snajpa
/snajpa
Uživatelé, kterým nevadí výpadky a potřebují poslední nové věci, ať dobrovolně vstoupí do devel větve a mají např. nižší poplatek za provoz, větší disk apod.
Jiní ať pracují v produkční větvi, protože si výpadky _nemohou_ dovolit. Mohou tak získávat postupně více devítek v dostupnosti, přibližovat se postupně k 6 sigma :)
Současný stav mi přijde nešťastný.
Dne 17.9.2014 13:20, mrkva@mrkva.eu napsal(a):
Ahoj, na tohle jsi prisel jak?
On 17.9.2014 11:26, Tomáš Valoušek wrote: > Ahoj...
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iF4EAREIAAYFAlQZfccACgkQMBKdi9lkZ6pPpAD/coMtX2DIUDq0EuZ7zJe00EzP EF9TZqxVZy8CQBtUGj0A/iNh6+j4QBqHWt65RQHNWqTVCsJWKP++gRsoqzgOQUu3 =ZIKf -----END PGP SIGNATURE-----
S timhle pravidlem bych uplne nesouhlasil. Velmi specificky zalezi na prostredi. Ja napriklad mam nastavene automaticke aktualizace s automatickymi restarty, jen prostredi je webovy cluster, kde vypadek jednoho stroje nic neovlivni a tim padem si to muzu dovolit. Maximalne u databazi par vterin nez to vybere noveho mastera.
Jarda
------ Original Message ------ From: "Vaclav Dusek" Vaclav.Dusek@cz-pro.cz To: "Pavel Snajdr" snajpa@snajpa.net; "vpsFree.cz Community list" community-list@lists.vpsfree.cz Sent: 9/17/2014 2:31:48 PM Subject: Re: [vpsFree.cz: community-list] Mimoradny vypadek dnes v noci
Pokud nejsou pro upgradde jádra či jiné komponenty _vážné_ důvody, NENÍ důvod upgradovat. Pro provoz to platí _dvojnásob_.
A že vyšla nová verze, která neřeší žádný z problémů (bezpečnostních / výkonových) _NENÍ_ důvod provádět upgrade.
Dne 17.9.2014 14:25, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:17 PM, Vaclav Dusek wrote:
Chapu,
ale jsou ty důvody, proc se dělají změny v produkci tak často, skutečne relevantní?
Základní poučka admina/správce přece zní:
Když ti něco funguje, tak se v tom zbytečně nehradej :D
Tobe prijde normalni updatovat jadro jednou za rok na produkcnich strojich? A to to jeste nedelame zdaleka tak casto, jak bychom meli!
/snajpa
Dne 17.9.2014 14:09, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:06 PM, Pavel Snajdr wrote:
On 09/17/2014 01:54 PM, Vaclav Dusek wrote:
Ahoj,
nikdo si nemůže dovolit testovat na koncových zákaznících v produkčním prostředí. Produkční prostředí je od toho, aby bylo maximálně stabilní za cenu jisté konzervativnosti v "zastaralých" verzích aplikací.
Jediné řešení vidím v jasném rozdělení VPSfree na 2 nezávislé větve
- produkce/provoz, tj. stabilita, konzervativnost, minimum
změn, pouze bezpečnostní aktualizace
- development, tj. testování nových věcí, které se po určité
době přenášejí do produkce, a nebo aplikují na nové servery, které se stávají později produkcí.
Coz je strasne pekna teorie, ano.
Jak rikam, ja ty veci testuju, nez jdou do production.
Uzivatele, kterym nevadi vypadky, v drtivy vetsine skoro nic neprovozujou - cili je to jeste horsi, nez muj testing env. Opravte mne, jestli se mylim, ale kdyz uz mam nejakou zatez, vetsinou mam duvod, proc ji mam => je to production.
Jak je ostatne videt na playgroundu :)
Ale abych Ti nekrivdil, pravda je, ze ten problem s MySQL by se nejspis projevil, jelikoz ja mam MySQL vsude uz od prvnich experimentu se ZFS s vypnutym native AIO.
Nicmene ne nestabilita, coz je nevetsi pain point IMHO.
/snajpa
/snajpa
Uživatelé, kterým nevadí výpadky a potřebují poslední nové věci, ať dobrovolně vstoupí do devel větve a mají např. nižší poplatek za provoz, větší disk apod.
Jiní ať pracují v produkční větvi, protože si výpadky _nemohou_ dovolit. Mohou tak získávat postupně více devítek v dostupnosti, přibližovat se postupně k 6 sigma :)
Současný stav mi přijde nešťastný.
Dne 17.9.2014 13:20, mrkva@mrkva.eu napsal(a): >Ahoj, na tohle jsi prisel jak? > >On 17.9.2014 11:26, Tomáš Valoušek wrote: >>Ahoj...
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iF4EAREIAAYFAlQZfccACgkQMBKdi9lkZ6pPpAD/coMtX2DIUDq0EuZ7zJe00EzP EF9TZqxVZy8CQBtUGj0A/iNh6+j4QBqHWt65RQHNWqTVCsJWKP++gRsoqzgOQUu3 =ZIKf -----END PGP SIGNATURE-----
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:31 PM, Vaclav Dusek wrote:
Pokud nejsou pro upgradde jádra či jiné komponenty _vážné_ důvody, NENÍ důvod upgradovat. Pro provoz to platí _dvojnásob_.
A že vyšla nová verze, která neřeší žádný z problémů (bezpečnostních / výkonových) _NENÍ_ důvod provádět upgrade.
Souhlasim. Takove bezduvodne aktualizace nedelame.
Projdi si OpenVZ changelog a RHEL6 kernel changelog a uvidis.
Od toho jsou to stable supported kernely.
/snajpa
Dne 17.9.2014 14:25, Pavel Snajdr napsal(a): On 09/17/2014 02:17 PM, Vaclav Dusek wrote:
Chapu,
ale jsou ty důvody, proc se dělají změny v produkci tak často, skutečne relevantní?
Základní poučka admina/správce přece zní:
Když ti něco funguje, tak se v tom zbytečně nehradej :D
Tobe prijde normalni updatovat jadro jednou za rok na produkcnich strojich? A to to jeste nedelame zdaleka tak casto, jak bychom meli!
/snajpa
Dne 17.9.2014 14:09, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:06 PM, Pavel Snajdr wrote:
On 09/17/2014 01:54 PM, Vaclav Dusek wrote: > Ahoj,
> nikdo si nemůže dovolit testovat na koncových > zákaznících v produkčním prostředí. Produkční prostředí > je od toho, aby bylo maximálně stabilní za cenu jisté > konzervativnosti v "zastaralých" verzích aplikací.
> Jediné řešení vidím v jasném rozdělení VPSfree na 2 > nezávislé větve
> - produkce/provoz, tj. stabilita, konzervativnost, > minimum změn, pouze bezpečnostní aktualizace
> - development, tj. testování nových věcí, které se po > určité době přenášejí do produkce, a nebo aplikují na > nové servery, které se stávají později produkcí.
Coz je strasne pekna teorie, ano.
Jak rikam, ja ty veci testuju, nez jdou do production.
Uzivatele, kterym nevadi vypadky, v drtivy vetsine skoro nic neprovozujou - cili je to jeste horsi, nez muj testing env. Opravte mne, jestli se mylim, ale kdyz uz mam nejakou zatez, vetsinou mam duvod, proc ji mam => je to production.
Jak je ostatne videt na playgroundu :)
Ale abych Ti nekrivdil, pravda je, ze ten problem s MySQL by se nejspis projevil, jelikoz ja mam MySQL vsude uz od prvnich experimentu se ZFS s vypnutym native AIO.
Nicmene ne nestabilita, coz je nevetsi pain point IMHO.
/snajpa
/snajpa
> Uživatelé, kterým nevadí výpadky a potřebují poslední > nové věci, ať dobrovolně vstoupí do devel větve a mají > např. nižší poplatek za provoz, větší disk apod.
> Jiní ať pracují v produkční větvi, protože si výpadky > _nemohou_ dovolit. Mohou tak získávat postupně více > devítek v dostupnosti, přibližovat se postupně k 6 > sigma :)
> Současný stav mi přijde nešťastný.
> Dne 17.9.2014 13:20, mrkva@mrkva.eu napsal(a): >> Ahoj, na tohle jsi prisel jak? >> >> On 17.9.2014 11:26, Tomáš Valoušek wrote: >>> Ahoj...
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Abych to trosku podlozil, pro ty, co jsou lini si o tom neco najit a radsi budou delat akorat chytry :))
OpenVZ akorat vcera vydalo testing kernel 042stab093.5, ktery rebasuje nad RHEL6 kernel 2.6.32-431.29.2.el6 - da se cekat, ze tak do tydne max vyjde jako stable.
https://rhn.redhat.com/errata/RHSA-2014-1167.html https://access.redhat.com/security/cve/CVE-2014-0205 https://access.redhat.com/security/cve/CVE-2014-3535 https://access.redhat.com/security/cve/CVE-2014-3917 https://access.redhat.com/security/cve/CVE-2014-4667
Z toho jsme affected CVE-2014-0205.
Takze tak.
Jeste nejaky poznamky od expertu, co se do toho vyznaji?
/snajpa
On 09/17/2014 02:41 PM, Pavel Snajdr wrote:
On 09/17/2014 02:31 PM, Vaclav Dusek wrote:
Pokud nejsou pro upgradde jádra či jiné komponenty _vážné_ důvody, NENÍ důvod upgradovat. Pro provoz to platí _dvojnásob_.
A že vyšla nová verze, která neřeší žádný z problémů (bezpečnostních / výkonových) _NENÍ_ důvod provádět upgrade.
Souhlasim. Takove bezduvodne aktualizace nedelame.
Projdi si OpenVZ changelog a RHEL6 kernel changelog a uvidis.
Od toho jsou to stable supported kernely.
/snajpa
Dne 17.9.2014 14:25, Pavel Snajdr napsal(a): On 09/17/2014 02:17 PM, Vaclav Dusek wrote:
Chapu,
ale jsou ty důvody, proc se dělají změny v produkci tak často, skutečne relevantní?
Základní poučka admina/správce přece zní:
Když ti něco funguje, tak se v tom zbytečně nehradej :D
Tobe prijde normalni updatovat jadro jednou za rok na produkcnich strojich? A to to jeste nedelame zdaleka tak casto, jak bychom meli!
/snajpa
Dne 17.9.2014 14:09, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:06 PM, Pavel Snajdr wrote: > On 09/17/2014 01:54 PM, Vaclav Dusek wrote: >> Ahoj, > >> nikdo si nemůže dovolit testovat na koncových >> zákaznících v produkčním prostředí. Produkční >> prostředí je od toho, aby bylo maximálně stabilní za >> cenu jisté konzervativnosti v "zastaralých" verzích >> aplikací. > >> Jediné řešení vidím v jasném rozdělení VPSfree na 2 >> nezávislé větve > >> - produkce/provoz, tj. stabilita, konzervativnost, >> minimum změn, pouze bezpečnostní aktualizace > >> - development, tj. testování nových věcí, které se >> po určité době přenášejí do produkce, a nebo aplikují >> na nové servery, které se stávají později produkcí. > > Coz je strasne pekna teorie, ano. > > Jak rikam, ja ty veci testuju, nez jdou do production. > > Uzivatele, kterym nevadi vypadky, v drtivy vetsine > skoro nic neprovozujou - cili je to jeste horsi, nez > muj testing env. Opravte mne, jestli se mylim, ale kdyz > uz mam nejakou zatez, vetsinou mam duvod, proc ji mam > => je to production. > > Jak je ostatne videt na playgroundu :)
Ale abych Ti nekrivdil, pravda je, ze ten problem s MySQL by se nejspis projevil, jelikoz ja mam MySQL vsude uz od prvnich experimentu se ZFS s vypnutym native AIO.
Nicmene ne nestabilita, coz je nevetsi pain point IMHO.
/snajpa
> > /snajpa > > >> Uživatelé, kterým nevadí výpadky a potřebují >> poslední nové věci, ať dobrovolně vstoupí do devel >> větve a mají např. nižší poplatek za provoz, větší >> disk apod. > >> Jiní ať pracují v produkční větvi, protože si výpadky >> _nemohou_ dovolit. Mohou tak získávat postupně více >> devítek v dostupnosti, přibližovat se postupně k 6 >> sigma :) > >> Současný stav mi přijde nešťastný. > > >> Dne 17.9.2014 13:20, mrkva@mrkva.eu napsal(a): >>> Ahoj, na tohle jsi prisel jak? >>> >>> On 17.9.2014 11:26, Tomáš Valoušek wrote: >>>> Ahoj...
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
A proc musi byt nase provozni prostredi za kazdou cenu ihned updatovano?
Verze z OpenVZ jeste neni stabilni. Co kdyz za tu chybu muze jejich oprava? v RH kernelu z RH 6 rady bych vinu primarne nedaval
Obecne se s opravami alespon nejakou doby pocka, pak se vezme testovaci jeden box a az pote se updatuje...
Zeptejte se spravcu Win serveru, jak to delaji, jak radeji nekolik dnu pockaji - za cenu zvyseneho kratkodobeho rizika.
Skutecen ta opravovana chyba byla tak zasadni, aby se ihned muselo updatovat cele VPSfree? Neumim to posoudit, ale nekolik dnu se mohlo pockat a jet pak postupne
Az vyda OpenVZ stabilni jadro, to budeme znova updatovat?
Dne 17.9.2014 14:57, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Abych to trosku podlozil, pro ty, co jsou lini si o tom neco najit a radsi budou delat akorat chytry :))
OpenVZ akorat vcera vydalo testing kernel 042stab093.5, ktery rebasuje nad RHEL6 kernel 2.6.32-431.29.2.el6 - da se cekat, ze tak do tydne max vyjde jako stable.
https://rhn.redhat.com/errata/RHSA-2014-1167.html https://access.redhat.com/security/cve/CVE-2014-0205 https://access.redhat.com/security/cve/CVE-2014-3535 https://access.redhat.com/security/cve/CVE-2014-3917 https://access.redhat.com/security/cve/CVE-2014-4667
Z toho jsme affected CVE-2014-0205.
Takze tak.
Jeste nejaky poznamky od expertu, co se do toho vyznaji?
/snajpa
On 09/17/2014 02:41 PM, Pavel Snajdr wrote:
On 09/17/2014 02:31 PM, Vaclav Dusek wrote:
Pokud nejsou pro upgradde jádra či jiné komponenty _vážné_ důvody, NENÍ důvod upgradovat. Pro provoz to platí _dvojnásob_.
A že vyšla nová verze, která neřeší žádný z problémů (bezpečnostních / výkonových) _NENÍ_ důvod provádět upgrade.
Souhlasim. Takove bezduvodne aktualizace nedelame.
Projdi si OpenVZ changelog a RHEL6 kernel changelog a uvidis.
Od toho jsou to stable supported kernely.
/snajpa
Dne 17.9.2014 14:25, Pavel Snajdr napsal(a): On 09/17/2014 02:17 PM, Vaclav Dusek wrote:
Chapu,
ale jsou ty důvody, proc se dělají změny v produkci tak často, skutečne relevantní?
Základní poučka admina/správce přece zní:
Když ti něco funguje, tak se v tom zbytečně nehradej :D
Tobe prijde normalni updatovat jadro jednou za rok na produkcnich strojich? A to to jeste nedelame zdaleka tak casto, jak bychom meli!
/snajpa
Dne 17.9.2014 14:09, Pavel Snajdr napsal(a): > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > On 09/17/2014 02:06 PM, Pavel Snajdr wrote: >> On 09/17/2014 01:54 PM, Vaclav Dusek wrote: >>> Ahoj, >> >>> nikdo si nemůže dovolit testovat na koncových >>> zákaznících v produkčním prostředí. Produkční >>> prostředí je od toho, aby bylo maximálně stabilní za >>> cenu jisté konzervativnosti v "zastaralých" verzích >>> aplikací. >> >>> Jediné řešení vidím v jasném rozdělení VPSfree na 2 >>> nezávislé větve >> >>> - produkce/provoz, tj. stabilita, konzervativnost, >>> minimum změn, pouze bezpečnostní aktualizace >> >>> - development, tj. testování nových věcí, které se >>> po určité době přenášejí do produkce, a nebo aplikují >>> na nové servery, které se stávají později produkcí. >> >> Coz je strasne pekna teorie, ano. >> >> Jak rikam, ja ty veci testuju, nez jdou do production. >> >> Uzivatele, kterym nevadi vypadky, v drtivy vetsine >> skoro nic neprovozujou - cili je to jeste horsi, nez >> muj testing env. Opravte mne, jestli se mylim, ale kdyz >> uz mam nejakou zatez, vetsinou mam duvod, proc ji mam >> => je to production. >> >> Jak je ostatne videt na playgroundu :) > > Ale abych Ti nekrivdil, pravda je, ze ten problem s > MySQL by se nejspis projevil, jelikoz ja mam MySQL vsude > uz od prvnich experimentu se ZFS s vypnutym native AIO. > > Nicmene ne nestabilita, coz je nevetsi pain point IMHO. > > /snajpa > >> >> /snajpa >> >> >>> Uživatelé, kterým nevadí výpadky a potřebují >>> poslední nové věci, ať dobrovolně vstoupí do devel >>> větve a mají např. nižší poplatek za provoz, větší >>> disk apod. >> >>> Jiní ať pracují v produkční větvi, protože si výpadky >>> _nemohou_ dovolit. Mohou tak získávat postupně více >>> devítek v dostupnosti, přibližovat se postupně k 6 >>> sigma :) >> >>> Současný stav mi přijde nešťastný. >> >> >>> Dne 17.9.2014 13:20, mrkva@mrkva.eu napsal(a): >>>> Ahoj, na tohle jsi prisel jak? >>>> >>>> On 17.9.2014 11:26, Tomáš Valoušek wrote: >>>>> Ahoj...
On , Vaclav Dusek wrote:
A proc musi byt nase provozni prostredi za kazdou cenu ihned updatovano?
Verze z OpenVZ jeste neni stabilni. Co kdyz za tu chybu muze jejich oprava? v RH kernelu z RH 6 rady bych vinu primarne nedaval
Obecne se s opravami alespon nejakou doby pocka, pak se vezme testovaci jeden box a az pote se updatuje...
IIRC, snajpa rikal, ze to co nasazoval uz nejakou dobu bezi v relbitu. To ze tady to pod specifickou zatezi failnulo se jinak nez nasazenim v podstate otestovat neda ne?
Skutecen ta opravovana chyba byla tak zasadni, aby se ihned muselo updatovat cele VPSfree? Neumim to posoudit, ale nekolik dnu se mohlo pockat a jet pak postupne
Jak snajpa rikal, tak problem je casto na jednom konkretnim nodu, to prece postupne upradovani neresi n?
P.
Ano kazde prostredi je specificke a VPSfree obzvlast. Proto by zde mela byt vyssi konzervativnost ve sprave.
Zakaznika ale zajima primarne stabilita. Coz je jiny uhel pohledu nez administratora.
Tyto vypadky maji jediny dusledek - ztrata duvery zakazniku
Co chceme vice, co je pro nas zajimavejsi?
Provozovat stabilni sluzbu a propagovat jeji dobre jmeno a nebo mit vsude posledni verze kernelu, patchu apod.? Ano vse je o kompromisech a mire prijatelneho rizika.
Dne 17.9.2014 15:43, Paladin napsal(a):
On , Vaclav Dusek wrote:
A proc musi byt nase provozni prostredi za kazdou cenu ihned updatovano?
Verze z OpenVZ jeste neni stabilni. Co kdyz za tu chybu muze jejich oprava? v RH kernelu z RH 6 rady bych vinu primarne nedaval
Obecne se s opravami alespon nejakou doby pocka, pak se vezme testovaci jeden box a az pote se updatuje...
IIRC, snajpa rikal, ze to co nasazoval uz nejakou dobu bezi v relbitu. To ze tady to pod specifickou zatezi failnulo se jinak nez nasazenim v podstate otestovat neda ne?
Skutecen ta opravovana chyba byla tak zasadni, aby se ihned muselo updatovat cele VPSfree? Neumim to posoudit, ale nekolik dnu se mohlo pockat a jet pak postupne
Jak snajpa rikal, tak problem je casto na jednom konkretnim nodu, to prece postupne upradovani neresi n?
P.
Správci Win serverů mají servery jednak za NATem a aktualizace mají vypnuté a jednou za čas (rok, dva) dají tlačítko aktualizovat. Je pravda, že mám zkušenosti jen z ministerstev. Vše samozřejmě za velmi restriktivním firewallem.
Navíc Pavel psal, že jádro dlouhodobě testoval, ale nepovedlo se mu nasimulovat dané prostředí, kdy to padá.
Jediným opravdovým řešením je kompletní zdvojení, kdy by se vytvořil "testovací cluster", který by klonoval všechny nody a zdvojoval provoz. Pak by jsi měl prostředí k testování a mohl odchytat tyhle situace. Ale za cenu mnohonásobně vyšších nákladů a zbytečného plýtvání výkonu. Šlo by to zredukovat na jeden nod a z hlediska provozu největší virtuály, ale pořád je to stejně drbačka.
Člověk, který potřebuje mít maximální dostupnost stejně musí řešit failover a počítat s tím, že nic neběží na 100%. Proto tu jsou clustery + SW řešení, která to řeší, ale samozřejmě za větší peníz.
Účelem VPSFree bylo a je hlavně poskytnout VPS za rozumný peníz a šířit znalosti o správě virtualizačního prostředí.
Navíc nezapomínejme, že díky tomu máš přehled proč se tomu stalo a kluci se nám snaží poskytnout maximum. U firmy budou security spíše řešit až když to nastane, nebo to svedou na zákazníka.
Jan Mareš
2014-09-17 15:56 GMT+02:00 Vaclav Dusek Vaclav.Dusek@cz-pro.cz:
Ano kazde prostredi je specificke a VPSfree obzvlast. Proto by zde mela byt vyssi konzervativnost ve sprave.
Zakaznika ale zajima primarne stabilita. Coz je jiny uhel pohledu nez administratora.
Tyto vypadky maji jediny dusledek - ztrata duvery zakazniku
Co chceme vice, co je pro nas zajimavejsi?
Provozovat stabilni sluzbu a propagovat jeji dobre jmeno a nebo mit vsude posledni verze kernelu, patchu apod.? Ano vse je o kompromisech a mire prijatelneho rizika.
Dne 17.9.2014 15:43, Paladin napsal(a):
On , Vaclav Dusek wrote:
A proc musi byt nase provozni prostredi za kazdou cenu ihned updatovano?
Verze z OpenVZ jeste neni stabilni. Co kdyz za tu chybu muze jejich oprava? v RH kernelu z RH 6 rady bych vinu primarne nedaval
Obecne se s opravami alespon nejakou doby pocka, pak se vezme testovaci jeden box a az pote se updatuje...
IIRC, snajpa rikal, ze to co nasazoval uz nejakou dobu bezi v relbitu. To ze tady to pod specifickou zatezi failnulo se jinak nez nasazenim v podstate otestovat neda ne?
Skutecen ta opravovana chyba byla tak zasadni, aby se ihned muselo
updatovat cele VPSfree? Neumim to posoudit, ale nekolik dnu se mohlo pockat a jet pak postupne
Jak snajpa rikal, tak problem je casto na jednom konkretnim nodu, to prece postupne upradovani neresi n?
P.
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
On Wed, 17 Sep 2014 16:03:46 +0200 Jan Mareš jan.mares@manast.eu wrote:
Správci Win serverů mají servery jednak za NATem a aktualizace mají vypnuté
Pokud NAT považujete za způsob zvýšení bezpečnosti, je bohužel vidět, že problematice nerozumíte. Důležitý není NAT, ale firewall, který je pravda v drtivé většině konfigurován současně s NATem, ale o NAT fakt nejde. Jde o ten firewall, a ten zapnutý je, jak na node*, tak (doufám) na Vaší VPS. ;-)
Nicméně firewall neřeší "local privilege escalation", a jak už Snajpa napsal, ten je v případě VPSfree relevantním vektorem útoku.
Petr Tesařík
Vaclav Dusek wrote:
Ano kazde prostredi je specificke a VPSfree obzvlast. Proto by zde mela byt vyssi konzervativnost ve sprave.
Teploučko a smrádek...
Zakaznika ale zajima primarne stabilita. Coz je jiny uhel pohledu nez administratora.
Tyto vypadky maji jediny dusledek - ztrata duvery zakazniku
Co chceme vice, co je pro nas zajimavejsi?
Provozovat stabilni sluzbu a propagovat jeji dobre jmeno a nebo mit vsude posledni verze kernelu, patchu apod.? Ano vse je o kompromisech a mire prijatelneho rizika.
Jak přesně chcete mít dobré jméno služby, když víte, že máte v jádře zneužitelné privilege escalation? Jako jo, směrem k zákazníkům služba bez výpadku vypadá moc pěkně, ale jenom do doby, než se něco kvůli zanedbané údržbě pořádně vy****, o což si přesně "konzervativním přístupem" koledujete.
Tohle je vidět na každém rohu, hlavní je vypadat dobře, na potenciální problémy se kašle, dokud se z nich nestanou skutečné problémy. A dost často to jde ještě dál a problémy se řeší jenom v případě, že hrozí škody vlastní organizaci. (Příkladem toho druhého budiž hromada trvale dostupného malware na serverech největšího a nejlevnějšího webhostingu v ČR.)
Sorry, ale přidám se k předřečníkovi. Jestli je server/služba tak důležitá, je potřeba řešit failover minimálně na jiný server na jiném hostiteli v rámci vpsfree (kdyby snajpa přistoupil na to restartovat jednu noc polovinu serverů a druhou noc druhou polovinu) nebo i mimo.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 04:15 PM, Jirka Bourek wrote:
Vaclav Dusek wrote:
Ano kazde prostredi je specificke a VPSfree obzvlast. Proto by zde mela byt vyssi konzervativnost ve sprave.
Teploučko a smrádek...
Zakaznika ale zajima primarne stabilita. Coz je jiny uhel pohledu nez administratora.
Tyto vypadky maji jediny dusledek - ztrata duvery zakazniku
Co chceme vice, co je pro nas zajimavejsi?
Provozovat stabilni sluzbu a propagovat jeji dobre jmeno a nebo mit vsude posledni verze kernelu, patchu apod.? Ano vse je o kompromisech a mire prijatelneho rizika.
Jak přesně chcete mít dobré jméno služby, když víte, že máte v jádře zneužitelné privilege escalation? Jako jo, směrem k zákazníkům služba bez výpadku vypadá moc pěkně, ale jenom do doby, než se něco kvůli zanedbané údržbě pořádně vy****, o což si přesně "konzervativním přístupem" koledujete.
Tohle je vidět na každém rohu, hlavní je vypadat dobře, na potenciální problémy se kašle, dokud se z nich nestanou skutečné problémy. A dost často to jde ještě dál a problémy se řeší jenom v případě, že hrozí škody vlastní organizaci. (Příkladem toho druhého budiž hromada trvale dostupného malware na serverech největšího a nejlevnějšího webhostingu v ČR.)
Presne tohle je i muj nazor, nechce se mi nechat vyhnivat tam stare obviously zranitelne verze - ono, takhle: vetsina tech chyb nema funkcni exploity v momente, kdy to dostava CVE cislo, jenze to je pak akorat otazka dnu/tydnu, nez nekdo takovy exploit napise. A v momente, kdy existuje verejne dostupny exploit kod, je prusvih.
Obzvlast, kdyz mame otevrene registrace a ucet udelame kazdemu bez zaplaceni hned. Na druhou stranu nedelat to znamena nedat lidem moznost nas vyzkouset a tim padem u velky vetsiny lidi == nezajem.
Sorry, ale přidám se k předřečníkovi. Jestli je server/služba tak důležitá, je potřeba řešit failover minimálně na jiný server na jiném hostiteli v rámci vpsfree (kdyby snajpa přistoupil na to restartovat jednu noc polovinu serverů a druhou noc druhou polovinu) nebo i mimo.
Vypada to jako nutnost. Akorat premejslim nad nejakym prediktibilnim klicem, podle kteryho to vezmem - asi to splitnout na pulku podle klice sudy/lichy. Nebo ma nekdo lepsi napad?
/snajpa
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Dne 17.9.2014 v 16:20 Pavel Snajdr napsal(a):
Sorry, ale přidám se k předřečníkovi. Jestli je server/služba tak důležitá, je potřeba řešit failover minimálně na jiný server na jiném hostiteli v rámci vpsfree (kdyby snajpa přistoupil na to restartovat jednu noc polovinu serverů a druhou noc druhou polovinu) nebo i mimo.
Vypada to jako nutnost. Akorat premejslim nad nejakym prediktibilnim klicem, podle kteryho to vezmem - asi to splitnout na pulku podle klice sudy/lichy. Nebo ma nekdo lepsi napad?
/snajpa
Přijde mi, že je celkem jedno jaký bude klíč, takže klidně sudá/lichá, ale důležité je, aby byl tento klíč veřejně známý a aby si mohl člověk objednat VPS z daného lotu, pokud si bude chtít udělat nějaké failover řešení a mít zajištěno, že mu z důvodu nějaké nestability nespadnou obě VPS najednou, jak už tu někdo psal (že při hromadném restartu mu nestihne první VPS kompletně naběhnout a druhá co zatím převzala práci už jde do restartu taky).
Š.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 05:39 PM, Stepan Liska wrote:
Dne 17.9.2014 v 16:20 Pavel Snajdr napsal(a):
Sorry, ale přidám se k předřečníkovi. Jestli je server/služba tak důležitá, je potřeba řešit failover minimálně na jiný server na jiném hostiteli v rámci vpsfree (kdyby snajpa přistoupil na to restartovat jednu noc polovinu serverů a druhou noc druhou polovinu) nebo i mimo.
Vypada to jako nutnost. Akorat premejslim nad nejakym prediktibilnim klicem, podle kteryho to vezmem - asi to splitnout na pulku podle klice sudy/lichy. Nebo ma nekdo lepsi napad?
/snajpa
Přijde mi, že je celkem jedno jaký bude klíč, takže klidně sudá/lichá, ale důležité je, aby byl tento klíč veřejně známý a aby si mohl člověk objednat VPS z daného lotu, pokud si bude chtít udělat nějaké failover řešení a mít zajištěno, že mu z důvodu nějaké nestability nespadnou obě VPS najednou, jak už tu někdo psal (že při hromadném restartu mu nestihne první VPS kompletně naběhnout a druhá co zatím převzala práci už jde do restartu taky).
Š.
S velkou pravdepodobnost tohle dostane vpsAdmin na starost, at to nemusime resit rucne. Jeste nemam jasno presne v jaky podobe, ale uz se mi to kuchti v hlave a Aither ma na to uz taky nejaky ideas.
/snajpa
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Vaclav Dusek wrote:
A proc musi byt nase provozni prostredi za kazdou cenu ihned updatovano?
Verze z OpenVZ jeste neni stabilni. Co kdyz za tu chybu muze jejich oprava? v RH kernelu z RH 6 rady bych vinu primarne nedaval
Obecne se s opravami alespon nejakou doby pocka, pak se vezme testovaci jeden box a az pote se updatuje...
Za poslední dobu si vzpomínám na Heartbleed nebo snadno zneužitelná CVE v jádře, která vedla k privilege escalation. Taky jste nějakou dobu čekal?
Krom toho už snajpa hned na začátku psal, že téměř stejnou verzi měl nasazenou na relbitu měsíc.
Zeptejte se spravcu Win serveru, jak to delaji, jak radeji nekolik dnu pockaji - za cenu zvyseneho kratkodobeho rizika.
Jo, nebo taky ještě pár dní, ještě tejden tomu necháme a nakonec na to radši nebudeme sahat, co kdyby se to rozbilo. A kdo nic nedělá, nic nezkazí, tím líp pro něj. Dokud se to celé nevy...
Vaclav Dusek wrote:
Pokud nejsou pro upgradde jádra či jiné komponenty _vážné_ důvody, NENÍ důvod upgradovat. Pro provoz to platí _dvojnásob_.
A že vyšla nová verze, která neřeší žádný z problémů (bezpečnostních / výkonových) _NENÍ_ důvod provádět upgrade.
To je teoreticky pravda, ale v praxi... dokážete to rozlišit?
Já se přiznám, že já teda ne. Jako hezký příklad k tomuhle používám chybu v KVM, která by se dala popsat slovy "opravena chyba, která umožňovala hot-unplug (virtualizovaných) zařízení, která nepodporovala hotplug)" - z toho se jenom těžko pozná, že tahle chyba umožňovala z toho virtuálu utéct.
Plus je potřeba mít na paměti, že přes Linuse neprojde nic, co by umožnilo snadno grepnout changelog kernelu a vidět bezpečnostní chyby. Takže mám zato, že je lepší věřit, že když vývojáři kernelu - ať už na kernel.org, nebo v RHEL - vydají novou verzi ve stabilní řadě, mají k tomu nějaký důvod.
A co pred upgrade proste vzdy vybrat jeden vpsFree node jako QA. Ten upgradovat a teprve po X dnech bez problemu upgradoval zbytek? Ano i to nemusi znamenat odhaleni vseho, ale otestuje to upgrade v prostredi vpsFree a minimalizuje pocet nasranych lidi v pripade problemu. Ano, je to cas navic. L.
17. 9. 2014 v 13:54, Vaclav Dusek Vaclav.Dusek@cz-pro.cz:
Ahoj,
nikdo si nemůže dovolit testovat na koncových zákaznících v produkčním prostředí. Produkční prostředí je od toho, aby bylo maximálně stabilní za cenu jisté konzervativnosti v "zastaralých" verzích aplikací.
Jediné řešení vidím v jasném rozdělení VPSfree na 2 nezávislé větve
produkce/provoz, tj. stabilita, konzervativnost, minimum změn, pouze bezpečnostní aktualizace
development, tj. testování nových věcí, které se po určité době přenášejí do produkce, a nebo aplikují na nové servery, které se stávají později produkcí.
Uživatelé, kterým nevadí výpadky a potřebují poslední nové věci, ať dobrovolně vstoupí do devel větve a mají např. nižší poplatek za provoz, větší disk apod.
Jiní ať pracují v produkční větvi, protože si výpadky _nemohou_ dovolit. Mohou tak získávat postupně více devítek v dostupnosti, přibližovat se postupně k 6 sigma :)
Současný stav mi přijde nešťastný.
Dne 17.9.2014 13:20, mrkva@mrkva.eu napsal(a):
Ahoj, na tohle jsi prisel jak?
On 17.9.2014 11:26, Tomáš Valoušek wrote: Ahoj...
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/17/2014 02:28 PM, Ladislav Blažek wrote:
A co pred upgrade proste vzdy vybrat jeden vpsFree node jako QA. Ten upgradovat a teprve po X dnech bez problemu upgradoval zbytek? Ano i to nemusi znamenat odhaleni vseho, ale otestuje to upgrade v prostredi vpsFree a minimalizuje pocet nasranych lidi v pripade problemu. Ano, je to cas navic. L.
Vypada to jako nejschudnejsi reseni, sice se mi vubec nelibi, ale asi nemame az tak na vyber.
Jenze si stejne nejsem jisty, jak by to pomohlo.
Viz ted - padal akorat node5. Jaka je pravdepodobnost, ze bych zacal prave nim?
Pred tim zase padal specificky jenom node8 (dneska node7) kvuli chybe v conntracku.
=> ma to teda vubec cenu, se o to pokouset?
Hard to say. Aspon za mne.
/snajpa
- 2014 v 13:54, Vaclav Dusek Vaclav.Dusek@cz-pro.cz:
Ahoj,
nikdo si nemůže dovolit testovat na koncových zákaznících v produkčním prostředí. Produkční prostředí je od toho, aby bylo maximálně stabilní za cenu jisté konzervativnosti v "zastaralých" verzích aplikací.
Jediné řešení vidím v jasném rozdělení VPSfree na 2 nezávislé větve
- produkce/provoz, tj. stabilita, konzervativnost, minimum změn,
pouze bezpečnostní aktualizace
- development, tj. testování nových věcí, které se po určité době
přenášejí do produkce, a nebo aplikují na nové servery, které se stávají později produkcí.
Uživatelé, kterým nevadí výpadky a potřebují poslední nové věci, ať dobrovolně vstoupí do devel větve a mají např. nižší poplatek za provoz, větší disk apod.
Jiní ať pracují v produkční větvi, protože si výpadky _nemohou_ dovolit. Mohou tak získávat postupně více devítek v dostupnosti, přibližovat se postupně k 6 sigma :)
Současný stav mi přijde nešťastný.
Dne 17.9.2014 13:20, mrkva@mrkva.eu napsal(a):
Ahoj, na tohle jsi prisel jak?
On 17.9.2014 11:26, Tomáš Valoušek wrote: Ahoj...
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
On , Pavel Snajdr wrote:
Viz ted - padal akorat node5. Jaka je pravdepodobnost, ze bych zacal prave nim?
Pred tim zase padal specificky jenom node8 (dneska node7) kvuli chybe v conntracku.
=> ma to teda vubec cenu, se o to pokouset?
Nebudu se tvarit, ze vim neco o administraci serveru v tomto meritku, ale pokud je sance, ze trefis node, na kterem je problem cca. 1/10, tak to IMHO fakt nema cenu..
P.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Abych byl konkretni:
1. OpenVZ kernel 042stab093.4 vysel 16.8. 2. Od cca. 17.8. ho mame v Relbitu v testing env 3. ZFS 0.6.3 jsme pouzivali do ted, ale on top of that priplavaly do gitu commity, ktere zavadeji podporu napr. pro bookmarks, potom spousta dalsich veci z upstreamu z Illumosu - vicemene s kazdym dalsim commitem buildim novou verzi a posouvam ji do testingu Relbitu 4. Aktualni Relbit production bezi na 042stab093.4 a 0.6.3-9_g61e99a7 (tedy git verze) uz 30 dni a neni problem. 5. Pro vpsF melo jit do produkce o par commitu novejsi ZFS, ale byly to commity, ktery pokazdy neco fixovaly, zadny prevratny novinky - cetl jsem si kod tech commitu a vypadalo to reasonable. Plus v Relbit testing env to bezelo v pohode bez problemu cca tyden.
Cili zaver pro mne z toho je, ze at muzu testovat, jak chci, produkcni vpsFree zatez se mi proste nedari zreplikovat.
/snajpa
On 09/17/2014 10:39 AM, Pavel Snajdr wrote:
Mno, prijit ti to muze.
Jestli myslis, ze pro to delam malo, nech sa paci, dam ti root pristup a muzes to spravovat za mne.
Jak uz po trilionty rikam, proste to NENI jak testovat. A je to vec kterou neumim rozlousknout uz 6 let.
/snajpa
On 09/17/2014 06:10 AM, Peter Bačinský wrote:
Ahoj, musím sa pridať. Nebudem tu mudrovať, do týchto vecí sa fakt velmi nevyznám, ale so stabilitou je to posledný mesiac fakt naprd. Neviem ako to chodí, ale potešilo by ma, keby sa dal udržať nejaký štandard, takto mi to príjde, ako by sa nejak zbytočne moc experimentovalo a potom to padá.
S pozdravom,
*Peter Bačinský* konateľ spoločnosti
*Webino, s. r. o.* Železničná 152/75 90024 Veľký Biel Slovensko
*Web stránky a internetové aplikácie pre Vaše podnikanie.*
+421 918 641 804, info@webino.sk mailto:info@webino.sk, www.webino.sk http://www.webino.sk/
*PROSÍM ZACHOVÁVAJTE HISTÓRIU V SPRÁVE, ĎAKUJEM*
On 16.09.2014 21:20, Martin Petricek wrote:
A nebylo by lepsi delat podobne planovane upgrady v ramci VPSfree "po jednom"? Napr. v pondeli node1, utery node2, atd ..... Pokud se vyskytne problem, nemusi se pak vsechno zase hromadne downgradovat (mam pocit ze minuly upgrade taky koncil podobne, po par neuspesnych rebotech se zase downgradovalo). Nebo minimalne jeden den jeden nahodne vybrany stroj, druhy den dalsi 2 a treti den zbytek (mene pracne nez delat nody kazdy den po jednom a mensi sance ze downgrade postihne vse ...)...
Pokud se neco prvni den podela, odnese to jen jeden stroj a ne vsechny...
Takhle budu mit zase noc kdy se nevyspim, dneska rano jsem daval dohromady servery po rebootu, na jednom nenajelo vubec mysql dokud jsem nenastavil innodb_use_native_aio = 0 :(
Puvodne jsem si tu poridil jeste druhe vps (jedno mam na node5, druhe na node6), aby byl nejaky failover, t.j. slusna sance ze v jakykoliv okamzik aspon jeden pojede, ale pokud se rebootuje vsechno najednou, nebo kousek po sobe, tak obvykle je druhe vps dole driv nez najede to prvni, pripadne drv nez stihnu spravit to prvni (pokud se objevi po rebootu nejaky problem), coz ty moje predstavy o tom ze druha fyzicka masina situaci zlepsi (sice zlepsi, ale ne o moc) tak trochu bori :)
Martin
On 2014-09-16 20:52, Pavel Snajdr wrote:
Ahojte,
tak je to tu znova, zase se mi nepovedlo poradne otestovat kombinaci vzkernel/ZFS v ostatnich prostredich, nez je vpsFree. A to podotykam, ze ty same verze nam v Relbitu bezi pod poradnou zatezi in production uz cca mesic. A neni tam problem.
Nicmene u nas to vypada, ze problem je, cili budeme muset downgradovat dnes v noci na ZFS 0.6.3-1 a SPL stejne verze.
Bude to obnaset vypadek rovnajici se rebootu vsech stroju, bohuzel.
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
ahoj, Virtualni servery pouzivam cca poslednich 5 let a zacinal jsem u Active24, FOPSI .... ->> az jsem skoncil u VPSFree, co se tyce ceny tak jsem za VPS platil mesicne i 2000,- IMHO v EVROPE nejlepsi sluzba. jeste jse to nikdy nepsal :) ale dekuju celemu tymu VPSFree za to jak to delaji
Jan Macík IT DEVELOPER 776 005 239 PS: POLITICI JSOU HYENY A NA KAZDOU HYENU SE VODA VARI !!!! ______________________________________________________________
Od: Pavel Snajdr snajpa@snajpa.net Komu: "vpsFree.cz Community list" community-list@lists.vpsfree.cz Datum: 17.09.2014 10:45 Předmět: Re: [vpsFree.cz: community-list] Mimoradny vypadek dnes v noci
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Mno, prijit ti to muze.
Jestli myslis, ze pro to delam malo, nech sa paci, dam ti root pristup a muzes to spravovat za mne.
Jak uz po trilionty rikam, proste to NENI jak testovat. A je to vec kterou neumim rozlousknout uz 6 let.
/snajpa
On 09/17/2014 06:10 AM, Peter Bačinský wrote:
Ahoj, musím sa pridať. Nebudem tu mudrovať, do týchto vecí sa fakt velmi nevyznám, ale so stabilitou je to posledný mesiac fakt naprd. Neviem ako to chodí, ale potešilo by ma, keby sa dal udržať nejaký štandard, takto mi to príjde, ako by sa nejak zbytočne moc experimentovalo a potom to padá.
S pozdravom,
*Peter Bačinský* konateľ spoločnosti
*Webino, s. r. o.* Železničná 152/75 90024 Veľký Biel Slovensko
*Web stránky a internetové aplikácie pre Vaše podnikanie.*
+421 918 641 804, info@webino.sk mailto:info@webino.sk, www.webino.sk <http://www.webino.sk/ http://www.webino.sk/>
*PROSÍM ZACHOVÁVAJTE HISTÓRIU V SPRÁVE, ĎAKUJEM*
On 16.09.2014 21:20, Martin Petricek wrote:
A nebylo by lepsi delat podobne planovane upgrady v ramci VPSfree "po jednom"? Napr. v pondeli node1, utery node2, atd ..... Pokud se vyskytne problem, nemusi se pak vsechno zase hromadne downgradovat (mam pocit ze minuly upgrade taky koncil podobne, po par neuspesnych rebotech se zase downgradovalo). Nebo minimalne jeden den jeden nahodne vybrany stroj, druhy den dalsi 2 a treti den zbytek (mene pracne nez delat nody kazdy den po jednom a mensi sance ze downgrade postihne vse ...)...
Pokud se neco prvni den podela, odnese to jen jeden stroj a ne vsechny...
Takhle budu mit zase noc kdy se nevyspim, dneska rano jsem daval dohromady servery po rebootu, na jednom nenajelo vubec mysql dokud jsem nenastavil innodb_use_native_aio = 0 :(
Puvodne jsem si tu poridil jeste druhe vps (jedno mam na node5, druhe na node6), aby byl nejaky failover, t.j. slusna sance ze v jakykoliv okamzik aspon jeden pojede, ale pokud se rebootuje vsechno najednou, nebo kousek po sobe, tak obvykle je druhe vps dole driv nez najede to prvni, pripadne drv nez stihnu spravit to prvni (pokud se objevi po rebootu nejaky problem), coz ty moje predstavy o tom ze druha fyzicka masina situaci zlepsi (sice zlepsi, ale ne o moc) tak trochu bori :)
Martin
On 2014-09-16 20:52, Pavel Snajdr wrote:
Ahojte,
tak je to tu znova, zase se mi nepovedlo poradne otestovat kombinaci vzkernel/ZFS v ostatnich prostredich, nez je vpsFree. A to podotykam, ze ty same verze nam v Relbitu bezi pod poradnou zatezi in production uz cca mesic. A neni tam problem.
Nicmene u nas to vypada, ze problem je, cili budeme muset downgradovat dnes v noci na ZFS 0.6.3-1 a SPL stejne verze.
Bude to obnaset vypadek rovnajici se rebootu vsech stroju, bohuzel.
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
community-list@lists.vpsfree.cz
-
bacu＠centrum.cz -
Jan Mareš -
Jaroslav Skřivan -
Jirka Bourek -
Ladislav Blažek -
Martin Petricek -
Michal Krajcirovic -
mrkva＠mrkva.eu -
Paladin -
Pavel Snajdr -
Peter Bačinský -
Petr Tesařík -
semanmar＠gmail.com -
Stepan Liska -
Tomáš Valoušek -
Vaclav Dusek -
Vojtěch Knyttl