mirrors 启用 SSD cache

优化之前,mirrors 磁盘阵列(sdh)的 io util 常常在 90% 以上,有些时候甚至“稳定”在 100%。从sda 往 sdh 复制一些小文件,竟然不到 5MB/s。尝试调整了 iscsi 的 MTU、txqueuelen 等网络参数,没有效果,瓶颈可能不在网络上。以一块 7500rpm SATA 磁盘随机读 75~100 iops 计算,RAID6 的 iops 大约是 450~600 iops,与我们的测试结果基本相符,因此磁盘阵列可能本来就这么慢。

SSD(/dev/sdb)被格式化为 ext4 文件系统(UUID=8e19059d-358e-41ca-8896-b9b26a2d4f59),用 tune2fs 去掉了 journal。挂载参数为 nodev,nosuid,noatime,discard,挂载点为 /mnt/ssd。

用 fio 测试结果如下(使用 1G 文件):

  • 连续读 139327KB/s,34831 iops
  • 连续写 1001.1MB/s,256500 iops
  • 同时连续读写,与单独测试相比没有明显变化
  • 随机读 15708KB/s,3926 iops
  • 随机写 762047KB/s,190511 iops
  • 同时随机读写,与单独测试相比没有明显变化

写的性能这么好,估计是由于 buffer。连续读性能不高,是因为 SSD 在 RAID 卡后面,不过对我们来说足够了。我们最关心的随机读性能 3926 iops 达到了预期,目前磁盘阵列的随机读性能不到 500 iops。

SSD cache 的缓存策略基于 HTTP access log。每天凌晨,选出前一周的 HTTP 200 请求,按照 URL 访问频率降序排序,填满 SSD cache 为止。

注册登录 USTC LUG GitLab,即可查看源代码:https://gitgeek.net/mirrors/ssd-cache

cron-cache.sh 每天运行一次,生成缓存:

  1. 读出最近7天的 HTTP access log
  2. 取出 200 请求,统计 URL 访问频率
  3. 筛选至少访问过2次的文件,按频率降序排序,得到 filefreq-20131010.gz 这样的文件列表。
  4. 从上述文件列表中依次取出文件,获取其大小,添加到缓存列表(tocache-20131010)中,直到达到设定的缓存总大小。
  5. 用 rsync 把缓存列表中的文件同步到缓存区。用 rsync 的好处是文件没有被修改时不需要重新复制,由于多数文件的访问频率是相对稳定的,每天复制的数据量并不大。

每个源同步后,要刷新 cache,这是 update-cache.sh 的职责。它同样使用了 rsync。

200G 的缓存共缓存了 3696 个文件(其中 iso 文件占 422 个),根据前7天的 HTTP 200 日志,最多的在7天内被访问了 1036142 次,最少的在7天内被访问了 97 次。

SSD cache 的效果怎么样呢?200G 的 cache 同步完成后,

  • 磁盘阵列(sdh)的负载从一直 90%+,降到了时而 90%+,时而 50%~60%
  • 总流量增加了约 50Mbps(原来是 ~350 Mbps,后来是 ~400 Mbps)
  • load average 似乎没有明显变化
  • 被缓存文件的校内下载速度可达 50~70 MB/s,能够吃满 mirrors 的千兆网卡

希望 status.lug.ustc.edu.cn 和 mirrors 的 collectd-web 尽快恢复,以便对 SSD 的效果做更多更直观的观察和评估。

科大开源软件镜像发生磁盘故障

2013年8月31日 11:06,科大开源软件镜像(mirrors.ustc.edu.cn)发生磁盘故障。磁盘 sda 从系统中突然消失。sda 上有 mirrors 主系统(mirrors-main)的根分区、各 LXC 虚拟机系统的根分区,sda 的消失导致 mirrors 的所有服务立即中断。

问题发生一小时后的 12:08,Stephen Zhang 在邮件列表发帖说 mirrors 挂了。收到邮件后,我们检查了服务监控系统,发现学校短信平台也很不巧地挂掉了,因此没有在第一时间收到报警短信。我们登录到 mirrors-base(mirrors-main 是 Xen 虚拟机,mirrors-base 是 Xen Domain0),发现 dmesg 中有同样的磁盘错误信息,/dev/sda 不见了。据此判断是磁盘故障。

由于此问题无法快速解决,我们采用以往的方法(所谓“启动应急预案”),将 mirrors 的 DNS 设置别名为 backup.mirrors.ustc.edu.cn,它解析到 lug.ustc.edu.cn 服务器,显示一个临时错误页,并把大部分源 HTTP 重定向到国内其他开源软件镜像。

随后,我们把 /etc 备份到其他机器上,挽救了一些尚在缓存内的配置文件。我们重新扫描了 SCSI 总线,未发现新设备。确认主管机房的张运动老师在校后,在学校的 bible 去了网络中心机房。张运动老师还说学校几百台服务器依赖 CentOS 来装软件包,让我们一定把 CentOS 源维护好。据去年统计,校内流量仅占 mirrors 总流量的1%,因此每次 mirrors 挂机,都可能影响数以万计的服务器和 PC,对此我们深感愧疚。

重新拔插硬盘、物理重启 mirrors 数次,包括使用不带 Xen 的内核,仍未在系统里发现丢失的那块磁盘。在 RAID 控制界面,发现有两块磁盘报 PD Missing 错误。我们尚未找到相关技术资料。

2013-08-31

目前 mirrors-base(Xen Domain0)仍然在正常运行,因其根文件系统在 sdc 上。mirrors-main 连同 LXC 虚拟机系统的根分区连同那块硬盘,已经消失了。我们怀疑并不是硬盘损坏,因为两块硬盘是硬 RAID1,同时损坏的概率微乎其微;怀疑是 RAID 卡损坏,或者主板上接线松了。

本次故障由于涉及硬件问题,恢复时间未知。我们对此带来的不便深表歉意。