Question Questions sur le point de défaillance unique pour les petites exploitations


  1. Si vous ne pouvez vous permettre ou n'avez pas besoin d'un cluster ou d'un serveur de réserve en attente de connexion en cas de panne, il semble que vous puissiez diviser les services fournis par un serveur costaud en deux serveurs moins volumineux. Ainsi si le serveur A tombe en panne, les clients risquent de perdre l'accès à, par exemple, les courriers électroniques, et si le serveur B tombe en panne, ils risquent de perdre l'accès au système ERP.

    Bien que, au début, cela semble plus fiable, cela n’augmente-t-il pas simplement le risque de défaillance matérielle? Ainsi, chaque échec n'aura pas un impact aussi important sur la productivité, mais maintenant, vous vous préparez à faire deux fois plus d'échecs.

    Quand je dis «moins costaud», ce que je veux vraiment dire, c'est une spécification de composant inférieure, pas une qualité inférieure. Donc, une spécification de machine pour la visualisation par rapport à deux serveurs spécifiés pour moins de charge chacun.

  2. Souvent, un réseau de stockage est recommandé afin que vous puissiez utiliser le clustering ou la migration pour conserver les services. Mais qu'en est-il du SAN lui-même? Si je devais mettre de l'argent sur le lieu d'une défaillance, ce ne serait pas sur le matériel de base d'un serveur, mais plutôt sur le stockage. Si vous ne disposez pas d'une sorte de SAN redondant, ces serveurs redondants ne me donneraient pas un grand sentiment de confiance. Personnellement, pour une petite opération, il serait plus logique pour moi d'investir dans des serveurs avec des composants redondants et des lecteurs locaux. Je peux voir un avantage dans les opérations plus grandes où le prix et la flexibilité d'un SAN sont rentables. Mais pour les plus petits magasins, je ne vois pas l'argument, du moins pas pour la tolérance aux pannes.


7
2018-01-29 20:00


origine




Réponses:


Tout cela se résume à la gestion des risques. Effectuer une analyse coûts / risques appropriée de vos systèmes informatiques vous aidera à déterminer où dépenser cet argent et quels risques vous pouvez ou devez supporter. Il y a un coût associé à tout… cela inclut la haute disponibilité et les temps d'arrêt.

Je travaille dans un petit endroit, je comprends donc cette lutte et le féru de l'informatique en moi ne veut pas de points de défaillance uniques, mais le coût de le faire à tous les niveaux n'est pas une option réaliste. Mais voici quelques choses que j'ai pu faire sans avoir un budget énorme. Cela ne signifie toutefois pas toujours la suppression du point de défaillance unique.

Bord du réseau: Nous avons 2 connexions Internet un T1 et Comcast Business. Nous prévoyons de transférer notre pare-feu sur une paire d’anciens ordinateurs exécutant pfSense à l’aide de CARP for HA.

Réseau: Le fait d’obtenir deux ou trois commutateurs gérés pour le cœur du réseau et d’utiliser la liaison pour répartir les serveurs critiques entre les deux commutateurs empêche une défaillance du commutateur de supprimer l’ensemble du compartiment de données.

Les serveurs: Tous les serveurs disposent de sources d'alimentation RAID et redondantes.

Serveur de sauvegarde: J'ai un système plus ancien qui n'est pas aussi puissant que le serveur de fichiers principal, mais il possède quelques grands disques sata dans raid5 qui prend des instantanés toutes les heures du serveur de fichiers principal. J'ai des scripts configurés pour que cela permette aux rôles de devenir le serveur de fichiers principal en cas de panne.

Serveur de sauvegarde hors site: Semblable à la sauvegarde sur site, nous effectuons des sauvegardes nocturnes sur un serveur via un tunnel vpn vers la maison du propriétaire.

Machines virtuelles: J'ai une paire de serveurs physiques qui exécutent un certain nombre de services au sein de machines virtuelles utilisant Xen. Ceux-ci fonctionnent à partir d'un partage NFS sur le serveur de fichiers principal et je peux effectuer une migration en direct entre les serveurs physiques si le besoin s'en fait sentir.


