Komoly adatközpont problémával küzd a Red Hat jelenleg

 ( trey | 2017. április 21., péntek - 19:26 )

... ami rohadtul kihat a Fedora szolgáltatásaira is. Gyakorlatilag minden áll náluk.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

lehet megint felnyomták őket... :p

lattam, evlitte az epel-t is a cica tobbekkozott.

Amikor teljesen leállítanak valamit, annak valószínűleg biztonsági okai vannak. Aztán majd jön a bla bla bla.

--
robyboy

Vagy nem. Gondoljunk csak arra amikor az amazon sikeresen leallitotta a keleti partot. :D
Sot nalunk is elofordult regebben, hogy egy kis hiba aztan tovabbgyuruzott terhelesi problemaba, ami szep lassan leallitott mindent.
Vagy gondolj csak bele, amikor amerikaba valaki bekapcsolt egy klimat es leallt tole a keleti part aramszolgaltatasa. :D

Ezért írtam, hogy valószínűleg. Pont azért, mert itt egy konkrét cég teljes infrastruktúrája halt le, és nem a fél világ.

--
robyboy

Pont akkortájt, amikor ez a tweet megjelent, az Internet Archive is kiírta, hogy "hopsz, bocsi", mert egy áramszünet miatt leállt a San Franciscoi adatközpont, ahol vannak...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

És ehhez kellett 2 óra 40 perc, hogy rájöjjenek? És mi van a szünetmentes áramellátással?

--
robyboy

Meg a tűz eloltásához, meg a másik 89.999 érintett ember áramellátásának a megoldásához ;)
http://edition.cnn.com/2017/04/21/us/san-francisco-power-outage/

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Mi mar jartunk ugy, hogy az egesz orszagban aramszunet volt es az adatkozponti UPS-ek es generatorok is megsultek.

--
L

Ok, de akkor is sok a 2 óra 40 perc, hogy ezt felismerjék.

--
robyboy

Lehet az is. De a körülmények ismerete nélkül nem igazán ítélnék ilyen határozottsággal.
Ugyanis 500 évnél ritkábban előforduló árvízre senki sem méretez gátat...

IT-ra fordítva: simán lehet, hogy a normál esetben több, független betáp iránnyal ellátott gépteremben elhelyezett szolgáltatásra nincs olyan BCP szcenárió, hogy "Mi van, ha egyáltalán nincs áram?". Ráadásul ez egy teljesen megfelelő terv is lehet!
Ha pedig ez volt az alapfeltevés, hogy ott mindig van áram, akkor lehettek ott a monitoringért, kommunikációért, adminisztrációért felelős holmik - amik lehetetlenné tehették, hogy az üzemeltető időben értesüljön arról, hogy történt valami; illetve lehetetlenné tették, hogy cselekedjen.

Üdv,
Marci

Arról nem beszélve, hogy ilyenkor a szaki azzal van elfoglalva, hogy hibát javit, nem azzal, hogy a státuszt frissiti, azt lehetőleg oldja meg vmi manager két mondat után szóban.

De mindig aranyos, mikor messziről megszakértenek ekkora rendszereket :-)

Nem szakértettem meg semmit, csak 2 dolgot tartok érdekesnek. Az egyik az, hogy ők írták, hogy 2 óra 40 perc alatt jutottak el az investigation-től, a finding-ig.

A másik, ha nagy áramszünet van, azt kb. azonnal észre lehet venni.

--
robyboy

Továbbra sem ismerve a helyi viszonyokat, feltételezzünk egy helyzetet:
-Indiában ül a first level support, aki vagy felügyeleti képernyőről vagy felhasználói bejelentésből értesül a szolgáltatáskiesésről, investigating-et jelez.
-Megpróbálja feladni a Csehországban ülő második szintre a hibajegykezelőben (ami elérhetetlen), küld e-mailt (csendben nem érkezik meg), nézi a telefonkönyvet (elérhetetlen).
-Valahogy csak eléri a második szintet, aki nekiáll és hasonló körülmények közt megpróbálja megtudni, hova lett az adatközpont a nagy víz túloldalán. Az adatközpontban a telefont nem veszik fel, érthető okokból.
-Eltelt a 2h40p.

