- Avons-nous une photo pour janvier, plus proche de février?
- Voyons maintenant ... Oui, il y en a! Maintenant ouvert.Il arrive qu'il y ait une durée de vie moyenne de la base de test, il y ait une durée de vie pour les instantanés convenus par tous ceux qui sont intéressés, mais certains des environnements «persistent» trop longtemps dans leur image, qui ne peuvent pas être supprimés ... et ensuite cela s'avère utile pour les collègues. Et moins à moins donne un plus.
Habituellement, pour tous les systèmes dans lesquels quelque chose peut se produire, vous devez créer des sauvegardes. Et s'il est toujours en cours de développement et en cours de finalisation, il est également nécessaire de déployer quelque part des environnements de développement et de test. De plus, pour les sauvegardes et les environnements de test qui fonctionnent, en fait, avec les mêmes données, vous avez besoin de beaucoup d'espace. Et pourtant, ces environnements doivent en quelque sorte conduire à l'état actuel. Et tout cela nécessite du matériel et des ressources en temps.
Dans notre cas, ces exigences étaient couvertes par les serveurs Oracle ZFS Storage Appliance et Oracle / Sun, qui ont en fait fusionné dans le même écosystème qu'Exadata, qui est apparu peu de temps avant eux.
Puisqu'il existe un commutateur InfiniBand à l'intérieur d'Exadata, à travers lequel ses composants communiquent, et que ZFS Storage est également un appareil Oracle, alors:
- tout d'abord, il était connecté directement à ce commutateur par une partie de ses ports;
- deuxièmement, il peut stocker des fichiers d'espace de table avec des segments compressés dans la compression hybride colonnaire Exadata (EHCC), ce qui nous permet d'économiser beaucoup d'espace dans le système principal. Si vous essayez de restaurer la base de données sur un serveur distinct, après la récupération, en vous référant aux données compressées, vous obtiendrez l'erreur: "ORA-64307: la compression en colonnes hybride n'est pas prise en charge pour les espaces disque logiques sur ce type de stockage" - car les fichiers de données compressé dans l'EHCC doit être stocké dans Oracle Appliance;
- troisièmement, cela ouvre la possibilité d'utiliser des capacités ZFS pour stocker des fichiers d'environnement de test.
Et l'endroit? La duplication doit être évitée.
Les environnements de test ont besoin des mêmes données que dans les sauvegardes. Ces données peuvent-elles remplir les deux fonctions? Pour être à la fois une sauvegarde et une base pour tout environnement de test privilégié qui a besoin d'un ensemble de données complet? Ils peuvent!
Oracle ZFS Storage Appliance est un tableau qui offre, entre autres, la possibilité de former des partages réseau fonctionnant sous le système de fichiers ZFS. Dans le système de fichiers ZFS, il est possible de créer des instantanés, sur la base desquels vous pouvez déployer des clones, qui sont visibles en tant que nouveaux partages réseau. Nous utilisons cette opportunité comme suit:
- Sur le stockage ZFS (comme nous appellerons le tableau, afin de ne pas être confondu avec le système de fichiers), deux partages sont créés - Archivelog est ajouté à l'un et les fichiers de base de données à l'autre;
- Le partage est monté sur le serveur Oracle / Sun (qui est également une appliance) et sur le serveur lui-même, une instance d'Oracle Database se lève, agissant comme une réserve physique en cascade - il reçoit les journaux d'un site réservé sous condition et applique les modifications aux fichiers du partage;
- L'utilisation des logs est organisée selon le principe de l'unité de travail (bonjour à tous les participants à l'informatique distribuée!). Au niveau de l'algorithme, le concept d'unité de travail est introduit, ce qui correspond à un certain intervalle de temps. Après avoir roulé les journaux pour l'intervalle requis, l'instance s'arrête et les fichiers restent dans le partage dans un état cohérent les uns par rapport aux autres et au fichier de contrôle. En fait, c'est une sauvegarde à froid, c'est aussi une copie d'image, au dessus de laquelle un instantané est réalisé;
- Lorsque vient le temps de recréer l'environnement de test, un clone est créé à partir de l'instantané souhaité. Il est monté sur le serveur sur lequel l'environnement s'exécute, après quoi les fichiers qu'il contient s'ouvrent en tant que base de données sous un nom différent et en mode lecture / écriture;
- Dans le processus de travail dans la base de test, des modifications sont apportées qui sont reportées dans le cadre du clone, et elle augmente lentement. À la fin du cycle de vie, le milieu pousse au maximum.
- Pour réduire la consommation d'espace disque, nous utilisons la compression LZJB, que ZFS Storage effectue à la volée.
En résumé:
- Dans la configuration actuelle, les environnements de test peuvent effectuer des E / S jusqu'au niveau de 3,75 Gb / s;
Le maximum pour la lecture est limité par les paramètres de port InfiniBand existants sur le serveur, le maximum pour l'écriture est CPU sur les contrôleurs de stockage ZFS et atteint environ 2 Gb / s. (Oui, oui! Comme 10 GbE ne suffisaient pas, des commutateurs séparés ont été achetés pour les serveurs de test, qui comprenaient ZFS Storage et les serveurs eux-mêmes); - Plusieurs instantanés sont créés par jour, qui sont désormais stockés, selon la base, de 2 semaines à 2 mois. Après quoi, ils sont tous supprimés, à l'exception des instantanés créés à 00h00, le 1er de chaque mois - ils sont stockés pendant plus d'un quart. Dans certains cas, des instantanés stockés pendant environ six mois se sont révélés utiles;
- Si nécessaire, l'intégralité de la base de données industrielle peut être restaurée à partir de l'instantané souhaité. Également avec une vitesse de l'ordre de 1 ... 3 Gb / s, mais l'option de créer un clone à partir de l'instantané souhaité est beaucoup plus populaire, à partir de laquelle les données des tables souhaitées sont ensuite déchargées;
- Le temps de recréation de l'environnement de test est d'environ 1 heure (avec le transfert d'un certain nombre de circuits supplémentaires, etc.);
- Le temps pour fournir à vos collègues un clone à partir duquel vous pouvez collecter des données pour la récupération ou tout simplement une sorte d'analyse est de 15 minutes (avec une combinaison idéale de conditions) à 1-2 heures (avec une charge parallèle importante sur ZFS Storage ou us J);
- Si nécessaire, vous pouvez restaurer à partir de l'instantané et du clone, et de la base de données entière;
- Une contrainte de performances majeure est le nombre d'E / S par seconde générées par des environnements de test ou des instances de secours en cascade. Et ici, le système se comporte de manière absolument adéquate et prévisible - dès que leur nombre est sélectionné à 75 IOPS par disque dur (il contient des disques de 3,5 pouces à 7200 tr / min) sous une charge prolongée, le système commence à s'affaisser progressivement. Et petit dans le temps - Write- et Read-Flash sont nettement plus faciles;
- Le nombre d'IOPS, la quantité totale de données entrantes, la charge sur le processeur, le nombre de lectures à partir de caches en RAM et sur Flash, ainsi que plusieurs dizaines (sinon des centaines) de métriques peuvent être consultés dans l'interface de gestion Web;
- Vous pouvez travailler avec des objets de stockage ZFS à l'aide des demandes REST décrites dans la documentation. Avec leur aide, il a été possible d'automatiser la suppression des instantanés obsolètes, mais beaucoup plus peut être fait!