NAS rakentelut

Osjur

ლ(ಠ益ಠ)ლ
Liittynyt
18.10.2016
Viestejä
54
Hm... miksi et tehnyt raidz2 tai raidz3? Ei olisi yhden tai kahden levyn hajoamisen haitannut? Nuo mircrosoftin koomailuviritykset kyllä toimii siinä missä unraidikin, mutta jos oikeasti haluaa saada tiedon talteen niin en menisi millään järjestelmällä alle kahden paritettilevyn. ZFS on vain paras ja luotettavin noista vaihtoehdoista kun se huolehtii bitrotista ja saa todella halvat ja hyvät snapshotit.

Tietenkin jos unix/linux maailma ei ole tuttu tai ei ole kiinnostusta siirtyä Microsoftin tuotteista muualle, niin ihan ymmärrettävää. Microsoftin tuotteet on vain sen verran huonot että edes he eivät pyöritä Azurea Windowssin päällä...
Juurihan sanoin että nykynen on raid6 (raidz2) snapshot raid. Snapraid ei ole missään tekemisissä microsoftin storage spaces ym. kanssa. Siinä on aivan yhtä hyvä suoja bitrottia vastaan kuin ZFS. Nuo vanhemmat raid5 pakat (yks windows ja yks linux) mitkä on itsellä hajonnut, on ollut aikakaudelta kun 1-2tb kovot oli vielä isoja. Ja koska Snapraid on JBOD tyylinen, niin jos se monen levyn rikko tulee ja tekee raidin rebuildista mahdottoman, niin silti niiltä levyiltä jotka jäi eloon saa sen datan vielä talteen.
ZFS:ssä taas tulee nuo nopeusedut sekä "ilmaiset" snapshotit joissa ei riskiä sille että data voisi muuttua snapshotin aikana. Lisäksi ZFS on esim. FreeNASsilla käytännössä yhtä helppo ottaa käyttöön.
Millään näistä "tee-se-itse" ratkaisuista ei taida olla helppoa valmista tapaa datan helppoon backuppaamiseen. Ymmärtääkseni Synologyllä yms on backuppeihin valmiita toimintoja esim. ulkoiselle levylle tai pilveen tai toiseen Synologyyn esim. toisessa kiinteistössä.

Tuo sun kuvailema setuppi on mielestäni enemmän tuollainen hybridi backuppia ja pariteetin laskemista. Se ei ilmeisesti ole reaaliaikainen eli riski datalossille on pienessä aikaikkunassa kohtuullisen suuri?
Tarpeita on erilaisia ja siksi ratkaisujakin on useampia.
Jees, periaatteessa tämä setup on hybridi, tosin sillä erotuksella että se duplikointi on reaaliaikainen sille tärkeelle datalle. Drivepool hoitaa sen duplikoinnin levyjen poolauksen lisäksi. Jos siirrän dataa poolin kansioon joka on määritetty duplikoitavaksi niin se data kirjoitetaan heti kaikille datalevyille ja tästä uudesta datasta snapraid laskee sitten vielä pariteetit öisin. Tätä käsittääkseni kutsutaan raid1+6 nykyään vaikka tää mun ratkaisu onkin realtime/snapshot hybridi. Ei niin tärkeä data jota ei duplikoida, voi kadota bittiavaruuteen, jos se levy minne se data kirjoitettiin, hajoaa ennen uutta pariteetin laskua.

Jossain kohtaa voisi varmaan ruveta tuota tärkeää dataa ajaa myös pilveen.
 
Viimeksi muokattu:

jsa

Liittynyt
20.10.2016
Viestejä
311
Apropoo, pitäs uusia modernimaan toi HBA levyservosta (max 2t rajote levyissä) joten mikäs se nyt on bang/$ mittarilla paras vaihtoehto? Kattelin IBM:n m1015:sta mutta onkos raadilla ehdottaa jotain parempaa värkkiä? Oman mausteensa soppaan tuo HP:n SAS expanderi..
 
Liittynyt
02.12.2016
Viestejä
1 640
Haluttujen / vaadittujen liitäntöjen määrä? Ulkoisia vai sisäisiä? Millä liittimellä? Onko jokin tietty piirisarja ulkona yhteensopivuuksien / muiden syiden johdosta?
 

jsa

Liittynyt
20.10.2016
Viestejä
311
Haluttujen / vaadittujen liitäntöjen määrä? Ulkoisia vai sisäisiä? Millä liittimellä? Onko jokin tietty piirisarja ulkona yhteensopivuuksien / muiden syiden johdosta?

Sisäisellä SFF-8087:llä. Yhteensopivuus onkin sitten vähän vaikeampi juttu. LSI:n piirit on ainakin toimineet tuon kanssa, mutta tuo voi nirsoilla kyllä.
 
Liittynyt
17.10.2016
Viestejä
497
Apropoo, pitäs uusia modernimaan toi HBA levyservosta (max 2t rajote levyissä) joten mikäs se nyt on bang/$ mittarilla paras vaihtoehto? Kattelin IBM:n m1015:sta mutta onkos raadilla ehdottaa jotain parempaa värkkiä? Oman mausteensa soppaan tuo HP:n SAS expanderi..
Oletko varmistanut että se HP:n SAS expander tukee kans yli 2t levyjä? Käsittääkseni ainakin SAS1 raudassa voi olla rajoituksia.
 
Liittynyt
02.12.2016
Viestejä
1 640
Oletko varmistanut että se HP:n SAS expander tukee kans yli 2t levyjä? Käsittääkseni ainakin SAS1 raudassa voi olla rajoituksia.
Jos ja kun kyseessä on tämä kortti, niin kyllä sen pitäisi olla SAS2 vehje, ellei sitten käy lottovoitto ja saa tuota aataminaikaista versiota käsiinsä:

 

jsa

Liittynyt
20.10.2016
Viestejä
311
Mikä käyttis siinä siis on?
Tällä hetkellä ihan Ubuntun alla pyörii, mutta mikään ei estä vaihtamasta käyttistä jos on tarvis. Kyse lähinnä siitä että alkaa 2teran levyt käymään pieniksi.
Ja juu on SAS 2.0 rauta. Pitkään toiminut, mutta nyt voisi taasen vaihtaa noita pienempiä levyjä pois isommiksi -> kontrolleri vaihtoon.
Eihän tuo enään ole niin nopea, mutta tuolla vielä saa oman lähiverkon saturoitua joten en vielä mieti expanderin vaihtoa "modernimpaan".

Samalla menee varmaan jollain aikataululla toi x4 B555 vaihtoon kattellaan nyt ensin nää muut romppeet kuntoon :)
 
