Bonjour,
Je suis en train de chercher des solutions (au moins une ) pour fiabiliser le changement d'un serveur physique opérationnel par un autre quand celui-ci tombe en panne.
En gros, le problème est le suivant : un système métier dispose de différents machines dont plusieurs serveurs, chacun assurant une fonction. Malheureusement, avec l'obsolescence des matériels, on se retrouve vite avec plusieurs modèles de serveurs différents pour assurer la même fonction. Sur le système, on peut mélanger une version de serveur avec un autre pour assurer la même fonction mais au niveau réinstall, on ne peut pas prendre une image du serveur v1 pour réinstaller le serveur v2.
Comme c'est de l'opérationnel, on ne peut pas mettre 3 plombes pour réintsaller un serveur et comme ce genre de serveur nécessite pas mal de conf en fonction du site où il se trouve (prise en compte du plan d'adressage, nom des machines...), ça devient vite la galère.
 
Je regarde donc ce qui se fait, notamment Ansible et Docker. Mais j'ai quelques petites questions.
 
Pour installer l'OS de base sur le serveur (sans prendre en compte les particularités du serveur, la conf...), je voyais bien :
- soit installer une image disque via un outil type Acronis true image ou XPE)
- soit installer une VM de l'OS via VMware ESX
L'ensemble des images disques et VM des différentes versions de machines seront stockées sur un NAS.
 
Ensuite, pour finaliser la conf de l'OS, installer les drivers propres à la version de la machine, finaliser la conf tenant compte de sa fonction et des spécificités du site..., je pensais passer par Ansible et/ou Docker :
- Ansible pour faire la prise en compte du plan d'adressage réseau, nommer la machine... et installer Docker
- Docker pour installer les conteneurs des composants, libs et applis hébergées par le serveur.
 
Questions :
1) ça vous inspire quoi ? Suis-je sur la bonne voie ? Y'a t-il mieux, plus simple ?
2) Où dois-je installer Ansible pour pouvoir finaliser la conf de mes machines ?
3) Comment puis-je accéder à mes machines depuis Ansible pour pousser mes confs ?
4) Je pensais faire un Ansible yml par fonction de la machine et par site et pareil pour le dockfile.
 
Je pense que je viendrai ajouter des questions sur ce topic au fur et à mesure de mon avancée dans ma réflexion.
 
Merci par avance pour votre aide

Bonjour
 
regarde du coté de puppet, à mon avis c'est lui qui correspond le mieux a ce que tu cherche à faire

Je connais de nom Puppet mais j'avais cru comprendre que c'était le même genre qu'Ansible ou Chef mais plus ancien et que du coup, c'était plus Ansibble qiu avait la "cote" actuellement car plus pratique.

ansible, puppet, chef sont des outils de config management et remplissent le même rôle.
 
documente toi sur le net sur les comparaisons entre les outils pour faire ton choix.
mon avis subjectif c'est que ansible est plus facile a prendre en main pour arriver aux premier résultats.
 
en effet il faut différencier l'étape d'install de l'OS sur le disque
et la config de l'OS par le fameux outils de config management
 
pour l'install:
ton option Acronis fait surement l'affaire.
une autre pratique courante est de booter en PXE sur un service qui t'installe un OS de base en mode non interactif.
ensuite tu peux passer ton config management sur cet OS vierge.
 
pour accéder a ta machine fraichement installée ça peut aller de:
- ton OS fixe une ip déterminée
- l'OS va dans un vlan "d'attente de config" avec dhcp
- ton OS s'enregistre dans une CMDB et sera directement accessible a l'outil de conf. management.
 
Je ne comprends pas pourquoi tu parle de VM, VMWare, images si on parle de serveurs physiques.
 
pour Docker je suis une bite donc je laisse la parole a d'autre expert. mais mettre ton appli métier dans Docker est une bonne idée oui
 
perso je gère les contraintes métier (php7.0, python5.17, lib-machin-chouette 2.1) direct dans Ansible mais c'est un peu old-school  