5
2018-01-29 21:26



Merci! Mais je parle en réalité de l’utilisation de deux serveurs sur un seul sans clustering ni réplication. Il s’agit essentiellement de diviser les services sur deux serveurs. Et si un stockage NAS ou SAN est utilisé pour le stockage, ne s'agit-il pas simplement de recréer le point de défaillance unique? Du point de vue des composants, la redondance (lecteurs, etc.) est assurée. Mais cela n'aide pas lorsque le contrôleur RAID panique et casse le module RAID. - Boden
Oui, j'ai déjà perdu une matrice RAID5 à cause d'un circuit défectueux dans le châssis remplaçable à chaud qui visse toute la chaîne. Cela ne devrait pas poser autant de problèmes avec les équivalents de série modernes qu'avec les anciens bus parallèles. L'élimination des points de défaillance uniques ne sera pas rentable à l'échelle dont vous parlez. À moins que le coût d'un échec soit extrêmement élevé, ce qui est peu probable. J'ai cependant une suggestion ... mais je le ferai dans un autre commentaire. - 3dinfluence
Si vous n'aviez que 2 serveurs, vous pouvez le faire. En supposant que les deux serveurs ont une capacité de stockage / RAM suffisante et prennent en charge la virtualisation. Vous pouvez configurer Xen sur les deux serveurs. Configurez des tâches cron sur chacune d’elles pour enregistrer l’état des machines virtuelles et copier le fichier résultant sur l’autre machine physique tous les soirs. Ainsi, en cas de défaillance du système, vous pourrez le remettre en marche rapidement sur le matériel restant. Minus quels que soient les changements survenus au moins ce jour-là. - 3dinfluence
C'est une suggestion intéressante. Cependant, cela risque d'augmenter considérablement le coût des serveurs. Chacun devra être capable d'exécuter la charge de l'autre (bien que peut-être avec des performances dégradées). Si vous allez dépenser ce genre d’argent, pourquoi ne pas disposer de deux serveurs identiques, dont l’un en veille immédiate? - Boden
Tout cela remonte à la gestion des coûts / risques. Vous êtes le mieux placé pour répondre à des questions telles que: L'exécution de vos services dans une performance dégradée est-elle meilleure que celle en panne? Êtes-vous prêt à perdre tous les changements depuis le dernier instantané? Vous pourrez peut-être contourner cela avec une stratégie de sauvegarde. Il est difficile d’atteindre un point d’échec unique sans économie d’échelle en votre faveur. Amazon Cloud peut être une option. Mais la virtualisation change cela mais pas tout à fait là et peut-être pas avec 2 serveurs. Des projets comme Sheepdog semblent intéressants. - 3dinfluence


Je pense que c’est une question qui a de nombreuses réponses, mais je conviens que dans de nombreux petits magasins, la solution à plusieurs serveurs fonctionne et, comme vous le dites, au moins quelque chose continue à fonctionner en cas de défaillance. Mais cela dépend de ce qui échoue.

Il est très difficile de couvrir toutes les bases, mais des alimentations redondantes, une alimentation de bonne qualité et de bonnes sauvegardes peuvent aider.

Nous avons utilisé Backup Exec System Recovery pour certains systèmes critiques. Pas tellement pour la sauvegarde quotidienne mais comme un outil de récupération. Nous pouvons restaurer sur différents matériels, si disponibles, et nous utilisons également le logiciel pour convertir l'image de sauvegarde en une machine virtuelle. Si le serveur tombe en panne et que nous devons attendre des réparations matérielles, nous pouvons démarrer une machine virtuelle sur un autre serveur ou une autre station de travail et continuer à marcher. Pas parfait, mais il peut être opérationnel rapidement.


4
2018-01-29 20:11





