Bevezetés

Nemrég azt a feladatot kaptam, hogy fejlesszek egy feladatátvételi fürtöt a számára PostgreSQL, amely egy városon belül több, optikai szállal összekapcsolt adatközpontban működik, és képes ellenállni egy adatközpont meghibásodásának (például áramszünetnek). A hibatűrésért felelős szoftverként én választottam Pacemakermert ez a RedHat hivatalos megoldása feladatátvételi fürtök létrehozására. Azért jó, mert a RedHat támogatást nyújt hozzá, és mert ez a megoldás univerzális (moduláris). Segítségével nem csak a PostgreSQL, hanem más szolgáltatások hibatűrése is biztosítható lesz, akár szabványos modulok használatával, akár egyedi igényekre való elkészítésével.

Ez a döntés felvetett egy ésszerű kérdést: mennyire lesz hibatűrő egy feladatátvevő klaszter? Ennek kivizsgálására kifejlesztettem egy tesztpadot, amely szimulálja a különböző hibákat a fürtcsomópontokon, megvárja a szolgáltatás visszaállítását, helyreállítja a meghibásodott csomópontot, és ciklusban folytatja a tesztelést. Ezt a projektet eredetileg hapgsql-nek hívták, de idővel meguntam a nevet, aminek csak egy magánhangzója volt. Ezért elkezdtem hívni a hibatűrő adatbázisokat (és a rájuk mutató float IP-t) krogan (egy számítógépes játék karaktere, amelyben minden fontos szerv megkettőződik), a csomópontok, klaszterek és maga a projekt pedig tuchanka (a bolygó, ahol a kroganok élnek).

Most a vezetőség megengedte nyissa meg a projektet a nyílt forráskódú közösség számára az MIT licenc alatt. A README-t hamarosan lefordítják angolra (mert várhatóan a fő fogyasztók a Pacemaker és a PostgreSQL fejlesztői lesznek), és úgy döntöttem, hogy a README régi orosz verzióját (részben) bemutatom e cikk formájában.

A fürtök virtuális gépeken vannak üzembe helyezve VirtualBox. Összesen 12 virtuális gép (összesen 36 GiB) kerül telepítésre, amelyek 4 hibatűrő fürtöt alkotnak (különböző opciók). Az első két klaszter két PostgreSQL szerverből áll, amelyek különböző adatközpontokban találhatók, és egy közös szerverből tanú c határozatképességi eszköz (egy harmadik adatközpont olcsó virtuális gépén tárolva), ami feloldja a bizonytalanságot 50% / 50%, szavazatát az egyik félnek adja át. Harmadik fürt három adatközpontban: egy mester, két slave, nem határozatképességi eszköz. A negyedik fürt négy PostgreSQL szerverből áll, adatközpontonként kettőből: egy mesterből, a többi replikából, valamint tanú c határozatképességi eszköz. A negyedik két szerver vagy egy adatközpont meghibásodását is kibírja. Ez a megoldás szükség esetén nagyobb számú replikára méretezhető.

Pontos időszolgáltatás ntpd hibatűrésre is át van konfigurálva, de magát a módszert használja ntpd (árva mód). Megosztott szerver tanú központi NTP-szerverként működik, idejét minden fürtnek elosztva, ezáltal szinkronizálva az összes szervert egymással. Ha tanú meghibásodik vagy elszigetelődik, akkor az egyik fürtkiszolgáló (a fürtön belül) elkezdi elosztani az idejét. Kiegészítő gyorsítótár HTTP proxy -ra is nevelték tanú, segítségével más virtuális gépek is hozzáférhetnek a Yum-tárolókhoz. A valóságban az olyan szolgáltatások, mint a pontos idő és a proxy, nagy valószínűséggel dedikált szervereken lesznek tárolva, de a fülkében tanú csak a virtuális gépek számának és a hely megtakarítása érdekében.

Verziók

v0. Működik a CentOS 7 és a PostgreSQL 11 rendszerrel a VirtualBox 6.1 rendszeren.

Klaszter szerkezet

