Debian – Rozložení zátěže a vytvoření zálohy

Zdravím, potřebuji rozložit zátěž, minimalizovat výpadky a také si vytvořit zálohu, která bude co nejvíce aktuální. Load balancing je fajn věc, ale nevím jakým způsobem udržovat aktuálnost dat. DB je vyřešené, ale nevím jak udržovat data. Uživatel nahrává obrázky přes web rozhraní a obrázek se nahraje na server, na kterém zrovna aktuálně je. Pokud bych přistupoval k datům (obrázkům) které bych měl pouze na jednom serveru, pak jsem si moc nepomohl. Třeba na to jdu z jiné strany, jak se to řeší?

Budujete neco takoveho? http://prntscr.com/bf4wucPotrebujete spolecne nezavisle datove uloziste (napr. NFS), nebo sitove zrcadlene uloziste (napr. GlusterFS)

na linuxu to lze snadno, řeší se to podobně jako databáze, tj. několik serverů, navzájem sychnronizovaných, data na všech replikovaná a samotná databáze se napojí do určitého adresáře přes "fuse" a poté k ní přistupuješ jako k obyčejné složce, jen uložení trvá o pár mlisekund déle. Zprovoznění je asi na hodinku pro šikovného admina a nároky na údržbu závisí na zvolené technologii a počtu výpadků.Jak už zmínil vdusek, často se třeba používá síťový filesystém NFS (určitě pouze verzi 4) nebo v tvém případě bych asi uvažoval o koupení uložiště typu Amazon S3, který také můžeš napojit do konkrétního adresáře a nepotřebuješ k tomu takový support jak u vlastního provozu.Seznam filesystémů přes více serverů je na wiki. Pokud chceš poradit konkrétně, napiš o jaké množství dat se jedná, kolik máš serverů, jaké bude zatížení a jestli chceš mít soubory u sebe nebo ti nevadí použít nějaký hosting typu Amazon.

Tyjo samej admin tu :) Prvne bych rad rekl, ze zaloha neni to same co replika. Kdyz si omylem smazes data z replikovaneho disku na jednom serveru, tak se samozrejme zacnou mazat a asi i smazou z druheho. To je replikace. Zajimalo by me, jak resis databazi, pokud se bavime o mysql. Podle mych chabych asi desetiletych zkusenosti s replikaci mysql bych nepovazoval master-master mysql replikaci mezi dvemi servery za vyreseny problem. Na obrazku, ktery postoval vdusek je problem storage, tam jak pise musi byt nejaky rozuny cluster filesystem, coz by asi resil glusterfs, ale i ten ma nejaka omezeni. POkud to diskove pole bude jen jedno, tak se vystavujes problemu, pokud ti odejde. Dal na to obrazku je neco jako HAWEB, coz by mohl byt nejaky balancer, klidne pomoci DNS, coz je pro tebe asi nejlevnejsi, ale zase to nepozna, ze jeden server chcipl. Lze to samozrejme vyresit, aby te pak netrapilo, ze ti chcipl jeden server a roundrobin v DNS ti pulku pozadavku posle na mrtvej server. Pokud ti nekdo napise, ze se replikace souboru resi snadno jako databaze, ze se neco na serverech, kde chces stabilitu a vykon pripojuje pres fuse a nazyva adresar podle obrazku slozky predstavujiciho adresar ve windows, tak ruce pryc :D O hodine na sestaveni ani nemluvim, nejak v te hodine nevidim testovani replikace, failoveru a dalsich veci. Ale co bys chtel za ty prachy zejo. Amazon S3, jako primarni uloziste na vlastnich serverech je pomale, no a stavet do jedne vety NFS a Amazon S3 je ... divny.Reseni je mozna spousta, ale zalezi kolik na to je casu a penez.

