[technique] Etat des miroirs chez tetaneutral.net

Baptiste Jonglez baptiste at bitsofnetworks.org
Sam 16 Jan 15:02:42 CET 2021


Bonjour,

Voici un nouveau point de situation sur les miroirs hébergés par
tetaneutral, qui fait suite aux points précédents :

https://lists.tetaneutral.net/pipermail/technique/2017-August/002855.html
https://lists.tetaneutral.net/pipermail/technique/2017-October/002890.html
https://lists.tetaneutral.net/pipermail/technique/2018-June/003235.html
https://lists.tetaneutral.net/pipermail/technique/2018-July/003248.html
https://lists.tetaneutral.net/pipermail/technique/2019-October/003693.html

Tout d'abord, notre serveur de distribution de tuiles OpenStreetMap a été
mis à la retraite fin décembre, parce que OpenStreetMap est passé sur un
CDN commercial (Fastly).  C'est un peu dommage, mais vu l'ampleur du
projet, c'était une grosse charge technique pour l'équipe de bénévoles OSM
qui gérait ça.

Ce serveur de distribution était une machine virtuelle hébergée sur le NUC
"miroir" de l'association, le cluster Ceph n'étant pas du tout adapté à
cet usage intensif.

La VM a fonctionné non-stop depuis juillet 2018.  J'estime qu'elle a servi
entre 500 To et 800 To de trafic réseau au total pendant cette période.
Avec une moyenne de 11 KB par tuile, en comptant un overhead x2 pour
HTTP/TCP, ça fait au moins 30 milliards de tuiles servies !

Il y a des stats munin ici pour les personnes intéressées :
https://munin.openstreetmap.org/openstreetmap.org/noomoahk.openstreetmap.org/index.html

Le système utilisait un SSD NVMe "grand public" comme cache.  En deux ans
et demi, on a atteint 140 TB d'écriture dessus, alors que ce modèle est
garanti pour 150 TB d'écritures.  C'est un bon exemple d'utilisation
intensive où les SSD "pros" seraient pertinents parce qu'ils ont une
meilleure endurance.  Ceci dit, le SSD fonctionne encore très bien et il
servira pour les autres miroirs.

Pour les personnes curieuses, voilà la sortie de smartctl sur le NVMe :

=== START OF INFORMATION SECTION ===  
Model Number:                       Samsung SSD 970 EVO 250GB
Serial Number:                      S465NB0K515629D
Firmware Version:                   1B2QEXE7
PCI Vendor/Subsystem ID:            0x144d       
IEEE OUI Identifier:                0x002538
Total NVM Capacity:                 250,059,350,016 [250 GB]

SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning:                   0x00
Temperature:                        40 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    57%
Data Units Read:                    919,605,551 [470 TB]
Data Units Written:                 274,090,140 [140 TB]
Host Read Commands:                 33,408,023,825
Host Write Commands:                6,595,497,389
Controller Busy Time:               65,825
Power Cycles:                       44
Power On Hours:                     21,839
Unsafe Shutdowns:                   30
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    92
Temperature Sensor 1:               40 Celsius
Temperature Sensor 2:               47 Celsius


Pour les autres projets, voilà la place allouée et occupée, toujours en
prenant le maximum sur le dernier mois pour "lisser" les variations
naturelles :

| Projet          | Espace alloué | Espace occupé | Espace occupé | Evolution | Evolution |
|                 | janvier 2021  | janvier 2021  | octobre 2019  | absolue   |         % |
|-----------------+---------------+---------------+---------------+-----------+-----------|
| Debian          | 1288 GB       | 1159 GB       | 1.1 TB        | N/A       |       N/A |
| OpenWrt         | 1050 GB       | 935 GB        | 609 GB        | +326 GB   |      +54% |
| LineageOS       | 750 GB        | 412 GB        | 531 GB        | -119 GB   |      -22% |
| F-Droid         | 570 GB        | 484 GB        | 324 GB        | +160 GB   |      +49% |
| OpenWrt archive | supprimé      | supprimé      | 232 GB        | -232 GB   |       N/A |
| OpenStreetMap   | supprimé      | supprimé      | 160 GB        | -160 GB   |       N/A |
| CTAN            | 60 GB         | 43 GB         | 41 GB         | +2 GB     |       +5% |
| CPAN            | 50 GB         | 30 GB         | 28 GB         | +2 GB     |       +7% |
| Tails           | 80 GB         | 29 GB         | 23 GB         | +6 GB     |      +26% |
|-----------------+---------------+---------------+---------------+-----------+-----------|
| Total           | 3848 GB       | 3092 GB       | 3107 GB       | -15 GB    |           |


