.png "Nexsan"){kind=logo}
As I watch the expansion of sync and share (SnS) into the enterprise, I’m growing concerned that many organizations are creating yet another silo of storage. Wouldn’t it be a better idea for the “unified storage” system in my data center to serve up the same files it delivers to local users via SMB to remote users via SnS?
Over a decade ago, vendors started integrating block storage, which until then was the exclusive domain of dedicated SAN arrays, into their file-serving NAS systems. This integration created multi-protocol, or unified storage.
Unifying file and block empowered users to support database servers, virtual machines, and other block-friendly workloads alongside user home directories and large file repositories on a single storage system. Unified storage as a concept has been so successful that it’s now rare to find a NAS that doesn’t provide iSCSI LUNs as an option.
File services have been our goto[1] [stet] solution for on-premises users ever since the glory days of Novell NetWare in the 1990s. Other than “Your personal files go in H: and the marketing group uses M:” users don’t need any training and get generally good performance.
Users in the field, on the other hand, have had to suffer with multiple generations of complicated and ultimately unsatisfactory solutions, from VPNs and FTP sites to the Windows Briefcase and offline folders. While some tech-savvy users could remember to sync their Briefcase before unplugging their laptop for a trip out of town, or connect the VPN before downloading a file, most ended up frustrated at 2AM in the Podunk Marriott.
Meanwhile, out on The Internet, innovators like Dropbox and YouSendIt (now Hightail) finally found a good way to keep the files used by mobile users up to date and to share files with outsiders. Their sync-and-share (SnS) solution finally gave road warriors an easy way to access files from HQ, and for users across the organization to share files with customers, resellers, and other “partners”.
Sync and share has been so popular that at least one industry leader predicted a couple of years ago that traditional file services will fade away in favor of SnS. The problem with that prediction is that file services have some significant advantages for users [with?] LAN or LAN-like connections to the filer.
The big difference between file services and SnS solutions is that file services provide shared access to a single copy of each file rather than making a copy of each file for each user that may want to access it. An organization replacing file services with sync and share would need to install multi-terabyte hard drives in each user’s desktop in addition to the 128GB SSD for the operating system and applications.
While file services can’t compete with online applications like Google Docs that allow multiple users to edit the same document and see each other’s changes in real time, the “Obadiah Stane has this file open, do you want to open a read-only copy” message gives you the opportunity to poke Obadiah and have him close the file or wait till he’s done. You might also want to let Mr. Stark know that Mr. Stane didn’t really die at the end of Iron Man.
Because SnS is asynchronous, if you and Mr. Stane each edit the plans for the Arc Reactor at the same time, you end up with two files: one with your changes and another with Obadiah’s. Now someone has to find all the changes and merge the files.
Then there are the applications that just require file services. The most glaring example is persistent VDI. All the major VDI systems, including VMware’s Horizon View and Citrix XenDesktop, store the user’s persona from desktop wallpaper to the cache of Outlook attachments they’ve opened on a file share. Syncing, rather than sharing, this data would require huge local storage on the VDI servers and extend login times significantly.
Today, most SnS solutions use dedicated storage repositories. While some solutions allow enterprises to keep the repository in their data center, it’s still a dedicated repository that users access exclusively via sync and share. When files must be shared between onsite and remote users, processes must be established to synchronize the file store and SnS repositories.
A truly unified storage system would allow users to access the files they need using the protocol that’s most appropriate for their needs at any given point in time. Local users access a file share via SMB, remote users sync to the same copy, and the system publishes URLs for sharing files with partners.
Since all users are now referring back to the same copy of the data on the unified storage system, that copy becomes the authoritative copy of the data. Yes, multiple versions of files will still be created when multiple users update the same file, but all will be stored on the unified storage system.
Having one authoritative copy of every file in one place not only saves the cost and data center space for yet another storage system but also centralizes all of our data governance activity. We have one storage system to backup and archive from, and only one place to search when an eDiscovery demand comes in.
One hint I may be right about integrating SnS with file services is Nexsan’s Unity. Unity integrates block and file technology from Nexsan with the sync and share from its acquisition of Geoff Barrall’s Transporter. Unity systems support Fibre Channel and iSCSI for block I/O, and SMB and NFS for file access. They also support web access and sync clients for Windows, OS X, Linux, Android, and iOS. Windows phone users, as usual, are left out.
Remote users running the sync client connect to a Nexsan-operated connection broker in the cloud, simplifying the network connection and firewall rules. Both SMB and SnS users authenticate against the user’s Active Directory. Access is controlled by the file system ACLs, so there’s just one set of security permissions to worry about.
Nexsan even threw in a feature I wasn’t looking for: synchronizing folders between Unity systems at multiple locations so larger sales offices can keep their files up to date and minimize the network traffic by sending each file just once.
My guess is that enterprise sync and share will become yet another protocol for unified storage. Nexsan thinks I’m right. Who’s next?
About the Author
Self-described as the storage industry’s skeptic, curmudgeon and professional explainer, Howard Marks is the Founder and Chief Scientist at DeepStorage, LLC an independent test lab and analyst firm specializing on data storage, virtualization and data center networking. Before founding DeepStorage Howard was a New York based consultant for over 30 years helping organizations including BBDO, SUNY Purchase and the Foxwoods Resort Casino solve their IT infrastructure problems.
An entertaining and highly rated speaker Howard speaks regularly at industry events including VMworld, Interop, SNW and Microsoft’s TechEd. He has written three books and hundreds of articles on networking and storage technologies. He currently writes a column/blog at NetworkComputing.com. For more from Howard, go to
https://www.deepstorage.net/NEW/2017/02/
[1] After way too many years writing BASIC my fingers can’t put a space in between go and to.
