• Huom! TechBBS-foorumi on päivitetty uusimpaan Xenforo 2.1-versioon. Kyseessä oli iso päivitys, jonka seurauksena ulkoasu täytyy työstää kokonaan uudelleen, lisäosat päivittää ja toiminallisuuksia säätää. Päivityksen jälkeinen työ ja viilailu jatkuu kulisseissa ja palautetta voi antaa palautealueella, kiitos.

Arvostelu: Uusi omarakenteinen Nas (ZFS on Linux)

dun

Liittynyt
18.10.2016
Viestejä
503
Ajattelin kirjoitella tänne arvostelun AMD Epyc 3201 piiriin perustuvasta 30W sulautetusta Mini-itx koneesta, jossa vertaan sitä vanhempaan i3-4130T 35W prosessorin ympärille rakennettuun Nasiin.

Kyseessä ei ole puhtaasti Nas, vaan enemmänkin kodin palvelin joka tarjoaa keskitetysti erilaisia palveluita.

Käyttiksenä säilyy edelleen Ubuntu server pelkällä terminaalina hallinnoima ja applikaatio asennetaan joko virtuaalikoneille (kvm2) tai docker containerilla.

Tiedostojärjestelmä on ext4 + ZFS 0.7.6.

Koppa: Silverstone ds380 mini-itx ( 8 x hotswap 3.5" + 4 x 2.5" internal)
Virtalähde: Corsair SFX 450 Gold
Kiintikset: 4 x Ironwolf + 1 x Samsung 850 Pro 256GB, Samsung 840 EVO 1TB
Pcie kortti: Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03) 8 x sata/sas (LSI SAS 2008 RAID Controller/ HBA Information)

