Comment compacter le stockage des sauvegardes dans le stockage objet jusqu'à 90 %

Nos clients turcs nous ont demandé de configurer correctement la sauvegarde de leur centre de données. Nous menons des projets similaires en Russie, mais ici, il s’agissait plutôt de rechercher la meilleure façon de le réaliser.

Étant donné : il existe un stockage S3 local, il existe Veritas NetBackup, qui a acquis une nouvelle fonctionnalité étendue pour déplacer les données vers le stockage objet, désormais avec prise en charge de la déduplication, et il existe un problème d'espace libre dans ce stockage local.

Tâche : tout faire pour que le processus de stockage des copies de sauvegarde soit rapide et bon marché.

En fait, avant cela, tout dans S3 n'était que des fichiers, et il s'agissait de moulages complets des machines critiques du centre de données. Autrement dit, ce n’est pas très optimisé, mais tout a fonctionné au début. Il est maintenant temps de le comprendre et de le faire correctement.

L'image montre ce à quoi nous sommes arrivés :

Comment compacter le stockage des sauvegardes dans le stockage objet jusqu'à 90 %

Comme vous pouvez le constater, la première sauvegarde a été effectuée lentement (70 Mb/s) et les sauvegardes suivantes des mêmes systèmes ont été beaucoup plus rapides.

En fait, plus loin, vous trouverez un peu plus de détails sur les fonctionnalités disponibles.

Journaux de sauvegarde pour ceux qui sont prêts à lire une demi-page de dumpComplet avec nouvelle analyse
18 décembre 2018 12:09:43 — L'accélérateur d'informations bpbkar (pid=4452) a envoyé 14883996160 octets sur 14883994624 octets au serveur, optimisation 0.0 %
18 décembre 2018 12:10:07 - Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport = Statistiques PDDO (flux multithread utilisé) pour (NBCC) : analysé : 14570817 1760761 0 Ko, CR envoyé : 87.9 XNUMX Ko, CR envoyé sur FC : XNUMX Ko, déduplication : XNUMX %, cache désactivé

Full
18 décembre 2018 12:13:18 — L'accélérateur d'informations bpbkar (pid=2864) a envoyé 181675008 octets sur 14884060160 octets au serveur, optimisation 98.8 %
18 décembre 2018 12:13:40 - Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport = Statistiques PDDO pour (NBCC) : analysé : 14569706 45145 0 Ko, CR envoyé : 99.7 XNUMX Ko, CR envoyé via FC : XNUMX Ko, déduplication : XNUMX %, cache désactivé

Incrémental
18 décembre 2018 12:15:32 — L'accélérateur d'informations bpbkar (pid=792) a envoyé 9970688 octets sur 14726108160 octets au serveur, optimisation 99.9 %
18 décembre 2018 12:15:53 - Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport = Statistiques PDDO pour (NBCC) : analysé : 14383788 15700 0 Ko, CR envoyé : 99.9 XNUMX Ko, CR envoyé via FC : XNUMX Ko, déduplication : XNUMX %, cache désactivé

Full
18 décembre 2018 12:18:02 — L'accélérateur d'informations bpbkar (pid=3496) a envoyé 171746816 octets sur 14884093952 octets au serveur, optimisation 98.8 %
18 décembre 2018 12:18:24 - Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport = Statistiques PDDO pour (NBCC) : analysé : 14569739 34120 0 Ko, CR envoyé : 99.8 XNUMX Ko, CR envoyé via FC : XNUMX Ko, déduplication : XNUMX %, cache désactivé

Quel est le problème

Les clients souhaitent effectuer des sauvegardes aussi souvent que possible et les stocker au moindre coût possible. Il est préférable de les stocker à moindre coût dans des stockages d'objets tels que S3, car ils sont les moins chers en termes de coût de service par mégaoctet, à partir desquels vous pouvez restaurer une sauvegarde dans un délai raisonnable. Lorsqu'il y a beaucoup de sauvegarde, cela devient coûteux, car la majeure partie du stockage est occupée par des copies des mêmes données. Dans le cas du HaaS de collègues turcs, le stockage peut être densifié d'environ 80 à 90 %. Il est clair que cela concerne spécifiquement leurs spécificités, mais je compterais certainement sur au moins 50 % de grand-père.

