关于Centos存储库镜像并选择最佳的镜像库

去年，我们为多个Linux发行版托管了在线镜像。 这不是一个复杂的过程，对于像Ubuntu这样的大型项目，它几乎是完全自动化的。 在其他情况下，您需要以一种或另一种方式（例如，在邮件列表中）联系该项目，并明确表达您的需求。


从技术上讲，它通常是按计划进行的rsync 。 有人为此提供了一组现成的脚本，例如Fedora，有人只是说您需要在这里从该服务器与推荐的参数集进行同步。 最昂贵的资源是位置，我们最近达到4 TB，在我们的情况下这是昂贵的，因为它不会产生任何利润。 作为回报，我们获得了所使用发行版的本地可用性，这使得可以消除服务器的强制Internet访问，从而简化了服务器的初始配置。 当然，即使我们参与程度不是很明显，我们也很高兴加入了一些大型活动。

我们的镜像是公开的，每个人都可以从中获得更新，如果通过上诉统计判断，这实际上是发生的。 这主要是俄罗斯，但不仅如此。 关于结果以及如何在本文的Centos第七版示例中选择通用服务器进行更新。

我们将讨论默认情况下安装了fastestmirror插件的yum软件包管理器，并且我们只会对选择特定镜像的过程感兴趣。

镜像列表

众所周知，除非另有说明，否则在/etc/yum.repos.d/目录中的文件中指定存储库列表。 这是/etc/yum.repos.d/Centos-Base.repo文件中的Base存储库设置：

 [base] name=CentOS-$releasever - Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 

在这里，您可以看到两个选项，它们指定了可以获取数据的位置。 第一个baseurl直接指向镜像，这里不需要选择。 第二个镜像列表指示一个链接，通过该链接将返回10个镜像的列表，从中可以进行选择，该选项处于活动状态。 我们还在链接内看到几个变量，它们最终都反映出存储库目录树中的特定位置：

• 发行版本： 6 8-stream 。 较旧的版本已从现有基础架构中撤出，但是其存储库的快照可以在http://vault.centos.org/找到。
• arch是i386或x86_64类的体系结构。 对于某些版本，某些体系结构将引用备用存储库和另一个镜像系统 ，但是与此同时，镜像选择基础结构仍然很常见。 对于版本7，唯一受支持的基本镜像是x86_64 ，它是i386的替代产品。 对于第一个，将在镜子的基本结构中形成一个列表，对于第二个，
• repo-在我们的例子中是os ，但是它可以是updates或其他updates ，实际上存储库的类型反映了我们需要的数据。 对于版本8，等效的os将是baseos
• 在下面 -我可以仔细地假设它仍然没有使用 ，至少在形成镜像列表时找不到它的处理。 它等于stock ，但是如果省略此参数，则不会出现可见的变化
• cc是国家代码；对于美国和加拿大，它也是州代码。 它不在上面的文件的示例中，因为在请求时，国家/地区是根据所请求的IP地址计算的。 此变量可用于消除地理位置错误。 对于俄罗斯， cc=ru

对于Centos的第7版，我们获得以下行： http ://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock，它将显示10种以下类型的镜像的列表：

 http://<   1>/7.xxx/os/x86_64/ http://<   2>/7.xxx/os/x86_64/ ... http://<   10>/7.xxx/os/x86_64/ 

请注意，每个镜像的特定路径与查询中的变量完全匹配。 尽管可以使用完整版本，但仍指示完整版本，尽管您也可以使用它： http://< >/7/os/x86_64/也存在，使用指向最新版本的符号链接实现。

实作

现在可以在https://github.com/CentOS/mirrorlists-code上找到实现，我们对镜像列表的形成方式很感兴趣。 Pearl脚本makemirrorlists-combined.pl做到了这一点 。 它的主要任务是通过将repodata/repomd.xml的哈希值与给定版本和体系结构的引用进行比较，以检查镜像的生命力。 因此，对于版本，存储库类型和体系结构的所有可用组合，文件必须存在。

