Hôte de secours à chaud vs hôte de secours à froid?

Nous avons plusieurs hôtes où nous avons un hôte de remplacement à chaud identique, qui est corrigé et mis à jour de sorte qu'il est très proche d'avoir le même logiciel et la même configuration. En cas de panne, le câble réseau est commuté et le serveur DHCP est mis à jour avec la nouvelle adresse MAC. C'est le meilleur cas, car il y en a généralement un peu plus qui doit être modifié.

Je pense que c'est un gaspillage d'électricité d'avoir un hôte de rechange et une perte de temps pour le maintenir, et puisque des modifications de configuration sont nécessaires en cas de basculement, je voudrais demander ce qui suit:

Les hôtes de rechange sont-ils de la vieille école et il existe de meilleures façons maintenant?

Au lieu d'avoir un hôte de secours, serait-il sensé d'en faire un disque de secours, de prendre les disques durs et de les placer dans l'hôte principal et de changer le RAID de 1 à 1 + 1. En cas d'échec, tout ce que je devrais faire est de changer les câbles réseau, de mettre à jour le serveur DHCP, de prendre les disques durs et de les insérer dans le disque de secours et de mettre sous tension. L'avantage, selon moi, est que les disques 2x2 sont toujours synchronisés, donc un seul hôte à maintenir et aucun changement de configuration n'est nécessaire lors du basculement.

est-ce une bonne idée?

Sobrique explique comment l'intervention manuelle fait que votre solution proposée est sup-optimale , et ewwhite parle de la probabilité de défaillance de divers composants . Ces deux OMI font valoir de très bons points et devraient être sérieusement prises en considération.

Il y a cependant un problème sur lequel personne ne semble avoir commenté jusqu'à présent, ce qui me surprend un peu. Vous proposez de:

faire de [l'hôte de secours à chaud actuel] un disque de secours, prendre les disques durs et les placer dans l'hôte principal et changer le RAID de 1 à 1 + 1.

Cela ne vous protège pas contre tout ce que le système d'exploitation fait sur le disque.

Il ne vous protège vraiment que contre les pannes de disque qui, en passant des miroirs (RAID 1) aux miroirs de miroirs (RAID 1 + 1), vous réduisez considérablement l'impact de commencer. Vous pouvez obtenir le même résultat en augmentant le nombre de disques dans chaque jeu de miroirs (passez de RAID 1 à 2 disques à RAID 1 à 4 disques, par exemple), tout en améliorant très probablement les performances de lecture pendant les opérations ordinaires.

Eh bien, voyons comment cela pourrait échouer .

• Supposons que vous installez des mises à jour système et que quelque chose provoque l'échec du processus à mi-chemin; peut-être qu'il y a une panne d'alimentation et d'onduleur , ou peut-être que vous avez un accident anormal et que vous avez rencontré un bug de noyau paralysant (Linux est assez fiable de nos jours, mais il y a toujours le risque).
• Peut-être qu'une mise à jour introduit un problème que vous n'avez pas détecté pendant les tests (vous testez les mises à jour du système, non?) Nécessitant un basculement vers le système secondaire pendant que vous corrigez le principal
• Peut-être qu'un bogue dans le code du système de fichiers provoque des écritures parasites et invalides sur le disque.
• Peut-être qu'un administrateur aux gros doigts (ou même malveillant) le fait rm -rf ../*ou rm -rf /*au lieu de rm -rf ./*.
• Peut-être qu'un bogue dans votre propre logiciel provoque une corruption massive du contenu de la base de données.
• Peut-être qu'un virus parvient à se faufiler.

Peut-être, peut-être, peut-être ... (et je suis sûr qu'il y a bien plus de façons dont votre approche proposée pourrait échouer.) Cependant, en fin de compte, cela revient à votre "avantage" les deux ensembles sont toujours synchronisés. Parfois, vous ne voulez pas qu'ils soient parfaitement synchronisés.

En fonction de ce qui s'est exactement passé, c'est à ce moment-là que vous souhaitez soit une mise en veille à chaud ou à froid prête à être activée et désactivée, soit des sauvegardes appropriées. Quoi qu'il en soit, les miroirs RAID de miroirs (ou miroirs RAID) ne vous aident pas si le mode de défaillance implique autre chose que la défaillance du périphérique de stockage matériel (panne de disque). Quelque chose comme raidzN de ZFS peut probablement faire un peu mieux à certains égards, mais pas du tout mieux à d'autres.

Pour moi, cela ferait en sorte que votre approche proposée ne soit pas possible dès le départ si l'intention était une sorte de basculement en cas de catastrophe.

Oui, c'est un peu vieille école. Le matériel moderne échoue non seulement aussi souvent. Concentrez-vous soit sur la haute disponibilité de vos applications (pas toujours possible), soit sur les éléments nécessaires pour rendre vos hôtes individuels plus résistants ...

Pour les hôtes:

• Achetez un meilleur matériel.
• Assurez-vous d'avoir des contrats de support.
• ENREGISTREZ les contrats de support de vos serveurs (les pièces détachées sont stockées localement en fonction des données d'enregistrement!)
• Utilisez des alimentations redondantes, (matériel?) RAID, des ventilateurs redondants.
• Si le serveur n'est pas capable de prendre en charge les fonctions redondantes ci-dessus, gardez un châssis ou des composants de rechange à portée de main pour pouvoir effectuer une auto-réparation en cas de panne.

Par ordre décroissant de fréquence de pannes, je vois: disques, RAM, alimentations, ventilateurs le plus souvent ... Parfois carte système ou CPU. Mais ces deux derniers sont là où votre contrat de support devrait entrer en jeu.

C'est plutôt inefficace - notamment en raison de la dépendance à l'intervention manuelle pour effectuer le changement.

J'ai travaillé dans des endroits qui exécutent un site de récupération à chaud - littéralement, des serveurs identiques au principal, prêts à fonctionner instantanément. Cependant, le basculement DR est un processus automatisé - nous ne parlons pas de câblage, d'un peu de tripotage et d'un commutateur, mais un processus lorsque nous appuyons sur le bouton fait basculer tout d'un site à l'autre.

Cette approche est terriblement chère, mais c'est une décision commerciale - un risque acceptable par rapport à l'argent nécessaire pour atteindre l'objectif. En règle générale, il existe une courbe exponentielle sur l'objectif de temps de récupération - plus il approche de zéro, plus il en coûte.

Mais c'est de cela qu'il s'agit vraiment. Quel est votre objectif de temps de récupération et quel est le moyen le plus efficace de l'atteindre. L'attente du démarrage d'un serveur prendra quelques minutes. Combien de temps faut-il à quelqu'un pour effectuer les tâches d'ajustement et de récupération lorsqu'il passe à 4 heures du matin?

Et combien de temps dure une panne acceptable?

Je dirais que si vous faites une «récupération à chaud», vous voulez penser au clustering. Vous pouvez être assez bon marché sur le clustering avec une bonne utilisation de VMWare - le `` basculement '' sur une VM - même à partir d'un physique - signifie que vous n'exécutez pas de matériel redondant. (Eh bien, N + 1 plutôt que 2N).

Si votre RTO est assez long, éteignez la boîte. Vous pouvez constater que le RTO est suffisant pour qu'une reconstruction à froid à partir de la sauvegarde soit correcte.

Le fait que ce soit de la vieille école ne fait pas nécessairement de l'utilisation d'un disque de rechange une mauvaise idée.

Votre principale préoccupation devrait être la justification, quels sont les risques que vous courez et comment l'exécution d'un disque de secours les atténue. Parce que, à mon avis, votre disque de secours ne traite que des pannes matérielles, ce qui n'est pas rare, ni le seul risque opérationnel que vous courez, ni le plus probable. La deuxième préoccupation est de savoir si les stratégies alternatives permettent de réduire davantage les risques ou de réaliser des économies importantes.

L'exécution d'un disque de secours avec plusieurs étapes de basculement manuel prendra du temps et risque de mal tourner, mais il me semble également que le basculement automatisé avec des suites de grappes HA se transformant en f * cks de cluster majeurs.

Une autre chose est que la mise en veille à chaud ou à froid au même endroit n'assure pas la continuité des activités en cas de catastrophe locale.

Le concept d'avoir un disque de secours chaud ou même froid dépend de la façon dont les applications sont construites en premier lieu.

Ce que je veux dire, c'est que si l'application a été conçue de manière à ce que la charge de données et de service soit répartie sur plusieurs machines, le concept de n'importe quelle machine unique arrêtant le système devrait disparaître. Dans cette situation, vous n'avez pas besoin d'un disque de rechange. Au lieu de cela, vous avez besoin d'une capacité excédentaire suffisante pour gérer quand une machine / un composant individuel meurt.

Par exemple, une application Web standard nécessite généralement un serveur Web et un serveur de base de données. Pour les serveurs Web, équilibrez simplement la charge 2 ou plus. Si l'on meurt, pas de biggie. La base de données est généralement plus difficile car elle doit être architecturée pour être multi-maître avec toutes les données synchronisées sur les machines participantes. Ainsi, au lieu d'un seul serveur de base de données, vous vous retrouvez avec 2 (ou plus) qui répondent tous deux à vos besoins de données. Les grands fournisseurs de services tels que Google, Amazon, Facebook, etc. ont choisi cette voie. Il y a plus de coûts initiaux en temps de développement, mais cela rapporte des dividendes si vous avez besoin d'évoluer.

Maintenant, si votre application n'est pas structurée de cette manière ou qu'il est tout simplement prohibitif de l'ajuster de manière rétroactive, alors oui, vous voudrez probablement un disque de rechange.