镜像文件系统

如果希望同时在两个或多个地域使用同一个 JuiceFS 文件系统，并获得相似的高性能体验，可以考虑使用 JuiceFS 的「镜像文件系统」功能：为文件系统创建一个或多个完整的「只读镜像」，内容完全一致，但用独立的文件系统名称和访问凭据来挂载。每个镜像文件系统均单独计费。

从 5.0 开始，JuiceFS 支持「写入镜像文件系统」，阅读下方相关小节了解更多。

工作原理

镜像首先需要建立元数据同步，这需要在镜像区域搭建元数据集群，并将其配置为源集群的镜像。同步的最小单位是整个元数据实例，而无法单独同步某一个文件系统，但考虑到元数据同步的开销不大，一般不会因此产生性能方面的问题。在镜像区域设置完毕并启动后，镜像集群会自动从源区域进行元数据同步，按照常见的跨区域网络状况，一般是秒级延迟，具体取决于实际网络状况。与此同时，控制台的后台任务也会对同步情况进行监控，在数据版本相差过大的时候进行报警。如果源集群发生故障、停止服务，镜像集群可以继续服务，但是由于数据同步中断，文件系统数据不会继续更新。

至于对象存储数据，用户可以根据场景需要，自行选择合适的方案：

• 方案一：多个区域共用一个对象存储。如果希望简化设置、降低对象存储费用，可以考虑两个区域共用同一个对象存储，然后在镜像区域搭建分布式缓存集群来提升性能，如下图所示。

  

• 方案二：每个区域使用独立的对象存储。如果镜像区域需要访问文件系统的全部数据，并且希望最大程度提升性能，那么需要使用独立的对象存储服务，开启数据复制保证数据及时同步。

  

对于方案二，由于镜像区域使用独立的对象存储服务，那么需要在挂载时提供两个对象存储的密钥信息（--access-key2、--secret-key2）。镜像元数据服务会根据变更日志，将需要同步的数据以后台任务形式下发给各个客户端来执行，客户端收到任务后，会在后台任务中从源文件系统的对象存储拉取数据，写入到镜像文件系统的对象存储。因此如果同步速度不理想，可以增加挂载客户端数，提高数据同步的并发度。镜像文件系统的数据复制原理，在数据复制的工作原理中有更详细的说明。

对于镜像区域的客户端，会优先从当前区域的对象存储读取数据，如果此时数据同步尚未完成，则会尝试从源区域的对象存储读取，读取完毕以后还会写回当前区域对象存储，避免下次访问发生穿透。流程如下图所示：

一对多复制

JuiceFS 没有镜像区域的数量限制，一个元数据集群可以创建任意数量的镜像，而每个文件系统都可以使用自己所在区域的当地对象存储，并且启用数据复制，因此可以用这种方法来实现文件系统一对多的复制。

该话题和「数据复制」功能高度相关，数据复制功能本身只能实现「一对一」的数据同步，因此如果需要「一对多」的复制效果，必须借助镜像文件系统来实现。这一点在「数据复制」的工作原理中也有更详细的介绍。

开始使用

如果需求已经确定，请联系 Juicedata 工程师为你在指定的云服务商（或数据中心）区域部署镜像元数据服务。如果你是私有部署客户，也可以从我们这里获取部署文档，自行实施。

镜像区域创建完毕、建立数据同步以后，点击进入文件系统的设置页面，然后就可以在「镜像文件系统」板块点击创建镜像了。

需要注意：

• 镜像文件系统有着自己的名字、访问凭据（Token），挂载的时候务必注意不要搞混这些要素；
• 如果启用了数据复制，那么第一次挂载镜像文件系统时，会自动开始同步历史数据，不过为了让镜像文件系统可以更快投产，我们推荐提前用其它方式手动进行全量同步（如通过 juicefs sync 同步数据）。在镜像区域客户端运行期间，也会定期（默认每周一次）全量同步对象存储中的数据；
• 默认情况下，镜像文件系统是只读访问，无法写入或修改数据。对于宿主机挂载点，任何写入操作都会直接出错。但是对于 CSI 驱动，则要尤其注意，不应使用文件系统中不存在的目录（比如使用「动态配置」，或者试图挂载不存在的子目录），否则将导致 CSI Controller 初始化失败，进而无法挂载；
• 如果需要通过镜像文件系统进行写入，可以修改客户端挂载 Token 的权限，使用读写权限，详见下方小节。

写入镜像文件系统

从 5.0 开始，JuiceFS 支持镜像文件系统的写功能，其原理也并不十分复杂：镜像区域的客户端实现了读写分离，元数据的读请求一律通过镜像区域的元数据服务来进行，而写请求则会跨区域写入源集群的元数据服务和对象存储。因此如果你需要在镜像区域进行文件写入，不再需要单独通过公网挂载源文件系统，而是可以直接通过镜像文件系统的客户端来执行写入。

上方架构图中体现的是镜像区域挂载点的写入，元数据会直接提交到「源集群」。类似地，如果镜像文件系统采用双对象存储桶的使用方式，镜像挂载点会关联 2 个对象存储桶（通过控制台的文件系统页面可以配置），运行架构如下：

• bucket1 会设置为镜像当地的存储桶，挂载点在读取数据的时候，优先访问该桶。如果 bucket1 不存在，则回源到 bucket2，读取成功以后再写回 bucket1。
• bucket2 是源区域的对象存储桶，挂载点在写数据的时候会优先写入该桶，然后异步写入到 bucket1，优先保证源区域的数据完整。

备注

镜像文件系统的写入支持现已正式发布（GA）。采用前请留意下方描述的一致性注意事项。

启用镜像文件系统的写入支持不需要特殊操作，你只需要在「访问令牌」页面正常创建读写权限的 Token 就可以了。因此如果希望对镜像文件系统进行权限管理，将写入行为局限在特定客户端中，只需要管理各个 Token 的读写权限即可。

使用镜像的写功能时，需要留意的一致性相关注意事项：

• 由于读写分离的架构，当多个客户端同时往镜像文件系统写入文件时，A 可能会无法立刻读取到 B 写入的新文件，需要等待镜像元数据更新，以及随之而来的客户端内存元数据刷新；
• 单个镜像文件系统的挂载点，在读写同一个文件时，会等待写入提交、Raft 数据版本号更新，才会继续读取文件。因此在混合读写文件的场景下，性能可能会受到影响；
• 对于多分区的镜像场景，每个元数据分区都各自进行着镜像数据传输和同步，一个目录下的不同文件可能会分散在多个分区，并且通过「跨分区链接」来记录引用关系。因此客户端实际访问的时候，会首先检查「跨分区链接」元数据中记录的 Raft 数据版本号，并等待目标分区的数据版本编号达到要求之后，才开始读取文件，避免由于各个分区的元数据同步速度不一致，导致访问文件的时候由于元数据尚未更新，被误判为“文件不存在”。