Conception de référence de haut niveau en temps réel
Suggérer des modifications
PDF
Cette section couvre un déploiement en temps réel d’un parc de bases de données SQL dans une configuration AOAG à l’aide d’un volume SMB Azure NetApp Files .
-
Nombre de nœuds : 4
-
Nombre de bases de données : 21
-
Nombre de groupes de disponibilité : 4
-
Conservation des sauvegardes : 7 jours
-
Archives de sauvegarde : 365 jours
|
Le déploiement de FCI avec SQL Server sur des machines virtuelles Azure avec un partage Azure NetApp Files fournit un modèle rentable avec une seule copie des données. Cette solution peut empêcher les problèmes d’opération d’ajout de fichier si le chemin du fichier diffère de celui de la réplique secondaire. |
L'image suivante montre les bases de données au sein d'AOAG réparties sur les nœuds.
Disposition des données
Les fichiers de base de données utilisateur (.mdf) et les fichiers journaux de transactions de base de données utilisateur (.ldf) ainsi que tempDB sont stockés sur le même volume. Le niveau de service est Ultra.
La configuration se compose de quatre nœuds et de quatre AG. Les 21 bases de données (faisant partie de Dynamic AX, SharePoint, du courtier de connexion RDS et des services d’indexation) sont stockées sur les volumes Azure NetApp Files . Les bases de données sont équilibrées entre les nœuds AOAG pour utiliser efficacement les ressources sur les nœuds. Quatre instances D32 v3 sont ajoutées dans le WSFC, qui participe à la configuration AOAG. Ces quatre nœuds sont provisionnés dans le réseau virtuel Azure et ne sont pas migrés depuis le site local.
Remarques :
-
Si les journaux nécessitent davantage de performances et de débit en fonction de la nature de l'application et des requêtes exécutées, les fichiers de base de données peuvent être placés au niveau de service Premium et les journaux peuvent être stockés au niveau de service Ultra.
-
Si les fichiers tempdb ont été placés sur Azure NetApp Files, le volume Azure NetApp Files doit être séparé des fichiers de base de données utilisateur. Voici un exemple de distribution des fichiers de base de données dans AOAG.
Remarques :
-
Pour conserver les avantages de la protection des données basée sur la copie Snapshot, NetApp recommande de ne pas combiner les données et les données de journal dans le même volume.
-
Une opération d'ajout de fichier effectuée sur la réplique principale peut échouer sur les bases de données secondaires si le chemin d'accès au fichier d'une base de données secondaire diffère du chemin d'accès de la base de données principale correspondante. Cela peut se produire si le chemin de partage est différent sur les nœuds principaux et secondaires (en raison de comptes d'ordinateur différents). Cette défaillance pourrait entraîner la suspension des bases de données secondaires. Si le modèle de croissance ou de performance ne peut pas être prédit et que le plan consiste à ajouter des fichiers ultérieurement, un cluster de basculement SQL Server avec Azure NetApp Files est une solution acceptable. Pour la plupart des déploiements, Azure NetApp Files répond aux exigences de performances.
Migration
Il existe plusieurs façons de migrer une base de données utilisateur SQL Server locale vers SQL Server dans une machine virtuelle Azure. La migration peut être en ligne ou hors ligne. Les options choisies dépendent de la version de SQL Server, des exigences commerciales et des SLA définis au sein de l’organisation. Pour minimiser les temps d'arrêt pendant le processus de migration de la base de données, NetApp recommande d'utiliser l'option AlwaysOn ou l'option de réplication transactionnelle. S’il n’est pas possible d’utiliser ces méthodes, vous pouvez migrer la base de données manuellement.
L’approche la plus simple et la plus testée pour déplacer des bases de données entre machines est la sauvegarde et la restauration. En règle générale, vous pouvez commencer par une sauvegarde de la base de données suivie d’une copie de la sauvegarde de la base de données dans Azure. Vous pouvez ensuite restaurer la base de données. Pour des performances de transfert de données optimales, migrez les fichiers de base de données vers la machine virtuelle Azure à l’aide d’un fichier de sauvegarde compressé. La conception de haut niveau référencée dans ce document utilise l’approche de sauvegarde du stockage de fichiers Azure avec la synchronisation de fichiers Azure, puis la restauration vers les fichiers Azure NetApp .
|
|
Azure Migrate peut être utilisé pour découvrir, évaluer et migrer les charges de travail SQL Server. |
Pour effectuer une migration, suivez les étapes de haut niveau suivantes :
-
En fonction de vos besoins, configurez la connectivité.
-
Effectuez une sauvegarde complète de la base de données vers un emplacement de partage de fichiers sur site.
-
Copiez les fichiers de sauvegarde sur un partage de fichiers Azure avec la synchronisation de fichiers Azure.
-
Provisionnez la machine virtuelle avec la version souhaitée de SQL Server.
-
Copiez les fichiers de sauvegarde sur la machine virtuelle en utilisant le
copycommande à partir d'une invite de commande. -
Restaurez les bases de données complètes sur SQL Server sur des machines virtuelles Azure.
|
|
Pour restaurer 21 bases de données, il a fallu environ neuf heures. Cette approche est spécifique à ce scénario. Cependant, d’autres techniques de migration répertoriées ci-dessous peuvent être utilisées en fonction de votre situation et de vos besoins. |
D'autres options de migration pour déplacer des données d'un serveur SQL local vers Azure NetApp Files incluent les suivantes :
-
Détachez les données et les fichiers journaux, copiez-les dans le stockage Azure Blob, puis attachez-les à SQL Server dans la machine virtuelle Azure avec un partage de fichiers ANF monté à partir de l’URL.
-
Si vous utilisez le déploiement du groupe de disponibilité Always On sur site, utilisez le "Assistant d'ajout de réplica Azure" pour créer une réplique dans Azure, puis effectuer un basculement.
-
Utiliser SQL Server "réplication transactionnelle" pour configurer l’instance Azure SQL Server en tant qu’abonné, désactiver la réplication et diriger les utilisateurs vers l’instance de base de données Azure.
-
Expédiez le disque dur à l’aide du service d’importation/exportation Windows.
Sauvegarde et récupération
La sauvegarde et la récupération sont un aspect important de tout déploiement SQL Server. Il est obligatoire de disposer d'un filet de sécurité approprié pour récupérer rapidement de divers scénarios de panne et de perte de données en conjonction avec des solutions de haute disponibilité telles que AOAG. L'outil de mise en veille de la base de données SQL Server, Azure Backup (streaming) ou tout autre outil de sauvegarde tiers tel que Commvault peuvent être utilisés pour effectuer une sauvegarde cohérente des bases de données avec l'application.
La technologie Azure NetApp Files Snapshot vous permet de créer facilement une copie ponctuelle (PiT) des bases de données utilisateur sans affecter les performances ou l’utilisation du réseau. Cette technologie vous permet également de restaurer une copie Snapshot sur un nouveau volume ou de rétablir rapidement le volume affecté à l'état dans lequel il se trouvait lorsque cette copie Snapshot a été créée à l'aide de la fonction de restauration du volume. Le processus de capture instantanée Azure NetApp Files est très rapide et efficace, ce qui permet plusieurs sauvegardes quotidiennes, contrairement à la sauvegarde en continu proposée par la sauvegarde Azure. Avec plusieurs copies Snapshot possibles au cours d'une journée donnée, les temps RPO et RTO peuvent être considérablement réduits. Pour ajouter de la cohérence à l'application afin que les données soient intactes et correctement vidées sur le disque avant la copie instantanée, utilisez l'outil de mise en veille de la base de données SQL Server.("Outil SCSQLAPI" ; l'accès à ce lien nécessite les informations de connexion NetApp SSO). Cet outil peut être exécuté à partir de PowerShell, ce qui met en veille la base de données SQL Server et peut à son tour prendre la copie instantanée du stockage cohérent avec l'application pour les sauvegardes.
*Remarques : *
-
L'outil SCSQLAPI prend uniquement en charge les versions 2016 et 2017 de SQL Server.
-
L'outil SCSQLAPI ne fonctionne qu'avec une seule base de données à la fois.
-
Isolez les fichiers de chaque base de données en les plaçant sur un volume Azure NetApp Files distinct.
En raison des vastes limitations de l'API SCSQL, "Sauvegarde Azure" a été utilisé pour la protection des données afin de répondre aux exigences du SLA. Il offre une sauvegarde basée sur le flux de SQL Server exécuté dans Azure Virtual Machines et Azure NetApp Files. Azure Backup permet un RPO de 15 minutes avec des sauvegardes fréquentes des journaux et une récupération PiT jusqu’à une seconde.
Surveillance
Azure NetApp Files est intégré à Azure Monitor pour les données de séries chronologiques et fournit des mesures sur le stockage alloué, l'utilisation réelle du stockage, le volume IOPS, le débit, les octets de lecture de disque/s, les octets d'écriture de disque/s, les lectures de disque/s et les écritures de disque/s, ainsi que la latence associée. Ces données peuvent être utilisées pour identifier les goulots d’étranglement avec des alertes et pour effectuer des contrôles d’intégrité afin de vérifier que votre déploiement SQL Server s’exécute dans une configuration optimale.
Dans ce HLD, ScienceLogic est utilisé pour surveiller Azure NetApp Files en exposant les métriques à l’aide du principal de service approprié. L’image suivante est un exemple de l’option de métrique Azure NetApp Files .
DevTest utilisant des clones épais
Avec Azure NetApp Files, vous pouvez créer des copies instantanées de bases de données pour tester les fonctionnalités qui doivent être implémentées en utilisant la structure et le contenu actuels de la base de données pendant les cycles de développement d'applications, pour utiliser les outils d'extraction et de manipulation de données lors du remplissage des entrepôts de données, ou même pour récupérer des données qui ont été supprimées ou modifiées par erreur. Ce processus n’implique pas de copier des données à partir de conteneurs Azure Blob, ce qui le rend très efficace. Une fois le volume restauré, il peut être utilisé pour des opérations de lecture/écriture, ce qui réduit considérablement la validation et le délai de mise sur le marché. Cela doit être utilisé en conjonction avec SCSQLAPI pour la cohérence de l'application. Cette approche fournit une autre technique d’optimisation continue des coûts avec Azure NetApp Files exploitant l’option Restaurer vers un nouveau volume.
Remarques :
-
Le volume créé à partir de la copie instantanée à l’aide de l’option Restaurer un nouveau volume consomme la capacité du pool de capacité.
-
Vous pouvez supprimer les volumes clonés à l’aide de REST ou d’Azure CLI pour éviter des coûts supplémentaires (au cas où le pool de capacité doit être augmenté).
Options de stockage hybride
Bien que NetApp recommande d'utiliser le même stockage pour tous les nœuds des groupes de disponibilité SQL Server, il existe des scénarios dans lesquels plusieurs options de stockage peuvent être utilisées. Ce scénario est possible pour Azure NetApp Files dans lequel un nœud dans AOAG est connecté à un partage de fichiers SMB Azure NetApp Files et le deuxième nœud est connecté à un disque Azure Premium. Dans ces cas, assurez-vous que le partage SMB Azure NetApp Files contient la copie principale des bases de données utilisateur et que le disque Premium est utilisé comme copie secondaire.
Remarques :
-
Dans de tels déploiements, pour éviter tout problème de basculement, assurez-vous que la disponibilité continue est activée sur le volume SMB. Sans attribut disponible en continu, la base de données peut échouer en cas de maintenance en arrière-plan au niveau de la couche de stockage.
-
Conservez la copie principale de la base de données sur le partage de fichiers SMB Azure NetApp Files .
Continuité des activités
La reprise après sinistre est généralement une réflexion après coup dans tout déploiement. Cependant, la reprise après sinistre doit être abordée lors de la phase initiale de conception et de déploiement pour éviter tout impact sur votre entreprise. Avec Azure NetApp Files, la fonctionnalité de réplication interrégionale (CRR) peut être utilisée pour répliquer les données de volume au niveau du bloc vers la région appariée afin de gérer toute panne régionale inattendue. Le volume de destination compatible CRR peut être utilisé pour les opérations de lecture, ce qui en fait un candidat idéal pour les simulations de reprise après sinistre. De plus, la destination CRR peut se voir attribuer le niveau de service le plus bas (par exemple, Standard) pour réduire le coût total de possession global. En cas de basculement, la réplication peut être interrompue, ce qui rend le volume respectif capable de lire/écrire. De plus, le niveau de service du volume peut être modifié en utilisant la fonctionnalité de niveau de service dynamique pour réduire considérablement les coûts de reprise après sinistre. Il s’agit d’une autre fonctionnalité unique d’ Azure NetApp Files avec réplication de blocs dans Azure.
Archive de copies d'instantanés à long terme
De nombreuses organisations doivent effectuer la conservation à long terme des données instantanées des fichiers de base de données en tant qu'exigence de conformité obligatoire. Bien que ce processus ne soit pas utilisé dans ce HLD, il peut être facilement réalisé en utilisant un simple script batch utilisant "AzCopy" pour copier le répertoire d’instantanés dans le conteneur Azure Blob. Le script batch peut être déclenché selon un calendrier spécifique à l'aide de tâches planifiées. Le processus est simple : il comprend les étapes suivantes :
-
Téléchargez le fichier exécutable AzCopy V10. Il n'y a rien à installer car c'est un
exedéposer. -
Autorisez AzCopy en utilisant un jeton SAS au niveau du conteneur avec les autorisations appropriées.
-
Une fois AzCopy autorisé, le transfert de données commence.
Remarques :
-
Dans les fichiers batch, assurez-vous d'échapper les caractères % qui apparaissent dans les jetons SAS. Cela peut être fait en ajoutant un caractère % supplémentaire à côté des caractères % existants dans la chaîne de jeton SAS.
-
Le "Transfert sécurisé requis" la configuration d'un compte de stockage détermine si la connexion à un compte de stockage est sécurisée avec Transport Layer Security (TLS). Ce paramètre est activé par défaut. L'exemple de script batch suivant copie de manière récursive les données du répertoire de copie Snapshot vers un conteneur Blob désigné :
SET source="Z:\~snapshot" echo %source% SET dest="https://testanfacct.blob.core.windows.net/azcoptst?sp=racwdl&st=2020-10-21T18:41:35Z&se=2021-10-22T18:41:00Z&sv=2019-12-12&sr=c&sig=ZxRUJwFlLXgHS8As7HzXJOaDXXVJ7PxxIX3ACpx56XY%%3D" echo %dest%
L'exemple de commande suivant est exécuté dans PowerShell :
–recursive
INFO: Scanning... INFO: Any empty folders will not be processed, because source and/or destination doesn't have full folder support Job b3731dd8-da61-9441-7281-17a4db09ce30 has started Log file is located at: C:\Users\niyaz\.azcopy\b3731dd8-da61-9441-7281-17a4db09ce30.log 0.0 %, 0 Done, 0 Failed, 2 Pending, 0 Skipped, 2 Total, INFO: azcopy.exe: A newer version 10.10.0 is available to download 0.0 %, 0 Done, 0 Failed, 2 Pending, 0 Skipped, 2 Total, Job b3731dd8-da61-9441-7281-17a4db09ce30 summary Elapsed Time (Minutes): 0.0333 Number of File Transfers: 2 Number of Folder Property Transfers: 0 Total Number of Transfers: 2 Number of Transfers Completed: 2 Number of Transfers Failed: 0 Number of Transfers Skipped: 0 TotalBytesTransferred: 5 Final Job Status: Completed
Remarques :
-
Une fonctionnalité de sauvegarde similaire pour la conservation à long terme sera bientôt disponible dans Azure NetApp Files.
-
Le script batch peut être utilisé dans n'importe quel scénario nécessitant la copie de données vers un conteneur Blob de n'importe quelle région.
Optimisation des coûts
Grâce au remodelage du volume et au changement dynamique du niveau de service, totalement transparent pour la base de données, Azure NetApp Files permet des optimisations continues des coûts dans Azure. Cette capacité est largement utilisée dans ce HLD pour éviter le surprovisionnement de stockage supplémentaire pour gérer les pics de charge de travail.
Le redimensionnement du volume peut être facilement réalisé en créant une fonction Azure conjointement avec les journaux d’alerte Azure.