NetApp Volumes product overview

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

  • Zonal or regional pool availability

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.

Storage pools with Flex service level

Flex storage pools offer two availability options:

  • Zonal pools: Zonal pools provide availability within a single zone. However, if the entire zone experiences an outage, the volumes in the zonal pool becomes inaccessible.

  • Regional pools: Regional pools provide availability across two zones in a region. Volumes are synchronously replicated between the primary and replica zone to ensure access to your data during a primary zone outage. The failover to the replica zone is automatic in the event of a zone failure. You can perform a manual zone switch for failback or load balancing.

For more information about NetApp Volumes availability, see Google Cloud NetApp Volumes Service Level Agreement (SLA).

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.

Auto-tiering

Auto-tiering is available as allow-listed General Availability (GA). To request access to auto-tiering, contact sales.

Auto-tiering reduces the overall cost of volume usage. Users who have large amounts of inactive data can reduce their overall storage cost with auto-tiering. Data which is never or very rarely used after it has been written to the volume is called cold data. Auto-tiering can be enabled at the per volume level. Once auto-tiering is enabled for a volume, NetApp Volumes identifies data that is infrequently used and moves cold data transparently from the primary hot tier to a cheaper but slower cold tier. Your active data stays on your hot tier. Auto-tiering can be enabled only for volumes of the Premium or Extreme service levels.

As a user, you create a volume with the right size to hold all of your data. Whether the data is located on the hot tier or cold tier, it is managed automatically by the volume and is transparent to an application or user accessing the volume using NFS or SMB. You can always see the full dataset. However, there can be a performance difference between reading data from the hot tier versus reading data from the cold tier. Data on the hot tier shows the same performance as a non-tiered volume. Data on the cold tier shows higher read latencies and reduced read performance.

NetApp Volumes determines whether to move cold data to the hot tier based on the access pattern. Reading the cold data with sequential reads, such as those associated with data copy, file-based backups, indexing and antivirus scans, leaves the data on the cold tier. Reading the cold data with random reads moves the data back to the hot tier. This data stays in the hot tier until it cools off again.

Note that regularly reading the data from the hot tier in non-sequential ways, might block data from getting cold, which might affect antivirus full scans or file-based full backups, depending on their data access pattern.

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 interacts with LDAP by querying for the following attributes:

  • Usernames

  • Numeric UNIX users (user ID)

  • Groups

  • Group memberships for NFS protocol operations

When you use LDAP for operations such as name lookup and fetching extended groups, the following process occurs:

  1. NetApp Volumes uses the LDAP client configuration to connect to a domain controller LDAP server. The LDAP server is found using the storage pool's Active Directory policy.

  2. If the TCP connection to the LDAP service port is successful, then NetApp Volumes LDAP client attempts to sign in to the domain controllers LDAP server using the credentials defined in the Active Directory policy.

  3. NetApp Volumes uses LDAP signing if required. LDAP signing requires a correct DNS PTR record for the LDAP server.

  4. After a successful authentication between the NetApp Volumes LDAP client and the domain controller LDAP server, then the NetApp Volumes LDAP client client uses the RFC 2307bis LDAP schema to query the LDAP server. The following information is passed to the server in the query:

    • Domain name as Base or user DN

    • Search scope type (subtree)

    • Object class (user, posixAccount for users, and posixGroup for groups)

    • UID or username

    • Requested attributes (uid, uidNumber, gidNumber for users, or gidNumber for groups)

  5. If the user or group can't be found, the request fails and access is denied.

  6. If the request is successful, then user and group attributes are cached for future use. The name lookup and fetching of extended groups improves the performance of subsequent LDAP queries associated with the cached user or group attributes, and also reduces the load on the LDAP server.

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.