This page provides an overview of the features and functionality of Google Cloud NetApp Volumes.
Network-attached storage
NetApp Volumes shares file systems, or volumes, to network-attached storage (NAS) clients. NAS clients are usually virtual machines (VMs) that run on Windows or Linux operating systems using the industry-standard Network File System (NFS) and Server Message Block (SMB) protocols.
Client-server model
Both NFS and SMB use a client-server model in which a client sends requests to a server to act on the file system. The server performs operations such as creating or deleting files or folders, modifying files, and browsing and reading files.
File systems are embedded in volumes which can be shared by many clients. Typically, Windows, Linux, and UNIX operating systems include built-in SMB and NFS client software.
Access permissions
All file system objects must have an owner, but you can grant other users and groups access permissions for objects.
For NFS, ownership specifies user IDs and group IDs, which use standard UNIX-style user and group permissions. NFSv4.1 can use user IDs and group IDs or security principals. When you use NFSv4.1 with Kerberos, the usage of Kerberos principals replaces user ID access, which authenticates user identities. In addition to standard UNIX permissions, NFSv4.1 also offers NFSv4.1 access control lists as an alternative method to manage access.
For SMB, Windows security identifiers specify ownership and use NTFS-style access control lists to manage access to objects.
Storage pools
Storage pools act as containers for volumes. All volumes in a storage pool share the following information:
Location
Service level
Virtual Private Cloud (VPC) network
Active Directory policy
LDAP use for NFS volumes, if applicable
Customer-managed encryption key (CMEK) policy
The capacity of the pool can be split up and assigned to volumes within the pool. Storage pools are a billable component of NetApp Volumes. Billing is based on the location, service level, and capacity allocated to a pool independent of consumption at the volume level.
Volumes
A volume is a file system container in a storage pool that stores application, database, and user data.
You can create a volume's capacity using the available capacity in the storage pool and you can define and resize the capacity without disruption to any processes.
Storage pool settings apply to the volumes contained within them automatically.
Snapshots and snapshot-based data management
NetApp Volumes helps you manage your data usage using snapshot capabilities. This lets you take snapshots of your data in seconds without requiring additional storage space.
NetApp Volumes snapshots aren't a separate physical copy of your data. Instead, NetApp Volumes snapshots capture only the data that's been changed since the last snapshot. Note that when you overwrite all of your data, snapshots can consume significant volume capacity.
Volume replication
You can protect your data through cross-location volume replication, which asynchronously replicates a source volume in one location to a destination volume in a different location. This capability lets you use the other volume for critical application activity in case of a location-wide outage or disaster.
Volume replication moves only used data blocks during the initial transfer. During subsequent incremental transfers, only changed blocks transfer. Charges incur only for bytes transferred, which optimizes transfer times and lowers costs.
Backups
A backup is a copy of a volume stored independently from the volume in a backup vault. If a volume is unavailable or deleted, you can use backups to restore your data to a new volume. NetApp Volumes supports manual and scheduled in-region volume backups.
The first backup of a volume contains all the volume's data. Subsequent backups capture only incremental changes which allows for fast incremental-forever backups and reduces the required capacity inside the backup vault.
Active Directory integration
File sharing protocols like SMB (CIFS), NFSv3 with extended groups, and NFSv4.1, rely on external directory services to provide user identity information using security principals. NetApp Volumes relies on Active Directory for directory services. Active Directory provides services like LDAP servers for looking up the following objects:
Users
Groups
Machine accounts
DNS servers (for hostname resolution)
Kerberos servers (for authentication purposes)
Data encryption
NetApp Volumes always encrypts your data at rest using volume-specific keys.
With customer-managed encryption keys (CMEK), volume-specific keys are wrapped using your keys stored in Cloud Key Management Service. This feature gives you greater control over the encryption keys you use and adds an additional layer of security by storing the keys on a system or in a location different from the data. NetApp Volumes supports Cloud Key Management Service capabilities such as hardware security modules, Encryption Key Management, and the full key management lifecycle of generate, use, rotate, and destroy.
Active Directory LDAP access
NFS use cases use Active Directory as an LDAP server. NetApp Volumes expects identity data using an RFC2307bis schema. Active Directory already provides this schema, but you need to make sure to populate the required attributes for your users and groups.
NetApp Volumes uses the provided credentials from the Active Directory policy to bind against LDAP using LDAP signing.
If the user or group cannot be found, access is denied.
Attribute caching
NetApp Volumes caches the results of LDAP queries. The following table describes the time to live (TTL) settings for the LDAP cache. If the cache holds invalid data due to misconfigurations you intend to fix, you have to wait until the cache refreshes before your changes in Active Directory are detected. Otherwise, the NFS server continues to use the old data to verify access, which can result in permission denied notifications on the client. After the TTL period, entries age out so that stale entries don't linger. Missing lookup requests are retained for a one minute TTL to help avoid performance issues.
| Cache | Default timeout |
|---|---|
| Group membership list | 24-hour time to live |
| UNIX groups (group user ID) | 24-hour time to live, 2-hours negative time to live |
| UNIX users (user ID) | 24-hour time to live, 2-hours negative time to live |
What's next
Read about NetApp Volumes application resilience considerations.