Failover cluster je v dnešní době docela levného úložiště přežitek. Kolikrát jsem se setkal s tím, že oděšlo super odolné pole (na vedoru nezáleží).
Asi jediná výhoda oproti ostatním metodám založeným na replikaci logů/dat je v rychlejším comitu transakce (zjednodušeně - není potřeba čekat na potvrzení z replikační vrstvy), ale oproti failover cluster u je zde i ohromná výhoda, failover je pak otázka pár sekund, že to aplikační vrstvu ani nemusí postihnout, protože instance s replikou jsou spuštěné s připojenou databází a tedy není potřeba čekat na přehození disků, spuštění instance jako v případě failover clusteru. I v Alze by se to dalo předělat za běhu bez nutnosti velkých investic.
V praci pouzivame clustery postave na DB od Oraclu Tj. active main app server, db a aux server. To same v passive. Data putuji z active main na db server, kde bezi wrapper, ktery data propise do aktive DB a zaroven je posila na stanby wrapper, ktery je propisuje do stanby db. Aplikacni failover v plnem vytizeni u cca 200GB DB trva radove 15-20 minut. Samotny DB failover bude mnohem rychlejsi.
Ono se to dela jinak, vzdy potrebujete jeste to zalozni pole. A jelikoz samozrejme nechcete co 5 let kupovat pole 2x, tak se to dela tak, ze to 5let stare, kteremu skoncil support pouzijete prave jako to pole zalozni. V pripade vypadku vam pak staci z ostreho serveru pripojit databazi ze stareho pole. I ztrata dat muze byt pomerne nicotna, pripadne i prakticky nulova, v zavislosti na tom jak to je vyreseno.
Alternativne jeste existuje moznost, ze zalohujete nikoli "databaze", ale jejich soubory (samozrejme ve spolupraci s databazi, jinak by to nebylo konzistentni) a potom muzete provest primo attach databaze prave z uloziste kam zalohujete. Otazka 2 minut. To pole mozna nebude tak vykone, ale zajisite docasny provoz do odstraneni problemu.
Protoze i kdyz vam nekdo posle tech letacku plnych vysmatych rodinek vagon, nic to nemeni na tom, ze cokoli selze. A zadny support vam nezajisti, ze vas problem bude vyresen. Natoz v nejake lhute.
Samo že to MSSQL umí (tuším se to jmenuje Live Replikace), ale narozdíl od active-passive clusteru se všechny licence včetně CALů a Internet Connectoru platí dvojmo plus potřebuješ druhé pole. Což v případě Alzy znamená rozdíl řekněme 15 melounů v pořizovací ceně plus provozní náklady. Možná i víc. Otázkou je, jestli by druhé pole se stejnými daty nevykázalo tutéž chybu, což by znamenalo marně vyhozených ... 15 mega nebo víc. To bych na koberečku vysvětlovat nechtěl :-)
Prijde mi to proste blbe navrzene. Failover cluster je dobry kdyz verite poli a neverite nodum, jinak nema smysl. Je to laciny, ale muze se to podelat a to se taky stalo a muze se to kdykoliv opakovat. Navic ten 2. nod nejspis nic nedela.
Co takhle koupit jeste jedno pole a ten server z 2. nodu k nemu pripojit a replikovat data z jedne DB do druhe. Primar RW, sekundar RO (urcite by se nasly nejake operace pro vyuziti toho sekundaru.). Pokud zdechne primar, tak se primar udela ze sekundaru a jede se dal. Vypadek v radu minut. Takhle bych to videl na Informixu nebo Oracle, MS by to asi taky umel, ne?
Samozrejme pokud je SQLServer zabugovany, tak vam stejne zadny hw nepomuze. Z toho co jsem tu cetl zas tak uplne jasne nevyplyvalo, jestli to skutecne zmrvilo to pole nebo MS.
Predpokladam, ze zaver je, ze se chtej zaruky od MS a vyrobce diskoveho pole "ze se to nebude opakovat" a tim to vadne.
Proste Alza usetrila (otazka je kde vlastne, kdyz to bylo tak drahe) a jak velka ztrata ji za tech 27 hodin vznikla.
Anebo se da udelat "pouceni z krizoveho vyvoje" a je to prilezitost jak to predelat ;-), ale spis to bude o tom modlit se, aby se to neopakovalo.