Sobre o repositório Centos espelha e escolhe o melhor

No ano passado, hospedamos espelhos online para várias distribuições Linux. Este não é um processo complicado e, para grandes projetos como o Ubuntu, é quase completamente automatizado. Em outros casos, é necessário, de uma maneira ou de outra, entrar em contato com o projeto, por exemplo, na lista de discussão e expressar claramente seu desejo.


Tecnicamente, é rsync , geralmente em um horário. Alguém para isso fornece um conjunto pronto de scripts, como o Fedora, e alguém apenas diz que você precisa sincronizar aqui neste servidor e o conjunto recomendado de parâmetros. O recurso mais caro é o local, recentemente chegamos a 4 terabytes e, no nosso caso, é caro, pois não gera lucro. Em troca, recebemos a disponibilidade local das distribuições que usamos, o que tornou possível simplificar a configuração inicial dos servidores, eliminando o acesso obrigatório à Internet. E, é claro, estamos felizes por termos juntado algo grande, mesmo que nossa participação nisso não seja muito perceptível.

Nosso espelho é público, todos podem receber atualizações dele, o que realmente acontece se julgado pelas estatísticas de apelações. Isto é principalmente a Rússia, mas não apenas. Sobre como isso acontece e como geralmente um servidor específico é selecionado para atualizações usando a sétima versão do Centos como exemplo.

Falaremos sobre o gerenciador de pacotes yum com o plugin fastestmirror instalado por padrão e estaremos interessados ​​apenas no processo de seleção de um espelho específico.

Lista de espelhos

Sabe-se que a lista de repositórios é especificada nos arquivos no diretório /etc/yum.repos.d/ , a menos que especificado de outra forma. É assim que as configurações do repositório Base parecem no arquivo /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 

Aqui você pode ver duas opções que especificam o local onde você pode obter dados. A primeira base aponta diretamente para o espelho, nenhuma escolha é necessária aqui. A segunda lista de espelhos indica um link através do qual uma lista de 10 espelhos será retornada a partir da qual a escolha será feita; é essa opção que está ativa. Também vemos várias variáveis ​​dentro do link, todas elas refletindo um local específico na árvore de diretórios do repositório:

• release - versão: 6 , 7 , 8 , 8-stream . As versões mais antigas são retiradas da infraestrutura existente, mas os snapshots de seus repositórios podem ser encontrados em http://vault.centos.org/
• arch é uma arquitetura como i386 ou x86_64 . Para algumas versões, algumas arquiteturas se referem a repositórios alternativos e outro sistema de espelhos , mas, ao mesmo tempo, a infraestrutura de seleção de espelhos permanece comum. Para a versão 7, o único espelho de base suportado é x86_64 , uma alternativa ao i386 . Para o primeiro, será formada uma lista na estrutura básica dos espelhos, para o segundo da alternativa
• repo - no nosso caso, os , mas pode ser updates ou outra, na verdade o tipo de repositório reflete quais dados precisamos. Para a versão 8, o equivalente de os será baseos
• infra - Posso assumir com cuidado que ele ainda não é usado , pelo menos não consegui encontrar seu processamento ao formar uma lista de espelhos. É igual ao stock , mas se você omitir esse parâmetro, nenhuma alteração visível seguirá
• cc é o código do país e, para os EUA e Canadá, também é o código do estado. Não está no exemplo do arquivo acima, pois o país é calculado quando solicitado pelo endereço IP do pedido. Essa variável pode ser usada para eliminar erros de localização geográfica. Para a Rússia, cc=ru

Para a sétima versão do Centos, temos a seguinte linha: http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock , que produzirá uma lista de 10 espelhos do seguinte tipo:

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

Observe que o caminho específico para cada espelho corresponde exatamente às variáveis ​​na consulta. A versão completa é indicada em vez da anterior, embora você também possa usá-la: http://< >/7/os/x86_64/ também existe, implementado usando um link simbólico para a versão mais recente.

Implementação

Agora, para a implementação, que pode ser encontrada em https://github.com/CentOS/mirrorlists-code , estamos interessados ​​em como a lista de espelhos é formada. O script pearl makemirrorlists-combined.pl faz isso . Sua principal tarefa é verificar a vitalidade do espelho comparando o hash do repodata/repomd.xml com a referência para a versão e a arquitetura fornecidas. Assim, o arquivo deve existir para todas as combinações disponíveis de versões, tipos de repositórios e arquitetura.

A verificação é realizada de acordo com a lista na seguinte ordem (cito no 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) 

As cláusulas 1 e 2 funcionam ou para verificar não apenas o código do país, mas também o código do estado. Em essência, é feita uma tentativa de selecionar os servidores geograficamente mais próximos. Para cada etapa, é feita uma consulta no banco de dados, por exemplo:

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

