Discussion sur l'infrastructure de Zeste de Savoir

Ou comment améliorer ça

a marqué ce sujet comme résolu.

Ce message a pour objectif de discuter de l'infrastructure actuelle, des améliorations possible et pourquoi pas fournir une proposition lors du prochain CA.

État des lieux

Aujourd'hui on dispose de 2 serveurs :

  • prod, un VPS CLOUD 2 avec 4Go RAM et 50Go HDD à 20€ TTC ;
  • preprod (ou beta), un VPS dont l'offre n'existe plus et dont il faut me confirmer le prix et la configuration.

On a également :

  • un sentry hébergé par sandhose ;
  • un munin hébergé par spacefox ;
  • 2 ou 3 versions faisant office de beta pour des POC ou des ZEP sur des serveurs des développeurs (artragis, sandhose, moi-même) ;
  • les backups chez spacefox (à confirmer).

Les problèmes

Le premier problème visible : tous les services ne sont pas chez Zeste de Savoir. Pour X ou Y raison, si spacefox ou sandhose venait à être indisponible ou perdre des informations (pas de renouvellement de leur serveur par exemple) : c'est la merde !!

Le second implique un problème de performances. Pour l'heure actuelle ça va mais si le site venait à grossir rapidement on pourrait vite avoir des soucis de perf aux heures de pointe (on est sur du VPS, pas du dédié). Un autre souci est la place qu'offre un VPS : 50Go. On va pas se mentir c'est beaucoup, mais on en a déjà une bonne partie d'utilisée.

Propositions d'amélioration

Je vous propose donc une solution qui est la mienne. Elle n'est pas forcément idéale et est à discuter.

Je vous invite à proposer d'autres solutions si jamais vous avez des idées ! Pour le moment on met de côté le coût mais essayer d'être réaliste et raisonnable ;)

Ce dont on a besoin :

  • prod
  • preprod (une minimum)
  • sentry
  • munin
  • mysql
  • mail

Proposition 1 (gustavi)

Serveur 1

Serveur dédié avec de la virtualisation (Xen, Esx, Promox, etc) qui contient plusieurs VPS (ou container selon le choix de la techno) :

  • prod : le serveur de production, le plus gros avec le plus de ressources et la priorité dessus.
  • alpha : un serveur qui est mis à jour à chaque modification de la branche dev (à chaque commit).
  • beta : un serveur qui joue le même rôle qu'à l'heure actuelles, à savoir faire des tests avant chaque release. Il serait mis à jour à chaque nouvelle release ou RC.
  • beta2, beta3, etc : plusieurs VPS qui peuvent être activés à la demande des développeurs. L'objectif est de pouvoir faire des tests, des POC ou de travailler sur des ZEP sans passer par la beta ou nos serveurs personnels. Ainsi sandhose peut déployer une version avec son nouvel éditeur pendant que moi-même déployera une version avec la ZEP-13 dans quelques jours. C'est très flexible.
  • mysql : le serveur de base de données. Il regroupe toutes les bases des serveurs cités précédemment.
  • (mail) : le serveur de mail. Je pense qu'on peut l'intégrer à la prod dans la mesure où sur les beta on ne l'utilise pas.

Une solution alternative serait de séparer ce gros serveur en deux plus petits : un avec la prod et un avec tout le reste.

Serveur 2

Serveur VPS qui permet la gestion des autres serveurs, il contient :

  • le sentry pour la gestion des erreurs post-production ;
  • le munin pour le monitoring ;
  • pourquoi pas un nagios pour orchestrer le tout.
+10 -0

De la définition des problèmes

Dépendances à des tiers

Le problème de la propriété des données en est un vrai, c'est d'autant plus gênant pour la sauvegarde (qui est faite chez moi, copiée sur un serveur distant en cas de crash disque).

Par contre, si Munin ou Sentry crashent, ce n'est pas très grave : on en remonte ailleurs. C'est juste con.

Performances

Aujourd'hui, le point noir, c'est le CPU, et dans certains cas les I/O disque. À noter qu'en cas de croissance de ZdS, on peut facilement corriger ce problème en mettant à jour le VPS vers un CLOUD3 (2 –> 4 cœurs, 4 –> 8 Go de RAM, 50 –> 100 Go de disque).

L'espace disque n'est pas un problème, ici depuis le nouveau serveur :

Fiabilité

Le principal inconvénient du VPS, c'est que ses performances sont assez instables au cours du temps, même si dans la très grande majorité des cas, avec le VPS actuel fait pour de la prod, ça reste tout à fait correct.

L'énorme avantage, c'est l'indépendance aux pannes matériel à coût modique. Un disque dur ou un SSD qui crashe, c'est fréquent. Et même chez des gens comme online.net, qui remplacent le matos sans soucis, si on a pas de contrat « pro » (et donc relativement cher), on parle de plusieurs jours d'indisponibilité. On doit donc avoir un serveur avec du RAID et savoir le surveiller et le gérer.