Liittynyt
02.12.2016
Viestejä
1 640
ööm niin siis, SAS2 tukee yli 2.7 teran levyjä. Mikä ohjain sulla nyt sitten on?
 

jsa

Liittynyt
20.10.2016
Viestejä
311
LSI 1068e pohjainen. Max 2.2T mitä voi saada toimiin, käytännössä 2T levy max. Eli ajellaan HBA IT:llä sitä SAS expanderia, jossa SATA levyt kiinni.
 

andyks

Tukijäsen
Liittynyt
20.09.2018
Viestejä
179
Jahas. Wddiag extended testit ajettu my bookeille läpi. Aika korkata kotelot jotta saa levyt nassiin.
Koodin mukaan haukkuvat wd Red levyiksi.
Mistä kotelosta nämä WD80EDAZ levyt ovat? Ei ole itsellä tuon näköisiä tullut vastaan vaikka tullut useampi MyBook ja Elements shuckattua.
 
Liittynyt
27.12.2016
Viestejä
294
Amazon.de tilatuissa My Bookeissa. 3kpl tuli ja vielä pitäs toiset kolme tilata. Kaksi korkkasin ja molemmissa samanlaiset. Kolmas vielä testissä ennen kotelon purkua.
Valmispvm ainakin näissä tuore kun on feb 2020.
IMG_20200324_114031.jpg
 
Viimeksi muokattu:
Liittynyt
07.03.2017
Viestejä
124
Nämä uudet MyBookit on kyllä ihana helppoja avata. Ne kaarevalla etuosalla oli kyl piruja avata, kun nämä avautuvat miltei vain sanomalla "kiltti!" :)
 
Liittynyt
15.08.2017
Viestejä
18
Itsekin tilasin kuun alussa Amazon.de:stä aiemmasta alesta 6 kpl 8 TB MyBookeja (itse 3 kpl ja puoliso toiset 3 kpl, koska myyntirajoitus). Näissä oli kaikissa WD80EZAZ-11TDBA0 sisässä. Oli kyllä helppo purkaa nuo koteloista kitaraplektrojen avulla, eipä tainnut minkäänlaisia jälkiä jäädä koteloihin. Sähköteipillä voi eristää 3 vasemmanpuoleista virtapinniä sen yhden sijasta, ei haittaa mitään ja isompi teippipala on helpompi saada paikalleen kuin yhden pinnin millisuikale.

Itse ajoin nuo sisään pitemmän kaavan kautta eli alkuun kaikille short ja long SMART-testit, sitten badblocksilla kovot kurmotukseen ja sen perään vielä yksi long SMART. Vajaa viikko meni tuohon rumbaan ja kaikki levyt läpäisivät puhtain paperein ja SMART-tiedoissa ei virheitä. Nyt riittää NAS:ssa taas tilaa hetkeksi.
 
Liittynyt
17.10.2016
Viestejä
381
Itse ostin kanssa pari tuollaista ja korkkasin ja levyt sisään ja Unraidissa preclear läpi ongelmitta. Itse en tehnyt mitään teippivirityksiä, vaan löin levyt suoraan koneeseen kiinni. En ole havainnut mitään ongelmia toistaiseksi...
 
Liittynyt
27.12.2016
Viestejä
294
Itse ostin kanssa pari tuollaista ja korkkasin ja levyt sisään ja Unraidissa preclear läpi ongelmitta. Itse en tehnyt mitään teippivirityksiä, vaan löin levyt suoraan koneeseen kiinni. En ole havainnut mitään ongelmia toistaiseksi...
Ton teipin vaativa 3,3V modi taitaa koskea noita 10 TB ja 12TB helium levyjä. Nää 8TB levyt on vielä "normaaleita".
 
Liittynyt
27.12.2016
Viestejä
294
Itsekin tilasin kuun alussa Amazon.de:stä aiemmasta alesta 6 kpl 8 TB MyBookeja (itse 3 kpl ja puoliso toiset 3 kpl, koska myyntirajoitus). Näissä oli kaikissa WD80EZAZ-11TDBA0 sisässä. Oli kyllä helppo purkaa nuo koteloista kitaraplektrojen avulla, eipä tainnut minkäänlaisia jälkiä jäädä koteloihin. Sähköteipillä voi eristää 3 vasemmanpuoleista virtapinniä sen yhden sijasta, ei haittaa mitään ja isompi teippipala on helpompi saada paikalleen kuin yhden pinnin millisuikale.

Itse ajoin nuo sisään pitemmän kaavan kautta eli alkuun kaikille short ja long SMART-testit, sitten badblocksilla kovot kurmotukseen ja sen perään vielä yksi long SMART. Vajaa viikko meni tuohon rumbaan ja kaikki levyt läpäisivät puhtain paperein ja SMART-tiedoissa ei virheitä. Nyt riittää NAS:ssa taas tilaa hetkeksi.
Hinta pysynyt paikallaan... näyttää, että antaisi tilata toiset 3kpl, en ole vielä lkokeillut. Toivottavasti ei joudu vaimolle tekemään tonne tiliä :)
 
Liittynyt
17.10.2016
Viestejä
31
Ton teipin vaativa 3,3V modi taitaa koskea noita 10 TB ja 12TB helium levyjä. Nää 8TB levyt on vielä "normaaleita".
Itseasiassa 8TB levyissäkin jouduin ainakin itse tuota modia käyttämään. 4 kpl viime vuonna noita tilasin kahdessa erässä.
 

andyks

Tukijäsen
Liittynyt
20.09.2018
Viestejä
179
Itse olen tilaillut pahan päivän varalle Aliexpressistä näitä Sata-Molex splittereitä joissa vain 4 piuhaa kytketty. Näillä ei teippauksia tarvita kun tuo 3.3V puuttuu piuhasta.


Myös vastaavista Sata-Sata splittereistä on helppo katkaista tuo 3.3V piuha poikki.
 
Liittynyt
27.12.2016
Viestejä
294
Itseasiassa 8TB levyissäkin jouduin ainakin itse tuota modia käyttämään. 4 kpl viime vuonna noita tilasin kahdessa erässä.
Hyvä tietää. Itsellä nyt osa levyistä powerin sata liittimissä ja osa just tuollaisissa nelijohtimisissa jatkopaloissa. Tosin 8tb levyt vielä odottaa sisään menoa pöydällä.
 
Liittynyt
30.10.2016
Viestejä
147
Alko nyt itseäkin kiinnostelemaan nuo My Bookit. Mitenkä noissa takuuhommelit sitten? Varsinkin Amazonin puolelle.
Kovalevy takas koteloon ja samaan kuosiin mitä oli ku paketista vedettäessä alunperin oli?
Onko nuo poisto-ohjeet pysynyt kutakuinkin samoina vuosien saatossa?
 
