NetApp Volumes 产品概览

本页面简要介绍了 Google Cloud NetApp 卷的特性和功能。

网络附加存储

NetApp Volumes 可将文件系统或卷共享给网络附加存储 (NAS) 客户端。NAS 客户端通常是使用业界标准的网络文件系统 (NFS) 和服务器消息块 (SMB) 协议在 Windows 或 Linux 操作系统上运行的虚拟机 (VM)。

客户端-服务器模型

NFS 和 SMB 都使用客户端-服务器模型,其中客户端向服务器发送请求以对文件系统执行操作。服务器执行诸如创建或删除文件或文件夹、修改文件以及浏览和读取文件等操作。

文件系统嵌入在可供多个客户端共享的卷中。通常,Windows、Linux 和 UNIX 操作系统都包含内置的 SMB 和 NFS 客户端软件。

访问权限

所有文件系统对象都必须有所有者,但您可以向其他用户和群组授予对象的访问权限。

对于 NFS,所有权指定用户 ID 和组 ID,这些 ID 使用标准的 UNIX 风格用户和组权限。NFSv4.1 可以使用用户 ID 和群组 ID 或安全正文。将 NFSv4.1 与 Kerberos 搭配使用时,Kerberos 主账号的使用会取代用户 ID 访问权限,后者用于对用户身份进行身份验证。除了标准 UNIX 权限之外,NFSv4.1 还提供了 NFSv4.1 访问控制列表,作为管理访问权限的替代方法。

对于 SMB,Windows 安全标识符用于指定所有权,并使用 NTFS 风格的访问控制列表来管理对对象的访问权限。

存储池

存储池充当卷的容器。存储池中的所有卷共享以下信息:

  • 位置

  • 服务等级

  • 虚拟私有云 (VPC) 网络

  • Active Directory 政策

  • 对 NFS 卷的 LDAP 使用(如果适用)

  • 客户管理的加密密钥 (CMEK) 政策

  • 可用区或区域性存储池可用性

存储池的容量可以拆分并分配给存储池中的卷。存储池是 NetApp Volumes 的一项可计费组件。 结算金额取决于分配给存储池的位置、服务等级和容量,与卷级使用量无关。

服务等级为“Flex”的存储池

灵活存储池提供两种可用性选项:

  • 可用区级存储分区:可用区级存储分区可在单个可用区内提供可用性。但是,如果整个可用区发生服务中断,则可用区存储池中的卷将无法访问。

  • 区域性存储池:区域性存储池可在一个区域中的两个可用区之间提供可用性。卷会在主可用区和副本可用区之间同步复制,以确保在主可用区发生服务中断时您仍能访问数据。如果可用区发生故障,系统会自动故障切换到副本可用区。您可以执行手动可用区切换以实现故障转移或负载均衡。

如需详细了解 NetApp Volumes 的可用性,请参阅 Google Cloud NetApp Volumes 服务等级协议 (SLA)

卷是存储池中的文件系统容器,用于存储应用、数据库和用户数据。

您可以使用存储池中的可用容量创建卷的容量,并且可以定义和调整容量,而不会中断任何进程。

存储池设置会自动应用于其中包含的卷。

快照和基于快照的数据管理

NetApp Volumes 可帮助您使用快照功能管理数据使用情况。这样,您无需额外的存储空间,即可在几秒钟内拍摄数据快照。

NetApp 卷快照不是数据的单独实体副本。相反,NetApp 卷快照仅会捕获自上次快照以来发生更改的数据。请注意,如果您覆盖所有数据,快照可能会占用大量卷容量。

卷复制

您可以通过跨位置卷复制来保护数据,该功能可将一个位置的源卷异步复制到另一个位置的目标卷。借助此功能,您可以在发生位置范围的服务中断或灾难时将另一个卷用于关键应用活动。

在初始传输期间,卷复制仅会移动已使用的块。在后续增量传输期间,系统只会传输更改的块。系统仅针对传输的字节收费,这有助于缩短传输时间并降低费用。

备份

备份是卷的副本,与卷在备份保险柜中的存储位置无关。如果某个卷不可用或已被删除,您可以使用备份将数据恢复到新卷。NetApp Volumes 支持手动和按计划进行的区域内卷备份。

卷的首次备份包含该卷的所有数据。后续备份仅捕获增量更改,这支持快速进行永久增量备份,并减少备份保险柜内所需的容量。

Active Directory 集成

SMB (CIFS)、具有扩展群组的 NFSv3 和 NFSv4.1 等文件共享协议依赖于外部目录服务,以使用安全正文提供用户身份信息。NetApp Volumes 依赖于 Active Directory 来提供目录服务。Active Directory 提供 LDAP 服务器等服务,用于查找以下对象:

  • 用户

  • 群组

  • 机器账号

  • DNS 服务器(用于主机名解析)

  • Kerberos 服务器(用于身份验证)

数据加密

NetApp Volumes 始终使用特定于卷的密钥对静态数据进行加密。

