90 likes | 105 Vues
NFSv4 Namespace & Migration Charles Fan Rainfinity. Three Global Namespaces. Cluster Namespace Called “global namespace” vs. “local node namespace” Many vendor solutions exist Enterprise Namespace Global multi-site deployment Fit for protocol standards work World-Wide Namespace
E N D
NFSv4 Namespace & Migration Charles Fan Rainfinity
Three Global Namespaces • Cluster Namespace • Called “global namespace” vs. “local node namespace” • Many vendor solutions exist • Enterprise Namespace • Global multi-site deployment • Fit for protocol standards work • World-Wide Namespace • One namespace to rule them all
Requirements • Location Independent • Logical view into file storage, independent of physical locations • Uniform Namespace • Clients possess views into the same global namespace • Transparent to Change • When the mapping between the namespace and physical location changes, the namespace presentation stays constant and clients are not affected • Secure • At least the same level of security is maintained as without the namespace
Considerations • Granularity • File system? Directory? File? • Hierarchical Mapping • Map /a/b to one link and /a/b/c to another? • Variable Support • Map /tools to f1:/tools_solaris for Solaris clients and f2:/tools_linux for Linux clients? • Manageability • Multi-protocol interoperability • Cycle Prevention
Based on Clients or Servers? • Purely client-based • Automounter + LDAP • Transparency concerns when namespace is changed • Purely server-based • Always in-band • Scalability concerns for distributed enterprises • Protocol-based • Both server and clients comply with protocol • Opportunity for highest level of transparency, scalability and interoperability.
Migration Issues • Server-server protocol • During migration • Third party vendor solution possible • Client-server protocol • Namespace update after migration • Protocol spec crucial • File Handle Refresh • Clients cache file names to look up again in new file system • How to take care of the rename case?
Work Items • Problem statement • Schema for global namespace • Client-server interaction for both referral case and migration case • Clarification of RFC 3530 • Reference implementation of clients, servers and namespace server • Possible minor version extensions • Best Practice documents
Rainfinity Motivation • Rainfinity relies on widely-adopted out-of-band global namespace solution for our Network File Virtualization architecture • Currently work with MS Dfs, Automounters, etc • Expect NFSv4 will enhance our functionality • Rainfinity RainStorage provides transparent server-server migration and temporary client redirection. • We hope that client-server interactions are built into clients and servers to handle permanent global namespace and dynamic change of data location • Rainfinity is ready to commit resource to work with other companies to move fast on standards work related to global namespace and migrations