Szegény ember HA-ja, ötletelés

Linux-haladó

Sziasztok,

Adott egy LAMP szerver rajta egy wp oldallal. Felmerült, h jó lenne, ha lenne valamiféle HA-t biztosítani.
A következőre gondoltam (egyenlőre tervezés alatt). A 2 szervernek 100M kapcsolata van, de nem LAN-on.
A Mysql master-master replikációval lenne szinkronban, míg a htdocs könyvtár vagy Ceph, GlusterFS vagy drbd (ki kell még próbálnom őket)
A domain a cloudflare nél van és úgy képzeltem el, hogy a másodlagos szerver monitorozza (nagios) az elsődlegest, majd ha 1 percen túl is elérhetetlen, akkor a cludflare api-n keresztül felül átírja a domain ip-jét. Visszafele már kézzel történne az ip visszaállítása.
Mi a véleményetek erről? Van-e valakinek hasonlóban tapasztalata? Hol lehetnek buktatók?

Köszi,
Szabek

  • 5676 megtekintés

( freeoli v | 2016. 09. 05., h – 11:48 )

A legfontosabb, mennyire keletkeznek itt új adatok? Mennyi a keret? Van-e alatta hypervisor?

Van egy nagy rakat fizetős HA-t megvalósító eszköz ami tökéletesen képes erre. Én az ARCserver RHA-t ismerem, azzal fizikai gépet lehet HA-ba helyezni egy virtualizálttal, ha támogatott az OS.

ilyen egyszerűen nem megy, pontosan az a baj, hogy míg élőbeszédben ez ilyenkor azt érted, hogy lehet fizetős, vagy nem fizetős is, addig ha azt írod hogy ! fizetős, az azt jelenti, hogy nem fizetős.

Ettől még én is ezt írtam volna, mert ilyenkor az ai kikövetkezteti :) csak trollkodtam :)

míg élőbeszédben ez ilyenkor azt érted, hogy lehet fizetős, vagy nem fizetős is, addig ha azt írod hogy ! fizetős, az azt jelenti, hogy nem fizetős.

Mondjuk én pont azt akartam írni hogy nem fizetős. :) mármint a jobboldalra :) Nem volt célom azt leírni, hogy lehet fizetős is meg nem is, csak egyszerűen azt, hogy nem egyenlő a nem fizetőssel.

Ettől még én is ezt írtam volna, mert ilyenkor az ai kikövetkezteti :) csak trollkodtam :)

:)

de a kettő mögött ugyanaz a köznyelvi jelentés van: ha nem egyenlő azzal, hogy nem fizetős, akkor nem biztos hogy fizetős, vagyis attól még hogy opensource, lehet fizetős is meg nem fizetős is. gondolom igazából azt akartad mondani, hogy irreleváns.

és egyébként nyilván amit írtam, az is csak addig igaz, amíg boolok vannak, ahogy mondjuk, int már nyilván nem :)

A képlet mindenképpen rossz, hiszen diszjunkt fogalmakat hasonlít össze. ;)
Alaptételek:
- Ha valamire azt mondják ingyen van, az biztosan átverés.
- Az az ingyenes opensource, amibe pl. az IBM igen gyakran millió dollárokat nyom bele. :)
- Ha nem vásárolsz pénzért, akkor esetleg a saját munkádat kell belefeccölni. Az meg ingyenes! Vagy nem. Szóval mennyi is pontosan a költség?

Inkább a költséget kellene összevetni:
költség(opensource) {reláció} költség(nem opensource)
Az összes egyéb összehasonítás megegyezik a "Ha a bolha összes lábát kitépem akkor megsüketül." állitás bölcsességével. Ezért lehet és érdemes is rugózni rajta.

Egész pontosan a teljes költséget. Épp szoftvert akarok(*) vásárolni, és már-már a sírás kerülget az autista és/vagy ordítóan görény oldalaktól (pl. adjam meg az adataimat az árajánlatkéréshez - mert a prices menü alatt csak árak nincsenek -, ez oké, de ezzel egyúttal engedélyezem hogy küldjék a spamot, amiről le lehet iratkozni. Illetve lehetne, ha regisztrálva lennék, de nem vagyok, csak beleegyeztem, hogy bármit csinálhatnak).

