Architecture sans partage vs architecture avec disques partagés

Evidian SafeKit

Architecture sans partage vs architecture avec disques partagés pour les clusters de haute disponibilité

Aperçu

Cet article étudie les avantages et les inconvénients de l'architecture sans partage par rapport à l'architecture avec disques partagés pour les clusters de haute disponibilité. On s'intéresse aux contraintes matérielles, à l'impact sur l'organisation des données applicatives, au temps de récupération, à la simplicité de mise en œuvre.

Architecture sans partage par rapport à l'architecture avec disques partagés

Les tableaux comparatifs suivants expliquent en détail la différence entre l'architecture avec disques partagés et SafeKit, un produit de clustering logiciel implémentant une architecture sans partage.

Qu'est-ce qu'une architecture avec disques partagés ?

Une architecture avec disques partagés (comme avec le failover cluster de Microsoft) est basée sur 2 serveurs partageant un disque avec un basculement automatique des applications en cas de pannes matérielles ou logicielles.

Cette architecture a des contraintes matérielles : le stockage partagé externe spécifique, les cartes spécifiques à installer à l'intérieur des serveurs, et les commutateurs spécifiques entre les serveurs et le stockage partagé.

Une architecture avec disques partagés a un fort impact sur l'organisation des données applicatives. Toutes les données de l'application doivent être localisées sur le disque partagé pour une reprise après basculement.

De plus, en cas de basculement, la procédure de récupération du système de fichiers doit être exécutée sur le disque partagé. Ceci augmente le temps de récupération (RTO).

Enfin, la solution n'est pas facile à configurer car des compétences sont nécessaires pour configurer le matériel spécifique. Des compétences applicatives sont également requises pour configurer les données de l'application dans le disque partagé.

Qu'est-ce qu'une architecture sans partage ?

Une architecture sans partage (comme avec SafeKit) est basée sur 2 serveurs répliquant les données en temps réel avec un basculement automatique des applications en cas de pannes matérielles ou logicielles.

Il existe deux types de réplication de données : une réplication de fichiers au niveau octet vs une réplication de disque au niveau bloc. Nous considérons ici la réplication de fichiers au niveau octet car elle présente de nombreux avantages par rapport à la réplication de disque au niveau bloc.

L'architecture sans partage n'a aucune contrainte matérielle : les serveurs peuvent être physiques ou virtuels avec n'importe quel type d'organisation disques. La réplication de fichiers en temps réel (synchrone pour avoir 0 perte de données) est effectuée via le réseau standard entre les serveurs.

Cette architecture n'a pas d'impact sur l'organisation des données applicatives. Par exemple, si une application a ses données sur le disque système, la réplication de fichiers en temps réel fonctionne.

Le temps de récupération (RTO) en cas de basculement est réduit au temps de redémarrage de l'application sur les fichiers répliqués du serveur secondaire.

Enfin, la solution est très simple à configurer puisque seuls les chemins des répertoires à répliquer sont configurés.

Avantages et inconvénients d'une architecture sans partage par rapport à une architecture avec disques partagés

Architecture sans partage

Architecture sans partage

Architecture avec disques partagés

Architecture avec disques partagés

Produit

SafeKit sous Windows et Linux

Toolkit de clustering pour disque partagé

Matériel supplémentaire

Non - Utilisez les disques internes des serveurs

Oui - Coût supplémentaire avec une baie de disques partagés

Organisation des données de l'application

0 impact sur l'organisation des données de l'application avec SafeKit.

Il suffit de définir des répertoires à répliquer en temps réel.

Même des répertoires dans le disque système peuvent être répliqués.

Impact sur l'organisation des données de l'application.

Configuration spéciale de l'application pour mettre ses données sur un disque partagé.

Les données dans le disque système ne peuvent pas être récupérées par le serveur de secours.

Complexité du déploiement

Non - installer un logiciel sur 2 serveurs

Oui - nécessite des compétences informatiques spécifiques pour la configuration du système d'exploitation et du disque partagé

Basculement

Redémarrer simplement l'application sur le deuxième serveur

Basculer le disque partagé.

Remonter le système de fichiers.

Passer la procédure de récupération sur le système de fichiers.

Et puis redémarrer l'application

Reprise après sinistre

Il suffit de placer les 2 serveurs sur 2 sites distants connectés par un réseau local étendu.

Coût supplémentaire avec une seconde baie de disques.

Compétences informatiques spécifiques pour configurer la mise en miroir des baies sur un réseau SAN.

Quorum et split brain

Application exécutée sur un serveur unique après une isolation de réseau (split brain).

Cohérence des données après un split brain.

Pas besoin d'une troisième machine, d'un disque de quorum ou d'une voie de heartbeat spéciale pour le split brain.

