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

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

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

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

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

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

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

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

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

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.

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

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

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

á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.

( locsemege v | 2017. 04. 22., szo – 00:28 )

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ó.

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

( ibenny v | 2017. 04. 22., szo – 12:07 )

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

( tompos v | 2017. 04. 22., szo – 22:01 )

Miert a /. jelenti be a twitteren?