Pour résoudre le problème, les principaux fournisseurs ont depuis longtemps créé des passerelles vers Amazon S3. Toutes leurs méthodes sont compatibles avec le S3 local tant qu'elles prennent en charge l'API Amazon. Dans le centre de données turc, une sauvegarde est effectuée sur notre S3, ainsi que sur le « Compresseur » T-III en Russie, car ce schéma de travail a bien fonctionné pour nous.

Et notre S3 est entièrement compatible avec les méthodes de sauvegarde Amazon S3. Autrement dit, tous les outils de sauvegarde prenant en charge ces méthodes vous permettent de tout copier sur un tel stockage « prêt à l'emploi ».

Veritas NetBackup a ajouté la fonctionnalité CloudCatalyst :

Comment compacter le stockage des sauvegardes dans le stockage objet jusqu'à 90 %

Autrement dit, entre les machines à sauvegarder et la passerelle, il existe un serveur Linux intermédiaire par lequel passe le trafic de sauvegarde des agents SRK et est dédupliqué à la volée avant de le transférer vers S3. Si auparavant il y avait 30 sauvegardes de 20 Go avec compression, désormais (en raison de la similitude des machines) leur volume est devenu 90 % plus petit. Le moteur de déduplication est utilisé de la même manière que lors du stockage sur des disques standards à l'aide de Netbackup.

Voici ce qui se passe avant le serveur intermédiaire :

Comment compacter le stockage des sauvegardes dans le stockage objet jusqu'à 90 %

Nous avons testé et sommes arrivés à la conclusion que, une fois mis en œuvre dans nos centres de données, cela permet à nous et à nos clients d'économiser de l'espace dans le stockage S3. En tant que propriétaire de centres de données commerciaux, nous facturons bien sûr en fonction du volume occupé, mais cela reste également très rentable pour nous - car nous commençons à gagner de l'argent sur des emplacements plus évolutifs dans les logiciels, et non sur la location de matériel. Eh bien, et c'est une réduction des coûts internes.

