Cluster ze tří blade serverů

[anonym]

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

[Reklama]

[nikdo]

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.

[Jose D]

.. 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..