epitsunk storaget :)

Merevlemezek, vezérlők

a vege az lett, hogy ugy dontottunk epitunk egy kicsit, teszt celra, ha bevalik, akkor pedig johet a nagy.

a vegleges parameterek (most rendeltem meg):
- Supermicro X9SCM-F
- E3-1230v2
- Fractal Design Arc Mini haz
- SAS HBAkent Intel SASUC8I (osszesen 8xSAS), nem raid modban
- 5x Seagate 1TB
- 2x Intel 520 256GB
- 3x Intel 330 60GB (2xRAID1 rendszer, 1x L2ARC)
- Chelsio T420-CR, igy a halozat fele 2x10Gbit lesz

amint megjon rakok fel kepeket meg benchmarkolok, foleg, hogy szeretnenk dedupot is, ami izgalmas kerdes (sok az ~egyforma VM)

benchmark tippek johetnek.

  • 43726 megtekintés

( secretx v | 2013. 03. 07., cs – 21:32 )

Mi is eleg sokat nezegettuk a wd red-et, de ez a butitott intellipoweres rpm nem meggyozo szamomra.
Inkabb a black akkor mar szerintem.
500Gb-os wd black egyik szeriaja 150MB/s transfer ratet iger, a redek 110-120, green meg lassabb...
Most testingbe vettunk par hasznalt 73GB-os sas-t, ezek raid6-ban (hp p400 kártya), 185MB/s-t hoznak random write-ban, ami nem rossz szerintem.
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( szollosiimre | 2013. 03. 07., cs – 22:38 )

Várom a fejleményeket. :)
Szintén agyalok storage-ban de kicsit kisebb méretben.

( elod v | 2013. 03. 07., cs – 22:56 )

ECC?

A WD Reddel semmi gond nincs, ez is hullhat mint bármi más, de legalább 3 év a standard garancia. Nyilván, ha agyon akarod hajtani, kell a sebesség és van rá keret, akkor mást veszel. Ja, az 1TB korántsem a jelenlegi optimális árfekvés.

( psc | 2013. 03. 07., cs – 23:06 )

nekem van az itthoni mediaserverembe 4 db wd red 3TB disk (raidz), egyenkent ezt tudjak: 


[root@micromaster ~]# dd if=/dev/gpt/disk0 of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 7.435749 secs (141018207 bytes/sec)

ez igy jol is nez ki, viszont overall performanceval nem vagyok elegedett. tehat pl. a lemeztomb egyik mappajabol a masikba masolas 30-40 MB/sec mindossze, illetve ha tobb kis dolog van, pl. 2-3 fullhd vagy bluray iso lejatszas (egyenkent olvasnak tobb MB/sec-kel), akkor mar nagyon belassul az egesz, s ez nem jelentos terheles.
itthonra jo, egyeb felhasznalasra nem javaslom.

aztan az sw raid eseteben gondolom zfs -re gondolsz :) , szvsz a desktop board i5-tel nem lesz jo ennyi lemezhez, tul keves lesz. ahogy a 8G RAM-ot is jocskan feljebb tolnam, nem olyan draga a memoria.
vagy veszel bele valami pciex8-as sata/sas "buta" vezerlot is, ami a lemezeket kiszolgalja, akkor a desktop board akar jo is lehet, viszont a fene tudja, hogy egy i5-os proci mennyire viszi el ennyi lemeznek az IO-jat. ki kene probalni, hogy mennyire reszponziv a rendszer. az utobbi idoben nekem a desktop cuccokkal mindig szivasom volt, viszont rendes entry-level (tehat viszonylag olcso) serve stuffokkal, xeon procikkal, hozzajuk valo alaplapokkal sokkal jobban megvoltam/vagyok. szeptikus vagyok a desktop board+i5 komboval kapcsolatban, plane 12+ lemez eseteben.

hwraid eseteben: azon a velemenyen vagyok, hogy ha van zfs-re lehetoseg, akkor inkabb az, mint hw raid, minden egyed esetben hw raid. LSI es adaptec kartyakkal volt dolgom, igaz csak SAS-sal, nem tudom, azok a SATA lemezeket mennyire kezelik. 3ware volt meg regen "meno"

A kedvemért nyomnál egy

iozone -b results.xls -r 4m -s 4g -t 6 -i 0 -i 1 -i 2

kiváncsiságból?

Köszi

itt a raid6 =

[root@xxx ~]# dd if=/mnt/test0 of=/dev/null bs=1M count=1000
1000+0 beolvasott rekord
1000+0 kiĂ­rt rekord
1048576000 bĂĄjt (1,0 GB) mĂĄsolva, 2,84659 mp, 368 MB/mp

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

microserver szinten?

raidz, tehat tekinthetjuk raid5 -nek: 


[root@micromaster ~]# dd if=/data/temp/t.img of=/dev/null bs=1M
3963+0 records in
3963+0 records out
4155506688 bytes transferred in 14.299998 secs (290594913 bytes/sec)

iozone-t elinditottam egy screen-ben, majd reggel megnezem az eredmenyet, ha el nem felejtem.
viszont kozben a zpool iostat 1 ezt mutatja, hat nem lesz tul jo eredmeny, azt boritekolom... 


[root@micromaster ~]# zpool iostat 1
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
storage     4.72T  6.15T     97     46  11.2M  1.67M
storage     4.72T  6.15T      0    550      0  2.17M
storage     4.72T  6.15T      0    616      0  2.43M
storage     4.72T  6.15T      0    550      0  2.17M
storage     4.72T  6.15T      0    275      0  1.08M
storage     4.72T  6.15T      0    963      0  3.79M
storage     4.72T  6.15T      0    543      0  2.14M
storage     4.72T  6.15T      0     76      0   305K
storage     4.72T  6.15T      0    880      0  3.46M
storage     4.72T  6.15T      0    811  3.16K  3.20M
storage     4.72T  6.15T      1    832  37.5K  3.96M
storage     4.72T  6.15T      0    248  1.53K  1002K
storage     4.72T  6.15T      1  1.10K  4.37K  5.02M
storage     4.72T  6.15T      0    560  2.46K  2.20M
storage     4.72T  6.15T      0     39      0   167K
storage     4.72T  6.15T      0   1003      0  3.94M
storage     4.72T  6.15T      0    224      0   903K
storage     4.72T  6.15T      0    726      0  3.28M
storage     4.72T  6.15T      0  1.15K      0  4.62M

nalad milyen rendszer, milyen gep, milyen lemez?

UPDATE: ezt az iozone-t kilottem, mert anyira megfogja a gepet, hogy hasznalhatatlan, nem tudok elinditani egy filmet rola, mert be van allva.
ssh-n is alig birtam bejelentkezni, 1 billentyulenyomast 10 sec alatt echo -z vissza.
load:
[root@micromaster ~]# uptime
12:44AM up 4 days, 10:54, 3 users, load averages: 17.70, 14.30, 8.91

microservert tobbet nem.

Ez egy játszós vas, Q8300 proci, 16g ram, sima asus alaplap, p400 512MB raid kártya, 6db használt 15k rpm 73GB sas diszk.

Rendes Centos 6.3 kernellel, tuned enterprise-storage opcióval ennyit tud:

"Throughput report Y-axis is type of test X-axis is number of processes"
"Record size = 4096 Kbytes "
"Output is in Kbytes/sec"

" Initial write " 275353.76

" Rewrite " 291034.00

" Read " 252083.12

" Re-read " 250815.98

" Random read " 299946.39

" Random write " 277412.34,

3.8.2-1.el6xen.x86_64 Xen kernellel, 1GB system rammal a random write lemegy 185MB/s-re.

Tudtommal a zfs-t echte a vasból csinálja a microserver, azért fogja meg ennyire, én ezért sem annyira csípem, jobban megbízok egy külön kártyában...

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

de most ezt a gépet minek hasonlítottuk a microserverhez?

"Tudtommal a zfs-t echte a vasból csinálja a microserver, azért fogja meg ennyire, én ezért sem annyira csípem, jobban megbízok egy külön kártyában..."
hát hogy lehet még a zfs-t csinálni? csinálnál a vezérlőn egy RAID-et, s azon egy sima zfs pool-t? akkor kb. a zfs értelmének a 70%-át veszíted el...

van egy valamivel combosabb storage bent az irodában, xeon pricval, LSI vezérlővel, 4db 15krpm 3,5" SAS lemezzel, 16GB RAM-mal, zfs raidz-vel az ír 550Mb/sec-kel, olvas 480MB/sec-kel, a párhuzamos IO műveletek meg se kottyannak neki szinte, azt kéne hosonlítani.

itt írtam róla, most nem áll módomban leteszteni iozone-val, mert már élesben van a gép, s van egy plusz layer ami jelentősen belassítja az I/O-t, s kikapcsolni nem tudom/akarom.
http://hup.hu//node/120200

