Comment compresser le stockage des sauvegardes dans le stockage d'objets jusqu'à 90%

Nos clients turcs nous ont demandé de bien configurer la sauvegarde pour le data center. Nous réalisons des projets similaires en Russie, mais ici, l’histoire portait surtout sur l’exploration des meilleures solutions à adopter.

Donné : il y a un stockage S3 local, un Veritas NetBackup qui a acquis de nouvelles fonctionnalités avancées pour le transfert de données vers des stockages d'objets, désormais avec prise en charge de la déduplication, et un problème d'espace libre dans ce stockage local.

Objectif : rendre le processus de stockage des sauvegardes rapide et peu coûteux.

En fait, auparavant, tout était stocké dans S3 sous forme de fichiers, et il s'agissait de copies complètes des machines critiques du data center. Ce n’était pas très optimisé, mais cela fonctionnait au départ. Maintenant, il est temps de faire le point et de faire les choses correctement.

Voici l'image de ce à quoi nous sommes arrivés :

Comme on peut le voir, la première sauvegarde a été effectuée lentement (70 Mo/s), tandis que les sauvegardes suivantes des mêmes systèmes étaient significativement plus rapides.

Voici plus de détails sur les spécificités rencontrées.

Journaux des sauvegardes pour ceux qui sont prêts à lire une demi-page de dumpsComplet avec rescanner
18 déc. 2018 12:09:43 PM — Info bpbkar (pid=4452) l’accélérateur a envoyé 14883996160 octets sur 14883994624 octets au serveur, optimisation 0.0%
18 déc. 2018 12:10:07 PM — Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=Statistiques PDDO (flux multi-thread utilisé) pour (NBCC) : analysé : 14570817 Ko, CR envoyé : 1760761 Ko, CR envoyé sur FC : 0 Ko, dédup : 87.9 %, cache désactivé

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

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

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

Quel est le problème

Les clients souhaitent effectuer des sauvegardes aussi souvent que possible et les stocker aussi peu cher que possible. Le stockage peu coûteux se fait mieux dans des systèmes de stockage d'objets comme S3, car ils offrent le meilleur rapport coût par mégaoctet pour récupérer les sauvegardes dans des délais raisonnables. Lorsqu'il y a beaucoup de sauvegardes, cela devient moins économique, car la plupart de l'espace de stockage est occupé par des copies des mêmes données. Dans le cas de HaaS, les collègues turcs peuvent compresser le stockage d'environ 80 à 90 %. Il est évident que cela concerne leur spécificité, mais je m'attendrais à un minimum de 50 % de dé-duplication.

Pour résoudre ce problème, les principaux fournisseurs ont depuis longtemps créé des passerelles vers S3 d'Amazon. Tous leurs méthodes sont compatibles avec les S3 locaux, si ceux-ci prennent en charge l'API d'Amazon. Dans le datacenter turc, la sauvegarde est réalisée dans notre S3, tout comme dans T-III « Compresseur » en Russie, car ce schéma de travail a bien fonctionné chez nous.

Notre S3 est entièrement compatible avec les méthodes de sauvegarde sur Amazon S3. Cela signifie que tous les outils de sauvegarde qui prennent en charge ces méthodes permettent de copier tout dans un stockage similaire « en standard ».

Veritas NetBackup a intégré une fonctionnalité CloudCatalyst :

Cela signifie qu'entre les machines à sauvegarder et la passerelle se trouve un serveur Linux intermédiaire, à travers lequel passe le trafic de sauvegarde des agents CRK et dans lequel la dé-duplication se fait « à la volée » avant de les transmettre à S3. Auparavant, il y avait 30 sauvegardes de 20 Go avec compression, mais maintenant (en raison de la similarité des machines), leur volume a diminué de 90 %. Le moteur de dé-duplication utilisé est le même que celui utilisé lors du stockage sur des disques ordinaires avec NetBackup.

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

Nous avons testé et conclu que la mise en œuvre dans nos datacenters permet d'économiser de l'espace dans les S3 pour nous et pour nos clients. En tant que propriétaire de datacenters commerciaux, nous facturons bien sûr en fonction du volume occupé, mais cela reste très avantageux pour nous aussi — car nous commençons à gagner sur des espaces plus évolutifs dans le logiciel, et non sur la location de matériel. De plus, cela réduit les coûts internes.

Journaux228 Jobs (0 En attente 0 Actif 0 En attente de réessai 0 Suspendu 0 Incomplet 228 Terminé — 13 sélectionnés)
(Filtre appliqué [13])

