Azure Backup, exemple d’architecture

Architecture Azure Backup

Sous la forme de services PaaS. Voire d’un service « SaaS» pour les bases de données managées. Ce sont des services natifs, disponibles directement dans le portail, qui bénéficient également d’une console de gestion centrale appelée Backup Center, élément indispensable pour faire le lien entre tous les sujets de la sauvegarde.

Ces services ont été améliorés ces dernières semaines et proposent maintenant plus d’options avec par exemple, pour le service Coffre Recovery Service, la possibilité de planifier plusieurs sauvegardes dans la même journée.

Comme souvent, la solution peut être complétée par des services périphériques Azure pour simplifier et améliorer l’expérience.

Ces 3 services sont Azure Policy, des diagnostics avancés pour Log Analytics ainsi que l’Explorateur Azure Resource. Ils seront présentés dans cet article pour montrer comment ils viennent épauler et donner plus de valeur aux services de sauvegarde.

Présentation des services Azure Backup

Il y a plusieurs types de sauvegardes sur Azure. Ce qui est abordé dans ce sujet concerne la sauvegarde des ressources. Et plus spécifiquement celle des machines virtuelles. Le sujet est trop vaste pour pouvoir en quelques pages faire une présentation même succincte de tout ce qu’il existe en termes de possibilités pour l’ensemble des autres ressources.
C’est du côté des PaaS que l’on trouve les deux services distincts pour les machines virtuelles. Ces PaaS couvrent plus que les machines virtuelles, voici la liste exhaustive des possibilités.

• Coffre Recovery Services, pour les VM, mais aussi les partages de fichiers, SQL Server dans une VM et SAP Hana dans une VM.
• Coffres de sauvegarde, pour les disques Azure (et par extension, les VM) mais aussi les Blobs et les serveurs Azure Database pour PostGreSQL.

S’il y a pas mal de choses qui rentrent en compte avant de déployer ces PaaS, voici quelques informations qui doivent être connues pour mieux décider de son architecture. Les éléments de base constituants la sauvegarde sont la redondance et les stratégies (fréquence et durée de conservation).

Comme pour toutes les études d’architecture, il doit y avoir à ce stade de la réflexion, une volonté d’optimisation des coûts. S’il est évident que fréquence et durée de conservation auront un impact sur le coût (puisqu’elles vont directement impacter le volume de stockage dont dépend en grande partie de la facturation), la redondance qui se « cache » derrière les coffres n’est pas toujours bien connue.

Stockage et Niveau de redondance

Car le stockage des données est possible selon 3 niveaux de redondance allant de la redondance locale LRS à faible coût, à une redondance géographique, GRS, avec un coût plus important. Cette option n’apparait pas à la création. Elle doit impérativement être revue avant la sauvegarde des premières ressources. Il n’y aura, ensuite, d’autres solutions que de détruire le coffre pour le recréer si la redondance choisie par défaut (GRS) ne convient pas.

Une fois assimilés ces points essentiels et structurants, il est plus facile de décider. Pour en terminer avec la partie théorique, depuis quelques semaines, Coffre Recovery Service a été enrichi par un type de stratégies (Stratégie améliorée) en préversion. C’est une belle amélioration avec notamment une fréquence de sauvegarde beaucoup plus élevée. Celles et ceux qui utilisent déjà la sauvegarde Azure trouveront là une belle opportunité. Avant cette nouveauté, la solution pour de multiples backups / jour pour les VM n’était pas très élégante. Puisqu’il fallait utiliser le second service PaaS, Coffres de sauvegarde, pour sauvegarder les disques de VM indépendamment de la machine.

Il y a de fortes chances pour que cet ajout vienne modifier l’architecture de la solution de sauvegarde chez les clients Azure.

Centre de sauvegarde

A ce niveau de la présentation, il manque un maillon essentiel pour une gestion centralisée. C’est ce que propose la console Centre de sauvegarde, avec :

• De la gestion d’instances (de ressources), de stratégies, de coffres.
• De la supervision, avec des alertes, de la mesure ou du rapport.
• De la stratégie de conformité.

Il faut faire une parenthèse ici pour préciser ce que sont les deux types de stratégies dont il est question.

• La stratégie de sauvegarde, où sont paramétrées les différentes règles (durée de la rétention, heure de la sauvegarde …etc.).
• La stratégie (Policy) Azure qui est un élément de gouvernance. Il va être question de cet important sujet dans la partie mise en œuvre de cet article. Afin de clarifier la présentation, le terme Policy est conservé pour la suite.

