NAS med ZFS

Berätta om dina pågående projekt.
Användarvisningsbild
lond
Inlägg: 3508
Blev medlem: 23 september 2009, 11:52:45
Ort: Hyssna

Re: NAS med ZFS

Inlägg av lond »

arvidb skrev:lond: Kör du scrubs på dina ZFS-pooler ibland? Kollar du resultatet? :)
Körs varje vecka

Kod: Markera allt

root@freenas:~ # zpool status
  pool: FreeNAS
 state: ONLINE
  scan: scrub repaired 0 in 0 days 02:26:13 with 0 errors on Sun Jan 13 02:26:15 2019
config:

        NAME                                            STATE     READ WRITE CKSUM
        FreeNAS                                         ONLINE       0     0     0
          raidz1-0                                      ONLINE       0     0     0
            gptid/cb1b62ce-36ee-11e5-adea-d0bf9c46894c  ONLINE       0     0     0
            gptid/cba064fb-36ee-11e5-adea-d0bf9c46894c  ONLINE       0     0     0
            gptid/cc3455ea-36ee-11e5-adea-d0bf9c46894c  ONLINE       0     0     0
            gptid/cccca994-36ee-11e5-adea-d0bf9c46894c  ONLINE       0     0     0

errors: No known data errors

  pool: freenas-boot
 state: ONLINE
  scan: scrub repaired 0 in 0 days 00:03:10 with 0 errors on Wed Jan 16 03:48:11 2019
config:

        NAME        STATE     READ WRITE CKSUM
        freenas-boot  ONLINE       0     0     0
          da0p2     ONLINE       0     0     0

errors: No known data errors
root@freenas:~ # uptime
10:24PM  up 46 days,  2:23, 1 user, load averages: 0.32, 0.28, 0.25
/// Marcus
guckrum
Inlägg: 1670
Blev medlem: 19 juni 2012, 09:04:27
Ort: Lund

Re: NAS med ZFS

Inlägg av guckrum »

Det jag skulle behöva är en liten crash course på är hur man kopplar och bryggar IP-adresser etc. om man tex. kör en FreeNAS i en VM (i KVM) och ändå har anständig datasäkerhet sedan.
En tanke kan vara att VLANa dina virtuella maskiners nätverkskopplingar och skicka vidare till din centrala router, om du har en sådan, kanske?
har förvisso ett flertal nätverksportar tillgänglig på servern (med Ubuntu 18.04 headless -administreras via SSH enkom) som skulle kunna upplåtas enkom för tänkta VM-maskiner.
Det är inte så "svårt" att koppla ett fysiskt nätverksinterface till en virtuell maskin. Jag har något sådant här i min definitions-xml:

Kod: Markera allt

    <interface type='direct'>
      <source dev='eth2' mode='private'/>
    </interface>
och då får jag tillbaka

Kod: Markera allt

    <interface type='direct'>
      <mac address='52:54:00:xx:xx:xx'/>
      <source dev='eth2' mode='private'/>
      <target dev='macvtap0'/>
      <model type='rtl8139'/>
      <alias name='net1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </interface>
och i den virtuella maskinen dyker denna macvtap0 upp som eth1.

Virsh känns onödigt komplext.
xxargs
Inlägg: 10183
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: NAS med ZFS

Inlägg av xxargs »

arvidb skrev:Jag har bestämt mig för att skippa OpenMediaVault och köra samba direkt på servern istället. Det verkar funka bra.

Det är ju flera här som kör ZFS (och Btrfs); hur ofta har ni stött på bitröta (alltså checksummefel)? Under hur lång tid och med hur mycket data?
Skulle nog säga att det händer väldigt sällan, och när det händer så har man större problem som pågående multipla rasande diskar i RAID:en.

Hårddiskar har i sig väldigt bra dataintegritetkontroll (en BCH-kod på 100 byte per 4k sektor) och risken för oupptäckt fel är väldigt låg - typ 1 miljon lägre än angivna nivå för ej korrigerbara fel.


Största svagheten i kedjan disk -> host för ej upptäckta fel är SATA-bussen tex. pga störningar i sin omgivning, glapp i sladden/kontakter etc. och den sätts till standarden till en sannolikhet av 1 fel per 1*10^17 byte - vilket innebär att om man konstant överföring vid 500 MB/s under ett år så finns det risk för 4.5 oupptäckta fel per år, beroende att SATA-bussen bara är skyddad med en CRC32 per 512-bytes sektor - dvs. att det blivit en situation med multipla antal bitfel i en sektor med en kombination som gör att checksumman är samma som den tänkta orginal-datat och inte upptäcks.

Shannons lag med begränsad signal/brusförhållande på signaleringen på sladden så kommer det att bli fel i överföringen -förr eller senare...

Därför vid hantering av mer kritisk data eller stora anläggningar med många diskanslutningar och kanske i flera led med rackexpandrar så förespråkar man att använda SAS-gränsnitt och dito diskar istället då man genast snäpper upp felupptäcksförmågan med en miljon gånger ( 1*10^23 byte per oupptäckt fel). SAS kan dessutom hantera förstorade sektorer med 520 och 528 Byte storlek för extra checksummor och transporteras hela vägen över SAS för 'hela vägen' för kontroll av datat hos mottagaren och då kan uppnå felrisk för 1 fel per 1*10^28 byte - medans SATA har inte möjligheten att skicka sektorstorlek annat än just exakt 512 byte.
Användarvisningsbild
arvidb
Inlägg: 4537
Blev medlem: 8 maj 2004, 12:56:24
Ort: Stockholm

