Fórum Root.cz
Hlavní témata => Server => Téma založeno: - - 17. 07. 2024, 07:04:00
-
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
-
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ě.
-
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?
-
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.
-
...
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.
-
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.
-
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
-
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.
-
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. ;D
-
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)
-
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.
-
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
-
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
-
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...
-
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ě?
-
Pretoze to tam bolo dodatocne dorobene lebo sudruhovia zistili, ze im to neskaluje, tak zacali vymyslat narovnavaky s milion "ale". Nic sa nevyrovna tomu, ak je ta DB uz inherentne navrhnuta tak, ze s tymto scenarom pocita. MySQL a podobne bude furt "single node db" kde to ako tak pojde replikovat ked privreme obe oci. Boh ochranuj kde sa to rozsype.
-
Ecs, rds, elasticache, s3. Před to CDNku.
-
Pretoze to tam bolo dodatocne dorobene lebo sudruhovia zistili, ze im to neskaluje, tak zacali vymyslat narovnavaky s milion "ale". Nic sa nevyrovna tomu, ak je ta DB uz inherentne navrhnuta tak, ze s tymto scenarom pocita. MySQL a podobne bude furt "single node db" kde to ako tak pojde replikovat ked privreme obe oci. Boh ochranuj kde sa to rozsype.
Dolepená funkcionalita byla do kde čeho. No a co.
Pokud máš hotové řešení, kde je DB nějak daná, tak stejně použiješ to, co daná DB nabízí. A replikované MySQL/MariaDB jsem spravoval ~15 let. Ze začátku jsem udělal pár blbostí, ale data jsem neztratil nikdy. Měl jsem Master-Master replikaci a k tomu připojený ještě jeden slave jako zálohovací.
-
To řešení, o kterém píšu samozřejmě není ideální, ale je levné a rychlé. Pokud by někdo chtěl skutečné HA, tak AWS, udělat image mašiny, load balancer, a v každé AZ přes cloud-init pustit mašinu s tím, že data budou na EFS a databáze na RDS, nádherné řešení, úplně HA, ale v minimální verzi bych to viděl na 2.000 - 3.000 Kč měsíčně, což pro firmu fajn, ale jednotlivce ne, dostupnost by tady byla nějakých 99,9995%.
To mnou navrhované řešení se záložní lokalitou je řádově dostupností horší, ale stojí to de fakto jen elektriku pro RPI.
-
Riesenie je:
- Docker swarm, minimalne 3 nody (jeden co bude presmerovavat traffic na 2 uzly)
(...)
- HaProxy
Jako free stack super, ale ten návod, podle kterého může laik postupovat bych chtěl vidět. ;D
Úplně nejjednodušší postup i pro poučeného laika je tento:
Webservery na Windows Server, nainstalovat roli IIS Web Server, nahrát obsah a vytvořit sajty
Klidně na jednom z nich přiinstalovat roli Network Load Balancing (ale lepší je na to mít na samostatné instanci)
V této roli nakonfigurovat cíle
Klienti přistupují na balancer
Tadá!
-
Tadá!
To vaše "tadá" bych rád viděl. Kde tam máte to PHP, kde tam máte tu MySQL? O té potřebě spouštět z toho ještě "nějaký" linuxový tool už radši ani nemluvím.
"Tadá" tak možná na nějaký statický web a i ten by průměrný čtenář roota asi rozjel na linuxu v kombinaci apache-nginx/haproxy rychleji než "tadá" na windows serveru.
-
Ten dotaz je od samého začátku pouze nesmyslné přání poučeného, možná trochu naivního, laika.
Obecně lze pouze konstatovat, že zajištění HA je velmi drahé.
A tím to mělo skončit.
Všichni zde mluvíte o softwaru, ale uvědomuje si tazatel, že musí mít dvě internetové konektivity, že musí mít dva elektrické okruhy, a celou hardwarovou infrastrukturu?!
A uvědomuje si, že běžná konektivita od ISP neumožňuje obrácený trafik, a že je primárně určená k downloadu, ale nikoliv pro poskytování služeb dalším stranám?!
Kromě toho, to že to nějak jde tady vůbec nic neznamená. I srdce se dá vyměnit. Ale to neznamená že to každý umí.
-
Úplně nejjednodušší postup i pro poučeného laika je tento:
Webservery na Windows Server, nainstalovat roli IIS Web Server, nahrát obsah a vytvořit sajty
Klidně na jednom z nich přiinstalovat roli Network Load Balancing (ale lepší je na to mít na samostatné instanci)
V této roli nakonfigurovat cíle
Klienti přistupují na balancer
Tadá!
Když odpadne ten balancer nebo jeho konektivita, tak je vysoká dostupnost kde? :-)
Ten dotaz je od samého začátku pouze nesmyslné přání poučeného, možná trochu naivního, laika.
Obecně lze pouze konstatovat, že zajištění HA je velmi drahé.
A tím to mělo skončit.
Proč by to mělo být "velmi drahé"? VPS za pár (deseti)korun je dneska na každém rohu, pořídit dva u různých poskytovatelů a v různých sítích zase nestojí tolik. Pak už je to jen o vhodném nastavení těch duplicit vs. požadavky na aktuálnost dat nebo jejich zápisy :)
-
Úplne najjednoduchšie bude zaplatiť niekoho (alebo sa to naučiť), kto nahodí v cloude HA loadbalancer, deployne tú tvoju appku do dvoch availability zón (ideálne ako container) a pod to dá HA databázu. Práca tak na 1.5 MD max aj s terraformom.
-
Zkus nový zerops.io. Tohle bys tam mohl zprovoznit za pár $ měsíčně. Je to navíc CZ firma.
-
Tadá!
To vaše "tadá" bych rád viděl. Kde tam máte to PHP, kde tam máte tu MySQL? O té potřebě spouštět z toho ještě "nějaký" linuxový tool už radši ani nemluvím.
"Tadá" tak možná na nějaký statický web a i ten by průměrný čtenář roota asi rozjel na linuxu v kombinaci apache-nginx/haproxy rychleji než "tadá" na windows serveru.
Proč MySQL? MSSQL to samozřejmě umí, i když Enterprise edice není levná. A IIS PHP umí. Co tam máme dál?
-
Úplně nejjednodušší postup i pro poučeného laika je tento:
Webservery na Windows Server, nainstalovat roli IIS Web Server, nahrát obsah a vytvořit sajty
Klidně na jednom z nich přiinstalovat roli Network Load Balancing (ale lepší je na to mít na samostatné instanci)
V této roli nakonfigurovat cíle
Klienti přistupují na balancer
Tadá!
Když odpadne ten balancer nebo jeho konektivita, tak je vysoká dostupnost kde? :-)
Ten dotaz je od samého začátku pouze nesmyslné přání poučeného, možná trochu naivního, laika.
Obecně lze pouze konstatovat, že zajištění HA je velmi drahé.
A tím to mělo skončit.
Proč by to mělo být "velmi drahé"? VPS za pár (deseti)korun je dneska na každém rohu, pořídit dva u různých poskytovatelů a v různých sítích zase nestojí tolik. Pak už je to jen o vhodném nastavení těch duplicit vs. požadavky na aktuálnost dat nebo jejich zápisy :)
Protože požadavek byl na živou migraci virtuálu (na VMware známo jako v-Motion).
Dá se říct, že zadání bylo spatláno tak, že nedává smysl, protože když mám v-Motion / Live Migration, nepotřebuju živou replikaci SQL.
-
Protože požadavek byl na živou migraci virtuálu (na VMware známo jako v-Motion).
Dá se říct, že zadání bylo spatláno tak, že nedává smysl, protože když mám v-Motion / Live Migration, nepotřebuju živou replikaci SQL.
Já v dotaze teda požadavek na "živou migraci" nevidím :) jen, že služba má pokračovat bez přerušení (to master2master v MySQL/MariaDb zvládne taky). Každopádně autor se dál nevyjadřuje - hlavně jaké "služby" tam očekává, tj. těžko hádat :)
-
simple
- kupte si ve trech oddelenych lokalitach nejakej virtual u tri ruznych isp
- nainstalujte HAP proxy proti frontendu a SSL
- nastavte RR (pisete webova aplikace) na vsechny nody
- nastavte HAP proti backendu
- natavte HAp proti mysql nebo pouzijte maxscale (nepisete ze je to komercni projekt)
done, jako podekovani poslete nejakou kacku na libovolny donio projekt