Hei Habr! Esitän huomionne artikkelin käännöksen Kirjailija: Andrew Beekhof
Monet ihmiset pitävät kahden solmun klustereista, koska ne vaikuttavat käsitteellisesti yksinkertaisemmilta ja ovat myös 33 % halvempia kuin kolmen solmun klusterit. Vaikka on täysin mahdollista koota hyvä kahdesta solmusta koostuva klusteri, useimmissa tapauksissa harkitsemattomien skenaarioiden vuoksi tällainen konfiguraatio aiheuttaa monia ilmeisiä ongelmia.
Ensimmäinen askel korkean käytettävyyden järjestelmän luomisessa on löytää ja yrittää poistaa yksittäisiä vikakohtia, joita usein lyhennetään SPoF (yksittäinen vika).
On syytä pitää mielessä, että kaikkia mahdollisia seisokkien riskejä on mahdotonta eliminoida missään järjestelmässä. Tämä johtuu siitä, että tyypillinen suojaus riskejä vastaan on ottaa käyttöön redundanssia, mikä lisää järjestelmän monimutkaisuutta ja uusien vikakohtien ilmaantumista. Siksi teemme aluksi kompromissin ja keskitymme yksittäisiin epäonnistumispisteisiin liittyviin tapahtumiin emmekä toisiinsa liittyvien ja siten yhä vähemmän todennäköisempien tapahtumien ketjuihin.
Kompromissit huomioon ottaen emme vain etsi SPoF:ää, vaan myös tasapainotamme riskejä ja seurauksia, minkä seurauksena johtopäätös siitä, mikä on kriittistä ja mikä ei, voi vaihdella jokaisessa käyttöönotossa.
Kaikki eivät tarvitse vaihtoehtoisia sähköntoimittajia itsenäisillä voimalinjoilla. Tosin vainoharhaisuus kostautui ainakin yhdelle asiakkaalle, kun heidän valvontansa havaitsi viallisen muuntajan. Asiakas soitti puheluita yrittäessään hälyttää sähköyhtiötä, kunnes viallinen muuntaja räjähti.
Luonnollinen lähtökohta on, että järjestelmässä on useampi kuin yksi solmu. Ennen kuin järjestelmä voi siirtää palveluita selviytyvään solmuun vian jälkeen, sen on yleensä varmistettava, että siirrettävät palvelut eivät ole aktiivisia muualla.
Kahden solmun klusterilla ei ole haittapuolia, jos vika johtaa siihen, että molemmat solmut palvelevat samaa staattista verkkosivustoa. Asiat kuitenkin muuttuvat, jos seurauksena on, että molemmat osapuolet hallitsevat itsenäisesti jaettua työjonoa tai tarjoavat koordinoimattoman kirjoitusoikeuden replikoituun tietokantaan tai jaettuun tiedostojärjestelmään.
Siksi yksittäisen solmun virheen aiheuttaman tietojen korruption estämiseksi luotamme johonkin ns "dissosiaatio" (miekkailu).
Dissosiaatioperiaate
Dissosiaatioperiaatteen ytimessä on kysymys: voiko kilpaileva solmu aiheuttaa tietojen korruptiota? Jos tietojen vioittuminen on todennäköinen skenaario, hyvä ratkaisu olisi eristää solmu sekä saapuvista pyynnöistä että jatkuvasta tallennustilasta. Yleisin tapa erottaa toisistaan on irrottaa vialliset solmut.
Dissosiaatiomenetelmiä on kaksi luokkaa, joita kutsun suora и epäsuora, mutta niitä voidaan myös kutsua aktiivinen и passiivinen. Suoria menetelmiä ovat selviytyneiden kumppanien toimet, kuten vuorovaikutus IPMI- (Intelligent Platform Management Interface)- tai iLO-laitteen (palvelimien hallintaan ilman fyysistä pääsyä) kanssa, kun taas epäsuorat menetelmät luottavat epäonnistuneeseen laitteeseen. solmu tunnistaa jotenkin, että se on epäterveessä tilassa (tai ainakin estää muita jäseniä toipumasta) ja ilmoittaa tarpeesta katkaista epäonnistuneen solmun yhteys.
Päätösvalta auttaa käytettäessä sekä suoria että epäsuoria menetelmiä.
Suora dissosiaatio
Suoran dissosiaation tapauksessa voimme käyttää päätösvaltaisuutta estämään dissosiaatiokilpailut verkkovian sattuessa.
Koorumin käsitteen avulla järjestelmässä on riittävästi tietoa (jopa ilman yhteyttä vertaisiin), jotta solmut tietävät automaattisesti, pitäisikö niiden aloittaa dissosiaatio ja/tai palautus.
Ilman päätösvaltaisuutta verkostojaon molemmat puolet olettavat oikeutetusti, että toinen puoli on kuollut, ja pyrkivät erottamaan toisen. Pahimmassa tapauksessa molemmat osapuolet onnistuvat sulkemaan koko klusterin. Vaihtoehtoinen skenaario on deathmatch, loputon silmukka solmuja, jotka kutevat, eivät näe vertaisiaan, käynnistävät ne uudelleen ja käynnistävät palautuksen vain uudelleenkäynnistystä varten, kun heidän vertaisensä noudattaa samaa logiikkaa.
Disasosioinnin ongelmana on, että yleisimmin käytetyt laitteet eivät ole käytettävissä samojen vikatapahtumien vuoksi, joihin haluamme kohdistaa palautuksen. Useimmat IPMI- ja iLO-kortit on asennettu niiden hallitsemiin isänteihin, ja ne käyttävät oletusarvoisesti samaa verkkoa, mikä saa kohdeisännät uskomaan, että muut isännät ovat offline-tilassa.
Valitettavasti IPMI- ja iLo-laitteiden toimintaominaisuudet otetaan harvoin huomioon laitteita ostettaessa.
Epäsuora dissosiaatio
Päätösvaltaisuus on tärkeä myös epäsuoran irtautumisen hallinnassa; oikein tehtynä päätösvaltaisuus voi antaa selviytyjille mahdollisuuden olettaa, että kadonneet solmut siirtyvät turvalliseen tilaan tietyn ajan kuluttua.
Tällä kokoonpanolla laitteiston vahtikoiran ajastin nollataan N sekunnin välein, jos päätösvaltaisuus ei katoa. Jos ajastin (yleensä useita N:n kerrannaisia) umpeutuu, laite suorittaa järjettömän virrankatkaisun (ei sammutuksen).
Tämä lähestymistapa on erittäin tehokas, mutta ilman päätösvaltaisuutta klusterin sisällä ei ole tarpeeksi tietoa sen hallitsemiseksi. Ei ole helppoa erottaa verkkokatkoksen ja vertaissolmun vian välillä. Syy tähän on se, että ilman kykyä erottaa kaksi tapausta, sinun on valittava sama toimintatapa molemmissa tapauksissa.
Ongelma yhden tilan valinnassa on se, että ei ole olemassa toimintatapaa, joka maksimoi saatavuuden ja estää tietojen katoamisen.
- Jos päätät olettaa, että vertaissolmu on aktiivinen, mutta itse asiassa epäonnistuu, klusteri pysäyttää tarpeettomasti palvelut, jotka olisivat käynnissä kompensoidakseen epäonnistuneen vertaissolmun palveluiden menetyksen.
- Jos päätät olettaa, että solmu ei toimi, mutta kyseessä oli vain verkkovika ja itse asiassa etäsolmu toimii, parhaimmillaan olet kirjautunut johonkin tulevaan tuloksena olevien tietojoukkojen manuaaliseen täsmäykseen.
Riippumatta siitä, mitä heuristia käytät, on triviaalia luoda vika, joka joko aiheuttaa molempien osapuolten epäonnistumisen tai saa klusterin sulkemaan säilyneet solmut. Koorumin käyttämättä jättäminen todellakin riistää klusterilta yhden sen arsenaalin tehokkaimmista työkaluista.
Jos muuta vaihtoehtoa ei ole, paras tapa on uhrata saatavuus (tässä kirjoittaja viittaa CAP-lauseeseen). Vioittuneiden tietojen korkea saatavuus ei auta ketään, eikä erilaisten tietojoukkojen manuaalinen yhteensovittaminen ole myöskään hauskaa.
Päätösvaltaisuus
Quorum kuulostaa hyvältä, eikö?
Ainoa haittapuoli on, että saadaksesi sen klusteriin, jossa on N jäsentä, sinulla on oltava yhteys N/2+1 jäljellä olevien solmujen välillä. Mikä ei ole mahdollista kahden solmun klusterissa yhden solmun epäonnistumisen jälkeen.
Mikä lopulta vie meidät kahden solmun perusongelmaan:
Koorumissa ei ole järkeä kahdessa solmuklusterissa, ja ilman sitä on mahdotonta määrittää luotettavasti toimintatapaa, joka maksimoi saatavuuden ja estää tietojen katoamisen
Jopa järjestelmässä, jossa kaksi solmua on yhdistetty jakokaapelilla, on mahdotonta erottaa lopullisesti verkkokatkoksen ja toisen solmun vian välillä. Yhden pään poistaminen käytöstä (jonka todennäköisyys on tietysti verrannollinen solmujen väliseen etäisyyteen) riittää kumoamaan kaikki oletukset, että linkin kunto on yhtä suuri kuin kumppanisolmun kunto.
Kahden solmun klusterin saaminen toimimaan
Joskus asiakas ei voi tai ei halua ostaa kolmatta solmua, ja meidän on pakko etsiä vaihtoehtoa.
Vaihtoehto 1 - Kaksoisdissosiaatiomenetelmä
Solmun iLO- tai IPMI-laite edustaa vikakohtaa, koska jos se epäonnistuu, selviytyjät eivät voi käyttää sitä solmun saattamiseksi turvalliseen tilaan. Kolmen tai useamman solmun klusterissa voimme lieventää tätä laskemalla päätösvaltaisuus ja käyttämällä laitteiston vahtikoiraa (epäsuora erotusmekanismi, kuten aiemmin käsiteltiin). Kahden solmun tapauksessa meidän on sen sijaan käytettävä verkkovirranjakeluyksiköitä (PDU).
Epäonnistumisen jälkeen selviytyjä yrittää ensin ottaa yhteyttä ensisijaiseen erotuslaitteeseen (sulautettu iLO tai IPMI). Jos tämä onnistuu, palautuminen jatkuu normaalisti. PDU:ta käytetään vain, jos iLO/IPMI-laite epäonnistuu; jos pääsy onnistuu, palautusta voidaan jatkaa.
Muista sijoittaa PDU eri verkkoon kuin klusteriliikenne, muuten yksittäinen verkkovika estää pääsyn molempiin erotuslaitteisiin ja estää palvelujen palauttamisen.
Tässä voit kysyä - onko PDU yksi vikakohta? Mihin vastaus on, tietysti on.
Jos tämä riski on sinulle merkittävä, et ole yksin: yhdistä molemmat solmut kahteen PDU:hen ja käske klusterointiohjelmistoa käyttämään molempia solmujen virran kytkemisessä ja katkaisussa. Klusteri pysyy nyt aktiivisena, jos yksi PDU kuolee, ja joko toisen PDU:n tai IPMI-laitteen toinen vika vaaditaan palautumisen estämiseksi.
Vaihtoehto 2 - Välimiehen lisääminen
Joissakin skenaarioissa, vaikka kaksoisdissosiaatiomenetelmä on teknisesti mahdollista, se on poliittisesti vaikeaa. Monet yritykset pitävät järjestelmänvalvojien ja sovellusten omistajien välisestä erosta, eivätkä tietoturvatietoiset verkonvalvojat ole aina innostuneita jakamaan PDU-käyttöasetuksia kenenkään kanssa.
Tässä tapauksessa suositeltava vaihtoehto on luoda puolueeton kolmas osapuoli, joka voi täydentää päätösvaltaisuuslaskentaa.
Vian sattuessa solmun on pystyttävä näkemään vertaisensa tai välimiehensä radioaallot palvelujen palauttamiseksi. Arbiter sisältää myös irrotustoiminnon, jos molemmat solmut näkevät välimiehen mutta eivät näe toisiaan.
Tätä vaihtoehtoa on käytettävä yhdessä epäsuoran erotusmenetelmän kanssa, kuten laitteiston vahtikoiran ajastimen kanssa, joka on määritetty tappamaan kone, jos se menettää yhteyden vertais- ja välityssolmuunsa. Siten selviytyjä voi kohtuudella olettaa, että sen vertaissolmu on suojatussa tilassa laitteiston valvontaajastimen umpeutumisen jälkeen.
Käytännön ero välimiehen ja kolmannen solmun välillä on, että välimies vaatii paljon vähemmän resursseja toimiakseen ja voi mahdollisesti palvella useampaa kuin yhtä klusteria.
Vaihtoehto 3 – Inhimillinen tekijä
Viimeinen lähestymistapa on, että selviytyneet jatkavat jo käyttämiensä palveluiden käyttämistä, mutta eivät käynnistä uusia, ennen kuin ongelma ratkeaa itsestään (verkon palautus, solmun uudelleenkäynnistys) tai henkilö ottaa vastuun manuaalisesti vahvistamisesta, että toinen osapuoli on kuollut.
Bonusvaihtoehto
Mainitsinko, että voit lisätä kolmannen solmun?
Kaksi telinettä
Väittelyn vuoksi oletetaan, että olen vakuuttanut sinut kolmannen solmun ansioista, nyt meidän on harkittava solmujen fyysistä järjestelyä. Jos ne sijaitsevat (ja saavat virtaa) samassa telineessä, tämä muodostaa myös SPoF:n, jota ei voida ratkaista lisäämällä toista telinettä.
Jos tämä on yllättävää, mieti, mitä tapahtuisi, jos teline, jossa on kaksi solmua, epäonnistuisi ja kuinka säilynyt solmu erottaisi sen verkkovioista.
Lyhyt vastaus on, että se ei ole mahdollista, ja taas käsittelemme kaikkia ongelmia kahden solmun tapauksessa. Tai selviytyjä:
- jättää päätösvaltaisuuden huomioimatta ja yrittää virheellisesti aloittaa palautuksen verkkokatkosten aikana (kyky erottaa toisistaan on eri juttu ja riippuu siitä, onko PDU mukana ja jakavatko ne virran minkä tahansa telineen kanssa), tai
- kunnioittaa päätösvaltaisuutta ja katkaisee yhteyden ennenaikaisesti, kun sen vertaissolmu epäonnistuu
Joka tapauksessa kaksi telinettä ei ole parempi kuin yksi, ja solmujen on joko saatava itsenäisiä virtalähteitä tai ne on jaettava kolmeen (tai useampaan, riippuen kuinka monta solmua sinulla on) telineeseen.
Kaksi datakeskusta
Tässä vaiheessa lukijat, jotka eivät enää pelkää riskejä, saattavat haluta harkita katastrofista palautumista. Mitä tapahtuu, kun asteroidi osuu samaan palvelinkeskukseen, jossa kolme solmua on jaettu kolmeen eri telineeseen? Ilmeisesti huonoja asioita, mutta tarpeistasi riippuen toisen datakeskuksen lisääminen ei välttämättä riitä.
Oikein tehtynä toinen palvelinkeskus tarjoaa sinulle (ja kohtuudella) ajantasaisen ja johdonmukaisen kopion palveluistasi ja niiden tiedoista. Kuten kahden solmun ja kahden telineen skenaarioissa, järjestelmässä ei kuitenkaan ole tarpeeksi tietoa maksimaalisen käytettävyyden varmistamiseksi ja korruption (tai tietojoukkoerojen) estämiseksi. Jopa kolmella solmulla (tai telineellä) niiden jakaminen vain kahteen datakeskukseen jättää järjestelmän kykenemättömäksi tekemään oikeaa päätöstä (nyt paljon todennäköisemmin) tapahtumassa, jossa kumpikaan osapuoli ei pysty kommunikoimaan.
Tämä ei tarkoita, etteikö kahden datakeskuksen ratkaisu olisi koskaan sopiva. Yritykset haluavat usein henkilön olevan tietoinen ennen kuin hän ottaa poikkeuksellisen askeleen siirtyäkseen varatietokeskukseen. Muista vain, että jos haluat automatisoida katkon, tarvitset joko kolmannen datakeskuksen, jotta päätösvaltaisuus olisi järkevä (joko suoraan tai välimiehen kautta), tai voit löytää tavan sulkea luotettavasti koko data. keskusta.
Lähde: will.com