Depuis 2017, nous essayons de vous fournir les meilleurs services possibles tout en combinant fiabilité et la recherche du meilleur rapport performance/prix.

Notre histoire ensemble a commencé par l'installation de nos premiers équipements en datacentre fin décembre 2018 à Rennes.

Notre premier routeur était un Mikrotik CCR1009 pour annoncer notre AS (39421), notre premier hyperviseur qui était un HP DL160 Gen8 avec 2 x E5 2630L, 128 Go de RAM et 4 x 500 Go SSD en ZFS.

Infrastructure à Rennes

Infrastructure de 2020/2021

En été 2020, nous avons décidé de migrer notre infrastructure chez notre partenaire dc2scale à Vélizy-Villacoublay en banlieue parisienne.

Ce changement nous a permis d'accélérer la croissance de notre activité, en proposant de nouveaux services tels que de la colocation ainsi des serveurs dédiés.

Cela nous a également permis d’améliorer nos services VPS par l’ajout de nouveaux hyperviseurs avec des disques NVMe.

Nous avons aussi fait le choix de l'ajout d'une connectivité 10 Gb/s sur tous nos serveurs, nous permettant d'être un des premiers hébergeurs alternatifs à proposer du 10 Gb/s sur toutes ses offres, et ce sans surplus ni limite de bande passante.

Nous avons aussi migré notre réseau sur du matériel Cisco (Cisco Nexus 9396PX effectuant le rôle de routeur de cœur de réseau).

Pour la distribution des dédiés clients livrés en 1 Gb/s, nous avons opté pour un commutateur Cisco Nexus 3048TP.


De nombreux défis

Durant ces 2 années à Vélizy-Villacoublay, le nombre de clients a fortement progressé. Nous avons mis en production de nouveaux hyperviseurs pour suivre la demande.

En août 2021, nous étions déjà à 9 hyperviseurs en production dans l’infrastructure VPS.

Cependant, nous avons rencontré quelques problèmes de stabilité de cellules sur nos SSD NVMe.

Initialement, nous avions opté pour des SSD NVMe de la marque Crucial, des Crucial P1, mais suite à ces problèmes, nous avons décidé de monter en gamme avec des Crucial P5.

Malgré ce changement de référence de SSD, les pannes sur nos hyperviseurs restaient malheureusement trop fréquentes à notre goût.

Après recherches, nous en avons déterminé que des modèles de SSD NVMe n'étaient pas compatible avec nos contraintes de production.

Cette situation était assez préoccupante, nous devions prendre des décisions structurantes pour sortir de ce mauvais pas. Nous avons donc repris de zéro notre infrastructure sur la base de notre expérience chèrement acquise.


La nouvelle infrastructure

Début 2022, nous avons préparé notre nouvelle baie et avons commencé à installer la nouvelle infrastructure. Cette infrastructure a été pensée pour être durable et robuste dans le temps.

Nous avons fait le choix de mettre des équipements du constructeur Arista en bordure du réseau. Nous avons opté pour l'Arista 7280SR3. Ce modèle dispose de 48 ports 25 Gb/s et de 8 ports 100 Gb/s. Ceci nous permettra par la suite de migrer tous nos hyperviseurs en 25 Gb/s. Nous en avons également profité pour passer nos interconnexions en 100 Gb/s avec notre transitaire.

Pour ce qui est de l'infrastructure VPS, nous avons décidé d'augmenter la densité par hyperviseur. Nous sommes passés de 9 à 4 hyperviseurs pour la même charge de travail.

Ces 4 hyperviseurs sont chacun équipés de deux processeurs Intel Xeon E5-2690 v4, 384 Go de RAM DDR4, 4 x 1 To en NVMe Intel Datacenter et sont connectés en 10 Gb/s pour l'accès internet.

Pour mémoire, les anciens serveurs avaient chacun deux processeurs Intel Xeon 2667 v2, 192 Go de RAM DDR3 et 2 x 1 To en NVMe Crucial P5.

Nous avons également remplacé les châssis HP DL360p Gen8 par des Dell R630, réduisant ainsi la consommation électrique globale et augmentant la fiabilité.

