Le déploiement multi-zones de Lindorm répartit les réplicas sur plusieurs zones pour assurer la reprise après sinistre au niveau du centre de données ou de la ville, avec une cohérence forte ou à terme par table. Le basculement est automatique.
Fonctionnalités
Pour les charges de travail nécessitant une résilience face aux pannes de serveur, aux coupures réseau ou aux sinistres à l'échelle d'une ville, le déploiement multi-zones offre :
Une reprise après sinistre au niveau du centre de données ou de la ville.
La prise en charge de la cohérence des données forte et à terme.
La détection automatique des pannes et le basculement sans intervention manuelle.
Limites
Les clients open source, tels que le client HBase, ne prennent pas en charge le déploiement multi-zones.
Le déploiement multi-zones s'applique uniquement à LindormTable. Les fonctionnalités de LindormTable telles que les index secondaires, les colonnes dynamiques et les colonnes génériques sont prises en charge. En revanche, les fonctionnalités dépendantes du moteur, comme les index de recherche et les index columnaires, ne le sont pas.
Le stockage froid et la séparation des données chaudes et froides ne sont pas pris en charge.
Fonctionnement du déploiement multi-zones
Dans un déploiement multi-zones, chaque partition de table large possède un réplica indépendant dans chaque zone. Lindorm synchronise les réplicas via son protocole de consensus, qui requiert des données provenant d'au moins deux réplicas. Les entrées du journal des transactions anticipées (WAL) sont stockées dans LindormDFS dans la zone C. Si la zone A tombe en panne, le WAL de la zone C permet de restaurer les données dans la zone B.
Lindorm prend en charge deux niveaux de cohérence : forte et à terme. Configurez chaque table selon vos besoins.
Cohérence forte
Avec la cohérence forte, toutes les lectures et écritures passent par la partition primaire. Les partitions secondaires reçoivent les données via le protocole de consensus. Les lectures retournent toujours les données les plus récemment écrites.
Si tous les serveurs de la zone primaire sont arrêtés ou si la zone devient indisponible, Lindorm promeut automatiquement une zone secondaire. Une courte période de transition est nécessaire.
Cohérence à terme
La cohérence à terme autorise les lectures et les écritures sur les partitions primaires et secondaires. La synchronisation des données entre les zones est asynchrone et s'effectue généralement en moins de 100 ms.
Les clients lisent et écrivent dans la zone la plus proche. Si les clients de lecture et d'écriture se trouvent dans la même zone, ils voient toujours les dernières données. Lorsqu'une zone devient indisponible, Lindorm achemine les requêtes vers une zone disponible sans attendre la promotion, ce qui réduit les pics de latence.
Choix du niveau de cohérence approprié
Les nouvelles tables utilisent par défaut la cohérence à terme, qui convient à la plupart des charges de travail :
Les données écrites au cours des 100 dernières millisecondes peuvent généralement être lues.
Les clients peuvent lire et écrire depuis la zone la plus proche.
Les partitions locales restent disponibles lors de perturbations transitoires ou d'arrêts de serveur.
Optez pour la cohérence forte si vous avez besoin :
D'une cohérence immédiate après écriture (read-after-write).
D'opérations atomiques telles que Increment et CheckAndPut.
D'index secondaires sur la table.
Remarque En mode de cohérence forte, toutes les lectures passent par la partition primaire et ne peuvent pas être distribuées sur les réplicas. Si la zone primaire tombe en panne, la promotion d'une zone secondaire prend du temps.
Comparaison des architectures
Reprise après sinistre traditionnelle primaire/secondaire
Dans la reprise après sinistre traditionnelle primaire/secondaire, deux instances sont déployées dans des zones distinctes. Lindorm Tunnel Service (LTS) synchronise les données de manière bidirectionnelle. En cas de panne de l'instance primaire ou de la zone, vous devez basculer manuellement vers l'instance secondaire.
Cette approche présente plusieurs inconvénients :
Absence de cohérence forte des données. La synchronisation entre instances est asynchrone. Lors du basculement, l'instance secondaire peut ne pas disposer des dernières données. Les opérations atomiques telles que Increment et CheckAndPut peuvent produire des résultats désordonnés ou annulés. Les problèmes réseau dans la zone primaire laissent l'instance secondaire incomplète jusqu'à la récupération.
Faible utilisation des ressources. L'instance secondaire reste inactive, sauf pendant le basculement.
Basculement manuel requis. Vous devez surveiller l'instance primaire et implémenter votre propre logique de basculement.
Le déploiement multi-zones résout ces problèmes.
Comparaison des fonctionnalités
Le tableau suivant compare le déploiement multi-zones, la reprise après sinistre primaire/secondaire et les protocoles basés sur Paxos/Raft.
| Fonctionnalité | Déploiement haute disponibilité multi-zones | Reprise après sinistre primaire/secondaire | Protocole de consensus basé sur Paxos ou Raft | |
|---|---|---|---|---|
| Cohérence forte | Cohérence à terme | |||
| Perte de données (RPO) | 0 | < 100 ms | < 1s | 0 |
| Récupération du service (RTO) | 1 minute | 10s à 30s | Dépend du temps de basculement | 30 secondes à 3 minutes |
| Temps de réponse d'accès | Accès aux données dans la zone primaire. Les lectures et écritures peuvent traverser les zones. | Accès aux données dans la zone la plus proche. Les lectures et écritures concernent plusieurs zones, réduisant les pics de latence. | Accès aux données dans la zone primaire. Les lectures et écritures peuvent traverser les zones. | Accès aux données dans la zone primaire. Les lectures et écritures peuvent traverser les zones. |
| Facilité d'utilisation | Aucun impact sur les applications métier. | Aucun impact sur les applications métier. | Nécessite des modifications applicatives. Utilise un lien de synchronisation externe que vous gérez. | Aucun impact sur les applications métier. |
| Nombre minimal de zones pour les journaux | 3 | 2 | 2 | 3 |
| Nombre minimal de zones pour les données | 2 | 2 | 2 | 3 |
Par rapport aux alternatives, le déploiement multi-zones offre un accès aux données plus flexible, un temps de récupération plus court et une facilité d'utilisation accrue.
Remarque Lindorm gère automatiquement la détection des pannes et le basculement pour toutes les tables larges, quel que soit le niveau de cohérence. Connectez-vous à une seule instance ; aucun middleware n'est nécessaire. Si votre charge de travail ne nécessite pas de cohérence forte, utilisez la cohérence à terme pour une latence plus faible. Si votre charge de travail exige une cohérence forte, définissez le niveau de cohérence de la table sur fort.
Achat d'une instance Lindorm multi-zones
Pour acheter une instance multi-zones, créez une instance dans la console Lindorm.
Utilisation d'une instance Lindorm multi-zones
Création d'une table et configuration du niveau de cohérence
Remarque L'API HBase et HBase Shell ne garantissent pas la cohérence des données. Les tables créées via l'API HBase ou HBase Shell utilisent par défaut la cohérence à terme. Modifiez l'attribut CONSISTENCY comme décrit ci-dessous.
Connectez-vous à LindormTable avec Lindorm-cli. Utilisez Lindorm-cli pour vous connecter à LindormTable et l'utiliser.
-
Configurez l'attribut CONSISTENCY pour la table.
Créez une table avec une cohérence forte : ``
CREATE TABLE dt ( p1 INT, p2 INT, c1 VARCHAR, c2 BIGINT, PRIMARY KEY(p1) ) WITH (CONSISTENCY='strong');``Créez une table avec une cohérence à terme : ``
CREATE TABLE dt2 ( p1 INT, p2 INT, c1 VARCHAR, c2 BIGINT, PRIMARY KEY(p1) ) WITH (CONSISTENCY='eventual');``Passez une table en cohérence à terme : ``
ALTER TABLE dt SET CONSISTENCY='eventual';``Passez une table en cohérence forte : ``
ALTER TABLE dt2 SET CONSISTENCY='strong';``
Écriture de données dans une table large
L'écriture de données dans une instance multi-zones fonctionne de la même manière que dans une instance mono-zone. Utilisez Lindorm-cli pour vous connecter à LindormTable et l'utiliser.
Importation de données dans une table large
Pour importer des données via une API, utilisez l'endpoint de l'instance depuis la console Lindorm. Le processus est identique pour les instances multi-zones.
Avec BulkLoad, importez une copie des données dans chaque zone. Contactez le support technique pour obtenir de l'aide.