Liittynyt
17.10.2016
Viestejä
10
Kun 9 vuotta vanhasta Applen TimeCapsulesta alkoi aika jättämään niin otin käyttöön tuotantokäytöstä jo aikoja sitten poistetun HP ML350e gen8:sin, 2x Xenon E5-2407, 32GB yhdellä kammalla ja jokunen 1Tt levy. Nyt olen Unraidia ajellut jokusen viikon ja kaikki rokkaa omassa käytössä vallan mainiosti mutta virrankulutus on melkoisen huimaa kun virtaa menee 150-200w välillä 24/7. Jos olen tullut toimeen tuollaisella köykäisellä TimeCapsulella niin varmaankin joku uusi HP Microserver ajaa asiansa jos siinä muutamaa virtuaalikonetta pyörittelee samalla?

Mitähän tuollaisella ML350e gen8:lla voisi olla arvoa jos sitä yrittäisi kauputella ja ostaisi nykyaikaista rautaa tilalle, ebaysta katselin ja en oikein jaksa uskoa mihinkään 600-700€ hintapyyntöihin 7 vuotta vanhan raudan osalta
 
Liittynyt
19.03.2017
Viestejä
91
No, SAS2.0 kortit pitäisi tunnistaa yli 3TB levyt (tai oikeastaan 2.7TB oli se raja) hienosti
Jees, kiitos tästä tiedosta. Sain lainaan yhden 8TB levyn ja hyvin tunnisti. Pääsee jatkamaan projektia.

mutta haluatko ihan välttämättä raid-kortin eli teet raidin raudalla etkä softalla?
Tää tulee Proliantiin kiinni ja sehän ei tunnistanut kuin 4TB kiintolevy. Toisekseen sattuu olemaan Adaptecin kortti.
 
Liittynyt
02.12.2016
Viestejä
1 640
Tää tulee Proliantiin kiinni ja sehän ei tunnistanut kuin 4TB kiintolevy.
HP:n virallinen dokumentaatio varmaan voi noin kertoakin, mutta jos laite tunnistaa yli 3TB levyjä, ei ole mitään syytä miksei se näkisi 4 terasta isompiakin.
 
Liittynyt
19.03.2017
Viestejä
91
HP:n virallinen dokumentaatio varmaan voi noin kertoakin, mutta jos laite tunnistaa yli 3TB levyjä, ei ole mitään syytä miksei se näkisi 4 terasta isompiakin.
Kokeilin, ei tunnistanut kuin 1,8TB kokoiseksi ja kaikki on päivitetty viimeisimpään.

Tietenkin on vielä se, et jos Proliant ei tunnista tuota Adaptecin korttia niin joutuupi hommaamaan muun siihen... Mut se onkin toinen tarina sit.
 

andyks

Tukijäsen
Liittynyt
20.09.2018
Viestejä
179
Olisikohan ihan hullu ajatus tilata Gigantista tuo WD Blue SN500 250GB NVMe levy NASiin ajamaan ZFS L2ARC ja SLOG virkaa?

Jos tuollaiselle levylle tekee esim. 8GB SLOGin ja 64GB L2ARCin eli 8+64GB osiot, niin oletan että tuon levyn sisäinen kontrollerilogiikka osaa nuo molemmat "pilkkoa" pitkin tuota 250GB tilaa jolloin käytännössä tuollainen hinnat alkaen levykin kestää ikuisesti?
Mutta onko tuossa sitten riittävä IOPS-suorituskyky?
Onkohan ko. levyn DRAMin puuttumisella miten iso merkitys ko. käytössä?

Nyt on käytössä SATA-väyläinen Sandiskin X110 120gb jossa 8GB SLOG + 32GB L2ARC... ainakin Crystaldiskmark-tulosten valossa pitäisi jonkun verran tulla boostia jos sen päivittää tuohon WD Blue levyyn, mutta miten mahtaa sitten käytännössä olla.
 
Liittynyt
07.07.2017
Viestejä
379
Kontrolleri osaa kuluttaa soluja tasaisesti kunhan TRIMmillä kertoo sille mitkä lohkot ovat poistettuja. DRAMin puuttuminen on pelkkää plussaa SLOGin kannalta, koska sen virkahan on ainoastaan suojata synkronoidut kirjoitukset äkilliseltä virtojen menetykseltä tai kernelin paniikilta, akkuvarmentamattoman haihtuvan muistin kanssa SLOG olisi hyödytön.

Mikä on käyttöskenaario? SLOG aiheuttaa melkein aina enemmän ongelmia mitä se ratkaisee, eikä L2ARC myöskään automaattisesti tarkoita nopeamaa pakkaa, ZFS kun hoitaa mallikkaasti ARCin käytön. Käytin molempia joitain kuukausia omassa poolissa ja molemmista tuli luovuttua. Aiheuttivat lähinnä säätämistä ja uusia hajoamistapoja pooliin, eikä se suorituskykylisäkään näkynyt kuin testiohjelmissa. Tosin mitään mainittavia tietokantoja ei pakalla tullut pyöritettyäkään.

Jos purkki on max. gigan linkin takana ja välttämättä haluat SLOGin, kiinasta saisi kympillä 16gb Intel Optane levyjä, tuhottoman nopeita latensseiltaan sekä erittäin kestäviä.
 

andyks

Tukijäsen
Liittynyt
20.09.2018
Viestejä
179
Kontrolleri osaa kuluttaa soluja tasaisesti kunhan TRIMmillä kertoo sille mitkä lohkot ovat poistettuja.
Miten tämä käytännössä onnistuu FreeNASsilla L2ARC/SLOG levylle? Hoituuko automaattisesti vai pitääkö jotain tehdä?

Mikä on käyttöskenaario? SLOG aiheuttaa melkein aina enemmän ongelmia mitä se ratkaisee, eikä L2ARC myöskään automaattisesti tarkoita nopeamaa pakkaa, ZFS kun hoitaa mallikkaasti ARCin käytön. Käytin molempia joitain kuukausia omassa poolissa ja molemmista tuli luovuttua. Aiheuttivat lähinnä säätämistä ja uusia hajoamistapoja pooliin, eikä se suorituskykylisäkään näkynyt kuin testiohjelmissa. Tosin mitään mainittavia tietokantoja ei pakalla tullut pyöritettyäkään.
Proxmox jossa FreeNAS virtualisoituna + muutama muu virtuaalikone. Koneessa on vain 64GB RAMia, joten FreeNASsille olen raaskinut antaa vain 16GB, joten ARC pienehkö. 32GB L2ARC lisäyksellä (Sandiskin SSD:lle) olin huomaavinani jonkinlaisen nopeusedun esim. isompia video-filejä pyöritellessä.

