Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - František Ryšánek

Stran: 1 ... 73 74 [75] 76 77 ... 84
1111
Sítě / Re:Print server - Raspberry Pi nebo router?
« kdy: 09. 07. 2018, 09:07:52 »
Joahaaa... GDI. Takže štěstí v neštěstí, že existuje jakýsi alpha driver pro dotyčný proprietární protokol (který někdo hacknul odposlechem bez dokumentace). Stáhnout z GITu a zkompilovat pro malinu. A závislost je každopádně CUPS. Hm.

1113
Tady se přiznám že z toho $HOME/.xsession nejsem zrovna chytrý, protože já v Home nemám žádnou složku .xsession

.xsession (nebo postaru .xinitrc, patrně deprecated) je skript, resp. možná by tak šel pojmenovat i ELFový binár.

Tuším jsem si všiml, že mi tam nechodí správně hranatá závorková konvence if []; then, ale příkaz "test" ano = patrně to bylo tím, že jsem neměl na prvním řádku zadaný #!/bin/sh   (= konkrétní interpreter).

Zadání "minimalistické X jenom jako podvozek pod browser" je zřejmě ultra-klasické :-)  Chrome / chromium mají parametr --kiosk, a jak jim tak firefoxu lze alternativně poslat F11 přes "xdotool". Klasický obsah .xsession v tom případě je něco jako

xset -dpms
xset s off
xset s noblank
matchbox-window-manager &

while true; do
    chromium-browser --kiosk http://moje.url   
done

1114
Věci, které se mají automaticky startovat při přihlášení do X, patří IMO do $HOME/.xsession .
Zrovna si s tím hraju na kombinaci Debian 9, Lightdm a Matchbox (právě Matchbox je první věc, která startuje z .xsession).

Rotovat kernelový framebuffer? Byl jsem skeptický, ale ono to možná funguje. Hmm... koukám Zetkový ATOM, ovšem s Intelskou grafikou? Možná dost klika že to není PowerVR :-)

1115
Sítě / Re:Print servr - raspi nebo routr?
« kdy: 07. 07. 2018, 09:29:49 »
Spíš tu malinu. Prostě přidej CUPS a hotovo.

Za mě spíš lpd. Přesněji dneska možná spíš lprng než legacy lpr/lpd (protože dostupnost v dnešních distrech).

CUPS jsem dlouho považoval za "cestu kupředu", protože jsem si to někde přečetl... napsal jsem si skript na automatické odpauznutí náhodně pauznutých front apod. Až po X-tém dist-upgrade v jedné verzi debianu (6? nebo 8?) jsem zjistil, že mi CUPS zahazuje joby, protože "job-name : bad UTF-8 sequence". Což byly z Windows prakticky všecky. Pak jsem si v manpage všiml, že ten software je od nakousnutého ovoce, a pohár mé trpělivosti přetekl (eufemismus).

Takže lprng. Balíček na debianu má v default runtime konfiguraci jednu-dvě pastičky... Doporučuji následující konfiguraci:

/etc/lprng/lpd.conf:

lpd_listen_port=515

V /etc/lprng/lpd.perms je potřeba zakomentovat:
#REJECT NOT SERVER
(by default je tato opšna aktivní = vidíte lpd naslouchat na 515 ale nebere joby z jiných strojů :-)

V printcapu upozorňuji na velmi vhodnou opšnu   :done_jobs=0:  tzn. celý /etc/printcap může vypadat třeba takto:

moje_jmeno_fronty:lp=/dev/usb/lp0:mx#0:sh:done_jobs=0:

Užitečné příkazy:
lpstat all
lpc status all

