NAS rakentelut

  • Keskustelun aloittaja Keskustelun aloittaja dun
  • Aloitettu Aloitettu
Tämä olis kans vaihtoehto zfs:llä nyt kun on tullu painiskeltua Red hatin tuotteiden kanssa niin vois harkita ihan taas räpellyksen vuoksi. Melko sillisalaatilta vaikuttaa ja kehittämisen taustalla on ilmeisesti isona syynä, että Red Hat ei voi käyttää zfs:ää lisenssisyistä ja hylkäsi pari vuotta sitten btrfs:n syistä joita en ny muista ulkoa.
Btrfs:n hylkäämisen syy oli vaikeus. Btrfs yritti tehdä gnu lisenssillä saman mitä zfs, mutta se oli jatkuvasti jäljessä eikä tullut koskaan valmiiksi. Sama kohtalo tulee olemaan Stratis Storagella valitettavasti tai se tee samoja juttuja kuin ZFS. Jännä että RedHat näkee lisenssit eri tavalla kuin Canonical (joka mahdollistaa ZFS natiivin ajon kerneli moduleilla vs. RedHat).

Taitaa olla lopulta ego-ongelma kyseessä.

Edit: Huomiona siis että vapaan maailman RHEL7 tuo onnistuu helposti, esim. Centoksella joka sallii reposta asentaa kernelimodulit. Eli ongelma on puhtaasti RedHat (IBM) puolella.
 
Viimeksi muokattu:
Moro! Ajattelin että voisin nyt kesän aikana pystyttää jonkinlaisen mediaserveri-NAS:in ja voisin tarvita apua siihen että mitä lähden etsimään.

Vaatimuksia tai ajatuksia ei vielä oikeen löydy, pääasiassa vaan että tallennustilaa ajattelin alkuun ehkä 8 tb ja mielellään sen kannalta laajennettava järjestelmä. Minkäköhänlaisia osia kannattaisi pikkuhiljaa metsästää? Mietiskelin että ettisin levyt käytettynä esim täältä foorumilta, prossuksi voisi hankkia jonkun uuden Intelin kun eikös niissä ole se joku enkoodausydin? Jos on tarkempia tietäjiä prossuasioista niin kertokaa ihmeessä! Koteloksi harkittin mahollisesti Node 304 kun sinne mahtuu levyjä tosi hyvin. ITX-koko kuitenkin tuo varmaaan pientä lisähintaa emolevyyn niin siksi on vielä harkinnassa vaikka pientä kokoaa juurikin haluaisin. Budjettia sinänsä en ole miettinyt mutta mahdollisimman halvalla toivoisin pääsevän kuitenkin että täyttää toiveet eli periaatteessa 4k enkoodaus ja ainakin 8tb levytilaa.

Softa/käyttispuolikin on vielä ihan auki. Ehdotuksia simppeliin softaapuoleenkin otetaan ehdottomasti vastaan. Mediaserverihommiin olis siis ideana -arrit(sonarr, ...) ja nehän tosiaan tykkää dockerista eli se pitäisi saada pyörimään.

Eli kaikki suunnan näyttämiset otetaan mielellään vastaan :)
 
Moro! Ajattelin että voisin nyt kesän aikana pystyttää jonkinlaisen mediaserveri-NAS:in ja voisin tarvita apua siihen että mitä lähden etsimään.

Vaatimuksia tai ajatuksia ei vielä oikeen löydy, pääasiassa vaan että tallennustilaa ajattelin alkuun ehkä 8 tb ja mielellään sen kannalta laajennettava järjestelmä. Minkäköhänlaisia osia kannattaisi pikkuhiljaa metsästää? Mietiskelin että ettisin levyt käytettynä esim täältä foorumilta, prossuksi voisi hankkia jonkun uuden Intelin kun eikös niissä ole se joku enkoodausydin? Jos on tarkempia tietäjiä prossuasioista niin kertokaa ihmeessä! Koteloksi harkittin mahollisesti Node 304 kun sinne mahtuu levyjä tosi hyvin. ITX-koko kuitenkin tuo varmaaan pientä lisähintaa emolevyyn niin siksi on vielä harkinnassa vaikka pientä kokoaa juurikin haluaisin. Budjettia sinänsä en ole miettinyt mutta mahdollisimman halvalla toivoisin pääsevän kuitenkin että täyttää toiveet eli periaatteessa 4k enkoodaus ja ainakin 8tb levytilaa.

Softa/käyttispuolikin on vielä ihan auki. Ehdotuksia simppeliin softaapuoleenkin otetaan ehdottomasti vastaan. Mediaserverihommiin olis siis ideana -arrit(sonarr, ...) ja nehän tosiaan tykkää dockerista eli se pitäisi saada pyörimään.

Eli kaikki suunnan näyttämiset otetaan mielellään vastaan :)

Jos kasaa NAS-boksin itse, levyjen määrää rajoittaa lähinnä käytetty kotelo, ja siinä mielessä ITX on juurikin huono idea. Lisäksi NAS-boksin koolla ei ole periaatteessa niin väliä, jos sen saa vaikka sohvan taakse piiloon, tai jotain. :)

Periaatteessa yhdellekin levylle saa 8Tt tavaraa, mutta käytännössä NASsiin haluaa jonkinlaisen raidin varmistukseksi. Raid1 hoituu kahdella 8Tt levyllä, mutta tällöin puolet tallennustilasta menee hukkaan. Raid5 (tai raidz1 ZFS:ää käytettäessä) kolmella 4Tt levyllä tulee halvemmaksi.

En ole kauhean hyvin perillä 4k-hommista, mutta ymmärtääkseni siihen ei tarvi olla aivan uutta inteliä. Jonkinlainen integroitu GPU vissiin on kuitenkin tarpeellinen.
 
Koteloksi harkittin mahollisesti Node 304 kun sinne mahtuu levyjä tosi hyvin.

Jos käytetty on vaihtoehto, niin myynti alueelta löytyy mini-itx nas-kotelo. Tuossa on 8x hot-swap paikkaa 3.5" levyille etuoven takana ja lisäksi sisällä 4x2.5" paikat vaikka käyttislevyille.

 
Jos käytetty on vaihtoehto, niin myynti alueelta löytyy mini-itx nas-kotelo. Tuossa on 8x hot-swap paikkaa 3.5" levyille etuoven takana ja lisäksi sisällä 4x2.5" paikat vaikka käyttislevyille.

En jaksa linkata, mutta netissä on ollut juttua että ilman kierto tuossa on heikko ja on suositeltu jotain pahvia koteloon ohjaamaan ilmavirran levyille. Lisäksi tuulettimet voi vaihtaa arcticin p12 tuulettimiin. Niitä saa 5 kpl 28 € ja yksittäin 7 €.

Alla vielä tuon kotelon tuulettimien specsit

Screenshot_20220603-000539_Outlook.jpg


Ja vertailun vuoksi alle vielä p12:

Screenshot_20220603-000843_Chrome.jpg


Voin sanoa että nää arcticin p12 tuulettimet ovat hiljaisia jopa täysillä.
 
En jaksa linkata, mutta netissä on ollut juttua että ilman kierto tuossa on heikko ja on suositeltu jotain pahvia koteloon ohjaamaan ilmavirran levyille. Lisäksi tuulettimet voi vaihtaa arcticin p12 tuulettimiin. Niitä saa 5 kpl 28 € ja yksittäin 7 €.

Alla vielä tuon kotelon tuulettimien specsit

Screenshot_20220603-000539_Outlook.jpg


Ja vertailun vuoksi alle vielä p12:

Screenshot_20220603-000843_Chrome.jpg


Voin sanoa että nää arcticin p12 tuulettimet ovat hiljaisia jopa täysillä.
Ihan riittävä ilmankierto kaikki 2,5" ja 3,5" väylät täynnä tavaraa kotelon mukanaa tulevilla tuulettimilla (ovat äänettömiä). Ei tarvitse tehdä mitään, levyt pysyy alle tarvitun 45c lämpötilassa ja silloin esim. Seagaten Ironwolf pysyy nätisti hengissä vähintään 5 vuottaa (takuuajan) ja sen jälkeen olisi hyvä katsella uusia levyjä tai ottaa tarpeeksi kiekkoja kaapin pohjalle lepäämään kun levyt alkaa rikkoutua yksi - kaksi kerrallaan (yleensä kestää 8-10 vuotta ennen kuin leviää).

Suositus DS380 omasta kokemukesta on aina raid6 (raidz2) ja tietenkin ZFS, mutta jos on masokisti niin muutakin saa käyttää.

Tuo kotelo on muuten sitten ihan superpaljon hiljaisempi kuin HPe Microserverit äänekkäämäkin levyillä (itsellä löytyy gen10+ joka hoitaa snapshot backupit ds380stä joka on pääserveri/nas), joten en voi kuin suositella.

Jos mini-itx ei ole sun juttu, niin sit kandeekin mennä suoraan räck-serveri asennukseen, isommalla määrällä levyjä, koska perus ATX kopan hommaaminen on vähän tylsä vaihtoehto kun ei ole kelkkoja edessä ilman kalliita virityksiä 5.25" paikkoihin. Mutta hommaa koppa joka mielyttää silmää ja josta löytyy kapasiteettia emolevylle + tarvitulle määrälle levyjä.
 