Identifiant de travail Type État Détails de l'état Statut Politique de travail Calendrier de travail Client Média Serveur Heure de début Temps écoulé Heure de fin Unité de stockage Tentative Opération Kilooctets Fichiers Nom du chemin % Complète (Estimé) PID du travail Propriétaire Copier ID du travail parent KB/Sec Actif Début Actif Écoulé Robot Profil du coffre-fort ID de session Média à éjecter Mouvement de données Hors hôte Type Principal Priorité Taux de dédupliquation Accélérateur de transport Optimisation Instance ou base de données Partager hôte
— 1358 Instantané Terminé 0 VMware — NGNCloudADC NBCC 18 décembre 2018 12:16:19 PM 00:02:18 18 décembre 2018 12:18:37 PM STU_DP_S3_****backup 1 100% root 1358 18 décembre 2018 12:16:27 PM 00:02:10 Récupération instantanée Disque Standard WIN-*********** 0
1360 Sauvegarde Terminé 0 VMware Complet NGNCloudADC NBCC 18 décembre 2018 12:16:48 PM 00:01:39 18 décembre 2018 12:18:27 PM STU_DP_S3_****backup 1 14,535,248 149654 100% 23858 root 1358 335,098 18 décembre 2018 12:16:48 PM 00:01:39 Récupération instantanée Disque Standard WIN-*********** 0 99,8% 99%
1352 Instantané Terminé 0 VMware — NGNCloudADC NBCC 18 décembre 2018 12:14:04 PM 00:02:01 18 décembre 2018 12:16:05 PM STU_DP_S3_****backup 1 100% root 1352 18 décembre 2018 12:14:14 PM 00:01:51 Récupération instantanée Disque Standard WIN-*********** 0
1354 Sauvegarde Terminé 0 VMware Incrémental NGNCloudADC NBCC 18 décembre 2018 12:14:34 PM 00:01:21 18 décembre 2018 12:15:55 PM STU_DP_S3_****backup 1 14,380,965 147 100% 23617 root 1352 500,817 18 décembre 2018 12:14:34 PM 00:01:21 Récupération instantanée Disque Standard WIN-*********** 0 99,9% 100%
1347 Instantané Terminé 0 VMware — NGNCloudADC NBCC 18 décembre 2018 12:11:45 PM 00:02:08 18 décembre 2018 12:13:53 PM STU_DP_S3_****backup 1 100% root 1347 18 décembre 2018 12:11:45 PM 00:02:08 Récupération instantanée Disque Standard WIN-*********** 0
1349 Sauvegarde Terminé 0 VMware Complet NGNCloudADC NBCC 18 décembre 2018 12:12:02 PM 00:01:41 18 décembre 2018 12:13:43 PM STU_DP_S3_****backup 1 14,535,215 149653 100% 23508 root 1347 316,319 18 décembre 2018 12:12:02 PM 00:01:41 Récupération instantanée Disque Standard WIN-*********** 0 99,7% 99%
1341 Instantané Terminé 0 VMware — NGNCloudADC NBCC 18 décembre 2018 12:05:28 PM 00:04:53 18 décembre 2018 12:10:21 PM STU_DP_S3_****backup 1 100% root 1341 18 décembre 2018 12:05:28 PM 00:04:53 Récupération instantanée Disque Standard WIN-*********** 0
1342 Sauvegarde Terminé 0 VMware Analyse_Complete NGNCloudADC NBCC 18 décembre 2018 12:05:47 PM 00:04:24 18 décembre 2018 12:10:11 PM STU_DP_S3_****backup 1 14,535,151 149653 100% 22999 root 1341 70,380 18 décembre 2018 12:05:47 PM 00:04:24 Récupération instantanée Disque Standard WIN-*********** 0 87,9% 0%

1339 Instantané Terminé 150 VMware — NGNCloudADC NBCC 18 décembre 2018 11:05:46 AM 00:00:53 18 décembre 2018 11:06:39 AM STU_DP_S3_****backup 1 100% root 1339 18 décembre 2018 11:05:46 AM 00:00:53 Récupération instantanée Disque Standard WIN-*********** 0
1327 Instantané Terminé 0 VMware — *******.********.cloud NBCC 17 décembre 2018 12:54:42 PM 05:51:38 17 décembre 2018 6:46:20 PM STU_DP_S3_****backup 1 100% root 1327 17 décembre 2018 12:54:42 PM 05:51:38 Récupération instantanée Disque Standard WIN-*********** 0
1328 Sauvegarde Terminé 0 VMware Complet *******.********.cloud NBCC 17 décembre 2018 12:55:10 PM 05:29:21 17 décembre 2018 6:24:31 PM STU_DP_S3_****backup 1 222,602,719 258932 100% 12856 root 1327 11,326 17 décembre 2018 12:55:10 PM 05:29:21 Récupération instantanée Disque Standard WIN-*********** 0 87,9% 0%
1136 Instantané Terminé 0 VMware — *******.********.cloud NBCC 14 décembre 2018 4:48:22 PM 04:05:16 14 décembre 2018 8:53:38 PM STU_DP_S3_****backup 1 100% root 1136 14 décembre 2018 4:48:22 PM 04:05:16 Récupération instantanée Disque Standard WIN-*********** 0
1140 Sauvegarde Terminé 0 VMware Analyse_Complete *******.********.cloud NBCC 14 décembre 2018 4:49:14 PM 03:49:58 14 décembre 2018 8:39:12 PM STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 14 décembre 2018 4:49:14 PM 03:49:58 Récupération instantanée Disque Standard WIN-*********** 0 45,2% 0%

