Bonjour à tous,
Nous envisageons de basculer vers une infrastructure plus "sécurisée" et forcément plus évolutive. Nous regardons les éléments suivants :
* plusieurs machines sur la gamme public cloud
* un NAS HA pour partager les fichiers
* une réplication mysql Master / Master entre les machines PC
* l'ip load balancer OVH en amont des machines PC
Avez-vous déjà mis en place ce genre d'infrastructure, est-ce qu'il me manque des briques ou est-ce tout simplement pas la bonne façon d'opérer…
Merci d'avance pour vos retours,
Pour la réplication master/master vous utiliseriez quoi ? Perso je suis sur un cluster Mariadb avec 3 nodes. Facilement augmentable en cas de pic d'activité.
Par contre dans cette config il est vivement recommandé d'utiliser des VM sur 3 hosts différents, car si 2 nodes tombent en même temps le cluster n'aime pas trop.
Il y'a bien une fonction anti affinité via l'API mais toujours limité à 2 vm pour le moment…
A noter aussi que j'ai été assez déçu par les perfs disques des VM cloud (disque réseau), par contre les VM sur disques SSD vont très bien, mais moins de HA dans ces conditions.
Côté NAS HA j'en utilise un et j'en suis très satisfait.
Salut,
Nous travaillons aussi sur une infrastructure chez OVH, on a aussi choisi une approche hybride serveurs dédiés/public cloud.
- MySQL : Replication master-slave MariaDB, on a des modifs à faire sur notre BDD avant de pouvoir passer à un cluster Galera. On exploite ProxySQL en amont pour répartir la charge sur les différents serveurs de BDD.
- NAS-HA : On pensait utiliser l'offre NAS-HA car sur la partie legacy de notre appli on doit partager des fichiers entre les serveurs web mais cela nous a été déconseillé par les gens de chez OVH à cause des perfs, du coup, on a monté un cluster GlusterFS avec des dédiés ayant des SSD et une connection vRack 10Gbps.
- IP load balancer : on utilise l'ip loadbalancer classic (pas le NextGen) devant 2 nginx qui font du reverse proxy ce qui nous permet d'avoir plus d'options au niveau des headers, redirections, …etc.
Niveau public cloud on n'utilise que des instances avec disque SSD sans RAID dans la mesure on tout est dupliqué et qu'on peut perdre une machine et le remonter à l'identique en 2min (provisioning automatique).
Effectivement en cas d'usage très intensif du stockage centralisé le NAS-HA peut s'avérer un peu light. 1gb/s de bande passante max, frontaux mutualisé…
Dans ces conditions un cluster de stockage maison sera bien évidemment plus performant, mais demande de suite une infra plus conséquente en coût et en complexité.
Il faut faire un arbitrage entre performance et cout/complexité.
Pour l'instant nous n'avons que 2 machines pour GlusterFS, on hésite encore à passer à 3 machines car l'objectif à moyen-court terme est de se débarrasser du partage glusterfs, on a déjà 80% des fichiers générés par l'appli qui sont directement stockés sur AWS S3.
Le plus gros souci pour nous c'est de devoir se contenter d'un seul datacenter pour le moment, on va vite réfléchir à mettre en place un DR sur plusieurs datacenter, aujourd'hui seul le slave MariaDB est dans un second datacenter.
Merci à tous pour vos réponses instructives. L'installation d'un cluster de stockage serait bien sûr plus performant mais demande plus d'investissements d'un côté mais également plus de maintenance de l'autre. C'est vraiment dommage que l'offre NAS-HA ne soit pas suffisante, je vais creuser du coup sur la partie GlusterFS.
Tout dépend de tes besoins, perso mon NAS HA me sert à stocker des VM (cluster proxmox) et quelques sites web.
Le tout fonctionne très bien pour mes besoins.
Possible également de démarrer sur un NAS-HA puis de migrer sur un cluster maison quand les besoins se font sentir.
Bonjour,
Petit point pour ne pas subir une mauvaise infra.
Pour moi et pour OVH il me semble aussi, le public cloud n'est pas réellement fait pour de la production.
Il est conçu pour palier à des piques de charges et ainsi pouvoir augmenter rapidement ou sur des périodes données les ressources de son infrastructure.
On créé donc une plateforme sur des serveurs dédiés avec cluster mysql/mariadb, partage de fichier entre machine, memcached en cluster etc …
Ensuite au besoin on peut ajouter des vm du public cloud pour avoir plus de puissance sur des frontaux ou plus de ressources au niveau des bases de données.
Il faut savoir que le point faible de cette architecture en vm, c'est que s'il y a des problèmes réseaux ou d'interface vers les disques, on risque de perdre la synchro ou pire de faire une corruption de données.
Il faut bien prendre en compte, dans des cas assez rare, que l'on peut perdre son infra et qu'il n'y a pas de garanti d'intégrité des disques.
Mieux vaut avoir de bonnes sauvegardes ou une partie avec des serveurs physiques dédiés.
Je pense que pour avoir quelque chose d'intéressant en terme de ressources et garantissant que les données soient conservées en permanence, il faut au moins un serveur physique pour chaque élément, data bdd etc …
Ensuite couplé avec un git, une synchro avec un espace de data externe et une base de données en cluster, on peut avoir quelque chose de performant et préparé pour la production.
Si l'on fait la calcul pour une production importante, on peut aussi vérifier que ce service est vraiment fait pour une extension de capacité ponctuelle, lorsque les choses sont faites pour durer, en terme budgétaire on s'y retrouve facilement sur des serveurs dédiés.
Bonne journée
https://www.captainadmin.com
Très bon résumé.
La différence de perf entre un dédié et un public cloud est vraiment flagrante…
Les cloud sont là pour des frontaux, pic de charge, petits projet…
Il ne reste plus qu'à creuser sur la mise en place via des dédiés en résumé !
Si c'est financièrement possible oui.
De toute façon les public cloud avec disques HA n'ont pas des perfs à la hauteur…
Même si ceux avec des disques SSD vont bien mieux, mais là attention à la rupture de service (des instances avec disques RAID 1 sont prévues)
Mais les publics cloud restent intéressant pour des petits projets, pour tester, pour démarrer…
Pour les plus grosses instances au vu du prix autant passer sur du dédié directement.
En même temps dans une architecture cloud on ne s'attend pas à ce qu'une instance (VM) soit toujours disponible, au contraire, on réfléchi l’infrastructure de façon qu'à tout moment on puisse dégommer une instance sans perte de service.
On utilise par exemple le bot "Chaos Monkey" de Netflix pour valider ce principe.
Dans ce cas de figure, on peut se permettre d'utiliser les instances avec disque SSD même s'il n'a pas de RAID.
Je pense qu'il ne faut pas utiliser le public cloud d'OVH (ou tout autre cloud) si l'application qu'on veut déployer n'est pas cloud ready.
Personnellement, dans le public cloud je me suis contenté de déployer les serveurs web, memcached, redis et un serveur FTP, que des éléments dont je peux perdre un pour plusieurs éléments sans interruption de service et que je peux remplacer très rapidement. Le reste j'ai exploité des serveurs dédiés : MariaDB, Solr, Glusterfs, …etc.
Effectivement, des nodes que l'on peut "perdre" sont parfaitement adaptées aux instance cloud, notamment celle en SSD.
Je m'en sers régulièrement pour augmenter le nombre de serveur dans un cluster web.