Votre entreprise s’appuie-t-elle sur des services en nuage, des bases de données, des serveurs distants ou des données stockées de quelque sorte que ce soit ?

Bien sûr que oui.

Vous craignez constamment les temps d’arrêt ?

Bien sûr que oui.

Dans notre marché(s) de 24 heures, toujours actif, toujours connecté, quelqu’un est toujours éveillé, le temps de disponibilité est critique. En d’autres termes, le manque de disponibilité est mauvais pour les affaires… et c’est inacceptable. C’est pourquoi les solutions d’ingénierie de haute disponibilité, comme celles proposées par Liquid Web et d’autres sociétés d’hébergement web modernes, sont si importantes. De l’infrastructure de haute disponibilité et des bases de données SQL, à la réplication redondante, aux journaux de transactions et à l’élimination des points uniques de défaillance, un hébergeur web est seulement aussi bon que ses services d’ingénierie de haute disponibilité (HA).

Supposons que votre application sera hébergée sur une infrastructure gérée traditionnelle.

Maintenant, regardons pourquoi un serveur de haute disponibilité est une meilleure solution.

Haute disponibilité résumée

Lorsqu’il s’agit de HA, les trois principes de l’ingénierie de la fiabilité doivent être pris en compte :

  1. Réduire ou éliminer les points uniques de défaillance.
  2. Dans les systèmes redondants, assurez-vous que les points de croisement sont fiables.
  3. Le système en place doit détecter et réagir aux défaillances en temps réel.
Découvrez comment l’infrastructure HA peut aider votre entreprise. Téléchargez notre livre blanc sur les raisons pour lesquelles la haute disponibilité est importante – et comment vous pouvez l’obtenir de manière fiable et abordable.

Lorsque ces trois principes sont mis en œuvre de manière fiable, une réduction significative des temps d’arrêt est obtenue. Un hébergeur de qualité aura ces principes à l’esprit lors de la conception de ses services.

Réduire les points uniques de défaillance dans un système HA signifie la redondance des données – virtuelles, physiques ou une combinaison des deux. Une structure HA aura un volume primaire, et au moins un volume physique de sauvegarde. Une configuration standard est composée de deux volumes primaires identiques sauvegardés par deux volumes physiques DR:BD (Distributed Replicated Block Device) identiques, sauvegardés par deux volumes virtuels DR:BD. Les volumes DR:BD effectuent une réplication sélective et synchrone des données, ce qui signifie que seuls les blocs de données modifiés (et non le volume entier) sont réécrits et sauvegardés en temps réel.

Les volumes DR:BD réduisent finalement les temps de sauvegarde car ils nécessitent moins de ressources informatiques à la fois. Chaque niveau de sauvegarde (deux volumes primaires identiques, deux volumes virtuels DR:BD identiques, etc.) est stocké sur des serveurs physiques distincts – certains hôtes vont même sauvegarder sur un serveur situé à un emplacement distant. Une configuration avec un emplacement distant élimine un autre point de défaillance unique en protégeant vos données des catastrophes naturelles et d’autres problèmes liés à l’emplacement comme les pannes de courant et les défaillances du réseau.

Que faire avec la base de données

Dans un système HA, il est recommandé que votre base de données SQL soit stockée sur un environnement de serveur séparé et redondant car cela améliore les performances et réduit les frais généraux sur votre serveur primaire. Un serveur SQL dédié fonctionne également avec/en accord avec les principes de l’ingénierie de la fiabilité car il est spécifiquement conçu pour la haute disponibilité, y compris les croisements automatisés et fiables et la détection des défaillances en temps réel.

Les bases de données SQL créent également des journaux de transactions incrémentiels ; une autre protection contre les points uniques de défaillance. Les journaux de transactions enregistrent chaque changement dans la base de données à des intervalles définis aussi fréquents qu’une minute – la base de données SQL peut utiliser les journaux de transactions comme un ensemble de données, en écrivant sur les serveurs de sauvegarde dans votre configuration HA.

La configuration standard de Liquid Web pour l’hébergement de bases de données SQL comprend une sauvegarde quotidienne de la base de données entière et 24 heures de roulement des journaux de transactions horaires.

Surveillance pour le basculement

Au cœur même de la configuration HA devrait se trouver un système de surveillance qui garde constamment et systématiquement un œil sur la santé des serveurs en cluster et qui effectue automatiquement les basculements lorsque cela est nécessaire. Le sous-système de surveillance le plus populaire dans l’industrie est Heartbeat. Heartbeat est un moniteur basé sur Linux qui peut prendre en charge plusieurs nœuds de manière fiable. Heartbeat peut identifier rapidement et précisément les défaillances critiques et assurer automatiquement la transition du système vers un serveur redondant.

Comme vous pouvez le constater, chaque partie du système HA fonctionne avec/vers plus d’un des trois principes de l’ingénierie de haute disponibilité. Les nœuds de données redondants (physiques et virtuels) réduisent les points de défaillance uniques et créent des points de croisement fiables.

Un serveur SQL dédié crée une autre couche de redondance, une autre protection contre les points de défaillance uniques, et dispose de points de croisement intégrés et automatisés.

Enfin, Heartbeat se trouve au centre de toute la configuration, surveillant le système en temps réel et automatisant les crossovers lorsque cela est nécessaire.

Avec un système HA de qualité en place, les temps d’arrêt sont réduits ou pratiquement éliminés, ce qui permet à votre entreprise de rester allumée et opérationnelle toute la journée, tous les jours.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.