2013-ban volt egy hasonló téma (http://hup.hu/node/121509), de azóta eltelt majdnem 4 év, megjelent és kiforrottá vált az openzfs, egyre több OSben támogatott vagy alapértelmezett a ZFS, stb.
Nem rég kezdtem neki egy komolyabb tárolónak, ami terveim szerint ZFS+NFS-en szolgálna ki 5 Dell PowerEdge szervert, kb 400 GB memóriával és 40 fizikai processzormaggal.
Maga a vas egy Supermicro SuperStorage Server 5028R-E1CR12L, 64 gb memóriával, 8x2 TB HGST NL-SAS HDD-vel és 2x150 GB Intel S3520 SSD-vel.
Érdekelnének mások tapasztalatai, illetve a megvalósítási/üzemeltetési tapasztalatok. Mennyire vált be egy ZFS alapú tároló és mennyire stabil a zfs replication alapú mentés.
Az első komolyabb teszteket ubuntuval végeztem, de az OS nincs rögzítve (OmniOS-t és FreeBSD-t teszteltem még). Tesztcéllal, ubuntu 14.04 alapokon van egy HP szerverem 4x2 TB sata hdd+2 SSD, 32 gb ram, ami most a kevésbé kritikus gépeket osztja ki a szervereknek. Itt majdnem 1 év az uptime, és még semmi negatívumot nem tapasztaltam, ameddig a HDDk bírják szépen skálázódik a gép.
Update1:
Végül mint OS, az Ubuntu mellett döntöttem, mivel fontosabbnak tartottam azt, hogy gyorsan tudjak reagálni problémákra, mivel ezt jól ismerem, illetve ennél pontosan tudom, mit és hogy tudok monitorizálni.
Jelenleg 50 nap az uptime, 45 virtuális gépet szolgál ki a szerver, kb 3 TB adatot tárol, a grafikonok alapján kb 1600 IOps az átlagos terhelése, és percenként készül róla egy replika egy távoli tárolóra.
Hozzászólások
Nekem a 8db nl-sas keveskenek tunik :)
De kivancsi leszek meresekre.
Nalam jellemzoen a mentes veri oda igazan az io-t, azt nem tudom hogy gondoltad kivitelezni.
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"
zfs replikával mentesz?
Én most naponta 1x mentek és nem érzi meg a gép. Így egy snapshot 20-30 GB.
Az összes vm-et lehet nem fogja elbírni, de ha beválik akkor valószínű kerül mellé még egy legalább ilyen, és ketten egymás kiesését is lefedve már meg kellene bírkózzanak az összes vm-el.
xenservereken futo vm-eket mentek full mentessel (snapshot majd export).
ez egy md1200-as storage tele nl-sas diskkel, es erezhetoen szarrawait-el amikor elkezdek menteni egy nagy (1,5T) vm-et.
Inkabb a diskek gyengesegere probaltam utalni, nem is a zfs-re.
Nyilvan lehet az ssd cache dob rajta, kerdes mennyit :)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"
A kerdes a zfs snapshotra vonatkozott. Azzal mented?
Mint irtak tobben, annyira minimal terhelest okoz, h meg sem erezni. Nalam a backup szerer oldalan egy atom is elvinne, a storage szerver oldalan pedig olyan, mintha nem is lenne.
Ha tobbszor mentesz naponta, akkor ertelemszeruen fokozottan igaz, nincs ideje megerezni.
Ha a VM(-ek)ben sok valtozas volt, sokat kell lemasolni, akkor persze igen. De ritka, h vki ilyen stuffot VM-be rakna.
t
nem zfs :)
Eleg negativ tapasztalataim voltak vele, varok meg... :)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"
A ZFS mentés az különbözeti mentés, ami futhat akár óránként, vagy elvileg percenként is (ha valakinek rendes terhelés esetén van ilyen tapasztalata, megoszthatná). Ha óránként fut akkor elvileg pár GB adatnál nem kell többet menteni, tehát szinte nulla a mentés terhelése.
Én most 25 VM-et (nagyon vegyes: exchange, tomcat, web, mail, stb) futtatok zfs tárolón és azok napi 20-40 GB adatot termelnek, aminek a mentése pár perc és nem érezhető az IO-ban.
ez jol hangzik, de ha storagerol kell mentenem zfs-re, akkor mar mas a leanyzoo fekvese ha jol gondolom :)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"
Jól gondolod.
Ehhez maga a storage kell zfs legyen.
Mi két MD1000-et váltanánk ki evvel, és a banálisan egyszerű backup az egyik fő érv, amiért a zfs-re esett a választás.
Attól függ, mennyi a változás, mennyit mentesz. Nekem 10 percenként megy a ZFS repl., így a viszonylag kevés adatot különösebben meg sem érzi a szerver (Dell PR R510, 10x4TB WD RE SATA + 2x512 Samsung 850 Pro)
----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Milyen OS-t használsz?
16-os Ubuntu-t (és a tárolt guest OS-ek nagy része is az)
----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Ez a tema engem is foglalkoztat, de en nem VM-eket etetnek rola, hanem gyors eleresu NAS-t szeretnek ZFS Linux (ubuntu) alapon.
Jelenleg a 16.04 LTS verzio van hasznalatban, (probaltam FREEBSD-t /FreeNAS-t is), de en azota miota van ZFS a Linux kernelben azt jobban preferalom.
Nekem a halozattal meggyult a bajom, hiaba van jo hardverem nem tudok olyan gyorsan felszippantani a diskekrol fileokat.
Ha mar itt vagyunk inkabb NFS vagy SAMBA-n is erdemes probalkozom? Nekem most SAMBA -n van a share es nem igazan ertem mi bottleneck-el el.
macdroog
Az NFS-nek kisebb az overhead-je, mint a Samba-nak. Ha megírod, milyen hardvert használsz, kitalálhatjuk, hol lehet a bottleneck.
CPU(s)~2 Hexa core Intel Xeon X5680s (-HT-MCP-SMP-)
speed~3334 MHz (max)
Kernel~4.4.0-53-generic x86_64
Mem~14763.3/24100.4MB
Mobo: Supermicro model: X8DAH
A vezerlo >> ATTO Pciex8 6Gb/s ezen van 8x6tb Hitachi NAS HDD (RAIDZ2) 33TB
A masik vezerlo >> ATTO Pciex8 6Gb/s ezen van 4x512GB Samsung Pro (RAIDZ) 1.8TB
Halozat >> 2 port Myricom 10Gbe - ez most igazabol nincs hasznalatban
Halozat >> 2 port 40Gbe Mellanox kartya ami egy Mellanox Switchbe megy (sx1036) >> a kartya Pcie3-at ismer, de ezen a lapon csak Pcie2.0 van (5GT/s) aminek az elmeleti sebessege 4GigaByte/s, amibol en Iperf3-al csak 2GigaByte/s-t tudtam kicsikarni, aminek mar nagyon orulnek mert a diszk ami (SSD RAIDZ) az DD-vel 1.3GB/s-t tud olvasni..... ha ezt a sebesseget a 40Gbe-n tudnam mozgatni nagyon orulnek.
A sysctl.conf igy nez ki >>
######CUSTOM_00######
# allow testing with buffers up to 128MB
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
# increase Linux autotuning TCP buffer limit to 64MB
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
# recommended default congestion control is htcp
net.ipv4.tcp_congestion_control=htcp
# recommended for hosts with jumbo frames enabled
net.ipv4.tcp_mtu_probing=1
# recommended for CentOS7/Debian8 hosts
net.core.default_qdisc = fq
# recommended by performace experts to set net.core.optmem_max as in net.core.rmem_max and wmem_max
net.core.optmem_max = 134217728
Az smb.conf >>
[global]
socket options = TCP_NODELAY SO_RCVBUF=524288 SO_SNDBUF=524288 IPTOS_LOWDELAY
A kliens egy WIN10 gep szinten 40Gbe kartya ami a switchbe csatlakozik JUMBO FRAME mindenhol server-switch-kliens egy filetransfer sima wincopy elindul 1.3GB/s -el majd lemegy 500MB/s-re.
Kliens (64gb RAM, X99 chipset, sok lane-es cpu)
Az iperf3 a ket gep kozott 17-20Gbit/s en latja egymast. (ami 2GB/s) en ezt a sebesseget szeretnem, halozaton! :D
Ha a RAIDZ2 tombodrol olvasol akkor szerintem az 500 MB/s tartos olvasasi sebesseg teljesen jo.
--
http://blog.htmm.hu/
A RAIDZ2 (8x6tb HDD)-bol olvasasra kihoztam mar az 500MB/s-t halozaton, en az SSD-k (RAIDZ) olvasasi sebesseget szeretnem elerni, halozaton.
1.3GigaByte/s-el amire az elmeleti sebessegem adott, de sajnos a gyakorlat nem ezt mutatja.
Én kipróbálnám a 2xraidz felállást. Nekem kb 10%al gyorsabb volt ez mint a raidz2, és majdnem hasonlóan megbízható, ugyanakkor egyenletesebb a terhelése.
A compress-t a tárolandó adatok függvényében megint érdemes bekapcsolni, mivel gyorsabb a modern CPUval ki/be csomagolni az adatot, mint kiolvasni a lemezről, tehát ha van legalább 20% hatásfoka a tömörítésnek gyorsabb lesz az átvitel.
Szintetikus teszteken (fio, bonnie++) sikerült 1,3TB/s olvasási sebességet mérnem 160GBs tesztadattal, 2x4hdd raidz-ben, compress bekapcsolva.
Elvileg úgy az NFS mint a Samba is tud elég gyors lenni, de ennyi adat kiküldéséhez 10Gbps kell, én LACP-vel bondolom a 4 hálókártyát, ami a 2x1 Gbps HP szerverből kiindulva bőven elég lesz.
> sikerült 1,3TB/s olvasási sebességet mérnem 160GBs tesztadattal [...] de ennyi adat kiküldéséhez 10Gbps kell
Tenyleg?:)
ja...
1.3GB/s
Az meg mindig sok lesz, de kozelit:)
OmniOS-t en kifejezetten szeretem. Pici, handy, mukodik betonstabil.
A tombot illetoen:
* raidz-hez en 2^n+1, raidz2-hoz 2^n+2 db diszket hasznalnek.
* Az intel-eket zil-nek, vagy l2arc-nak tervezed hasznalni? Hint: hasznalj kulon zil-t es l2arc-t is. Kulon lemezekkel! egesz lemezt adj hozza, ne particionald!
* Erdemes a vezerlot IT modba tenni, es az illumos-ra bizni a raid megszervezeet
* valami kis pottomnyi ssd-re telepiteni az os-t. Vagy amire jol esik. Magyaran valaszd kulon a "tank" es az "rpool" funkciokat.
Ahh, most nezem, hogy ez a kis intel valami 40k koruli iops-t tud.
En zil / l2arc celokra inkabb valami nvme / pcie csatlakozasu brutal cuccost hasznalnek.
Vagy ezeket a kis intel vackokat az rpool-nak gondoltad?
Így utólag OSnek marad. Teszt közben jöttem rá, hogy nem biztos, hogy tud gyorsítani.
Mivel a hdd hely adott, én úgy képzeltem, hogy minden az ssdken van, az OS és a zil mirrorban és az l2arc stipe-ban, particiokon.
A zil és az arc kizárólag SSD-ken legyen. Ha HDD-re teszed, azzal éppen az értelmüket vesztik el. BTW FreeBSD és *Solaris rendszereken nincs (performance)hátrány abból, hogy partíciókra teszed a ZFS-t/zil-t/arc-ot.
Linuxon sincs, csak akkor kezzel kell noop-ra allitani.
Jó tudni, köszi.
A lenti példában, az sde,f,g deadline-on van:
/sys/block/sda/queue/scheduler:[noop] deadline cfq
/sys/block/sdb/queue/scheduler:[noop] deadline cfq
/sys/block/sdc/queue/scheduler:[noop] deadline cfq
/sys/block/sdd/queue/scheduler:[noop] deadline cfq
/sys/block/sde/queue/scheduler:noop [deadline] cfq
/sys/block/sdf/queue/scheduler:noop [deadline] cfq
/sys/block/sdg/queue/scheduler:noop [deadline] cfq
Nekem ezek az SSDk tehát ubuntu 16.04-en az SSD és usb flash default deadline-ra kerül.
Googli szerint a noop az a natív átvilelnél segít, még a deadline az IO-t gyorsítja. Ha így van, akkor a deadline tűnik nekem jobbnak cache esetén.
Azt szoktak mondani deadline v. noop....de igazabol papir szerint a noop kellene, h jobb legyen, mert a zfs-nek aztan sajatja van.
Eros a gyanum, h valojaban tokmind1.
Az világos, hogy SSD-re kell kerüljön, a kérdés csak az, hogy hogy oldjam meg.
A szerverbe 12 SAS (hdd) és 2 SATA (SSD) megy bele natívan és ennyi is van tervezve bele, tehát nincs több hely.
PCIExpress kártyával lehet még megoldani a cache-t, de az nem biztos, hogy belefér a keretbe/megéri-e.
A jelenlegi demó szervernél soha nem ment 1 GB fölé a ZIL tehát teljes disk biztos nem kell neki, a l2arc méretben lehet jó lenne ha 100 GBnél több lenne, de mint sebesség szintén a tesztszerverből kiindulva, elég kellene legyen a SATA SSD.
Az elmúlt 3 hónapban a maximális terhelés 1200 IOps volt, ami bőven az SSD maximuma alatt van.
BTW FreeBSD és *Solaris rendszereken nincs (performance)hátrány abból, hogy partíciókra teszed a ZFS-t/zil-t/arc-ot.
Azért ez így ebben a formában kicsit csúsztatás.
Ez amit írsz, csak FreeBSD-re igaz:
https://wiki.freebsd.org/ZFSTuningGuide
https://wiki.freebsd.org/ZFSTuningGuide#L2ARC_discussion
"The caveat about only giving ZFS full devices is a solarism that doesn't apply to FreeBSD. On Solaris write caches are disabled on drives if partitions are handed to ZFS. On FreeBSD this isn't the case."
Lásd még:
http://open-zfs.org/wiki/Performance_tuning#Whole_Disks_versus_Partitio…
"Whole Disks versus Partitions
ZFS will behave differently on different platforms when given a whole disk.
On illumos, ZFS attempts to enable the write cache on a whole disk. The illumos (nee Solaris) UFS driver cannot ensure integrity with the write cache enabled, so by default Sun/Solaris systems using UFS file system for boot were shipped with drive write cache disabled (long ago, when Sun was still an independent company). For safety on illumos, if ZFS is not given the whole disk, it could be shared with UFS and thus it is not appropriate for ZFS to enable write cache. In this case, the write cache setting is not changed and will remain as-is. Today, most vendors ship drives with write cache enabled by default.
On Linux, the Linux IO elevator is largely redundant given that ZFS has its own IO elevator, so ZFS will set the IO elevator to noop to avoid unnecessary CPU overhead.
ZFS will also create a GPT partition table own partitions when given a whole disk under illumos on x86/amd64 and on Linux. This is mainly to make booting through UEFI possible because UEFI requires a small FAT partition to be able to boot the system. The ZFS driver will be able to tell the difference between whether the pool had been given the entire disk or not via the whole_disk field in the label.
This is not done on FreeBSD. Pools created by FreeBSD will always have the whole_disk field set to true, such that a pool imported on another platform that was created on FreeBSD will always be treated as the whole disks were given to ZFS."
Találtam pár skriptet ami elég rendesen leterheli a rendszert:
https://github.com/zfsonlinux
A zfsstress pár perc alatt kibuktatja a ZFS. Ez magát a fájlrendszert stresszteszteli, úgy hogy dataseteket, fájlokat, linkeket, stb hoz létre töménytelen mennyiségben. Pár perc után egyszerűen eltűnik a pool és újra kell importálni. A system load ekkor 3 körül mozgott.
A filebench-el mind a 8 proci 100%on teker, a system load 60 köré is felmegy. Evvel már jól lehet követni, hogy viselkedik a rendszer terhelés alatt.
Sajnos a filebanch kihal a tesztprocessek elindítása után, de maga a terhelés nem áll le, csak ha kilövöm.
Kipróbáltam OpenIndiana-val is a teszteket. Itt már mindkét teszt tökéletesen működött de kb 5 perc zfssterss után itt is elszállt a pool (ubuntun kevesebb mint 1 percig bírta).
A filebench alatt kissebbnek tűnt a rendszer terhelése, mint linuxon, igaz a htop valamivel látványosabb és jobban követhető mint a top, és más monitorizáló tool-t nem ismerek solarishoz.
A top nem hogy nem Solaris eszköz, de nem is igazán ad valós képet rajta - ott a prstat szolgál erre a célra. (Nem nekromanciának szántam, talán még nem is minősül annak. :D)
------------------------
{0} ok boto
boto ?
sub
+1
sub
Van valakinek tapasztalata Linux(Debian Jessie)+ Xen+ Zfs (on linux) párossal?
Teszt rendszerben nézegetem, vannak néha furcsaságai.
Alap rendszer mdadm+LVM. Első körben próbáltam az alap rendszert is zfs-re, de nem igazán ment zökkenőmentesen.
A virtualizált gépeket szeretném rájuk rakni(SSD LOG, cache és snapshot miatt).
Nem igazán találok doksit, teszteket róla.
Mi most kezdtünk egy ilyen projectben.
Storage debian8 zfsonlinux
zvol -- iscsi --- xen domU
30 nap alatt nem volt probléma.
DE még nem sok éles szolgáltatás fut rajta.
Bocsanat toletek, de eles kirnyezetbe mindenkit tavoltartanek ettol.
Ha mar sok vm fut egy cegben akkor meg kell tudnia venni egy megfelelo infrastrukturat, nem kifizethetetlen egy dell md das + 1-4 barmilyen host. Ha meg ez keves akkor eleg fontos es terhelt egy komolyabb tarolora is.
Egy ilyen rendszernek az a lenyege, hogy az altalad emlitett "megfelelo" infrastrukturat csinalja meg, esetleg jobban, mint a "komolyabb" tarolo.
Plz a sajat tudatlansagodat (bizalomhianyodat?) ne tedd egyenlove azzal, hogy a fenti rendszer nem az.
Egeszen komoly cegek vannak, akik zfs-re epulo "komolyabb" tarolokbol elnek, sot akar dobozos termeket allitanak ossze.
Sot, azt is mondhatnank, h kabathoz a gombot es ne forditva, azaz fingod nincs, mennyit er az eles kornyezet es mit er meg ala rakni.
Valamint nem mellesleg a kezzel osszerakott ugyanugy szet tud esni, mint a dobozos csilivili.
Tehat kijelenteni ennyi info alapjan a fentieket meresz, sot demagog.
"Egy ilyen rendszernek az a lenyege, hogy az altalad emlitett "megfelelo" infrastrukturat csinalja meg, esetleg jobban, mint a "komolyabb" tarolo."
Igen, otthon én is meg fogom csinálni, magamnak és lesz egy nagy tudású tárolóm otthon ami vagy megy vagy nem.
Semmi gond. Te vállalod a felelősséget, hogy egy Debian + linuxonfzs majd működni fog garantáltan. Elemben a " zfs-re epulo "komolyabb" tarolok" nál van támogatás és van aki hibát keres és megoldhat.
"Plz a sajat tudatlansagodat (bizalomhianyodat?) ne tedd egyenlove azzal, hogy a fenti rendszer nem az."
Egy Deboan + zfsonlinux lehet hogy stabil és jó, de akkor sem tenném rá egyetlen ügyfelem vagy kollégám éles adatát sem produktív környezetben főleg ha az MDADM meg LVM kevés. Sajnos a hup is tele van a titkárnő levedlett szarján történő reszelős ámokfutásokkal mint server üzemeltetés.
>Sajnos a hup is tele van a titkárnő levedlett szarján történő reszelős ámokfutásokkal mint server üzemeltetés.
nembeszól az excess heat hasznosítás projectre
Azt a k.rva. :D
jövőre a krumplitároló salgóba fogom beépíteni, nehogy elfagyjon az ennivaló
Hatalmas +1. A zfsonlinux megbízhatóságával kapcsolatos problémákról még a topiknyitó is írt.
Ezt a teszteredményem közben többé-kevésbé megcáfoltam:
http://hup.hu/node/150883#comment-2069855
Oké, a zfs githubos issue trackerén azonban jelenleg ~838 nyitott issue van, köztük néhány memory leak. Nekem ezek alapján a linuxos ZFS fork (zfsonlinux) még nem tűnik production ready-nek.
> Semmi gond. Te vállalod a felelősséget, hogy egy Debian + linuxonfzs majd működni fog garantáltan. Elemben a " zfs-re epulo "komolyabb" tarolok" nál van támogatás és van aki hibát keres és megoldhat.
Nalatok arrol szol a munka, kire lehet kenni a felelosseget?
Fasza lehet:)
> Egy Deboan + zfsonlinux lehet hogy stabil és jó, de akkor sem tenném rá egyetlen ügyfelem vagy kollégám éles adatát sem produktív környezetben főleg ha az MDADM meg LVM kevés. Sajnos a hup is tele van a titkárnő levedlett szarján történő reszelős ámokfutásokkal mint server üzemeltetés.
Vilagos, h te nem tudnad megcsinalni. De aki meg tudja, az miert ne tehetne? Miert lesz rossz az a megoldas, ha egyebkent helyes a kivitelezes?
Tekintsunk el attol, hogy mennyien ganyoljak ossze az ilyet es mennyien csinaljak valoban jol. Az elvrol beszelek.
De mondok egy egeszen konkret peldat. A te hozzaallasoddal ki lehet dobni a glusterfs-t es a ceph-et is (sok egyeb hasonlo termek mellett) a kukaba. Mert nem dobozos "rendes" storage.
Jobb, ha lehuzzak a rolot.
Sot mitobb, emlekszem az idore, amikor a te mentalitasoddal tamadtak a linux usereket a windows-zal ellenben:)
+rengeteg!
De azért te is el tudod képzelni (és el tudod fogadni), hogy vannak olyan helyek, ahol a te tákolt (egyébkény zsír cool!) ZFS-es kutyafaszáddal körberöhögnének?
--
trey @ gépház
A HUP ilyen.
Mervado:P
Esetleg irtam olyat, hogy a ZFS-sel kezzel osszerakott stuff az ultimate megoldas oregapad aranyerere is?
Továbbra sem javaslom a Debian + zfsforlinux használatát éles környezetben VM-ek alá mert túl nagy a kockázata és mivel minden free, jó eséjjel max forum support van hozzá, igaz, az uis megoldás lehet.
Akkor inkább javaslok egy free Hyper-V-t vagy kulcsolt ESX-et.
Neked úgy látszik az aranyered a nyakadra tekeredett.
Lehet, hogy személyes sértésnek érzed, hogy nem javasoltam azt ami neked a szíved csücske, de okkal tettem és nem azért, hogy Te ne használd vagy rossz ha használod. Azt teszel a rád bízott adatokkal amit akarsz. Teheted zfsforlinux-ra is.
> Továbbra sem javaslom a Debian + zfsforlinux használatát éles környezetben VM-ek alá mert túl nagy a kockázata
Ez hasbol jott vagy csinaltal ra teszteket stb.?
> és mivel minden free, jó eséjjel max forum support van hozzá, igaz, az uis megoldás lehet.
Mint sok free megoldasra, erre is lehet vasarolni supportot jo penzert. Kulonben nem erne meg fejleszteni. Ez az uzleti modell:)
> Akkor inkább javaslok egy free Hyper-V-t vagy kulcsolt ESX-et.
Komolyan? ESX-et hasznalnal storage megoldasnak VM-ek ala?
> Lehet, hogy személyes sértésnek érzed, hogy nem javasoltam azt ami neked a szíved csücske
Bar a szivem csucske a zfs, de ehhez koze nincs. Minden ceco nelkul lemondok rola, ha nem alkalmas a feladatra. Meg(?) sok ilyen van. Lehet idovel kevesebb lesz.
> de okkal tettem és nem azért, hogy Te ne használd vagy rossz ha használod. Azt teszel a rád bízott adatokkal amit akarsz. Teheted zfsforlinux-ra is.
Igen, az okokat szeretnem olvasni. A nem "alkalmas", nem "rendes" es tarsai onmagukban lofaszt ernek. Egy mernok odairja, mi alapjan jutott erre. Mindenekelott egy mernok mer. Toled nem olvastam olyat, hogy a gyakorlatban megnezted volna, mi a helyzet.
En ezt ugy irom, hogy hasznalom naponta es gyakorlati tapasztalatom van vele. Ezen kivul osszehasonlitasi alapnak van dobozos storage tapasztalatom, meg mdraid es lvm tapasztalatom is van.
Mindezzel egyutt sem mondanam ra, h alkalmas, mert fogalmam nincs a kliens oldali igenyekrol, de nem vagom ra vaktaban, h arra nem alkalmas.
Szeretnem latni, hogy te mi alapjan irtad ezt. Kulonosen mivel masok beirtak, hogy hasznaljak igen hasonlo kornyezetben, viszonylag hosszabb ideje es hozza az elvarhatot.
> Komolyan? ESX-et hasznalnal storage megoldasnak VM-ek ala?
lehet elment melletted a vilag, de remelem azert hallottal mar a vSAN-rol...
> Ezen kivul osszehasonlitasi alapnak van dobozos storage tapasztalatom
abbol sem valami high-end (a sajat bevallasod szerint valami dzsunka Promise meg valami low-end HP, ha jol emlekszem), ebbol nem erdemes messze meno kovetkeztetest levonni...
> Igen, az okokat szeretnem olvasni.
ok, akkor par ok:
- nem hiszem, hogy van in-house expertisetek debuggolni egy komolyabb ZFS hibat (ha szerinted igen, en attol ezt meg egy hangyani ketelkedessel fogom fogadni...)
- nem hiszem, hogy a barominagy (= ertsd random kernel random disztribbel) "support matrix"-ot barki is tudja rendesen tamogatni, akar penzert is
- ha epp bedolne, akkor lehet, hogy van support, viszont nem biztos, hogy 0-24 fel tudom hivni oket es _MOSTAZONNAL_ foglalkoznak az en problemammal, mert all a ceg
- csudaszep ez a zfsforlinux, es en is hasznalnam bizonyos esetben (scratch space, mondjuk 48x NVMEs driveon, 100GbE-n), viszont skalazni mar nem tudod
- az egesz dobozod egy SPOF, nem tudsz tobbszorosen aktiv-aktiv rendszert epiteni belole (FIXME, a Nexenta meg egyeb takolt megoldasok max HA-t tudnak aktiv-aktivval, az angol ceg aki tolja, es elfelejtettem a nevuket meg eleg fapadosnak tunik egyelore)
- senki nem beszelt itt sebessegrol, ha nem scratch-spacenek hasznalja az ember, akkor a sebesseg csak _masodlagos_ tenyezo, az elso a megbizhatosag
> lehet elment melletted a vilag, de remelem azert hallottal mar a vSAN-rol...
Elfogadom, megoldhato vele.
> abbol sem valami high-end (a sajat bevallasod szerint valami dzsunka Promise meg valami low-end HP, ha jol emlekszem), ebbol nem erdemes messze meno kovetkeztetest levonni...
Idejott a masik tudos.
Hihg-end storage mihez? Kabatot a gombhoz?
> - nem hiszem, hogy van in-house expertisetek debuggolni egy komolyabb ZFS hibat (ha szerinted igen, en attol ezt meg egy hangyani ketelkedessel fogom fogadni...)
Nincs tobb, mint barmilyen komolyabb storage hibat debuggolo expertunk.
Se windows, linux es meg sorolhatnam tovabb.
> - nem hiszem, hogy a barominagy (= ertsd random kernel random disztribbel) "support matrix"-ot barki is tudja rendesen tamogatni, akar penzert is
Megint a rendes szon van a hangsuly. Ezen kivul felhoztal olyan peremfeltetelt onkenyesen, ami amugy erthetetlen (random disztrib, random kernel)
> - ha epp bedolne, akkor lehet, hogy van support, viszont nem biztos, hogy 0-24 fel tudom hivni oket es _MOSTAZONNAL_ foglalkoznak az en problemammal, mert all a ceg
Futtyfurutty, hogy jon ide a mostazonnal? A kiscsako nem irt 1 perces SLA-rol.
> - csudaszep ez a zfsforlinux, es en is hasznalnam bizonyos esetben (scratch space, mondjuk 48x NVMEs driveon, 100GbE-n), viszont skalazni mar nem tudod
Honnan hova nem tudom? Szukseg van a skalazasra? Mi a project celja?
Te onceluan a storage kedveert csinalsz storage-okat, vagy van celja?
> az egesz dobozod egy SPOF
Abszolut igaz. Mar csak az a kerdes, hogy van-e masra szukseg...:)
> - senki nem beszelt itt sebessegrol, ha nem scratch-spacenek hasznalja az ember, akkor a sebesseg csak _masodlagos_ tenyezo, az elso a megbizhatosag
Senki, akkor te miert hoztad be?:)
> Hihg-end storage mihez? Kabatot a gombhoz?
az isteni tompos kinyilatkoztatas az a topicban, hogy a zfs jo mindenre, es korberohogted azt, aki azt mondta, hogy vannak helyek, ahova meg "igazi" storaget vesznek. ettol ugy veltem, hogy mar altalanossagban beszelgetunk, nem a topicinditorol...
> Nincs tobb, mint barmilyen komolyabb storage hibat debuggolo expertunk.
egy brand storagon nincs mit debuggolni, vagy megy, vagy nem, ha nem, felveszed a telefont, es felhivod a gyartot
> Megint a rendes szon van a hangsuly. Ezen kivul felhoztal olyan peremfeltetelt onkenyesen, ami amugy erthetetlen (random disztrib, random kernel)
miert, a linuxonzfs projektnek van hivatalos support matrixa hogy csak ezen a disztrin csak ezt a kernelt tamogatjuk?
> Futtyfurutty, hogy jon ide a mostazonnal? A kiscsako nem irt 1 perces SLA-rol.
megint altalanossagban beszeltem, nem a kiscsako problemajarol, mint ahogy ez a sub-thread errol szol (szerintem)
> Honnan hova nem tudom? Szukseg van a skalazasra? Mi a project celja?
> Te onceluan a storage kedveert csinalsz storage-okat, vagy van celja?
ha tudod, hogy soha nem lesz annyi adatod, hogy kelljen skalazni, akkor jo ez a hozzaallas, de ha pl tolem kernek a felhasznalok 200TB storaget akkor itt siman elkepzelheto hogy masnap kernek meg 200-at...
> Abszolut igaz. Mar csak az a kerdes, hogy van-e masra szukseg...:)
altalanossagban elmondhato hogy a joskapista cegeken kivul van szukseg arra, hogy legalabb egy memoriahiba miatt ne alljon meg az egesz.
> Senki, akkor te miert hoztad be?:)
te hoztad be a topic masik reszeben, en csak reagaltam ra.
> az isteni tompos kinyilatkoztatas az a topicban, hogy a zfs jo mindenre
Idezz vagy kussolj.
> egy brand storagon nincs mit debuggolni, vagy megy, vagy nem, ha nem, felveszed a telefont, es felhivod a gyartot
Nalatod, vagy mukodik, vagy nem:)
Ha nem, baszhatod ugyanugy. Az adatot is meg mindent. Aztan vakarja a HP mernok a fejet egy napon at, elmegy, visszajon meg izzad egy kicsit, majd feladja. Volt ilyen.
Lehet tesztelni a backupot.
> korberohogted azt, aki azt mondta, hogy vannak helyek, ahova meg "igazi" storaget vesznek. ettol ugy veltem, hogy mar altalanossagban beszelgetunk, nem a topicinditorol...
Megintcsak kerem, hogy idezz. Nem irtam ilyet. Esetleg mondatertelmezesi problemad van.
> miert, a linuxonzfs projektnek van hivatalos support matrixa hogy csak ezen a disztrin csak ezt a kernelt tamogatjuk?
Egeszen vadbaromsagokat tudsz beirni.
Te hasznalj random kernelt, mas meg nem randomot.
Windows megmondok beszeltek igy 10-15 evvel ezelott. Konkretan ugyanezeket a suletlensegeket hoztak fel.
Oszinten bele akartok menni egy disztribhaboruba? Az enyem jobb:)
> ha tudod, hogy soha nem lesz annyi adatod, hogy kelljen skalazni, akkor jo ez a hozzaallas, de ha pl tolem kernek a felhasznalok 200TB storaget akkor itt siman elkepzelheto hogy masnap kernek meg 200-at...
Eltevedtel, ez a topic nem 200TB-rol szol. Meg a tizederol sem.
> altalanossagban elmondhato hogy a joskapista cegeken kivul van szukseg arra, hogy legalabb egy memoriahiba miatt ne alljon meg az egesz.
Irgalmatlan nagy cegek mukodnek ennel joval gyatrabb rendszereken. Mukodtek regen is, amikor ezek a technologiak meg ismeretlenek voltak.
A desktopokon pl. meg mindig nem terjedt el az ECC, pedig az egy valodi SPOF.
> te hoztad be a topic masik reszeben, en csak reagaltam ra.
Kezdem azt hinni, h nekem tulajdonitottal vki mas hozzaszolasat.
En ebben a threadben nem irtam le ezt a szot.
ugy latom kar barmennyi energiat is beled fektetni, menj, homokozz a jatszotereden, majd az elso adatvesztesnel azert kivancsi lennek a fejedre, csak azt sajnos mar nem jossz majd a hupra reklamozni :(
"Idezz vagy kussolj!"
tompos (C) (TM)
Szerintem az esetek többségében, a fentiekben is, létezik pénzügyi plafon. Én is ezért döntöttem egy ilyen megoldás mellett éles környezetben, mert a hibalehetőségek kockázatának anyagi vonzata kisebb mint egy brand tároló ára, illetve nekem fontosabb volt az, hogy legyen folyamatos mentésem bevállalva pár óra leesés kockázatát, mint szinte 100% uptime, de egy hiba esetén amire mindig van esély, egy totális adatvesztés, amit csak nehézkesen heket alatt lehet backupból visszaállítani.
Minden megoldásnak megvan a helye, pl. egy bank éles adatainak tárolására már nem valószínű, hogy tákolt megoldást választanék, ugyanakkor egy 10 fős minicég fájlszerverének nem valószínű, hogy bármi 2000 eurót meghaladó megoldáson gondolkodnék.
Nem hiszem, hogy az a lényeg, hogy production környezetben használsz ilyen megoldást, hanem az, hogy kielégítse az adott környezet igényeit, figyelembe véve a kockázatokat.
Eléggé hitvita alakult ki ismét.
++++ Ákos.
* Nalatok arrol szol a munka, kire lehet kenni a felelosseget?
Nem. De vannak vállalások, órákkal, úgy hívják SLA és ha valami nem működik mert hekkelés van akkor valakik nem tudnak dolgozni és egy hobbiprojekt esetén nem tudsz még fizetős támogatáshoz sem nyúlni. Nem nyúlunk, de nem maradhatunk zsákutcában, kell tudni valakit mindig hívni, minden esetben el kell tudni jogilag leírt módon a szoftver fejlesztőjéhez ha kell. Nem kell, de ha valami dokumentáción kívülre kerül azt nem tudjuk üzemeltetésből megoldani.
* Vilagos, h te nem tudnad megcsinalni. De aki meg tudja, az miert ne tehetne? Miert lesz rossz az a megoldas, ha egyebkent helyes a kivitelezes?
Tekintsunk el attol, hogy mennyien ganyoljak ossze az ilyet es mennyien csinaljak valoban jol. Az elvrol beszelek.
Igazából bekaphatod.
Tehetné és tegye, azt javasoltam, hogy ne csinálja, mert ebben történetben annyi az ismeretlen tényező ami nem biztos, hogy megéri a kockáztatást, de lesz a hupon még egy szál hogy a szarom összefosta magát egy áramszünet után és mindenki ideges mer lespórolták a mentést.
* ...
"glusterfs-t es a ceph" mindkettőt RedHat vagy SLES termékben mindenkinek ajánlom. Ez a jövő és a jelen is. Egyiket sem használom, csak ismerem és próbálgattam. Ezekkel ne keverd össze Debian + zfsforlinux párost, nem egy liga és nem is egy környék. Inkább bort kólával keverj.
Az én mentalitásom, hogy az informatikai eszközök a reál gazdasági tevékenység támogatására jöttek létre és arra is kell használni. Minden meg kell tenni, hogy a lehető leghatékonyabban segítse elő a vállalat alapvető tevékenységét, teljesen mindegy, hogy az milyen OS és ki férhet hozzá a forráskódhoz.
A Te mentalitásodnak megfelelő hekkmesterek tömegei után pucoltam már ki rendszereket és migráltam leírt módon üzemeltethető infrastruktúrára, ami mindig azzal kezdődött, hogy meg kellett fejteni, hogy mit és hova is okoskodtak ki majd, minden szarukat egy raklapra tettem és toltam el a hulladéklerakóba.
Azért mert más nem használ egy megoldást az a legkisebb eséllyel van azért mert az a megoldás zseniális, inkább okkal nem használják. Nyugi, vannak nálunk okosabbak sok témában.
Zfs-t a zfs boltból, ne az ext boltból vegyetek és nem lesz baj.
> Nem. De vannak vállalások, órákkal, úgy hívják SLA és ha valami nem működik mert hekkelés van akkor valakik nem tudnak dolgozni
Ismered a fent szereplo ceget, hogy milyen SLA-t igenyel?
I/N valaszt irj, leccike.
> egy hobbiprojekt esetén nem tudsz még fizetős támogatáshoz sem nyúlni.
Hobbiprojekt:D
Kabare, amit irsz:P
Nem nyúlunk, de nem maradhatunk zsákutcában, kell tudni valakit mindig hívni, minden esetben el kell tudni jogilag leírt módon a szoftver fejlesztőjéhez ha kell. Nem kell, de ha valami dokumentáción kívülre kerül azt nem tudjuk üzemeltetésből megoldani.
Aztakurva. Mar megint a joghoz ertel el. Te azt lesed, h kire lehet kenni a felelosseget. Egy olyan kornyezetben, ahol nem ismered a peremfelteteleket.
> Tehetné és tegye, azt javasoltam, hogy ne csinálja, mert ebben történetben annyi az ismeretlen tényező ami nem biztos, hogy megéri a kockáztatást, de lesz a hupon még egy szál hogy a szarom összefosta magát egy áramszünet után és mindenki ideges mer lespórolták a mentést.
Mar a mentesnel meg _NEM_ letenel tartasz, pedig meg csak a futtatasnal tartunk:D
Bar megjegyzem, a mentes az, ami kurvaegyszeru lesz ebben az esetben.
Reagalva a fentire. Mennyi az ismeretlen tenyezo. Mielott atveszed te a projektet a fenti huppertol, megallapithatjuk, hogy te vagy AZ ISMERT es remelhetoleg megbizhato TENYEZO?
Neked azert lehet hinni, remelem. Vmi etalonbol ki kell indulni. Ha neked nem, a Dell-nek, HP-nak lehet? Az ugy van? Ha ok elbasznak, milyen karteritest fogsz kapni?:)
> mindkettőt RedHat vagy SLES termékben mindenkinek ajánlom.
Baszki, most esik le, h itt szimpla Debian utalatrol van szo:)
> A Te mentalitásodnak megfelelő hekkmesterek tömegei után pucoltam már ki rendszereket és migráltam leírt módon üzemeltethető infrastruktúrára, ami mindig azzal kezdődött, hogy meg kellett fejteni, hogy mit és hova is okoskodtak ki majd, minden szarukat egy raklapra tettem és toltam el a hulladéklerakóba.
En meg a tefajta megmondoemberek utan szoktam takaritani:)
> Zfs-t a zfs boltból, ne az ext boltból vegyetek és nem lesz baj.
A fentiekbol mar vilagos. Te nem a hekkmestereket, hanem az innovaciot iteled el.
Rohog a vakbelem.
Nezd te egy olyan kornyezetben dolgozol, ahol osszerakjatok a dobozos termekeket. Megtanulod az hogyant a treningen, leveszed a polcrol, a betu szerint osszerakod.
Aki nem tudja kifizetni, az szamodra nem erdemes az eletre (jobb esetben johiszemuen elhajtod mashoz).
Nincs vele gond, millio ilyen hely van, ahol erre van szukseg.
De kerlek fogadd el, hogy vannak mas, a tiedtol eltero, sikeresen mukodo megoldasok is. Frusztral v. nem, ez a helyzet. VAN, aki meg tudja csinalni.
Azt furcsállom, hogy miért bántja mások lelkét, ha valaki mást használ, mint Ők.
Felteszek egy kérdést gyakorlati megvalósításról, erre a válaszok x%-a: "miért azt a szart használod", "kókányolsz", stb, stb.
Nem lehetne olyan fórumrész, ahol az olyan "reszelős", "gányolós", semmihez nem értő, rendszertelen gazdák beszélgethetnének(mint én), a nem támogatott nem hardveres raid támogatásra épülő sufni rendszerekről?
Ahova a mindenkinélmindentjobbantudok emberek nem irkálnak!
Elfogadom, hogy van megagigaextraenterprise rendszer, de én nem ebben a körben mozgok.
Mindeközben picit feljebb.
Ahogy irtam, nekem szart be dobozos storage is epp elegge (HP), de hasznaltam/hasznalok legajjabb dobozos storage-it, amire kevesebbet se biznek meg a kaki.hu tartalmat (promise...bar latszolag mukodik, igaz anno VM-ek ala vettek, arra szar)...stb.
Nem tudok csatlakozni a hozzaszolashoz. Nekem mukodik, sok masoknak mukodik. Semmitobbet nem tudok elmondani.
Ha ezt te ki tudod vitelezni az ügyfeleidnél, akkor jó helyen vagy.
Sokkal egyszerűbb dolgom lenne, ha nem nekem kellene a rendszert "reszelni", hanem veszek x nast és szervert és minden redundáns.
Ha probléma van vele, akkor gyári support és elvileg megoldják(elvileg).
Nem kellene éjszakákat tölteni doksi kereséssel, online tanfolyammal, rendszer tesztekkel.
Errefelé egy 10 fős iroda nem engedhet meg magának ilyen beruházást.
Örülök, ha 3 évente diszkeket, 5 évente gépeket tudok cserélni.
Ha esetleg már van második szerver, ahol mentések megvannak még 1 példányban, van valamennyi redundancia, akkor elértem a maximumot.
A 100 000-200 000 körüli nasokban pedig nem bízom. Inkább Microserver mdadm raid1+ LVM.
Visszatérve. Zfs mint elgondolás, funkciók, sebesség tetszik. Ha tudja teljesíteni, amire tervezték, lassan be fogom rakni a cégeknél. Ez viszont még kb. 10 hónapig nem fenyeget.
Addig kell tesztelni.
A ZFS idén 12 éves. Tudja, amit kell, maximum a portjai és a felhasználói nem tudják.
------------------------
{0} ok boto
boto ?
Nagyon sajnálom a magyar valóságot. Tényleg. Nyomor hegyén hátán, de ezt most nem kavarom tovább.
A 10 fős iroda szerintem fizessen elő felhőben vagy nyomjon kevesebb szolgáltatást vagy vegyen legalább 1 nem hókolt vasat. A régi 8 éves szerver havi átlagos üzemben tartása együtt jár 20k villanyszámlával, az admin óradíjával remélhetőleg, a mentéssel ami már néha több mindennél de még egy garanciális vasnál is. Nem is kérdezem, meg hogy ott van-e ups és az képes-e leállítani a host-ot ami képes-e szabályosan leállítani a futó vm-eket.
Tudom, hogy a szarevés az egyik legnagyobb hungarikum és a tco egy ismeretlen fogalom, de sokszor amikor leírtam, hogy mennyibe kerül a vagy b lehetőség akkor rögtön, néha sikerült észhez téríteni sokakat. Igaz a friss X5-re mindig volt új gumara 500k évszakonként ezeken a helyeken.
"A 100 000-200 000 körüli nasokban pedig nem bízom. Inkább Microserver mdadm raid1+ LVM. "
Megértem, ne is tedd. Egyik nagyobb szar a másiknál.
"Visszatérve. Zfs mint elgondolás, funkciók, sebesség tetszik. Ha tudja teljesíteni, amire tervezték, lassan be fogom rakni a cégeknél. Ez viszont még kb. 10 hónapig nem fenyeget."
Egyetértek azzal, hogy tényleg olyan funkcionalitással rendelkezik ami miatt érdemes elővenni és használni.
Az az én véleményem, hogy nem tenném rá senki VM-jeit azért mert lassú egy jelenlegi rendszer.
+sok
Megértem, látok én is kókány megoldást, ezt akarom elkerülni.
11 éve ügyfelem, nem volt még nem tervezett leállásuk. Szerver részen megfelel neki a linux és a szolgáltatásai.
A jelenlegi rendszer nem lassú, de a zfs(onlinux) "tényleg olyan funkcionalitással rendelkezik ami miatt érdemes elővenni és használni."
>Inkább Microserver mdadm raid1+ LVM.
--($:~)-- mdadm -V
mdadm - v2.6.4 - 19th October 2007
--($:~)-- ./mdadm -V
mdadm - v1.9.0 - 04 February 2005
--($:~)-- mdadm --manage /dev/md2 -a /dev/sdb2
mdadm: cannot find valid superblock in this array - HELP
--($:~)-- ./mdadm --manage /dev/md2 -a /dev/sdb2
mdadm: hot added /dev/sdb2
O.K.!
Én egy gépen szeretném megoldani.
Image-file-lal már megy a DOMU, viszont közvetlen akarom kiajánlani a DOMU-nak a poolt, mint pl. egy lvm logikai kötetet.
Erre nem találok igazán semmi doksit.
Lehet nem jó fórumtémát folytattam, mert nem csak a ZFS Storage tapasztalatok érdekelnének.
zvolt szeretnél alátenni nem ?
bocsi, igazad van
zvol
Mi kb 1 éve kezdtünk zfs-t használni egy HP ProLiant ml310e szerveren ubuntuval. Kb. 9 hónapig futott kísérleti szerverként, kb 15-25 virtuális gépet kiszolgálva nfs-en.
Ezt egy supermicro storage szerver váltotta, ami most 40 gépet oszt ki nfs-en vmware-nek, és szintén hibátlanul működik. Ezen a root is zfs-en van, a hp-n csak a storage rész volt zfs-en.
Elrontottad.
Esetleg a kepzeleted szulemenye:) A biztonsag kedveert a bizonyitekot is te szolgaltatod ugyanebben a threadben. A fellebbezesnek helye nincs!
Nem igazán értelek. Tény, hogy a válasz megírása után olvastam el a témafelvezetést és jöttem rá, hogy én kezdtem a threadet, és ezért érdekesen hangzik a hozzászólásom, amiben részben ismétlem a fő bejegyzésem, de a többi stimmel...
Vagy mit kellene elképzeljek?
Ironizaltam es erre ill. a felette levo hozzaszolasokra reagaltam:
http://hup.hu/node/150883?comments_per_page=9999#comment-2069721
Bocs, nem tamadtalak teged.
Nem kell ám, most besértődni! Nekem is vannak tákolt storage-aim, amik évek óta teszik a dolgukat problémamentesen. De azt is tudom, hogy vannak helyzetek és helyek, ahova ha ilyennel be akarnál állítani, az árajánlat fázisban kibasznának mint macskát szarni. Én elhiszem, hogy te ezen heherészel. Ettől még ez tény.
--
trey @ gépház
Es a fenti hely ilyen? Vagy mit szeretnel kozolni?
Ha a fenti ilyen, akkor bocs, felreertettem vmit.
én az emlékezetes "brand gépbe csak brand hdd-t!" elvednél ragadtam le, azóta van új?
"elvednél"
Hízelgő, hogy nekem tulajdonítod vezető gyártók ajánlásait, előírásait, de azért ez kicsit túlzás.
"elvednél ragadtam le, azóta van új?"
Nem, nincs, bár nem tudom, hogy ez hogyan jön ide.
--
trey @ gépház
>nem tudom, hogy ez hogyan jön ide.
látod én is pontosan ezt gondoltam amikor megláttam a threadben hogy "trey", meg ezzel egyidőben felrémlett a brand-marhaság
Ja, azt hittem lesz valami érv is, de csak a semmi.
--
trey @ gépház
+
Talán megvan mire gondolsz..., de nem látok ellentmondást.
A zfsstress-el ki lehet fektetni valamit aminek az eredménye a pool lecsatolása, de ez egy speciálisan a zfs kinyírására fejlesztett szkripthalmaz. Sem éles sem tesztkörnyezetben normál használatot szimulálva nem sikerült egyszer sem kifektetni a tárolót.
Soha nem néztem utána, hogy mi okozta konkrétan a pool eltűnését, mivel nem volt kedvem több ezer sor log-ot átolvasni, de átnézve a kódot, talán meg is van az ok:
https://github.com/zfsonlinux/zfsstress/blob/master/randimportexport.sh
Ez a szkript ha random meghívásra kerül le majd visszacsatolja a poolt, és szerintem itt hal el a dolog, mivel nem sikerül a visszacsatolás, pl mert egy előzőleg elindított process épp befejezi egy fájl kiírását, és egy nem üres mappába nem lehet felcsatolni a pool-t.
XEN-en van egy Ubuntu, abban egy zfs, samba share-el, kb egy éve. A root itt ext4.
Eleinte kiakadt párnaponta (pörgött magában). Ennek a megoldása elég triviális volt (xattr=sa).
Most csak párhavonta jut ilyen állapotba. Lehet újra kéne pakolni az adatokat?
FreeBSD-n (root on zfs) RAID1-ben levő két haldokló merevlemezt túlélt adatvesztés nélkül, le a kalappal. Mostanában kell újraépítsem, ez csak iSCSI és backup tároló lesz.
nekünk ubuntu alatt fut egy zfs storage.
Az egyetlen szívás az volt vele, hogy először nem UUID alapján hivatkoztunk a diszkekre és egy reboot alkalmával szétesett, mert átrendeződtek a lemezek.
hát itt a hupon nekem azt mondogatták hogy binux alatt milyen fasza mán a zfs, de ezekszerint azért "apróbb problámák" még lehetnek, tekintettel arra hogy a zfs (rendes OS-en legalábbis) nem device name hanem tartalom alapján keresi a diskeket, ergo akármilyen "átrendeződést" kezel
Szerintem egy kis túlzás, hogy szétesett, egyszerűen mivel /dev/sdx-ként volt a diskekre hivatkozva nem rakta össze a poolt, mivel nem talált egy-két disket. Egy zpool importal szerintem simán összerakta újra a poolt. Én kényelemből többször sdx-ként hozom létre, majd egy zpool export/importal beteszen UUID vagy más egyedi azonosító szerint.
én /dev/disk/by-id/ hivatkozok adiskekre,igy is volt ajánlva a zfsonlinux oldalon. Remélem nem szívombe vele.
Azt nem tudta feldolgozni, hogy két egyébként teljesen egészséges lemez megcserélődött. Az egyiket visszakta a másik helyére, a másiknál meg közölte, hogy korrupt és degradálódott a tömb. Olyan csúnyán becsípődött neki valami metadata, hogy csak úgy tudtam helyrehozni, hogy mind a két disk elejét-végét (a GPT táblák helyét) dd-vel teleírtam 0-val, majd újra behoztam a két lemezt a poolba. Ezek után szépen resilverelt és ment minden tovább.
Azért a teljesség kedvéért tegyük, hozzá, hogy:
1. abban, hogy a dev/sdx átrendeződik időnként az ubuntu a hülye, nem a zfs tehet róla
2. amikor összeraktuk az egészet elsiklottunk azon ajánlás felett, hogy linuxnál célszerű uuid alapján megadni a diskek elérési útját.
"1. abban, hogy a dev/sdx átrendeződik időnként az ubuntu a hülye, nem a zfs tehet róla"
De nem is az Ubuntu...
"2. amikor összeraktuk az egészet elsiklottunk azon ajánlás felett, hogy linuxnál célszerű uuid alapján megadni a diskek elérési útját"
Vagy 15 éve.
Magyarul, aki hibázott, az ti voltatok.
--
trey @ gépház
Oké, nem az ubuntu a hülye. Ellenben eddig csak és kizárólag az ubuntu csinált ilyet. Volt előtte pontosan ugyan ezen a gépen debian, annál érdekes módon helyben bírtak maradni a device-ok annak ellenére, hogy a raidvezérlők ugyan úgy összevissza térnek magukhoz a boot során.
Szerintem elvárható lenne, hogyha nem történt hardver változás (nem vettem ki/tettem be lemezt vagy vezérlőt) akkor ugyan abban a sorrendben maradjon a /dev/sdX két reboot között.
No offense: Amikor a linux mellett döntöttetek a storage szerver esetén, volt valami érv a linux mellett?
Ilyesmire gondolok, hogy csak azt ismertétek, és nem akartatok belevágni más rendszer megtanulásába,
vagy
nem csak storage célt lát el a gép, hanem összvér megoldás, és másnak is kell róla mennie
vagy
etwas.
Mikor anno (2009) nekem kellett storage-ot összerakni "olcsóból", mérlegeltem a lehetőségeket, és végül az opensolaris mellett döntöttem.
Később upgradeltük openindiana-ra, amikor oracle's shit just hit the fan.
Azóta munka részeként már nem kell storage-ot üzemeltessek, de az otthoni nas-omon, amin meg minden vackot futtatok, átálltam OmniOS-re, és egészen bevált.
Ha most kellene munka részeként storage megoldást szállítanom, 99,999%, hogy ha a technikai rész rám van bízva, akkor az OmniOS nyerne.
Ha meg valami fejesnek "támogatott" rendszer kell, akkor még meg is lehet mutatni, hogy hol lehet a kasszához fáradni! ;)
Amikor telepítettük egyrészt másnak is kellett róla működnie, másrészt a linuxot ismerjük a legjobban. Bennem akkor még a FreeBSD merült fel, de nem volt idő sokat játszani, kellett a tárhely. A kezdeti rövid baki óta egyébként teljesen jól működik, mind megbízhatóságban, mind teljesítményben.
Az említett storage 100% storage, semmi más feladatot nem lát el.
Én végigteszteltem az OpenSolarist, OmniOS-t, FreeBSD-t és Ubuntut. De OmniOS-nél már ott elakadtam, hogy pár alapcsomagot nem tudtam, hogy kell feltenni, mert repóban nem volt, és itt feladtam, mivel előre láttam, hogy további hetekbe telne, hogy eléggé átlássam a rendszert.
A storageokat zabbix-el monitorizálom és az első ránézésre nem támogatta az OpenSolaris-t és emlékeim szerint a FreeBSD-t sem tökéletesen. Ettől még mivel a FreeBSD-nél mindent fel tudtam tenni és be tudtam állítani amit elsőre akartam, nem zártam ki. Akkor zártam csak ki, amikor átgondoltam, hogy hiba esetén mit tudok kezdeni vele, illetve át kellett volna szervezni a távoli replikát is, mivel arra már más storage replikált és ubuntu alapú volt, azt meg nem biztos, hogy bevállaltam volna, hogy különböző OS közt megy a zfs replika. Ezen kívül ubuntuból mindig van kéznél vagy egy livecd vagy egy telepített os, tehát ha kimenne az alaprendszer, akkor percek alatt újra UP lehetne a storage. FreeBSD-vel ezt külön tesztelni kellett volna, stb...
Ha jól tudom proxmox már alapértelmezetten zfs-el települ, lehet ott is érdemes lenne körülnézni vélemények után, végül is ott is vm-ek futnak róla.
Négy évvel ezelőtt raktunk össze 3 szervert proxmox-zfs kb 40 felhasználóra, a szerverek egymásra mentenek, bármelyik 2 elegendő a felhasználók kiszolgálására. Semmi gond velük. Nagyjából negyedéből kijött a rendszer, mint ha ugyanezt valami nagytól vettük volna. Most uptime 320 nap.
ha mar felmerult: en kiprobalasi cellal telepitettem egy aktualis proxmox-ot zfs-alapon es egy erdekesseget vettem eszre: folyamatosan irasi muveletek tortennek, mikozben a szerver idle. tenyleg idle, egy vm se fut cacti szerint 5-6 iras/masodperc/disk tortenik.
~# zpool iostat -v 1
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
rpool 10.2G 3.62T 0 50 0 592K
sdb2 1.89G 926G 0 22 0 215K
sda 8.26G 2.71T 0 27 0 377K
---------- ----- ----- ----- ----- ----- -----
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
rpool 10.2G 3.62T 0 0 0 0
sdb2 1.89G 926G 0 0 0 0
sda 8.26G 2.71T 0 0 0 0
---------- ----- ----- ----- ----- ----- -----
--
meg 3x szinten 0-s sorok, majd
--
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
rpool 10.2G 3.62T 0 45 0 590K
sdb2 1.89G 926G 0 20 0 215K
sda 8.26G 2.71T 0 24 0 375K
---------- ----- ----- ----- ----- ----- -----
ugy tunik minden 5. masodpercben van 2-400 kbyte iras. mi okozhatja ezt?
google talalt hasonlot, egy zfs bugreportot 2011-bol. ott arra jutottak, hogy nem normalis a dolog, de nem talaltak ra megoldast.
5 sec-enként van cache flush, konfigurálható
a proxmoxlinuxos systemdbackdoorokról nem tudni semmit
es ha nincs iras egyebkent akkor mit flush-ol? azt irja ki ~400kbyte-ban mindket hdd-re, hogy nincs mit kiirni eppen?
nocsak, milyen backdoor? nem hallottam rola. link, forras, valami bovebb info van valahol?
>es ha nincs iras
dehát van
>nem hallottam rola. link, forras
klikku
azt hittem mar tudsz valamit. mivel permanensen mellozod az irasjelek hasznalatat, azt gondoltam kerdojel van a mondat vegen...
gabu csak trollkodni tud, azt is kicsit bénán