I/O弹性
该文档描述了Alluxio如何处理意外或者可预期的宕机,例如当Alluxio workers变得不可用时。 有多种机制来平滑地处理应用程序请求,并确保Alluxio系统的总体I/O弹性。
UFS回退机制
Alluxio客户端从Alluxio工作节点读取元数据和数据。如果请求的工作节点变得不可用或返回错误,客户端可以回退到从UFS请求这些信息。
UFS回退机制在默认情况下是开启的。 这种设置在一些情况下可能有负面情况出现,例如潜在大量请求过载UFS,这种效应被称作是羊群效应问题。(参见https://en.wikipedia.org/wiki/Thundering_herd_problem)
如果想要禁用该机制,可以使用以下方式设置
通过FUSE接口读取文件时启用FUSE UFS回退机制
用户如果通过FUSE接口读取文件,并且在操作中途工作节点变得不可用,Alluxio将无缝地从工作节点切换到UFS来转换读取源。 这样将避免工作节点被移除时,客户端需要显式重试读取操作的需要
跨副本重试
当启用多副本并且客户端未能从工作节点获得响应时,客户端将在其他可用的工作节点上重试。这一机制既适用数据访问,也适用元数据访问。 同样的,这避免了在目标工作节点突然无响应的情况下,客户端需要显式重试读取操作的需要。
成员变更
添加工作节点
当向集群中添加工作节点时,新添加的工作节点将根据一致性哈希算法,从既有工作节点处接管一些哈希范围。 客户端仍将从现有的工作节点中读取文件,直至客户端检测到成员已发生变更。 如果请求被指向新的工作节点,由于工作节点需要重新从UFS加载数据,读取操作可能会变慢,但操作不应显示任何错误。
移除工作节点
当工作节点被移除时,之前指向被移除工作节点的路径将根据一致性哈希算法重新分配给其他工作节点。 由被移除工作节点服务的,正在进行的请求,将会失败。 如果启用了UFS回退机制,客户端将尝试直接向UFS重试请求。 一旦客户端检测到成员变更,这些请求将被适时指向剩余尚在工作的工作节点。 如果基于FUSE结构的UFS回退机制,工作节点被移除时,FUSE客户端不应显示错误。 如果基于S3和fsspec接口,应用程序可能会看到正在进行的读取发生瞬时读取错误,但应该能够在工作节点成员更新后恢复。
重启工作节点
重启工作节点,与移除工作节点后再次添加是相同的。因为每个工作节点都有一个特定身份从而形成一致性哈希环。 重启的工作节点将负责它之前管理的相同路径,这样此工作节点上缓存的数据仍然有效。同样,FUSE客户端在工作节点重启的情况下不应观察到任何读取失败。
Last updated