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 14:33 | Nová verze

Byla vydána nová verze 1.30 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
dnes 14:22 | Nová verze

Deset dnů po představení beta verze byla vydána stabilní verze Steam Linku pro Raspberry Pi umožňující streamovat hry ve službě Steam z počítače na televizní obrazovku.

Ladislav Hagara | Komentářů: 1
včera 20:00 | Nová verze

Byla vydána (YouTube) verze 2018.3 multiplatformního herního enginu Unity (Wikipedie). Přehled novinek i s videoukázkami v příspěvku na blogu a v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
včera 19:33 | Nová verze

Byla vydána verze 18.12.0 KDE Aplikací (KDE Applications). Přehled novinek v kompletním seznamu změn a na stránce s dalšími informacemi. Správce souborů Dolphin umí nově například zobrazovat náhledy dokumentů vytvořených v LibreOffice a aplikací ve formátu AppImage. Konsole plně podporuje obrázkové znaky emoji. V Okularu lze k pdf souborům přidávat poznámky.

Ladislav Hagara | Komentářů: 3
včera 17:11 | Nová verze

Byla vydána nová stabilní verze 2.2 (2.2.1388.34) webového prohlížeče Vivaldi (Wikipedie). Z novinek vývojáři zdůrazňují například vylepšení správy listů - vybrané listy lze uložit jako relaci, možnost zobrazení klávesových zkratek určených webovou stránkou nebo možnost přehrávání videí v režimu obrazu v obraze. Nejnovější Vivaldi je postaveno na Chromiu 71.0.3578.85.

Ladislav Hagara | Komentářů: 6
včera 14:22 | Nová verze

Po 4 měsících vývoje od vydání verze 3.0.0 byla vydána nová verze 3.1.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 189 vývojářů. Provedeno bylo více než 1 900 commitů. Přehled úprav a nových vlastností v seznamu změn.

Ladislav Hagara | Komentářů: 0
včera 01:32 | Nová verze

Letos bylo v komunitě Mageia hodně změn. Po volbě nových vedoucích přišla velká aktualizace a krátce na to udržovací verze 6.1. 7.12., dle plánu, vyšla Mageia s číslem 7 v její první beta verzi. Chyby můžete hlásit v bugzille. Chyby v českých překladech pak na fóru české komunity.

Joelp | Komentářů: 0
včera 00:11 | Zajímavý projekt

Kvůli rychlejšímu vývojovému cyklu byla přemístěna Cinelerra-gg. Cinelerra-gg je fork Cinelerry-hv. Některé rozdíly forků popisuje sám hlavní vývojář William Morrow (aka GoodGuy). Není zde popsán i fork Lumiera, zřejmě kvůli zatím nepoužitelnému stavu.

… více »
D81 | Komentářů: 0
12.12. 19:11 | Nová verze

Do aplikace pro instant messaging Telegram (Wikipedie) lze nově nahrát češtinu. Více v příspěvku na blogu Telegramu.

Ladislav Hagara | Komentářů: 7
12.12. 10:55 | Nová verze

Jean-Baptiste Kempf, prezident neziskové organizace VideoLAN stojící za svobodným multiplatformním multimediálním přehrávačem a frameworkem VLC, oznámil v příspěvku na svém blogu vydání první oficiální verze 0.1.0 v říjnu představeného dekodéru svobodného videoformátu AV1 (AOMedia Video 1) s názvem dav1d (Dav1d is an AV1 Decoder). Jedná se o alternativu k referenčnímu dekodéru libaom. Kódový název dav1da verze 0.1.0 je Gazelle.

Ladislav Hagara | Komentářů: 3
Chystáte se přejít na Wayland na „desktopu“?
 (25%)
 (6%)
 (12%)
 (31%)
 (26%)
Celkem 124 hlasů
 Komentářů: 18, poslední dnes 10:05
Rozcestník

Dotaz: Linux cluster - stonith / fencing

28.2. 13:40 Odpadlik
Linux cluster - stonith / fencing
Přečteno: 354×
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: 26
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.
28.2. 18:08 DarkKnight | skóre: 26
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.