Engem a wd red érdekelt igazándiból, zfs és egyéb huncutságokhoz volt már szerencsém, de a microserver miatt nem viszonyítási alap így sajnos, először szó se volt róla... :|
Pl én pont ezért nem tennék microserverbe zfs-t, mert kivégzi :)

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

én meg adatot csak zfs-en vagyok hajlando tarolni :)

mondjuk arra amire kell, jo, tehat hogy egyszerre 3-4-5 -en nezunk rola filmet, de altalaban nem szokott tobb lenni az 1-2 konkurens filmnezes, azt kiszoglalja.
akkor vagyok gondba, ha rendezgetni kell rajta a mappakat, s egyikbola masikba kell masolni, na akor nagyon idegesito, hogy tetu lassu.
meg barmi port-ot feltenni ra idegolo, anyira lassan fordul rajta minden, mint 10+ eve valami pentium-os masinan.
jo, lehet ez tulzas, de iszonyat kenyelmetlen,h ogy pl. egy portinstall mc a fuggosegeivel kb. 1 ora, mire lefordul...
egy normalis gepen ez nem tobb par percnel.

hat mert zfs kell nekem, es solarishoz nem nagyon ertek, vlamint nem tudom, hogy mennyire futna a microserveren, illetve kellenek olyan programok, amik solarisra nem erhetoek el, mint pl. plex server, logitech media server (squeezebox), stb.stb. linuxon nem akarok zfsezni. igy marad a freebsd.
amugy miert ne forditanam a portot? mire gondolsz?

linuxozni nem akarok, pont.
ne offoljunk itt evvel.

debian kfreebsd eleg oszvernek tunik, kiserletezni nem akarok, a freebsd-t sok sok eve hasznalom, bevalt, bizok benne, zfs-ben bizok.
ha nem lenne tetu lassu a microserver, szavam nem lenne.

freebsd packages:
elofordul, hogy nincs package...

a pina az jo gondolat! :)

[off?](Személy szerint nem utazom e-penisben, tehát nekem elég, ha annyit tud, amennyit kihasználok - és) teljes megelégedéssel használok egy első generációs N36L-ben ZFS-t WD Red lemezeken _otthon_. Nem tudom, mit lehetne kitaposni belőle, mert nem taposom; cserébe halk, hűvös és nem eszi meg a kenyeremre valót...[on?]

/etc/lib/lu/plugins/lupi_bebasic

Én sem vettem meg; amíg az OTN-t nem sérted és nem bánod, ha release-enként egyben (vagy nem) frissítesz, nem is kell megvedd. Támogatást persze ne remélj hivatalosan. Egyébként akkor valamelyik illumos-disztribúció irányába mennék, ahogy magam is teszem. (Sérteni tervezem az OTN-t :))

/etc/lib/lu/plugins/lupi_bebasic

Az OpenSolaris-t ugye amikor az Oracle jegelte végül, létrejött egy fork illumos néven, ami igazából "csak" az OS lelke - az OI ennek egy disztribúciójaként az OSOL örököse, ha úgy tetszik. Vannak más disztribúciók is, lásd Nexenta, SmartOS, OmniOS. Mind-mind specifikus célokkal. A kódbázis immáron - amennyire én tudom - független az Oracle-vonaltól; a többiek összedolgoznak. Attól függ, mit tekintesz Solarisnak :) Fogalmad okvetlen lesz sok dologról, ami több efféle rendszeren is előfordul.

/etc/lib/lu/plugins/lupi_bebasic

"Az OpenSolaris-t ugye amikor az Oracle jegelte végül, létrejött egy fork illumos néven, ami igazából "csak" az OS lelke"

Pontosan. A kernelt és közvetlen környezetét elvileg közösen fejlesztik.
Kicsit hasonlít a dolog a Linux kernel és a Linux disztribuciók viszonyához.

"Es a Nyitott Indiana az 1:1 replacement? Legalabbis, az ilyen parancssori cuccokat tekintve?"

Az OpenIndiana még eléggé hasonlít a Solarisra, de egyre inkább eltér a kettő.
SMF, dtrace, ZFS, SVM még ugyanaz, az ezer éves cli eszközök még ugyanaz.
Fokozatosan távolodik a Solaris és az Open vonal.

Azt ami érdekli az embert, vagy szüksége van rá. :)

Ha esélyes, hogy Sparc rendszerekkel kell dolgozni, akkor Solaris. Ingyen letölthető, és teljes értékű, tanulásra kiválóan használható, a dokumentáltsága kimondottan jó.

Én azért választottam az OpenIndiana-t, mert az ami a meglévő Solaris tudásomhoz leginkább "kézre állt".
Álltalános célú szervernek teljesen ok, ez a disztro áll legközelebb a Solarishoz.

A SmartOS, és OmniOS ami állítólag még jó. Mindkettőt egy-egy cég fejleszti, és saját cloud infrastruktúráját építi belőle. Ezek már inkább arra vannak kihegyezve, hogy cloud építőelemei legyenek. Ennek megfelelően ezek a Solarisra egyre kevésbé emlékeztetnek.

Dokumentáltságban szerintem elég problémás az utóbbi kettő, tanulásra semmiképpen. Az OpenIndiana még csak-csak, de az sincs sehol a Solaris dokumentáltságához képest.

Teljes mértékig egyetértek zwei kollégával. Még annyit tennék hozzá, hogy Solaris-ból is a 10-es utolsó update-jét venném elő. Ha azt kiismerted, jöhet a 11.1, és utána bátran válthatsz bármelyik utódra.

(Olyannyira virtualizálható a 10-es, hogy van hozzá unofficial virtio_blk driver portolva. Találsz a vendor oldalán ovf-et is akár, nyilván enélkül, de belereszelhető hamar abba is.)

/etc/lib/lu/plugins/lupi_bebasic

( calamari | 2013. 03. 07., cs – 23:47 )

Nagyon tetszik és érdekel ez a téma, köszönöm a topicnyitónak.

Milyen alternatívák vannak még ilyen sok disket befogadó házakra, gyárt más gyártó is ilyet?

Innét esetleg lehet még ihletet venni:
http://blog.backblaze.com/2011/07/20/petabytes-on-a-budget-v2-0revealin…
(illetve van már 3.0-ás is http://blog.backblaze.com/2013/02/20/180tb-of-good-vibrations-storage-p…)
Itt pl. ezeket a Hitachi Deskstar 5K3000 HDS5C3030ALA630 vinyókat dicsérik (ki tudja gyártják-e még).
Illetve azt állítják, hogy software RAID 6-ot használnak (Debian-al).
Van valakinek fogalma arról, hogy egy ilyen software RAID 6 mennyire megbízható, stabil, illetve erőforrásigényes egy ilyen vagy hasonló kiépítésben (12x3TB vagy 24x3TB)?

Amennyiben megbízható egyébként én a software RAID irányába mennék el így első körben.

♲♻♲

Igen valsz LVM-el jól össze lehetne stripeolni a kisebb RAID6-os tömböket, mármint nem stripe ra gondolok, hanem simán egy VG-be őket.
Mondjuk a legjobb ha az alkalmazás kezeli a több kisebb területet és akkor minden egyes kisebb RAID6 tömbre mehet külön fájlrendszer, ami némileg csökkenti a teljes adatvesztés kockázatát is abban az esetben, ha valamelyik RAID6 tömb mégis megadja magát...

♲♻♲

mennyi az az annyi? $56,696? Azért a a 10+ milla k.sok 500GB-ért, még egy EVA-ba is... :)

Egyébként 10K USD alatt elég szép konfigokat össze lehet építeni, de olyan huncutságokat azért ne várjon az ember ennyi pénzért, mint pl. redundáns controller, vagy aktív-aktív FC multipath, meg még egy pár apróság ami egy enterspájz storage-ban nagyjából 15 éve alap.

Az Intelnek is van ilyen barebone szervere:
http://www.szerver.hu/intel-szerver/intel-e5-2600-2u-rack-szerver-sandy…

Akár 12 db. 3.5"-os diszk, plusz 2 db. SSD az op.rendszernek, vagy
akár 24 db. 2.5"-os diszk, plusz 2 db. SSD az op.rendszernek

természetesen kapható hozzá 6Gb/s-os Intel HW RAID vezérlő modul 1GB cache-sel

Köszi, pont ilyesmikre gondoltam.
Itt ha kiválasztom azt a modellt, ami 24 disket fogad akkor van ott ötféle RAID vezérlő a listában.
Ezek közül rá tudok valamelyikre dugni 24 lemezt (ha igen, akkor hogy, a legnagyobb SAS port szám, amit látok az a 8)?
Ha software RAID-et akarok és nem kell RAID vezérlő, akkor hogyan tudom rádugni a 24 lemezt?
(Feltételezem, hogy nincs 24 SATA port az alaplapon.)

