Pourquoi un cluster dhcp ?

La question peut légitimement se poser. En effet, un client ayant acquis son adresse la conserve un certain temps, ce temps est appelé bail ou lease in English :) (Chez Microsoft par défaut sur un LAN 8 jours). Au bout de ce délai le client voit son bail arrivé à terme, il demande au serveur s'il peut le prolonger. De même pour le serveur, lorsqu'un bail arrive à terme il envoie une demande au client pour savoir si celui-ci souhaite prolonger son bail.

Maintenant que se passe-t-il si entre le début et la fin du bail le service DHCP tombe ?

Et bien les clients ne seront tout simplement plus capable d'obtenir une adresse IP et ne pourront donc plus communiquer. 

Jusqu'ici la méthode classique permettant de palier à la perte d'un service DHCP était d'avoir deux serveurs DHCP avec des scopes identiques. Le premier serveur était actif et le second avec le service non démarré. Lors d'une panne DHCP sur le premier serveur on démarrait le service DHCP sur le deuxième serveur et les clients retrouvaient la possibilité de communiquer.

Mis à part son côté archaïque cette méthode présuppose que l'on détecte la panne du premier serveur. Cette panne a moins d'avoir un système de monitoring n'était généralement détecter que lors de la perte du service sur le premier serveur générant au mieux quelques temps d'indisponibilité pour les clients, du stress pour les équipes («Heu quelqu'un a déjà tester le DHCP de backup ?») et au pire un remontage de serveur :D

Deuxième point sur le second serveur à moins de faire régulièrement un export de configuration on ne retrouvera pas les dernières options mises sans trop réfléchir (C'est mal), les leases actuels, les réservations, bref la configuration.

Une autre méthode est de diviser ses scopes DHCP. Ainsi si l'on prend l'exemple d'un parc de 50 clients. La coutume voudrait que l'on attribue un scope de 50 adresses plus une marge permettant l'expansion du parc. En fonction de l'activité on ajoutera 10 - 20 - 30% voire plus. 

Pour suivre l'exemple avec des chiffres simples nous imaginerons un environnement dynamique et l'on attribuera un scope de 100 adresses soit le double de ce qui est nécessaire. Maintenant que la taille du scope est définie passons à la redondance. 

La technique du "Split-DHCP" consiste donc à diviser sont scope sur des serveurs permettant ainsi si l'un tombe que l'autre puisse prendre la relève mais aussi d'équilibrer la charge car les serveurs sont actif-actif.

Pour ce faire il va falloir s'assurer qu'un seul et unique serveur puisse prendre en charge l’intégralité du service si le second tombe. Ainsi chaque scope présent sur chaque serveur doit être capable d'adresser l’intégralité du parc. Dans notre exemple nous devrons donc créer sur chaque serveur DHCP un scope de 100 adresses chacun (sur la même plage bien-sûr) avec les même options.

Ici aussi petit problème, afin d'assurer la redondance d'un service nous avons recourt à une forme de bricolage qui demande de doubler les scopes et aussi de maintenir de façon manuelle l'exactitude des configurations entre les deux serveurs.

Sous 2008R2 Microsoft permet d'utilise un wizard afin de procéder à cette manipulation.

Une troisième solutions existe donc c'est le cluster DHCP.
Pour commencer sur les cluster voici quelques éléments clés.

Qu'est-ce que le quorum ?

Pour faire simple, le quorum est un terme bien mystérieux pour décrire un concept assez simple. C'est donc le nombre minimum de nœud nécessaire au fonctionnement du cluster. Le fonctionnement est simple, les membres du cluster votes, si le nombre de votes tombe sous la valeur du quorum, le cluster s’arrête.

Il existe quatre types de quorum :

• Node Majority : Chaque nœud vote, le cluster fonctionne uniquement si la majorité absolue est atteinte (plus de 50%). 
• Node and Disk Majority : Le fonctionnement est le même que le "Node Majority" néanmoins une partie supplémentaire interviens dans le vote, c'est le witness disk (disque témoin)
• Node and File Share Majority : ici le principe est le même que pour le "Node and Disk Majority" mais le disk witness est remplacer par un partage réseau classique
• No Majority, Disk Only: Dans ce fonctionnement seul les nœuds en communication avec le witness disk peuvent continuer à faire fonctionner le service. Ici il n'est pas nécessaire d'avoir une majorité de nœud en fonctionnement.

Witness disk et File Share Majority

Un petit exemple :

Le cluster est composé de quatre serveurs. 

• Node Majority : Si deux nœud tombe (quorum = 2), le service proposé s’arrête.
• Node and disk majority : Le cluster comporte un membre de plus (le witness disk) on a donc 5 nœuds. Ainsi Si deux nœud tombe (quorum = 3), le service continue. En revanche si trois tombe, le quorum passe à 2 ce qui est sous la majorité et le service s'arrête.
• Node and file share majority : fonctionnement identique à "Node and disk majority" avec un partage réseau.
• No Majority, Disk Only: La condition de fonctionnement est l'accès au witness disk. Trois des quatre membres du cluster peuvent tomber, si le dernier est toujours en liaison avec le witness disk, le service continue. En revanche, si tous les membres du cluster fonctionnent mais que le witness disk tombe, le cluster complet tombe.

Le but d’un cluster est bien évidemment d’offrir une résistance élevé aux différentes pannes qu’il est possible de rencontrer. Ainsi même si il est possible de créer un cluster avec des nœuds n utilisant qu’une unique interface réseau pour communiquer entre eux, accéder au quorum et offrir le service aux clients il est préférable de séparer ces trois services.
De plus d’un point de vue physique il sera bien évidemment préférable d’avoir des interfaces physiques sur différentes cartes utilisant différents bus.
Ensuite viens la redondance réseau, ce point n’entre pas dans ce sujet mais il sera bien évidemment préférables d’avoir des chemins divers utilisant différents switch.
Ainsi la meilleure solution est bien d’utiliser deux cartes multi port utilisant des bus différents. Ces interfaces étant câblé sur différent switch et ayant eux même une solution de teaming offrant une solution de fault tolérance.

Tutorial 

Pour faire simple nous allons monter un cluster DHCP avec deux nœuds sur un lab.

Environnement 

Nœud 1 : powerhouse2008a
Nœud 2 : powerhouse2008b

Ces deux serveurs sont les deux AD de mon Lab. 

Les deux volumes sont présentés par un serveur FreeNas. @IP : 192.168.0.248

Nom du cluster : ClusterDHCP
@IP du cluster : 192.168.0.250 

Attention :

Avant de commencer : Si les serveurs DHCP que vous souhaitez utiliser pour monter ce cluster comportent déjà une configuration cette dernière sera perdue lors de la mise en place du cluster. Penser à faire un backup ou utiliser des serveurs "neufs".

Idem avec le volume permettant de stocker la configuration DHCP. Le resultat doit etre deux volumes visibles par les deux serveurs :

 
Ensuite libre à vous de tester le tout en coupant une carte réseau, le serveur iScsi, un serveur etc et voir le fonctionnement.
A noter que vous pouvez aussi ajouter une interface réseau dédié à la communication entre les noeuds.

Si vous avez des questions, des commentaires, des retours d’expériences je suis preneur :D

A bon entendeur,

Julien


Sources :

http://technet.microsoft.com/en-us/library/ee405263(v=ws.10).aspx

http://blogs.technet.com/b/askcore/archive/2010/02/12/windows-server-2008-failover-clusters-networking-part-1.aspx

http://technet.microsoft.com/en-us/library/cc770620(v=ws.10).aspx