关于开源软件镜像联盟(技术篇)

请先阅读:关于开源软件镜像联盟(非技术篇),谢谢

一、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