Jos mini-itx ei ole sun juttu, niin sit kandeekin mennä suoraan räck-serveri asennukseen, isommalla määrällä levyjä, koska perus ATX kopan hommaaminen on vähän tylsä vaihtoehto kun ei ole kelkkoja edessä ilman kalliita virityksiä 5.25" paikkoihin. Mutta hommaa koppa joka mielyttää silmää ja josta löytyy kapasiteettia emolevylle + tarvitulle määrälle levyjä.

Pilkunviilauksena sen verran että eipä noi levyt niin usein hajoile, että perus-ATX koppa haittaisi isommin menoa. Samoin silmän miellyttämisen merkitys on vähän niin ja näin, ellei sitä ole nimenomaan tarkoitus laittaa esille. ;)
 
Jos mini-itx ei ole sun juttu, niin sit kandeekin mennä suoraan räck-serveri asennukseen, isommalla määrällä levyjä, koska perus ATX kopan hommaaminen on vähän tylsä vaihtoehto kun ei ole kelkkoja edessä ilman kalliita virityksiä 5.25" paikkoihin. Mutta hommaa koppa joka mielyttää silmää ja josta löytyy kapasiteettia emolevylle + tarvitulle määrälle levyjä.

Itse ehkä neuvoisin tutkimaan vaihtoehtona jonkun Define R7:n tuollaiselle Rack-kotelolle. Rack-kotelot ovat tietenkin se "paras" vaihtoehto, mutta mielestäni vain silloin, kun on tarkoitus hankkia myös se rack. Ilman sitä nuo kotelot ovat käyttömukavuudeltaan aika huonoja ja resonoivat aika komeasti, jos makaavat vain lattialla (ainakin omat koteloni niin tekivät). Perus ATX-kotelo kun on suunniteltu toimimaan itsenäisesti, niin sen käytettävyys on aina melko hyvä vaikka niistä ei HDD-kelkkoja löydykkään.

Mutta tietenkään mikään ei voita rackia, kiskoja ja hyvää rack-koteloa. Tuota on ihan ilo sorvata verrattuna oman pöytäkoneen (TJ08-E) kotelon pyörittelyyn. Minulla nyt on tuossa 12U Rackissa kaikkea muutakin, niin saan sen avulla kivasti laitteet organisoitua. Jos rakentaisin pelkkää NAS:ia, niin en lähtisi kuitenkaan tälle linjalle.
 
Ihan riittävä ilmankierto kaikki 2,5" ja 3,5" väylät täynnä tavaraa kotelon mukanaa tulevilla tuulettimilla (ovat äänettömiä). Ei tarvitse tehdä mitään, levyt pysyy alle tarvitun 45c lämpötilassa ja silloin esim. Seagaten Ironwolf pysyy nätisti hengissä vähintään 5 vuottaa (takuuajan) ja sen jälkeen olisi hyvä katsella uusia levyjä tai ottaa tarpeeksi kiekkoja kaapin pohjalle lepäämään kun levyt alkaa rikkoutua yksi - kaksi kerrallaan (yleensä kestää 8-10 vuotta ennen kuin leviää).

Suositus DS380 omasta kokemukesta on aina raid6 (raidz2) ja tietenkin ZFS, mutta jos on masokisti niin muutakin saa käyttää.

Tuo kotelo on muuten sitten ihan superpaljon hiljaisempi kuin HPe Microserverit äänekkäämäkin levyillä (itsellä löytyy gen10+ joka hoitaa snapshot backupit ds380stä joka on pääserveri/nas), jote
Tuossa ylikuumentumista:

Lämmöt 55 ja yhdellä levyllä jopa 61.
 
Tuossa ylikuumentumista:

Lämmöt 55 ja yhdellä levyllä jopa 61.
Ok, ilmeisesti huonommat levyt siis tai huonompi paikka? Itsellä on talvella 43-44c, kesällä 45-46c. Että en oikein tiedä mitä tuohon nyt sitten sanoisi muuta kuin että ehkä joku ajaa tota eri tavalla? Itsellä on todella hiljaiset tuulettimet tuossa, ääntä ei kuule samassa huoneessa ja kiintisten rasahtelutkin peittyy hyvin.

Koodi:
$ sudo hddtemp /dev/sd[a-h]
/dev/sda: ST4000VN008-2DR166: 45°C
/dev/sdb: ST4000VN008-2DR166: 46°C
/dev/sdc: ST4000VN008-2DR166: 46°C
/dev/sdd: ST4000VN008-2DR166: 43°C
/dev/sde: ST4000VN008-2DR166: 46°C
/dev/sdf: ST4000VN008-2DR166: 45°C
/dev/sdg: ST4000VN008-2DR166: 47°C
/dev/sdh: ST4000VN008-2DR166: 45°C
 
Ok, ilmeisesti huonommat levyt siis tai huonompi paikka? Itsellä on talvella 43-44c, kesällä 45-46c. Että en oikein tiedä mitä tuohon nyt sitten sanoisi muuta kuin että ehkä joku ajaa tota eri tavalla? Itsellä on todella hiljaiset tuulettimet tuossa, ääntä ei kuule samassa huoneessa ja kiintisten rasahtelutkin peittyy hyvin.

Koodi:
$ sudo hddtemp /dev/sd[a-h]
/dev/sda: ST4000VN008-2DR166: 45°C
/dev/sdb: ST4000VN008-2DR166: 46°C
/dev/sdc: ST4000VN008-2DR166: 46°C
/dev/sdd: ST4000VN008-2DR166: 43°C
/dev/sde: ST4000VN008-2DR166: 46°C
/dev/sdf: ST4000VN008-2DR166: 45°C
/dev/sdg: ST4000VN008-2DR166: 47°C
/dev/sdh: ST4000VN008-2DR166: 45°C
Joo, ympäristöllä on iso merkitys. Kaikilla ei ole sitä ylellisyyttä, että huoneen lämpötila on aina alta 25. Kerrostaloissa ihan suomessa kesällä voi huoneen lämpötila pahimmillaan lähennellä 30 astetta ja jossain Texasasissa 35-40 astetta ei ole mikään mahdottomuus. Ehkä mä olin vähän turhaan huolissani noista lämmöistä, mutta tässä konkurssissa(levyt + kone) tuulettimien vaihto on täysin kustannuksiltaan täysin olematon ja pahvi oli helppo laittaa ohjaamaan ilmaa. Ilkeämpää se nas on purkaa lämpötilojen takia. Ei vara venettä kaada.
 
Ajattelin oman palvelimen käyttiksen siirtää peilatuille SSD-levyille nyt kun alkuperäinen SSD on jo ollut käytössä muutaman vuoden. Suunnitelma olisi siis ostaa kaksi uutta SSD:tä, laittaa Mirroriin/Raid1:een, asentaa käyttis ja palauttaa kaikki ennalleen backupin kautta.

Vaihtoehtoja toteutukselle olisi pari. Yksi olisi Root on ZFS, mutta tämä taitaa olla melko vähän suositeltu uutuutensa vuoksi. Toinen olisi sitten Ubuntun mdraid.

Tuleeko mieleen mahdollisia sudenkuoppia tai muita hyviä toteutusvaihtoehtoja? Olen aika vahvasti kallellaan mdraidiin (Raid1-konfiguraatiossa). Ajattelin tosiaan alkuperäisen OS SSD:n pitää hommasta erillään myös siksi, että jos kaikki menee reisille, niin saan palvelimen pystyyn vain vaihtamalla käyttislevyä.
 
Itsellä on backup serverin rakentaminen ollut hetken mielessä. Mitään valokuvia ja videoita tärkeämpää ei nykyisessä Truenas pohjaisessa nassissa ole. Lähinnä datan säilömisen ja opiskelun halusta aiheeseen.

Varsinainen NAS on Proxmox päällä pyörivä Truenas muiden virtuaalikoneiden kanssa (levyt 4x 4Tb Z2). Backup käyttöön meinaan laittaa Truenas pyörimään suoraan raudalla (i3-4xxxT, 8GB, LSI 3x 3Tb Z1). Kovot sen takia 3 teraisia, kun löytyvät hyllystä valmiiksi. Ajatus kierrättää nykyisen nassin kovot tänne, jos suurennan niitä joskus. Toki pari 120GB ssd boottilevyksi. Rauta sen takia tuollaista, kun löytyy hyllystä valmiina ja tuo low power cpu (35W) on plussaa.

Tai olisiko fiksumpi vaihtoehto lisätä nuo 3 levyä edellisten kaveriksi LSI kortille ja tehdä backupit sinne?

Mitä mieltä? Onko joku selvä pullonkaula tai ongelma? Toinen kone tulee lopullisessa sijainnissaan olemaan ainakin tällä hetkellä gigaisen verkon päässä.
 
Viimeksi muokattu:
Yllättävän hyvin toiminut tuo viimevuonna rakentamani UNRAID tolla ASRock J4105-ITX emolevyllä jossa integroitu 2 core celeroni.

8GB ram
6kpl 4TB IronWolf joista 2 levyä toimii parity levyinä.
Lisäksi tuossa pyörii Windows 10 VM jossa TeamViewer etäkäyttöä varten sekä Plex serveri elokuvien striimaamista varten eikä ole ollut suorituskykyongelmia vaikka ei tuossa potkua löydy nimeksikään.