Depois, verifica-se a vitalidade dos espelhos nesta lista, comparando os hashes, conforme descrito acima. Se 10 pessoas forem recrutadas, a tarefa necessária será concluída, o trabalho será concluído. Se você não digitar, vá para a próxima etapa para obter a lista geral em 10 ou até esgotarmos todas as opções. O resultado é salvo em um arquivo e transferido para o front end da parte apresentada pelo Python com o script ml.py , cuja tarefa é selecionar e fornecer o arquivo desejado, depois de descobrir primeiro o país da fonte de solicitação pelo endereço IP. O tipo de protocolo IPv4 ou IPv6, para o qual são formadas listas diferentes, também é levado em consideração.

De volta à consulta que usa ORDER BY RAND() , isso significa que a lista será aleatória? Sim, quão aleatória é a implementação no DBMS, mas isso se aplica apenas à ordem em cada etapa. Ou seja, se para um país em particular, mais de 10 espelhos do tipo de repositório e arquitetura necessários forem digitados (para a Rússia, existem apenas 17), no final, cada vez obteremos uma lista embaralhada de 10 espelhos diferentes em um país. Se houver menos, no topo da lista sempre haverá repositórios embaralhados de um país, repositórios embaralhados adicionais dos países mais próximos e assim por diante. Como resultado, obtemos uma lista não inteiramente aleatória que consiste em várias partes aleatórias. É importante quando não há tantos espelhos de trabalho em um país, por exemplo, os espelhos IPv6 na Rússia são apenas 7 e sempre estarão no topo da lista:


Pior ainda, a arquitetura i386 é uma arquitetura alternativa para o Centos 7 e um sistema de espelho separado. Na Rússia, existe apenas um servidor que suporta arquiteturas alternativas; ele sempre estará em primeiro lugar:


A lista não é mais aleatória; se você se concentrar na primeira linha, a escolha é predeterminada. O suporte a repositórios para arquiteturas alternativas do Centos é uma questão de princípio, mas para muitos, o altruísmo puro está aqui.

Os repositórios são verificados continuamente e sem considerar os mecanismos de armazenamento em cache, o resultado é atualizado aproximadamente a cada 3 horas. Citação 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

Na prática, comecei a receber opções de lista de espelhos na Rússia para IPv4 e IPv6 uma vez por minuto para o repositório Base Centos 7 - http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock&cc=ru e ficou assim: por alguns dias de observação:


lista IPv4 azul, IPv6 vermelho. A mudança não ocorre a cada 25 minutos, mas não a cada 3 horas - tudo se encaixa no intervalo de meia hora a duas. A imagem com a arquitetura i386 e os espelhos alternativos é radicalmente diferente - http://mirrorlist.centos.org/?release=7&arch=i386&repo=os&infra=stock&cc=ru cerca de uma semana de observação:


Podemos esperar que a cada 15 minutos tenhamos uma nova lista, em 30 minutos algumas mudanças ocorrerão. Mas! Lembre-se de que quanto menos ativo espelhos, menos aleatória é a ordem e, em primeiro lugar agora na Rússia, é sempre o mesmo espelho.

Fastestmirror

No total, a lista de espelhos é formada, na melhor das hipóteses, por acaso, o que provavelmente não é ruim para o balanceamento de carga. Na pior das hipóteses, podemos esperar que, escolhendo apenas o primeiro espelho da lista, não tenhamos escolha como tal. Além disso, a divisão territorial de países no caso de um país grande como o nosso pode ser um truque, colocando um espelho de Petropavlovsk-Kamchatsky http://mirror.vilkam.ru para o cliente de Sochi no topo da lista. Portanto, seria bom avaliar a disponibilidade de espelhos nessa lista. Isso é feito pelo plugin mais rápido do espelho . A essência disso é reduzida a uma ação simples:

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

Sem HTTP ou ICMP , abra o soquete para o nó, considere quanto tempo levou, aplique sort() aos resultados. Todos os 10 espelhos que foram obtidos na etapa anterior são enviados como parâmetros, na forma da URL completa a partir da qual apenas o nome do host é usado. O plug-in é fácil de trabalhar separadamente do yum , basta comentar as linhas 52 e 55:

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

O processamento ocorre em vários segmentos, para que você não precise esperar muito, mesmo para todos os 17 espelhos listados na Rússia. O resultado do trabalho na forma de duas listas, a primeira na qual o tempo de execução é indicado, é a depuração e não é classificado, embora possa parecer. O segundo depois que a palavra Result classificada de uma resposta menor para uma maior, é ele quem é usado para trabalhos adicionais na ordem recebida.

dnf também usa o mais rápido espelho do conjunto de bibliotecas RPM, mas é resolvido através da libcurl e, em geral, tudo é mais complicado.

No final, tudo depende da rapidez com que a resposta do espelho é recebida, enquanto o armazenamento em cache deve ser levado em consideração, ou seja, o cálculo direto do atraso nem sempre é feito. Os intervalos de tempo são bastante afetados pelo desempenho interno da máquina local e sua carga de trabalho. Nós próximos que mostram resultados semelhantes provavelmente mudarão de lugar com frequência. Mas aqui é alcançado, parece-me que o principal objetivo não é enviar um nó de Sochi para renovação a Petropavlovsk-Kamchatsky, ir a Moscou ou Volgogrado é bastante aceitável. No que mais prestamos atenção, a escolha é feita a partir da lista que foi obtida na primeira etapa antes do fastestmirror ; se esses dados ainda não estiverem no cache, o espelho mais próximo na primeira tentativa pode não ser o melhor, simplesmente porque ele nem será analisado sem entrar em detalhes. os dez melhores.