Il est grandement recommandé d’utiliser cette console qui permet toutes les actions sur les fonctionnalités de sauvegarde, et de creuser l’utilisation du menu Rapports de sauvegarde qui va rendre de nombreux services ! Comme la détection des anomalies fréquentes ou l’affichage du volume de stockage par VM. Une mine d’or !

Azure Backup : Mise en œuvre

Si la mise en œuvre unitaire est une opération assez simple, la solution de sauvegarde doit être pensée dans son ensemble. Les différentes possibilités ainsi que les services périphériques dont il a été question plus haut offrent tellement d’avantages qu’il serait dommage de s’en passer. Pour illustrer ce propos, un exemple d’architecture de sauvegarde pour des machines virtuelles est présenté ci-dessous. Il intègre plusieurs notions.

Avant de rentrer dans le détail, le cas d’usage auquel il va répondre est le suivant :

• Une gestion automatique des sauvegardes pour les ressources existantes.
• Une gestion automatique des sauvegardes pour les nouvelles ressources.
• Des rapports de diagnostics avancés (en plus des rapports de base).
• Une optimisation des coûts avec une sauvegarde différente pour une machine hors production et une machine de production.

Schéma d’architecture pour la sauvegarde des VM.

Comme toujours lorsqu’il est question de gouvernance, Azure Policy et les étiquettes (ou tags) sont au centre du sujet. Pour que le schéma d’architecture soit respecté, il faut que les machines virtuelles soient clairement identifiées par une étiquette. Ici, tout est possible.

Soit avec un couple nom valeur Sauvegarde/Prod ou Sauvegarde/NonProd par exemple. Ou par l’utilisation d’une convention pour le nommage du groupe de ressource qui héberge la VM. Peu importe la méthode. Ce qu’il faut retenir, c’est qu’Azure Policy va utiliser ces données et faire les actions automatiquement.

Bien utilisé, il peut ajouter / corriger les valeurs manquantes pour l’existant / le futur mais il peut aussi imposer certaines valeurs. Résultat, chaque VM est correctement identifiée comme Prod ou NonProd.

Pour la suite, c’est toujours du côté d’Azure Policy qu’il faut se tourner. Puisqu’il y a dans les Policy BuiltIn la possibilité d’attacher automatiquement une VM à un Coffre Recovery Service existant en se basant sur une étiquette.

Configurer une sauvegarde sur des machines virtuelles avec une étiquette donnée

dans un coffre Recovery Services existant dans la même localisation

Comme tout va se faire automatiquement, autant que cela se fasse avec bon sens.

• Une machine étiquetée NonProd se verra attachée à un Coffre localement redondant, avec une rétention de sauvegarde à 7 jours. Ici, c’est un bon compromis entre la sécurité des données et un coût modéré.
• Une machine étiquetée Prod se verra attachée à un Coffre géo redondant, avec une rétention de sauvegarde à 21 jours. Ici, c’est une élévation de sécurité des données et un coût plus important. Mais justifié par le fait que c’est une machine de production.

Reste à enrichir le Centre de sauvegarde par le déploiement des paramètres de diagnostic avancé pour le Coffre. Cette opération va ajouter plus de 10 points de diagnostic supplémentaires dans le rapport. De quelle façon ? … toujours et encore par Policy.

Déployez les paramètres de diagnostic du coffre Recovery Services

La promesse de cette architecture est tenue ! Une fois déployée, les machines sont automatiquement sauvegardées, la console de gestion centrale expose des paramètres de diagnostics avancés et l’optimisation financière est au rendez-vous.

Cerise sur le gâteau, l’utilisation de l’outil de requêtes l’Explorateur Azure Resource va traiter le sujet des éventuelles ressources en anomalies. Avec un exemple de requête qui retourne toutes les machines qui n’auraient pas le tag (en Anglais dans la requête)  nommé Backup.

Resources
| where type =~ ‘Microsoft.Compute/virtualMachines’
| where isempty(tags.Backup)
| project name

Une piste pour affiner encore et encore le sujet.

Azure Backup, exemple d’architecture, en résumé, ce qu’il faut retenir en 3 étapes 

1 / Les sauvegardes Azure sont traitées par plusieurs services PaaS ou SaaS.
2 / Azure Policy permet une automatisation complète des sauvegardes et la garantie d‘un service optimal.
3 / Les leviers pour optimiser la facturation sont nombreux, le coût de stockage représente une bonne partie de cette optimisation.

Publié dans Smart DSI N°26