És akkor a 3rd level supportot még bele sem írtam...

Üdv,
Marci

Tényleg. Az ilyet hívom én amatőr megoldásnak.
Prio 1-nél pl. kellene mobiltelefon-nak (is) lenni, ami működhet még ilyen helyzetben is, vagy - ó Dzsízász - analóg telefonnak, ami saját feszről müködik. India olcsó, egész addig, amíg nincs semmi gond az infrastruktúrával. Pl. angolul sem tudnak normálisan, és sokszor az alapvető kommunikáció sem működik értelmesen.

Elfajzott egy világ ez, ahol szakmailag igazi kihívást jelent egy nyomorult áramszünet. Pont az ilyen DR-Fall-okra kellene a legjobban felkészülve lennie mindenkinek.

A jövő amúgy is az áramszünetekről fog szólni, mert a fogyasztás egyfolytában nő, a termelés meg nem bírja tartani a lépést a fogyasztással...

--
robyboy

Félreértesz. Nem arról beszéltem, hogy nem lehet ezer évente egyszer előforduló árvízre gátat építeni.
Arról beszéltem, hogy a tények ismerete hiányában az is feltételezhető, hogy tudatosan, szándékosan, gondos mérlegelés eredményeképpen nem építettek ilyen gátat.
Ezért irreleváns, ha leírod, hogyan kell 1000 évenkénti árvízre gátat építeni.

Természetesen az is benne van a kalapban, hogy voltak ilyen helyzetre kidolgozott BCP-DRP eljárások, de azok kudarcot vallottak. Nem tudjuk.

Üdv,
Marci

Mivel az áramellátás alapvető egy informatikai szolgáltatónál (is), illetve majdnem mindenhol, ez lenne a legfontosabb, az ilyen helyzetekre felkészülni.

Ez nem 1000 év kérdése, hanem folyamatosan aktuális.

Akit egy áramszünet padlóra küld, annak sajnos az az üzenete, hogy alkalmatlanok a helyzet kezelésére. Az sem mentség, hogy kispórolták a pénzt a rendszerből, különböző 1000 évekre hivatkozva.

Továbbra is az a gyanúm, hogy hackertámadás történt. Abban az esetben elfogadhatóbb a 2 óra 40 perces hibafelderítési idő.

--
robyboy

Write only vagy.

Üdv,
Marci

OK. Ertjuk. Mi mind szarul csenajjuk mester! De Te aztan tudod... :D

Bar a security problemaba is pont beletrafaltal lattatlanba, meg hogy majd el fogjak hallgatni...ja varj, megse :D

Tudod a biztonság csak pénz kérdése, és ez az, amire a legtöbben nem költenek (eleget).
Attól még lehetnek jó szakembereik, ezt sosem vitattam. Nincs szoros összefüggés a kettő között.

Egy akkora cég komolyságát bizony kikezdheti, ha azt mondják, hogy egy áramszünet fektette meg a teljes infrastruktúrájukat.

Szerintem rengeteg áramszünet lehetett már mindenhol, mondjuk az elmúlt húsz évben, mégsem emlékszem, hogy mindenféle Tech-cégek azt jelentgették volna, hogy emiatt feküdt meg a rendszerük.

Mondjuk garázs Bt-nél még el is fogadnám.

--
robyboy

Kérlek, áruld el, mekkora géppark volt a legnagyobb, aminek a BCP-DRP tervezésében és tesztelésében részt vettél?

Üdv,
Marci

Beletrafáltál, mert DR-Planer (is) vagyok a munkahelyemen, több ezer felhasználóval, 2 lokális Site-al, 4 böszme nagy szünetmentessel, 2 dízelgenerátorral.

