À propos des miroirs du référentiel Centos et choisir le meilleur

L'année dernière, nous avons hébergé des miroirs en ligne pour plusieurs distributions Linux. Ce n'est pas un processus compliqué et pour les grands projets comme Ubuntu, il est presque entièrement automatisé. Dans d'autres cas, il est nécessaire d'une manière ou d'une autre de contacter le projet, par exemple, sur la liste de diffusion et d'exprimer clairement votre désir.


Techniquement, c'est rsync , généralement selon un horaire. Quelqu'un pour cela fournit un ensemble de scripts prêt à l'emploi, comme Fedora, et quelqu'un dit simplement que vous devez synchroniser ici à partir de ce serveur et l'ensemble de paramètres recommandé. La ressource la plus chère est l'endroit, on est récemment arrivé à 4 téraoctets et c'est cher dans notre cas car cela ne génère aucun profit. En retour, nous avons reçu une disponibilité locale des distributions que nous utilisons, ce qui a permis de simplifier la configuration initiale des serveurs en en supprimant l'accès Internet obligatoire. Et bien sûr, nous sommes heureux d'avoir rejoint quelque chose de grand, même si notre participation à ce projet n'est pas très perceptible.

Notre miroir est public, tout le monde peut en recevoir des mises à jour, ce qui se produit en fait s'il est jugé par les statistiques des appels. C'est principalement la Russie, mais pas seulement. A propos de la façon dont cela se passe et comment le serveur général est sélectionné pour les mises à jour sur l'exemple de la septième version de Centos de ce message.

Nous parlerons du gestionnaire de paquets yum avec le fastestmirror le plus fastestmirror installé par défaut et nous ne serons intéressés que par le processus de sélection d'un miroir spécifique.

Liste des miroirs