Huomioitavaa:
ZFS on LSI:n kortissa kiinni ja SSD:t on emolevyn piirisarjan tarjoamassa sata-väylässä kiinni.
ZFS record size on 128K jokaisella datasetillä (niin siirtely datasetistä toiseen on nopein mahdollinen.
deDup on pois päältä jokaisella datasetillä.
compressratio on aika tarkkaan 1.00x.


Päivitettävät osat (kaikki hommattu 2015):
  • Intel i3-4130T@2.9ghz
  • ASRock E3C226D2I mini-itx c226 emolevy ipmi:llä (ASRock Rack > E3C226D2I)
  • 2 x 4GB DDR3 ECC
Uusi kokoonpano (tulee tammikuun puolessa välissä alustavien tietojen mukaan):
Nopeustestit joilla mittaan eron, tulee kun pystyn ajamaan testit.
  • Tiedosto siirto ssd > ZFS pakka
  • Tiedosto siirto ZFS > ssd
  • Tiedoston siirto ZFS > ZFS
  • Tiedoston purku ZFS > ZFS
  • Plexmediacenter käyttö 5 yhtäaikaisella jaolla 1080p transkoodaus
  • Plexmediacenter käyttö 5 yhtäaikaisella jaolla 4k transkoodaus
Edit:
Jos tulee mieleen mitä muita testejä ajaisin, niin kyselkää.

Tulokset (kolme kertaa ajettu komento, paras tulos kirjattu):
  • Vanha
    Koodi:
    du -h CentOS-8-x86_64-1905-dvd1.iso
    6,5G    CentOS-8-x86_64-1905-dvd1.iso
Tiedosto siirto ssd > ZFS pakka
Koodi:
$ pv CentOS-8-x86_64-1905-dvd1.iso > ssd_zfs/CentOS-8-x86_64-1905-dvd1.iso
6,65GiB 0:00:31 [ 219MiB/s] [=====================================>] 100%

Tiedosto siirto ZFS > ssd

Koodi:
$ pv CentOS-8-x86_64-1905-dvd1.iso > zfs_ssd/CentOS-8-x86_64-1905-dvd1.iso
6,65GiB 0:00:49 [ 136MiB/s] [=====================================>] 100%

Tiedoston siirto ZFS > ZFS

Koodi:
$ pv CentOS-8-x86_64-1905-dvd1.iso > zfs_zfs/CentOS-8-x86_64-1905-dvd1.iso
6,65GiB 0:01:48 [62,5MiB/s] [=====================================>] 100%
Plexmediacenter käyttö 5 yhtäaikaisella jaolla 1080p transkoodaus
* Riittää nippa nappa kolmelle käyttäjälle koska ei gpu kiihdytystä käytössä...

Plexmediacenter käyttö 5 yhtäaikaisella jaolla 4K transkoodaus
* Ei onnistu

Cachen poisto

Koodi:
sudo zpool remove tank ata-Samsung_SSD_840_EVO_1TB_S1D9NSAF631461J-part2

Uudelleen ajo ilman ssd cachea...
Tiedosto siirto ssd > ZFS pakka

Koodi:
$ pv CentOS-8-x86_64-1905-dvd1.iso > ssd_zfs/CentOS-8-x86_64-1905-dvd1.iso
6,65GiB 0:00:56 [ 120MiB/s][=====================================>] 100%

Tiedosto siirto ZFS > ssd

Koodi:
$ pv CentOS-8-x86_64-1905-dvd1.iso > zfs_ssd/CentOS-8-x86_64-1905-dvd1.iso
6,65GiB 0:00:48 [ 140MiB/s] [=====================================>] 100%

Tiedoston siirto ZFS > ZFS

Koodi:
$ pv CentOS-8-x86_64-1905-dvd1.iso > zfs_zfs/CentOS-8-x86_64-1905-dvd1.iso
6,65GiB 0:01:56 [58,5MiB/s] [=====================================>] 100%
l2arc + slog lisäys
Koodi:
        logs
          ata-Samsung_SSD_840_EVO_1TB_S1D9NSAF631461J-part1  ONLINE       0     0     0
        cache
          ata-Samsung_SSD_840_EVO_1TB_S1D9NSAF631461J-part2  ONLINE       0     0     0

Ja uudelleen...
Tiedosto siirto ssd > ZFS pakka

Koodi:
$ pv CentOS-8-x86_64-1905-dvd1.iso > ssd_zfs/CentOS-8-x86_64-1905-dvd1.iso
6,65GiB 0:00:54 [ 125MiB/s][=====================================>] 100%

Tiedosto siirto ZFS > ssd

Koodi:
$ pv CentOS-8-x86_64-1905-dvd1.iso > zfs_ssd/CentOS-8-x86_64-1905-dvd1.iso
6,65GiB 0:00:51 [ 131MiB/s] [=====================================>] 100%

Tiedoston siirto ZFS > ZFS

Koodi:
$ pv CentOS-8-x86_64-1905-dvd1.iso > zfs_zfs/CentOS-8-x86_64-1905-dvd1.iso
6,65GiB 0:01:35 [71,0MiB/s] [=====================================>] 100%
  • Uusi (odottaa emolevyn ja muistien saapumista) 1.1.2020
 
Viimeksi muokattu:
Liittynyt
20.10.2016
Viestejä
136
Virrankulutus järjestelmän levossa ja erilaisilla backup/mediacenter -kuormilla kiinnostaa.
 

dun

Liittynyt
18.10.2016
Viestejä
503
Vanhan NAS:n tulokset kirjattu nyt ensimmäiseen viestiin. Odotellaan vielä uutta emo + muisteja, niin pääsee ajamaan vertailutestit. Tuloksissa oli yllättävän paljon heittoa, josta nopein vaikutti olevan vielä toistaiseksi alkuperäinen setup pelkällä l2arc SSD cachella.
Liittyy niin puhtaasti tallennukseen tämä että ei mene tuonne. Pääasiassa keskityn pakan suorituskykyyn ZFS:n kanssa ja en niinkään kotelon modaukseen.
 

dun

Liittynyt
18.10.2016
Viestejä
503
Näyttää myös siltä että vanhalle nas:lle riitti 1Gbps linkki näköjään kun kiintikset ei sisällä pysty parempaan. Jos nopeutta ei tule lisää, niin jätän tuon 1Gbps nopeuden käyttöön uudella koneella. Toinen vaihtoehto on bondata se neljällä kaapelilla kytkimeen jossa on kaikki kaapelilla kiinniolevat laitteet. Tällöin saan ehkä teoriassa 4Gbps nopeuden Nassista kytkimeen. Kytkimestä eteenpäin se menee edelleen yhdellä kaapelilla per laite ja koska Cat6 käytössä ja ei ole 10Gbps kortteja tai nic:jä tarjolla, niin 1Gbps linkkiin jää (ellen liitä pelikonetta kahdella 1Gbps linkillä kiinni kytkimeen).

Edit: Huomasin myös testejä ajellessa että minulla oli ollut 4GB swappi käytössä, joka tarkoittaa että muisti on tosi rajallinen resussi vanhalla setupilla.

Koodi:
              total        used        free      shared  buff/cache   available
Mem:           7,7G        5,1G        630M        1,7M        2,0G        2,3G
Swap:           15G        4,7G         11G
 

dun

Liittynyt
18.10.2016
Viestejä
503
Kunhan uusi rauta tulee ja saa muistit käyttöön, niin kokeilen deduppia ja pakkausta kanssa. Vanhassa ympäristössä ei riittänyt resurssit oikein kumpaankaan.

Eli laitan pakasta päälle compression ja dedupin (säädön muistin käytön kohdalleen myös) ja sitten siirrän hakemisto kerrallaan tiedostot 1TB ssd:lle ja takaisin, niin saan dedupin ja pakkauksen käyttöön. Hetki hän tuossa menee, mutta onneksi yksikään hakemisto ei ole 1TB kokoinen niin onnistuu helposti vielä...

Lähde: ZFS dedupe (again): Is memory usage dependent on physical (deduped, compressed) data stored or on logical used?
 

dun

Liittynyt
18.10.2016
Viestejä
503
Dedup ja pakkaus kumpikin turhia jos linux distrot on jo pakattu.
Niin no tämän mukaan saisin säästettyä n. 70% tilasta...

Koodi:
$ time sudo zdb -S tank
# ...
dedup = 1.69, compress = 1.00, copies = 1.00, dedup * compress / copies = 1.70

real    27m53,591s
Pääasiassa on mp4 ja jpg tiedostoja kameroilta ja sitten pöytäkoneiden file history backupit (paljon toisteisia pakattuja tiedostoja), niin compressio ei tuo juuri mitää etua, mutta dedupista tulee aika rajusti etua kun tiedostot on tallennettu vain kerran. Tuohon kun lisää sitten vielä snapshotit, niin dedupin etu alkaa olla aika kova (nyt ei vielä snapshotteja käytössä kun kaikki tärkeä data on tallennettu vielä ulkoiseen palveluun).

Kunhan uusi rauta tulee, niin saa dedupin käyttöön ja samalla varmaan teen poolin uusiksi niin saa tiedostotkin kirjoitettua suoraan uuteen pooliin vanhasta. Mutta testailen nykyisen poolin vielä uudella raudalla ennen kuin muutan konffeja.

Edit: Dedupin muistivaatimus mahtuu näköjään heittämällä tulevaan rammiin, nykyiseen ei mahdu mitenkään.
 
Liittynyt
17.10.2016
Viestejä
1 383
Niin sulla on jotain spesiaalia toisteista kuraa paljon.

Kannattaa se dedup laittaa valikoivasti päälle vaan siihen mihin sen tarvii. Kuvien ja videoiden ei siitä kyllä käsittääkseni pitäisi hyötyä.
 

dun

Liittynyt
18.10.2016
Viestejä
503
Niin sulla on jotain spesiaalia toisteista kuraa paljon.

Kannattaa se dedup laittaa valikoivasti päälle vaan siihen mihin sen tarvii. Kuvien ja videoiden ei siitä kyllä käsittääkseni pitäisi hyötyä.
Ne siitä dedupista vasta hyötyy varsinkin jos sulla on sama kuva miljoonassa eri hakemistossa... Se kuva ei pakkaannu ollenkaan, mutta jos sulla on se kuva vain kerran tallennettu levylle ja loput on linkkejä, niin silloin säästyy tosi paljon tilaa. Sen jälkeen jos ottaa vielä snapshotit käyttöön, niin se sama tiedosto on olemassa vain kerran ja loput on vain linkkejä alkuperäiseen tiedostoon. Dedup on todella tärkeä jos levyllä on valmiiksi pakattua materiaali paljon ja jos siellä on käyttäjien ripottelemia tiedostoja (kopioita samasta tiedostosta).
 
Liittynyt
17.10.2016
Viestejä
1 383
Ne siitä dedupista vasta hyötyy varsinkin jos sulla on sama kuva miljoonassa eri hakemistossa... Se kuva ei pakkaannu ollenkaan, mutta jos sulla on se kuva vain kerran tallennettu levylle ja loput on linkkejä, niin silloin säästyy tosi paljon tilaa. Sen jälkeen jos ottaa vielä snapshotit käyttöön, niin se sama tiedosto on olemassa vain kerran ja loput on vain linkkejä alkuperäiseen tiedostoon. Dedup on todella tärkeä jos levyllä on valmiiksi pakattua materiaali paljon ja jos siellä on käyttäjien ripottelemia tiedostoja (kopioita samasta tiedostosta).
Ei ole kovin normaalia pitää samaa dataa monessa hakemistossa.
 

dun

Liittynyt
18.10.2016
Viestejä
503
Ei ole kovin normaalia pitää samaa dataa monessa hakemistossa.
Voi huokaus, jos oikeasti nas on varmuuskopiota varten usealta ihmiseltä eikä yksin kerran netistä ladatujen linux kuvien säilytykseen, niin sitä tavaraa on teratavutolkulla tallessa. Yleensä vielä useampaan kertaan tallennettu vielä (snapshot vs. esim. winkkarin filehistory joka tuuppaa ja kopioi samaa tiedostoa uudella nimellä uuteen kansioon kun ei ymmärrä että jpg tiedostossa voisi olla sama hash joka kerta...).

Esim. jos valokuvausta harrastavalla ihmisellä on pari teraa lokaalisti levyä ja sitten niistä otetaan backupit mahdollista jälkikäsitelyä varten ja sulla on kopio sekä alkuperäisestä että käsitellystä matskusta ja haluat säilyttää niitä (puhumattakaan videoista), niin aletaan puhua jo useista kymmenistä teroista matskua (tosin useammalta vuodelta) per työasema.

Esim. meillä ei yleensä varmuuskopida off-sitelle kuin valmis materiaali, joka yleensä vie ehkä 5-10% alkuperäisestä matskusta ja koska levyjen hinnat ei ole mitään päätä huimaavia, niin sen sijaan että heittäisi alkuperäistä matskua roskiin, niin on helpompi vain hommata isompia levyjä ja laajentaa b-rulla varastoa. Esim. vuonna 2000-2005 napsitut kuvat mahtuu about muutamaan gigaan (kiitos kamerakennojen ollessa 1-3mpix vekottimia), mutta siitä eteenpäin aletaan laskemaan sadoissa gigoissa per vuosi ja 2010-2019 puhutaan jo useista sadoista gigoista per vuosi materiaalia. Meillä menee digitaalinen jalajälki lapsuuteen asti, joka tarkoittaa vhs, minidv, mini8, dia, kino yms. digitalisoitua materiaalia ja vaikka sekin on hevc tai h264 encoodattuna tallessa, niin sitä on satoja gigoja, joka odottaa aina silloin tällöin uutta leikkausta perhetilaisuutta varten.

Tämän takia ZFS on todella hyvä tiedostojärjestelmä, koska se ei luota rautaan, vaan tarkistaa (scrub) että tieto pysyy muuttumattomana levyllä, toisin kuin normaalit raidit jotka antaa bitrotin tapahtua (eli on tosi mukava huomata että 20-vuotta vanhat digikuvat ei enää aukea kun bitit on ihan vinossa...).

En aikaisemmin ajatellut deduppia (koska muistivaatimus), mutta nyt kun löysin tuon epycin ja sen että se tukee 512GB rammia, niin se ratkaisi kaikki omat pulmat rikkomatta pankkia. Ja kiitos 0.7 version ZFS:n niin ei ole enää typerää dedupin 1/4 max ram vaatimusta vaan sitä voi ihan vapaasti muokata lennosta (eli enää ei tarvi 5TB tallennustilalle 20GB muistia vaan pärjää huomattavasti vähemmällä).

Esim: How To Size Main Memory for ZFS Deduplication

Koodi:
#zdb -S tank
Simulated DDT histogram:

bucket              allocated                       referenced        
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1    1.00M    126G    126G    126G    1.00M    126G    126G    126G
     2    11.8K    573M    573M    573M    23.9K   1.12G   1.12G   1.12G
     4      370    418K    418K    418K    1.79K   1.93M   1.93M   1.93M
     8      127    194K    194K    194K    1.25K   2.39M   2.39M   2.39M
    16       43   22.5K   22.5K   22.5K      879    456K    456K    456K
    32       12      6K      6K      6K      515    258K    258K    258K
    64        4      2K      2K      2K      318    159K    159K    159K
   128        1     512     512     512      200    100K    100K    100K
 Total    1.02M    127G    127G    127G    1.03M    127G    127G    127G

dedup = 1.00, compress = 1.00, copies = 1.00, dedup * compress / copies = 1.0
Muistin varaus tälle on:
Koodi:
In-core DDT size (1.02M) x 320 = 326.4 MB of memory is required
Eli (127GB levyä) jos on 1,02M block:ia * 320 tavua, niin päädytään 326,4MiB muistimäärään ja koska ei olla enää Oraclen vanhassa ZFS:ssä, niin tuolle määrälle materiaa riittääkin jo alle 1GiB keskusmuistia eikä se vaadi pelkästään zfs:lle 1,3GiB + OS varausta.

Jos käytetään vanhaa 5TB esimerkkiä, ja 40,2M blockkia, niin muistia tarvisi n. 12,8GiB pelkästään dedup datalle ja tämä kertaa 4 tarkoittaisi 51GiB muistinvarausta. Mutta koska voitkin antaa metadatalle nykyään vaikka 75% kokonaismuistista, niin tarvitsetkin muistia ZFS:lle vain sen alkuperäisen 12,8GiB ja annat sen kasvaa siitä ylöspäin.

Toinen vaihtoehto on käyttää l2arc (cache) ssd:tä dedup datan säilytykseen. Voin sanoa että 256GB MLC samsung ei ole pahan hintainen ja on aika sukkela vekoitin myös vrt. swappaus kiintikselle.
 
Liittynyt
17.10.2016
Viestejä
1 383
Kovasti nyt tuntuu puristavan.

Sulla on tarve dedupille anna mennä. Suurelle osalle se ei ole tarpeen koti nassissa.
 

dun

Liittynyt
18.10.2016
Viestejä
503
Dodih, tuleepahan testattua että tuleeko tosta dedupista mitää käytännön hyötyä. Pistin siirtymään uudelle zfs poolille, missä on seuraavat ominaisuudet enabloitu, kaiken datan jota ei ole backupattu pilveen. Mietin pitkään teenkö mirrorille (vaatisi 2 x saman kokoiset levyt + en ole hommaamassa uusia levyjä nyt), joten pienellä riskillä mennään että ennen raudan vaihtoa sekä nykyinen 4 levyn pakka lahoaa + että tämä ylimääräinen levy lahoaisi. Mutta ihan kaikkeen ei ole rahaa ja tärkeät tiedot on anyway pilvessä turvassa.

Koodi:
sudo zpool create backup \
  /dev/disk/by-id/wwn-0x5000c5009e5fe989-part1
 
sudo zpool add -f backup cache /dev/disk/by-id/ata-Samsung_SSD_840_EVO_1TB_S1D9NSAF631461J-part1

sudo zfs set xattr=sa backup
sudo zfs set acltype=posixacl backup
sudo zfs set compression=lz4 backup
sudo zfs set atime=off backup
sudo zfs set relatime=off backup
sudo zfs set dedup=on backup

sudo zfs create backup/2020-01-11
sudo chown -R $USER. /backup/2020-01-11
Pilvitiedolle tein jo testin ja siinä tuli 1.39 kertainen dedup käyttöaste samoilla asetuksilla, joten nyt isommalla datasetillä (- cloud backup, koska siihen ei tarvii koskea, sen voi aina ladata takaisin levylle pilvestä).

Aloitin syncronisaation uusilla komennoilla (koska uudelleen käytettävä ja voi päivittää tilanteen nopeammin tulevaisuudessa).
Koodi:
#Snapshottaus
sudo su -
zfs snapshot source/dataset1@2020-01-11_dataset1
zfs snapshot source/dataset2@2020-01-11_dataset2

# Listaa snapshotit
zfs list -t snapshot
NAME                                     USED  AVAIL   REFER  MOUNTPOINT
source/dataset1@2020-01-11_dataset1     x,xxM      -  xx,xxT  -
source/dataset2@2020-01-11_dataset2     x,xxM      -  xx,xxT  -

# Kopioi poolista toiseen
time zfs send source/dataset1@2020-01-11_dataset1 | zfs receive backup/dataset1 &&\
time zfs send source/dataset2@2020-01-11_dataset2 | zfs receive backup/dataset2
Edit: Jaha, tossa saattaa hetki mennä, välillä tiedostonsiirto tipahtaa n. 1MB/s nopeuteen normaalista n. 100-120MB/s. Tämä on tyyppillistä zfs:lle kun on liian vähän keskusmuistia ja hidas cpu (vaikka l2arc onkin auttamassa). Kaikki koneen huikeasta 7,72GB keskusmuistista on käytössä ja roottilevyn (samsung 850 pro) swapistakin on 4GB/16GB käytössä...

Edit2: Syy vanhan pakan tuhoamiselle on tämä 2017 huhuillun ominaisuuden puute... [WIP] raidz expansion, alpha preview 1 by ahrens · Pull Request #8853 · zfsonlinux/zfs

Edit3: Ei taida 24h riittää ekan datasetin kopiointiin. No kunhan se on valmis, niin aloitan backup datasettien siirron jonka pitäisi parantaa dedup ratiota (enimmäisten satojen gigojen jälkeen dedup on 1.11x ja compressioratio on 1.03x)...

Keksiikö joku paremman komennon tilanteen tarkkailuun? Nyt joutuu ajamaan 3 komentoa että saa sortattua toisen parametrin mukaisesti...
Koodi:
clear;zfs get used ${ZDATASETS};\
zfs get available ${ZDATASETS};\
zfs get compressratio ${ZDATASETS};\
zpool list
Edit4: Enpä keksinyt muuta kuin tämän...
Koodi:
clear;zfs get used,available,compressratio ${ZDATASETS}|head -n1;\
zfs get used,available,compressratio ${ZDATASETS}|sed '1d'|sort -k2,2;\
zpool list
Edit5: Pudotin rsyncin pois kopioinnista kun zfsstähän löytyy komennot jo itsestään jotka huolehtii myös tulevaisuuden incremental synkistä (niin ei tarvii tehdä miljoonaan kertaan initial synkkiä poolien välillä). Kätsyä, kannattaa joskus vähän googlailla ja lukea manuaalia.

Edit6: Tässä uutta rautaa odotellessa pistin vanhalla raudalla tuulemaan (ja nyt pitää odotella ties montako päivää). Eli siirtelen pilvibackupit omalle datasetille (compressio ja dedup päällä nyt), henkilökohtaiset backupit dedupille ja uudelleen järjestely, mutta mountpointit pysyy samana. Seuraavaksi pitää katsoa onko joku kirjoittanut jo hyvät systemd/cronjob scriptit jolla saa tehtyä tunnin, päivittäisen, viikottaisen, kk ja vuoden snapshot rotaatiot.

Jos ei ole, niin teen itse, mutta luulisi noin yleisen toimenpiteen joku jo tehnyt. Esim. 7pv tunnin snapshotit talteen, sitten 30 pv:ltä pv snapshot tallessa, ja sitten 12kk 1kk snapshot tallessa tms...

Edit7: Nyt löytyi paras komento siirrolle. Nyt myös mahdollista siirrot kun sain yhden ison datasetin jaettua useampaan pienempään kun järkevöitin pakan käyttöä. Dedup tekee kyllä nykyisestä raudata ihan kauhean käyttää, kun kaikki loppuu kesken ja siirrot ja tiedostojen poistot muodostuu ihan kamalan hitaaksi. Mutta nyt kun symlinkit otti isompaan käyttöön ja siirsi eri datat eri dataseteille, niin yleisestä verkkojaostakin tuli järkevämpi.

Eli stuktuuri muuttui nyt näin:

Koodi:
# Poolin rakenne
source/dataset_public # Jaettu kaikille. Ei deduppia
source/dataset{2..xx} # Henkilökohtainen verkkojako jonne backupit, compress + dedup
source/dataaset_cloud # Pilveen tallennettava tärkeä tieto, compress + dedup. Symlink  source/dataset_public/dataset_cloud

# Näin voi helposti symlinkillä jakaa yhteiseen datasettiin näkeyvyyttä ja
# voi samalla pitää henkilökohtaiset jaot erilllään yhteisestä paikasta.
# Aikaisemmin kaikki oli samassa, mikä tarkoitti että quotat yms. meni
# vaikeaksi jos piti lohkoa.
# Onneksi tässä tietojärjestelmässä kaikki on vain
# helpompaa vrt. NTFS/ext4/btrfs.

# Eka varmuuskopio
sudo time zfs send source/dataset1@2020-01-12_dataset1 | pv | sudo zfs receive target/dataset1 &&\
sudo time zfs send source/dataset2@2020-01-12_dataset2 | pv | sudo zfs receive target/dataset2 &&\
# ...
sudo time zfs send source/dataseXX@2020-01-12_datasetXX | pv | sudo zfs receive target/datasetXX
# Jos target on tarpeeksi iso, niin voi myös ottaa ihan kaikesta
# backupin kerralla yhdellä komennolla:
sudo time zfs send -rn source@2020-01-12_all| pv | sudo zfs receive target

# Deltan siirto
sudo time zfs send -i
source/dataset1@2020-01-13_dataset1 | pv | sudo zfs receive target/dataset1 &&\
sudo time zfs send -i source/dataset2@2020-01-13_dataset2 | pv | sudo zfs receive target/dataset2
 
Viimeksi muokattu:

dun

Liittynyt
18.10.2016
Viestejä
503
Nykyisen raudan nopeus:
n. 101,77GB/h kun siirtää dataa poolien välillä (datasetissä on tekstitiedostoista useiden satojen megojen mp4 tiedostoihin ja sitten erinäinen määrä jpeg kuvia). Dedup + pakkaus kohteessa käynnissä.

Kun saa uuden raudan, niin voin ajaa saman testin ja nähdä tapahtuuko mihinkään suuntaan muutosta (cpu vääntöä tulee 2 x määrä, per thread ei muutu ja muistia tulee 8 x määrä). Jos ei tule muutosta, niin sitten ei tule, jääpähän lisää tehoa sitten tarjolle kun ajaa softaa. Swappi disabloidaan kokonaan.

Edit1: Jeps, hidasta on, 35MB/s on siirtonopeus kun katsoo keskiarvoa tunnillta. Aikaisemmin oli 28MB/s kun siirsin kasan pienempiä tiedostoja. No onneksi siirtyy taustalla, niin ei tarvii huolehtia.

Jos olisi paketti vähän epävarmempi, niin tuohon zfs send/receive säätöön voisi ottaa nämä arvot käyttöön:

Koodi:
# zfs receive:
-s  If the receive is interrupted, save the partially received state, rather than deleting it.  Interruption may be due to premature
           termination of the stream (e.g. due to network failure or failure of the remote system if the stream is being read over a network
           connection), a checksum error in the stream, termination of the zfs receive process, or unclean shutdown of the system.

           The receive can be resumed with a stream generated by zfs send -t token, where the token is the value of the receive_resume_token
           property of the filesystem or volume which is received into.

           To use this flag, the storage pool must have the extensible_dataset feature enabled.  See zpool-features(5) for details on ZFS fea‐
           ture flags.
 
Viimeksi muokattu:

dun

Liittynyt
18.10.2016
Viestejä
503
Jeps, vauhti tipahti takaisin 27,5MB/s. Tässä tovi menee, ilman deduppia pääsisi varmaan 3-4 nopeuteen, mutta sitten loppuisi levytila varmuuskopio-kohteesta. Noh, katsotaan huomenna aamulla missä mennään kun varmuusasema ruksuttelee menemään. Sitten pitääkin tehdä päätös että tilaisiko yhden uuden ironwolffiin ja tekee backupin mirroriin. Toivottavasti toi raidz expansion tulisi että tätä hommaa ei tarvisi tehdä sitten kun päättää panostaa 4 levyn verran (tai jos yhden jo ostan, niin sitten 3 levyn verran). Toki jos tuo raidz expansion vihdoin tulee, niin sitten voi levy kerrallaan ostella aina 8 asti (nyt hyllyssä yksi ylimääräinen levy siltä varalta jos joku noista olemassa olevista laukeaisi, mutta noita levyjä saa sen verran vauhdilla kaupasta, että taitaa olla turha yhtä ylimääräistä pitää kaapin pohjalla odottelemassa.

Edit1: Load average: 11.04 10.98 10.62
Eli tämä tarkoittaa että 4 prosessin lisäksi 7 odottaa suoritusta... Puuh.
 
Viimeksi muokattu:

dun

Liittynyt
18.10.2016
Viestejä
503
Jeps jeps. Vedin pelkästään snapshot siirron jaetusta vapaasta sisällöstä, 66h 30min tasan siirtyi ja dedup päätyi olemaan 1.25. Backupeilla pääsi dedupissa jo 1.69 ilman snapshotteja, mutta huh huh. Ainakaan nykyisellä raudalla ei kannata deduppia käyttää muuta kuin backup dataseteillä.

Tulisi nyt uusi rauta, niin pääsisi leikkimään vähän tehokkaamalla laitteistolla...
 

dun

Liittynyt
18.10.2016
Viestejä
503
Näyttää siltä että Supermicrolla ei ole alle 1kk toimitusajalla koko euroopassa saatavilla tota haluaamaani emoa. Voi elämän kevät, no saapa nähdä mitä sieltä saa jos vaihtaa pakettia. Hinta tosiaan pomppaa kyllä :(

Edit1: Tilasin sitten 2 kpl lisää levyjä, teen nyt 6 levyn uuden pakan kun tulevat ja toivon että tuo raidz expansion tulee saataville, saapahan pooliin 2 x kapasiteetin nyt kun sa 6 levyä (2 pariteettilevyä). Expansion kun tulee, niin voin sitten laajentaa vielä + 2 levyllä yksitellen.

Edit2: Suunnitelma näyttää siltä, että kun saan kaksi uutta levyä käyttöön ja pakan tehtyä, niin teen poolin löytämälläni asetuksilla, mutta jätän dedupin kokonaan käytämättä. Sen aiheuttama nopeushaitta (ainakin nykyisellä raudalla) oli niin merkittävä, että ei ole mitään järkeä odottaa 4 levyn ssd-kiihdytettyä poolia 35MB/s nopeuksilla vaikka kuinka säästäisi tilassa (taino, jos mennään yli 2x säästön yli, niin sitten, ehkä). Itsellä kipuraja pakkaan kirjoittaessa on se 70-100MB/s, koska sen verran pitää löytyä kirjoitusnopeutta tässä taloudessa tai rahat menee hukkaan.

Edit3: Taino, kai se dedup voisi olla mahdollinen jos 6 levyn boolin lisäksi hommaa sitten 2 levyn mirror poolin johon enabloi dedupin. Hm.. Pitää pohtia asiaa sitten kun saa budjetin kasaan 2 x 10-20TB levyille.
 
Viimeksi muokattu:

dun

Liittynyt
18.10.2016
Viestejä
503
Ja pöh, tilasin vielä 2 kpl odotellessa lisää levyjä. Ironwolffeissa parin viikon toimitusaika myös. Puuh.
On tämäkin kun joutuu odottamaan kk kaupalla rautaa. Toivottavasti on odotuksen ja budjetin arvoista...
 

dun

Liittynyt
18.10.2016
Viestejä
503
Nyt sain paketin pöydälle. Pari yötä aikaa kasailla... Jos tuuri käy, niin nykyinen käyttis boottaa tänään...

Edit: uudet kiintikset on vielä matkalla. Eli pakkaa ei pääse vielä rakentamaan uusiksi...
 
Viimeksi muokattu:

dun

Liittynyt
18.10.2016
Viestejä
503
Vielä talteen cpu testi ennen kuin vanha sotaratsu pääsee teuraalle (Intel i3-4130T@2,9Ghz). Eli kyseessä on yksi tyypillinen ajo koneelta, eli useita tiedostoja konvertoidaan jostain bittivirta/resoluutiosta johonkin testattuun hyvään muotoon (esim. 4k => 480p web-jako sukulaisille messengerissä yms.). Tässä tapauksessa otettu 720p sukellusvideo/allasvideo (8min ja päälle) Nikonin kameralta ja käännetään 1080p muotoon (koska miksei, laatu ei parane pätkääkään) matroska-konttiin.

Testin aikana koneessa ei muuta rasitusta päällä ja kaikki 4 threadia 100% käytössä.

Testitiedosto:
Koodi:
$ du -h testivideo.mov
1,1G    testivideo.mov
Koodi:
# ffmpeg enkoodaus-asetukset:
#/bin/bash

# Muuttujat
INPUT_FILE=$1

# Applikaatio
ffmpeg \
  -y \
  -i "$INPUT_FILE" \
  -s hd1080 \
  -c:v libx264 \
  -b:v 9000k \
  -c:a libmp3lame \
  -b:a 192k \
  ${INPUT_FILE%.*}.mkv
Klippi käännösaikaisesta tuloksesta:
Koodi:
$ time konvertaa_1080p testivideo.mov
ffmpeg version 3.4.6-0ubuntu0.18.04.1 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 7 (Ubuntu 7.3.0-16ubuntu3)
  configuration: --prefix=/usr --extra-version=0ubuntu0.18.04.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-librsvg --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
  libavutil      55. 78.100 / 55. 78.100
  libavcodec     57.107.100 / 57.107.100
  libavformat    57. 83.100 / 57. 83.100
  libavdevice    57. 10.100 / 57. 10.100
  libavfilter     6.107.100 /  6.107.100
  libavresample   3.  7.  0 /  3.  7.  0
  libswscale      4.  8.100 /  4.  8.100
  libswresample   2.  9.100 /  2.  9.100
  libpostproc    54.  7.100 / 54.  7.100
Guessed Channel Layout for Input Stream #0.1 : mono
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'testivideo.mov':
  Metadata:
    major_brand     : qt
    minor_version   : 537331968
    compatible_brands: qt  niko
    creation_time   : 2014-12-10T15:48:40.000000Z
  Duration: 00:08:14.49, start: 0.000000, bitrate: 18575 kb/s
    Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt470bg/unknown/bt470m), 1920x1080 [SAR 1:1 DAR 16:9], 18185 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc (default)
    Metadata:
      creation_time   : 2014-12-10T15:48:40.000000Z
    Stream #0:1(eng): Audio: pcm_s16le (sowt / 0x74776F73), 24000 Hz, mono, s16, 384 kb/s (default)
    Metadata:
      creation_time   : 2014-12-10T15:48:40.000000Z
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
  Stream #0:1 -> #0:1 (pcm_s16le (native) -> mp3 (libmp3lame))
Press [q] to stop, [?] for help
[libx264 @ 0x5576a5a82e80] using SAR=1/1
[libx264 @ 0x5576a5a82e80] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0x5576a5a82e80] profile High, level 4.0
[libx264 @ 0x5576a5a82e80] 264 - core 152 r2854 e9a5903 - H.264/MPEG-4 AVC codec - Copyleft 2003-2017 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=23 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=abr mbtree=1 bitrate=9000 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, matroska, to 'testivideo.mkv': time=-577014:32:22.77 bitrate=  -0.0kbits/s speed=N/A  
  Metadata:
    major_brand     : qt
    minor_version   : 537331968
    compatible_brands: qt  niko
    encoder         : Lavf57.83.100
    Stream #0:0(eng): Video: h264 (libx264) (H264 / 0x34363248), yuvj420p(pc, progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 9000 kb/s, 23.98 fps, 1k tbn, 23.98 tbc (default)
    Metadata:
      creation_time   : 2014-12-10T15:48:40.000000Z
      encoder         : Lavc57.107.100 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/9000000 buffer size: 0 vbv_delay: -1
    Stream #0:1(eng): Audio: mp3 (libmp3lame) (U[0][0][0] / 0x0055), 24000 Hz, mono, s16p, 192 kb/s (default)
    Metadata:
      creation_time   : 2014-12-10T15:48:40.000000Z
      encoder         : Lavc57.107.100 libmp3lame
frame= 1037 fps=9.3 q=28.0 size=   42338kB time=00:00:42.43 bitrate=8173.4kbits/s speed=0.38x
Puolessa välissä kääntämistä muistinkäyttö ja top:
Koodi:
$ free -hm
              total        used        free      shared  buff/cache   available
Mem:           7,7G        3,2G        2,6G         53M        1,9G        4,2G
Swap:           15G        1,1G         14G

Tasks: 404 total,   1 running, 342 sleeping,   0 stopped,   0 zombie
%Cpu(s):  3,6 us,  3,9 sy,  0,7 ni, 84,9 id,  6,6 wa,  0,0 hi,  0,2 si,  0,0 st
KiB Mem :  8090828 total,  2597396 free,  3384648 used,  2108784 buff/cache
KiB Swap: 16777212 total, 15671292 free,  1105920 used.  4360456 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                
 2700 user123+  20   0 1734520 563876  27764 S 342,1  7,0  68:55.79 ffmpeg
Aika joka kääntämiseen meni (minuuteissa):
Koodi:
frame=11856 fps= 10 q=-1.0 Lsize=  554463kB time=00:08:14.49 bitrate=9185.4kbits/s speed=0.428x   
video:544565kB audio:9659kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.043091%
[libx264 @ 0x5576a5a82e80] frame I:51    Avg QP:20.02  size:185589
[libx264 @ 0x5576a5a82e80] frame P:2998  Avg QP:23.10  size: 83692
[libx264 @ 0x5576a5a82e80] frame B:8807  Avg QP:25.26  size: 33753
[libx264 @ 0x5576a5a82e80] consecutive B-frames:  0.9%  0.2%  0.2% 98.8%
[libx264 @ 0x5576a5a82e80] mb I  I16..4:  8.9% 73.2% 17.9%
[libx264 @ 0x5576a5a82e80] mb P  I16..4:  3.1% 17.2%  1.8%  P16..4: 47.1% 18.4% 10.6%  0.0%  0.0%    skip: 1.9%
[libx264 @ 0x5576a5a82e80] mb B  I16..4:  0.5%  2.8%  0.1%  B16..8: 40.7%  4.9%  0.9%  direct:22.3%  skip:27.8%  L0:44.1% L1:48.8% BI: 7.1%
[libx264 @ 0x5576a5a82e80] final ratefactor: 21.72
[libx264 @ 0x5576a5a82e80] 8x8 transform intra:79.3% inter:76.5%
[libx264 @ 0x5576a5a82e80] coded y,uvDC,uvAC intra: 78.5% 97.3% 75.8% inter: 32.1% 70.4% 17.8%
[libx264 @ 0x5576a5a82e80] i16 v,h,dc,p: 13% 20% 20% 47%
[libx264 @ 0x5576a5a82e80] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 19% 33%  4%  5%  5%  6%  5%  7%
[libx264 @ 0x5576a5a82e80] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 23% 23%  5%  6%  5%  6%  5%  5%
[libx264 @ 0x5576a5a82e80] i8c dc,h,v,p: 55% 19% 14% 12%
[libx264 @ 0x5576a5a82e80] Weighted P-Frames: Y:7.1% UV:4.8%
[libx264 @ 0x5576a5a82e80] ref P L0: 43.3% 11.1% 29.5% 15.6%  0.5%
[libx264 @ 0x5576a5a82e80] ref B L0: 83.4% 13.7%  2.9%
[libx264 @ 0x5576a5a82e80] ref B L1: 93.3%  6.7%
[libx264 @ 0x5576a5a82e80] kb/s:9021.48

real   19m15,083s
user   73m51,711s
sys   0m24,769s

# koko vielä
$ du -h testivideo.m*
542M    testivideo.mkv
1,1G    testivideo.mov
 

j7u

Liittynyt
14.12.2016
Viestejä
126
Edit: uudet kiintikset on vielä matkalla. Eli pakkaa ei pääse vielä rakentamaan uusiksi...
Toivotaan limppujen olevan ehjiä.
Omasta 4 sarjasta 1 oli heti rikki ja nyt 1 v jälkeen näkyy olevan yli 2000 bad block toisella levyllä.
No opetushan on se ettei pidä siikakeittimen levyjä hankkia.
 

dun

Liittynyt
18.10.2016
Viestejä
503
Toivotaan limppujen olevan ehjiä.
Omasta 4 sarjasta 1 oli heti rikki ja nyt 1 v jälkeen näkyy olevan yli 2000 bad block toisella levyllä.
No opetushan on se ettei pidä siikakeittimen levyjä hankkia.
Juu, testaan kaikki merkistä riippumatta. Syy miksi otin ironwolffeja ei ollut hinta vaan se että muutkin pakan levyt on samanlaisia ja saan identtisistä levyistä muodostettua poolin(t).

Jos 8:sta levystä 3 levyä menee rikki, menetän kaiken datan poolista, mutta tuon lisäksi on backup pooli, jossa data on kertalleen vielä snapshotattuna. eli en ole kovin huolissani jos seagate, wd tai toshiba kusahtaa. Noista eniten on kusahtanut wd:n levyjä itsellä (tosin niitä on myös ollut eniten, pitkään kartoin seagaten levyjä, mutta pari vuotta sitten hommasin kun olivat halvimpia. Harmi ettei nyt ollut tarjouksessa, mutta eipä se mitään.
 

dun

Liittynyt
18.10.2016
Viestejä
503
Heh, eli cpu vääntöä tuli n. 4x lisää ja cpu cooler äänettömällä/passiivisena cpu ilmoittaa omien sensoriensa mukaan 44c lämpötilan. Ei huono, tosin alle 5min ei taida lämmöt vielä nousta...

Koodi:
# CPU:n nopeus kun sama encodaus.
real    4m40,344s
user    72m14,152s
sys     0m15,998s
Edit: Huoh, zfs pooli ei importtaudu eikä nouse. Levyt ei myöskään näy kernelille. Mikähän tohon korttiin iski... Toivottavasti ei mennyt paskaksi.
 
Viimeksi muokattu:

dun

Liittynyt
18.10.2016
Viestejä
503
No niin, nyt sain toimimaan levytkin, kesti vain aika kauan että nousi. Harmi ettei indikoi mitenkään että mitä tekee. ZFS luuli että oli uncraceful shutdown kyseessä ja buildasi DDT:n uusiksi (kesti varmasti yli 20min). Nyt pääsee testailemaan.

Tähän mennessä cpu nopeus kasvoi mitattavassa muodossa 4.125 kertaiseksi. Eli ei ollenkaan paha. Levynopeus pitää testata seuraavaksi, mutta ei ollenkaan hassu päivitys vaikka aika extreme ihan omasta syystä onkin. Kiitos Silverstonen ja Supermicron (tuli defaulttina molemmat melkein äännettömillä tuulettimilla), nyt en kuule 2 metrin päässä olevasta pöpelistä enää kuin pikkuisen levyjen rapinaa kun iso kirjoitus lähtee käyntiin. 3 x 120mm tuuletimet on alimmilla kieroksilla ja prossun lämpötila cpu sensorin mukaan on kiva 22c ja korkeimmillaan nähnyt sen 44c ilman että cpu cooleri edes alkaa nostamaan kieroksia enemmän (pikkuisen nostaa ja sen huomaa kun laittaa korvan kiinni).

Ajoinpa kokeeksi testin (dedup ei ole päällä, cache ssd poistettu):
Bash:
# Tiedoston siirto ssd > ZFS pakka
$ pv CentOS-8-x86_64-1905-dvd1.iso > ssd_zfs/CentOS-8-x86_64-1905-dvd1.iso
Vanha: 6,65GiB 0:00:31 [ 219MiB/s] [=====================================>] 100%
Uusi: 6,65GiB 0:00:24 [ 276MiB/s] [=====================================>] 100%

# Tiedoston siirto ZFS > ssd
$ pv CentOS-8-x86_64-1905-dvd1.iso > zfs_ssd/CentOS-8-x86_64-1905-dvd1.iso
Vanha: 6,65GiB 0:00:49 [ 136MiB/s] [=====================================>] 100%
Uusi:  6,65GiB 0:00:05 [1,13GiB/s] [=====================================>] 100%

# Tiedoston siirto ZFS > ZFS
$ pv CentOS-8-x86_64-1905-dvd1.iso > zfs_zfs/CentOS-8-x86_64-1905-dvd1.iso
Vanha: 6,65GiB 0:01:48 [62,5MiB/s] [=====================================>] 100%
Uusi:  6,65GiB 0:00:16 [ 409MiB/s] [=====================================>] 100%
Että että, ei huonompi päivitys. Seuraavaksi sitten odotellaan uudet levyt ja rakennetaan pakka uusiksi. Kuvankaappaus koneesta ja sen käyttämistä resursseista...
1580902363251.png
 
Viimeksi muokattu:

dun

Liittynyt
18.10.2016
Viestejä
503
Piti vähän säätää, tämä AMD Zen+ generaation cpu / emo yhdistelmä ei oikein toimi Dell Perc H310 kortin kanssa ennen kuin pakotti nykyisellä firmis/bios combolla pci-e väylän toimimaan pci-e 2.0 nopeudella. Auto-asetuksella kortti vain tippui kernelistä...

Nopeudet on ihan samat kuin aikaisemminkin, joten ZFS:n pakkaan asetus ei ainakaan nopeuden puolesta vaikuttanut.

Ajoin myös plexmediaserverin web-playerillä testiä ja en tiedä mikä kyykkäsi, mutta kun oli 6 x chrome ikkunaa auki ja eri video pyörimässä jokaisessa, niin alkoi pätkimään. Cpu loadi ei ollut millään corella kummassakaan koneessa (clientillä eikä serverillä) mitenkään korkea, mutta heti kun sulki yhden ikkunoista pois, kaikki videot pyöri normisti ilman pätkimisiä. Pelkästään 6:n ikkunan avaus ja koti-sivulle meno plexillä aiheutti pätkimistä, joten jokin resurssi loppui tai sisäinen raja tuli vastaan. Levynkäyttö oli kilotavuissa, eli edes megatavuja ei siirtynyt ja dataa siirtyi verkkopiuhaa pitkin n. 114Mbit maksimissaan, sekin tosin heilui jonkin verran. Eli kai ihan ok tulos, tiedä sit mikä tuossa oli. Mutta jos ei tule kysymyksiä tai kommentteja, niin taitaa olla aika pitkälti tässä tämä arvostelu.
 

andyks

Tukijäsen
Liittynyt
20.09.2018
Viestejä
109
RAM ei loppunut? Millä transkoodaat? Jos HW transkoodaus, loppuiko GPU:sta potku? Mihin transkoodaat? Eihän ko. kohteesta loppunut potku?
Eihän pätkiminen johtunut clientin päästä? 6 ikkunaa videota Chromella ei ole enää mikään ihan kevyt operaatio...
 

dun

Liittynyt
18.10.2016
Viestejä
503
Cpu loadi clientillä oli alle 10%, näyttiksellä 12% clienttikoneella. Serverillä, kuten varmaan huomasit ei ole rautakoohdytykseen sopivaa prosessoria kun koko koneesta ei löydy gpu:ta. Loadi tai yksikään ydin koneessa ei noussut edes 5%. Kummassakin koneessa oli muistia kymmeniä gigatavuja käyttämättä. Chromet oli luonnollisesti 64-bittisiä.
 

dun

Liittynyt
18.10.2016
Viestejä
503
Dodih, maanantaina tulee 4 kpl uusia kiekkoja. Backupit otettu ja pääsee harjoittelemaan tietojen palautusta zfs poolista toiseen... Täytyy sanoa että ei ole liioiteltua että muistin määrä on tärkeää zfs:lle. Se on melkein tärkein kriteeri, seuraavaksi tärkein on cpu joka ei omalla kohdalla ole enää ongelma. Deduppia ei kannata kyllä käyttää kuin äärimmäisessä hädässä (backup poolissa johon tulee paljon snapshotteja). Sain 2 x pienemmälle poolille dedup päällä kaiken lokaalin datan. Kaivan vielä dedup + pakkaus arvon poolista.
 

dun

Liittynyt
18.10.2016
Viestejä
503
Tässä odotellessa tutkiskelin vähän että mitä voisi tehdä nyt eritavalla kuin aikaisemmin ja huomasin pari asiaa:

1) pipenv oli työkalu jonka en tiennyt olevan olemassa. Siistiä.
2) LinuxServer wow. Menee aika helpoksi tämä...

