Tentang cermin repositori Centos dan memilih yang terbaik

Tahun lalu, kami menyelenggarakan mirror online untuk beberapa distribusi Linux. Ini bukan proses yang rumit dan untuk proyek-proyek besar seperti Ubuntu, ini hampir sepenuhnya otomatis. Dalam kasus lain, Anda perlu menghubungi proyek dengan satu atau lain cara, misalnya, di milis dan menyatakan keinginan Anda secara eksplisit.


Secara teknis, ini rsync , biasanya sesuai jadwal. Seseorang untuk ini menyediakan satu set skrip yang sudah jadi, seperti Fedora, dan seseorang hanya mengatakan bahwa Anda perlu melakukan sinkronisasi di sini dari server ini dan set parameter yang direkomendasikan. Sumber daya yang paling mahal adalah tempatnya, kami baru-baru ini mencapai 4 terabyte dan ini mahal untuk kami karena itu tidak menghasilkan laba apa pun. Sebagai imbalannya, kami menerima ketersediaan lokal dari distribusi yang kami gunakan, ini memungkinkan untuk menyederhanakan konfigurasi awal server dengan menghilangkan akses Internet wajib dari itu. Dan tentu saja, kami senang bahwa kami bergabung dengan sesuatu yang besar, bahkan jika partisipasi kami dalam hal ini tidak terlalu terlihat.

Cermin kami bersifat publik, semua orang dapat menerima pembaruan darinya, yang sebenarnya terjadi jika dinilai oleh statistik banding. Ini terutama Rusia, tetapi tidak hanya. Tentang bagaimana ternyata dan bagaimana server umum dipilih untuk pembaruan pada contoh versi ketujuh Centos dari posting ini.

Kami akan berbicara tentang pengelola paket yum dengan plugin yang paling cepat diinstal secara default dan kami hanya akan tertarik pada proses memilih mirror tertentu.

Daftar Cermin

Diketahui bahwa daftar repositori ditentukan dalam file di direktori /etc/yum.repos.d/ kecuali ditentukan lain. Ini adalah apa yang tampak seperti pengaturan repositori Base di file /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 

Di sini Anda dapat melihat dua opsi yang menentukan tempat Anda dapat memperoleh data. Baseurl pertama langsung menunjuk ke cermin, tidak ada pilihan yang diperlukan di sini. Daftar mirror kedua menunjukkan sebuah tautan di mana daftar 10 mirror akan dikembalikan dari mana pilihan akan dibuat, itu adalah opsi ini yang aktif. Kami juga melihat beberapa variabel di dalam tautan, semuanya akhirnya mencerminkan tempat tertentu di pohon direktori repositori:

• rilis - versi: 6 , 7 , 8 , 8-stream . Versi lama ditarik dari infrastruktur yang ada, tetapi snapshot dari repositori mereka dapat ditemukan di http://vault.centos.org/
• arch adalah arsitektur seperti i386 atau x86_64 . Untuk beberapa versi, beberapa arsitektur akan merujuk ke repositori alternatif dan sistem mirror lain , tetapi pada saat yang sama, infrastruktur pemilihan mirror tetap umum. Untuk versi 7, satu-satunya mirror dasar yang didukung adalah x86_64 , sebuah alternatif untuk i386 . Untuk yang pertama, daftar akan dibentuk dalam struktur dasar cermin, untuk yang kedua dari alternatif
• repo - dalam kasus kami, os , tetapi bisa berupa updates atau lainnya, sebenarnya jenis repositori mencerminkan data apa yang kami butuhkan. Untuk versi 8, setara dengan os akan menjadi baseos
• infra - Saya dapat dengan hati-hati berasumsi bahwa itu masih belum digunakan , setidaknya saya tidak dapat menemukan pemrosesan ketika membentuk daftar mirror. Itu sama dengan stock , tetapi jika Anda menghilangkan parameter ini, tidak ada perubahan yang terlihat akan mengikuti
• cc adalah kode negara, untuk Amerika Serikat dan Kanada juga kode negara. Itu tidak ada dalam contoh dari file di atas, karena negara dihitung ketika diminta oleh alamat IP yang diminta. Variabel ini dapat digunakan untuk menghilangkan kesalahan geolokasi. Untuk Rusia, cc=ru

Untuk Centos versi ke-7, kita mendapatkan baris berikut: http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock , yang akan menghasilkan daftar 10 cermin dari jenis berikut:

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

