Questions sur le point de défaillance unique pour les petites opérations

1. Si vous ne pouvez pas vous permettre ou n'avez pas besoin d'un cluster ou d'un serveur de rechange en attente de mise en ligne en cas de panne, il semble que vous pourriez diviser les services fournis par un serveur costaud en deux serveurs moins costauds. Ainsi, si le serveur A tombe en panne, les clients peuvent perdre l'accès à, par exemple le courrier électronique, et si le serveur B tombe en panne, ils peuvent perdre l'accès au système ERP .

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

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

2. Souvent, un SAN est recommandé afin que vous puissiez utiliser le clustering ou la migration pour maintenir les services en place. Mais qu'en est-il du SAN lui-même? Si je devais mettre de l'argent là où une panne va se produire, cela ne sera pas sur le matériel du serveur de base, ça va avoir quelque chose à voir avec le stockage. Si vous n'avez pas 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 d'investir dans des serveurs avec des composants redondants et des disques locaux. Je peux voir un avantage dans des opérations plus importantes où le prix et la flexibilité d'un SAN sont rentables. Mais pour les petits magasins, je ne vois pas l'argument, du moins pas pour la tolérance aux pannes.

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

Je travaille dans un petit endroit, donc je comprends cette lutte et le geek informatique en moi ne veut aucun point de défaillance unique, 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. Cependant, cela ne signifie pas toujours supprimer le point de défaillance unique.

Network Edge : Nous avons 2 connexions Internet T1 et Comcast Business. Prévoyez de déplacer notre pare-feu sur une paire d'anciens ordinateurs exécutant pfSense à l'aide de CARP pour HA.

Réseau : obtenir quelques commutateurs gérés pour le cœur du réseau et utiliser la liaison pour diviser les serveurs critiques entre les deux commutateurs empêche une panne de commutateur de supprimer l'intégralité du placard de données.

Serveurs : tous les serveurs sont dotés de RAID et d'alimentations 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 a quelques gros 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 permute les rôles pour être le serveur de fichiers principal en cas de panne.

Serveur de sauvegarde hors site : Similaire à la sauvegarde sur site, nous effectuons des sauvegardes nocturnes sur un serveur via un tunnel VPN vers l'un des propriétaires.

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

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

Il est très difficile de couvrir toutes les bases, mais les 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 tant pour la sauvegarde quotidienne que comme outil de récupération. Nous pouvons restaurer sur un matériel différent, si disponible, 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 poste de travail et booster. Pas parfait mais il peut être opérationnel rapidement.

Concernant les SAN: Presque tout ce que vous utilisez sera redondant. Même s'il s'agit d'un boîtier unique, il y aura à l'intérieur des alimentations doubles, des connecteurs doubles et des «têtes» doubles, chacune avec des liens vers tous les disques. Même quelque chose d'aussi simple qu'un MD3000 vendu par Dell possède toutes ces fonctionnalités. Les SAN sont conçus pour être au cœur de vos boîtiers, ils sont donc conçus pour survivre à presque 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 ... "Combien la société acceptera-t-elle les temps d'arrêt". Si la perte de votre serveur de messagerie pendant un jour ou deux n'est pas un gros problème, vous ne devriez probablement pas vous embêter avec deux d'entre eux. Mais si une panne de serveur Web commence à vous faire perdre de l'argent réel à chaque minute, alors vous devriez peut-être passer le temps à en faire un cluster approprié.

Plus vous avez de serveurs, plus vous risquez de casser quelque chose, c'est une façon de voir les choses. Un autre est que si l'on casse, vous êtes à 100%, comme vous le dites.

La panne matérielle la plus courante est les HD, comme vous le disiez ci-dessus. Indépendamment de la façon dont vous souhaitez répartir les opérations, vous devez effectuer un stockage RAID de votre stockage.

Je voterais pour quelques serveurs (RAIDed bien sûr) au lieu d'un énorme, à la fois pour la stabilité des opérations et les performances. Moins de logiciels se heurtant à chaque demande de ressources, encombrement réduit, plus de disques à lire / écrire, etc.