Il est connu que la liste des référentiels est spécifiée dans les fichiers du répertoire /etc/yum.repos.d/ sauf indication contraire. Voici à quoi ressemblent les paramètres du référentiel de Base dans le fichier /etc/yum.repos.d/Centos-Base.repo :

 [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 

Ici, vous pouvez voir deux options qui spécifient l'endroit où vous pouvez obtenir des données. Le premier baseurl pointe directement vers le miroir, aucun choix n'est nécessaire ici. La deuxième liste de miroirs indique un lien par lequel une liste de 10 miroirs sera renvoyée à partir de laquelle le choix sera fait, c'est cette option qui est active. Nous voyons également plusieurs variables à l'intérieur du lien, toutes reflétant finalement une place spécifique dans l'arborescence de répertoires du référentiel:

• version - version: 6 , 7 , 8 , 8-stream . Les anciennes versions sont retirées de l'infrastructure existante, mais des instantanés de leurs référentiels peuvent être trouvés sur http://vault.centos.org/
• arch est une architecture telle que i386 ou x86_64 . Pour certaines versions, certaines architectures feront référence à des référentiels alternatifs et à un autre système miroir , mais en même temps, l'infrastructure de sélection de miroir reste courante. Pour la version 7, le seul miroir de base pris en charge est x86_64 , une alternative à i386 . Pour le premier, une liste sera formée dans la structure de base des miroirs, pour le second de l'alternative
• repo - dans notre cas, os , mais il peut s'agir de updates à updates ou autre, en fait le type de référentiel reflète les données dont nous avons besoin. Pour la version 8, l'équivalent de os sera baseos
• infra - Je peux soigneusement supposer qu'il n'est toujours pas utilisé , au moins je n'ai pas pu trouver son traitement lors de la formation d'une liste de miroirs. Il est égal au stock , mais si vous omettez ce paramètre, aucun changement visible ne suivra
• cc est le code du pays; pour les États-Unis et le Canada, c'est aussi le code de l'État. Ce n'est pas dans l'exemple du fichier ci-dessus, puisque le pays est calculé lorsqu'il est demandé par l'adresse IP du demandé. Cette variable peut être utilisée pour éliminer les erreurs de géolocalisation. Pour la Russie, cc=ru

Pour la 7e version de Centos, nous obtenons la ligne suivante: http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock , qui produira une liste de 10 miroirs du type suivant:

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

Notez que le chemin spécifique de chaque miroir correspond exactement aux variables de la requête. La version complète est indiquée à la place de l'ancienne, bien que vous puissiez également l'utiliser: http://< >/7/os/x86_64/ existe également, implémenté à l'aide d'un lien symbolique vers la dernière version.

Implémentation

Maintenant pour l'implémentation, qui peut être trouvée sur https://github.com/CentOS/mirrorlists-code , nous sommes intéressés par la façon dont la liste des miroirs est formée. Le script perle makemirrorlists-combined.pl le fait . Sa tâche principale est de vérifier la vitalité du miroir en comparant le hachage du repodata/repomd.xml avec la référence de la version et de l'architecture données. Par conséquent, le fichier doit exister pour toutes les combinaisons disponibles de versions, types de référentiels et architecture.

La vérification s'effectue selon la liste dans l'ordre suivant (je cite le code):

 # 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) 

Les articles 1 et 2 fonctionnent soit pour vérifier non seulement le code du pays, mais aussi le code de l'État. En substance, une tentative est effectuée pour sélectionner les serveurs géographiquement les plus proches. Pour chaque étape, une requête est faite à partir de la base de données, par exemple:

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

Ensuite, il y a une vérification de la vitalité des miroirs sur cette liste en comparant les hachages, comme décrit ci-dessus. Si 10 personnes sont recrutées, la tâche requise est terminée, le travail est terminé. Si vous ne tapez pas, passez à l'étape suivante pour obtenir la liste générale à 10 ou jusqu'à ce que nous ayons épuisé toutes les options. Le résultat est enregistré dans un fichier et transféré à la partie frontale de la pièce présentée par Python avec le script ml.py , dont la tâche est de sélectionner et de donner le fichier souhaité, après avoir d'abord découvert le pays de la source de la requête par adresse IP. Le type de protocole IPv4 ou IPv6, pour lequel différentes listes sont formées, est également pris en compte.

Retour à la requête qui utilise ORDER BY RAND() , cela signifie-t-il que la liste sera aléatoire? Oui, à quel point l'implémentation est aléatoire dans le SGBD, mais cela ne s'applique qu'à l'ordre dans chaque étape. Autrement dit, si pour un pays particulier plus de 10 miroirs du type de référentiel et d'architecture requis sont typés (pour la Russie, il n'y en a que 17), à la fin, chaque fois, nous obtiendrons une liste mélangée de 10 miroirs différents dans un pays. S'il y en a moins, en haut de la liste, il y aura toujours des référentiels mélangés d'un pays, d'autres référentiels mélangés des pays les plus proches, et ainsi de suite par étapes. En conséquence, nous obtenons une liste non entièrement aléatoire composée de plusieurs parties aléatoires. Cela compte quand il n'y a pas autant de miroirs fonctionnels dans un pays, par exemple, les miroirs IPv6 en Russie ne sont que 7 et ils seront toujours en tête de liste:


Pire encore, l'architecture i386 est une architecture alternative pour Centos 7 et un système de miroir séparé. En Russie, il n'y a qu'un seul serveur de ce type qui prend en charge des architectures alternatives; ce sera toujours en premier lieu:


La liste n'est plus aléatoire, si vous vous concentrez sur la première ligne, le choix est prédéterminé. La prise en charge des référentiels pour les architectures Centos alternatives est une question de principe, mais pour beaucoup, l'altruisme pur est là.

Les référentiels sont analysés en continu et sans tenir compte des mécanismes de mise en cache, le résultat est mis à jour toutes les 3 heures environ. Citation de 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

En pratique, j'ai commencé à obtenir des options de liste miroir en Russie pour IPv4 et IPv6 une fois par minute pour le référentiel Base Centos 7 - http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock&cc=ru et cela s'est avéré comme ceci pour quelques jours d'observation:


liste IPv4 bleue, IPv6 rouge. Le changement ne se produit pas toutes les 25 minutes, mais pas une fois toutes les 3 heures - tout tient dans l'intervalle d'une demi-heure à deux. L'image avec l'architecture i386 et les miroirs alternatifs est radicalement différente - http://mirrorlist.centos.org/?release=7&arch=i386&repo=os&infra=stock&cc=ru environ une semaine d'observation:


