Design d'infra serveur (web, appli tierces, bdd) : besoin d'avis

Support Debian
#1

Hello,

Actuellement chez OVH, j’ai 2 hyperviseurs, avec 5 adresses IPv4 publiques affectables , je pense en prendre encore 4 ou 8 autres.

Je dois distribuer les services suivants :

  • Serveur de mail (en place, et tout est sur un seul serveur KVM, avec postfix/dovecot/clamav/rspamd/etc… avec base mysql)
  • Serveur web (nginx + php + mysql)
  • serveur d’applis tierces (XMPP, et autres bricoles)

Ce n’est pas une grosse infra, mais quand même utilisée par ~20000.

L’actuelle futur-ancienne prod tourne sur 2 petits VPS. Ça fait le job, mais je veux me débarrasser des VPS pour tout migrer sur mes 2 hyperviseurs KVM pour pouvoir avoir loisir de créer à la volée autant de serveurs que je veux et surtout être indépendant sur les snapshot (qui aujourd’hui chez OVH sont manuels, chose que j’ai automatisé avec KVM sur mes hyperviseurs).

J’ai donc plusieurs applis web, avec leur versions en test. Tout ça est et restera servi par du Nginx, PHP-FPM et MariaDB.

Au départ j’étais parti pour monter un premier serveur virtuel avec dessus ma base mariadb, mon nginx/php-fpm, tout ça pour la prod. Et son équivalent en préprod, de façon à bien séparer les environnements.
Après je me suis dis “et pourquoi ne pas tout séparer ?”. A savoir MariaDB sur un serveur et mon frontal Nginx/PHP-FPM sur un autre. Après quoi je me suis dis que pour le coup, c’était peut-être lourd pour une infra si petite.

Du coup, je tourne en rond. J’ai plein de solutions pour dessiner cette nouvelle infra, mais pas une ne me semble meilleurs qu’une autre.

Je pense que ma première solution de faire un gros serveur de prod et un gros serveur de test/preprod est pas mal.

Ça c’est mon premier souci et j’aimerais votre avis pour savoir ce qu’il serait le mieux de faire. A savoir que mon infra ne sert pas des services vitaux (pas de chaines de montages ou je ne sais quoi d’autre derrière), c’est une très grosse association. Il y a une légère tolérance à la panne, mais la donnée ne doit ni fuiter, ni être perdue.

Pour quelque-chose de ce type, comment feriez-vous ?

#2

Du coup tu ferais une VM par appli sur chaque serveur ? A priori pas de problème je pense.
Pour l’éventuelle séparation de MariaDB, ça dépend, c’est intéressant seulement si plusieurs applis distinctes ont besoin d’une BDD.

Ton environnement de pré-prod tu le fais comment ? Au boulot sur les applis qu’on expose au public, on fait un snapshot LVM régulier des conteneurs pour les remonter sur la pré-prod.

Pour les sauvegardes tu fais comment ? Un 3e serveur (pour les dumps BDD, rsync des répertoires de tes applis - pour ce dernier point, backuppc est plutôt sympa je trouve -, etc.) ?

A part ça, si tu anticipes des gros pics de charge, tu peux dupliquer les VM de ta prod et les synchroniser (réplication temps réel des bases mariadb, etc) et monter un apache / nginx qui fera office de load balancer (je ne sais pas lequel des 2 est le plus indiqué pour ce rôle, je n’en utilise pas) mais ça alourdit considérablement le tout.

#3

En fait, non.

Là j’ai en prod 2 VPS OVH.
L’un me sert de serveur de mails, et l’autre d’applications (web ou tierces).

Je veux me débarrasser de ces machines pour tout coller sur mes hyperviseurs et séparer un peu les environnements.

Je pensais donc faire ceci :

  • Un serveur virtuel pour les applis web (intégrant une bdd)
  • Un serveur virtuel pour les applis tierces (avec bdd possible aussi)
  • Un serveur virtuel de mail (bdd, postfix etc…) => déjà en prod
  • Et leurs équivalents pour le test/préprod.
  • Pour basculer à froid tout ça d’un hyperviseur à un autre (faire en sorte que les 2 soient toujours capacitifs par rapport à la charge totale potentielle)

A savoir que chez moi, il n’y a pas vraiment de préprod, la phase test/préprod sont plus ou moins les mêmes.

Je me demandais si cette approche était correcte, ou si il fallait pensait l’architecture autrement, à savoir :

  • 1 frontal nginx
  • 1 frontal php-fpm
  • 1 frontal mysql
  • 1 frontal de fichier
  • 1 fronal courrier
  • 1 frontal de monitoring/log

Et tout connecter, comme on pourrait le voir dans des grosses structures (ce qui n’est pas mon cas).

Je pense que ma première approche, simpliste, est la meilleurs, mais je voulais vos avis aussi.

Pour la sauvegarde, elle est de plusieurs types :

  • Les VMs ont un snapshot KVM fait automatiquement tous les 2 jours
  • A l’intérieur des VMs, il y a un snapshot LVM fait d’un répertoire de configuration et de données sensibles
  • Un script passe et fait également des dumps des bases pour les envoyer sur un NAS extérieur

Ce n’est pas le top du top de la sauvegarde, mais ça tient la route.

Ce qui m’embête, c’est qu’avec le Vrack OVH, je n’arrive à faire dialoguer sur un réseau local que les 2 hyperviseurs, pas les VMs elles même, sinon j’aimerais bien monter un NAS interne qui me simplifierait la vie.

#4

Je n’ai pas encore lu le reste, mais déjà, ça sent la planification d’une infra en ipv4.
Est ce bien raisonnable de la penser d’abord en ipv4 ces jours ci ?
Je ne sais pas comment OVH est sur l’ipv6, mais le nombre d’ips statiques n’aurait plus aucune importance.

Moi ça me parait pas mal de distribuer la charge des services sur les machines physiques distinctes.
Et en mettant le frontal web d’un coté et la bdd de l’autre, si la charge augmente, tu peux rajouter un serveur web physique redondant sur la même bdd (la charge bdd augmente moins que le service web avec le volume de visiteurs).
Aprés, ou faut il mettre le mail ?
Ca…

Enfin cette répartition là me semble mieux que serveur de prod/serveur de test, à moins que tu ne testes des os/noyaux/applis:
si c’est du web, la version de test peut être en sous domaine sur le même serveur (à moins que tes applis web puisse faire planter le serveur en test, mais ca me semble rare).

Ensuite, je ne sais pas si tu gères aussi le dns, si tu as d’autres services tellement secondaires que tu ne les as pas cités, mais ce n’est pas forcément optimal de faire une vm séparée pour chaque service que tu mets sur un hyperviseur, enfin pas systématiquement, il y a des synergies entre services dans une même machine parfois.
Déjà, séparer nginx de php ne me semble pas pertinent (et je vois mal comment en fait).
Une machine courrier, pourquoi pas.
Frontal de fichier, ça veut dire quoi ? Que l’accés ftp aux hébergements de site se fera par une machine distincte du serveur web ? Pas trés pertinent non plus de l’en séparer (et ça ne me viendrait plus à l’idée de laisser autre chose pour les fichiers que le sftp).
La vm de monitoring, pourquoi pas, mais je me demande si les softs de surveillance n’ont pas besoin d’être prés du mail.

Tout ça pour alimenter ta réflexion.

#5

Je ne connais pas le vrac OVH, mais tu dois avoir moyen de monter un bus/réseau interne virtuel sur chacun de tes hyperviseurs avec l’hyperviseur et les vms dessus, et de connecter tes deux bus avec un lien (ipsec) et routage entre les hyperviseurs.
[edit: ou avec le vRack, vu qu’aprés lecture, tu peux router le flux des bus entre tes hyperviseur par là.]

#6

Hello,

Donc tu proposes de mettre la/les base(s) mysql sur un hyperviseur et le applis sur l’autre. C’est une idée oui, je n’y avais pas pensé.

Ce que je voudrais dans tous les cas, c’est que chaque hyperviseur soit capacitif (capable de prendre la charge des 2 en cas d’arrêt de l’un).

Pour le moment, vos réponses m’ont bien éclairé, à dire vrai je pense m’être posé des questions pas forcément adaptées à la taille de mon infra (en voulant chercher trop complexe).

Sinon, oui, je gère les dns moi même, avec 2 serveurs PDNS.

La question qui reste en suspend est la connectivité des machines entres elles.

J’ai un lien 1Gbs montant et 10 Gbs montant sur chaque HV. Je pourrais faire comme tu le proposes à coup de bus réseau/virtuel, mais je suis une vraie buse en réseau, il va falloir que je me penche sur la question car je ne vois pas comment faire, sinon, une autre idée m’était venue à l’esprit, ce n’est sans doute pas la meilleurs mais que vaut-elle ? Relier chaque VM à un VPN (dont le serveur serait une VM à part). De cette façon, j’aurais un réseau privé par lequel je touche toutes mes VMs, pour moi ce serait plus simple à mettre en place.

Est-ce que cette solution du VPN est viable ?

Si oui, est-ce que ça le serait même si je veux mettre un montage NAS accessible dessus ? (En gros, dans chaque VM j’ai des scripts, avec des bibliothèques que je mets à jour sur chaque serveur, c’est chiant… je préférerais n’avoir qu’un dépôt de ces bibliothèques et monter ça sur tous mes serveurs au moyen d’un partage NAS).

#7

Dans ce cas ils doivent être des clones, et on discute pour rien à se poser de questions sur quoi mettre dessus.

Elle est surtout coûteuse en ressource de chiffrement, et niveau réseau, sans doute plus difficile à configurer en terme de réseau qu’une solution avec deux boucles internes reliées par un lien entre les hyperviseurs…

#8

Pourquoi des clones ? Dans mon esprit, je souhaite simplement, si par exemple je vois qu’une barette mémoire commence à donner des signes de faiblesses ou toute autre avarie matérielle, bricoler un script qui copie le fichier image de ma VM sur mon autre hyperviseur, plus toute sa conf et pouvoir redémarrer de l’autre côté sereinement pendant que HV1 est en maintenance.

Ça c’est la solution manuelle que je privilégierais, et si j’avais accès à du SAN (ou un simple NAS), je pourrais envisager du clustering, mais c’est impensable en l’état (quand je vois ce que coute par mois le passage sur le vrack à 1gbs + la location du NAS…).

Pour ta réflexion sur le VPN, ok, j’oublie ça. Ça me paraissait moi aussi un peu gros comme utilisation, mais je préférais demander.

Je vais mettre les mains dans cambouie côté réseau et essayer de monter dessus de l’ipsec comme tu le proposes.

#9

Parce que tel que tu le présentais, ça semblait être un problème de tolérance au pannes (bascule sans interruption de service).
Mais effectivement, dans le cadre d’un plan de récupération, si tu te moques d’une interruption le temps de remonter la dernière image de ta vm (avant le crash, puisque ton serveur ne sera plus accessible en cas de barette foireuse), alors oui, ce n’est pas obligé.

Alors non.
Je proposais ipsec avant de savoir que ton vrac te permet de monter des vlans entre tes hyperviseurs, ce qui fait le taf:
d’abord tu regardes comment créer une boucle réseau virtuelle sur lesquelles tu peux brancher toutes les VM d’un HV et l’HV lui me comme si elles étaient en LAN, et tu leur attribue des adresses privées genre 192.168.0.X,
tu n’utilise que l’adresse de ton HV en externe, et tu rediriges port à port chaque service (http, mail dns) demandé depuis l’exterieur sur ton HV vers le port concerné de la machine qui s’en occupe sur le LAN virtuel,
tu dupliques sur l’autre HV en changeant de frange d’adresse privé genre 192.168.1.X,
tu relies tes deux HV par un VLAN du vrac,
tu indique à toutes les machines de l’HV qui héberge le 192.168.0 que pour aller sur 192.168.1, il faut envoyer les paquets à leur HV qui les routera, et inverse pour les VM de l’autre HV,
tu indiques au HV qui héberge le 192.168.0 que pour envoyer des paquets vers 192.168.1, il faut envoyer par le VLAN entre tes HV, et l’autre sens pareil.
Là je crois que j’ai fait le tour.

Avec ça, seuls tes HV sont vraiment exposés à l’extérieur, les VMs sont derrière sur leur lan virtuel, et
ce qui circule entre toutes tes machines reste à l’intérieur des HV, ou bien va d’un LAN à l’autre par le VLAN chiffré entre tes HV.

#10

En l’état, j’ai déjà mes 2 hyperviseurs qui savent communiquer via le vrack, sur 192.168.0/24. L’un est en .1 et l’autre en .2.

Pour ne présenter que les ip publiques des hyperviseurs, en lieu et place de présenter aussi les ip publiques des VM, puis ensuite faire du PAT pour rediriger le trafic vers les bons services, ça me parait clair.

Par contre, avec quel outil vois-tu ça ? OpenvSwitch ?

En fait, indépendamment du contexte vrack, je pense savoir comment faire pour faire communiquer mes VMs de HV1 avec HV1 sur un réseau privé (simplement via un bridge auquel je connecterais chaque interface du réseau privé pour chaque VM et l’HV, je devrais pouvoir gérer ça sans trop de difficulté), ce qui me parait plus costaud, c’est ensuite d’envoyer le trafic sur l’autre hyperviseur au moyen de Vrack.

Parceque si je veux faire tout communiquer ensemble, je dois passer par le vrack, pas le choix.

Je vais jeter un oeil pour voir si je trouve une conf similaire ou une bonne doc, je ne dois pas être le seul à essayer de monter ça.

/edit: je viens de piger pourquoi tu parlais de 2 vlans… En fait il y aurait un vlan pour les HV (celui du Vrack) et un vlan pour les VM et ce dernier passerait au travers du vlan des HV (pour que l’ensemble des VMs puissent communiquer).

#11

Connais pas.
C’est quoi comme techno de virtualisation tes hyperviseurs ? Ils n’ont pas leur propre solution de réseau virtuel ?

Ah mais non. Je n’ai parlé que d’un VLAN pour le lien entre HV.
Par contre, j’ai parlé de 2 circuits/bus/reseaux internes virtuels, mais rien à voir avec des vlan qui pour moi sont des réseaux virtuels cohabitant sur un réseau physique. Mais bon, peut être que le terme vlan s’applique aussi à de telles boucles.

mais oui, sinon, le réseau complet c’est:

VM1.1 \                                                                              / VM2.1
VM1.2 - (switch virtuel 1) - HV1 ----- (vlan de vrac)------ HV2 - (switch virtuel 2) - VM2.2
VM1.3 /                       |                              |                       \ VM2.3
                           Internet                       Internet
#12

Me concernant, c’est KVM avec Quemu que j’utilise. Et oui, ton schéma correspond exactement à ce que je veux faire.

Je vais déjà essayer de faire communiquer toutes les VMs d’un HV entres elles (et avec l’HV) sur un réseau privé.

Pour ça, je pense qu’un bridge et quelques mac devraient faire l’affaire. Une piste ici. J’étudie ça.

#13

Non non, ça, si tu bridge tes vm sur l’if externe de ton hv, tu auras bien tes machines en réseau, ais sur ton réseau externe, pas sur une boucle interne.
Si tu veux en faire des machines “derrière” ton HV, avec qemu, il me semble plutôt que c’est du “network backend slip”, ou peut être un tap sur ton HV, éventuelleent sur lequel tu bridges tes VM:
https://wiki.qemu.org/Documentation/Networking
Mais je t’avouerais que je n’ai pas tout lu.
En tous cas, le bridge ne me semble pas la solution (vu les limitations sur le routage entre les interfaces intègrées au bridge), et certainement pas en bridgeant sur la carte de ton HV.

Je lirais plus tard.