Decentralizovaný hosting s vysokou dostupností

[- -]

Víte prosím někdo o bezplatném nebo velmi levném software, díky kterému mohu hostovat 1 dynamický web (PHP, MySQL,+ to potřebuje další linuxovou utilitu) na 2-3 Linux serverech vlastního výběru s tím, že když na jendom serveru dojde k selhání disku, cloud hosting bude bez přerušení jakýchokoli služeb pokračovat na zbývajících serverech?

Potřeboval bych pouze jednoduché řešení a nebo řešení, kde je návod (víte o takovém?), podle kterého může laik postupovat. Vím, že existuje třeba OpenStack, OpenNebula, které by možná šly použít, ale nenašel jsem nějaký jednoduchý návod. Rád bych začal na jednom nebo dvou serverech a později přidával více.

Nebo pokud víte o snadném způsobu jak zálohovat celý Linux server a snadno ho obnovit na novém serveru u jiného poskytovatele. Děkuji

[Reklama]

[David]

Docela těžko. Můžete mít replikaci databáze a přes nějaký monitoring přepnout na master a změnit DNS, aby mířily na nový server. Ale spíš bude cesta sdílené úložiště a HA virtuál, který naběhne v případě problémů na jiném nodu. Nebo managované služby třeba v Azure, ale to je hodně drahé. Musíte vědět, proč to tak potřebujete a zaplatit za to adekvátně.

[mensinamlcici]

Uvědomte si prosím, o jakém použití (use case) píšete. Celý server nebo jen nějaká data řešíte? Děláte to pro sebe nebo je výsledkem něco, co předáte poučenému laikovi? Je to jednorázové řešeni nebo jich bude časem více? Jak budete vyhodnocovat efektivitu vynaložených nákladů celého projektu?

[Jan Forman]

Tyjo fascinuje mě, že to někoho vůbec napadne. Pokud by tam chybělo slovo levně či zadarmo tak neřeknu.
V cloudech jsou tyhle služby decentralizované a používají speciální software který se používá jako služba.
Výpadek serveru (VPS nebo HW) se bere jako normální stav a software sám o sobě to musí dokázat odfiltrovat.
Nicméně ta VPS stejně zemře... jediný způsob jak to omezit je živá migrace. Což má extrémní dopad na výkon.

Pokud půjde jen o storage tak tam je pár variant jak to řešit. Prostě provádět pravidelný backup či snapshot a nebo použít něco jako CEPH.
Jenže stejně to bude drahé... servery, konektivita a disky nejsou zadarmo.

Není žádné abrakadabra řešení to je zcela jiná architektura. Slova levné a vysoce dostupné jdou hodně proti sobě.
O zadarmo či neomezeném už ani nebudu mluvit.

[jjrsk]

...

Hele, jednoduchy a zadarmo a v 99% zcela vyhovujici reseni je, ze kdyz jeden srv umre, tak nekdo jde a zapne druhej.

Pokud chces lepsi reseni, tak to je nejaka virtualizace, ale ta v zasade funguje v zakladu presne stejne, jen se ten "nahradni stroj" zapne sam.

Na bezvypadkovej provoz !jednoho! virtualniho stroje potrebujes zajistit 10Gbit konektivity mezi tema HW. Nejmene. A to je jen jedna z mnoha podminek.

Pokud chces bastlit, tak to muzes udelat i tak, ze ti tech stroju pobezi vic, ale to musi umet samozrejme vsechny zucastnene aplikace. Tzn ve tvym pripadne budes muset resit syncovani dat v databazich. Coz sice neni nic sloziteho, ale typicky trva par tisic clovekohodin, nez se to odladi tak, aby to aspon v 90% pripadu fungovalo.

BTW: Protoze o tom vis zjevne prd, tak pro info, treba presun virtualniho stroje na jinej HW za behu ve skutecnosti funguje tak, ze se udela snap a vzdy tam dojde nejakemu kratkemu vypadku. Predpoklada se, ze normalni aplikace to zkousnou, ale ne kazda aplikace je normalni.

V pripade ze HW umre, se proste nastartuji stroje na jinem HW = chova se to presne stejne jako restart natvrdo. Pokud chces tomuhle predejit, tak viz vejs, dochazi pak setrvale treba k syncovani ramky, coz ma samozrejme svou nikoli nepatrnou cenu.

[Reklama]

[kanoe22]

Pride vam to ako jednoducha poziadavka, chcete mat par serverov kde ked jeden umrie tak to prevezmu ine.

Ono to ale jednoducha poziadavka nie je, kor ak to chcete mat napriec X poskytovatelmi, vysoku dostupnost, defacto non-stop fresh data z diskov dostupne inde, atd.

To co chcete je jednoznacne enterprise riesenie, a tie nikdy nie su lacne, natoz zadarmo.

Treba bud vyrazne ubrat z poziadaviek ako to vlastne ma byt odolne voci vypadkom a na schopnostiach premigrovat to inam (aj keby len v ramci jedneho poskytovatela na iny server u neho), alebo treba vyrazne pridat na rozpocte (a to fakt vyrazne, tu sa nebavime o ucte par desiatok eur za mesiac)
Inak tuto otazku nema ani zmysel riesit, pretoze riesenie je nemozne.

[Matho23]

Riesenie je:
- Docker swarm, minimalne 3 nody (jeden co bude presmerovavat traffic na 2 uzly)
- GlusterFS pre real-time synchronizovanie assetov (napriklad uploadnute subory webu)
- Traefik
- replikovana databaza - pre PostgresSQL existuje Spilo projekt od Zalando, ako je to u MySQL neviem
- HaProxy

[thisisroot]