Nous pouvons nous attendre à ce que toutes les 15 minutes, nous aurons une nouvelle liste, dans 30 minutes, des changements seront apportés. Mais! N'oubliez pas que moins les miroirs sont actifs, moins l'ordre est aléatoire et, en premier lieu, maintenant en Russie, c'est toujours le même miroir.

Le plus rapide des miroirs

Au total, la liste des miroirs se forme au mieux par hasard, ce qui n'est sans doute pas mauvais pour l'équilibrage de charge. Au pire, nous pouvons nous attendre à ne choisir que le premier miroir de la liste, nous n'aurons pas le choix en tant que tel. De plus, la division territoriale des pays dans le cas d'un grand pays comme le nôtre peut jouer un tour en plaçant en tête de liste un miroir de Petropavlovsk-Kamchatsky http://mirror.vilkam.ru pour le client de Sotchi. Par conséquent, il serait bon d'évaluer la disponibilité des miroirs de cette liste. Cela se fait par le plugin de miroir le plus rapide . Dont l'essence se résume à une simple action:

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

Pas de HTTP ou ICMP , ouvrez le socket pour le nœud, considérez combien de temps cela a pris, appliquez sort() aux résultats. Tous les 10 miroirs obtenus à l'étape précédente sont envoyés en tant que paramètres, sous la forme de l' URL complète à partir de laquelle seul le nom d'hôte est utilisé. Le plugin est facile à faire fonctionner séparément de yum , il vous suffit de commenter les lignes 52 et 55:

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

Le traitement se déroule en plusieurs threads, vous n'avez donc pas à attendre longtemps, même pour les 17 miroirs répertoriés en Russie. Le résultat d'un travail sous forme de deux listes, la première dans laquelle le temps d'exécution est indiqué, est le débogage et il n'est pas trié, même si cela peut sembler le cas. La seconde après le mot Result triée d'une réponse plus petite à une réponse plus grande, c'est lui qui est utilisé pour d'autres travaux dans l'ordre reçu.

dnf utilise également le dnf plus rapide de l'ensemble des bibliothèques RPM, mais là, il est résolu via libcurl et en général tout est plus compliqué.

En fin de compte, tout dépend de la rapidité avec laquelle la réponse du miroir est reçue, tandis que la mise en cache doit être prise en compte, c'est-à-dire que le calcul direct du retard n'est pas toujours effectué. Les intervalles de temps sont grandement affectés par les performances internes de la machine locale et sa charge de travail. Les nœuds proches montrant des résultats similaires changeront probablement fréquemment de place. Mais ici c'est fait, il me semble que l'objectif principal n'est pas d'envoyer un nœud de Sotchi pour renouvellement à Petropavlovsk-Kamchatsky, se rendre à Moscou ou Volgograd est tout à fait acceptable. À quoi d'autre faisons-nous attention, le choix est fait à partir de la liste qui a été reçue à la première étape avant le fastestmirror , si ces données ne sont pas encore dans le cache, alors le miroir le plus proche au premier essai peut ne pas être le meilleur, simplement parce qu'il ne sera même pas analysé sans entrer dans le top dix.

Dans la pratique, les résultats suivants ont été obtenus lors d'une enquête hebdomadaire toutes les 10 minutes. Chiffres - le nombre de fois combien de nœuds ont gagné au cours de la comparaison, pour un fastestmirror et un 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

Et version IPv6 de la liste:

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


On peut voir que le choix n'est pas directement sans ambiguïté, mais ici la proximité du point à partir duquel j'ai effectué l'enquête joue probablement un rôle - jusqu'à plusieurs miroirs, la différence est inférieure à une milliseconde. Le deuxième point, la liste IPv6 est différente et c'est pire - l'hôte IPv6 le plus proche est plus loin que l'IPv4 le plus proche et le choix est moins. Étant donné la priorité d'IPv6, ce n'est pas très bon. Les résultats de fping concis, moins de nœuds gagnants, mais sont généralement les mêmes avec le fastestmirror .

Atlas mûr

Avec un choix local, tout est plus ou moins clair, voyons maintenant comment les choses se passent dans tout le pays. Pourquoi utilisons-nous les services https://atlas.ripe.net/ - un ensemble de sondes (sondes) et d'outils pour travailler avec eux sous les auspices de RIPE NCC, je vous avertis immédiatement, ce n'est pas le site le plus rapide et le plus agile. Tout le monde peut obtenir une sonde et utiliser ce réseau. Mais pour exécuter les tests, vous avez besoin d'une devise interne qui s'accumule à partir des appareils enregistrés et actifs après vous. J'ai choisi tous les appareils en Russie qui prennent en charge IPv6 et IPv4 en même temps, 82 d'entre eux se sont révélés. Selon les résultats des mesures, une partie devait être éliminée, il en restait donc 67 sur plus de 400 .

Il existe plusieurs options de test que vous pouvez exécuter, bien sûr, il n'y a pas ce qui est utilisé dans le fastestmirror , mais il y a un ping régulier. Pour tous les miroirs, à l'exception de mirror.linux-ia64.org pour lequel ICMP filtré et mirror.axelname.ru qui est apparu après les tests, à partir de tous les périphériques sélectionnés, séparément pour IPv6 et IPv4, toutes les 3 heures pendant une semaine 10 demandes chacune. Le temps de réponse moyen a été enregistré. Sur l'ensemble des mesures, environ 50 pour chaque miroir, la médiane a été prise et comparée à d'autres miroirs sur cette sonde. Le miroir avec le temps de réponse le plus court a gagné.


Les sondes (marqueurs bleus) et les miroirs (marqueurs rouges) sont distribués de manière trop inégale et gravitent vers les capitales, de sorte que les résultats ne doivent pas être considérés comme quelque chose de significatif. Les données brutes sont disponibles à partir du numéro de mesure 23159879 à 23159901 , si vous le souhaitez, elles peuvent être analysées plus strictement. Nombre total résumé de premières places pour 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


et 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


On peut dire que pour presque tous les miroirs, je leur rappelle 17, il y a des consommateurs. Il est intéressant de mirror.yandex.ru que mirror.yandex.ru dernière place avec mirror.vilkam.ru de Petropavlovsk-Kamchatsky. En même temps, Yandex est disponible presque partout, il perd un peu plus de réactivité à chaque fois, mais mirror.vilkam.ru gagne une fois, mais plus mirror.vilkam.ru par rapport aux autres sur la sonde 6606 de Khabarovsk (RTT en millisecondes):

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


Les meilleurs résultats dans la région d'une ou plusieurs millisecondes, et le pire résultat en réponse à Salekhard, sonde 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


Postface

Pour ceux qui sont arrivés à cet endroit, je répondrai à la question qui sera posée - notre miroir http://mirrors.powernet.com.ru et voici comment il est utilisé:



De plus, la part de ce trafic provenant de notre réseau est négligeable.

Voici comment se termine l'endroit:


Les étapes bien distinctes sont des moments où nous ajoutons une nouvelle distribution. Au début, VirtualBox fonctionnait sous Windows sur un ordinateur de bureau sur lequel étaient stockées les archives vidéo de notre service de publicité. Ensuite, nous sommes passés au système de virtualisation de combat et c'est devenu un peu plus facile:


À titre de comparaison, mirror.truenetwork.ru renvoie un trafic de 3 Gb / s à partir de deux serveurs. Tout est beaucoup plus modeste avec nous et, en général, il nous suffit largement d'apprécier le processus, ainsi que les rares critiques enthousiastes d'amis et d'abonnés lorsque quelqu'un remarque des lignes soudainement familières lors de la mise à jour de leur système. Et aussi, scintillant parfois en arrière-plan dans divers articles et manuels, où les liens vers notre miroir sont visibles dans les journaux ou les captures d'écran.

Vous pouvez voir l'état de tous les miroirs connus dans Centos ici , et lire comment rejoindre le projet ici , c'est à la fois simple et responsable à la fois, mais certainement pas inutile.