Accueil › Serveur d'impression › Meilleures pratiques SQL Server haute disponibilité dans le cloud – Bien choisir son serveur d impression
Serveur d'impression

Meilleures pratiques SQL Server haute disponibilité dans le cloud – Bien choisir son serveur d impression

Le 5 février 2020 - 7 minutes de lecture

L'exécution de SQL Server dans le cloud peut donner aux utilisateurs du logiciel de base de données plus de flexibilité et d'évolutivité que les déploiements sur site – et peut-être aussi leur faire économiser de l'argent. Mais les choses tournent souvent mal avec les systèmes cloud, ce qui oblige à se concentrer sur la haute disponibilité et la reprise après sinistre.

C'est le message délivré par David Bermingham, évangéliste technique senior chez SIOS Technology Corp., dans un webinaire produit par la société de logiciels de gestion de cluster SQL Server. Bermingham a détaillé un ensemble de meilleures pratiques de haute disponibilité SQL Server pour les utilisateurs du cloud, tout en comparant et en contrastant les fonctionnalités de haute disponibilité offertes par Microsoft Azure et les clouds AWS et Google.

Une solide stratégie de haute disponibilité peut aider à créer un flux de travail efficace, une disponibilité fiable et des procédures de reprise après sinistre efficaces pour les systèmes SQL Server basés sur le cloud, a déclaré Bermingham. L'alternative est moins agréable: temps d'arrêt de la base de données, perte de données et autres problèmes pouvant causer de gros maux de tête aux administrateurs de base de données SQL Server (DBA).

Voici quelques-unes des meilleures pratiques de haute disponibilité de SQL Server recommandées par Bermingham.

Lisez les petits caractères avant d'utiliser une plateforme cloud

L'accord de niveau de service (SLA) d'Azure promet seulement 22 minutes d'indisponibilité de la base de données par mois. Cependant, cela ne s'applique que lorsque deux instances ou plus de SQL Server sont regroupées dans un ensemble de disponibilité composé de plusieurs machines virtuelles (VM), selon Bermingham. Si vous ne configurez qu'une seule instance, vous pourriez vous retrouver avec "une tonalité", at-il dit. "Il est capable de faire un ping, il est en ligne, mais il ne garantit pas que le stockage est disponible."

David Bermingham, évangéliste technique senior chez SIOS TechnologyDavid Bermingham

Dans son SLA pour les systèmes SQL Server, AWS promet un alléchant temps d'arrêt de 4,5 minutes – ou 99,99% de disponibilité – par mois, a déclaré Bermingham. Mais similaire au SLA d'Azure, la garantie de disponibilité ne s'applique qu'à deux ou plusieurs instances de base de données qui sont couplées les unes aux autres, a-t-il ajouté.

Google Cloud Platform ne promet également que 4,5 minutes d'indisponibilité de la base de données par mois, a déclaré Bermingham. Cependant, il a noté que la définition de temps d'arrêt dans le SLA de Google est une "perte de connectivité externe ou d'accès persistant au disque pour toutes les instances en cours d'exécution" dans un déploiement avec des instances placées sur deux zones ou plus dans la même région de calcul.

Soyez prêt pour les pannes du système

Bien que le cloud puisse être une ressource utile, il est important de reconnaître que les services cloud peuvent – et parfois échouent -. Étant donné que le cloud n'est pas infaillible, les meilleures pratiques de haute disponibilité de SQL Server décrites par Bermingham incluent la mise en place d'un plan d'urgence en cas de panne.

"Vous devez vous assurer que vous disposez d'un accès Internet redondant", a déclaré M. Bermingham. "Prévoyez comment vos applications se connectent à SQL [Server] et comment vos clients se connectent à vos applications. "

Une perte inattendue de service Internet est un point de défaillance unique que les utilisateurs devront trouver un moyen de faire face ou de contourner, a-t-il ajouté.

Une autre chose à prendre en considération est l'utilisation de plusieurs zones de disponibilité pour un déploiement de SQL Server dans le cloud. Parce qu'il est tout à fait possible qu'une zone de disponibilité devienne complètement sombre, Bermingham a recommandé de déployer des bases de données sur plusieurs zones pour compenser une panne complète en une seule.

Bermingham a également souligné l'importance de mettre en place un plan de reprise après sinistre, car les données dans le cloud peuvent être perdues de diverses manières – du catastrophique au banal. Les catastrophes naturelles telles que les incendies et les inondations peuvent détruire ou endommager les serveurs physiques qui contiennent des données importantes, mais "la plupart des pannes que nous avons vues sont dues à une sorte d'erreur humaine", a-t-il déclaré.

Profitez des outils de haute disponibilité

Lors de la mise en œuvre des meilleures pratiques de haute disponibilité de SQL Server pour les systèmes basés sur le cloud, des mesures doivent être prises pour garantir que les données importantes restent disponibles pour une utilisation, peu importe quoi.

"Si vous exécutez SQL Server dans le cloud, vous gérez toujours [it]et vous devez vous assurer qu'il reste en ligne ", a déclaré M. Bermingham lors du webinaire, qui a été publié sur le site Web MSSQLTips.com. Il a souligné les fonctionnalités de haute disponibilité dans SQL Server qui peuvent aider les administrateurs de base de données à le faire à la fois sur site et dans le cloud. systèmes – par exemple, Groupes de disponibilité Always On et Instances de cluster de basculement Always On.

Si vous exécutez SQL Server dans le cloud, vous gérez toujours [it]et vous devez vous assurer qu'il reste en ligne.

David Berminghamévangéliste technique senior, SIOS

Introduits dans SQL Server 2012, les groupes de disponibilité Always On associent un ensemble de bases de données primaires à huit ensembles correspondants de bases de données secondaires configurés pour basculer ensemble en cas de panne. Parce que SQL Server s'exécute sur chaque instance, la technologie permet un basculement très rapide, a déclaré Bermingham.

Il a ajouté que les réparations de page peuvent être effectuées automatiquement sans l'utilisation de produits tiers et que les administrateurs de base de données peuvent effectuer des sauvegardes et exécuter des rapports sur les systèmes secondaires. Bermingham a cependant noté que les groupes de disponibilité Always On ne protègent que les bases de données utilisateur, pas les bases de données système utilisées pour gérer et maintenir SQL Server.

Les instances de cluster de basculement Always On utilisent la fonctionnalité WSFC (Windows Server Failover Clustering) de Microsoft pour fournir une protection haute disponibilité pour une instance SQL Server entière. Une instance de cluster de basculement est déployée sur plusieurs nœuds WSFC pour la redondance en cas de pannes. En conséquence, les administrateurs de base de données ne sont pas tenus de gérer la disponibilité ou de maintenir les mots de passe et les noms d'utilisateur sur plusieurs instances, a déclaré Bermingham.

Chaque fournisseur de plate-forme cloud fournit également des options pour gérer la disponibilité du stockage dans les systèmes SQL Server, a-t-il déclaré. Par exemple, Microsoft propose des disques gérés Azure, un logiciel publié en 2017. Entre autres fonctionnalités, Azure Managed Disks réduit les pannes de stockage potentielles pour les machines virtuelles Azure dans un ensemble de disponibilité en répartissant les données sur différentes unités de stockage.

Articles relatifs:

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.