Patent Publication Number: US-11042512-B1

Title: Enabling granular snapshots and provisioning in NAS (network attached storage) clusters

Description:
BACKGROUND 
     Data storage systems are arrangements of hardware and software that include storage processors coupled to arrays of non-volatile storage devices, such as magnetic disk drives, electronic flash drives, and/or optical drives, for example. The storage processors service storage requests, arriving from host machines (“hosts”), which specify files or other data elements to be written, read, created, deleted, and so forth. Software running on the storage processors manages incoming storage requests and performs various data processing tasks to organize and secure the data elements stored on the non-volatile storage devices. 
     Some data storage systems implement their operational software within virtual machines (“VMs”) or other virtualization platforms, such as userspace containers. As is known, virtual machines run entire operating systems, including both userspace and kernel space. Containers create virtualized userspace instances that run over a common kernel. 
     Some virtualization platforms provide their own mechanisms for provisioning storage and supporting snapshots (“snaps”), i.e., point-in-time versions of data objects. For example, ESX hosts (available from VMWare, Inc., of Palo Alto, Calif., now part of Dell Corporation) support provisioning of vdisks (virtual disks) to virtual machines. To support snaps, an executive program, such as vCenter, directs an ESX host to create a snap of a vdisk. vCenter orchestrates the snap activity and makes the snap available to the ESX host, which can access the snap for recovery, record keeping, or other purposes. 
     SUMMARY 
     Efforts are underway to develop a data storage system in the form of a NAS (network attached storage) cluster. The NAS cluster aggregates file systems using NAS servers, where each NAS server includes a collection of host file systems, one or more network servers, and various settings (e.g., as a further developed form of virtual data mover, or “VDM”). Examples of network servers include SMB (Server Message Block) servers, other CIFS (Common Internet File System) servers, and/or NFS (Network File System) servers. In such systems, it would be desirable to provide snapshots at file-system-granularity but to provide replication and mobility across the cluster at NAS-server granularity. It would also be desirable to support operation of many NAS servers on each data node of the cluster and to back each file system of each NAS server with its own logical disk, such as its own vdisk. 
     Unfortunately, the way that virtualization platforms manage snapshots is not consistent with these aims. For example, taking a snapshot of a vdisk in a virtual machine platform effectively binds the vdisk to the VM to which it is provisioned, making it impossible or impractical to reassign the vdisk from one VM to another. If the VM runs many NAS servers, then all the NAS servers would need to move together, as part of moving the entire virtual machine from one node (computer) to another. But such movement would be at per-VM granularity, not at per-NAS-server granularity, as desired. 
     To make a VM implementation work with the current limitations, it might be necessary to deploy each file system in its own VM (one file system per VM). However, this approach would come at a very high cost in terms of processor and memory utilization, as each virtual machine has a large processor and memory footprint. Also, the time required to tear down a virtual machine on one node and to boot it on another, e.g., consequent to load balancing, failover, and so forth, would not be acceptable to customers in most enterprise deployments. A more practical solution is needed. 
     In contrast with prior approaches, an improved technique for supporting snapshots in a NAS (network attached storage) cluster includes implementing a file system built upon a virtual disk realized in a virtualization platform, the virtual disk itself built upon a first LUN (Logical UNit) in block storage. In response to a request to take a snapshot of the file system, the NAS cluster bypasses the virtualization platform and directs a request to a block storage manager to take a snapshot of the first LUN, thereby creating a second LUN. The NAS cluster records a relationship between the first LUN supporting the file system and the second LUN supporting the snapshot, but the virtualization platform treats the second LUN as an independent object with no known snapshot relationship to any other object. 
     Advantageously, the improved technique isolates the virtualization platform from the snapshot process, such that any constraints regarding mobility of virtual disks that have been snapped are avoided. As a consequence, the NAS cluster is able employ the virtualization platform while still supporting snapshots at per-file-system granularity and mobility at per-NAS-server granularity. 
     In some examples, the NAS cluster isolates the virtualization platform not only from the snapshot process, but also from a process for provisioning. For example, to create a new file system, the NAS cluster may direct the block storage manager to provision a new LUN. The virtualization platform may discover the new LUN and render it as a virtual disk that supports the new file system. The NAS cluster may record any relationships of the new LUN to other objects that it tracks, or may indicate no relationship if that is the case, but the virtualization platform treats the new LUN as an independent object. 
     Certain embodiments are directed to a method of managing data in a NAS (network attached storage) cluster. The method includes operating multiple NAS data nodes in the NAS cluster, each of the NAS data nodes having access to block storage, the block storage controlled by a storage manager. The method further includes providing a file system in a NAS data node in the NAS cluster, the NAS data node running within a virtualization platform on a physical computing machine, the file system built upon a virtual disk from the virtualization platform, the virtual disk derived from a first LUN (Logical UNit) assigned to the virtualization platform from the block storage. In response to receiving a request to create a snapshot of the file system, the method still further includes bypassing the virtualization platform and issuing a snap command to the storage manager, the block storage then creating a second LUN as a snapshot of the first LUN and recording a snapshot relationship between the first LUN and the second LUN in the NAS cluster, the snapshot of the file system thereby created without involvement of the virtualization platform. 
     Other embodiments are directed to a NAS cluster constructed and arranged to manage data in, such as the method described above and other methods directed to provisioning a new file system. Still other embodiments are directed to a computer program product. The computer program product includes a set of non-transient, computer-readable media that store instructions which, when executed by control circuitry of a NAS cluster, cause the control circuitry to perform a method of managing data in a NAS cluster, such as the method described above. 
     The foregoing summary is presented for illustrative purposes to assist the reader in readily grasping example features presented herein; however, the foregoing summary is not intended to set forth required elements or to limit embodiments hereof in any way. One should appreciate that the above-described features can be combined in any manner that makes technological sense, and that all such combinations are intended to be disclosed herein, regardless of whether such combinations are identified explicitly or not. 
    
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 
       The foregoing and other features and advantages will be apparent from the following description of particular embodiments of the invention, as illustrated in the accompanying drawings, in which like reference characters refer to the same or similar parts throughout the different views. 
         FIG. 1  is a block diagram of an example electronic environment and NAS (network attached storage) cluster in which embodiments of the improved technique hereof can be practiced. 
         FIG. 2  is a block diagram of an example physical computing machine of the NAS cluster of  FIG. 1  configured as a cluster manager. 
         FIG. 3  is a block diagram of an example physical computing machine of the NAS cluster of  FIG. 1  configured as a NAS data node. 
         FIG. 4  is a block diagram showing an example NAS data node running within a virtual machine. 
         FIG. 5  is a block diagram showing an example NAS data node running within a container that provides a virtualized userspace environment. 
         FIG. 6  shows an example arrangement of a file system in a NAS server. 
         FIG. 7  shows an example FSDB (file system database) of a NAS server in additional detail. 
         FIG. 8  shows an example management database of a cluster manager of  FIG. 1  in additional detail. 
         FIG. 9  shows an example sequence for creating a new NAS server in the NAS cluster of  FIG. 1 . 
         FIG. 10  shows an example sequence for creating a new file system within a NAS server. 
         FIG. 11  shows an example sequence for performing failover. 
         FIG. 12  shows an example sequence for performing load balancing. 
         FIG. 13  shows an example sequence for generating a snapshot. 
         FIG. 14  is a flowchart showing an example method for renaming a file system. 
         FIG. 15  is a flowchart showing an example method of performing replication. 
         FIG. 16  is a flowchart showing an example method of managing data storage. 
         FIG. 17  is a block diagram showing an example arrangement for generating a snapshot of a file system. 
         FIG. 18  is a block diagram showing example structures that support the file system and the snapshot in a physical computing machine of  FIG. 1 . 
         FIG. 19  is a block diagram showing example movement of a NAS server, including the file system and the snapshot, from one virtual machine to another. 
         FIG. 20  is a sequence diagram showing an example procedure for issuing a snap command. 
         FIG. 21  is a flowchart showing an example method for managing data in a NAS cluster. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Embodiments of the invention will now be described. It should be appreciated that such embodiments are provided by way of example to illustrate certain features and principles of the invention but that the invention hereof is not limited to the particular embodiments described. 
     This document is provided in the following sections to assist the reader:
         Section I presents an example system environment and NAS (network attached storage) cluster in which embodiments of improved techniques hereof can be practiced.   Section II presents techniques for performing granular storage provisioning and snapshots in NAS clusters, such as the one presented in Section I.
 