Aiemmin myös muut VM-imaget pyörivät FreeNASin HDD-poolista (sekä iSCSI, että NFS yli kokeiltu), mutta tietokantaoperaatiot (Home Assistantin kirjoitukset+oma pyörittelyt InfluxDB:llä ja Grafanalla) ja työpöytäkäyttö (Ubuntu VM) tahmasivat välillä ikävästi. Tällöin ei ollut SLOGia eikä L2ARCia.
Nyt kaikki VM-imaget Proxmoxin omassa ZFS-mirroroidussa SSD-poolissa, jonka takia olen "joutunut" varaamaan myös Proxmoxin ZFS:lle 8GB ARC:n. Näille SSD:ille tulee nyt järjetön määrä levyoperaatioita ja hiukan hirvittää miten pitkään kestävät.
Tekisi mieli siis kokeilla taas siirtää nuo VM-imaget HDD-pooliin FreeNASiin, jotta saisi kaikelle yhteisen ARC:n ja itse imaget pois "kuluvilta" SSD-levyiltä.

Jos purkki on max. gigan linkin takana ja välttämättä haluat SLOGin, kiinasta saisi kympillä 16gb Intel Optane levyjä, tuhottoman nopeita latensseiltaan sekä erittäin kestäviä.
Toistaiseksi on gigan linkin takana, mutta tarkoitus on lähiaikoina päivitellä joko 10GB kupariin tai sitten ko. purkin ja käyttökoneen välille ~10m DAC-kaapeli. Niin ja virtuaalikoneiden välillähän on ~30-40GB linkit, ja jonkin verran siirrellään filejä sielläkin.

Olisiko lähdettä noille 16GB Intel Optane levyille kiinasta? Tuollaisen voisi laittaa tulemaan, tai vähän isompana L2ARCiksi. Järkeväähän nuo SLOG ja L2ARC olisi pitää erillään, mutta kustannukset edellä tässä mennään kuitenkin.
 
Liittynyt
07.07.2017
Viestejä
379
Normaalisti dataseteissä TRIM hoituu joko itse tai asettamalla autotrim=on, SLOGin ja L2ARCin suhteen en nyt suorilta muista onko niissä omaa tapaa, mutta hoituuhan se niinkin, että ajaa secure erasen ja jättää levylle ison osioimattoman alueen.

Hieman omituista, jos L2ARC vaikuttaa videoihin (=peräkkäisoperaatioihin), ZFS:n kyllä tulisi osata prefetchit yms sen verran hyvin, että se ei tavallisilla asetuksilla edes tarjoa peräkkäisdataa L2ARCille. Viisaana järjestelmänä se jättää sen juurikin noille virtuaalikoneille yms. satunnaisoperaatioille, joissa siitä voi olla ihan merkittävää hyötyäkin.

Ebaysta hankin oman 16gb Optanen. Siihen mahtui oikein hyvin Proxmox ja kymmenkunta pientä virtuaalikonetta, pieksee latensseissa kisaisimmatkin NAND SSD:t ja kestää vaikka sähkökatkotkin kadottamatta bittiäkään. Isommat koneet pyörivät sitten HDD pakassa muun sälän seassa.

Peräkkäiskirjoitusnopeuttahan noilla ei paljoa ole tarjottavana, mutta harvoin se on edes oleellista, satunnaisnopeudet ovat se oleellinen asia. SLOGin ollessa kyseessä peräkkäisoperaatiot menisivät joka tapauksessa suoraan pyörivälle levylle.

Ennemmin kuitenkin pakottaisin kirjoitukset muistiin kuin pistäisin ne mitä-sattuu levylle, RAM on paljon nopeampaa (ja kestävempää) ja yhtälailla viimeisin kirjoitus häviää jos virrat katkeaa kesken kaiken.
 

andyks

Tukijäsen
Liittynyt
20.09.2018
Viestejä
179
Hieman omituista, jos L2ARC vaikuttaa videoihin (=peräkkäisoperaatioihin), ZFS:n kyllä tulisi osata prefetchit yms sen verran hyvin, että se ei tavallisilla asetuksilla edes tarjoa peräkkäisdataa L2ARCille. Viisaana järjestelmänä se jättää sen juurikin noille virtuaalikoneille yms. satunnaisoperaatioille, joissa siitä voi olla ihan merkittävää hyötyäkin.
Siis tuo etu lähinnä käsiteltäessä videoita jolloin eestaas hyppimisiä tulee. En tiedä osaako näissä tapauksissa sitten ZFS cacheta myös isot filet, vai johtuuko nopeutuminen siitä että sieltä väleistä jää ne muut satunnaisoperaatiot pois.

Ebaysta hankin oman 16gb Optanen. Siihen mahtui oikein hyvin Proxmox ja kymmenkunta pientä virtuaalikonetta, pieksee latensseissa kisaisimmatkin NAND SSD:t ja kestää vaikka sähkökatkotkin kadottamatta bittiäkään. Isommat koneet pyörivät sitten HDD pakassa muun sälän seassa.
On kyllä pieniä virtuaalikoneita. Mulla pelkälle FreeNASille varattuna 8GB.
Onko sulla siis tuo HDD-pakkakin Proxmoxissa ZFSonLinuxilla vai esim. FreeNASissa virtualisoituna?
Onko tuo kyseinen Optane siis esim. tämä ?

Peräkkäiskirjoitusnopeuttahan noilla ei paljoa ole tarjottavana, mutta harvoin se on edes oleellista, satunnaisnopeudet ovat se oleellinen asia. SLOGin ollessa kyseessä peräkkäisoperaatiot menisivät joka tapauksessa suoraan pyörivälle levylle.
Niin kai tuolla SLOGilla haetaankin sitä että se hanskaa satunnaisoperaatiot ja HDD:t saavat sitten rauhassa peräkkäiskirjoituksilla tyhjentää SLOGin?

Ennemmin kuitenkin pakottaisin kirjoitukset muistiin kuin pistäisin ne mitä-sattuu levylle, RAM on paljon nopeampaa (ja kestävempää) ja yhtälailla viimeisin kirjoitus häviää jos virrat katkeaa kesken kaiken.
Mitä tarkoitit tällä? Meinaatko että pyörittäisi tietokantoja (ja VM:iä) RAMmilla josta sitten duplikoisi ne jollain skriptillä HDD:lle ajoittain?
 
