Dans des publications précédentes, nous avons partagé des instructions pour la configuration et basée sur Veeam. Aujourd'hui, nous souhaitons parler de la sauvegarde avec Commvault. Il n'y aura pas d'instructions, mais nous vous expliquerons ce que nos clients sauvegardent déjà et comment.
Les systèmes de stockage de sauvegarde basés sur Commvault dans le data center OST-2.
Comment cela fonctionne ?
Commvault est une plateforme de sauvegarde pour les applications, bases de données, systèmes de fichiers, machines virtuelles et serveurs physiques. Les données sources peuvent se trouver sur n'importe quelle plateforme : chez nous, du côté du client, dans un autre data center commercial ou dans le cloud.
Le client installe un agent sur les objets de sauvegarde - iData Agent – et le configure selon les politiques de sauvegarde requises. L’iData Agent collecte les données nécessaires, les compresse, les déduplique, les chiffre et les transmet au système de sauvegarde DataLine.
Les serveurs proxy assurent la connectivité entre le réseau client et notre réseau, ainsi que l'isolation des canaux par lesquels les données sont transférées.
Du côté de DataLine, les données de l’iData Agent sont acceptées par Media Agent Server et envoyées pour stockage sur des systèmes de stockage, bibliothèques de bandes, etc. Tout cela est géré par CommServe. Dans notre configuration, le principal serveur de gestion est situé sur le site OST, le serveur de secours – sur le site NORD.
Par défaut, les données du client sont stockées sur une seule plateforme, mais il est possible d'organiser des sauvegardes sur deux emplacements ou de planifier le transfert des sauvegardes vers un second emplacement. Cette option s'appelle « copie de données supplémentaire » (auxiliary copy). Par exemple, toutes les sauvegardes complètes à la fin du mois seront automatiquement dupliquées ou déplacées vers le second site.
Le schéma de fonctionnement du système de sauvegarde Commvault.
Le système de sauvegarde fonctionne principalement sur la virtualisation VMware : des serveurs CommServe, Media Agent et serveurs Proxy sont déployés sur des machines virtuelles. Si le client utilise notre matériel, les sauvegardes sont stockées sur le système de stockage Huawei OceanStor 5500 V3. Pour les sauvegardes des systèmes de stockage des clients, des bibliothèques de bandes sont utilisées avec des Media Agents séparés sur des serveurs physiques.
Qu'est-ce qui est important pour les clients ?
D'après notre expérience, les clients qui choisissent Commvault pour la sauvegarde portent une attention particulière aux éléments suivants.
Console. Les clients souhaitent gérer eux-mêmes les sauvegardes. Toutes les opérations principales sont disponibles dans la console Commvault :
- ajout et suppression de serveurs pour la sauvegarde ;
- configuration de l'iData Agent ;
- création et exécution manuelle de tâches ;
- restauration autonome des sauvegardes ;
- configuration des alertes sur l'état des tâches de sauvegarde ;
- définition des accès à la console en fonction des rôles et des groupes d'utilisateurs.
Déduplication. La déduplication permet d'identifier et de supprimer les blocs de données en double lors du processus de sauvegarde. Cela aide à économiser de l'espace sur le stockage et réduit le volume des données transmises, diminuant ainsi les exigences en matière de vitesse de bande passante. Sans déduplication, les sauvegardes occuperaient un volume deux à trois fois supérieur à celui des données d'origine.
Dans le cas de Commvault, la déduplication peut être configurée du côté client ou du côté Media Agent. Dans le premier cas, les blocs de données non uniques ne seront même pas transmis au serveur Media Agent. Dans le second cas, le bloc répété est rejeté et n'est pas enregistré sur le stockage.
Cette déduplication par blocs repose sur des fonctions de hachage. À chaque bloc est attribué un hachage, qui est conservé dans une table de hachage, une sorte de base de données (Deduplication Database, DDB). Lors de la transmission des données, le hachage est vérifié dans cette base. Si ce hachage est déjà présent dans la base, le bloc est marqué comme non unique et ne sera pas transmis au serveur Media Agent (dans le premier cas) ou ne sera pas enregistré dans le système de stockage (dans le second).
Grâce à la déduplication, nous parvenons à économiser jusqu'à 78 % d'espace dans le système de stockage. Actuellement, 166,4 To sont stockés. Sans déduplication, nous devrions stocker 744 To.
Possibilité de définir des droits. Commvault permet d'établir différents niveaux d'accès à la gestion des sauvegardes. Les dites "rôles" définissent quelles actions seront autorisé à l'utilisateur vis-à-vis des objets de sauvegarde. Par exemple, les développeurs pourront uniquement restaurer le serveur avec la base de données à un emplacement spécifique, tandis que l'administrateur pourra lancer une sauvegarde à la demande pour ce même serveur et ajouter de nouveaux utilisateurs.
Cryptage. Les données peuvent être chiffrées lors de la sauvegarde via Commvault de plusieurs manières :
- Du côté de l'agent client : les données seront transmises au système de sauvegarde déjà chiffrées.
- Du côté de l'agent média ;
- Au niveau du canal : les données sont chiffrées du côté de l'agent client et déchiffrées sur le serveur Media Agent.
Algorithmes de chiffrement disponibles : Blowfish, GOST, Serpent, Twofish, 3-DES, AES (recommandé par Commvault).
Un peu de statistiques
À la mi-décembre, nous avons 27 clients sauvegardés grâce à Commvault. La majorité d'entre eux sont des détaillants et des organisations financières. Le volume total des données initiales sauvegardées est de 65 To.
Environ 4400 tâches sont effectuées par jour. Ci-dessous, les statistiques des tâches effectuées au cours des 16 derniers jours.
Le plus souvent, les sauvegardes via Commvault concernent le système de fichiers Windows, SQL Server et les bases de données Exchange.
Et maintenant, les cas promis. Bien qu'anonymisés (NDA salut ! :)), ils donnent une idée de la manière dont les clients utilisent la sauvegarde basée sur Commvault. Ci-dessous, des cas de clients utilisant un système de sauvegarde unifié, c'est-à-dire des logiciels communs, des serveurs Media Agent et des systèmes de stockage.
Cas 1
Client. Société de commerce et de production russe sur le marché des confiseries avec un réseau de succursales réparties dans toute la Russie.
Objectif.Organisation de la sauvegarde pour les bases de données Microsoft SQL, les serveurs de fichiers, les serveurs d'applications, les boîtes aux lettres Exchange Online.
Les données sources sont réparties dans des bureaux à travers la Russie (plus de 10 villes). Il faut sauvegarder sur le site DataLine avec une restauration ultérieure des données dans n'importe quel bureau de l'entreprise.
Le client souhaitait cependant une gestion autonome complète avec des restrictions d'accès.
Durée de conservation – un an. Pour Exchange Online – 3 mois pour les copies actives et un an pour les archives.
Solution. Pour les bases de données, une copie supplémentaire a été configurée sur un deuxième site : la dernière sauvegarde complète du mois est transférée sur un autre site et y est conservée pendant un an.
La qualité des canaux depuis les bureaux distants du client ne permettait pas toujours de réaliser les sauvegardes et les restaurations dans des délais optimaux. Pour réduire le volume de trafic transféré, une déduplication a été configurée côté client. Grâce à cela, le temps de sauvegarde complète est devenu acceptable compte tenu de l'éloignement des bureaux. Par exemple, une sauvegarde complète de la base de données de 131 Go depuis Saint-Pétersbourg prend 16 minutes. Depuis Ekaterinbourg, une base de données de 340 Go est sauvegardée en 1 heure et 45 minutes.
Avec l'aide des rôles, le client a configuré pour ses développeurs des autorisations différentes : soit uniquement pour la sauvegarde, soit pour la restauration.
Cas 2
Client. Réseau russe de magasins de jouets pour enfants.
Objectif. Organisation de la sauvegarde pour :
un cluster MS SQL très chargé basé sur 4 serveurs physiques ;
des machines virtuelles avec site, serveurs d'applications, 1C, Exchange et serveurs de fichiers.
Toute l'infrastructure mentionnée du client est répartie entre les sites OST et NORD.
RPO pour les serveurs SQL – 30 minutes, pour les autres – 1 jour.
Profondeur de stockage – de 2 semaines à 30 jours selon le type de données.
Solution. Ils ont choisi une combinaison de solutions basées sur Veeam et Commvault. Pour la sauvegarde de fichiers depuis notre cloud, Veeam est utilisé. Les serveurs de bases de données, Active Directory, les serveurs de messagerie et les serveurs physiques sont sauvegardés via Commvault.
Pour atteindre une haute vitesse de sauvegarde, le client a alloué un adaptateur réseau séparé sur les serveurs physiques avec MS SQL pour les tâches de sauvegarde. Une sauvegarde complète d'une base de données de 3,4 To prend 2 heures et 20 minutes, et une restauration complète – 5 heures et 5 minutes.
Le client avait un grand volume de données source (près de 18 To). Si ces données étaient archivées sur une bibliothèque de bandes, comme le faisait le client auparavant, il aurait fallu plusieurs dizaines de cartouches. Cela aurait compliqué la gestion de l'ensemble du système de sauvegarde du client. Par conséquent, dans la mise en œuvre finale, la bibliothèque de bandes a été remplacée par une SAN.
Cas 3
Client. Réseau de supermarchés dans la CEI
Objectif. Le client souhaitait organiser la sauvegarde et la restauration des systèmes SAP, hébergés dans notre cloud. Pour les bases de données SAP HANA, RPO=15 minutes, pour les machines virtuelles avec serveurs d'applications RPO=24 heures. Profondeur de stockage – 30 jours. En cas d'accident, RTO=1 heure, pour la restauration d'une copie sur demande RTO=4 heures.
Solution. Pour la base de données HANA, une sauvegarde des fichiers DATA et des fichiers Log a été configurée avec une périodicité donnée. Les fichiers Log étaient archivés toutes les 15 minutes ou lorsque certaines tailles étaient atteintes.
Pour réduire le temps de restauration de la base de données, nous avons configuré un stockage de sauvegardes en deux niveaux, basé sur un système de stockage et une bibliothèque de bandes. Des copies opérationnelles sont stockées sur disques avec possibilité de restauration à tout moment durant la semaine. Lorsque la sauvegarde a plus d'une semaine, elle est déplacée dans l'archive, sur la bibliothèque de bandes, où elle est conservée pendant 30 jours supplémentaires.
Une sauvegarde complète d'une des bases de données d'une taille de 181 Go prend 1 heure 54 minutes.
Lors de la configuration de la sauvegarde, l'interface backint de SAP a été utilisée, permettant d'intégrer les systèmes de sauvegarde de tiers avec SAP HANA Studio. Ainsi, la sauvegarde peut être gérée directement depuis la console SAP. Cela facilite la vie des administrateurs SAP qui n'ont pas besoin de s'habituer à une nouvelle interface.
La gestion de la sauvegarde est également accessible au client via la console client standard Commvault.
C'est tout pour aujourd'hui. Posez vos questions dans les commentaires.
Source : habr.com