Section I: Example Environment and NAS Cluster.
       

     A technique for managing data storage provides multiple physical computing machines and block storage arranged in a NAS (network attached storage) cluster. The physical computing machines run NAS servers, with each NAS server including an FSDB (file system database) that identifies a set of file systems that belong to the NAS server. Providing FSDBs on a per-NAS-server basis promotes mobility of NAS servers as well as scalability of the NAS cluster overall. 
     This section presents a novel platform for realizing a NAS cluster, which employs any number of NAS data nodes and one or more management nodes having access to shared block storage. Each node of the cluster runs a software library to support NAS cluster operations within an operating system, such as Linux. Example implementations of the NAS cluster leverage software-defined features, such as software defined storage (SDS), and may be deployed over a wide range of operating platforms, such as ESX (VMware), KVM (kernel-base virtual machine), bare metal, or containers (e.g., Docker containers). 
       FIG. 1  shows an example environment  100  in which embodiments of the techniques disclosed herein can be practiced. Here, multiple host computing devices (“hosts”)  110  access a NAS cluster  130  over a network  120 . The NAS cluster  130  includes multiple physical computing machines  140  (e.g.,  140 - 1  through  140 -M) connected to one another via a computer network, such as a LAN (local area network)  132 . Each of the physical computing machines  140  has access to block storage  170 , which includes multiple storage drives  174 , such as magnetic disk drives, electronic flash drives, NVM-e drives, and/or other types of drives. The block storage  170  includes a storage manager  172 , which manages block-based functions, such as provisioning, snapping, replication, and so forth, as well as communication with external equipment. In some examples, the storage manager  172  arranges the storage drives  174  in RAID (Redundant Array of Independent Disks) groups or in other redundant arrangements, and expresses the storage drives  174  as Logical Units (LUNs)  180 . Each LUN  180  may be constructed from any number of storage drives  174 , from portions of such storage drives  174 , or from a single portion of a single storage drive  174 . As is known, clients may access data in LUNs by specifying logical unit number and offset. 
     The environment  100  further includes an administrative machine  114 , such as a computer, which runs an administrative program  114   a  for managing the NAS cluster  130 . In some examples, the administrative program  114   a  and the storage manager  172  are provided together in a single program or set of programs. Thus, in some examples, the storage manager  172  manages not only the block storage  170  but also the NAS cluster  130 . 
     The physical computing machines  140  may be provided as circuit board assemblies, or “blades,” which plug into a chassis (or multiple chassis) that encloses and cools them. Each chassis has a backplane for interconnecting the physical computing machines  140 , and additional connections may be made among physical computing machines using cables. It is understood that no particular hardware configuration is required, however, as the physical computing machines  140  may be any type of computing devices capable of processing host I/O requests. 
     The hosts  110  may be any computing device or devices that access the NAS cluster  130  for reading and/or writing data stored therein. Examples of hosts  110  include personal computers, smart phones, tablet computers, Internet of Things (IoT) devices, workstations, enterprise servers, or any other type or types of processing device capable of exchanging data over a network. The network  120  can itself be any type of computer network, such as the Internet, a WAN (wide area network), a LAN, or any other type of network or combination of networks. In some examples, the network  120  and the LAN  132  are provided as a single network. 
     The block storage  170  may be implemented in a variety of ways. In one example, a VMAX array, Storage Center array, XtremIO array, or some other type of block-based array provides the block storage  170  (VMAX, Storage Center, and XtremIO are available from Dell EMC). In such arrangements, each of the physical computing machines  140  may connect to the block storage  170  directly, via a SAN (storage area network), or in some other manner. In other examples, the block storage  170  may be provided using cloud-based storage, such as Amazon Web Services (e.g., EC2 or EBS), Microsoft Azure, and Google Cloud, using VSAN (virtual storage area network), or using SDS, such as ScaleIO, which turns direct-attached storage into shared block storage. Using ScaleIO, the physical computing machines  140  may include direct-attached storage, which ScaleIO virtualizes and makes available for use across the NAS cluster  130 . In some examples, the NAS cluster  130  renders the block storage  170 , regardless of its source, as SDS, e.g., by abstracting APIs (application programming interfaces) for platform management, provisioning, and advanced data services. Different types of storage technology may be combined in any suitable way. For example, the block storage  170  may include a combination of XtremIO storage and cloud-based storage. 
     As further shown in  FIG. 1 , the physical computing machines  140  may be configured as either cluster manager nodes  140   a  or as NAS data nodes  140   b . In the example shown, which is not intended to be limiting, each physical computing machine  140  serves only one role, either as a cluster manager node or as a NAS data node, and there is only one cluster manager node for the entire NAS cluster  130 . As shown, physical computing machine  140 - 1  is configured as a cluster manager node and includes a cluster manager  170 . The cluster manager  160  includes a management database  162 , which contains information about the NAS cluster  130  and information about the various NAS data nodes. In an example, the cluster manager  160  acts as a single entry point for control and management of the NAS cluster  130 . 
     As further shown, physical computing machines  140 - 2  through  140 -M are configured as NAS data nodes  140   b . The NAS data nodes  140   b  host NAS servers  150 .  FIG. 1  shows several NAS servers  150  (A-F and X-Z), with NAS Server D shown in additional detail and intended to be representative of all NAS servers  150 . Each NAS server  150  includes a file system database (FSDB)  152 , a set of network servers  154  (e.g., one or more CIFS, SMB, and/or NFS servers), and a set of file systems  156  that belong to the NAS server  150 . The FSDB  152  provides information about each of the set of file systems  156 , and the network server(s)  154  enable network access to the set of file systems  156  by hosts  110 . 
     The set of file systems  156  may include production file systems as well as snapshots. In a particular example, each file system is backed by a respective LUN  180  in the block storage  170 , i.e., there is a one-to-one relationship between file systems and LUNs. In an example, each file system belongs to one and only one NAS server  150 . These are working assumptions but should not be regarded as limiting. A NAS data node may operate any number of NAS servers  150 , and each NAS server  150  may include any number of file systems. 
     NAS servers  150  are not generally themselves implemented as virtual machines or even virtualized userspace containers. Rather, NAS servers  150  are preferably lightweight structures, with many NAS servers  150  capable of operating within a single execution environment on a physical computing machine  140 . Owing to their lightweight nature, NAS servers  150  can be quickly moved from one physical computing machine to another with little or no disruption to hosts  110 . 
     Although the NAS cluster  130  appears to be deployed from a single location, this is merely an example. Alternatively, the NAS cluster  130  may be deployed across multiple locations. 
     In example operation, hosts  110  issue I/O requests  112  directed to particular file systems within the NAS cluster  130 . Network servers  154  operating within NAS data nodes  140   b  receive the I/O requests  112 , and the respective physical computing machines process the I/O requests  112  to effect reads and/or writes of specified data. Specified data may include particular files, directories, or portions thereof within specified file systems. 
     One should appreciate that the NAS data nodes  140   b  act as vehicles for moving data between hosts  110  and block storage  170  but do not persistently store the file systems themselves. Rather, block storage  170  provides persistent storage of the file systems of all of the NAS servers  150 , e.g., with data of each file system stored in a respective LUN  180 . 
     The pictured arrangement promotes mobility of NAS servers  150  among NAS data nodes  140   b . For example, the cluster manager  160  orchestrates provisioning, failover, and load balancing of NAS servers  150  across NAS data nodes in an efficient manner that avoids bottlenecks. By providing an FSDB  152  with each NAS server  150 , each NAS server  150  is realized as a highly self-contained structure, as it does not rely on access to any centralized database for most information about its contents. Movement of a NAS server  150  from a first NAS data node to a second NAS data node is predominantly a matter of disabling a network server  154  on the first NAS data node, starting a network server on the second NAS data node, accessing the FSDB  152  of the NAS server to identify the file systems that it contains, and connecting to the LUNs  180  in block storage  170  that provide backing store for those file systems. The self-contained nature of the NAS servers  150  also promotes scalability as it enables thousands of NAS servers to be managed by a single cluster manager  160 . 
       FIG. 2  shows an example implementation of a physical computing machine configured as a NAS cluster manager node  140   a . Physical computing machine  140   a  is intended to be representative of physical computing machine  140 - 1  in  FIG. 1 , as well as any additional cluster manager nodes. For example, some implementations may employ multiple cluster manager nodes for redundancy or locality. 
     Cluster manager node  140   a  includes one or more communication interfaces  210 , a set of processing units  212 , and memory  220 . The communication interfaces  210  include, for example, network interface adapters for converting electronic and/or optical signals received over the network  120  to electronic form for use by the cluster manager node  140   a . The set of processing units  212  includes one or more processing chips and/or assemblies. In a particular example, the set of processing units  212  includes numerous multi-core CPUs. The memory  220  includes both volatile memory (e.g., RAM), and non-volatile memory, such as one or more ROMs, disk drives, solid state drives, and the like. The set of processing units  212  and the memory  220  together form control circuitry, which is constructed and arranged to carry out various methods and functions as described herein. The memory  220  includes a variety of software constructs realized in the form of executable instructions. When the executable instructions are run by the set of processing units  212 , the set of processing units  212  is caused to carry out the operations of the software constructs. Although certain software constructs are specifically shown and described, it is understood that the memory  220  typically includes many other software constructs, which are not shown, such as various applications, processes, and daemons. 
     As further shown in  FIG. 2 , the memory  220  “includes,” i.e., realizes by execution of software instructions, an operating system (OS)  230 , which includes userspace  230   a  and kernel space  230   b . The cluster manager  160  ( FIG. 1 ) runs within userspace  230   a  and includes the following software constructs:
         Administrative Interface  242 . An interface for communicating with administrative program  114   a , which may be implemented stand-alone or within storage manager  172  ( FIG. 1 ). For example, administrative program  114   a  presents a graphical user interface (GUI) that enables administrators to query the NAS cluster  130 , establish settings, provision NAS servers  150 , create file systems, perform load balancing, take snapshots, start replication sessions, and/or perform other administrative activities.   Data Node Interface  244 . Interface to NAS data nodes  140   b  in the NAS cluster  130 . May use TCP/IP (transmission control protocol/Internet protocol) or some other suitable protocol for communicating over LAN  132 .   Management Database  162 . The above-described database for storing information about the NAS cluster  130  and information about the various NAS data nodes.   Cluster orchestration  246 . Manages procedures involving data services within and between NAS data nodes.   Block Storage Interface  250 . Control interface to block storage  170 . May include REST (representational state transfer) interface  252  and one or more adapters  254 . REST interface  252  provides a generalized control interface that applies across different makes and/or models of block storage  170 . Adapter(s)  254  are specific to particular makes and/or models, and map REST instructions to corresponding control instructions in a native control vocabulary of the block storage  170 . In some examples, adapter  254  is provided in storage manager  172  rather than in cluster manager  160 . For example, adapter  254  may be installed as a storage manager plug-in.       

     In an example, the cluster manager node  140   a  implements the cluster manager  160  as a user process. In a particular non-limiting example, the operating system  230  is Linux-based. Other operating systems may be used, however, such as Unix-based operating systems and Windows-based operating systems. Although the operating system  230  is shown as running directly on the cluster manager node  140   a  (on bare metal), it may alternatively be run within a virtual machine or within a “container,” i.e., a virtualized userspace process (e.g., a Docker container). 
       FIG. 3  shows an example implementation of a physical computing machine configured as a NAS data node  140   b . Physical computing machine  140   b  is intended to be representative of physical computing machines  140 - 2  through  140 -M in  FIG. 1 . 
     NAS data node  140   b  includes one or more communication interfaces  310 , a set of processing units  312 , and memory  320 , which may be configured similarly to the communication interfaces  210 , set of processing units  212 , and memory  220  of the cluster manager node  140   a  described above. In some examples, however, processors and memory on NAS data node  140   b  may be optimized for moving data and may thus include greater numbers of processing cores and/or larger amounts of memory. The set of processing units  312  and the memory  320  together form control circuitry, which is constructed and arranged to carry out various methods and functions as described herein. Also, the memory  320  includes a variety of software constructs realized in the form of executable instructions. When the executable instructions are run by the set of processing units  312 , the set of processing units  312  of the NAS data node  140   b  is caused to carry out the operations defined by the software constructs. Although  FIG. 3  specifically shows certain software constructs, it is understood that the memory  320  typically includes many other software constructs. 
     As further shown in  FIG. 3 , the memory  320  includes an operating system (OS)  330  (e.g., Linux, Unix, Windows, etc.), which includes userspace  330   a  and kernel space  330   b . A NAS data node manager  340  runs within userspace  330   a , e.g., as a userspace process, and includes the following software constructs:
         I/O Stack  342 . An execution path for processing I/O requests  112  arriving from hosts  110 . Converts read and/or write requests directed to particular files or directories in specified file systems to corresponding block-based requests suitable for submission to block storage  170 .   Local Orchestration  344 . Manages procedures involving data storage and services within NAS data node  140   b.      Cluster Node Interface  346 . A management/control interface to cluster manager  160 , e.g., via data node interface  244  in cluster manager node  140   a.      Local NAS Server(s)  150   a . NAS servers  150  hosted by this NAS data node  140   b . Each of NAS servers  150   a  has its own FSDB  152  for tracking its own file systems.       

       FIG. 3  further shows an example relationship between a file system of a NAS server  150   a  and a LUN that backs the file system. The illustrated arrangement is intended to be representative of file system deployments across the NAS cluster  130 . Here, a single file system FS-A is represented within the I/O stack  342 . In an example, the file system FS-A has a continuous address space  350 , which is denominated in blocks, for example, where a “block” is a smallest unit of storage that may be allocated by the file system. The I/O stack  342  maps reads and/or writes directed to FS-A to corresponding reads and/or writes of corresponding blocks within the address space  350 . The file system FS-A is itself laid out on a NAS volume  360  (NAS-Vol-A), which is constructed in userspace  330   a . NAS-Vol-A is itself laid out on a kernel-based block device  370  (Block-Dev-A), such as a Linux block device. Block-Dev-A itself is built upon a LUN  180 A provided from block storage  170 . 
     In an example, the cluster manager  160  directs activities to configure the illustrated arrangement, such as by provisioning LUN  180 A to NAS data node  140   b , such that the operating system  330  discovers LUN  180 A and expresses it as a block device  370  (e.g., a Linux block device), which resides in kernel space  330   b . The NAS data node manager  340  discovers Block-Dev-A and constructs NAS volume NAS-Vol-A upon Block-Dev-A (in Linux, developers may use libaio for this purpose). The NAS data node manager  340  may then format FS-A on NAS-Vol-A. In an example, there is a one-to-one relationship between each file system address in address space  350  and a corresponding address in each of NAS-Vol-A, Block-Dev-A, and LUN  180 A, such that reads and writes directed to a particular block address in address space  350  translate to reads and writes of a corresponding block in LUN  180 A. 
     Although  FIG. 3  shows an example arrangement for implementing a single file system FS-A, one should appreciate that the NAS data node manager  340  may support many file systems, which may number in the thousands, in a similar manner. Thus, for example, each file system available from the NAS data node  140   b  is laid out on an associated NAS volume  360  in userspace  330   a , which is built upon a block device  370  in kernel space  330   b , which is in turn built upon an LUN  180  in block storage  170 . 
     In an example, the NAS cluster  130  maintains uniqueness of identifiers of block devices that support file systems across the entire NAS cluster  130  (in Linux, developers may use udev may for this purpose). For example, the cluster manager  160  coordinates with each NAS data node  140   b  to ensure that each block device  370  supporting a file system has a unique ID (identifier) within the NAS cluster  130 . Moreover, the NAS cluster  130  ensures that such block device IDs supporting file systems do not change, even when the NAS servers  150  that contain the file systems are moved from one NAS data node  140   b  to another. Thus, for example, the unique ID of a block device  370  supporting a file system stays the same across the NAS cluster  130 , regardless of which node is realizing the block device  370 . 
       FIG. 4  shows another example arrangement for realizing a NAS data node  140   b . Certain features in common with the example of  FIG. 3  are omitted for the sake of clarity. The arrangement of  FIG. 4  differs from that of  FIG. 3  in that the operating system  330  in  FIG. 4  runs within a virtual machine  420 . The virtual machine  420  runs under a virtual machine server  410 . In an example, the virtual machine server  410  is vSphere ESX server, available from VMWare, Inc., of Palo Alto, Calif. (now part of Dell Corporation). The virtual machine  420  is a VMWare virtual machine. Other virtual machine technologies may be used, such as KVM (kernel-based virtual machine) and Microsoft Hyper-V. 
     As shown in  FIG. 4 , the virtual machine  420  imposes additional layers, which the NAS cluster  130  must manage when deploying file systems backed by LUNs  180  in block storage  170 . In this case, the cluster manager  160  directs block storage  170  to provision LUN  180 A to the virtual machine server  410 . The virtual machine server  410  creates a vdisk  480  (Vdisk-A) from the LUN  170 A and provisions the vdisk  480  to the virtual machine  420 . The operating system  330  (e.g., Linux) running within the virtual machine  420  discovers the vdisk  480  and creates a kernel-based block device  370 . As before, the NAS data node  340  discovers the block device  370 , builds a NAS volume  360  on the block device  370 , and formats out the file system upon the NAS volume  360 . The one-to-one address correspondence described above also applies to the vdisk  480 , as well as to the NAS volume  360 , block device  370 , and LUN  180 A. 
       FIG. 5  shows yet another example arrangement for realizing a NAS data node  140   b . Here, the NAS data node  340  runs within a container  510 , i.e., a virtualized userspace instance. The NAS data node  340  may run multiple containers, like the container  510 , with each container providing a userspace execution environment that is isolated from similar environments provided by other containers. Unlike virtual machines, containers do not virtualize the OS kernel. Rather, all containers share the same kernel. Examples of containers  510  include Docker containers, available from Docker, Inc. 
     When using virtual machines or containers, it may be desirable to run the cluster manager  160  and the NAS data node manager  340  together on the same physical computing machine  140 . For example, the cluster manager  160  may run in one virtual machine or container while the NAS data node manager  340  runs in another. Thus, it is not necessary for the cluster manager  160  to consume an entire physical computing machine  140  in the NAS cluster  130 . 
       FIG. 6  shows example features of a NAS server  150  in additional detail. Although a particular NAS server is shown, the illustrated structure is intended to be representative of NAS servers  150  in general. As shown, the NAS server  150  includes a root file system  610 , a config file system  620 , and any number of user file systems, which may include both production file systems and snapshots (others supported types of file systems may include migration targets). In the example shown, the NAS server  150  includes two user file systems. File system  620  is a production file system, and file system  640  is a snapshot. 
     The root file system  610  has a directory structure, which includes, for example, a root directory (slash), a “/Private Space” directory, and a “/Mountpoints” directory. In an example, the Private Space directory includes the above-described FSDB  152 . Thus, for example, the FSDB  152  is itself implemented within a file system of the NAS server  150 . In an example, the FSDB  152  tracks user file systems, such as file systems  630  and  640 , but does not track the root file system  610  or the config file system  620 . The Private Space directory may also include the following:
         NAS Server Name and UUID. The NAS server  150  has a name, which may be user-assigned or automatically assigned, and a UUID (universally unique identifier).   Dev-ID for Root FS. A unique identifier of a block device  370  that supports the root file system  610 . In an example, the root file system  610  is deployed within a NAS data node  340  using the same structure as described for FS-A in connection with  FIGS. 3-5 .   Dev-ID for Config FS. A unique identifier of a block device  370  that supports the config file system  620 . In an example, the config file system  620  is implemented within a NAS data node  340  using the same structure as described for FS-A in connection with  FIGS. 3-5 .
 
