Auteur Sujet: Insallation d'un serveur speedtest.net Ookla avec https et ramdisque  (Lu 233 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 30 223
    • Twitter LaFibre.info
Installation du logiciel serveur Ookla / SpeedTest.net avec https et ramdisque

Pré-requis : Ubuntu server / Debian avec Apache2 + PHP installé
Le ramdisque permet de garantir de très hautes performances.
Il est déconseillé de mettre le serveur SpeedTest sur une VM, pour des raisons de performances.
Un CPU récent 4 cœurs 8 threads et 8 Go de ram suffit, même si la documentation explique qu'il faut "Dual Socket Quad Core" pour des tests à 1 Gb/s.


L'exemple est donné pour le nom de domaine "massy.testdebit.info".
Il faut bien sur le remplacer par le votre.

Étape N°1 : Installation du HTTP Legacy Fallback

sudo -s
apt install zip unzip
adduser speedtest --disabled-login --gecos speedtest
mkdir /home/speedtest/tmpfs
echo "# RamDisque pour SpeedTest" >> /etc/fstab
echo "tmpfs   /home/speedtest/tmpfs   tmpfs   defaults,size=300M   0 0" >> /etc/fstab
mkdir /home/speedtest/files
wget -O /tmp/http_legacy_fallback.zip http://install.speedtest.net/httplegacy/http_legacy_fallback.zip
unzip /tmp/http_legacy_fallback.zip -d /home/speedtest/files/
rm /home/speedtest/files/speedtest/upload.asp
rm /home/speedtest/files/speedtest/upload.aspx
rm /home/speedtest/files/speedtest/upload.jsp
nano /etc/apache2/sites-available/speedtest.conf

<VirtualHost *:80>
ServerName "massy.testdebit.info"
ServerAlias "massy2.testdebit.info"

DocumentRoot "/home/speedtest/tmpfs"
<Directory "/home/speedtest/tmpfs">
Options None
AllowOverride None
Require all granted
</Directory>

ErrorLog "${APACHE_LOG_DIR}/apache2-speedtest-error.log"
CustomLog "${APACHE_LOG_DIR}/apache2-speedtest-access.log" combiport
</VirtualHost>
a2ensite speedtest.conf
service apache2 reload

vivien

  • Administrateur
  • *
  • Messages: 30 223
    • Twitter LaFibre.info
Insallation d'un serveur speedtest.net Ookla avec https et ramdisque
« Réponse #1 le: 09 février 2019 à 10:26:05 »
Étape N°2 : Installation de Let's Encrypt

add-apt-repository ppa:certbot/certbot
apt update
apt dist-upgrade
apt install python-certbot-apache
certbot --apache --domains massy.testdebit.info certonly
chmod 770 /etc/letsencrypt/archive/
chmod 770 /etc/letsencrypt/live/
chown root:speedtest /etc/letsencrypt/archive
chown root:speedtest /etc/letsencrypt/live/
chown root:speedtest /etc/letsencrypt/archive/massy.testdebit.info/fullchain1.pem
chown root:speedtest /etc/letsencrypt/archive/massy.testdebit.info/privkey1.pem

nano /etc/apache2/sites-available/speedtest.conf

Rajouter le code pour le https :

<VirtualHost *:443>
        ServerName "massy.testdebit.info"

        SSLEngine on
        SSLCertificateFile /etc/letsencrypt/live/massy.testdebit.info/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/massy.testdebit.info/privkey.pem

        DocumentRoot "/home/speedtest/tmpfs"
        <Directory "/home/speedtest/tmpfs">
                Options None
                AllowOverride None
                Require all granted
        </Directory>

        ErrorLog "${APACHE_LOG_DIR}/apache2-speedtest-error.log"
        CustomLog "${APACHE_LOG_DIR}/apache2-speedtest-access.log" combiport
</VirtualHost>

service apache2 reload

vivien

  • Administrateur
  • *
  • Messages: 30 223
    • Twitter LaFibre.info
Insallation d'un serveur speedtest.net Ookla avec https et ramdisque
« Réponse #2 le: 09 février 2019 à 10:29:54 »
Étape N°3 : Installation de OoklaServer (écoute sur le port TCP 8080)