Ehhez képest az opensource dokumentáció (ami csak egy verzióval korábbi, és majdnem igaz ami le van írva) bogarászása valóságos felüdülés.

*) Illetve akar a hóhér, de muszáj.

Ehhez képest az opensource dokumentáció (ami csak egy verzióval korábbi, és majdnem igaz ami le van írva) bogarászása valóságos felüdülés.

Masszív plusz egy. (és rejtett subscribe)

A másik kedvencem az EULA-bogarászás, hogy miután egy talicskányi pénzt áttoltam a gyártónak, az EULA melyik szabályával megy szembe, hogy van pofám használni a szoftvert. [és masszív plusz pont az Amazonnak az AWS Service Terms 57.10-es pontjáért :) ]

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( deviance | 2016. 09. 05., h – 11:51 )

Ajánlani tudnám a Corosync+Pacemaker+drbd koncepciót! Ha gond van akkor automatikusan átveszi a cluster másik tagja a Master opciót és domain mögé regelt IP-t sem kell átírnod mert felveszi automatricán az IP-t mint amin eddig is szolgáltatott. :)

DRBD erre nem lesz a barátod szerintem. Nagy lehet a latency, ami nem tesz jót majd a teljesítménynek.
Egy inkonzisztens 2. node meg annyit ér mintha nem is lenne.

Én a htdocs-ot időközönként rsyncelném, a mysql meg master-slave HA cluster, ha nem akarsz a multimaster megoldásokból eredő lehetséges limitációk miatt szívni valami egyedi alkalmazással pl. A corosync, pacemaker, rgmanager a mysql master-slave megvalósítására teljesen jó.

Pl.: https://raw.githubusercontent.com/y-trudeau/resource-agents/master/hear…

( szegecs | 2016. 09. 05., h – 12:10 )

Nagyon jó ötlet, igazi hupwiki-be való elképzelés.

Amikor majd (max. 2 hét) összedől, dobj egy mailt és küldök árajánlatot recovery-re és javításra+üzemeltetésre.

Szvsz arra próbált célozni, hogy a topicnyitó kérést pont annyira lehet teljesíteni, mint mondjuk fából vaskarikát faragni.
2 gépből 6 hopon át még éppenséggel lehet vmi rsync+sql replika kombót építeni ami tetű lassan, de működni fog. Vagy virtualizálva lehet a két VM (online és offline) tartalmát realtime szinkronizálni egy értelmes környezettel.
Viszont autofailover klasztert egy harmadik, witness vagy management vagy hypervisor vagy nevezzük bárhogy, gép vagy réteg nélkül nem lehet csinálni.

( janoszen v | 2016. 09. 05., h – 12:28 )

Borzaszto otletnek hangzik. Tobb lesz vele a szivas mint amit meger. Nezzuk a problemakat:

1. Elmelet

Ha van ket szervered, akkor az, hogy a ket szerver nem latja egymast, egyaltalan nem biztos, hogy azt jelenti, hogy tenyleg nem mukodnek. Csak eppen elconfoltad a tuzfalat, nem ment egy kicsit a BGP, kihuzott valaki egy kabelt valahol, stb stb. Vannak ilyenek, keress ra egy altalad valasztott bulvar ujsag tech rovataban.

Na most, ha a ket szerver nem latja egymast, mindketto azt fogja gondolni a masikrol, hogy meghalt es megprobalja magahoz rantani a szolgaltatast. Na ennek az a gyonyoru kovetkezmenye, hogy ossze-vissza fogsz irni adatokat hol az egyikre, hol a masikra. Szakszoval elve: split brain. Sok sikert az adatok osszefesulesevel.

2. MySQL

Az ugye adott, hogy a MySQL replikacioja aszinkron. Ez azt jelenti, hogy amikor a szerver diskre irja az adatot es visszaigazolja a WP-nel az irast, meg nem tudja, hogy van-e utkozes a masik oldalon. Kepzeld el, hogy mi tortenik egy atallas pillanataban. Amikor az egyik szerveren MEG fut az egyik request, a masikon meg MAR fut egy ugyanolyan request az adatok irasara. Na ilyenkor, ha azonos adatot probalsz irni (pl. unique vagy primary key-el vedve), a replikacio szepen meg fog allni, mert hogy inkompatibilis valtozasok vannak. Ha van monitorozasod, ertesulsz rola. Ha nincs, allni fog a replikacio es az egesz szart se er.

Ezt lehet orvosolni SZINKRON replikacioval, pl. Galera clusterrel, de a Galerasok szerencsere tobb szakirodalmat olvastak es rajottek, hogy ket gepbol nem lehet automatikus HA-t epiteni splitbrain veszely nelkul, eppen ezert a Galera 2 gepen nem lesz hajlando neked automatikus failoverrel mukodni, csak kezivel ha jol emlekszem (fixme).

3. Filerendszer.

A WP magja alapvetoen ket esetben ir a diskre: amikor filet toltesz fel, es amikor updatelsz.

A file feltoltest eleg egyszeru megoldani, mert vannak hookok, amikkel at tudod jatszani a masik gepre vagy S3-ra a filet, es ezzel meg van oldva.

Az updatek kicsit trukkosebbek, de ha nem akarod autoupdaten uzemeltetni a WP-t, akkor CLI-bol eleg sok mindent meg lehet oldani.

De itt jon a nagy bokkeno: ez csak a WP core reszere igaz. A mindenfele kakitaliga pluginek random fajlokat akarnak irni, sot, helyenkent meg a webszerver configba is bele szeretnek berhelni. Ez esetben megint szemben jon a MySQL-nel leirt szivashalmaz, miszerint 2 gepbol nem lehet automata failovert epiteni splitbrain veszelye nelkul, ami egy filerendszernel eleg kritikus.

4. Javaslat

Mivel itt WP-rol van szo, szerintem joggal feltetelezheto, hogy keves iras tortenik, es azt is jol meghatarozott emberhalmaz koveti el. Ez azt jelenti, hogy az egesz rendszer teljesen jol el tud mukodni read only uzemmodban is. Vagyis van lehetoseged arra, hogy a masodlagos gepet read only uzemmodban fusson, es az admin felulet reszeret kiveszed ebbol, az erre erkezo keresek mindig az elsodleges gepre menjenek. Ezzel mentesulsz a harom gep kovetelmenyetol, hiszen a front oldalon nincs irasi muvelet es csak a cloudflare oldalon van "failover", a gep szintjen minden ugy nez ki, mintha egy helyi wordpress install lenne egy read-only particion. (Extrem esetben meg lsyncd-vel is megoldhatod, nem kell hozza semmifele elosztott filerendszer.)

Ettol fuggetlenul eltanacsolnalak az egesz projekttol azon egyszeru okbol kifolyolag, hogy a Wordpress architekturalisan nem erre van kitalalva. Muszakilag lehetseges Wordpress failover/lb clustert epiteni (rengeteg workarounddal), de egy ilyen kis koltsegvetesu projektnel jo esellyel a komplexitasbol adodo leallas tobb lesz, mint amit egy sima egyszeru LAMP gep egyedul produkalna. Inkabb legyen egy jol tesztelt hot spare ahova megy a napi / orankenti mentes es allitsd at kezzel a masik gepre a szolgaltatast.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

1. egy harmadik geppel, megoldhato Corosync+Pacemaker + "setup-CFip-to-me" script resource, majd a CP kitalalja hogy ki el/ki nem, es az szerint futtatja a cloudflare ip valtas megoldo scriptet.
2. bar sokan nem szeretik, de multimaster es auto_increment_increment=2, auto_increment_offset=1, de ezt biztos ismered. ha meg nem ert at a friss update egy failover valtaskor, hat az IJ. legfeljebb nem lesz friss a wp post.
3. wp+pluginek frissites amugy is kezzel sajat git repobol, (eleve www-data nem tudja irni a wp fajlokat, meg ha bele van turva kicsit a core-ba akkor macera a webupdate, meg eleve nem az elesen teszteljuk ki hogy a frissites megy-e), igy csak az uploads konyvtarat kell szinkronban tartalni (pl rsnyc, vagy s3-upload, de lehet van ami mysqlben tartolja az uploadolt fajl contentet)
4. a readonlys javaslat viszont jo, es egyszerubb mint a fenti moka. (nem igenyel sok tanulast)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

1. ha van harmadik gep, akkor tok mas a helyzet, de a komplexitasbol adodo downtime akkor is szamottevo szempont.
2. ez csak akkor segit, ha nincs unique key valamire. Wordpressnel pedig van.
3. csak akkor mukodik, ha a plugin maga ugy van megirva, hogy nem akar mindenfele helyekre irogatni.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

Ez nem Linux, hanem clustering. Hogy mivel csinalod meg az sem Linux, hanem kulonbozo termekek/programok/megoldasok.

Hasznalhatsz direct clustering megoldasokhoz fejlesztett dolgokat: Corosync/keepalived/pacemaker/stb. vagy mashogy oldod meg, mint pl. containerek inditasaval volume-ok segitsegevel, de ehhez is kell egy orchestrator, vagy unikerneles orulettel, mert az nem masodpercek alatt all fel, hanem ezredmasodpercek alatt, de akkor jo ha ertesz az oCalm-hoz, C++-hoz hogy foltozgasd a sajat kerbeledet. Ezek technologiak, amik a Linux-on futnak, neha hasznaljak a Linux kernel lehetosegeit (container - namespaces, cgroups), de nem egyenloek a Linux-szal. Ez olyan, mintha azt mondanam nem ertek a Linuxhoz, mert nem nagyon kondiguraltam meg Postfix-et (na jo, nem elegszer, hogy ugy erezzem jo lennek benne).

Pedig ha valasztani kell, akkor a Disqus messze jobb valasztas. Egy mezei Wordpress eleg gyorsan tele lesz szemettel, stb. Refaktoron ezt a kerdest ugy oldottuk meg, hogy opcionalisan bekapcsolhatoak a kommentek. Ha nem akarod, nem nezed.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

( aaron v | 2016. 09. 05., h – 14:05 )

Failover részhez filléres, nagyon megbízható megoldás:
https://aws.amazon.com/route53/
Production-ön már sok-sok hónapja tesztelve nem kis forgalmú website-tal, ahol a failover az read-only, nyilván az a része már az adott CMS berhelése.

( bitraider01 | 2016. 09. 05., h – 15:16 )

Nem tudom, hogy mekkora a static content - de ajánlom figyelmedbe: https://contabo.com/?show=vps

Több vps-s tartok náluk, gond nélkül működnek. 2015 március óta - 1 db tervezett leállásuk volt, abban a cloudban ahol én vagyok.

Én futnék egy kört, max buktál cirka 5e forintot. :)

( bitraider01 | 2016. 09. 05., h – 15:16 )

Nem tudom, hogy mekkora a static content - de ajánlom figyelmedbe: https://contabo.com/?show=vps

Több vps-s tartok náluk, gond nélkül működnek. 2015 március óta - 1 db tervezett leállásuk volt, abban a cloudban ahol én vagyok.

Én futnék egy kört, max buktál cirka 5e forintot. :)

( szabek | 2016. 09. 06., k – 09:10 )

Köszönöm a hozzászólásokat! janoszen, neked különösképp, h felhívtad a buktatókra a figyelmet! Még végig gondolom, h lesz-e belőle valami, de mindenképp figyelembe veszem, amit mondtatok!

( mhmxs v | 2016. 09. 06., k – 09:20 )

Csak egy kerdes, ha mar a fajlok meg az adatbazis szinkronban vannak, akkor miert nem szolgal ki mindket szerver parhuzamosan? A load balancer mindket helyre kuldi a kereseket amig mindket node elerheto. HA (erted HA) pedig kiesik az egyik, akkor csak arra amelyik el. Az altalad vazold megoldas a hot backup, amit nem sokkal nehezebb osszehozni, mint egy sima terheles elosztast.

-
Big Data trendek 2016