In some examples, the root file system  610  also stores redundant information, which the NAS cluster  130  may use to rebuild the management database  162 , e.g., in the event of a failure of the cluster manager  160 .
       

     The config file system  620  stores configuration information describing the NAS server  150 , such as a NAS server configuration file, a database of shares/exports, the Dev-ID for the Root FS (described above), and a secmap. 
     The Mountpoints directory in the root file system  610  exposes mount points on which other file systems may be mounted to join their namespaces. For example, the NAS data node manager  340  may mount the config file system  620  and each of the user file systems ( 630  and  640 ) on respective mount points in the Mountpoints directory to join their namespaces. The resulting namespace is specific to the NAS server  150  but is independent of the namespaces of other NAS servers (unless they are joined through other means). 
     In the arrangement shown, the FSDB  152  resides within the root file system  610  and thus moves wherever the root file system  610  moves. Thus, for example, when performing failover, load balancing, or other operations, a NAS data node  140   b  that takes over operation of a NAS server  150  can identify all of the NAS server&#39;s user file systems based only on receipt of the root file system  610 . 
       FIG. 7  shows example information stored in each FSDB  152 . For each user file system that belongs to a NAS server  150 , the FSDB  152  for that NAS server  150  stores the following information.
         File System Name. May be user-defined or automatically defined.   Export FSID. File system identifier (e.g., UUID or 32-bit value) used when file system is a replication or migration target.   Internal FSID. File system identifier (e.g., UUID) used to identify a file system within NAS cluster  130 .   File System State. Whether the file system is currently mounted or unmounted.   Dev-ID of File System. Identifier of kernel-based block device  370  (e.g., Linux block device) which supports the file system. Unique within NAS cluster  130  and invariant as NAS server  150  is moved from one physical computing machine  140  to another.   Mount Point Name and Options for File System. The mount point to which this file system is mounted in the Mountpoints directory of the root file system of this NAS server  150 , as well as mount options (e.g., read-write, read-only, etc.). For example, the mount point for production file system  630  in  FIG. 6  is shown as “/FS 1.”   Maximum Provisioned Capacity of File System. The maximum size to which the file system can grow. Specified, for example, when file system is created.   Nature of File System. Whether the file system is a production (primary) file system, a snapshot, or a migration target.
 