Szerk.:
Illetve úgy látom, hogy ez nem is SATA, hanem SAS.

♲♻♲

Expandernek hívják azt az eszközt, amely továbbosztja a 8 SAS/SATA fizikai portot 24 eszköz felé:
Intel RES2SV240 24 portos 6Gb/s SAS/SATA expander kártya:
http://www.intel.com/support/motherboards/server/sb/CS-031813.htm

Ez természetesen kompatibilis az alaplaphoz csatlakoztatott HW RAID vezérlővel. A szerverhez pedig jár a 6 db. SFF8087 to SFF8087 kábel az expander és a Hot-Swap backplane-ek (3 db. 8-as) összekötéséhez.

De létezik olyan model is, amely előre beépítve tartalmazza a HW RAID vezérlőt és az expandert:
Intel Server System R2224GZ4GCSAS (24db. 2.5"-os diszk)

Ebben gyárilag installált és kábelezett az Intel RMS25CB080 8-port HW RAID SAS modul és az Intel RES2CV360 Integrated 36 port expander - így mind a 24 diszk a HW RAID vezérlőre van kötve.

Látom, hogy otthon vagy a témában, ezért kérdeznék még egyet, előre is köszönöm a választ.
Ha egy adott konfigurációnál a hardware RAID mellett döntök, akkor milyen esélyem van arra, hogy ugyanezeket a diskeket pl. 3 év múlva át tudom tenni egy másik szerverbe és az abba beleépített "új" vezérlő is kezelni fogja a diskeket.
Ugye a software RAID-ben egy nagyon vonzó dolog az, hogy kiveszem az egyik gépből, összekeverem őket és egy másik gépbe átrakva teljesen más sorrendben, ugyanúgy össze tudom állítani a tömböt.
Ez ugye nem tesz függővé egy adott modelltől vagy akár egy adott gyártótól, ha x év múlva más gyártó jobb vagy olcsóbb lesz akkor könnyű az átállás.

Nyilván azzal tisztában vagyok, hogy két teljesen különböző gyártó termékei nem lesznek kompatibilisek egymással.
Viszont ha most összeállítok egy ilyen szervert és 3 év múlva beszerzésre kerül egy új hardware (ugyanúgy Intel, egy akkor aktuális modell)
és a diskeket nem akarom cserélni, vagy nem rögtön akarom cserélni (bármilyen okból is, ne menjünk bele, hogy 3 év után azt is érdemes lenne cserélni, stb.),
akkor tudok-e majd olyan (akkor újan kapható) vezérlőt venni, ami kezeli a már létező diskeket, jobb esetben úgy, hogy bármilyen sorrendbe is teszem be őket.
Mennyire figyelnek oda erre a gyártók, vagy kimondottan az Intel, aki szintén valamelyik másik gyártó chipjeit használja a RAID vezérlőin, asszem.

♲♻♲

Meggyőződésem szerint 3 év múlva az aktuális legújabb Intel HW RAID (mondjuk 12Gb/s SAS/SATA-4) vezérlő fel fogja ismerni a RAID kötegeket a diszkeken és berendezi őket. Én mondjuk azért nem kevergetném össze őket, figyelnék a diszk sorrendre.

A mostani Intel RAID vezérlők biztosan felismerik az előző generációs Intel vezérlők által kezelt kötegeket.

Ez persze egy akadémikus vita lehetne, melyik fogja tovább bírni, a hardver, vagy a diszkek... Szerintem kb. 5 évre érdemes tervezni, addig bírni fogja minkettő - feltéve, hogy valódi szerver (nem desktop) diszkeket szerelsz a szerverbe.

Az Intel vezérlők gyakran átbrandelt LSI vezérlők.

Ahogyan egyes IBM vezérlők is -- az IBM általában a legolcsóbb, míg az LSI a legdrágább (bár elég nagy barom az, aki listaárat fizet, tehát YMMV). Sokan ezért kihagyják a marketingesek adóját és IBM-ként veszik meg és átflashelik sima IT HBA-ra, és zfs-t futtatnak rajta.

Bónusz lenne a VT-d, ami a vezérlőt szépen összepasszírozza a virtualizációval. Nem értem miért, a kis Intel Xeon-os microserver mintha direkt tiltaná le a VT-d. Kár érte.

( zwei | 2013. 03. 08., p – 08:59 )

http://www.zfsbuild.com/

A zfs mellett itt álltalános okosságok (szempontok amiket érdemes figyelembe venni) is vannak.

Az egyik fő konklúziója pl.: rakj bele sok-sok-sok memóriát. A working set méretétől függően akár kegyetlen sokat is tud dobni a random-read teljesítményen a nagy read cache.
A fenti cuccba pl. min 64GB-t raknék, de a kétszerese sem ördögtől való. :)

Desktop boardok, és gagyi cpu-k nem javasoltak, ha több klienst is rá akarsz lógatni, és fontos az IO teljesítmény.
Ha zfs-t használsz, akkor pl. egy nem túl aggresszív tömörítés is jelentős IO teljesítmény növelő lehet, de ahhoz is CPU kell.

A hot-spare diszkről se feledkezz meg.

Hát, ha az ember nem figyel oda akár csak pár hónapig, szédületes, hogy mennyit változik a hardware kínálat.

Pár éve még szekrény méretű vasakban volt 128GB-nél több.
Most nem egy olyan 4 unitos van a kezem alatt, amiben 512GB memória van. Talán emiatt már egy ideje már nem is nagyon hoz lázba, ha egy kicsit durvább vassal van dolgom. (Pedig én is C64-en kezdtem)
Régen Kb-ban mértük a memóriát, aztán egy ideig Mb-ban, majd Gb-ban, lassan kezd eljönni a Tb-ok ideje. (Gramar nazik: please most hagyjuk a Gb, GB, GiB, stb. féle vergődést.)

Előttem lévő vasban van 8 db xenon e5-2620 as cpu 512G ram.
Telefonomban 1G ram, de már vannak 2G rammal rendelkező telefonok.

Rohan az idő.

Viszont ez nem a magyar átlag, múltkor volt szerencsém egy családnak a gépét csinálni, amivel netezni akartak. Celeron 1300Mhz 256M ram. Mondtam nekik, ha van pár ezer ft-juk akkor legalább egy 512M-1G ramos gépbe fektessenek, be ezzel sokat nem fognak netezni.

Fedora 17, Thinkpad x61s

Elnezest, hogy ezen a szalon kicsit off leszek, de elojott a ZFS, es eszembe jutott, hogy milyen jo kis cross-platform FS.

Az lenne a kerdesem, hogy egy sima atlag desktop felhasznalasra, illetve annal picit tobbre alkalmas-e?

Konkretan VirtualBox gepeket szeretnek futtatni, es nagyon fontos lenne, hogy ezek a gepek mind Linux mind OS X alol elerhetoek legyenek. Dedup, tomorites nem kell, csak a pure FS funkcionalitas.

Ezen felul van egy csomo apro pici fajl (forrasfajlok), amiket el szeretnek erni, de itt nem fontos a teljesitmeny, mert nem forditok forrasbol nagyon semmit, ket iras kozott meg eltelik par perc/ora szoval irrelevans.

Jelenleg HFS-re formazott journal nelkuli particioval szivok mint kozos storage, de a Linuxnak iszonyatosan tre a HFS tamogatasa, es ez csak reszben szarmazik abbol, hogy maga az FS zart: egyszeruen intenzivebb hasznalat mellett naponta, ha nem futtatok VirtualBoxot, akkor 3-4 naponta osszehanyja magat a gep (=elpanikol).

Elorebocsatom: csak a fenti kerdesem van, a problemat nem akarom maskeppen megoldani, sem kulso storage-zsel, sem mashogy.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem sokat, fejleszteshez hasznalt webappokrol van szo elsodlegesen. Esetleg 1-1 komolyabb tesztrendszert epitek (2-3 gep, peldaul Linux HA vagy mysql replikacio kiprobalasahoz), de szamottevo terhelest sosem rakok ra, mert a winyo sem birna (egy 7200-as samsung van benne, ami nem rossz, de egy komplett szerver terheleset nem birna el), de nincs is ra igenyem. Inkabb foleg fejleszteshez, bizonyos dolgok kiprobalasahoz hasznalom.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( kisg v | 2013. 03. 09., szo – 09:37 )

Szerintem most, hogy az E3-as Xeonok desktop árban vannak (Intel alaplap + processzor + ECC RAM-ról beszélek), nincs igazán értelme desktop alkatrészekkel szenvedni, főleg ott, ahol a költségek nagy részét úgyis a HDD-k és SSD-k, na meg a ház és a 10GE-s hálókártya fogják adni...

( NagyZ v | 2013. 03. 09., szo – 14:28 )