Voici un comparatif de la différence de performance entre les anciens et nouveaux CPUs :

Nous avons fait le choix technique de passer notre infrastructure en architecture hyperconvergée.

L'hyperconvergence consiste à faire tourner à la fois le cluster de stockage et les machines virtuelles sur les mêmes machines physiques.

Pour le cluster de stockage, nous avons opté pour la technologie CEPH qui est une technologie de stockage d'objets distribué via le réseau.

Nous avons mis un réseau dédié au stockage. Pour ce faire, chaque hyperviseur est équipé d'une carte 2 x 40 Gb/s dédiés à cet usage. Nous avons également deux commutateurs Cisco C3164PQ avec chacun 64 x 40 Gb/s en haute disponibilité pour le stockage. Nous prévoyons de remplacer les commutateurs Cisco par des Arista dans les semaines à venir pour réduire encore un peu plus la consommation électrique.

Grâce à la migration sous la technologie CEPH, tous les disques NVMe présents sur les hyperviseurs peuvent être utilisés dans le cluster de stockage.

Les données des machines virtuelles sont dispatchées sur l'ensemble des disques présents dans le cluster, permettant la réplication des données entre plusieurs machines physiques, ainsi que la tolérance à la panne d'un disque et/ou d'une machine physique.

Ceci nous permet d'atteindre des performances en lecture et écriture de 3 Go/s par machine virtuelle présentes sur nos hyperviseurs. Nous arrivons également à atteindre 45k IOPS par machine virtuelle.

Résultat en lecture séquentielle (block size de 4M) :

