Discussion :

[Bananasplit]

Bonjour,

Je fait appel à votre expérience pour faire le bon choix des softs et de l'organisation d'une infra pour héberger une application assez lourde. Je manque personnellement d'expérience sur ce type d'infra .

L'application à faire tourner repose sur une énorme base de donnée MongoDB, nécessite de stocker de gros volumes de données ou des milliers de petites fichiers, et nécessite parfois d'effectuer des calculs de rendus sur certaines données (il faut donc quelques serveurs dédiés au calculs).
Objectif : 100% opensource (si l'infra proposée est propre, cela peut être accepté), disponibilité de plus de 99.5%, et possibilités de faire croitre l'infra avec la croissance de la base de donnée et des données.

Pour le moment, je réfléchi à l'aspect software.

Je pense me baser sur :

• oVirt pour gérer l'ensemble des VMs. (Les moteurs sont auto hébergés dans chacun une VM, dispo depuis la 3.4)
• nagios pour le monitoring.
• glusterfs comme système de fichier parallèle.
• ansible pour manager tout ce petit monde.

L'OS : CentOS 6.5 ou 7, à voir.

Ce qui donne grossièrement :



Il s'agit d'une vision macro, avant d'aller plus en détails par la suite.

Les choix vous semblent-ils judicieux ? J'ai le choix entre OpenStack et oVirt, mais le nombre de VM prévues n'est pas suffisant pour déployer un mastodonte comme OpenStack à mon avis.

Merci d'avance pour vos retours

BS

[frp31]

à première vue comme ça sans avoir d'infos, je dirais que ça semble assez correct comme idée de base.

redonder le manager de VM et la baie SAN ou du NAS serait bienvenu ainsi qu'un réseau de sauvegarde (qui peut être fait entre les VMs directement)
vaut juste prévoir la volumétrie et le calendrier des backups à froid et à chaud... idem pour le SGBD en mode master/slave classique

si tu redonde Ovirt penses qu'il te faudra un haproxy pour basculer ton accès (tu peux le faire sur chacune des Ovirt ...

les trucs à faire attention :
-----routages entre les VMs et vers le reste....
----les upgrades et autres modifications doivent être répliquées entres les machines de même rôles...
----un backup n'est utile que si les restores sont régulièrement testées et validées. !!!!!!!!!!!!!! <<<<-------------- l'erreur de base classique que meme les industiels font ... se dire que s on a des backups on est bons.....je suis actuellement confronté au cas .... un très gros industriel d'importance mondial...... pourtant..... (y'a des backup mais pas restorable.... parce que personne n'a eu l'idee de les tester)....
----si tu as un accès exterieur attention au hardenning de securité à suivre chaque semaine (au minimum)
----tout documenter de A à Z au cas où tu meurts qu'il soit possible de repasser derrière sans devoir financer un cassage complet et recréation from scratch....(oui c'est encore du vécu)
----ne livrer qu'une fois la solution bien qualifiée...
----faire un petit minimum de MCO .... donc ça ira tout seul si tu mets des agents nagios assez pertinants
----oublies pas de paramètres les FS pour l'optimisation de petits fichiers.


Nagios = Oui
Ovirt sans l'avoir qualifié personnellement je dis oui qd meme
MongoDB je dit oui meme si j'ai pas joué avec....
ClustFS = Oui

CentOS 7 oui ... c'est stable et moderne à la fois... et bien maintenu.

sans prendre plus de 2 minutes pour y refléchir.... voilà ce que je peux dire.

[Bananasplit]

Merci pour ce retour

Beaucoup de notions nouvelles pour moi, mes anciennes missions ne prévoyaient pas de HA et les systèmes étaient complètement différents.
Je digère rapidement tout ça (haproxy, réseau de sauvegarde, etc) et je reviens d'ici la semaine prochaine avec un schéma plus complet, qui devrait cette fois inclure les différents services et le réseau (1gb et 10gb).

Pour la doc, je prévois une Redmine, il y a tout ce qu'il faut pour documenter l'installation et garder une trace des problèmes rencontrés. Quand au backup, j'en ai fait l'expérience il y a peu, 2 semaines pour tout réinstaller car l'image du backup était défectueuse...

[netmonk]

Dans le schéma il manque les interactions avec l’extérieur (frontend http ?, api json ? ...)
Ton routage admin (vlan différent) ?

[Bananasplit]

Oui, pour le moment je manque d'informations sur l'application hébergée et ses interactions avec l'extérieur. Je me demande surtout si dans une configuration "normale", l'extérieur est relié au 10GbE, ou sur un autre réseau directement connecté aux VMs (comme mis grossièrement sur le schéma ci dessous). Sur mes anciennes configs, il y avait un serveur avec 2 interfaces qui faisait office de lien vers l'extérieur, les utilisateurs n'allant pas plus loin et lançant les commandes d'ici.

Voilà à peu près où j'en suis pour le moment (j'ai lancé un autre sujet ici pour le réseau : http://www.developpez.net/forums/d15...reseau-10gb-ha). L'admin passe donc par le réseau 1GbE :



Cependant, j'ai de sérieux doutes sur GlusterFS depuis hier. Le système de fichier est performant, simple à installer, mais les retours sont très négatifs concernant la stabilité en cas de panne et la récupération de fichiers. Je regarde du coté de CephFS, plus jeune mais apparemment plus stable. Hadoop semble lui peu adapté aux infra de ce type.
Dans le cadre de l'infra que je dois fournir, la sécurité des données est prioritaire sur tout le reste, performance incluse. D'où mon inquiétude.

[netmonk]

Si c'est la protection des données qui est importante, je te suggère lvm et raid5 sur serveur dédié de stockage avec export des partitions ou bien iscsi, avec mirroring sur un serveur secondaire.

Sinon là tu as construit un site, mais quid d'un site secondaire en cas de gros crash sur le primaire ?*

[Bananasplit]

Merci du retour.

Un site secondaire est prévu, mais pour le moment j'ai le choix :
- L'application hébergée s'occupe elle même de la réplication et de la synchronisation des données entre les sites
- Ou, l'opération est à la charge de l'infrastructure, et donc du système de fichier ou de tout autre outil(s).

Pour des raisons de "responsabilité", la première version m’arrangerait, mais la sécurité des données passant avant tout (et c'est un projet global), je pense que la seconde possibilité est à choisir. Après tout, on ne va pas réinventer la poudre, et si un système de fichier éprouvé possède une fonction de réplication entre des sites, il me semblerai dommage de s'en priver.

Concernant le lvm+raid5, je pensais à du LVM+raid6, en plus de la réplication de la donnée sur le système de fichier. Cela donne donc, pour 2 copies, une résistance théorique à 3 pannes pour du raid5 ! (je peux perdre 3 disques sans perdre la donnée). Il faudra voir au coût si je peux m'offrir ce luxe, et surtout si ca vaut le coup...

Après de multiples études, les systèmes de fichier encore en course dans nos choix sont :
- CephFS
- MooseFS
- HadoopFS

Nous avons décidé d'écarter GlusterFS car de très nombreux retours donnent des instabilités lorsque l'infrastructure devient massive, malgré des performances excellentes à saluer.

Selon les retours, HadoopFS est malheureusement plombé par son unique MDS, et les débits sont peu réjouissants. De plus, il n'est pas totalement compatible POSIX. CephFS est probablement le plus performant, mais il n'est pas encore finalisé. MooseFS semble un bon candidat, j'ai pu trouver des entités dépassant les 3 Po avec ce système de fichier, sans pépins.