Lol...couldn't agree more...attaching multiple LUNs from different arrays to a Linux box is an exercise in frustration, and multipathing on Linux is a joke...especially with SLES.
IMO both have their nuances, but I've had a lot better results/stability with OpenSolaris than Linux...and let's not mention volume management...EVMS vs ZFS? Lol...
Linux is great for simple LAMP stacks...
If all you want is cheap NAS, you can do the same thing using any number of the free NAS solutions out there. Just add lots of cheap SATA disks in whatever cheap JBODs you can get your hands on, and you are done.
To replace a modest percentage of the functionalities of a mature NAS solution like Netapp's ONTAP + WAFL, you would need to:
1. Install Solaris 10 on a extremely reliable platform 2. Configure your zpools/filesystems 3. Set your NFS attributes 4. Install and compile all dependencies for Samba to support LDAP, Winbind, Kerberos (SFW stuff doesn't cut it) 5. Configure winbind/kerberos/LDAP 6. Configure LDAP backend in Samba (hint: NFS) 7. Either extend AD schema/turn on POSIX attributes or use a metadirectory to store idmaps
Now throw manageability into this equation...considering half of the admins out there have problems getting past step 5 above with any kind of consistency, Netapps suddenly makes a lot of sense, especially to companies that are contractor-happy and not willing to maintain that level of in house expertise.
What about scalability as a NAS (keyword NAS)? We can always throw SC 3.2 into the mix right? Unfortunately, NFS/Samba can only be configured as failover, and not scalable services in a Solaris Cluster. And ZFS? it can't be globally mounted and can only be used locally or for failover through HAStorage+...by the time you get to this point, you won't be using SATA drives with cheap JBODs anyway.
Now what about using ZFS to replace a SAN? Again, no.
A SAN's main function is to provide hosts with uniformed access to storage devices in your environment, be it through FC/Infiniband fabrics or iSCSI. This in turn allows you to better manage many aspects in your storage environment, such as but not limited to storage allocation, host access control/security, availability, and virtualization.
ZFS, at its core, is a file system. Yes, its well integrated with volume management, NFS, and self-healing functions. But it is still just a file system. A file system's job is to provide access to files (yes I know you can set up raw volumes with ZFS).
If you really look at the big picture, a file system is just another layer of virtualization in the storage game...by their very nature, filesystems and SANs sit at different layers in the OSI model. Comparing ZFS to SANs, is somewhat akin to comparing FTP to IP.
One cannot replace the other, they serve different functions in your storage environment.
Slashdot Mirror
Lol...couldn't agree more...attaching multiple LUNs from different arrays to a Linux box is an exercise in frustration, and multipathing on Linux is a joke...especially with SLES. IMO both have their nuances, but I've had a lot better results/stability with OpenSolaris than Linux...and let's not mention volume management...EVMS vs ZFS? Lol... Linux is great for simple LAMP stacks...
If all you want is cheap NAS, you can do the same thing using any number of the free NAS solutions out there. Just add lots of cheap SATA disks in whatever cheap JBODs you can get your hands on, and you are done.
To replace a modest percentage of the functionalities of a mature NAS solution like Netapp's ONTAP + WAFL, you would need to:
1. Install Solaris 10 on a extremely reliable platform
2. Configure your zpools/filesystems
3. Set your NFS attributes
4. Install and compile all dependencies for Samba to support LDAP, Winbind, Kerberos (SFW stuff doesn't cut it)
5. Configure winbind/kerberos/LDAP
6. Configure LDAP backend in Samba (hint: NFS)
7. Either extend AD schema/turn on POSIX attributes or use a metadirectory to store idmaps
Now throw manageability into this equation...considering half of the admins out there have problems getting past step 5 above with any kind of consistency, Netapps suddenly makes a lot of sense, especially to companies that are contractor-happy and not willing to maintain that level of in house expertise.
What about scalability as a NAS (keyword NAS)? We can always throw SC 3.2 into the mix right? Unfortunately, NFS/Samba can only be configured as failover, and not scalable services in a Solaris Cluster. And ZFS? it can't be globally mounted and can only be used locally or for failover through HAStorage+...by the time you get to this point, you won't be using SATA drives with cheap JBODs anyway.
Now what about using ZFS to replace a SAN? Again, no.
A SAN's main function is to provide hosts with uniformed access to storage devices in your environment, be it through FC/Infiniband fabrics or iSCSI. This in turn allows you to better manage many aspects in your storage environment, such as but not limited to storage allocation, host access control/security, availability, and virtualization.
ZFS, at its core, is a file system. Yes, its well integrated with volume management, NFS, and self-healing functions. But it is still just a file system. A file system's job is to provide access to files (yes I know you can set up raw volumes with ZFS).
If you really look at the big picture, a file system is just another layer of virtualization in the storage game...by their very nature, filesystems and SANs sit at different layers in the OSI model. Comparing ZFS to SANs, is somewhat akin to comparing FTP to IP.
One cannot replace the other, they serve different functions in your storage environment.