Liittynyt
07.07.2017
Viestejä
379
Siis tuo etu lähinnä käsiteltäessä videoita jolloin eestaas hyppimisiä tulee. En tiedä osaako näissä tapauksissa sitten ZFS cacheta myös isot filet, vai johtuuko nopeutuminen siitä että sieltä väleistä jää ne muut satunnaisoperaatiot pois.
Niiden muutamien satunnaisoperaatioiden sheivaaminen peräkkäisdatan L2ARCiin pistämällä kuluttaa huomattavat määrät sekä ARCia että L2ARCia hidastaen oleellisempia kakutettavia asioita, joten normaalioloissa ZFS ei niitä sinne tarjoa. Toki poikkeuksiakin voi varmasti olla.

On kyllä pieniä virtuaalikoneita. Mulla pelkälle FreeNASille varattuna 8GB.
Onko sulla siis tuo HDD-pakkakin Proxmoxissa ZFSonLinuxilla vai esim. FreeNASissa virtualisoituna?
Onko tuo kyseinen Optane siis esim. tämä ?
Proxmox vie gigan ja Ubuntun päivitetty template 600MB, josta saa "ilmaiseksi" kloonattua uusia koneita. pfSenselle on varattu neljä gigaa ja noita 20MB Alpine koneita mahtuu vaikka kuinka. ZoL HDD pakka juurikin tuollein bindmountattu (muutamalle) CT:lle, josta jako verkkoon. Ja juurikin tuo Optane kyseessä.
Niin kai tuolla SLOGilla haetaankin sitä että se hanskaa satunnaisoperaatiot ja HDD:t saavat sitten rauhassa peräkkäiskirjoituksilla tyhjentää SLOGin?
SLOG ei ole kirjoituspuskuri, sieltä ei koskaan lueta mitään ellei kone ole kaatunut ja dataa pitää pelastaa. Puskuri sijaitsee RAMissa, josta se tyhjennetään levyille.

Mitä tarkoitit tällä? Meinaatko että pyörittäisi tietokantoja (ja VM:iä) RAMmilla josta sitten duplikoisi ne jollain skriptillä HDD:lle ajoittain?
Kun puskuri sijaitsee kuitenkin muistissa, eikä SLOGissa, SLOG vain hidastaa kirjoitusta aiheuttamalla ylimääräistä työtä. Ottamalla sen pois ja asettamalla sync=off, päästään siitä hidasteesta eroon sillä riskillä, että koneen kaatuessa viimeisin kirjoitus saattaa kadota. Se saattaa kuitenkin yhtälailla kadota SLOGinkin kanssa, jos se puskuroi haihtuvaan varmentamattomaan muistiin.

EDIT: Hieman vielä terminologiaa. SLOG tarkoittaa Separate LOGia. Nomaalisti LOG kirjoitetaan siihen pooliin mihin nyt data kirjoitetaankin, jolloin se kulkee nimellä ZIL. ZIL:n pointti on se, että data hutkitaan nopeasti johonkin kohtaan levyä, että päästään sanomaan kirjoittavalle ohjelmalle, että data on nyt varmasti tallessa. ZFS sitten ajan mittaan (vakiona 5s kuluessa) kirjoittaa sen ZILin sisällön (RAMista, siellä on se alkuperäinen kopio vielä tallessa) paremmin parhaaksi näkemiinsä paikkoihin.

SLOG on vehje, jolle ZFS voi kirjoittaa login sen pyörivän levyn sijaan ja näin saadaan nopeammin kuitattua data kirjoitetuksi.

Kaikki tämä koskee kuitenkin vain ja ainoastaan kirjoituksia, jotka kirjoittava ohjelma vaatii synkronisesti kirjoitettavaksi. Ja useimmiten myös mm. perättäiskirjoitukset menee suoraan levylle käymättä logeissa. Normaalisti kaikki kirjoitukset ovat myöskin asynkronisia, jolloin logi sijaitsee pelkästään RAMissa.

Sync=off kuuluu myös juttuihin, joita yleensä ei suositella, ainakaan kriittisen datan kanssa. Silloin ZFS valehtelee ohjelmalle kirjoittaneensa pysyvästi, vaikka data vielä makaa RAMissa odottamassa kirjoitusta.
 
Viimeksi muokattu:
Liittynyt
02.12.2016
Viestejä
1 640
Tällä hetkellä etsinnässä 6U korkeita 19" blankoja räkkikoteloita joissa syvyys 250-300mm, köyhän miehen DIY stornado ajatuksena rakentaa. Saa vinkata jos tuollaisia löytää jostain ja vieläpä edukkaastikin (lue: alta 100 euroa posteineen)
 
Liittynyt
26.02.2019
Viestejä
289
Tällä hetkellä etsinnässä 6U korkeita 19" blankoja räkkikoteloita joissa syvyys 250-300mm, köyhän miehen DIY stornado ajatuksena rakentaa. Saa vinkata jos tuollaisia löytää jostain ja vieläpä edukkaastikin (lue: alta 100 euroa posteineen)
En tiedä ihan, että oliko esim tälläisia hakusessa, mutta selviää kyllä.
 

GJ

Liittynyt
27.10.2016
Viestejä
203
Kolmas Synology DS1815+ tekee kuolemaa, aika vaihtaa leiriä.

Kaipaisin erityisesti emolevy+kotelo ehdotuksia, kriteerit seuraavat:
  1. 10GB lan
  2. 8 kpl 3,5" levyjä
  3. 1-2 kpl M2 asemia
  4. Pieni ja hiljainen
Kategoriassa "olis kiva" vielä seuraavaa: etähallinta, HBA lisäksi tilaa näyttikselle. Ajatuksena laittaa unraid tai esxi.
 

andyks

Tukijäsen
Liittynyt
20.09.2018
Viestejä
179
SLOG ei ole kirjoituspuskuri, sieltä ei koskaan lueta mitään ellei kone ole kaatunut ja dataa pitää pelastaa. Puskuri sijaitsee RAMissa, josta se tyhjennetään levyille.

Kun puskuri sijaitsee kuitenkin muistissa, eikä SLOGissa, SLOG vain hidastaa kirjoitusta aiheuttamalla ylimääräistä työtä.
ZFS sitten ajan mittaan (vakiona 5s kuluessa) kirjoittaa sen ZILin sisällön (RAMista, siellä on se alkuperäinen kopio vielä tallessa) paremmin parhaaksi näkemiinsä paikkoihin.
Kiitos tästä. Kuvittelin jo ymmärtäneeni tuon SLOGin toiminnan, mutten näköjään sittenkään täysin. Tietysti tuo on järkevää että data kirjoitetaan lopullisestikin pooliin RAMista, RAMin kauttahan se todnäk. joutuisi jokatapauksessa menemään. Tuo 5s kuluessa tuli mulle yllärinä. Kuvittelin että ZFS kirjoittelee tuon ZILin sisällön pooliin vasta joskus myöhemmin kun ehtii muilta operaatioiltaan (tai ZIL/SLOG loppuu kesken). Ja jotenkin ajattelin että ZFS siinä välissä käyttäisi jotain älyä ja kirjottaisi datan pooliin niin että se voidaan sieltä myöhemmin lukea perättäislukuina, mutta tuskinpa tässä välissä mitään optimointia tehdään vaan data recordit kirjoitetaan sellaisenaan eteenpäin.