Log hledejte ve /var/spool/lpd/moje_jmeno_fronty/*
= v adresáři pohromadě s tiskovými joby.
Aspoň tak to vypadá na Debianu, netuším jestli to Raspbian nemá jinak.

Pokud se má tisknout taky přes Sambu, tak do /etc/smb.conf  zadat

printcap name = /etc/printcap
load printers = yes
printing = lprng

1116
Hardware / Re:Mohu sekundární GPU vypnout napájení?
« kdy: 03. 07. 2018, 06:49:18 »
Moc nevěřím, že je běžné, aby šel VRM pro GPU vypnout fidláním s power states v PCI zařízení. Čekal bych že se tím třeba odstaví/deaktivují nějaké interní bloky, hluboce se uspí, ale šváb zůstane pod napětím.

Jinak doporučuji dotaz do Googlu "lspci setpci power state" a přečíst prvních pár odpovědí. Nakonec tam tuším není konkrétní návrh s použitím setpci, ale i tak je to zajímavé čtení.

Pokud byste dokázal té kartě třeba nějakým FETem vypnout vnější přívod 12V, tak by to mohlo mít nějaký vliv. Pokud by se nesnažila přežít ze 12V z PCI slotu (v tom případě by patrně lehnul celý systém, protože by to motherboard neutáhl.)

Samotná PCI sběrnice by měla podporovat hot swap. Uhh... a nejsem si jist, jestli prostě vypnutím napájení dosáhnete stavu "proběhlo odpojení od sběrnice". V PCI-e slotu jsou piny PRSNT#1 a PRSNT#2 (PRSNT#2 je několik, podle šířky sběrnice) - pokud je karta na plošáku navzájem propojí, tak při zasunutí karty dojde k "detekci zasunutí" motherboardem (upstream bridgem). Nejsem si jist, že je ten popis správný - protože se tam taky píše, že PRSNT#1 je na motherboardu uzemněný. Možná jsou plošky na kartě ještě navíc kratší. Jestli jde toto nějak nafintit u onboard naletovaného PCI-e zařízení (uzemněním PRSNT#2), na to není obecná odpověď :-) Pravděpodobně nikoli. Viz též.

1117
Odkladiště / Re:Výběr židle nebo křesla k počítači
« kdy: 29. 06. 2018, 18:02:52 »
Mám v práci židli co stála před časem v Kika asi 4kKč. Napohled hezká, na posezení pohodlná, vysoké opěradlo, kolem dokola zvenčí síťovina, jenom po stranách "závodní boční opěrky" (proti sklouzávání v zatáčkách) jsou z loupavé čínské koženky. Pocaď dobrý, až na tu koženku ten vršek není konstrukčně úplně špatnej.

Ale jedno zásadní kurvítko, společné se všemi židlemi ještě levnějšími: ta spodní pětinohá hvězdice, co má na paprscích kolečka, tak je plastová. A průser je s tím ten, že je plastové i "kónické futro", ve kterém sedí kovová konická "teleskopická vzpěra" uprostřed. Průser je konkrétně v tom, že ta kónická díra v plastové hvězdici časem povolí, roztáhne se, vzpěra zajíždí hlouběji a hlouběji až... to vyvrcholí tím, že ostrými hranami na spodním konci vzpěry drhnete o koberec. Docela mi trvalo, než jsem zjistil, že to nedrhnou zadřená kolečka, ale že se jedná o orbu koberce tou kónickou trubkou. V tomhle stavu je i trochu problém tu vzpěru vytlouct z hvězdice zpátky ven. No a další kurvítko je, že ta vzpěra je nerozebiratelně smontovaná (posvařovaná) s pár díly železného třmenu, který drží pohromadě vzpěru k sedačce. Jiné židle mají tento pletenec rozebiratelný.

BTW ta kónická vzpěra "kupodivu" není natlakovaná, je to jenom kovový futrál, dá se do něj navrtat pár děr a vrazit do nich šroubky, aby vpěra nezajížděla - ale je to ošklivý hack.

Bezkurvítková židle s pohodlným sedákem myslím nebude stát míň než cca 5 kKč / 200 EURO.

Další věc co nesnáším jsou oblé opěrky na ruce - když sedím u stolu, tak ten oblouk "uhne" přesně v místě, kde bych si potřeboval opírat lokty. Opěrky o které si ruce neopřete. Opět atribut levných židlí. (Ta moje má opěrky rozumné.)

Synek má nějakou židli z Ikey... je to asi 2-3 roky co byla v akci. Má napohled bytelný železný rám potažený jakýmsi tuhým syntetickým hadrem, a vespod železnou hvězdici. Vysoké opěradlo. Kolečka mají zřejmě naschvál dost odpor. (Ještě že tak. Na židli se nejezdí. To smím jenom já.)

1118
Server / Re:Linuxový cluster pro výpočty
« kdy: 28. 06. 2018, 14:31:36 »
Ono pokud to jede nad intenzivně sdílenými daty v RAMce, tak může být i rozdíl mezi 1x 32core vs. 2x16 vs. 4x8 core (jedna/dvě/čtyři patice) - za předpokladu, že propoj mezi paticemi (HT/QPI) je pomalejší, než interní sběrnice v rámci patice. Každopádně snaha emulovat SMP (NUMA) nad Ethernetem je už na první pohled špatný nápad :-)

Takhle kdyby ten software uměl řešit "lokalitu" alokované RAM a CPU jádra. Tzn. kdyby si byl vědom NUMA struktury stroje. Resp. aspoň kdyby úloha byla s ohledem na nestejné latence v NUMA topologii nějak optimalizovatelná. Linux má o těchto věcech interně přehled a údajně může proces "svoje" alokované "virtuální" stránky přestěhovat na konkrétní NUMA uzel (resp. má právo o to požádat.) Jenom mi ohledně linuxu/libnuma není jasné, jestli se baví jenom o procesu (pid) nebo v jemnějším smyslu slova o vlákně. Našel jsem třeba zmínky, že Linux se snaží vlákna v rozvlákněném procesu spouštět na jádrech v rámci jediné "patice" (numa uzlu) - ale "co když chci aby vlákna běžela napříč celým NUMA strojem a měla přehled o svých alokacích paměti" ? To je podle mého téma na další googlení, průzkum bojem a debatu v LKML. Náznak jsem zažil kdysi když jsem zjišťoval, jak si nechat probudit kernelovým timerem konkrétní vlákno, tzn. nikoli celý proces. (Pozn.: syscall gettid() je tuším už normálně k dispozici i skrz glibc.) Všimněte si třeba nejednoznačného užívání termínů proces, vlákno a hlavně "task" - člověk musí pořád zkoumat, jestli se bavíme o user space, kernelu a na jaké úrovni abstrakce, jak to mapuje NPTL apod. Konkrétně: výše odkázaná manpage knihovny libnuma používá "task" ve smyslu rozvlákněný proces, kdežto v kernelu "struct task_struct" odpovídá jednotlivému user-space vláknu :-( Přesto se domnívám, že jestli je někde šance, tohle všechno rozplést a "nalinkovat po svém", tak je to v Linuxu. Jindy taktéž velice pokrokové FreeBSD zde patrně teprve dohání náskok.

S uvedenou problematikou volně souvisí další finta: snažit se, aby algoritmus pokud možno "běžel v CPU cache" - v rámci jednoho vlákna na konkrétním CPU jádře (popř. v rámci NUMA uzlu). Což je ovšem těžko splnitelné, pokud jsou data křížem krážem provázána odkazy (pointery) = úlohy typu "procházení rozsáhlého grafu" se takto optimalizovat z principu nedají :-( a budou vyžírat vždycky ty nejhorší latence.

Závěrem odkaz na jedno hezké PDF o těchto věcech...

1119
Server / Re:Současný hardware pro 1PB storage
« kdy: 27. 06. 2018, 15:01:14 »
Hm tyjo. Na DIITu zrovna zajímavá zprávička a v diskusi to někdo ještě opepřil. Pomalu začínám chápat, kdo se zbavuje 16GB DIMMů a 6Gbit/16port SAS HBA.

1120
Server / Re:Současný hardware pro 1PB storage
« kdy: 27. 06. 2018, 13:09:15 »
1TB 64x16GB DDR3 vyjde kolem 90 tis.

:-) 90 Kč / GB? Konečně chápu a souhlasím. Nové DDR4 stojí asi 350 Kč/GB.

Pokud ta věc bude bootovat z nějakého direct-attached mirroru (klidně interního) tak není ani potřeba, aby prašivý značkový BIOS "viděl" všechny HBA a disky. Možná naopak lepší kdyby neviděl :-D Ono by možná šlo zakázat v BIOSu startování přídavných option ROM ze zásuvných PCI karet.  Hlavně aby byly HBA dostupné na PCI sběrnici. Linux nebo BSD už si je přebere. Moderní HBA čipy IMO nepotřebujou, aby si na ně při startu sáhla BIOSová option ROMka.

1121
Server / Re:Současný hardware pro 1PB storage
« kdy: 26. 06. 2018, 15:17:19 »
Pozor na to řešení s HBA co mají velký počet SAS portů - typicky mají tyhle HBA stejně na čipu jen 4 SAS linky, takže velký počet portů je pak spíš pro pocit

Budu-li mluvit konkrétně:
Areca ARC-1320-8x (Marvell): 8 linek pro disky (2x x4 multilane)
Areca ARC-1320ix-16 (Marvell): onboard expandér
LSI SAS 9300-16e (2 ks LSI 3008 "Fury" + PCI-e bridge): PCI-e 3.0 x8, čistých 16 linek pro disky, <2 M IOps, full height, 27W
LSI SAS 9302-16e (2 ks LSI 3008 "Fury" + PCI-e bridge): PCI-e 3.0 x16, čistých 16 linek pro disky, 2.8 M IOps, full height, 29W
LSI SAS 9305-16e (1 ks LSI 3216 "Cutlass"): PCI-e 3.0 x8, čistých 16 linek pro disky, 1.5 M IOps, low profile, 13 W
LSI SAS 9400-16e (1 ks LSI 3416 "Crusader"): PCI-e 3.1 x8, čistých 16 linek pro disky, ? IOps ?, low profile?, 11W
LSI SAS 9405-16e (1 ks LSI 3616 "Mercator"): PCI-e 3.1 x16, čistých 16 linek pro disky, ? IOps ?, low profile?, 14W

Crusader a Mercator zatím zřejmě nejsou ve FreeBSD, ve vanilkovém upstream Linuxu už ano. Ve widlowsím driveru je vidět pár dalších (novějších) codenames.

1122
Server / Re:Současný hardware pro 1PB storage
« kdy: 26. 06. 2018, 14:09:07 »
Dekuji za smysluplnou reakci. Resim celkovou raw kapacitu 1PB, jak si to rozdelim pak je na me a mych pozadavcich ktere jsou mimo tuhle diskusi. Do racku by se AFAIK melo vejit 1PB bez problemu, treba backblaze ma ve 4U 60 disku, to co mam ted je takove na kolene poskladane reseni, ale kapacitne to nezabira vice nez 6U se 4tb disky, tudiz by to melo jit. Co se tyce ram a desek - mam nejakou predstavu, 1TB chci kvuli dedup a dalsim vecem, myslim ze 64gb moduly se daji sehnat, zalezi od konkretniho vyrobce. Pokud mate zkusenosti s konkretnimi deskami budu rad za info.

Popravdě v levném serverovém HW mám spíš dávné vzpomínky než nějaký aktuální přehled. Dustin vypadá, že je víc v obraze a má přehled o značkovém HW.

Obecně každému doporučuji, mít disky v šuplíkách jednotlivě přístupné zepředu (aby šly jednotlivě vyměňovat) a identifikovatelné, proto enclosure management. V momentě, kdy RAID vykopne disk, tak člověk brečí vděkem za failure LEDku - ale zákazníkům se to předem občas těžko vysvětluje :-) Na in-band SES se dá sáhnout pomocí sesutil (používá driver ses).

Z tohoto důvodu, a taky kvůli chlazení, váze a hloubce (klidně přes metr) se mi nelíbí kastle, kde se do 4U nacpe 60-100 disků nastojato.

Pokud to nebude někde v útulné "teplé a studené uličce" tak bacha ať má stojan po celé ploše děrovaná vrata vpředu i vzadu (a osobně bych se snažil omezit i falešný vzduch uvnitř stojanu zezadu dopředu). Pokud máte ten luxus vybrat si stojan, tak 80cm šířka dává prostor po stranách pro umístění distribuce napájení a tahání kabeláže (ale bacha na ten falešnej vzduch).

Obecně u nového hardwaru je volba spíš věcí osobního vkusu a subjektivní důvěry v konkrétní značku - protože u toho prostě nejsou zkušenosti s konkrétním modelem motherboardu, zdrojů apod. Statistika se vytvoří až po létech běhu, a tou dobou je na trhu HW zas o dvě generace novější.

Jak jsem psal, nemám zkušenosti s aktuálním HW tohoto kalibru, ale dlouhodobě dost věřím značce Areca, a třeba Supermicro vypadá, že nakonec taky docela funguje (poslední průser si vybavuju ještě v dobách končící Capacitor Plague).

Zjistil jsem, že dokonce Areca má v nabídce JBODy na 12 disků/2U nebo 24disků/4U. Uvnitř je expandér (nebo dva pro redundanci) a zezadu kouká jako uplink 12Gb SAS (x4 multilane). Tzn. není to direct attach, ale ten multilane SAS nebude úplně pomalý. Bude pomalejší než Dustinův nekompromisní "přímý propoj na každý jednotlivý disk". Případně by se dalo přemejšlet, jestli vzít šasi po 12 nebo 24 discích (šasi po 12 discích dá teoreticky větší průchodnost, ale vyjde dráž.)

Popravdě se mi Arečí "PS/2" zdroje s 80mm ventilátorem líbí víc, než Supermicrovic napájecí zdroje, hubené a dlouhé s 40mm větráky - ale je to jenom bezelstný pohled zvenčí, ono u zdrojů hodně záleží na obvodovém řešení, součástkách, detailech zapojení/chlazení, jmenovitém dimenzování atd.

Areca má taky nějaké "svoje" SAS HBA, tuším končí na 6 Gbps (opět - vcelku proč ne) ale určitě budou fungovat i HBA od LSI apod. Arečí vlastní ARC-1320 má čipy Marvell, expandéry jsou pravděpodobně od LSI.

Bejvaly doby, kdy SASové čipy vyrábělo AVAGO a LSI a navzájem si konkurovali. Dneska jsou zřejmě oba pod jednou střechou (LSI bylo sežráno Avagem a Avago se zanedlouho přejmenovalo na Broadcom). Zdá se, že aktuální 93xx/94xx jsou nadále "3rd-gen MPT SAS" (tzn. dědictví LSI Fusion MPT) ale skoro mám pocit, podle IDček z Windows driverů, že 94xx ještě možná nejsou komplet v Linuxové vanilce (driver mpt3sas) a prakticky shodná je koukám situace ve FreeBSD (driver mrsas). Čili situace je stejná jako před 15-20 lety: aktuálně prodávaný nejnovější HBA hardware ještě nemá drivery v distribucích :-) Opět má pravdu Dustin: držet se vyzkoušených modelů. (A to se snažím nevzpomínat na dávné quirky třeba u Adaptecu.)

Mě osobně se líbí šasi od Arecy. Jsou hluboká jenom asi 50 cm, všechno přístupné pro servis zvenčí, celá kisna se připojí k HBA jediným fousem. Do 16 U se vejde 96 disků, k serveru se to připojí 4 nebo 8 fousy. Na to teoreticky stačí 1-2 HBA karty (při dvojitě redundantním připojení 2-4).

Dustinova koncepce "direct attach" má teoreticky tu výhodu, že každý disk má svůj vlastní kanál na HBA, tzn. nevstupuje do toho expandér. (V dávných dobách se tradovalo, že za určitých okolností expandér jede proti HBA jediným lanem, ale už nevím, jestli to bylo v případě kdy se skrz expandér sahalo na SATA disk, nebo jediné vlákno, nebo v čem byl přesně problém.) Direct attach má maximální průchodnost. Kromě toho je expandér další potenciální "point of failure".
Odhadem může být problém, dosáhnout při "direct attach" na failure LEDky, protože jednotlivě připojené disky nemají in-band SES (expandér pravděpodobně ano). Leda by se z HBA do backplanu dalo dotáhnout ještě taky SGPIO. Matně si vybavuju, že TQ šáska SuperMicro SGPIO podporují. Ale nenašel jsem zmínky, že by SGPIO podporovaly mpt3sas HBA's a že by se na to dalo nějak sáhnout. Čili SGPIO asi leda v kombinaci s HW RAIDem :-(

Tady jsem našel debatu se zmínkou o ZFS nad multipath SASem proti diskům: Debatěj tam taky o zapřažení flash SSD a že to jde připojit na multipath pomocí "redukce do šuplíku". Konkrétně od Supermicra.

Pokud se týče boardů, koukal jsem na tyhle s DDR4: 1 2 3 4 . Plus spousta příbuzných. Koukám všechny berou DDR4 LR paměti. Uvedené desky jsou všecky s LGA2011, ale tamtéž jsou k vidění i sestřičky s LGA3647. Poslední PCI-e slot bývá jenom x4, ale není to železné pravidlo a i kdyby, tak PCIe 2.0 nebo 3.0 x4 má průchodnosti pořád relativně dost.

Pokud se týče RAM, namátkou jsem nahlédl zde: DDR4 ECC REG a DDR4 LR. (Nemám s tou firmou nic společného.) Bacha ECC REG a LR zřejmě nejsou v konkrétním boardu záměnné. Jasně jsou to koncovky, dál to komentovat nebudu. Pro přehled to myslím stačí velmi dobře. Pokud správně rozumím, "škáluje" u DDR4 cena lineárně mnohem dál než u DDR3. Nebo se u DDR3 bavíme o 8GB modulech z druhé ruky, které adminům "zbývají" při upgradech a proto jsou levné? Tolik k nápadu repasovat starší hardware a cpát do něj terabajt DDR3.

Pokud se týče disků: podle popisu připadají v úvahu např. Seagate Exos x12 (až 12 TB), Exos x10 (až 10 TB), Exos 7E8 (až 8 TB). x10 a x12 jsou héliové, 7e8 je zřejmě plněný vzduchem. Všechny tři rodiny obsahují SATA i SAS modely, na výběr je kupodivu dodnes velikost sektoru 512B nebo 4 kB. A všechny modely se SAS rozhraním mají dvojitý uplink - pokud by byl zájem o multipath zapojení disků.

Pokud byste se zajímal o Arecu/Supermicro, tak Starline, Abacus i Compos tenhle hardware staví/prodávají dlouhá léta (a snad se i trochu starají o zákazníky v DC), budou vědět co a jak, přitom jsou to pořád v zásadě "železářství" tzn. doufám žádní nafukovací hochštapleři.

1123
Server / Re:Současný hardware pro 1PB storage
« kdy: 25. 06. 2018, 20:23:13 »
A DDR4 ECC REG škáluje přímou úměrou až do 64 GB na DIMM modul, ten stojí něco přes 20kKč vč.DPH. Ať už se jedná o ECC REG nebo ECC LR. Tzn. s deskou co má 16 SODIMM slotů by se na ten 1 TB dalo dostat. Procesorově k tomu bude potřeba 2x Xeon E5.

1124
Server / Re:Současný hardware pro 1PB storage
« kdy: 25. 06. 2018, 20:01:49 »
Koukám že na velké šuple pro disky není třeba chodit daleko...

1125
Server / Re:Současný hardware pro 1PB storage
« kdy: 25. 06. 2018, 14:23:01 »
Zkusím se trochu zasnít:

Jestli správně počítám, 42 U = 14 šasi po 3U, do 3U se vejde standardně 16 disků normálně v šuplíku na čelní stěně. To je 224 disků. Takže pokud je požadavek na 1 PB, vycházelo by to na 4.5 PB na disk v RAIDu 0. Tzn. pokud by to byl RAID 10 nebo nějaká podobná míra redundance (+100%), vychází to na cca 9-10 TB disky. Případně jsou k vidění šasi pro 24x 3.5" disků v 4U. To by se do stojanu vešlo 240 disků + by zbyly 2U na nějaký ten server. Asi trochu nesmysl to takhle našlapat, ale takové jsou teoretické počty. A jsou i nějaká šasi, kde se disky zřejmě strkají *dovnitř* = nejsou jednotlivě dostupné pro hot-swap z čelní strany. Což pak podle mého znamená, že je třeba celé šasi odstavit kvůli výměně jednoho disku...

Od koho šasi? No pokud ne HP / IBM / EMC=DELL tak třeba Infortrend nebo tihle němci - vedle Infortrendu vedou i nějaké "svoje" značky s Arecou apod. uvnitř. Svého času tuším prodávali i Fujitsu nebo NEC, už nevím. Jsou na trhu už hrozně dlouho a výrobci přicházejí a odcházejí. Jo a abych nezapomněl, něco by se dalo vybrat taky u Supermicra (u nás Abacus / Compos).

Chápu správně, že to bude jediný veliký JBOD, nad kterým poběží ZFS?

Čím to připojit k serveru: no teoreticky asi přes SAS. Nakolik to bude provozně spolehlivé, bůh suď - celý ten strom JBODů bude samý single point of failure. Taky bacha jestli ty JBODy budou umět "větvit" / daisy-chainovat. Už si nepamatuju, jestli 240 disků nedojede na počet SCSI IDček na jedné sběrnici...

SAS dává teoreticky možnost, vydrátovat šasi "dvojmo" kvůli redundanci. A teoreticky jsou i nějaké disky, co mají dvojitý SAS uplink - jenom si nejsem jistej, nakolik je dvojitý SAS uplink na discích běžná věc. A jestli třeba takové ty "entry-level SAS Barracudy" nejsou naschvál single. A taky by to znamenalo, pořešit v serveru multipath. Další zajímavé téma je enclosure management a hot-swap jednotlivých disků. Matně si vybavuju z doby před 10-15 lety, že FreeBSD mělo už tehdy jakousi podporu pro enclosure manager šváby a normy...

Hrozně dlouho jsem neslyšel o discích s nativním FC, takže pokud by to mělo mít vnější interconnect přes FC, tak leda by to šasi obsahovalo bridge. Ještě mě napadá, jakpak je to s možností bridgovat SAS na InfiniBand.

A další možnost, jako alternativa ke kaskádě SAS expandérů nebo IB fabricu: vyvést ze serveru co nejtlustší PCI-e do externího expanzního šasi (nebo do dvou), do těch šasi naložit větší počet SAS HBA. A každý HBA kanál by pak měl na sobě třeba jediný expandér v jediném diskovém šasi. Tzn. žádný vícepatrový daisy-stromeček ze SAS expandérů. Ale zase by narostl potřebný prostor pro servery a expanzní PCI-e boxy. Hm popravdě kdyby ty JBODy měly každý jediný uplink, tak by se 5-7 SAS HBA (každý 2x multilane external) vešly teoreticky do jednoho 3U šasi. Které by navíc eventuelně mohlo mít svých 16 disků. Jde jenom o to najít serverový board se 7x PCI-e.

Asi netřeba zdůrazňovat, že celá tahle DAS pornografie je dost old-school. Větší kapacity se dneska běžně řeší spíš "cloudově a distribuovaně" nad Ethernetem nebo TCP/IP apod., tzn. samotné disky a HBA jsou nuda, zajímavé je SW uspořádání nad tím.

No a stojan naložený cca půl tunou šásek a disků, s běžnou spotřebou (topným výkonem) okolo 3 kW, při rozběhu klidně k 10 kW (ledaže staggered spin-up)... dneska už asi jsou hostingy, které tohle vezmou. :-) Předpokládám že nehrozí začátečnické chyby typu "stojan nedostatečně hluboký" nebo "teplo se o sebe postará samo" :-)

Jak už tady říkali ostatní, on to rád někdo dodá celé na klíč. A asi je i správně, aby si za to celé ručil. Ale taky je fakt, že není špatné, udělat si předem jasno, jestli třeba řadič externího RAIDu v rámci "fair balancingu" neomezí datový tok jednoho "vlákna" na 100 MBps zatímco Vy potřebujete na chroustání 4k videa 10x tolik apod :-) Nepříjemná nedorozumnění se občas stávají...

BTW terabajt RAMky? Jo aha, ono je to "vcelku normální"... dá se to nacpat do desky s pouhými 8 DIMM sloty, pokud seženete DIMMy o kapacitě 128 GB (v provedení DDR4 se údajně nějaké dělají). Nejnovější dvoupaticové desky s LGA2011 tohle umí vcelku běžně, našel jsem i nějaké jednopaticové... Nebo jestli jsou DIMMy 32GB pořád ještě citelně levnější, tak vzít desku se 16 DIMM sloty (2x Xeon E5) a spokojit se s 512 GB RAM.

Stran: 1 ... 73 74 [75] 76 77 ... 84