Re: NAS med ZFS

Inlägg av arvidb »

Så bitröta ger i princip alltid upphov till ett ej korrigerbart fel då, och det är sådana man letar efter när man kör en scrub?
guckrum
Inlägg: 1670
Blev medlem: 19 juni 2012, 09:04:27
Ort: Lund

Re: NAS med ZFS

Inlägg av guckrum »

Så bitröta ger i princip alltid upphov till ett ej korrigerbart fel då, och det är sådana man letar efter när man kör en scrub?
Ett svar kan vara att allting handlar om statistik och att man bygger lager på lager
för att hantera detta. (Det går inte att bygga "felfritt" i rumstemperatur eftersom
allting skakar runt stokastiskt i positiva temperaturer.)

Inne i disken tänker jag att det ofta blir läsfel, varav de flesta korrigeras av kodningen,
medan andra troligen löses genom att läsa datan multipla gånger (+3dB SNR för en
omläsning, typ, antaget termiskt brus). När disken upptäcker att det är problem
någonstans kommer den att flytta datan till ett annat, förhoppningsvis bättre, ställe
osv. Det är först när det blir multipla fel och diskkontrollern ger upp som det propagerar
till "användaren", och det är sannolikt en indikator på att det är dags att undersöka
närmare om man är mån om drifttid / dataintegritet osv.

Sedan har jag varit med om ett par gånger att datan är fel när den processas, men okej
på disk. Det har alltså gått snett någonstans i "sladdarna" mellan kislet i disken och kislet
i RAM. Cacharna i CPUerna ger upp ganska ofta också. Så det räcker inte med ECC
och checksummor i filsystemet - det blir fel ändå.
Användarvisningsbild
arvidb
Inlägg: 4537
Blev medlem: 8 maj 2004, 12:56:24
Ort: Stockholm

Re: NAS med ZFS

Inlägg av arvidb »

Tack guckrum, bra förklaring!

---

En möjlig nackdel med disken som jag köpte (ST6000DM003) är att den inte stödjer "SCT Error Recovery Control", det vill säga man kan inte ställa in hur länge disken ska försöka läsa en trasig sektor innan den ger upp. Här jämfört med en Western Digital Red (WD30EFRX):

Kod: Markera allt

# smartctl -l scterc /dev/disk/by-id/ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N0988278
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.14.91zfs] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

SCT Error Recovery Control:
           Read:     70 (7.0 seconds)
          Write:     70 (7.0 seconds)

# smartctl -l scterc /dev/disk/by-id/ata-ST6000DM003-2CY186_WF205B26
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.14.91zfs] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

SCT Error Recovery Control command not supported
Edit: Jag vet inte hur stor betydelse detta har egentligen om man värderar dataintegritet högre än tillgänglighet? Eller hur ZFS beter sig när disken inte svarar på nån minut...
Användarvisningsbild
arvidb
Inlägg: 4537
Blev medlem: 8 maj 2004, 12:56:24
Ort: Stockholm

Re: NAS med ZFS

Inlägg av arvidb »

Och där dog nya disken.

Kod: Markera allt

Jan 19 19:11:12 sv2 kernel: [424852.096280] ata6: hard resetting link
Jan 19 19:11:13 sv2 kernel: [424853.396271] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Jan 19 19:11:18 sv2 kernel: [424858.731279] ata6.00: qc timeout (cmd 0x27)
Jan 19 19:11:18 sv2 kernel: [424858.733452] ata6.00: failed to read native max address (err_mask=0x4)
Jan 19 19:11:18 sv2 kernel: [424858.733455] ata6.00: HPA support seems broken, skipping HPA handling
Jan 19 19:11:18 sv2 kernel: [424858.733461] ata6: hard resetting link
Jan 19 19:11:24 sv2 kernel: [424864.084305] ata6: link is slow to respond, please be patient (ready=0)
Jan 19 19:11:28 sv2 kernel: [424868.764323] ata6: hard resetting link
Jan 19 19:11:34 sv2 kernel: [424874.116356] ata6: link is slow to respond, please be patient (ready=0)
Jan 19 19:11:38 sv2 kernel: [424878.796358] ata6: hard resetting link
Jan 19 19:11:44 sv2 kernel: [424884.148373] ata6: link is slow to respond, please be patient (ready=0)
Jan 19 19:11:45 sv2 kernel: [424885.812392] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Jan 19 19:11:51 sv2 kernel: [424890.987428] ata6.00: qc timeout (cmd 0xef)
Jan 19 19:11:51 sv2 kernel: [424890.989593] ata6: limiting SATA link speed to 3.0 Gbps
Jan 19 19:11:51 sv2 kernel: [424890.989598] ata6: hard resetting link
Jan 19 19:11:52 sv2 kernel: [424892.492406] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
Jan 19 19:11:52 sv2 kernel: [424892.510770] ata6.00: configured for UDMA/133
Jan 19 19:11:52 sv2 kernel: [424892.510774] ata6.00: retrying FLUSH 0xea Emask 0x4
Jan 19 19:11:52 sv2 kernel: [424892.644876] ata6: EH complete
Jan 19 19:13:35 sv2 kernel: [424995.452811] ata6: hard resetting link
Och så vidare...

Ok, stängde av, bytte SATA-kabel, tog bort bakplanet i den billiga Lian-Li-lådan och kopplade kablarna direkt till diskarna istället. Disken är sig själv igen efter omstart. Egentligen skulle man försöka få dit lite avstörningskondensatorer på strömförsörjningen också, men jag testar så här först. Vi får se om/hur länge det håller...
Skriv svar