Google Cloud于8月5日宣布，托管文件存储服务Filestore已经运行在Colossus分布式存储架构上。Colossus是Google File System的后继系统，长期支撑Google内部与云端的大规模数据服务，这次调整把Filestore的共享NFS能力放到同一套底层架构中。
Filestore主要解决多台云服务器、容器或虚拟化工作负载同时读写同一组文件的问题。它与只能由有限主机写入的块存储不同，也保留了POSIX语义、文件锁和目录结构，不需要把传统应用全部改造成对象存储访问方式。
Filestore底层转向Colossus
Colossus把数据管理、存储节点和访问路径分散到大规模基础设施中，容量与性能不再依赖一组固定文件服务器。Filestore接入后，Google可以在不改变用户NFS使用方式的前提下，继续扩展底层存储池。
这项变化对用户最直观的意义不是出现一种新协议，而是托管文件服务的扩展边界被重新打开。应用仍然通过NFS挂载共享目录，底层的数据放置、冗余与故障处理由Google Cloud负责。
Colossus并不等于所有Filestore实例都会获得相同性能。实例所在区域、服务层级、容量、配置的IOPS与客户端并发能力，仍会决定最终吞吐和延迟。
最高吞吐达到26GiB/s
Google Cloud当前公布的Filestore上限为100TiB容量、26GiB/s吞吐和92万IOPS。区域层级还提供99.99%的可用性服务等级协议，用于需要跨可用区韧性的企业应用。
这些数字属于最高规格，并不是创建一台基础实例后就能直接达到。高性能文件存储需要足够的客户端数量、并发队列、网络带宽和应用I/O模型，单台小规格云服务器往往先受到网卡或CPU限制。
Filestore还提供自定义性能选项，容量与IOPS可以分别调整。对元数据密集型任务、渲染、电子设计自动化和高性能计算来说，这比单纯为了提高速度而扩大存储容量更容易控制资源。
云服务器与GKE继续使用NFS接入
Filestore可以连接Compute Engine云服务器、Google Kubernetes Engine集群、Google Cloud VMware Engine、Cloud Run和本地数据中心。现有应用继续使用NFSv3或受支持层级中的NFSv4.1，不需要因为底层迁移到Colossus重写文件访问逻辑。
在GKE中，Filestore可通过CSI驱动为多个Pod提供ReadWriteMany共享访问。容器被重新调度到其他节点时，数据仍保留在独立文件服务中，适合内容管理、模型文件、共享工作目录和需要文件锁的应用。
NFSv4.1支持通过Kerberos提供传输加密，NFSv3本身则不提供相同的协议级加密能力。跨网络连接时仍要核对协议、VPC访问规则与传输保护，不能只依赖存储端静态加密。
区域实例可在可用区故障时继续服务
Filestore Zonal面向区域内的高性能任务，Regional则强调可用区故障下的连续访问。区域实例采用严格一致性策略，写入只有在数据持久化后才会确认，发生单个可用区故障时仍可继续读取和写入。
需要更高灾备等级的业务还可以把实例异步复制到其他区域，并在区域级故障时提升备用实例。快照、备份与跨区域复制解决的问题不同，不能只创建快照就认为已经具备异地容灾。
底层进入Colossus后，扩展能力和企业功能有了更统一的基础，但用户仍需要根据业务选择Zonal或Regional。只追求最高性能与强调跨区连续性，对实例层级和成本的要求并不相同。
普通网站不必因架构变化立即迁移
WordPress、Drupal和传统企业应用可以使用Filestore保存多台前端服务器共享的内容文件，但访问量不高的单机网站通常用本地云盘更简单。共享文件系统的价值主要出现在多实例、弹性扩容和集中内容管理场景。
现有Filestore用户需要关注的是服务层级、性能配置、客户端协议和区域可用性，而不是自行操作底层迁移。应用侧更值得测试的指标包括小文件延迟、元数据操作、并发写入、故障切换和备份恢复时间。
此次公告说明Google Cloud正在把共享文件存储进一步纳入其超大规模存储底座。Colossus带来的容量与扩展潜力已经明确，具体业务能获得多大收益，仍要结合实例规格与真实I/O测试判断。