验证按照以下顺序进行（我引用了代码）：

 # phase 1 -- this US state or Canada province # phase 2 -- this country # phase 3 -- other nearby countries # phase 4 -- mirrors from the same continent # phase 5 -- a random mirror from each continent (for fallback only) # note: phase 5 will be executed once for each continent (with "redo") # phase 6 -- random mirrors from any continent (for fallback only) # phase 7 -- centos servers from the same continent # phase 8 -- centos servers from other continents (used also for fallback) 

条款1和2起作用，或者不仅检查国家代码，而且检查州代码。 本质上，尝试选择最近的地理位置服务器。 对于每个步骤，都会从数据库中进行查询，例如：

 SELECT $columns FROM mirrors WHERE type IN ('Direct', 'Indirect') AND status = 'Active' AND cc = '$cc' AND $commonqueryparams $skipregion $altarch_where ORDER BY RAND(); 

然后，如上所述，通过比较散列来检查此列表中的反射镜是否具有生命力。 如果招募了10个人，则所需任务已完成，工作已完成。 如果您没有输入，请继续下一步，将常规列表设置为10，或者直到我们用尽所有选项为止。 将结果保存到文件中，并使用ml.py脚本传输到Python呈现的零件的前端，该脚本的任务是在首先通过IP地址找到请求源的国家/地区之后，选择并提供所需的文件。 还考虑了形成不同列表的IPv4或IPv6协议的类型。

返回使用ORDER BY RAND()的查询，这是否意味着列表将是随机的？ 是的，DBMS中实施的随机性如何，但这仅适用于每个步骤中的顺序。 也就是说，如果对于一个特定的国家，键入了超过10个所需的存储库和体系结构类型的镜像（对于俄罗斯，只有17个），那么最后，每次我们都会得到一个国家10个不同镜像的随机列表。 如果数量较少，则列表顶部将始终有一个国家/地区的经过改组的存储库，最近国家/地区的经过进一步改组的存储库，依此类推。 结果，我们得到一个不完全随机的列表，该列表由几个随机部分组成。 一个国家没有那么多工作镜像时很重要，例如，俄罗斯的IPv6镜像只有7个，它们将始终排在列表的首位：


更糟糕的是， i386架构是Centos 7和单独的镜像系统的替代架构。 在俄罗斯，只有这样一种服务器支持替代体系结构；它将始终排在首位：


该列表不再是随机的，如果您专注于第一行，则该选择是预先确定的。 对替代Centos体系结构的存储库的支持是一个原则问题 ，但是对于许多人来说，纯利他主义在这里。

连续扫描存储库，并且不考虑缓存机制，结果大约每3小时更新一次。 引用mirrorlist_crawler_deployment_notes.txt中的内容 ：

- A full scan of all repos and all versions without any cached data is going to take close to 3 hours, but typically altarch is <10min, C6 <25min, C7 <25min with all the repos enabled

实际上，我开始每分钟一次在俄罗斯为Base Centos 7存储库接收针对IPv4和IPv6的镜像列表选项-http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock&cc=en，结果是这样的经过几天的观察：


蓝色的IPv4列表，红色的IPv6。 更改不会每25分钟发生一次，但不会每3小时一次-一切都介于半小时到两小时之间。 具有i386架构和备用镜的图片完全不同i386 &infra=stock&cc= http://mirrorlist.centos.org/?release=7&arch=i386&repo=os&infra=stock&cc=ru大约需要一周的观察时间：


我们可以预期，每15分钟就会有一个新列表，在30分钟内会发生一些变化。 但是！ 请记住，活动镜像越少，顺序的随机性就越小，而在俄罗斯，首先始终是相同的镜像。

最快的镜子

总而言之，镜像列表最多是偶然形成的，这对于负载平衡来说可能还不错。 最糟糕的是，我们可以期望仅从列表中选择第一个镜像，因此我们将别无选择。 此外，在像我们这样的大国中，国家的区域划分也可以发挥作用，方法是将Petropavlovsk-Kamchatsky http://mirror.vilkam.ru的镜子放在清单顶部，以索契的客户为重。 因此，最好从该列表中评估镜像的可用性。 这是由最快的镜像插件完成的 。 其实质简化为一个简单的动作：

 time_before = time.time() sock.connect((self.host, self.port)) result = time.time() - time_before 

