Tiszta infrastruktúra, 4. rész – Magas rendelkezésre állású rendszer két gépből? — Refaktor Magazin

A minap felmerült egy kérdés, sokadjára itt a HUP-on, hogy lehet-e két gépből HA clustert építeni? Noha egy tipikus alkalmazás alá nem lehet, vannak helyezetek amikor igen. Ahhoz, hogy ezt megértsük, bele kell merülnünk a cluster építés elméleti alapjaiba.

A cikk, szokás szerint, a Refaktor Magazinon olvasható.

Hogy ne maradj le, kövess minket Facebookon vagy Twitteren.

( dap | 2016. 09. 08., cs – 12:21 )

"Természetesen STONITH-t csak és kizárólag quorummal együtt használhatunk, különben megtörténhet, hogy a két gép egyszerre lövi ki egymást és mindkét gép leáll. (A STONITH működése általában pár másodpercnyi időt vesz igénybe, ezért ez igen könnyen előfordulhat.)"

Egyszer már volt erről egy csörténk a hupon de mintha elfelejtetted volna. :)

A pár másodperc nagyon durva - többnyire milliszekundumban mérhető a reset késleltetése. Eleve nagyon fontos a redundáns kommunikációs csatorna, így az, hogy két egészséges node elkezdi egymást "nem látni", már eleve extrém ritka. Ha mégis megtörténik, akkor a fencinghez egyiknek elő kell lépni DC-vé, ami annyi késleltetést jelent, hogy a másik kilövi a picsába mire megtörténne. Ez gyakorlatilag kizárja, hogy épp egyszerre lőjjék ki egymást. De a legjobb érv maga az élet, mert sok 2 node-os clustert használok és még SOHA nem fordult elő ez a hiba.

Valósabb forgatóköny, hogy az egyik gép betápja elszáll, leáll a beépített menedzsment, így a fencing device elérhetetlen lesz, ami miatt nem jön össze az automatikus failover. Egy külső fencing device biztosabb. Másik tipikus, hogy fencing után bebootol a node de a hálózata még nem állt fel, így előlép DC-vé és fencingeli a jól működő node-ot. Ezen segít a quorum, de az is elég, ha csak működő hálózattal indítjuk a clustert.

Az, hogy "velem soha nem fordult meg elo" akkor jo erv, ha van backupja es hajlando backupbol visszaallni, ha egyszer megis. Egyebkent nekem annak idejen az elso (!) probalkozasra sikerult osszehozni egy olyat, hogy egyszerre lotte ki egy mast. Persze terheles alatt, amikor a gepek mar amugy is dogrovason voltak.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

Talán a stonith-action nem reset (reboot) volt hanem soft poweroff volt..? Egy soft poweroff + döglődő gép persze hogy nem áll le fél nap alatt sem. IPMI-vel egy reset nem lehet több pár milliszekundumnál, tök mindegy a szerver gyártmánya, aktuális terhelése. A stonith pedig nem a szabályos leállításról szól.

Ez egy elvben is valószínűtlen hibalehetőség, amit a gyakolat csak igazolt.

Nem errol volt szo, hanem arrol, hogy a gepek (az aktiv is) terheles alatt volt, es alig jutott "ereje" elinditani a megfelelo scriptet. Onnantol, hogy elindult a megfelelo program, mar gyorsan vegbe ment a folyamat, de addigra a masik is cselekedett.

Nyilvan, normalis esetben ennek nem szabadna elofordulnia, de hat a HA azokra az esetekre kell, amikor eleve mar rotyog a szar a fazekban es pl. lovik a gepeket.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

Értem, csak továbbra is elhanyagolhatóan valószínűtlennek tartom, hogy abban a pár milliszekundumos ablakban találkozzon két stonith parancs. Mennyit késlekedtek a gépek a stonith-ig a terhelés miatt, mondjuk 60000-120000ms? Az időablak, amíg valóban mindkét reset parancs queue-ban van a BMC-n az legyen max 100ms. Az esélye annak, hogy ez bekövetkezett 600-1200 az 1-hez volt (kissé leegyszerűsítve).