Concernant les SAN: Presque tout ce que vous utilisez sera redondant. Même s’il s’agit d’un seul boîtier, il y aura deux alimentations, deux connecteurs et deux têtes, chacune avec des liens vers tous les disques. Même quelque chose d'aussi simple qu'un MD3000 vendu par Dell présente toutes ces fonctionnalités. Les réseaux de stockage sont conçus pour constituer le cœur de vos boîtes. Ils sont donc conçus pour survivre à peu près à toutes les pannes matérielles aléatoires.

Cela étant dit, vous avez raison de dire que la redondance n'est pas toujours la meilleure option. Surtout si cela augmente la complexité. (et ce sera le cas) Une meilleure question à poser est la suivante: "Combien de temps l'entreprise acceptera-t-elle les temps d'arrêt". Si la perte de votre serveur de courrier pendant un jour ou deux n’a rien de grave, vous ne devriez probablement pas vous soucier de deux. Mais si une panne de serveur Web commence à vous faire perdre de l’argent réel chaque minute, alors vous devriez peut-être passer du temps à créer un cluster approprié.


3
2018-01-29 21:13





Plus vous avez de serveurs, plus il y a de chances que quelque chose se casse, c’est une façon de voir les choses. Un autre problème est que, si l’un se casse, vous craquez à 100%, tout comme vous le dites.

La défaillance matérielle la plus courante est celle des disques durs, comme vous le disiez ci-dessus. Indépendamment de l'ampleur de la division des opérations, vous devez mettre en RAID votre stockage.

Je voterais pour un couple de serveurs (RAIDed bien sûr) au lieu d’un énorme, à la fois pour la stabilité des opérations et la performance. Moins de logiciels se heurtent à chacun demandant des ressources, moins d'encombrement, plus de disques sur lesquels lire / écrire, etc.


2
2018-01-29 20:30





Personnellement, je choisirais plusieurs serveurs. Je ne pense pas que les pannes d'équipement soient plus probables dans ce scénario. Oui, vous avez plus d’équipements susceptibles d’échouer, mais les probabilités de défaillance d’une unité donnée doivent être constantes.

Ce qui me permet d’avoir plusieurs serveurs dans une configuration non redondante / non HA, c’est la possibilité de décharger une partie du travail sur un autre serveur en cas de panne. Alors, disons que mon serveur d'impression tombe en panne. Si je peux mapper quelques imprimantes sur le serveur de fichiers pendant que je répare le serveur d'impression, l'impact sur les opérations est réduit. Et c'est là que ça compte vraiment. Nous avons souvent tendance à parler de redondance matérielle, mais le matériel n'est qu'un outil de continuité des opérations.


2
2018-01-30 03:03



Eh bien, vos chances de gagner à la loterie sont plus grandes si vous achetez deux billets, même si cela ne fait pas beaucoup de différence. Un serveur nécessitant 6 heures de réparation peut coûter moins cher que deux, même en tenant compte des pertes dues à six heures d'indisponibilité complète. Bien que je convienne que certains services peuvent être rapidement déplacés vers un deuxième serveur, le temps requis pour déplacer des services plus importants peut être supérieur au temps nécessaire pour réparer le serveur défaillant. "Pourrait" être le mot clé. C'est un problème intéressant. Merci d'avoir répondu! - Boden


