关于开源软件镜像联盟（技术篇）

|
LUG

请先阅读：关于开源软件镜像联盟（非技术篇），谢谢

一、DNS or 301?

Update: 之前我对DNS的CNAME理解错误，现在更正。参考文献：https://tools.ietf.org/html/rfc3568

DNS方案（如果说得不对欢迎拍砖）：

  1. 每个镜像分配一个二级域名，以便分别调度；NS记录设置为主站
  2. 用户从运营商DNS查询IP
  3. 主站根据来源IP（运营商DNS的IP）返回一个或多个镜像节点的IP地址
  4. 运营商DNS把这个IP返回给用户，同时缓存一定期限

  5. 用户与镜像节点建立连接，进行下载
    301方案：

  6. 域名A记录解析到主站

  7. 用户与主站建立连接，发起HTTP请求
  8. 主站根据用户来源IP返回HTTP 301状态，跳转到一个镜像节点
  9. 用户与这个镜像节点建立连接，进行下载

比较

DNS

301

调度精确性

只能获知运营商DNS的IP，按区域匹配

可以获知用户IP，根据用户IP精确匹配

调度策略修改

需要等到DNS缓存超时才能生效

随时修改，立即生效

镜像节点目录结构

必须相同

不必相同

用户需要访问校外

不需要

需要(*)

访问延迟

几乎不增加延迟

需要先与主站建立连接，增加一次TCP握手的延迟

主站压力

运营商DNS有缓存，压力低

每个访问都要去主站，而且HTTP请求解析成本比DNS高，故压力高

主站稳定性要求

高

较高

多主站负载均衡

可以实现

可以实现



(*) 即使校内有镜像节点，用户也必须开通校外访问权限（限制IPv6的学校多吗？如果大部分学校的IPv6没有访问限制则忽略此条）

二、镜像间通信

主节点要实时监控各镜像节点的状态，例如用Ganglia/Nagios；发现故障时，一方面要调整调度策略，让新请求不再走这个镜像；另一方面要通过邮件发出报警。

一个镜像的大陆主节点定期从上游源同步。同步完成后通知其他节点来自己这里同步（这个API还要讨论）；如果同步失败，也要通知其他节点自己去上游源同步。

镜像的访问日志有分析价值，是调度策略调整的重要依据，因此要有一种机制，每天各节点把Web访问日志汇总到主站，主站再按照镜像进行分类。

各镜像站尽量协商使用同一种Linux发行版，方便编写“维护工具链”。

三、主站Web界面要提供的信息

  • 公开的镜像列表，显示每个镜像的大小、每日更新量统计、已经有哪些镜像节点，以及每个节点维护着哪些镜像，以便新加入的镜像站量力而行，把有限的资源用到最需要的镜像上。
  • 各镜像节点的状态监控
  • 用户使用每个镜像的帮助信息
    本文参考：http://blog.ustc.edu.cn/pipermail/ustc_lug/2013-March/009974.html