Hôte de rechange chaud ou hôte de rechange froid ?

Oui, c'est un peu de la vieille école. Le matériel moderne ne juste échouer si souvent. Concentrez-vous soit sur l'amélioration de la 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 du meilleur matériel.
• Assurez-vous que vous disposez de contrats d'assistance.
• ENREGISTRER les contrats de support de vos serveurs (les pièces de rechange sont stockées localement sur la base des données d'enregistrement !)
• Utilisez des alimentations redondantes, le RAID (matériel ?), des ventilateurs redondants.
• Si le serveur n'est pas capable d'accueillir les fonctions redondantes ci-dessus, gardez un châssis ou des composants de rechange à portée de main pour pouvoir s'auto-réparer en cas de panne.

Dans l'ordre décroissant de la fréquence des pannes, je vois : les disques, la RAM, les alimentations, les ventilateurs le plus souvent... Parfois la carte système ou le CPU. Mais c'est sur ces deux derniers points que votre contrat d'assistance devrait intervenir.

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

J'ai travaillé dans des endroits qui géraient un site DR chaud - littéralement, des serveurs identiques au primaire, prêts à fonctionner instantanément. Cependant, le basculement en DR est un processus automatisé - nous ne parlons pas de câblage, d'un peu de bricolage et d'un commutateur, mais d'un processus qui, lorsque nous appuyons sur le bouton, bascule tout d'un site à l'autre.

Cette approche est excessivement coûteuse, mais c'est une décision commerciale - risque acceptable par rapport à l'argent nécessaire pour atteindre l'objectif. En règle générale, il y a une courbe exponentielle sur l'objectif de temps de récupération - plus il se rapproche de zéro, plus il coûte cher.

Mais c'est le sujet de votre question, vraiment. Qu'est-ce que est votre objectif de temps de récupération, et quel est le moyen le plus efficace de l'atteindre. Attendre le démarrage d'un serveur prend quelques minutes. Combien de temps faut-il à quelqu'un pour effectuer les réglages et les "tâches de récupération" lorsque le serveur s'éteint à 4 heures du matin ?

Et quelle est la durée d'une panne acceptable ?

Je dirais que si vous faites de la "récupération à chaud", vous devez penser à la mise en grappe. Vous pouvez être assez bon marché sur le clustering avec une bonne utilisation de VMWare - "échouer" à une VM - même à partir d'un physique - signifie que vous n'exécutez pas de matériel redondant. (Enfin, N+1 plutôt que 2N).

Si votre RTO est suffisamment long, alors éteignez le boîtier. Vous constaterez peut-être que le RTO est suffisant pour qu'une reconstruction à froid à partir de la sauvegarde soit acceptable.

Le fait qu'il s'agisse d'une vieille école ne fait pas nécessairement de l'utilisation d'une pièce de rechange chaude une mauvaise idée.

Votre principale préoccupation devrait être le raisonnement, quels sont les risques que vous courez, et comment l'utilisation d'un hot spare les atténue. En effet, selon moi, le remplacement à chaud ne concerne que les pannes matérielles, qui, bien qu'elles ne soient pas rares, ne constituent pas 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 significatives.

L'exécution d'un hot spare avec de multiples étapes de basculement manuel prendra beaucoup de temps et risque de mal tourner, mais j'ai aussi vu des basculements automatisés avec des suites de clusters HA se transformer en de gros f*cks de clusters.

Par ailleurs, le fait de disposer d'une réserve chaude ou froide au même endroit n'assure pas la continuité des activités en cas de catastrophe locale.

Le concept d'avoir une réserve chaude ou même froide est dépendant comment l'application ou les applications sont construites en premier lieu.

Ce que je veux dire, c'est que si l'application a été construite de manière à ce que la charge des données et des services soit répartie sur plusieurs machines, l'idée qu'une seule machine puisse mettre le système hors service devrait disparaître. Dans cette situation, vous n'avez pas besoin d'une machine de secours. Vous avez plutôt besoin d'une capacité excédentaire suffisante pour faire face à l'arrêt d'une machine ou d'un composant individuel.

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, il suffit d'équilibrer la charge de 2 ou plus. Si l'un d'eux meurt, ce n'est pas grave. La base de données est généralement plus difficile car elle doit être conçue pour être multi-maîtres avec toutes les données synchronisées entre les machines participantes. Ainsi, au lieu d'un seul serveur de base de données, vous vous retrouvez avec deux (ou plus) qui répondent tous deux à vos besoins en matière de données. Les grands fournisseurs de services tels que Google, Amazon, Facebook, etc. ont choisi cette voie. Les coûts initiaux sont plus élevés en termes de temps de développement, mais ils sont payants si vous devez passer à l'échelle supérieure.

Maintenant, si votre application n'est pas structurée de cette manière ou s'il est simplement prohibitif de la réadapter, alors oui, vous aurez probablement besoin d'une réserve chaude.