Minden klasztert úgy terveztek, hogy több adatközpontban helyezkedjenek el, egyetlen lapos hálózatba egyesítve, és ki kell bírniuk egyetlen adatközpont meghibásodását vagy hálózati elszigetelését. Ezért lehetetlen elleni védelemre használja hasított agyú szabványos pacemaker technológia az úgynevezett STONITH (Shoot The Other Node In The Head) vagy vívás. Lényege: ha a fürt csomópontjai gyanakodni kezdenek, hogy valami nem stimmel valamelyik csomóponttal, nem válaszol, vagy rosszul viselkedik, akkor „külső” eszközökön, például IPMI vagy UPS vezérlőkártyán keresztül erőszakosan kikapcsolják. . Ez azonban csak olyan esetekben működik, amikor egyetlen hiba esetén az IPMI vagy UPS szerver továbbra is működik. Itt azt tervezzük, hogy egy sokkal katasztrofálisabb meghibásodás ellen védekezzünk, amikor az egész adatközpont meghibásodik (például áramkimaradás). És egy ilyen visszautasítással mindent stonith-eszközök (IPMI, UPS stb.) szintén nem fognak működni.

Ehelyett a rendszer a határozatképesség elvén alapul. Minden csomópontnak van hangja, és csak azok működhetnek, amelyek az összes csomópont több mint felét látják. Ezt a „fél + 1” mennyiséget nevezzük határozatképesség. Ha nem éri el a kvórumot, akkor a csomópont úgy dönt, hogy hálózati elszigeteltségben van, és ki kell kapcsolnia az erőforrásait, pl. ez az, ami megosztott agyú védelem. Ha a szoftver, amely felelős ezért a viselkedésért, nem működik, akkor például egy IPMI-n alapuló watchdognak működnie kell.

Ha a csomópontok száma páros (egy klaszter két adatközpontban), akkor ún. bizonytalanság keletkezhet 50% / 50% (ötven-ötven), amikor a hálózati elkülönítés pontosan a felére osztja a klasztert. Ezért páros számú csomópont esetén hozzáadjuk határozatképességi eszköz egy igénytelen démon, amely egy harmadik adatközpont legolcsóbb virtuális gépén is elindítható. Szavazatát az egyik szegmensre adja (amit lát), és ezzel feloldja az 50%/50% bizonytalanságot. Megneveztem a szervert, amelyen a kvórum eszköz elindul tanú (terminológia a repmgr-ből, tetszett).

Az erőforrások egyik helyről a másikra mozgathatók, például a hibás szerverekről az egészségesekre, vagy a rendszergazdák parancsára. Annak érdekében, hogy az ügyfelek tudják, hol találhatók a szükséges erőforrások (hova csatlakozhatnak?), lebegő IP (float IP). Ezek olyan IP-címek, amelyeket a Pacemaker mozgathat a csomópontok között (minden lapos hálózaton van). Mindegyik egy-egy erőforrást (szolgáltatást) szimbolizál, és ott lesz, ahol csatlakoznia kell ahhoz, hogy hozzáférjen ehhez a szolgáltatáshoz (esetünkben egy adatbázishoz).

Tuchanka1 (áramkör tömörítéssel)

Szerkezet

Az ötlet az volt, hogy sok kis terhelésű adatbázisunk van, amelyekhez nem kifizetődő egy dedikált slave szervert hot standby üzemmódban fenntartani a csak olvasható tranzakciókhoz (nincs szükség ekkora erőforráspazarlásra).