Évente végzünk 1-nél több DR-tesztet is, volt már, hogy mi idéztük elő a hibát, de a működésben nem történt kiesés. Nem mondom, hogy nem történhet nagy probléma, de az nem egy egyszerű áramszünet lesz, az biztos.

Ha kiesik teljesen az egyik Site, akkor is működünk tovább. De az nem áramszünet miatt lesz, hanem pl. robbanás vagy tűz miatt. Arra azt mondom, Havária.

Georedundánsak is vagyunk, kicsi az esélye, hogy mindkét Site egyszerre felrobbanjon.

--
robyboy

Remek, így sokkal könnyebb szót érteni.
Mi a helyzet, ha kiesik két site?

Üdv,
Marci

kétségbeesett hup thread nyílik "Felnyomták a szerverem?!?!?$" címmel

Mi miatt is kellene mindkettőnek kiesni?

--
robyboy

QED.

Üdv,
Marci

Várom a Redhat jelentését az esetről. Kíváncsi vagyok. Fent van már valahol, mi is történt pontosan?
Mondjuk ha meg is jelenik valami tájékoztatás, akkor sem leszek abban biztos, hogy a teljes igazság ki fog belőle derülni.

Nem mondom, hogy nem lehetnek kiesések. Lehetnek. Az a nem mindegy, hogy mi okozza őket, és, hogy hogyan lehet az ellen védekezni. Az áramszünet önmagában nem magyarázat. Az ellen lehet és kell is védekezni.

--
robyboy

"Várom a Redhat jelentését az esetről. Kíváncsi vagyok. " - Na hál' Istennek, csak megérkeztünk végül a hét hozzászólással korábbi mondandómhoz. :D

"Az áramszünet önmagában nem magyarázat. Az ellen lehet és kell is védekezni." - Ti sem készültök két gépterem egyidejű, váratlan kiesésére, ha jól értem. Van olyan esemény, amire tudatosan nem készülünk. Persze, továbbra sem ismert, mi történt. Ezért nem szerencsés Virág-elvtárs módjára a tárgyalás előtt megírni az ítéletet.

Amúgy volt olyan teszt Nálatok, amit lentebb kérdeztem?

Üdv,
Marci

... és "a hét legunalmasabb kukilengetős threadje" díjat nyerte: ez.

5 pontos noname hupmeme member robika VS mikroszoftos marceekaXDD, gratulálunk

Amiben a legszomorúbb elem, hogy mi legalább elvagyunk vele, míg Te meg itt untatod magad. Mazó-e vagy?

Üdv,
Marci

Azért szegecs a nickneved, mert már páran annak néztek?

Kulturált eszmecserére ekkora talentum hozzászólás... made my day :)

--
robyboy

Mer a elviszik az ufok. Épp erről beszél Marci is, hogy ugyan eloadod hogy amatőrség aztán kiderül, hogy neked sincs terved arra hogy mi van, ha az egész rendszered beborul

Az a Havária. Arra senkinek sincs terve. De ott is a valós okok a mérvadóak, és nem az, amit egy manager, vagy marketing-es a világ képébe tol.

--
robyboy

Na jó, de te épp azon értetlenkedtél, hogy ha esetleg az RHnál is olyan ütött be, akkor miért tartott ennyi ideig.

Egyébként, meg de, van, általában business continuity plannek szokták hívni, és épp arról szól, hogy mi van akkor ha az IT/valamelyik nagy beszállító/akárki, aki a rendes üzletmenet szempontjából fontos/stb szétteszi a kezét, hogy ez most nincs, és egy darabig nem is lesz. És láttam már olyat leírva, aminek még haszna a volt.