La suppression de la VM OSM a été discutée plus haut.  La suppression de
l'archive OpenWrt a été nécessaire par manque de place, et elle était
complètement inutilisée.  Pour Debian, l'espace semble stable mais il a
fallu supprimer quelques architectures non utilisées pour compenser
l'augmentation générale de taille.  Enfin, pour LineageOS, l'espace
utilisé est souvent variable parce qu'ils suppriment les anciens builds
avec une politique assez fluctuante.  C'est aussi pour ça qu'il y a
beaucoup d'espace alloué à LineageOS par rapport à l'utilisation actuelle.

Malgré les suppressions, on est tout juste à l'équilibre par rapport à
octobre 2019, et la place se faire rare : il ne reste que 80 GB à allouer
sur l'ensemble SSD 4 To + NVMe 256 Go.

La plus grosse augmentation est OpenWrt, et c'est un problème connu à
cause des builds "snapshots" qui s'accumulent.  J'ai remonté le problème,
mais si ce n'est pas corrigé et qu'il n'y a plus de place, on devra
arrêter de faire miroir pour les snapshots.

Ensuite, F-Droid a aussi fait +50% mais ça semble normal vu le nombre
croissant d'applications.

En tout cas, il va falloir réfléchir à des évolutions :

- acheter une deuxième machine ? Il lui faudrait au moins 4 TB de stockage
  pour pouvoir séparer les miroirs en deux et accompagner l'augmentation
  de place.

- peut-être en profiter pour tester ZFS en remplacement de LVM : LVM
  fonctionne très bien, mais ça oblige à configurer statiquement l'espace
  alloué à chaque miroir.  Quand un miroir diminue en taille (cas de
  LineageOS), on "gaspille" l'espace alloué.  Avec ZFS, tous les miroirs
  partageraient l'espace d'un même pool.


Niveau réseau, on était autour de 350 Mbit/s (au 95ème percentile) en 2020,
mais on a récemment perdu 150 Mbit/s avec l'arrêt du serveur OSM.  Ça
tient donc largement sur du gigabit.

Pour le breakdown du trafic par projet, je mesure avec une analyse de logs
(goaccess) moyennée sur une semaine :

| Projet    | Données servies | Données services | Evolution | Note       |
|           | Janvier 2021    | Octobre 2019     |           |            |
|-----------+-----------------+------------------+-----------+------------+
| Fdroid    | 720 GB/jour     | 450 GB/jour      | +60%      |            |
| LineageOS | 365 GB/jour     | 400 GB/jour      | -9%       |            |
| Tails     | 160 GB/jour     | 100 GB/jour      | +60%      |            |
| CTAN      | 81 GB/jour      | 1 TB/jour        | -92%      |            |
| OpenWrt   | 0.8 GB/jour     | 0.3 GB/jour      | N/A       | 95% robots |
| CPAN      | 0.5 GB/jour     | 0.4 GB/jour      | N/A       |            |
| Debian    | 0.2 GB/jour     | 2 GB/jour        | N/A       | 65% robots |


On voit une belle progression pour Fdroid et Tails, et une grosse chute de
trafic pour CTAN.  LineageOS est stable.  Les autres miroirs sont toujours
peu utilisés (parce que pas intégrés à des systèmes de distribution
automatique de charge).

Pour CTAN, la répartition par fichier est toujours dominée par MacTeX,
suivi par miktex (Windows).  Le volume plus faible est sûrement lié à un
changement de répartition de charge, parce que maintenant 70% du volume va
vers l'Europe.  En octobre 2019, c'était bien réparti entre Europe,
Amérique du Nord et Asie.

À bientôt pour le prochain point !
Baptiste
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 833 octets
Desc: non disponible
URL: <http://lists.tetaneutral.net/pipermail/technique/attachments/20210116/f7a2a8b7/attachment.sig>


Plus d'informations sur la liste de diffusion technique