The elements of information listed in  FIG. 7  promote efficiency in the NAS cluster  130 . Some elements may be omitted and others that are not shown may be added. The listed elements are not intended to be exhaustive or to present strict requirements but are rather illustrative.
       

       FIG. 8  shows example information stored in the management database  162 . As indicated, the management database  162  organizes information both by tenant and by NAS server  150 . As is known, a “tenant” is an entity on whose behalf data are stored, such as a company, some other type of organization, or a user. The NAS cluster  130  may store the data of multiple tenants and enforce strict measures to keep different tenants&#39; data separate. For each tenant storing data in the NAS cluster  130 , the management database  162  stores the following:
         Tenant Name. A name of the tenant, such as “ACME Industries.”   Tenant UUID. A universally unique identifier of the tenant.   ID of each NAS Node Exclusively Owned. An identifier of each NAS data node  140   b  (or, equivalently, of each NAS data node manager  340 ) that the tenant exclusively owns. Exclusively owned NAS nodes are available for storing only the owning tenants&#39; data.   ID of each NAS Node Shared. An identifier of each NAS data node (or, equivalently, of each NAS data node manager  340 ) that the tenant does not exclusively own, but which the tenant may share with other tenants. A shared NAS node cannot be owned by any tenant.       

     In addition to this per-tenant information, the management database  162  also stores the following information for each NAS server  150 :
         Tenant UUID. A universally unique identifier of the tenant that owns the NAS server  150 .   NAS Node ID. An identifier of the NAS data node  140   b  on which the NAS server  150  is currently operating.   NAS Server Name. A name of the NAS server  150 . May be user-defined or automatically defined.   NAS Server UUID. A universally unique identifier of the NAS server  150 .   State. The state of the NAS server  150 , such as normal (operational), destination (the target of replication or migration), or offline.   Unique Dev-ID and LUN for Root FS. A unique identifier of a block device  370  that supports the root file system  610  (Dev-ID), and an identifier of the LUN in block storage  170  that backs that block device  370 . “LUN” in this case refers to the logical unit number of the LUN and hence is an identifier.   Unique Dev-ID and LUN for Config FS. A unique identifier of a block device  370  that supports the config file system  620  (Dev-ID), and an identifier of the LUN in block storage  170  that backs that block device  370 .   Unique Dev-ID and LUN for each User File System. For each user file system, a unique identifier of the block device  370  that supports that user file system (Dev-ID), and an identifier of the LUN in block storage  170  that backs that block device  370 .
 