Seuraava parannus voisi olla esim 1TB Cache asema, eikö tällä saisi siirtonopeuksiin lisää vauhtia?
Pari vuotta pyörinyt tuolla ASRock J4105-ITX emolevyllä ja päivitin nyt i3-10100 4-core systeemiin, videoiden hakunopeus parantui huomattavasti ja myös tiedostojen siirtonopeudet nousi 45-60 MB/s laineilevasta vauhdista tasaiseen 112 MB/s nopeuteen, selkeästi olisi alunperin kannattanut laittaa vähän parempaa rautaa nassiin. Tarvitsin myös vapaan PCIE slotin että saan tulevaisuudessa 10GB ethernet kortin kiinni, tuossa vanhassa m-itx levyssä oli vain 1 slotti ja siinä käytössä SATAIII lisäkortti joten senkin takia olisi alunperin pitänyt laittaa ATX buildi, helppo olla jälkiviisas.
 
mdraidille on paljon howto-ohjeistuksia ja esimerkkejä, miten se kannattaa tehdä. Esim:

Itse kokeilisin asennuksen lopuksi käynnistää serverin ilman toista ssd-asemaa, eli testaisin, että kumpikin SSD on varmasti buuttaava, jos jonain päivänä tilanne tulee oikeasti eteen.

Noniin sain tämän nyt testailtua ja kiitos tuosta nostosta, ei olisi varmaan heti asennusvaiheessa tullut mieleen testata. Tuli testattua ja toimi kuten pitikin, boottasi normaalisti.

Mdadm:llä toteutin Raid1:en ja homma meni pääosin hyvin. Ohjeistusta seuraten tein osioinnit kuntoon, asensin käyttiksen ja palautin backupista. Kaikki siis meni ihan suunnitellusti. Tosin, muutama pieni ongelmakohta nousi eteen ja tässä niitä listattuna alle jos vastaava setup kiinnostaa.
  • Tee hyvät backupit, mielellään vaikka useamalla eri ohjelmalla, jos haluat palauttaa käyttiksen entiselleen helposti. Tein itse backupit ensin Dejadupilla ja sitten varmuuden vuoksi vielä Back-in-timellä. Dejadupin palautus ei sitten toiminutkaan ja kaatui viestillä Unknown error. Back-in-time pelasti oman päiväni.
  • Aloita migraatio siten, että vanha levy on vielä kiinni koneessa, jos mahdollista. Itse jouduin ZFS:n takia vielä hyppäämään pari kertaa vanhan levyn puolelle mm. exportaamaan poolit.
    • ZFS:n kanssa ole vielä tarkkana jos ajat zfs-utilsin uudempia 2.x versioita. Minulla kesti hetki keksiä miten saan importattua vanhan ZFS 2.*:een upgradetun poolin, kun käyttiksen mukana tulee edelleen 0.8.4-versio. Ei iso homma, mutta vaati yhden lisäpaketin asennuksen ja boottauksen.
  • Jos käytät Public Key Authenticationia SSH:n kanssa ja koneestasi ei löydy IPMI:ä, niin varmista että et lukitse itseäsi koneelta ulos missään vaiheessa. Uutta käyttistä alustaessa voi asentaa OpenSSH:n ilman aiempia asetuksia, mutta minulla ainakin yhdistävät laitteet herjasivat muuttuneesta fingerprintistä eivätkä suostuneet yhdistämään. Tämä korjautui minulla väliaikaisesti muokkaamalla SSH-konfiguraatiota käyttämään salasanatunnistautumista ja tilanne palautui normaaliksi backupien palauttamisen kautta.
Siinäpä nuo suurimmat ongelmat oikeastaan. Omalla kohdalla mikään näistä ei ollut erityisen vakava, koska osasin jokseenkin varautua näihin kaikkiin. Olen aiemminkin ollut ongelmissa Dejadupin kanssa ja tiesin, että siihen ei täysin kannata luottaa. Samaten olen aiemminkin tapellut poolien importien kanssa, migraatioiden yhteydessä ja Public Key Authentication on harvoin suuri ongelma, jos koneelta löytyy IPMI. Mutta en kyllä tiedä olisiko oma osaaminen tähän operaatioon riittänyt pari vuotta sitten. Kyllä tuossa on monta kohtaa, jossa saa käyttiksen jumiin tai lukittua itsensä täysin ulos.

Kokeilin tässä samassa yhteydessä alustavasti tuota Root on ZFS asennusta ja kyllä se kovin keskeneräiseltä tuntuu. Käyttis asentuu hyvin, mutta toisen levyn lisääminen ei sitten onnistukaan ihan ohjeiden mukaisesti (ainakaan minulta). En viitsinyt itse jäädä kokeilemaan, kun ei helposti homma mennyt. Jo pelkästään snapshotit olisivat olleet riittävän suuri etu minulle Root on ZFS valitsemiseen, mutta tuo keskeneräinen vaikutelma kyllä karkotti tehokkaasti.
 
Sivukysymyksenä onko Unraidissa jotain mitä muihin NAS käyttiksiin tai perus linux palvelimeen ei saisi? RAID toteutus on Unraidin oma, mutta onko esim. apps / plugings puolella muuta kuin uudelleen paketoitus opensource sovelluksia?
 
  • Jos käytät Public Key Authenticationia SSH:n kanssa ja koneestasi ei löydy IPMI:ä, niin varmista että et lukitse itseäsi koneelta ulos missään vaiheessa. Uutta käyttistä alustaessa voi asentaa OpenSSH:n ilman aiempia asetuksia, mutta minulla ainakin yhdistävät laitteet herjasivat muuttuneesta fingerprintistä eivätkä suostuneet yhdistämään. Tämä korjautui minulla väliaikaisesti muokkaamalla SSH-konfiguraatiota käyttämään salasanatunnistautumista ja tilanne palautui normaaliksi backupien palauttamisen kautta.

Esim. puttyssä tulee ikkuna, joka vaan varoittaa että sormenjälki on muuttunut, ja jossa voi valita että yhdistää kumminkin. Linuxin komentorivi-ssh taitaa kyllä vaatia sen, että vanha avain poistetaan ennen kuin se suostuu ottaan yhteyttä, mutta ei sormenjäljen muuttumisella saa lukittua itseään ulos.
 
Esim. puttyssä tulee ikkuna, joka vaan varoittaa että sormenjälki on muuttunut, ja jossa voi valita että yhdistää kumminkin. Linuxin komentorivi-ssh taitaa kyllä vaatia sen, että vanha avain poistetaan ennen kuin se suostuu ottaan yhteyttä, mutta ei sormenjäljen muuttumisella saa lukittua itseään ulos.

Joo totta, samaten Termius antaa vaihtoehdon päivittää fingerprintin omalla vastuulla, mutta esimerkiksi suoraan cmd:tä käyttämällä ei tuollaista promptia tule. Siihen itse viittasin, olisi pitänyt tarkentaa. Tuonkin saisi varmaan kierrettyä, mutta itsellä ei ollut tarvetta.
 
Joo totta, samaten Termius antaa vaihtoehdon päivittää fingerprintin omalla vastuulla, mutta esimerkiksi suoraan cmd:tä käyttämällä ei tuollaista promptia tule. Siihen itse viittasin, olisi pitänyt tarkentaa. Tuonkin saisi varmaan kierrettyä, mutta itsellä ei ollut tarvetta.

Ne avaimet tosiaan on tallessa tiedostossa ~/.ssh/known_hosts. Sen kun poistaa tai editoi oikean rivin pois, niin alkaa pelittää.
 
Tätä on varmaankin aiemminkin käsitelty täällä mutta kaipaisin silti vielä rautalankaa.

Minulla pyörii tällä hetkellä freenas palvelin jossa on 6x 10tb levyä raidz2 konfiguraatiossa ja tila alkaa käymään ahtaaksi.
Tämän kaiken datan siirto muualle ja uuden poolin rakentaminen uusilla levyillä ei tunnu oikein hyvältä ratkaisulta (ei toki täysin poissuljettu), kun dataa olisi kuitenkin kymmeniä teroja väliaikais säilöttäväksi.

Ilmeisesti levyt voisi yksitellen vaihtaa suuremmiksi ja tehdä välissä resilverin ja kaikkien levyjen ollessa vaihdettuna pooli kasvaisi vastaamaan uutta kokoa eli esim 16gb levyillä 40tb -> 64tb.

Kuitenkin ajatus 8 levyn poolsita houkuttaa kokoajan enemmän jo senkin takia, että raidz2 konffilla saisi kuuden levyn kapasiteetin käyttöön ja todennäköisesti nuo kaksi parieettilevyä riittäisi vielä vallan hyvin. Onko levyjen lisääminen mitenkään järkevästi mahdollista nykyisessä tilanteessa?
 
Ne avaimet tosiaan on tallessa tiedostossa ~/.ssh/known_hosts. Sen kun poistaa tai editoi oikean rivin pois, niin alkaa pelittää.

Kantsii tehdä sinne .ssh hakemistoon config tiedosto ja sisällöksi hitain tyyliin:
Koodi:
cat /home/jiipee/.ssh/config
Host 10.*.*.*
   StrictHostKeyChecking no
   UserKnownHostsFile=/dev/null

Host 192.168.*.*
   StrictHostKeyChecking no
   UserKnownHostsFile=/dev/null

