Názor k článku Cluster na Linuxu: vysoká dostupnost s RHEL a deriváty od obenes - Dobrý den, díky za komentář a omlouvám se...

  • Článek je starý, nové názory již nelze přidávat.
  • 14. 8. 2017 17:52

    obenes

    Dobrý den, díky za komentář a omlouvám se za pozdní reakci.

    K pár bodům:

    Vícekrát jsem na něm viděl ztrátu informace o konfiguraci clusteru nebo hůře, ztrátu dat při splitbrain nebo i "běžné" relokaci

    ===> Tohle by mě zajímalo. Byl otevřen case na Red Hat podporu? Co Vám tam řekli? Split brain je poměrně těžko dosažitelný stav, pokud je cluster správně konfigurován (viz níže)

    O něčem vypovídá i fakt, že podobné situace se vyskytují i na připravených labech.

    ===> Nejsem si jistý, kam tím směřujete. Můžete to prosím říct jinak?

    "druhořadá" metoda fencingu, tedy např SCSI rezervace

    ===> Druhořadá proto, že stejně musíme zajistit reboot nodu. Jinak pokud storage SCSI 3 rezervace podporuje, a fence device je správně nastavena, pak SCSI fencing zpravidla účinně a okamžitě zamezí danému nodu přistupovat k datům

    STONITH má zásadní problémy
    - race condition (servery se mohou zastřelit navzájem, zvlášť pokud používáte KVM agenty, a pak leží všechno)

    ===> Z tohoto důvodu se používá parametr delay na jedné z fence devices. Pokud by měla nastat situace, kdy se oba nody chtějí fencnout zároveň (ve stejnou chvíli), jedna bude fencovat dříve než ta druhá -- a split brain nenastane

    - žádný sync nebo nějaké podobé řešení nacachovaných filesystem (meta) dat, a tedy větší riziko ztráty.

    ===> Toto pozjíšťuji, nedokážu teď odpovědět

    - Nod, který nemá co dělat (a tedy je vlastně méně provozně důležitý) má větší pravděpodobnost, že "vystřelí dřív". Když se taky nudí a celé dny si jen hraje s bouchačkou...

    ===> Ńetuším, co tím chcete říct... Zkuste znovu jinými slovy prosím

    - problém se zvětšuje s počtem nodů v clusteru.

    ===> Který problém? Předpokládám, že se odvoláváte na to "vystřelení"?

    Ostatní clustering řešení fencing řeší kombinací externí autority a mechanismu v kernelu jednotlivých nodů

    ===> Externí autorita může být quorum disk (quorum device od 7.4) a mechanismus v kernelu je využíván při SBD -- storage based death (sbd poison-pill fencing via block-device).

    https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/High_Availability_Add-On_Reference/index.html#s1-ov-newfeatures-7.4-HAAR

    https://access.redhat.com/articles/2943361

    Asi bychom potřebovali probrat konrétní situace a udělat RCA na základě logů a daných konfigurací.

    Díky, jsou to připomínky k věci.