Lopputuloksena tulee olemaan loppujenkin palveluiden siirtyminen docker-compose hallittuun konttijärjestelmään. Pitää vain tehdä datasetit nyt niin että konttien käyttämät bind mountit osuu oikein...

Lopputuloksena tulee olemaan aika minimalistinen ansible playbook joka pistää kerneltason asiat kuntoon, hoitaa zfs import / mount asiat ja sitten lopuksi ajaa docker composen ylös. Niin kauan kun kubernetesiä tai muuta en aio tuolla pyöritellä niin menkööt kontit ilman replikointia. Toisaalta koneessa on sen verran tehoa, että minikuben voisi tietenkin asentaa...
 

dun

Liittynyt
18.10.2016
Viestejä
503
Jeps, sain aika hyvin toimimaan nyt. Ei paha kyllä. Saapa nähdä minkälaista tätä on ajaa nyt tolla docker-composella pelkästään. Piti tehdä oma repo linuxserverin palikoille johon sijoitin sitten Pipenv, Pipenv.lock ja docker-compose.yaml tiedostot ja sen jälkeen ajoin pystyyn seuraavilla komennoilla (käsin tosin tässä vaiheessa vielä):
Bash:
# Ympäristön deployaus
$ cd ~/linuxserver
$ pipenv install --ignore-pipfile
$ pipenv shell