Kaikki tämä koskee kuitenkin vain ja ainoastaan kirjoituksia, jotka kirjoittava ohjelma vaatii synkronisesti kirjoitettavaksi. Ja useimmiten myös mm. perättäiskirjoitukset menee suoraan levylle käymättä logeissa. Normaalisti kaikki kirjoitukset ovat myöskin asynkronisia, jolloin logi sijaitsee pelkästään RAMissa.

Sync=off kuuluu myös juttuihin, joita yleensä ei suositella, ainakaan kriittisen datan kanssa. Silloin ZFS valehtelee ohjelmalle kirjoittaneensa pysyvästi, vaikka data vielä makaa RAMissa odottamassa kirjoitusta.
Mulla on ollut käytössä VM-dataseteissä sync=always ja Proxmoxissa Cache mode=No cache. Olen kuvitellut että tällä kombinaatiolla Proxmox eikä FreeNAS käytä RAMia writebufferina. Kyseessä oleva VM bufferoi omat kirjoituksensa "normaalisti" omaan RAMiinsa, joten jos joku tietty applikaatio edellyttää syncwriteä se ohittaa VM:n bufferit ja päätyy suoraan syncwritenä levylle asti.

Jos pyrkisi siihen että kirjoitukset bufferoitaisiin vain RAMille niin mikä olisi järkevin ratkaisu?
Jos käyttää Proxmoxissa "No cache" -modea ja itse image on FreeNASissa NFS-jakona, käykö siinä niin että kirjoitettavaa dataa on bufferoituna sekä itse VM:n RAMissa että FreeNASin RAMissa? Puhumattakaan jos käyttää "writeback" -modea niin dataa on VM:n RAMissa, hostin (Proxmox) RAMissa ja FreeNASin RAMissa?
Jos käyttäisi "directsync" tilaa Proxmoxissa, mutta asettaa datasetille sync=off, Proxmox luulee kirjoittavansa kaiken suoraan levylle, joten bufferoinnin on pakko tapahtua FreeNASin RAMissa? Tällöin FreeNASille pitäisi varata reilusti enemmän RAMia?

Jos sync=off ja dataa kirjoitetaan paljon ja RAM loppuu kesken, alkaako ZFS viivyttelemään noiden vastausten kanssa? Eikö tästä voi tulla jotain timeout ongelmia?
 

andyks

Tukijäsen
Liittynyt
20.09.2018
Viestejä
179
Tarvittaisiin nimenomaan niitä koteloita joita noihin telineisiin on tarkoitus laittaa :sori:
6U ja max 300mm syvä? Eihän tuo aito stornadokaan ole noilla mittasuhteilla? Kuulostaa sen verran eksoottiselta että joutunet itse tekemään/teettämään.
Kun jokatapauksessa tyhjään koteloonkin joutuisit levykelkat yms sisälle askartelemaan, niin ota pari valmista esim. 1U/2U koppaa aihioksi ja jatka niistä?
Tai suosiolla äitilevy ja levyasemat eri koteloihin ja SAS kaapeli välille?
 
Liittynyt
02.12.2016
Viestejä
1 640
6U ja max 300mm syvä? Eihän tuo aito stornadokaan ole noilla mittasuhteilla? Kuulostaa sen verran eksoottiselta että joutunet itse tekemään/teettämään.
Kun jokatapauksessa tyhjään koteloonkin joutuisit levykelkat yms sisälle askartelemaan, niin ota pari valmista esim. 1U/2U koppaa aihioksi ja jatka niistä?
Tai suosiolla äitilevy ja levyasemat eri koteloihin ja SAS kaapeli välille?
Siksipä juuri köyhän miehen. Nimenomaan tuollainen täysin blanko laitekotelo hakusessa ilman ainuttakaan valmista ruuvinreikää tai kierrettä. 3x8 levyn backplanet mulla on jo hankittuna, ne vievät yhteensä 24cm tilan syvyyssuunnassa, ja levyt oli tarkoitus nimenomaan tiputella katon kautta sisään, josta johtuen 4U on vielä liian matala tuohon tarkoitukseen, ja 5U taitaa olla vielä eksoottisempi kuin 6U.

Sähköt ja data tulisi sitten DIY XLR ja SFF-8088 kaapeleilla boksille koneelta, joka oli tarkoitus myös rakennella identtisen lodjun sisään (6U ja 300mm syvä) jotta nuo voisi sitten jatkossa niputella jonnekin räkkikaappiin kätsysti. :tup:
 
Liittynyt
07.07.2017
Viestejä
379
Kiitos tästä. Kuvittelin jo ymmärtäneeni tuon SLOGin toiminnan, mutten näköjään sittenkään täysin. Tietysti tuo on järkevää että data kirjoitetaan lopullisestikin pooliin RAMista, RAMin kauttahan se todnäk. joutuisi jokatapauksessa menemään. Tuo 5s kuluessa tuli mulle yllärinä. Kuvittelin että ZFS kirjoittelee tuon ZILin sisällön pooliin vasta joskus myöhemmin kun ehtii muilta operaatioiltaan (tai ZIL/SLOG loppuu kesken). Ja jotenkin ajattelin että ZFS siinä välissä käyttäisi jotain älyä ja kirjottaisi datan pooliin niin että se voidaan sieltä myöhemmin lukea perättäislukuina, mutta tuskinpa tässä välissä mitään optimointia tehdään vaan data recordit kirjoitetaan sellaisenaan eteenpäin.
Tuo 5s timeout on useimmiten hyvä ratkaisu, sinä aikana ZFS saa riittävästi dataa muodostaakseen niistä sisään tulleista satunnaiskirjoituksista helposti luettavia kokonaisuuksia levylle. Siellä on kyllä muitakin rajoitteita login koolle, mm. suurin sallittu koko tavuina. Omalla kohdalla nostin tuon 30 sekuntiin, nopeuksissa en eroa huomannut, mutta kirjoitukset tuolle Optanelle tippui viidesosaan kun ei tarvitse jokaisen pienen logiin tulevan merkinnän takia kirjoittaa koko 128 kB recordia uudelleen. Eli siis ZFS taiteilee puskurin aikana tulleista pienistä kirjoituksista yhden isomman kokonaisuuden.
Tuo 5s timeout tarkoittaa myös sitä, että gigan linkin päässä (~100MB/s) SLOGiin ei voida kirjoittaa kuin korkeintaan sen ~500MB, yli gigan kokoinen SLOG olisi siis täysin turhaan varattua tilaa.