megneztem memoriabol mi az, amihez a legkonnyebben hozza tudok jutni. a nyertes: Kingston ValueRAM ECC Registered, 1x 16GB, DDR3-1600, CL11 (KVR16R11D4/16)

ugy nezem, hogy siman tudnek ebbol venni akar 8at is a storageba, nem tul draga (142 CHF a kisker ara)

( andrej_ v | 2013. 03. 09., szo – 19:29 )

Most megint leírom a jelenlegi kedvenc AMD Opteron konfigomat. :)

Alaplap: Supermicro H8SCM-F (http://www.supermicro.com/Aplus/motherboard/Opteron4000/SR56x0/H8SCM-F…), ha kevés a PCIe bővítőhely, akkor van remek 2 cpu-s verzió is a lapból (http://www.supermicro.com/Aplus/motherboard/Opteron4000/SR56x0/H8DCL-iF…).
CPU: Ízlés szerinti 4200 vagy 4300-as Opteron
Memória: Mivel a lap 128GB-ot, illetve normális áron 64GB-ot, támogat ezért remek ZFS alá is. Én 2x8GB-al indulnék (szigorúan Reg. ECC Kingston-éktól és DDR3-1600), amit ha kell 2x16GB-vel könnyen meg lehet toldani és máris 48GB-nél járunk erölködés nélkül.

Ha ZFS vagy softraid:
- Ízlés szerinti LSI SAS6G HBA (8-16 belső portig, maximum 3 db)
- Ízlés szerinti SAS (igen, akár nearline is) HDD-k, ha már SASolunk
- L2ARC-hoz Samsung 840 Pro SSD, ami az alaplapi SATA portra is köthető
- Ízlés szerint akár két (vagy három) valami egyszerűbb SATA diszkről, sőt pendrive-okról is lehet bootolni, szintén az alaplapi SATA vezérlőről vagy az alaplap belső USB csatijáról

A ZFS tudtommal jelenleg nem tud online capacity expansiont, szóval a későbbi diszk bővítést erősen ki kell találni.

Ha HW Raid:
- Ízlés szerinti RAID vezérlő, én mondjuk P420-as vagy P410-es (akár használtan is) SmartArray-ekben gondolkodnék, SAS expanderrel vagy több példányban.

Hálózat:
- Alapból 2x1Gbites intel vezérlő integrált, ha elég két LSI HBA vagy HW RAID vezérlő, akkor remekül elfér a fenti tge kártya.

Ha csak 1T-s diszkekben gondolkosz, akkor lehet jobban jársz a 2,5"-os NLSAS vonallal. Kisebb fogyasztás, kisebb házikó, kisebb hűtési igény. A 2,5"-os seagate átlagos igénye 6,35W, a 3,5"-osnál 8,93W, ami óránként olyan bő 60W megtakarítás csak a diszkek fogyasztásán és a tápot is kevésbé terheled.

Sok diszkkel nem, de egy 4x500GB-os mérést tudok majd egy teszt példányon a helyi SATA vezérlővel a single cpu-s lappal. Használjuk a kétprocis lapot 4x73GB-nyi U320-as diszkkel (nem őrültünk meg, ilyen volt temérdek) Linuxos softraiddel és remekül szalad (SQL + webszerver), pedig ha 2 alá megy a load és 100Mbit alá a kimenő adat akkor az idle-nek számít. :)

Csak jóval kisebb gépekre volt eddig igény sajnos. A mérésnél nagyon fontos, hogy a hálózaton mit tud kitolni vagy fogadni a gép az adott protokollal. Mert sokszor láttam, hogy a helyben mért érték nem nagyon van köszönő viszonyban a hálózatossal.

Akkor az NFS lesz gondolom vagy esetleg iSCSI. Van már a Linux kernelben is fscache vagy mi és pont NFS alá elvileg. Nekem a ZFS NFS felől mért sebessége eléggé csapnivaló és sajnos ez valami "központi" bug FreeBSD-vel, mint kiderült. Igaz esetemben backup szerverről van szó, de ott sem árt, ha tempósan átjönnek a mentések. :)

Én egy időben mentettem zfs-re hálózaton mindenféle módon, de ritka szar volt minden tekintetben, és elég sokszor széthullott (nexenta store volt), azóta hálég nincs közöm ilyesmikhez, szerinted milyen az ideális SW környezet?

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

FreeBSD 8.3-al próbálkoztam, azaz most is az van, SSD-t kapott a ZIL, de L2ARC nem volt. FreeBSD-vel elég jól megy, deduplikál, tömörít stb. Egy ősi netburst-ös Xeonon és egy LSI 16 portos SAS HBA-val operálunk, de még csak 3x2TB raidz-nek, 2x64GB SSD került rá. Az aktuális problémám, hogy állítólag Sambával remek a ZFS sebesség, de cserébe nem tudom FreeBSD-n megoldani hogy az AD-ből menjen az authentikáció és ezzel se vagyok egyedül. :)

Nekem előfordult, hogy volt egy storage, amin nfs-en volt kiadva az archive ds, ez menet közben gondolt egyet és game over, aztán valami elég mély kókányolással sikerült csak újra alávarázsolni, istenért se fogadta el...
Ez emlékeim szerint 4.1 verzió volt, remélhetőleg javították ezt azóta...

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( f0xhu v | 2013. 03. 09., szo – 20:51 )

--
A gyors gondolat többet ér, mint a gyors mozdulat.

( NagyZ v | 2013. 03. 11., h – 22:42 )

a zfsbuildes hw elegge tetszik, szerintem majdnem ugyanilyet fogok epiteni.

- eleg az a 20G ZILre? ha jol olvastam, ez $RAM/2 altalaban, ok meg 64G ram melle raktak be a 20G-t.
- az E5-1660 kb 1100 CHF, az E3-1270v2 pedig csak 360; tudom, hogy ez csak 32G memoriat tud kezelni. eleg lenne ez?

A ZFS alapértelmezetten 10 másodpercenként ír a lemezre, arra kell a ZIL, hogy a 10 másodperc alatt összejött adatmennyiséget tudd tárolni. 20GB ZIL esetén 2GB/sec-el bejövő adatmennyiség esetén fog megtelni a ZIL. Persze szívás van (gondolom), de ha max 500MB/sec-el jönnek az adatok, akkor nem fog megtelni, és ki fogja tudni írni, ha a mögöttes storage szekvenciálisan bírja.
Szerk: ja és alapból a RAM-ba esik be az adat. A ZIL arra kell, hogy ne a nagy válaszidejű HDD-re írja ki a RAM-ból, hanem a gyors SSD-re. A ZIL előnye abban van, hogy a szinkron requesteknél nem 8-10 ms lesz a válaszidő, hanem 1 ms, ugyanis szinkron kérésnél addig nem jelez vissza, hogy végzett az írással, amíg a RAM-ból ki nem lett írva valahova (SSD, vagy HDD). Ezért teljesít gyengén a ZFS ZIL nélkül írásban.

Volt olyan korábbi verziója a zfsnek (15 talán), ahol ha a zilt hozzáadtad, utána nem lehetett kivenni, és ha valamiért meghalt (pl. mert nem mirrorozott volt), akkor valami nagy mágiával lehetett csak kitúrni az diszkekből azokat az adatokat, amik ahhoz kellettek, hogy újra importálni tudd a poolt. Újabb zfsen elvileg már kevésbé problémás a dolog, de én mindig tükrözött zilt használok, biztos ami biztos.

Üdv,
Gergely

Elég sokáig.
A ZFS jellegéből adódóan egyenletesen terheli az SSD celláit, mert nem ír felül adatblokkokat, hanem a változásokat új blokkokba írja.
Egyébként meg jó minőségű SSD-t kell venni, ami bírja az írást, mert a SLOG -ra csak és kizárólag írási IO kerül.

A ZIL-ben nem fájlok tárolódnak, hanem blokkok.
Egy pillanatra elgondolkodtam azon, hogy a garbage collection és TRIM hogy működik ilyenkor, de rájöttem, hogy ha egyenletesen terheli az eszközt, akkor nincs szükség mindenféle varázslásra, mert közel egyformán "kopnak" a cellák.

"20GB ZIL esetén 2GB/sec-el bejövő adatmennyiség esetén fog megtelni a ZIL."

Nos ez nem teljesen így van. A ZFS Intent Log meta adatokat tartalmaz.
A Separate Intent Log (SLOG) ZIL szinkron IO cachelésére használatos, az aszinkron IO mindig közvetlenül diszkre kerül.

Ahogy te is írtad, SLOG hozzáadásával gyorsíthatók a szinkron IO műveletek, azért mert az intent log (ami kb. a ext3 ext4 esetén a journaling-nak felel meg) gyorsabb eszközre kerül.
Ezen felül a kiírandó adat csak 64k-nál kisebb írási IO esetén kerül a ZIL-re, vagyis nem az összes kiírandó adat megy át a ZIL-en, csak jóval kevesebb.

