Pour un projet, j'ai la tâche de planifier une configuration à haute disponibilité pour une boutique en ligne et un système CMS. Cependant, bien sûr, le projet est sur un budget serré. Donc, une solution haut de gamme pourrait ne pas être dans le budget.
Il y aura deux machines exécutant le serveur Web (CMS, boutique), une machine exécutant la base de données et une machine pour exécuter un serveur de télécopie nécessaire pour livrer les commandes aux partenaires. Tous les systèmes fonctionnent sous Linux. Tous ces composants doivent être hautement disponibles et doivent prendre en charge le basculement transparent.
Pour réduire les coûts matériels, je pense à un environnement virtualisé. Il y a beaucoup d'informations là-bas, mais je ne sais pas exactement où commencer. Il semble évident qu'au moins des serveurs sont nécessaires en tant qu'hôte pour les machines virtuelles, de sorte qu'il n'y a pas de point de défaillance unique.
Quelle est la meilleure façon de prendre en charge la haute disponibilité?
La première question est de savoir quelle solution de virtualisation est la meilleure dans cette situation. Il doit y avoir une sorte d'interface de gestion. Il doit exister un moyen de déplacer une machine virtuelle en cours d'exécution d'un hôte à un autre afin de pouvoir effectuer la maintenance de l'hôte. Il doit y avoir une sorte de mécanisme, afin que les machines virtuelles soient toujours disponibles en cas de défaillance d'un hôte. Pourriez-vous nous conseiller ici sur une solution valable?
Un stockage de fichiers partagé semble être une condition préalable à une haute disponibilité dans la plupart des cas (attendez-vous à VMware vSphere qui est plutôt cher). Cependant, il serait préférable de mettre plus d'argent dans les hôtes de la machine virtuelle que d'ajouter deux autres serveurs à la configuration pour fournir un magasin de fichiers NFS redondant. Est-il possible de s'entendre uniquement avec les deux hôtes de machine virtuelle? Une solution pourrait être deux utiliser ces deux comme hôtes NFS également. Y a-t-il une grande pénalité de performance pour ce faire?
EDIT: Je vise une disponibilité à 99,9%. Cependant, aucune disponibilité 24h / 24 et 7j / 7 n'est requise car il y a des heures d'ouverture régulières, ce qui donne un peu d'espace de manœuvre. La période de disponibilité qui doit être garantie d'une manière ou d'une autre se situe entre 10h et minuit.
Réponses:
De manière générale, pour atteindre la haute disponibilité, vous avez besoin de:
Le numéro 1 est aussi simple qu'il y paraît - achetez deux serveurs identiques.
Le numéro 2 peut être atteint par un SAN de réplication (coûteux, très rapide, très fiable) ou un système de fichiers répliqué sur chacun des serveurs (bon marché, la vitesse et la fiabilité peuvent dépendre de votre connaissance de la technologie choisie).
Le numéro 3 peut être atteint par un SAN (un LUN de stockage, accessible par deux serveurs), ou un système de fichiers répliqué (deux zones de stockage séparées, chaque serveur ne peut voir que le sien).
Le numéro 4 peut être atteint par une application de battement de coeur.
Pour ce faire avec un petit budget, disons VMWare vSphere, vous pouvez utiliser un SAN ou VMWare propose désormais une appliance de stockage à réplication automatique qui propose deux magasins de données distincts sur deux serveurs pouvant être utilisés pour une haute disponibilité. vSphere propose également des pulsations intégrées et des configurations à haute disponibilité.
Pour ce faire sans budget, vous pouvez suivre le chemin Xen et utiliser DRBD pour répliquer le stockage entre les deux nœuds. Ensuite, vous configurez Heartbeat pour basculer le nœud de stockage DRBD actif et l'instance Xen pour démarrer les machines virtuelles sur le 2e hôte lorsque le premier tombe en panne.
Vous n'obtiendrez pas de disponibilité de 5-neuf (99,999%) en utilisant ces recommandations de base, mais vous pourriez facilement obtenir 3-neuf (99,9%) en utilisant les méthodes les moins chères si vous savez ce que vous faites.
la source
Vous parlez de «dépenses» en termes de «combien d'argent cela coûtera-t-il pour acheter» lorsque vous discutez du stockage partagé. C'est un point tout à fait valable bien sûr, l'argent est serré partout .
Mais si vous parlez de haute disponibilité, vous devez également vous demander " pourquoi voulons-nous une haute disponibilité?" et si la réponse est, par exemple, "parce que l'entreprise génère plus de 2000 $ par heure de ventes en ligne, donc si nous sommes partis pendant une heure, nous avons perdu 2000 $", alors la question des dépenses et de l'abordabilité peut devenir "Pouvons-nous avez- vous les moyens de ne pas acheter quelque chose qui permet ou améliore considérablement notre déploiement de haute disponibilité? "
C'est un détail important et cela joue avec votre commentaire sur le budget - la «queue» informatique ne doit pas remuer le «chien» de l'entreprise en insistant sur une solution trop complexe et coûteuse à un petit problème, mais en même temps si l'entreprise a certaines exigences de son infrastructure informatique, il doit alors être prêt à les budgétiser correctement ou à ajuster ses exigences.
Je pense que la virtualisation a beaucoup de potentiel pour améliorer la disponibilité des systèmes, mais ce n'est pas une baguette magique. Le côté matériel des choses, bien qu'important, est très secondaire par rapport aux exigences logicielles - il est inutile d'avoir un cluster de base de données SQL qui tombe sans problème en cas de panne de l'un des serveurs SQL si l'application frontale qui parle à la base de données s'étouffe car il ne peut pas gérer le basculement.
Et deux serveurs "hautement disponibles" assis côte à côte dans un centre de données sont toujours vulnérables aux pannes de courant, au vol, etc. Encore une fois, selon la réponse à " pourquoi faisons-nous cela?", Vous devrez peut-être considérer cet aspect assez soigneusement car cela peut ajouter des dépenses et de la complexité à plusieurs parties de votre projet.
la source
...no good having a SQL database cluster that falls over with no trouble in the event of one of the SQL servers crashing if the front-end application that talks to the database chokes because it can't handle the failover.- Je ne saurais trop insister sur ce point. Nous avions un client qui nous avait fait implémenter un cluster HA SQL Server sur un grand SAN et à la fin de la journée, leur logiciel devait être redémarré en cas de basculement car il ne pouvait pas gérer une interruption des communications. C'était un exercice coûteux qui était inutile quand un miroir SQL et un NLB auraient suffi.Sans savoir quelle base de données et quel serveur d'applications vous utilisez, je recommanderais:
HA-Exemples:
Si vous effectuez une HA sur la couche application, cette couche sait mieux comment répliquer des sessions. Si un nœud tombe en panne (planifié ou non), le nœud survivant prendra le relais, y compris les sessions.
la source
Pourquoi voulez-vous acheter vos propres hôtes? Pourquoi ne trouvez-vous pas un fournisseur Enterprise Cloud / IaaS comme BlueLock ou Terremark qui fournira l'infrastructure dont vous avez besoin. Ils fourniront des services comme vSphere HA (plus comme des temps d'arrêt réduits que le service HA mais c'est une solution rentable), pare-feu, déchargeur LTM / SSL, SAN (avec des étagères redondantes), surveillance / alerte, etc. Notez que nous ne sommes pas parler de solutions cloud grand public ici alors soyez prêt à payer pour la valeur.
la source
Vous pouvez envisager une solution de réplication tout-en-un virtualisée / de stockage.
Le système de fichiers ZFS rend cela possible, comme indiqué dans cet article de blog .
Une autre option serait de suivre le tutoriel détaillant une solution avec Red Hat KVM .
la source