Des nouveaux serveurs pour le Gladys Gateway?

Salut à tous !

Afin d’améliorer la performance et la latence du Gladys Gateway (déjà excellente, mais c’est toujours possible de mieux faire! :smiley: ), je suis entrain de réfléchir à upgrader les serveurs afin de passer à des instances “High Compute” de chez Vultr, localisé en France.

En effet, avec les nouveaux usages de la v4 (caméra et cie), le Gladys Gateway est de plus en plus sollicité, et j’aimerais être sur que cette augmentation de l’usage ne soit pas au détriment de la qualité de service.

J’ai fais un benchmark de ces types d’instances, que j’ai publié sur mon blog:

Salut,

Tu as déjà des métriques des serveurs actuels au niveau CPU / RAM / Disk / Network histoire de dimensionner suivant ce qui est utilisé aujourd’hui ?

Je ne sais pas si tu connais, mais y’a des choses pas mal aussi ici : Dedicated servers in Paris, France | OneProvider

Je viens de voir que chez VULTR, il y a une limite de bande passante mensuel j’imagine, cela peut sans doute devenir limitant suivant ta conso future

  1. First droplet is running the PostgreSQL database.
  2. Second droplet is running 4 Docker containers:
  3. Redis
  4. Gladys Gateway server
  5. Nginx-proxy for SSL
  6. Let’s Encrypt companion to renew SSL certificate automatically

Comment sont géré les connexions entre Gladys Gateway et Gladys ?

Dans l’idée, pour répartir ta charge, tu ne pourrais pas envisagé plusieurs instances Gladys serveur sur plusieurs serveur, et tu place un haproxy devant qui va répartir la charge ? Ça te permettrait d’avoir une haute dispo par la même occasion.

J’ai des métrics, après c’est plus par rapport à des tests que j’ai réalisé avec les nouveaux usages que j’aimerais upgrader en prévision + pour mettre les serveurs en France.

Jusque-là, j’avais décidé de séparer la VM de DB de la VM du serveur afin de laisser de l’air à la DB, mais au final avec l’expérience, le serveur du Gateway n’interroge que très peu la DB (c’est principalement un passe plat de websockets), et donc la seule VM qui bosse c’est la VM du serveur.

Ca me fait mal de payer une VM de DB qui tourne à 1% de CPU toute la journée et avec 80% de la RAM vide, je pensais donc prendre une seule VM au lieu de deux dans le nouvel hébergeur, la DB tournera sur cette VM aussi.

Je connais, j’ai un serveur chez eux ! Je sais pas, d’impression OneProvider ça me semble pas très « pro ». En regardant les différents serveurs, les CPUs ont l’air de dater un peu (après des recherches sur CPUBenchmark) et on a pas trop d’infos sur les disques montés (Oui SSD, mais NVMe?, etc…). Pareil pour le SLA, la stabilité du réseau, je suis pas hyper confiant, tu as de l’expérience avec eux? Je me trompe peut-être.

Ce n’est pas une limite, c’est un « free tier », ensuite c’est payant en supplément. Je suis d’accord avec toi, c’est le seul point qui est « dommage », après je me demande si justement les hébergeurs avec ce genre de pratique ne sont justement pas les hébergeurs chez qui le réseau est « stable ».

Je m’explique: de toute manière, sur le rack tu partage ton cable avec d’autres serveurs. Chez des providers type DigitalOcean/Vultr, la bande passante supplémentaire est payante et donc tu ne retrouve pas avec des voisins abusifs qui font du torrent et te prennent toute la bande passante, car ce genre d’usage n’a pas de sens sur ces plateformes. Dans des hébergeurs avec la bande passante illimitée, le risque c’est qu’un gars d’un coup se retrouve sur le même rack et te pourrisse ta connexion…

Après, si l’usage grossit beaucoup, ça peut effectivement être limitant, mais pour l’instant on est encore très loin de péter les 3 To mensuels. Lorsqu’on arrivera à ce point là, on pourra soit prendre plus de serveurs, soit changer de provider, c’est pas si lourd de changer, mon archi étant en full docker je déploie l’infra en quelques minutes :slight_smile:

Je pensais aussi à ça au début comme moyen de scaler, mais avec l’expérience je ne pense pas que c’est comme ça que je vais procéder à terme (je dis à terme, car on est encore très loin d’avoir besoin de scaler horizontalement)

Explication :

  • Lorsqu’une requête arrive sur le Gladys Gateway, il n’y a pas de « boulot » à effectuer, il faut juste rediriger le traffic vers l’instance Gladys correspondante, le Gladys Gateway n’est qu’un proxy lui aussi !
  • La mesure la plus importante pour nous, c’est la latence entre le client et le serveur. Il y a très peu de calculs/accès disque.

Lorsque notre premier serveur de Gateway sera saturé, et que je n’aurais plus de moyen de scaler verticalement (on a de la marge vu l’offre Vultr…), j’ouvrirais des serveurs dans d’autres datacenters, plus proche des zones d’activité de Gladys.

Si par exemple, j’ai beaucoup d’utilisateurs à Marseille, j’ouvrirais un serveur « Marseille » chez un hébergeur local, et le traffic Marseille ira via cette instance.

Centraliser le traffic via un HAProxy n’aurais pas trop d’intérêt, car la VM de load balancing ne pourrait elle même pas gérer plus de traffic que les VMs de backend derrière (qui ne font pas plus de travail qu’un load balancer en somme)

Websockets

One provider c’est online en faite, on vient de prendre avec des collègues un serveur 2 xeon 128Go de ram et 3*3To de stockage, je pourrais te faire un retour à l’utilisation dessus :wink:

Pas forcément, si tu as un dédié, tu es seul sur ton cable en sortie de ton serveur.
Par contre, en sortie / entrée du data, tu sera forcément mutualisé avec les autres (a moins d’avoir ta fibre qui arrive dans le data), c’est plus le capacité du datacenter qui fera la différence, parce qu’aujourd’hui la majorité des serveurs ont mini des cartes 10G.
Ensuite suivant les offres, l’hébergeur peut mettre de la QOS pour garantir que ton 1G t’appartient et que les autres autour ne peuvent pas te polluer… ou pas ^^

La map d’interco online : map.online.net (des jolies petits pic actuellement à plus de 3.5Tb :slight_smile: )

Pour le taux de dispo, pour casie tous les data tu as du 99,9% grand minimum, c’est très facile à avoir. (https://uptime.is/) du fait que les alim, carte réseau, Switch, arrivé électrique sont redondé (voir même le stockage en ceph par exemple)

J’ai plutôt l’inverse en termes d’expériences, prévoir l’architecture de base pour monter en charge, permet de basculer plus facilement sans interruption de service après.

Ah, ça me rassure pas du coup ^^

En analysant en détail l’offre OneProvider, je reste du point de vue que ces instances Vultr sont bien plus adaptée à l’usage pro, les soucis de haute disponibilités, et la qualité de service que je recherche ! Tout ça pour un prix très doux au départ, et qui peut m’accompagner fluidement en cas de montée en charge.