The particular data elements described above are intended to be illustrative rather than limiting.
       

     One should appreciate that the illustrated example provides LUN information only in the management database  162  ( FIG. 8 ) but not in the FSDB  152  ( FIG. 7 ). In addition, only the FSDB  152  provides file system names and FSIDs. The illustrated distribution of information between the management database  162  and the FSDBs  152  is intended to reduce reliance on the cluster manager  160  when performing most data management tasks, while also providing the cluster manager  160  with the information it needs to support its role in managing the NAS cluster  130 . 
       FIGS. 9-13  show example sequences for performing various activities in the NAS cluster  130 . Each of these figures identifies nodes in the NAS cluster  130  according to their roles as cluster manager  160  and NAS data nodes (labeled A-M), rather than by physical computing machines  140 . It should be noted that activities ascribed below to the NAS data nodes A-M may be performed by the NAS data node managers  340  running on the respective NAS data nodes. 
       FIG. 9  shows an example sequence for creating a NAS server  910  in the NAS cluster  130 . The encircled numerals depict the following example sequence of operations:
         1. Receive, by cluster manager  160 , a request from administrative program  114   a  to create NAS server  910  on NAS data node B. The instruction may be issued by an administrator or other user and may include a name of the NAS server  910 .   2. Allocate, by cluster manager  160 , UUID of NAS server  910 .   3. Allocate, by cluster manager  160 , two new unique device IDs for block devices  370  that support the root file system  610  and the config file system  620  of the NAS server  910 ; direct block storage  170  to allocate two LUNs  180 , one for the root file system  610  and another for the config file system  620 ; bind together the unique device ID for the root file system with the LUN for the root file system; bind together the unique device ID for the config file system with the LUN for the config file system.   4. Cluster manager  160  calls into NAS data node B and provides NAS server name, UUID, and device IDs of block devices  370  that support root file system  610  and config file system  620 .   5. NAS data node B formats root file system and config file system over respective block devices  370 .   6. NAS data node B mounts root file system  610  as “/” and config file system  620  as “/ConfigFS” (see  FIG. 6 ).   7. NAS data node B initializes config file system  620  (e.g., Shares/Exports DB and NAS Server Config File); initializes FSDB  152  in root file system.   8. NAS data node B records name and UUID of NAS server  910  in root file system  610 ; records device ID of block device  370  supporting root file system  610  and device ID block device  370  supporting config file system  620 ; records in FSDB  152  device IDs of block devices  370  supporting user file systems, if any; records redundant information stored in management database  162 .   9. Cluster manager  160  records information about NAS server  910  in management database  162  (e.g., in per-NAS-server information; see  FIG. 8 ).   10. Cluster manager  160  acknowledges request received in step 1.
 
As shown, the actions performed to provision the NAS server are kept mostly within the NAS data node B, with limited interactions with block storage  170 .
       

       FIG. 10  shows an example sequence for creating a file system in the NAS cluster  130 . The encircled numerals in  FIG. 10  depict the following example sequence of operations:
         1. Receive, by cluster manager  160 , a request from administrative program  114   a  to create a file system FS-X on NAS data node B. The instruction may be issued by an administrator or other user and may include a name of the NAS server  910 .   2. Allocate, by cluster manager  160 , a new device ID for a block device  370  that supports the file system FS-X; direct block storage  170  to allocate a LUN  180  for FS-X; bind together the unique device ID with the LUN for FS-X.   3. Cluster manager  160  calls into NAS data node B and provides NAS server UUID, device ID of block device  370  that supports FS-X, as well as Maximum Provisioned Capacity of FS-X, Mount Point Name and Options for FS-X, and the Nature of FS-X, e.g., production, snapshot, or migration.   4. NAS data node B allocates UUID for FS-X. If nature of file system is “Production,” the same UUID is used for both Export FSID and Internal FSID.   5. NAS data node B formats the new file system on the block device  370  indicated by the received device ID.   6. NAS data node B creates a mount point on the root file system  610  of the NAS server  910 .   7. NAS data node B records information about FS-X in the FSDB  152  of NAS server  910 .   8. NAS data node B mounts FS-X.   9. Cluster manager  160  updates management database  162  for NAS server  910  with newly allocated device ID of block device  370  and LUN for FS-X.   10. Cluster manager  160  acknowledges request received in step 1.
 
Here, as well, the actions performed are mostly kept within the NAS data node B, with limited interactions with block storage  170 .
       

       FIG. 11  shows an example sequence for conducting failover of a NAS data node in the NAS cluster  130 . The encircled numerals in  FIG. 11  depict the following example sequence of operations:
         1. Receive, by cluster manager  160 , a notification from block storage  170  that NAS data node B has failed. Alternatively, the cluster manager  160  monitors an operational state of each of the NAS data nodes and detects on its own that NAS data node B has failed.   2. Cluster manager  160  accesses management database  162  and changes NAS Node ID ( FIG. 8 ) for NAS server  910  to NAS data node A.   3. Cluster manager  160  calls into NAS data node A and provides name of NAS server  910 , UUID of NAS server  910 , and device IDs of block devices  370  that support root file system  610  and config file system  620  of NAS server  910 . In some examples, the cluster manager  160  may reassign the LUNs  180  that back the root file system  610 , config file system  620 , and each of the user file systems of NAS server  910  from NAS data node B to NAS data node A.   4. NAS data node A brings up NAS server  910 .   5. NAS data node A indicates that NAS server  910  is operational.   6. Cluster manager  160  acknowledges completion of failover.       

     In some examples, the cluster manager  160  monitors not only operational state, but also spare capacity of each of the NAS data nodes. The cluster manager  160  then bases its determination of failover node at least in part on spare capacity. For example, the cluster manager  160  may have determined that NAS data node A was not very busy, or was less busy than other nodes, such that it was a good candidate for receiving NAS server  910 . 
     In some examples, the failing NAS data node may support numerous NAS servers  150 , which become stranded by the failure of that NAS data node. In such examples, the cluster manager  160  may transfer operation of the stranded NAS data nodes based at least in part on spare capacity of still-functioning NAS data nodes, performing load balancing in the process. For example, the cluster manager  160  may distribute the stranded NAS servers across multiple NAS data nodes in the cluster  130 , so as to balance workload across NAS data nodes and to avoid overloading any one NAS data node. 
     Some virtual machine platforms support their own mechanisms for failover. For example, VMWare uses vMotion to support movement of virtual machines from one physical computer to another. In examples where NAS data nodes operate within virtual machines, such as in  FIG. 4 , virtual machine failover may be disabled for NAS data nodes, such that the cluster manager  160  remains in control of the placement of NAS servers  150  in the NAS cluster  130 . 
     In some examples, virtual machine failover may be preserved for the cluster manager  160  itself. For instance, in cases where the cluster manager  160  runs in a virtual machine and a failure occurs in that virtual machine or in the associated physical computing machine, vMotion or similar procedures may restore operation of the cluster manager  160  from a different physical computing machine. 
       FIG. 12  shows an example sequence for performing load balancing in the NAS cluster  130 . The mechanics for load balancing are similar to those for performing failover, except that there is no failing node. In an example, the sequence proceeds as follows:
         1. Receive, by cluster manager  160 , a notification from block storage  170  that NAS data node B is overloaded. Alternatively, in some examples, the cluster manager  160  itself monitors the spare capacity of NAS data nodes and detects on its own that NAS data node B is overloaded, e.g., by determining that the spare capacity has fallen below a predetermined threshold.   2. Cluster manager  160  calls in to NAS data node B and directs it bring down one or more of its NAS servers. In this example, the cluster manager  160  directs NAS node B to bring down NAS servers  1230  and  1240 , but not NAS server  1220 .   3. NAS data node B brings down NAS server  1220  and NAS server  1230 .   4. NAS data node B acknowledges to cluster manager  160  that NAS servers  1220  and  1230  are down.   5. Cluster manager  160  accesses management database  162 , changes NAS Node ID ( FIG. 8 ) for NAS server  1230  to NAS data node C, and changes NAS Node ID for NAS server  1240  to NAS data node M. The cluster manager  160  may previously have determined that NAS data nodes C and M have spare capacity and are good candidates for receiving NAS servers  1230  and  1240 .   6. Cluster manager  160  calls into NAS data node C and provides name of NAS server  1230 , UUID of NAS server  1230 , and device IDs of block devices  370  that support root file system  610  and config file system  620  of NAS server  1230 . In some examples, cluster manager  160  may reassign the LUNs  180  that back the root file system  610 , config file system  620 , and each of the user file systems of NAS server  1230  from NAS data node B to NAS data node C.   7. NAS data node C brings up NAS server  1230 .   8. NAS data node C indicates that NAS server  1230  is operational.   9. Cluster manager  160  calls into NAS data node M and provides name of NAS server  1240 , UUID of NAS server  1240 , and device IDs of block devices  370  that support root file system  610  and config file system  620  of NAS server  1240 . In some examples, the cluster manager may reassign the LUNs  180  that back the root file system  610 , config file system  620 , and each of the user file systems of NAS server  1240  from NAS data node B to NAS data node M.   10. NAS data node M brings up NAS server  1240 .   11. NAS data node M indicates that NAS server  1240  is operational.   12. Cluster manager  160  acknowledges completion of load balancing.
 