# Palveluiden käynnistys
(linuxserver)$ cd ~/linuxserver
(linuxserver)$ docker-compose up -d
 

dun

Liittynyt
18.10.2016
Viestejä
503
Dockerin hyvä puoli on se, että on yäysin käyttisriippumaton. Eli reposta saa versiohallitut konffit kun gitin on saanut asennettua ja ansiblella saa käyttiksen siihen tilaan että kontteja voi ajaa. Tästä innostuisi räpläämään enemmänkin jos ei työskeen tätä tekisi :)
 

dun

Liittynyt
18.10.2016
Viestejä
503
Huoh, levyt tuli ja yksi oli rikki. Piippasi ja kolisi kun yritti käynnistyä. Paketti oli sen näköinen että olisi mennyt lihamyllyn läpi. Nyt pitää tulostella lippulappusia ja lähetellä osaa Saksaan ja saan rahat takaisin. Uutta tuotetta ei ole tullossa.
 

dun

Liittynyt
18.10.2016
Viestejä
503
Voi perse, ei ollut missään ironwolffeja, hommasin rikkoutuneen tilalle wd redin ja kävin hakemassa sen juuri. Mitä katselin benchmarkkeja, niin sequentaalisesti on hitaampi labraoloissa, mutta 4k read, write ja mixed on taas 10% nopsempia, niin tuosta ei pitäisi isoa hittiä tulla poolin suorituskykyyn, jos ollenkaan. Yleensähän noita ei kannata hirveästi mixailla ja mätsäillä kun hitaimman mukaan mennään, mutta n. 160 MB/s vs. ironwolffin 190MB/s ei ole mitään merkitystä jos vain latessit on lähellä toisiaan.

No mutta nyt harjoitellaan sitten pool1 (raidz2) => backup (mirror) => pool2(raidz2) siirtoa ja kun homma alkaa sujumaan niin pool1 ja pool2 tuhotaan ja sitten palautetaan backup=> pool1:lle (destroy => create 8 kpl, raidz2).
 

dun

Liittynyt
18.10.2016
Viestejä
503
Dodih, olipas jännä tulos. pool2 on aika paljon nopsempi kuin pool1. Ilmeisesti vapaan tilan määrä ja fragmentaatio vaikuttaa, koska en oikein keksi mikä muu voisi olla kyseessä.

pool1:
- 4 x ironwolf 5900rpm

pool2:
- 3 x ironwolf 5900rpm
- 1 x wd red 5400rpm

Bash:
# Pool 1 => pool 2
$ pv /pool1/opt/CentOS-8-x86_64-1905-dvd1.iso > /pool2/opt/CentOS-8-x86_64-1905-dvd1.iso
6,65GiB 0:00:10 [ 655MiB/s] [=====================================>] 100%

# Pool 1 => ssd
$ pv /pool1/opt/CentOS-8-x86_64-1905-dvd1.iso > /ssd/opt/CentOS-8-x86_64-1905-dvd1.iso
6,65GiB 0:00:07 [ 958MiB/s] [=====================================>] 100%

# Pool 2 => pool 1
$ pv /pool2/opt/CentOS-8-x86_64-1905-dvd1.iso > /pool1/opt/CentOS-8-x86_64-1905-dvd1.iso
6,65GiB 0:00:15 [ 439MiB/s] [=====================================>] 100%

# Pool 2 => ssd
$ pv /pool2/opt/CentOS-8-x86_64-1905-dvd1.iso > /ssd/opt/CentOS-8-x86_64-1905-dvd1.iso
6,65GiB 0:00:06 [ 976MiB/s] [=====================================>] 100%

## Rsyncillä sama
# Pool 1 => pool 2
$ rsync -avP /pool1/opt/CentOS-8-x86_64-1905-dvd1.iso_rsync /pool2/opt/CentOS-8-x86_64-1905-dvd1.iso_rsync
sending incremental file list
CentOS-8-x86_64-1905-dvd1.iso
  7,135,559,680 100%  270.64MB/s    0:00:25 (xfr#1, to-chk=0/1)

sent 7,137,301,891 bytes  received 35 bytes  279,894,193.18 bytes/sec
total size is 7,135,559,680  speedup is 1.00

# Pool 1 => ssd
$ rsync -avP /pool1/opt/CentOS-8-x86_64-1905-dvd1.iso_rsync /ssd/opt/CentOS-8-x86_64-1905-dvd1.iso_rsync
sending incremental file list
CentOS-8-x86_64-1905-dvd1.iso
  7,135,559,680 100%  287.47MB/s    0:00:23 (xfr#1, to-chk=0/1)

sent 7,137,301,891 bytes  received 35 bytes  291,318,445.96 bytes/sec
total size is 7,135,559,680  speedup is 1.00

# Pool 2 => pool 1
$ rsync -avP /pool2/opt/CentOS-8-x86_64-1905-dvd1.iso_rsync /pool1/opt/CentOS-8-x86_64-1905-dvd1.iso_rsync
sending incremental file list
CentOS-8-x86_64-1905-dvd1.iso
  7,135,559,680 100%  230.31MB/s    0:00:29 (xfr#1, to-chk=0/1)

sent 7,137,301,890 bytes  received 35 bytes  241,942,438.14 bytes/sec
total size is 7,135,559,680  speedup is 1.00

# Pool 2 => ssd
$ rsync -avP /pool2/opt/CentOS-8-x86_64-1905-dvd1.iso_rsync /ssd/opt/CentOS-8-x86_64-1905-dvd1.iso_rsync
sending incremental file list
CentOS-8-x86_64-1905-dvd1.iso
  7,135,559,680 100%  336.15MB/s    0:00:20 (xfr#1, to-chk=0/1)

sent 7,137,301,890 bytes  received 35 bytes  331,967,531.40 bytes/sec
total size is 7,135,559,680  speedup is 1.00
Mutta näillä mennään, eli WD red ei onneksi hidasta ainakaan mitenkään merkittävästi pakan toimivuutta ainakaan 4 levyllä.
 

andyks

Tukijäsen
Liittynyt
20.09.2018
Viestejä
109
Jos nyt ymmärsin oikein niin nopeampi pool1 on stripe+mirror ("raid10") ja hitaampi pool2 on raidz2?
Tottakai mirror on nopeampi.
Ei neljällä levyllä kannata raidz2 tehdä.
Tilan kannalta mirror ajaa saman asian ja mirroroidessa pariteettia ei tarvitse laskea, joten nopeus kasvaa.
Toki ehkä teoriassa raidz2 vikasietoisuus hieman parempi kun mitkä tahansa kaksi levyä saa hajota. Stripetussa mirrorissa saa hajota vain yksi levy per vdev kerrallaan. Mutta on jo aika huonoa tuuria että kaksi levyä samasta vdevistä hajoaa yhtaikaa. Ja taas kääntöpuolena Raidz2 rebuildissa uudet levyrikot ovat todennäköisempiä kun kaikki levyt tekevät töitä.
 

dun

Liittynyt
18.10.2016
Viestejä
503
Jos nyt ymmärsin oikein niin nopeampi pool1 on stripe+mirror ("raid10") ja hitaampi pool2 on raidz2?
Tottakai mirror on nopeampi.
Ei neljällä levyllä kannata raidz2 tehdä.
Tilan kannalta mirror ajaa saman asian ja mirroroidessa pariteettia ei tarvitse laskea, joten nopeus kasvaa.
Toki ehkä teoriassa raidz2 vikasietoisuus hieman parempi kun mitkä tahansa kaksi levyä saa hajota. Stripetussa mirrorissa saa hajota vain yksi levy per vdev kerrallaan. Mutta on jo aika huonoa tuuria että kaksi levyä samasta vdevistä hajoaa yhtaikaa. Ja taas kääntöpuolena Raidz2 rebuildissa uudet levyrikot ovat todennäköisempiä kun kaikki levyt tekevät töitä.
Ymmärsit väärin, molemmat oli raidz2. Erona oli kiintisten ikä, poolin käyttöaste (63% vs 0%) ja toisessa oli 3kpl ironwolffeja ja yksi red.

Nyt siis kakki levyt on pool1:ssä (7 x ironwolf + 1 wd red) ja restore käynnissä. Näyttää siltä että restore tulee n. 1h nopeammin valmiiksi kuin 4 x kiintiksen raidz2 poolille.
 
Liittynyt
30.10.2016
Viestejä
586
Mistä hankit tuon Supermicon? Vanhemmilta laukesi serveristä poweri, joka ilmeisesti vei emolevyn mukanaan, joten LGA775/DDR3-kamppeiden tilalle pitää keksiä jotain korvaavaa?
 

dun

Liittynyt
18.10.2016
Viestejä
503
Mistä hankit tuon Supermicon? Vanhemmilta laukesi serveristä poweri, joka ilmeisesti vei emolevyn mukanaan, joten LGA775/DDR3-kamppeiden tilalle pitää keksiä jotain korvaavaa?
Täältä: Hinnastot | Damicon Kraa Oy, palvelu oli hyvää, mutta keskittyvät enemmän b2b liiketoimintaan, niin kuluttaja-asiakkailta puuttuu melkein kokonaan infrastruktuuri. Maksutavatkin oli suora tilisiirto ennakkoon tai hakupäivänä tai vaihtoehtoisesti käteinen.

Helpoiten homma hoitui itsellä kun lähetin sähköpostia ja kysyin millä hinnalla myyvät xyz-komponentin. Itselle ei ollut ongelma, koska työnpuolesta joutuu b2b kauppojen kanssa olemaan tekemisissä, mutta se ei ole mikään verkkokauppa.com.

Edit: Löysin liikkeen kun kävin Supermicron maahantuojat läpi Suomen osalta ja tuo myi suoraan kuluttaja-asiakkaille. Hinta oli edullisempi kuin amazon.de:stä joten ei ollut kahta sanaa valinnan kanssa ja saa toimivan Suomi-takuun ja tarvittaessa voi pyörähtää liikkeessäkin.
 
Viimeksi muokattu:
Toggle Sidebar

Statistiikka

Viestiketjuja
80 411
Viestejä
1 637 954
Jäsenet
36 225
Uusin jäsen
matlok

Hinta.fi

Ylös Bottom