Riesenie je:
- Docker swarm, minimalne 3 nody (jeden co bude presmerovavat traffic na 2 uzly)
- GlusterFS pre real-time synchronizovanie assetov (napriklad uploadnute subory webu)
- Traefik
- replikovana databaza - pre PostgresSQL existuje Spilo projekt od Zalando, ako je to u MySQL neviem
- HaProxy

Tohle by šlo dobře např. na cloudu od Oracle. Ale nevím jak moc výkonné servery potřebujete. Zatím mají ve free tier 24GB RAM, 4OCPU a 200GB HDD na ARM. Takže by z toho šly udělat 4 instance po 6GB, 1OCPU a 50GB. Na nějaký PoC by to mohlo stačit, pak uvidíte dále.

[hmmmw]

Riesenie je:
- Docker swarm, minimalne 3 nody (jeden co bude presmerovavat traffic na 2 uzly)
- GlusterFS pre real-time synchronizovanie assetov (napriklad uploadnute subory webu)
- Traefik
- replikovana databaza - pre PostgresSQL existuje Spilo projekt od Zalando, ako je to u MySQL neviem
- HaProxy

Jako free stack super, ale ten návod, podle kterého může laik postupovat bych chtěl vidět. 

[kanoe22]

Riesenie je:
- Docker swarm, minimalne 3 nody (jeden co bude presmerovavat traffic na 2 uzly)
- GlusterFS pre real-time synchronizovanie assetov (napriklad uploadnute subory webu)
- Traefik
- replikovana databaza - pre PostgresSQL existuje Spilo projekt od Zalando, ako je to u MySQL neviem
- HaProxy

Tohle by šlo dobře např. na cloudu od Oracle. Ale nevím jak moc výkonné servery potřebujete. Zatím mají ve free tier 24GB RAM, 4OCPU a 200GB HDD na ARM. Takže by z toho šly udělat 4 instance po 6GB, 1OCPU a 50GB. Na nějaký PoC by to mohlo stačit, pak uvidíte dále.

Ak mu na tom jedinom servery klakne disk, tak pojdu k vode vsetky instancie ktore tam budu - poziadavka bola odolnost na zlyhanie disku -> a to vyzaduje bud raid (plus hotswap technologiu), alebo dve fyzicke masiny (a pravdaze nejaku synchonizaciu/mirroring medzi nimi)

[Martin12]

Mám to vyřešené téměř zadarmo, a připravuji o tom článek pro root.cz.

Ve zkratce, je master node, který má master mysql a www, pak je slave node, ten má slave replikaci mysql, rsyncem se kopírují www data a nagios monitoruje dostupnost master node, pokud master node klekne, tak nagios má event, že na cloudflare má přehodit směřování DNS a veškerý traffic jde na slave.

Není k tomu potřeba nic moc (slave mám RPI), ani nějaká rychlá linka (věřím, že by to běželo i na lince 1Mbit), ani to není nákladné, de fakto jen elektřina, IPv6 adresu mám zdarma a cloudflare tam směřuje provoz.

Takže to určitě jde.

Nasetupování mysql replikace není těžké - konfigy jsem si vygeneroval přes ChatGPT, a event co při výpadku přehazuje doménu jsem taky vygeneroval přes ChatGPT.

Jak říkám, mám to funkční, odzkoušené, píšu o tom článek.

[alfi]

Co je na tom webu a jak moc čerstvá data tam musí být? Nejjednodušší je povolit cachování html a zapnout třeba Cloudflare. Jinak třeba ta replikace mariadb master-master, i pro zápisy, musí tam být i sessions + rsync + uptime check a přepínání DNS s krátkým TTL (ale ani to nemusí fungovat 100% - když linka mezi nimi nevypadne úplně, ale jen zlobí, nebo když monitoring vidí živý server, ale zákazník v síti XY ne). To přepínání DNS jsme úspěšně provozovali řadu let

[tralala5]

preco sa vsetci snazia replikovat mysql? na takychto otazkach clovek vie medzi akymi ludmi sa pohybuje ...

OP potrebuje distribuovanu databazu a nie ohybaky na narovnavaky. Ked chce redundanciu a availability nech si to postavi na Cassandre, tri nody, RF 3, CL quorum. Jeden node ked vypadne tak to je uplne jedno.

Nad webovkou nech si postavi nejaky load balancer co mu to furt pinguje a spravi failover ked to neni online a je ...

Nejaky "glusterfs" je zbytocny, ked ide deploynut novu verziu webu tak len preklopi git branch na kazdom stroji cez nejaky pssh alebo co

[mhepp]

Mám to vyřešené téměř zadarmo, a připravuji o tom článek pro root.cz.

Ve zkratce, je master node, který má master mysql a www, pak je slave node, ten má slave replikaci mysql, rsyncem se kopírují www data a nagios monitoruje dostupnost master node, pokud master node klekne, tak nagios má event, že na cloudflare má přehodit směřování DNS a veškerý traffic jde na slave.

Není k tomu potřeba nic moc (slave mám RPI), ani nějaká rychlá linka (věřím, že by to běželo i na lince 1Mbit), ani to není nákladné, de fakto jen elektřina, IPv6 adresu mám zdarma a cloudflare tam směřuje provoz.

Takže to určitě jde.

Nasetupování mysql replikace není těžké - konfigy jsem si vygeneroval přes ChatGPT, a event co při výpadku přehazuje doménu jsem taky vygeneroval přes ChatGPT.

Jak říkám, mám to funkční, odzkoušené, píšu o tom článek.

Já bych před to hodil HA proxy, to umí přehazovat ten provoz podle potřeby...

[mhepp]

preco sa vsetci snazia replikovat mysql?

MySQL umí replikaci už hodně dlouho, je to stabilní a funkční řešení. Tak proč je to špatně?