One should appreciate that the order of activities above can be varied. For example, movement of NAS server  1230  may be performed completely before initiating movement of NAS server  1240 . Alternatively, the acts for moving NAS servers  1230  and  1240  may be performed in parallel or interleaved in any suitable manner.
       

       FIG. 13  shows an example sequence for creating a snapshot FS-Y (Snap) of a file system FS-Y in the NAS cluster  130 . As will be apparent, the cluster manager  160  directs the creation of the snapshot and the block storage  170  performs the underlying snapshot activities. An example sequence proceeds as follows:
         1. Receive, by cluster manager  160 , a request to create a snapshot of FS-Y in NAS server  910 .   2. Cluster manager  160  queries NAS server  910  to obtain, from its FSDB, device ID of block device  370  that supports FS-Y. This device ID is referred to herein as “DEV-ID(Y).”   3. Cluster manager  160  accesses management database  162  and identifies the LUN  170  “LUN(Y)” associated with DEV-ID(Y); cluster manager  160  calls into block storage  170  and directs block storage  170  to create a snapshot of the LUN(Y); block storage  170  creates a new LUN “LUN(YS)” as a snapshot of LUN(Y); block storage  170  also creates a new device ID “DEV-ID(YS)” for a block device  370  that will support LUN(YS); Cluster manager  160  returns LUN(YS) identifier and DEV-ID(YS) to the cluster manager  160 .   4. Cluster manager  160  calls into NAS data node B and provides UUID of NAS server  910 , DEV-ID(YS), mount point, and designation as “Snapshot.”   5. NAS data node B allocates new FSID for the new snapshot FS-Y (Snap). For snapshot purposes, NAS data node B applies the same new FSID for both Export FSID and Internal FSID.   6. NAS data node B creates new mount point on the root file system  610  of NAS server  910 .   7. NAS data node B records received information about the new file system (the snapshot) in the FSDB  152  of NAS server  910 .   8. NAS data node B mounts the new file system (the snapshot).   9. NAS data node B acknowledges success; cluster manager  160  updates management database  162  for NAS server  910  with newly created DEV-ID(YS) and LUN(YS).   10. Cluster manager  160  acknowledges completion of snapshot request.       

       FIGS. 14-16  show example methods  1400 ,  1500 , and  1600  that may be carried out in connection with the environment  100 . The methods  1400 ,  1500 , and  1600  are typically performed, for example, by the software constructs described in connection with  FIGS. 1-3 , which reside in the memory  220  and  320  of the respective physical computing machines  140   a  and  140   b  and are run by the respective sets of processing units  212  and  312 . The various acts of methods  1400 ,  1500 , and  1600  may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in orders different from those illustrated, which may include performing some acts simultaneously. 
       FIG. 14  shows an example method  1400  for changing the name of a file system and demonstrates an example distribution of information between the cluster manager  160  and the NAS data nodes. 
     At  1410 , the cluster manager  160  receives a request, e.g., from administrative program  114   a , to change the name of an identified file system from a first name, such as “myFS” to a second name, such as “yourFS.” 
     At  1420 , the cluster manager  160  identifies the NAS data node in the NAS cluster  130  that operates the NAS server  150  which contains the identified file system. For example, the cluster manager  160  may broadcast a request that specifies the name myFS to all NAS data nodes in the NAS cluster  130 . Each NAS data node may then query its own FSDBs  152  (e.g., the FSDBs for all NAS server  150  that it hosts). The NAS data node that finds myFS in one of its FSDBs responds to the request and identifies itself to the cluster manager  162 . 
     At  1430 , the cluster manager  160  directs the identified NAS data node to change the name of the file system from myFS to yourFS in the FSDB  152  of the NAS server that contains the identified file system. In an example, no changes are made in the management database  162 , as this database does not track file system names. 
       FIG. 15  shows an example method  1500  for performing replication in the NAS cluster  130 . At  1510 , the cluster manager  160  receives a request from administrative program  114   a  to replicate an identified NAS server  150 . One should appreciate that the request is to replicate a NAS server, rather than any individual file systems. Thus, replication is requested here at per-NAS-server granularity. 
     At  1520 , in response to the request to replicate the NAS server, the cluster manager  160  identifies each file system listed in the FSDB  152  for that NAS server  150  and proceeds to initiate a replication session for each identified file system. Replication activities then proceed together for all identified file systems. The underlying replication transport may be synchronous, as in continuous replication, and/or asynchronous, as in snapshot-shipping replication. The cluster manager  160  orchestrates replication activities. The replication transport may be operated by the NAS data nodes, by the block storage  170 , or by both acting together. 
       FIG. 16  shows an example method  1600  for managing data storage and provides a summary of certain activities and features described above. 
     At  1610 , multiple physical computing machines  140  operate in a NAS (network attached storage) cluster  130 . The physical computing machines  140  are interconnected by a computer network  132  and have access to block storage  170 . 
     At  1620 , a NAS server  150  operates from a first physical computing machine (e.g.,  140 - 3 ) in the NAS cluster  130 . The NAS server  150  includes a dedicated FSDB (file system database)  152  that identifies a set of file systems  156  that belong to the NAS server  150 . The set of file systems  156  is backed by a set of LUNs (Logical UNits)  180  hosted by the block storage  170 . 
     At  1630 , in response to a second physical computing machine (e.g.,  140 - 2 ) in the NAS cluster receiving a request to take over operation of the NAS server  150 , the second physical computing machine  140 - 2  accesses the FSDB  152  of the NAS server  150  to identify each of the set of file systems  156  and the second physical computing machine  140 - 2  provides host access to each of the set of file systems  156  identified in the FSDB  152 . Such host access may include, for example, allowing hosts  110  to mount any of the set of file system  156  and to issue I/O requests  112  to such file systems for effecting reads and writes. 
     An improved technique has been described for managing data storage, which provides multiple physical computing machines  140  and block storage  170  arranged in a NAS cluster  130 . The physical computing machines  140  run NAS servers  150 , with each NAS server  150  including an FSDB  152  that identifies a set of file systems  156  that belong to the NAS server  150 . The FSDB  152  provides a local repository of information about contents of the NAS server  150 , which enables the NAS server  150  to carry information about its own contents with it as it moves from one physical computing machine  140  to another. The file systems identified by the FSDB  152  may include both production file systems and snapshots, such that snapshots as well as production objects follow a NAS server as it moves from one physical computing machine to another. The particular distribution of information within the NAS cluster  130  reduces reliance on centralized data and enables the NAS cluster  130  to scale to very large sizes while avoiding performance bottlenecks. 
     Section II: Enabling Granular Storage Provisioning and Snapshots in NAS Clusters. 
     This section describes an improved technique for creating snapshots in a NAS (network attached storage) cluster. The technique includes implementing a file system built upon a virtual disk realized in a virtualization platform, the virtual disk itself built upon a first LUN (Logical UNit) in block storage. In response to a request to take a snapshot of the file system, the NAS cluster bypasses the virtualization platform and directs a request to a block storage manager to take a snapshot of the first LUN, thereby creating a second LUN. The NAS cluster records a relationship between the first LUN supporting the file system and the second LUN supporting the snapshot, but the virtualization platform treats the second LUN as an independent object with no known snapshot relationship to any other object. 
     This section further describes an improved technique for supporting storage provisioning in a NAS (network attached storage) cluster. The technique includes implementing a file system built upon a virtual disk realized in a virtualization platform, the virtual disk itself built upon a first LUN (Logical UNit) in block storage. In response to a request to provision a second file system, the NAS cluster bypasses the virtualization platform and directs a request to a block storage manager to provision a second LUN, which is independent of the first LUN. The NAS cluster records a relationship between the second file system and the second LUN. 
     Embodiments described in this section may be realized in the environment and in the example NAS cluster as presented in Section I. However, embodiments presented in this section are not limited to the environment of Section I or to the particular NAS cluster as described. Rather, embodiments may be used in other environments, in other NAS clusters, and in computerized technology that does not require a NAS cluster. Further, as used herein, the term “NAS cluster” describes an electronic system that includes multiple data nodes having access to shared block storage and configured to service file-based requests for data over a network. A “NAS data node” or “data node” as used herein is a node that processes I/O requests from host devices for effecting reads and/or writes of data persisted in the block storage. Data nodes may be realized on physical computing machines or in virtual machines or containers that run on physical computing machines. 
       FIG. 17  shows portions of the environment  100  in additional detail and highlights certain features of the improved technique. Here, physical computing machine  140 -X (e.g., one of physical computing machines  140 , as shown in  FIG. 1 ) runs a virtualization platform  1710 , such as ESX, KVM, Docker, etc., in which a virtual machine (“VM”) or container  1720  is operated. A data node manager  340  runs within the VM/container  1720 , e.g., within an instance of Linux or some other operating system. Thus, the physical computing machine  140 -X is configured to operate as a data node  1702  within the NAS cluster  130 . The data node  1702  may run any number of NAS servers  150 , with a NAS server NS-1 particularly shown. 
     NS-1 includes file system FS-1, and may include other file systems, as well. In the manner shown, and consistent with the arrangement described above in connection with  FIG. 4 , FS-1 is backed by a virtual disk, vdisk-1, which is itself backed by a LUN  180 F in block storage  170 . 
     In example operation, administrative program  114   a  issues a request  1750  to generate a snapshot of FS-1. The request may include a name or other identifier of FS-1. The cluster manager  160  receives the request  1750  and resolves the name or other identifier to a corresponding LUN in block storage  170 . For example, the cluster manager  160  communicates with data node  1702  to access the FSDB  152  thereon and to obtain the unique Dev-ID (device identifier) associated with FS-1. The cluster manager  160  may then access the management database  162  to obtain the LUN associated with the retrieved Dev-ID. Although the request  1750  is shown as originating from the administrative program  114   a , the request  1750  may alternatively originate from within any NAS data node (e.g., within the node on which the file system to be snapped is run, or within some data other node), from the cluster manager  160 , or from some external entity. 
     The cluster manager  160  then bypasses the virtualization platform  1710  and issues a snap command  1760  to the storage manager  172 , specifying the LUN that supports FS-1. In response, the storage manager  172  directs the block storage  170  to generate a snapshot of LUN  180 F (the LUN backing FS-1) to create LUN  180 S. 
     One should appreciate that the block storage  170  requires no information about how the NAS cluster  130  uses the LUN  180 F or its snapshot  180 S. While the block storage  170  may track the fact that LUN  180 S is a snapshot of LUN  180 F, the block storage  170  is not required to have any information that associates LUN  180 F with file system FS-1 or that associates LUN  180 S with a snapshot of FS-1. Rather, the NAS cluster  130  tracks information about FS-1 and its snapshot, e.g., by making appropriate updates to the FSDB  152  and to the management database  162 . 
     One should further appreciate that the virtualization platform  1710  may have no information that a snapshot has been created. As the snapshot was not taken in the usual manner, i.e., through the virtualization platform  1710 , the virtualization platform  1710  may have no knowledge that the snapshot even exists. 
     Once the block storage  170  has created LUN  180 S (the snapshot), the cluster manager  160  may proceed to coordinate operations to enable the NAS cluster  130  to express the LUN  180 S in its intended form as a snapshot of FS-1. For example, the cluster manager  160  directs the storage manager  172  to assign LUN  180 S to the virtualization platform  1710 , which proceeds to render LUN  180 S as a virtual disk, vdisk-2. The virtualization platform  1710  then assigns vdisk-2 to the VM/container  1720 , which enables the data node  1702  to access vdisk-2 for purposes of realizing the snapshot, SN-1. Further details about procedures for creating snapshots may be found in the description accompanying  FIG. 13  above. 
     Similar operations may be performed for provisioning a file system. For example, instead of providing a request  1750  to create a snapshot, the administrative program  114   a  may instead provide a request to create a new file system. In response, the cluster manager  160  again bypasses the virtualization platform  1710  and issues a command to storage manager  172  to create a new LUN. Block storage  170  responds by creating the new LUN, which the cluster manager  160  may make available to the virtualization environment  1710  in a manner similar to that described for snapshots. Further details about procedures for provisioning a file system may be found in the description accompanying  FIG. 10  above. 
       FIG. 18  shows an example arrangement of storage structures in the NAS data node  1702 . Here, file system FS-1 is supported by a local volume  360   a  (NAS-Vol-1) running in userspace  330   a . The local volume  360   a  is created over a block device  370   a  (Block-Dev-1), which in turn is deployed over a virtual disk  480   a  (vdisk-1). Vdisk-1 is deployed over LUN  180 F. The arrangement of storage structures in  FIG. 18  is thus similar to those described in connection with  FIG. 4 . 
     Here, however, NAS server NS-1 also includes snapshot SN-1. To render LUN  180 S as a usable snapshot, the block storage  170  assigns LUN  180 S to the virtualization platform  1710 , which expresses LUN  180 S as vdisk-2. In a virtual machine scenario, vdisk-2 may be provided alongside vdisk-1 in a virtual machine file system, or VMFS  1810 . The virtualization platform  1710  (e.g., ESX) may provision vdisk-2 using raw device mapping, e.g., using RDM-P (physical) or RDM-V (virtual). Alternatively, no VMFS may be used, and the virtualization platform  1710  may provision vdisk-2 as a VVOL (virtual volume). 
     Once it has provisioned vdisk-2, and assuming a virtual machine implementation, the virtualization platform  1710  assigns vdisk-2 to the virtual machine  1720 . Linux, or some other operating system  330 , discovers vdisk-2 (e.g., by scanning for devices) and expresses vdisk-2 as a kernel space block device  370   b  (i.e., Block-Dev-2). The NAS data node manager  340  then builds local volume  360   b  over block device  370   b , and proceeds to deploy the snapshot SN-1 over the local volume  360   b . These acts are similar to those described in connection with  FIGS. 3 and 4 . 
     In some examples, the block storage  170  creates the LUN  180 S as a read/write object. The NAS data node  1702  may then mount SN-1 read/write. This read/write capability enables the NAS data node  1702  to replay transactions in any embedded transaction log in the snapshot, i.e., to bring the snapshot into an application-consistent state. 
     One should appreciate that the structure of snapshot SN-1 may be similar to that of FS-1. Further, one should appreciate that similar acts may be taken when creating a new file system (rather than taking a snapshot), i.e., in terms of provisioning a vdisk, expressing a block device, creating a local volume, and laying out the file system on the local volume. 
       FIG. 19  shows and example arrangement for moving a NAS server between virtual machines, e.g., as part of failover, load balancing, or for any reason. Such movement of NAS servers would not be possible or practical in conventional situations where a vdisk having snapshots is assigned to a virtual machine. 
     Here, administrative program  114   a  may issue a move request  1950  to move NAS server NS-1 from data node  1702  to data node  1902 , i.e., to a data node running on physical computing machine  140 -M. Alternatively, the move request  1950  may be issued by the cluster manager  160  or from some other entity. 
     In response to the move request  1950 , the cluster manager  160  directs the storage manager  172  to unassign any LUNs backing the file systems of NS-1 from the virtualization platform  1710  running on NAS data node  1702 , and to reassign any such LUNs to the virtualization platform  1710 -M running on NAS data node  1902 . Here, the LUNs of NS-1 include LUN  180 F and LUN  180 S, which back FS-1 and SN-1, respectively. Prior to unassigning the LUNs, in some examples (and assuming the NAS data node  1702  is still running and reachable), the cluster manager  160  directs the NAS data node  1702  to shut down NS-1 and directs the virtualization platform  1710  to detach all vdisks from the VM/container  1720 . Once the block storage  170  has reassigned the LUNs  180 F and  180 S, the virtualization platform  1710 -M expresses the LUNs  180 F and  180 S as new virtual disks, i.e., as vdisk-3 and vdisk-4. A NAS data node manager running on data node  1902  then realizes the FS-1 and SN-1 in a manner similar to that described in connection with  FIG. 18 . The NAS data node  1902  may then operate FS-1 and/or SN-1, as well as any other file systems belonging to NS-1, e.g., by responding to I/O requests  112  directed to the objects to effect reads and writes. 
       FIG. 20  shows an example sequence  2000  of activities for issuing snap command  1760 . The sequence  2000  may be carried out, for example, in the NAS cluster  130 , and involves participation by the administrative program  114   a , cluster manager  160 , NAS data node  1702 , and storage manager  172 . 
     At  2010 , the administrative program  114   s  sends a request  1750  to the cluster manager  160  to create a snapshot of file system FS-1. For example, an administrator may operate the program  114   a  and issue the request  1750  explicitly. Alternatively, the request  1750  may originate from within the NAS cluster  130 . The request  1750  includes a name or other identifier of the file system (FS-1) to be snapped. 
     At  2020 , the cluster manager  160  receives the request  1750  and proceeds to send a request to data node  1702  to get the device ID (Dev-ID) of FS-1. 
     At  2030 , the data node  1702  performs a look-up in the FSDB  152  of the file system name or other identifier received from the cluster manager  160 . The FSDB  152  for NS-1 stores, for each user file system in NS-1, the following information (see also  FIG. 7 ):
         File System Name.   Export FSID.   Internal FSID.   File System State.   Dev-ID of File System.   Mount Point Name and Options for File System.   Maximum Provisioned Capacity of File System.   Nature of File System.
 
