Följ Black Week på SweClockers
Forum Datorer och system Server Tråd Inlägg

ZFS och RAIDZ i produktionsmiljö

1 2
Skriv svar
Permalänk
Medlem ★
●

ZFS och RAIDZ i produktionsmiljö

Hej,

Jag har länge varit förespråkare för hårdvaruraid, mest för att det är välbeprövat och jag vet vad jag får, men nu är det uppenbart att det finns en ny aktör med i spelet: Mjukvaruraid med ZFS och RAIDZ, vilket jag absolut kan se fördelar med, men jag undrar om det är någon här som faktiskt har tagit ZFS och RAIDZ i bruk i en produktionsmiljö eller om det bara är i lab- och/eller hemmamiljö som det används här på SweClockers?

Om så är fallet; vilken mjuk- och hårdvara har ni använt er av och vad används servern till?

Senast redigerat
Visa signatur

{|XSX|PS3|PS4|}

Redigera
Citera flera Citera
Permalänk
Keeper of the Bamse ★
●

Körde en openindiana med ZFS på labmiljö; den agerade iSCSI-san åt några ESX-hostar. Det var inte alltid helt stabilt men det berodde nog mest på skit bakom spakarna

Hårdvaran vad helt vanlig konsumentdito; intelprolle, ATX-mobo, LSI 8port kontrollerkot som hade 8st 2TB-diskar kopplat på sig och 2st patadiskar för OS. Sen 2st intel SSD i raid0 som cache.

Blev bra prestanda, men som sagt, i produktion är det nog bara att langa upp plånboken och gå till 3par eller Netapp.

Visa signatur

i7 10770K, NH-D15. 16GB corsair. RTX 3080. 3TB nvme. Samsung G9. Fractal Torrent Compact. Corsair RM850.
Logitech G pro wireless mouse. Logitech TKL915 wireless. Logitech Pro X Wireless.
Macbook M3 (16GB, 512GB). HP Reverb G2.
www.bamseclockers.com

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Har satt upp en FreeBSD 9 och sedan 9.1 server i OSX miljö som kör iSCSI mot klienterna. Maskinen är en SuperMicro X9SCM-F + Xeon E-1230v2 med 32 GB ECC RAM och två LSI SAS 9211-8i HBA som servar två RAID-Z2 vdevs med 6x3TB diskar var. Allt körs i en zpool. Har ingen SSD cache för L2ARC eller ZIL. Ethernet sköts av ett Intel quad nic med LACP. Systemdiskarna sitter på den interna kontrollern i speglat läge.

Kör lätt ZLE komprimering på iSCSI diskarna så att de inte blåser upp sig onödigt, men har inte haft problem med att de måste "trimmas". Samtliga diskar är över-provisionerade, har en dashboard widget som visar ledig kapacitet på servern. Arkivering sker på egen ZFS maskin. Kommer att uppgradera till 9.2 om en stund och tänker då experimentera med LZ4 på några "diskar".

Har inte haft några problem efter installation. Systemet ger totalt ca 3400 Mbit vid fyra klienter som arbetar samtidigt mot var sin disk och ledigt utrymme delas mellan de.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av beh:

Har satt upp en FreeBSD 9 och sedan 9.1 server i OSX miljö som kör iSCSI mot klienterna. Maskinen är en SuperMicro X9SCM-F + Xeon E-1230v2 med 32 GB ECC RAM och två LSI SAS 9211-8i HBA som servar två RAID-Z2 vdevs med 6x3TB diskar var. Allt körs i en zpool. Har ingen SSD cache för L2ARC eller ZIL. Ethernet sköts av ett Intel quad nic med LACP. Systemdiskarna sitter på den interna kontrollern i speglat läge.

Kör lätt ZLE komprimering på iSCSI diskarna så att de inte blåser upp sig onödigt, men har inte haft problem med att de måste "trimmas". Samtliga diskar är över-provisionerade, har en dashboard widget som visar ledig kapacitet på servern. Arkivering sker på egen ZFS maskin. Kommer att uppgradera till 9.2 om en stund och tänker då experimentera med LZ4 på några "diskar".

Har inte haft några problem efter installation. Systemet ger totalt ca 3400 Mbit vid fyra klienter som arbetar samtidigt mot var sin disk och ledigt utrymme delas mellan de.

Gå till inlägget

