Acerca de los espejos de repositorio de Centos y elegir el mejor

El año pasado, alojamos espejos en línea para varias distribuciones de Linux. Este no es un proceso complicado y para proyectos grandes como Ubuntu, está casi completamente automatizado. En otros casos, es necesario de una forma u otra ponerse en contacto con el proyecto, por ejemplo, en la lista de correo y expresar claramente su deseo.


Técnicamente, es rsync , generalmente en un horario. Alguien para esto proporciona un conjunto de scripts listos para usar, como Fedora, y alguien simplemente dice que necesita sincronizar aquí desde este servidor y el conjunto de parámetros recomendado. El recurso más caro es el lugar, recientemente llegamos a 4 terabytes y esto es caro en nuestro caso, ya que no genera ningún beneficio. A cambio, recibimos la disponibilidad local de las distribuciones que utilizamos, lo que hizo posible simplificar la configuración inicial de los servidores al eliminar el acceso obligatorio a Internet. Y, por supuesto, nos alegra habernos unido a algo grande, incluso si nuestra participación en esto no es muy notable.

Nuestro espejo es público, todos pueden recibir actualizaciones de él, lo que en realidad sucede si se juzga por las estadísticas de las apelaciones. Esto es principalmente Rusia, pero no solo. Acerca de cómo resulta y cómo se selecciona el servidor general para actualizaciones en el ejemplo de la séptima versión de Centos de esta publicación.

Hablaremos sobre el administrador de paquetes yum con el plugin más fastestmirror instalado por defecto y solo nos interesará el proceso de selección de un espejo específico.

Lista de espejos

Se sabe que la lista de repositorios se especifica en los archivos en el directorio /etc/yum.repos.d/ menos que se especifique lo contrario. Así es como se ve la configuración del repositorio Base en el archivo /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 

Aquí puede ver dos opciones que especifican el lugar desde donde puede obtener datos. La primera base apunta directamente al espejo, aquí no se necesita elección. La segunda lista de espejos indica un enlace a través del cual se devolverá una lista de 10 espejos desde la cual se realizará la elección, es esta opción la que está activa. También vemos varias variables dentro del enlace, todas ellas reflejan en última instancia un lugar específico en el árbol del directorio del repositorio:

• lanzamiento - versión: 6 , 7 , 8 , 8-stream . Las versiones anteriores se eliminan de la infraestructura existente, pero se pueden encontrar instantáneas de sus repositorios en http://vault.centos.org/
• arch es una arquitectura como i386 o x86_64 . Para algunas versiones, algunas arquitecturas se referirán a repositorios alternativos y otro sistema espejo , pero al mismo tiempo, la infraestructura de selección espejo sigue siendo común. Para la versión 7, el único espejo base compatible es x86_64 , una alternativa al i386 . Para el primero, se formará una lista en la estructura básica de los espejos, para el segundo de la alternativa
• repo : en nuestro caso, os , pero puede ser updates u otro, en realidad el tipo de repositorio refleja qué datos necesitamos. Para la versión 8, el equivalente de os será baseos
• infra : puedo suponer cuidadosamente que todavía no se usa , al menos no pude encontrar su procesamiento al formar una lista de espejos. Es igual a stock , pero si omite este parámetro, no habrá cambios visibles.
• cc es el código de país; para EE. UU. y Canadá también es el código de estado. No está en el ejemplo del archivo anterior, ya que el país se calcula cuando lo solicita la dirección IP de la solicitada. Esta variable se puede usar para eliminar errores de geolocalización. Para Rusia, cc=ru

Para la séptima versión de Centos, obtenemos la siguiente línea: http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock que mostrará una lista de 10 espejos del siguiente tipo:

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

Tenga en cuenta que la ruta específica para cada espejo coincide exactamente con las variables en la consulta. Se indica la versión completa en lugar de la anterior, aunque también puede usarla: http://< >/7/os/x86_64/ también existe, implementado usando un enlace simbólico a la última versión.

Implementación

Ahora para la implementación, que se puede encontrar en https://github.com/CentOS/mirrorlists-code , estamos interesados ​​en cómo se forma la lista de espejos. El script de perlas makemirrorlists-combined.pl hace esto . Su tarea principal es verificar la vitalidad del espejo comparando el hash del repodata/repomd.xml con la referencia para la versión y arquitectura dadas. En consecuencia, el archivo debe existir para todas las combinaciones disponibles de versiones, tipos de repositorios y arquitectura.

La verificación se lleva a cabo de acuerdo con la lista en el siguiente orden (cito del código):

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

Las cláusulas 1 y 2 funcionan o para verificar no solo el código de país, sino también el código de estado. En esencia, se intenta seleccionar los servidores geográficos más cercanos. Para cada paso, se realiza una consulta desde la base de datos, por ejemplo:

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