A hivatalos dokumentációk egyébként RAM/2 méretű SLOG-ot javasolnak.

Nem tudom. :)
Elvileg nem szükséges.

Szerencsére dinamikusan lehet hozzáadni/elvenni a log dev-et, így lehet játszani a méretével.

Az SSD-t még L2ARC -ra is lehet használni (kb: másodlagos read cache) ezért ha pl. nagyobb méretű SSDnk van, a ZIL csökkentésével és az L2ARC növelésével lehet az olvasási teljesítményen is javítani, attól függően, hogy milyen az IO terhelés jellege.

szerk: egyébként, ha teheti az ember, ZIL-re és L2ARC-ra külön SSD-t érdemes használni.
ZIL-re olyat ami bírja az írást, megbízható, és nem feltétlen nagy méretű.
L2ARC-ra jó az olcsó, kevésbé megbízható, nagyobb méretű. Ezt még tükrözni sem kell, mert nincs adatvesztés ha megdöglik, legfeljebb csak csökken az olvasási teljesítmény.

szerk2: Ezzel a scripttel megnézhető, hogy mekkora a ZIL tényleges írási terhelése: http://www.richardelling.com/Home/scripts-and-programs-1/zilstat (dtrace alapú, szóval nem működik mindenhol)

> Szerencsére dinamikusan lehet hozzáadni/elvenni a log dev-et, így lehet játszani a méretével.

Igen, ez vilagos es probalgatom is, de nem igazan uptodate a doksi. Az erdekelt, hogy mi a kozvetlen gyakorlati tapasztalatod ezugyben.

> ZIL-re olyat ami bírja az írást, megbízható, és nem feltétlen nagy méretű.

Nekem ettol fuggetlenul is az a tapasztalatom egyelore, hogy valojaban szinte mind1 az ssd-knek, hogy mennyit irsz rajuk. Legalabbis atlagos felhasznalas mellett (md raid es zfs eseten is). Kopp-kopp...

> L2ARC

Ha jol emlekszem, mirrorozva hozza sem lehet adni, ha kettot adsz hozza, akkor stripe-olva lesz

> script

Koszi, megnezem, bar linux-szal hasznalom, szoval erdekes lesz:)
Sokkal inkabb erdekelne ugyanez L2ARC-ra, hiszen a ZIL-t max. egy picit tulmeretezi az ember es 10 helyett 20G-t ad neki. De ZIL eseten lenyeges, hogy 120G v. 240G...vagy akarmennyi.

10x
tompos

"Az erdekelt, hogy mi a kozvetlen gyakorlati tapasztalatod ezugyben."

Ja, külön ZIL-t csak teszteléskor használtam.
ZFS-re vagy mentéseket pakolok ahol nincs szükség külön ZIL eszközre, vagy FC SAN-van, ami meg elég gyors és azért nincs külön dev.

"Ha jol emlekszem, mirrorozva hozza sem lehet adni, ha kettot adsz hozza, akkor stripe-olva lesz"

pontosan. Csak azért írtam, mert felmerült feljebb a hardware-es raid is, ami L2ARC esetében felesleges.

mennyi a valoszinusege annak, hogy a memoria bufferben talalhato adatok (~64MB+), amelyek nem irodtak meg ki, az aramszunet soran stabil tarolora keruljenek ?

nem az a gond, ahogy ami stabil tarolora irodott azt esetleg nem tudja visszaolvasni, hanem az hogy a disk azt hazudta hogy kiirodott, kozben tenylegesen nem, csak a memoria bufferbe kerult bele

100%. Ez a lényege az egésznek: amint az ZIL kiírásra kerül az SSD-ra, a ZFS jelez, hogy az adat stabil tárolón van. (Értelemszerűen szinkron műveletről beszélünk)

Diszk meg ne hazudja azt, hogy ki lett írva ha még nem. Ez ZFS-től, SSD-től független probléma, itt most nem arról van szó.

Az SSD már mondhatja azt, hogy kiírásra került, hiszen nem felejtő tárolón van az adat - az oprendszer feladata, hogy egy újraindulás után összelegózza az adatokat a kétféle tárolóról. Aztán hogy ténylegesen mikor kerülnek át a diszkre az adatok, az irreleváns, majd valamikor - ha leállítás során van "takarítás" (bbwc esetén illik, ssd-s cache esetén nem igazán tartom kritikusnak, pláne, hogy a diszkre már kiírt blokkoknál valahogy jelezni kell ezt az állapotot, azaz a diszkre írás az ssd-n is írási műveletet fog generálni. Egy bbwc más tészta, ott egyértelmű, hogy a cache csak átmenetileg képes tárolni a benne lévő adatot, ergo a szabályos leállításnál ki kell söpörni az utolsó bájtot is a cache-ből.

Ha az SSD ilyet csinál, akkor ki kell dobni, és venni kell egy olyat, ami nem csinálja. Mégis hogyan képzelsz el egy olyan rendszert adatvesztés nélkül, ahol nem garantált, hogy az adat tényleges kiíródott?
A ZFS ebben az esetben is csak annyit tud, hogy mivel az überblock írása atomi művelet, ezért az fs mindig konzisztens állapotban van.

Along with higher endurance, the SSD includes a new data loss protection feature, which maintains sufficient internal power via internal electrolytic capacitors with self-testing capabilities that can alert a systems administrator to irregularities. If power is lost, the drive automatically redirects writes in progress from the cache directly to the NAND flash, avoiding data loss, Peene said.


tessek, ezert lehet siman, hogy az SSD hazudik ;-)

( turul16 v | 2013. 03. 13., sze – 09:44 )

HW -raid csak az elem (battery backed) miatt lehet erdekes, egyebkent erdemesebb a soft raidet hasznalni IMHO.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A szokasos:
- Nem lassabb, mint a meregdraga raid vezerlo es gyakran Linux kernel softraid implementacio okosabbnak es gyorsabb bizonyul
Ha feltetlezuk, hogy egyforman okosak, akkor soft raid hatranya lehet, hogy tenylegesen (RAID 1, n*2 disk) 2x annyi I/O -t vegez a rendszer, ez mindadig nem baj, amig a bus vagy a CPU nem a szuk keresztmetszet (default: nem az).

- nincs vendor lock-in, HW -raidek neha furcsan taroljak dolgot, amit csak a josagos tervezojuk tud

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Vegyünk egy "egyszerű" RAID5-öt. egy írás legalább egy olvasás és kettő darab írási művelet, közben meg checksum számolgatás. Azaz legalább három i/o-művelet egy írás. ILyen alapon a ToE-t is kikapcsolhatnád, hiszen "belefér" a hálózati forgalom checksum-számolgatása a modern cpu-k teljesítményébe...

Eleg jol elmondtad miert nem preferalom RAID5 -ot, megha gyakran kicsit okosabban is tortenik a dolog..

RAID5 3 disk: 1* iras, 2* olvasas, 2* kapacitas
RAID10 4 disk (softraid): 2* iras, (2-)4* olvasas, 2* kapacitas
+1 disk olcsobb, mint egy raid vezerlo, a vegeredmeny gyorsabb is.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

RAID5, 3 diszk esetén egy blokk írásához be kell rántani a "párját", amivel elkészül a checksum blokk, majd kiírni az új adatot és a megváltozott checksum-ot, azaz egy írás szoftveres raid esetén egy olvasás+kettő írás lesz szerintem... Mindezt célszerűen rábízod a vezérlőre, ami az OS felé egy darab írási művelettel letudja a dolgot. Egyébként nagy diszkeknél hot spare nélkül nem csinálnék raid5-öt (sw/hw raid mindegy ebben az esetben), úgyhogy a kettő diszk után a négy darabos felállás a következő nyugodtan alvós verzió - az meg összefűzött/tükrözött verzióban teljesen jó - még szerencsétlenül kidöglött két diszk esetében is megmarad az adatok egy része.

Nekem mondod... :-P Láttam széthullani tizenx TB-os RAID5 tömböt sajna, és ott aztán hiába lett volna spare diszk, 10 percen belül sem a szinkron, sem a diszkcsere nem lett volna meg :-/ Aztán ugyanabban a gépben egy másik tömb is széthullott - kellemes éjszaka volt, mit ne mondjak... Azóta, ha jól tudom, problémamentesen ketyeg a vas, de immáron raid6-ba rakva a diszkeket...

A 3 nagy diszk raid5 - orosz rulett. Ha van egy 4d berakva hot spare-ként, akkor picit jobb - ellenberger négy diszknél valamilyen raid10 megoldásra hajlanék inkább, pláne a sw-es raid6 helyett.

Amennyire tudom, leallt a figura a fejlesztesevel, mivel a zfs megjelenesevel okafogyotta valt lenyegeben. Bar ezt igy leirva talan sosem olvastam es nem is kerdeztem ra.