majkro: podívej se na první větu tazatele, nepotřebuje dělat čtyř devítkovou infrastrukturu. Bohužel toho více nenapsal, tak lze jen odhadovat, mysql/mariadb v master-master není žádná lahoda, je ale možné, že mu to běží už třeba v azure a používají jejich přednastavenou clusterovou db, kdo ví.Přečti si pozorně co jsem napsal a nedávej mi do úst něco jiného, slovo snadno vztahuji k linuxu, na jiných platformách není tolik možností a taková flexibilita (občas tady padají dotazy i na windows). Rozhodně nepíšu, že se to řeší snadno jako databáze, ale že cesta řešení je podobná tomu, co se musí dělat u databází.Bez více informací nelze zohledňovat výkon a stabilitu, ono i naivní řešení může pro malé weby stačit, podle prvotního dotazu to nevypadá na větší a vytíženější web. Ano, s hodinou jsem to výrazně podcenil, ale instalace bez otestování déle trvat nebude, jedná se o běžně řešení problém a sám již mám řadu scénářů z automatizovaných. Důkladné otestování a správu jsem do toho nepočítal.Diskuze o terminologii adresář/složka je ubohá, mám tyhle české termíny naučené už z dob CP/M, prosím neurážeji diskutující, když o nich nevíš lautr nic.Amazon S3 a NFS se chovají pro aplikaci hodně podobně a nejedná se o složité technologie pro používání, proto jsem je zmínil jako vhodnou možnost a záleží pouze na požadavcích, jestli se budou dát použít nebo nikoliv.mcever4: můžeš tedy upřesnit co od toho čekáš, jestli máš někoho kdo se ti o to bude starat, kolik dat budeš mít a jak často se budou číst a zapisovat?

Trochu upřesním:Pokud bych měl sdílené úložiště, pak budu přistupovat z více serverů na jedno místo, rychlost načítání bude stejná, dokonce si myslím že pomalejší, než pokud bych měl data na serveru přímo. Pokud budu provádět zálohu, tak úložiště zatížím a bude pomalé. Jednalo se mi o to, abych měl data na dvou serverech synchronizované i s tím že pokud data smažu, smažu je i na druhém serveru. Pokud jeden server bude nedostupny, pak přebírá funkci druhý. Tak jak funguje RAID.Není to mega projekt, jedná se cca denně o 1000 fotografií o velikosti 100kB, a 1000 foto o velikosti 10kB a běží to od roku 2009cca 2 880 000 fotografií (souboru)Nyní to běží na dedikovaném serveru s RAID 5Kdybych se vešel cenové do 8 tis měsíčně, budu rád.

Pro mirroring disků přes síť jde použít technologie DRBD, která však trošku snižuje výkon.Pro podobný účel si myslím, že by stačilo použít rsync a pouštět ho například každou hodinu (nejjednodušší věci často fungují nejlépe).Pokud by hodina nestačila, tak je možné využít inotify a sync si vyžádat vždy při změně souboru - https://github.com/axkibe/lsyncd/ nebo https://github.com/hollow/inosync.Pro HA bych v tomto případě použil protokol VRRP (keepalived) a nechal bych servery střídat se o virtuální IP adresu.

mcever4: v tom případě si to dej do zakázek a normálně si na toho někoho najmi, nepotřebuješ poradit, ale potřebuješ to udělat, sám to těžko budeš patlat.Osobně bych doporučil ty fotky hodit do něčeho jako Amazon S3, jen to chce spočítat traffic, ušetříš s tím fůru starostí a bude ti to spolehlivě fungovat, ale poptej si někoho, nech si to od něho navrhnout a pak případně tady si to můžeš nechat zkontrolovat, ale nemá smysl se teď dohadovat jak to udělat.

Napsal smitka;1299013

Pro mirroring disků přes síť jde použít technologie DRBD, která však trošku snižuje výkon.

Pro podobný účel si myslím, že by stačilo použít rsync a pouštět ho například každou hodinu (nejjednodušší věci často fungují nejlépe).

Pokud by hodina nestačila, tak je možné využít inotify a sync si vyžádat vždy při změně souboru - https://github.com/axkibe/lsyncd/ nebo https://github.com/hollow/inosync.

Pro HA bych v tomto případě použil protokol VRRP (keepalived) a nechal bych servery střídat se o virtuální IP adresu.

DRBD se spozdenym zapisem tomu vykonu trosku pomuze a kdyz si omylem smaze data, tak bude mit rosku casu navic na rozpojeni drbd. Inotify neni moc spolehlivy u hodne souboru, mel jsem s tim dost problemu. VRRP bude OK, tpo poresi i ten problem s DNS balancovanim.