Luego, se verifica la vitalidad de los espejos en esta lista comparando hashes, como se describió anteriormente. Si se reclutan 10 personas, entonces se ha completado la tarea requerida, se completa el trabajo. Si no escribe, vaya al siguiente paso para obtener la lista general a 10 o hasta que hayamos agotado todas las opciones. El resultado se guarda en un archivo y se transfiere al frente de la parte presentada por Python con el script ml.py , cuya tarea es seleccionar y dar el archivo deseado, después de averiguar el país de origen de la solicitud por dirección IP. También se tiene en cuenta el tipo de protocolo IPv4 o IPv6, para el que se forman diferentes listas.

Volviendo a la consulta que usa ORDER BY RAND() , ¿significa esto que la lista será aleatoria? Sí, cuán aleatoria es la implementación en el DBMS, pero esto solo se aplica al orden dentro de cada paso. Es decir, si para un país en particular se tipean más de 10 espejos del tipo requerido de repositorio y arquitectura (para Rusia solo hay 17), al final, cada vez obtendremos una lista aleatoria de 10 espejos diferentes en un país. Si hay menos, en la parte superior de la lista siempre habrá repositorios aleatorios de un país, repositorios adicionales de los países más cercanos, y así sucesivamente. Como resultado, obtenemos una lista no completamente aleatoria que consta de varias partes aleatorias. Importa cuando no hay tantos espejos en funcionamiento en un país, por ejemplo, los espejos IPv6 en Rusia son solo 7 y siempre estarán en la parte superior de la lista:


Peor aún, la arquitectura i386 es una arquitectura alternativa para Centos 7 y un sistema de espejo separado. En Rusia, solo hay uno de esos servidores que admite arquitecturas alternativas; siempre estará en primer lugar:


La lista ya no es aleatoria, si te enfocas en la primera línea, la elección está predeterminada. El soporte para repositorios para arquitecturas Centos alternativas es una cuestión de preocupación principal , pero para muchos, el altruismo puro está aquí.

Los repositorios se escanean continuamente y sin tener en cuenta los mecanismos de almacenamiento en caché, el resultado se actualiza aproximadamente cada 3 horas. Cita 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 la práctica, comencé a obtener opciones de lista espejo en Rusia para IPv4 e IPv6 una vez por minuto para el repositorio de Base Centos 7: http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock&cc=ru y resultó así por un par de días de observación:


lista azul de IPv4, rojo IPv6. El cambio no ocurre cada 25 minutos, pero no una vez cada 3 horas; todo cabe en el intervalo de media hora a dos. La imagen con la arquitectura i386 y los espejos alternativos es radicalmente diferente: http://mirrorlist.centos.org/?release=7&arch=i386&repo=os&infra=stock&cc=ru aproximadamente una semana de observación:


Podemos esperar que cada 15 minutos tengamos una nueva lista, en 30 minutos sucederán algunos cambios. Pero! Recuerde que cuanto menos espejos esté activo, menos aleatorio será el orden y, en primer lugar, ahora en Rusia es siempre el mismo espejo.

El espejo más rápido

En total, la lista de espejos se forma en el mejor de los casos por casualidad, lo que probablemente no sea malo para el equilibrio de carga. En el peor de los casos, podemos esperar que al elegir solo el primer espejo de la lista, no tendremos otra opción como tal. Además, la división territorial de los países en el caso de un país grande como el nuestro puede ser un truco al poner un espejo de Petropavlovsk-Kamchatsky http://mirror.vilkam.ru para el cliente de Sochi en la parte superior de la lista. Por lo tanto, sería bueno evaluar la disponibilidad de espejos de esta lista. Esto se realiza mediante el complemento más rápido de espejo . La esencia de la cual se reduce a una simple acción:

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

Sin HTTP o ICMP , abra el socket para el nodo, considere cuánto tiempo tardó, aplique sort() a los resultados. Todos los 10 espejos que se obtuvieron en el paso anterior se envían como parámetros, en forma de la URL completa desde la que solo se utiliza el nombre de host. Es fácil hacer que el complemento funcione por separado de yum , solo necesita comentar las líneas 52 y 55:

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

El procesamiento se realiza en varios subprocesos, por lo que no tiene que esperar mucho, incluso para los 17 espejos que se enumeran en Rusia. El resultado del trabajo en forma de dos listas, la primera en la que se indica el tiempo de ejecución, es la depuración y no está ordenada, aunque pueda parecerlo. El segundo después de que la palabra Result ordena de una respuesta más pequeña a una más grande, es él quien se utiliza para el trabajo adicional en el orden recibido.

dnf también utiliza el espejo más rápido del conjunto de bibliotecas RPM, pero allí se resuelve a través de libcurl y, en general, todo es más complicado.

Al final, todo depende de qué tan rápido se reciba la respuesta del espejo, mientras que el almacenamiento en caché debe tenerse en cuenta, es decir, el cálculo directo del retraso no siempre se realiza. Los intervalos de tiempo se ven muy afectados por el rendimiento interno de la máquina local y su carga de trabajo. Los nodos cercanos que muestran resultados similares probablemente cambiarán de lugar con frecuencia. Pero aquí se logra, me parece que el objetivo principal no es enviar un nodo desde Sochi para su renovación a Petropavlovsk-Kamchatsky, para ir a Moscú o Volgogrado es bastante aceptable. ¿A qué más prestamos atención? La elección se realiza de la lista que se recibió en el primer paso antes del fastestmirror , si estos datos aún no están en la caché, entonces el espejo más cercano en el primer intento puede no ser el mejor, simplemente porque ni siquiera se analizará sin entrar en los diez primeros