A figura az energiajat inkabb egy storage tiering module fejlesztesere forditja (btier), hamarosan varhato az 1.0 kiadas.

tompos

( NagyZ v | 2013. 03. 14., cs – 22:00 )

ZFS-ezni Nexenta, vagy vegyek Solarist? :)

( NagyZ v | 2013. 03. 14., cs – 22:34 )

hogy lehetne HA-sitani a dobozt?
a BE24-es doboz backplaneje dual expanderes, azt lehetne ket HBA-ra kulon-kulon rakotni, de egyeb opciot nem nagyon latok...

( NagyZ v | 2013. 03. 20., sze – 14:38 )

ami most felmerult, az az, hogy a compute nodeokon lenne ceph, es nem lenne kozponti storage.

Röviden: kevés tudás van belőle, iszonyat tákolás/reszelés lehet egy nagyobb architektúra összerakása.
Amíg egy iSCSI/NFS/FC alapú tárolás "régi" bejáratott technológiákon alapszik, és jól integrálható mindenfélével, addig a ceph, drbd és társai szerintem a sajtreszelővel rejszolás kategóriája.

Pl. egy nagyobb Citrix/VMware/Hyper-v cluster környezetbe triviálisan illeszthető egy SAN/NAS tároló, addig a ceph-et rá sem tudod hegeszteni arra a vasra, amin azok futnak. Ha saját magad rakod össze a kvm/xen akármi virtualizációs szervert, az 10-szer annyi idő, mint ugyanazt megoldást összepattintani kereskedelmi termékekből (vagy azok ingyenes verziójából.)

Más felhasználási területen, pl. web/adatbázis kiszolgálás esetén talán egyszerűbb a feladat, de akkor is kézzel kell implementálni, nincsenek hozzá management eszközök, stb.

Nem mondom, hogy nincs létjogosultsága, tuti, hogy van sokszáz terás referencia installáció, de talán akkor egyszerűbb egy ilyet hatékonyan összerakni és üzemeltetni, ha van a reszelgetéshez/szopáshoz megfelelő mennyiségű idő és kedv.

" pl, ingyenes kereskedelmi termékből hogy csinálsz HA-t pl? "

Úgy mint az ingyenes opensource termékkel: sok tákolással és szívással.
Egyébként meg terméke válogatja. Citrix xenserverből pl. megegyező szerverekkel és némi scripteléssel nem túl bonyolult. Vmware alatt már nem vagyok benne biztos, hogy megoldható.

Szerk: hyper-v -vel sem lehet ingyen, viszont ha már HA kell, akkor nem olyan nagy dolog kiköhögni azt az 1db windows szerver licenszet, ami a HA-hoz szükséges domain controllerhez kell.

Az ingyenes opensource cuccok is pénzbe kerülnek, csak éppen a legtöbbször munkaidő formájában fizeti ki az ember.

El kéne már fogadni, hogy a nagy rendelkezésre állású informatika bizony pénzbe kerül.

Akinek HA kell, az valószínűleg fontos üzleti célra használja, ami pénzt termel, vagy támogatja a pénzt termelő tevékenységet. Ez esetben meg tessék kiköhögni az árát.

Ideális esetben az ember kombinálja az ingyenes opensource és fizetős kereskedelmi termékeket, aszerint, hogy az adott infrastruktúrában az adott célra melyiket olcsóbb használni.

Pl. egy 20 windows munkaállomásos környezetbe a franc sem szivatja magát linux/samba/cups file/printer szerverrel (windows DC töredék idő, nagyságrendel nagyobb funkcionalitással), ellemben a pop3/imap/smtp mehet linuxra vidáman.

"Citrix xenserverből pl. megegyező szerverekkel és némi scripteléssel nem túl bonyolult."
Az eula-t sérted gondolom egyértelműen ezzel ugye :) ?!

Egyértelmű hogy pénzbe kerülnek, mégpedig kemény mérnökórákba, de ha ezt üresjáratban teszi az ember, akkor számolhatjuk ingyenesnek is.. :)

"Akinek HA kell, az valószínűleg fontos üzleti célra használja, ami pénzt termel, vagy támogatja a pénzt termelő tevékenységet. Ez esetben meg tessék kiköhögni az árát."

Persze, de nem mindegy mit és hogyan..
Amelyik cég alapból nyitott az open source vonalra, és úgy gondolja, neki jobban megtérül mérnökórát/üresjáratot feccölni bele, az nyert vele, főleg ha ha egyszer ismeri a technológiát,onnan kvázi ingyen viszi, nem az éves licencel.

És ha nem is fél év alatt, de 5 alatt ez jobb lesz szerintem.
De nem generálom magunknak a konkurenciát, persze vegyétek csak a fizetőset mindenből, mindenre :)

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

" eula-t sérted gondolom egyértelműen ezzel ugye :) ?!"

Nem sérted. Live migration az ingyenes Citrixben is van. senki nem akadályoz meg, hogy ne csinálj pár scriptet, ami figyeli a VM-ek állapotát, aztán kapcsolgat ha kell.

"Egyértelmű hogy pénzbe kerülnek, mégpedig kemény mérnökórákba, de ha ezt üresjáratban teszi az ember, akkor számolhatjuk ingyenesnek is.. :)"

Soha nem ingyenes. Fizetés formájában odaadod a mérnöknek, és nem termel belőle pénzt.
Amiről te beszélsz, az gyakorlatilag egy hosszú távú és jelentős tőkeigényű termékfejlesztés.

Olyan helyen van értelme csinálni, ahol ez a tudás pénzzé tehető, vagy akkora méretben lehet alkalmazni, ahol már a saját innováció költséghatékonyabb is lehet.

Ahol az IT kiszolgáló terület, ott is lehet sikeresen ingyenes opensource megoldást alkalmazni, de ekkor nyilván egy külső beszállító implementálja, ami ha licenszdíjat nem is kér, bizony nem ingyen dolgozik. Ez esetben az ügyfél megnézi, hogy a fizetős szoftvert ajánló cég és az ingyenes szoftvert ajánló cég megoldása mennyibe kerül. Van úgy hogy az egyik olcsóbb, van úgy hogy a másik.
(zárójeles megjegyzés: Ha az ingyenes open source terméket szállító cég a kérdéses megoldást "megpatkolja" saját fejlesztéseivel, akkor az ügyfél könnyen egy kedves kis vendor-lock-in szituban találhatja magát. Ez mondjuk az ingyenes opensource terméket szállító cégnek egy előnyös helyzet.)

"De nem generálom magunknak a konkurenciát, persze vegyétek csak a fizetőset mindenből, mindenre :)"

Eredetileg ez a thread nem erről szólt. A ceph féle elosztott rendszer vs. "hagyományos" NAS/SAN rendszerek. És eredetileg nem is az ingyenes opensource-al kapcsolatban emlegettem a "reszelés/szopás" kifejezéseket, hanem a ceph és hozzá hasonló relative új (az én konzervatív felfogásomban még experimental) jellegű rendszerekre mondtam.
A "nagy rendelkezésre állású informatika pénzbe kerül" sem azt jelenti, hogy nem lehet ingyenes open source programokkal megoldani. Gyakran jobban is meg lehet oldani, de akkor is (sok) pénzbe kerül: kell normális vas, és jó szakember.

Ha jobban körülnézel, látod, hogy az egész topic egy ingyenes, opensource szoftveren alapuló storage építéséről szól, amihez úgy gondolom adtam én is pár használható tanácsot (sőt, 1-2 hónapja nekem is eszembe jutott, hogy kéne egy ilyet összerakni saját használatra), és egyszer nem említettem, hogy vegyen az illető egy normális EMC-t vagy Netappot. :)

Nagyon eltértünk a témától, szerintem ezt itt zárjuk le.

( _ventura_ v | 2013. 03. 21., cs – 11:12 )

SUN/Oracle X45xx sorozata, abba fér 48db disk, Solaris + zfs, lehet nexenta is elfut rajta nem tudom, mi solarissal használjuk.

Fedora 17, Thinkpad x61s

( secretx v | 2013. 04. 03., sze – 19:03 )

Ha összeállt a vas, egy IOzone-t futtass már rajta plz, a pontos konfig megadása mellett...

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( insomnia v | 2013. 04. 03., sze – 22:45 )

Az iozone eredmenyre en is kivancsi vagyok, osszehasonlitanam az intel vassal.

Az L2ARC-ból okosan levezettem, hogy ZFS lesz rajta, de milyen OS?
A ZIL is ezen a 330-ason lesz? Azt nem kéne duplikálni?
Gondolom RAM-ból kitömitek a 32GB-re.
Hány VM szerver lesz rálógatva és milyen topológiával?
A 2x256GB SSD gyors storage-nak lesz (pl. VM swap)?
Az 5 seagate mirrorban lesz 1 tartalékkal, vagy raidzX?