Melkein kaikki ZFS:n kanssa harrastamista aloittavat ajattelevat juurikin tuon SLOGin olevan kirjoituspuskuri ja siksi vain hyvä homma. Samoin L2ARCin ajatellaan olevan ilmainen lisä lukukakkuun. Itsekin olen käynyt tuon polun, eikä se edes harmita yhtään, siinä oppi jälleen lisää ZFS:n sielunelämästä. Nykyisin räpellyksille on jo oma koneensa, tällä hetkellä tuo 4c Intel Atom vuosikymmenen ikäisen SSD:n kanssa, copies=2 moodissa gzip-6 pakkauksella sekä deduplikoinnilla porskuttaa yllättävän hyvin, vaikka kaikki noista kuuluu listalle asioista, joita ei tulisi käyttää koskaan.

Mulla on ollut käytössä VM-dataseteissä sync=always ja Proxmoxissa Cache mode=No cache. Olen kuvitellut että tällä kombinaatiolla Proxmox eikä FreeNAS käytä RAMia writebufferina. Kyseessä oleva VM bufferoi omat kirjoituksensa "normaalisti" omaan RAMiinsa, joten jos joku tietty applikaatio edellyttää syncwriteä se ohittaa VM:n bufferit ja päätyy suoraan syncwritenä levylle asti.

Jos pyrkisi siihen että kirjoitukset bufferoitaisiin vain RAMille niin mikä olisi järkevin ratkaisu?
Jos käyttää Proxmoxissa "No cache" -modea ja itse image on FreeNASissa NFS-jakona, käykö siinä niin että kirjoitettavaa dataa on bufferoituna sekä itse VM:n RAMissa että FreeNASin RAMissa? Puhumattakaan jos käyttää "writeback" -modea niin dataa on VM:n RAMissa, hostin (Proxmox) RAMissa ja FreeNASin RAMissa?
Jos käyttäisi "directsync" tilaa Proxmoxissa, mutta asettaa datasetille sync=off, Proxmox luulee kirjoittavansa kaiken suoraan levylle, joten bufferoinnin on pakko tapahtua FreeNASin RAMissa? Tällöin FreeNASille pitäisi varata reilusti enemmän RAMia?

Jos sync=off ja dataa kirjoitetaan paljon ja RAM loppuu kesken, alkaako ZFS viivyttelemään noiden vastausten kanssa? Eikö tästä voi tulla jotain timeout ongelmia?
Sync=always toimii parhaiten niissä tilanteissa, joissa ohjelma (ml. VM:n) ei osaa jostain syystä itse kertoa, että data on kriittisesti suojattava äkillisiltä sähkökatkoilta. Virtuaalikoneissa harvemmin on mitään omaa kirjoituspuskuria (ellei niitä asenna ZFS:lle ZFS:n päälle, mikä on huono idea), sen sijaan ne puskuroi (virtuaalisen) levyn muistiin käyttiksen muistin sijaan ja komentavat cache flushia synkronisten kirjoitusten yhteydessä. Sync=standard on vakioasetus ja se, mikä on melkein aina paras vaihtoehto. Se antaa ohjelman itse päättää onko data kriittistä ja synkronisesti kirjoitettavaa, vai vähemmän kriittistä ja nopeudesta hyötyvää asynkronista. Proxmoxin cache modeista tuo "No cache" on useimmiten se nopein olematta myöskään kovin vikaherkkä, sen kanssa VM kakuttaa vain lukemiset ja kirjoituskakusta vastaa ZFS.
Sync=always ei varsinaisesti vaikuta kirjoituspuskuriin tai sen kokoon, se vaan pakottaa kaikki kirjoitukset synkronisiksi, eli RAMin lisäksi logiin kirjoitettavaksi. Paitsi peräkkäiskirjoitukset ja jotkut muut poikkeukset, jotka menevät suoraan levylle. ZFS alkaa kyllä jarruttelemaan jos logi täyttyy, joko ajallisesti tai tilallisesti, timeoutin kanssa ei tule ongelmia.

Proxmoxin ZFS kakuttaa vain oman poolinsa dataa eikä esim NFS:llä olevaa, ja kuten mainittua, VM:t ei varsinaisesti edes puskuroi kirjoituksiaan. Proxmox itsestään ei myöskään kakuta mitään, se on tiedostojärjestelmän tehtävä, ja nuo cache modet vaikuttavat siihen miten VM:t keskustelee tiedostojärjestelmän kanssa. Periaatteessa kirjoitukset eivät siis oikein voi olla useaan kertaan RAMissa ainakaan merkittävissä määrin, mutta lukukakku puolestaan voi olla.

Sanoisin järkevimmän ratkaisun olevan sync=standard + cache mode "no cache". Miltei riskitön ja kuitenkin erittäin nopea, toimii tilanteessa kuin tilanteessa.


Terminologiaan vielä sen verran tarkennusta, että jos tarkkoja ollaan, ZFS:n kirjoituspuskuri sijaitsee myös siellä levyllä eikä RAMissa, RAMissa oleva data kuuluu (ymmärtääkseni) transaction grouppeihin. Se ei ole varsinainen puskuri koska siihen kuuluu paljon muutakin, juurikin ZILit ja SLOGit sun muut. Vähän samalla tapaa kuin datasetit eivät ole varsinaisia osioita. Itsekään ei tule aina pysyttyä kärryillä termeistä.
 
Liittynyt
27.12.2016
Viestejä
294
Laitetaanpa tänne mielipidekysely, jos saisi siitä itselle uutta näkövinkkeliä. Eli 3kpl 3levyn raidz1 pakkoja on nyt kolmen uuden levyn avulla muutettu 2kpl 6levyn raidz2 pakoiksi.
Pakka1 on 3kpl 4tb ja 3kpl 8tb levyt
Pakka2 on 5kpl 3tb ja 1kpl 4tb levy.
Molempien poolien täyttöaste noin 45% eli tilaa on riittävästi.
Onko fiksua jatkaa vain näin ja ajaa vanhempia levyjä loppuun vai ostaa vielä toiset 3kpl 8tb levyjä ja venyttää tuo pakka1 isoksi. Kaikki tieto mahtuisi silloin helposti sinne ja kaikki vanhat 9kpl levyä saisi myytyä pois? Toisaalta vaikka ostaisi kolme uutta levyä, tekisi mieli jättää pakka2 silti eloon, tällöin kustannus kasvaisi kun vain 3kpl levyjä lähtisi myyntiin. Etuina olisi kriittisemmän datan snapshottien teko pakalta tooselle ristiin.
 