Je travaille dans un petit magasin (un service informatique composé d'une seule personne) et je ne remplacerais jamais mes serveurs multiples par un seul serveur, quelles que soient les circonstances. Si l'un des serveurs tombe en panne, j'ai la possibilité d'ajouter les services manquants à une autre machine ou même de les configurer sur un PC de rechange. Nous pouvons vivre avec une panne d'une heure ou deux pour la plupart des choses, mais nous ne pouvons pas vivre avec une panne complète de tous les systèmes. Bien que je puisse remplacer n’importe quel de nos serveurs par un PC, du moins temporairement, je n’ai ni ne peux obtenir facilement quoi que ce soit qui soit assez puissant pour remplacer tout les serveurs à la fois.


1
2018-01-30 08:33





"Bien qu'au début cela semble plus fiable, cela n'augmente-t-il pas simplement le risque de défaillance matérielle?"

  • Du point de vue matériel, je ne vois pas en quoi cela augmente pratiquement les risques d’échec. Il y a beaucoup trop de variables ici, et je n’ai jamais étudié les probabilités, mais je vais trop simplifier: disons que Dell crée un mauvais serveur pour 100 000 unités. Vos chances sont passées de 1 sur 100 000 à 2 sur 100 000 (ou 1 sur 50 000). Donc oui, deux fois plus de chances, mais toujours à cause de l'échelle, les chances ne sont pratiquement pas si différentes.
  • je pense la perspective est la clé ici. "Vous vous préparez pour deux fois plus d'échecs." Peut-être de votre la perspective, mais dans les deux scénarios que vous avez donnés, la messagerie électronique s'exécute sur un serveur et ERP sur un serveur.  Donc, du point de vue du courrier électronique ou de l’ERP (c’est ce qui importe le plus pour l’entreprise), c’est vraiment la même chose. Sauf s'ils se sentent seuls ou aiment leur espace ;-)
  • Je pense que vous devriez aussi regarder ça du point de vue des gens. Je pense qu’il est peut-être plus probable que des erreurs soient commises à cause d’erreurs commises par des personnes. De cette manière, il est probable que quelqu'un ne bousillerait qu’un serveur à la fois. Cela facilite également l'identification des problèmes liés à la charge, par exemple. Si un e-mail et un site Web sont exécutés sur un serveur, prenez plus de temps pour trouver la cause du problème.

Ce n'est jamais aussi simple, de gros serveurs costauds peuvent être mieux ou pire. Ils peuvent avoir des pièces de meilleure qualité, mais peuvent produire plus de chaleur et ne sont pas refroidis correctement. Un serveur costaud a plus de RAM, plus de processeurs, etc. En fin de compte, vous avez peut-être autant de processeurs dans les deux scénarios, de sorte qu'un serveur n'est peut-être pas la bonne unité à prendre en compte.

À cause de la complexité des chances, je pense que tout ce qui est le plus rentable gagne. Si vous devez payer pour des licences, un gros serveur peut coûter moins cher que quelques serveurs plus petits, en fonction de la structure de licence.


0
2018-01-29 20:49



Je pense que cela augmente les risques de défaillance matérielle. La moitié du MTBF, en supposant que les deux serveurs sont identiques et exécutent le même nombre d'heures et charge ... - Scott Lundberg
Scott: Mis à jour pour expliquer un peu plus, je voulais dire pratiquement. De plus, je pense vraiment que c'est une question de perspective. - Kyle Brandt♦
De plus, les serveurs ne sont pas les mêmes ... - Kyle Brandt♦
Cela augmente les risques d'échec. Un RAID0 à deux disques est plus susceptible d'échouer tôt qu'un seul disque. Bien sûr, dans ce cas, vous perdez tout, donc ce n'est pas tout à fait analogue à la situation que je décris: diviser vos services sur deux serveurs au lieu de les exécuter tous sur un seul. Le résultat d'une défaillance unique n'est pas aussi grave, mais j'ai maintenant plus de matériel qui peut échouer. - Boden
Merci pour la mise à jour! Je suis désolé et j'aurais dû mieux qualifier ma question, du moins en termes de "costaud". Je parle ici de choisir entre, par exemple, un HP DL380 avec deux processeurs, une tonne de RAM et 8 disques durs, par opposition à deux DL380 avec un seul processeur, moins de mémoire et de disques durs, moins de mémoire de contrôleur, etc. ( juste un exemple ... mais supposons que la qualité de construction des serveurs "moins costauds" soit la même que celle du serveur "costauds") Oui, cela coûte plus cher pour deux serveurs de cette façon, mais quand cela en vaut-il la peine? - Boden