A valódi okok, meg hát... szóval igen, de pl minden support egyik rákfenéje a mindenáron kötelezően megcsinálandó root cause analysis, aminek elég sokszor utólag kb az az eredménye, nyilván managerül elkenve, hogy "valami bug miatt beszart" az action plan hozzá meg, hogy "imádkozunk, hogy ennél az üfnél többet ne jöjjön elő". Én egyszer bejátszottam, hogy kell-e majd rendes RCA, mert akkor még pár órát itt elmojolok -- és nem biztos, hogy meglesz majd -- vagy szeretnének inkább szolgáltatást az ügyfélnél.

Volt olyan DR-tesztetek, amiben az egyik gépteremben, a rendszerek előkészítése nélkül, minden betápra kiterjedő teljes áramszünetet csináltatok?

Üdv,
Marci

Egyszer volt, épület főkapcsoló lekapcsolva. Azt túlélte akkor a rendszer. Egyébként általában nem akkor van gond, amikor elmegy az áram, hanem akkor, amikor visszajön. Minőségi szünetmentesekkel át lehet hidalni ezt a problémát is.
Persze ez az egész nem jelenti azt, hogy legközelebb is túlélné. Ezért is van 2 Site és Geo-Redundancia.

Amúgy igaz, hogy nincs 100%-os biztonság. De minél közelebb vagyunk a 100-hoz, annál megbízhatóbb a rendszer.
Nyilván pénzügyi döntés, hogy a büdzsé mit engedhet meg, illetve milyen kompromisszumokat kell kötni. Aztán ezek a rendszer Achilles-sarkai, és egy napon megbosszulják a spórolósdit.

--
robyboy

Kétségtelenül elismerésre méltó, szép eredmény!
Valóban a visszakapcs a nehezebb ügy: az ember néha nem győz fekete kakast keresni, hogy annak vérével vuduzva elérje, hogy az a bizonyos történelem előtti diszk-torony legalább nagyobbik részben felpörögjön. :D
Viszont az, hogy még ilyen fejlett üzemeltetés mellett Ti is csak egyszer vetemedtetek a tesztelésére (ami messze _több_ az átlagnál), mutatja, hogy pont a teljes géptermi hirtelen tápvesztés olyasmi, amit a költségei és kockázatai miatt nem szívesen próbálnak ki sokan, ezért bizony könnyű vele lyukra futni...
Majd ha a teszt- és szimulációs rendszereink olyanok lesznek, mint mondjuk a Paksi atomerőmű szimulátora, akkor már könnyebb lesz megnézni, minden jól működik-e egy teljes keresztmetszetű primer köri csőtörésnél...
Amúgy fixa ideám, hogy a hibrid software defined x technológiák térnyerésével idővel el lehet jutni oda, hogy ezen tesztek megfizethető költséggel és kockázattal rendszeresen végrehajthatók legyenek, sőt, hogy a meghibásodások a szokásos napi üzem részeként legyenek kezelve.

Üdv,
Marci

+1 = egyetértek.

--
robyboy

> Tudod a biztonság csak pénz kérdése, és ez az, amire a legtöbben nem költenek (eleget).

Nincs olyan, hogy abszolút biztonság. Persze, ahogy Dadan egy bolgár haverja mondaná... :)

Nyilván nincs, nem is ezt mondtam. De törekedni lehet és kell(ene) is rá, ami -valljuk be- rohadt sokba kerül. De egy akkora cégnek, mint a RedHat, nem szabadna ekkora problémát előidéznie egy áramkimaradásnak. Ha mégis, akkor ott vagy meghibásodások sorozata, vagy egy Single Point of Failure, vagy tesztelések/karbantartások hiánya, akár egy takarítónő az ok.

Lehet, hogy a RedHat nem sorolta be a rendszereit a Mission Critical kategóriába, így simán zöldre jelentik a menedzsment felé az egészet.

--
robyboy

+1

extraprofit szagot érzek

sokminden ki lett spórolva

Mindenesetre a két legvalószínűbb ok számomra továbbra is:

1. illetéktelen behatolás
2. félrement change / emberi hiba

Az áramszünet meg a legkézenfekvőbb kamu duma, amivel meg lehet etetni a fél világot.

"Jáj-jáj, indiai szákember benézni tűzfalförmvert... elszállt a konfig... jáj jáj"

--
robyboy

Idézet:
áramkimaradásnak

Keveset voltam gépközelben tegnap/ma, nem tudom, lett-e közben RH-tól bármi új infó, de az áramszünetet speciel az Internet Archive-ra írtam (meg San Francisco egy szép nagy részére :) ), messze nem biztos, hogy náluk is ez volt (legalábbis hivatalos forrásból még említés szinten sem hallottam)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Egy picit mar mas a vilag, de jo kis tortenet.

Mindenhol mindenki eszreveszi, hogy minden all, ezert a rad hat pros zart fb oldalon es messenger szobaban azonnal hivjak egymast es nyomjak a megosztast egy durva emojival hogy nagy a baj es mindenki hiv mindenkit es ir mindenkinek akinek az elerhetoseget tudjak. Persze ekkorra az oreg motoros, aki a telojarol is pingeli az oldalakat mar benn van a szobaba es nyomkodja a gombokat, huzza a kabeleket.

A RedHat-nél dolgozol?

Üdv,
Marci

Nem. Az enyém is csak egy történet volt.

Az ilyen helyzetekben az itil nehezen tartható.

Próbáltam volna elérni a Fedora build szervert, nem sikerült. Aztán magam is megtaláltam, hogy itt bizony valami baj van. :(


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Fedorához nincsenek tükrözött meg regionálisan szétszórt repótrükkök? Archnál vannak, lehet gépet dedikálni, szinkronizálni egy másik repós szerverrel, felkerül az is a repólistára, ha az egyik szerver elérhetetlen, ott a másik, meg még nem tudom hány földrészen. Az is igaz, hogy Archnál jóval kevesebb csomag van, mint Fedorához, szóval nem tudom mennyire megoldható.

Build szervert mondott, az nem repotükör

All systems go

--
trey @ gépház

érdekes szakfordítást hallottunk a "major outage"-re

Tény, hogy megy, le is töltöttem a build szerverről a legfrissebb, 4.10.12-es kernelt.

Valami infó van a történtek okáról?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

rhn-outage-list -- Announcements Related to RHN Service Interruptions

https://www.redhat.com/archives/rhn-outage-list/

"redhat.com will be back soon."

Még csinálódik.

--
trey @ gépház

http://status.redhat.com/

SSO se megy még

Ha jól látom, kb. 2 óra 40 perc alatt azonosították a hiba okát. Ez nem kevés idő. Már ha lehet hinni az adatoknak.

Identified - We have identified the issue and are working to resolve the problem.
Apr 21, 13:52 EDT
Investigating - Widespread system issues are causing parts of the Customer Portal to become non-responsive. We are working to resolve and will update this incident with relevant details.
Apr 21, 11:13 EDT

--
robyboy

Ha lett volna gondolatolvasó sisakjuk, sokkal gyorsabban ment volna.

Áramszünetet észrevenni? Erre vannak megfelelő tool-ok, rendszerek.

--
robyboy

http://status.redhat.com/
Sehol nem írták, hogy áramkimaradásuk lett volna.
Azt ellenben igen, hogy hálózati (network) volt.

2 óra 40 perc

Ebédszünettel együtt.

Biztos most váltottak systemd-re. :-)

ők pénzelik a systemd-t. Egyébként meg /triggered. Eleinte tényleg szar volt a systemd de most már sztem egy nagyon jó szoftver.

--
GPLv3-as hozzászólás.

Tudom, ezért volt ott a smiley, mostanra én is szeretem, jól kiforrta magát, csak tréfálkoztam. :-)

Miert a /. jelenti be a twitteren?

Náluk volt áram. :)