Que ce soit au sein de grandes entreprises ou bien dans toute PME/TPE, les systèmes informatiques tendent à être de plus en plus critiques.
Il est rare aujourd’hui d’installer un logiciel de messagerie tel qu’Exchange Server sans penser à la haute disponibilité. Qu’en est-il des bases de données ? Votre intranet Sharepoint s’appuie sur une base SQL Server. Des logiciels de comptabilité, de paye, des applications de CRM, des sites web, des applications spécifiques s’appuient sur des bases SQL Server. Quel est l’impact de non disponibilité de ces bases de données sur l’activité métier et sur les résultats commerciaux de l’entreprise ? Après avoir rapidement abordé les causes de non disponibilité, nous allons faire un tour d’horizon des solutions de haute disponibilité SQL Server.
La mise en miroir d’une base de données est une solution de haute disponibilité apparue avec SQL Server 2005 SP1. La mise en miroir d’une base permet d’obtenir deux exemplaires d’une base de données. Le premier exemplaire est stocké sur le serveur principal. Le second exemplaire, sur le serveur miroir, est une copie, non opérationnelle, à moins de créer une capture instantanée de la base. Ce « database snapshot » permettra un accès en lecture seule de la base miroir. Le serveur principal et le serveur miroir collaborent en tant que serveurs partenaires dans une session de mise en miroir de bases de données. Lors de cette session, chaque serveur à un rôle, principal ou miroir, qui peut être inversé à tout moment. Une session de mise en miroir de bases de données s’exécute de manière synchrone ou asynchrone. En fonctionnement asynchrone, les transactions sont validées sans attendre que le serveur miroir enregistre le journal sur disque. Ce mode est appelé mode haute performances.
En général, l’écart entre les deux bases est relativement faible, mais peut devenir plus conséquent si la charge du serveur principal est élevée. Auquel cas, si le rôle change, il se peut qu’il y ait une légère perte de données. En fonctionnement synchrone, une transaction est validée sur les deux serveurs partenaires, mais au prix d’une latence accrue des transactions. D’un point de vue client, la transaction a duré plus longtemps. Dans ce modèle haute disponibilité, les deux bases sont exactement au même niveau, ainsi en cas de changement de rôle, il n’y a pas de perte de données.
Il existe aussi la possibilité d’ajouter un serveur témoin à cette architecture. Ce serveur prend à sa charge la surveillance du serveur principal et va déclencher le changement de rôle en cas de détection de problème. Cette solution de haute disponibilité est accessible depuis la version standard de SQL Server. Les versions groupe de travail et express, quant à elles, ne peuvent supporter que le rôle de témoin. Il est intéressant de noter que le stoc-kage n’est pas le point unique de défaillance. Les données sont dupliquées sur des disques distincts. Contrairement à un cluster, où le nom virtuel de l’instance est unique, ici, l’application va devoir être informée du statut spécial de la base mise en miroir. Il faut que le driver d’accès aux données (ADO.Net par exemple) supporte la fonctionnalité en intégrant la notion de « failover partner » dans la chaîne de connexion afin de rendre totalement transparent un changement de rôle.
Téléchargez cette ressource
Comment sécuriser une PME avec l’approche par les risques ?
Disposant de moyens financiers et humains contraints, les PME éprouvent des difficultés à mettre en place une véritable stratégie de cybersécurité. Opérateur de services et d’infrastructures, Naitways leur propose une approche pragmatique de sécurité « by design » en priorisant les risques auxquelles elles sont confrontées.
