Merci pour ces précisions, et bon week-end (à tous !)
Version imprimable
Merci pour ces précisions, et bon week-end (à tous !)
Je dirais plutôt qu'on virtualise le Filesystem et les services/applications, le noyau étant le même entre le container et son hôte. Il serait intéressant de voir si les processus lancées depuis un container sont vus en dehors de celui-ci ou si l'on ne voit que le processus "container".Citation:
Conteneurs: on virtualise le noyau d'un système d'exploitation sur lequel on installe d'autres systèmes d'exploitations qui partagent ce noyau et donc doivent être compatibles avec ce noyau et dans lesquels on installe les applications que l'on veut.
Dans le cas de Docker par exemple, pour l'utiliser sous Windows ou Mac OS X, ça s’appuie sur VirtualBox (Docker étant lié au noyau Linux, tout comme BSD Jail et les zones Solaris cités par jlliagre sont respectivement liés à BSD et à l'OS Solaris).
Ceci donne une bonne vision :
https://fr.wikipedia.org/wiki/OpenVZ
Virtuozzo cité par jlliagre s'appuie sur OpenVZ
Je rajouterais qu'avec un hyperviseur, les systèmes sont beaucoup plus cloisonnés et utilisent des fonctionnalités du CPU (VT-x ou AMD-v), les conteneurs c'est plus léger et ça utilise des fonctions OS (LXC, CGroups pour Docker). En cas de faille, une escalade de privilège sera plus simple qu'avec un hyperviseur.Citation:
- Hyperviseurs: on virtualise un matériel unique et commun, une machine physique sur laquelle on instancie des machines logiques sur lesquelles on installe les systèmes d'exploitations complets que l'on veut et dans lesquels on installe les applications que l'on veut.
- Conteneurs: on virtualise le noyau d'un système d'exploitation sur lequel on installe d'autres systèmes d'exploitations qui partagent ce noyau et donc doivent être compatibles avec ce noyau et dans lesquels on installe les applications que l'on veut. ex: jails bsd, zones solaris, wpar aix, virtuozzo, lxc.
Dans le cas de Docker, qui prend actuellement de l'ampleur, Microsoft travaille en partenariat avec eux pour intégrer le support de celui-ci à leurs produits. Ceci va probablement créer une norme pour la conteneurisation au même titre que OVA pour l'import-export de VM.
https://www.docker.com/microsoft
En tout cas, les containers ont une place au sens large dans le P2V. On peut très bien envisager de mettre un service, tel que FTP, DNS, Mail, etc .. dans un container, et si on doit isoler le FTP du DNS, créer deux containers sera moins lourd en ressources que de créer deux VM. Il est possible d'appliquer/adapter les méthodes présentées dans le tutoriel. Il me semble par contre actuellement impossible de déplacer un container à chaud, mais je peux me tromper. Et encore, si le contenu du container est accessible comme un simple dossier au niveau de son hôte, rien n’empêche en théorie d'utiliser rsync, d'utiliser LVM ou DRBD pour pouvoir changer le container de serveur.
Pas vraiment, on virtualise potentiellement tout le système d'exploitation, bien plus que le système de fichiers. Le noyau est bien le même mais on en a pas du tout la même vision en fonction du container dans lequel on se trouve.Citation:
Envoyé par chrtophe
Dans un container, on ne voit que les processus de ce container. A partir du système hôte (hors conteneur donc), on voit tout les processus.Citation:
Il serait intéressant de voir si les processus lancées depuis un container sont vus en dehors de celui-ci ou si l'on ne voit que le processus "container".
Rien n'empêche d'utiliser tout hyperviseur supportant Linux.Citation:
Dans le cas de Docker par exemple, pour l'utiliser sous Windows ou Mac OS X, ça s’appuie sur VirtualBox
Ce n'est plus tout à fait vrai. Docker s'est libéré de la dépendance à lxc et aux cgroups, deux composants spécifiques à Linux, en les remplaçant par une couche d'abstraction portable, libcontainer.Citation:
(Docker étant lié au noyau Linux, tout comme BSD Jail et les zones Solaris cités par jlliagre sont respectivement liés à BSD et à l'OS Solaris).
Il n'y a (aura) plus de raison technique empêchant le support de Docker sur d'autres noyaux que Linux, ce que tu évoque d'ailleurs déjà dans ta réponse à propos de Microsoft.
Oracle travaille aussi avec Docker pour une intégration avec les zones Solaris :Citation:
Dans le cas de Docker, qui prend actuellement de l'ampleur, Microsoft travaille en partenariat avec eux pour intégrer le support de celui-ci à leurs produits.
https://blog.docker.com/2015/08/dock...solaris-zones/
C'est l'objectif de l'Open Containers Initiative : https://www.opencontainers.org/Citation:
Ceci va probablement créer une norme pour la conteneurisation au même titre que OVA pour l'import-export de VM.
Ce n'est pas encore intégré ou stable mais c'est en cours de développement pour lxc :Citation:
Il me semble par contre actuellement impossible de déplacer un container à chaud, mais je peux me tromper.
https://www.flockport.com/live-migra...g-soon-to-lxc/
pour docker (où l'intérêt est plus limité):
http://blog.circleci.com/checkpoint-...ner-with-criu/
et enfin, côté Solaris, la migration à chaud de conteneurs est disponible depuis Solaris 11.3 avec les kernel zones, qui sont un peu spéciales dans le sens où elles cloisonnent plus l'environnement virtualisé que des conteneurs classiques, mais sans vraiment faire appel à un hyperviseur traditionnel.
http://docs.oracle.com/cd/E53394_01/...tml#SOLWNgpqkq
Oui, mais là il s'agit de migration à froid qui est bien sûr possible avec toutes les technos de conteneurs.Citation:
Et encore, si le contenu du container est accessible comme un simple dossier au niveau de son hôte, rien n’empêche en théorie d'utiliser rsync, d'utiliser LVM ou DRBD pour pouvoir changer le container de serveur.
Bonjour,
J'ai parcouru avec intérêt votre article car je vais sans doute devoir virtualiser d'ici peu de temps un vieux serveur de test tournant sous Windows Server 2003 SE.
J'avoue ne pas être expert (et de loin) dans ces problématiques d'ou j’espère qu'on ne tiendra pas compte du fait que je puisse poser des questions stupides pour les initiés
Caracteristique:
Machine: HP Proliant ML350 G4 1G
OS: Windows Server 2003 SE SP2
BD: Oracle 10G R2
Il s'agit comme je l'ai dit d'une base de test pour un logiciel de GMAO (gestion de maintenance assistée par ordinateur) qui communique donc avec ma base Oracle.
J'ai comme vous vous en doutez quelques questions sur la virtualisation:
- Ce serveur comprend des HDD hotswap (x6) de capacité différentes découlant sur 3 disque logiques (1 pour le Système et programme Windows, 1 pour les données, 1 pour les points de sauvegarde système). Le disque logique "données" comporte a la fois ma base Oracle et ma GMAO, et est physiquement constitué de 4HDD monté en RAID 5 .
D'ou les questions:
Est ce que la virtualisation est possible?
Et si oui ( et que j'ai bien compris le principe ce qui n'est pas sur :aie: ) cela ne me créera que 3 disques de capacité égale a celles dont je dispose aujourd'hui ou le RAID risque de poser quelques problème?
Est-il possible aussi de réduire la taille des disques à la virtualisation sans perdre de données?
- Étant donné que ce serveur était auparavant un serveur en exploitation, il a fait donc partie d'un domaine (mais qui 1 n'existe plus et 2 était sur un réseau fermé et différent de celui sur lequel le serveur se trouve actuellement).
Cela peut il poser problème?
Est-il possible de changer le domaine a posteriori ou faut-il le modifier directement sur la machine?
Mais j'ai aussi une question plus générale: Selon vous quel utilitaire faudrait-il employer (gratuit si possible) pour virtualiser cette machine, puisque visiblement Disk2Vhd ne permet pas de virtualiser mon OS (du moins d'apres ce que j'ai compris sur https://technet.microsoft.com/fr-fr/...15(en-us).aspx) VMware? ColdCLone? ...
Je sais je suis désolé mais ça fait beaucoup de questions :oops:
En remerciant par avance tout ceux qui voudront bien m'aider
Cdt
Si ce serveur est un serveur de test, il peut donc être indisponible. Le plus simple est de créer un ntbackup en sauvegardant tous les volumes. Tu arrêtes tous les services avant de lancer le ntbackup. Une fois ton image système crée, tu arrêtes le serveur physique. Il s'agit donc là de migration à froid.
Tu prépares ta VM avec un fichier image disque par disque physique existant dans l'ancien serveur (exemple C, D, E etc..). Leur taille doit correspondre au minimum à la taille d'occupation des disques d'origine. Tu installes un windows 2003 de base dans la VM, tu montes ton disque de sauvegarde, puis tu restaures ta sauvegarde. On se fous que les disques soient en RAID, on accèdes à C, D ,E sans s'en préoccuper. Tu peux envisager de ne pas sauvegarder le disque de sauvegarde.
En théorie, au reboot, ton serveur tourne (sans parler des drivers). Il te faudra probablement effectuer des ajustements. Il te faudra désinstaller les anciens drivers, puis installer les drivers VM via les additions invitées.(c'est expliqué dans le tuto mais lje fais un rappel)
Tu auras peut-être des soucis de réactualisation de licence, Windows au moins détectera que le "matériel" a changé. Pour Oracle, certainement aussi.
Quand tu crée les disques de la virtualisation, tu peux créer des disques à taille fixe ou dynamique. Un,e taille fixe te créera un fichier de 10 Goi pour un disque virtuel de 10 Go, un disque dynamique de 10 Go ne pèsera que quelques octets à sa création, puis grossira au fur et à mesure de son remplissage à hauteur de 10 Go. Attention à l'espace disque sur l'hôte dans ce cas.Citation:
Est-il possible aussi de réduire la taille des disques à la virtualisation sans perdre de données?
Donc dans un premier temps si ton disque de données d'origine est un disque de 20 Go et qu'il est rempli à 50%, lors de la restauration depuis la VM, le fichier atteindra une taille de 10 Go et pourra grossir jusqu'à 20 Go si tu as défini celui-ci pour être un disque dynamique de 20 Go. Ensuite pour la réduction, c'est les mêmes règles qu'une machine réelle : il faut défragmenter de façon à ce que les données soit concentrées au début de la partition, puis réduire celle-ci. (avec un live-cd Linux et GParted par exemple). A ce stade, au niveau de la VM tu auras un disque dur avec de l'espace libre, tu pourrais par exemple créer une nouvelle partition dedans. Le fichier image au niveau de l'hôte restera à la même taille.
Ensuite, si tu veux réduire ce fichier, il te faudra utiliser les outils de l’hyperviseur, qui te permettrons soit de réduire la taille du fichier, soit réécrire un nouveau fichier. attention ici aussi à l'espace disque sur l'hôte.
Au niveau RAID, ton hyperviseur peut avoir son filesystem sur un système RAID pour la protection de défaillances disque.
Cela sors du sujet Virtualisation, mais je vais quand-même répondre.Citation:
- Étant donné que ce serveur était auparavant un serveur en exploitation, il a fait donc partie d'un domaine (mais qui 1 n'existe plus et 2 était sur un réseau fermé et différent de celui sur lequel le serveur se trouve actuellement).
Pour sortir une machine d'un domaine : dcpromo, si celle-ci était contrôleur, ou tu la sors simplement du domaine depuis les propriétés si serveur autonome.
Pour travailler sur un réseau isolé, tu mets ta VM en mode NAT au niveau réseau (situation par défaut en général), ou en réseau privé, pas en mode pont afin qu'elle ne soit pas vue comme une machine normale sur le réseau.
Si ÇA !! c'est pas de la réponse! , c'est que j'y connais rien! :mouarf:
Merci vraiment pour toutes ces réponses (et vu l'heure j’espère ne pas t'avoir tenu réveillé :calim2: )
Je vais faire comme tu as dis en espérant ne pas avoir de problèmes insurmontables (quoique il y a toujours developpez.com et ses membres pour ce genre de choses ;) )
Merci encore
L'article est bien fait.
J'ai participé à des migrations massives P2V de machines physiques dans des datacenters et ça se fait généralement en L2 (on reste à IP iso-périmètre ie dans les mêmes subnets IP source/destination). C'est très rassurant pour le client qui ne maîtrise pas (voire jamais) les adhérences IP entre ses machines (cas des archis n-tiers par exemple avec plusieurs niveaux de firewalling).
En revanche, plus c'est simple pour le client, et plus c'est compliqué pour l'hébergeur :-(
Parce que tirer des liens L2 vers un datacenter, ça peut être dangereux, et pour le client et pour l'hébergeur, surtout si on veut faire de la résilience... Ca demande d'avoir la cartographie précise du Spanning Tree bazar.
Et ma recommandation, c'est d'utiliser des équipements L2/L3 dédiés en datacenter pour ce client et que tous les flux tombent dans des lames "bac-à-sable".
Parce que tirer des VLAN dans des vrf bien isolées dans un coeur de réseau mutualisé, c'est a priori sexy mais si ça part en vrille, le coeur de réseau montera en CPU et ce sont toutes les vrf qui seront impactées :-(
Il y aurait bcp à dire sur le P2V massif vers AWS/Azure mais ça dépasse le cadre de la discussion :-(
VX
Toute contribution est la bienvenue, même s'il s'agit d'écrire un autre article complet sur le sujet ;)Citation:
Envoyé par vxlan.is.top
Attention tout de même à bien faire attention au cout des licences lorsqu'il y a virtualisation des machines physiques en production, surtout pour les produits basés sur les CPUs physiques.
Les éditeurs de logiciels sont "malins", surtout Oracle qui a défaut d'innover sur ses produits, innove sur la facturation.
Exemple :
Vous avez un serveur physique 2 x CPUs avec un WebLogic dessus, votre cout de licence est calculée sur la base de ces 2 CPUs physiques.
Vous basculez votre serveur physique en une machine virtuelle (2 CPUs virtuels) mais votre machine virtuelle s'exécute sur une plus grosse bécane avec 8 CPUs physiques
--> votre cout de licence est maintenant multiplié par 4
Chers membres du Club,
J'ai fait une mise à jour conséquente de mon tutoriel, tenant compte de l'évolution des produits.
Ce tutoriel vous présentera la migration à chaud, la migration à froid, ainsi que la migration intermédiaire que j'ai nommée migration « à tiède » . Le tutoriel vous présentera également différents produits pour effectuer cette migration.
:fleche: N'hésitez-pas à me donner votre avis.
:fleche: Si vous avez des questions ou des choses à ajouter, n'hésitez-pas.
Bonne lecture ;)