J'opterais personnellement pour plusieurs serveurs. Je ne pense pas qu'une panne d'équipement soit plus probable dans ce scénario. Oui, vous avez plus d'équipement qui pourrait tomber en panne, mais les chances de défaillance d'une unité donnée devraient être constantes.

Ce que le fait d'avoir plusieurs serveurs dans une configuration non redondante / non HA me donne 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 moindre. 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.

Je travaille dans une petite boutique (service informatique un homme) et je n'échangerais pas mes multiples serveurs contre un seul en aucune circonstance. 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 l'un de nos serveurs par un PC, au moins temporairement, je n'ai pas, ou je peux facilement me procurer, quoi que ce soit de suffisamment puissant pour remplacer tous les serveurs à la fois.

Votre post d'origine émet l'hypothèse que vous ne pouvez pas vous permettre un cluster, mais vous envisagez des solutions avec deux serveurs (sans les sauvegardes). Cela impliquerait que vous avez probablement trois serveurs en main, suffisamment pour démarrer un cluster.

Il existe des solutions intermédiaires qui peuvent éviter SPoF tout en étant adaptées aux petites et moyennes entreprises: réplication de nœud à nœud sans stockage SAN.

Ceci est pris en charge par exemple par Proxmox (mais je pense qu'il est également pris en charge par XCP-ng / XenServer et probablement par ESXi).

Considérons une configuration à 3 nœuds. Le tout avec RAID, bloc d'alimentation redondant, réseau redondant.

• Les nœuds A et B ont un processeur costaud et beaucoup de RAM.
• Le nœud C est plus modeste en CPU / RAM mais dispose de beaucoup de stockage et est utilisé pour fournir le quorum au chien de garde à haute disponibilité et aux sauvegardes d'hôte.

Ensuite, deux options:

1. Toutes les machines virtuelles s'exécutent normalement sur le nœud A et sont répliquées sur le nœud B (nécessitant des unités de processeur décentes)
2. Les machines virtuelles sont réparties entre les nœuds A et B, et répliquées mutuellement certaines du nœud A au nœud B et du nœud B au nœud A.

Ce type de configuration peut tolérer une défaillance du réseau, une défaillance totale et majeure du nœud (l'un des trois), avec un temps d'arrêt d'environ 1 minute (environ le temps nécessaire au démarrage d'une machine virtuelle). L'inconvénient est la perte de données depuis la dernière réplication (qui, en fonction de vos paramètres et des performances matérielles, peut être aussi faible que 1 minute et aussi élevée que quelques heures).

Avec la 2e option (VM normalement répartie entre les nœuds A et B), vous devez prioriser les VM autorisées à revenir en ligne. Étant donné que la charge de votre machine virtuelle est généralement répartie entre deux serveurs, le fait de les exécuter tous sur un seul nœud peut épuiser la RAM du nœud ou encombrer le processeur.

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

• D'un point de vue matériel, je ne vois pas comment cela augmente pratiquement les risques d'échec. Il y a beaucoup de variables ici, et je n'ai jamais étudié la probabilité, mais pour simplifier à outrance: disons que Dell fait 1 mauvais serveur pour 100 000. Vos chances sont passées de 1 sur 100 000 à 2 sur 100 000 (ou 1 sur 50 000). Alors oui, deux fois plus de chances, mais toujours en raison de l'échelle, les chances ne sont pratiquement pas si différentes.
• Je pense que la perspective est la clé ici. "Vous vous préparez pour deux fois plus d'échecs." Peut-être de votre point de vue, mais dans les deux scénarios que vous avez donnés, le courrier électronique s'exécute sur un serveur et l'ERP s'exécute sur un serveur. Donc, du point de vue du courrier électronique ou de l'ERP (ce qui importe à l'entreprise), c'est vraiment la même chose. À moins qu'ils ne se sentent seuls ou qu'ils aiment leur espace ;-)
• Je pense que vous devriez également le considérer du point de vue des gens. Je pense que l'échec dû aux erreurs des gens est peut-être plus probable, et de cette façon, quelqu'un ne visserait probablement qu'un serveur à la fois. Cela facilite également l'identification des problèmes avec des choses comme la charge. Si le courrier électronique et un site Web fonctionnent sur un serveur, vous disposez de plus de temps pour découvrir où se situe le problème.

Ce n'est jamais aussi simple, de gros serveurs costauds peuvent être mieux ou moins bien faits. 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 CPU, etc., donc à la fin vous avez peut-être autant de CPU dans les deux scénarios, donc peut-être qu'un serveur n'est pas la bonne unité à laquelle penser.

En raison de la complexité des chances, je pense que ce qui est le plus rentable gagne. Si vous devez payer pour des licences, un gros serveur peut être moins cher que quelques serveurs plus petits, selon la structure des licences.

Mon approche par défaut est d'éviter toute infrastructure centralisée. Par exemple, cela signifie pas de SAN , pas d'équilibreur de charge . Vous pouvez également appeler une telle approche centralisée "monolithique".

En tant qu'architecte logiciel, je travaille avec l'infrastructure du client. Cela peut signifier utiliser leur propre centre de données privé ou utiliser quelque chose comme AWS. Donc, je n'ai généralement pas de contrôle sur l'utilisation ou non d'un SAN. Mais mon logiciel couvre généralement plusieurs clients, donc je le construis comme s'il serait exécuté sur des machines individuelles isolément sur un réseau.

L'exemple d'email

Le courrier électronique est bizarre, car c'est un système hérité (qui fonctionne). Si le courrier électronique était inventé aujourd'hui, il utiliserait probablement des API RESTFul sur les serveurs Web, et les données seraient dans une base de données qui pourrait être répliquée à l'aide d'outils normaux (réplication transactionnelle, sauvegardes incrémentielles).

La solution d'architecture logicielle est qu'une application Web se connecterait à l'un d'une liste de nœuds disponibles (au hasard), et si ce n'est pas disponible, elle essaiera de se connecter à un autre nœud (au hasard). Un client peut se faire virer d'un serveur s'il est trop occupé. Ici, il n'est pas nécessaire qu'un équilibreur de charge se connecte à une batterie de serveurs Web; et, il n'y a pas besoin d'un SAN pour une haute disponibilité. Il est également possible de partager la base de données par département ou par zone géographique.

Marchandise signifie ...

Ainsi, au lieu d'avoir un ou deux serveurs coûteux et un SAN avec des mesures de redondance interne, vous pouvez utiliser plusieurs machines à faible coût et à faible consommation.

• Simplicité - la redondance provient uniquement du nombre d'appareils. Vous pouvez facilement vérifier votre redondance par le nombre de machines. Et vous estimez plus correctement qu'ils ont un risque d'échec plus élevé et préparez-vous à cela.

• Pourcentage de redondance - Si vous avez 2 serveurs, si l'un tombe en panne, il vous en reste 1 (50%). Si vous avez 10 serveurs de base et un échoue, il vous en reste 9 (90%)

• Inventaire - un appareil de base est facilement disponible dans tous les magasins à proximité à un prix avantageux.

• Compatibilité - avec les canaux Fibre Channel et toutes sortes de normes pour les formats de volume de disque, les appareils de base et l'architecture logicielle signifie que vous n'êtes pas enfermé dans un modèle ou une marque d'appareil unique.

• Performance - Avec 2 appareils sur SAN, ils doivent être dans la même pièce. Avec l'approche par machine standard, si vous avez 5 bureaux, vous pouvez en avoir 2 dans chaque bureau, avec une redondance VPN WAN entre les bureaux. Cela signifie que le logiciel et les communications se trouvent sur le LAN à un temps d'accès <1 ms.

• Sécurité - en s'appuyant sur le haut niveau de redondance, vous pouvez facilement reconstruire des nœuds en tant que processus normal de base. Vous souhaitez reconstruire un cluster monolithique à 2 serveurs? Sortez le manuel. En reconstruisant souvent les machines (avec automatisation), vous maintenez les logiciels à jour et empêchez tout pirate ou virus de prendre pied sur votre réseau.

Remarque: vous devrez toujours disposer de plusieurs commutateurs et de redondances de routeur de passerelle