En la práctica, se obtuvieron los siguientes resultados de primer lugar en una encuesta semanal cada 10 minutos. Dígitos: la cantidad de veces cuántos nodos ganaron durante la comparación, para el fastestmirror y 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

Y la versión IPv6 de la lista:

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


Se puede ver que la elección no es directamente inequívoca, pero aquí la proximidad del punto desde el que hice la encuesta probablemente juega un papel: hasta varios espejos, la diferencia es menos de un milisegundo. El segundo punto, la lista de IPv6 es diferente y es peor: el host IPv6 más cercano está más lejos que el IPv4 más cercano y la elección es menor. Dada la prioridad de IPv6 no es muy buena. Los resultados de fping concisos, menos nodos ganadores, pero generalmente son los mismos con el fastestmirror .

Atlas maduro

Con una elección local, todo está más o menos claro, ahora veamos cómo están sucediendo las cosas en todo el país. ¿Por qué utilizamos los servicios https://atlas.ripe.net/ ? Un conjunto de sondas (sondas) y herramientas para trabajar con ellos bajo los auspicios de RIPE NCC. Le advertiré de inmediato, este no es el sitio más rápido y más ágil. Cualquiera puede obtener una sonda, así como usar esta red. Pero para ejecutar las pruebas, necesita una moneda interna que se acumule de los dispositivos que están registrados y activos después de usted. Seleccioné todos los dispositivos en Rusia que admiten IPv6 e IPv4 al mismo tiempo, resultaron 82 de ellos. Según los resultados de la medición, una parte tuvo que ser eliminada, por lo que quedaron 67 de más de 400 .

Hay varias opciones de prueba que puede ejecutar, por supuesto, no hay lo que se usa en el fastestmirror , pero hay un ping regular. Para todos los espejos, con la excepción de mirror.linux-ia64.org para el cual ICMP filtra ICMP y mirror.axelname.ru que apareció después de que se realizaron las pruebas, desde todos los dispositivos seleccionados, por separado para IPv6 e IPv4, cada 3 horas durante una semana 10 solicitudes cada uno. Se registró el tiempo de respuesta promedio. Del conjunto completo de mediciones, aproximadamente 50 por cada espejo, se tomó la mediana y se comparó con otros espejos en esta sonda. El espejo con el menor tiempo de respuesta ganó.


Las sondas (marcadores azules) y los espejos (marcadores rojos) se distribuyen de manera demasiado desigual y gravitan hacia las mayúsculas, por lo que los resultados no deben tomarse como algo significativo. Los datos sin procesar están disponibles a partir del número de medición 23159879 a 23159901 , si se desea, pueden analizarse más estrictamente. Número total resumido de primeros lugares para 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


e 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


Podemos decir que para casi todos los espejos, les recuerdo a los 17, hay consumidores. Es interesante que mirror.yandex.ru en el último lugar junto con mirror.vilkam.ru de Petropavlovsk-Kamchatsky. Al mismo tiempo, Yandex está disponible en casi todas partes, solo pierde un poco más de respuesta cada vez, pero mirror.vilkam.ru gana una vez, pero más que honestamente en comparación con otros en la sonda 6606 de Khabarovsk (RTT en milisegundos):

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


Los mejores resultados en la región de uno o varios milisegundos, y el peor resultado en respuesta en Salekhard, sonda 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


Epílogo

Para aquellos que llegaron a este lugar, responderé la pregunta que se hará: nuestro espejo http://mirrors.powernet.com.ru y así es cómo se usa:



Además, la participación de este tráfico desde nuestra red es insignificante.

Así es como termina el lugar en él:


Los pasos bien distinguibles son momentos en los que agregamos una nueva distribución. Cuando todo comenzó, fue VirtualBox ejecutándose en Windows en una computadora de oficina en la que se almacenaron los archivos de video de nuestro departamento de publicidad. Luego pasamos al sistema de virtualización de combate y se volvió un poco más fácil:


A modo de comparación, mirror.truenetwork.ru devuelve 3 Gb / s de tráfico desde dos servidores. Todo es mucho más modesto con nosotros y, en general, es más que suficiente para que disfrutemos el proceso, así como las raras críticas de entusiastas y sorprendidos de amigos y suscriptores cuando alguien nota líneas familiares repentinas mientras actualiza su sistema. Y también, a veces parpadea en segundo plano en varios artículos y manuales, donde los enlaces a nuestro espejo son visibles en los registros o capturas de pantalla.

Puede ver el estado de todos los espejos conocidos en Centos aquí , y leer acerca de cómo unirse al proyecto aquí , es simple y responsable al mismo tiempo, pero ciertamente no es inútil.