没有HTTP或ICMP ，打开节点的套接字，考虑花费了多少时间，对结果应用sort() 。 上一步中获得的所有10个镜像均以完整URL的形式作为参数发送，其中仅使用主机名。 该插件易于与yum分开工作，只需注释掉第52和55行：

 # from yum.plugins import TYPE_CORE requires_api_version = '2.5' # plugin_type = (TYPE_CORE,) 

处理是在多个线程中进行的，因此您不必等待很长时间，即使对于俄罗斯列出的所有17个镜像也是如此。 工作的结果以两个列表的形式进行了调试，并且未进行排序，尽管看起来似乎是这样，但它们以两个列表的形式显示了执行时间。 在Result从较小的响应到较大的响应排序之后的第二秒，是他按接收到的顺序用于进一步的工作。

Dnf还使用RPM库集中的最快镜像 ，但是在那里可以通过libcurl解决，并且一般来说，所有操作都比较复杂。

最后，这完全取决于接收到来自镜像的响应的速度，同时应考虑缓存，即，并非总是直接计算延迟。 时间间隔受本地计算机的内部性能及其工作负载的影响很大。 显示相似结果的关闭节点可能会经常更改位置。 但是在这里实现了这一目标，在我看来，主要目标不是将索契的一个节点更新到彼得罗巴甫洛夫斯克-堪察加，去莫斯科或伏尔加格勒是可以接受的。 我们还要注意什么，是从fastestmirror之前第一步收到的列表中进行选择的，如果此数据尚未在缓存中，则第一次尝试时最接近的镜像可能不是最佳的，仅仅是因为即使不进入也不会对其进行分析前十名。

实际上，每周一次的调查每10分钟获得以下第一名的结果。 fastestmirror比较fastestmirror和fastestmirror期间在比较中赢得了多少个节点的次数：

1422,1013 mirror.logol.ru
534,986 mirror.docker.ru
28,8 mirrors.datahouse.ru
16 centos-mirror.rbc.ru
6 mirror.sale-dedic.com
5,7 mirror.reconn.ru
2 dedic.sh
1 mirror.corbina.net

和IPv6版本列表：

1989,1980 mirror.reconn.ru
18,34 mirror.sale-dedic.com
7 dedic.sh


可以看出，选择并不是直接明确的，但是在这里，我进行调查的起点附近很可能会起作用-多达几面镜子，相差不到一毫秒。 第二点，IPv6列表不同，而且更糟-最近的IPv6主机比最近的IPv4主机更远，选择范围更小。 鉴于IPv6的优先级不是很好。 fping的结果fping简洁，获胜的节点更少，但通常与fastestmirror相同。

成熟的地图集

有了本地选择，一切都差不多了，现在让我们看看整个国家的情况。 我们为什么要使用服务https://atlas.ripe.net/-在RIPE NCC的主持下，一组用于与它们一起工作的探针（探针）和工具，我会立即警告您，这不是最快，最灵活的网站。 任何人都可以进行探查，也可以使用此网络。 但是要运行测试，您需要一种内部货币，该内部货币是从您注册之后并处于活动状态的设备中累积的。 在俄罗斯，我选择了同时支持IPv6和IPv4的所有设备，其中有82台设备被淘汰，根据测量结果，必须淘汰其中的一部分，因此在400多个设备中 ，有67 个设备仍然存在。

您可以运行多种测试选项，当然， fastestmirror没有使用什么fastestmirror ，但是有定期的ping 。 对于所有镜像， mirror.linux-ia64.org要每3小时从所有选定的设备（分别针对IPv6和IPv4 ICMP筛选出ICMP的mirror.linux-ia64.org和完成测试后出现的mirror.linux-ia64.org除外。每个请求10个。 记录平均响应时间。 在整个测量中，每个反射镜约50个，取中值并将其与该探头上的其他反射镜进行比较。 响应时间最短的镜子获胜。


