Názory k článku Cluster na Linuxu: vysoce dostupný web pomocí httpd
-
Na základní HA je peacemaker kanón na vrabce. Úplně by stačil samotný heartbeat bez peacemakeru, keepalived nebo třeba ucarp.
Chápu, že tohle se hezky čte a vypadá to zajímavě a sofistikovaně, ale peacemaker je pěkně zrádná mrcha a pokud někdo bez hlubší znalosti a zkušenosti peacemakeru tohle nekde nakonfiguruje podle návodu v článku, tak až mu to jednou přestane fungovat, tak to pravděpodobně nebude schopen v rozumném čase vyřešit.
-
Ray (neregistrovaný)
Zdar vespolek, mohu potvrdit, že se dokonce pro některé věci vyplatí upravit/napsat něco malého, protože v případě průseru odhalit strom závislostí se rozumně nedá, ikdyž člověk jakš takš ví, která bije. Od jisté doby mne právě děsí tyhle služby - ve smyslu závislostí. Funguje to skvěle, až do prvního "jiného" průseru. U mne ten jistý okmažik byl, když jsem ztrávil 2 dny života hledním chyby, kdy se cluster začal "náhodně" lockovat při IO operacích. Někdy se rozjel, někdy se něco sestřelilo, ... Logy prázdné, veškeré síťové prvky OK (10G karty po 2), ... přesto se to shazovalo. Nakonec šlo o to, že jeden ze storage backup strojů měl (z důvody SW chyby) menší rychlost než by měl mýt (zapisoval jen pár stovek MB/sec, zatímco hlavní měli řádově víc). To lehce zmátlo DRDB (byť zůstavalo v klidu), posléze iSCSI, na tím pěkně LVM se svejma cachema... a celá kaskáda jela... Šlo tedy jen o to, jak cache dokáže překrýt (časově) rozdíl rychlostí. A protože to má par desitek GB RAM, tak to v zásadě "fungovalo dobře". Skoro pořád :) Jasně, zpětně člověk už ví, proč se nody sestřelovaly, že by bylo lepší přepnout DRDB do jiného sync módu na úkor rychlosti (byl by pomalej od začatku a problém by se projevil hned), dlouhodobě otestovat rychlost (nestačí pustit dd na 20 sekund, což vždycky stačilo :) etc etc. A to jsou právě ty zkušnosti k nezaplacení podtržené šílenou závislostí, které si už nezadá s kdysi slavným "DLL hell" od maloměkého :) A nikde se nedá najít jednoduše "původce" chyby. Všechno samo o sobě funguje, logy prázdné, ... Podrtženo sečteno, v tomto konkretním případě několik písmen v DRDB konfiguráku a problem by nebyl i rychlost toho "pomalého" backupu je dostatečná... A ten "doporučenej" mód syncu byl samosebou podle jejich tutorialu, jako rozumná kombinace mezi rychlostí/bezpečností.
Za ty léta si linux pomalu začíná žít vlastní jaderný život, vzhlekem k počtu ekosystémů a zavislostí, které přibývají a přibývají. A relativně nedávno někdo hodil do ty hromady hnoje pěkný vidle a máme ještě o další komplexní úroveň závislostí navíc :) No flame(d).
R.
-
Ray (neregistrovaný)
Jestli to takhle (myšleno obecně) s linuchem půjde dál, tak nám ani nic jiného nezbude. Fakt je, že s relativně obyčejnýma strojema (já tu mám třebas vesměs HP s 25 diskama a k tomu 2x RAID kartu,2x10G optika) se dájí udělat pěkně fungující i rychlé věci (za par drobných, víc stojí ten měsíc práce to pořádně udělat, pak už je to jen dd :). V porovnání s iSCSI s hot zálohou to je cca o řád levnější +- (už jen protože se to prakticky musí koupit nové). Bohužel, jak systémy bobtnají (IMHO úplně zbytečně, prostě jen protože bobtnají i korporace, co mu "vládnou" - taková demokracie v praxi) tak exponencíálně roste složitost... Ne toho, jak to udělat/nastavit, to umí každej trotl s copy/paste do terminálu. Ale složitost opravdu *vědět* co ty věci (u)dělají. A to už je fakt asi lepší vzít black-box a věřit výrobci, že to ma uvnitř nadrátované dobře. A když ne... Kdo obnovoval spadnutej HW RAID, protože žádnej kompatibilní po ruce nebyl (nebo za týden a tak) ví o čem mluvím. Není sice složitý, napsat si malej program, co skenuje sektor po sektoru, hledá začátek FW a jak to řadič rozházel. Ale toho sraní... Navíc se to dá tak pro RAID0/1. Jak jde čas, tak na otázku, "co se stane když" čím dál častěji odpovídám "asi" neb bůch ví, jak si to zrovna všechno "popovídá" jak má.
Nakonec je stejně asi jednodušší cesta tohle řešit po SW stránce (na úrovni aapz) a neztrácet čas clusterováním v pravém slova významu. Když to jde.
Jednou nám takovej pěknej switch od Cisca přestal šířit broadcasty. Ale ne úplně. Tak na půl :) Několik dní v prdeli, než se jeden dohrabe co se vlastně děje. Samo log čistej... Případně nedávno juniper a novej FW a multicasty. Může to všechyno být nastavené skvěle, když to pak sejme nějaká takovádle debilita úplně mimo. A switch za 100K mít hozenej bokem pro strejdu příhodu ? To se stane, až po tom, co nějakej bezporuchovej se skvělým SLA odejde :/
R.
-
. . (neregistrovaný)
mám stejný názor, dříve jsem sám zajistit provoz "celé" servovny, dnes stěží stačím na jedinou službu. SW, který se píše lze poměrně snadno automaticky testovat, podrobovat různým kontrolním mechanismům a být si jistý, že to funguje, debugování SW je lahoda. Naproti tomu HW je čím dál větší magie, teď několik dní zabitých díky HP smart array, vadný kus, diagnostika nic neodhalila, pomohla výměna, ale debugovat se to nedá, kdyby to nebylo tak těžké, prohodím to oknem.
Ve srovnání s třeba IBM Z jsou linux servery hračky pro děti, a to mluvím jako člověk, kterého linux a servery živí :).
-
j (neregistrovaný)
ad ... diagnostika nic neodhalila, prazdny logy, ... to je vsehno zapricineno vyhradne tim, ze k patlalum ktery pisou SW dneska proste navic prisli patlalove, ktery navrhujou HW.
Viz napriklad hromady veci na tema usetrime cent za kontrolku. Takze misto aby clovek aspon vedel, ze to "neco" dela, prosychr nevi uz ani to, jestli je to vubec zaply.
-
fronz (neregistrovaný)
nj "zlate" DBRD , si pamatam ako nam na produkci po nejakom nw outage preplacla secondary strana (ktora vypadla zo syncu) preplacla primary...
Celkovo sme tento pacemaker "HA" volali haha cluster , neda sa porovnavat so SG serviceguardom (jasne haha je zadarmo, takze sa setri)a uplne idealne SG na hpux , ale ten je zial mrtvy a IA tiez...takze uz sa aj do korporatu a mission critical veci dost dlho tlaci lunex coz je imo pekne naprd (a to podotykam ze ani nerobim platformaka)
stary dobry hpux :(
-
karlik (neregistrovaný)
Původně jsem o něčem takovém uvažoval, v CentOS je myslím Pacemaker/Corosync.
Webové rozhraní s klikátky a další kýbl podpůrných programů pro funkci. :-)
Skončil jsem na ucarp, jeden program, jednoduchá konfigurace v textovém souboru.
Pro cluster s 30 PC bych to možná zkusil, ale pro dva PC master-slave... -
Dobrý den,
díky za reakci.
"peacemaker je pěkně zrádná mrcha a pokud někdo bez hlubší znalosti a zkušenosti peacemakeru tohle nekde nakonfiguruje podle návodu v článku, tak až mu to jednou přestane fungovat, tak to pravděpodobně nebude schopen v rozumném čase vyřešit."
Nechci se pouštět do zbytečné diskuze o tom, jestli je pacemaker "pěkně zrádná mrcha", nebo "kanón na vrabce", nebo ne. Evidentně s pacemakerem máte špatné zkušenosti a podle toho reagujete. Osobně mi pacemaker přijde jako nástroj snadno ovladatelný pomocí
pcspříkazů.Výchozí nastavení pacemakeru a corosyncu je pro méně náročné nasazení většinou dostačující. Pro doladění nastavení na míru zákaznííkovu prostředí stačí dost často změnit jen málo parametrů. Jako u každého nástroje, i v případě pacemakeru je dobré vědět, co měníte, pokud to měníte. Ale nemyslím si, že pro základní doladění potřebujete hluboké znalosti pacemakeru. Navíc tu platí: pokud si nevíte rady, pošlete to supportu...
Otázka, která mě napadla při čtení Vašeho příspěvku, je: "až mu to jednou přestane fungovat" -> proč by to mělo přestat fungovat?
Pokud "to přestane fungovat", pak se pravděpodobně něco změnilo v infrastruktuře, nebo cluster nebyl dostatečně otestován, nebo něco bylo změněno v nastavení (což znamená, že jsme měli důvod něco měnit a že bychom měli vědět, co měníme a jak se změna projeví). Je zbytečné se hypoteticky dohadovat o detailech, co v kterém prostředí kdy "přestalo fungovat". Bylo by potřeba posuzovat tyto případy vzhledem k prostředí a tehdejší situaci (obvykle je ve hře více proměnných).
Není možné v tomto seriálu podat přesný návod na konkrétní prostředí, kam se cluster nasadí. V jednom bude třeba upravit timeouty pro resource operace, jinde zvýšit token timeout corosyncu. Zdaleka ne všechny clusteru budou postaveny na KVM, spousta bude využívat jiné než iSCSI úložiště.... Cílem seriálu je především praktická ukázka toho, jak HA na RHEL a Fedoře/CentOS funguje.
A promiňte, ale neodpustím si jednu hnidopišskou: je to pacemaker, ne peacemaker.
Přijde mi, že tato diskuze má náběh na flame, proto bych to s dovolením zastavil tady. Pokud máte problémy s pacemakerem na SUSE nebo RHEL, tiket na podporu obvykle pomůže.
Díky, že seriál čtete a reagujete na něj.
ČLÁNKY DO MAILU