Fórum Root.cz
Hlavní témata => Server => Téma založeno: Vojta 02. 05. 2014, 22:28:27
-
Zdravím. Potřeboval bych poradit, jak navrhnout serverovy cluster. Jedná se o 3 blade servery, na kterých poběží VS třetích stran (cloud). Napadá mě dat 2 servery do clusteru a pomocí load-balanceru vyvažovat výkon a třetí nechat jako záložní. Záloha probíhá pomocí snaphotu. Je to ok? nebo by to šlo udělat lépe?
-
Zdravím, potřeboval bych poradit, jaké si koupit kolo, na kterém budu jezdit. Neřeknu vám nic o tom, jak často a v jakém terénu ho chci používat, ani jaký cloud s jakými aplikacemi tam poběží.
-
To co v cloudu poběží si zvolí sám uživatel, takže tohle jde do předu těžko zjistit ;) Mě jen zajímá jestli je tohle řešení vhodné. Píšu bakalářskou práci a nemám praktické zkušenosti.
-
Kromě snad ČVUT a VUT v Brně je fakt jedno, co tam napíšeš, stejně tomu hovno rozumí.
Dej tam cokoliv se SAS nebo HBA.
-
Bohužel jsem z VUT :D
-
Blade sice nemame, ale load balancer neni spatna moznost. Sami to tak mame. Mame to teda nastaveny tak, ze vytizeni v celku neni 50% a ten zalozni server nepouzivame, imho je to zbytecnost, nic ti nebrani mit vsechny 3 v cloudu.
-
No jasný, ale jedná se mi o to, že když jeden klekne, tak aby se nastartoval záložní. Nevím jestli to dobře chápu nebo jestli je to dobrý řešení, ale ty 2 bych dal do clusteru a použil load balancer a třetí nechal jako záložní, kdyby jeden z těch dvou vypadl. VS se ze zálohy obnoví a jede se dál, ikdyž data nebudou aktuální. Prostě redundantní zapojení :)
-
No jasný, ale jedná se mi o to, že když jeden klekne, tak aby se nastartoval záložní.
Ne. K čemu? Když jeden umře, přemigruješ z něj služby na ty dva zbývající.
A co bys chtěl loadbalancovat? Jestli jsem to pochopil, jde ti o poskytování individuálních VPS.
-
3 je v tyhle situaci dost malo
pokud chces mit on-demand spousteni hostu tak jich potrebujes alespon 1 navic proti "zaruceny kapacite" vzdycky bezici, plus kolik chces spicich jako bonus
myslenka je takova ze v pripade ze 1 host zhavaruje tak nechces cekat az se ti jinej spusti, potrebujes co nejrychleji restartovat umrely VMka
-
jak jiz bylo zmineno, nepises nic o tom co na tom pobezi... VMware? Hyper-V? XEN? nebo neco jineho. Jinak 3 ziletky je potrebne minimum, predpokladam ze 3 blady neznamena 3 chassi kazda s 16 ziletkami. VMware (vSphere) i Hyper-V (MSSC) si pak s failover cluterem poradi "sam". S Xenem a dalsima zkusenosti nemam. Jinak velmi dulezite je reseni storage, ptz. na tom stoji a pada cely cloud... (i takove reseni tu nedavno bylo...)
-
Virtualizaci zajistí VMware. 3 blade = 3 žiletky.Se storage by neměl být problém. Jde mi o to, jak ty servery zapojit, aby byla zajištěna vysoká dostupnost, která je při cloudu potřeba a abych z nich dostal maximum.
-
V pripade vyuziti platformy od spolecnosti VMware se to co hledas jmenuje HA (High Availability) a v KB VMwaru najdes spoustu WH i BP. Doporuji tedy nejprve neco o tom precist a pochopit jak to pracuje. Az pak resit samotne zapojeni a nastaveni...
-
Koukám, že to VUT dává taky vzdělání celkově nahovno, když si ani neumí vygooglovat to svoje Google:blade high availability.
Jako druhý post by našel tohle:
http://amod.ee.duke.edu/PAPERS/ibms_smith.pdf
To je až smutný řekl bych.
-
A co se tyce storage, tak tu v zadnem pripade nepodcenuj... jedna se o nejslabsi clanek celeho cloudoveho reseni. Mas 3 nezavisle ziletky, kdyz jedna umre VM, ktere na ni bezeli se otoci a pusti se jinde. Idealne by mely byt servery redundantni na urovni celeho chassi... tzn. alespon 2 chassi a kazde o 3 ziletkach. Porad ti zustava problem se storage data by nemela byt redundantni jen na urovni disku/polic, ale na urovni alespon dvou nezavislych ulozist (idealne synchrone replikovanych). Pri reseni s jednou storage ti pada cely cloude s padem jedne storage... A ver tomu ze obcas se stane ze i lepsi HW odejde do kremikoveho nebe. Klidne to muze byt vlivem ktery nepredvidas (napr konec ledna... hodne toho bylo na lupe...)
-
Díky. Princip HA, už mi je jasný. Co se týče storage, tak je implementováno diskové pole IBM N6210. To je kategorie midrange v zapojení dual – controller active - actice. 14 ks 600GB 15.000 rpm FC HDD a 14 ks 1 TB SATA HDD.
Zapisuje na typ RAID 6. Pole je díky tomu odolné proti současnému výpadku dvou disků při zachování stejného výkonu. Organizace nepočítá s doupením dalšího redundantního pole. Myslíte, že je tohle diskové pole dostačující?
-
pole vypada slusne, dual controller reseni je asi nejlepsi pomer ceny za muziku (redundanci)
mas redundanci na urovni radicu, zdroju i disku, jeste musis udelat spravne zapojeni (tedy kazdy ze serveru by mel mit 2 SAS/FC/whatever radice, kazdy zapojen do obou radicu na poli) a mel bys mit hotovo
pak jen doufat ze neodejde nejaka z "pasivnich" casti, ktere nemas redundantni (backplane pole, midplane blade chassis)
dalsi problem je v tom ze obcas odchazi klimatizace, prichazi voda atd. pro opravdu 'cloudovou' spolehlivost potrebujes tohle resit, tim ze mas techniku ve vice lokacich, s nejakou slusnou lajnou (treba 10GE optika, samozrejme nekolikrat pro redundanci) pro synchronizaci
-
zalezi na tom jake hodnoty jsou vyzadovany od RPO(recovery point objective) a RTO (recovery time objective) a jak kriticke aplikace se provozuji. Porad se totiz predpoklada (hlavne na ceskem trhu), ze ze zadny DR (disaster recovery) scenar nikdy nenastane nebo nejsou vubec DR plany zpracovany, jak v pripade katastrofy postupovat. Moje narazka byla smerovana na udalost, ktera se udala jedne nejmenovane spolcenosti v Praze nekdy pocatkem roku. Udajne obnovili vse ze zalohy a zaroven mely dat do provozu i zminene synchornni pole. Ono totiz se muze stat cokoliv a nikdy nelze vse predvidat na 100%. Je hezke, ale i dulezite mit aktivni HA, ale podstatne vetsi problem nez nefunkcni HA je v pripada poruchy jednoho centralniho uloziste. Protoze pak padne vse a cas potrebny pro obnovu u dat v radech desitek az stovek TB se muze pohybovat v radu tydnu! Jinak samozrejme zaloha v zadnem pripade neni snapshot!!! Kor kdyz se nachazi na stejnem primarnim poli. A pri navrhu je potreba opravdu pocitat se vsim.
Druha poznamka k poli: jako druhe pole muze byt klidne vyuzito neco pomalejsiho, ale je potreba mit plan ktere VM budou v pripade DR omezeny. Takove reseni ovsem je zcela nevhodne pro provoz verejneho cloudu... Jak tam rozhodnu ktere stroje budou mit prioritu...
Pri realnem provozu pak je vhodne se zabyvat adaptativni optimalizaci, protoze pole prece jen nema neomezene IO.
-
.. pak jen doufat ze neodejde nejaka z "pasivnich" casti, ktere nemas redundantni (backplane pole, midplane blade chassis)..
.a nebo misto doufani blady rovnou rozhodit po ruznych chassis do ruznych racku, pohlidat si napajeci vetve..
Nevim jestli to tady uz nezaznelo, ale krome serveroveho zeleza je dobre pohlidat i redundanci u cele lan/wan a san infrastruktury, jinak je cluster k prdu, kdyz se na nej nekdo nedoboucha..