探针（蓝色标记）和反射镜（红色标记）分布不均匀，并且倾向于大写字母，因此不应将结果视为重要的东西。 原始数据从测量编号23159879到23159901开始可用，如果需要，可以对它们进行更严格的分析。 IPv4的首位汇总总数：

22 mirror.docker.ru
12 mirror.awanti.com
10 centos-mirror.rbc.ru
6 dedic.sh
4 mirror.truenetwork.ru
3 mirror.corbina.net
3 mirrors.powernet.com.ru
2 ftp.nsc.ru
2 mirrors.datahouse.ru
1 mirror.reconn.ru
1 mirror.vilkam.ru
1 mirror.yandex.ru


和IPv6：

20 dedic.sh
20 mirror.reconn.ru
10 mirror.yandex.ru
8 mirror.sale-dedic.com
5 ftp.nsc.ru
3 mirror.corbina.net
1 mirrors.powernet.com.ru


可以说，对于几乎所有的镜子，我都会提醒他们有17个消费者。 有趣的mirror.yandex.ru mirror.vilkam.ru和Petropavlovsk-Kamchatsky的mirror.vilkam.ru一起mirror.yandex.ru在最后。 同时，Yandex几乎可以在任何地方使用，每次都失去一点响应能力，但是mirror.vilkam.ru赢了一次，但与哈巴罗夫斯克（ mirror.vilkam.ru的6606探针相比，坦白地说，它比其他人还多：

centos-mirror.rbc.ru,105.4163369
dedic.sh,109.2160474
ftp.nsc.ru,106.4012836
mirror.awanti.com,107.0802782
mirror.corbina.net,98.5339837
mirror.docker.ru,102.7883347
mirror.logol.ru,105.9588192
mirror.reconn.ru,106.5717624
mirror.sale-dedic.com,106.1676841
mirror.truenetwork.ru,110.9780753
mirror.tversu.ru,107.9966083
mirror.vilkam.ru,25.1486164
mirror.yandex.ru,99.7320257
mirrors.datahouse.ru,103.6546383
mirrors.powernet.com.ru,116.4087614


最好的结果在1毫秒或几毫秒的范围内，而最差的结果在Salekhard的探针22767中响应：

centos-mirror.rbc.ru,59.9632155
dedic.sh,63.765421
ftp.nsc.ru,59.349309
mirror.awanti.com,75.8998928571
mirror.corbina.net,59.906047
mirror.docker.ru,65.8720585
mirror.logol.ru,63.2041255
mirror.reconn.ru,63.7120505
mirror.sale-dedic.com,63.052342
mirror.truenetwork.ru,61.2567465
mirror.tversu.ru,66.2593372222
mirror.vilkam.ru,138.3730595
mirror.yandex.ru,63.4150445
mirrors.datahouse.ru,59.304435
mirrors.powernet.com.ru,78.7411795


后记

对于那些到达这个地方的人，我将回答将会提出的问题-我们的镜像http://mirrors.powernet.com.ru ，下面是它的用法：



此外，来自我们网络的流量份额可以忽略不计。

这是地方的结束方式：


当我们添加新的分发时，很容易区分的步骤。 当一切开始时，是VirtualBox在办公室计算机上的Windows上运行，该办公室中存储了我们广告部门的视频档案。 然后我们转到了战斗虚拟化系统，它变得容易一些：


为了进行比较， mirror.truenetwork.ru从两台服务器返回3 Gb / s的流量。 一切对我们来说都比较温和，总的来说，这足以让我们享受流程，以及当有人在更新系统时注意到突然熟悉的台词时，来自朋友和订户的罕见而热情的评论。 而且，有时在各种文章和手册中，背景在闪烁，在日志或屏幕截图中可以看到指向我们镜像的链接。

您可以在此处查看 Centos中所有已知镜像的状态，并在此处了解如何加入该项目，它既简单又负责，但当然也没有用。