Rätt konfigurerar verkar ju RAIDZ vara väldigt effektivt, men helt okunnig inom BSD/*nix är det nog inte att tänka på för mig...

Skrivet av Printscreen:

Körde en openindiana med ZFS på labmiljö; den agerade iSCSI-san åt några ESX-hostar. Det var inte alltid helt stabilt men det berodde nog mest på skit bakom spakarna

Hårdvaran vad helt vanlig konsumentdito; intelprolle, ATX-mobo, LSI 8port kontrollerkot som hade 8st 2TB-diskar kopplat på sig och 2st patadiskar för OS. Sen 2st intel SSD i raid0 som cache.

Blev bra prestanda, men som sagt, i produktion är det nog bara att langa upp plånboken och gå till 3par eller Netapp.

Gå till inlägget

Precis, jag sätter ju ogärna upp något jag inte är van att arbeta vid i en produktionsmiljö och kompletta SAN-lösningar med ZFS drar nog iväg ekonomiskt.
Prestandan verkar ju vara helt okej i alla fall.

Hur pass mycket prestanda kan ett komplett NAS-OS med ZFS och RAIDZ tillhandahålla med liknande hårdvara som beh kör?

Visa signatur

{|XSX|PS3|PS4|}

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Wixner:

Hej,

Jag har länge varit förespråkare för hårdvaruraid, mest för att det är välbeprövat och jag vet vad jag får, men nu är det uppenbart att det finns en ny aktör med i spelet: Mjukvaruraid med ZFS och RAIDZ, vilket jag absolut kan se fördelar med, men jag undrar om det är någon här som faktiskt har tagit ZFS och RAIDZ i bruk i en produktionsmiljö eller om det bara är i lab- och/eller hemmamiljö som det används här på SweClockers?

Om så är fallet; vilken mjuk- och hårdvara har ni använt er av och vad används servern till?

Gå till inlägget

Jag har en bekant som gav mig lite info om deras backupserver på jobbet. Han jobbade på ett webhotell då.

Prestandan låg på 600 MBps. Inte megabit, utan megabyte alltså.

Info om setup: "33 diskar i 3 way mirror (11 vdevs), 6 cache devices (ZeusIOPS) och 3 ZIL (3 way mirror, ZeusRAM)". Som du kan förstå är detta ett system för hundratusentals kronor.

Något man måste förstå är att ZFS är primärt skapat för skalbarhet och datasäkerhet. Man har alltså inte fokuserat först och främst på prestandan, utan det är att datan som ligger där ska vara 100% korrekt och att man ska kunna bygga vidare när behoven utökas. Just skrivprestanda kan bli lidande när man använder billig hårdvara eftersom allting ska checksummas och skrivas synkront till diskarna.

ZFS är inte nytt. Det lanserades 2005 och är utan tvekan det bästa vi har att tillgå. Det är helt oberoende av hårdvara och det är just detta som är dess styrka. Vilken hårdvara som helst kan användas helt sömlöst, bara att flytta diskarna fysiskt dit de behövs. Det finns även kommandon för att klona datan från gammal till ny hårdvara över nätverk som garanterar att datan kommer fram korrekt.

När det gäller hemmabruk kan man väl säga att ZFS är ett bra val om man är medveten om att man kan tappa viss prestanda jämfört med en vanlig RAID-setup. Man vinner säkerheten och flexibiliteten i gengäld. Min erfarenhet är att man får vara beredd att lägga lite mer pengar på hårdvaran när man ska använda ZFS. En Intel Atom med 4GB ram lär inte räcka för att fylla en gigabit-länk om du kör RAIDZ. Min kompis körde en sån plattform med 4 diskar på 1TB var i en RAIDZ1. Han fick ut ungefär 10-20 MBps skrivning. Dock var läsningen ganska snabb.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Wixner:

Rätt konfigurerar verkar ju RAIDZ vara väldigt effektivt, men helt okunnig inom BSD/*nix är det nog inte att tänka på för mig...

Precis, jag sätter ju ogärna upp något jag inte är van att arbeta vid i en produktionsmiljö och kompletta SAN-lösningar med ZFS drar nog iväg ekonomiskt.
Prestandan verkar ju vara helt okej i alla fall.

Hur pass mycket prestanda kan ett komplett NAS-OS med ZFS och RAIDZ tillhandahålla med liknande hårdvara som beh kör?

Gå till inlägget

Nexenta byggera kommersiella lösningar på zfs med support som tävlar med netapp och de andra på allt utom priset, som är mycket lägre.

Ska du köra det själv så rekommenderar jag att du kör någon sorts solaris även om zfsonlinux är stabilt (enligt de själva stabilt nog för produktion).

Vill du köra linux kan du köra mdadm och xfs istället som är i jämförelse med zfsonlinux (och zfs på solaris) mycket mogen, kör det själv på min hp microserver då zfsonlinux+kryptering inte gick snabbt nog (cpun orkade inte med).

Visa signatur

CCNP

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Wixner:

Rätt konfigurerar verkar ju RAIDZ vara väldigt effektivt, men helt okunnig inom BSD/*nix är det nog inte att tänka på för mig...

Hur pass mycket prestanda kan ett komplett NAS-OS med ZFS och RAIDZ tillhandahålla med liknande hårdvara som beh kör?

Gå till inlägget

Jag tror att det är en fråga man måste ställa sig, vad är det som är viktigt för er? Jag är ingen BSD / Unix lord, men valde att sätta upp den lösningen för att alternativen var såpass långt från det som jag ville leverera. Det går att erbjuda snapshotting, thin provisioning och komprimering med andra system med, men det är svårare att administrera och varje lager är nya möjligheter för fel i data. kombinationen av Zfs och iSCSI eller Infiniband gör att man kan bygga ett system som tar tillvara på data med blocklevel checksumming, är enhetligt att administrera (nästan bara zfs kommandon), stödjer snapshots / rollback, har god prestanda, har komprimering och möjlighet att meddela om fel i realtid.

iSCSI blir också en god barriär mellan olika system, eftersom klienterna får använda sig av sina nativa filsystem och serven får använda sina. Samba eller NFS blir alltid kompromisser.

Om du vill ha lite bättre data än vad jag kan erbjuda så rekommenderar jag denna sidan: http://www.zfsbuild.com/

De har satt upp följande maskin:

  • SuperMicro SC846BE16-R920 chassis – 24 bays, single expander, 6Gbit SAS capable. Very similar to the ZFSBuild 2010 server, with a little more power, and a faster SAS interconnect.

  • SuperMicro X9SRI-3F-B Motherboard – Single socket Xeon E5 compatible motherboard. This board supports 256GB of RAM (over 10x the RAM we could support in the old system) and significantly faster/more powerful CPU’s.

  • Intel Xeon E5 1620 – 3.6Ghz latest generation Intel Xeon CPU. More horsepower for better compression and faster workload processing. ZFSBuild 2010 was short on CPU, and we found it lacking in later NFS tests. We won’t make that mistake again.

  • 20x Toshiba MK1001TRKB 1TB SAS 6Gbit HDD’s – 1TB SAS drives. The 1TB SATA drives that we used in the previous build were ok, but SAS drives give much better information about their health and performance, and for an enterprise deployment, are absolutely necessary. These drives are only $5 more per drive than what we paid for the drives in ZFSBuild 2010. Obviously if you’d like to save more money, SATA drives are an option, but we strongly recommend using SAS drives when ever possible.

  • LSI 9211-8i SAS controller – Moving the SAS duties to a Nexenta HSL certified SAS controller. Newer chipset, better performance, and replaceability in case of failure.

  • Intel SSD’s all around – We went with a mix of 2x Intel 313 (ZIL), 2x 520 (L2ARC) and 2x 330 (boot – internal cage) SSD’s for this build. We have less ZIL space than the previous build (20GB vs 32GB) but rough math says that we shouldn’t ever need more than 10-12GB of ZIL. We will have more L2ARC (480GB vs 320GB) and the boot drives are roughly the same.

  • 64GB RAM – Generic Kingston ValueRAM. The original ZFSBuild was based on 12GB of memory, which 2 years ago seemed like a lot of RAM for a storage server. Today we’re going with 64 GB right off the bat using 8GB DIMM’s. The motherboard has the capacity to go to 256GB with 32GB DIMM’s. With 64GB of RAM, we’re going to be able to cache a _lot_ of data.

Med Infiniband så klarar denna av att leverera 1854 MB/s = 14832 Mbit/s till en klient. Det finns mer benchmarks på sidan, så kolla genom där. På Serverfault finns även men massa trådar om liknande massiva byggen.

Skrivet av Traxton:

Jag har en bekant som gav mig lite info om deras backupserver på jobbet. Han jobbade på ett webhotell då.

Prestandan låg på 600 MBps. Inte megabit, utan megabyte alltså.

Info om setup: "33 diskar i 3 way mirror (11 vdevs), 6 cache devices (ZeusIOPS) och 3 ZIL (3 way mirror, ZeusRAM)". Som du kan förstå är detta ett system för hundratusentals kronor.

Något man måste förstå är att ZFS är primärt skapat för skalbarhet och datasäkerhet. Man har alltså inte fokuserat först och främst på prestandan, utan det är att datan som ligger där ska vara 100% korrekt och att man ska kunna bygga vidare när behoven utökas. Just skrivprestanda kan bli lidande när man använder billig hårdvara eftersom allting ska checksummas och skrivas synkront till diskarna.

ZFS är inte nytt. Det lanserades 2005 och är utan tvekan det bästa vi har att tillgå. Det är helt oberoende av hårdvara och det är just detta som är dess styrka. Vilken hårdvara som helst kan användas helt sömlöst, bara att flytta diskarna fysiskt dit de behövs. Det finns även kommandon för att klona datan från gammal till ny hårdvara över nätverk som garanterar att datan kommer fram korrekt.

När det gäller hemmabruk kan man väl säga att ZFS är ett bra val om man är medveten om att man kan tappa viss prestanda jämfört med en vanlig RAID-setup. Man vinner säkerheten och flexibiliteten i gengäld. Min erfarenhet är att man får vara beredd att lägga lite mer pengar på hårdvaran när man ska använda ZFS. En Intel Atom med 4GB ram lär inte räcka för att fylla en gigabit-länk om du kör RAIDZ. Min kompis körde en sån plattform med 4 diskar på 1TB var i en RAIDZ1. Han fick ut ungefär 10-20 MBps skrivning. Dock var läsningen ganska snabb.

Gå till inlägget

Kan meddela att min hemma server med en gammal sliten E4500 och 4 gig ram inte har några problem med saturera en 1GB länk med 6 diskar i raid-Z2. Men det är endast med en användare, börjar man läsa på fler ställen samtidigt så sjunker det mer än 1GB / antal strömmar. Antagligen för att readahead inte funkar med så lite ram.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av beh:

Kan meddela att min hemma server med en gammal sliten E4500 och 4 gig ram inte har några problem med saturera en 1GB länk med 6 diskar i raid-Z2. Men det är endast med en användare, börjar man läsa på fler ställen samtidigt så sjunker det mer än 1GB / antal strömmar. Antagligen för att readahead inte funkar med så lite ram.

Gå till inlägget

Ja, det hade jag förväntat mig också. Det är just dessa lågpresterande strömsnåla processorer så som Atom som har problem. Min tanke med vad jag skrev var just att varna för sådana processorer, jag skulle ha varit tydligare. En äldre "vanlig" CPU lär ju också fungera.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Traxton:

Ja, det hade jag förväntat mig också. Det är just dessa lågpresterande strömsnåla processorer så som Atom som har problem. Min tanke med vad jag skrev var just att varna för sådana processorer, jag skulle ha varit tydligare. En äldre "vanlig" CPU lär ju också fungera.

Gå till inlägget

No offence, jag ville bara påtala att prestandaförlusten måste finnas någon stans mellan denna gamla C2D och Atom.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av beh:

No offence, jag ville bara påtala att prestandaförlusten måste finnas någon stans mellan denna gamla C2D och Atom.

Gå till inlägget

No offense taken.

Kul att veta att en så pass gammal CPU funkar så bra, det öppnar ju upp möjligheten att kunna köpa begagnade prylar och komma undan billigt.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av beh:

Jag tror att det är en fråga man måste ställa sig, vad är det som är viktigt för er? Jag är ingen BSD / Unix lord, men valde att sätta upp den lösningen för att alternativen var såpass långt från det som jag ville leverera. Det går att erbjuda snapshotting, thin provisioning och komprimering med andra system med, men det är svårare att administrera och varje lager är nya möjligheter för fel i data. kombinationen av Zfs och iSCSI eller Infiniband gör att man kan bygga ett system som tar tillvara på data med blocklevel checksumming, är enhetligt att administrera (nästan bara zfs kommandon), stödjer snapshots / rollback, har god prestanda, har komprimering och möjlighet att meddela om fel i realtid.

iSCSI blir också en god barriär mellan olika system, eftersom klienterna får använda sig av sina nativa filsystem och serven får använda sina. Samba eller NFS blir alltid kompromisser.

Om du vill ha lite bättre data än vad jag kan erbjuda så rekommenderar jag denna sidan: http://www.zfsbuild.com/

De har satt upp följande maskin:

  • SuperMicro SC846BE16-R920 chassis – 24 bays, single expander, 6Gbit SAS capable. Very similar to the ZFSBuild 2010 server, with a little more power, and a faster SAS interconnect.

  • SuperMicro X9SRI-3F-B Motherboard – Single socket Xeon E5 compatible motherboard. This board supports 256GB of RAM (over 10x the RAM we could support in the old system) and significantly faster/more powerful CPU’s.

  • Intel Xeon E5 1620 – 3.6Ghz latest generation Intel Xeon CPU. More horsepower for better compression and faster workload processing. ZFSBuild 2010 was short on CPU, and we found it lacking in later NFS tests. We won’t make that mistake again.

  • 20x Toshiba MK1001TRKB 1TB SAS 6Gbit HDD’s – 1TB SAS drives. The 1TB SATA drives that we used in the previous build were ok, but SAS drives give much better information about their health and performance, and for an enterprise deployment, are absolutely necessary. These drives are only $5 more per drive than what we paid for the drives in ZFSBuild 2010. Obviously if you’d like to save more money, SATA drives are an option, but we strongly recommend using SAS drives when ever possible.

  • LSI 9211-8i SAS controller – Moving the SAS duties to a Nexenta HSL certified SAS controller. Newer chipset, better performance, and replaceability in case of failure.

  • Intel SSD’s all around – We went with a mix of 2x Intel 313 (ZIL), 2x 520 (L2ARC) and 2x 330 (boot – internal cage) SSD’s for this build. We have less ZIL space than the previous build (20GB vs 32GB) but rough math says that we shouldn’t ever need more than 10-12GB of ZIL. We will have more L2ARC (480GB vs 320GB) and the boot drives are roughly the same.

  • 64GB RAM – Generic Kingston ValueRAM. The original ZFSBuild was based on 12GB of memory, which 2 years ago seemed like a lot of RAM for a storage server. Today we’re going with 64 GB right off the bat using 8GB DIMM’s. The motherboard has the capacity to go to 256GB with 32GB DIMM’s. With 64GB of RAM, we’re going to be able to cache a _lot_ of data.

Med Infiniband så klarar denna av att leverera 1854 MB/s = 14832 Mbit/s till en klient. Det finns mer benchmarks på sidan, så kolla genom där. På Serverfault finns även men massa trådar om liknande massiva byggen.

Kan meddela att min hemma server med en gammal sliten E4500 och 4 gig ram inte har några problem med saturera en 1GB länk med 6 diskar i raid-Z2. Men det är endast med en användare, börjar man läsa på fler ställen samtidigt så sjunker det mer än 1GB / antal strömmar. Antagligen för att readahead inte funkar med så lite ram.

Gå till inlägget

Mycket matnyttigt där och det är kanske värt att sätta upp en labbmiljö och lära sig Solaris, även om den extrema prestandan handlar om att all hot-data ligger i RAM och inte på en SSD-cache eller mekanisk lagring.

Jag befinner mig i en situation där jag behöver tillhandahålla en större mängd iSCSI-targets som kommer att vara begränsade av 1GbE (möjligt 10GbE mot ett Hyper-V kluster) och jag misstänker starkt att jag klarar mig på en hårdvaruraid med ett LSI 9271 med CacheVault och 8st 4TB SAS2-diskar i RAID6 och en hotspare och ReFS-filsystem. Då får jag både felkontroller på hårdvarunivå (consistency checks och patol reads) och filsystemsnivå (ReFS)

Jag har dessvärre aldrig lyckas utvärdera hur hög overhead ReFS har.

Visa signatur

{|XSX|PS3|PS4|}

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Traxton:

No offense taken.

Kul att veta att en så pass gammal CPU funkar så bra, det öppnar ju upp möjligheten att kunna köpa begagnade prylar och komma undan billigt.

Gå till inlägget

Ja, den har ganska bra troughput under scrub: 10,7 Tb på 9:40, vilket ger ca 310 MB/s. Dock det är bara ca 50 MB/s pr. disk, men en scrub är till största del random IO och det kanske är vad diskarna klarar?

Skrivet av Wixner:

Mycket matnyttigt där och det är kanske värt att sätta upp en labbmiljö och lära sig Solaris, även om den extrema prestandan handlar om att all hot-data ligger i RAM och inte på en SSD-cache eller mekanisk lagring.

Jag befinner mig i en situation där jag behöver tillhandahålla en större mängd iSCSI-targets som kommer att vara begränsade av 1GbE (möjligt 10GbE mot ett Hyper-V kluster) och jag misstänker starkt att jag klarar mig på en hårdvaruraid med ett LSI 9271 med CacheVault och 8st 4TB SAS2-diskar i RAID6 och en hotspare och ReFS-filsystem. Då får jag både felkontroller på hårdvarunivå (consistency checks och patol reads) och filsystemsnivå (ReFS)

Jag har dessvärre aldrig lyckas utvärdera hur hög overhead ReFS har.

Gå till inlägget

Jag har inte förstahands erfarenhet med hur ReFS uppför sig, men många labb-burkar verkar vara sega: http://social.technet.microsoft.com/Forums/windowsserver/en-U...
Dock kan ju förklaringen vara att det just är labb-burkar, med ostabil hardware, äldre diskar och kanske inte den största insikt vid konfigurering.

Ett tips till TS och andra som vill lära sig om ZFS är denna serien med artiklar om ämnet: http://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux/ (dock behöver man ju inte köra debian och zfs-on-linux, baskunskapen gäller även FreeBSD och Solaris eftersom zfs administreras med egna kommandon).

Redigera
Citera flera Citera
Permalänk
Medlem
●

Jag har jobbat med NexentaStor, som är ZFS- och Solaris-baserat, i produktionsmiljö. Det var SAN byggda på mestadels SuperMicro-hårdvara med diskar (SSD) från OCZ.

Användningsområdet var både fillagring (på iSCSI-lun:ar) och VM-lagring via NFS.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Jag har satt upp en Nexenta-baserad filserver på KTH som körs i produktionsmiljö. Burken är en HP Proliant DL180 G6 med en enkel Xeon E5606 och 12GB RAM. Medföljande controllerkort (P410) slängde jag givetvis ut direkt, eftersom det funkar dåligt med ZFS. Datapoolen består i nuläget av 2x 2TB + 2x 3TB Constellation ES diskar i RAID10 och rpool ligger på 2x Intel 320 series 40GB i RAID1. Den har gått i snart två år nu utan några som helst problem och med bra prestanda.

En svårighet i denna miljö är att vi har enormt många små filer, vilket ZFS tycks klara av bra bortsett från att en scrub tar ganska lång tid (~10h).

Kan tillägga att jag kör en Solaris-server hemma med lite fler diskar i följande konfiguration:

	NAME                       STATE     READ WRITE CKSUM     CAP            Product
	newtank                    ONLINE       0     0     0
	  raidz1-0                 ONLINE       0     0     0
	    c0t5000C500500C27A2d0  ONLINE       0     0     0     4 TB           ST4000DM000-1F21
	    c0t5000C500500EECAEd0  ONLINE       0     0     0     4 TB           ST4000DM000-1F21
	    c0t5000C500500F4F73d0  ONLINE       0     0     0     4 TB           ST4000DM000-1F21
	    c0t5000C500500FBEA8d0  ONLINE       0     0     0     4 TB           ST4000DM000-1F21
	    c0t5000C50050120238d0  ONLINE       0     0     0     4 TB           ST4000DM000-1F21
	  raidz1-1                 ONLINE       0     0     0
	    c14t0d0                ONLINE       0     0     0     2 TB           WDC WD20EARX-00P
	    c14t1d0                ONLINE       0     0     0     2 TB           WDC WD20EARX-00P
	    c14t2d0                ONLINE       0     0     0     2 TB           WDC WD20EARX-00P
	    c14t3d0                ONLINE       0     0     0     2 TB           WDC WD20EARX-00P
	    c14t5d0                ONLINE       0     0     0     2 TB           WDC WD20EARS-00J
Senast redigerat
Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Vad jag förstår ska inte en scrubs hastighet påverkas av antalet filer, den arbetar ju på blocknivå (är ett zpool kommando) och block som block tycker jag.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av beh:

Vad jag förstår ska inte en scrubs hastighet påverkas av antalet filer, den arbetar ju på blocknivå (är ett zpool kommando) och block som block tycker jag.

Gå till inlägget

Det är möjligt att det är så. Jag har för mig att jag har läst att antalet filer påverkar scrub-hastigheten ändå, dock inte från någon auktoritet i ämnet. Långsamt (70 MB/s) går det i alla fall - jag hade förväntat mig bättre prestanda från de diskarna.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Hmm, ja det finns inget som jag känner till som har så stor inverkan på hastighet och därmed kan förklara dina 17,5 MB/s per. disk. Av ren nyfikenhet, har du motsvarande till ashift=12 på den? Dvs. det som man i FreeBSD måste göra för att tvinga ZFS att alingna på 2^12 bytes. Inte att det borde göra någon stor skillnad, med än möjligtvis vid många random reads.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Det är ashift=9 på vdevarna, men det är korrekt eftersom de har 512B/sektor. När jag kollade lite närmare på diskarna påmindes jag om det var 4x2 TB jag köpte i slutändan, pga av en prishöjning på 3 TB-diskarna. Kan dock passa på att klaga på HP då jag fick två olika märken på diskarna (i samma beställning). En av diskarna var till min förvåning en WD RE4, som nu måste samsas med 3 Constellation ES.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Det lutar nog åt att jag kommer att sätta upp en tillfällig lagringslösning på existerande hårdvara (Intel Core2Quad Q9550, 8GiB DDR2, 2xDELL SAS 6iR med IT-firmware och 4x1TiB 7200 RPM Samsungdisk) för att lära mig mer om Solaris (Av de OS med moget ZFS-stöd jag hunnit testa gillar jag Solaris bäst) och sätta upp och underhålla en RAIDZ1.

Det är dock ännu en fråga som jag inte fått svar på:
Om jag installerar ett HBA som har en SFF8087-kontakt och ansluter detta till ett aktivt SAS-bakplan, kommer jag då att kunna utnyttja SGPIO för diskstatus eller är SGPIO helt hårdvarubaserat?

Senast redigerat
Visa signatur

{|XSX|PS3|PS4|}

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

SGPIO finns det i alla fall stöd för i FreeBSD, men jag har endast fått det att fungera med GEOM och AHCI drivaren (Activity, tror jag fungerar med ZFS men Locate och Fail har jag inte fått att fungera med annat än GEOM). Dock tror jag inte att det är klart för SAS2008.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av beh:

SGPIO finns det i alla fall stöd för i FreeBSD, men jag har endast fått det att fungera med GEOM och AHCI drivaren (Activity, tror jag fungerar med ZFS men Locate och Fail har jag inte fått att fungera med annat än GEOM). Dock tror jag inte att det är klart för SAS2008.

Gå till inlägget

Tack för svaret.

Om stödet för SGPIO är "sådär" och beroende på underliggande operativsystem så är jag själv inte beredd på att gå över till mjukvaruraid.
Visst, det går säkert att skicka sms / email vid läs/skrivfel på en disk, men risken att rycka fel disk i kabinettet är fortfarande överhängande stor

Visa signatur

{|XSX|PS3|PS4|}

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Jag löste det genom att ha koll på mina diskar, har läst ut serienummer från varje disk med "camcontrol inquiry daX" och märkt upp de. Eftersom ZFS (likt alla moderna raid) inte behöver ha diskar i speciell ordning, så är de märkta med sin GPT label och det finns en fil på serverns OS disk som går andra hållet, dvs. från serienummer till label om man skulle behöva det någon gång.

Men det är förstås inte lika smidigt som att ha en komplett SGPIO setup och kanske inte något man ger sig in på om man inte brinner för att få köra ZFS

Redigera
Citera flera Citera
Permalänk
Avstängd
●

När det gäller ZFS vs NetApp, så är ZFS vanligare. Det är nog det vanligaste seriösa lagringslösningen i världen, större än NetApp och EMC/Isilon kombinerat:
http://blog.nexenta.com/blog/bid/257212/Evan-s-predictions-fo...

Ska du köra ZFS i produktion så rekommenderas Solaris 11.1 (det kostar pengar) eller OmniOS eller SmartOS eller Nexenta. Alla dessa är Solarish (dvs Solaris distron). Beroende på vad för data kanske du bör använda SSD diskar också. Man kan använda SSD som läs eller skrivcache. Ska du köra NFS så bör du använda SSD. Men helst ska du isåfall använda en rambaserad disk, såsom "STEC". Det finns flera Petabyte installationer utav ZFS, utan några problem. På www.hardforum.com finns trådar med seriösare installationer av ZFS, såsom SAS switchar och grejer, på Petabyte. Även på www.servethehome.com finns ZFS trådar, bl.a. folk som kör massa VMs på SSD raids och ZFS. Det... går snabbt. Typ, flera GB/sek.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Hej Wixner

Tänkte bara ge lite feedback på vad vi har uppsatt i mitt företag, åtminstone en del av det. Tidigare hade vi ca 20 servrar (1U HP servrar) där varje kund hade sin egen dedikerade server. I samband med att vi gick över till ESXi migrerade vi de flesta servrarna till en HP DL380 G7. Då denna och dess diskkapacitet snabbt blev en begränsning kopplade jag på ett 24 st 3,5" Supermicro chassi (expander versionen) på HP servern via ett LSI HBA kort. Uppsättning var ett gäng 1 TB pro HDD diskar samt två Intel 3xx SSD för skrivcache och en Intel 240GB som läscache.

Just denna komplettering med de extra 4-6TB vi fick har varit 100% stabil och till en mycket liten kostnad jämfört med vad det skulle kostat att komplettera upp HP 380 servern med deras egna diskar.

I samband med att vi gick över till ZFS arrayn skapade vi även en failover lösning mot ett externt hostingföretag (för de som undrar varför jag bara pratar om 1 server).

Till denna uppsättning kör vi Veeam på ett Windows 2012 i en av de gamla hp 1U burkarna som relativt löpande kör backuper på allt och dumpar detta på en Synology NAS, kör deduplicering både i Veeam och på Win2012 (bara det sparar oss just nu över 4TB backupdata, underbart).

Den lösning vi driftar gäller anläggningsregister/felanmälan mm. för flera av Sverige större företag (snittomsättning på vår kund är 11 Miljarder/år). Min största reflektion på allt detta är hur pass mycket en rejält utrustad ESXi server faktiskt klarar av. Vi har aldrig fått en kommentar om begränsad prestanda och vår aktuella flaskhals just nu är RAM-minne.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Andyreas:

Hej Wixner

Tänkte bara ge lite feedback på vad vi har uppsatt i mitt företag, åtminstone en del av det. Tidigare hade vi ca 20 servrar (1U HP servrar) där varje kund hade sin egen dedikerade server. I samband med att vi gick över till ESXi migrerade vi de flesta servrarna till en HP DL380 G7. Då denna och dess diskkapacitet snabbt blev en begränsning kopplade jag på ett 24 st 3,5" Supermicro chassi (expander versionen) på HP servern via ett LSI HBA kort. Uppsättning var ett gäng 1 TB pro HDD diskar samt två Intel 3xx SSD för skrivcache och en Intel 240GB som läscache.

Just denna komplettering med de extra 4-6TB vi fick har varit 100% stabil och till en mycket liten kostnad jämfört med vad det skulle kostat att komplettera upp HP 380 servern med deras egna diskar.

I samband med att vi gick över till ZFS arrayn skapade vi även en failover lösning mot ett externt hostingföretag (för de som undrar varför jag bara pratar om 1 server).

Till denna uppsättning kör vi Veeam på ett Windows 2012 i en av de gamla hp 1U burkarna som relativt löpande kör backuper på allt och dumpar detta på en Synology NAS, kör deduplicering både i Veeam och på Win2012 (bara det sparar oss just nu över 4TB backupdata, underbart).

Den lösning vi driftar gäller anläggningsregister/felanmälan mm. för flera av Sverige större företag (snittomsättning på vår kund är 11 Miljarder/år). Min största reflektion på allt detta är hur pass mycket en rejält utrustad ESXi server faktiskt klarar av. Vi har aldrig fått en kommentar om begränsad prestanda och vår aktuella flaskhals just nu är RAM-minne.

Gå till inlägget

Hej Andyreas,

Alltid lika roligt att få höra historier ur riktiga verksamheter
Den miljö du beskriver ovan kunde lika väl driftsättas med ett (eller två för redundans) riktigt raidkort från (exempelvis) LSI med 1GB DDR3 Cache och en CacheCade-nyckel med SSD-cache kopplat till ett dualport-baklplan och ett ReFS-filsystem på diskvolymen.

Naturligtvis finns det ju stora fördelar med ZFS och RAIDZ med dess hårdvaruindepens och möjligheten att ansluta oändligt antal fysiska volymer samt att du kan använda RAM-minnet som Tier0/Tier1 cache, men om man snackar om lösningar för hundratusentals kronor så är, enligt mig, hårdvaruraid fortfarande ett mycket konkurrenskraftigt alternativ.

Visa signatur

{|XSX|PS3|PS4|}

Redigera
Citera flera Citera
Permalänk
Medlem
●

Där säger jag inte emot dig och hade det inte funnits någon redundans i våran lösning (externa hostingföretaget) så är jag osäker på om jag vågat köra på denna lösning då jag själv har lite begränsat med tid att gräva ner mig i just ZFS och OSt det kör på.

Om man dock ska prata lite pengar så la jag ca 80-90K på HP servern men endast ca 35k på hela supermicroboxen inkl diskar och HBA kort. Att göra motsvarande komplettering i HP boxen med ex. LSI kort var inte möjlig då, varken rent fysiskt eller prismässigt men jag kan tänka mig om man börjar gå över 100k strecket så ändras förutsättningarna. Hade jag satt upp allt på nytt idag hade jag gjort det annorlunda igen.

Då hade det blivit en C6100 box med 2,5" diskplatserna sen hade jag endast kört Samsungs 1TB SSD diskar, spritt ut nuvarande ca 40VM på 2-3 av noderna och sen kört Veeams replikation till den 4de noden och därmed minskat ner på Raidredundans och istället förlitat mig på replikorna (var 5min). Det hade förenklat hela uppsättningen rejält och då vi kör IBM Domino som applikationsplattform hade den vid en krash endast behövt återsynka de 5 min med hostingföretagets data vilket tagit ett par sekunder.

Inte minst hade detta kostat mindre än 50% av nuvarande lösning till 4-5ggr prestandan.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Andyreas:

...
I samband med att vi gick över till ZFS arrayn skapade vi även en failover lösning mot ett externt hostingföretag (för de som undrar varför jag bara pratar om 1 server). ...

Gå till inlägget

Hur ser uppsättningen ut?
Kör du med VMDirectPath mot en virtuell Solaris eller BSD gäst och sedan iSCSI tillbaka mot ESXi värden?

Du får gärna utveckla lite mer tekniskt!

Visa signatur

AMD Ryzen 7950x3D | Asus ROG Strix B650E-E | 32GB G.Skill DDR5 6000Hz CL30 | ASUS TUF RX 7900 XTX OC | Cooler Master Tempest GP27U, Dell U2515H

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Vad jag förstod det som så var ZFS och VM boxen separata.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av beh:

Vad jag förstod det som så var ZFS och VM boxen separata.

Gå till inlägget

Efter att ha läst inlägget igen så tolkar jag också det så. Tolkade det först som en Supermicro disklåda.

Men det hade fortfarande varit intressant att få lite mer info om OS etc.

Visa signatur

AMD Ryzen 7950x3D | Asus ROG Strix B650E-E | 32GB G.Skill DDR5 6000Hz CL30 | ASUS TUF RX 7900 XTX OC | Cooler Master Tempest GP27U, Dell U2515H

Redigera
Citera flera Citera
Permalänk
Medlem
●

Hej Calle/beh

Låt mig förtydliga lite, alla vms körs på en HP DL380 G7 server, i denna sitter det ett LSI HBA kort med externa portar, dessa portar är kopplade rakt in i ett "dumt" supermicrochassi som endast innehåller en expander till 24 3,5" diskplatser. Så fast det är två fysiska boxar är supermicrochassit egentligen bara en utökning av simpla diskplatser.

Själva OSt som hanterar ZFS arrayn körs som ett vm med 32 GB Ram i vilket HBA kortet är passthruat (svenglish ftw). Lösningen började som en OpenIndiana installation med Napp-IT men slutade som OmniOS med Napp-it.

ZFS arrayn jag skapat och dess share delar jag ut tillbaka till ESXi ssom en vanlig datastore via NFS. Solaris har en bra NFSmotor men det är inte det snabbaste protokollet, dock kompenseras detta mer än tillräckligt av SSD zilen (läscachen).

Just nu har jag 3 datastore som ESXi har tillgång till, en raid1 lösning bestående av 450GB HP HHD diskar i HP servern, en Raid10 Array bestående av 4 st HP 640GB diskar samt datastoren från ZFS. Att clona ett vm från Raid1 lösning till ZFSdatastoren går ca 4ggr så fort som att clona den till Raid10 arrayn.

OmniOS kör vmxnet3 nätverk så delningen tillbaka till ESXi är via 10Gbps.

Redigera
Citera flera Citera
1 2
Skriv svar