Comment utiliser DRBD pour la réplication complète du système
J'ai installé et configuré [~ # ~] drbd [~ # ~] sur mes serveurs Ubuntu 9.10, en suivant les liens ci-dessous.
Je suis dans un plan pour configurer les serveurs Ubuntu pour la haute disponibilité, j'ai donc testé le fonctionnement de DRBD et c'est bien selon les liens que j'ai mentionnés. Mais ma principale exigence est que je pourrais mettre un autre serveur en production si le serveur principal tombe en panne/corrompu. Est-il possible de configurer DRBD de sorte que toutes les modifications apportées sur le serveur principal à '/' sont répliqués sur le serveur secondaire ?.
MODIFIER:
Chers experts:
J'ai un serveur Ubuntu qui héberge Apache , Tomcat , mysql , ldap et ainsi de suite. Je ne sais pas comment dire ... comme si ce serveur était corrompu ou fonctionnait mal, je devrais immédiatement faire fonctionner un autre système avec les mêmes applications de bases de données, services, fichiers et répertoires (comme un clone). Je me demande s'il y a quelque chose comme le primaire et le secondaire qui se répliquent (tout le système) et si en cas de défaillance du serveur principal, je peux immédiatement trouver le secondaire.
Je ne parle pas seulement de DRBD, il peut s'agir de n'importe quel outil tiers qui répond à toutes mes exigences. Je dois le faire avant l'heure qui m'est impartie. D'une manière ou d'une autre, vous essayez de comprendre ce dont j'ai besoin et d'y mettre un terme
Je vous remercie!
Répliquer l'ensemble du système dans un scénario à haute disponibilité n'est probablement pas une bonne idée, pour deux raisons:
Il existe quelques paramètres de configuration propres à chaque serveur: par exemple, le nom d'hôte et l'adresse IP, éventuellement le mappage des périphériques DRBD aux disques. La configuration du système afin qu'il puisse choisir la configuration correcte en fonction de certains paramètres "environnementaux" (par exemple, le numéro de série du processeur) est certainement plus difficile que cela ne vaut.
L'un des avantages des configurations à haute disponibilité est la possibilité d'effectuer des mises à niveau du système sans interruption de service: vous mettez à niveau le système de "sauvegarde", testez son fonctionnement, échangez les rôles "principal" et "de sauvegarde", mettez à niveau l'ancien système primaire. En cas de problème, vous avez toujours au moins un système opérationnel. La configuration d'une réplication automatisée du système entier annule cette procédure: si vous mettez à niveau un système, l'autre est également mis à niveau: vous ne pouvez probablement pas le faire pendant que le service est en cours d'exécution et vous perdez la fonction de "reprise après sinistre".
Cela dit, il est possible de répliquer exactement les parties du système dont vous avez besoin pour avoir un "hot spare" pour les systèmes de production, prêt à démarrer en cas de panne du serveur principal.
Les détails exacts de la façon dont vous procédez dépendent du service que vous souhaitez exécuter (www? Mysql? Nfs?), Mais l'idée générale est la suivante: configuration répliquée et données mutables . Par exemple, en supposant que vous souhaitiez disposer d'un serveur NFS hautement disponible, vous pouvez procéder comme suit (sur les deux serveurs):
Configurez un disque DRBD répliqué et montez-le sur
/nfssur les deux serveurs (principal et de secours).Créer des répertoires
/nfs/etcet/nfs/dataSymlink
/etc/exportà/nfs/etc/exportet lui faire exporter le/nfs/datasystème de fichiers aux clients.Faites gérer le service NFS par heartbeat , plutôt que par le démon init/upstart du système, afin qu'il monte et descend en fonction du rôle de serveur (principal ou de sauvegarde) et de la disponibilité du disque DRBD.
C'est assez sommaire, mais cela devrait suffire pour vous aider à démarrer.
Vous pouvez envisager de combiner drdb avec la virtualisation. Plus d'informations peuvent être trouvées ici .
Par exemple, vous pouvez créer un xen VM qui utilise un disque soutenu par drbd.