ECS : Comportement prévisible en cas de panne temporaire du site

Summary: Comportement attendu sur les buckets ADO lorsque le système est en panne de site temporaire (TSO)

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Instructions

Virtual Data Center (VDC)
Panne temporaire de site (TSO)
Access During Outage (ADO)


Qu’est-ce qu’une TSO ?

Perte prolongée du rythme cardiaque pendant 15 minutes
Causes possibles : Les problèmes de réseau, les coupures d’alimentation sur site ou l’intervention manuelle dans certaines situations client ayant un impact si les données ne peuvent pas être lues à partir d’un site VDC spécifique.


Qu’est-ce qu’ADO ?

ADO est une fonctionnalité qui peut être activée au niveau du bucket. Elle permet au bucket d’être disponible lors d’une panne temporaire du site. Une TSO fait passer ECS dans un état cohérent à terme. Les accès pendant les opérations de création/mise à jour/suppression d’objets pendant une panne sont dans un état cohérent à terme.
ECS offre toutefois le choix entre cohérence et disponibilité. Les buckets compatibles ADO sont cohérents à terme, tout en assurant la disponibilité des données. Pour maintenir une forte cohérence, mais au détriment de l’accès lors d’une panne, n’activez pas ADO.


Comportement attendu pour le scénario sur deux sites (soyez particulièrement attentif à la réussite et à l’échec des opérations sur les deux sites)

Organigramme ADO pour le scénario deux sites

Pour vous aider à suivre le schéma ci-dessus :

Avant le TSO
  • Bucket créé sur le site 1 et répliqué sur le site 2
  • Obj 1 créé sur le site 1 et répliqué sur le site 2
  • Obj 2 créé sur le site 2 et répliqué sur le site 1
Une panne réseau se produit 
  • Au bout de 15 minutes, une panne de site temporaire se produit
  • Reportez-vous à la liste des opérations réussies et ayant échoué sur Site 1. Par exemple, dans le site 1 est uniquement en mesure de créer des objets, de lire et de mettre à jour des objets détenus et répliqués, de répertorier les objets dans un bucket et de répertorier les buckets détenus localement. 
  • De même, pour le site 2, voici une liste des opérations réussies et ayant échoué sur le site 2. Comme pour le Site 1, le Site 2 peut créer des objets, lire et mettre à jour des objets détenus et répliqués, répertorier les objets dans un bucket, répertorier les buckets détenus localement.
  • Par conséquent, l’obj 1 peut être mis à jour sur l’un ou l’autre site.
  • Obj 2 peut être mis à jour sur l’un ou l’autre site.
  • Les objets peuvent être créés sur l’un ou l’autre des sites.
Lorsque ADO est activé sur un bucket et lors de la détection d’une panne temporaire, le système revient à un modèle de cohérence éventuel, autrement dit, les lectures/écritures à partir d’un site secondaire (non-propriétaire) sont acceptées et honorées. En outre, une écriture sur un site secondaire lors d’une panne réseau oblige le site secondaire à prendre possession de l’objet. Cela permet à chaque VDC de continuer à lire et à écrire des objets à partir de buckets dans un espace de nommage partagé.


Comportement attendu pour le scénario à trois sites (le Site 1 est perdu ou inaccessible depuis Site2 ou Site3)

Organigramme ADO pour le scénario à trois sites

Dans ce scénario, les connexions au site 1 sont complètement perdues ou le site 1 est inaccessible à partir des sites 2 et 3. Le Site 1 est le propriétaire du compartiment A.

Au bout de 15 minutes, une TSO se produit et la propriété du bucket A est transférée au site 2 et au site 3. Entre ces deux sites, la décision de propriété de l’objet est déterminée, car le propriétaire du bucket d’origine, qui est le Site 1, est inaccessible. 
 
Remarque : La principale différence entre une TSO de deux sites et une TSO de trois sites est que, dans le scénario de trois sites, la création et la mise à jour d’objets ne sont pas autorisées pour le site marqué.


Comportement attendu pour trois sites où un seul site est en panne.

Organigramme ADO pour un scénario à trois sites avec un site en panne

Dans ce scénario, un seul lien est en panne et, par conséquent, la propriété du bucket peut être transférée vers le site 1 et le site 3 ou le site 2 et le site 3. ECS utilise le protocole PAXOS pour déterminer que le Site 2 est en panne et que le Site 1 et le Site 3 sont deux sites valides (dans cet exemple). Le protocole PAXOS est un mécanisme de résolution et de gestion du consensus. Ainsi, dans cet exemple, la propriété de l’objet est déterminée entre le site 1 et le site 3. Comme sur la diapositive précédente, l’accès est limité en fonction du site.

Pour plus d’informations sur le comportement attendu au cours d’une TSO, reportez-vous au Guide d’administration. Voici le lien vers le Guide d’administration d’ECS 3.8.

Affected Products

ECS
Article Properties
Article Number: 000224833
Article Type: How To
Last Modified: 22 Jan 2025
Version:  1
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.