We got a 4220 as a big storage box with decent perf to go with an HP 3par in our 3 node Windows server cluster. It is running over ISCSI.
We bought a Netgear M7100-24X 10GB switch to go with it. We are running the Hyper-V Hosts and NAS in LACP mode on the switch. They use their own subnet. LAG is layer 3 and 4 (src/dest IP and port) on the switch and NAS. The Hyper-V hosts are using Dynamic mode with LACP.
We are running 12 Red Pro WDC WD4001FFSX drives which are on the HCL.
Couple of issues, A RAID 10 rebuild takes 30 hours on this box compared to an xraid2 raid 6 or 5 build which takes around 7. It should be a simpler build, why does it take longer?
The biggest issue is the NAS has been locking up and going non responsive. It did it three times in 2 days last week. I have a support case open, but support say the logs show everything is fine.
I put it into Xraid2 raid 6 and it worked for the whole weekend, but perf is not as good as I wanted for test VM's running Databases.
Bitrot is turned off and so is sync on write. Performance is good when it is running, but having to hard power it off every day is going to get old fast.
I have just done an OS reinstall and factory reset yesterday, waiting on RAID 10 to build again (15 hours in and 15 hours to go), then will create an 8TB LUN to present to the Hyper-V servers and see how it goes again.
Do I need to wait for the RAID build to complete before creating my LUN?
We are running 6.2.4, I see here: http://kb.netgear.com/app/answers/detail/a_id/29938 that 6.4.0 is released, is that a final release now? Should I try that to address any BTRFS and ISCSI issues that are fixed according to the changelog?
Cool, thanks. I have installed it this morning and provisioned a new 8TB iscsi lun on my freshly build RAID 10 volume. It has got a few VM's on it. Now we wait...
If you're running VMs, set sync writes to disabled, make sure it is a thick LUN, no snapshots, no bit rot protection, and be on 6.4.0. This should increase the performance of your VM as well as keep the file system less-able to become fragmented. Being fragmented is a huge cause for lock-ups on copy-on-write file systems.
Also set up a defrag and balance schedule to keep your volume clear from fragmentation. Have it run defrag then balance in that order during a time of least use.
Hi, thanks for the reply. We had thick luns, sync writes off, copy on write off and no snapshots. Maybe we needed to make sure it was all set that way before putting VM's on instead of changing settings after it was already in use. I only learned about copy on write and sync writes after we had some VM's running on it.
So far we have been up for a day which is better than the first RAID 10 effort. If it makes it through the weekend, it will equal the longest run we had without a crash. Fingers crossed the kernel changes in 6.4.0 are the silver bullet that makes this NAS stable. In RAID 10 with the disks we have in it, performance is sparkling and it has loads of space. If it can be as stable as our old faithful ReadyNAS 2100, I would be stoked. I have scheduled a defrag and balance to run on a schedule now.
Hi, progress report, the NAS has been up since Friday last week (5 days now). 6.4.0 seems to be stable and the BTRFS/ISCSI changes have helped. It has one odd thing, like the splash screen for Web login still displays 6.2.4 on the 4220, but overall it is working well on the 316 and the 4220.
So your on 6.4 using iSCSI your running Raid 10 now or Flex5 and you said everything is working fine now? I am using Raid 10, iscsi and can't keep it running more than a few days without it locking up from using backup exec 10 on it and the latest 6.4.2 will only last a day.
I had to install 6.4.0 (I haven't put on 6.4.1 or ..2,) I am running Raid 10 and ISCSI with a 3 node HyperV cluster. I think from memory I fully reset it to factory after doing the install of 6.4.0 as it had nothing on it at the time. It was just about to come out of the rack and go back to Netgear. It has had no issues since then. I also have a little 6 bay NAS also using ISCSI presenting storage to a backup server running Veeam. That was having similar issues and has been fine on 6.4.2.
