Haute disponibilité du serveur pour une petite entreprise

Après avoir eu un peu peur avec un serveur qui ne viendrait pas un matin, les hauts responsables ont décidé que l'entreprise avait besoin d'une configuration à haute disponibilité / basculement.

Nous avons 5 serveurs principaux (4x Linux, 1x OpenBSD) qui doivent tous fonctionner pour que l'entreprise fonctionne. Trois des serveurs sont assez standard (Fichiers / Web / Base de données), le quatrième gère la plupart des routages réseau et des proxys Web, tandis que le cinquième prend en charge notre système téléphonique et dispose d'un matériel non standard.

Mon patron a déclaré que le délai de traitement d'une panne de serveur devrait être inférieur à 30 minutes.

Mon expérience dans ce domaine est inexistante (je suis juste un programmeur qui a été «promu»), donc je suppose que ma question se résume vraiment à:

• Est-ce quelque chose qui devrait même être tenté par quelqu'un ayant des compétences moyennes en administration de serveur. Si oui, que dois-je lire et à qui dois-je m'adresser?

Merci.

Je pense que vous devriez commencer par rassembler les chiffres pour décrire le coût associé à la satisfaction de l '"exigence" énoncée pour voir si cela relève même du budget. Si vous n'êtes pas à l'aise avec toutes les méthodes "normales" qui seraient utilisées pour répondre à l'exigence (clustering de basculement, hyperviseurs avec capacité de "migration à chaud", etc.), alors vous feriez probablement bien de trouver un consultant qui peut aider.

Il y aura des coûts associés à l'étude de faisabilité, mais cela coûtera beaucoup moins cher de découvrir qu'une bonne solution ne correspondra pas aux exigences énoncées (ce qui signifie que les attentes doivent être définies de manière plus réaliste par la direction - ou elles besoin de poney plus d'argent) qu'il n'en coûtera pour faire quelque chose à demi-cul qui finit par ne pas remplir du tout l'exigence et faire exploser une tonne d'argent dans le processus.

On dirait que votre patron vient de retirer ce numéro de l'air. Peut-être qu'il a fait une analyse et sait quel est le coût horaire associé aux temps d'arrêt de divers systèmes, mais j'en doute. Cela ressemble à un certain nombre de tarte dans le ciel qui n'est pas lié à la réalité. Je serais ravi si tous vos systèmes ont besoin de ce type de disponibilité. Il se peut, au cours de l'étude de l'entreprise, que vous découvriez que seul un sous-ensemble de fonctionnalités doit avoir un tel degré de disponibilité et de tolérance aux pannes (et, par conséquent, une telle solution coûterait finalement moins cher). Je suis sûr que les téléphones et l'application métier sont là-haut, mais vous pouvez avoir une certaine tolérance pour les temps d'arrêt sur certains des autres systèmes.

Mon instinct dit que vous allez probablement trouver une victoire dans l'utilisation des technologies de virtualisation pour créer un système de basculement basé sur la migration de machines virtuelles entre du matériel redondant. Que cela convienne ou non à votre budget dépendra de votre entreprise, car vous aurez certainement besoin d'un certain type de SAN pour que cela fonctionne efficacement.

Cependant, ne négligez pas le clustering de basculement «traditionnel». Il y a aussi certainement des "gains" si vos applications sont bien adaptées à une telle configuration.

Je me demande si votre patron a pensé à des scénarios de défaillance catastrophiques (brûlures de bâtiments, inondations, tornades, vols, etc.). Si ce n'est pas déjà prévu, ce serait une occasion en or de travailler à la planification générale de la continuité des activités et à la reprise après sinistre.

Obtenez de l'aide de quelqu'un qui peut venir étudier votre entreprise et faire des recommandations. Vous ne le regretterez pas.

"Cette route mène à beaucoup de douleur et de mal ..."

Alors, quel est le plan de continuité de votre entreprise? Vous plan de reprise après sinistre?

Vous en avez discuté? Écrit par écrit? TESTÉ?

Vous devez avoir une conversation appropriée avec les "plus hauts" et vraiment aller au fond des exigences de haute disponibilité car c'est différent pour différents services.

Alors, quel était vraiment le "point douloureux" qu'ils ont ressenti ce matin-là?

Était-ce?

• Les téléphones ont cessé de fonctionner? Problème assez important (et visible). Et oui - cela nécessitera une "solution" mais j'espère que cela fait partie d'un accord de soutien?
• Le site Web a échoué? OK - assez visible mais pas inattendu, et à moins que vous ayez une énorme présence sur le Web, ce n'est pas si important. OK pour arrêter ce serveur pendant quelques heures.
• Serveur de base de données en panne? Effrayant ... J'espère que vous avez obtenu de bonnes sauvegardes! Ne perdez pas les données, sinon l'entreprise échouera. Mais, tant que les données sont sécurisées, c'est un serveur qui est important et devrait avoir un plan de récupération.
• Fichier et impression (et applications internes, etc.). Il s'agit de PITA pour la plupart des gens car ils resteront assis et ne feront rien pendant une matinée pendant que vous le réparez.

Je suppose que vous avez acheté du matériel de haute qualité pour vos principaux systèmes? Bon, parce que faire du bon marché sur le matériel est une fausse économie car ces serveurs sont livrés avec "tout" dans la boîte.

Je suppose également que vous savez COMMENT reconstruire un serveur, échanger des ventilateurs, des blocs d'alimentation, monter un serveur, configurer des réseaux à double chemin en commutateurs redondants? Vous l'avez fait suffisamment de fois pour comprendre ce qui fonctionne et ce qui ne fonctionne pas, ce qui est normal et ce qui est erroné? Si ce n'est pas le cas, obtenez de l'aide et une formation (ou au moins pratique et expérience).

Peut-être qu'une grande partie du problème était FEAR. Ils n'avaient aucune idée qu'un tel problème pouvait se produire (et à quel point les serveurs étaient importants pour leur entreprise) et vous ne saviez pas vraiment ce que vous faisiez (?) Un problème de confiance?

Vous devez obtenir tout ce qui précède AVANT de descendre la route HA très coûteuse. L'entreprise peut-elle se permettre cet équipement coûteux (et la plupart, par définition, ne sera jamais utilisé qu'en cas de panne et souvent jamais utilisé!)