Üdv,
Gergely

nexenta/fbsd
egyelore megnezzuk ZIL/L2ARC nelkul, aztan megnezzuk mennyit dob rajta, ha vannak
mivel ez foleg "jatszos" storage, igy nem olyan sok VM, kb 40-60
gyors storagenak, igen, viszont openstacken at barmelyik juzer kerhet maganak egy iSCSI targetet, igy igazabol arra hasznalja, amire akarja
ezt meg nem talaltuk ki, valszin mirror+1 tartalek egyelore, ha a performancia keves, akkor valtunk

( NagyZ v | 2013. 06. 08., szo – 22:19 )

a nexenta kozolte, hogy a chelsio t420 nem tamogatott, szoval nincs vele 10G-m. FreeBSD-vel meg egyeb bajaim vannak jelenleg :(

FBSD-n jo ideje nem neztem, csak a levlistak bejegyzesei alapjan vannak benyomasaim.
Ezek alapjan ugy tunik, meg vmivel talan kevesbe kiforrott. Ha jol latom, az Illumos-t tekinti mindket projekt az upstream-nek, de feature-ok portolasa megy ide es oda is.

Ha pl. jon vki, h vagy egy corrupt pool-ja, akkor probaltatjak vele mindenfele live rendszerekkel importaltatni is, koztuk fbsd-sel is.

A ZoL-t ha nem is gozerovel, de azert fejlesztik intenziven, de nem tudom, hogy az spl alkotta +1 reteg miatti problemakat le fogja valaha vetkozni. Elofordul kernel panic is miatta a bugracker szerint, bar amikre egyebkent trivialisak szoktak lenni a fix-ek.

Nekem szubjektiven ez a meglatasom.

tompos

( NEUROFiRE | 2013. 06. 29., szo – 15:01 )

Jo reggelt!

Hasonlo cuccot szeretnek, ill. en kb. ket eve csinaltam is valamit ami mukodik es tetszik, csak eleg kokany, raadasul kezdem kinoni, szoval fejleszteni kell egy kicsit.

A cel: nagyobb mennyisegu adat tarolasa es egy kisebb/kozepes tesztkornyezet (a teljesitmeny nem kritikus) virtualis gepei ala tarhely (errol futnak a gepek vagy helyben, vagy iSCSI-rol).

Korabban nagyjabol ezek voltak az elvek, ebbol most sem engednek, foleg mivel ezek mar adottak:
-ECC RAM
-HW RAID6

A jelenlegi allapot:
-Intel S1200BTL
-valami ULV Core i3 (meg Sandy Bridge alapu)
-16GB ECC RAM
-Intel RS2BL040 RAID hartya
-2x Intel AXX6DRV3GEXP (SAS expanderes hotswap cage)
-12x Hitachi 2T/7200RPM HDD (7K2000/7K3000 vegyesen)
-hulladek haz (Codegen 4U500)
-FSP Epsilon tokomtudja milyen tap (500-600W)

Igazabol a hazzal es a tappal vagyok bajban, a tobbit megoldom, ill. van elkepzelesem a megoldasra.
Eredetileg 4U600 hazat szerettem volna, mert azt a hazat egy kicsit atalakitva belefert volna a ket hotswap cage (sot, meg tovabbi ketto is), aztan 4U600 nem volt sehol (azota sincs, kb. UK-bol lehetne rendelni), az Intel cage is EOL lett tavaly (nincs is utodja, mas iranyba indult a ceg). A tappal az a baj, hogy allandoan ugat miatta az alaplap, ill. bekapcsolasnal nem mindig indul elsore a gep (amikor egyszerre akar elindulni a jelenlegi 18db HDD az kicsit sok, es bar a tap birna, de az alaplap ugy latja hogy nem es suru anyazas (IPMI logba) es sipolas kozben kikapcsol...)

Szoval olyan hazat keresek, ami min. 16-24db 3.5"-os SATA/SAS hotswap fiokkal rendelkezik, hasznalni tudom a meglevo RAID kartyamat (vagy kompatibilis a hazba esetlegesen beepitett expanderrel vagy szerzek Intel RES2SV240 expandert), kepes rendesen meghajtani a drive LED-eket (most pl. nem csak aktivitast latok, hanem hiba eseten szep narancssarga lesz az adott drive LED-je; ebbol sem szeretnek engedni), tudok bele olyan (vagy annyi:) tapot rakni ami megbirkozik ennyi vinyoval (staggered spin up nincs, a desktop HDD-k maradnak, sot gyarapodnak...), es nem kerul 2000USD-be.
4-5U rack formatum preferalt, de felolem lehet torony is vagy barmi, igazabol nincs jelentosege.

A hazat (uresen) szeretnem max. 100k korul meguszni.

Amit eddig talaltam (Supermicro, Chenbro, stb) az nem ez a kategoria:/

Redundancia nem kell, nem kritikus cucc es ugysincs redundans betap:) Tappal az a baj, hogy az ossz fogyasztas nem sok (200W koruli ertek dereng, de regen mericskeltem), csak a bekapcsolasnal fellepo lorugast viseli nehezen:)
Hazbol amit lattam es tetszene az 350k (igaz ez mar kisker brutto), ezert kerdeztem, hogy van-e valakinek olcsobb javaslata:) Ha lenne meg jelenleg hasznalt expanderes cage-hez hasonlo cucc akkor egy 4U600 haz es egy kis barkacs megoldana a problemat fillerekbol, de nincs egyik sem, hogy rohadnanak meg.

Nekem ugy tunik, hogy a tap birja (birna), csak az alaplap finnyas.
Eloszor (meg joval kevesebb vinyoval) valami (szinten 'gagyinak' mondhato:) Enermax tappal probalkoztam, azzal pl. be sem lehetett kapcsolni. Az a tap azota is megy sima desktop lappal (C2Q procival, viszonylag eros VGA-val, 2-3 vinyoval, szoval valoszinuleg sokkal nagyobb terhelest kap mint ULV i3-mal, (akkor meg csak) 6-7 vinyoval kapott volna)

Hiaba, ezek a PC-k szepsegei.

Na, a hazra csak talaltam valamit:
http://www.norcotek.com/item_detail.php?categoryid=1&modelno=rpc-4224

Sajnos ez is csak Kulfoldisztanban kaphato, de az ar kb. stimmel (~400USD). A szallitast nem mertem megnezni, gondolom van vagy masfelszer annyi mint maga a haz:)
Enclosure management persze ebben {n|s}incs.

neha azert a kommenteket is erdemes megnezni...

Hello, this kind of backplane has been discontinued over 2 years. New version backplane can work well with 3TB or larger drives. If you have any problem with Norco products, please contact service@norcotek.com. Thank you!

ergo nem szamit, hogy regen elrontottak, hogyha mostmar kijavitottak.

az elmult par hetes tesztek es meresek eredmenye az, hogy ha vmware ala fogod hasznalni, nfs-el (ami sync writeokat csinal), akkor a szuk keresztmetszet a ZIL latencyje. egy samsung 840pro (256gb) kb 110mega/s -el tud szinkronban irni, es ennyi...

hazat en sem talaltam olcsobban mint kb 400k, ha talalsz, szolj ;-)

A power loss protection (hianya) miatt elegge orosz rulett. Nehany kesleltetes meresi eredmeny:

Samsung 840pro:
http://www.storagereview.com/images/samsung_ssd_840_pro_512gb_precondit…
http://www.storagereview.com/images/samsung_ssd_840_pro_512gb_precondit…

Intel S3700:
http://www.storagereview.com/images/intel_ssd_dc_s3700_preconditioning_…
http://www.storagereview.com/images/intel_ssd_dc_s3700_preconditioning_…

ioDrive2 Duo (slc - ez nem egy arkategoria):
http://www.storagereview.com/images/fusion_iodrive2_duo_slc_preconditio…
http://www.storagereview.com/images/fusion_iodrive2_duo_slc_preconditio…

( NagyZ v | 2013. 07. 01., h – 13:06 )

intel 520 eredmenyek, Jens Axboe ssd-steadystate.fio scriptjevel:

(egy LSI HBA-n van, SAS2-es porton sajnos, szoval csak 3Gbit/s) 


