The Google File System 翻译和理解( 九 )


为了防止克隆操作的流量影响到客户端的流量,Master 限制了集群和每个块服务器上正在运行的克隆操作数量 。此外,每个块服务器通过减少发往源块服务器的读请求,限制了每个克隆操作所占用的带宽 。
最后,Master 周期性地对副本重新进行负载均衡:它检查当前的副本分布情况,并将副本移动到更合适的磁盘空间上,达到负载均衡 。通过这个过程,Master 逐步的填充新的块服务器,而不是马上使用新的块和大量的写入流量填充它 。这个新副本的分布标准与上面提到的类似 。此外 , Master 必须选择移动哪个已存在的副本,通常情况下,它更倾向于从剩余空间小于平均值的那个块服务器上移动副本 , 以使磁盘使用率相等 。
4.4 垃圾回收在一个文件被删除后,GFS 不会立即回收可用的物理存储空间 。而是只在文件和块级别上定期地进行垃圾回收 。我们发现,这个方法使系统更加简单,更加可靠 。
4.4.1 机制当一个文件被应用删除时,Master 会像其他操作一样立即记录下这个删除操作 。然而 , 文件仅仅会被重命名为一个包含删除时间戳且隐藏的名字,而不是立即回收资源 。在 Master 定期扫描文件系统的命名空间期间,它将真正删除已经被隐藏超过三天的文件(这个间隔可以配置) 。在此之前,文件仍然可以通过新的特殊的名字进行读取 , 也可以通过重命名为普通的文件名从而撤销删除操作 。当隐藏文件从命名空间中真正被删除时,内存中对应的元数据也会被清除,这样能有效的切断文件和它的所有块的连接 。
在对块的命名空间做类似的扫描时,Master 标识出孤儿块(任何文件都无法访问到的块) , 并将那些块的元数据清除 。在与 Master 进行定期的心跳信息交换时,每个块服务器报告其所含有块的集合,Maste r回复块服务器哪些块没有出现在 Master 的元数据中,块服务器将释放并删除这些块的副本 。
4.4.2 讨论虽然分布式回收机制在编程语言领域是一个需要复杂解决方案的难题 , 但在我们的系统中十分简单 。我们能简单的确定一个块的所有引用:它们唯一的保存在 Master 的文件-块映射中 。我们也能轻松的确定一个块的所有副本:它们都以 Linux 文件的形式存储在每台块服务器的指定目录下 。任何 Master 不认识的副本都是“垃圾” 。
用于存储回收的垃圾回收方法通过惰性删除拥有几个优势:

  • 首先,对于组件失效是常态的大规模分布式系统来说,这种方式简单可靠 。块创建操作可能在一些块服务器上执行成功 , 但在另一些服务器上执行失败,残余的副本在主节点上无法识别 。副本删除消息可能丢失,Master 必须重新发送执行失败的消息,包括自身的和块服务器的 。垃圾回收机制提供了一个一致的、可靠的方法来清除没用的副本 。
  • 其次,它将存储回收操作合并到了 Master 定期的后台操作中 , 比如定期浏览命名空间和与块服务器握手 。批处理的方式分摊了任务的开销 。此外,只有在 Master 相对空闲时才会完成垃圾回收,Master 对客户端需要及时回复的请求有更高的优先级进行响应 。
  • 第三,延迟回收存储空间可以为防止意外的、不可撤销的删除操作提供一个安全保障 。
在我们的经验中,上述机制主要的缺点是:当存储空间紧张时,会阻碍用户对系统进行及时调整 。频繁创建和删除临时文件的应用不能马上重用删除数据后的可用空间 。我们通过在已被删除的文件上显式的再次进行删除来解决垃圾回收的这些问题;我们也可以允许用户对命名空间的不同部分应用不同的复制和回收策略 。比如,用户可以指定一些目录树下的所有文件进行无副本存储,任何被删除的文件会从系统上迅速的、不可恢复的删除 。
4.5 过期副本的检测如果一个块服务器失效并在宕机期间丢失了块的修改操作,块副本可能会过期 。对于每个块,Master 维护一个块版本号来区分最新的副本和过期的副本 。
  1. 每当 Master 授予某个块一个新租约 , 这个 Primary 副本都会自增版本号,并向所有副本通知新版本号 。
  2. 在客户端接收到通知并开始进行写操作之前,Master 和 Master 的副本将此块的新版本号持久化 。
  3. 如果其它副本当前不可用,它的块版本号将不会被更新 。
  4. 当块服务器重启并报告它所有的块集合和它们相应的版本号时,Master 还会探测这个块服务器下副本的版本号 。
    1. 一方面记录下是否有过期的副本 。

      推荐阅读