Perhatikan bahwa jalur spesifik untuk setiap cermin sama persis dengan variabel dalam kueri. Versi lengkapnya ditunjukkan bukan versi yang lebih lama, meskipun Anda juga dapat menggunakannya: http://< >/7/os/x86_64/ juga ada, diimplementasikan menggunakan tautan simbolis ke versi terbaru.

Implementasi

Sekarang untuk implementasinya, yang dapat ditemukan di https://github.com/CentOS/mirrorlists-code , kami tertarik pada bagaimana daftar mirror dibentuk. Makemirrorlists script mutiara-combined.pl melakukan ini . Tugas utamanya adalah untuk memeriksa vitalitas cermin dengan membandingkan hash dari file repodata/repomd.xml dengan referensi untuk versi dan arsitektur yang diberikan. Karenanya, file tersebut harus ada untuk semua kombinasi versi, tipe repositori, dan arsitektur yang tersedia.

Verifikasi dilakukan sesuai dengan daftar dalam urutan berikut (saya kutip dari kode):

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

Klausa 1 dan 2 berfungsi baik atau untuk memeriksa tidak hanya kode negara, tetapi juga kode negara. Intinya, upaya dilakukan untuk memilih server geografis terdekat. Untuk setiap langkah, kueri dibuat dari database, misalnya:

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

Lalu ada pemeriksaan untuk vitalitas cermin pada daftar ini dengan membandingkan hash, seperti dijelaskan di atas. Jika 10 orang direkrut, maka tugas yang diperlukan telah selesai, pekerjaan selesai. Jika Anda tidak mengetik, maka lanjutkan ke langkah berikutnya untuk mendapatkan daftar umum hingga 10 atau sampai kami kehabisan semua opsi. Hasilnya disimpan dalam file dan ditransfer ke ujung depan bagian yang disajikan oleh Python dengan skrip ml.py , tugasnya adalah memilih dan memberikan file yang diinginkan, setelah terlebih dahulu mengetahui negara sumber permintaan dengan alamat IP. Jenis protokol IPv4 atau IPv6, di mana daftar yang berbeda dibentuk, juga diperhitungkan.

Kembali ke kueri yang menggunakan ORDER BY RAND() , apakah ini berarti bahwa daftar akan acak? Ya, seberapa acak implementasi dalam DBMS, tetapi ini hanya berlaku untuk urutan dalam setiap langkah. Artinya, jika untuk negara tertentu lebih dari 10 cermin dari jenis repositori dan arsitektur yang diperlukan diketik (untuk Rusia hanya ada 17), maka pada akhirnya, setiap kali kita akan mendapatkan daftar 10 cermin berbeda yang diacak di satu negara. Jika jumlahnya lebih sedikit, maka di bagian atas daftar akan selalu ada repositori yang diacak dari satu negara, repositori yang dikocok lebih jauh dari negara-negara terdekat, dan seterusnya dalam langkah-langkah. Hasilnya, kami mendapatkan daftar yang tidak sepenuhnya acak yang terdiri dari beberapa bagian acak. Itu penting ketika tidak ada banyak cermin yang bekerja di satu negara, misalnya, cermin IPv6 di Rusia hanya 7 dan mereka akan selalu berada di urutan teratas daftar:


Lebih buruk lagi, arsitektur i386 adalah arsitektur alternatif untuk Centos 7 dan sistem cermin terpisah. Di Rusia, hanya ada satu server yang mendukung arsitektur alternatif, yang akan selalu ada di tempat pertama:


Daftar ini tidak lagi acak, jika Anda fokus pada baris pertama, pilihannya sudah ditentukan sebelumnya. Dukungan untuk repositori untuk arsitektur Centos alternatif adalah masalah prinsip, tetapi bagi banyak orang, altruisme murni ada di sini.

Repositori dipindai terus menerus dan tanpa mempertimbangkan mekanisme caching, hasilnya diperbarui sekitar setiap 3 jam. Kutipan dari 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

Dalam praktiknya, saya mulai mendapatkan opsi daftar cermin di Rusia untuk IPv4 dan IPv6 satu menit sekali untuk repositori Base Centos 7 - http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock&cc=ru dan ternyata seperti ini selama beberapa hari pengamatan:


daftar IPv4 biru, IPv6 merah. Perubahan tidak terjadi setiap 25 menit, tetapi tidak setiap 3 jam - semuanya sesuai dalam interval dari setengah jam menjadi dua. Gambar dengan arsitektur i386 dan cermin alternatif berbeda secara radikal - http://mirrorlist.centos.org/?release=7&arch=i386&repo=os&infra=stock&cc=ru sekitar satu minggu pengamatan:


Kita dapat berharap bahwa setiap 15 menit kita akan memiliki daftar baru, dalam 30 menit beberapa perubahan akan terjadi. Tapi! Ingatlah bahwa cermin yang kurang aktif semakin acak urutannya dan di tempat pertama sekarang di Rusia selalu cermin yang sama.

Kekaguman tercepat

Secara keseluruhan, daftar mirror dibentuk secara kebetulan, yang mungkin tidak buruk untuk load balancing. Paling buruk, kita dapat berharap bahwa hanya dengan memilih mirror pertama dari daftar, kita tidak akan memiliki pilihan seperti itu. Selain itu, pembagian wilayah negara-negara dalam kasus negara besar seperti kita dapat memainkan trik dengan meletakkan cermin dari Petropavlovsk-Kamchatsky http://mirror.vilkam.ru untuk klien dari Sochi di bagian atas daftar. Oleh karena itu, alangkah baiknya untuk mengevaluasi ketersediaan cermin dari daftar ini. Ini dilakukan oleh plugin tercepat . Esensi yang direduksi menjadi tindakan sederhana:

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

Tidak ada HTTP atau ICMP , buka soket untuk node, pertimbangkan berapa banyak waktu yang diperlukan, terapkan sort() ke hasilnya. Semua 10 mirror yang diperoleh pada langkah sebelumnya dikirim sebagai parameter, dalam bentuk URL lengkap yang hanya menggunakan nama host. Plugin ini mudah digunakan secara terpisah dari yum , Anda hanya perlu mengomentari baris 52 dan 55:

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

Pemrosesan berlangsung dalam beberapa utas, sehingga Anda tidak perlu menunggu lama, bahkan untuk semua 17 cermin yang terdaftar di Rusia. Hasil kerja dalam bentuk dua daftar, yang pertama di mana waktu eksekusi diindikasikan, adalah debugging dan tidak diurutkan, meskipun sepertinya begitu. Yang kedua setelah kata Result diurutkan dari respons yang lebih kecil ke yang lebih besar, dialah yang digunakan untuk pekerjaan lebih lanjut dalam urutan yang diterima.

dnf juga menggunakanmirror dnf dari himpunan perpustakaan RPM, tetapi di sana diselesaikan melalui libcurl dan secara umum semuanya lebih rumit.

Pada akhirnya, itu semua tergantung pada seberapa cepat respons dari cermin diterima, sementara caching harus diperhitungkan, yaitu, perhitungan langsung dari penundaan tidak selalu dilakukan. Interval waktu sangat dipengaruhi oleh kinerja in-house dari mesin lokal dan beban kerjanya. Tutup node yang menunjukkan hasil yang serupa mungkin akan sering berganti tempat. Tapi di sini tercapai, menurut saya tujuan utama bukan untuk mengirim simpul dari Sochi untuk pembaruan ke Petropavlovsk-Kamchatsky, untuk pergi ke Moskow atau Volgograd cukup dapat diterima. Apa lagi yang perlu kita perhatikan, pilihan dibuat dari daftar yang diterima pada langkah pertama sebelum fastestmirror , jika data ini belum ada dalam cache, maka mirror terdekat pada percobaan pertama mungkin bukan yang terbaik, hanya karena itu bahkan tidak akan dianalisis tanpa masuk ke dalam sepuluh besar.

Dalam praktiknya, hasil tempat pertama berikut diperoleh pada survei mingguan setiap 10 menit. Digit - berapa kali jumlah node dimenangkan selama perbandingan, untuk fastestmirror dan 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

Dan daftar versi IPv6:

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


Dapat dilihat bahwa pilihannya tidak langsung tidak ambigu, tetapi di sini kedekatan titik di mana saya melakukan survei kemungkinan besar memainkan peran - hingga beberapa cermin, perbedaannya kurang dari satu milidetik. Poin kedua, daftar IPv6 berbeda dan lebih buruk - host IPv6 terdekat lebih jauh dari IPv4 terdekat dan pilihannya lebih sedikit. Mengingat prioritas IPv6 tidak terlalu baik. Hasil dari fping ringkas, lebih sedikit node yang menang, tetapi umumnya sama dengan fastestmirror .

Atlas matang