Les journaux228 tâches (0 En file d'attente 0 Actif 0 En attente de nouvelle tentative 0 Suspendu 0 Incomplet 228 Terminé — 13 sélectionnés)
(Filtre appliqué [13])

Type d'ID de tâche État Détails de l'état Statut Politique de la tâche Planification de la tâche Heure de début du serveur de médias client Heure écoulée Heure de fin Unité de stockage Tentative d'opération Kilo-octets Nom de chemin des fichiers % terminé (estimé) PID de la tâche Propriétaire Copie ID de la tâche parent Ko/s Démarrage actif Session de profil Robot Vault écoulée active Support d'identification pour éjecter le mouvement des données Type hors hôte Priorité principale Taux de déduplication Accélérateur de transport Optimisation Instance ou hôte de partage de base de données
— 1358 Snapshot Done 0 VMware — NGNCloudADC NBCC 18 décembre 2018 12:16:19 00:02:18 18 décembre 2018 12:18:37 STU_DP_S3_****sauvegarde 1 100 % racine 1358 18 décembre 2018 12 :16:27 PM 00:02:10 Disque de récupération instantanée standard WIN-*********** 0
1360 Sauvegarde effectuée 0 VMware Full NGNCloudADC NBCC 18 décembre 2018 12:16:48 00:01:39 18 décembre 2018 12:18:27 STU_DP_S3_****sauvegarde 1 14,535,248 149654 100 23858 1358 % 335,098 racine 18 2018, 12 16 décembre , 48 00:01:39 0:99.8:99 Disque de récupération instantanée Standard WIN-*********** XNUMX XNUMX % XNUMX %
1352 Snapshot Done 0 VMware - NGNCloudADC NBCC 18 décembre 2018 12:14:04 00:02:01 18 décembre 2018 12:16:05 STU_DP_S3_****sauvegarde 1 100 % racine 1352 18 décembre 2018 12 : 14:14 00:01:51 Disque de récupération instantanée standard WIN-*********** 0
1354 Sauvegarde effectuée 0 VMware Incrémentale NGNCloudADC NBCC 18 décembre 2018 12:14:34 00:01:21 18 décembre 2018 12:15:55 STU_DP_S3_****sauvegarde 1 14,380,965 147 100 23617 1352 % 500,817 racine 18 2018 12 décembre 14 , 34 00:01:21 0:99.9:100 Disque de récupération instantanée Standard WIN-*********** XNUMX XNUMX % XNUMX %
1347 Snapshot Done 0 VMware - NGNCloudADC NBCC 18 décembre 2018 12:11:45 00:02:08 18 décembre 2018 12:13:53 STU_DP_S3_****sauvegarde 1 100 % racine 1347 18 décembre 2018 12 : 11:45 00:02:08 Disque de récupération instantanée standard WIN-*********** 0
1349 Sauvegarde effectuée 0 VMware Full NGNCloudADC NBCC 18 décembre 2018 12:12:02 00:01:41 18 décembre 2018 12:13:43 STU_DP_S3_****sauvegarde 1 14,535,215 149653 100 23508 1347 % 316,319 racine 18 2018, 12 12 décembre , 02 00:01:41 0:99.7:99 Disque de récupération instantanée Standard WIN-*********** XNUMX XNUMX % XNUMX %
1341 Snapshot Done 0 VMware - NGNCloudADC NBCC 18 décembre 2018 12:05:28 00:04:53 18 décembre 2018 12:10:21 STU_DP_S3_****sauvegarde 1 100 % racine 1341 18 décembre 2018 12 : 05:28 00:04:53 Disque de récupération instantanée standard WIN-*********** 0
1342 Sauvegarde effectuée 0 VMware Full_Rescan NGNCloudADC NBCC 18 décembre 2018 12:05:47 00:04:24 18 décembre 2018 12:10:11 STU_DP_S3_****sauvegarde 1 14,535,151 149653 100 22999 1341 % 70,380 racine 18 2018 12 05 décembre 47 , 00 04:24:0 87.9:0:XNUMX Disque de récupération instantanée Standard WIN-*********** XNUMX XNUMX % XNUMX %

1339 Instantané terminé 150 VMware - NGNCloudADC NBCC 18 décembre 2018 11:05:46 00:00:53 18 décembre 2018 11:06:39 STU_DP_S3_****sauvegarde 1 100 % racine 1339 18 décembre 2018 11 : 05:46 00:00:53 Disque de récupération instantanée standard WIN-*********** 0
1327 Instantané terminé 0 VMware - *******.*********.cloud NBCC 17 décembre 2018 12:54:42 05:51:38 17 décembre 2018 6:46:20 STU_DP_S3_****sauvegarde 1 100 % racine 1327 17 décembre 2018 12:54:42 05:51:38 Disque de récupération instantanée Standard WIN-*********** 0
1328 Sauvegarde effectuée 0 VMware Complète *******.*******.cloud NBCC 17 décembre 2018 12:55:10 05:29:21 17 décembre 2018 6:24:31 STU_DP_S3_****sauvegarde 1 222,602,719 258932 100 12856 1327 % 11,326 racine 17 2018 12 55 décembre 10 05:29:21 0:87.9:0 Disque de récupération instantanée Standard WIN-*********** XNUMX XNUMX % XNUMX%
1136 Instantané terminé 0 VMware - *******.*********.cloud NBCC 14 décembre 2018 4:48:22 04:05:16 14 décembre 2018 8:53:38 STU_DP_S3_****sauvegarde 1 100 % racine 1136 14 décembre 2018 4:48:22 04:05:16 Disque de récupération instantanée Standard WIN-*********** 0
1140 Sauvegarde effectuée 0 VMware Full_Scan *******.*******.cloud NBCC 14 décembre 2018 4:49:14 03:49:58 14 décembre 2018 8:39:12 STU_DP_S3_****sauvegarde 1 217,631,332 255465 100 26438 1136 % 15,963 racine 14 2018 4 49 décembre 14 03:49:58 0:45.2:0 Disque de récupération instantanée standard WIN-*********** XNUMX XNUMX % XNUMX%

L'accélérateur permet de réduire le trafic des agents, car Seules les modifications de données sont transmises, c'est-à-dire que même les sauvegardes complètes ne sont pas entièrement téléchargées, puisque le serveur multimédia collecte les sauvegardes complètes ultérieures à partir des sauvegardes incrémentielles.

Le serveur intermédiaire dispose de son propre stockage, où il écrit un « cache » de données et gère une base de données pour la déduplication.

L'architecture complète ressemble à ceci :

  1. Le serveur maître gère la configuration, les mises à jour, etc. et est situé dans le cloud.
  2. Le serveur multimédia (machine intermédiaire *nix) doit être situé le plus près des systèmes redondants en termes d'accessibilité au réseau. Ici, la déduplication des sauvegardes de toutes les machines réservées est effectuée.
  3. Sur les machines sauvegardées, il existe des agents qui envoient généralement au serveur multimédia uniquement ce qui n'est pas dans son stockage.

Tout commence par une analyse complète - il s'agit d'une sauvegarde complète à part entière. À ce stade, le serveur multimédia prend tout, le duplique et le transfère vers S3. La vitesse vers le serveur multimédia est faible, mais elle est plus élevée à partir de celui-ci. La principale limitation est la puissance de calcul du serveur.

Les sauvegardes suivantes sont complètes du point de vue de tous les systèmes, mais en réalité elles ressemblent à des sauvegardes complètes synthétiques. Autrement dit, le transfert et l'enregistrement réels vers le serveur multimédia se produisent uniquement pour les blocs de données qui n'ont pas encore été rencontrés dans les sauvegardes de VM auparavant. Et seuls les blocs de données dont le hachage ne figure pas dans la base de données de déduplication du serveur multimédia sont transférés et enregistrés dans S3. En termes plus simples, c’est quelque chose qui n’a jamais été vu auparavant dans une sauvegarde d’une seule VM.

Lors de la restauration, le serveur multimédia demande à S3 les objets dédupliqués nécessaires, les réhydrate et les transfère aux agents IRB, c'est-à-dire il est nécessaire de prendre en compte le volume de trafic lors de la restauration, qui sera égal au volume réel de données en cours de restauration.

Voici à quoi il ressemble:

Comment compacter le stockage des sauvegardes dans le stockage objet jusqu'à 90 %

Et voici un autre morceau de journaux169 tâches (0 En file d'attente 0 Actif 0 En attente de nouvelle tentative 0 Suspendu 0 Incomplet 169 Terminé — 1 sélectionnés)

Type d'ID de tâche État Détails de l'état Statut Politique de la tâche Planification de la tâche Heure de début du serveur de médias client Heure écoulée Heure de fin Unité de stockage Tentative d'opération Kilo-octets Nom de chemin des fichiers % terminé (estimé) PID de la tâche Propriétaire Copie ID de la tâche parent Ko/s Démarrage actif Session de profil Robot Vault écoulée active Support d'identification pour éjecter le mouvement des données Type hors hôte Priorité principale Taux de déduplication Accélérateur de transport Optimisation Instance ou hôte de partage de base de données
- 1372 Restauration effectuée 0 NBPR01 NBCC 19 décembre 2018 1:05:58 00:04:32 19 décembre 2018 1:10:30 1 14,380,577 1 100 % 8548 RACINE 1372 70,567 19 décembre 2018 1:06 :00 PM 00:04:30 GAGNER-********** 90000

L'intégrité des données est assurée par la protection du S3 lui-même - il y a une bonne redondance pour se protéger contre les pannes matérielles telles qu'une broche de disque dur morte.

Le serveur multimédia a besoin de 4 To de cache : il s'agit de la taille minimale recommandée par Veritas. Plus c'est mieux, mais c'est ce que nous avons fait.

Total

Lorsqu'un partenaire a ajouté 3 Go dans notre S20, nous avons stocké 60 Go, car nous proposons une triple géoréservation des données. Il y a désormais beaucoup moins de trafic, ce qui est bon à la fois pour le canal et pour les tarifs de stockage.

Dans ce cas, les routes sont fermées au-delà du « grand Internet », mais vous pouvez diriger le trafic via VPN L2 sur Internet, mais il est préférable d'installer le serveur multimédia avant l'entrée du fournisseur.

Si vous souhaitez en savoir plus sur ces fonctionnalités dans nos centres de données russes ou si vous avez des questions sur la mise en œuvre à la maison, posez-les dans les commentaires ou par e-mail. [email protected].

Source: habr.com

Ajouter un commentaire