Liittynyt
20.10.2016
Viestejä
208
Laitetaanpa tänne mielipidekysely, jos saisi siitä itselle uutta näkövinkkeliä. Eli 3kpl 3levyn raidz1 pakkoja on nyt kolmen uuden levyn avulla muutettu 2kpl 6levyn raidz2 pakoiksi.
Pakka1 on 3kpl 4tb ja 3kpl 8tb levyt
Pakka2 on 5kpl 3tb ja 1kpl 4tb levy.
Molempien poolien täyttöaste noin 45% eli tilaa on riittävästi.
Onko fiksua jatkaa vain näin ja ajaa vanhempia levyjä loppuun vai ostaa vielä toiset 3kpl 8tb levyjä ja venyttää tuo pakka1 isoksi. Kaikki tieto mahtuisi silloin helposti sinne ja kaikki vanhat 9kpl levyä saisi myytyä pois? Toisaalta vaikka ostaisi kolme uutta levyä, tekisi mieli jättää pakka2 silti eloon, tällöin kustannus kasvaisi kun vain 3kpl levyjä lähtisi myyntiin. Etuina olisi kriittisemmän datan snapshottien teko pakalta tooselle ristiin.
Jos ymmärsin oikein, käytät3 kappaletta 8TB ja yhden 4TB levyn noissa pakoissa vain osittain? Itse hankkisin samankokoisia levyjä ja samalla möisin vanhat pikkulevyt pois. Näin et hukkaa isompien levyjen kapasiteettia suotta.
 
Liittynyt
27.12.2016
Viestejä
294
Jos ymmärsin oikein, käytät3 kappaletta 8TB ja yhden 4TB levyn noissa pakoissa vain osittain? Itse hankkisin samankokoisia levyjä ja samalla möisin vanhat pikkulevyt pois. Näin et hukkaa isompien levyjen kapasiteettia suotta.
Juuri näin. Halusin siirtyä raidz2 aikaan ja päätin, että toteutus olisi 6levyn ratkuisu. Yksi neliterainen tuolla pienemmällä pakalla, koska yksi 3tb levy aikanaan hajosi ja ostin 4tb levyn tilalle ajatuksena jos olisi joskus tehnyt expandin tolle levyjä vaihtamalla.
Isommassa pakassa taas nuo 8tb levyt juuri hankittu, kun en halunnut enää 4tb levyjä ostaa :). Nyt vaan pohdin kuten edellisessä viestissä kirjoitin, että kannattaakone toiset kolme8tb levyä ostaa kun ihan pakottavaa tarvetta ei ole.
 
Liittynyt
26.10.2016
Viestejä
60
Laitetaanpa tänne mielipidekysely, jos saisi siitä itselle uutta näkövinkkeliä. Eli 3kpl 3levyn raidz1 pakkoja on nyt kolmen uuden levyn avulla muutettu 2kpl 6levyn raidz2 pakoiksi.
Pakka1 on 3kpl 4tb ja 3kpl 8tb levyt
Pakka2 on 5kpl 3tb ja 1kpl 4tb levy.
Molempien poolien täyttöaste noin 45% eli tilaa on riittävästi.
Onko fiksua jatkaa vain näin ja ajaa vanhempia levyjä loppuun vai ostaa vielä toiset 3kpl 8tb levyjä ja venyttää tuo pakka1 isoksi. Kaikki tieto mahtuisi silloin helposti sinne ja kaikki vanhat 9kpl levyä saisi myytyä pois? Toisaalta vaikka ostaisi kolme uutta levyä, tekisi mieli jättää pakka2 silti eloon, tällöin kustannus kasvaisi kun vain 3kpl levyjä lähtisi myyntiin. Etuina olisi kriittisemmän datan snapshottien teko pakalta tooselle ristiin.
Paha sanoa mikä on järkevää kun ei tiedä käyttötarkoitusta, mutta...
Entäpä jos ostat ne 3kpl 8TB levyt, laitat noi 5kpl 3TB levyä myyntiin, siirrät 4TB levyt pakkaan 2 ja teet siitä striped&mirrored Zpoolin (RAID 10)? Paljon parempi ajaa tuolla esim. iSCSI targetteja.

Edit: IMHO RAIDZ2 antaa ihan riittävän suojan mekaanisten vikojen varalle. En siis pitäisi pakalta toiselle tehtäviä backuppeja mitenkään tärkeänä. Toki jos tilaa on, niin anna mennä vaan. Sitten kun tila loppuu, luopuisin ennemmin noista backupeista kuin menisin heti ostamaan isompia levyjä. Mieti kriittisen datan backupeille ennemmin jokin järkevä off-site järjestely.
 
Viimeksi muokattu:
Liittynyt
27.12.2016
Viestejä
294
Paha sanoa mikä on järkevää kun ei tiedä käyttötarkoitusta, mutta...
Entäpä jos ostat ne 3kpl 8TB levyt, laitat noi 5kpl 3TB levyä myyntiin, siirrät 4TB levyt pakkaan 2 ja teet siitä striped&mirrored Zpoolin (RAID 10)? Paljon parempi ajaa tuolla esim. iSCSI targetteja.

Edit: IMHO RAIDZ2 antaa ihan riittävän suojan mekaanisten vikojen varalle. En siis pitäisi pakalta toiselle tehtäviä backuppeja mitenkään tärkeänä. Toki jos tilaa on, niin anna mennä vaan. Sitten kun tila loppuu, luopuisin ennemmin noista backupeista kuin menisin heti ostamaan isompia levyjä. Mieti kriittisen datan backupeille ennemmin jokin järkevä off-site järjestely.
Kiitoksia hyvistä pointeista. Kumpainenkin pooli enempi data-varastoina ihan network drivena. Siinä mielessä iscsi suorituskyky ei paina paljoa.
Otan "korvaamattomista" dataseteistä backupit ulkoiselle levylle säännöllisen epäsäännöllisesti ja tuo ulkoinen kovo on sit aina fyysisesti eri paikassa säilytyksessä. Muu data tuolla on sellaista, että katoaminen harmittaisi, muttei olisi ylitsepääsemätöntä. Siinä mielessä raidz2 antaa jo melko hyvää turvaa.
Tilanne siinä mielessä ohi, että amazaon nosti jälleen 8tb levyn hinnan "normaali"tasolle ja nyt pitää odottaa, koska putoaa seuraavan kerran tuohon 139€ hintaan.
 
Toggle Sidebar

Statistiikka

Viestiketjut
92 252
Viestejä
1 888 692
Jäsenet
39 701
Uusin jäsen
VH666

Hinta.fi

Ylös Bottom