Persze az is felmerül, hogy miért akarták egymást versengve stonith-elni? Ha a problémát az extrém terhelés okozta, akkor bármilyen más HA setup megoldás lett-e volna? Valószínűleg mindenképp lefeküdt volna a szolgáltatás, ergo az adott vasakkal nem létezett jó HA setup arra az esetre. Ha pedig nem lett volna extrém terhelés, akkor nincs esély arra, hogy összeakadjon a stonith, mert a DC mindenképp hamarabb adja ki a parancsot a másik BMC-nek és vége a versenynek. Mindenképp borult a bili.

Volt egy rossz tapasztalatod és messzemenő következtetést vontál le belőle, szerintem nem túl bölcsen. A HA csak a valószínűségét csökkenti a leállásnak, ami soha nem lesz nulla. Elvben sem kell tökéletesnek lennie, nem is lehet, emiatt nem vetném el ezt a felállást elvből amiatt, hogy van benne egy nagyon alacsony kockázat.

Szerintem ezek a "hogyan epitsunk ket gepbol clustert" temak sokkal tobb sebbol vereznek, mint hogy mikor mi lovi le a gepeket. A kerdezoknek az esetek tulnyomo tobbsegeben ket gepre van koltsegvetese, es szerintem sokkal jobban jarnanak, ha elobb osszeraknak az alapokat, mint peldaul hogy legyen normalis, tesztelt backup, rendszeren kivuli monitorozas, veszhelyzeti forgatokonyv. Mert amig ezek nincsenek meg, addig a kerdezo homokra epit varat.

A STONITH/Quorum kerdessel kellene ujfent koroket futni, jopar eve volt. Jelenleg masfele cluster rendszereket epitek, ott eleve nem opcio az, hogy sporoljunk az ilyesmin. Arra emlekszem, hogy eleg konzisztensen sikerult eloidezni azt, hogy lelottek egymast a gepek. A cikkben viszont nem fogok a best practiceknek, es az altalam nagyra tartott szakembereknek ellentmondo dolgokat irni, kezdoknek azt tanacsolva hogy persze, epits ket gepbol clustert, jo lesz az neked.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

Na, közben itt privátban ment a vita oda-vissza egy kollegával hogy mi a helyzet ezzel a kérdéssel. A következőket következtetéseket vontuk le:

  • A dolog akár működhet is (igen, ez a mea culpa rész), de
  • Csak akkor, ha a STONITH egységed kellően gyors. (Nem mernék megesküdni, de amivel annó játszottam, az valamiért tetülassan reagált.)
  • És csak akkor, ha a node vagy komplett leáll, vagy ha újra is indul, nem próbál meg visszajönni a clusterbe, mert attól billegni fog mint az egész libikóka.
  • Ettől függetlenül nem vettem ki egészen a vonatkozó részt a cikkből, csak módosítottam, mert ez a megoldás jónéhány buktatóval rendelkezik, ami egy kezdő esetén a pofonfa rázásával egyenértékű.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

Lehet két gépből is megbízhatóan működő magas rendelkezésre állású rendszert építeni, persze ehhez megfelelő eszközöket is kell választani, ami nem lesz olcsó dolog.
Alapvetően ha egy cégnek valóban HA-ra van szüksége, akkor képesnek kell lennie ennek az árát kitermelni. Amennyiben erre nincs lehetőség, akkor valószínűleg egy megbízható monitoring, DR és BCM megoldások nem fognak olyan jelentős bevétel kiesést okozni ami mindenképpen indokolná a HA -t.

Léteznek technológiák, ahol van RS232/diszk/FC heartbeat. Alapvető, hogy maga a vas is magas rendelkezésre állású legyen(dual táp,adapterek,service processor,cooling, stb..) megfelelő mennyiségű erőforrásokkal. Dual LAN/SAN fabric. Redundáns monitoring és management megoldások.
Ezekkel már lehet valódi megbízható HA rendszereket építeni. Persze ez már nem kisvállalati kategória.

( mrceeka v | 2016. 09. 08., cs – 12:40 )

Windows Failover Clustering esetén a cluster tagjait Quorum Witness-el is kiegészíthetjük a többség biztosítására, ami lehet
-disk (ez a régi SCSI rezervációs sztori)
-fileshare és
-a Windows Server 2016 tech preview-ban cloud witness is.

Üdv,
Marci