The NAS data node  1702  locates the file system in the FSDB  152  having the provided File System Name or other identifier, such as Internal FSID (e.g., “FS-1”), and obtains the associated device ID (“Dev-ID of File System”) for the located file system. Recall that the NAS cluster  130  maintains uniqueness of all Dev-IDs and keeps Dev-IDs associated with for particular file systems constant. Thus, the Dev-ID for a file system is the same regardless of the data node on which the file system is run. At  2040 , the NAS data node  1702  returns the located Dev-ID for FS-1 to the cluster manager  160 .
       

     At  2050 , the cluster manager  160  performs a look-up in the management database  162  for the LUN associated with the Dev-ID it received at  2040 . The management database  162  stores the following information for NS-1: (see also  FIG. 8 ):
         Tenant UUID.   NAS Node ID.   NAS Server Name.   NAS Server UUID.   State.   Unique Dev-ID and LUN for Root FS.   Unique Dev-ID and LUN for Config FS.   Unique Dev-ID and LUN for each User File System.       

     The cluster manager  160  identifies a matching Dev-ID and the associated LUN in one of the fields for “Unique Dev-ID and LUN for each User File System.” The LUN identified from the management database  162  is thus the LUN associated with the received dev-ID, which is LUN that backs FS-1 in the block storage  170 , i.e., LUN  180 F. 
     At  2060 , the cluster manager  160  issues the snap command  1760 , specifying the matching LUN  180 F. Operation then proceeds as indicated above. 
     From the foregoing, it is evident that the FSDB  152  and the management database  162  store information about data objects backed by LUNs  180  in the block storage. The databases  152  and  162  thus track information about file systems and snaps, including relationships among them. For example, the FSDB  152  may store, among other things, the following information for FS-1: 
                                 TABLE 1                          File System Name:   FS-1           Export FSID   UUID assigned to FS-1           Internal FSID:   UUID assigned to FS-1           File System State:   Mounted           Dev-ID for File System   Unique Dev-ID of FS-1           Mount Point Name and Options   FS1; R/W           for File System               Max Provisioned Capacity of    20 TB           File System               Nature of File System   Production                        