L'accélérateur permet de réduire le trafic des agents, car seules les modifications des données sont transférées, c'est-à-dire que même les sauvegardes complètes ne sont pas transférées intégralement, le serveur multimédia collectant les sauvegardes complètes ultérieures à partir des sauvegardes incrémentielles.

Le serveur intermédiaire a son propre stockage, où il écrit le « cache » des données et maintient une base pour la déduplication.

Dans l'architecture complète, cela ressemble à ceci :

1. Le serveur maître gère la configuration, les mises à jour et autres, et se trouve dans le cloud.
2. Le serveur multimédia (machine intermédiaire *nix) doit être situé le plus près possible des systèmes à sauvegarder en termes d'accessibilité réseau. C'est ici que la déduplication des sauvegardes à partir de toutes les machines à sauvegarder se fait.
3. Sur les machines à sauvegarder, il y a des agents qui, en général, n'envoient au serveur multimédia que ce qui n'est pas déjà présent dans son stockage.

Tout commence par une analyse complète — il s'agit d'une sauvegarde complète à part entière. À ce moment-là, le serveur multimédia récupère tout, effectue la déduplication et transfère vers S3. La vitesse vers le serveur multimédia est faible, mais plus élevée en retour. La principale limitation est la puissance de calcul du serveur.

Les sauvegardes suivantes sont considérées comme complètes du point de vue de tous les systèmes, mais en réalité, il s'agit de quelque chose comme des sauvegardes complètes synthétiques. Autrement dit, le transfert et l'enregistrement sur le serveur multimédia ne concernent que les blocs de données qui n'ont pas encore été rencontrés dans les sauvegardes des VM précédemment. Et le transfert et l'enregistrement dans S3 ne portent que sur les blocs de données dont le hash n'est pas dans la base de déduplication du serveur multimédia. En d'autres termes, il s'agit de ce qui n'a été rencontré dans aucune des sauvegardes d'aucune VM auparavant.

Lors de la restauration, le serveur multimédia demande les objets dédupliqués nécessaires à S3, les régénère et les transmet aux agents SРK, c'est-à-dire qu'il faut tenir compte du volume de trafic lors de la restauration, qui sera égal au volume réel des données à restaurer.

Voici à quoi cela ressemble :

Et voici un autre extrait des journaux169 Jobs (0 En attente 0 Actifs 0 En attente de réessai 0 Suspendus 0 Incomplets 169 Terminés — 1 sélectionné)

Identifiant de travail Type État Détails de l'état Statut Politique de travail Calendrier de travail Client Média Serveur Heure de début Temps écoulé Heure de fin Unité de stockage Tentative Opération Kilooctets Fichiers Nom du chemin % Complète (Estimé) PID du travail Propriétaire Copier ID du travail parent KB/Sec Actif Début Actif Écoulé Robot Profil du coffre-fort ID de session Média à éjecter Mouvement de données Hors hôte Type Principal Priorité Taux de dédupliquation Accélérateur de transport Optimisation Instance ou base de données Partager hôte
— 1372 Restauration terminée 0 nbpr01 NBCC 19 déc. 2018 13:05:58 00:04:32 19 déc. 2018 13:10:30 1 14 380 577 1 100% 8548 root 1372 70 567 19 déc. 2018 13:06:00 00:04:30 WIN-*********** 90000

L'intégrité des données est assurée par la protection de S3 lui-même — il y a une bonne redondance pour se prémunir contre les pannes matérielles comme la défaillance d'un axe de disque dur.

Média-serveur 4 To de cache sont nécessaires — c'est la recommandation de Veritas pour le volume minimum. Mieux vaut plus, mais nous avons fait exactement cela.

Conclusion

Lorsque le partenaire a chargé 20 Go dans notre S3, nous avons stocké 60 Go, car nous garantissons un triple géo-repérage des données. Actuellement, le trafic est bien moindre, ce qui est bon pour le canal et pour la tarification du stockage.

Dans ce cas, les routes sont fermées hors du « grand Internet », mais il est possible de faire passer le trafic aussi par VPN L2 via Internet, mais il est préférable de placer le serveur multimédia avant l'entrée du fournisseur.

Si vous êtes intéressé par ces fonctionnalités dans nos centres de données russes ou si vous avez des questions sur leur mise en œuvre chez vous, n'hésitez pas à demander dans les commentaires ou par email à ekorotkikh@croc.ru.

Source : habr.com