[email protected] ~# fio -ioengine=libaio -direct=1 -name=test -bs=4M -iodepth=128 -rw=read -runtime=60 -filename=test --size=50GB
test: (g=0): rw=read, bs=(R) 4096KiB-4096KiB, (W) 4096KiB-4096KiB, (T) 4096KiB-4096KiB, ioengine=libaio, iodepth=128
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [R(1)][100.0%][r=3435MiB/s][r=858 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=26834: Sun Feb 20 11:08:36 2022
  read: IOPS=738, BW=2953MiB/s (3096MB/s)(50.0GiB/17339msec)
    slat (usec): min=93, max=181770, avg=1336.52, stdev=4665.27
    clat (msec): min=39, max=404, avg=170.86, stdev=40.17
     lat (msec): min=55, max=404, avg=172.20, stdev=40.15
    clat percentiles (msec):
     |  1.00th=[  104],  5.00th=[  121], 10.00th=[  130], 20.00th=[  140],
     | 30.00th=[  148], 40.00th=[  155], 50.00th=[  163], 60.00th=[  174],
     | 70.00th=[  186], 80.00th=[  199], 90.00th=[  224], 95.00th=[  247],
     | 99.00th=[  305], 99.50th=[  334], 99.90th=[  384], 99.95th=[  397],
     | 99.99th=[  405]
   bw (  MiB/s): min= 1600, max= 3664, per=99.15%, avg=2927.91, stdev=392.14, samples=34
   iops        : min=  400, max=  916, avg=731.94, stdev=98.02, samples=34
  lat (msec)   : 50=0.01%, 100=0.80%, 250=94.71%, 500=4.48%
  cpu          : usr=1.15%, sys=18.70%, ctx=1656, majf=0, minf=10996
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.2%, >=64=99.5%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.1%
     issued rwts: total=12800,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=128

Run status group 0 (all jobs):
   READ: bw=2953MiB/s (3096MB/s), 2953MiB/s-2953MiB/s (3096MB/s-3096MB/s), io=50.0GiB (53.7GB), run=17339-17339msec

Disk stats (read/write):
  vda: ios=50518/4, merge=0/1, ticks=4301276/999, in_queue=4205716, util=97.96%

Résultat en écriture séquentielle (block size de 4M) :

[email protected] ~# fio -ioengine=libaio -direct=1 -name=test -bs=4M -iodepth=128 -rw=write -runtime=60 -filename=test --size=50GB
test: (g=0): rw=write, bs=(R) 4096KiB-4096KiB, (W) 4096KiB-4096KiB, (T) 4096KiB-4096KiB, ioengine=libaio, iodepth=128
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][w=2999MiB/s][w=749 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=26907: Sun Feb 20 11:16:39 2022
  write: IOPS=721, BW=2885MiB/s (3026MB/s)(50.0GiB/17744msec); 0 zone resets
    slat (usec): min=199, max=142087, avg=1368.38, stdev=4088.47
    clat (msec): min=44, max=381, avg=174.78, stdev=32.98
     lat (msec): min=44, max=382, avg=176.15, stdev=33.04
    clat percentiles (msec):
     |  1.00th=[  108],  5.00th=[  129], 10.00th=[  138], 20.00th=[  150],
     | 30.00th=[  159], 40.00th=[  165], 50.00th=[  174], 60.00th=[  180],
     | 70.00th=[  188], 80.00th=[  199], 90.00th=[  215], 95.00th=[  228],
     | 99.00th=[  279], 99.50th=[  313], 99.90th=[  355], 99.95th=[  359],
     | 99.99th=[  380]
   bw (  MiB/s): min= 1184, max= 3337, per=99.11%, avg=2859.76, stdev=380.88, samples=35
   iops        : min=  296, max=  834, avg=714.91, stdev=95.21, samples=35
  lat (msec)   : 50=0.09%, 100=0.55%, 250=97.08%, 500=2.28%
  cpu          : usr=31.14%, sys=17.43%, ctx=1221, majf=0, minf=10
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.2%, >=64=99.5%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.1%
     issued rwts: total=0,12800,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=128

Run status group 0 (all jobs):
  WRITE: bw=2885MiB/s (3026MB/s), 2885MiB/s-2885MiB/s (3026MB/s-3026MB/s), io=50.0GiB (53.7GB), run=17744-17744msec

Disk stats (read/write):
  vda: ios=0/50632, merge=0/5, ticks=0/4106809, in_queue=3995748, util=97.52%

Résultat d'écriture séquentielle (block size de 4k) :

[email protected] ~# fio -ioengine=libaio -direct=1 -name=test -bs=4k -iodepth=128 -rw=randwrite -runtime=60 -filename=test --size=10GB
test: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=128
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [w(1)][100.0%][w=159MiB/s][w=40.8k IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=26782: Sun Feb 20 11:02:46 2022
  write: IOPS=42.5k, BW=166MiB/s (174MB/s)(9955MiB/60003msec); 0 zone resets
    slat (usec): min=3, max=6440, avg=10.79, stdev=16.01
    clat (usec): min=691, max=67388, avg=2997.21, stdev=1408.40
     lat (usec): min=702, max=67405, avg=3009.20, stdev=1408.57
    clat percentiles (usec):
     |  1.00th=[ 1401],  5.00th=[ 1762], 10.00th=[ 1942], 20.00th=[ 2180],
     | 30.00th=[ 2376], 40.00th=[ 2540], 50.00th=[ 2737], 60.00th=[ 2900],
     | 70.00th=[ 3163], 80.00th=[ 3523], 90.00th=[ 4228], 95.00th=[ 5145],
     | 99.00th=[ 7767], 99.50th=[ 9241], 99.90th=[15664], 99.95th=[22152],
     | 99.99th=[37487]
   bw (  KiB/s): min=80151, max=187928, per=99.99%, avg=169874.93, stdev=15328.66, samples=120
   iops        : min=20037, max=46982, avg=42468.68, stdev=3832.22, samples=120
  lat (usec)   : 750=0.01%, 1000=0.07%
  lat (msec)   : 2=11.76%, 4=75.90%, 10=11.91%, 20=0.30%, 50=0.06%
  lat (msec)   : 100=0.01%
  cpu          : usr=32.03%, sys=50.08%, ctx=69602, majf=0, minf=11
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.1%
     issued rwts: total=0,2548523,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=128

Run status group 0 (all jobs):
  WRITE: bw=166MiB/s (174MB/s), 166MiB/s-166MiB/s (174MB/s-174MB/s), io=9955MiB (10.4GB), run=60003-60003msec

Disk stats (read/write):
  vda: ios=0/2543962, merge=0/29, ticks=0/6392817, in_queue=6405976, util=100.00%

Nous prévoyons également l'ajout d'un 5e hyperviseur dans les semaines à venir pour pouvoir augmenter le stock et augmenter l'efficacité de la réplication des données sur le cluster de stockage.


La phase de migration

Une fois le matériel installé, configuré et testé, nous devions effectuer une migration planifiée le 16 janvier 2022.

Nous avions initialement prévu de déplacer physiquement toute l'infrastructure (hyperviseurs, serveurs dédiés, serveurs en colocation et le réseau).

Cependant, nous avons rencontré de multiples problèmes qui nous ont contraint de repousser la migration.

Nous avons revu notre approche pour cette migration. Nous avons décidé en interne de commencer par la migration des serveurs en colocation ainsi que des serveurs dédiés.

Une fois cette migration effectuée, il nous restait l'intégralité des machines virtuelles présentes sur l'infrastructure VPS à migrer.

Nous avons préparé tout le plan d'action pour migrer les services avec le minimum de downtime possible. L'idée n'était plus de bouger les serveurs physiquement, mais de migrer machine virtuelle par machine virtuelle sur le nouveau cluster.

Pour ce faire, nous avons monté un serveur de partage de fichier NFS sur une machine virtuelle présente dans le nouveau cluster. Ceci nous a permis de déplacer les machines virtuelles avec un débit de 10 Gb/s et de les restaurer avec un débit pouvant aller jusqu'à 80 Gb/s.

Nous n'avons pas spécialement communiqué sur la migration étant donné que le downtime prévu par machine virtuelle était très faible. Cette migration était assez transparente, chaque machine virtuelle n'a été coupée que pendant 15 minutes au maximum.

À l'occasion de la migration de notre AS sur notre nouveau transitaire, nous avons constaté des graves effets de bords qu'il nous a fallu 24 heures pour corriger. Nous sommes très sincèrement désolés de la gêne occasionnée. Nous avons énormément appris de cette situation qui ne se reproduira pas.

Pour conclure sur cette migration, il faut préciser qu'il a fallu 7 jours pour migrer l'ensemble des machines virtuelles. Cela a représenté plusieurs heures de travail réparties entre 22h et 3h du matin, pratiquement tous les jours. En moyenne, chaque machine virtuelle a été interrompue pour le transfert entre 5 et 15 minutes selon la taille des disques.


Sapinet, c'est vert, c'est net

Depuis notre création, notre objectif est clair. Devenir un acteur de l'hébergement ayant réellement à cœur de limiter au maximum son impact environnemental.

Dans cette optique, nous avons décidé de migrer en décembre 2021 vers un datacentre qui a de sérieux atouts sur ce plan.

Notre nouveau datacentre fonctionne selon le principe du free-cooling direct, et recycle la chaleur.

Ce datacentre n'utilise aucun système de climatisation, mais régule la température qui parvient aux serveurs de manière à tenir une température qui ne varie pas plus d’un degré par demi-journée.

En cas de température extérieure élevée, le système se met alors à surventiler, et dans les cas les plus extrêmes (>33 °C), à micropulvériser de l’eau à l’admission d’air pour refroidir l’air entrant par un phénomène de refroidissement adiabatique.

L’ensemble du système de régulation fonctionne en 2N, et la chaleur est même recyclée en hiver et en mi-saison pour chauffer les locaux tout proches.

Son PUE est estimé à 1.1 sur un cycle annuel complet, et si le calcul du PUE tenait compte de la chaleur recyclée, le datacentre attendrait alors la performance remarquable d’un PUE de 0,7.

À titre de comparaison, un datacentre moyen dans le monde à un PUE de 1.5. En d’autres termes, et même en restant dans la définition la plus littérale du PUE, ce datacentre est 5 fois plus efficace que la moyenne.


Conclusion

Sapinet c'est avant tout une aventure de passionnés, passionnés par la technique, qu'elle soit réseau, serveur, stockage, ou même environnementale. Nous avons fait des pas de géant ces derniers mois, et vous pouvez compter sur nous pour continuer à avancer toujours plus loin vers la performance économique et écologique.

Merci de nous lire, merci d'être client, c'est grâce à vous que nous trouvons l'énergie de faire de Sapinet ce qu'il est.