Tuon jälkeen ei enää natise avaimista.
 
Tätä on varmaankin aiemminkin käsitelty täällä mutta kaipaisin silti vielä rautalankaa.

Minulla pyörii tällä hetkellä freenas palvelin jossa on 6x 10tb levyä raidz2 konfiguraatiossa ja tila alkaa käymään ahtaaksi.
Tämän kaiken datan siirto muualle ja uuden poolin rakentaminen uusilla levyillä ei tunnu oikein hyvältä ratkaisulta (ei toki täysin poissuljettu), kun dataa olisi kuitenkin kymmeniä teroja väliaikais säilöttäväksi.

Ilmeisesti levyt voisi yksitellen vaihtaa suuremmiksi ja tehdä välissä resilverin ja kaikkien levyjen ollessa vaihdettuna pooli kasvaisi vastaamaan uutta kokoa eli esim 16gb levyillä 40tb -> 64tb.

Kuitenkin ajatus 8 levyn poolsita houkuttaa kokoajan enemmän jo senkin takia, että raidz2 konffilla saisi kuuden levyn kapasiteetin käyttöön ja todennäköisesti nuo kaksi parieettilevyä riittäisi vielä vallan hyvin. Onko levyjen lisääminen mitenkään järkevästi mahdollista nykyisessä tilanteessa?
Tätä odotellessa, pitkä ja kivinen tie on ollut: RAID-Z Expansion Feature for ZFS In the Home Stretch | FreeBSD Foundation

Eli Q3/2022 olisi nyt kai release aikataulu tolle, mutta saa nähdä, sitä on lupailtu jo niin kauan että huh huh. Itse tein oman 4 levyn => 8 levyn siirron 2020 sitten ostamalla kylmästi vain lisää levyjä ja rautaa. Vanha NAS 4 levyllä meni vanhemmille varmuuskopio-asemaksi kun olin siirtänyt tavaran vanhalta uudelle.

Sen jälkeen hommasin vielä HPe Microserver Gen 10 + vekottimen johon laitoin z1 4 tuplakokoista levyä ottamaan snapshot backupit pääpavelimelta (jonne tuuppaan parista nassista tavarat säilöön 3-2-1 periaatteella omasta kotoa ja sukulaisilta ettei niiden tärkeät valokuvat katoa.
 
Tätä odotellessa, pitkä ja kivinen tie on ollut: RAID-Z Expansion Feature for ZFS In the Home Stretch | FreeBSD Foundation

Eli Q3/2022 olisi nyt kai release aikataulu tolle, mutta saa nähdä, sitä on lupailtu jo niin kauan että huh huh. Itse tein oman 4 levyn => 8 levyn siirron 2020 sitten ostamalla kylmästi vain lisää levyjä ja rautaa. Vanha NAS 4 levyllä meni vanhemmille varmuuskopio-asemaksi kun olin siirtänyt tavaran vanhalta uudelle.

Sen jälkeen hommasin vielä HPe Microserver Gen 10 + vekottimen johon laitoin z1 4 tuplakokoista levyä ottamaan snapshot backupit pääpavelimelta (jonne tuuppaan parista nassista tavarat säilöön 3-2-1 periaatteella omasta kotoa ja sukulaisilta ettei niiden tärkeät valokuvat katoa.

Toimiihan tuo levyjen korvaaminen kuitenkin kuvatusti, eli voisin päivittää 6 levyä suuremmiksi ja tällöin voisin ottaa vanhoille levyille tiedot talteen vaikka usb-telakan kautta ja lopuksi tehdä kokonaan uuden asennuksen kahdeksalla isommalla levyllä?

Tämä lienisi järkevin tapa hoitaa päivitys.

Muuten ei viitsisi uuteen rautaan sijoittaa, kun nykyinen setti on vasta kolme vuotta vanha ja kostuu kuitenkin supermicrosta ja xeonista, jolla uskon käyttöikää näinkin kevyessä käytössä riittävän.

Näin jälkikäteen harmittaa, että nuukuus iski kuuden levyn kohdalla, kun kahdeksalle olisi tilat.
 
Toimiihan tuo levyjen korvaaminen kuitenkin kuvatusti, eli voisin päivittää 6 levyä suuremmiksi ja tällöin voisin ottaa vanhoille levyille tiedot talteen vaikka usb-telakan kautta ja lopuksi tehdä kokonaan uuden asennuksen kahdeksalla isommalla levyllä?

Tämä lienisi järkevin tapa hoitaa päivitys.

Muuten ei viitsisi uuteen rautaan sijoittaa, kun nykyinen setti on vasta kolme vuotta vanha ja kostuu kuitenkin supermicrosta ja xeonista, jolla uskon käyttöikää näinkin kevyessä käytössä riittävän.

Näin jälkikäteen harmittaa, että nuukuus iski kuuden levyn kohdalla, kun kahdeksalle olisi tilat.
Toimii, ei ole onelmaa sen kanssa. Mutta varmista nyt kuitenkin että tärkeistä tiedostoista on backup jossain muuallakin, koska jos jotain menee pieleen (yleensä menee). Nimimerkillä eka nas meni ruvelle kun aloin nuukailla backup-varaston kanssa ja onnistuin jotenkin tuhoamaan itseltä tärkeitä kuvia ison nipun kun onnistuin tuhomaan kaikki 3 lokaatiota tilan puuteen takia ja sitten se yksi paikka jossa oli muka turvassa meni ruvelle).

Eli joko odotat kiltisti että tulee toi päivitys ja otat sen käyttöön (se tulee halvalla koska tarvitset vain 2 uutta levyä, nämä voi olla isompiakin kuin 10tb jos tarkoitus on joskus kasvattaa nuo 6 levyä isommaksi) tai uusi "backup" nas jonne tuuppaat nykyiseltä nassilta tärkeät tiedot talteen siksi aikaa kun lisäät levyjä? 35 Teraa raaka-dataa on kuitenkin aika iso säilöminen väliaikaisesti.

En tiedä olisiko AWS S3 tai glacier vaihtoehto jos siirtäisit hetkellisesti turvaan sinne ja sitten ottaisit takaisin kun pooli olisi jälleenrakennettu täydelle määrälle levyjä? Tulee varmasti halvemmaksi kuin uusi rauta. Tosin tiedostonsiirto S3 edes takaisin tulee olemaan sitten kohtuu pitkä urakka riippuen mikä sun nettiyhteyden uppinopeus on.

Edit:
Nopea laskutoimitus S3 Tukholmaan maksaisi n. 800-900 USD per kk, eli halpaa ei sekään ole.
 
Toimii, ei ole onelmaa sen kanssa. Mutta varmista nyt kuitenkin että tärkeistä tiedostoista on backup jossain muuallakin, koska jos jotain menee pieleen (yleensä menee). Nimimerkillä eka nas meni ruvelle kun aloin nuukailla backup-varaston kanssa ja onnistuin jotenkin tuhoamaan itseltä tärkeitä kuvia ison nipun kun onnistuin tuhomaan kaikki 3 lokaatiota tilan puuteen takia ja sitten se yksi paikka jossa oli muka turvassa meni ruvelle).

Eli joko odotat kiltisti että tulee toi päivitys ja otat sen käyttöön (se tulee halvalla koska tarvitset vain 2 uutta levyä, nämä voi olla isompiakin kuin 10tb jos tarkoitus on joskus kasvattaa nuo 6 levyä isommaksi) tai uusi "backup" nas jonne tuuppaat nykyiseltä nassilta tärkeät tiedot talteen siksi aikaa kun lisäät levyjä? 35 Teraa raaka-dataa on kuitenkin aika iso säilöminen väliaikaisesti.

En tiedä olisiko AWS S3 tai glacier vaihtoehto jos siirtäisit hetkellisesti turvaan sinne ja sitten ottaisit takaisin kun pooli olisi jälleenrakennettu täydelle määrälle levyjä? Tulee varmasti halvemmaksi kuin uusi rauta. Tosin tiedostonsiirto S3 edes takaisin tulee olemaan sitten kohtuu pitkä urakka riippuen mikä sun nettiyhteyden uppinopeus on.

Edit:
Nopea laskutoimitus S3 Tukholmaan maksaisi n. 800-900 USD per kk, eli halpaa ei sekään ole.
Hyviä pointteja.
Nettiyhteys ei kyllä käytännössä mahdollista koko NAS:n pilveen lähettämistä tai takaisin lataamista.
Myöskin ns. elintärkeää dataa tuolla on loppujenlopuksi aika vähän ja sen backupit onkin suht hyvin kunnossa. (aina voisi ja pitäisi parantaa.)
 
Hyviä pointteja.
Nettiyhteys ei kyllä käytännössä mahdollista koko NAS:n pilveen lähettämistä tai takaisin lataamista.
Myöskin ns. elintärkeää dataa tuolla on loppujenlopuksi aika vähän ja sen backupit onkin suht hyvin kunnossa. (aina voisi ja pitäisi parantaa.)
No, sitten halvin mitä mä ehkä tekisin olisi kaivaa jostain vanha emo+prossu ja muistia. Asentaa freenas/truenas ja lyödä 3 kpl z1:een jompia kumpia:
* Seagate Enterprise Exos X20 20TB
* Western Digital Ultrastar DC HCS560 20TB

Suomesta ostettuna on n 415-450€ kpl, eli kustantaa n. 1500€.

