Názory k článku Nestřílejte specialisty aneb Co způsobilo rozsáhlý databázový výpadek v Alza.cz
Článek je starý, nové názory již nelze přidávat.
-
lzap (neregistrovaný) ---.cust.sloane.cz
Pracuju pro nejmenovanou firmu v oblati open-source která dodává operační systém, aplikační stack, middleware no prostě všechno, podobně jako Microsoft. Z vlastní zkušenosti mohu říct, že platící zákazník se relativně rychle probojuje až k lidem, kteří ten software píší - tedy až k softwarovým inženýrům jak se nám moderně říká. A to jsou normální zákazníci co mají obyčejný support 24/5 nebo 24/7. Vím to, protože se s nima občas vídám (máme sem tam nějaký ten bug to se stane :-) - a to máme několikaúrovňovou podporu.
Ještě jsem nikdy neznal nikoho za ta léta v IT, který by se dovolal nebo pro-emailoval k programátorovi v Microsoftu. Protože mezi zákazníkem a Microsoftem existuje tuna resellerů a aby vůbec v Microsoftu řešili nějaké tickety, člověk musí platit nehorázné peníze za "super prémium podporu". Podobnou zkušenost mám s vendory IBM nebo Tibco - pracoval jsem na "druhé straně" a snažil se dovolat z holandské mezinárodní firmy v oblasti Telco. Kdepak, problém jsem vyřešil disassemblací java bytekódu a patchem binárního souboru.
Dodavatele softwaru je třeba si vybírat také podle hlediska "až nastane průser". Bohužel se taková věc špatně vyhodnocuje předem.
-
Ming (neregistrovaný) ---.net.upcbroadband.cz
Ráno sofistikovaně okomentuju politiku, před obědem poradím lidem co s autem, po obědě pořeším architekturu a jak lépe vyřešit dopravní stavby, pak chvilku rady ohledně zahrádky a chalupy a navečer SQL, operační systémy, případně i sítě, když jsem v náladě. Češi a diskuse, to je prostě boží.
-
Martin Prokeš (neregistrovaný) ---.41.broadband11.iol.cz
Tuším, že podobně se už kdysi spálil i Seznam se svým freemailem.
"Nerozbitné pole", které se jaksi ehm, rozbilo.
On ten Google nebyl úplně mimo, když založil svou architekturu na komoditním hardwaru. Od té doby se zjistilo, že to byla geniální myšlenka.
-
MasoxCZ (neregistrovaný) ---.ipv6.broadband.iol.cz
Jen pro zajímavost... v době kdy Alza vznikla, jaké konkrétní jiné řešení, pro daný účel použitelné a, pokud vím, tehdy snad ještě studentem zafinancovatelné, by náš regionální svatý expert doporučil? Protože architektura systému se snadno mění v době návrhu, trochu hůř u rozjetého projektu ve výstavbě, v malé produkci už jdou změny poměrně dost ztuha, a jakmile to vyroste do rozměrů dnešní Alzy, znamená to nasypat desítky milionů do druhého datacentra, na něm rozběhat novou verzi, a pak to buď přemigrovat s odstávkou (což obchodně může dost bolet, když je dat hodně, a tady jich hodně bude), nebo to udělat tak aby nový centrum dokázalo zpracovávat objednávky, přidat nějakou formu balanceru, a data od nejčerstvějších přesypat za provozu. A tahle fáze přelívání dat může trvat klidně několik měsíců.
Jenomže udělat to tak, aby balancer mohl provoz házet na nový systém za současného provozu starého, a přitom aby to pro zákazníka vypadalo úplně stejně, je vyšší dívčí a stojí to ranec. Schůdné je to, při výchozí pozici kdy je všechno na jedné hromadě, jedině skrz roztrhání databáze na menší celky a jejich "rozestěhování", jenomže to TAKY "pár mandayů" a hromadu peněz sežere, a přitom se tím "jen" připraví pozice pro další fázi. A dokud to není HOTOVO, padají všechny ty mandaye a peníze do žumpy, a veškerý rozvoj většinou stojí, protože hrabat do původního systému vývojářům a správcům pod rukama, když mají připravit migraci do nového, je koledování si o nakládačku na firemním parkovišti. -
Martin Prokeš (neregistrovaný) ---.41.broadband11.iol.cz
V Alze mají v MS SQL všechno. Úplně. Desítky tisíc uložených procedur, ve kterých je kompletní business logika. Až do takové úrovně, že skladník zmáčkne na svém minipočítači na ruce tlačítko a spouští se uložená procedura v MS SQL.
Viděl jsi někdy peklo? :)
-
jenda (neregistrovaný) ---.net.upcbroadband.cz
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. -
MasoxCZ (neregistrovaný) 193.86.27.---
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 :-)
-
Právě proto, že je Facebook tolikrát větší, může si dovolit na vývoj a support těch open source produktů zaměstnávat nezanedbatelný počet vlastních vývojářů. Totéž platí např. pro Google. Ale Alza je při vší úctě někde úplně jinde, takže nelze z toho, že Facebooku nějaký model dobře funguje, automaticky usuzovat, že Alza by to měla dělat stejně.
Na druhou stranu ale to, že je projekt open source, ani zdaleka neznamená, že si k němu nelze pořídit placený support se všemi obvyklými službami.
-
Ono dost záleží na tom, jak se ten hardware skutečně chová v praxi. Ono když hardware lže, tak toho není až tak mnoho, co můžete dělat. Taky je problém, že vždy bude určitá pravděpodobnost, že se Vám chyby sejdou a stejně budete mít výpadek. Jedná se o jedno z poměrně špatně objasněných témat a na jakékoliv výpočty potřebujete model a podle toho, co vím, tak ty modely můžou mít hodně odlišné či přímo protichůdné výsledky a to stačí jen drobný rozdíl v předpokladech.
Co hlavně všichni zapomínají, že mít jen jednoho nebo dva zasvěcené databázové adminy v miliardovém podniku je tak trochu málo. Jeden na dovolené, druhý onemocní a hned máte dobu obnovy + 1-2 dny v optimistickém případě, kdy se admin dopraví z dovolené zpět do země resp. se připojí přes remote odněkud a instruuje lidi ve firmě.
Myslím, že Google to prostě řeší tak masivní redundancí, quorem/ rozhodnutím většiny (bloků dat) a navíc počítají s určitou chybou prakticky na denním pořádku, že to jsou úplně jiné podmínky. Alza je oproti Google jako pískoviště proti písáku. Google zaměstnává řádově více inženýrů a administrátorů, než o čem si Alza může nechat zdát. V Alze navíc asi nebudou mít nutně kompetenci si napsat jak databázi, tak distribuovaný storage a to nemluvíme o tom, že nemusí dávat smysl něco takového implementovat - prostě protože je levnější jednou za pár let mít 1-2 dny výpadek. Tak holt mají dostupnost "jen" 99,95% (když počítám jednou za tři roky, tak to zhruba na těch 27 hodin sedí) místo 99,999% (jednou za tři roky 15 minut výpadek).
Díky za zkušenosti. Taky mám dojem, že např. Red Hat má lepší podporu než Microsoft, ale zatím nemůžu moc doporučit přeprodanou podporu od HPE co se týče Red Hat. Jako problém se vyřeší, ale přímo Red Hat reaguje daleko svižněji i když by podle smlouvy nemuseli. HPE má dost krkolomné support procesy.
-
MasoxCZ (neregistrovaný) ---.ipv6.broadband.iol.cz
"Prispevku jsem dal "plus", nicmene okomentuji "co funguje nemen"."
V původním znění s titulky "if it ain't broken, don't fix it".
Jenomže některá (dost pravděpodobně všechna) řešení při svém růstu narazí na strop, který nelze prorazit prostým nahrnutím dalšího železa, protože prostě pro danou architekturu dostatečně výkonné železo neexistuje nebo není jak obejít úzké hrdlo. A pak je to řešitelné jenom změnou architektury, která ovšem kromě nákladů zpravidla má své vlastní v trávě nastražené hrábě, třesoucí se touhou aby na ně někdo pořádně dupl. -
Pupik (neregistrovaný) ---.cust.vodafone.cz
Otázka je, kde se opravdu stala chyba. Jestli vznikla chybou diskového pole, tak by to replikace řešila, ale jestli byla chyba již v okamžiku zápisu do transakčního logu na úrovni MSSQL, tak by se vám ta chyba pravděpodobně zapsala do všech replik.
Je těžké teď někoho odsuzovat. Sám to vidím. Jste malá firma a tak vsadíte na nějaké řešení a jak rostete, tak se vaše potřeby zvětšují a vy kupujete virtualizaci, SAN, diskové pole s mirroringem, dáte vše na failover cluster, jen tu databázi překopat na jiné řešení by bylo peklo a tak jen doufáte že výrobce databáze bude růst s vámi a zajistí dodatečnou robustnost a servis. Takový Oracle je výkonnostně určitě úplně jinde než Microsoft, jenže finančně taky. Navíc na MS produkty seženete asi nejvíc IT lidí do firmy. -
MasoxCZ (neregistrovaný) ---.ipv6.broadband.iol.cz
Hehe, s kolegou jsme kdysi v souvislosti s něčím objevili dost blbou a nepříjemnou chybu v mechanismu connection poolingu ODBC do SQL serveru, projevující se tím, že na 2000kách po nějaké době provozu (resp po nějakém objemu dat proteklých spojením) otevřená spojení skrz ODBC do MSSQL7 s aktivním connectionpoolingem prostě vytuhla a přestala vracet výsledky dotazů. Já na to narazil, zjistil jak to zreplikovat, a on vyzkoumal v čem ta chyba přesně spočívala.
Že tam ta chyba skutečně je potvrdili do 48ti hodin, ale prohlásili, že by oprava byla moc velký zásah, a že jelikož si nikdo další nestěžoval, tak že to tedy bude řešit až příští verze. A bylo to tam ještě ve 2008R2. -
MasoxCZ (neregistrovaný) ---.ipv6.broadband.iol.cz
"Jeste take museli cely den platit zamestnance kteri nic nedelali, takova drobnost"
Což je samozřejmě nesmysl, protože by je platili tak jako tak.
"Dalsi skody pak vznikou jako nasledne - objednane zbozi prijede, nekdo jej musi prijmout, protoze dopravce nezajima ze nefunguje vas system (pripadne zaplatite pukuty za prostoje), ale to zbozi se pak bude prijimat jeste podruhe, az system fungovat bude. Dusledkem nejspis bude prescasova prace ve dnech po vypadku = dalsi stovky tisic nejmene."
Naskladnění není totéž co převzetí zboží z kamiónu. Ten nacouvá na gate, skladníci to vyloží po paletách a kontrolují čísla a počet palet. Naskladnění probíhá až POTOM, po rozbalení palet, a to rozhodně neprobíhá přímo z rampy. Právě proto, aby krátký výpadek skladového systému neohrozil vykládku. Samozřejmě je otázka, kolik toho ten retenční prostor pobere, a kolik je tedy skutečný prostoj.
"1500 zamesnancu = rekneme 4MKc/den zcela jiste. A vypadek nemusi trvat prave den, muze trvat dele, takze reseni za 15M rozhodne neni drahe."
Jak se to vezme. Výpadek trval 9/8 dne, takže škoda při tomhle výpočtu 4,5MKč (diskutabilních). Zrušených zakázek kvůli prodlení bylo jak velké procento? Troufnu si tvrdit, že do 0,5% (každá dvoustá).
Alza existuje jak dlouho? 15 let? 20 let? A kolik za tu dobu měla takovýchto výpadků?
-
U toho řešení Google ale zapomínáte porovnávat ještě cenu. Nebo-li nevyšlo by Alzu nakonec dráž „Google“ řešení v porovnání s jejich současným řešením, a to i když započítáte náklady na ten výpadek? A porovnávat můžete různé varianty – „Google řešení“ in-house postavené vlastními prostředky v Alze, Alza hostovaná v Google cloudu, a pak také varianty migrace starého řešení Alzy do cloudu vs. Alza startuje v roce 2015 a píše cloudové řešení na zelené louce.
Ono totiž mít geniální myšlenky je mnohem snazší, když na to máte rozpočet.
-
Jeason (neregistrovaný) 212.205.52.---
Premiér podpora od na stojí ranec peněz a rozdíl od standard vidím jen v tom že mi dříve odpoví na email stylem náš technik na problémů pracuje a pak klidne12 hodin ticho.kdyz nemají volného inženýra, který by problém mohl resit, Ani dráha podpora problém nevyřeší.
-
anonym (neregistrovaný) 2001:470:5a94:----:----:----:----:----
Výborně napsaný článek.
Autor v podstatě nastínil jádro problému. Jak mít odolnost ale zároveň si udržet rozumnou pořizovací cenu. Každopádně, to co autor popisuje, zejména s podporou vendora zažívám také, technik z Bangalore často o produktu ví výrazně méně než já. I když můžu ale i napsat, že jeden z velkých vendorů, má technickou podporu o celé námořní míle napřed, ale cena za podporu je samozřejmě zcela jinde a rozhodně nevolá nikdo z Indie.
Řešení jaké má Alza bych neodsuzoval, měli pro to důvod (snad důvodem výběru takového řešení opravdu nebyla jen působivá prezentace místního obchodníka).
-
Já se probíranou tématikou docela zabývám a užil jsem si to taky. Transakční log je fakt sviňa a můžu jen zaklepat do všeho, co kolem mě je, že se mi to ještě nestalo.
Ono když to funguje, tak to vypadá jako docela epesní řešení. Ale jak se podělá něco, s čehož poděláním se fakticky nepočítá, tak je docela pakec. -
MasoxCZ (neregistrovaný) ---.ipv6.broadband.iol.cz
"Pral bych si, aby v nasi firme to fungovalo aspon jako v Alze. V situacim kdy tlak na uspory je takovy, ze vam meni vadne hdd za disky z druhe ruky je, prinejmensim, alarmující."
V tom případě by stálo za to zvážit, že nezlepšit cash-flow prodejem informací na těch discích z druhé ruky nalezených :-D
-
Nechci vám brát iluze, ale moje osobní zkušenost je, že úroveň Premium supportu šla hodně dolů, hlavně ve spojení s přesunem velké části do Indie. Ten propad je fakt mimo diskusi, ještě dva roky dozadu bych vaše tvrzení do značné míry podporoval, dnes už ale spíš ne.
A mimochodem k RAP - absolutně nevěřím, že by měl jakýkoli dopad zrovna na situaci popsanou v článku (jinak ale celkem dobrá služba). -
Scénář je sice nutný, ale zdaleka není postačující. Součástí disaster recovery procesu MUSÍ být i trénik havarijní situace na reálných datech (srovnatelné velikosti, třeba ze staré zálohy). Tím se prověří jak proces, tak doba jeho trvání. Ovšem je to pouze teorie, prakticky by si Alza musela na takové cvičení pronajmout na pár dní srovnatelný HW, uvolnit lidi atd. A jak je správně v diskuzi výše, chytrej je každej až po boji.
P.S. Doufám, že vedení po této události pár chloupků na přípravu pustí :-) -
Q (neregistrovaný) ---.net.upcbroadband.cz
vidim ze je tu pametnik velmi davnych casu.. nerozbitne pole neexistuje. Ale kdyz v v IBM DS nemenite vadne disky, mate blbe udelany RAID a jeste to nechate varit mimo provozni teploty, tezko se pak divit ze to jednou spadne.. pole bylo opravene hned, ale recovery trval dlouho.
-
Noname (neregistrovaný) 194.50.226.---
Haha, vzpominam si na situaci v jedne velke firme, kde se pripravovalo trochu riskantni nasazeni nejakych uprav kritickych systemu. A v ramci planovani nasazeni se resila i otazka, co budou delat zamestanci firmy, kdyz se nasazeni nepovede a nebudou moct normalne delat svoji praci, aby se neflakali. (No nektere napady byla fakt hodne obskurni)
-
MasoxCZ (neregistrovaný) ---.ipv6.broadband.iol.cz
Jojo, a bezva je, když zákazník do helpdesku hodí tiket s kritickou závažností, a popis problému vypadá, jako kdyby ho posílal přes twitter... "něco se rozbilo a něco nejde". Zavoláš tam, a ten kdo to takhle odeslal šel po šichtě domů, nikdo neví co se stalo, co mu nešlo, kdy se to stalo (takže se v logu není čeho chytit), a všem teď všechno funguje a nikdo problém nemá.
-
sep (neregistrovaný) ---.valachnet.cz
Jako DBA musim rict ze preferuju replikaci na urovni DB a ne diskovym polem. Pro ucely DR cele firmy je nicmene nutne mit i tuto moznost, vzdyt spoustu firem ma svuj byznyz zavisly i na souborech jednotlivych uzivatelu. Bohuzel to je fakt. Resil jsem korupce DB z X ruznych duvodu a na ruznych platformach a dodneska se zdraham rict jestli je lepsi Oracle, MSSQL, PostgreSQL nebo MySQL. Samotne DB systemy maji svoje bugy ktere napr. zpusobi korupci standby databaze kterou zjistite az pri pokusu o failover. To se testuje fakt dost blbe. Problemy maji samotne OS nebo jejich komponenty jako multipathing drivery apod. Lost write na storage je fakt blby a na TLogu v podstate neresitelny. Clovek se az na zaklade vlastnich zkusenosti dobere tem "spravnym" resenim. Protoze u DB plati ze verit se neda nicemu. Byt prilis optimisticky znamena ze jednou to padne na hubu. A vetsinou to schyta clovek ktery v dane firme zustal, naockovan optimismem sveho predchudce. V Alze je mozna 1 kriticka DB pro beh cele firmy a jeji nedostupnost muze nastartovat DR proceduru. Ale v korporatech je X systemu navzajem propojenych a dohromady kritickych, problem jednoho systemu DR proceduru nespusti, ale musi se resit in-place. Takze obecne rady nefunguji. Vsichni z nas kdo ctou LUPu si myslim jsou schopni sebereflexe a ze sve praxe si vybavi kde sami udelali chybu v navrhu nebo implementaci nejakeho systemu. Nekdy mam dojem ze vyse zminovani optimiste jsou ti co casto meni zamestnavatele, protoze jsou si vedomi svych lehkovaznych rozhodnuti a potencialnich problemu ktere by se mohli projevit, tak radeji "utecou" a pak tvrdi ze jejich design je ten osvedceny, protoze za jejich pusobeni (kratkeho) se u predchozich zamestnavatelu zadny problem neobjevil. Toz tak. Drzim palce vsem komu zatim jejich kriticky system nepadnul na hubu. Odpocitavani bezi...
-
No nevím, jestli je databáze na mainframu to pravé ořechové.
Jednou jsem měl praxi u AS/400, kde mi "nejvyšší guru" říkal a tady nám běží celé řízení podniku v kterém pracuje 10 000 lidí. Ukázal jsem na velký červený vypínač uprostřed mainframu a zeptal se suše "Co se stane, když ho teď vypnu?". Měli jste vidět ten pohled...
Ono fakt je lepší decentralizace aka Google, a počítat s tím, že si uklízečka přitáhne synáčka, který vám ukradne tři disků z RAID 6ky, než se spoléhat na naprosto neprůstřelná a kulervoucí řešení, které přežijou i konec světa...
-
Sushi (neregistrovaný) ---.net.upcbroadband.cz
Jsem rad, ze se tohle stalo a bude stávat nadále. Jen by to mohlo být častěji :-) Dokud si manažer kontrolující a spravující IT budget neuvědomí, že je potřeba se také podívat na to, kolik je stoji hodina výpadku (Cost of Outage) kritických systémů (pokud vědí které to jsou). Bohužel v našich podmínkách něco jako BIA (Business Impact Analyse) a posuzování rizik je věcí krajně nepopulárni a převládá zde názor "doteď se nic nestalo, tak není důvod k obavám" :-).
Faktem je, že jedno pole je krásný příklad SPOF a vždy bude. Nejde ani tak o technologii použitého HW/SW, nebo zda je to OpenSource nebo komerční produkt. Nelze totiž nikdy vyloučit lidskou chybu, třeba i záměrnou, vedoucí ke ztrátě dat. Aktualizovaný plán obnovy je tedy vždy na místě...Návrh infrastruktury prostě musí odpovídat hodnotě toho, jakou službu zajišťuje v provozu na adekvátní úrovni. Je to disciplína jako každá jiná. Chtěl bych vidět, jak někdo z vás půjde k zubaři, který nabízí nejlevnější služby někde na ulici v zapadlé čtvrti bez pořádného vybavení. To chce hodně odvahy.... :-)
Děkuji autorovi za článek!
-
Dabo (neregistrovaný) 5.170.100.---
Otazka je, jaka skoda realne Alze vznikla. Pokud nekdo zminuje 15 milionu za skutecne redundantni reseni, tak bych se vsadil, ze kdyz se podivaji na mesicni prodeje, tak 15 milionu v zisku neprodelali ani nahodou, to by znamenalo vypadek kolem 300 milionu obratu, mozna jeste vice. Takze mozna nakonec to rozhodnuti riskovat takovy vypadek bylo spravne.
-
fd (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
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.
-
Ivan (neregistrovaný) 165.225.76.---
Taky delam s Oracle a musim rict ze se mi podobna vec stala i na 9i. SGA memory corruption, crash databaze, poskozene redo-logy. Databaze segfaultovala behem media recovery. Jako reseni se nabizelo full restore, preskoceni media recovery & dump dat do nove db. Kvulil casovemu presu a hrozicim ztratam, jsme nakonec jen preskocili media recovery, rebuildovali indexy jelo se dal.
-
lol (neregistrovaný) ---.ipv6.broadband.iol.cz
já sem tedy jen obyčejny BFU PC uzivatel, ale co je to velikosti mnoha TB? 10? 20? 100TB? vic? jak dloho trva na rychle diskovem serveru zkopirovat 10TB? proboha co je to za databazi ktera ma desitky nebo sdnad stovky TB? Nekdo tu zminoval ze databaze obsahuje fotky produktu? to jako vazne? to neni tak ze v databazi je "adresauloziste/fotoprodukt1.jpg"? Ale rovnou cela fotka? jako vazne?
-
zen (neregistrovaný) 185.112.167.---
Především jsem nenapsal, že kdyby byl proveden RAP tak k této situaci nedošlo. RAP kromě jiného umožňuje srovnat nastavení konkrétní aplikace se zkušenostmi, které MS získal s danou aplikací na celém světě. Dále umožňuje posoudit architekturu aplikace a především výstup z RAP dobrý pro vedení a majitele firmy. Dále RAP velmi striktně trvá na nejen na dokumentaci systému (což umožní rychlejší obnovu), ale díky němu se většinou podaří nastavit také interní procesy, takže je jasné a jednoznačné kdo o čem a kdy rozhoduje. Tím je šance, že se například zkrátí čas na proces think time. Není možné aby do procesu řešení "technického" problému zasahovalo zasahoval každý vrcholový manažer jen proto, že si myslí, že IT rozumí. Každý musí mít jasně definovanou odpovědnost a své kolegy, manažery, by měl nechat řešit jejich problémy. Jinak vzniká chaos. Možná někdy někde se díky chaosu něco vyřešilo rychleji než řízeným procesem, ale na to spoléhat nelze.
Co se týká architektury, tak odvolávat se finanční náročnost, je také z jisté části jen alibismus. Firma velikosti Alzy, tedy obrat v desítkách miliard Kč, čistý zisk jistě v miliardách, by si měla svých dat vážit víc.
Nicméně, pokud si kdokoli myslí, že má architekturu systému takovou, že pád jím spravovaného systému je vyloučený, tak je hodně naivní. Stačí se po světě podívat po pádech velkých systémů. O středních a malých firmách nemluvě. Proto je důležité mít připravené scénáře jak postupovat když dojde k nejhoršímu. A z tohoto pohledu si myslím, že je velmi důležité nebránit se pohledu na systém odborníků, kteří nejsou zatíženi vazbou na managment firmy nebo historií vývoje systému. Takovýto pohled může systém zlepšit, rozhodně ho nezhorší. -
Tom (neregistrovaný) ---.mraknet.com
pěkné, setkání s enterprise procesy na vlastní kůži.
Na českém trhu existuje řada integrátorů MS technologií, škoda, že jste více nerozhodili sítě, MS si běžně najímá subdodavatele a půjčuje si lidi, není problém jít přímo, pár lidí bylo k dispozici, někdy i oprava je možná.
Raid pole jsou peklo, extrémně uzavřené technologie a neřešitelné problémy. Na DR zpravidla není přenosová kapacita, tenhle svět znám :)
-
asdasd (neregistrovaný) 64.43.36.---
s tim bych mirne souhlasil, z toho co jsem cetl je jasne, ze tady by to chtelo primy pristup k vyvojarum
spis me ale napadlo, ze podle dostupnych informaci se to teoreticky muze stat kdykoli znovu - alespon jsem tam nedekodoval informaci, ze SW problem radice byl potvrzen a hlavne opraven!
-
radeji_ne (neregistrovaný) 194.213.208.---
Takze Alza vlastne zadne DR nemela (a nejspis nema). Tohle co popsal, je absolutne neuveritelne, spolehaji na to, ze to proste pojede a nestane se nic neocekavatelneho. A to jsem doted myslel, ze naprosty zaklad je db replikovat online nekam jinam, ukladat logy a sem tam udelat dump/snapshot. No, nevadi, evidentne nemaji zadne IT, jen lidi, co (nejak) pisou kod.
-
MasoxCZ (neregistrovaný) ---.ipv6.broadband.iol.cz
Záleží, jestli se zprasí už před odesláním k uložení do replik, nebo až při fyzickém zápisu na médium. V případě a) jseš na tom jak Baťa s dřevákama, v případě b) by služby v clusteru měly dál běžet proti zdravému nodu a na nemocném si to opravíš replikací ze zdravého. Ale pokud máš dvě identická pole a řadič má chybu ve firmwaru, která se manifestuje v důsledku toho co přiteče k uložení, jseš slušně řečeno v hajzlu, protože se to zapíše do obou replik a systém o tom vůbec neví, dokud se tam znova nekoukne, načež zjistí že zdravá kopie neexistuje a celý to padne na hubu.
-
MasoxCZ (neregistrovaný) ---.ipv6.broadband.iol.cz
"Co je ale nezajímavější je, že takoví amatérští rádcové v průměru neradí o moc hůře než specialisté.
A někde jsem četl, že specialisté s pletou vůbec nejvíc, chybí jim nadhled a selský rozum."Nassim Nicholas, Černá Labuť. Zajímavé čtivo, i když se sám několika vlastním pastem v původním vydání nevyhnul a právě těmto svým chybám se věnuje v dodatku, který má rozsah skoro poloviny prvního vydání.
"Nebo jej nenapadlo, že by mohl být dobrý nápad, starší data již uzavřených objednávek uchovávat v jiných tabulkách, aby obnova funkčnosti na které závisí provoz byla rychlejší, když nebude vidět historie po několik dní nikomu to celkem vadit nebude."
Jasně, ale tenhle úklid mívá až překvapivě vysokou režii, takže pokud s tím není počítáno v původním návrhu, jeho pozdější zavedení do velké databáze může být bez velké modernizace neproveditelné. Takže se s tím pak čeká na "nové železo, které to už zvládne levou zadní". Viděl jsem to víc než jednou.
"Zde např. specialista neslyšel o naprosto běžné možnosti klonování databáze za chodu."
Ale notak, autor píše že slyšel, ale z nějakého důvodu (tipuju finančního) tato cesta zvolena nebyla. Protože s ohledem na nutnost platit licence dvojmo (u MSSQL se u active-passive platí jen za aktivní node, zatímco u active-active za oba včetně CALů a Internet Connectoru), což v kombinaci s druhým polem a druhou sadou SSD vychází, ve velmi konzervativním odhadu bez dalších podrobností, tak na 15 mega minimum plus provozní náklady.
A jelikož, pokud jsem články pochopil správně, za těch 27 hodin neselhávaly objednávky, nýbrž "jen" odbavování zakázek a tedy doručení, což znamená že škody z neuzavřených obchodů nevznikly za celou dobu výpadku, nýbrž jen v nějakém zanedbatelném procentu, dá se předpokládat že to byly VELMI rozumně uspořené náklady. Protože s ohledem na obvyklé marže, jak už tu někdo psal, by muselo dojít k výpadku cca 300+ megaKč obratu. Což, pokud se správně pamatuju, je v případě Alzy kompletní výpadek na cca 2 měsíce. -
Hele s těmi DR testy je to takové všelijaké...
Ano, v řadě firem se DR testy dělají, jenže vždy to jsou testy řekněme očekávaného stavu typu "mám dvě datacentra, jedno natvrdo spadne, jak mi to přejde do druhého" nebo "spadlo mi pole, jak to obnovím ze zálohy". Tohle je samozřejmě užitečné, jenže pořád tu máte obrovskou variabilitu a podle zákona schválnosti se skutečný výpadek trefí zrovna do situace, která nikoho nenapadla (ve stylu spadne X způsobem, který ještě nikoho nenapadl a jako jediný existující naruší nejen Y, s čímž se počítá, ale i Z).
Přijde mi, že i v Alze šlo o podobnou situaci - selhala věc, branná za velmi slušně redundantní a ještě tím nejhorším způsobem... Jistě se poučí, ale to neznamená, že nevyplave něco dalšího :-( -
xsouku04 (neregistrovaný) ---.ip.nej.cz
A průběžná replikace databáze za chodu? Vždyť to přece umí i 10 let stará mysql a používá to kde jaký amatér. Nebo je to o tom, že alza chtěla ušetřit za další licenci?
Pokud máte replikaci, není úplně nutné aby to běželo na tak drahém hardwaru, tedy dal se ušetřit barák za Prahou. Nebo spíše za stejné či menší peníze můžete mít několik aktuálních kopií všech dat. Navíc číst lze pak v některých případech z vždy aktuálních replikací, čímž se sníží zátěž hlavního serveru.
A v případě havárie hlavního serveru je jen vypnete a jako hlavní databáze začne sloužit nějaká replika. Ostatní klony překonfigurujete tak, aby klonovali od jinud.
Spoléhat se jen na noční zálohy a že se nikdy nestane žádná vážnější chyba mi přijde fakt amatérské.
Ale když má někdo nutkání utrácet u Microsoftu, který ani u SQL není jedničkou, asi mu je fakt těžké pomoci. -
Noname (neregistrovaný) 194.50.226.---
Znam velke firmy, ktere nektere pomerne kriticke databaze maji take jen jednou. A to na zaklade racionalniho vypoctu nakladu selhani a nakladu na redundantni databazi. (Je fakt, ze zrovna tahle databaze nema primy dopad na klienty firmy, takze nasrani pri vypadku by byli hlavne zamestnanci.)
-
Mates (neregistrovaný) 194.50.226.---
Pokud jsem článek dobře pochopil, tak finální problém byl v poškození redo logů a nemožnost provést recovery.
SQL server má možnost provádět redo log repliku (i když do SQL server 2012 jen sériově), od 2016 dokonce paralel redo.
Pro takto kritická řešení se používá uložení redo logů odděleně od datových souborů db na jiné fyzické disky, ideálně na jiném stroji, a pak ještě replika redo logů (někdy i vícenásobná), opět na jiném stroji (jiných strojích). Otázkou jsou samozřejmě rozpočtová omezení... -
Rudolf Dvořáček (neregistrovaný) 217.33.113.---
Proc ne, pokud ma instance nakonfigurovan FILESTREAM, ktery se zalohuje s celou databazi. To hned data narostou. Ukladat binarni data do FILESTREAMU ma sve vyhody. Zaloha je provedena kompletne, pri pristupu k binarnim datum nemusi aplikace kontrololovat existenci dat, zda k nim ma opravneni, apod. Bohuzel to zvysuje cas pri zalohach a obnove.
-
fd (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
A z te vasi zakazky vyrobite objednavku smerem k dodavateli jak? Pak z toho vyrobite prijem? A vydej? A faktury? Takze se da rici, ze vy nechapete, ze proces prodeje nejsou zdaleka jen nejake objednavky od zakazniku. Pominul jsem pochopitelne spousty dalsich veci - reklamace, vraceni zbozi atd atd. To vse musi mit navaznost do ucetnicvi, skladu ...
-
Chulda (neregistrovaný) 194.108.1.---
Což je právě ten kámen úrazu - především očekávají a komentář p. Kubečka na to poukazuje.
Kdyby si přečetli podmínky smlouvy, nemuseli by být nemile překvapeni ve svém očekávání.
Kolegové si zaplatili gold support u sunu (tenkrát) a byli nemile překvapeni, že se to řeší až v pracovní hodiny.
A v podmínkách skutečně bylo, že reakce supportu je do jedné hodiny, ale řešení v pracovní hodiny. -
Ja teda nevim, jestli MS SQL umi neco jako WAL shipping. V Showmax (https://tech.showmax.com) pouzivame pqsql, streamujeme logy a tim je mozne drzet _geograficky_ oddelene zallohy, ze kterych se da obnovit 'point in time'. (A teda taky mame psql per mikro-service, takze recovery je jednoddussi, ale to neni podstatne).
Odkazy: https://www.pgbarman.org ; https://www.postgresql.org/docs/current/static/continuous-archiving.html -
JD (neregistrovaný) 185.50.127.---
60MKc obratu za den pri hyperoptimistickem zisku 10% dela 12MKc za 2 dni vypadku.
Porovnejte to s cenou 15MKc (+- desne moc) za reseni s nutnou obnovou cca kazdych asi 5 let. Takze pokud se Alze nestane podobny vypadek vice nez jednou za 5 let, je to ekonomicky nesmysl.
Ale to jsou hausnumera. Ten usly denni zisk je silne prestreleny, na druhou stranu tu nejsou ztraty ze ztraty duvery. -
MasoxCZ (neregistrovaný) ---.ipv6.broadband.iol.cz
"já sem tedy jen obyčejny BFU PC uzivatel, ale co je to velikosti mnoha TB? 10? 20? 100TB? vic? jak dloho trva na rychle diskovem serveru zkopirovat 10TB? proboha co je to za databazi ktera ma desitky nebo sdnad stovky TB? Nekdo tu zminoval ze databaze obsahuje fotky produktu? to jako vazne? to neni tak ze v databazi je "adresauloziste/fotoprodukt1.jpg"? Ale rovnou cela fotka? jako vazne?"
1) netvrdím že to tak skutečně mají
2) právě pro ukládání obecných dat (třeba právě obrázků, videa. audia) do databází slouží typ BLOB (a ne, s Kaplického chrchlem to nesouvisí)
3) databáze je v tomto kontextu chápána jako "báze dat". V Alze jsem nikdy nedělal, takže nevím, jestli to konkrétně oni mají jako monolit, nebo konglomerát více databází, případně jako mix n databází a hromady souborů, ale viděl jsem spoustu řešení, kde např. záznamy z kamer byly ukládány jako BLOBy přimo do databáze. Bylo to kvůli tomu, aby se snížila režie souborového systému. Celkem kontraintuitivně, čím byly ty soubory menší a početnější, tím byl výkonový přínos větší. -
Jak už jsem napsal v původním příspěvku, podobné "historky ze zákulisí" mají mizivou hodnotu, ať už pocházejí z kterékoli strany, protože těžko mohou poskytnout statisticky relevantní obraz. Zákazníci jsou různí, od perfektně spolupracujících až po "máte to rozbité, tak to koukejte honem spravit, a já tu nejsem od toho, abych vám něco zjišťoval" - a stejně tak je to i s lidmi na supportu. Jen bych zdůraznil to, co jste - možná nechtěně - zmínil i ve svém příspěvku: "...má odvádět to, za co je placen". Někteří zákazníci mají totiž dost zkreslené představy, jakou službu si vlastně platí, jaké jsou její podmínky a na co mají nárok. A pak se holt diví a píší do fór podobné zhrzené výkřiky jako vy.
-
TNP (neregistrovaný) 185.60.104.---
Tak vymlouvat se na podporu výrobce databáze při opravě transakčního logu je jen okraj ledovce, po kterém to řešení klouže celé dolů. Zvlášť , kdy jde o MS, který funguje transparentně a jejich technologie pro eCommerce zrovna určeny nejsou. Po prohrané bitvě se generál nenajde..... většinou. Spíš se naleznou vykladači, kteří hledají příčiny a následky a v zásadě se většinou neshodnou. Technická příčina na úrovni poli je jistě jen obětní beránek, protože jinak je vše úplně v pořádku. A toto se nám stává pouze jednou za 10 let :-). Pokud největší ecommerce poskytovatel spoléhá na to, že má zřejmě veškerá uživatelská a produktová data v jedné obří databázi (lhostejno v kolika schématech a instancích), na kterou spoléhá, že nemá SPOF, je špatně něco někde jinde. Pokud se zastaví celá společnost díky výpadku jediné databáze, je to pravděpodobně jev. který má vést majitele k poznání, že současná vývojová cesta, přílišná agilita a obdobné řešení může společnosti způsobit nejen obří ztráty, ale i způsobit ztrátu reputace. Možná je čas na změnu, nejen architektury, ale i it organizace. Kdo z nás by nějaký výpadek Alza už na vlastní kůži nezažil. Zastaví se mobilní aplikace, sklady, logistika.....tramvaje. A peníze netečou!
Doufám, že to uvedené databázové architekty vede k úvaze, že se nevyplatí myslet izolovaně na úrovni jedné technologie, ale, že celé monolitická struktura řešení je špatná vize a je třeba navrhnout smysluplnou architekturu, což neznamená jen povýšit verzi programovacího jazyka.
-
nhlfan (neregistrovaný) ---.95-102-196.t-com.sk
ked neviem o com hovorim radsej mlcim. Keby kupili rovnaky storage v druhej lokalite (neveim ze maju svoje datacentrum, pouzivaju verejne), mozu zacat zrkadlit absolutne bez odstavky. Ak by chceli potom automaticky failover, je to mozno o kratsej odstavke a rekonfiguracii clustru, ale nic velke
-
in (neregistrovaný) ---.cust.selfnet.cz
Takže všude jinde jsou ty diskuze věcné, odborné, slušné, ... :-) Svým příspěvkem přesně potvrzujete, jak to s těmi diskuzemi je. Máte pocit, že je rozumný, věcný, protože patříte k těm rozumným a on je přitom naprosto mimo. A samozřejmě si to vymluvit nenecháte. Docela by mě zajímalo, jak diskutují Švédi, Noři, Albánci, Iránci, Portoričané, ... člověk se nesmí uzavírat a nepochybně máte tuny zkušeností. Počtěte si, jak třeba v Norsku řešili hejtery. A to by člověk myslel, že jsou jen tady, že. Já osobně to vidím s píše tak, že jsou lidé znalí a ví to, jsou lidé znalí a neví to a nebo se bojí to dát najevo, lidé, co si myslí, že jsou znalí, lidé, co ví, že jsou neznalí, ... no a tak je to všude a zvláště ta třetí varianta je problematická. Většinou z těch se rekrutují blbci různého ražení. A tak bych prosil, nenalepkujte mě, nenálepkujte Čechy, nenálepkujte žádný národ, protože to pak zase nemá daleko k různým ideologiím, které nakonec nejsou přátelské ani k původním zastáncům. V historii je příkladů dost.
-
JD (neregistrovaný) 185.50.127.---
1-5% obratu je hezka vec. Jenze kdyz vam v silne konkurencnim prostredi bude dychat na zada konkurence, ktera dava jen 0.5% nebo mene, tak vas prevalcuje.
Ano, je velka pravdepodobnost, ze se konkurenci neco podela a odpadne. Ale kdyz tech konkurentu je vic, tak pravdepodobnost, ze se minimalne jednomu z nich zadari a prezije to bez poruchy velika, je to prakticky jistota.
PS: tim se tohoto setreni nezastavam, jen je uvadim do realneho sveta. -
MasoxCZ (neregistrovaný) ---.ipv6.broadband.iol.cz
Ono se to nezdá, ale dost pravděpodobně jo. Ke každému artiklu jsou fotky, popisy, spousta dalších dat (dodavatel, historie cen, čísla smluv a dodávek), plus je potřeba držet podklady k sortimentu i hluboko do minulosti kvůli náhledům z historie zakázek, když se zákazník bude chtít mrknout, co si to vlastně před lety koupil a čím to dneska nahradit.
Aby zákazníci měli přístupnou celou svoji historii, musí taky celá být v databázi.
Pokud je to všechno v jedné databázi na jednom serveru, jen rozházené do tabulek, určitě to není z dnešního pohledu šťastné řešení, ale dovedu si představit, že k tomu na začátku byl důvod (např. nasazení i pro komerční použití bezplatného SQL Express, tehdy MSDE, který měl vždycky omezení na počet obsluhovaných databází a počet příchozích spojení nebo souběžně zpracovávaných dotazů, což se časem samozřejmě měnilo a rostlo) a dokud byla Alza malá problémy bylo řešit modernizací hardwaru, asi to stačilo a hlavně to muselo být řešení v začátcích ufinancovatelné.
Ale změna, byť by to mělo být jen rozházení monolitické databáze do dílčích a rozestrkání na víc instancí databázových serverů, není tak jednoduchá jako vymyšlení jak to udělat líp. -
Lol Phirae (neregistrovaný) 2001:470:6f:----:----:----:----:----
jiste jde vkladat primo obrazkt ale na aplikacni urovni (web) to bude fungovat jak?
Např. :-P
-
rotr (neregistrovaný) ---.cust.nbox.cz
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.
-
fd (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Ja bych prozmenu mohl prihodit desitky konkretnich pripadu, kdy support dostal daleko vic, nez vubec mel narok zadat, ma primy pristup k zakaznikovi, do logu, databazi atd, a presto neudelal vubec nic, reseni nakonec zustalo na IT dotycneho zakaznika.
Zrovna nedavno se mi stalo, odpoved placeneho supportu "to delate spatne" .. .a jak je to spravne? "to si najdete v dokumentaci" ... nakonec se mi podarilo pres vlastni kontakty najit cloveka (ktery s dodavatelem ma spolecneho jen to, ze je take "stastnym" uzivatelem jejich produktu), ktery jen potvrdil, co jsem vedel - ze zadna takova dokumentace neexistuje, ale poradil mi, protoze narazil na stejny problem - a stravil nekolik dnu reverznim inzenyrsvim a zkoumanim toho, v cem je zakopany pes.
Takze si ten vas vykrit strcte vite kam, nebot ten kdo je placen je ten kdo ma odvadet to za co je placen. Zakaznik neni od toho, aby resil to, co ma resit onen support, a kdyz neresi, neni duvod jej platit.
-
nhlfan (neregistrovaný) ---.95-102-196.t-com.sk
Pouzivat vobec MS SQL server pre taku mission crtical aplikaciu... No ale proti gustu..
By ma celkom zaujimalo co bol ten “enteprise class storage”. Anway v dnesnej dobe kde sa kladie priorita na realse verzii novych funkcionalit, aj naozaj enteprise pole typu EMC VMAX, IBM DS8000 alebo HITACHI je proste SPOF. Aj pre tieto technologie sa predavaju mirroring funckionality, kde storage replikuje (moze aj synhronne) data na storage v druhej lokalite.
Za kolko alza zarobi na skutocne DR riesenie? Myslim ze za toto by mal letiet COO/CIO/CTO ci aku funkciu tam maju aj s auditorom. Klasika hlavne ze maju High Availability, ale na DR nemysli nikto.
Je mozny aj sync mirroring na urovni MS SQL, samotnyn autorom spomenute Always On Groups, aj ked je to dost zla napodobenina Oracle Data Guard (ktory je sam o sebe nic moc technology).Snad to bude aspon na cas vystrahou podobnym firmam, ktorym je luto mat riesene v dvoch nezavislych DataCenters na dvoch roznych storage... (a idealne mat aj tretiu pre quorum clustra).
Na druhej strane za posledny rokmje aj dost vypadkov v cloudoch... a tiez parkrat nezafungovalo DR
-
Cx (neregistrovaný) 93.157.130.---
Jsem obyčejný devopák, ale kolem pár systémů jsem prošel a vždy byla limitujícím faktorem cena/čas. Když firma začíná s nějakým vývojem, tak neví, zda bude vůbec úspěšný. Během vývoje se z nezkušenosti nebo čistě z časového pressu udělají rozhodnutí, které jsou nekompatibilní s růstem služby. Nakonec skončíte s kódem za desítky, možná stovky milionů, který je závislý na jediném připojení k databázi. Interně je systém přes knihovny, frameworky, optimalizace i špatná rozhodnutí tak propojený s jednou databází, že není možné ho upravit, aby používal nějaké více failure friendly řešení. Máme databáze, které byly navrženy kolem replikačních algoritmů jako CouchDB nebo Hadoop, ale kód je tak prolezlý vazbami na jednu konkrétní databázi, že bez obrovských investic není možné s tím hnout. V týmu k tomu většinou ani není vůle a když už se někdo pokusí, dřív nebo později narazí a sám to nezvládne. Nakonec se prostě s nějakými problémy počítá. Když se to komunikuje správně, tak to moc škody neudělá.
-
nhlfan (neregistrovaný) ---.95-102-196.t-com.sk
oracle redolog multiplexing je tak doby proti user chybe (takze je pekne ked ma db dve kopie) a na nejakom lokalnom serveri s malou DB. Vyzera ze im naozaj padol storage controller a nestihol zapisat data z cache na disky, cim vznikol takzvany lost write a to je smrt. Ked sa to stane, kedze do transakcneho loku pise db skoro da sa povedat nepretrzite. Keby mali multipliexing na rovnakom storage, zrejme to chyti oba zapisy (ktore databazova instancia vykonava paralelne) a su tam kde boli...
-
ms sql hračička (neregistrovaný) ---.net.upcbroadband.cz
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. -
ajtik (neregistrovaný) ---.static.masterinter.net
Máte pravdu v tom že Multipath je na spoustu systémech problémovej, ale v případě Windows pokud je storage od renomovaného výrobce který dodal MPIO drivery jsou funkční. Provozoval jsem storage s FC kdy jsme postupně z 8 linek degradoval až na jednu a zase postupně zprovoznil všech 8 a jak OS kde byl boot form SAN tak databáze a aplikace s úložištěm na storage vše šlapalo jak mělo ani jedno selhání jen v logu zápis o nefunkční lince a atd. Stejně stabilní to bylo u RedHat a Centos, ale u Ubuntu to bylo tak 50:50 někdy neustál ztrátu jedné linky někdy ustál ztrátu poloviny linek. Taky záleží na FC HBA kdy Qlogic se mi zdál stabilnější než Emulex.
-
ajtik (neregistrovaný) ---.static.masterinter.net
Jenže jak Facebooku tak Googlu je uplně jedno když jim zdechne nějaká malá součást, protože v jejich strukturách je na každou malou funkcionalitu několik set počítačů v clusteru jak aplikačním tak datovým atd a když se to náhodou posere tak nefunguje třeba chat pro jeden stát, a oprava spočívá v tom že bud obnoví automaticky data ze zálohy nebo přepnou funcionalitu na jiný clustery. koukněte se na dokument o Googl Datacentrech tam prostě vemou server vyhodí ho ze systemu a zapojí jinej, přes PXE nabootuje zavaděč proběhne bezobslužná instalace a server se zařadí do clusteru a stáne si data co potřebuje. ano máj to na opensorce ale umí to i korporátní placenej software. open source neni žádnej zázrak ani spása.
-
ShadowMaster (neregistrovaný) 89.24.38.---
Něco mi tu zasmrada. Z opačného soudku. Každý bere cache (nvram) jako něco co se smaže a zhroutí po pádu controlleru. Ale ví někdo jak to funguje? Když už byl zápis commitnuty z cache směrem k sql serveru, tak byl ok. Je pak na controlleru kdy zapíše obsah na disky. Vždy se to dělá na velkých polích tak, že ta cache je tam minimálně ve dvou kopiích a je replikovana. To aby pád controlleru neznamenal zastavení provozu. A i kdyby celé pole padlo a data zůstaly v cachich tak prvni věc je zapsat data z cache na disky, kdyby ne tak to nenajde s nějakou hlaskou a volá se vendor. Pokud by padl jeden controller a bylo by něco s nvram ve startovanem controlleru kontrola by na to přišla a opět by to stoplo, pokud ne, nvram se smaže a jede se dal, protože to obsloužil běžící kontrolér. No a při mirroringu na další pole je ten zápis hazeny na druhé pole při zápis do nvram a ne při zápisu na disky (teda očekával bych za ty dve Tesly) alespoň synchronní mirror. A v případě redologu či jiných transakcnich dat jsem měl dojem, že je vyžadováno aby byla uložena jinde, než na místě kde jsou produkční data, proboha, stačilo by i na lokálním disku odehrávanym do backup řešení. Asi tak. Musel jsem se z toho vypsat. Když už si najímají odborníky tak at to delaji z různých oblastí, může se jim to vyplatit.
-
Starous (neregistrovaný) ---.cust.vodafone.cz
nestřílejte specialisty, ale člověka co tam dal SQL server od Microsoftu. Ze všech databází co znám je nejpomalejší a má nejzvrácenější logiku. Jinak se imho jedná o problém návrhu že jsou aktivní data v jedné obří databázi se starými objednávkami ale to je oproti selhani cele db detail. Btw proč nemají active-active cluster?
-
Uložené procedury také můžete testovat pomocí jednotkových testů. Proč by to nešlo? Akorát na to asi nenajdete hotový framework, takže bude potřeba napsat si k tomu můstek do nějakého testovacího frameworku v jiném jazyce. Buď to můžete testovat na úplně prázdné databázi, vždy před testem naplnit vhodná data, spustit uloženou proceduru, zkontrolovat výstupy a rollbacknout transakci. A nebo můžete začínat už s databází s testovacími daty a pokračovat stejným způsobem – to bude mít tu výhodu, že tam nejspíš budete mít větší množství testovacích dat, takže těch testů asi napíšete víc, protože se zmenší ta nezábavná činnost v podobě přípravy testovacích dat.
-
Jako sorry, ale jedná se pořád pouze o obchod, který bere objednávky.
Takže bych obchod rozdělil na nějakou víceméně RO část (typu zobrazování produktů, diskuse a podobné blbosti).
A zmigroval bych až samotné tvoření objednávek, expedici, tracking pošty atd.
Ono fakt mít databázi v řádu TB na OBJEDNÁVKY je dobrý hnus.
Proč se nerozdělí samotný obchod, kde je plno obrázků, komentů, specifikácí a obchodní část, která je kritická? Je fakt nutné mít TB databázi, která pak bude čekat řadu hodin na obnovu a mezitím bude celý kolos stát?
Sorry, ale i kdyby se to mezitím duplikovalo do nějakého .txt souboru (ty objednávky) jen aby to jelo, než najede obnova hlavní databáze, tak by to bylo lepší řešení.
Prostě pořád nechápu, proč obchod, pitomý obchod potřebuje terabajtovou databázi na objednávky, opakuji objednávky?! Pak trvá obnova dva dny... Proboha rozdělte to na super duper "zobrazovací" pasivní část obchodu a to, co je nezbytně nutné pro objednávky, expedici atd.
Je to, jako by někdo (pejsek a kočička) si navrhli eshop, narvali vše do jedné databáze i s obrázky produktů, komenty, popisky, pak najednou má pejsek úspěch, vyroste z toho velký business a ono ups. je to vše pořád splácané v jedné databázi (navíc de*bilní, tedy DB2 je taky dobrý bastl a Oracle je pro změnu arogantní) a pak se dělá obnova půl roku.
A když nemá IT firma investice do IT zařízení, tak ať vyhodí nějakého IT manažera, ono ten dům za prahou a dvě tesly to se rovná plus mínus platu jednoho managera, který v případě fail overu stejně nakonec pak po vás bude chtít něco v excellu, protože nic jiného neumí.
-
MasoxCZ (neregistrovaný) ---.ipv6.broadband.iol.cz
Jojo, a bezva je, když zákazník do helpdesku hodí tiket s kritickou závažností, a popis problému vypadá, jako kdyby ho posílal přes twitter... "něco se rozbilo a něco nejde". Zavoláš tam, a ten kdo to takhle odeslal šel po šichtě domů, nikdo neví co se stalo, co mu nešlo, kdy se to stalo (takže se v logu není čeho chytit), a všem teď všechno funguje a nikdo problém nemá.
-
nhlfan (neregistrovaný) ---.95-102-196.t-com.sk
to sa mi paci :) Ale aj IBM DS som videl vselico. Silent data corruption na DS8300, corruption dat pocas patchovania firmware a tak... A aj IBM DS ma option PPRC, abysa pekne zrkadlilo na druhe IB DS ;) Dnes mozno radsej 2x storwize s metro mirror, ako len jedno DS ako SPOFZ
-
nhlfan (neregistrovaný) ---.95-102-196.t-com.sk
ked niekto obhajuje usporu penazi ALZA, neuvedomuje si to, ze alza kludne mohla stratit niekolko hodin objednavok. Teraz zrejme storage poskodil transakcny log v case vypadku, system spadol a uz sa nedarilo recovery. Pri obnove z full zalohy a vykonani incomplete recovery sa ale mohlo stat, ze by sa podarilo recovery po cas 1-2h pred vypadkom. Tym by stratili 1-2h objednavok klientov, ktori im poslali peniaze. Muselo by to narocne parovat z billingoveho systemu a prachy posielat naspat, lebo by zrejme nevedeli za co im ich ludia poslali. Zda sa ze teraz mali stastie a stratili objednavok par, ze sa o tom ani neoplati rozpravat.
takyto system v takej velkej firme proste potrebuje syncronnu repliku do druheho DataCenter -
Klik je cvik (neregistrovaný) 84.19.86.---
Reakce na reakci ? A kde jsou informace na které by bylo možné z tohoto místa reagovat ? Je přeci známo že jednotlivé oblasti IT rozvoje spolu těsně souvisí a navzájem se ovlivňují a teprve propojením těchto oblastí do jednotného pohledu je možné získat celkový ,,obrázek,, o chybě ..
-
xsouku04 (neregistrovaný) ---.ip.nej.cz
Co je ale nezajímavější je, že takoví amatérští rádcové v průměru neradí o moc hůře než specialisté.
A někde jsem četl, že specialisté s pletou vůbec nejvíc, chybí jim nadhled a selský rozum.
Zde např. specialista neslyšel o naprosto běžné možnosti klonování databáze za chodu.
Nebo jej nenapadlo, že by mohl být dobrý nápad, starší data již uzavřených objednávek uchovávat v jiných tabulkách, aby obnova funkčnosti na které závisí provoz byla rychlejší, když nebude vidět historie po několik dní nikomu to celkem vadit nebude. -
asdasdasd (neregistrovaný) 64.43.36.---
ja predchozi prispevek pochopil tak, jestli ukladat obrazky primo do DB nebo jen metadata.
jiste jde vkladat primo obrazkt ale na aplikacni urovni (web) to bude fungovat jak? to budete vkladat obrazky primo do html nebo budete emitovat jakesi temp soubory, ktere pak budete linkovat z html (i kdyz treba s nejakou cache apod)... zminim jen tri pismena...CDN :D
-
OBK (neregistrovaný) ---.net.upcbroadband.cz
Zdravím. Nemám ALZU rád, ale mám rád lidi, kteří tam pracují v IT. Osobně bych nediskutoval a šel na ORACLE. Z léta, co jsem pozoroval a prodával clustery na téhle DB, jsem jim uvěřil. Buď chcete spolehlivost, nebo nízkou cenu. Chyba se stala. Při volbě platformy. Váš business už není start-up, myslím.
-
fd (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
"Nejprve musí padnout rozhodnutí o tom, zda se vydáme cestou pokusu opravy, nebo obnovy."
To rozhodnuti ale ma padnout davno pred tim, nez k jakekoli zavade dojde, rika se tomu disaster recovery plan. V okamzik jakekoli vypadku pak jde jiz jen o identifikaci toho co selhalo a "tupy" postup v souladu s tim planem. Bezne se to dela napriklad tak, ze se stanovi nejaky jednoznacny casovy limit na odstraneni problemu tou nejistou opravou, a pokud se nezadari, automaticky nasleduje obnova zaloh, rozhodne by se nemelo o nicem diskutovat a schuzovat.Opravovat pak muzete pripadne i po te obnove, a pokud se zadari, daji se rozdilova data jeste zpetne do databaze vlozit - pochopitelne opet v zavislosti na typu dat a v souladu s tim planem.
BTW: EMC? Zazil jsem osobne, V mem pripade slo nastesti o soubor FS, databazi to netrefilo.
-
Co je na tom neuvěřitelného? Vrazili do větší peníze do (zřejmě) značkového HW, takže právem očekávali, že bude fungovat. A firmu, která má prověřený a otestovaný DR plán bych taky rád viděl - předpokládám, že v nějaké takové pracujete. A co se replikace týká, taky není všemocná - nám třeba selhalo primární i záložní datacentrum současně.
-
Oni podle mě ani neví kde byla chyba. Ale jak už vidím, že má někdo něco podobného postaveného na MS SQL, tak se mi zvedají chlupy na pr.. Protože ono je myslím úplně jedno, jakou databázi člověk používá, jestli to má na MySQL, Postgre, MSSQL, Oraclu a nebo DB2, ale když mu to kiksne, tak ocení Oracle.
Když už používáte neschopné produkty co se týče databáze a vyháníte to výkonem, tak to zachraňte na uložišti.
Proč třeba tak velká firma jako je Alza neřeší zálohy a failover na bázi NetAppu, nebo co je tam za uložiště? Nějaký jeden disk WD Green s operačním systémem MS DOS 6.22? Samozřejmě přeháním, ale vypadá to na dobrý bastl.
-
Je to teda děsivé řešení rvát tohle do Microsoft SQL, ale jako dědictví minulosti budiž.
Nicméně už to dávno mělo být rozřezané na malé kusy a napojené integrací - už jen proto aby vypadl vždy jen segment.
A taky proto aby šel ten segment jednoduše obnovit. Tohle mohlo být únosné jen na malém množství dat.Jediná možnost prostě dekomponovat a nasadit jen minimalistickou core SQL databázi (pro napojení) a hromadu zbylého bordelu nasypat do NoSQL na Cassandru nebo ScylluDB. Pochopitelně distribuovaně, nikoliv nějaký SAN.
-
zen (neregistrovaný) 185.112.167.---
Nezlobte se na mne, ale mít core funkcionalitu tak velkého e-shopu na uvedeném produktu a neplatit si Premier support? Manažer, který toto navrhl a především udělal toto rozhodnutí, by měl být vyhozen na ulici a to z nejvyššího patra, které má Alza k dispozici. Také je potřeba říci, že Premier support nezajišťuje přímo zastoupení Microsoft s.r.o., ale firma Microsoft sevices. Nějaké zkušenosti s touto podporou mám a vím velice dobře co specialisté z Microsoft services dokáží. Samozřejmě, zázraky také neumí. Kromě podpory však mohou odhalit budoucí potenciální problémy v rémci prgramu RAP.
Takže se ukázalo, jak se šetřící rozhodnutí může projevit v zajištění funkčnosti firmy. -
fd (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Jeste take museli cely den platit zamestnance kteri nic nedelali, takova drobnost ... a to samo o sobe mohlo nejaky ten milion stat. Dalsi skody pak vznikou jako nasledne - objednane zbozi prijede, nekdo jej musi prijmout, protoze dopravce nezajima ze nefunguje vas system (pripadne zaplatite pukuty za prostoje), ale to zbozi se pak bude prijimat jeste podruhe, az system fungovat bude. Dusledkem nejspis bude prescasova prace ve dnech po vypadku = dalsi stovky tisic nejmene.
1500 zamesnancu = rekneme 4MKc/den zcela jiste. A vypadek nemusi trvat prave den, muze trvat dele, takze reseni za 15M rozhodne neni drahe.
-
fd (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
A vy si k tomu vasemu zisku jeste prictete provozni naklady atd, v pripade alzy ze mouhou celkove skody z 1 dne vypadku bez problemu pohybovat kolem 10M. A takovych dnu muze byt behem jednoho roku i vice, natoz behem 5 let.
A jiste, bavime se o nejakych virtualnich cislech, protoze realne to vypada tak, ze hodinovy vypadek nestoji skoro nic, a 3 dny firmu polozi. Prictete si k tomu laskave i to, ze nikde neni receno, ze problem bude v jakekoli dohledne dobe vyresen. To vam zadny bezny support nezajisti. Klidne se vam muze stat, ze i zcela funkcni support bude vasi zavadu resit mesic.
Pak laskave zakalkulujte to, ze se obecne doporucuje, ze by rozpocet na IT infrastruklturu mel byt nekde mezi 1-5% obratu. Pochopitelne vcetne lidi. U alzy se pak bavime o 200M+ Kc ... rocne. Z toho je nejakych 3M naprosto smesna cast.
Laskave si uvedomte, ze se bavime o mnohem mene nez jednom pivu ktere si nekde date. Bavime se o 0,0001 obratu, coz pri prepoctu na prumernou mzdu znamena v rozpoctu 3Kc.
-
Hlupaci usetrili (neregistrovaný) 2001:67c:2660:----:----:----:----:----
Tak asi zase nekdo setril na nespravnem miste.... u takove jaderne elektrarny, jakou ALZAk nepochybne ridi, je potreba kvalitni transakcni databazi - a ta je jen jedna - DB2 na AS/400. Treba takova DHLka s tom jede a oni moc dobre vedi, proc to tam maji, protoze vykonnost te databaze je nesrovnatelne vyssi nez nejake SQL od MS ....
-
PetrN (neregistrovaný) 212.4.155.---
Nakonec se zjistí, že je nejlepší použít nějaký open source a sám si ho upravit podle potřeb. Pár hlupáku se tomu sice vysměje, ale když jim ukážete, že například x tisíckrát zatíženější Facebook jede na PHP a MySQL (+ vlastní úpravy), nemá dále s těmito hlupáky cenu diskutovat.
-
- Customer Support Advisor in Prague (RU + ENG)
- SAP Konzultant/Programátor Ostrava
- SAP Procesní Analytik- Trutnov
- SW Developer C#/.NET
- PROGRAMÁTOR/KA ANALYTIK IT senior
- Vývojář/vedoucí vývoje HW-SW ARM
-
- Secret Dictionary of Native Speakers
- Začínáme s fundraisingem
- Nastavení PPC kampaní s analýzou klíčových slov
- OneDrive pro firmy 3: Pracujte se soubory na svém počítači – synchronizujte
- Sebevědomá a asertivní komunikace
- Obsahová strategie I: První kroky
-
- SAP Konzultant/Programátor Ostrava
- PROGRAMÁTOR/KA ANALYTIK IT senior
- Vývojář/vedoucí vývoje HW-SW ARM
- Global Helpdesk IT Specialist - different kind of IT support
- Network Security Analyst
- Integrační vývojář
-
- Secret Dictionary of Native Speakers
- Improvizace aneb jak být pohotový
- Začínáme s fundraisingem
- Sebevědomá a asertivní komunikace
- Obsahová strategie I: První kroky
- Zdravé jídlo a život jako základ prospívání v práci i soukromí
