abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 16:22 | IT novinky

CEO Intelu Brian Krzanich rezignoval (tisková zpráva). Oficiálním důvodem je "vztah na pracovišti". S okamžitou platností se dočasným CEO stal Robert Swan.

Ladislav Hagara | Komentářů: 0
dnes 14:11 | Komunita

Konsorcium Linux Foundation ve spolupráci s kariérním portálem Dice.com zveřejnilo 2018 Open Source Jobs Report. Poptávka po odbornících na open source neustále roste.

Ladislav Hagara | Komentářů: 1
dnes 12:44 | Zajímavý článek

Na stránkách linuxové distribuce Ubuntu Studio byla publikována příručka Ubuntu Studio Audio Handbook věnována vytváření, nahrávaní a úpravě zvuků a hudby nejenom v Ubuntu Studiu. Jedná se o živý dokument editovatelný na jejich wiki.

Ladislav Hagara | Komentářů: 0
dnes 12:11 | Zajímavý projekt

Společnost Red Hat koupila na konci ledna společnost CoreOS stojící mimo jiné za odlehčenou linuxovou distribucí optimalizovanou pro běh kontejnerů Container Linux. Matthew Miller, vedoucí projektu Fedora, představil v článku na Fedora Magazine nový podprojekt Fedory s názvem Fedora CoreOS. Fedora CoreOS má být to nejlepší z Container Linuxu a Fedora Atomic Hostu. Podrobnosti v často kladených otázkách (FAQ) a v diskusním fóru.

Ladislav Hagara | Komentářů: 0
dnes 08:00 | Nová verze

Po více než devíti měsících vývoje od vydání verze 11.0 byla vydána verze 12.0 zvukového serveru PulseAudio. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 9
včera 20:00 | Upozornění

Výbor pro právní záležitosti Evropského parlamentu (JURI) dnes přijal své stanovisko ke kontroverzní novele směrnice, která v EU upravuje autorské právo v online prostředí (Pro: 14, Proti: 9, Zdrželo se: 2). Další kolo legislativního procesu proběhne na začátku července.

Ladislav Hagara | Komentářů: 29
19.6. 19:55 | Zajímavý článek

Byly zveřejněny (pdf) podrobnosti o kritické bezpečnostní chybě CVE-2017-12542 v HPE iLO 4 (Integrated Lights-Out), tj. v proprietárním řešení společnosti Hewlett Packard Enterprise pro vzdálenou správu jejich serverů. Bezpečnostní chyba zneužitelná k obejití autentizace a k vzdálenému spuštění libovolného kódu byla opravena již v květnu loňského roku ve verzi 2.53.

Ladislav Hagara | Komentářů: 15
19.6. 17:55 | Zajímavý projekt

CSIRT.CZ informuje o CTF (Capture the Flag) platformě ZSIS CTF s úlohami pro procvičování praktických dovedností z oblasti kybernetické bezpečnosti a upozorňuje na soutěž Google Capture the Flag 2018, kde je možné vyhrát zajímavé ceny.

Ladislav Hagara | Komentářů: 0
19.6. 17:00 | Komunita

Byly zveřejněny prezentace a videozáznamy přednášek z prvního československého setkání síťových operátorů CSNOG konaného 11. a 12. června v Brně a semináře IPv6 2018 uskutečněného 6. června v Praze.

Ladislav Hagara | Komentářů: 0
19.6. 16:11 | Komunita

Svobodný unixový operační systém FreeBSD slaví 25 let. Přesně před pětadvaceti lety, tj. 19. června 1993, byl vybrán název FreeBSD.

Ladislav Hagara | Komentářů: 0
Jak čtete delší texty z webových stránek?
 (77%)
 (23%)
 (4%)
 (7%)
 (3%)
 (11%)
