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


8

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?


1
Est-ce que ces "hôtes" physiques avec des services réels ou des hôtes VM avec un tas d'invités?
Nathan C

2
Avec VMware FT et Hyper-V Replica disponibles en tant qu'options de virtualisation (ainsi que l'ancien HA), je trouve que l'idée d'avoir un disque de secours dédié pour un hôte à usage unique est un peu décalée.
joeqwerty

Réponses:


6

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.


C'est à ça que servent les sauvegardes et la gestion de la configuration, non?
ewwhite

@ewwhite Absolument, mais il devrait être beaucoup plus facile, si nécessaire, de basculer vers un hôte secondaire qui a déjà une configuration (probablement bonne connue) (logiciel et paramètres), que de briser un miroir RAID, de déplacer physiquement les disques, de faire tout les modifications de configuration nécessaires (câblage réseau, DNS, paramètres IP, ...), puis vous devez corriger tout ce qui ne va pas, vous obligeant à basculer en premier lieu avant que votre hôte de secours ne vous fasse du bien. À ce stade, vous pourriez tout aussi bien le réparer. (Ou en particulier si vous êtes en mesure d'exécuter des machines virtuelles, revenez à un instantané pertinent.)
un CVn du

Oh, définitivement. Si j'ai des solutions de réplication, il y a aussi une considération RPO / RTO et un décalage (10-15 minutes) pour couvrir les scénarios ci-dessus.
ewwhite

@ewwhite Je ne conteste pas votre point (et j'ai en fait voté votre réponse), j'ajoute simplement une autre façon que je n'ai vu personne mentionner comment la solution proposée par le PO pourrait (ne pourrait) pas produire le résultat le plus probable, qui est la récupération après échec. Était en fait surpris de voir ma réponse acceptée.
un CVn

5
Sandra travaille de façon mystérieuse ...
ewwhite

11

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.


Les pièces mobiles meurent en premier - heureusement les disques RAID, sinon ce serait mon échec le plus fréquent.
Sobrique

2
+1 juste pour "ENREGISTRER les contrats de support de vos serveurs". Même dans mon expérience limitée, il est plus courant que vous ne le pensez que j'appelle le support lors d'une situation SHTF sur un nouveau site et le support n'a aucune idée que le matériel particulier existe et a un contrat attaché.

Les serveurs en question sont tous IBM et ont probablement 5 ans. Jusqu'à présent, nous n'avons eu qu'une seule carte mère et une seule défaillance du processeur.
Jasmine Lognnes

1
IBM et HP sont solides. Dell parfois. Si Supermicro, je recommanderais de conserver DEUX pièces de rechange par serveur;)
ewwhite

1
Sur mes serveurs HP, les premiers seuils ECC sont dépassés et déclenchent une alerte . La RAM est généralement remplacée avant qu'il n'y ait un impact sur les applications. Je le vois environ 10 fois par an sur quelques centaines de serveurs.
ewwhite

9

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.


2
+1 juste pour la courbe de temps de récupération; Je dis toujours aux clients qu'ils obtiennent 99% de disponibilité pour le coût du kit et de la configuration, mais chaque 9 supplémentaire dont ils décident qu'ils ont besoin augmentera le coût de deux à dix fois.
MadHatter

Les temps d'arrêt pendant la nuit ne sont pas bons, mais ils ont accepté d'acheter le PDG. Pendant les heures de travail, 30 minutes suffisent probablement tous les 6 mois. Passer à une machine virtuelle est une idée intéressante. Peut-on le faire avec KVM? Aurai-je encore besoin de maintenir la machine virtuelle avec des correctifs et des changements de configuration, ou cela peut-il être automatisé?
Jasmine Lognnes

La VM est une machine virtuelle, rien à voir avec un KVM. (Clavier / Vidéo / Souris). Et oui, vous devez garder l'instance du système d'exploitation à jour et vérifier que tout fonctionne normalement. Mais vous devriez pouvoir utiliser le même mécanisme de mise à jour que vous utilisez sur le périphérique principal.
Sobrique

Bien que sérieusement - à quelle fréquence votre serveur est-il tombé? Je veux dire complètement, pour des raisons liées au matériel? La plupart des pièces de matériel de «qualité serveur» exécutent une résilience N + 1.
Sobrique

3
@sobrique dans ce contexte, KVM signifie probablement machine virtuelle basée sur le noyau - linux-kvm.org
Grant

5

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.


2

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.