Plus d'informations sur les heartbeats, le failover et le quorum

Requiert un disque de quorum spécial ou un troisième serveur de quorum pour éviter la corruption des données sur un split brain

Convient pour

Les éditeurs de logiciels qui souhaitent ajouter une option de disponibilité simple pour leur application

Les entreprises possédant des compétences en informatique dans le clustering et avec des applications de bases de données volumineuses

Différentiateurs de la solution de haute disponibilité SafeKit par rapport à la concurrence

Vidéo comparant un cluster avec disques partagés et un cluster sans partage avec 2 sites distants

Contenu de la vidéo

Cette vidéo illustre d'abord le travail à effectuer avec une architecture à disques partagés lorsque les deux serveurs d'un cluster de haute disponibilité doivent être placés sur deux sites distants.

Ensuite, la vidéo montre le même cas d'utilisation avec l'architecture SafeKit sans partage.

SafeKit : une solution idéale pour une application partenaire

Cette solution indépendante de la plateforme est idéale pour un partenaire ayant une application critique et qui souhaite proposer une option de haute disponibilité simple à déployer auprès de nombreux clients.

Elle est également reconnue comme la plus simple à mettre en œuvre par nos partenaires.

Modules SafeKit pour des solutions de haute disponibilité plug&play

SafeKit Modules for Plug&Play High Availability Solutions

Partage de charge réseau et reprise sur panne

Windows farm

Linux farm

Generic farm   > Generic farm   >
Microsoft IIS   > -
NGINX   >
Apache   >
Amazon AWS farm   >
Microsoft Azure farm   >
Google GCP farm   >
Other cloud   >

Architectures de clustering avancée

Plusieurs modules peuvent être déployés dans le même cluster. Ainsi, des architectures de clustering avancées peuvent être mises en œuvre :

Démonstrations de solutions de haute disponibilité avec SafeKit

Webinaire SafeKit

Ce webinaire présente en 2 minutes Evidian SafeKit.

Dans ce webinaire, vous comprendrez les clusters ferme et miroir de SafeKit.

Cluster Microsoft SQL Server

Cette vidéo montre la configuration d'un module miroir avec réplication temps réel synchrone et reprise sur panne.

La réplication de fichiers et le basculement sont configurés pour Microsoft SQL Server mais fonctionnent de la même manière pour d'autres bases de données.

Essai gratuit ici

Cluster Apache

Cette vidéo montre une configuration d'un module ferme avec équilibrage de charge et reprise sur panne.

L'équilibrage de charge et le basculement sont configurés pour Apache mais fonctionnent de la même manière pour d'autres services Web.

Essai gratuit ici

Cluster Hyper-V

Cette vidéo montre un cluster Hyper-V avec des réplications complètes de machines virtuelles.

Les machines virtuelles peuvent s'exécuter sur les deux serveurs Hyper-V et elles sont redémarrées en cas de panne.

Essai gratuit ici

Formation à SafeKit

Introduction

  1. Introduction / pptx

    • Fonctionnalités
    • Architectures
    • Avantages distinctifs
  2. Compétition / pptx

    • Cluster matériel vs logiciel
    • Réplication synchrone vs asynchrone
    • Réplications de fichiers vs disques
    • Haute disponibilité vs tolérance aux fautes
    • Load balancing matériel vs logiciel
    • HA de machines virtuelles vs applications

Installation, configuration, CLI

  1. Installation / pptx

    • Installation du package
    • Configuration des nœuds
    • Configuration du cluster
    • Upgrade
  2. Console web / pptx

    • Configuration du cluster
    • Onglet Configuration
    • Onglet Contrôle
    • Onglet Supervision
    • Onglet Configuration avancée
  3. Ligne de commande / pptx

    • Installation silencieuse
    • Administration du cluster
    • Administration du module
    • Command line interface

Configuration avancée

  1. Module miroir / pptx

    • userconfig.xml + restart scripts
    • Heartbeat (<hearbeat>)
    • Virtual IP address (<vip>)
    • Real-time file replication (<rfs>)
  2. Module ferme / pptx

    • userconfig.xml + restart scripts
    • Farm configuration (<farm>)
    • Virtual IP address (<vip>)
  3. Checkers / pptx

    • Failover machine (<failover>)
    • Process monitoring (<errd>)
    • Network and duplicate IP checkers
    • Custom checker (<custom>)
    • Split brain checker (<splitbrain>)
    • TCP, ping, module checkers

Support

  1. Outils pour le support / pptx

    • Analyse des snaphots
  2. Support Evidian / pptx

    • Récupérer les clés permanentes
    • S'enregistrer sur support.evidian.com
    • Call desk

Documentation

  1. Documentation technique

  2. Documentation d'avant vente