su - speedtest -s /bin/bash
mkdir /home/speedtest/bin
cd /home/speedtest/bin/
wget http://install.speedtest.net/ooklaserver/ooklaserver.sh
chmod a+x ooklaserver.sh
./ooklaserver.sh install
nano /home/speedtest/bin/OoklaServer.properties

Ecouter uniquement sur le port 8080 en TPC et UDP + en IPv6 :

# The server listens to TCP port 5060 and 8080 by default. This can be changed to any other port if desired. Only a single port is required.
OoklaServer.tcpPorts = 8080

# The server listens to UDP port 5060 and 8080 by default. This can be changed to any other port if desired. Only a single port is required.
OoklaServer.udpPorts = 8080

# Remove the comment mark below to bind OoklaServer to IPv6
OoklaServer.useIPv6 = true

nano /home/speedtest/check_speedtest.sh
copier /coller ce fichier qui permet de démarrer le serveur et de vérifier qu'il est toujours up

#!/bin/dash
if [ `ps -C OoklaServer | wc -l` = "1" ]
then
  date >> /tmp/plantage_speedtest.log
  cd /home/speedtest/bin
  /home/speedtest/bin/OoklaServer --daemon >> /tmp/plantage_speedtest.log 2>&1
fi
chmod +x /home/speedtest/check_speedtest.sh

sortir de l'utilisateur speedtest : exit

nano /etc/cron.d/speedtest

# Auto restart on reboot
@reboot         speedtest   sleep 1 ; /home/speedtest/check_speedtest.sh
@reboot         speedtest   sleep 2 ; cp -r /home/speedtest/files/* /home/speedtest/tmpfs

# Auto restart SpeedTest on crash
*/5 * * * *     speedtest   sleep 20 ; /home/speedtest/check_speedtest.sh

nano /home/speedtest/bin/OoklaServer.properties

Rajouter la configuration https sous la ligne "# OoklaServer.enableAutoUpdate = true" :

#
# SSL Options
#

# Enable Let's Encrypt certificate generation (default)
#
# OoklaServer.ssl.useLetsEncrypt = true

# To use a custom certificate, create a certificate and private key and set the path to them here:
# (Note, this will disable Let's Encrypt certificate generation)
openSSL.server.certificateFile = /etc/letsencrypt/live/massy.testdebit.info/fullchain.pem
openSSL.server.privateKeyFile = /etc/letsencrypt/live/massy.testdebit.info/privkey.pem

reboot

vivien

  • Administrateur
  • *
  • Messages: 30 223
    • Twitter LaFibre.info
Insallation d'un serveur speedtest.net Ookla avec https et ramdisque
« Réponse #3 le: 09 février 2019 à 10:35:42 »
Étape N°4 : Vérifications

Vérifier que tout est OK en utilisant l'outil de test Ookla : https://www.ookla.com/host-tester

Si vous avez des questions, je peut répondre.

vivien

  • Administrateur
  • *
  • Messages: 30 223
    • Twitter LaFibre.info
Insallation d'un serveur speedtest.net Ookla avec https et ramdisque
« Réponse #4 le: 09 février 2019 à 21:50:39 »
STRAT38 m'a posé deux questions en message privé, je pense qu'il est intéressant que j'y réponde de manière publique.

concernant ton article https://lafibre.info/serveur-linux/insallation-serveur-speedtest/ je voulais juste savoir deux chose:
- concernant ramdisk, juste savoir comment tu as évalué " tmpfs   defaults,size=300M".

Je dimensionne la taille de mes ramdisque de manière a toujours être inférieur à 50% de remplissage, mon premier seuil de warning pour la supervision.
Ne pas oublier que la RAM consommée par un ramdisque est celle effectivement consommée : un ramdisque de 16 Go rempli à hauteur de 100 Mo, cela ne consomme que 100 Mo de RAM.