Näin saisit 40TB (35TB käytettävää) tilaa eli saman verran kuin tuo sinun 40TB z2 pakka (4 x 10TB). Toki tarviit sitten vielä 2 kpl 10TB levyjä jotta saat tehtyä uuden 8 x 10TB z2 pakan.

Toinen vaihtoehto on että odottelet tota ominaisuutta ja ostat 2 kpl 10TB levyjä lisää ja teet ton reflown. Mä ehkä sinuna odottelisin sitä...
 
En muista onko virtalähteiden hyötysuhteista puhuttu täällä aiemmin, mutta onko kukaan nähnyt missään hyvän hyötysuhteen omaavia pienitehoisia virtalähteitä?

Ilmeisesti virtalähteiden hyötysuhde kyykkää pienellä kuormalla, jolloin NAS-käytössä pienitehoinen virtalähde olisi järkevämpi. Esim. mulla mitatessa NASsin idleteho oli 67W ja maksimi noin 130W...

Tätä odotellessa, pitkä ja kivinen tie on ollut: RAID-Z Expansion Feature for ZFS In the Home Stretch | FreeBSD Foundation

Eli Q3/2022 olisi nyt kai release aikataulu tolle, mutta saa nähdä, sitä on lupailtu jo niin kauan että huh huh. Itse tein oman 4 levyn => 8 levyn siirron 2020 sitten ostamalla kylmästi vain lisää levyjä ja rautaa.

Joskus aiemmin asiaan tutustuessa ymmärsin että reflow toimisi vain uudelle datalle, eikä vanhalta datalta saisi tilaa vapaaksi. Onko tilanne muuttunut sen jälkeen?
 
En muista onko virtalähteiden hyötysuhteista puhuttu täällä aiemmin, mutta onko kukaan nähnyt missään hyvän hyötysuhteen omaavia pienitehoisia virtalähteitä?

Ilmeisesti virtalähteiden hyötysuhde kyykkää pienellä kuormalla, jolloin NAS-käytössä pienitehoinen virtalähde olisi järkevämpi. Esim. mulla mitatessa NASsin idleteho oli 67W ja maksimi noin 130W...



Joskus aiemmin asiaan tutustuessa ymmärsin että reflow toimisi vain uudelle datalle, eikä vanhalta datalta saisi tilaa vapaaksi. Onko tilanne muuttunut sen jälkeen?
Kannattaa lukea tuo artikkeli ajatuksella, mutta reflow sijoittaa "vanhat" blokit vain uusien levyjen sisälle ja sitten lopuksi tekee uutta tyhjää tilaa kaikille levyille. Eli blokkitasolla tietojen järjestys vain ei ole yhtä tasainen kuin aikaisemmin.

ks. kuva artikkelista. Eli jos menettää levyn 1,2,3,4 tai 5, niin ei koskaan menetä kahta "palikkaa" kerralla vaan edelleen jokainen palikka on erillisellä levyllä.
1657748460767.png
 
Täällä kun on nyt ollut puhetta pooleista ja on ollut esillä vähän kaikkia ratkaisuja niin hiukan omia mietteitä aiheesta ja myös kokemuksia.

MergerFS + Snapraid oli ittellä käytössä tovin. Se on ajatuksena ihan näppärä mutta ei ongelmaton. Vahvuutena on nimenomaan se että jos tulee katastrofi tilanne ja pari levyä hojaa ja on yksi pariteetti, niin silti ei menetä kaikkea. Mutta ongelmina on pääasiassa suorituskyky koska yhden kovalevyn luku/kirjoitusnopeus riittää nippa nappa gigaselle verkolle ja kaikilla levyillä ei edes siihen kun mennään sinne levyn sisäkehälle jolloin suorituskyky on paljon huonompi kuin ulkokehällä.
Ittellä tuli ongelmia siellaisissa tapauksissa kun samban yli pooliin yritti "streamata" isompaa köntsää mitä levyllä oli tilaa. Tätä keissiä MergerFS ei hanskaa hyvin. Suurimmaksi osaksi se feilasi sitten kokonaan, ilmeisesti jonkin sortin timeouttiin. MergerFS ilmeisesti siis yrittää siirtää sen homman toiselle levylle jossa on tilaa, mutta jos on 40G vaikka kirjoitettu ja sitä aletaan sitten siirtämään niin siinähän kestää tovi.
Viimeinen ongelma joka itseni ajoi pois tämän käytöstä oli se hetki kun pooli alkoi täyttyä ja siellä oli joitakin qemu imageita dynaamisella koolla joka aiheutti lopulta tilanteen että snapraid alkoi kitistä että pariteetti tila on loppu. Syynä tähän on se että snapraid toimii tiedostotasolla ja jos tiedosto ilmoittaa kooksi vaikka 1TB kuten qemu dynaamiset imaget voivat tehdä, niin vaikka se ei itse levyltä veisi kuin 1GB niin snapraid käsittelee sitä kuin 1TB köntsää.

Stratista olen hiukan testaillut virtuaalikoneella ja lueskellut sen docuja jonkin verran. Vaikuttaa varsin kunnianhimoiselta projektilta jonka tarkoituksena on ainakin ollut ottaa hyviä puolia vähän sieltä ja täältä ja tehdä kokonaan uusi kikotin joka on helppo käyttää. Toistaiseksi on kyllä ominaisuuksiltaan aika köykäinen. Raid tuki käsittääkseni edelleen puuttuu. Hiukan jotenkin tuntuu jopa ideologiselta projektilta, yritetään tehdä samoja asioita uudelleen kun vaihtoehtona olisi käyttää ja kehittää jo olemassa olevia ratkaisuita. Stratis voisi ihan hyvin olla helppokäyttöinen käyttöliittymä joka nitoisi yhteen mdadm, lvm ja dm. Tuon kolmikon yhdiseloa jos saataisiin parannettua niin elämä helpottuisi paljon. Noi on käytettävyydeltää niin erilaisia jokainen kikkare että niiden opiskeluun tarvii uhrata aikaa jokunen tovi. Tähän siis Stratis olisi voinut mielestäni panostaa tekemällä käyttöliittymän joka nitoo noi kolme yhteen joilla saa ihmeitä aikaan kunhan osaa.

btrfs on filesysteeminä ittellä käytössä mutta sehän on paljon muutakin kuin pelkkä filesystem. Tuli myös sen raid-5 ominaisuutta kokeiltua mutta se on pahasti vielä keskeneräinen ja suurin ongelma on että poolin scub ottaa aivan tolkuttomasti aikaa. Se kun on toteutettu huonosti, tsekkaa jokaisen levyn periaatteessa erikseen. Eli pooli tsekataan yhtä monta kertaa kuin on levyjä vaikka yksi kerta riittäisi. Sitä ollaan korjaamassa.
btrfs:n raid toteutus on siitä mielenkiintoinen että poolissa voi olla eri kokoisia levyjä eikä tilaa hukata. Sen takia siihen itse alkujaan läksin, mutta kun on keskeneräisiä ominaisuuksia niin eihän sellaista voi käyttää. raid-1, raid-0 ja jbod (single) siinä toimii ihan loistavasti.

Nyt on sitten palattu taas mdadm käyttöön. Mulla on 6x3TB levyjä raid-5 ja toinen volume 5x4TB raid-5. Nämä on sitten nidottu yhteen lvm:n kanssa, jonka jälkeen luks ja lopulta btrfs.
LVM on varsin näppärä kunhan jaksaa perehtyä sen toimintaan. Tulevaisuudessa voin kasvattaa poolia helposti lisäämällä vain ihan minkä tahansa levyn, jonka jälkeen jos vaikka haluan päästä noista 3TB lätyistä eroon niin ei muuta kuin lvm komennoilla siirtää vanhalta uudelle ja poistaa vanhan.
Sitten mitä tulee mdadm vs. zfs niin olen tietoinen että zfs:ssä on varsin kova feature setti, mutta itte en sitä ala käyttää niin pitkään kuin se ei ole kernelissä suoraan tuettuna.

mdadm, lvm ja dm on sellainen kattaus että siitä löytyy nykyisin työkalut joilla päästään ihan vastaaviin fyytsöreihin, toki hallittavuus ei ole samaa tasoa juurikin kun on kolme eri kikkaretta. dm-integrity on aika kiva jos on oikein paranoidi. Sen kanssa on mahdollista rakentaa raid pakka jossa on käytännössä aika mahdotonta saaha ulos virheellistä dataa koska levyn pinnasta uhrataan pieni osa checksummeille.
Tässä taas tulee se ongelma kun käytetään montaa kikkaretta niin jos dm-integrityä haluaa käyttää niin jokainen levy on ensin ajettava tuon integrityn läpitte joka kirjoittaa koko levyn läpi, eli kestää aikaa isommilla levyillä. Koska dm-integrity on dm ominaisuus, niin tuon integrityn voi tehdä myös cryptauksen kanssa, mutta mikäli tarkoitus on taas levyn nitoa yhteen mdadm kanssa, niin siitä seuraa sellainen typerä tilanne että jokaisella levyllä pyörii sitten oma cryptaus, nyky raudalla ei tietenkään ole sinäänsä ongelma, mutta turhaahan se on.

device-mapper mahdollistaa toki myös raid tuen suoraan, mutta ittelle se on ainakin liian kryptinen alkaa opetella. Sama pätee lvm:n.

Mitä sitten tulee cacheen Itte opin vasta hiljattain että mdadm on nykyisin myös cache tuki suoraan. Sitten lvm löytyy cache ominaisuus ja sitten sellainen härveli kuin bcache. Josta päästäänkin sitten taas seuraavaan aasinsiltaa, eli tuon tekijä on aloittanut kunnianhimoisen projektin, eli bcachefs jonka pitäisi sitten joskus jos valmistuu olla se kaikkien härveleitten äiti.
bcache on tullut kokeiltua ja ihan toimiva kapistus. Ittellä vaan oli niin onnettomat SSD:t suorituskyvyltään että hirveästi apuja ei saanut, kirjoitus itseasiassa sakkasi sen kanssa mutta johtui puhtaasti kuluttaja tason SSD:stä.

Alkaa vaan mennä aika monimutkaiseksi jos kaikkia fyytsöreitä haluaa ottaa käyttöön. :D
fyysinen levy -> partitiointi -> dm-integrity -> mdadm -> lvm -> bcache -> luks -> filesystem; on jo sellainen layer viidakko että jotain jos/kun hajoaa niin on ihmettelemistä.


Kannattaa tosiaan pistää joku linux virtuaalikoneeseen ajoon ja siihen virtuaali koneelle sitten pulttaa vaikka 10kpl jotain 10GB virtuaalilevyjä niin pääsee leikkimään ikäänkuin "oikeilla" levyillä. 10GB on sen verran pieni että vaikka jotain rait pakkaa alustelee ja ne virtuaali levyt on fyysisesti yhdellä ja samalla levyllä niin ei siihen aikaa ihan liikaa tuhraannu.
Toki losetup on myös vaihtoehto, mutta itte tykkään leikkiä mieluummin "oikeilla" levyillä.
 
Nyt on sitten palattu taas mdadm käyttöön. Mulla on 6x3TB levyjä raid-5 ja toinen volume 5x4TB raid-5. Nämä on sitten nidottu yhteen lvm:n kanssa, jonka jälkeen luks ja lopulta btrfs.
Öh.. nyt kuulostaa vähän kummalliselta. mdadm+lvm+luks+btrfs, saisko vielä yhden kerroksen mukaan tuohon sekamelskaan?

Itse varmaan myisin nykyiset levysi, ostaisin 5x10TB ja löisin ne raidz2 + native zfs encryption. 30TB käytettävissä (vrt 27TB nykyiseesi), parempi/sama vikasietoisuus (riippuen miten tilannetta katselee), luotettavampi (zfs paljon testatumpi kuin btrfs, nopeampi/dynaamisempi kuin mdadm), kaikki hallinta hoidetaan yhdellä työkalulla (zfs) eikä viidellä eri. Tai tekisin kaksi erillistä raidz1 pakkaa, eli sama 2kpl raid-5 kuin nyt, mutta edelleen vain yhden työkalun takana. Ne voi myös "nitoa" toisiinsa (raid-0 / stripe), vaikka ovatkin eri kokoisia. Kirjoitukset jakautuvat tasaisesti riippuen vapaasta tilasta, esim 1TB ja 2TB vdev ("pakka", kokonaistila) jakautuisi n. 1:2 suhteessa.

Tästä hieman luettavaa, zfs vs mdadm, huomattavin noista on zfs recordsize jonka voit määrittää per-dataset (riippuen sovelluksista joita käytät, tietokannat jne), kun taas mdadm se on koko pakan levyinen.
 
Viimeksi muokattu:
NAS raid5 raid1 raid0 raid10

Riippuu pitkälti käytöstä.

- Raid 1 antaa parhaan suojan mutta suorituskyky ei ole mitenkään erityisen hyvä. Aika pitkälti sama kuin ajaisi yhtä levyä. Lukeminen nopeutuu ainoastaan tilanteissa kun lukuoperaatioita on on kaksi tai enemmän yhtäaikaa, jolloin lukuoperaatiot jakautuu levyille. 2 laikkaa riittää. Tilaa saat saman kuin yhdellä laikalla.
- Raid 10 parantaa molempia, luku sekä kirjoitusta, mutta riskikerroin kasvaa koska jos 2 levyä menee samanaikaisesti ja ne sattuu olemaan sopivasti juuri se Raid 0 puoli, niin menettää kaiken. Vaatii vähintään 4 laikkaa. Tilaa saat kahden laikan verran.
- Raid 5 antaa kivasti suorituskykyä niin kirjoitukseen kuin lukuun, mutta myös suurin riski. 2 levyn yhtäaikainen rikko on takuuvarma menetys kaikelle. Vaatii vähintään 3 laikkaa. Tilaa saat levyjen kokonaismäärä - 1.

Itte olen aika pitkälti aina ajanut raid-5 koska se on kustannustehokkain. On levyrikkoa vastaan suoja ja kokonais levypintaa ei menetä puolta kuten noissa muissa vaihtoehdoissa. Taino raid-1 ei sinäällä ole rajotettu 2 levyyn, voit laittaa vaikka 10 levyä raid-1 jos tarttet oikein hullusti IO:ta.


Öh.. nyt kuulostaa vähän kummalliselta. mdadm+lvm+luks+btrfs, saisko vielä yhden kerroksen mukaan tuohon sekamelskaan?

Itse varmaan myisin nykyiset levysi, ostaisin 5x10TB ja löisin ne raidz2 + native zfs encryption. 30TB käytettävissä (vrt 27TB nykyiseesi), parempi/sama vikasietoisuus (riippuen miten tilannetta katselee), luotettavampi (zfs paljon testatumpi kuin btrfs, nopeampi/dynaamisempi kuin mdadm), kaikki hallinta hoidetaan yhdellä työkalulla (zfs) eikä viidellä eri. Tai tekisin kaksi erillistä raidz1 pakkaa, eli sama 2kpl raid-5 kuin nyt, mutta edelleen vain yhden työkalun takana.

Tästä hieman luettavaa, zfs vs mdadm, huomattavin noista on zfs recordsize jonka voit määrittää per-dataset (riippuen sovelluksista joita käytät, tietokannat jne), kun taas mdadm se on koko pakan levyinen.

Tiedän varsin hyvin zfs:n hyödyt ja myös sen haitat. Onhan se hieno vekotin mutta toisaalta myös varsin jäykkä. Parannusta toki on tulossa jäykkyyteen. Mutta suurin turn ooff on siis natiivi kernel tuki jota ei ole ja tuskin koskaan tulee koska lisenssit.

Mitä tulee btrfs:n niin se on filesystem tasolla ihan tarpeeksi testattu ja luotettava. Lähinnä valittu CoW takia ja scrub:n. Itteä ei haittaa että on useampi layeri koska osaan jokaista myös hallita. Eihän tämä sellaiselle henkilölle tietenkään sovi joka ei hanskaa mdadm, lvm ja dm.

Kaikilla ei ole varaa pistää kaikkia levyjä kerralla uusiksi, joten tämä on sen suhteen kompromissi että pystyn helposti laajentamaan poolia tulevaisuudessa.
 
Viimeksi muokattu:
Olisi tarvetta mielipiteen tueksi. Tällä hetkellä levytilaa palvelee wanha core2duo. Laitteen teho piisaa periaatteessa nykyiseen (pohjalla open media vault: nextcloud, jellyfish, parit lamp-pinot konteissa).

Kaksi vaihtoehtoa:
1. Uusi prossu, emo ja muistit, loput vanhasta

2. Uusi palvelin (hpe microserver)

Molemmissa puolensa, mutta mikä olisi järkevin. Wanhan raudan kesto jo jännittää, kun ikää jo on.
 
Riippuu pitkälti käytöstä.

- Raid 1 antaa parhaan suojan mutta suorituskyky ei ole mitenkään erityisen hyvä. Aika pitkälti sama kuin ajaisi yhtä levyä. Lukeminen nopeutuu ainoastaan tilanteissa kun lukuoperaatioita on on kaksi tai enemmän yhtäaikaa, jolloin lukuoperaatiot jakautuu levyille. 2 laikkaa riittää. Tilaa saat saman kuin yhdellä laikalla.
- Raid 10 parantaa molempia, luku sekä kirjoitusta, mutta riskikerroin kasvaa koska jos 2 levyä menee samanaikaisesti ja ne sattuu olemaan sopivasti juuri se Raid 0 puoli, niin menettää kaiken. Vaatii vähintään 4 laikkaa. Tilaa saat kahden laikan verran.
- Raid 5 antaa kivasti suorituskykyä niin kirjoitukseen kuin lukuun, mutta myös suurin riski. 2 levyn yhtäaikainen rikko on takuuvarma menetys kaikelle. Vaatii vähintään 3 laikkaa. Tilaa saat levyjen kokonaismäärä - 1.

Itte olen aika pitkälti aina ajanut raid-5 koska se on kustannustehokkain. On levyrikkoa vastaan suoja ja kokonais levypintaa ei menetä puolta kuten noissa muissa vaihtoehdoissa. Taino raid-1 ei sinäällä ole rajotettu 2 levyyn, voit laittaa vaikka 10 levyä raid-1 jos tarttet oikein hullusti IO:ta.