The FSDB  152  may also store, among other things, the following information for SN-1:
 
                                 TABLE 2                          File System Name:   SN-1           Export FSID   UUID assigned to SN-1           Internal FSID:   UUID assigned to SN-1           File System State:   Unmounted           Dev-ID for File System   Unique Dev-ID of SN-1           Mount Point Name and Options   SN1; R/W           for File System               Max Provisioned Capacity of    20 TB           File System               Nature of File System   Snapshot                        
The FSDB  152  thus identifies objects by name and FSID and indicates whether the devices are primary objects or snapshots. Meanwhile, the management database  162  may store, among other things, the following information:
 
                                 TABLE 3                          Unique Dev-ID of File System   Unique Dev-ID of FS-1           Associated LUN of File System   LUN of FS-1                        
and
 
                                 TABLE 4                          Unique Dev-ID of File System   Unique Dev-ID of SN-1           Associated LUN of File System   LUN of SN-1                        
Together, the FSID  152  and the management database  162  provide information about file systems and snapshots, as well as the LUNs in block storage  170  that back them. The databases thus make it possible to avoid involvement of the virtualization platform  1710  in tracking file systems and snapshots, as the databases do that instead, thus enabling the techniques as taught herein of bypassing the virtualization platform.
 
     One should appreciate that the FSDB  152  and/or management database  162  may include additional information for tracking file systems and snapshots. For example, the FSDB  152  may further include a “Version Set” field for tracking file systems that are related to one another via snapping. For example, each file system and its respective snaps, including snaps of those snaps, could be assigned to a single version set, whereas file systems unrelated by snapping would be assigned to different version sets. The FSDB  152  could further store additional content that tracks the exact chain of snapping, such as generation counts, parent objects, child objects, and so forth. Such version set information would be considered to be part of the FSDB  152  even if it were placed in a different location in a NAS server  150  from the location of the FSDB  152  (i.e., in the root file system, as described above). 
       FIG. 21  shows an example method  2100  for managing data in a NAS cluster. The method  2100  may be performed, for example, by the software constructs described in connection with  FIGS. 2-5 , which reside in the memories  220  and  320  and are run by the sets of processing units  212  and  312 . The recited acts of method  2200  may be performed in any suitable order, which may include performing some acts simultaneously. 
     At  2110 , multiple NAS data nodes are operated in the NAS cluster  130 . Each of the NAS data nodes (e.g.,  1702 ,  1902 ) has access to block storage  170 , and the block storage  170  is controlled by a storage manager  172 . 
     At  2120 , a file system FS-1 is provided in a NAS data node  1702  in the NAS cluster  130 . The NAS data node  1702  runs within a virtualization platform  1710  on a physical computing machine  140 -X. The file system FS-1 is built upon a virtual disk vdisk-1 from the virtualization platform  1710 . The virtual disk vdisk-1 is derived from a first LUN (Logical UNit)  180 F assigned to the virtualization platform  1710  from the block storage  170 . 
     At  2130 , in response to receiving a request  1750  to create a snapshot SN-1 of the file system FS-1, the method  2100  further includes bypassing the virtualization platform  1710  and issuing a snap command  1760  to the storage manager  172 , the block storage  170  then creating a second LUN  180 S as a snapshot of the first LUN  180 F. 
     At  2140 , a snapshot relationship is recorded between the first LUN  180 F and the second LUN  180 F in the NAS cluster  130 . The snapshot SN-1 of the file system FS-1 is thereby created without involvement of the virtualization platform  1710 . 
     An improved technique has been described for enabling snapshots and provisioning in a NAS (network attached storage) cluster  130 . The technique includes implementing a file system FS-1 built upon a virtual disk vdisk-1 realized in a virtualization platform  1710 . The virtual disk vdisk-1 itself built upon a LUN (Logical UNit)  180 F in block storage  170 . In response to a request to take a snapshot of the file system or to provision a new file system, the NAS cluster  130  bypasses the virtualization platform  1710  and directs a request to a block storage manager  172 , either to take a snapshot of the LUN (in the case of snapshot) or to create a new LUN (in the case of provisioning). The NAS cluster  130  records a relationships among LUNs, file systems, and snaps, but the virtualization platform treats the LUNs as independent objects. 
     Having described certain embodiments, numerous alternative embodiments or variations can be made. For example, although embodiments have been described with a primary focus on virtual machines, the same principles may also be applied on container-based virtualization platforms, such as Docker. 
     Further, although embodiments have been described wherein a single cluster manager  160  runs a single management database  162 , the cluster manager  160  and management database  162  need not be implemented on a single node of the cluster  130 , but may rather be distributed across multiple nodes. 
     Further, although features are shown and described with reference to particular embodiments hereof, such features may be included and hereby are included in any of the disclosed embodiments and their variants. Thus, it is understood that features disclosed in connection with any embodiment may be included with any other embodiment. 
     Further still, the improvement or portions thereof may be embodied as a computer program product including one or more non-transient, computer-readable storage media, such as a magnetic disk, magnetic tape, compact disk, DVD, optical disk, flash drive, solid state drive, SD (Secure Digital) chip or device, Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), and/or the like (shown by way of example as medium  1450  in  FIGS. 14-16, and 21 ). Any number of computer-readable media may be used. The media may be encoded with instructions which, when executed on one or more computers or other processors, perform the process or processes described herein. Such media may be considered articles of manufacture or machines, and may be transportable from one machine to another. 
     As used throughout this document, the words “comprising,” “including,” “containing,” and “having” are intended to set forth certain items, steps, elements, or aspects of something in an open-ended fashion. Also, as used herein and unless a specific statement is made to the contrary, the word “set” means one or more of something. This is the case regardless of whether the phrase “set of” is followed by a singular or plural object and regardless of whether it is conjugated with a singular or plural verb. Further, although ordinal expressions, such as “first,” “second,” “third,” and so on, may be used as adjectives herein, such ordinal expressions are used for identification purposes and, unless specifically indicated, are not intended to imply any ordering or sequence. Thus, for example, a “second” event may take place before or after a “first event,” or even if no first event ever occurs. In addition, an identification herein of a particular element, feature, or act as being a “first” such element, feature, or act should not be construed as requiring that there must also be a “second” or other such element, feature or act. Rather, the “first” item may be the only one. Although certain embodiments are disclosed herein, it is understood that these are provided by way of example only and that the invention is not limited to these particular embodiments. 
     Those skilled in the art will therefore understand that various changes in form and detail may be made to the embodiments disclosed herein without departing from the scope of the invention.