Voici l'utilisation des différentes partitions pour le serveur dédié SpeedTest de Massy (il n'héberge pas d'autres tests de débit) :
- / : Partition sur SSD de 36 Go pour le système
- /home : Partition sur SSD de 55 Go pour les données
- /tmp : ramdisque de 16 Go (je l'ai augmenté en juin 2018, car 13 Go (40% de la RAM) ne suffisait plus.
- /var/log/apache2 : ramdisque de 13 Go
- /home/speedtest/tmpfs : ramdisque de 300 Mo (98 Mo utilisé, c'est fixe)

La ligne verte à 50%, c'est le seul d'alerte.

Voici mon /etc/fstab :
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda2 during installation
UUID=1da7cec0-cf2e-4974-8305-46033424c198 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=CC0B-4EE0  /boot/efi       vfat    umask=0077      0       1
# /home was on /dev/sda4 during installation
UUID=4b9708c6-8682-4f40-811b-6ee93dfee951 /home           ext4    defaults        0       2
# swap was on /dev/sda3 during installation
UUID=cf75d319-458e-422a-bf13-134bccca2e37 none            swap    sw              0       0
# Placer /tmp sur un RamDisque
tmpfs                                     /tmp            tmpfs   defaults,size=50% 0       0
# RamDisque pour SpeedTest
tmpfs   /home/speedtest/tmpfs   tmpfs   defaults,size=300M   0 0
# RamDisque pour les log Apache2
tmpfs   /var/log/apache2        tmpfs   defaults,size=40%  0 0

Donc je m’aperçois que j'ai oublié dans mon tutoriel de mettre /tmp dans un ramdisque, c'est important, car c'est la que php garde les fichiers uploadé pendant le test (cela ne concerne que les tests de débit legacy)
Sans ramdisque, vous allez user votre SSD pour des performances moins bonnes.

Pour la même raison, je mets les log Apache2 en ramdisque (4 jours d'historique seulement)


- dans l'optique d'une utilisation plus standardisé d'un serveur https+apache ( pas de speedtest) qui tourne sur un ssd avec optimisation des accès disques, est-ce que le ramdisk est encore vraiment nécessaire ?

Tout ce qui est test de débit, je mets en ramdisque, car les SSD, c'est plus rapide que les disques dur mais, cela reste très limité pour des tests à 1 Gb/s ou plus.

Sur un autre serveur, j'ai calculé que le débit utile est limité à 400 Mb/s par SSD (ici c'est un RAID 0 hardware de deux SSD Intel de 960 Go, afin de doubler les performances) :


Il y a un mois, j'avais l'archive Ubuntu qui était pour grande partie sur un SSD de 1 to et sur un disque dur classique de 500 Go.

Depuis trois semaines, j'ai maintenant tout sur SSD (un RAID 0 hardware Dell PERC H330 de deux SSD Intel de 960 Go chacun, connecté en SATA et avec des puces MLC)

J'ai donc ouvert le serveurs aux connexions rsync comme le font presque tous les serveurs par défaut pour un pays et je vois que c'était attendu car sans même communiquer sur cette nouvelle fonctionnalité, j'ai eu plusieurs synchronisations.

Problème : je suis déçu par les performances des SSD, vous allez comprendre dans les stats : je sature un RAID 0 de deux SSD avec un débit en lecture de 100 Mo/s (800 Mb/s). Pourquoi ?

Rsync: Quantités de données échanges via Rsync, par période de 5 minutes, en Go :

On est a environ 19 Go/5minutes soit environ 500 Mb/s.

Rsync: Nombre de fichiers échangés par période de 5 minute :

On est a environ 10k fichiers/5minutes, soit 33 fichiers par seconde environ (pic de 65k fichiers/5minutes, soit 220 fichiers par seconde

Regardez l'impact sur l'utilisation disque :

Pourcentage d'utilisation des disques: (c'est un RAID 0 hardware constitué de deux SSD Intel 960Go MLC en SATA)

"sda" correspond au RAID 0 hardware de deux SSD Intel

Les caractéristiques de la carte RAID Dell PERC H330 dans le lscpi -v :

03:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS-3 3008 [Fury] (rev 02)
   DeviceName: Integrated RAID
   Subsystem: Dell PERC H330 Adapter
   Flags: bus master, fast devsel, latency 0, IRQ 18
   I/O ports at 3000 [size=256]
   Memory at 95c00000 (64-bit, non-prefetchable) [size=64K]
   Memory at 95b00000 (64-bit, non-prefetchable) [size=1M]
   Expansion ROM at <ignored> [disabled]
   Capabilities: [50] Power Management version 3
   Capabilities: [68] Express Endpoint, MSI 00
   Capabilities: [d0] Vital Product Data
   Capabilities: [a8] MSI: Enable- Count=1/1 Maskable+ 64bit+
   Capabilities: [c0] MSI-X: Enable+ Count=97 Masked-
   Capabilities: [100] Advanced Error Reporting
   Capabilities: [1e0] #19
   Capabilities: [1c0] Power Budgeting <?>
   Capabilities: [148] Alternative Routing-ID Interpretation (ARI)
   Kernel driver in use: megaraid_sas
   Kernel modules: megaraid_sas


Débit en Mo/s lu / écrit sur les disques: (Ne correspond pas au trafic réseau, car la RAM cache les données les plus lues)

On est sur un trafic de 650 à 800 Mb/s, soit 150 à 300 Mb/s de plus que le débit RSYNC => C'est lié au fait que le transfert RSYNC doit vider du cache disque des fichiers fortement demandés.

Nombre de IOPS sur les disques (opérations d'entrée-sortie par seconde) :
 

Latence accès disque (enfin le RAID 0 de SSD) :


Avec un disque saturé à 100% en E/S, le Load average explose et le CPU attend les E/S (iowait) :
 

Bien sur il n'y a pas que RSYNC qui charge le serveur, il y a les requêtes http de mise à jour de milliers d'ordinateurs, mais c'est toujours les mêmes fichiers qui sont chargés et le contenu est probablement en cache RAM (il y a 32 Go de RAM)

Débit des connexions Apache (mises à jour via http/https) en Mo/s :   Nombre de fichiers téléchargés par seconde :
   

Trafic réseau en Mb/s sur la carte réseau : (comprend donc les requêtes http/https et rsync)


vivien

  • Administrateur
  • *
  • Messages: 30 223
    • Twitter LaFibre.info
Insallation d'un serveur speedtest.net Ookla avec https et ramdisque
« Réponse #5 le: 09 février 2019 à 22:07:08 »
Tant que je suis dans les statistiques, le serveur SpeedTest de Massy est dédié à SpeedTest.net (nPerf est sur un serveur voisin avec 4GMark, de même que iPerf / Testdebit.info qui est sur un troisième serveur, chacun avec 10 Gb/s dédié)

Voici le load average : il a été longtemps très haut sans que je comprenne pourquoi une telle charge, car :
- le CPU (un Xeon E3-1240 v5 @ 3.50GHz) ne semblait pas trop chargé, on restait à moins d'un thread utilisé (moins de 100% sur une échelle qui va à 800%)
- il n'y a aucune entrée / sortie disque vu que tout est sur des ramdisque.

Load average est bien lié au débit (au début les serveurs SpeedTest étaient en anycast, donc le serveur de paris recevais presque tout le trafic, depuis c'est interdit et les serveurs de région (Lille, Lyon, Marseille, Boredaux) reçoivent beaucoup plus de trafic.

La baisse spectaculaire du load average fin octobre est lié uniquement à l'upgrade Ubuntu 16.04 => Ubuntu 18.04

Ce n'est pas lié a un changement de noyau Linux, car la version 16.04 utilisait déjà le Kernel 4.15 quelques mois avant la mise à jour
(j'utilise les Kernel HWE avec une mise à niveau de la version tous les 6 mois, afin d'avoir toujours un kernel récent, ce qui permet de bénéficier rapidement des optimisations TCP/IP. En ce moment mes serveurs sont en Kernel 4.18, qui apporte des avantages en terme de performance, cf J'ai fait passer plusieurs serveurs sous Ubuntu 18.04 du noyau 4.15 vers le noyau 4.18 : Gain de performance dans certains cas)



Débit moyenné sur 24h (un point = un jour)

 

Mobile View