Tiedän varsin hyvin zfs:n hyödyt ja myös sen haitat. Onhan se hieno vekotin mutta toisaalta myös varsin jäykkä. Parannusta toki on tulossa jäykkyyteen. Mutta suurin turn ooff on siis natiivi kernel tuki jota ei ole ja tuskin koskaan tulee koska lisenssit.

Mitä tulee btrfs:n niin se on filesystem tasolla ihan tarpeeksi testattu ja luotettava. Lähinnä valittu CoW takia ja scrub:n. Itteä ei haittaa että on useampi layeri koska osaan jokaista myös hallita. Eihän tämä sellaiselle henkilölle tietenkään sovi joka ei hanskaa mdadm, lvm ja dm.

Kaikilla ei ole varaa pistää kaikkia levyjä kerralla uusiksi, joten tämä on sen suhteen kompromissi että pystyn helposti laajentamaan poolia tulevaisuudessa.
No harrastukset on mukavia. Tämä vain tuulahdus menneiltä vuosikymmeniltä, niin siksi itseä kummeksutti että miksi ihmeessä... Mutta mikäs siinä jos omalle työlle ei laske mitään arvoa ja miettii vain että paljonko limput maksaa ja voiko niitä lisätä edelliseen pakkaan (tosin, ZFS:stä lähtee vihdoin kotikäyttäjiä vaivannut zpoolin laajennus viimein pois, tosin tämäkään ei oikeasti ole niin iso ongelma kuin siitä tehdään).

Toivottavasti 4tb sata ssd:t tulisi jossain vaiheessa järkeviin hintoihin että voisi alkaa noita mekaanisia kiekkoja korvaamaan. Vielä on liian tyyristä :(
 
No harrastukset on mukavia. Tämä vain tuulahdus menneiltä vuosikymmeniltä, niin siksi itseä kummeksutti että miksi ihmeessä... Mutta mikäs siinä jos omalle työlle ei laske mitään arvoa ja miettii vain että paljonko limput maksaa ja voiko niitä lisätä edelliseen pakkaan (tosin, ZFS:stä lähtee vihdoin kotikäyttäjiä vaivannut zpoolin laajennus viimein pois, tosin tämäkään ei oikeasti ole niin iso ongelma kuin siitä tehdään).

Toivottavasti 4tb sata ssd:t tulisi jossain vaiheessa järkeviin hintoihin että voisi alkaa noita mekaanisia kiekkoja korvaamaan. Vielä on liian tyyristä :(

Siis mikä on tuulahdus menneiltä vuosikymmeniltä? mdadm, lvm ja dm? Kaikki saa jatkuvasti uusia ominaisuuksia kuten mdadm cache tullut tässä jossain vaiheessa joka mahdollistaa samalla journalin, eli käytännössä tappaa writehole mahdollisuudeen joka on ollut SE juttu jossa zfs on ollut parempi.
Noi kaikki on kuitenkin edelleen varsin laajasti käytössä. Itse seuraillut mdadm postituslistaa niin siellä on välillä esim jenkkien military rojujen ylläpitäjä kysellyt jotain juttuja kun on rakennellut levypalvelinta mdadm kanssa. Hiukan toisen luokan kamaa mitä me rakennellaan. Dual EPYC ja montakymmentä nvme asemaa.
Noiden rauta raid korttien aika kun tahtoo olla ohitte. Niissä ei yksinkertaisesti riitä potku nykyajan tarpeisiin.

SSD:n hinnat ei ainakaan itselle tule houkutteleviksi vielä pitkiin aikoihin, eikä ole niin edes tarvetta. Joten ittelle riittää nää halvat käytety pyörivät romut. Jossain laadukaassa 5v vanhassa pyörivässä romussa on kuitenkin vuosia jäljellä vielä paljon.
Esimerkiksi tässä windows koneessa mulla on WD:n teranen Raid Edition 3, laikka naitettu 500GB SSD:n kanssa yhteen pelipooliksi. (cachetettu pooli siis, sitä mitä paljon ladataan, se siirretään SSD:lle ja muu on HDD:llä. Tämän teko onnistuu powershell työkaluilla.)

1658268612054.png


Tunteja on laikassa kiitettävästi eikä mitään merkkejä että olisi hajoamassa.

Tuossa nassissa noi WD RED laikat on ollut hiukan pettymys. Oli 8kpl jotain pari vuotta sitten hankittu ja niistä on 2 hajonnut. Ittellä SSD:stä se kokemus että ne voi mennä täysin mykäksi ihan ilman mitään varoitusta. HDD mulla ei ainakaan ole kertaakaan vielä levinnyt täysin yllättän vaan oireilu yleensä alkaa sillä että tulee pending sector ja reallocation alkaa kasvaa jolloin kantsii hankkiutua lätystä pikapikaa eroon.
Jos ei hankkiudu niin sellainen kokemus on että se kun alkaa pahenemaan niin aiheuttaa kaikenlaista jännää jäätyilyä koneeseen.
 
Raid 1 antaa parhaan suojan mutta suorituskyky ei ole mitenkään erityisen hyvä. Aika pitkälti sama kuin ajaisi yhtä levyä. Lukeminen nopeutuu ainoastaan tilanteissa kun lukuoperaatioita on on kaksi tai enemmän yhtäaikaa, jolloin lukuoperaatiot jakautuu levyille. 2 laikkaa riittää. Tilaa saat saman kuin yhdellä laikalla.
- Raid 10 parantaa molempia, luku sekä kirjoitusta, mutta riskikerroin kasvaa koska jos 2 levyä menee samanaikaisesti ja ne sattuu olemaan sopivasti juuri se Raid 0 puoli, niin menettää kaiken. Vaatii vähintään 4 laikkaa. Tilaa saat kahden laikan verran.
- Raid 5 antaa kivasti suorituskykyä niin kirjoitukseen kuin lukuun, mutta myös suurin riski. 2 levyn yhtäaikainen rikko on takuuvarma menetys kaikelle. Vaatii vähintään 3 laikkaa. Tilaa saat levyjen kokonaismäärä - 1.
En tiedä mistä lainauksesi oli, mutta mielestäni raid 6/raid z2 olisi voinut mainita, koska on saman tyyppinen kuin raid5, mutta kestää kahden levyn hajoamisen. Vaati vähintään 4 levyä, mutta 5-6 levyn kohdalla muuttuu järkeväksi, ja ehkä 8-9 levyä on minne asti tuolla kannattaa mennä. 10 levyllä saattasi olla jo raid z3 paikallaan, mutta toisaalta 10 levyn raid 6/z2 vastaa 5 levyn raid 5 joka on vähän kiikun kaakun olisiko lisäturva hyvä olla vai ei.
 
En tiedä mistä lainauksesi oli, mutta mielestäni raid 6/raid z2 olisi voinut mainita, koska on saman tyyppinen kuin raid5, mutta kestää kahden levyn hajoamisen. Vaati vähintään 4 levyä, mutta 5-6 levyn kohdalla muuttuu järkeväksi, ja ehkä 8-9 levyä on minne asti tuolla kannattaa mennä. 10 levyllä saattasi olla jo raid z3 paikallaan, mutta toisaalta 10 levyn raid 6/z2 vastaa 5 levyn raid 5 joka on vähän kiikun kaakun olisiko lisäturva hyvä olla vai ei.

Se on ihan omasta päästä, ei lainattu mistään. Ja raid-6 skippasin kun ei sitä kysytty. Samoiten skippasin raid-0 vaikka sitä kysyttiin koska raid-0 ei ole järkevä kuin aivan spessuissa keisseissä koska se tuplaa, triplaa jne riskin menettää kaiken riippuen siitä montako levyä siihen raid-0 laittaa.

Se että montako levyä raid-5/6 jne pakkaan kannattaa laittaa rippuu mielestäni myös siitä millaisessa käytössä se pakka on. Jos on aktiivista käyttöä jatkuvasti niin rebuild laittaa aivan toisenlaista stressiä sinne ja rebuild aika kasvaa verrattuna sellaiseen joka pääasiassa idlaa taikka käyttäjä itse voi välttää käyttöä silloin kun rebuildi on ajossa, jolloin se rebuild valmistuu huomattavasti joutusammin. Jälkimmäisessä skenaariossa mielestäni 5-6 levyä raid-5 on ihan ok. Tuosta ylitte niin kannattaa alkaa harkita raid-6.

Ja aina kannattaa muistaa että raid ei ole backup. Sen ei ole tarkoitus korvata oikeita backuppeja vaan tarjota suorituskykyä ja suhteellisen hyvää takuuta siitä että data ei katoa ja järjestelmä pysyy toiminnassa levyrikosta huolimatta.
 
Onko mitään hyötyä käyttää Synology DS918+:ssa link aggregationia? Tällä ilmeisesti saisi joko a) varmemman yhteyden tai b) nopeamman yhteyden (1 gigaa vs. 2 gigaa).
 
Onko mitään hyötyä käyttää Synology DS918+:ssa link aggregationia? Tällä ilmeisesti saisi joko a) varmemman yhteyden tai b) nopeamman yhteyden (1 gigaa vs. 2 gigaa).
Jos useampi lataa nassilta tai nassiin samaan aikaan, niin sitten on hyötyä, kun se kaista on sen 2 gigaa. Jos itseksesi siirtelet tiedostoja, niin sitten nopeus ei muistaakseni noussut 1 gigaa isommaksi (olettaen, että oman koneen verkko on nopeampi, kuin 1 gb). Korjatkaa, jos muistan tämän väärin.