root@x:~# fio ssd-steadystate.fio 
sequential-fill: (g=0): rw=write, bs=1M-1M/1M-1M, ioengine=libaio, iodepth=16
random-write-steady: (g=1): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=32
...
random-write-steady: (g=1): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=32
2.0.8
Starting 5 processes
Jobs: 1 (f=1): [_w___] [99.8% done] [0K/169.7M /s] [0 /43.5K iops] [eta 00m:16s]    
sequential-fill: (groupid=0, jobs=1): err= 0: pid=13704
  Description  : [Sequential fill phase]
  write: io=228936MB, bw=254191KB/s, iops=248 , runt=922262msec
    slat (usec): min=57 , max=161 , avg=88.19, stdev= 8.42
    clat (msec): min=4 , max=120 , avg=64.36, stdev= 6.36
     lat (msec): min=4 , max=120 , avg=64.45, stdev= 6.36
    clat percentiles (msec):
     |  1.00th=[   63],  5.00th=[   64], 10.00th=[   64], 20.00th=[   64],
     | 30.00th=[   64], 40.00th=[   64], 50.00th=[   64], 60.00th=[   64],
     | 70.00th=[   64], 80.00th=[   64], 90.00th=[   64], 95.00th=[   69],
     | 99.00th=[  104], 99.50th=[  105], 99.90th=[  110], 99.95th=[  113],
     | 99.99th=[  118]
    bw (KB/s)  : min=230962, max=259576, per=100.00%, avg=254523.28, stdev=6784.71
    lat (msec) : 10=0.01%, 20=0.01%, 50=0.01%, 100=97.93%, 250=2.06%
  cpu          : usr=1.33%, sys=1.53%, ctx=232684, majf=0, minf=25
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=228936/d=0, short=r=0/w=0/d=0
random-write-steady: (groupid=1, jobs=4): err= 0: pid=13727
  Description  : [Random write steady state phase]
  write: io=909808MB, bw=137254KB/s, iops=34313 , runt=6787748msec
    slat (usec): min=1 , max=202 , avg= 6.53, stdev= 4.38
    clat (usec): min=370 , max=167539 , avg=3712.98, stdev=2978.15
     lat (usec): min=381 , max=167556 , avg=3719.86, stdev=2978.20
    clat percentiles (msec):
     |  1.00th=[    3],  5.00th=[    3], 10.00th=[    3], 20.00th=[    3],
     | 30.00th=[    4], 40.00th=[    4], 50.00th=[    4], 60.00th=[    4],
     | 70.00th=[    4], 80.00th=[    4], 90.00th=[    7], 95.00th=[    7],
     | 99.00th=[    9], 99.50th=[   13], 99.90th=[   45], 99.95th=[   66],
     | 99.99th=[  102]
    bw (KB/s)  : min=11840, max=174464, per=25.06%, avg=34389.73, stdev=8436.36
    lat (usec) : 500=0.01%, 750=0.05%, 1000=0.01%
    lat (msec) : 2=0.23%, 4=83.78%, 10=15.20%, 20=0.43%, 50=0.22%
    lat (msec) : 100=0.07%, 250=0.01%
  cpu          : usr=6.99%, sys=10.63%, ctx=203534882, majf=0, minf=560
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=232910950/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=228936MB, aggrb=254190KB/s, minb=254190KB/s, maxb=254190KB/s, mint=922262msec, maxt=922262msec

Run status group 1 (all jobs):
  WRITE: io=909808MB, aggrb=137253KB/s, minb=137253KB/s, maxb=137253KB/s, mint=6787748msec, maxt=6787748msec

Disk stats (read/write):
  sdi: ios=275/233366233, merge=0/1672, ticks=324/890319028, in_queue=892197916, util=100.00%
root@x:~#

( NagyZ v | 2013. 07. 06., szo – 14:29 )

az intel 520-bol kuldhetek is vissza egyet, mindossze kb 4TB iras utan...

Kingston-ok adatkapján rajta van egy TBW érték. Én V300-ast néztem ki SOHO cuccohoz, annak a 60GB-os verziójára emlékeim szerint 47 vagy 48TB-ot adnak meg. KC300-asnak meg 46,5TB-ot, ami a 875-höz képest elég karcsúnak tűnik.

A Samsung 840Pro mennyire vált be? Én majdnem mellényúltam, mert csak 840-es volt raktáron, aztán kiderült, hogy a sima 840-es TLC és nem MLC.
Amin még gondolkozom az a Kingston KC300-as, csak az adatai alapján nem tudom eldönteni, hogy "tud-e" annyival többet a V300-nál, mint amennyivel drágább.

igen, erre, koszi. bar mehetett volna nagyobb adatmennyiseggel is, mert igy meg cachelhet is a drive, de ez mar csak reszletkerdes.

osszefoglalom a tobbieknek (meg a guglinak):
4k random writera, elobb direct, utana sync:

lat (usec): min=25 , max=24682 , avg=65.67, stdev=138.20
WRITE: io=14015MB, aggrb=239179KB/s, minb=239179KB/s, maxb=239179KB/s, mint=60001msec, maxt=60001msec

lat (msec): min=2 , max=48 , avg= 9.11, stdev= 1.12
WRITE: io=105264KB, aggrb=1754KB/s, minb=1754KB/s, maxb=1754KB/s, mint=60001msec, maxt=60001msec

128k random write:

lat (usec): min=356 , max=30810 , avg=1223.04, stdev=802.10
WRITE: io=24472MB, aggrb=417633KB/s, minb=417633KB/s, maxb=417633KB/s, mint=60002msec, maxt=60002msec

lat (msec): min=1 , max=66 , avg=14.34, stdev= 2.90
WRITE: io=2085.2MB, aggrb=35585KB/s, minb=35585KB/s, maxb=35585KB/s, mint=60001msec, maxt=60001msec

1M random write:

lat (msec): min=3 , max=57 , avg= 9.69, stdev= 3.70
WRITE: io=24755MB, aggrb=422274KB/s, minb=422274KB/s, maxb=422274KB/s, mint=60030msec, maxt=60030msec

lat (msec): min=7 , max=78 , avg=30.16, stdev= 5.02
WRITE: io=7883.0MB, aggrb=134532KB/s, minb=134532KB/s, maxb=134532KB/s, mint=60002msec, maxt=60002msec

jol latszik ugyanaz a betegseg, ami nalam elojott: sync writenal egyszeruen meghal az egesz sebesseg, a latency meg megy az egekbe.

(leteszteltem egy fusion ioDrive2-vel is, ott ugyanazt az eredmenyt kapom sync nelkul, meg sync-el is, de nyilvan par az aruk kozott kb egy 20x-os szorzo)

( NagyZ v | 2013. 10. 20., v – 12:40 )

akkor dobjuk fel a topicot kicsit :-)

van valaki, aki esetleg full SSD kiepitesben (8x, 16x, 24x) rakott NFS-t VMek ala?

nezegettem a nexentat is, de igazabol akkora hely nem kell (~12TB eleg lenne), viszont a compression/dedup jol jonne, btrfssel meg nincs kedvem orosz rulettezni..

NFSen Nexenta nem ajánlja a storage szintű dedupot, csak a compressiont.....

más, kéne nekem 8GBit FC-n kiadni kb 10-15TB tárhelyet, inkább területre és peak io-ra számolva (mentések mennének rá), mit ajánlasz? vmi 24x 2,5" chassisban gondolkodom, SATA3 esetleg SAS diskekkel, ZIL es ARC cachenek 2x64GB és 1x 64GB SSD -vel...

szerk: pontosabban best prctice szerint ha nfsen adod oda VMWarenak akkor dedup off az adott volumeon

en mostanaban ceph orult lettem, az az igazsag, hogy nagyon tetszik, de nem tud se compressiont, se dedupot*, es minden alapbol mindent replikal, azaz fele annyi hellyel kell szamolni, viszont ha csak mentesek mennek ra, akkor 3TB-s diszkbol szerintem 20db nem draga :-)

a supermicro 24x2.5"-es doboza bejon, van a kezem alatt, gondolom a 3.5"-es dobozaik sem rosszabbak, mert bizony a 3T-s diszkekhez mar 3.5"-es chassis kell valoszinuleg.

*: mivel OSD-knek igazabol filerendszert hasznal (ill a diszk es a ceph-osd kozott ott az fs), igy ott be lehet kapcsolni mindkettot btrfs eseten pl, de en nem mertem eddig btrfst hasznalni :)

Na meghozták az első kecskék az árakat...
jelenlegi terv:

1x Supermicro SSG-6047R-E1R24L
2x Ivy Bridge 6C E5-2620V2 2.1G 15M 7.2GT/s QPI
8x 8GB DDR3-1600 2Rx8 1.35v ECC REG RoHS
18x SEAGATE 4.0TB SAS 6Gb/s 7.2K RPM 128MB 3.5" 512N
1x Qlogic QLE2560-CK Single 8Gbe FC

+ vmi SSD-vel megtámadni ZIL + ARCL2

Ja, hogy a LIO-ba is elkezdtek FC targetet implementálni?! Ez tök jó (insert random rant here about why LIO project was started in the first place, instead of simply merging SCST upstream).

Most már lassan akkor el kell kezdenem ezt a LIO dolgot kipróbálni, mert mindenki ezt nyomatja.
---
Régóta vágyok én, az androidok mezonkincsére már!