月度归档： 2016年12月

mirrors 新服务器上线通知

科大开源镜像站已经与各位开源爱好者一起走过了17个年头啦！目前镜像站共提供了106个镜像，镜像总大小超过24T，月流量超过100TB。

近期，由于服务器老化，曾导致服务数次中断。在网络信息中心张焕杰老师的帮助下，科大开源镜像站添置了新的服务器。经过半个多月的数据迁移，新服务器已经准备就绪。我们计划逐步将服务转移至新服务器，具体迁移时间见附表。

最后，感谢科大网络信息中心和各位捐赠者的热心捐赠，在此向你们致以最诚挚的谢意。

科大开源镜像站与每位开源爱好者同在~

附1：新服务器配置

  • CPU：双路E5-2620
  • 内存：256GB DDR4
  • 硬盘：6T*12(HDD), 250G*2(SATA SSD), 480G(NVMe SSD)
  • 网卡：1Gbps*2

附2：服务迁移时间表

  • 2016-12-29:  切换教育网线路DNS（试运行）
  • 2016-12-30:  切换电信线路DNS（试运行）
  • 2016-12-31:  所有线路切换至新服务器。（需短暂停机，以交换新旧服务器IP地址）

update 2016-12-29：已修改教育网线路DNS记录

update 2016-12-30：已修改电信线路DNS记录

update 2016-12-31：整体迁移出现错误。ipv4成功，ipv6失败。

update 2017-1-1：IPv6恢复。迁移完成。

mirrors 外部磁盘阵列故障

2016年12月24日8点03分，mirrors外部磁盘阵列出现故障。目前，出现故障的镜像已重定向至其他镜像站。

技术细节：

最初，网卡挂掉一小会儿（可能是主板寿命快到了，近期网卡经常性故障）。iSCSI无法与外部阵列通讯。紧接着xfs文件系统出现错误，随后文件系统进入离线状态。

目前我们正在着手处理该问题，文件系统检查将会花费一些时间。

近期我们将上线新的服务器，届时将彻底解决设备老化带来的各种问题。

感谢您对科大开源镜像站的理解与支持。

mirrors 将逐步停用非标准域名

由于历史原因，科大开源软件镜像站拥有一批功能相同的域名，包括：

  • mirrors.ustc.edu.cn
  • ftp.cn.debian.org
  • debian.ustc.edu.cn
  • centos.ustc.edu.cn
  • oss.ustc.edu.cn

为了方便域名解析的切换与管理，我们计划逐步停用不常用的非标准域名，包括：

  • debian.ustc.edu.cn
  • centos.ustc.edu.cn
  • oss.ustc.edu.cn

请使用mirrors.ustc.edu.cn作为访问科大开源软件镜像站的首选域名。建议您尽早完成切换，避免日后使用出现问题。

注1: ctos.ustc.edu.cn由网络中心管理，与科大开源软件镜像站没有直接关系，不受影响。

注2: 计划时间表：

  • 2017年7月1日：停止非标准域名的rsync服务
  • 2018年1月1日：停止非标准域名的解析

mirrors 升级内存

tuna的Miao Wang赞助的48G内存到了，今天下午去机房安装，升级内存有助于缓解磁盘阵列压力。

不出意外的话，预计14:00~15:00之间完成安装，这一时间段mirrors暂停服务。

UPDATE: 已经成功安装，mirrors内存从16G升级到48G，从清华某报废机器上拆下来的12条内存正在发挥余热，虽然新机器还没到但硬盘负载高的问题应该可以得到很大改善。再次感谢tuna的帮助！

LUG权威DNS(mirrors)遭到DDOS攻击

2016年12月5日 1:48起，LUG权威DNS服务器遭到DDOS攻击，峰值流量150Mbps，最大包速率 200K pps，受攻击的域名为：*.mirrors.ustc.edu.cn。

攻击仍在持续中，LUG旗下所有服务均受到不同程度的影响。目前我们已进行了紧急处理，但由于攻击流量过大，DNS仍有几率解析失败。

另外，受此次攻击影响，科大开源镜像站负载过高，曾数次宕机。

给您带来的不便，我们深表歉意。

update 2016.12.5 7:00 a.m  攻击停止，DNS服务恢复正常

update 2016.12.6 0:00 a.m  第二波攻击开始

update 2016.12.6 3:00 a.m  第二波攻击结束

mirrors新机器暂时不能到，准备用dm-cache救急

mirrors目前去掉了bcache，最近也不怎么宕机了，但缺少ssd缓存给服务质量带来了很大影响。

网络中心帮忙筹备的新机器暂时还不能到货，如果恢复bcache还是会出现不定期宕机的问题。

所以我们前一阵子重新启用了原来根据nginx日志，每日缓存热文件到ssd的办法，但目前并没有很好地改善问题。

我们决定再尝试一下device-mapper提供的缓存机制，这个不需要重新格式化硬盘，而且可以解决bcache上文件系统于硬盘头部有8192字节不能直接挂载的问题。我们测试好之后会在深夜部署dm-cache，根据目前了解的资料应该不会遇到太多问题，缓存的部署和撤除不会对底层存储有太大影响。