Protection des données avec Astra
Cette page présente les options de protection des données pour les applications basées sur des conteneurs Red Hat OpenShift qui s'exécutent sur VMware vSphere à l'aide d'Astra Control Center (ACC).
Au fur et à mesure que les utilisateurs s'engagent dans la modernisation de leurs applications avec Red Hat OpenShift, une stratégie de protection des données doit être mise en place pour les protéger contre toute suppression accidentelle ou toute autre erreur humaine. Souvent, une stratégie de protection est également nécessaire à des fins réglementaires ou de conformité afin de protéger leurs données contre les données d'un grand nombre.
Les exigences en matière de protection des données varient entre le retour à une copie instantanée et le basculement automatique vers un autre domaine de panne sans intervention humaine. De nombreux clients choisissent ONTAP comme plateforme de stockage préférée pour leurs applications Kubernetes en raison de ses nombreuses fonctionnalités, telles que la colocation, le multiprotocole, les performances et les capacités élevées, la réplication et la mise en cache pour les sites multisites, la sécurité et la flexibilité.
La protection des données dans ONTAP peut être obtenue en utilisant ad hoc ou contrôlé par des règles - instantané - sauvegarde et restauration
Les copies Snapshot et les sauvegardes protègent les types de données suivants : - les métadonnées de l'application qui représentent l'état de l'application - tout volume de données persistantes associé à l'application - tout artefact de ressource appartenant à l'application
Instantané avec ACC
Une copie instantanée des données peut être capturée à l'aide de Snapshot avec ACC. La règle de protection définit le nombre de copies Snapshot à conserver. L'option horaire minimum disponible est horaire. Les copies Snapshot manuelles à la demande peuvent être effectuées à tout moment et à intervalles plus courts que les copies Snapshot planifiées. Les copies Snapshot sont stockées sur le même volume provisionné que l'application.
Configuration de l'instantané avec ACC
Sauvegarde et restauration avec ACC
Une sauvegarde est basée sur une copie Snapshot. ACC peut effectuer des copies Snapshot à l'aide de CSI et effectuer des sauvegardes à l'aide de la copie Snapshot instantanée. La sauvegarde est stockée dans un magasin d'objets externe (tout système s3 compatible avec ONTAP S3 à un emplacement différent). La règle de protection peut être configurée pour les sauvegardes planifiées et le nombre de versions de sauvegarde à conserver. L'objectif de point de récupération minimal est d'une heure.
Restauration d'une application à partir d'une sauvegarde à l'aide d'ACC
ACC restaure l'application à partir du compartiment S3 où sont stockées les sauvegardes.
Crochets d'exécution spécifiques à l'application
En outre, vous pouvez configurer des crochets d'exécution pour qu'ils s'exécutent en conjonction avec une opération de protection des données d'une application gérée. Même si les fonctionnalités de protection des données au niveau des baies de stockage sont disponibles, il est souvent nécessaire de suivre des étapes supplémentaires pour rendre les sauvegardes et les restaurations cohérentes avec les applications. Les étapes supplémentaires spécifiques à l'application peuvent être : - avant ou après la création d'une copie Snapshot. - avant ou après la création d'une sauvegarde. - Après restauration à partir d'une copie Snapshot ou d'une sauvegarde.
ASTRA Control peut exécuter ces étapes spécifiques à l'application codées comme des scripts personnalisés appelés crochets d'exécution.
"Projet GitHub NetApp Verda" fournit des crochets d'exécution pour les applications cloud les plus courantes afin de simplifier, renforcer et orchestrer la protection des applications. N'hésitez pas à contribuer à ce projet si vous avez suffisamment d'informations pour une application qui ne se trouve pas dans le référentiel.
Exemple de crochet d'exécution pour pré-instantané d'une application redis.
Réplication avec ACC
Pour la protection régionale ou pour une solution à faible RPO et RTO, une application peut être répliquée vers une autre instance Kubernetes s'exécutant sur un autre site, de préférence dans une autre région. ACC utilise ONTAP Async SnapMirror avec RPO à partir de 5 minutes. La réplication s'effectue par réplication dans ONTAP, puis un basculement crée les ressources Kubernetes dans le cluster de destination.
Notez que la réplication est différente de la sauvegarde et de la restauration où la sauvegarde est envoyée vers S3 et la restauration depuis S3. Pour plus d'informations sur les différences entre les deux types de protection des données, consultez le lien : here. |
Reportez-vous à "ici" Pour obtenir les instructions d'installation de SnapMirror.
SnapMirror avec ACC
les pilotes de stockage san-economy et nas-economy ne prennent pas en charge la fonction de réplication. Reportez-vous à "ici" pour plus d'informations. |
Vidéo de démonstration :
Continuité de l'activité avec MetroCluster
La plupart de notre plate-forme matérielle pour ONTAP dispose de fonctionnalités de haute disponibilité pour se protéger contre les pannes de systèmes, ce qui évite d'avoir à effectuer des opérations de récupération à plat. Mais pour éviter les risques d'incendie ou de tout autre incident et pour poursuivre l'activité avec un RPO nul et un RTO faible, on utilise souvent une solution MetroCluster.
Les clients qui disposent actuellement d'un système ONTAP peuvent s'étendre à MetroCluster en ajoutant des systèmes ONTAP pris en charge dans les limites de distance pour fournir une reprise après incident au niveau de la zone. Trident, le CSI (interface de stockage des conteneurs) prend en charge NetApp ONTAP, y compris la configuration MetroCluster, ainsi que d'autres options comme Cloud Volumes ONTAP, Azure NetApp Files, AWS FSX ONTAP, etc. Trident propose cinq options de pilotes de stockage pour ONTAP, toutes prises en charge pour la configuration MetroCluster. Pour plus d'informations sur les pilotes de stockage ONTAP pris en charge par Trident, reportez-vous à la section"ici".
La solution MetroCluster nécessite une extension réseau de couche 2 ou une capacité d'accès à la même adresse réseau à partir des deux domaines de défaillance. Une fois la configuration MetroCluster en place, la solution est transparente pour les propriétaires d'applications, puisque tous les volumes du svm MetroCluster sont protégés et profitent des avantages de SyncMirror (RPO nul).
Pour la configuration back-end Trident (TBC), ne spécifiez pas la dataLIF et le SVM lors de l'utilisation de la configuration MetroCluster. Spécifier l'IP de gestion du SVM pour la LIF managementLIF et utiliser les identifiants de rôle vsadmin |
Des informations détaillées sur les fonctionnalités de protection des données d'Astra Control Center sont disponibles "ici"