Blog

Aujourd’hui, je vais parler de la haute disponibilité de SQL Server dans un environnement AX, en utilisant Microsoft SQL Server 2008 R2 et Microsoft Dynamics AX 2009. Je vais expliquer comment fonctionne des bases de données en miroir, du clustering avec basculement et l'envoi de journaux de transactions sont utilisés et si oui ou non ces modèles sont viables pour un environnement AX.

Le mode de base de données en miroir conserve la base de données miroir en mode de récupération, prête à basculer presque instantanément. Le fait que la base de données est en mode de récupération signifie qu'elle n'est pas accessible par les clients. Les deux modes possibles pour l’écriture vers un système de bases de données en miroir sont synchrones (haute sécurité) et asynchrones (haute performance). Synchrone signifie que la transaction est réalisée sur la base de données miroir en premier, et est ensuite réalisée sur la base de données principale. Parce que la transaction est appliquée à la base de données miroir d'abord, on s'assure que le miroir est le plus à jour possible, ce qui rend le modèle plus sûr mais plus lent. Asynchrone signifie que la transaction est réalisée sur la base de données principale d'abord, puis sur la base de données miroir. Parce qu'il n'a pas à attendre pour le miroir pour terminer premier, il est plus rapide mais moins sûr. Pour avoir un basculement automatique, il vous faut un serveur témoin dans votre configuration qui surveille la base de données principale et la base de données miroir. Malheureusement, dans un environnement AX, le basculement automatique n'est pas possible parce que l'AOS ne sait pas que le basculement a été fait. Pour faire le basculement manuel, vous devez modifier la configuration du serveur sur votre AOS pour pointer vers la base de données miroir. Lorsque le principal est déconnecté, vous devez arrêter l'AOS (si elle n'a pas déjà stoppé), changer la configuration du serveur AX pour pointer vers la base de données miroir, et commencer à l'AOS sauvegarder. Ensuite, tous les clients AX doivent être redémarrés. Même s’il n'y a pas de basculement automatique possible pour un environnement AX mis en miroir, il fait tout de même parti des solutions viables de haute disponibilité SQL à faible coût. Pour plus d’informations à propos des bases de données en miroir, référez-vous au lien ICI.

Le clustering avec basculement dans SQL utilise le service Microsoft Cluster (nécessite l’édition Entreprise de Windows Server). Vous créez le cluster en installant le service mentionné sur chacun des serveurs qui feront partie du cluster. Ces serveurs seront ensuite appelés nœuds. Une fois cela fait, vous installez SQL Server sur chaque nœud. Lors de l'installation, vous spécifiez une instance nommée ou celle par défaut, et vous point les répertoires sur des disques partagés. Puis, quand vous faites l'installation de AX, vous installez la base de données sur le cluster lui-même (c.-à-d., CLUSTER\MSSQLSERVER) et non sur un nœud individuel (c.-à-d., NODE1\MSSQLSERVER). Cette configuration associée à un équilibrage de charge des serveurs AOS serait le modèle de haute disponibilité idéal à mon avis. Chaque fois qu'un nœud tombe en panne pour une raison quelconque, la charge est transférée vers un autre nœud de manière transparente. L'inconvénient de ce modèle est le coût très élevé. Vous avez besoin d'une licence pour chaque serveur pour Windows et aussi pour SQL. Pour plus d’informations à propos du clustering avec basculement dans SQL, référez-vous au lien ICI.

L'envoi de journaux de transactions est au niveau base de données. Il utilise une base de données appelée la base de données principale et une ou plusieurs bases de données appelées bases de données secondaires. L'envoi de journaux est un processus en trois étapes. Tout d'abord, une sauvegarde du journal des transactions est effectuée sur la base de données principale. Deuxièmement, il envoie les sauvegardes du journal sur le serveur hébergeant la base de données secondaire. Troisièmement, le journal des transactions est restauré sur la base de données secondaire. Vous répétez ces étapes sur une base régulière (par exemple, toutes les 15 minutes). L'avantage est que la base de données secondaire est en attente (warm standby), ce qui signifie qu'elles peuvent être interrogées (limitée). Ainsi, par exemple, dans un environnement AX, vous pouvez exécuter vos cubes sur la base de données secondaire sans affecter les performances des clients AX puisqu’ils se connectent sur la base de données principale. Dans cette configuration, si la communication vers la base de données primaire échoue, vous devez  faire une sauvegarde de queue du journal de transaction (tail log) et manuellement l'appliquer à la base de données secondaire avec récupération comme option (WITH RECOVERY). Après avoir fait la restauration, vous devez modifier la configuration de serveur AX de l’AOS (même chose que pour les bases de données en miroir) et les clients AX doivent être redémarrés. Il n'y a pas de basculement automatique disponible pour cette méthode, mais vous pouvez utiliser les bases de données secondaires (warm standby). Cela fait de ce modèle une option viable pour un environnement AX. Pour plus d’informations, référez-vous au lien ICI.

En fin de compte, tous les modèles de haute disponibilité ont leurs bons et mauvais côtés. Les bases de données en miroir prennent du temps pour faire le passage du serveur primaire vers le serveur secondaire, il n'y a aucune perte de données, et il est peu couteux. Le serveur secondaire doit être en mode de récupération ce qui signifie qu'il est inutilisable pendant cette période. Le clustering avec basculement fait le basculement automatiquement et instantanément sans perdre de données, mais le coût de ce modèle est très élevé. L'envoi de journaux vous permet d'utiliser le serveur secondaire pour certains types de requêtes et est peu couteux aussi, mais il est possible de perdre des données (le maximum serait le délai entre vos sauvegardes de journaux) et prend du temps pour faire le changement de configuration manuellement. En terminant, gardez à l'esprit qu'aucun modèle de haute disponibilité est bon s’il n’est pas couplé avec une bonne stratégie de sauvegarde.

Simon Loiselle