Evan a réussi quelques bons points, mais voici peut-être un moyen rentable spécifique d'obtenir un temps de récupération inférieur à 1 heure en cas d'échecs.

Les petites entreprises signifient probablement un petit matériel, il peut donc ne pas être très coûteux de faire des choses simples qui ajoutent en fait une quantité importante de résilience face aux problèmes. L'idée principale est simplement d'avoir du matériel supplémentaire prêt à l'emploi.

Tout d'abord, familiarisez-vous avec l'idée d'une adresse IP virtuelle. Il s'agit de l'adresse IP à laquelle les utilisateurs parleront, mais elle peut résider sur n'importe quel serveur auquel vous la communiquez. Il s'agit de l'adresse IP que vous utilisez et les applications voudront parler. Et ce sera le plus utile pour ultimement toute solution que vous choisirez. Avoir un VIP signifie que vous ne devriez pas avoir à reconfigurer l'une des applications lors du basculement. Gardez également à l'esprit que le fait d'avoir du matériel redondant a également pour effet d'augmenter les frais d'administration, en effectuant deux mises à jour de configuration au lieu d'une.

Si nous commençons avec votre serveur de routage / proxy Web, c'est probablement le plus simple car leur état réel ne devra pas être stocké sur la boîte elle-même. Il suffit donc d'obtenir un double de la même boîte et de le configurer de la même manière. Je garderais les deux branchés sur le segment LAN, et en supposant que vous êtes sur Internet sur une autre interface, échangez les câbles si leur échec. Du point de vue du routage, vous définissez tous vos clients LAN pour cibler l'adresse .1 (VIP) pour leur route par défaut et le serveur proxy donne au serveur A l'adresse .2 et au serveur B l'adresse .3. De cette façon, ils peuvent tous deux être gérés pour les mises à jour de configuration (s'applique aux deux). Et tout ce que vous avez à faire pour basculer est de supprimer l'affectation IP .1 de .2 et de la déplacer vers .3, et de déplacer la connexion Internet vers l'autre interface. Ce n'est pas très compliqué, facile à faire et à comprendre, et coûte le matériel supplémentaire d'une deuxième boîte. Si vous pouvez obtenir une redondance du côté Internet, vous pouvez ajouter de la complexité et obtenir un basculement automatique en utilisant quelque chose comme VRRP.

