Que dire sur le Cloud Computing à part qu’on en entend parler aujourd’hui à toutes les sauces, technologie hyper en vogue, qui séduit de plus en plus les sociétés.
Les différents cloud sont les suivants:
Le cloud public: Un prestataire tierce héberge et administre la solution cloud (voir les 3 services ci-dessous) retenue par la société
Le cloud privé: La solution Cloud retenue peut être hébergé soit en interne soit par un prestataire mais est exploité par la société
Le cloud hybride: Cloud qui permet de relier entres eux un cloud privée et un cloud public
à cela s’ajoutent les trois services suivants:
SAAS (Software as as service): Abonnement d’application hébergé dans le cloud, exemple Exchange Online Service ou Lync
PAAS (Platform as a Service) : Permet à une société d’héberger ses applications web dans le cloud sans s’occuper de l’infrastructure qu’il y a autour.
IAAS (Infrastructure as a service ): Tel que son nom l’indique, la société qui héberge ce service chez un prestataire dispose de l’infrastructure virtualisée de celui ci et peut faire évoluer son parc dynamiquement. Elle n’administre pas la virtualisation (les serveurs physiques) mais les OS invités via RDP par exemple.
Pourquoi passer au cloud?
L’externalisation de la gestion du parc informatique apporte un réel souffle aux administrateurs qui peuvent ainsi passer plus de temps à l’administration/peaufinage des services plutôt qu’à la gestion des équipements informatiques. (ajout de disque, mise à jours des firmware, contrat de maintenance….)
Le prestataire externe qui héberge votre solution cloud dispose d’une infrastructure Haute Dispo, clustering, répartiteur de charge, etc.. et qu’aujourd’hui la continuité de service fait partie des priorités .
Parce que vous payer ce que vous consommez, fini les disques durs utilisés à 30% et la ram en attente de nouvelles machines virtuelles
Parce que c’est tendance :p et que je le vaux bien
L’idée est louable, certains vous diront qu’il est tout de même conseillé de garder un DC physique, on peut partager cette idée également.
les conseils que je vous donne:
Sur votre VM ajout d’un second disque (D:\) pour la sauvegarde hebdomadaire de l’etat system de votre DC, personnellement j’ai utilisé un vhd à taille fixe de 20Go
la sauvegarde peut se faire via le planificateur de tache + un petit batch de ce type:
je supprime d’abord l’existant sur D:\ car 20Go ce n’est pas assez pour contenir deux sauvegardes complètes, ensuite la sauvegarde se réalise
Synchroniser l’horloge avec une source externe du type fr.pool.ntp.org
Décocher la synchro de l’horloge entre la vm et son serveur physique sinon l’horloge du DC continuera de se synchroniser sur le serveur Hyper-V, chez nous les serveurs physique Hyper-V ne font pas partie du domaine donc se synchronise nul part.
Spécifier le comportemant de la VM lors d’un reboot de l’hyperviseur, par defaut la machine virtuelle se met dans l’état « enregistré » ce qui peut poser des conflits lors des réplications entre DC par exemple.
récemment je me suis éclaté avec la mise en place d’un cluster de basculement SQL:
Environnement:
-un réseau virtuel externe pour les accès client en 21.11.255.x/24
-un réseau virtuel privé pour le heartbeat et le stockage ISCSI 10.0.0.x/8 (normalement il faut un réseau dédié uniquement au stockage ISCSI)
Toutes les VM tournent sur un serveur physique Hyper-V2 2008 R2 DataCenter sp1
-une VM nommée SQLNoeud1 / 2Go de ram et 2 vCPU / 21.11.255.181 / 10.0.0.2
-une VM nommée SQLNoeud2 / 2Go de ram et 2 vCPU / 21.11.255.182 / 10.0.0.3
-une VM nommée ISCSITarget / 1Go de ram et 1 vCPU / 21.11.255.180 / 10.0.0.1 (ici l’@IP 21.11.255.180 permet uniquement d’administrer la VM à distance)
schéma réseau
Les étapes:
– renommer vos serveurs
– configurer le réseaux (donc une carte en 21.11.255.x et une carte en 10.0.0.x)
– personnellement j’ai désactivé les FW pour des questions de simplicité! un ping nous permet ainsi de vérifier que les vm communiquent bien entres elles
– joindre vos machines virtuelles au domaine local
– une fois vos machines virtuelles redémarrées, faites les mises à jour windows (wsus si vous avez ou windows update of course)
– sur la vm ISCSITarget, installé le logiciel « Microsoft ISCSI Software Target 3.3 »
– configurez votre 1ère cible ISCSI en indiquant son nom exemple « bddsql » puis les @IP des clients qui y auront accès, comme l’@IP 10.0.0.x de vos deux noeuds SQL
Cible ISCSILes initatieurs ISCSI
– il suffit ensuite de créer un disque virtuel de 10Go nommé par exemple quorum.vhd, un second de 40Go bddsql.vhd et un troisième de 10Go msdtc.vhd (vous pouvez aussi créer 3 cibles ISCSI et dans chacunes d’elles mettre soit quorum.vhd soit bddsql.vhd soit msdtc.vhd)
les vhd quorum + bdd + msdtc
– vous pouvez maintenant retourner sur vos VM SQLnoeud1 et 2 et activer l’inititateur ISCSI avec en cible l’@IP de ISCSITarget 10.0.0.x pour que les nouveaux disques attribués « montent », prenez soin de les mettre en ligne, de les initialiser et des les formater.
cible ISCSI
LUNLUN après formatage
– ceci fait, sur vos deux noeuds, installer la fonctionnalité « clustering avec basculement » et dans rôles cochez « serveur d’application » puis Transactions distribuées.
– puis sur SQLNoeud1 par exemple, lancer l’installation de SQL serveur 2008R2 entreprise en mode cluster pour créer le cluster SQL, il vous sera demandé le nom dns du cluster exemple clustersql.domain.com.local, l’@IP virtuelle de ce cluster exemple 21.11.255.x, l’emplacement du quorum, le répertoire où seront stockés les bases de données, ce répertoire devant pointer évidemment sur bddsql.vhd, dans mon cas, F:\quelqueschose\ (vous remarquerez que les disques ISCSI sont marqués comme « réservé » par le système d’exploitation)
– sur SQLnoeud2, lancer l’installation de SQL serveur pour ajouter ce serveur en tant que nouveau noeud au cluster créer précédemment.
– Dans le gestionnaire de cluster on voit que tous nos noeuds sont actifs, on peut donc s’amuser a arrêter le noeud hébergeant le service SQL et voir que le second noeud prend le relais autormatiquement. Dans mes tests, la perte de connectivité lors du basculement de noeud dure entre 10 à 20s.
mes scénario de basculement concluant:
shutdown de la vm
arret de la vm
perte de la connectivité « accès public » en 21.11.255.x
perte de la connectivité « accès ISCSI baie de stockage » en 10.0.0.x
le basculement ne se fait pas lorsque j’arrête manuellement le service SQL, le cluster SQL apparaît comme étant « déconnecté », ce comportement est normal.
vue des noeuds actifsRésumé des disques attachés à ce clustersur SQLnoeud1 on voit que cette VM héberge actuellement les disques + les services SQL et MSDTCFenêtre nous permettant de modifier la vip du service SQL
j’ai fait les screen shot après avoir tout installé …. 🙂 alors veuillez m’excuser pour les screens manquants comme l’installation du cluster et celle d’SQL
Mon ressenti:
Cet environnement de test est réellement pratique car fonctionnel même si l’utilisation d’une réelle baie de stockage serait plus parlant quant aux performances par exemple.
En plus d’être fonctionnel, cette plateforme est plutôt rapide à mettre en place, cela peut être montée en 1/2 journée voir une journée.
L’ajout de noeud permet de réaliser des modifications de configuration de quorum. (par exemple avec deux noeuds, le cluster me recommandait l’utilisation d’un quorum de type « noeud et disque majoritair » alors que l’ajout d’un 3ème noeud nous incite à changer le quorum en un quorum à « noeud majoritaire ».
Ce cluster de basculement, permet d’aborder sagement la haute dispo des applications, en l’occurrence SQL
J’espère que ce pseudo « tuto », vous donnera envie de monter votre propre maquette :p
OZEr la VIRTUalisation! 