Dengan pilihan lokal, semuanya kurang lebih jelas, sekarang mari kita lihat bagaimana keadaan di seluruh negeri. Mengapa kami menggunakan layanan https://atlas.ripe.net/ - satu set probe (probe) dan alat untuk bekerja dengan mereka di bawah naungan RIPE NCC, saya akan segera memperingatkan Anda, ini bukan situs tercepat dan paling gesit. Siapa pun bisa mendapatkan penyelidikan, serta menggunakan jaringan ini. Tetapi untuk menjalankan tes, Anda memerlukan mata uang internal yang terakumulasi dari perangkat yang terdaftar dan aktif setelah Anda. Saya memilih semua perangkat di Rusia yang mendukung IPv6 dan IPv4 pada saat yang sama, 82 diantaranya ternyata. Menurut hasil pengukuran, sebagian harus disingkirkan, jadi 67 dari lebih dari 400 yang tersisa.

Ada beberapa opsi tes yang dapat Anda jalankan, tentu saja tidak ada yang digunakan dalam fastestmirror , tetapi ada ping biasa. Untuk semua mirror, dengan pengecualian mirror.linux-ia64.org mana ICMP difilter dan mirror.axelname.ru yang muncul setelah pengujian dilakukan, dari semua perangkat yang dipilih, secara terpisah untuk IPv6 dan IPv4, setiap 3 jam selama seminggu Masing-masing 10 permintaan. Waktu respons rata-rata dicatat. Dari seluruh rangkaian pengukuran, sekitar 50 untuk setiap cermin, median diambil dan dibandingkan dengan cermin lain pada probe ini. Cermin dengan waktu respons terpendek menang.


Probe (spidol biru) dan mirror (spidol merah) didistribusikan terlalu tidak merata dan condong ke arah ibukota, sehingga hasilnya tidak boleh dianggap sebagai sesuatu yang signifikan. Data mentah tersedia mulai dari angka pengukuran 23159879 hingga 23159901 , jika diinginkan, mereka dapat dianalisis lebih ketat. Ringkas jumlah total tempat pertama untuk 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


dan 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


Kita dapat mengatakan bahwa untuk hampir semua mirror, saya ingatkan pada 17, ada konsumen. Sangat menarik bahwa mirror.yandex.ru di tempat terakhir bersama dengan mirror.vilkam.ru dari Petropavlovsk-Kamchatsky. Pada saat yang sama, Yandex tersedia dengan baik hampir dari mana-mana, itu hanya kehilangan sedikit lebih responsif setiap kali, tetapi mirror.vilkam.ru menang sekali, tetapi lebih dari jujur ​​dibandingkan dengan yang lain pada penyelidikan 6606 dari Khabarovsk (RTT dalam milidetik):

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


Hasil terbaik di wilayah satu atau beberapa milidetik, dan hasil terburuk dalam respons di Salekhard, menyelidiki 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


Kata penutup

Bagi mereka yang sampai di tempat ini saya akan menjawab pertanyaan yang akan ditanyakan - mirror kami http://mirrors.powernet.com.ru dan berikut ini cara penggunaannya:



Selain itu, pangsa lalu lintas ini dari dalam jaringan kami dapat diabaikan.

Beginilah tempat tempat itu berakhir:


Langkah yang dapat dibedakan dengan baik adalah saat-saat ketika kita menambahkan distribusi baru. Ketika semuanya dimulai, VirtualBox berjalan pada Windows di komputer kantor tempat arsip video departemen periklanan kami disimpan. Kemudian kami pindah ke sistem virtualisasi tempur dan itu menjadi sedikit lebih mudah:


Sebagai perbandingan, mirror.truenetwork.ru mengembalikan lalu lintas 3 Gb / s dari dua server. Semuanya jauh lebih sederhana dengan kami dan, secara umum, itu lebih dari cukup bagi kami untuk menikmati prosesnya, serta ulasan antusiasme yang mengejutkan dari teman dan pelanggan ketika seseorang melihat garis yang tiba-tiba akrab saat memperbarui sistem mereka. Dan juga, kadang-kadang berkedip-kedip di latar belakang dalam berbagai artikel dan manual, di mana tautan ke cermin kita terlihat di log atau tangkapan layar.

Anda dapat melihat status semua mirror yang dikenal di Centos di sini , dan membaca tentang cara bergabung dengan proyek di sini , itu sederhana dan bertanggung jawab pada saat yang sama, tetapi tentu saja tidak sia-sia.