使用客户管理的加密密钥 (CMEK) 时,系统会使用存储在 Cloud Key Management Service 中的密钥封装特定于卷的密钥。借助此功能,您可以更好地控制所使用的加密密钥,并通过将密钥存储在系统上或与数据不同的位置来增添一层额外的安全保障。NetApp Volumes 支持 Cloud Key Management Service 功能,例如硬件安全模块、加密密钥管理,以及生成、使用、轮替和销毁的完整密钥管理生命周期。

自动分层

自动分层已列入许可名单,现已推出正式版 (GA)。如需申请使用自动分层功能,请与销售团队联系。

自动分层可降低数据卷使用总费用。拥有大量闲置数据的用户可以通过自动分层来降低总体存储费用。写入卷后从未使用或很少使用的称为冷数据。您可以在每个卷级别启用自动分层。为卷启用自动分层后,NetApp 卷会识别不常使用的数据,并将冷数据透明地从主要的热层移至价格较低但速度较慢的冷层。您的有效数据会保留在热层中。只有高级或极速服务等级的卷才能启用自动分层。

作为用户,您可以创建大小合适的卷来存储所有数据。无论数据位于热层还是冷层,都会由卷自动管理,并且对使用 NFS 或 SMB 访问卷的应用或用户是透明的。您可以随时查看完整的数据集。 不过,从热层读取数据与从冷层读取数据的性能可能会有所不同。热层中的数据的性能与非分层卷相同。冷存储层中的数据读取延迟时间更长,读取性能较差。

NetApp 卷会根据访问模式确定是否将冷数据移至热层级。使用顺序读取(例如与数据复制、基于文件的备份、索引编制和杀毒扫描相关的读取)读取冷数据时,数据会保留在冷层级。使用随机读取读取冷数据会将数据移回热层。这些数据会一直保留在热层中,直到再次冷却。

请注意,以非顺序方式定期从热层读取数据可能会阻止数据变冷,这可能会影响杀毒软件的完整扫描或基于文件的完整备份,具体取决于其数据访问模式。

Active Directory LDAP 访问权限

NFS 用例使用 Active Directory 作为 LDAP 服务器。NetApp 卷预计使用 RFC2307bis 架构的身份数据。Active Directory 已提供此架构,但您需要确保为用户和群组填充所需的属性。

NetApp Volumes 通过查询以下属性与 LDAP 交互:

  • 用户名

  • 数字 UNIX 用户(用户 ID)

  • 群组

  • NFS 协议操作的群组成员资格

当您使用 LDAP 执行名称查找和提取扩展群组等操作时,系统会执行以下过程:

  1. NetApp 卷使用 LDAP 客户端配置连接到网域控制器 LDAP 服务器。系统会使用存储池的 Active Directory 政策查找 LDAP 服务器。

  2. 如果与 LDAP 服务端口的 TCP 连接成功,NetApp 卷 LDAP 客户端会尝试使用 Active Directory 政策中定义的凭据登录网域控制器 LDAP 服务器。

  3. NetApp Volumes 会根据需要使用 LDAP 签名。LDAP 签名需要 LDAP 服务器具有正确的 DNS PTR 记录。

  4. 在 NetApp Volumes LDAP 客户端与域控制器 LDAP 服务器之间成功完成身份验证后,NetApp Volumes LDAP 客户端会使用 RFC 2307bis LDAP 架构查询 LDAP 服务器。查询会将以下信息传递给服务器:

    • 域名为 Baseuser DN

    • 搜索范围类型(子树)

    • 对象类(对于用户,为 user、posixAccount;对于群组,为 posixGroup)

    • UID 或用户名

    • 请求的属性(对于用户,是 uid、uidNumber 和 gidNumber;对于群组,是 gidNumber)

  5. 如果找不到用户或群组,请求将失败,并且系统会拒绝访问。

  6. 如果请求成功,系统会缓存用户和群组属性以供日后使用。扩展群组的名称查找和提取可提高与缓存的用户或群组属性关联的后续 LDAP 查询的性能,还可降低 LDAP 服务器的负载。

属性缓存

NetApp Volumes 会缓存 LDAP 查询的结果。下表介绍了 LDAP 缓存的存活时间 (TTL) 设置。如果缓存因您打算修正的错误配置而包含无效数据,则您必须等待缓存刷新,然后系统才能检测到您在 Active Directory 中所做的更改。否则,NFS 服务器会继续使用旧数据来验证访问权限,这可能会导致客户端上显示权限被拒通知。在 TTL 期限结束后,条目会过期,以免过时条目保留在缓存中。系统会将缺失的查询请求保留 1 分钟的 TTL,以帮助避免性能问题。

缓存 默认超时
群组成员名单 24 小时制存留时间
UNIX 组(群组用户 ID) 24 小时的存留时间,2 小时的负存留时间
UNIX 用户(用户 ID) 24 小时的存留时间,2 小时的负存留时间

后续步骤

了解 NetApp Volumes 应用弹性考虑