This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
We've recently purchased (2) ReadyNas 3220's to go in conjunction with a NEW Vsphere 6.0 environment. We clearly overlooked the VSphere compatibility lists with regards to these units and are now faced with degraded VMWare support when referring to these units. These units were purchased as Bronze level storage that we were anticipating landing VM backups/ISO's and other cold storage items. Our primary storage will be an Equallogic SAN in which we have had very good results with. My question is, how long will it , or will Netgear ever get to the point where the 3200 units will be ESXI 6.0 compatible? Is this something that needs to be done on the VMWare side or the Netgear side and any timelines would be greatly appreciated?
VMs work if you have it configured. I recommend using a Thick LUN, no snapshots, no bit rot protection, sync writes set to disabled. This prevents fragmentation. What problem are you having with ESXi 6.0 otherwise with ReadyNAS?
VMs work if you have it configured. I recommend using a Thick LUN, no snapshots, no bit rot protection, sync writes set to disabled. This prevents fragmentation. What problem are you having with ESXi 6.0 otherwise with ReadyNAS?
There's a lot of factors into getting storage devices onto the VMware HCL. Now that 6.4.0 is using a more enhanced kernel and upgraded functionality, we can try to get VMware certified again (it's already on the list).
Regardless of VMware's HCL, ReadyNAS devices work fine with VMware, but you really have to configure the device for your use case. Picking up a device with a copy-on-write fs and trashing the file system in minutes due to improper configuration is very easy to do.
btrfs is a copy-on-write file system and there's a lot of factors in play about how data is written. I've been running VMs without incident directly from the NAS using iSCSI without any fragmentation for quite some time now.
If you have bit rot protection turned on, it is keeping track of all file system transactions taking place. This is not ideal in VM environments because VMs do a LOT of random IO and this gunks up the metadata table so your system will crawl when trying to get metadata. Do not turn this on when creating the LUN or when creating a share that hosts VMs.
Don't use the ReadyNAS snapshots to keep snapshots of the iSCSI LUN or of VM files. If you have bit rot protection off, but take a snapshot, it enables copy-on-write and starts keeping track of your transactions. Don't snapshot an iSCSI LUN or VM files. Use your VM software to take snapshots.
Sync writes are notortious for slowing down VMs. Each time your initiator sends a sync command, the ReadyNAS has to wait for all that data to sync from RAM to disk and can't write new data. A lot of syncs in a row cause it to become unusable. Turn off sync writes to improve performance on VMs.
Don't use Thin LUNs for VMs. Thin LUNs inherently fragment the file system as the LUN grows. Thick LUNs preallocate space and allow data to be added into a file, rather than added onto a file. Use Thick LUNs
Try not to exceed 80% of your volume. btrfs has an expandable metadata table that needs the ability to grow when necessary. The more full your unit is, the less likely it can expand your metadata table, so it will be unable to write more data. ReadyNAS devices duplicate the metadata table, so if you're using 20 GB of metadata, you're really using 40 GB. 100 GB of metadata is really 200 GB. If you have this much metadata, consider how much RAM your unit has and imagine trying to squeeze 20 GB of metadata into 2 or 4 GB of RAM. This also adds a ton of disk i/o when it needs to find free space and eventually can't find the free space fast enough, and it panics. Leave 15-20% of your file system open for breathing room.
Schedule volume maintenance. This is your only agent in helping reduce the risk of fragmentation besides properly configuring your device. Run defrag first (this reduces the number of extents your files have in the file syste; realistically, you want 1-10 extents per file, including large files), let it finish, and then run balance (balance will reduce total allocations of data and metadata). I generally run defrag on Saturday mornings when it is not being used heavily. I run balance Sunday morning when it is not in use. Scrub is only probably needed once every 3-6 months, if that (but it depends on your usage).
The same goes for backup jobs, really... Don't snapshot your backup data because your backup data will always be changing (pruning after a snapshot still uses all the space). Snapshots work best with file shares, like storing documents, pictures, and video files.