Celkem 231 hlasů
 Komentářů: 39, poslední dnes 17:44
    Rozcestník

    Dotaz: Linux cluster - stonith / fencing

    28.2. 13:40 Odpadlik
    Linux cluster - stonith / fencing
    Přečteno: 339×
    Není tu náhodou někdo kdo rozumí clusterům, konkrétně pacemaker/stonith/fencing? Docela rád bych věděl, proč je třeba u HA clusteru s GFS2 nutno toto konfigurovat...

    Řešení dotazu:


    Odpovědi

    28.2. 14:40 DarkKnight | skóre: 25
    Rozbalit Rozbalit vše Re: Linux cluster - stonith / fencing
    Co udela cluster, kdyz se spojeni prerusi mezi jednotlivymi uzly? Da se predpokladat, ze i kdyz ma node minoritni quorum, tak porad na nej muze nekdo zkusit zapsat, cimz by doslo k nekonzistenci dat (ktera jsou platna, na prvni casti rozpadleho clusteru, nebo na druhe?).

    Z tohoto duvodu se prave aplikuje STONITH - pokud nema ta cast rozpadleho clusteru majoritni quorum, zabij ho (neresi problemy, kdy se rozpoji vsechny uzly najednou). To je i duvod, proc se u dvouuzlovych clusteru (velmi pitomy napad - kvuli split-brainu) STONITH vypina.
    28.2. 14:54 Odpadlik
    Rozbalit Rozbalit vše Re: Linux cluster - stonith / fencing
    To je sice pravda, ale v případě HA clusteru je to k ničemu. GFS2 je sdílený FS - tzn tam se předpokládá, že resource užívají oba uzly zároveň. Tj můj dotaz to neodpovídá.
    28.2. 16:44 Lyco | skóre: 12 | blog: Lyco
    Rozbalit Rozbalit vše Re: Linux cluster - stonith / fencing
    GFS2 sice může být sdílený FS, ale to ještě neznamená, že je schopný dlouhodobě bezpečného provozu bez spojení mezi jednotlivými uzly. Podle dokumentace to vypadá, že nody které ztratí quorum přestanou pracovat, ale nenašel jsem co to přesně znamená - pokud zůstanou read-only, můžou aplikace vidět zastaralá data, což je problém pokud někdo (klienti aplikací s daty na GFS2 a pod.) vidí data z obou stran clusteru. I pokud by tam tenhle problém nebyl, je tu pořád riziko chyb v programu, v částech kter jsou míň otestované než to co běží v normálním provozu.

    Navíc, to že server neodpovídá před timeoutem (a to je obvykle jediná věc kterou o něm ostatní můžou zjistit) neznamená, že nic nedělá. Krom toho, že může prostě pracovat pomalu nebo nedělat nic, může být taky vážně rozbitý a aktivně ničit data. (To jsem reálně viděl, naštěstí v nekritické věci - chyba v kernelu způsobila, že MySQL server spadl, ale před tím do logu zapsal několik MB nulových bytů. Kdyby to byl binlog, tak rozbije repliku.) V případě, že se o něm ví, že neodpovídá, je nejjistější ho prostě zabít.

    Obecně, většina distribuovaných systémů předpokládá, že se věci pokazí jen tak, že něco přestane pracovat (fail-stop model): packet se ztratí nebo opozdí, server se restartuje nebo je pomalý. Takové systémy se katastrofálně rozbijí, pokud porucha způsobí něco vážnějšího. STONITH je pragmatické řešení: bylo by příliš složité a pomalé zabezpečit se proti všem typům chyb, tak zkusíme zajistit, že nefunkční server vždycky přestane pracovat, a zajistíme to co nejdřív.

    Viz také https://en.wikipedia.org/wiki/Byzantine_fault_tolerance
    Příspěvek se rázem stává až o 37,5 % pravdivější, je-li pod ním napsáno reálné jméno.
    Řešení 1× (Aleš Kapica)
    28.2. 18:08 DarkKnight | skóre: 25
    Rozbalit Rozbalit vše Re: Linux cluster - stonith / fencing
    Ale odpovida. To co pisu neznamena, ze nemuzes zapisovat na oba uzly najednou. Ale pokud dojde k chybe (to je to dulezite) - tj. treba se prerusi konektivita mezi jednim uzlem a zbytkem clusteru, aplikace najednou zacne pracovat se stejnym souborem na kazdem uzlu a problem je na svete. Ktera verze zmeny je ta spravna? Obecne nelze predpokladat, ze jedna je spravna a druha je spatna - proto STONITH jeden uzel zabije (ten, ktery nema majoritni quorum) a je zajistene, ze na ten uzel uz nikdo nezapise.

    A znovu pripominam, ze dvouuzlovy cluster nedava pro data-sensitive aplikace (FS, DB, aj.) smysl - neni to HA.
    1.3. 08:55 Odpadlik
    Rozbalit Rozbalit vše Re: Linux cluster - stonith / fencing
    Ale to je přeci běžný problém který se řeší zámkem. Jako rozuměl bych kdyby se v tomto případku STONITH definovalo na dlm démon nutný k provozu GFS či síťovou konektivitu. Ono se to ale řeší přes samotné blokové zařízení:

    pcs stonith create iscsi-stonith-device fence_scsi devices=/dev/sdb meta provides=unfencing

    ... což mi opravdu nedává žádný smysl. Co tento příkaz vlastně udělá? Podotýkám že nezajistí exkluzivní přístup k blokovému zařízení /dev/sdb - tak co tedy zajistí?
    1.3. 13:27 Lyco | skóre: 12 | blog: Lyco
    Rozbalit Rozbalit vše Re: Linux cluster - stonith / fencing
    Split-brain v 2nodovém clusteru je problém, který zámkem nelze vyřešit. Buď dojde k deadlocku (když zámek nemá timeout a některý node umře natrvalo), nebo k nekonzistenci dat (pokud je výpadek komunikace - způsobený např. přetížením - delší než timeout zámku, a oba nody zapíšou různá data). Klasický zámek je v reálné (tj. nespolehlivé) síti neřešitelný problém.

    Ten iscsi device ve tvém stonithu je pravděpodobně quorum disk. To je takový divný hack - cluster dvou nodů totiž nedokáže při ztrátě spojení mezi nimi rozhodnout, kdo má zůstat naživu, a nody by se vzájemně zabily. Proto oba servery zkusí kontaktovat třetí node - v tomhle případě disk připojený SCSI protokolem - a zamknout ho. SCSI protokol garantuje že uspěje maximálně jeden node, ten se to dozví a zabije ten druhý který zámek nedostal. V podstatě má takový cluster 3 nody, ale jeden z nich slouží jenom k rozhodování "sporů".

    K tomuhle účelu se často používá přímo ta sdílená storage na které jsou data, protože nechceme, aby node který ztratil spojení se storagí byl ten, který přežil stonith.

    (Tady poznamenávám, že quorum diskům sám moc nerozumím, takže možná jsou detaily špatně.)
    Příspěvek se rázem stává až o 37,5 % pravdivější, je-li pod ním napsáno reálné jméno.
    2.3. 09:47 Odpadlik
    Rozbalit Rozbalit vše Re: Linux cluster - stonith / fencing
    No je to skutečně o zámcích, takže máte pravdu:

    https://access.redhat.com/solutions/15575

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.