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

Nos clients turcs nous ont demandé de configurer correctement la sauvegarde du centre de données. Nous menons des projets similaires en Russie, mais c'est ici que l'histoire portait davantage sur la meilleure façon de faire.

Étant donné: il existe un stockage S3 local, il y a Veritas NetBackup, qui a acquis de nouvelles fonctionnalités avancées pour déplacer les données vers les magasins d'objets maintenant avec prise en charge de la déduplication, et il y a un problème d'espace libre dans ce stockage local.

Objectif: tout faire pour que le processus de stockage de sauvegarde soit rapide et bon marché.

En fait, avant cela, dans S3, tout n'était que des fichiers, et il s'agissait de moulages complets de machines critiques de datacenter. Ce n'est pas pour qu'il soit très optimisé, mais tout a fonctionné au départ. Il est maintenant temps de le comprendre et de le faire correctement.

Dans l'image, ce que nous en sommes venus à:



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

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

Quel est le problème

Les clients veulent sauvegarder aussi souvent que possible et stocker le moins cher possible. Il est bon marché de les stocker au mieux dans le stockage d'objets de type S3, car ils sont les moins chers au prix de la maintenance par mégaoctet d'où vous pouvez effectuer une restauration dans un délai raisonnable. Lorsqu'il y a beaucoup de sauvegardes, cela devient peu coûteux, car la plupart du stockage est occupé par des copies des mêmes données. Dans le cas de HaaS de collègues turcs, le stockage peut être densifié d'environ 80 à 90%. Il est clair que cela s'applique spécifiquement à leurs spécificités, mais je compterais certainement sur au moins 50% de la déduction.

Pour résoudre le problème, les principaux fournisseurs ont depuis longtemps créé des passerelles sur Amazon S3. Toutes leurs méthodes sont compatibles avec S3 local si elles prennent en charge l'API Amazon. Dans le centre de données turc, la sauvegarde est effectuée dans notre S3, ainsi que dans le «compresseur» T-III en Russie, car un tel schéma de travail s'est avéré bon pour nous.

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

Veritas NetBackup a créé une fonctionnalité CloudCatalyst:



C'est-à-dire qu'entre les machines qui doivent être sauvegardées et la passerelle, il y a un serveur Linux intermédiaire à travers lequel passe le trafic de sauvegarde des agents CPC et la déduplication est effectuée à la volée avant de les transférer vers S3. Si auparavant il y avait 30 sauvegardes de 20 Go chacune avec compression, maintenant (en raison de la similitude des machines), elles sont devenues 90% plus petites en volume. Le moteur de déduplication est utilisé de la même manière que lorsqu'il est stocké sur des disques normaux à l'aide de Netbackup.

Voici ce qui se passe avant le serveur de transfert:



Nous avons testé et conclu que, une fois implémenté dans nos centres de données, cela économise de l'espace dans les stockages S3 pour nous et pour les clients. En tant que propriétaire de centres de données commerciaux, bien sûr, nous facturons le volume occupé, mais cela est toujours très rentable pour nous aussi - car nous commençons à gagner sur des emplacements plus évolutifs dans les logiciels, et non sur la location de fer. Eh bien, c'est une réduction des coûts internes.


L'accélérateur vous 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 intégralement versées, car le serveur multimédia collecte les sauvegardes complètes suivantes à partir des sauvegardes incrémentielles.

Le serveur intermédiaire a son propre référentiel où il écrit un "cache" de données et détient la base de déduplication.

En architecture complète, cela ressemble à ceci:

1. Le serveur maître gère la configuration, les mises à jour, etc., et se trouve 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 de disponibilité du réseau. Ici, les sauvegardes sont dédupliquées de toutes les machines redondantes.
3. Il y a des agents sur les machines redondantes qui n'envoient généralement au serveur multimédia que 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 dédoublonne et le transfère vers S3. La vitesse vers le serveur multimédia est faible, de là - plus élevée. La principale limitation est la puissance de traitement du serveur.

Les sauvegardes suivantes sont effectuées du point de vue de tous les systèmes, mais en réalité, il s'agit de sauvegardes complètes synthétiques. Autrement dit, le transfert et l'enregistrement réels sur le serveur multimédia ne sont que les blocs de données qui n'ont pas encore été vus dans les sauvegardes de VM auparavant. Et le transfert et l'enregistrement vers S3 ne sont que les blocs de données dont le hachage ne se trouve pas dans la base de données de déduplication du serveur multimédia. Si en termes plus simples - qu'il n'y avait aucune machine virtuelle dans aucune sauvegarde auparavant.

Lors de la restauration, le serveur multimédia demande les objets dédupliqués nécessaires à S3, les réhydrate et les transmet aux agents CPC, 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 ça ressemble:




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 protéger contre les pannes matérielles telles qu'une broche de disque dur morte.

Le serveur multimédia a besoin de 4 téraoctets de cache - c'est la recommandation de Veritas pour la taille minimale. Mieux encore, mais nous l'avons fait.

Résumé

Lorsqu'un partenaire a jeté 20 Go dans notre S3, nous avons stocké 60 Go, car nous fournissons une géo-réservation de données à trois reprises. Maintenant, le trafic est beaucoup moins, ce qui est bon à la fois pour le canal et pour la charge de stockage.

Dans ce cas, les itinéraires sont fermés après le "grand Internet", mais vous pouvez générer du trafic via VPN L2 via Internet, mais il est préférable de configurer le serveur multimédia à 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 façon de les mettre en œuvre, posez-les dans les commentaires ou envoyez un e-mail à ekorotkikh@croc.ru.