Sans détails, c'est difficile à dire, mais votre serveur Web peut être tout aussi simple. Ajoutez un deuxième serveur avec une configuration identique, créez un vIP entre les deux et déplacez le VIP vers la sauvegarde en cas d'échec. Cela ne me dérange généralement pas si l'état de la session est perdu lors d'un basculement (c'est un problème critique de provoquer un basculement). Donc, si les utilisateurs doivent se reconnecter, ce n'est pas grave. Encore une fois, vrrp peut probablement être utilisé pour le basculement automatique.

Passer à votre base de données, c'est beaucoup plus complexe. La plupart des bases de données ont une sorte de modèle principal / secondaire, dans lequel vous sauvegardez la base de données d'origine sur le secondaire, puis copiez tous les journaux de transactions ou les modifications de base de données dans le secondaire. Encore une fois, vous pouvez combiner cela avec des VIP pour les applications / utilisateurs qui accèdent réellement à la base de données. Cependant, le basculement est plus compliqué. En fonction de l'échec du serveur principal, vous devrez peut-être réellement installer les disques pour les copier et les journaux de transactions restants. Amenez ensuite le secondaire actif. Si vous pouvez tolérer certaines données perdues, vous pouvez immédiatement activer le secondaire. Après le basculement, le serveur B est maintenant votre serveur principal, et votre travail consiste à restaurer le serveur A et à le transformer en nouvelle sauvegarde afin qu'il soit prêt à être défaillant lorsque le serveur b finit par rencontrer des problèmes.

Les serveurs de fichiers sont toujours la partie la plus difficile, car contrairement aux bases de données, il est beaucoup plus difficile d'obtenir une fonction intégrée du système de fichiers. Cependant, un certain niveau de résilience peut être atteint en ayant un deuxième serveur, et en écrivant simplement un script qui analyse le système de fichiers pour les modifications, et en copiant tous les nouveaux fichiers sur votre secondaire. Vous pouvez essentiellement exécuter rsync sur un cron que je crois faire. Encore une fois, vous utilisez un VIP que vous donnez aux utilisateurs, que vous déplacez si vous effectuez un basculement. Dans votre script, je vous recommande fortement de vérifier que le système est le propriétaire du VIP avant de transférer des fichiers. Vous ne voulez vraiment vraiment pas que le rsync s'exécute dans la mauvaise direction et écrase toutes les modifications que vous faites. Cela pourrait perdre certains fichiers en cas d'échec,

Je n'ai aucune idée de ce que vous pourriez faire à propos de votre système téléphonique ... cela dépend vraiment du fournisseur et de la configuration. Le fournisseur peut avoir une solution standard pour la résilience.

Quelques derniers mots d'avertissement. Assurez-vous de tester soigneusement toute configuration que vous allez utiliser. Assurez-vous de savoir comment le basculer sans perdre ces informations critiques. Testez test test pour vous assurer qu'il fonctionnera lorsque vous en aurez besoin. Assurez-vous que des processus sont en place pour que les modifications de configuration, les mises à jour logicielles, etc. soient appliquées correctement aux sauvegardes principales et. La bonne nouvelle est que vous pouvez probablement effectuer des basculements contrôlés lorsque vous souhaitez mettre un serveur à niveau, etc. Ce n'est pas une configuration active-active, vous n'avez donc aucune idée si le secondaire fonctionnera lorsque vous en aurez besoin.

Je travaille dans les télécoms et nos équipements sont très redondants, y compris dans la plupart des cas la redondance géographique. Notre point de défaillance numéro 1 est que la redondance n'est pas testée après les modifications et que les utilisateurs apportent des modifications qui ne savent pas comment fonctionne le modèle de redondance. Cependant, nous avons le problème supplémentaire que tous nos équipements doivent prendre en charge le basculement automatique en quelques secondes au maximum. Vous pouvez tolérer une intervention manuelle dans vos basculements si vous n'avez besoin d'être opérationnel qu'en 30 à 60 minutes. Vous avez juste besoin d'être préparé. Bonne chance.

Tous les autres points sont excellents, donc juste quelques commentaires.

30 minutes est impossible à garantir, surtout pour tout. Vous pouvez dire que c'est un objectif, mais il ne peut en aucun cas être une garantie, car il y a toujours le facteur X. Vous pourriez avoir 2 lignes de FAI et un camion s'écraser dans le bâtiment et les retirer tous les deux parce que vous ne pensiez pas que leur acheminement des extrémités opposées du bâtiment était un exemple.

Pour commencer, doublez tout. Vous avez 5 serveurs, vous devez donc doubler. Il n'est pas nécessaire que tout soit sur le matériel, vous pouvez virtualiser, mais vous voyez ce que je veux dire. En plus de cela, tout doit être conscient de la HA, ce qui augmentera également le coût, vous découvrirez peut-être que vous devrez remplacer votre routeur par un nouveau et oh vous en aurez besoin de 2. N'oubliez pas de doubler les alimentations et d'obtenir le générateur, car vous ne pouvez pas garantir que la compagnie d'électricité sera de retour dans les 30 minutes.

Ces exemples pensent que c'est plus ou moins une configuration de secours automatique, ce que je pense que votre patron pense.

Ce que je trouve meilleur pour la petite entreprise, c'est de concevoir un plan pour récupérer et classer tout.

Découvrez quels services sont

critique (arrêt des affaires)

important (les affaires ralentissent)

routine (les entreprises peuvent s'en passer un moment).

Par exemple, vos téléphones de centre d'appels sont essentiels, alors peut-être que l'un vaut la peine d'acheter un deuxième serveur et un deuxième FAI et votre panne de courant moyenne est d'environ 15 minutes, nous allons donc obtenir un onduleur qui durera 60 minutes (ne oubliez pas non plus les postes de travail). Supposons maintenant que l'ERP soit seulement important, ce qui signifie que vous pouvez fonctionner sans lui un peu. Peut-être que les gens de votre centre d'appels l'utilisent, mais s'il est en panne, ils peuvent revenir au stylo et au papier ou au bloc-notes, puis mettre à jour l'ERP. La procédure pour le faire s'il est en panne sera peut-être moins chère que d'essayer d'en faire un service essentiel. Et les routines peuvent être quelque chose comme des imprimantes, ok c'est une douleur mais nous pouvons le faire pendant quelques jours si elles tombent toutes en panne.

Cela vous donne également l'ordre de réparer les trucs si la merde frappe vraiment le fan un jour :)

C'est possible? Sûr. Est-ce abordable? Probablement pas pour une "petite entreprise", surtout si vous avez un patron qui vous donne des chiffres arbitraires pour travailler et qu'il exige une haute disponibilité d'un service informatique composé d'un programmeur adjoint (vu plusieurs fois ailleurs et ce n'est jamais joli pour votre niveau de stress, si votre situation était comme la leur).

Le basculement est possible mais nécessite généralement du matériel redondant, des SAN pour partager les données entre les serveurs, etc ... en d'autres termes, bonne chance pour qu'il soit financé s'il n'engage pas d'administrateur dédié pour s'en occuper.

Votre matériel de système d'appel que vous avez mentionné est du matériel spécialisé, et vous avez fait allusion à être un centre d'appels. Vous devriez parler au fournisseur des options pour rendre cela redondant. Se moquer de cela pourrait annuler le soutien en premier lieu.

D'autres systèmes, vous pourriez très probablement gagner en redondance en investissant dans des solutions de type VMWare (ou Hyper-V ou XenServer, mais je regarderais d'abord VMware et XenServer). Ensuite, vous pouvez envisager d'obtenir un SAN, quelques serveurs costauds avec des commutateurs réseau rapides et utiliser LiveMotion pour migrer des serveurs virtualisés entre des serveurs matériels en cas de panne, ainsi qu'équilibrer une partie de la charge entre les serveurs au fur et à mesure des besoins.

Vous avez mentionné que vous exécutez Linux sur ces systèmes. Avec de l'argent pour obtenir plusieurs serveurs, vous pourriez plutôt envisager de configurer DRBD avec un programme Heartbeat et STONITH pour répliquer les données entre les serveurs et prendre le relais lorsque l'un devient indisponible; vous envisagez de mettre en place un système où vous avez littéralement dupliqué chaque serveur, ainsi que doublé votre consommation d'énergie et la dissipation de chaleur dans la salle des serveurs (si vous avez une salle des serveurs). Cela peut être fait pour le coût du matériel et de votre santé mentale. De plus, vous devriez le tester, vous auriez des temps d'arrêt lors de la configuration et vous avez toujours la possibilité que cela ne fonctionne pas parfois car il y a toujours la possibilité de problèmes qui doivent être résolus (split cerveau, par exemple).

Le dernier est un plan pour faire en sorte que deux systèmes agissent comme des systèmes vierges et avoir un très bon plan de sauvegarde pour vous permettre de restaurer les données sur l'un des systèmes "vierges" si un serveur meurt. Le fait d'avoir du matériel sur place vous donnera quelques options si / quand un serveur meurt; mais vous aurez toujours un certain temps d'arrêt lors de la restauration des données, et vous avez besoin d'instructions sur la façon d'installer correctement vos applications sur le nouveau serveur. Selon la vitesse à laquelle vous travaillez et la taille des données, vous pouvez avoir un temps d'arrêt de quelques heures à un jour ou deux. Vous ne disposez d' un travail, en bon état de sauvegarde pour vos serveurs, avec un plan de redressement en place, oui?

Devriez-vous l'essayer? Ma première réaction est que si vous vous grattez la tête à l'une des suggestions ou si vous sentez un creux dans l'estomac en essayant de penser à ces choses, alors vous ne devriez pas. Vous auriez besoin d'une société de conseil pour examiner le problème et déterminer les coûts et le mettre en œuvre, ou vous devez engager un administrateur système dédié pour le faire pour votre entreprise.

Le fait qu'ils vous disent de le faire et vous dites que vous êtes "juste un programmeur qui a été" promu "et que vous avez un PHB vous disant de donner une redondance avec un temps d'échec maximum de 30 minutes, c'est que vous êtes gentil d'un ruisseau.