Fórum Root.cz
Hlavní témata => Server => Téma založeno: czechsys 12. 05. 2025, 11:31:00
-
Ahoj,
provozujeme lokalni HA nas v jedne lokalite a potrebovali bychom reseni pro 2 lokality z hlediska HA. Jiz jsme poridil SAN (iscsi), ktery operuje nad obema lokalitami, ale neporidila se s nim licence nfs a dokoupeni je "docela drahe".
Testoval jsem VM nfs na tom SANu a dostal jsem se na 1/3 vykon stareho reseni (30k iops read, 10k iops write, fio randrw mixed mode). Kolega testoval obdobne jeho specificky cephfs cluster a dostal se na 2/3. Tudy tedy zrejme cesta nevede, i kdybych postavil vice VM s nfs a rozdelil provoz.
Sice bych mohl postavit stare reseni po novu pomoci, ale urcite neni v mych silach pokryt vetsinu klasickych vypadkovych stavu, nemluve o nejakem oddeleni uzivatelu - mit na NASu desitky L2 siti (sitovek) me docela desi.
Ma nekdo v provozu nejaka reseni, ktera by se dala dat na uroven small/middle business? Nevim, zda by to pokrylo treba synology. Lokality mame propojene optikou, pro pripadnou 3. lokalitu (quorum) pouzivame cloud. Hodi se i tipy na firmy, ktere takova reseni implementuji, abychom mohli ziskat cenu takovych reseni.
Diky.
-
Ahoj,
provozujeme lokalni HA nas v jedne lokalite a potrebovali bychom reseni pro 2 lokality z hlediska HA. Jiz jsme poridil SAN (iscsi), ktery operuje nad obema lokalitami, ale neporidila se s nim licence nfs a dokoupeni je "docela drahe".
Testoval jsem VM nfs na tom SANu a dostal jsem se na 1/3 vykon stareho reseni (30k iops read, 10k iops write, fio randrw mixed mode). Kolega testoval obdobne jeho specificky cephfs cluster a dostal se na 2/3. Tudy tedy zrejme cesta nevede, i kdybych postavil vice VM s nfs a rozdelil provoz.
Sice bych mohl postavit stare reseni po novu pomoci, ale urcite neni v mych silach pokryt vetsinu klasickych vypadkovych stavu, nemluve o nejakem oddeleni uzivatelu - mit na NASu desitky L2 siti (sitovek) me docela desi.
Ma nekdo v provozu nejaka reseni, ktera by se dala dat na uroven small/middle business? Nevim, zda by to pokrylo treba synology. Lokality mame propojene optikou, pro pripadnou 3. lokalitu (quorum) pouzivame cloud. Hodi se i tipy na firmy, ktere takova reseni implementuji, abychom mohli ziskat cenu takovych reseni.
Diky.
Můžu vám nabídnout placené konzultace, tohle umím velmi dobře. Moje cena je nízké desetitisíce kč za nastavení jednoho serveru s hromadou disků. Síti ale nerozumím.
-
Myslím, že by to měl řešit Ceph multisite. Tzn, máš 2 Ceph clustery a mezi nimi tohle. Ale prakticky jsme nezkoušel.
-
Myslím, že by to měl řešit Ceph multisite. Tzn, máš 2 Ceph clustery a mezi nimi tohle. Ale prakticky jsme nezkoušel.
Já mám vynikající zkušenosti s multi-site až do 100nodů (Linux, BTRFS, ZFS, FreeBSD, automatické, i offline záloha). Jen to chce síťaře. Umím elektřinu, takže připojím i UPS. Nabízím své služby v ČR. Platba fakturou. Vše s dokumentací. A vše v majetku objednavatele.
-
Nebyl by lepší, a možná levnější Azure, a nebo možná AWS?
Azure Files, Azure NetApp Files - podle ceny a potřeby
-
Nebyl by lepší, a možná levnější Azure, a nebo možná AWS?
Azure Files, Azure NetApp Files - podle ceny a potřeby
V jednotkách GB určitě, pokud ale řešíme terabajty, tak ani náhodou
-
Tak AWS apod. rovnou skrtam, kdyz jsem koukal na ceniky EFS, tak by to urcite nevychazelo. Tam by melo akorat smysl nacpat web aplikaci primo do tech web VM/kontejneru a teprve zbytek souborovych dat na EFS, ale i tak by to bylo ve stovkach GB - realny provoz na nfs siti se spatne kalkuluje.
Cephfs jsem moc nezkousel, ale uz zpusob pripojovani klienta (auth) do ceph clusteru me od toho trochu odrazuje. Navic multisite (znam jen z proxmoxu) je spis jednostranna replika. Nemluve o tom, ze pro potrebny vykon bych potreboval nejakou hromadu ceph nodu na obou stranach. To se nevyrovna max 2U per lokalita profi reseni.
Jinak cekal jsem spis informace, ze nekdo pouziva takove reseni (synology HA, truenas, konejnery) popr. odkazy na ruzne MSP ci firmy to zajistujici. Nejak se mi nechce verit, ze jsme v CR jedini, kdo to resi a neni to banka nebo korporat.
Zatim me napadlo prinejhorsim postavit lokalni nfs cluster v kazde lokalite, z gitu by se posilaly zdrojaky na oba, a mezi clustery nasadit nejaky replikacni mechanismus pro zbytek souborovych "dat" - dokumenty, obrazky, apod. Mozna porad lepsi, kdyz sluzba "bezi", ale nema "data", nez nebezi nic. Ale krome drbd neznam nic, co by bezelo v realtime (async,sync) a ne opakovanym cronem apod.
-
Tak AWS apod. rovnou skrtam, kdyz jsem koukal na ceniky EFS, tak by to urcite nevychazelo. Tam by melo akorat smysl nacpat web aplikaci primo do tech web VM/kontejneru a teprve zbytek souborovych dat na EFS, ale i tak by to bylo ve stovkach GB - realny provoz na nfs siti se spatne kalkuluje.
Cephfs jsem moc nezkousel, ale uz zpusob pripojovani klienta (auth) do ceph clusteru me od toho trochu odrazuje. Navic multisite (znam jen z proxmoxu) je spis jednostranna replika. Nemluve o tom, ze pro potrebny vykon bych potreboval nejakou hromadu ceph nodu na obou stranach. To se nevyrovna max 2U per lokalita profi reseni.
Jinak cekal jsem spis informace, ze nekdo pouziva takove reseni (synology HA, truenas, konejnery) popr. odkazy na ruzne MSP ci firmy to zajistujici. Nejak se mi nechce verit, ze jsme v CR jedini, kdo to resi a neni to banka nebo korporat.
Zatim me napadlo prinejhorsim postavit lokalni nfs cluster v kazde lokalite, z gitu by se posilaly zdrojaky na oba, a mezi clustery nasadit nejaky replikacni mechanismus pro zbytek souborovych "dat" - dokumenty, obrazky, apod. Mozna porad lepsi, kdyz sluzba "bezi", ale nema "data", nez nebezi nic. Ale krome drbd neznam nic, co by bezelo v realtime (async,sync) a ne opakovanym cronem apod.
Já to z popisu chápu tak, že chceš něco, co má mít už dost enterprise charakteristiky...
Z toho ten Ceph vychází jako levná a dobrá alternativa. Na věci typu Synology bych zapomněl rovnou, truenas bych považoval take jen za dost tupý storage...
Kolega ti tady nabízel konzultaci, takových lidí je málo, kteří jsou schopní s tím fundovaně poradit. A také záleží na budgetu, podkud není, tak se na to raději vykašli.
-
chceš moc za málo peněz.
Active-active replikace mezi dvěma lokalitami je vysoká dívčí, to nelze zajistit na koleni, asynchronní replikaci umí i cvičený králík.
Synology, TrueNAS jsou hračky pokud jde o HA s více lokalitami, plno heků, plno vylomenin, minimální podpora a záruky, při řešení problémů to je spíše ke vzteku.
Ceph je toho plně schopný, ale na obou stranách potřebuješ několik nodů, v 2U krabici to lze řešit, ale pak výpadek krabice ti položí značnou část clusteru (či dokonce celý), otázka je co vlastně potřebuješ.
Na druhé straně tady máš enterprise řešení jako purestorage.com nebo Dell PowerScale (dříve IBM Isilon), to tě výjde na miliony na lokalitu.
Nepíšeš nic o latencích, datových přenosech a ani plánovaných iops. Umím ti s tím poradit, orientuji se i v sítích a cephu, ale zatím mám dojem, že toho chceš prostě příliš.
-
Ja to nechci, to chce vedeni :-) Ja si uvedomuji, ze pokud to neni garazove reseni (ten stary nfs jsem slepil ja) slepene sysadminem/netadminem, tak to nikdy nebude levne. Synchronni to byt spis nemusi, vse, co jsme tu zatim zakoupili/postavili jsou urcite asynchroni reseni.
U tech truenas/synology mam info z vice stran - jedna si to pochvaluje, jedna si stezuje a tak. Tezko pak posoudit pouzitelnost do SMB. Reseni za miliony tady neuspeje, kdyz zatim neuspela nfs licence za nzke desitky tisic euro (licence+support).
Konzultace za desitky tisic, na to mi budget asi taky nedaji, resp. budget reseni jen vedeni, takze ja nemam v ruce ani halir, podle ktereho bych se mohl ridit :-) Stacilo by mi, kdyby mi nekdo napsal nejake firmy, ktere takove reseni nabizeji, ktere bych mohl oslovit pro zakladni naceneni. Ty konzultace "predbihaji" posloupnost. Vedeni proste potrebuje znat nejake ceny, aby se mohlo "rozhodnout", kterym smerem se pujde.
Co se tyce technickych parametru, nejsou momentalne primo definovane. Co urcite zname, jsou parametry stareho NFS (sata i nvme ssd) - a treba novy SAN ISCSI ma nizsi vykon, ale ma ty "feature". Ze na vse pouzivame 10G site, mame moznost strcit (pouze) NAS na 100GB switch. K tomu mame vyhrazenou 10G optiku mezi lokalitami, opet moznost prepojit na 100G, ale zaklad je tech 10G.
Zatim jsem si obnovil znalost, ze jsem tehdy objevil Starwinds VSAN.
-
Jak tu rekli jini, ujasni si nejdriv, co se vlastne ocekava a predevsim PROC. Pak si ujasni, kolik na to mas, a dost pravdepodobne zjistis, ze na to nemas. Nema smysl utracet miliony kdyz resis potencielni skody za tisice.
A uvedom si predevsim, ze za jakejkoli samorobo batl pak taky sam zodpovidas, coz je pohoda presne do chvile, nez se to podela.
Pricemz stejne jak tu psali jini, tvoje pozadavky uz jen takhle od stolu a velmi bywoko vpohode prelezou 10M.
-
pokud potřebuješ nějaké referenční nabídky, tak zkus namátkou oslovit společnosti jako cnnc.cz, asbis.cz, fortion.cz atd. (nemám s žádnou žádný vztah, pouze je znám), ale ta cena ti půjde vysoko.
Problém Synology je, že se to umí nepěkně rozbít a nejsi schopný to nijak opravit, musíš koupit nový HW (či mít ve skladu náhradní) a data mít někde zálohovaná, je to blackbox, který nelze snadno opravit a ani rekonstruovat. TrueNAS teď přechází na linux, v podloubí není tak zlý, zfs dokážeš obnovit i externími nástroji, je relativně otevřený, ale primárně to je standalone, o mutlilokalitě tam vůbec nevím (replikace přes snapshoty je něco jiného).
Pokud chceš levné řešení, tak ideálně práce přes jednu lokalitu a replikace přes snapshoty do druhé, DR s výpadky a ruční/poloautomatickou prací atd. To jsou levná řešení, které lze zprovoznit na komunitním SW nebo nějakých retail krabičkách.
-
A znas alespon zakladni pozadavky?
- pristup jako block device vs pristup jako k souborum/objektum?
- potrebujes garantovanou synchronicitu dat (a tudiz ztrata spojeni bude znamenat media offline, nebo drop do RO), nebo lze akceptovat lazy-sync s nejakou latenci?
- potrebujes pristup skrze klasicke protokoly (smb/nfs), nebo jde o datove uloziste pres vyssi API ?
- co jsou klienti daneho storage reseni? a jaka data tam jsou ulozena
-
Ja to nechci, to chce vedeni :-) Ja si uvedomuji, ze pokud to neni garazove reseni (ten stary nfs jsem slepil ja) slepene sysadminem/netadminem, tak to nikdy nebude levne. Synchronni to byt spis nemusi, vse, co jsme tu zatim zakoupili/postavili jsou urcite asynchroni reseni.
Tak se zamysli nad tim, ze nechat se do toho natlacit znamena pro tebe osobne nejspis slapnout do poradne velkeho hovna.
Ale myslim, ze to sam tusis...
-
Jak píše RDa dej požadavky a popiš co od toho očekáváš za funkcionalitu. A stanov skutečný rozpočet na investice, ev. na měsíční bázi.
Ideální by bylo i kdyby jsi dal zadání od vedení, co vlastně oni od toho očekávají.
Teprve pak zde můžeš získat nějaké obecné řešení, a nebo radu která tě smyslplně posune dál.
Zatím mám pocit že jsi napsal že jsi koupil nějaký SAN. A NFS je údajně drahé!
Takže nejspíše nějaké peníze jsou, ale jde se na to takovým tím švejkovský postupem, něco koupím a pak přemýšlím.
No, myslím si že se zde mělo nejdříve víc přemýšlet, pak analyzovat, pak se na to vyspat a ještě jednou probrat zda se něco neopomnělo a pak poptat např. u Servodata atd. aby vznikl cenový nástřel.
Já jsem zmínil Azure, netuším jestli je to to pravé.
Je SQL Oracle nebo co tam je. Je tam SAP/HANA nebo něco podobné?
A nebo je to pouhopouhé sdílení souborů.
Ale všechny tyto řešení většinou očekávají i robustní infrastrukturu a hlavně konektivitu.
Kdysi velmi dávno jsem řešil podobné úvahy v jedné vesnické firmě s podobným záměrem, ale když mi řekli že mají 10Mbit wifi a měsíční náklady "nejradši zadarmo" tak jsem to radši sám ukončil.
-
Neriešil by Váš problém lsyncd alebo glusterfs?
-
Asi nepouzivam spravna slova, protoze nektere otazky jsou jako kdybych neco neuvedl "v popisu". Uz to, kdyz zminuji dedikovane optiky, 10Gbps, SAN apod by napovedelo, ze to uplne garazovka neni, ale bohata firma taky ne. Rozhodne ale nez se neco koupi, tak se planuje/vyhodnocuje, proc se to koupi. Ale budiz.
glusterfs apod. rovnou skrtam, to nebylo pouzitelne ani pred 8 lety, kdy jsem nas aktualni nfs cluter, dnes to je prekonane kontejnery popr. ceph.
Zadani od vedeni je klasicky manazerske, tedy v pripade primarniho datacentra chteji provozovat (aspon nektere sluzby, samozrejme tim mysli skoro vse, co je dobre placene) z druhe lokality. Takze se postupne delaji jednotlive kroky - k aktualnimu nfs clusteru se poridil SAN s georedundanci, tim jsme vyresili (blokove) uloziste pro VM.
Chce se tedy neco obdobneho pro soubory, protoze jedeme hlavne linux, tak nfs je prvni volba. Cestu mit zdrojaky primo ve VM jsme tehdy zamitli, to se muze zmenit. Ale zbytek souborovych dat je orisek, mozna by na to bylo vhodnejsi neco typu S3, ale s tim jsem zatim nemel cest. Porad ale reseni nejdrive on-premise.
Webove sluzby ktere poskytujeme, maji jiz zabudovanou redundanci. Tedy vice kopii web/compute serveru, ktere si tahaji zdrojaky, obrazky, dokumenty, videa a dalsi a dalsi z nfs. Bavime se i v nekterych pripadech i o milionech souboru podle velikosti jednotlivych projektu, zatim celkove pod 1TB ciste kapacity. Takze nastesti zadna SAP HANA nebo tak. Kdybych mel k dispozici rozumne admistratovatelny kontejnerizacni system obdoby proxmoxu (vmware is dead), tak bych ty zdrojaky nacpal do kontejneru a mam to o neco jednodussi.
NAS replikace staci async. Jedine misto, kde pouzivam sync, je pripojeni klientu k nfs.
Rozpocet stanovit nemuzu, muzu jen predlozit vedeni cisla, ale vetsinu obchodni jednani vede primo vedeni.
Protoze tu nikdo nema zkusenosti z cloudovych poskytovatelu apod., tak me moc jinych technologii jak resit tyhle veci nenapada. Proto se poptavam, co se pouziva pripadne u koho se daji nechat nacenit reseni, nez se to pripadne bude resit DIY.
-
Jenze to je prave o tom, ze ty prakticky neuvadis zadne relevantni udaje.
Treba 10Gbit je strasne malo. 10G mam doma na svuj domaci NAS. U mensich zakazniku maji ciste storage, ktery se nikam nereplikujou, 8x 10G. Kdyz odbocim trebas k virtualizaci a vmware, tak by ti 10G hrokotezko stacilo na bezvypadkovy provoz JEDNOHO virtualu.
To co vyplyva z tvyho popisu je, ze chces master-master realtime replikaci. A to je slozity a tudiz drahy a proto to skoro nikdo nepouziva. Protoze presne v okamzeni kdy se podivas na cenu, tak zjistis, ze to neportebujes.
Dell/EMC:
"Carefully consider the write profile of workloads that will run on replicated volumes; additional network capacity will be needed to accommodate the additional write overhead. In replicating systems, therefore, we recommend using 4x 25GbE or 2x 100GbE networks to accommodate the back-end storage traffic."
To jen aby sis udelal predstavu, jak smesnych je 10G.
-
Ano, pro master-master to bude chtit nejen tlustsi linku, ale hlavne redundantni.
Na druhou stranu - podle toho popisu mi vychazi ze workload je spis RO, a pokud nekde dochazi k zapisum tak to budou spis logy/databaze a to lze agregovat/distribuovat jinak (u DB by se taky dala udelat segmentace, aby ten rw sdileny obsah byl co nejmensi a zbytek jen ro).
1TB je zde spise vyhoda (a to se pres 10G da pretahnout za 20 min cely).
Jeste jinak - jsi schopen na svych klientech striktne oddelit kam zapisama sahaji ?
(napada me pak reseni mit dve nezavisle NAS s NFS, a na obou NAS pobezi neco navazane na inotify a vsechno co se zmenilo, bude pushnuto pres 10G na druhy breh ... ale je zde velice silnej pozadavek, aby nedochazelo ke konfliktum)
Ke konfliktum treba nedojde, kdyz kazda aplikace (resp. bezici instance) bude bezet pouze na jedne strane, a na druhe se spusti az jedna lokace klekne. Pripadne ty appky musi mit vlastni individualni (lokalni, nesyncovanej) temp a pod.
-
... ale je zde velice silnej pozadavek, aby nedochazelo ke konfliktum)
Mno prave. Proto si to dodavatele nechaji velmi dobre zaplatit.
To co popisujes dal vpodstate meni to reseni na master-slave. To je easy, protoze ti nevadi ze se to na druhou stranu zapise "az nekdy". A presne proto ti taky staci vyrazne nizsi konektivita, protoze ti proste staci, kdyz se ty data nejak zvladaj prenaset + navic vlastne nemusis prenaset ani vsechno, muzes zacit resit jen rozdily, komprimovat to atd atd, cimz pochopitelne razantne snizis naroky.
-
Ona ta konektivita (sirka pasma) je potreba v zavisloti na pomeru RO:RW operaci. Pokud je veskera aktivita RO, tak nepotrebujete konektivitu zadnou ,)
Pro master-master (vs master-slave) je pak dulezitejsi latence na konektivite - aby slo vykomunikovat zamky v nejakem rozumnem case. A na to nema vliv objem zaplacenych prostredku - vice penez do storage technologie vam nezlepsi experience.
Zpet k tomu memu - pokud fakt neni rozpocet na 3rd party proprietarni reseni, tak nezbyva nic jineho nez si zkulturnit sve aplikace, aby si do zeli nelezli.. a pak muzete nasadit nejakou jednodussi formu reseni i ve vlastni rezii.
PS: ale zalohovat (a obnovovat) bych tenhle bastl pak nechtel :D
-
no a jako vždy u podobného nápadu skončíme u toho, že se budou dělat dumpy databází, jednou za čas snapshoty virtuálů a ty budou čekat v druhé lokalitě. Když to holt bude kritické, bude se realtime replikovat transakční log u databáze. Řešení za pár desítek tisíc na konzultace a půl roku vývoje/úpravy doma.
Tohle řeší všichni, ale také všichni skončí s tím, že si prostě vyberou těch pár kritických dat/aplikací, ty replikují rovnou a zbytek pomalu snapshotují a odlévají. Ztráta pár desítek minut dat je přijatelná skoro všude, hlavně se ušetří miliony na implementaci a provoz.
Nezapomeň, že tohle děláš, abys zvýšil spolehlivost, jakákoliv komplexnost ti naopak tu spolehlivost zase posouvá dolů. Testovat stabilitu musíš v nejhorším scénáři a ne v tom nejlepším a pak tvrdit, že synology je vlastně super, není. Oni i ty enterprise systémy trvá dlouho vyladit a náklady na pravidelné testy jdou také do dost vysokých čísel. Někdy je prostě lepší se znovu snést na zem.
-
Možná jsem to tu přehlédl, ale co přístup "zápis jen na masteru, čtení na replikách?" Když bude aplikace v regionu s replikou chtít zapisovat, a následně se to z masteru může rychle zkopírovat do repliky. V případě výpadku masteru se replika prohlásí za master a jede se dál. Akorát to dost zpomalí zápisy (data musí udělat roundtrip z read-only regionu do masteru a zpět), ale ze zadání mi není jasné, zda je to přijatelné, nebo ne. A člověk se tím vyhne celé té složitosti s master-master.
PS: za zvážení stojí otázka, jak moc je pravděpodobné, že časem přibude třetí region, a vybrat vhodný přístup hned na začátku. Master-master je jedna věc, N-uzlový mesh je ještě další úroveň.
-
... N-uzlový mesh je ještě další úroveň.
To uz mas jedno. To co vyrabis je defakto zrcadlo, a nehraje zasadni roli (technologicky) jestli mas v tom zrcadle ty "disky" dva nebo jich mas deset. Jen ty naklady nerostou linearne, ale spis exponencelne. Potrebujes treba zajistit propoje vseho se vsim (pokud to teda opravdu ma zvladat vypadek cehokoli)
Jenze tady je podstatny to, ze tazatel zatim vubec nedokazal zduvodnit, nac neco takovyho chce. Ja osobne neznam firmu (a mam ve svy bubline tech konaktu docela dost) kde by treba vypadek storage i na par hodin byl nejakej kritickej problem. Jiste, muze to byt neprijemnost, muze to zpusobit nejake financni skody, ale firmu to nepolozi a jaderna elektrarna kvuli tomu nevybuchne.
Ja treba u nekterych zakazniku umim (a to u tech vetsich) v ramci rekneme 10ti minut nahodit provoz ze sekundarniho storage, a ani to neni nijak automaticke a je to zcela vyhovujici (za poslednich 20 let sem to delal 1x). Defakto nejhorsi scenar kterej muze nastat je nutnost obnovovat zalohy (tzn chciply by obe storage zaroven), coz narazi na limity HW a konektivity. Jenze v takovym pripade si nejak nedovedu predstavit, ze by toho nepochcipalo mnohem vic (treba pozar budovy) a tudiz by nejaka obnova zaloh bylo stejne az to posledni, co by bylo k reseni.
-
Ano, pro master-master to bude chtit nejen tlustsi linku, ale hlavne redundantni.
Na druhou stranu - podle toho popisu mi vychazi ze workload je spis RO, a pokud nekde dochazi k zapisum tak to budou spis logy/databaze a to lze agregovat/distribuovat jinak (u DB by se taky dala udelat segmentace, aby ten rw sdileny obsah byl co nejmensi a zbytek jen ro).
1TB je zde spise vyhoda (a to se pres 10G da pretahnout za 20 min cely).
Jeste jinak - jsi schopen na svych klientech striktne oddelit kam zapisama sahaji ?
(napada me pak reseni mit dve nezavisle NAS s NFS, a na obou NAS pobezi neco navazane na inotify a vsechno co se zmenilo, bude pushnuto pres 10G na druhy breh ... ale je zde velice silnej pozadavek, aby nedochazelo ke konfliktum)
Ke konfliktum treba nedojde, kdyz kazda aplikace (resp. bezici instance) bude bezet pouze na jedne strane, a na druhe se spusti az jedna lokace klekne. Pripadne ty appky musi mit vlastni individualni (lokalni, nesyncovanej) temp a pod.
Tak databaze resit nemusim, u nich mam k dispozici replikaci zabudovanou v db.
Ano, vetsina workloadu nad soubory je RO, takze nam 10G redundantni propoje staci, zatim jsme to nebyly schopni zatizit trvale vic nez par desitek %.
Taky me napadlo dva nezavisle nfs clustery. Zdrojaky by nahraval gitlab do obou clusteru. Oddeleni od "media,office dat apod." by samozrejme museli resit vyvojari, aby se to dalo dat na nejake "replikovane" reseni. Coz uz pak muzu "replikovat" vse, vzhledem k celkove velikosti zdrojaku/dat.
-
... N-uzlový mesh je ještě další úroveň.
To uz mas jedno. To co vyrabis je defakto zrcadlo, a nehraje zasadni roli (technologicky) jestli mas v tom zrcadle ty "disky" dva nebo jich mas deset. Jen ty naklady nerostou linearne, ale spis exponencelne. Potrebujes treba zajistit propoje vseho se vsim (pokud to teda opravdu ma zvladat vypadek cehokoli)
Jenze tady je podstatny to, ze tazatel zatim vubec nedokazal zduvodnit, nac neco takovyho chce. Ja osobne neznam firmu (a mam ve svy bubline tech konaktu docela dost) kde by treba vypadek storage i na par hodin byl nejakej kritickej problem. Jiste, muze to byt neprijemnost, muze to zpusobit nejake financni skody, ale firmu to nepolozi a jaderna elektrarna kvuli tomu nevybuchne.
Ja treba u nekterych zakazniku umim (a to u tech vetsich) v ramci rekneme 10ti minut nahodit provoz ze sekundarniho storage, a ani to neni nijak automaticke a je to zcela vyhovujici (za poslednich 20 let sem to delal 1x). Defakto nejhorsi scenar kterej muze nastat je nutnost obnovovat zalohy (tzn chciply by obe storage zaroven), coz narazi na limity HW a konektivity. Jenze v takovym pripade si nejak nedovedu predstavit, ze by toho nepochcipalo mnohem vic (treba pozar budovy) a tudiz by nejaka obnova zaloh bylo stejne az to posledni, co by bylo k reseni.
Zakaznici to chteji. Jde o jejich business.
Do 10 minut, to jsi frajer. Ja jsem zazil vypadek primarniho storage 2x, kdy nedoslo k automatickemu prepnuti, protoze se to zaseklo. Nebyt u ntb, tak to do tech 10 minut nevyresim.
-
PS: za zvážení stojí otázka, jak moc je pravděpodobné, že časem přibude třetí region, a vybrat vhodný přístup hned na začátku. Master-master je jedna věc, N-uzlový mesh je ještě další úroveň.
Pokud by naopak mel 3 lokace (klidne tu treti jako pasivni/zalozni), tak by bylo nejvhodnejsi vzit CEPH.
(pripadne to resit jako 2+2 (+2) pro klasicky setup kde si muzete po jednom updatovat nody a nic nevypadne)
-
Neriešil by Váš problém lsyncd alebo glusterfs?
Přimlouvám se za keep it simple. Třeba rsync v cronu udělá taky spoustu práce, ale lsyncd je o krok dál. Glusterfs by tomu dal křídla, jenom už to souvrství začíná být maličko složitější :-)
Nezapomeň, že tohle děláš, abys zvýšil spolehlivost, jakákoliv komplexnost ti naopak tu spolehlivost zase posouvá dolů. Testovat stabilitu musíš v nejhorším scénáři a ne v tom nejlepším a pak tvrdit, že synology je vlastně super, není. Oni i ty enterprise systémy trvá dlouho vyladit a náklady na pravidelné testy jdou také do dost vysokých čísel. Někdy je prostě lepší se znovu snést na zem.
Taky mám radši věci, do kterých je vidět dovnitř. Snáz se v tom dá vyznat v případě nějakého katastrofického kolapsu (disaster recovery). Věci automagické, složité a uzavřené jsou mi spíše z principu podezřelé :-(
Jakýkoli systém na bázi geografického clusteru, kde se na každé lokalitě do té věci konkurenčně zapisuje, smrdí problémem pokud nastane split-brain. Jak se z něho vrátit do spojitého stavu. Principielně je potřeba se snažit, aby lokality nemusely "sdílet stav s právem zápisu". Každá lokalita ať si zapisuje do svého lokálního písečku, a na jiné lokality se jenom "letmo zálohuje" s možností "lokálního read-only přístupu k datům vzniklým v jiné lokalitě". Na jaké vrstvě se povedou hranice mezi "parcelami lokalit" je vcelku na uvážení integrátora. Může se jednat o oddělené foldery ve filesystémech, nebo o atribut "location of origin" v SQL databázi (nebo mě napadá, přidělit každé lokalitě její vlastní řadu generovaných unikátních klíčů v rámci sdíleného sloupce, ale to je moje lidová tvořivost :-) Což samozřejmě komplikuje vývoj aplikace, pokud má být "jenom jedna, společná, homogenní napříč lokalitami", datový model má hodně entit apod.
Hmm šimrá mě správně v šedé hmotě keyword Mumps ?
Tuším jsem taky zaslechl termín "eventual consistency", jako že "časem se to rozkopíruje a začne to v globále dávat smysl". Vývojově to tuším pochází z modernější doby, no-SQL v masivních cloudových systémech, microservices apod., než klasické poučky o distribuovaných systémech z minulého století...
Distribuovaný systém se simultánním RW provozem bez explicitního rozparcelování lokalit lze postavit, ale pak řešíte vzájemnou synchronizaci, zamykání, konkrétně two-phase commit (2PC) a podobné radosti, což je právě závislé na přenosových latencích (jak už psali ostatní). Co máte v rámci jednoho stroje (hypervizoru) v desítkách nanosekund, na LANce je v řádu desítek mikrosekund, napříč městem či krajinou jdou další řády nahoru... Čím větší ethernetový switch nebo router, tím větší hrubá průchodnost, ale obecně taky store-and-forward latence jdou nahoru... a pak je problémem potenciální split-brain. Jak se při něm chovat (zastavit provoz? zastavit zápisy?) a jak se případně zotavit, pokud provoz nezastavíte... mít jednu "centrální" lokalitu, jejíž "spojitý přeživší shluk" může zapisovat dál, a kdo se odpojí od centrálního shluku, smí lokálně pouze číst?
-
Zakaznici to chteji. Jde o jejich business.
Do 10 minut, to jsi frajer. Ja jsem zazil vypadek primarniho storage 2x, kdy nedoslo k automatickemu prepnuti, protoze se to zaseklo. Nebyt u ntb, tak to do tech 10 minut nevyresim.
Zakaznici chteji ledacos, a kdyz chteji tak at si to zaplati. Ale je mimo jiny ukolem ITka jim vysvetlit, ze to co chteji je pitomost.
Setkal sem se s pozadavkem na garantovani bezvypadkoveho provozu 24/7 ... to neumej ani banky. Doticni to nechteli pochopit, tak sme jim nacenili jen HW. Pak uz to nepotrebovali. SW by ve skutecnosti stal jeste tak 10x vic nez ten HW. Drtiva vetsina SW neco takovyho vubec neumi a nepredpoklada a dodavatele/jejich vyvojari typicky nemaji ani paru ze by neco takovyho mohlo vubec existovat.
BTW: virtualy se replikujou na sekundarni storage, ze ktery je mozny je rovnou nastartovat. Neni to automaticky a to z dobryho duvodu. Bylo by treba osetrovat spoustu "co kdyz", ktery ITk vyhodnoti pohledem za minutu a stejne kdyz osetris 150 variant, nastane ta 151.
-
nejsem dealer netappu ale přijde mi, že pro orientaci bys mohl managementu nechat nacenit tohle: https://www.netapp.com/snapmirror-data-replication/. Dělá to to, co si myslím, že ty zhruba popisuješ.
-
nejsem dealer netappu ale přijde mi, že pro orientaci bys mohl managementu nechat nacenit tohle: https://www.netapp.com/snapmirror-data-replication/. Dělá to to, co si myslím, že ty zhruba popisuješ.
to ale není samostatné řešení, k tomu potřebuješ storage, např. softwarový ONTAP, celkově to začíná na tisících dolarech měsíčně, cenu mají tierovanou podle iops a množství dat. Patří sice pořád mezi ty levnější vendory, ale řekl bych, že to je pořád pro tenhle use case vysoko.
-
Ja osobne neznam firmu (a mam ve svy bubline tech konaktu docela dost) kde by treba vypadek storage i na par hodin byl nejakej kritickej problem. Jiste, muze to byt neprijemnost, muze to zpusobit nejake financni skody, ale firmu to nepolozi a jaderna elektrarna kvuli tomu nevybuchne.
Tak to ti příklad milerád dám. Operační řízení záchranných složek. Jasně, existujou věci jako přelivy tísňových linek, nouzové postupy, kdy se v nejhorším případě píše na papír, apod., ale v každým případě to akceschopnost výrazně omezí a už jen to, že ztratíš informaci o poloze jednotek, významně prodlouží dojezdový časy. A když z tebe stříká krev nebo kolem tebe šlehají plameny, eventuálně nadzvukovou rychlostí sviští malý kousky těžkýho kovu, je každá sekunda navíc zatraceně dlouhá, a ohrožení životů je zcela reálný.
Příklad následků prodlení v řádu minut, o kterým by sis myslel, že nic neznamená (s ohledem na NDAčko bez podrobností): před pár lety (bylo to i ve zprávách) došlo k tomu, že technik operátora při výměně prvku mobilní sítě místo podle not jel po paměti (protože to dělal miliónkrát), a zapomněl na jednu docela drobnost. A následující den pán cca 65 let zkolaboval. Posléze bylo zjištěno (bylo to v lázních), že se mu udělalo špatně s chtěl si zavolat záchranku, ale nedovolal se na žádné tísňové číslo. Nedokázal se už ale dostat k nouzovému pípáku na pokoji, takže chvíli trvalo než si ho někdo všimnul. I pak ale problém s tísňovými čísly trval, takže než se někdo dostal k pevné lince nebo mobilu s kartou jiného operátora (ono totiž když mobil má registraci mobilní sítě a jen nejde směrování tísně, tak se na tíseň prostě nedovoláš, protože ten mobil NEVÍ, že má použít jinou síť), došlo k prodlení při vyslání záchranky. Jelikož šlo o selhání oběhového systému, těch asi 20 minut prodlení rozhodlo o tom, že umřel, což konstatoval znalecký posudek. A jestli se správně pamatuju, ten technik dostal za nedbalostní způsobení vážné újmy na zdraví s následkem smrti v důsledku závažného porušení pracovních povinností 2 nebo 3 roky natvrdo.
Což není ilustrace toho, že mobilní buňky mají diskový pole; je to ilustrace toho, že i zdánlivě nepodstatný zdržení v důsledku drobný závady má někdy dalekosáhlý důsledky, a řeší se pak kdo za co odpovídal a kdo za to může.
-
Ehm ... lol ... jo, opravdu se smeju. Protoze zjevne narozdil od tebe treba vim, ze to ze sou zahranari/hasici bez spojeni, je bezna vec. Napriklad. A to ze se nekdo dovola o kraj (nebo i stat) vedle, kde schodou okolnosti taky maji horni dolni a zachranka prijede tam, je taky bezny.
Dohledej si na yt kanal tech z Jablunkova (napr) a pokochej se tim spolehlivym systemem. Vypada to zhruba tak, ze maji v aute 3 radia, pouzivaji misto toho soukromej mobil, dovolaji se na slovensko, a tam je prepojujou knam, a to jeste pekne na 3x, aby se konecne dostali na svuj dispecink, kterej jim stejne neumi rict kam maji jet.
Takze kde hori hledaj tak ze obvolavaj sousedy a ptaj se jich estli nevidej kour.
-
Ty jseš teda hodně vtipnej komik. Jablůnkov má akorát obecní dobráky, ty kašpare. Ty sice státní leckdy přizývají, ale IZS na nich nestojí.
Ale ono v otázce tvé kvalifikace leccos vysvětluje ta šílená lavina hrubek.
-
Ty jseš teda hodně vtipnej komik. Jablůnkov má akorát obecní dobráky, ty kašpare. Ty sice státní leckdy přizývají, ale IZS na nich nestojí.
Na obecních dobrácích sice IZS nestojí, ale někdy na nich padá. Zažil jsem kousek od nás, že hořelo auto hned jim za rohem, 20 metrů od brány. S velkou slávou se seběhli a nastartovali akorát ve chvíli, kdy přijížděli státní hasiči - a vjeli jim přímo do cesty, načež ta tatrovka chcípla a nechtěla hned nastartovat, a blokovala cestu těm státním. A typická doba "ostrého výjezdu," jak to oni říkají, je půl hodiny bouchání dveří a pobíhání, jak se sjíždí z okolí, z toho deset minut plnění ulice smradem ze studeného motoru, potom minuta houkání při odjezdu a do 15 minut potupný návrat (měřeno několikrát se stopkama), protože požár byl buď tak malý, že ho už někdo jiný uhasil, nebo tak velký, že je k tomu nechcou pustit. Takže tomu popisu od jjrsk naprosto věřím. ;D
-
Tak to bys mohl ještě dopodrobna rozvést, jak to souvisí s operačním řízením státních hasičů, ZZS a PČR (podotýkám na úrovni kraje) a odolností IZS proti technickým výpadkům.
-
To byl trochu off-topic komentář jako že "naprosto věřím tomu, že někde v Jablůňkově to takhle funguje" aniž bych jakkoliv oponoval tobě.
-
Nekdo se zkusenostmi se Starwinds VSAN? Maji relativne slusne reference a jde to pouzit s DIY HW.
-
Dobrý den,
máme dvě instance, jednu pro dožívající Vmware Essential plus jako SDS na 3 nodách Dell a druhý nový pro Hyper-v Cluster dvou nodový Think Server.
Nemáme s ním problém podpora funguje velmi dobře a nadstandardně dohlíží na to jak je řešení nainstalované a radí při návrhu řešení, v angličtině tedy.
Obě instance jsou full flash a duální 10GBE. Prostor je 30TB Datastore výsledný. V režimu 3 nody, převážná většina v režimu dva servery jde buď witness server nebo priorita, scénářů je hodně možných.
Storage máme připojen ke konzumentům přes iSCSI.
Umí i repliky do cold storage, mohou být synchronní nebo snapšoty dle planovače co se přenesou.
Hardware je dobré s nimi konzultovat předem než je posadit k hotovému.
Nekdo se zkusenostmi se Starwinds VSAN? Maji relativne slusne reference a jde to pouzit s DIY HW.
-
To byl trochu off-topic komentář jako že "naprosto věřím tomu, že někde v Jablůňkově to takhle funguje" aniž bych jakkoliv oponoval tobě.
On tam je problém v tom, že sice dobráci ze zákona jsou součástí IZS, tzn v případě potřeby podléhají velení HZS (které spadá pod vnitro), ale 1) AFAIK mají automaticky jen matrácké ručky, možná v technicky to umožňujících autech vozidlovky, 2) jejich financování visí plně na krku zřizovatele = obce => vybavení a jeho stav odpovídá finančním možnostem obce, a většinou není možné držet stálou posádku, tzn nejspíš je někdo na krizovém mobilu, přijme volání, musí svolat ostatní (kteří mají přidělenou službu a měli by být schopni v nějakém čase dorazit na základnu), tam se musí oblíct a vyrazit. Odezva je nevyhnutelně o dost pomalejší než u profesionálních, ale s ohledem na dojezdové časy to pořád dává smysl.
Ale aby dobráci dosáhli na technickou úroveň vybavenosti profíků, bylo by potřeba pěkných pár bambiliard. A ty nikdo nedá, protože je nemá.
-
Nekdo se zkusenostmi se Starwinds VSAN? Maji relativne slusne reference a jde to pouzit s DIY HW.
pouze lokálně, nikdy jsem to neviděl nasazené na delší vzdálenost mezi 2 lokalitami. Pokud máš dva servery kousek od sebe a umíš je spojit přes L2 ne víc než přes jeden hop, je tohle naprosto skvělé a levné řešení, jak zajistit redundanci a live migraci virtuálů třeba s pomocí kvm.
Vůbec nikdy jsem to ale neviděl nasazené na větší vzdálenost. Není to bezstavové, na každém serveru potřebuješ mít jejich kontrolní službu, který to celé řídí a spojuje se s controllerem na druhé straně. Dobře tam je i řešení výpadků, kdy mají jednotlivé nody svoji prioritu a při pádu spojení, jen ten s nejvyšší prioritou může přijímat zápisy, tím se dá vyhnout split-brainu při zachování provozu z jednoho nodu. Mají tam heartbeat mezi nody a tady si myslím, že bude velká citlivost na latency, sice můžeš mít pomalé (asynchronní) replikace, ale node musí být pořád online.
-
Ehm ... lol ... jo, opravdu se smeju. Protoze zjevne narozdil od tebe treba vim, ze to ze sou zahranari/hasici bez spojeni, je bezna vec. Napriklad. A to ze se nekdo dovola o kraj (nebo i stat) vedle, kde schodou okolnosti taky maji horni dolni a zachranka prijede tam, je taky bezny.
Dohledej si na yt kanal tech z Jablunkova (napr) a pokochej se tim spolehlivym systemem. Vypada to zhruba tak, ze maji v aute 3 radia, pouzivaji misto toho soukromej mobil, dovolaji se na slovensko, a tam je prepojujou knam, a to jeste pekne na 3x, aby se konecne dostali na svuj dispecink, kterej jim stejne neumi rict kam maji jet.
Takze kde hori hledaj tak ze obvolavaj sousedy a ptaj se jich estli nevidej kour.
Zase zvatlas onecem ocem vys uplne kulove, asi linej si zjsitit fakta....
Kdyz to houkne dobrakum, tak vedi kam a naco jedou. Dispecink vybira ktera jednotka pojede nebo ne, dobraci akorat potvrziuji, kdyz potvrdi, tak musi do 10min vyjet.
Zajmavou osvetu siri treba Hanko https://www.youtube.com/watch?v=u4atR1r9K7c (https://www.youtube.com/watch?v=u4atR1r9K7c)
Sry za off-topic, ale tyhle kidy se nedaj cist...
-
Dobrý den,
máme dvě instance, jednu pro dožívající Vmware Essential plus jako SDS na 3 nodách Dell a druhý nový pro Hyper-v Cluster dvou nodový Think Server.
Nemáme s ním problém podpora funguje velmi dobře a nadstandardně dohlíží na to jak je řešení nainstalované a radí při návrhu řešení, v angličtině tedy.
Obě instance jsou full flash a duální 10GBE. Prostor je 30TB Datastore výsledný. V režimu 3 nody, převážná většina v režimu dva servery jde buď witness server nebo priorita, scénářů je hodně možných.
Storage máme připojen ke konzumentům přes iSCSI.
Umí i repliky do cold storage, mohou být synchronní nebo snapšoty dle planovače co se přenesou.
Hardware je dobré s nimi konzultovat předem než je posadit k hotovému.
Nekdo se zkusenostmi se Starwinds VSAN? Maji relativne slusne reference a jde to pouzit s DIY HW.
Diky, predpokladam tedy komplet reseni vcetne HW od Starwinds. Na cenu se ptat nebudu, tam roli hraje kapacita.
-
Nekdo se zkusenostmi se Starwinds VSAN? Maji relativne slusne reference a jde to pouzit s DIY HW.
pouze lokálně, nikdy jsem to neviděl nasazené na delší vzdálenost mezi 2 lokalitami. Pokud máš dva servery kousek od sebe a umíš je spojit přes L2 ne víc než přes jeden hop, je tohle naprosto skvělé a levné řešení, jak zajistit redundanci a live migraci virtuálů třeba s pomocí kvm.
Vůbec nikdy jsem to ale neviděl nasazené na větší vzdálenost. Není to bezstavové, na každém serveru potřebuješ mít jejich kontrolní službu, který to celé řídí a spojuje se s controllerem na druhé straně. Dobře tam je i řešení výpadků, kdy mají jednotlivé nody svoji prioritu a při pádu spojení, jen ten s nejvyšší prioritou může přijímat zápisy, tím se dá vyhnout split-brainu při zachování provozu z jednoho nodu. Mají tam heartbeat mezi nody a tady si myslím, že bude velká citlivost na latency, sice můžeš mít pomalé (asynchronní) replikace, ale node musí být pořád online.
Diky. Kolega sitar by L2 pres dedikovanou optiku nemel problem sestavit. SAN jsme ale sestavili pres L3 (vzdy preferuji pred L2). No poslu jim tam teoreticky PoC k posouzeni.
-
Nekdo se zkusenostmi se Starwinds VSAN? Maji relativne slusne reference a jde to pouzit s DIY HW.
pouze lokálně, nikdy jsem to neviděl nasazené na delší vzdálenost mezi 2 lokalitami. Pokud máš dva servery kousek od sebe a umíš je spojit přes L2 ne víc než přes jeden hop, je tohle naprosto skvělé a levné řešení, jak zajistit redundanci a live migraci virtuálů třeba s pomocí kvm.
Vůbec nikdy jsem to ale neviděl nasazené na větší vzdálenost. Není to bezstavové, na každém serveru potřebuješ mít jejich kontrolní službu, který to celé řídí a spojuje se s controllerem na druhé straně. Dobře tam je i řešení výpadků, kdy mají jednotlivé nody svoji prioritu a při pádu spojení, jen ten s nejvyšší prioritou může přijímat zápisy, tím se dá vyhnout split-brainu při zachování provozu z jednoho nodu. Mají tam heartbeat mezi nody a tady si myslím, že bude velká citlivost na latency, sice můžeš mít pomalé (asynchronní) replikace, ale node musí být pořád online.
Diky. Kolega sitar by L2 pres dedikovanou optiku nemel problem sestavit. SAN jsme ale sestavili pres L3 (vzdy preferuji pred L2). No poslu jim tam teoreticky PoC k posouzeni.
To se implikuje, starwinds vsan používá tcp (nebo rdma, ale to je pro jiný typ použití), potřebuje to ale jumboframe nebo výrazně padá iops, protože 4kb zápisy bloků na FS to rozloží na několik paketů a prostě to není ono, proto píšu L2 s miniem skoků. L3 s malým MTU a vysokou latencí je něco, kde jsem starwinds nikdy neměl potřebu provozovat a ani to neviděl.
Zkus je poptat, je to určitě dobrý nápad a třeba budou mít řešení i pro tebe. Cenově to ale stejně začíná na nějakých 100k Kč na node ročně s základní podporou a aktualizacemi.
-
Sry za off-topic, ale tyhle kidy se nedaj cist...
To je fakt, vis o tom lautrhovno ale zvanit picoviny ti to nebrani. Prijde vyzva ze vyjezd (klidne v podobe houkajici sireny,. ale to veleblb jako ty nemuze tusit), kdyz se lidi sebehnou tak dispecink mozna rekne ze nekde za vsi v udoli, a kdyz se dojede do udoli, bezi se na kopec, protoze neni signal. Kdyz typicky podle presne stejnyho zadani do stejny rite dorazej profici, tak dobrasi uz typicky aspon nekoho nechaj na krizovatce, aby jim ukazal kam.
Stejne tak tu zjevne zdejsi zvanilove vubec netusej, ze dobrasu je 80k zatimco profiku 20k. A v zavislosti na kategorri maji i ti dobrovolnici co to delaj zadarmo povinost vyjet do 5 minut. Ti mene retardovani si muzou pocist https://www.hasicido.cz/faq/co-je-to-jpo-i-az-vi/
Ty to necti, to nezvladnes.
-
Koukám že psychopat Keďar si založil duplicitní účet.
-
DELL EMC PowerScale
(DELL EMC VPLEX Metro Cluster)
-
DELL EMC PowerScale
(DELL EMC VPLEX Metro Cluster)
o tom jsme se tady už bavili a myslím, že to je cenově úplně mimo, to jsou miliony za krabici
-
Sry za off-topic, ale tyhle kidy se nedaj cist...
To je fakt, vis o tom lautrhovno ale zvanit picoviny ti to nebrani. Prijde vyzva ze vyjezd (klidne v podobe houkajici sireny,. ale to veleblb jako ty nemuze tusit), kdyz se lidi sebehnou tak dispecink mozna rekne ze nekde za vsi v udoli, a kdyz se dojede do udoli, bezi se na kopec, protoze neni signal. Kdyz typicky podle presne stejnyho zadani do stejny rite dorazej profici, tak dobrasi uz typicky aspon nekoho nechaj na krizovatce, aby jim ukazal kam.
Stejne tak tu zjevne zdejsi zvanilove vubec netusej, ze dobrasu je 80k zatimco profiku 20k. A v zavislosti na kategorri maji i ti dobrovolnici co to delaj zadarmo povinost vyjet do 5 minut. Ti mene retardovani si muzou pocist https://www.hasicido.cz/faq/co-je-to-jpo-i-az-vi/
Ty to necti, to nezvladnes.
Vem si prasek. Vyjezd chodi houakjici syrenou, a nejcasji pres gms sms ze. Dispecink to mozna nerekne ale rekne to urcite, odtoho tam je ze? Kolikrat tam procka ani nejedou. Nebo si myslsi ze procka jezdej ke kazde zapalene popelnici, to asi ne ze. Ano Dobraci jsou kalsifikovani podle trid, ja psal nejdelsi casovej udaj do kdy musej vyjet. Nechtel jsem aby ti rupla zbytecne zilka stim ze jezdej i driv. Ale delat znich idioty je fakt mimo misu. Takze navstiv sveho doktoram mediakce ocividne brani normlani diklsuzi a mela by se zmenit...