Pour continuer notre série sur l’intégration des Objects Stores dans Nutanix Database Service (NDB), voici un nouvel article pour plonger dans les entrailles de la sélection des Objects Stores, et les différentes étapes de l’utilisation par NDB.
1. Object Store : sélection
Ici, il n’est pas mentionné l’intégration d’un Object Store existant ou la création de ce dernier via NDB, car c’est documenté de manière officielle ici et ici.
L’objectif est surtout de décrire le processus de sélection de l’Object Store au déploiement d’une database.
Un point important à saisir, c’est que lorsqu’au moins un object store est présent, NDB utilisera tout le temps par défaut ce type de stockage pour les opérations de log-catchup de Time Machine.
Partons du principe que les Object Store sont déja enregistrés.
Dans un exemple comme celui ci, avec deux objects stores, la sélection du primaire se fera en fonction du temps de réponse. Le premier Object Store qui répondra lors de la demande de création de la database et de sa Time Machine associée, sera celui utilisé comme primaire.
Dans des environnements NDB en haute disponibilité, avec des composants répartit sur différents clusters, hébergeant eux mêmes des objects stores OU dans des infrastructures où peu de différences de latences existent entre les clusters / object stores, la sélection peut s’avérer aléatoires vis a vis de l’affinité désirée.
Lorsqu’une affinité est désirée entre la database et un object store particulier, il est possible d’outre passer cette sélection automatique et de forcer l’utilisation d’un object store en particulier. J’avais pu développer ce type d’opération dans l’article suivant.
2. Créations des éléments
Lorsque une database est déployée, utilisant un object store, plusieurs éléments sont créés.
Voici un rapide aperçu de ces différentes entités propre à l’utilisation de l’Object Store par NDB.
Un couple d’utilisateur et de clé pour l’authentification
Pour accéder à l’object store, NDB va créer avec son utilisateur (par le biais de celui renseigné à l’enregistrement de Prism Central), un couple utilisateur/secret pour réaliser ses opérations sur le bucket avec une authentification dédiée et placer les droits sur les buckets en questions.
Un bucket dédié
Lors d’une opération de création de database et lors de la configuration de la partie TimeMachine, un bucket va être créé si non existant et alloué aux opérations de TimeMachine pour la database en question.
Cette opération est clairement visible dans le suivi des tâches de déploiements.
Des fichiers propre à chaque opération
A l’intérieur du bucket, chaque opération de logcatchup va créer un répertoire spécifique dans lequel seront stockés les fichiers collectés par le Time Machine (ici .trn pour du MS SQL).