À noter que les serveurs accessibles niveau prix et qui supportent le RAID n'ont souvent pas de SSD.

Comment améliorer l'infrastructure ?

Contraintes

  1. Rien ne doit pouvoir perturber la prod. Rien, pas même les effets de bord idiots du genre « Une autre VM squatte toutes les I/O » (encore vu récemment au boulot). Et c'est notre principal problème aujourd'hui, ce serait idiot de changer de solution mais pas de problème. Donc :
    1. La prod est sur un serveur séparé du reste.
    2. La BDD de prod n'est pas sur un serveur partagé.
  2. Ne pas oublier le serveur de sauvegarde (bacula actuellement)
  3. On doit pouvoir administrer tout ça. Aujourd'hui on galère a gérer nos serveurs. Alors quand je vois passer un serveur alpha automatiquement mis à jour… c'est intéressant, mais quand on aura recruté deux admins sys supplémentaires.

Exemple d'infrastructure réintégrée

Serveur de production

La prod, assez puissante et indépendante de tout le reste.

Contient tout ce dont a besoin la prod :

  • Serveur HTTP
  • Gunicorn (ZdS)
  • Solr (ZdS)
  • MySQL spécial prod (ZdS)
  • L'envoi de mails

Tout ça peut être installé sur 1 machine ou jusqu'à 1 composant par machine. Je préfère la solution d'une machine : c'est plus facile de trouver des machines correctement dimensionnées (les besoins CPU/RAM/disque/IO dont différents selon les éléments), c'est plus simple à administrer, il n'y a pas de problèmes de communications entre les machines.

Physiquement ça peut être n'importe quoi : VPS, Dedibox XC 2015 (si on trouve une combine pour le disque), Dedibox Classic 2015, …

Le serveur du reste

Une machine sur laquelle on peut installer (via des VMs, directement, etc) le reste :

  • La sauvegarde. Prévoir pas mal de place (elle me prends presque 50 Go là).
  • Le serveur de bêta
  • Munin
  • Sentry
  • Un serveur MySQL pour tous les outils qui ne sont pas la prod
  • Dans le futur : nos idées : bêtas supplémentaires, alpha auto-déployée, nagios, etc

Physiquement, c'est probablement un dédié à cause de l'espace disque nécessaire.

Ca me choquerais pas que Solr, soit stocké sur un autre serveur (avec d'autre truc). ça libérait un peu d'espace cpu. Elle concerne pas de fonctionnalité critique et donc on s'en fout un peu que le temps de réponse soit pourri. Si c'est sur des machines sur le même réseau interne pourquoi pas.

+2 -0

Bon on relance pour de vrai !

Donc si on fait un mix de ce qui a été proposé, l'idéal serait :

  • Serveur prod : uniquement la production (web + BDD + Solr + mails)
  • Serveur preprod : la beta + (alpha +) des beta spécifiques + backup
  • Serveur monitoring : munin + sentry + nagios

Note : on pourrait éventuellement externalisé/séparer la partie sauvegarde.

Les besoins par serveurs sont les suivants :

  • Serveur prod : rapide et performant.
  • Serveur preprod : performances moins importantes, pas mal de stockage en revanche.
  • Serveur monitoring : peu de ressources.

Il faudrait donc définir en détails nos besoins en terme de ressources pour les donner à Gandi et avoir une offre. Je pense aussi qu'on peut leur demander tout ce qui est NDD et pourquoi pas un WildCard ?

Sinon, si Gandi ne nous convient pas, je pense qu'on peut regarder du côté des nouvelles Dedibox qui sont même plus intéressantes que les Kimsufi (no fake) : https://www.online.net/fr/serveur-dedie#perso

Si vous avez d'autres bons plans allez-y !

+4 -0

Je ne suis pas tout à fait d'accord avec mon voisin du dessus, mais ça tient surtout du détail.

Généralités

  • On a aujourd'hui environ 1/4 d'admin système, donc on doit faire simple

Production

Contraintes

  1. Tolérant aux pannes
  2. Assez performant pour tenir un pic de charge raisonnable
  3. Assez performant pour tenir une prévision de croissance réaliste, ou facilement évolutif
  4. Performances fiables dans le temps, à charge égale

Consommation actuelle

Utilisation annuelle de l'espace disque, 100 % de / = 50 Go.

On est donc large pour un moment.

Utilisation des I/O disque, quotidienne et mensuelle.

On ne fait peu lecture sur le disque (la moyenne est faussée par la sauvegarde, visible aux pics quotidiens), signe que MySQL et tous les caches sont bien configurés. On fait par contre pas mal d'écritures, une partie non négligeable étant due aux indexations du moteur de recherche.

Utilisation CPU (x86 de puissance normale, pas du Atom-like), quotidienne et mensuelle.

Plusieurs enseignements intéressants ici :

  1. On consomme beaucoup de CPU vus le nombre de visiteurs sur le site. C'est en partie inhérent à la technologie (Python / Django), je pense.
  2. On est quand même pas CPU-limited
  3. Mais on l'est en cas de pic de charge. Le gros pic sur le graphe mensuel, c'est 8 à 12 pages (le HTML, généré par Django) par seconde, selon les pages, et le ralentissement associé du site est sensible.
  4. Il nous faudrait donc plus de puissance CPU, mais pas énormément. 3 ou 4 cœurs identiques aux actuels me paraissent largement suffisants pour un bon moment.
  5. Vus les temps minimaux de génération des pages HTML, ça ne me paraît pas une bonne idée de partir sur une solution avec plus de cœurs mais moins puissants (genre ARM ou Intel Avoton), au moins pour la prod.

Utilisation mémoire, quotidienne et mensuelle.

4 Go sans SWAP semblent suffisants, on même encore de la RAM libre (même pas utilisée par le cache disque).

Trafic réseau, quotidien et mensuel.

Même la sauvegarde n'est pas limitée par le réseau, mais par les accès disque (parce que c'est principalement des dépôts Git, donc des tas de minuscules fichiers).

