NAS rakentelut

[dun]

Pahoitteluni jos missasin jo aiemmin sanottua, mutta harkitsitko Truenas Scalea? Debian-pohjainen ja ei tarvitse kipuilla conffaamisten kanssa. Jos ideana juurikin itse säätäminen, niin mikäs siinä.

Olitko siirtymässä pois Qnapista tietoturvaongelmia vai puuttuvien ominaisuuksien takia?

Ajoin truenas Scalen RC2:sta vm:ssä ennen päivitystä pääkoneelle ja totesin että on vielä lasten kengissä käyttökokemus. Odotellaan vielä vuosi pari niin ehkä alkaa toimimaan. Kokeilin myös Truenas Corea ja se pelitti vakaammin ja paremmin, niin laitoin sen nyt tonne remote replikaksi (riittää pääsy SSH rsa-avaimella, eli siellä ei pyöri mitään muuta kuin ZFS pooli replikaa varten). Pääserverillä teen vielä niin paljon erilaisia juttuja että tuo Scale ei vaan toiminut. Web-käyttikset on niille jotka niitä tarvii.

Debian tai RHEL pohjaisilla tiedostojärjestelmillä ei cronjobeja ole käytetty kohta 10 vuoteen, eli ne on korvattu SystemD:llä kun EL7 tuli ulos (toki ihmiset ei tietenkään näin ole tehneet kun community dokumentaatio laahaa perässä n. 10 vuotta eri blogeissa).

Pitääpä katsoa nuo automaattiscriptit läpi, en ole aikaisemmin törmännyt. Itsellä kesti service + timer scriptien templatointi olemassa olevaan Ansible playbookiin ehkä 20 min ja sitten toinen 20min kirjoitella incremental script /usr/local/bin hakemistoon jota toi systemd kutsuu halutulla aikataululla. En oikein tiedä pitäisikö näin yksinkertaista käyttötapausta varten hommata erillinen ohjelma, mutta jos siinä on jotain jänskää niin voisi sitä testa (mutta tarve on oikeasti paikallisten snapshottien teko + siirto replikaan ja se onnistuu muutamalla ZFS peruskomennolla...).

 

[Eskomoto]

Ajoin truenas Scalen RC2:sta vm:ssä ennen päivitystä pääkoneelle ja totesin että on vielä lasten kengissä käyttökokemus. Odotellaan vielä vuosi pari niin ehkä alkaa toimimaan. Kokeilin myös Truenas Corea ja se pelitti vakaammin ja paremmin, niin laitoin sen nyt tonne remote replikaksi (riittää pääsy SSH rsa-avaimella, eli siellä ei pyöri mitään muuta kuin ZFS pooli replikaa varten). Pääserverillä teen vielä niin paljon erilaisia juttuja että tuo Scale ei vaan toiminut. Web-käyttikset on niille jotka niitä tarvii.

Debian tai RHEL pohjaisilla tiedostojärjestelmillä ei cronjobeja ole käytetty kohta 10 vuoteen, eli ne on korvattu SystemD:llä kun EL7 tuli ulos (toki ihmiset ei tietenkään näin ole tehneet kun community dokumentaatio laahaa perässä n. 10 vuotta eri blogeissa).

Pitääpä katsoa nuo automaattiscriptit läpi, en ole aikaisemmin törmännyt. Itsellä kesti service + timer scriptien templatointi olemassa olevaan Ansible playbookiin ehkä 20 min ja sitten toinen 20min kirjoitella incremental script /usr/local/bin hakemistoon jota toi systemd kutsuu halutulla aikataululla. En oikein tiedä pitäisikö näin yksinkertaista käyttötapausta varten hommata erillinen ohjelma, mutta jos siinä on jotain jänskää niin voisi sitä testa (mutta tarve on oikeasti paikallisten snapshottien teko + siirto replikaan ja se onnistuu muutamalla ZFS peruskomennolla...).

Toki näin, käyttäjän taitojen ja erityisesti käyttötarkoituksen mukaan. Core on itsellä pääasiallisessa käytössä ja Scale backup-purkissa ollut kesästä lähtien. Nyt siinä ajossa RC2 ja omiin tarpeisiin tuntuu sen verran toimivalta, että ehkä siirrän pääasiallisen nassin Scalen piiriin kesän korvilla. Vähän siinä ja siinä onko aitoa tarvetta edes sille kun käytössä myös Proxmox kaikkeen muuhun. Ja värikkäät web-liittymät on kivoja.

Riippuu toki käyttäjän tietopohjasta enkä liikaa halua olettaa, mutta jos valmiista pakettiratkaisusta hyppää kylmiltään ZFS-maailmaan ja komentoriviloitsujen pariin, kannattanee harkita puolivalmista ratkaisua, jossa scrubit on automaattisia (paitsi importatuille pooleille) ja ajastetut snapshotit ja replikaatiot onnistuu selkeästi selaimella klikkailemalla, eikä tarvitse pohtia pitikö käyttää cronjobeja vai systemd:tä. Linusin videoista voi olla montaa mieltä, mutta sieltä saa aika tuoretta esimerkkiä, kun lähtee diy-zfs -linjalle, eikä varsinaisesti osaa mitään. (linkki)

 

[dun]

Toki näin, käyttäjän taitojen ja erityisesti käyttötarkoituksen mukaan. Core on itsellä pääasiallisessa käytössä ja Scale backup-purkissa ollut kesästä lähtien. Nyt siinä ajossa RC2 ja omiin tarpeisiin tuntuu sen verran toimivalta, että ehkä siirrän pääasiallisen nassin Scalen piiriin kesän korvilla. Vähän siinä ja siinä onko aitoa tarvetta edes sille kun käytössä myös Proxmox kaikkeen muuhun. Ja värikkäät web-liittymät on kivoja.

Riippuu toki käyttäjän tietopohjasta enkä liikaa halua olettaa, mutta jos valmiista pakettiratkaisusta hyppää kylmiltään ZFS-maailmaan ja komentoriviloitsujen pariin, kannattanee harkita puolivalmista ratkaisua, jossa scrubit on automaattisia (paitsi importatuille pooleille) ja ajastetut snapshotit ja replikaatiot onnistuu selkeästi selaimella klikkailemalla, eikä tarvitse pohtia pitikö käyttää cronjobeja vai systemd:tä. Linusin videoista voi olla montaa mieltä, mutta sieltä saa aika tuoretta esimerkkiä, kun lähtee diy-zfs -linjalle, eikä varsinaisesti osaa mitään. (linkki)

