Názory k článku Velká řešení otevřeně: základní vybavení
-
peci1Stříbrný podporovatelJa to chapu tak, ze je to prvni dil serialu. Treba se popisu hw budou venovat nektere z pristich dilu.
-
Tak ono se da pracovat i s nespolehlivym HW. Snazim se vyhnout nejake reklame, ale tady to snad napsat muzu. Mam pozitivni zkusenost se SuperMicro 2U Twin2 servery. Do skatule se vejdou celkem 4 nody, ma to dva zdroje a ke kazdemu nodu se daji pripojit 3 disky (ve variante s 3.5"). Ma to presne to, co potrebuji -- vsechno alespon dvakrat, takze na vymenu neni treba vypinat cely stroj.
-
BobTheBuilderStříbrný podporovatelSnad jen to, že IPMI je v ceně, zatímco ILO funguje jen 5 nebo 10 sekund po startu systému a pokud chcete dál, musíte zaplatit licenci - na HP mikro server asi 5 tisíc, to se, vzhledem k ceně serveru, rozhodně vyplatí.
-
No... on HP microserver není ideální stroj pro "velké řešení", to je opravdu mašina pro náročného uživatele na doma, maximálně pro nenáročné blbosti v malé firmě a tam se podle mě vyplatí spíš připlatit pár korun za řádově lepší SuperMicro. Když se potom člověk se serverem včetně rozšířeného supportu a licencí na VMWare dostává běžně k částkám 300-500k, pár tisíc za iLO ho už moc netrápí, vzhledem k benefitům, jaké mu to v HA prostředí poskytne. A už přesně nevím, za co to bylo, ale i u SuperMicra se dalo připlatit za nějaké lepší funkce.
-
Trident (neregistrovaný)
No musim si rypnout. Srovnatelne s cenou za supermicro uz se daji poridit entry level servery Dell. Dell ma ted dost agresivni cenovou politiku. Po sleve pres jejich eshop polovina ceny. Po jednani z obchodakem jeste 15% dolu - opet end user(zivnostnik) cena. Zadna zvyhodneni pro firmy, zadne znamosti. Franta z ulice.
Takze mit orezane supermicro a nebo dell? Pro mne je volba jasna. No offense. Supermicro je blbe a drahe -
CHe (neregistrovaný)
Všetko závísí od scenára použitia. ZFS sice má zásadný benefit oproti bežnému mirroru v garantovaní integrity a samoopraviteľnosti. Nie je ale ani zďaleka "zadarmo", ak s ním chceš dosiahnuť nad rovnakou sadou rotačných diskov trochu porovnateľné IOPS charakteristiky ako by mal MDADM RAID 1 + trebárs EXT4, vyžadujte to brutálne zdroje (RAM, SSD keš) navyše. Už v bežnom setupe, bez deduplikácie. Inak si vyrobíš akurát tak spoľahlivý bottleneck, ktorý ti pri prvej trochu dlhšie trvajúcej I/O-bound záťaži úspešne zahltí mašinu.
-
CHe (neregistrovaný)
Pokiaľ sa bavíme o priepustnostiach (či už IOPS alebo BULK), relevantných pre rotačné disky resp. ich polia nad rádovo kusovými počtami fyz. diskov, je MD RAID prakticky transparentný. Výsledná charakteristika je daná prevažne charakteristikou diskov a I/O schedulingom.
Čo sa týka robustnosti (MDADM vs. hw. radiče), osobne mám skôr opačnú skúsenosť.
-
hw raid funguje jen kdyz ma poradne velkou cache (~1G) a dobrou baterku. To se hodi na raid6. Pokud chcete provozovat raid1, tak je vetsinou mdraid lepsi, protoze je tam o vrstvu min. Ta vrstva ma casto vlastni predstavu o tom, ktere operace maji byt rychle, a ktere pomale, a tato predstava se nekdy neshoduje se systemem. Potom je treba vysoka propustnost ale zaplacena zbytecne vysokou latenci na nekterych souborech. (To se mi stalo pred 7 lety s radicem Areca, bylo to na raid 6, takze mdraid jsme radeji nezkouseli).
Na takoveto "domaci serverovovani", s dvema disky per server je hw raid naprosto zbytecna investice. Staci cokoli co ma hotplug disku. -
Petr M (neregistrovaný)
No ale já vím. Mívali jsme v open space (50 lidí, průchoďák do dalších dvou kanclů) rack , normálně zamčený a nikdo z něj nikdy nic nevyškubal. To samý ve výrobě, cca 600 lidí na hale, třísměnný provoz a rack u dvěří do šaten, nikdy se nic neztratilo, nikdo nic nevypojil ani nevypnnul.
No a vzhledem k tomu, že se to celý asi nebude vznášet jenom tak v prostoru a je na to potřeba "vhodná skříň)", tak si o šifrování kvůli krádeži HDD myslím svoje.
A ještě je super, když WidloBFU ve firmě zlobí IS, restartne, nepomůže to, tak jde natvrdo resetovat server... Stroje prostě patří pod zámek a hotovo.
-
Trident (neregistrovaný)
Zrejme spatne technologicky navrzene prostory. Uz 25 let se budovy delaji s technologickym zazemim. Rozumej kazde patro ma mistnosti na technologie. A tim nemyslim jen IT, ale vzduchotechnika,EZS, rozvody topeni,vody,elektro atd. Uz budovy v realnem socialismu jako treba hotely mely naznak techto koutu pro udrzbare na patre.
Nechapu proc davas spatny navrh za vzor. Architekta bych hnal bicem.Je to jako postavit kotel v kuchyni nebo v loznici. Ano funguje to, ale to technologicke zazemi ma mit vyhrazeny prostor. Uz jen kvuli propojeni technologii,zapezpecni v jednom miste a propojeni take v jednom miste. U patrovych budov jsou to sachtove skrine, u velkych hal jsou sektorove rozvody s toutez filozofii akorat rozestavene na plose.
Mit rack v satne to musel navrhovat nejaky betonovy inzenyr strejchnuty vumlem a slivovici. -
Trident (neregistrovaný)
Dvouzdrojovy stroje jsou dneska docela bezny zelezo studentu pod stolem;) To je entry level. Navic x86 HW neni az na velmi specialni vyjimku v kategorii mission critical hw, takze tam ta redundance komponent obvykle neni na urovni nekolika motherboardu, cpu,pameti,radicu a tak dale.
-
Trident (neregistrovaný)
No mdraid je lepsi pokud mate dva identicke disky. Jenomze pokud se budem bavit pouze o urovni redundance, tak ZFS muze dobre fungovat i s ruzne rychlymi disky. Za behu si dela statistiky rychlosti a rozklada cteni/zapis dle rychlosti disku.
Hotplug disku umi kazdy levny SATA radic. Je to obsazene ve specifikaci. Pokud ne tak zkontrolovat drivery nebo reklamovat ze nesplnuje SATA specifikaci. SATA/SAS/FC/WTF=hotplug. Tecka. Na domaci serverovani uplne staci odhodit dekl a prepojit disky za behu bez suflu. Za studentskych let kdy bylo sata novinka tak spolubydla mel "manual cold spare" ze jen prehodil v kisne(pro prazaky pocitacova skrin) kabely z disku na disk.
-
j (neregistrovaný)
2lazywriter: Pata disky s tim problem nemely, problem s tim mel prevazne system/MB ... tomu disku je celkem jedno, jestli ho zapnes tak, ze sepnes zdroj, nebo tak ze do nej vrazis napajeni. Jenze nekdy pripojeni nebo odpojeni vedlo celkem spolehlive k sestreleni systemu /vytuhnuti MB. Coz ostatne plati na desktopech i se sata, byt to by to melo umet nativne ...
Druha vec je samo pomerne nevhodny mechanicky reseni, ale to se dalo osefovat suplikem.
-
Trident (neregistrovaný)
Je treba rezervovat zdroje na ZFS a rici co potrebuji. Dnes je vykon na CPU levnejsi nez vykon na storage. O RAM to pravda uz tak neplati. Stale je vsak x86 zeleza zvykem pohybovat se pouze ve stovkach GB RAM . Jinak lze ZFS premluvit tuningem aby nepouzivalo optimalizace. Nicmene otazkou je take na jakem OS a jakem zeleze. Na solarisu mam celkem dobre zkusenosti. U ZFS je i vyhoda ze pokud mas slabou storage nebo malo vlakno na disky, tak se da pomoci komprese prohnat vice dat byt s vyssi latenci.
Zalezi na use case. Napriklad na DB zatez bych spise doporucil pouzivat raw device bez filesystemu a mit tam primo vnitrni fs databaze. Tam je ZFS paradoxne vice na obtiz.
Na proti tomu kdybych delal nejaky rozsahly datovy sklad napriklad digitalizovanou knihovnu tak ZFS je prvni volba+nejaka replikace.Je treba si uvedomit, ze ZFS je navrzen puvodne jako backend filesystem pro vetsi NAS a SAN a jako konkurence veritasu. Tam se pocitalo s dedikovanym strojem na managementzpracovani a rozdilnym nastavenim.
Dalsi vyhoda ZFS je ze se spousta veci vylepsuje a zpousta veci jde v novych verzich i vypnout. A neni to zas az takovy problem protoze umi online upgrade a iopy ktere upgrade resi maji nizsi prioritu.
-
. Napriklad na DB zatez bych spise doporucil pouzivat raw device bez filesystemu a mit tam primo vnitrni fs databaze. Tam je ZFS paradoxne vice na obtiz.
Z toho většina databází už vyrostla. Navíc většina filesystémů není problém nastavit tak, aby se starali prakticky jen o alokace bloků souboru a zbytek byl více nebo méně raw. A té alokaci bloků zase napomáhají databáze tím, že alokují po velkých kusech. Výhodou takového řešení je, že se z toho dají běžnými nástroji vydolovat data v případě různých problémů. Navíc se to dá ve vypnutém stavu zmigrovat na oddíl jiné velikosti. Jádra mají dnes docela dost možností jak jim vysvětlit jaký workload od toho souboru databáze očekává. To má pak výhodu, že není potřeba extra disk na systém. (Dávat databázi jeden diskový oddíl je vzhledem k různým blokovým keším v jádře podobné jako dát jí vhodně nastavený filesytém.) -
Rhinox (neregistrovaný)
O btrfs bych ja osobne neuvazoval pro nic vic, nez muj desktop (nebo nakej testovaci servr). A v tom pripade musim byti pripravenej na to, ze mozna prijdu o vsechny data (ktere sem nezalohoval).
Ano, mate pravdu ze zfs neni na debianu dlouho, presto je to lety proverenej filesystem kteremu ja duveruju mnohem vic, nez btrfs (jehoz vyvoj jaksi zustal stat, alespon ja mam takovej dojem) nebo kombinaci mdadm+lvm+ext4. Pamet a ssd jsou dnes tak levne, ze neni zadnej problem narvat do servru kolik se tam toho vejde. Taky je to otazka osobnich skusenosti. Jak se rika, jednou skusis ZFS, a pak uz nechces nic jinyho...
-
No nevím, ale nemám z toho nejlepší pocit... první fail je už obrázek u článku, na každé krabici se serverem je napsáno, že ho mají nosit 2 lidi, na velkých krávách jsou někdy i 4 (a světe div se, při manipulaci s krabicí v ceně auta, někdy i luxusního, se to dodržuje). Nehledě k tomu, že ten obrázek ukazuje celkem pěknou serverovničku, ale článek vypadá spíš na nějaký domácí experimentováníčko.
Ale to bylo jen malý rejpnutí, teď k věci...
Vzhledem k tomu, že evidentně půjde o seriál, v kapitole "Základní vybavení" bych očekával základní vybavení, nástřel toho zmíněného rozhodování, co má být spolehlivé, trocha s tím související teorie, co je to SPOF, rozhodně bych zmínil možnost použití samostatného úložiště (SAN), k základnímu vybavení clusteru rozhodně patří i něco na zálohování, UPSky, rozhodně by bylo na začátku dobré nějaké rozdělení clusterů, minimálně HA a HPC, ale je toho víc, tahle kapitola měla být minimálně 5x delší, nebo jí měla předcházet nějaká čistě teoretická...
Popis produkčního stroje jednou větou... redundantní zdroj a RAID 1... opravdu? A co ECC, nebo dokonce memory mirroring, co zálohovaný řadič? Já chápu, že to jsou věci, které doma člověk nevyzkouší, ale pokud chci někoho uvést do problému, měl bych mu alespoň říct, jak to má vypadat. Samotné zkoušení nějakých služeb už se pak dá řešit klidně na RPi a není důvod si pořizovat dva plnohodnotné stroje, které jsou na doma zbytečné a na skutečnou produkci nepoužitelné... -
Ondro (neregistrovaný)
Ja by som tiez cakal na uvod detailnejsi popis o co v tomto seriali pojde. Privatny cloud je buzzword a kazdy si pod tym moze a predstavuje nieco ine.
Ja som podla popisu cakal HA s CEPH, DRBD alebo GlusterFS. Namiesto toho som precital nieco tazko zrozumitelne, z coho som nepochopil o co autorovi ide. -
j (neregistrovaný)
Defakto stavi odpadky a rika tomu "velke reseni".
SAN budes delat uz pro 5+ ks HW zcela jiste, protoze te uz vyjde levnejs, a vykon bude o par radu jinde. Reduntance zdroje je ti naprd, pokud nemas osefovany radice a dalsi komponenty. Navic to defakto vubec nepotrebujes, pokud mas data na poli, a aplikace je navrzena jako cluster, tak to sou zbytecny naklady navic.
A jak pises, pokud bys chtel realne resit to, aby vec nemela SPOF, tak tech veci ktery budes muset duplikovat bude o poznani vic - vcetne treba toho ze kazdou jednu vec musis pripojit k nejmin dvoum prvkum infrastruktury - at uz eth/fc/...
Navic jaksi naprosto chybi zminka ... o financich. Zajimavy ze to nejpodstatnejsi nikdo neresi. Protoze pokud me vypadek na tejden stoji par (tisici) korun, tak nema vubec smysl investovat jakykoli penize do nakupu redundantniho HW.
-
Ondro (neregistrovaný)
Nemusi stavat odpadky. Vsetko zalezi na co to ma sluzit, to nam ale autor zabudol povedat..
Existuju scenare, kde vypadok radovo v hodinach(az den) je v pohode, tak tam je pouzitie tych "odpadkov" uplne OK.Ak si mozes dovolit len kratky vypadok +- do hodiny, tak aj tam sa to da riesit s "odpadkami" viacerymi sposobmi.
Ak si nemozes dovolit vypadok, tak je to znovu o niecom inom a aj tam sa to da riesit viacerymi sposobmi.
Fiancie nikto neriesi, lebo autor zabudol napisat co od toho ocakava. Takze mozme len teoretizovat.
-
Pravda, mozna jsem se mel vrhnout do rozepsani, kde to pouzit, ale prostoru bylo malo. Snazim se tu psat o zkusenostech, ktere mohou byt prinosne pro mensi firmy, ktere si nemohou dovolit typicke reseni na klic za vice jak sesti mistne sumy. Tomu take odpovida pozadovany level spolehlivosti. chci maximalizovat dostupnost (vypadky jsou OK, jsou-li kratke nebo mimo pracovni dobu a pokud se neztrati data), minimalizovat nutnost okamzitych zasahu (opravdu nechci v deset vecer o vikendu jezdit x kilometru vymenovat kritickou komponentu) a zaroven se potrebuji vejit do pro firmu rozumneho cenoveho limitu. Uz jenom tech cca 80 tisic za zakladni HW se tezko obhajovalo.
-
Trident (neregistrovaný)
80kkc je kapesne za ktere jsem porizoval IT vybaveni labu do domu z ebaye abych se mel kde ucit na certifikace. Kurzy staly 60kkc +50kkc rozsireni. Takze jsem usetril a nemusel jsem se strkat s hlupaky v labu u alefa. Pokud firma nedokaze odhadnout rizika ztrat dat a resit takovou nickovou castku, tak nema v oboru co delat.
-
Palo M. (neregistrovaný)
Podla mna ten clanok je trocha o niecom inom. Doraz je na otvorenych technologiach, autor tiez spomina "maly privatny cloud" a zatial "najmenej dva servery", co tak trocha naznacuje o com to bude. Zatial to vyzera, ze by z toho aj mohol byt nejaky skutocny cloud (nie ako OwnCloud ktory ma ten cloud akurat tak v nazve), ale postaveny vlastnymi silami na pomerne beznom HW.
Nadupany hardver (ci uz su to servery, diskove polia, alebo routery) su sice pekne veci, ale potom si zavisly od dodavatela, takze sa z velkej casti straca to caro otvorenych technologii vo vlastnej rezii, pretoze ked uz valis velke peniaze za HW support, tak mozes valit aj velke peniaze do SW supportu a nemusis nic riesit - lenze potom by o tom nebol takyto clanok (resp. by bol clanok oznaceny ako "komercni sdeleni").
Sice si autor nedal vela prace s uvodom a rovno vhupol do instalacie a rozdelenia disku, takze je trocha nejasne co ma vlastne byt vysledok, ale zase keby dal siahodlhu teoreticku omacku, tak by sa v diskusii aj tak vyrojilo plno kritiky, ze su to len take kecy a nic konkretne (plus klasicke nesuhlasne nazory, ze to treba robit cele inak). Takto mame zatial aspon zaciatok z praktickej stranky.
Ja to nevnimam tak tragicky. Je to prvy clanok mladeho autora, tak asi nebude hned produkovat rovnaku kvalitu, ako ostrielani matadori...
-
No já bych to viděl docela špatně, protože jeden ze dvou požadavků na HW - dual PSU, nepatří úplně do kategorie běžných domácích bastleníček, čemuž odpovídá i honosný název začínající slovy Velká řešní. Zatím to vypadá na velkého kočkoprasopsa a trošku se obávám, že článek je nejen nekvalitní (zmatený), ale především obsahuje velmi nekvalitní informace. Kapitola "základní vybavení" tak obsahuje cca dvě věty o základním vybavení, jejichž informační hodnota se limitně blíží nule, zato obsahuje spoustu další omáčky bez jakékoliv návaznosti.
-
j (neregistrovaný)
Viz Tuxik. Bud si stavim soho skladacku ... kde mi jak sem rek vypadek zily netrha, a pak mi de defakto maximalne o to, abych neprisel o data. Rozhodne pak neresim dualni napajeni, protoze to je zcela mimo realitu provozu.
Jakmile ale zacnu resit dualni napajeni === neco od ceho ocekavam ze to jen tak znicehoz nic nelehne na HW chybu, tak jednoznacne resim i spoustu dalsich aspektu, jinak je mi to dualni napajeni leda naprd. A ty dalsi aspekty = spousta dalsich penez (a bavime se minimalne v radu stovek tisic).
Protoze ... dva servery, kazdej aby mel co mit ma(tzn nejen dva zdroje, ale i dva radice atd atd) ... tak to bude za 100k kazdej (nejmin). K tomu dva switche ... dve upsky (kdyby jedna posla) ... a zacinas atakovat 1/2M. (jo a jasne, da se koupit 1Ucko za 30k ... se sata diskama, onboard sata radicem, a jednim zdrojem)
Tohle je takovej clanek pro nic a vo nicem ... budem kupovat dva servery s dualnima zdrojema (kazdej jeden zdroj za petiltr navic nejmin) ... ale na management kartu uz 15 stovek nemame (nehlede na to, ze u kazdyho normalniho zeleza je minimalne nejaka zakladni verze standardni soucasti) ...
Pricemz autor uz v nazvu deklaruje ze chce velka reseni === v milionech nikoli Kc, ale $.
-
Hm. Nazev clanku tedy asi nebyl zvolen uplne nejlepe. Ale ono nadpis "Chceme si hrat na velke reseni, ale nase penezni moznosti jsou blizke nule, takze se k tomu jen zkusime priblizit" taky zrovna neni vhodny napis.
Jinak vypadek zily netrha, pokud si ten vypadek pocka na konec pracovni doby. Dualni napajeni je velmi pohodlna vec, ktera umoznuje veci jako vymenu UPS bez nutnosti vypnout server. Navic uz jsem videl dost vyhorelych zdroju na to, abych vedel, ze spolehat jen na jeden se nevyplaci.
-
CHe (neregistrovaný)
Solídnejšie zdroje by mali obsahovať ochranné prvky (tlmivky, transily, varistory) vo vstupnom obvode aj na výstupných vetvách. V lacných spotrebných často nie sú kompletne osadené ani tie vstupné (ako spomienka na ne tam bývají prázdne pozície resp. drôtové prepojky na PCB). V kombinácii s nevhodne dimenzovanými prvkami samotného meniča je pri nich najväčšie riziko, že so sebou na odchode zoberú aj napájané komponenty.
-
Diky. Ano snazim se o nastin problemu a reseni, kdyz si chce clovek vybudovat neco, cemu se nestydi rikat cloud. Jedina vetsi investice je tedy vlastne HW. Ano, lze to vybudovat i na RPi, ale bude to pomale. Ale, lze to delat na jednom kancelarskem PC, ale mohou nastat neprijemne vypadky v nejmene vhodnou dobu.
Uvody pisu strasne nerad a clanek ma byt prakticky. O unudeni k smrti teorii se casem pokusi snad nekdo jiny.
-
No... překvapení, on ten Dell může stát něco od 30k do 1M, u bladů se dá dostat i o dost výš. Pokud se budeme bavit o "velkém řešení", tak ten dell za 30k se hodí tak maximálně na monitoring.
Jinak představa "velkého řešení" osekaná na dva servery - 2x server dle potřeby, 2x SAN pole, 2x 16G FC switch, 2x 10G network switch, 2x dostatečně velká UPS. I když osekáš výkon, paměť, diskovej prostor... už jsi někde u mega a to by bylo nanejvýš vhodný k tomu mít ještě nějaký zálohování na externí média (pásky).
-
j (neregistrovaný)
Asi tak nejak ... a realita ...
SAN ... jedna police, kombinace SSD + HDD ... cca 1M ... to cele 2x, pokud si chceme hrat na cloud.
Server - 1U 2x CPU ... 256GB ... cca 300k
FC switch ... cca 200k
10G ... dtto.
UPSka, ktera to vsechno utahne 2x ... cca 100k.Takze ... vcetne nejaky bizuterie kolem, sme na +- 2M ... za 1/2 ... kdyby to vsechno melo bejt 2x, tak +- 4M.
Pricemz se bavime o maximalne midrange HW (= to pole rozhodne neda vic nez 5 polic). Zalohovani k tomu bude za dalsi minimalne stovky tisic (v nejjednodussi variante rekneme 150k HW + SW ....)
-
Sifrovani boot partition? To jako nema bezet 24/7? Protoze jestli jo, tak bud poznate, ze to je vypnuty, nebo se do toho dostane utocnik za behu, a pak je oddil pripojeny, takze utocnik ani nepotrebuje heslo znat... Pokud vymenujete disk za ziva tak snad ani neni sance, ze by se z noveho disku data pouzila. A pokud s tim sam manipulujete za vypnuteho stavu, tak si stejne musite byt jisty, ze vam nekdo nedodal modifikovany disk (s vlastnim nezasifrovanym bootovacim oddilem). A k sirfovani toho ostatniho, kde ze to vlastne planujete ulozit heslo, tak aby se ho utocnik nedozvedel? Nebo to po zapnuti potrebuje manualni zasah?
Jediny prinos zasifrovaneho oddilu vidim v tom, ze teoreticky neni nutne disk pred vyhozenim promazat, pokud by na nem mohla byt citliva data. Ale tady se vracim k bezpecnemu ulozeni klice. Pokud to nema byt na tom serveru, tak by bylo asi nejlepsi aby bootoval ze site (aby se daly disky vyhodit), pak ale nepotrebuju zadny bootovaci oddil.
Jestli mate nekdo scenar, kdy by na 24/7 serveru davalo sifrovani smysl, tak se podelte. Ja ho tam moc nevidim.
-
Pro případ, že disk (celý server) někdo ukradne? Ale je to trochu mimo... to podstatné v článku z velké části chybí a to, co tam tak nějak logicky nezapadá, o tom je největší část. Každopádně, pokud jde opravdu o citlivá data, tak nezbývá, než to zašifrovat celý. On se normální server nerestartuje každej druhej den, aby byl takovej problém ho jednou za čas nahodit a klidně i osobně, když už tak moc nevěřím idrac/ilo/ipmi.
-
Crow (neregistrovaný)
> Pokud to nema byt na tom serveru, tak by bylo asi nejlepsi aby bootoval ze site (aby se daly disky vyhodit), pak ale nepotrebuju zadny bootovaci oddil.
Chápu to správně, že by se přes pxe natáhnul do paměti os ze kterého by se pak normálně fungovalo? Jak bych třeba potom řešil mount disků? Je to reálné použitelné/nasaditelné?
Vždy mi tahle možnost přišla z nějakého důvodu atraktivní.
P. S. Jako scénář by mě asi napadla razie státních orgánů. To jestli chci mít s takovým serverem něco společného je otázka jiná.
-
Adam KaliszStříbrný podporovatelJoyent to se SmartOS dělá. Je to někde na videu s Bryanem Cantrillem. Mají víc místa pro uživatelská data... a 300 MB image navíc není tak moc na dnešní RAM.
-
pf (neregistrovaný)
Sirovani disku na serveru snad jedine proti fyzicky kradezi, kdyz lezi server nekde na koberci v serverovne/normlani mistnosti nekde v mensi/stredni firme.
Automaticky odemceni po restartu se da celkem jednoduse udelat tak, ze se velkej datovej RAID (kde sou ty dulezity data) ani nemusi pripojujovat pri bootu, ale klidne az po bootu se do /etc/rc.local prida skript, kerej si sahne klidne po ssh nekam na sit a veme si klic k sifrovani RAIDu a odemkne ho. Po kradezi se ten sitovej klic da hned zneplatnit (smazat) + chranit pristup na nej z jinejch siti.
Pokud nebudeme chtit ani aby to sahani na sit pro klic nebylo citelny ve forme skriptu, da se udelat binarka v Ccku (nebo čemsi) a je to zas o kus dál.
Treba. -
Aby to fungovalo opravdu dokonale, bylo by potřeba, aby po rebootu klíč byl alespoň dočasně nedostupný, protože když se k tomu někdo dostane fyzicky, rebootuje, spustí si z flashky nějaký live distro, přečte klíč přes ssh a maže i se serverem pryč. Obfuskace binárkou místo skriptu je dost chabá, když někdo ví co dělá a navíc třeba může i vědět, jak je ten systém udělanej (špatně placený zaměstnanec to mohl vykecat, vyhozený zaměstnanec se mstí...). Ale potom to jaksi ztrácí smysl, protože po regulérním rebootu to bude zase stejnej opruz. Maximálně by šlo na regulérní reboot vypnout dočasně to zneplatnění, ale v ten moment je opět server zranitelný, i když jen chvíli. Jakýkoliv ústupek v otázce bezpečnosti se může nevyplatit a pokud se jedná o opravdu cenná data, je třeba počítat s lidským faktorem - takže s čímkoliv. Ono je kolikrát velmi těžké domyslet, jaký důsledek může mít byť jen minimální ústupek a obecně bych řekl, že buď jsou to nějaké nepříliš zajímavá data a na šifrování se můžeme vykašlat, nebo je to něco, co by mohlo někomu stát za problémy a pak je potřeba to udělat pořádně. Když už by byl někdo ochotný kvůli datům naběhnout do datacentra, zdolat ochranku, dostat se přes několik dveří až k racku a ukrást server, pak už je potřeba počítat s čímkoliv.
-
Problem je v tom, ze server je kdesi v rackove skrini, kam muze mit pristup cizi osoba. Neni tedy problem, aby sel nekdo okolo a rekneme "vytrhl" disk ze serveru. V takovem pripade je dobre mit disk sifrovany. Vypnuty server sice poznam, ale to uz take muze byt pozde a data zcizena. Heslo samozrejme nikde ulozene neni, ale zadava se manualne (IPMI, SSH, fyzicka klavesnice). Proto je vhodne, aby se nemusel moc casto delat reboot a pripadne se zde daji delat ustupky mezi mirou zabezpeceni a pohodlnosti. Taky bych mohl odemykat HW tokenem, ale to opravdu znamena k tomu serveru prijet, coz neni vzdy mozne.
-
Fyzický přístup třetí osoby k serveru osobně považuji za problém. Může se pokusit pomocí díry v nějakém usb ovladači získat přístup, může vložit "sniffer" na lan a pak zapříčinit "náhodný" výpadek proudu. Pochybuju, že to IPMI bude zabezpečené. Ještě tak to SSH by se dalo, ale v tom případě se nebavíme o zašifrovaném bootovacím oddílu. A pak je zase otázka, jak zjistit, že nenabootoval systém upravený o keylogger. Zůstává pak jen možnost startovat to s fyzickým přístupem (aby člověk mohl udělat fyzickou kontrolu serveru při startu). Ostatní možnosti jsou spíše jen pocit, než bezpečí.
Takže uzamykatelný rack, a komunikaci mimo rack pouze zabezpečeným protokolem (pro účely nabootování). Jinak se bavíme pouze o teoretickém zabezpečení, nebo ekvivalentu FABky na dveřích u bytu. Ta se ale dává jen proto, aby náhodný kolemjdoucí neměl nutkání krást. Běžně zkušený zloděj takovou obranu překoná.
Stejně tak tady bych použil nejprve mechanické zabezpečení, to se alespoň nedá hacknout po síti, a většinou vyžaduje fyzickou (občas i hlučnou) manipulaci, u které je šance, že si někdo všimne něčeho podezřelého. Pak teprve bych řešil jakékoli elektronické zabezpečení proti mechanické manipulaci. -
. . (neregistrovaný)
těch případů, které to řeší je ale více, pokud mám třeba nový HW, disk se porouchá, chci ho dát na reklamaci. V případě, kdy nešifruji, mám problém, ona fyzická likvidace mě stojí víc než samotný disk a k tomu mi ještě u sešrotovaného disku neuznají záruku. A porouchaný disk se špatně maže.
Pokud má server raid řadič, šifrování často za menší licenční poplatek zvládá samotný řadič a za odměnu si nechá klíče jen pro sebe a není potřeba nikde nic zadávat při bootu.
-
To je stejná úrovneň bezpečnosti jako mít ty klíče třeba na USB nebo SATA flashce na vnitřím USB nebo SATA portu na motherboardu. Pak ale nic nebrání tam mít celý boot. A můžou ty flashky bejt pro jistotu dvě v raidu 1, pokud chce mít člověk jistotu. Některé motherboardy mají dokonce takovou flashku přímo na desce (to byl myslím nějaký 2U server od HP).
-
. . (neregistrovaný)
jak se to vezme, z HP Smart Array ty klíče reálně nedostaneš, z flasky si je zkopíruješ aniž by o tom někdo věděl, ten HP třeba maže klíče, když ho zapojíš do jiného serveru.
Ano, těch možností je spousta, boot na flashce nebo přes ipxe je také často vídané řešení, nechci polemizovat nad tím co je bezpečnější, to se bez znalosti prostředí a očekávaných útoků říct nedá.
Chtěl jsem pouze oponovat tomu, proč je užitečné data na disku šifrovat, s novou EU legislativou to bude daleko ožehavější a začnou se disky šifrovat častěji.
-
No, vlastně se to dá shrnout do toho, jestli bráníme heslo proti:
1.) někomu, kdo může ten server otevřít, vlézt dovnitř a cokoliv tam vyndat/zandat
2.) někomu, kdo získá práva roota na běžícím serveru
V bodě dva si takový člověk může stáhnout data přímo. V bodě jedna může mít možnost donutit server aby nabootoval jeho operační systém aniž by manipuloval s řadičem, takže se také dostane k datům. Je tam velmi úzký use case kdy to tu bezpečnost zvýší, ale mě to připadá, že to spíš umožní šifrovat disky bez ohledu na to, jestli a jak rozumí správce šifrování systémem. -
M. (neregistrovaný)
Ono to záleží na té implementci šifrování v tom HW řadiče. Výše byl zmíněn případ HP řadičů.
Ale jsou řadiče, které to mají výrazně rozšířeno, takže třeba jsou spojeny i s detekci narušení HW, takže když někdo zkusí server otevřít (i ve vypnutém stavu), tak pak už řadič nedovolí nebootovat. Stejně tak slušnější řdiče mají v sobě čidla na vibrace, teplotu, radiaci, akcelerometry, ..., takže řadič mající v sobě šifrovací klíče odmítne nabootovat nebo přímo klíče smaže při detekci, že se serverem hýbalo, zkoušel ho něko otevřít, případně mrazit/zahřívat, navrtat atd... no, tko vybavné řadiče už nebývjí v základu a doplněí zvedá cenu serveru násobkem.
Samozřejmě toto neřeší ten bod 2, že někdo získá práva na běžícím serveru, to už se musí řešit jinými prostředky, ať už šifruji celé disky jakýmkoliv způsobem.
Ale tento článek se zabývá low cost řešením pro malou firmu, kde nejde postihnou vše v daném rozpočtu. Zde otázku fyzického přístupu k serveru v kumbále může řešit "dostatečně" nasraný párek hladových dobrmanů a šifrování disku řeší třeba hlavně to, aby nunikla data přes zatoulaný disk (kdo řeší toto vážně, tak stejně disk na konci životnoti nebo i při selhání prohání drtičkou, ať byl/nebyl obsah na něm šifrován). -
dfghjklô (neregistrovaný)
Zvazujem stavbu GPU farmy, ktora by obcas luskala duhove tabulky a vo volnom case.. treba Monero alebo Ethereum (bez nejakych ocakavani, len pre radost).
Nejaky tip na chladenie? Vodne, nech je to tiche? Olej-style Wedos?
Tip na hw, co podporuje vela RAM (512GB?) - jj, pozriet ponuku a potom specifikaciu, ale ci nema nejaky super tip.
Tip na stavbu lowend diskoveho pola zo starych diskov? :-D
-
Já tedy nechci radit, rozumím tomu, že se chcete podělit o zkušenosti, ale domluvil bych se s redakcí, ať to stáhnou a začal bych znovu a lépe. Nadpis: Řešení privátního cloudu pro malé firmy. Pokračoval bych napsáním úvodu, kde popíšete, čeho chcete dosáhnout, komu a na co to má sloužit, že je kladen důraz na nízkou cenu s ohledem na co nejlepší zabezpečení a spolehlivost v rámci daných možností atd atd. Rozhodně bych se vyhnul nějakým honosnostem a nikdy, NIKDY, NIKDY bych už nepsal, že k serveru má přístup každej jouda z ulice, kterej může vyškubnout disk a utéct. Jestli má být tohle alespoň mírná propagace amagical.net , tak jste si právě vyrobil tak neskutečně negativní reklamu, že příčetnej majitel jakékoliv firmy si od vás neobjedná ani balík kancelářskýho papíru.
Nebo máte druhou možnost, soustřeďte se jen na SW technologie a raději vůbec neřešte HW stránku věci, prostě popište jednotlivé služby, k čemu jsou, jak je nastavit atd.
To, co je napsáno v článku, to je fail, ale to, jak jste to dorazil v komentářích, pro to už neexistuje ani výraz. -
Ne, opravdu to nema byt zadna propagace (je snad clanek oznacen jako komercni sdeleni?), ale pokus o predani zkusenosti. A mohu prosim konkretne vedet, cim jsem to podle Vas dorazil?
Jinak situace v mensich i strednich firmach je takova, ze servery jsou sic zamcene v racku v hostingovem centru, ale to neznamena, ze k nim nema pristup kazdy z ulice. Spoleham se jen na obsluhu centra, ze se tam nikdo nedostane. V tomto pripade je ma duvera znacne omezena, takze se snazim unik dat minimalizovat vhodnymi prostredky.
-
"Velká řešení" = "Uz jenom tech cca 80 tisic za zakladni HW se tezko obhajovalo"
"Chcete provozovat služby s nepřetržitou dostupností?" = "vypadky jsou OK, jsou-li kratke nebo mimo pracovni dobu a pokud se neztrati data"
"znamena k tomu serveru prijet, coz neni vzdy mozne" - dříve zmiňovaná nepřetržitá dostupnost znamená, že to musí být možné
"servery jsou sic zamcene v racku v hostingovem centru, ale to neznamena, ze k nim nema pristup kazdy z ulice" - nevím, jak vy, ale já se v datacentru prokazuju občankou a dveře otevírám kartou a otiskem prstu, rack nemáme s nikým sdílený a je zamčený. Jak jsem psal jinde, pokud máte pocit, že jsou data natolik cenná, že to někomu za to stojí, potom ano, šifrovat, ale komplet, jinak to opravdu nemá cenu, pokud se chcete bránit proti někomu s fyzickým přístupem.
Celé je to strašně nekonzistentní, mícháte dohromady rádoby profi řešení s bastlem. Nevím, čeho se přesně snažíte dosáhnout, ale zatím mi na to stačí dva HP microservery, na nich nějaké qemu s virtuálkami, synchronizace disků přes drbd a peacemaker, který to řádně zclusteruje. Tohle vám za těch 80k dodá schopnej studentík i s prací a ještě jako bonus k tomu přihodí levný NAS na zálohy, nějakou menší UPSku a switch. Nemusím řešit dual PSU, což je na tento use case overkill, dokonce bych se mohl vykašlat i na raid v rámci každého stroje, který stejně bez poctivého řadiče se zálohovanou cache nemá moc význam, protože ačkoliv sw raid funguje a na spoustu věcí je dostatečný, ve zvláštních případech by se dalo o konzistenci dat polemizovat.
Jak jsem psal, zcela bych se vykašlal na HW, protože to je opravdu kapitola sama pro sebe a evidentně v tomto ohledu nemáte kdovíjaké zkušenosti. Raději bych se pustil do popisu jednotlivých SW technologií.
-
V Z Vasich zkusenosti vyplyva, ze nejste cilova skupina tohoto clanku. Muzete si pred vsechna zminovana tvrzeni treba dodat "Chceme-li se pokusit o ...".
Ja se tkae prokazuji obcanskym prukazem, nicmene pak uz je vse na obsluze datacentra, ktera mne po otevreni dveri opousti. Nemam ozkousena, nakolik jsem pozorovan a zda by si nekdo dostatecne rychle vsiml pokusu o vniknuti do jineho racku. Dalsi vec je, ze ne vsichni si mohou dovolit ten luxus nesdileneho racku, pak je urcite dalsi ochrana na miste.
O nutnosti komplet sifrovani jsem psal. Doplnil jsem jen ustupek v podobe nezasifrovane boot partition, ktery by pri spravne kontrole, ze opravdu bootuji to, co mam, nemel snizovat celkovou bezpecnost. Navic odemykani pomoci SSH povazuji za bezpecnejsi nez skrze IPMI.
-
No cílovka asi nejsem, na tom se shodneme, to ale neznamená, že mě podobné open technologie nezajímají, i když v této oblastí máme většinu řešení komerčních. Ale mě by spíš zajímala ta opravdová cílovka, nějaká koncepce, kam se tento seriál ubírá. To z vás leze jak z chlupaté deky a pokud nemáte nějaký opravdu zajímavý use case, nevidím v tom vůbec logiku. Dejme tomu, že pro low cost řešení se md raid 1 používá, takže s tím se smířím, ale pořád mi tam nesedí ty zcela z kontextu vytržené dual PSU, které udělají v ceně pěkných pár tisíc rozdíl, což mi přijde na úplně mimo, pokud je cílem HA cluster a krátké výpadky a delší odstávky mimo pracovní dobu jsou v rámci ceny přijatelné, potom to nemá žádnou cenu. Takže v rámci dalšího pokračování vám doporučuji přesně to, co jste sám částečně psal a neudělal. Řekněte, jakých služeb chcete dosáhnout, posuďte rizika, pokud to má být HA, tak si to nakreslete, zjistěte, kde a kolik je SPOF, rozdělte si je podle pravděpodobnosti selhání a potom je od těch nejvážnějších začněte eliminovat. Pokud dojdete k tomu, že jich půlku vyřešíte a půlku ne, je třeba přehodnotit, jestli některé z těch vyřešených nejsou zbytečnost a řešení tomu přizpůsobte.
Příklad:
služby jsou používané z internetu -> musím mít dvě konektivity -> dva routery -> pokud je landcape složitější, tak dva switche -> každý server dvě rozhraní (a ideálně nezávislé). Pokud hned na začátku vím, že dvě konektivity třeba kvůli ceně nechci, nebo není v místě možnost, vše ostatní můžu klidně škrtnout. A takhle se musí postupovat se vším. V ideálním případě se musím zamyslet ještě dál, použít AS, BGP routery, pak je dobré zjistit, do jaké míry jsou konektivity nezávislé. Případ zákazníka ze života: V Brně měl hlavní připojení přes optiku většího poskytovatele a zálohu přes nějakou menší firmu přes bezdrát. A co se nestalo, většímu poskytovateli se něco hodně pokazilo a od koho si myslíte, že měl konektivitu sekundární menší poskytovatel? Ne, že by ta záloha byla úplně k ničemu, mohlo se pokazit koncové zařízení providera, nebo něco těsně před ním a potom by to ta záloha zachránila, ale je to řešení napůl a je dobré o tom vědět. -
j (neregistrovaný)
2bez přezdívky: Ty zjevne nechapes, co se ti tu tuxik snazi rict ...
1) vubec nevis co to je velky reseni => pouc se a prestan tvrdit ze tvoje reseni je velke
2) patlas dokupy zcela nesmyslny pozadavky => opet, ujasni si, co ma byt cilem.Jestli je tvuj rozpocet 80k, tak to je soho bastl. S tim se smir, proste to tak je. Tudiz zacatek celyho clanku mel (vcetne nazvu) byt uvozen (napr) "jak poridid co nejvice muziky s velmi omezenym rozpoctem", pricemz si tam tech 80k mel napsat.
Dal si mel vyjmenovat pozadavky. Tudiz napriklad ... ze vypadek provozu do ... hodiny, neni zasadni problem (ve skutecnosti, a to se klidne vsadim, neni problem i celodeni vypadek, pri tomhle rozpoctu mozna ani vice dnu).
Tudiz ... pokud mas 80k na HW ... tak za to rozhodne neporidis nic moc. Takze, zapomenme na dva switche, switch se da koupit v nejblizsi garazi, management netreba. Kdyz nejde elektrina, stejne pojdou desktopy, tudiz ani nema smysl switch zalohovat.
Dal, kolik vykonu potrebuju pro beznej provoz toho co chci provozovat ... tzn kolik ramky, kolik cpu ... predpokladam nejakej sambashare, nejaky maily ... a pri tomhle rozpoctu +- vsjo. Nepocitam s nejakou placenou databazi, maximlane neco co vyuziva mysql/acces(=ta samba)/... ale to musis vedet TY.
Kdyz tohle vim, tak muzu definovat HW - zase placnu, vystacim si s 8-16GB ram, protoze na tom nebudu provozovat zadnou virtualizaci a chci to maximalne jako diskovou cache. Rekneme ze chci ty disky sifrovat, takze bude fajn, kdyz tam bude CPU s AES-NI. Protoze disky jsou nejchcipavejsi potvory, dam si tam dva do zrcadla. SSDcko nepotrebuju, protoze je to overkill ...
A rekneme ze by bylo fajn, kdybych to moh dat do racku aby to trochu vypadalo ... takze podivam se jak sem na tom, nebude rozhodne sas, bude sata, nejakej levnej dell nebo hp ... bude novej stat kolem 30k jeden, to by bylo 60 za dva. Bude to nejspis s 3-5y NBD.
Chci to? Potrebuju to? K tomu za rekneme 5k za malej rack, Rekneme 3k za ne uplne shit switch. Zbejva 7k, takze poridime upsku ... a sme na nule.
Nebo ... pudu do frcu a ty samy servery starsi generace tam koupim po +- 8k/ks, koupim do nich 4 novy disky po rekneme 3k/ks. Takze sem na 30k za servery. Upsku koupim samo novou, protoze baterka by nestala o moc min. Dualni zdroje neresim, je to ptakovina, v tyhle cenovy relaci naprosta. U UPSky potrebuje jen to, aby umela komunikovat s vic strojema najednou = bud vic USB nebo sit, coz ale znamena zalohovat i switch. V kazdym pripade potrebuju minimalne line-interactive, offline upsky sou pomaly a specielne switch to prevazne neustoji.
Tzk sem nekde na 40-45k za dva servery, disky, switch a ups. K tomu opet nejakej rack.
Samo pokud nechci resit rack, koupim to vsechno v podobe tower. A switch holt hodim nekam aspon na polici.
Pricemz mi v tohle pripadne zbyl rozpocet jeste na dalsi krabici na zalohovani. Kterou v idealnim pripade vnutim majiteli domu.
A presne neco na tohle tema melo byt soucasti tvyho clanku = co potrebuju, nac to potrebuju a jak to teda poresim na urovni hw.
-
MasoxCZ (neregistrovaný)
Na tu UPSku se sítí nebo víc USB bych se vykašlal. Pokud to nebudeš chtít vypínat při výměně baterky, tak každému serveru klidně malou kancelářskou, ale vlastní, a pokud možno každou na jinou větev napájení. V tom momentě nemusíš pro tenhle účel řešit zálohování switche.
A souhlas, že vysvětlení cílů mohlo klidně tvořit celý první díl. -
A není náhodou kód "ef": Partition that contains an EFI file system? Nevím co znamená to 02, ale bootovací partition v ne-EFI režimu určí zavaďěč nahraný do mbr, v tomhle režimu bios partition tabulce ani rozumět nemá. Na linuxech se do mbr většinou dává grub, který pak umí načíst jádro i přímo z rootího ext4 (pokud není poslední blok přes limit daný biosem), a na partition typy úplně kašle. Na starých dosech/windowsech byl v mbr zavaděč, který se díval na flag "aktivní" v partition tabulce, a vlastně taky na typy kašlal. Typy pak potřeboval až ovladač disku, který podle toho například přiřazoval písmenka jednotek.
-
Tak se omlouvám, ef02 je terminologie jednoho programu, který nepoužívám:
https://superuser.com/questions/975436/how-to-set-a-partition-type-to-ef02-with-fdisk nicméně ten popis bootovacího procesu platí, pro legacy boot vůbec takový tag potřeba není. -
Mbr jako software/zavaděč máš. Ostatně proto se to jmenuje "Master BOOT record". To že tam není partition tabulka (tedy že to není dos-mbr) je věc druhá. To co chceš popsat je nejspíš GPT+GRUB. (Ten mbr zavaděč je v tomto případě od grubu, a ten používá partition s určitým GUIDem, gparted pak tento guid kóduje jako ef02.)
-
linuxmag (neregistrovaný)
Podle mě se autor vůbec neměl do hw pouštět. Je to obsáhlé téma a jeden seriál nemůže obsáhnout oboje. Měl se zabývat softwarem s tím, že hw existuje a na hw udělat zvlášť seriál v spolupráci s Fujitsu Siemens nebo IBM. Nechalo by se na tom udělat hodně peněz za reklamu a lidi by to zajímalo.
K čemu mi je vědět že hw má být spolehlivý a server má mít dva zdroje? K čemu třeba konkrétně ty dva zdroje? Problematika napájení je velmi složitá a jen do ní tuknout nemá cenu. Jsou tu různé UPS, přívody do serverovny, agregáty ... prostě věc o které se dá samostatně mluvit celý článek a zase, můžete pozvat firmu co o tom něco ví a představit dobrá řešení.
Tohle vypadá na kočkopsa bez jakékoliv vize. Zatím hodnotím tak 1 z 10.
-
j (neregistrovaný)
Mrtvej zdroj z cca 100ks serverovyho zeleza a dalsi infrastruktury sem za 10 let videl ... jedinej (cisco, chcip jeden ze dvou zdroju ve switchi a to cca 1/2 roku po dodani). Dva zdroje se nepouzivaj proto, ze by jeden mel chcipnout ale daleko castejs proto, aby bylo mozny vyuzit napajeni ze dvou vetvi (coz sou pochopitelne dalsi, a nikoli nepatrny, naklady).
A opet, ma to smysl jedine v pripade, ze si provozovatel nemuze dovolit vypadek toho konkretniho serveru, coz pokud si chce nekdo hrat na cmoud, by nemelo vadit naprosto vubec.
Realita dnesni doby je, ze se nahodi vmware, na 2-3ks serveru (kdyz v malym, do 3ks po dvou CPU staci levna foundation licence nebo jak se to ted jmenuje) a kdyz jeden z tech serveru umre ... no tak se nic nedeje, protoze se provoz prenese na zbyvajici. Tudiz neni vubec treba resit trebas to dualni napajeni. Pochopitelne soucasti je SAN .. jinak to nemuze fungovat (respektive oni soudruzi dodavaj i neco na tema virtualni san, s tim ze se to rozlozi po discich tech serveru, ale tomu bych teda nejen moc neveril ani co do funkcnosti ani co do vykonu, specielne bych tomu neveril to, ze se to umi koser vypnout).
-
Ondro (neregistrovaný)
K tomu virtualnemu SAN. Hovoria ti nieco skratky CEPH, DRBD, GLusterFS? Ta virtualna SAN je dnes uz realtivne bezna vec.
Ich vyhoda je v tom, ze si vies pomocou nich postavit ulozisko take ake potrebujes a nespornou vyhodou je aj ich otvorena licencia. Klasicke SAN je dost draha zalezitost ale hlavne malo flexibilna. Dnes su ine technologie a poziadavky. Dnes ti napriklad staci na menej objemne vykonne ulozisko jedno-dva SSD alebo ak nepotrebujes vykon a na urcitu kapacitu len par diskov(klasicke 10-12TB disky). Casto uz nepotrebujes objemne police a specializovany HW. Pri klasickom SAN by si to zbytocne preplatil.Nepoznam ako to robi vmware(nepouzivam) ale Proxmox + CEPH vyzera zaujimavo(prave s nim experimentujem).
-
Ondro (neregistrovaný)
To flexibilny som myslel to, ze niesom obmedzovany na SAN HW ale viem to postavit na takom HW na akom potrebujem a na takych technologiach ake potrebujem. Niesom obmedzovany tym, co ponuka vyrobca SAN. Viem si storage prisposobit. Pri SAN az take moznosti nemam.
Viem si napriklad postavit maly CEPH cluster z 3 entry level serverov a s cenou niekde uplne inde ako pri entry level SAN. Ten cluster viem nasledne skalovat tak ako potrebujem.
Tu SAN vrstvu mi robi SW, ktory nieje zadratovany s HW ako v pripade klasickeho SAN a to ho robi flexibilnejsim. -
j (neregistrovaný)
Krasna teorie ... sem zvedav jak budes majiteli firmy vysvetlovat, ze sice pouzivas reseni "zadarmo", ale ze to ma holt svy musky, treba ty, ze kdyz se slozi vic nez N nodu, tak se to cely rozpadne a je treba obnovit zalohy.
Mimochodem, zakladni pole bez disku (respektive s nejakejma 4-6 10k diskama) bez dalsich serepeticek a s NBD ... se da koupit (novy) od nejakych 200k. Samo, budes ho muset pripojit nejspis pres iscsi, protoze za FC by sis musel priplatit.
Takze tvoje uspora je spis velice virtualni. A bezpecnost provozu ... kolik nodu ti muze umrit pri 3?
-
Ondro (neregistrovaný)
Kade riesenie ma svoje musky. Tebe sa tiez moze zlozit pole alebo aj N poli naraz a tiez budes musiet obnovovat zo zalohy. Stale sa moze udiat pripad, ze ani N redundantna topologia ti nepomoze. Nikto ti neda 100% zaruku a 100% uptime.
Ja som nic nespominal o rieseni "zadarmo",len to, ze je to open source riesenie. Open source neznamena, ze to je zadarmo bez akejkolvek podpory. Najvecia vyhoda open source je v jeho otvorenosti, nie v tom, ze to mozes mat zadarmo.Bezpecnost tvojho riesenia je aka?
Kolko poli ti moze umriet pri tom tvojom jednom poli?K tej cene za zakladne pole. Uvediem ti trochu extremny priklad - mam tu HP microservere Gen8 kus za 130eur.
SAN je zaujimave az od urciteho nasadenia(cenovo aj funkcionalne). Virtualne SAN vies pouzit v sirsom meritku a pruznjesie. Mas oddeleny HW od SW, podla mna je to buducnost vo viacerych oblastiach. Napriklad mas tu uz SDN(software defined networking). Co na tom nechapes.
-
Doporucit mdraid level 1 muze akorat clovek, ktery to v zivote nepouzil v produkci. Je vcelku bezne, ze se na tom Linux vyseka, protoze mdraid mirror neumi redispatchnout IO, ktere uz je in flight. Proste se to na tom vyseka. O data neprijdete, ale masinu je potreba resetnout. Proto kdo tohle vi, pouziva (beze srandy) mdraid level 10 v degradovanem rezimu, far copies.
-
CHe (neregistrovaný)
Vieš to ev. doložiť nejakými nezávislými zdrojmi? Oba layouty (RAID 1 aj 10,f2) používame (aj v produkcii) roky, bez jediného zaznamenaného prípadu nejakých problémov, mašiny majú uptime rádovo v stovkách dní, reštarty akurát z dôvodov údržby.
RAID 10,f2 má oproti RAID 1 výhodu hlavne v lepšej priepustnosti pri sekvenčom čítaní (kde sa v ideálnom prípade blíži k RAID 0) aj mierne lepšom random prístupe na rotačných diskoch (v priemernom prípade kratšie seeky). Nevýhoda je na I/O náročnejší zápis.
-
Ray (neregistrovaný)
Taky se jen pripojim k tomu co bylo receno :) V konecnem dusledku ten HW je dulezitejsi nez SW, kde si sice usetrim/pridelam praci, ale pokud si neujasnim propusnost 'dat' tak to stejne dojede. A cim vic instanci mam a potrebuju k tomu automatizovat, tim dulezitejsi HW je... Ja jsem shodou okolnosti tohle resil nedavno a skoncil u reseni 2x 10G eth (switch+karty) a nad tim RAID s 25 diskama (1+0) a ciste linux reseni (iscsi/drbd). Bez tyhle vrstvy si nema smysl hrat na 'cloud'. On totiz clovek velice rychle zjisti fakt, ze nekolik SCSI disku proste neutahne vetsi IOPS zatez. A rozdil mezi 'local' a 'iscsi' diskem je dost diametralni (ve prospech toho iscsi). U ty 10G site dokonce i seek, nema nejake vetsi zpozdeni. A 'typicke' computing servery nemaji vic jak 2-6 disku. Krom toho v dnesni dobe lze takove reseni slozit relativne za par korun, velka datova centra prodavaji krasne stroje za par fifniku v porovnani s tim, kolik by stal novej. Samo tohle je na serii clanku, nez SW, kde je bambilion tutorialu 'jak to delat'. Ale o HW nic moc...
R.
-
j (neregistrovaný)
A to te jeste porad brzdi to iscsi ... protoze FC je jeste o rad jinde. Coz samo obnasi dalsi $$$ do dalsiho HW.
Pokud se ovsem spokojis se zelezem z frcu, tak 8G FC switch se da poridit uz kolem 10k. Zanovni pole pak poridis radove do 100k vcetne disku.
Mimochodem, to vubec neni spatnej koncept ani pro maly firmy, porad je to solidni HW byt bez supportu, ale pokud existuje osoba ktera vi vocogo, neni problem na to za par zbrdli koupit nahradni dily. Furt lepsi nez nejaky bastly. Pokud se to pak koupi tak aby vzdycky byla k dispozici nahrada, je to zpusob jak za smesny prachy poridit velmi slusny byt starsi zelezo s bezpecnosti provozu na urovni novyho.
-
Ray (neregistrovaný)
Problem je vzdycky v lidech. My tohle reseni poridili jeste o dost levneji, HP disc server s HW RAID vcetne bat modulu, diskama a kompletnim nahradnim sasim a HW radicem, 2x 10G sitovky, ... okolo 30K penez. 25x 300G disky (aktualne staci). Krat 2 na hot zalohu. Fyzicky to cte bez cache nad 1GB/sec, zapisuje lehce pod. Za tim je pak M1000e od dellu, kde 10G switch stoji par korun - myslim jako fabric switch modul. Cena klasickeho 10G switchu, mnozstvi kabelu, ... mne nakonec dokopala do toho blade reseni a zatim jsem nenasel jedinou zapornou vlasnost. Fakt je, ze na zacatku je 'hodne veci jinak'. 10G switch s tolika portama za ~4K penez je docela bezkonkurecni cena. I s ohledem na to co umi (M8024). Dtto s bladama, 10G sitovka stoji rozumne penize, nacpou se tam 3. Kazda ma 2 fyzicke porty. Kazdy par jde do samostatnyho modulu (tech je 6). Takze redundance se da resit jak na urovni karet, tak na urovni switchu. Prvni zapojeni takove kravy ale stoji za to :) Zvuk ne nepodobny startujicimu letadlu.
FC je o naprosto jinych penezich. Je jasny, ze overhead TCP a linux stacku bude hodne znat. Nicmene pri 8K framech to jede jako vino. Na druhou stranu, jakmile neni vyple tso, kernel pada na drzku (resp. ovladac sitovky, kernel to prezije, ale nezvladne ani jeho restart -> reboot). Tj. ne kazdej overhead jde vypnout, ikdyz to HW umi. V konecnem dusledku ma tso problem s VLANama. Kdyz jsem se hrabal ve zdrojacich na ty sitovky (proc to pada), zvedal se mi zaludek, jak je to napsany, tak se ani nevidim. Na druhou stranu - v konecnem dusledku to jede a za levno.
R.
-
jeste se u podobnejch supermiker hodi nastavit serial konzoli do cmd line kernelu:
console=ttyS1,115200
clovek pak muze pouzit ipmitool -I lanplus -H host -U user -P heslo sol activate
k pripojeni na seriovou konzoli pres IPMI lan, coz se hodi kdyz je neco rozbity..
Vyrazne lepsi nez defaultni java konzole v ipmi web interface..
