L’exécution de SQL Server dans le cloud peut offrir 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 en permanence 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 : indisponibilité de la base de données, perte de données et autres problèmes qui peuvent causer de gros maux de tête aux administrateurs de base de données (DBA) SQL Server.

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

Similaire  404 Page non trouvée

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 ou plusieurs instances de SQL Server sont regroupées dans un ensemble à haute disponibilité composé de plusieurs machines virtuelles (VM), selon Bermingham. Si vous ne configurez qu’une seule instance, vous pourriez vous retrouver avec rien d’autre qu’une « tonalité », a-t-il déclaré. « C’est ping-able, c’est en ligne, mais cela 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 temps d’arrêt alléchant de 4,5 minutes – ou une disponibilité de 99,99 % – par mois, a déclaré Bermingham. Mais à l’instar du SLA d’Azure, la garantie de disponibilité ne s’applique qu’à deux ou plusieurs instances de base de données couplées l’une à l’autre, 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. Toutefois, 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 au disque persistant 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 de système

Bien que le cloud puisse être une ressource utile, il est important de reconnaître que les services cloud peuvent échouer, et échouent parfois. É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é Bermingham. « Planifiez la manière dont vos applications se connectent à SQL [Server] et comment vos clients se connectent à vos applications. »

Une perte inattendue du service Internet est un point de défaillance unique que les utilisateurs devront trouver un moyen de gérer 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. Étant donné 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 aider à 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 différentes manières, du catastrophique au banal. Les catastrophes naturelles comme 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é.

Bénéficiez d’outils de haute disponibilité

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

« 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é Bermingham dans le webinaire, qui a été publié sur le site Web MSSQLTips.com. Il a souligné les fonctionnalités de haute disponibilité de 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, les groupes de disponibilité Always On et les 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 lient un ensemble de bases de données principales à jusqu’à huit ensembles correspondants de bases de données secondaires qui sont configurées pour basculer ensemble en cas de panne. Étant donné 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 utiliser 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 noté, cependant, 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é de clustering de basculement Windows Server (WSFC) de Microsoft pour fournir une protection haute disponibilité pour l’intégralité d’une instance SQL Server. Une instance de cluster de basculement est déployée sur plusieurs nœuds WSFC pour la redondance en cas de panne. En conséquence, les administrateurs de base de données ne sont pas tenus de gérer la disponibilité ou de conserver les mots de passe et les noms d’utilisateur sur plusieurs instances, a déclaré Bermingham.

Chaque fournisseur de plate-forme cloud propose é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 Azure Managed Disksun 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.