Chaque développeur veut son propre stand de développement. Chaque testeur veut son propre banc d'essai. Et chaque spécialiste de la pré-production veut son propre stand - pour enfin tout vérifier et répéter le lancement dans la prod. Lorsque toutes ces listes de souhaits convergent dans le traitement - l'un des systèmes les plus importants et les plus actifs de la banque - les coûts d'infrastructure vous font vous gratter la tête et rechercher des «options». Nous raconterons ce que nous avons trouvé dans ce post.
Le volume de traitement des bases de données dans notre entreprise est d'environ 6 To. Sur une copie des bases de données, les développeurs interfèrent les uns avec les autres, de sorte que l'espace réel occupé par les bases croît rapidement et proportionnellement. Bien qu'à quelle vitesse ... trop rapide pour le service d'escorte et pas assez rapide pour ceux qui ont besoin de copies des bases de données. Et voici pourquoi.
Pour les tests, il est nécessaire que le banc d'essai soit parfaitement cohérent avec la version actuelle de production (il en va de même pour le banc de pré-production). La sauvegarde principale du système est copiée toute la journée, puis déployée sur le stand. Pendant ces longues opérations, les stands ne sont pas disponibles, donc la copie est reportée aux week-ends et jours fériés lorsque personne ne travaille avec des stands. Nous obtenons un délai de 1 à 5 jours. Pour s'entendre au préalable sur le processus de copie lui-même, cela prend également du temps - nous avons plusieurs bancs d'essai, généralement de trois à six. Nous ajoutons 2-3 jours pour coordonner le temps d'inactivité du stand. Avant d'obtenir l'approbation de l'administrateur, l'application est toujours dans la file d'attente. Au total, nous obtenons un très gros retard.
Ce qui a aidé Delphix
Qu'est-ce qui peut accélérer le processus et économiser de l'espace? Virtualisation de la base de données. Nous avons considéré différentes options: Oracle SnapClone, NetApp + Oracle Cloud, uniquement des instantanés sur des tableaux. Tout nécessite une configuration complexe. De plus, les solutions Oracle ne fonctionnent qu'avec des bases de données Oracle.
Ensuite, j'ai regardé Delphix. Il est facile à mettre en œuvre, il prend en charge différentes bases de données - Oracle, SQL Server, DB2, Sybase ASE. Une interface est fournie pour toutes les opérations. Grâce à lui, les développeurs et les testeurs peuvent gérer indépendamment leurs copies - mise à jour, état de sauvegarde / restauration, arrêt / démarrage, etc. Il existe également une API et une CLI pour l'intégration avec les systèmes CI / CD ou leurs processus.
Le déploiement de Delphix lui-même ne prend pas très longtemps - plusieurs heures. La source peut être connectée beaucoup plus longtemps, ici le temps est proportionnel à la taille. Dans notre cas, la source était une copie commerciale de la base de données et sa connexion a pris près d'une journée. La préparation de la source et des serveurs pour les clones de base de données ne nécessite pas de travail particulier. Sur le serveur cible, vous devez installer le ORACLE_HOME approprié et également créer un utilisateur spécial pour se connecter. Pour les copies de test virtuelles, nous utilisons les mêmes serveurs qui possédaient auparavant des copies physiques.
Delphix vous permet de créer des bancs d'essai en temps quasi réel, sans aucune coordination, car les bancs sont complètement isolés les uns des autres. Un certain temps est consacré uniquement à la mise à jour de la base de données à l'état actuel - de 20 minutes à plusieurs heures, il n'est pas question de jours.
Nous essayons d'effectuer des tests de résistance dans des conditions aussi proches que possible du produit. Si la prod sur les disques physiques - alors la charge aussi. Dans ce cas, le bouton Delphix V2P aide, ce qui vous permet de créer une base de données «honnête» à partir d'une base virtuelle.

En ce qui concerne l'économie d'espace disque, les lectures de notre tableau de bord Delphix, bien sûr, sont trompeuses - une réduction de 73 fois du volume est trop fabuleuse. Dans notre traitement, une copie de la vente avec des instantanés quotidiens et des journaux de transactions archivés pendant 2 semaines (200 Go par jour) occupe 4,5 To d'espace disque. Un autre 1,5 To - neuf clones de tailles de 50 à 500 Go, chacun d'entre eux stockant également un historique des instantanés quotidiens. Au total, 6 To sont obtenus.
Nous ajoutons encore 15% d'espace libre (900 Go) pour que Delphix puisse fonctionner normalement. Ainsi, en ne dépensant qu'environ 7 To, nous pouvons obtenir une copie de test avec des données pertinentes à tout moment au cours des deux dernières semaines.
Auparavant, pour stocker neuf copies physiques de la base de données dans 6 To, nous avions besoin de 54 To (ou ~ 20 To en tenant compte de la compression 2-3 fois sur le stockage). Et, contrairement au nouveau système, ici, les développeurs ne pouvaient pas gérer ces copies et restaurer les états précédents - lorsque les données étaient détruites, il n'était possible de recharger qu'à partir d'une copie de la vente.
Delphix vous permet également de créer rapidement différentes branches du même conteneur pour différents projets - et tout cela en un minimum de temps. Les développeurs n'ont pas peur de corrompre les données, ils peuvent revenir en arrière et restaurer leur état précédent. Cela donne un coup de pouce aux performances.
Mais il y a des nuances ...
Les impressions de Delphix sont généralement positives, même si tout n'est pas parfait. Le plus gros problème est l'utilisation de disques. Chaque bloc de données n'est stocké qu'une seule fois pour toutes les copies virtuelles et jusqu'à ce que toutes les copies virtuelles cessent d'utiliser le bloc, il ne peut pas être supprimé. Des problèmes d'organisation peuvent survenir ici - tous les utilisateurs ne sont pas prêts à supporter le court cycle de vie de leurs stands. Si le banc d'essai vit sur une ancienne copie, je la vendrai. Nous résolvons ce problème en profondeur, en étendant les disques, ce qui peut être fait sans interrompre le service. Nous nous assurons que 15% de l'espace libre est toujours économisé. S'il est plus petit, le système cessera simplement d'effectuer toutes les opérations avec des copies virtuelles. Bien que les bases elles-mêmes restent disponibles.
Pour les systèmes avec des E / S disque intensives, la bande passante réseau est susceptible d'être un facteur limitant. Selon le profil de charge spécifique, le système peut commencer à mieux fonctionner avec la virtualisation. En fonction de la charge, la latence de lecture séquentielle moyenne d'un fichier db est de 5 à 10 ms, ce qui est assez bon même pour les systèmes industriels.
Les disques Delphix «classiques» sont connectés de n'importe quelle manière qui prend en charge ESX, et le fournisseur a une liste de recommandations sur la façon de le faire avec des performances maximales. Nous utilisons SAN. Le système lui-même présente les disques sur lesquels se trouvent les fichiers de la base de données virtuelle, uniquement via le protocole NFS. Pour cette raison, vous devez faire attention à la bande passante du canal et à sa congestion. Dans notre cas, il est logique de placer uniquement des fichiers de données pour Delphix sur des baies de disques afin qu'aucune activité dans la banque n'affecte la vitesse d'E / S pour les bases de données virtuelles.
Maintenant, nous travaillons sur Delphix 5.1.9, mais regardez la version 5.2 - l'interface utilisateur a quitté le flash et, selon le fournisseur, est devenue beaucoup plus pratique. Delphix a impressionné nos collègues et, après le traitement, nous envisageons de transférer le profil, le CRM et les services bancaires par Internet à ce système de développeurs.