Ubuntu serverin hyväpuoli on että defaultit on kunnossa (35d scrupt automaattisesti käytössä) toisin kuin EL7 suoraan repoista käänetyssä ZFS:ssä (joka on niin vanilla kuin voi olla, LTT käytti Centos 7 varianttia tuosta EL7:sta, [=Enterprise Linux 7 = RHEL 7 = RedHat Linux 7]). Siinä tekivät ekan virheen (tosin eivät tienneet tai välittäneet. Noi asiat on oikeasti dokumentoitu aika hyvin ... . Olisivat saaneet toki kuntoon jos olisivat kysyneet esim. oman talonsa ulkopuolelta vaikka L1 techisltä Wendeliltä kun laittoivat alunperin pystyyn Mutta tuleepahan hyvää kontenttia siitä mitä pitää ja mitä ei pidä tehdä.

Tossa vaan valitettavasti paistaa läpi Linusksen ylimielisyys ja se että Posix serverin pitäisi jotenkin toimia samalla tavalla kuin Windows desktopin vaikka kyseessä on selvästi kaksi täysin eri platformia. Vähän sama kun haukkuisin Windowssia siitä että miksi sen tiedostojärjestelmä, prosessit, scheduleri ja käyttömukavuus ei toimi samalla tavalla kuin Gnome ja linux kerneli 1.2.3.4.5 ja ton platan päälle asennettavat modulaariset ohjelmat (= jos oikeasti ymmärtää kummankin platformin edut ja heikkoudet, niin tästä kommentista ei triggeröidy). Microsoftin tuotteet sopii kotiin työpöydälle vielä toistaiseksi oikein hyvin, toimistoon / palvelinsaliin ei niin hyvin.

 

[Bahamies]

Ubuntu serverin hyväpuoli on että defaultit on kunnossa (35d scrupt automaattisesti käytössä) toisin kuin EL7 suoraan repoista käänetyssä ZFS:ssä (joka on niin vanilla kuin voi olla, LTT käytti Centos 7 varianttia tuosta EL7:sta, [=Enterprise Linux 7 = RHEL 7 = RedHat Linux 7]). Siinä tekivät ekan virheen (tosin eivät tienneet tai välittäneet. Noi asiat on oikeasti dokumentoitu aika hyvin ... . Olisivat saaneet toki kuntoon jos olisivat kysyneet esim. oman talonsa ulkopuolelta vaikka L1 techisltä Wendeliltä kun laittoivat alunperin pystyyn Mutta tuleepahan hyvää kontenttia siitä mitä pitää ja mitä ei pidä tehdä.

Tossa vaan valitettavasti paistaa läpi Linusksen ylimielisyys ja se että Posix serverin pitäisi jotenkin toimia samalla tavalla kuin Windows desktopin vaikka kyseessä on selvästi kaksi täysin eri platformia. Vähän sama kun haukkuisin Windowssia siitä että miksi sen tiedostojärjestelmä, prosessit, scheduleri ja käyttömukavuus ei toimi samalla tavalla kuin Gnome ja linux kerneli 1.2.3.4.5 ja ton platan päälle asennettavat modulaariset ohjelmat (= jos oikeasti ymmärtää kummankin platformin edut ja heikkoudet, niin tästä kommentista ei triggeröidy). Microsoftin tuotteet sopii kotiin työpöydälle vielä toistaiseksi oikein hyvin, toimistoon / palvelinsaliin ei niin hyvin.

Älyttömintä minusta tuossa LTT:n sekoilussa on se, että tämä on jo toinen kerta kun dataa menetetään. Onhan tässä omissakin homelab-leikeissä käynyt virheitä, mutta 1. toimeentulo ei riipu omista palvelinleikeistä 2. virheistä pitää pyrkiä oppimaan.

Tuossa heidän prosessissaan virheitä on tullut kokonaisuutenaan niin paljon, että tuo vaikuttaa jo melkein tarkoituksenmukaiselta "Katsotaan miten kestävä ZFS oikeasti on"-testaamiselta. Ei scrubeja, järkyttävän typerästi kasatut zpoolit, ei varsinaista ylläpitoa tai seurantaa... Ja tämä kaikki sen jälkeen, kun kertaalleen jo menetettiin dataa oman typeryyden takia.

Omaan silmään tuollainen 15 levyn RaidZ2 pakka näytti jo lähtökohtaisesti aivan kuolleena syntyneeltä idealta ja niitä olikin sitten vielä monta (6?). Muistan jo ensimmäisen palvelinvideon kohdalla naurahtaneeni ääneen, Linus perusteli että tällainen zpool on ihan ok, koska "laadukkaat levyt kestävät kyllä".

Ja jotta ei pääsisi unohtumaan, niin LTT on häärännyt myös muilla YT-kanavilla laittamassa "palvelimet kuntoon".

E: Never stop the madness! Taas mennään 15 levyn RaidZ2 vdeveillä. Sitten vaan odotetaan kun parin vuoden päästä vaihdetaan ensimmäistä hajonnutta levyä ja vdev leviää jälleen.

 

[jsa]

E: Never stop the madness! Taas mennään 15 levyn RaidZ2 vdeveillä. Sitten vaan odotetaan kun parin vuoden päästä vaihdetaan ensimmäistä hajonnutta levyä ja vdev leviää jälleen.

Jotenki huvittaa, mutta kai se on tarpeeks rahaa tuottavaa että voi iskeä kirveellä polveen jälleen kerran.

 

[Joku_242]

Jotenki huvittaa, mutta kai se on tarpeeks rahaa tuottavaa että voi iskeä kirveellä polveen jälleen kerran.

Saapa ainakin tehtyä uuden videon...

Ei sillä, on mullakin NASsissa viiden levyn raidz1-pakka, vaikka jälkikäteen ajatellen olisi ollut parempi ostaa yksi levy lisää raidz2 varten. Toki Linusilta voisi odottaa enemmän.

 

[iccb]

Pahoitteluni jos missasin jo aiemmin sanottua, mutta harkitsitko Truenas Scalea? Debian-pohjainen ja ei tarvitse kipuilla conffaamisten kanssa. Jos ideana juurikin itse säätäminen, niin mikäs siinä.

Olitko siirtymässä pois Qnapista tietoturvaongelmia vai puuttuvien ominaisuuksien takia?

Truenas Scale pyörii toisessa koneessa, mutta en ole oikein koskaan päässyt sinuiksi truenassin kanssa... Sen tähden en halua sitä..
Qnapin QuTS Hero toimii ihan kohtalaisen hyvin, mutta toki melkoisia reikiä löytyy siitä ja dockereiden pyörittely ja gpu transkoodaukset saisi paremmin toimimaan ubuntussa...
Ehkä nämä kaikki viimeaikaiset reijät on antanut kipinän vaihtaa...

 

[iccb]

Riippuu toki käyttäjän tietopohjasta enkä liikaa halua olettaa, mutta jos valmiista pakettiratkaisusta hyppää kylmiltään ZFS-maailmaan ja komentoriviloitsujen pariin, kannattanee harkita puolivalmista ratkaisua, jossa scrubit on automaattisia (paitsi importatuille pooleille) ja ajastetut snapshotit ja replikaatiot onnistuu selkeästi selaimella klikkailemalla, eikä tarvitse pohtia pitikö käyttää cronjobeja vai systemd:tä. Linusin videoista voi olla montaa mieltä, mutta sieltä saa aika tuoretta esimerkkiä, kun lähtee diy-zfs -linjalle, eikä varsinaisesti osaa mitään. (linkki)

Tykkään kyllä selaimella konffailla ja kotiympäristössä pitää puntaroida myös sitä paljonko on aikaa näihin asioihin ja paljonko toisaalta haluaa säätää...
ZFS ei ole vieras asia mitenkään, mutta en myöskään sen sielunelämää läpikotaisin tunne...
Mahtaako tolle Linusille oikeasti ollut käynyt tuo datanmenetys vai kuuluuko se vaan kanavan bisnekseen?...
Itse en juuri katsele Linusin videoita.

 

[dun]

No, z2 on fine 15 (on itse asiassa 3 x 20 levyä ja 18 per vdev kapasiteetti) levyn kanssa, se kommentti hotsparesta on siinä ja siinä että onko ne järkeviä (mielummin suoraan z3, koska hotspare vie virtaa ja kuluu siinä rinnalla).

Aika usein ehdit vaihtamaan levyn jos vain hyllyssä on kylmänä. Jos sinä aikana läjähtää vielä toinen, niin senkin ehtii vielä vaihtaa ja yleensä ensimmäinen levy on jo resilvattu siinä vaiheessa.

Myistaakseni ltt:llä on toi tehty näin:
20 (z2)\
20 (z2) - Dataset/samba share (945TB => 875TiB)
20 (z2)/

Jolloin kestää 2-6 levyrikkoa ennen kuin leviää.

Nythän niillä oli levinnyt (miinus bitrot) 2 + 2 + 1 levyä ja eivät vaan olleet huomanneet sitä koska sähköpostit. Koska ei ollut scrubia käytössä, niin koko pakka sekaisin resilverin alettua.

Jos on 4 kol cold sparea valmiina, niin minäkin ajaisin tota settiä noin, koska tossa menettää vain nice to have datan (niillä oli videot jo editoituna pilvessä, joten b-roll katosi ehkä ja jälkimuokkaus alkuperäisestä materiaalista. Jos eivät siis saa dataa palautettua, mikä on täysin mahdollista mitä nyt sinne tänne voi tulla aetifakteja koska videotiedostoissa itsessäänkin on crc checkki koska windows ntfs sen käpysyys

Edit: Lisäyksenä vielä tohon NTFS kommenttiin, että sama myös MacOS:llä ja ext2/3/4. Jokaisesa on jonkun sortin mekanismi crc checkille ja bitrotia vastaan, mutta ZFS oli eka joka teki sen kunnolla ja oikein (koska varmistaa toisilta levyiltä). Tässä tapauksessa olivat vaan antaneet sen mädäntyä niin paljon että vaikka kaikki levyt olisi olleet kunnossa olisi kosahtanut scrubissa (mutta sen voi ehkä skipata tai ajaa kevyesti läpi jonka jälkeen saavat vielä ehkä datan toistettavassa muodossa, mutta artifaktien tai ilman kanssa).

 

[Bahamies]

No, z2 on fine 15 levyn kanssa, se kommentti hotsparesta on siinä ja siinä että onko ne järkeviä (mielummin suoraan z3, koska hotspare vie virtaa ja kuluu siinä rinnalla).

Aika usein ehdit vaihtamaan levyn jos vain hyllyssä on kylmänä. Jos sinä aikana läjähtää vielä toinen, niin senkin ehtii vielä vaihtaa ja yleensä ensimmäinen levy on jo resilvattu siinä vaiheessa.

Tuossa vaan pitäisi huomioida mielestäni se, että nyt kun palvelin kasataan ja sinne laitetaan uutena kaikki levyt, niin riskit siinä resilveroinnin aikana ovat potentiaalisesti aika korkealla. Puhutaan kuitenkin levyistä, jotka saavat saman rasituksen ja käytön koko elinaikansa. Jos yksi leviää ja kyseessä on esim. huono kappale, niin täten ollaan maksimoitu riski datan menetykselle jos kyseessä onkin huono tuotantoerä.

Tällä sivulla pystyy vertailemaan graafisesti, miten riski poolin menetykselle kasvaa eri konfiguraatioilla. Ero 15z2*4 ja 15z3*4 välillä on aika hurja. Tuollakin pienellä muutoksellä hävitään tässä kokoluokassa mitätön 80TB kapasiteetista, mutta vaikutus levyn hajoamisen kestoon on suuri.

 

[Joku_242]

Tuossa vaan pitäisi huomioida mielestäni se, että nyt kun palvelin kasataan ja sinne laitetaan uutena kaikki levyt, niin riskit siinä resilveroinnin aikana ovat potentiaalisesti aika korkealla. Puhutaan kuitenkin levyistä, jotka saavat saman rasituksen ja käytön koko elinaikansa. Jos yksi leviää ja kyseessä on esim. huono kappale, niin täten ollaan maksimoitu riski datan menetykselle jos kyseessä onkin huono tuotantoerä.

Tällä sivulla pystyy vertailemaan graafisesti, miten riski poolin menetykselle kasvaa eri konfiguraatioilla. Ero 15z2*4 ja 15z3*4 välillä on aika hurja. Tuollakin pienellä muutoksellä hävitään tässä kokoluokassa mitätön 80TB kapasiteetista, mutta vaikutus levyn hajoamisen kestoon on suuri.

Tuolla sivulla väitettiin seuraavaa:

• When one drive has failed in ZFS, the act of rebuilding the zpool is itself a high-risk, high-intensity operation which puts the drive under considerably more stress than its default run condition. Because of this, rebuilding a zpool may actually increase the likelihood that the pool dies. Again, this calculator does not account for that.

Eikö scrubin pitäisi olla levyille yhtä raskas operaatio kuin resilverin? Eli säännöllisen harjaamisen pitäisi tällöin myös toimia stressitestinä levyille, jos tulkitsin tuon oikein.

 

[Bahamies]

Eikö scrubin pitäisi olla levyille yhtä raskas operaatio kuin resilverin? Eli säännöllisen harjaamisen pitäisi tällöin myös toimia stressitestinä levyille, jos tulkitsin tuon oikein.

Ei. Scrubissa vain luetaan ja verrataan checksumiin, resilverissä kopiodaan. Resilver on huomattavasti raskaampi operaatio.

A resilver re-copies all the data in one device from the data and parity information in the other devices in the vdev: for a mirror it simply copies the data from the other device in the mirror, from a raidz device it reads data and parity from remaining drives to reconstruct the missing data.

 

[Joku_242]

Ei. Scrubissa vain luetaan ja verrataan checksumiin, resilverissä kopiodaan. Resilver on huomattavasti raskaampi operaatio.

Ööh, miten lukeminen eroaa kopioinnista poolin vanhojen levyjen kannalta? Prosessorille se on toki raskaampi operaatio, mutta se tuskin on hajoamassa mihinkään. Sama homma sen uuden levyn kanssa, jolle data kirjoitetaan, eikä sen hajoamisella olisikaan väliä.

 

[Timo 2]

Onko TRUENAS se yksinkertaisin ja helpoin käyttöjärjestelmä NASsiksi (suunnitelmana pääosin mediapalvelimena 6x12 kiintolevyä raid 5 eli kestää yhden levyn hajoamisen), vai pitäisikö valita joku toinen? Koodata en osaa eikä linuksista ole kokemusta. Komentokehoitteen käyttö onnistuu, mutta ei ole helppoa. En myöskään ole verkkovelho. Ehkä kaupallinen NAS(qnap, synology, yms) olisi ollut paras vaihtoehto, mutta nyt se on jo myöhäistä. Osat on jo ostettu, kun sai halvemmalla parempaa rautaa. Tämä taitaa olla jossain määrin perse edellä puuhun kiipeämistä, mutta pyrin että loppu on mahdollisimman kivutonta.

 

[kopsteri]

Itsellä ollut vuosikausia Freenas/Truenas core plex serveri ja nas käytössä. On yksinkertainen ja pelkällä guilla pärjää.

 

[Bahamies]

Ööh, miten lukeminen eroaa kopioinnista poolin vanhojen levyjen kannalta? Prosessorille se on toki raskaampi operaatio, mutta se tuskin on hajoamassa mihinkään. Sama homma sen uuden levyn kanssa, jolle data kirjoitetaan, eikä sen hajoamisella olisikaan väliä.

Käsittääkseni vain siten, että levyjä, joilta data luetaan on yksi vähemmän. Ongelmaksi tilanne eskaloituu, kun datasta löytyy paljon virheitä resilveroinnin aikana. Tällöin ZFS pudottaa virheilevän levyn offlineen ja levyjä on taas yksi vähemmän. Jos resilverointia ei saada ikinä valmiiksi, menetetään dataa. Resilveroidessa ehjä data pitäisi löytää jostain ja jos perus huoltotoimenpiteitä ei ole tehty, niin sitä ei välttämättä ole. Tämän vuoksi scrubit ovat tärkeitä.

Korjatkaa nyt joku jos olen ZFS:n toiminnan täysin väärin ymmärtänyt

Se on tosin totta, että periaatteessa scrub ja resilverointi eivät ole poolin muille levyille enemmän/vähemmän raskaita. Tuolloin luotettavuus on ongelma lähinnä silloin, jos kaikki levyt ovat samasta valmistuserästä ja on mahdollisuus siihen, että toinenkin levy saattaa olla päässyt elinkaarensa loppuun. Tuon varalle pystyy suunnittelemaan silloin, kun poolia kasataan ja levyt stressitestataan. Sen jälkeen menee tuuripeliksi tämän suhteen. Laadukkailla kovalevyillä riski on aina pienempi, mutta ei silti ikinä 0.

 

[iccb]

Onko TRUENAS se yksinkertaisin ja helpoin käyttöjärjestelmä NASsiksi (suunnitelmana pääosin mediapalvelimena 6x12 kiintolevyä raid 5 eli kestää yhden levyn hajoamisen), vai pitäisikö valita joku toinen? Koodata en osaa eikä linuksista ole kokemusta. Komentokehoitteen käyttö onnistuu, mutta ei ole helppoa. En myöskään ole verkkovelho. Ehkä kaupallinen NAS(qnap, synology, yms) olisi ollut paras vaihtoehto, mutta nyt se on jo myöhäistä. Osat on jo ostettu, kun sai halvemmalla parempaa rautaa. Tämä taitaa olla jossain määrin perse edellä puuhun kiipeämistä, mutta pyrin että loppu on mahdollisimman kivutonta.

Oma kokemus on, että Truenassia helpompi on openmediavault. Se on kanssa vähän makuasia kyllä. Openmediavault ei suoraan tue zfs tiedostojärjestelmää, mutta helposti sen siihen asennettua kyllä.
Kokeile vaikka molempia hetken ja pystyt sitten päättämään.

 

[kopsteri]

Erityisesti tykännyt truenassissa tuota kun haluat vaihtaa serveri rautaa niin ei muutakun kovot uuteen koneeseen ja asennat truenas ja lataat tallennetun konffin ja kaikki on hetkessä toiminnassa uudelleen.

 

[Joku_242]

Käsittääkseni vain siten, että levyjä, joilta data luetaan on yksi vähemmän. Ongelmaksi tilanne eskaloituu, kun datasta löytyy paljon virheitä resilveroinnin aikana. Tällöin ZFS pudottaa virheilevän levyn offlineen ja levyjä on taas yksi vähemmän. Jos resilverointia ei saada ikinä valmiiksi, menetetään dataa. Resilveroidessa ehjä data pitäisi löytää jostain ja jos perus huoltotoimenpiteitä ei ole tehty, niin sitä ei välttämättä ole. Tämän vuoksi scrubit ovat tärkeitä.

Korjatkaa nyt joku jos olen ZFS:n toiminnan täysin väärin ymmärtänyt

Se on tosin totta, että periaatteessa scrub ja resilverointi eivät ole poolin muille levyille enemmän/vähemmän raskaita. Tuolloin luotettavuus on ongelma lähinnä silloin, jos kaikki levyt ovat samasta valmistuserästä ja on mahdollisuus siihen, että toinenkin levy saattaa olla päässyt elinkaarensa loppuun. Tuon varalle pystyy suunnittelemaan silloin, kun poolia kasataan ja levyt stressitestataan. Sen jälkeen menee tuuripeliksi tämän suhteen. Laadukkailla kovalevyillä riski on aina pienempi, mutta ei silti ikinä 0.

Joo, sitä toki tarkoitin että jos levyt kestää vaikka kuukausittaisen scrubin, on pienempi riski että ne pääsee menemään niin huonoon kuntoon että hajoavat heti resilverissä.

Vaikka ne olisivat samasta erästä, niin aika huono säkä pitää olla että juuri samoilla käyttötunneilla pamahtaisivat ellei ole valmistusvirhettä. Vaikka on sekin toki mahdollista.

 

[dun]

Niin no ikuisuus kysymyahän tuo on. Levyt oikeasti hajoaa aina näin riippumatta valmistajasta (99,5% siis, ei aina .

5 vuoden kohdalla 0,5-3% 10000 levyn otannalla.
LTT:n kohdalla 60 levyä.

Yleensä:
1-2 Dead on Arrival (=DoA), riippuu kuljetushöykytyksestä.
1-30 viikon aikana max 1-2 ehkä (omat kokemukset olleet tämmöisiä).
5 vuoden aikana 60 * 0,02 (Exoksella on yleensä alle 1% vikaantuminen), ehkä 1-2 levyä.

 

[Obi-Lan]

Töissä kaikki menneisyydessä menetetyt RAID pakat olivat sellaisia missä yksi levy hajoaa, alkaa rebuild jolloin ohjain huomaa, ettei toiseltakaan levyltä saa luettua dataa ja koko pakka mennyttä. Nämä oli HP/IBM palvelimia, joissa oli yleensä säästetty ja käytetty SATA levyjä (valmistajan omia merkkilevyjä) SAS levyjen sijaan. En muista oliko noissa ohjaimissa edes mitään patrolreadin tyylistä ominaisuutta vaiko osaamattomuutta. SAS levyissä on taas parempi diagnostiikka, ja ne osaavat itse kertoa paljon varmemmin, jos ovat hajoamassa.

Scrub on mielestäni ihan hyvä koska se varmistaa säännöllisesti, että kaikki data on luettavissa. Etenkin kun SATA levy ei välttämättä tiedä vielä hajonneensa. Jos levy hajoaa scrubiin niin kaikki data siltä levyltä oli jo menetetty.

Piti varmistaa, että tekeekö proxmox scrubin ja siinä homma on tehty päivittäisellä cronjobilla:

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# TRIM the first Sunday of every month.
24 0 1-7 * * root if [ $(date +\%w) -eq 0 ] && [ -x /usr/lib/zfs-linux/trim ]; then /usr/lib/zfs-linux/trim; fi

# Scrub the second Sunday of every month.
24 0 8-14 * * root if [ $(date +\%w) -eq 0 ] && [ -x /usr/lib/zfs-linux/scrub ]; then /usr/lib/zfs-linux/scrub; fi

 

[Timo 2]

Töissä kaikki menneisyydessä menetetyt RAID pakat olivat sellaisia missä yksi levy hajoaa, alkaa rebuild jolloin ohjain huomaa, ettei toiseltakaan levyltä saa luettua dataa ja koko pakka mennyttä. Nämä oli HP/IBM palvelimia, joissa oli yleensä säästetty ja käytetty SATA levyjä (valmistajan omia merkkilevyjä) SAS levyjen sijaan. En muista oliko noissa ohjaimissa edes mitään patrolreadin tyylistä ominaisuutta vaiko osaamattomuutta. SAS levyissä on taas parempi diagnostiikka, ja ne osaavat itse kertoa paljon varmemmin, jos ovat hajoamassa.

Oliko kuinka isoja pakkoja? 5 + 1 on lienee riittävä varmistus, vai pitääkö olla 5 + 2? Montako vuotta / montako tuntia levyjä uskaltaa ajaa ennen levyn vaihtoa, jos smartissa ei näy mitään?

 

[hatih]

Nämä oli HP/IBM palvelimia, joissa oli yleensä säästetty ja käytetty SATA levyjä (valmistajan omia merkkilevyjä) SAS levyjen sijaan.

Yksi hieman vaikuttava tekijä on se että SATA-levyt ovat keskimäärin suht paljon SAS-levyjä isompia joten rebuild kestää kauemmin ja rasittaa niitä vanhoja levyjä enemmän. Tämän takiahan suositellaan että SATA-levyillä toteutettuissa RAID-5 pakoissa ei käytettäisi liian isoja levyjä, oliko maks 4 teraa.

 

[Obi-Lan]

Oliko kuinka isoja pakkoja? 5 + 1 on lienee riittävä varmistus, vai pitääkö olla 5 + 2? Montako vuotta / montako tuntia levyjä uskaltaa ajaa ennen levyn vaihtoa, jos smartissa ei näy mitään?

Sen verran aikaa näistä, että taisivat olla RAID5 2+1 tai 3+1 ja max 750Gb levyjä. Takuusta tuli uudet tilalle eli alle 5v palvelimia olivat. Omassa matopurkki NASsista käytän 4+2 RAIDZ2 eli RAID6 tapaista. Sanoisin, että säännölliset ajastetut scrub, patrol read tai vastaava ajot ovat parhaita hajoavan levyn tunnistukseen, jos niissä tulee toistuvia lukuvirheitä niin sen pitäisi ilmestyä myös SMARTiin ja siitä viimeistään tietää pistää levyn vaihtoon.

Levyrikolta ei voi täydellisellä varmuudella välttyä, moni toki vältyy muuten vaan. Hyvä backup ratkaisu kannattaa olla.

Yksi hieman vaikuttava tekijä on se että SATA-levyt ovat keskimäärin suht paljon SAS-levyjä isompia joten rebuild kestää kauemmin ja rasittaa niitä vanhoja levyjä enemmän. Tämän takiahan suositellaan että SATA-levyillä toteutettuissa RAID-5 pakoissa ei käytettäisi liian isoja levyjä, oliko maks 4 teraa.

Kyllä totta tämäkin. Mielestäni SAS levyissä tuli monesti predict failure viestejä, jolla ne sai jo vaihdettua takuuseen.

 

[Bahamies]

Enää ei malttanut olla tilaamatta uutta rautaa, kun löytyi Asrock Rack X470D4U 220€ hintaan.

Tuolle olisi tarkoitus etsiä kaveriksi joku kohtuuhintainen 2. tai 3. sukupolven Ryzen (2700X, 3600 tai 3700X) ja muistia 2x32Gb (että jää laajennusvaraa jos nälkä taas kasvaa). Toistaiseksi tulee pyörittämään vain omaa tiedostopalvelinta, mutta saa nähdä mitä kaikkea saa tehtäväkseen tulevaisuudessa.

 

[dun]

Enää ei malttanut olla tilaamatta uutta rautaa, kun löytyi Asrock Rack X470D4U 220€ hintaan.

Tuolle olisi tarkoitus etsiä kaveriksi joku kohtuuhintainen 2. tai 3. sukupolven Ryzen (2700X, 3600 tai 3700X) ja muistia 2x32Gb (että jää laajennusvaraa jos nälkä taas kasvaa). Toistaiseksi tulee pyörittämään vain omaa tiedostopalvelinta, mutta saa nähdä mitä kaikkea saa tehtäväkseen tulevaisuudessa.

Juu, tuota itsekin katselin ennen kuin menin tällä nykyisellä Embedded Epycillä. Tossa on muistaakseni impi joten se on jo senkin takia hyvä vekotin. Kannattaa miettiä myös noita AMD:n APU prossuja, niissä kun on se gpu mukana, niin saa sitäkin käytettyä tarvittaessa ilman että tarvii asentaa pci-e väylään mitään.

 

[Eskomoto]

Enää ei malttanut olla tilaamatta uutta rautaa, kun löytyi Asrock Rack X470D4U 220€ hintaan.

Tuolle olisi tarkoitus etsiä kaveriksi joku kohtuuhintainen 2. tai 3. sukupolven Ryzen (2700X, 3600 tai 3700X) ja muistia 2x32Gb (että jää laajennusvaraa jos nälkä taas kasvaa). Toistaiseksi tulee pyörittämään vain omaa tiedostopalvelinta, mutta saa nähdä mitä kaikkea saa tehtäväkseen tulevaisuudessa.

AMD Ryzen 5 PRO 5650G, halvin hinta 222€

Halvin hinta 222 € (232 € toimituskuluineen). Vertailussa 2 kauppaa. Ominaisuudet: Ytimiä: 6, Socket AM4. AMD Ryzen 5 PRO 5650G.

hinta.fi

Tai

AMD Ryzen 5 PRO 4650G, halvin hinta 130€

Halvin hinta 130 € (136 € toimituskuluineen). Vertailussa 5 kauppaa. Ominaisuudet: Ytimiä: 6, Socket AM4. AMD Ryzen 5 PRO 4650G.

hinta.fi

 

[Bahamies]

Kiitti vinkeistä!

Normaalisti ehkä olisin kallistunut APU-ratkaisuun, mutta satuin itse juuri hankkimaan tuollaisen SFF-PC:n taannoin, juuri sitä varten, että kaikki palvelut, jotka hyötyvät QSV:stä, voin heittää pyörimään sille. Koska emoltakin löytyy IPMI, niin en oikein keksi käyttöä tässä kokoonpanossa APU:lle. Samaan hintaan kuin 5650G sai Ebaysta 3700X:n, joka soveltuu omaan käyttöön vähän paremmin.

Olen nyt pakottanut itseni tutustumaan tarkemmin Dockeriin sillä ajatuksella, että tämä toimii väliportaana virtualisointiin, jos siitäkin innostuu joskus. Tosin nyt tuntuu siltä, että Dockerinkin kanssa suurin ongelma on oma luovuus, kun ei meinaa edes keksiä mitä kaikkea sillä tekisin. Tätä käyttöä silmälläpitäen tärkeämpää on tehokas prosessori, vaikka ero 5650G:n ja 3700X:n välillä ei kauhean suuri ole.

 

[Psychedelic]

Kiitti vinkeistä!

Normaalisti ehkä olisin kallistunut APU-ratkaisuun, mutta satuin itse juuri hankkimaan tuollaisen SFF-PC:n taannoin, juuri sitä varten, että kaikki palvelut, jotka hyötyvät QSV:stä, voin heittää pyörimään sille. Koska emoltakin löytyy IPMI, niin en oikein keksi käyttöä tässä kokoonpanossa APU:lle. Samaan hintaan kuin 5650G sai Ebaysta 3700X:n, joka soveltuu omaan käyttöön vähän paremmin.

Olen nyt pakottanut itseni tutustumaan tarkemmin Dockeriin sillä ajatuksella, että tämä toimii väliportaana virtualisointiin, jos siitäkin innostuu joskus. Tosin nyt tuntuu siltä, että Dockerinkin kanssa suurin ongelma on oma luovuus, kun ei meinaa edes keksiä mitä kaikkea sillä tekisin. Tätä käyttöä silmälläpitäen tärkeämpää on tehokas prosessori, vaikka ero 5650G:n ja 3700X:n välillä ei kauhean suuri ole.

5650G-ehdotus on siitä hyvä, että AMD:lla ECC on validoitu toimimaan työpöytäprosessoreista ainoastaan Threadrippereillä ja Ryzen Pro-malleilla (kuten 5650G). Toki ECC periaatteessa toimii myös muilla Ryzeneillä, mutta sen käytännön toimivuus ja tuki vaihtelee runsaasti eri emolevyjen kesken.
Itse päädyin 5650GE-malliin juuri tästä syystä.

 

[Bahamies]

5650G-ehdotus on siitä hyvä, että AMD:lla ECC on validoitu toimimaan työpöytäprosessoreista ainoastaan Threadrippereillä ja Ryzen Pro-malleilla (kuten 5650G). Toki ECC periaatteessa toimii myös muilla Ryzeneillä, mutta sen käytännön toimivuus ja tuki vaihtelee runsaasti eri emolevyjen kesken.
Itse päädyin 5650GE-malliin juuri tästä syystä.

Itse olen käsittänyt juuri niin päin, että prosessorien suhteen tuki löytyy kaikista, mutta emolevyjen suhteen toimivuus on vaihdellut. Asrock Rackin AM4-emolevyt tukevat ECC:tä eli en olisi sen suhteen huolissani, toki tuohan on myös helppo testata miten asia toimii käytännössä, kun osat saapuvat.

Tässä AMD:n edustaja vastaa ainakin kategorisesti "kyllä" ECC-tuen suhteen 3700X:n kanssa. Ehtoina, että käytössä UDIMM ECC-muistit ja sopiva emolevy.

 

[Psychedelic]

Itse olen käsittänyt juuri niin päin, että prosessorien suhteen tuki löytyy kaikista, mutta emolevyjen suhteen toimivuus on vaihdellut. Asrock Rackin AM4-emolevyt tukevat ECC:tä eli en olisi sen suhteen huolissani, toki tuohan on myös helppo testata miten asia toimii käytännössä, kun osat saapuvat.

Tässä AMD:n edustaja vastaa ainakin kategorisesti "kyllä" ECC-tuen suhteen 3700X:n kanssa. Ehtoina, että käytössä UDIMM ECC-muistit ja sopiva emolevy.

Tätä nimenomaan hain, että tuki löytyy. Virallista validointia kuitenkaan ei ole ja vaatii emolevyn (ja BIOSin) joka tukee ECC:tä kyseisen prosessorin kanssa.
Eli jos ei satu juuri oman emon kanssa toimimaan, no can do. Asrock on ollut kuitenkin parhaimmasta päästä ECC-tuen suhteen.

Täällä on aika hyvin kuvattu tilanne:
r/Amd - Demystifying Ryzen ECC Support

• Ryzen has no official ECC support, but will utilize ECC RAM, if available
• Motherboard manufacturers must support ECC operation mode
• The chipset is irrelevant
• There is no firmware error reporting, hence no official way to verify if an ECC configuration works or not

 

[Joku_242]

Kiitti vinkeistä!

Normaalisti ehkä olisin kallistunut APU-ratkaisuun, mutta satuin itse juuri hankkimaan tuollaisen SFF-PC:n taannoin, juuri sitä varten, että kaikki palvelut, jotka hyötyvät QSV:stä, voin heittää pyörimään sille. Koska emoltakin löytyy IPMI, niin en oikein keksi käyttöä tässä kokoonpanossa APU:lle. Samaan hintaan kuin 5650G sai Ebaysta 3700X:n, joka soveltuu omaan käyttöön vähän paremmin.

Olen nyt pakottanut itseni tutustumaan tarkemmin Dockeriin sillä ajatuksella, että tämä toimii väliportaana virtualisointiin, jos siitäkin innostuu joskus. Tosin nyt tuntuu siltä, että Dockerinkin kanssa suurin ongelma on oma luovuus, kun ei meinaa edes keksiä mitä kaikkea sillä tekisin. Tätä käyttöä silmälläpitäen tärkeämpää on tehokas prosessori, vaikka ero 5650G:n ja 3700X:n välillä ei kauhean suuri ole.

Sanoisin että Dockerin hyödyllisyys kotipalvelimessa on vähän kyseenalaista. Sillä saa nopeasti skaalattua ylös nettipalvelun kapasiteettia esim. jos tulee paljon lisää käyttäjiä, mistä tuskin on kotikäyttäjälle iloa kun kaikki kuitenkin on yhdellä koneella. Jos taas haluaa eristää nettiin näkyvän softan (esim. kuvagalleria) omasta NAS-boksista, virtuaalikone on turvallisempi valinta.

 

[Bahamies]

Sanoisin että Dockerin hyödyllisyys kotipalvelimessa on vähän kyseenalaista. Sillä saa nopeasti skaalattua ylös nettipalvelun kapasiteettia esim. jos tulee paljon lisää käyttäjiä, mistä tuskin on kotikäyttäjälle iloa. Jos taas haluaa eristää nettiin näkyvän softan (esim. kuvagalleria) omasta NAS-boksista, virtuaalikone on turvallisempi valinta.

Minulla ei ole edes palveluita nettiin auki kyseiseltä palvelimelta, joten hyöty-näkökulmaa en edes mieti. Kyse on lähinnä erilaisiin toteutuksiin tutustumisesta ja opiskelusta.

Virtualisointiin suhtaudun vähän samalla tavalla. Nyt sille ei varsinaista tarvetta edes ole, mutta sekin on aihepiiri joka kiinnostaisi. Tosin virtualisointi avaisi ehkä omaa kotikäyttöäni varten "järkevämpiä" asioita testattavaksi (esim. mainitsemasi eristäminen), Docker nyt on lähinnä itselle vaihtoehtoinen tapa ottaa sovelluksia käyttöön.

Tosin on tässä ihan kotikäytön kannalta hyötynsäkin, Portainerin avulla palvelujen käyttöönotto ja ylläpito on helppoa ja Portainer Agentien avulla saa ylläpidettyä kaikki kotiverkon kontteja helposti. Toki vastaavia toteutuksia voi tehdä ilman Dockeria ja Portaineria, mutta ei oman kokemuksen mukaan ihan yhtä pienellä vaivalla.

 

[Joku_242]

Minulla ei ole edes palveluita nettiin auki kyseiseltä palvelimelta, joten hyöty-näkökulmaa en edes mieti. Kyse on lähinnä erilaisiin toteutuksiin tutustumisesta ja opiskelusta.

Virtualisointiin suhtaudun vähän samalla tavalla. Nyt sille ei varsinaista tarvetta edes ole, mutta sekin on aihepiiri joka kiinnostaisi. Tosin virtualisointi avaisi ehkä omaa kotikäyttöäni varten "järkevämpiä" asioita testattavaksi (esim. mainitsemasi eristäminen), Docker nyt on lähinnä itselle vaihtoehtoinen tapa ottaa sovelluksia käyttöön.

Tosin on tässä ihan kotikäytön kannalta hyötynsäkin, Portainerin avulla palvelujen käyttöönotto ja ylläpito on helppoa ja Portainer Agentien avulla saa ylläpidettyä kaikki kotiverkon kontteja helposti. Toki vastaavia toteutuksia voi tehdä ilman Dockeria ja Portaineria, mutta ei oman kokemuksen mukaan ihan yhtä pienellä vaivalla.

En ole itse käyttänyt Portaineria, joten en siitä osaa sanoa, ja Dockeria/kubernetesta vaan työjutuissa. Googlailun perusteella Portainer on joku webbikäyttöliittymä noille, ja jos puhtaasti haluaa opetella tunkkausta, en tiedä kannattaako siitä lähteä liikkeelle.

Mihin oot muuten käyttänyt Portaineria?

 

[Bahamies]

En ole itse käyttänyt Portaineria, joten en siitä osaa sanoa, ja Dockeria/kubernetesta vaan työjutuissa. Googlailun perusteella Portainer on joku webbikäyttöliittymä noille, ja jos puhtaasti haluaa opetella tunkkausta, en tiedä kannattaako siitä lähteä liikkeelle.

Mihin oot muuten käyttänyt Portaineria?

Itse aloitin siis ihan terminaalin kautta docker run-pohjalta liikkeelle, olen erilaisia kontteja kotikäytössä pyörittänyt kolmisen vuotta.

Lähinnä graafisena käyttöliittymänä olen sitä käyttänyt, vaihtoehtoinen käyttötapa vilkuilla konttien kuulumisia tai ottaa uusia käyttöön. Vaatii kyllä tosiaan sen, että dockerin toiminnan perustuntemus on kunnossa, muuten tuolla ei kauheasti saa aikaan.

 

[Joku_242]

Itse aloitin siis ihan terminaalin kautta docker run-pohjalta liikkeelle, olen erilaisia kontteja kotikäytössä pyörittänyt kolmisen vuotta.

Lähinnä graafisena käyttöliittymänä olen sitä käyttänyt, vaihtoehtoinen käyttötapa vilkuilla konttien kuulumisia tai ottaa uusia käyttöön. Vaatii kyllä tosiaan sen, että dockerin toiminnan perustuntemus on kunnossa, muuten tuolla ei kauheasti saa aikaan.

Jooh, näin voisi kuvitellakin asian olevan. Mutta tarkoitin että mihin tarkoitukseen olet noita kontteja pyöritellyt? Sinänsä luulisi että perus NAS-toiminnot kuten levytilan jako on helpompi toteuttaa ilman kontteja kuin niiden kanssa.

 

[Bahamies]

Jooh, näin voisi kuvitellakin asian olevan. Mutta tarkoitin että mihin tarkoitukseen olet noita kontteja pyöritellyt? Sinänsä luulisi että perus NAS-toiminnot kuten levytilan jako on helpompi toteuttaa ilman kontteja kuin niiden kanssa.

Kontit vähän vaihtelevat, mutta toistaiseksi käyttö on ollut kahdenlaista. Yksi syy kontin käytölle on ollut se, että kyseisen softan asennus on suositeltavaa kontissa. Miksi näin on, pitäisi kysyä sitten kehittäjältä, mutta tästä nyt vaikka esimerkkinä tuo Scrutiny, jota aloin hiljattain käyttää. Käyttöönotto tälle on helpointa kontissa.

Toinen on testaustarkoitus. Yleensä kun suunnittelen jonkin palvelun käyttöönottoa, niin tykkään testailla softaa ensin kontissa (ilman sen kummoisempia räätälöintejä), jotta saan vähän kuvaa käyttötuntumasta. Tälla tavalla pystyy kätevästi vertailemaan muutaman eri vaihtoehdon ja poistamaan asennuksen helposti. Yleensä näissä tilanteissa laitan sen voittaneen vaihtoehdon pyörimään ilman Dockeria ellei käyttöä sitten jostain syystä suositella kontissa.

Eli karkeasti:
1. Koska on se on järkevämpää syystä x
2. Käytän testiympäristönä

Kaikki minulle tärkeät palvelut pyrin aina käyttämään ilman kontteja, jos mahdollista.

 

[ruorimies]

Nyt on TrueNas projektiin emo ja muistit kotona, koppa ja poweri matkalla. Miten tuon emon prossujäähdytys kannattaisi hoitaa? Kyseessä Supermicro X9 series emo jossa Xeon E3-1275v2 prossu. Kopaksi tulee Fractalin Node804. Äänitaso ei ole kovin merkityksellinen kun kone jää autotallin puolelle.

ehdotuksia?

 

[Joku_242]

Nyt on TrueNas projektiin emo ja muistit kotona, koppa ja poweri matkalla. Miten tuon emon prossujäähdytys kannattaisi hoitaa? Kyseessä Supermicro X9 series emo jossa Xeon E3-1275v2 prossu. Kopaksi tulee Fractalin Node804. Äänitaso ei ole kovin merkityksellinen kun kone jää autotallin puolelle.

ehdotuksia?

Mulla on myös Supermicro X9-sarjan emo, ja yksinkertaisesti ostin tältä palstalta jonkun halvan jäähyn. Tosiaan ei tarvi olla kauhean ihmeelliset jäähdytystehotkaan, kun ei ole kellotusta mielessä.

Nykyään näemmä vanhempia Noctuoitakin saa parilla kympillä.

Myyty - Noctua NH-U12P (AM4 / 1x NF-P12) [Turku]

Myytävä tuote: Noctua NH-U12P (AM4) 1x NF-P12 Hinta: 15e Tuote ostettu (mistä ja milloin): Verkkokauppa.com (10.8.2008) Kuitti löytyy (takuu voimassa): Kyllä (ei) Muuta huomioitavaa: Todella hyvin ja pitkään palvellut jäähy myyntiin kun tuli ostettua mITX-kotelo ja siinä integroitu jäähy...

bbs.io-tech.fi

 

[Bahamies]

Mulla on myös Supermicro X9-sarjan emo, ja yksinkertaisesti ostin tältä palstalta jonkun halvan jäähyn. Tosiaan ei tarvi olla kauhean ihmeelliset jäähdytystehotkaan, kun ei ole kellotusta mielessä.

Eikös noissa joissain X9-sarjalaisissakin ole Supermicron oma backplate? Se monimutkaistaa jäähdytinhankintaa ainakin uudemmissa X10-emolevyissä.

Itse ratkaisin tuon sillä, että kiinnitin vaan tuulettimen mukana tulleeseen passiiviseen 1U-jäähdyttimeen. Tuolla pysyy lämmöt aina alle 60 asteen omassa käytössä.

Jotkin jäähdyttimet ovat suoraan sopivia tuohon Supermicron backplateen, mutta saatavuuden sellaisille ovat huonot oman kokemukseni mukaan.

 

[Joku_242]

Eikös noissa joissain X9-sarjalaisissakin ole Supermicron oma backplate? Se monimutkaistaa jäähdytinhankintaa ainakin uudemmissa X10-emolevyissä.

Itse ratkaisin tuon sillä, että kiinnitin vaan tuulettimen mukana tulleeseen passiiviseen 1U-jäähdyttimeen. Tuolla pysyy lämmöt aina alle 60 asteen omassa käytössä.

Jotkin jäähdyttimet ovat suoraan sopivia tuohon Supermicron backplateen, mutta saatavuuden sellaisille ovat huonot oman kokemukseni mukaan.

Joo, omassakin oli sellainen backplate, mutta sen sai irrotettua kuumentamalla sitä varovaisesti kuumailmapuhaltimella, mikä sulatti liiman. En tiedä oliko aktiivijäähyn käyttö liioittelua, mutta esim. ZFS:n scrubi pistää prossun kuormille useammaksi tunniksi putkeen.

 

[ruorimies]

Nykyään näemmä vanhempia Noctuoitakin saa parilla kympillä.

Myyty - Noctua NH-U12P (AM4 / 1x NF-P12) [Turku]

Myytävä tuote: Noctua NH-U12P (AM4) 1x NF-P12 Hinta: 15e Tuote ostettu (mistä ja milloin): Verkkokauppa.com (10.8.2008) Kuitti löytyy (takuu voimassa): Kyllä (ei) Muuta huomioitavaa: Todella hyvin ja pitkään palvellut jäähy myyntiin kun tuli ostettua mITX-kotelo ja siinä integroitu jäähy...

bbs.io-tech.fi

Oliko siis niin että Noctua sopii sellaisenaan tuohon X9 lankkuun vai edellyttää modausta?
en ehtinyt vielä tutustua oliko tuossa emossa joku backplate vai ei. Ei toi speksikään mitään mulle ainakaan kerro.

Supermicro | Products | Motherboards | Xeon® Boards | X9SCM-F

 

[Joku_242]

Oliko siis niin että Noctua sopii sellaisenaan tuohon X9 lankkuun vai edellyttää modausta?
en ehtinyt vielä tutustua oliko tuossa emossa joku backplate vai ei. Ei toi speksikään mitään mulle ainakaan kerro.

Supermicro | Products | Motherboards | Xeon® Boards | X9SCM-F

Eikös X9-sarjan emoissa ole normaali LGA1155 -kanta? Kai Noctuan pitäisi saada siihen kiinni, ainakin jos myyjällä on ne palikat tallella. Ja jos mukana ei tullut niitä, Noctualta pitäisi saada sovituspalat tilattua ilmaiseksi.

Supermicron oman backplaten tosin taitaa joutua irrottamaan, jos siinä semmoinen on.

 

[ruorimies]

Ok, tutkitaan. Pikaetsinnällä tällainenkin usui silmään, olenko oikealla polulla?

SNK-P0046P Passive CPU heatsink Grey tuuletin - 23.01 €

Hinta: 23.01 €. Tietokoneet - Komponentit - Tuulettimet: SNK-P0046P Passive CPU heatsink Grey tuuletin

www.rde.fi

 

[Bahamies]

Oliko siis niin että Noctua sopii sellaisenaan tuohon X9 lankkuun vai edellyttää modausta?
en ehtinyt vielä tutustua oliko tuossa emossa joku backplate vai ei. Ei toi speksikään mitään mulle ainakaan kerro.

Supermicro | Products | Motherboards | Xeon® Boards | X9SCM-F

Noctuat tulevat oman backplaten kanssa eli en tiedä yhtään nykyistä joka sopisi. Periaatteessahan modailu ei vaatisi kuin sopivat ruuvit. Helpointa oman elämän kannalta olisi irrottaa se backplate ja laittaa coolerin oma kiinni. Itse en siihen kuitenkaan lähtisi ilman kuumailmapuhallinta. Muutenkin nuo E3-Xeonit jäähtyvät aika helposti, niin eikun vaan tuuletinta siileen kiinni jos tulee mukana.

Eikös X9-sarjan emoissa ole normaali LGA1155 -kanta? Kai Noctuan pitäisi saada siihen kiinni, ainakin jos myyjällä on ne palikat tallella. Ja jos mukana ei tullut niitä, Noctualta pitäisi saada sovituspalat tilattua ilmaiseksi.

Niin minäkin luulin, mutta: Yhteensopivuustaulukko on aika tylyä luettavaa.

Ok, tutkitaan. Pikaetsinnällä tällainenkin usui silmään, olenko oikealla polulla?

SNK-P0046P Passive CPU heatsink Grey tuuletin - 23.01 €

Hinta: 23.01 €. Tietokoneet - Komponentit - Tuulettimet: SNK-P0046P Passive CPU heatsink Grey tuuletin

www.rde.fi

Tuo sopii käsittääkseni, mutta tarkista vielä Supermicron materiaaleista.

Tässä listaa sopivista jäähdyttimistä.

 

[Joku_242]

Niin minäkin luulin, mutta: Yhteensopivuustaulukko on aika tylyä luettavaa.

Ja kun lukee mitä siellä sanotaan, niin todetaan että ongelmana on Supermicron backplate (jonka pitäisi saada irti kuumailmapuhaltimen avustuksella), ja lisäksi tarvii tilata mounttauskitti, jonka saa ilmaiseksi.

NH-U12S SE-AM4

The pre-installed backplate is glued to the motherboard which prevents the installation of our mounting system. Optional mounting-kit required (free of charge). Please contact our support team.

Ok, tutkitaan. Pikaetsinnällä tällainenkin usui silmään, olenko oikealla polulla?

SNK-P0046P Passive CPU heatsink Grey tuuletin - 23.01 €

Hinta: 23.01 €. Tietokoneet - Komponentit - Tuulettimet: SNK-P0046P Passive CPU heatsink Grey tuuletin

www.rde.fi

Hmm, itse ehkä yrittäisin ennemmin irroittaa backplatea kuin ostaa jäähyä, jos sitä ei tule emon mukana. Mutta kaipa tämä on makuasia.

 

[Bahamies]

Hmm, itse ehkä yrittäisin ennemmin irroittaa backplatea kuin ostaa jäähyä, jos sitä ei tule emon mukana. Mutta kaipa tämä on makuasia.

No sanotaanko nyt näin, että jos yhtään pysyy työkalut käsissä ja vähänkään järkeä on mukana kun alkaa irrotella, niin todellakin kannattaa. Itse koitin pitkään etsiä omaan 4U koteloon sopivaa jäähdytintä ja valinnan vara oli todella rajallinen. Itsekin teen tuon operaation, kun nyt joskus jaksan ottaa tuon emolevyn irti hetkeksi. Tuohon irrottamiseenkin löytyy ihan ohjeet jostain Truenasin foorumeilta.

Toisaalta jos nyt ei 100% rasituksella aja tuota kokoonpanoaan usein, niin veikkaan että tuo 1U siili ja tuuletin riittää (myös scrubien aikana omassa palvelimessa). Nämä nyt ovat kuitenkin jo sitten käyttäjäkohtaisia asioita.

 

[ruorimies]

Kuumailmapuhallin löytyy, eli sillä ensin liikkeelle. kiitos jeeseistä.

 

[ruorimies]

Projekti etenee, backplate on nyt poissa ja jäähyä odotellaan että pääsee asentamaan. TrueNasin käyttötarkoitus tulee olemaan mediapalvelin, Nextcloud, Plex MS ja pari pikku jailia (Sonarr/Radarr).

Lopputuloksena suunniteltu setuppi olisi jotakuinkin tällainen:
1x 120Gb Ssd (OS)
4x 4TB HDD zfs poolina (media)
2x 2TB HDD zfs poolina (Nextcloud)
2x 500Gb Ssd (cache)

Emolla on 6 Sata liitäntää, joten joku lisäkortti pitää hankkia. Onko järkevintä hankkia joku PCI-E SAS/sata kortti, esim:

SilverStone ECS04, 8-porttinen SAS/SATA RAID-kortti, PCIe Gen3 x8 - 158,90€

Ominaisuudet : - 8 x SAS/SATA -portti - Tukee SAS/SATA 6Gb/s - PCI-E Gen 3.0 x8 läpivienti 64 Gbps - Low Profile design - Tukee RAID 0, 1, 1E, 10 Tekniset tiedot :

www.jimms.fi

ja ajaa noita zfs pakkoja SAS levyinä, ja jättää emon sata litännät Ssd levyille? Vai riittääkö joku halpis sata kortti?

Sitten käytännön haasteet.
Nyt käytössä on pikku NAS jossa 1x 1TB HDD dokkareille ja backupeille ja 1x 4Gb Ironwolf HDD joita ostan 3kpl lisää. Ensin kaksi 4TB uuteen NASiin jotta saan siirrettyä vanhalta mediat. Sitten kaksi levyä lisää (toinen vanhasta NASista), niin eikös zfs poolin voi jälkikäteen muuttaa neljälle levylle 8GB varmistetuksi (2x4TB x 2)?

Vanha Zyxelin NASsi jäisi ehkä sitten TrueNAsin backupiksi kun hankkii siihen uudet levyt.

MIten noi 500GB Ssd levyt kannattaa parhaiten hyödyntää? Käytössä olisi myös kaksi 250Gb SSd levyä joita voi hyödyntää jollain tavalla. Ja onko OS järkevää edes asentaa omalle 120Gb SSd levylle vai suoraan toiselle 500Gb levylle?

Ideoita ja ehdotuksia kuunnellaan, aikaa on vielä ennen kuin hankin loput osat.

 

[Purulumi]

Projekti etenee, backplate on nyt poissa ja jäähyä odotellaan että pääsee asentamaan. TrueNasin käyttötarkoitus tulee olemaan mediapalvelin, Nextcloud, Plex MS ja pari pikku jailia (Sonarr/Radarr).

Lopputuloksena suunniteltu setuppi olisi jotakuinkin tällainen:
1x 120Gb Ssd (OS)
4x 4TB HDD zfs poolina (media)
2x 2TB HDD zfs poolina (Nextcloud)
2x 500Gb Ssd (cache)

Emolla on 6 Sata liitäntää, joten joku lisäkortti pitää hankkia. Onko järkevintä hankkia joku PCI-E SAS/sata kortti, esim:

SilverStone ECS04, 8-porttinen SAS/SATA RAID-kortti, PCIe Gen3 x8 - 158,90€

Ominaisuudet : - 8 x SAS/SATA -portti - Tukee SAS/SATA 6Gb/s - PCI-E Gen 3.0 x8 läpivienti 64 Gbps - Low Profile design - Tukee RAID 0, 1, 1E, 10 Tekniset tiedot :

www.jimms.fi

ja ajaa noita zfs pakkoja SAS levyinä, ja jättää emon sata litännät Ssd levyille? Vai riittääkö joku halpis sata kortti?

Sitten käytännön haasteet.
Nyt käytössä on pikku NAS jossa 1x 1TB HDD dokkareille ja backupeille ja 1x 4Gb Ironwolf HDD joita ostan 3kpl lisää. Ensin kaksi 4TB uuteen NASiin jotta saan siirrettyä vanhalta mediat. Sitten kaksi levyä lisää (toinen vanhasta NASista), niin eikös zfs poolin voi jälkikäteen muuttaa neljälle levylle 8GB varmistetuksi (2x4TB x 2)?

Vanha Zyxelin NASsi jäisi ehkä sitten TrueNAsin backupiksi kun hankkii siihen uudet levyt.

MIten noi 500GB Ssd levyt kannattaa parhaiten hyödyntää? Käytössä olisi myös kaksi 250Gb SSd levyä joita voi hyödyntää jollain tavalla. Ja onko OS järkevää edes asentaa omalle 120Gb SSd levylle vai suoraan toiselle 500Gb levylle?

Ideoita ja ehdotuksia kuunnellaan, aikaa on vielä ennen kuin hankin loput osat.

Omia ajatuksia:
PCI-E SAS/SATA kortiksi löytyy kolmasosan maksavia vaihtoehtoja, jos 3 viikon toimistusaika ei ole ongelma:

INSPUR 9211-8i 6Gbps HBA LSI FW:P20 IT Mode ZFS FreeNAS unRAID+2* SFF-8087 SATA | eBay

ETA 3 to 6 Weeks. We will do our best and help you provide the solution. ※ All faulty due to improper installation or improper use will NOT be covered by the warranty.

www.ebay.de

Itsellä on tämä ja toimii. Kuhan katsot kortin, joka on valmiiksi IT-modessa RAID-moden sijaan.

500GB SSD cache jokaiselle poolille erikseen. Truenas ei itse tarvitse juurikaan tilaa, oma VM pyörii 20GB osiolla.

Kannattaa tehdä heti 4 levyn kanssa raidz2 mallin pooli, jos sellaista on lähtökohtaisesti tekemässä. Levyn lisäämisestä ja raidz tyypin vaihdosta ei ole kokemusta tai onko ylipäätään mahdollista. Cache levyn lisääminen ei ainakaan ollut iso juttu.