Merci pour ton retour.
Je parle de WMware ESX car ça peut être une solution intéressante dans ce sens qu'il n'y a pas besoin d'installer un OS hôte "fortement" lié au matériel, c'est VMware ESW qui offre un mini OS et qui permet ensuite de déployer dessus un OS hôte pour accueillir les applis.
 
En gros, j'ai pas besoin de passer par Acronis true image pour générer mon image puis passer par son utilitaire pour booter et charger l'image disque (ou via PXE). J'ai l'impression que VMware ESX est plus utilisé dans l'industrie IT pour déployer des serveurs qu'Acronis.
 
Et je me dis aussi, peut-être à tort, que c'est plus facile de générer une VM qu'une image disque quand tu a besoin de modifier 2-3 truc dans l'OS hôte à déployer.
 
"perso je gère les contraintes métier (php7.0, python5.17, lib-machin-chouette 2.1) direct dans Ansible mais c'est un peu old-school" --> pourquoi tu trouves que c'est old-school ? Tu estimes que ça serait mieux via Docker ? Ou tu penses à autre chose ?
Edit : j'ai bien entendu cherché sur internet. Mais ce que je trouve surtout, c'est pour des serveurs déjà virtualisés. Rarement, on parle du déploiement physique de serveurs.
Sinon, on est bien d'accord qu'Ansible doit être installé sur un serveur à part qui va gérer la conf des serveurs de mon système applicatif ?

Mais pourquoi partir sur des serveurs physiques de toute façon ? Je pense qu'il faudrait que tu recentres sur le besoin fonctionnel avant de partir sur une solution technique précise.

oui une VM c'est beaucoup plus simple. tu peux faire un template de base
ensuite clic, clic déployer et paf ta VM est UP. tu peux ensuite passer ansible dessus si tu veux.
 
généralement tu installes une flotte de VMWare ESX sur tes serveurs physiques où tu y met toute tes VMs.
SI un serveur a besoin de performances particulières tu l'installe directement sur un serveur physique.
 
si tu pars sur du docker. tu peux te passer de gérer l'OS hôte des docker en installant directement sur VMware ou sur physique un orchestrateur de conteneurs (style Kubernetes)
a voir selon la dimension de ton projet si ça vaut le coup
 
Sinon, on est bien d'accord qu'Ansible doit être installé sur un serveur à part qui va gérer la conf des serveurs de mon système applicatif ?
oui

Ben parce que l'appli en question ne peut absolument pas être mise dans le cloud et les sites où cette appli est déployée n'ont pas de datacenter (et c'est pas demain la veille qu'il y en aura   ). Je précise que cette appli ne doit pas être connectée à internet. Donc, pour Docker, ça sera des conteneurs stockés en local.

Pour qu'il n'y ait pas de mésentente, quand je parle de serveur physique, j'entends par là, une machine physique (que le hardware donc). Pour qu'un tel serveur puisse fonctionner, il faut lui installer un OS ou un "truc" capable de faire tourner un OS virtualisé (genre VMware ESX).
 
J'ai regardé Kubernetes. J'ai l'impression que ça fait un peu ce que fait Docker mais à un niveau au-dessus avec cette notion de management des pods. Je ne penses pas que ça me sera utile. Dans mon cas, on doit avoir guère plus de 15 serveurs physiques par site et ces sites ne sont pas reliés entre-eux par le réseau (en tout cas, pas au niveau applicatif). Chaque site est vu comme "coupé du monde" et autonome.