Na prática, os seguintes resultados em primeiro lugar foram obtidos em uma pesquisa semanal a cada 10 minutos. Dígitos - o número de vezes que nós vencemos durante a comparação, para o fastestmirror e 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

E versão IPv6 da lista:

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


Pode-se ver que a escolha não é diretamente inequívoca, mas aqui a proximidade do ponto em que eu fiz a pesquisa provavelmente desempenha um papel - até vários espelhos, a diferença é menor que um milissegundo. O segundo ponto, a lista de IPv6 é diferente e é pior - o host IPv6 mais próximo fica mais longe que o IPv4 mais próximo e a escolha é menor. Dada a prioridade do IPv6, não é muito bom. Os resultados do fping concisos, com menos nós vencedores, mas geralmente são os mesmos com o fastestmirror .

Atlas maduro

Com uma escolha local, tudo fica mais ou menos claro, agora vamos ver como as coisas estão acontecendo em todo o país. Por que usamos os serviços https://atlas.ripe.net/ - um conjunto de probes (probes) e ferramentas para trabalhar com eles sob os auspícios do RIPE NCC, aviso imediatamente que este não é o site mais rápido e ágil. Qualquer pessoa pode obter uma sonda e usar esta rede. Mas, para executar os testes, você precisa de uma moeda interna que se acumule com os dispositivos registrados e ativos depois de você. Eu escolhi todos os dispositivos na Rússia que suportam IPv6 e IPv4 ao mesmo tempo, 82 deles, de acordo com os resultados da medição, de acordo com os resultados da medição, parte dele teve que ser eliminada, e 67 dos mais de 400 permaneceram.

Existem várias opções de teste que você pode executar, é claro que não há o que é usado no fastestmirror , mas há ping regular. Para todos os espelhos, com exceção do mirror.linux-ia64.org para o qual o ICMP filtrado e o mirror.axelname.ru que apareceu após a conclusão dos testes, de todos os dispositivos selecionados, separadamente para IPv6 e IPv4, a cada 3 horas por uma semana 10 pedidos cada. O tempo médio de resposta foi registrado. De todo o conjunto de medições, cerca de 50 para cada espelho, a mediana foi obtida e comparada com outros espelhos nessa sonda. O espelho com o menor tempo de resposta venceu.


As sondas (marcadores azuis) e os espelhos (marcadores vermelhos) são distribuídos de maneira muito desigual e gravitam em direção às capitais, de modo que os resultados não devem ser tomados como algo significativo. Os dados brutos estão disponíveis a partir do número de medição 23159879 a 23159901 , se desejado, eles podem ser analisados ​​com mais rigor. Número total resumido de primeiros 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 dizer que, para quase todos os espelhos, lembro a eles de 17, existem consumidores. É interessante que mirror.yandex.ru em último lugar, juntamente com mirror.vilkam.ru de Petropavlovsk-Kamchatsky. Ao mesmo tempo, o Yandex está disponível bem em quase todos os lugares, mas perde um pouco mais de resposta a cada vez, mas o mirror.vilkam.ru vence uma vez, mas mais do que honestamente, em comparação com outros na sonda 6606 de Khabarovsk (RTT em milissegundos):

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


Os melhores resultados na região de um ou vários milissegundos e o pior resultado em resposta em 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


Posfácio

Para quem chegou a este lugar, responderei à pergunta que será feita - nosso espelho http://mirrors.powernet.com.ru e aqui está como ele é usado:



Além disso, a parcela desse tráfego de dentro da nossa rede é insignificante.

É assim que o lugar termina:


Etapas bem distinguíveis são momentos em que adicionamos uma nova distribuição. Quando tudo começou, o VirtualBox estava sendo executado no Windows em um computador do escritório no qual estavam armazenados os arquivos de vídeo do nosso departamento de publicidade. Depois, mudamos para o sistema de virtualização de combate e ficou um pouco mais fácil:


Para comparação, o mirror.truenetwork.ru retorna tráfego de 3 Gb / s de dois servidores. Tudo é muito mais modesto conosco e, em geral, é mais do que suficiente para desfrutarmos do processo, além de raras críticas entusiasmadas e surpreendidas de amigos e assinantes quando alguém percebe linhas subitamente familiares ao atualizar seu sistema. E também, às vezes piscando em segundo plano em vários artigos e manuais, onde os links para o nosso espelho são visíveis nos logs ou nas capturas de tela.

Você pode ver o status de todos os espelhos conhecidos no Centos aqui e ler sobre como ingressar no projeto aqui , é simples e responsável ao mesmo tempo, mas certamente não é inútil.