Egy pelda. itt konkretan HAProxyval. En csak azt akartam mondani, hogy egy hot backupos megoldast, ahol nagiossal monitorozza az egyik a masikat, es az eltunesre reagalva atiranyitja a kereseket nem konnyebb osszehozni, mint elerakni egy HA load balancert, ha mar fileok meg adatok szinkronban vannak igyis-ugyis.

-
Big Data trendek 2016

LOL :D Teljesen egyetértünk tovább is görgetem: ha csinálunk HA-t a cloudlair-re akkor a következő spof a BIX, ha európa több országba lerakjuk a weboldal egy-egy node-ját még mindig spof a kontinens( nevetsz de emlékezz a thai földi hdd gyárakra), ha már több kontinensen vagyunk még mindig spof a bolygó ... :)
--------------------
http://grant-it.com/

Huh. Akkor megnyugottam, hogy nem a HA elvben van a hiba... :-P

ui: ezeket a 2D-ben navigalodo slide-okat nem lehet kiteriteni?
Kb. mint egy konyvet. Elkezdi az ember az elejen, es eljut a vegere...

ui2: most latom html forrasbol egesz jol olvashato. Egyebkent se megy az animacio meg a szovegmegjelenites pl. a 3. slideon (firefox 48.0)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( balazsasd | 2016. 09. 06., k – 16:25 )

Ha a két szerver logikailag távol van egymástól akkor nem sok gyorsaságra számíthatsz sajnos.

A mysql replika megvalósítható, és még jó is lesz, legyen róla mentésed :).

Az adatszinkront már nehezebb megoldani.

Glusterfs-t egyszerűen nem lehet annyira finomhangolni, hogy gyors legyen, egy joomla vagy wp site képtelen még cache-el is ésszerű idő alatt bejönni, az adminfelülete pedig katasztrófálisan lassú. Céleszközzel, egyedileg fejlesztett kerettel már szebb eredményeket el lehet érni. Tapasztaltam sajnos.

Drbd-nél a három mód közül van egy olyan, ahol a sebesség elfogadható lesz akár két távoli szervernél is, viszont ha mind a két szerver erősen ír, pl egy forgalmas délután, komoly splitbrain-re lehet számítani. Roundrobinnál nem javaslom.

Ceph-el én kisérleteztem, ahhoz 3 node kell hogy úgy működjön ahogy a nagykönyvben is megvan írva. A kettő nekem sűrűn szétesett.

A cloudflare-nek nem tudom hogy van-e master-slave proxy megoldása, talán az neked a beeső connection-okat valahogy képes lenne szétdobálni, előnyben részesíteni az egyik szervert, így már talán meg merném próbálni a drbd-t.

Az igazán jó megoldás az egy két szerver közös lanban, lacp+keepalive+haproxy+drbd lenne, szvsz.

( Sempi | 2016. 09. 07., sze – 20:07 )

2 gép hoszting díjából (kérdés, hogy csak ez van-e rajta) simán kijön egy AWS Beanstalk + RDS / Aurora + EFS
S3-ba mentés, Glacier-be archivum. Tartozik hozzá LoadBalancer, ahhoz meg AWS ad SSL certet.

Hat hacsak nem eppen cloudflair, nagios, glusterfs, ceph, mysql replika mester a delikvens azt sem egyszerubb szakerteni, vagy talalni szakertot, aki ezeket vagja. De ez nem egy agysebeszet, az emlitett aws technologiakat konnyebb elsajatitani mint ossze hangolni a masikat, sot azt mondom, hogy pont a nehezet csinalja meg az AWS, es nem kell redundans load balancert faragni, meg adatbazis replikaval foglalkozni, raadasul a vegen nem csak ket gepen fog mukodni a dolog, hanem gyakorlatilag a beanstalkkal a "vegtelensegig" skalazhato.

Persze vannak hatranyai is a dolognak, hogy csak 1et mondja vendor locking. Ugyfeleink tulnyomo resze AWSt hasznal, es azt tapasztaljuk, hogy tul jo az integracio egyes servicek kozott, es amikor mar 3-4-5-8-12 dologra epitkezik valaki, akkor nem konnyu kiszallni.

-
Big Data trendek 2016