VMWare ESX est un OS (c'est un linux custom made in VMWare en gros)
tu installes VMWare ESX directement sur le serveur physique.
 
ensuite tu créé des VMs sur cet ESX.
sur les VM tu installes l'OS de ton choix (debian, windows, redhat,....).

Oui, c'est ce que j'avais compris.

Tu peux déployer des VM sans cloud ni datacenter. Tu peux faire accéder des utilisateurs à une appli sans passer par internet.
Je pense que tu devrais te renseigner sur les concepts de virtualisation, hyperviseurs etc...car si tu n'as aucune connaissance dessus ça va être difficile de bâtir une archi propre.

Je connais a peu près (sans être expert) la virtualisation et les différents types. J'ai peut-être trop interprété ton message qui disait "Mais pourquoi partir sur des serveurs physiques de toute façon". J'en ai déduit, peut-être à tort que tu voulais proposer une solution où j'enlève mes serveurs physiques et que je fasse héberger mon système (avec ses applis) sur des gros serveurs d'une infra type cloud ou datacenter. Solution que j'ai écartée à causes des contraintes d'exploitation.
Si j'ai mal compris ton propos, vas-y, explique-moi ce que tu avais en tête.
 
Tu noteras que j'ai bien pensé à la virtualisation puisque je parle de VMware ESX. Et Docker est une forme de virtualisation.
 

Tu mentionnes "installer une VM de l'OS via VMWare ESX", mais implémenter une plate-forme de virtu c'est plus complexe que cela.
 
Monter un pauvre ESXi  avec une VM dessus, c'est du bricolage, tu ne fais pas ça pour de la prod. Il faut penser réseau, stockage, backup, haute dispo, monitoring, support etc...
Pareil pour du Docker.
 
Donc déjà parmi les questions à poser, est-ce que vous avez une plate-forme de virtu ? Est-ce que cette appli est virtualisable ? Les contraintes de serveurs physiques sont-elles justifiées ? Quelles sont les contraintes de haute dispo/backu/restauration/PRA qui te sont imposées ?
 
En gros, tu es en train d'attaquer la phase technique alors qu'il faudrait commencer par la phase architecture. Mais en 2020 il y a très peu de cas où on utilise encore des serveurs physiques pour autre chose que des hyperviseurs.
 

A la base, la problématique à résoudre est comment pouvoir remettre en service rapidement un serveur physique qui a craché et qui est remplacé par un autre mais qui peut être d'un modèle un peu différent (genre, chipset de la CM différent, modèle de cartes réseau différents...), les 2 serveurs remplissant une fonction applicative identique sachant qu'il y a un travail important de conf pour prendre en compte le plan d'adressage réseau et un certain nb de paramètres dépendant du site où le serveur se trouve.
 
La virtualisation de l'OS du serveur physique n'est donc pas une obligation. C'était une possibilité car, peut-être à tort, j'avais l'impression que de modifier le contenu d'une VM était plus simple que de modifier une install réelle d'un serveur et d'en faire une image disque.
 
J'avais pensé à Ansible et Docker car ces 2 technos permettent via les playbooks et dockfiles d'automatiser la finalisation de la conf d'une machine, permettant de fiabiliser l'opération (pas se planter dans la conf à appliquer).
Enfin, Docker permet de containariser les applis et de les virtualiser, ce qui me paraissait intéressant pour faciliter le déploiement.
 
Pour l'aspect backup, dispos..., le système en question dispose d'un autre système (différent) qui assure ces aspects donc le pb de la dispo n'est pas dans le scope car déjà traité.
 
Pour l'instant, la contrainte des serveurs physiques est une donnée qu'on ne peut éviter (ça changera peut-être un jour mais pas avant quelques années je pense).
 
Donc oui, le scope de mon étude est purement technique (et un peu méthodologique).
Actuellement, un tel remplacement met beaucoup trop de temps (plusieurs heures voire jours en cas de pbs avec, dans certains cas, une demande de l'industriel a renvoyer la machine chez eux pour faire l'install ce qui n'est pas acceptable en opérationnel).

J'ai du mal à piger.
 
Y'a une contrainte de serveurs physiques mais on mentionne docker, vSphere, etc.
 
L'applicatif doit absolument avoir accès à la couche matérielle ? Si oui, sur quel point ?
 
Si non, faut virtualiser.
Et il restera toujours un serveur physique pour accueillir l'hyperviseur.
Au final y'a toujours du physique.
Sauf que l'appli serait sur une VM qu'on peut rejouer sans aucune conf sur un autre hyperviseur, quel que soit le matériel derrière (enfin presque).

Pour l'instant, comme j'ai compris, oui, conserver le nb de serveurs physiques est imposé (architecture de l'industriel).
La problématique est bien d'automatiser l'install d'un serveur quand celui assurant la même fonction est en panne et que le temps de remise en route soit le plus court possible tout en permettant de remettre en place le paramétrage applicatif spécifique au site et à la fonction assurée par le serveur.
 
Comme je l'expliquais dans mes posts précédents, Ansible et Docker semblent permettre de répondre à cette problématique en introduisant quelques changements mais qui me paraissent acceptables par ceux qui produisent le système en question.
Mais si vous connaissez d'autres solutions compatibles avec les contraintes énoncées, je suis preneur
 
Edit : a priori non, l'applicatif n'a pas besoin d'accéder à la couche matériel absolument. Par de la virtualisation, ça le ferait.

 
 
Comprends tjs pas.
Si l'applicatif n'a pas besoin d'accéder à du matériel spécifique et peut-être virtualisé, pourquoi causer de garder nécessairement des serveurs physiques plutôt que des VMs ?
Que l'applicatif soit constitué de différents rôles à faire tourner chacun sur des OS propres, OK. Mais pourquoi allez mêler la notion de nombre de serveurs physiques à garder ?
C'est quoi cette appli ?

En fait ton idée initiale est une espèce de master bricolé, sauf que l'on ne travaille jamais de cette façon sur les serveurs. Entre autres raisons historiques, de vrais problèmes de compatibilité coté matériel, et des configurations un peu spéciale sur ce genre de machines, notamment liées au RAID.
 
Le standard, c'est de virtualiser tes serveurs pour te libérer de ces contraintes. Ensuite tu as plusieurs façons de virtualiser : VM classique, docker etc...et je pense que c'est là qu'il faut que tu te renseignes sur quelle solution permet quoi et comment.
Par contre tes serveurs ne pourront sans doute pas être réutilisés comme hyperviseurs. Et tu pourras éventuellement rajouter du Ansible pour gérer et standardiser la conf de tes VM et de leur contenu.
 
Ca revient à changer de paradigme pour passer d'une infra purement physique années 90/2000 à une infra virtualisée plus moderne. Mais pour ça il te faudra des compétences, du budget, et te poser les bonnes questions car d'après ce que tu dis je ne pense pas que tu prends la problématique par le bon bout.

Quand je parle de serveur, je parle de machine de type serveur physique mais pas de fonction serveur comme on l'entend dans l'IT. En gros, ces machines sont de type serveur mais leur fonction est une simple brique applicative.
On est bien d'accord que l'infra proposée par l'industriel est de type années 90/2000. Mais ça, a va pas changer de suite Après, le système applicatif dont il est question est très métier. Doit y avoir 20 à 30 industriels à tout péter qui font ce genre de système dans le monde et ils sont rarement orienté technos IT Pour vous dire, ça fait seulement 1 à 2 ans que certains d'entre eux ont accepter de virtualiser certaines portions de leur système pour qu'on puisse s'affranchir du pb de l'obsolescence des machines livrées initialement y'a environ 15 ans

Virtualise tout (en p2v).
prend veeam sauvegarde et replication
 
et tu sera tranquille

Ma question, à la base, c'est comment automatiser le déploiement d'une machine suite à une panne avec l'OS, les libs, composants, applis et conf/paramétrage spécifique de la machine lié à sa fonction et au site où elle se trouve. Je pense que la virtualisation fait partie de la solution mais j'aimerai bien discuter plus de l'aspect déploiement automatisé de la conf et paramètres spécifiques

veeam peut surveiller l'etat d'une machine et la restaurer si elle déconne.
il faut juste determiner les test a faire pour marquer la machine comme fonctionnel ou défectueuse

Ok, je note l'info, ça peut servir. Merci.