Toki toiminta on varmempaa, kun on kahdella narulla kiinni.
 
Jos useampi lataa nassilta tai nassiin samaan aikaan, niin sitten on hyötyä, kun se kaista on sen 2 gigaa. Jos itseksesi siirtelet tiedostoja, niin sitten nopeus ei muistaakseni noussut 1 gigaa isommaksi (olettaen, että oman koneen verkko on nopeampi, kuin 1 gb). Korjatkaa, jos muistan tämän väärin.

Toki toiminta on varmempaa, kun on kahdella narulla kiinni.

Eli voisi olla fiksua tehdä linkin ohjeista "Load Balancing Network Bond". Alla olevista pitäisi ilmeisesti valita "Balance-TCP"? Mistä tiedän tukeeko DNA:n Technicolour-päätelaite tuota link aggregationia?

"Now, select either the Balance-SLB or Balance-TCP options as marked in the screenshot below.

Balance-SLB: If you want to bond network interfaces from different network-switch to increase your Synology NAS download/upload speed, select the Balance-SLB option.

Balance-TCP: If you have a switch that supports link aggregation, then configure your switch ports for link aggregation first and use this option to configure link aggregation for your Synology NAS."
 
Onko mitään hyötyä käyttää Synology DS918+:ssa link aggregationia? Tällä ilmeisesti saisi joko a) varmemman yhteyden tai b) nopeamman yhteyden (1 gigaa vs. 2 gigaa).
Nopeampaa siirtoa saat vain, jos myös käyttämäsi jako tukee sitä. Käytännössä vaihtoehdot ovat SMB v3, jota Synology ei tietääkseni tue tai sitten iSCSI+MPIO. Veikkaan kyllä, että homman monimutkaistuminen on isompi haitta, kuin mitä tolla konffilla saisit hyötyjä.

Tuossa hyvä, ja yksinkertainen esimerkki aiheesta:
 
Viimeksi muokattu:
Eli voisi olla fiksua tehdä linkin ohjeista "Load Balancing Network Bond". Alla olevista pitäisi ilmeisesti valita "Balance-TCP"? Mistä tiedän tukeeko DNA:n Technicolour-päätelaite tuota link aggregationia?

"Now, select either the Balance-SLB or Balance-TCP options as marked in the screenshot below.

Balance-SLB: If you want to bond network interfaces from different network-switch to increase your Synology NAS download/upload speed, select the Balance-SLB option.

Balance-TCP: If you have a switch that supports link aggregation, then configure your switch ports for link aggregation first and use this option to configure link aggregation for your Synology NAS."
Itse olen tehnyt "Active/Backup modella" vikasietoisuuden. Varmaan makuasioita. Oli joskus kyllä "Balance-TCP" käytössä, mutta en laittanut toistamiseen, kun asensin NAS:in uusiksi. Ei oikein ollut hyötyä kotikäytössä. Toisessa ympäristössä tuo olisi oikeampi vaihtoehto.

Tuo malli kyllä tukee SMB3:stakin.

1659072036907.png


Eikös tuo Link aggregation ole vain kytkimien ominaisuus eikä reitittimien? Eli nähdäkseni pitäisi olla hallittava kytkin jotta saat moisen tehtyä.
 
Onko WD Ultrastar HE10 järkevä kovo nassiin? Näyttävät olevan hinnoiltaan edullisempia kuin WD Redit tai Seagate Ironwolf (Prot).
 
Oli puhetta kaverin kanssa omasta NASista kun alkaa tila käymään vähiin. 4x4 teran levyn raidz2 (TrueNAS) pool tällä hetkellä käytössä. Voisin rakentaa toisen samanlaisen tai raidz1 rinnalle tai sitten kasvattaa nykyistä, jota kyllä kannattaisin käytettävyyden ja ylläpidon kannalta. Ties kuinka kauan vaan tuota kasvatusominaisuutta vielä joutuu odottelemaan...

Kaveri kuitenkin kaipaili valokuvilleen helppoa offsite backuppia ja oli valmis maksamaankin hieman. Mikä olisi järkevin, helppokäyttöinen ja turvallinen tapa toteuttaa pääsy esim. tuonne yhteen kohdennettuun kansioon? Nextcloud pyörimään vai mitä?
 
Oli puhetta kaverin kanssa omasta NASista kun alkaa tila käymään vähiin. 4x4 teran levyn raidz2 (TrueNAS) pool tällä hetkellä käytössä. Voisin rakentaa toisen samanlaisen tai raidz1 rinnalle tai sitten kasvattaa nykyistä, jota kyllä kannattaisin käytettävyyden ja ylläpidon kannalta. Ties kuinka kauan vaan tuota kasvatusominaisuutta vielä joutuu odottelemaan...

Kaveri kuitenkin kaipaili valokuvilleen helppoa offsite backuppia ja oli valmis maksamaankin hieman. Mikä olisi järkevin, helppokäyttöinen ja turvallinen tapa toteuttaa pääsy esim. tuonne yhteen kohdennettuun kansioon? Nextcloud pyörimään vai mitä?

Oletan, että tähän halutaan jokin galleriamahdollisuus? Nextcloudissa tulee kyllä vain tuohon käyttöön nähden niin paljon romua mukana, että heittäisin ehkä mieluummin Piwigo jailin pystyyn (löytyy community plugareista suoraan): Piwigo - Open source photo management software tai vaikka FAMP jail + Lychee: Lychee — Self-hosted photo-management done right
Hifistelijöille löytyy myös PhotoPrismin Community Edition.

Toki Nextcloudilla suora uppaus esim. luurista on todennäköisesti helpompaa. Eli riippunee siitä, miten tuonne halutaan kuvia työntää.
 
Viimeksi muokattu:
Entä ihan vaan SSH? :hmm:

Ajattelin varmaan liian vaikeasti kun ei edes tullut mieleen.

Oletan, että tähän halutaan jokin galleriamahdollisuus? Nextcloudissa tulee kyllä vain tuohon käyttöön nähden niin paljon romua mukana, että heittäisin ehkä mieluummin Piwigo jailin pystyyn (löytyy community plugareista suoraan): Piwigo - Open source photo management software tai vaikka FAMP jail + Lychee: Lychee — Self-hosted photo-management done right
Hifistelijöille löytyy myös PhotoPrismin Community Edition.

Toki Nextcloudilla suora uppaus esim. luurista on todennäköisesti helpompaa. Eli riippunee siitä, miten tuonne halutaan kuvia työntää.

Kevyt galleria vois kyllä tarjota lisää käytettävyyttä. Pitänee vähän perehtyä noihin eri vaihtoehtoihin ja kysellä kaverin tarpeist lisää, kiitos vinkeistä.
 
Itsellä on nyt hetken aikaa ollut HP ML310 G8 servu NAS käytössä mutta valitettavasti pari kuukautta sitten muuton yhteydessä piti tehdä uusi sähkösopimus joka on tietenkin sikakallis joten mietein olisiko aika päivittää vähävirtaisempaan. (Ensimmäinen sähkölasku oli 50 euroa)

HP:ssa tällähetkellä xeon e3-1220 v2 prosessori ja tilalle mietein asrock C3558D4I-4L emolevyä jossa atom C3558. (Emolevy maksaa noin 400 euroa)

Kysymys on kuinka paljon hitaampi tuo atom on kuin nykyinen xeon ja kuinka vähävirtaisempi?

Servu on päällä 24/7 joten olettaisin että tällä päivityksellä tulisi iso säästö sähkölaskuun, olenko väärässä?
 
Itsellä on nyt hetken aikaa ollut HP ML310 G8 servu NAS käytössä mutta valitettavasti pari kuukautta sitten muuton yhteydessä piti tehdä uusi sähkösopimus joka on tietenkin sikakallis joten mietein olisiko aika päivittää vähävirtaisempaan. (Ensimmäinen sähkölasku oli 50 euroa)

HP:ssa tällähetkellä xeon e3-1220 v2 prosessori ja tilalle mietein asrock C3558D4I-4L emolevyä jossa atom C3558. (Emolevy maksaa noin 400 euroa)

Kysymys on kuinka paljon hitaampi tuo atom on kuin nykyinen xeon ja kuinka vähävirtaisempi?

Servu on päällä 24/7 joten olettaisin että tällä päivityksellä tulisi iso säästö sähkölaskuun, olenko väärässä?
Varmaan oleellinen tieto olisi millä käytöllä ja minkälaisella levyarmadalla NAS on.
 
Varmaan oleellinen tieto olisi millä käytöllä ja minkälaisella levyarmadalla NAS on.
Totta, anteeksi.
Tällähetkellä neljä kaksiteraista kovalevyä ja servu toimii ainoastaan tiedostopalvelimena yhdelle käyttäjälle. (Käyttiksenä openmediavault)

Tulevaisuudessa tarkoituksena asentaa myös jellyfin ja owncloud, mutta tämän raskaampaa käyttöä tuskin tulee.
Myöskin kovojen määrä saattaa lisääntyä kahdeksaan jos ostan kotelon johon mahtuu.
 

Statistiikka

Viestiketjuista
259 137
Viestejä
4 503 120
Jäsenet
74 331
Uusin jäsen
Bopperhopper

Hinta.fi

Back
Ylös Bottom