[technique] Etat des miroirs chez tetaneutral.net

[Baptiste Jonglez]

Bonjour Marc,

On 30-10-23, Marc_marc via technique wrote:
> Le 30.10.23 à 11:21, Baptiste Jonglez via technique a écrit :
> > # Utilisation disque
> > | OpenWrt   | 2160 GiB
> 
> > # Trafic réseau
> > Sur mirror-02, <...> environ 181 TiB envoyés par an. trafic entrant
> > (pour synchroniser les miroirs) <...> 45 TiB reçus par an.
> > le trafic du miroir OpenWrt représente les 15% restants
> 
> cad ~7TiiB/an

Non, les 15%, c'est pour le trafic sortant (principalement via rsyncd), et
non le trafic entrant.  Ce chiffre de 7 TiB / an de trafic entrant ne
correspond pas à la réalité.

Nous n'avons actuellement pas de statistiques détaillées sur le trafic
entrant lié à la synchronisation des miroirs, je ne suis donc pas capable
de fournir un chiffre ou même une estimation sur ce point.

> > # Trafic HTTP
> > | OpenWrt     | 2.8 GiB/jour    55% à 75% robots |
> 
> cad un traffic utilisateur d'environ ~0.4TiB/an
> 
> > # Trafic rsync
> > | Trafic rsync | 2023 (10 mois)
> > | OpenWrt      | 32088 GiB
> 
> > les plus gros consommateurs viennent des pays suivants : Kazakhstan,
> > USA,
> 
> l'ip correspond aux mirroirs renseigné sur le wiki ?

Bien vu, je n'avais pas pensé à cette liste, c'est en effet mirror.ps.kz
pour le Kazakhstan, et le miroir de Starburst Services pour les USA.

> > Singapore (CDN77)
> 
> cela m'a pas l'air d'être le même AS que le miroir du pays (M1)

En effet, ça semble différent, mais c'est dur à dire, on voit une IPv6 qui
se connecte, alors que le miroir renseigné côté wiki OpenWrt n'a qu'une
IPv4 dans son DNS.

> > Thaïlande
> 
> c'est pertinent alors qu'il y a un miroir à Singapore ?

Nous ne contrôlons pas qui se synchronise sur notre miroir.

> d'une manière générale, OpenWrt
> - a un très faible volume http "utilisateur" ~0.4TiB/an
> - un traffic nécessaire pour le synchroniser ~7TiiB/an
> je me demande si ces synchronisation de miroir font économiser
> du traffic réseau ou si la synchronisation des miroirs
> consomme plus de traffic qu'elle n'en fait économiser :
> si on compte que les utilisateurs http(s) direct, 7TiiB entrant
> pour servir 0.4TiB sortant, il n'y pas de gain en traffic,
> au contraire la synchro consomme ~17x ce qu'elle délivre.
> Pour la majorité des utilisateurs il n'y a probablement pas non
> plus de gain de latence (vu la proximité du miroir principal,
> j'ignore cependant la vitesse du miroir principal)
> Et pour les miroirs qui se synchronise chez TTN, cela ne changera
> pas pas réellement la situation globale d'utiliser le miroir principal
> 
> d'autant que OpenWrt est le plus gros consommateur disque 2TiB
> 
> > OpenWrt <...> pas partie d'un système de répartition de charge
> 
> cela a l'air de rendre le miroir peu efficace, sauf à titre
> de secours en cas de panne du miroir principal

C'est un choix du projet OpenWrt, ce n'est pas tetaneutral tout seul qui
peut changer ça.

Notre miroir a tout de même un petit intérêt : disponible en cas de panne
du serveur principal, utilisation locale du miroir pour builder des images
OpenWrt, diminution de la charge sur le serveur principal puisque d'autres
miroirs se synchronisent sur nous plutôt que sur lui (mais c'est un
argument assez circulaire je l'admets).

C'est assez similaire pour Debian, ça nous prend une place conséquente
pour un traffic utilisateur relativement faible.  Mais c'est utilisé par
pas mal de machines dans le réseau de tetaneutral et un peu plus
largement.

De manière générale, le non-objectif de rentabilité de tetaneutral permet
de s'affranchir (en partie) des strictes questions d'efficacité.  Cela
permet de founir un service sur le temps long, même si il n'est pas
efficace ou "rentable" dans un premier temps.  Peut-être qu'il deviendra
davantage utilisé sur le long terme, justement parce qu'il est
particulièrement stable et pérenne.

Bien sûr, si tous les miroirs avaient un aussi faible taux d'utilisation,
ça remettrait en question l'investissement en temps bénévole, en énergie,
en matériel et en argent de l'association pour ce projet.  Heureusement,
ce n'est pas le cas.

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/20231030/e603dfb2/attachment.sig>