Proposition 1 : IaaS Gandi

En partant sur 4 cœurs, 4 Go de RAM, 50 Go de disque, j'arrive à environ 48 €/mois, 34 €/mois si on achète les crédits par pack de 2 000 000 (4 mois de fonctionnement d'un coup).

Avantages

  • Soutien possible, donc réduction massive possible sur le prix
  • Très souple : on peut gonfler très facilement le serveur en cas de besoin
  • VPS : tolérance aux pannes par conception
  • Disponible quand on veut

Inconvénients

  • Aucune garantie sur la puissance CPU et surtout sur la réactivité des disques (à demander à Gandi)

Proposition 2 : Dédibox Classic 2015

Les modèles inférieurs n'ayant qu'un seul disque et donc pas de RAID possible, ils ne conviennent pas pour la prod.

Avantages

  • Serveur dédié : on est impactés par personne.
  • Puissance largement suffisante, sauf énorme croissance surprise (on est à 0 % depuis le début de l'année).

**Inconvénients

  • Disponibilité assez aléatoire
  • Disque dur et pas SSD (même si ce n'est pas critique normalement)
  • Serveur dédié = pas de site si le serveur lâche

Bêta + sauvegarde + Sentry + éventuels environnements supplémentaires

Cette dédibox https://www.online.net/fr/serveur-dedie/dedibox-xc me parait bien, en version HDD : espace disque et puissance suffisants pour tout notre bordel, 100 Go pour une copie externalisée de la sauvegarde si le serveur lâche. Le problème est la disponibilité.

Supervision

Un VPS le moins cher qu'on trouve, genre https://www.scaleway.com/

Nagios peut attendre.

On a un compte et des crédits chez Gandi pour faire des tests.

Avant d'installer quoi que ce soit, est-ce qu'on pourrait réfléchir à une arborescence de déploiement plus intelligemment qu'aujourd'hui ?

Pour information, on a tout en vrac dans un seul dossier :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
zds@vps41247:/opt$ tree -d -L 3
.
└── zdsenv
    ├── apache-solr
    │   ├── bin
    │   ├── contrib
    │   ├── dist
    │   ├── docs
    │   ├── example
    │   └── licenses
    ├── bin
    ├── include
    │   └── python2.7 -> /usr/include/python2.7
    ├── lib
    │   └── python2.7
    ├── local
    │   ├── bin -> /opt/zdsenv/bin
    │   ├── include -> /opt/zdsenv/include
    │   └── lib -> /opt/zdsenv/lib
    ├── logs
    ├── mails_beta
    └── ZesteDeSavoir
        ├── articles-data
        ├── assets
        ├── broken-tuto-before-zep12
        ├── conf
        ├── contents-private
        ├── contents-public
        ├── dist
        ├── doc
        ├── errors
        ├── fixtures
        ├── geodata
        ├── media
        ├── scripts
        ├── static
        ├── templates
        ├── tutoriels-private
        ├── tutoriels-public
        ├── watchdog-build
        └── zds

39 directories

On pourrait séparer tout ce qui est -private, -public et media et les stocker à par sur le serveur. L'avantage c'est qu'on pourrait backup plus facilement ce genre de choses et que ça allégerait le venv.

D'ailleurs pour tout ce qui est fichiers statiques on ne pourrait pas utiliser https://www.gandi.net/hebergement/serveur/accelerateur/achat pour soulager un peu le serveur de prod ?

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte