Informationen zu Centos Repository-Spiegeln und zur Auswahl des besten

Letztes Jahr haben wir Online-Spiegel für verschiedene Linux-Distributionen gehostet. Dies ist kein komplizierter Prozess und für große Projekte wie Ubuntu ist es fast vollständig automatisiert. In anderen Fällen müssen Sie das Projekt auf die eine oder andere Weise kontaktieren, z. B. über die Mailingliste, und Ihren Wunsch ausdrücklich äußern.


Technisch ist es rsync , in der Regel nach einem Zeitplan. Jemand stellt dafür fertige Skripte zur Verfügung, wie Fedora, und jemand sagt nur, dass Sie von diesem Server aus und mit den empfohlenen Parametern hier synchronisieren müssen. Die teuerste Ressource ist der Ort, wir haben vor kurzem 4 Terabyte und dies ist in unserem Fall teuer, weil es keinen Gewinn generiert. Im Gegenzug erhielten wir die lokale Verfügbarkeit der von uns verwendeten Distributionen. Dies ermöglichte es, die Erstkonfiguration von Servern zu vereinfachen, indem der obligatorische Internetzugang wegfiel. Und natürlich freuen wir uns, dass wir uns etwas Großem angeschlossen haben, auch wenn unsere Teilnahme daran nicht sehr auffällig ist.

Unser Spiegel ist öffentlich, jeder kann Updates davon erhalten, was tatsächlich passiert, wenn man die Statistik der Berufungen beurteilt. Dies ist vor allem Russland, aber nicht nur. Wie es ausgeht und wie der allgemeine Server für Updates ausgewählt wird, erfahren Sie am Beispiel der siebten Centos-Version dieses Beitrags.

Wir werden über den yum Paketmanager sprechen, auf dem das fastestmirror Plugin standardmäßig installiert ist, und uns nur für den fastestmirror eines bestimmten Spiegels interessieren.

Liste spiegeln

Es ist bekannt, dass die Liste der Repositorys in den Dateien im Verzeichnis /etc/yum.repos.d/ angegeben ist, sofern nicht anders angegeben. So sehen die Einstellungen des Base Repositorys in der Datei /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 

Hier sehen Sie zwei Optionen, die den Ort angeben, an dem Sie Daten abrufen können. Die erste Baseurl zeigt direkt auf den Spiegel, hier ist keine Wahl erforderlich. Die zweite Spiegelliste gibt einen Link an, über den eine Liste mit 10 Spiegeln zurückgegeben wird, über die die Auswahl getroffen wird. Diese Option ist aktiv. Wir sehen auch verschiedene Variablen im Link, die letztendlich alle eine bestimmte Stelle im Repository-Verzeichnisbaum widerspiegeln:

• release - version: 6 , 7 , 8 , 8-stream . Ältere Versionen werden aus der vorhandenen Infrastruktur entfernt, Snapshots ihrer Repositorys finden Sie jedoch unter http://vault.centos.org/.
• arch ist eine architektur wie i386 oder x86_64 . In einigen Versionen beziehen sich einige Architekturen auf alternative Repositorys und ein anderes Spiegelsystem , gleichzeitig bleibt die Infrastruktur für die Spiegelauswahl jedoch weiterhin gebräuchlich. Für Version 7 ist x86_64 , eine Alternative zu i386 , der einzige unterstützte Basisspiegel. Zum einen wird in der Grundstruktur der Spiegel eine Liste gebildet, zum anderen die Alternative
• repo - in unserem Fall os , aber es können updates oder andere sein, tatsächlich spiegelt der Repository-Typ wider, welche Daten wir benötigen. In Version 8 ist das Äquivalent von os baseos
• infra - Ich kann mit Bedacht davon ausgehen, dass es immer noch nicht verwendet wird , zumindest konnte ich seine Verarbeitung beim Erstellen einer Liste von Spiegeln nicht finden. Es ist gleich stock , aber wenn Sie diesen Parameter weglassen, werden keine sichtbaren Änderungen folgen
• cc ist die Landesvorwahl, für die USA und Kanada auch die Landesvorwahl. Dies ist im obigen Beispiel nicht der Fall, da das Land auf Anforderung anhand der IP-Adresse des angeforderten Landes berechnet wird. Diese Variable kann verwendet werden, um Geolocation-Fehler zu beseitigen. Für Russland ist cc=ru

Für die 7. Version von Centos erhalten wir die folgende Zeile: http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock, in der eine Liste von 10 Spiegeln der folgenden Art angezeigt wird:

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

Beachten Sie, dass der spezifische Pfad für jeden Spiegel genau mit den Variablen in der Abfrage übereinstimmt. Die Vollversion wird anstelle der älteren Version angezeigt, obwohl Sie sie auch verwenden können: http://< >/7/os/x86_64/ ebenfalls vorhanden und wird über einen symbolischen Link zur neuesten Version implementiert.

Implementierung

Nun interessiert uns für die Implementierung, die unter https://github.com/CentOS/mirrorlists-code zu finden ist, wie die Liste der Spiegel gebildet wird. Das Perlenskript makemirrorlists-combined.pl macht das . Seine Hauptaufgabe besteht darin, die Vitalität des Spiegels zu überprüfen, indem der Hash der repodata/repomd.xml mit der Referenz für die angegebene Version und Architektur verglichen wird. Dementsprechend muss die Datei für alle verfügbaren Kombinationen von Versionen, Repository-Typen und Architekturen vorhanden sein.

Die Überprüfung erfolgt gemäß der Liste in der folgenden Reihenfolge (ich zitiere aus dem 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) 

Die Absätze 1 und 2 funktionieren entweder oder überprüfen nicht nur die Landesvorwahl, sondern auch die Landesvorwahl. Im Wesentlichen wird versucht, die nächstgelegenen geografischen Server auszuwählen. Für jeden Schritt wird eine Abfrage aus der Datenbank durchgeführt, zum Beispiel:

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

Anschließend wird die Vitalität der Spiegel in dieser Liste überprüft, indem die oben beschriebenen Hashes verglichen werden. Wenn 10 Personen eingestellt sind, ist die erforderliche Aufgabe erledigt, die Arbeit ist erledigt. Wenn Sie nichts eingeben, fahren Sie mit dem nächsten Schritt fort, um die allgemeine Liste auf 10 zu setzen, oder bis alle Optionen ausgeschöpft sind. Das Ergebnis wird in einer Datei gespeichert und mit dem ml.py- Skript an das Front-End des von Python präsentierten Teils übertragen . Die Aufgabe besteht darin, die gewünschte Datei auszuwählen und anzugeben , nachdem das Quellland der Anforderung anhand der IP-Adresse ermittelt wurde. Der Typ des IPv4- oder IPv6-Protokolls, für das unterschiedliche Listen erstellt werden, wird ebenfalls berücksichtigt.

ORDER BY RAND() dies, dass die Liste zufällig ist, wenn Sie zu der Abfrage zurückkehren, die ORDER BY RAND() ? Ja, wie zufällig die Implementierung im DBMS ist, dies gilt jedoch nur für den Auftrag innerhalb jedes Schritts. Das heißt, wenn für ein bestimmtes Land mehr als 10 Spiegel des gewünschten Repository- und Architekturtyps eingegeben werden (für Russland sind es nur 17), erhalten wir am Ende jedes Mal eine gemischte Liste von 10 verschiedenen Spiegeln in einem Land. Wenn weniger Repositorys vorhanden sind, werden am Anfang der Liste immer Repositorys aus einem Land gemischt, weitere Repositorys aus den nächstgelegenen Ländern gemischt und so weiter. Als Ergebnis erhalten wir eine nicht ganz zufällige Liste, die aus mehreren zufälligen Teilen besteht. Es ist wichtig, wenn es in einem Land nicht so viele funktionierende Spiegel gibt, zum Beispiel, IPv6-Spiegel in Russland sind nur 7 und sie werden immer ganz oben auf der Liste stehen:


Schlimmer noch, die i386 Architektur ist eine alternative Architektur für Centos 7 und ein separates Spiegelsystem. In Russland gibt es nur einen solchen Server, der alternative Architekturen unterstützt und der immer an erster Stelle stehen wird:


Die Liste ist nicht mehr zufällig, wenn Sie sich auf die erste Zeile konzentrieren, ist die Auswahl vorbestimmt. Die Unterstützung von Repositorys für alternative Centos-Architekturen ist ein grundsätzliches Anliegen , aber für viele ist hier reiner Altruismus.

Repositorys werden kontinuierlich gescannt und ohne Berücksichtigung der Caching-Mechanismen wird das Ergebnis ungefähr alle 3 Stunden aktualisiert. Zitat aus 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

In der Praxis erhielt ich in Russland einmal pro Minute Spiegellistenoptionen für IPv4 und IPv6 für das Base Centos 7-Repository - http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock&cc=ru für ein paar Beobachtungstage:


blaue IPv4-Liste, rote IPv6. Der Wechsel erfolgt nicht alle 25 Minuten, sondern nicht alle 3 Stunden - alles passt in den Intervall von einer halben bis zwei Stunden. Das Bild mit der i386 Architektur und alternativen Spiegeln unterscheidet sich radikal - http://mirrorlist.centos.org/?release=7&arch=i386&repo=os&infra=stock&cc=ru etwa eine Woche Beobachtung:


Wir können davon ausgehen, dass alle 15 Minuten eine neue Liste erstellt wird. In 30 Minuten werden einige Änderungen daran vorgenommen. Aber! Denken Sie daran, dass die Reihenfolge umso weniger zufällig ist, je weniger aktive Spiegel sind. In Russland ist dies in erster Linie immer derselbe Spiegel.

Schnellster Spiegel

Insgesamt wird die Liste der Spiegel bestenfalls zufällig gebildet, was für den Lastausgleich wahrscheinlich nicht schlecht ist. Im schlimmsten Fall können wir davon ausgehen, dass wir bei der Auswahl nur des ersten Spiegels aus der Liste keine andere Wahl haben. Darüber hinaus kann die territoriale Aufteilung der Länder in einem großen Land wie dem unseren einen Streich spielen, indem ein Spiegel von Petropawlowsk-Kamtschatski http://mirror.vilkam.ru für den Kunden aus Sotschi ganz oben auf der Liste steht. Daher wäre es schön, die Verfügbarkeit von Spiegeln aus dieser Liste zu bewerten. Dies erledigt das schnellste Mirror Plugin. Das Wesentliche davon ist auf eine einfache Handlung reduziert:

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

Kein HTTP oder ICMP , öffnen Sie den Socket für den Knoten, überlegen Sie, wie lange es gedauert hat, und wenden Sie sort() auf die Ergebnisse an. Alle 10 Spiegel, die im vorherigen Schritt erhalten wurden, werden als Parameter in Form der vollständigen URL gesendet, von der nur der Hostname verwendet wird. Das Plugin ist einfach zu bedienen, Sie müssen nur die Zeilen 52 und 55 auskommentieren:

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

Die Verarbeitung erfolgt in mehreren Threads, sodass Sie nicht lange warten müssen, auch nicht auf alle 17 in Russland aufgeführten Spiegel. Das Ergebnis der Arbeit in Form von zwei Listen, in der die Ausführungszeit angegeben ist, ist das Debuggen und es wird nicht sortiert, obwohl es so scheint. Die Sekunde, nachdem das Wort Result von einer kleineren zu einer größeren Antwort sortiert wurde, ist es, die für die weitere Arbeit in der erhaltenen Reihenfolge verwendet wird.

dnf auch den schnellste Spiegel aus der Menge der RPM-Bibliotheken, aber dort wird er durch libcurl gelöst und im Allgemeinen ist alles komplizierter.

Letztendlich hängt alles davon ab, wie schnell die Antwort vom Spiegel empfangen wird, während das Zwischenspeichern berücksichtigt werden sollte, dh die direkte Berechnung der Verzögerung wird nicht immer durchgeführt. Die Zeitintervalle werden stark von der internen Leistung der lokalen Maschine und ihrer Arbeitslast beeinflusst. Nahe Knoten mit ähnlichen Ergebnissen werden wahrscheinlich häufig die Position wechseln. Aber hier ist es erreicht, es scheint mir, dass das Hauptziel nicht ist, einen Knoten von Sotschi zur Erneuerung nach Petropawlowsk-Kamtschatski zu senden, nach Moskau zu gehen oder Wolgograd ist durchaus akzeptabel. Worauf wir sonst noch achten, die Auswahl wird aus der Liste getroffen, die im ersten Schritt vor dem fastestmirror Spiegel fastestmirror wurde. Wenn diese Daten noch nicht im Cache sind, ist der nächste Spiegel beim ersten Versuch möglicherweise nicht der beste, einfach weil sie nicht einmal analysiert werden, ohne darauf einzugehen die Top Ten.

In der Praxis wurden bei einer wöchentlichen Umfrage alle 10 Minuten die folgenden ersten Ergebnisse erzielt. Ziffern - die Anzahl der beim Vergleich gewonnenen Knoten für fastestmirror und 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

Und IPv6-Version der Liste:

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


Es ist zu sehen, dass die Auswahl nicht direkt eindeutig ist, aber hier spielt die Nähe des Punktes, von dem aus ich die Umfrage durchgeführt habe, höchstwahrscheinlich eine Rolle - bis auf mehrere Spiegel beträgt der Unterschied weniger als eine Millisekunde. Der zweite Punkt, die IPv6-Liste, ist anders und es ist schlimmer - der nächste IPv6-Host ist weiter als der nächste IPv4-Host und die Auswahl ist geringer. Angesichts der Priorität von IPv6 ist das nicht sehr gut. Die Ergebnisse von fping prägnanter, weniger gewinnbringende Knoten, aber im Allgemeinen die gleichen wie bei fastestmirror .

Reifer Atlas

Mit einer lokalen Entscheidung ist alles mehr oder weniger klar, jetzt wollen wir sehen, wie sich die Dinge im ganzen Land entwickeln. Warum verwenden wir die Dienste https://atlas.ripe.net/ - eine Reihe von Sonden (Probes) und Tools für die Arbeit mit ihnen unter der Schirmherrschaft von RIPE NCC, ich werde Sie sofort warnen, dies ist nicht die schnellste und agilste Website. Jeder kann eine Sonde bekommen und dieses Netzwerk nutzen. Zum Ausführen der Tests benötigen Sie jedoch eine interne Währung, die sich aus den Geräten zusammensetzt, die nach Ihnen registriert und aktiv sind. Ich entschied mich für alle Geräte in Russland, die IPv6 und IPv4 gleichzeitig unterstützen, von denen sich 82 herausstellten. Gemäß den Messergebnissen musste ein Teil davon entfernt werden, so dass 67 von mehr als 400 übrig blieben.

Es gibt mehrere fastestmirror , die Sie ausführen können. Natürlich wird in " fastestmirror nicht das verwendet, aber es wird regelmäßig ein ping fastestmirror . Für alle Spiegel mit Ausnahme von mirror.linux-ia64.org für die ICMP gefiltert wird, und mirror.axelname.ru die nach den Tests von allen ausgewählten Geräten getrennt für IPv6 und IPv4 alle 3 Stunden für eine Woche mirror.axelname.ru wurden Je 10 Anfragen. Die durchschnittliche Antwortzeit wurde aufgezeichnet. Aus dem gesamten Satz von Messungen, ungefähr 50 für jeden Spiegel, wurde der Median genommen und mit anderen Spiegeln auf dieser Sonde verglichen. Der Spiegel mit der kürzesten Reaktionszeit hat gewonnen.


Sampler (blaue Markierungen) und Spiegel (rote Markierungen) sind zu ungleichmäßig verteilt und tendieren zu Großbuchstaben, daher sollten die Ergebnisse nicht als signifikant angesehen werden. Rohdaten sind ab Messnummer 23159879 bis 23159901 verfügbar . Falls gewünscht, können sie genauer analysiert werden. Zusammengefasste Gesamtzahl der ersten Plätze für 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


und 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


Wir können sagen, dass es für fast alle Spiegel, ich erinnere sie an 17, Verbraucher gibt. Es ist interessant, dass mirror.yandex.ru zusammen mit mirror.vilkam.ru aus Petropawlowsk-Kamtschatski an letzter Stelle steht. Zur gleichen Zeit ist Yandex fast überall verfügbar, es verliert jedes Mal ein wenig an Reaktionsfähigkeit, aber mirror.vilkam.ru gewinnt einmal, aber mehr als ehrlich im Vergleich zu anderen auf der 6606-Sonde aus Chabarowsk (RTT in Millisekunden):

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


Die besten Ergebnisse im Bereich von einer oder mehreren Millisekunden und das schlechteste Ergebnis in der Antwort bei Salechard, Probe 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


Nachwort

Für diejenigen, die an diesen Ort kamen, werde ich die Frage beantworten, die gestellt wird - unser Spiegel http://mirrors.powernet.com.ru und hier ist, wie es verwendet wird:



Darüber hinaus ist der Anteil dieses Verkehrs innerhalb unseres Netzwerks vernachlässigbar gering.

So endet der Ort darauf:


Gut unterscheidbare Schritte sind Momente, in denen wir eine neue Distribution hinzufügen. Als alles begann, lief VirtualBox unter Windows auf einem Bürocomputer, auf dem die Videoarchive unserer Werbeabteilung gespeichert waren. Dann sind wir zum Kampfvirtualisierungssystem übergegangen und es wurde ein bisschen einfacher:


Zum Vergleich gibt mirror.truenetwork.ru 3 Gbit / s Datenverkehr von zwei Servern zurück. Bei uns ist alles viel bescheidener und im Allgemeinen ist es mehr als genug für uns, den Prozess zu genießen, sowie seltene überraschend-enthusiastische Bewertungen von Freunden und Abonnenten, wenn jemand plötzlich vertraute Zeilen bemerkt, während er sein System aktualisiert. Und manchmal flackert es im Hintergrund in verschiedenen Artikeln und Handbüchern, in denen Links zu unserem Spiegel in den Protokollen oder Screenshots sichtbar sind.

Sie können hier den Status aller in Centos bekannten Spiegel sehen und lesen, wie Sie sich an dem Projekt beteiligen können. Es ist sowohl einfach als auch verantwortungsbewusst, aber sicherlich nicht nutzlos.