Minden adatközponthoz egy szerver tartozik. Minden szervernek két PostgreSQL-példánya van (a PostgreSQL terminológiában ezeket fürtöknek hívják, de a félreértések elkerülése érdekében példányoknak nevezem őket (más adatbázisokhoz hasonlóan), a Pacemaker-fürtöket pedig csak fürtöknek nevezem. Az egyik példány mester módban működik, és csak az nyújt szolgáltatásokat (csak a float IP vezet hozzá). A második példány a második adatközpont slave-jeként működik, és csak akkor nyújt szolgáltatásokat, ha a mestere meghibásodik. Mivel legtöbbször csak a kettőből egy példány (a fő) nyújt szolgáltatásokat (kéréseket hajt végre), az összes szerver erőforrás a fő számára van optimalizálva (memória van lefoglalva a shared_buffers gyorsítótár számára stb.), de úgy, hogy a második példány elegendő erőforrással rendelkezik (bár a fájlrendszer gyorsítótárán keresztüli működéshez nem megfelelő) az egyik adatközpont meghibásodása esetén. A slave nem nyújt szolgáltatásokat (nem hajt végre csak olvasási kéréseket) a fürt normál működése során, így nincs háború az erőforrásokért a mesterrel ugyanazon a gépen.

Két csomópont esetén a hibatűrés csak aszinkron replikációval lehetséges, mivel szinkron replikáció esetén egy slave meghibásodása a master leállásához vezet.

A tanúskodás elmulasztása

A tanúskodás elmulasztása (határozatképességi eszköz) Csak a Tuchanka1 klasztert veszem figyelembe, az összes többivel ugyanaz lesz a történet. Ha a tanú kudarcot vall, semmi sem fog megváltozni a klaszter struktúrájában, minden ugyanúgy fog működni, mint korábban. De a határozatképesség 2-ból 3 lesz, és ezért minden későbbi hiba végzetes lesz a klaszter számára. Akkor is sürgősen meg kell javítani.

Tuchanka1 elutasítás

A Tuchanka1 egyik adatközpontjának meghibásodása. Ebben az esetben tanú egy második adatközpont második csomópontjára adja le szavazatát. Ott a korábbi slave mesterré változik, ennek eredményeként mindkét master ugyanazon a szerveren dolgozik, és mindkét lebegő IP-címe rájuk mutat.

Tuchanka2 (klasszikus)

Szerkezet

Két csomópont klasszikus sémája. Az egyiken a mester dolgozik, a másodikon a rabszolga. Mindkettő végrehajthat kéréseket (a slave csak olvasható), így mindkettőre a float IP mutat: krogan2 a master, krogan2s1 a slave. A master és a slave is hibatűréssel rendelkezik.

Két csomópont esetén a hibatűrés csak aszinkron replikációval lehetséges, mert szinkron replikációnál a slave meghibásodása a master leállásához vezet.

Tuchanka2 elutasítás

Ha az egyik adatközpont meghibásodik tanú szavazat a másodikra. Az egyetlen működő adatközpontban a mester fel lesz emelve, és mindkét lebegő IP rá fog mutatni: a mester és a slave. Természetesen a példányt úgy kell beállítani, hogy elegendő erőforrással rendelkezzen (kapcsolati korlátok stb.) ahhoz, hogy egyidejűleg fogadjon minden kapcsolatot és kérést a master és slave float IP-ről. Azaz normál működés közben elegendő határértékkel kell rendelkeznie.

Tuchanka4 (sok rabszolga)

Szerkezet

Már egy másik véglet. Vannak olyan adatbázisok, amelyek sok csak olvasható kérést kapnak (a nagy terhelésű webhelyek tipikus esete). A Tuchanka4 olyan helyzet, amikor három vagy több rabszolga kezelheti az ilyen kéréseket, de még mindig nem túl sok. Nagyon sok rabszolga esetén szükség lesz egy hierarchikus replikációs rendszer feltalálására. Minimális esetben (a képen) mind a két adatközpontban két-két szerver található, mindegyikben egy-egy PostgreSQL-példány.

A séma másik jellemzője, hogy már lehetséges egy szinkron replikáció megszervezése. Úgy van konfigurálva, hogy lehetőség szerint egy másik adatközpontba replikáljon, ne pedig a mesterrel azonos adatközpontban lévő replikára. A masterre és minden slave-re egy lebegő IP-cím mutat. Szerencsére a rabszolgák között valahogy egyensúlyozni kell a kéréseket sql proxypéldául az ügyféloldalon. A különböző típusú ügyfelek különböző típusokat igényelhetnek sql proxy, és csak az ügyfélfejlesztők tudják, hogy kinek melyikre van szüksége. Ez a funkció megvalósítható külső démonnal vagy klienskönyvtárral (kapcsolatkészlettel) stb. Mindez túlmutat a feladatátvételi adatbázis-fürt témakörén (feladatátvétel SQL proxy önállóan is megvalósítható, az ügyfél hibatűrésével együtt).

Tuchanka4 elutasítás

Ha egy adatközpont (azaz két szerver) meghibásodik, a tanú a második mellett szavaz. Ennek eredményeként a második adatközpontban két szerver fut: az egyiken egy master fut, és a mester lebegő IP-cím arra mutat (az írási-olvasási kérések fogadására); a második szerveren pedig egy szolga fut szinkron replikációval, és az egyik slave float IP erre mutat (csak olvasható kérésekre).

Az első dolog, amit meg kell jegyezni, hogy nem minden slave lebegő IP-cím lesz dolgozó, hanem csak egy. És a megfelelő munkához ez szükséges lesz sql proxy minden kérést átirányított az egyetlen fennmaradó lebegő IP-címre; és ha sql proxy nem, akkor a kapcsolat URL-jében felsorolhatja az összes float IP slave-t vesszővel elválasztva. Ebben az esetben a libpq a kapcsolat az első működő IP-re lesz, ez az automatikus tesztelő rendszerben történik. Talán más könyvtárakban, például a JDBC-ben, ez nem fog működni, és szükséges sql proxy. Ez azért van így, mert a szolgák lebegő IP-címei tilos egyidejűleg egy szerveren felemelni, így azok egyenletesen oszlanak el a szolgakiszolgálók között, ha több is fut.

Másodszor: még az adatközpont meghibásodása esetén is megmarad a szinkron replikáció. És még akkor is, ha másodlagos hiba történik, azaz a fennmaradó adatközpontban lévő két szerver közül az egyik meghibásodik, a fürt, bár leállítja a szolgáltatásnyújtást, továbbra is megőrzi az információkat az összes olyan végrehajtott tranzakcióról, amelyekre vonatkozóan a véglegesítést megerősítette. (másodlagos hiba esetén nem lesz veszteség információ).

Tuchanka3 (3 adatközpont)

Szerkezet

Ez egy olyan fürt, ahol három teljesen működő adatközpont van, amelyek mindegyike rendelkezik egy teljesen működő adatbázis-kiszolgálóval. Ebben az esetben határozatképességi eszköz nem szükséges. Az egyik adatközpontban mester, a másik kettőben rabszolgák dolgoznak. A replikáció szinkron, típusa ANY (slave1, slave2), vagyis a kliens véglegesítési visszaigazolást kap, amikor valamelyik slave elsőként válaszol, hogy elfogadta a véglegesítést. Az erőforrásokat egy lebegő IP-cím jelzi a master és kettő a slave számára. A Tuchanka4-el ellentétben mindhárom lebegő IP hibatűrő. A csak olvasható SQL-lekérdezések egyensúlyba hozásához használhatja sql proxy (külön hibatűréssel), vagy rendeljen hozzá egy slave lebegő IP-t a kliensek feléhez, a másik felét pedig a másodikhoz.

Tuchanka3 elutasítás

Ha az egyik adatközpont meghibásodik, kettő marad. Az egyikben a mester és a lebegő IP-cím a mestertől megemelkedik, a másodikban a szolga és mindkét szolga lebegő IP-cím (a példánynak dupla erőforrástartalékkal kell rendelkeznie ahhoz, hogy mindkét szolga lebegő IP-címről fogadjon minden kapcsolatot). Szinkron replikáció a master és a slave között. Ezenkívül a fürt két adatközpont megsemmisülése esetén (ha nem egyidejűleg semmisül meg) elmenti a végrehajtott és megerősített tranzakciók adatait (nem fog adatvesztést okozni).

Úgy döntöttem, hogy nem adok bele részletes leírást a fájlszerkezetről és a telepítésről. Aki játszani akar, mindezt elolvashatja a README-ban. Csak az automatizált tesztelés leírását adom.

Automatikus tesztelő rendszer

A klaszterek hibatűrésének tesztelésére különféle hibák szimulálásával egy automatikus tesztelő rendszert hoztak létre. Szkript alapján elindítva test/failure. A szkript paraméterként veheti fel a tesztelni kívánt fürtök számát. Például ez a parancs:

test/failure 2 3

csak a második és harmadik klasztert teszteli. Ha a paraméterek nincsenek megadva, akkor az összes fürt tesztelésre kerül. Az összes klasztert párhuzamosan tesztelik, és az eredmény megjelenik a tmux panelen. A Tmux dedikált tmux-kiszolgálót használ, így a szkript az alapértelmezett tmux-ból futtatható, ami beágyazott tmux-ot eredményez. Azt javaslom, hogy a terminált nagy ablakban és kis betűtípussal használja. A tesztelés megkezdése előtt az összes virtuális gépet visszaállítja egy pillanatképre a szkript befejezésekor setup.

A terminál oszlopokra van osztva a tesztelt klaszterek száma szerint, alapértelmezés szerint (a képernyőképen) négy van. Az oszlopok tartalmát a Tuchanka2 példáján írom le. A képernyőképen látható panelek számozottak:

1. A tesztstatisztikák itt jelennek meg. Oszlopok:
   • kudarc — a hibát emuláló teszt neve (a szkriptben lévő függvény).
   • reakció — az a számtani átlagidő másodpercben, amely alatt a fürt visszanyerte működését. Mérése a hibát emuláló szkript kezdetétől egészen addig a pillanatig történik, amikor a fürt visszaállítja működését, és képes folytatni a szolgáltatások nyújtását. Ha az idő nagyon rövid, például hat másodperc (ez több rabszolgát tartalmazó klaszterekben történik (Tuchanka3 és Tuchanka4)), ez azt jelenti, hogy a hiba az aszinkron slave-ben volt, és semmilyen módon nem befolyásolta a teljesítményt; nem volt klaszter állapotkapcsolók.
   • eltérés — az érték szórását (pontosságát) mutatja reakció szórás módszerével.
   • számít — hányszor végezték el ezt a vizsgálatot.
2. Egy rövid napló segítségével értékelheti, hogy a fürt jelenleg mit csinál. Megjelenik a művelet iterációs (teszt) száma, időbélyegzője és neve. A túl hosszú futás (> 5 perc) problémát jelez.
3. szív (szív) - aktuális idő. A teljesítmény vizuális értékeléséhez mesterek Az aktuális idő folyamatosan be van írva a táblájába a float IP master segítségével. Ha sikeres, az eredmény megjelenik ezen a panelen.
4. üt (impulzus) - „aktuális idő”, amelyet korábban a forgatókönyv rögzített szív elsajátítani, most olvasni rabszolga float IP-jén keresztül. Lehetővé teszi a szolga és a replikáció teljesítményének vizuális értékelését. A Tuchanka1-ben nincsenek lebegő IP-vel rendelkező szolgák (nincs szolgák, amelyek szolgáltatásokat nyújtanak), de van két példány (DB), ezért itt nem jelenik meg ütÉs szív másodfokon.
5. A fürt állapotának figyelése a segédprogram segítségével pcs mon. Megmutatja az erőforrások szerkezetét, csomópontok közötti elosztását és egyéb hasznos információkat.
6. Itt jelenik meg a fürt minden virtuális gépének rendszerfelügyelete. Több ilyen panel is lehet attól függően, hogy hány virtuális gép van a fürtben. Két grafikon CPU terhelés (a virtuális gépeknek két processzora van), virtuális gép neve, Rendszer terhelés (A terhelési átlag neve, mert átlagolása 5, 10 és 15 perc alatt történik), feldolgozza az adatokat és a memóriafoglalást.
7. A tesztet végrehajtó szkript nyoma. Meghibásodás esetén - a működés hirtelen megszakadása vagy végtelen várakozási ciklus - itt láthatja ennek a viselkedésnek az okát.

A tesztelés két szakaszban történik. Először a szkript minden típusú teszten megy keresztül, és véletlenszerűen kiválaszt egy virtuális gépet, amelyen alkalmazni kívánja ezt a tesztet. Ezután végtelen tesztelési ciklus zajlik, a virtuális gépek és a hiba véletlenszerűen kerülnek kiválasztásra minden alkalommal. A tesztelési szkript (alsó panel) hirtelen leállása vagy valamire való várakozás végtelen ciklusa (> 5 perc végrehajtási idő egy műveletnél, ez látható a nyomon) azt jelzi, hogy ezen a fürtön néhány teszt meghiúsult.

Minden teszt a következő műveletekből áll:

1. Indítson el egy hibát emuláló funkciót.
2. Kész? — várja a klaszter helyreállítását (amikor minden szolgáltatás biztosított).
3. Megjeleníti a fürt helyreállítási időtúllépését (reakció).
4. Rögzít – a klaszter „javítása” folyamatban van. Ezt követően vissza kell térnie teljesen működőképes állapotába, és készen kell állnia a következő meghibásodásra.

Íme a tesztek listája, és leírja, hogy mit csinálnak:

• ForkBomb: Villásbombával létrehozza az „Out of memory” (Memóriafogyás) üzenetet.
• Téren kívül: A merevlemez megtelt. A teszt azonban meglehetősen szimbolikus: a tesztelés során keletkező jelentéktelen terhelés mellett a PostgreSQL általában nem hibázik, ha a merevlemez megtelt.
• Postgres-KILL: megöli a PostgreSQL-t a paranccsal killall -KILL postgres.
• Postgres-STOP: lefagy a PostgreSQL parancs killall -STOP postgres.
• Kikapcsolni: „feszültségmentesíti” a virtuális gépet a paranccsal VBoxManage controlvm "виртуалка" poweroff.
• vissza: túlterheli a virtuális gépet a paranccsal VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: paranccsal felfüggeszti az SBD démont killall -STOP sbd.
• Leállitás: parancsot küld a virtuális gépnek SSH-n keresztül systemctl poweroff, a rendszer kecsesen leáll.
• Leválasztás: hálózati leválasztás, parancs VBoxManage controlvm "виртуалка" setlinkstate1 off.

A tesztelés befejezése a szabványos "kill-window" tmux paranccsal Ctrl-b &, vagy a "detach-client" parancsot Ctrl-b d: ezen a ponton a tesztelés véget ér, a tmux bezárul, a virtuális gépek kikapcsolnak.

A tesztelés során azonosított problémák

• Jelenleg őrkutya démon sbd a megfigyelt démonok leállításán, de nem lefagyasztásán dolgozik. És ennek eredményeként olyan hibák, amelyek csak fagyáshoz vezetnek Corosync и Pacemaker, de nem lóg sbd... Ellenőrzésre Corosync már PR#83 (a GitHubon itt: sbd), elfogadva a szálba mester. Azt ígérték (a PR#83-ban), hogy lesz valami hasonló a Pacemakerhez is, remélem addigra Red Hat 8 megteszi. De az ilyen „hibás működés” spekulatív jellegű, és könnyen szimulálható mesterségesen, például killall -STOP corosync, de soha nem találkozunk a való életben.

• У Pacemaker számára készült verzióban 7 CentOS rosszul beállítva sync_timeout у határozatképességi eszköz, ennek eredményeként ha az egyik csomópont meghibásodott, bizonyos valószínűséggel a második is újraindult, ahová a mesternek költöznie kellett volna. Megnagyobbodás által gyógyult sync_timeout у határozatképességi eszköz telepítés közben (szkriptben setup/setup1). Ezt a módosítást a fejlesztők nem fogadták el Pacemaker, ehelyett azt ígérték, hogy úgy alakítják át az infrastruktúrát (valamilyen meg nem nevezett jövőben), hogy ez az időkorlát automatikusan kiszámításra kerüljön.

• Ha az adatbázis konfigurációja úgy rendelkezik LC_MESSAGES (szöveges üzenetek) Unicode használható, pl. ru_RU.UTF-8, majd indításkor postgres olyan környezetben, ahol a területi beállítás nem UTF-8, mondjuk egy üres környezetben (itt pacemaker+pgsqlms(paf) fut postgres), azután a napló UTF-8 betűk helyett kérdőjeleket fog tartalmazni. A PostgreSQL fejlesztői nem állapodtak meg abban, hogy mit kell tenni ebben az esetben. Ez kerül, telepíteni kell LC_MESSAGES=en_US.UTF-8 adatbázispéldány konfigurálásakor (létrehozásakor).

• Ha a wal_receiver_timeout be van állítva (alapértelmezés szerint 60 mp), akkor a PostgreSQL-STOP teszt során a masteren a tuchanka3 és tuchanka4 klaszterekben A replikáció nem csatlakozik újra az új mesterhez. Ott a replikáció szinkron, így nem csak a slave áll le, hanem az új master is. Megoldható a wal_receiver_timeout=0 beállításával a PostgreSQL konfigurálásakor.

• Alkalmanként replikáció lefagyását figyeltem meg a PostgreSQL-ben a ForkBomb teszt során (memória túlcsordulás). A ForkBomb után előfordulhat, hogy a slave-ek nem csatlakoznak újra az új masterhez. Ezzel csak a tuchanka3 és tuchanka4 klaszterekben találkoztam, ahol a mester lefagyott a szinkron replikáció miatt. A probléma hosszú idő (kb. két óra) után magától megszűnt. Ennek kijavításához további kutatásokra van szükség. A tünetek hasonlóak az előző hibához, amelyet más ok okoz, de ugyanazokkal a következményekkel.

Krogan kép készült DeviantART a szerző engedélyével:

Forrás: will.com