Ce n'est un secret pour personne que je connais assez bien la solution de clustering de bases de données d'Oracle. Récemment, j'ai terminé une solution de clustering SQL Server haute disponibilité qui a pris deux ans, de la conception initiale à la mise en œuvre finale. Ce processus impliquait la documentation des exigences, la détermination des options, la mise en correspondance des exigences avec les détails de mise en œuvre, la budgétisation, l'approvisionnement, l'installation, la configuration et les tests.
Maintenant que mon projet est terminé, j'ai pensé donner quelques éléments sur le clustering de SQL Server du point de vue d'un gars d'Oracle RAC. Nous savons tous que SQL Server et Oracle sont tous deux des moteurs RDBMS et qu'ils peuvent avoir certaines choses en commun. Mais ce sont aussi des créatures complètement différentes. Donc, si vous êtes à l'aise avec Oracle Grid Infrastructure, RAC et Data Guard, et que vous envisagez de mettre en œuvre une solution SQL Server HA, cela vous fournira peut-être de bonnes informations.
Notre système de production actuel est une base de données principale Oracle RAC à 4 nœuds. Cela offre une haute disponibilité (et des performances élevées) au sein de notre centre de données principal. Nous utilisons Data Guard pour transporter la restauration vers une base de données de secours physique RAC à 3 nœuds. Même si SQL Server <> Oracle, je voulais garder notre configuration aussi similaire que possible pour faciliter l'administration. Nous avons donc déployé un cluster de basculement SQL Server à 2 nœuds sur notre site principal et une base de données "de secours" à 1 nœud sur notre site DR.
Passons maintenant à mes observations, sans ordre particulier.
- La solution de clustering HA de SQL Server est active/passive. Oracle est actif/actif, ce qui pour moi est "meilleur", et oui... c'est un terme subjectif. Pour notre implémentation active/passive, je n'aimais pas l'idée de deux serveurs physiques assis là avec un essentiellement inactif tout le temps. Nous avons donc un serveur physique qui est le nœud "préféré" et un serveur virtuel. Si le serveur physique tombe en panne, le clustering basculera automatiquement l'instance SQL Server vers le serveur virtuel et nous serons à nouveau opérationnels. Ce cluster actif/passif ne traite pas l'évolutivité comme le fait Oracle RAC, mais il me donne une plus grande disponibilité dans notre environnement principal.
- La mise en œuvre du clustering est extrêmement simple. Activez le clustering au niveau du système d'exploitation. Comme il s'agit d'une pile entièrement Microsoft, ils ont intégré le clustering dans le système d'exploitation. Il est déjà là pour vous. Il vous suffit de l'allumer. Ensuite, lancez Outils d'administration -> Gestionnaire de cluster de basculement et des assistants vous guident tout au long de la configuration. C'est beaucoup plus facile que d'installer Grid Infrastructure. Mais Oracle doit faire face à différentes plates-formes de système d'exploitation, ce qui rend les choses plus difficiles là-bas. Il sera intéressant de voir comment SQL Server 2016 sur Linux gère le clustering de basculement.
- Oracle utilise un modèle de disque partagé alors que SQL Server est Shared Nothing. Mais vous devez utiliser le "disque partagé" d'une certaine manière car le disque doit être disponible sur les deux nœuds. Cependant, MS Failover Clustering (MSFC) monte le disque en cluster sur le nœud actif. Lorsque SQL Server est déplacé vers l'autre nœud, automatiquement ou manuellement, MSFC démonte le disque sur un nœud puis le monte sur l'autre. C'est un peu étrange d'avoir une fenêtre de l'Explorateur Windows ouverte et de voir le disque apparaître ou disparaître pendant cette transition.
- Grid Infrastructure utilise le disque de vote pour les opérations de quorum. Dans MSFC, vous pouvez avoir un disque Quorum, utiliser un partage de fichiers ou configurer sans quorum. Si vous optez pour ce dernier, vous entravez votre capacité de basculement automatique.
- J'ai l'habitude que mon serveur principal ait son propre cluster et le serveur de secours son propre cluster. Avec SQL Server, les nœuds principaux et les nœuds de secours doivent faire partie du même cluster. Heureusement, le cluster peut traverser des sous-réseaux, ce qui est différent d'Oracle GI. L'ajout du nœud de secours était super facile, nous avons juste supprimé ses droits de vote et nous n'avons pas configuré le disque quorum pour le nœud de secours. Cela nous convenait car nous souhaitions que le basculement vers la veille soit une opération manuelle.
- Pour une base de données de secours, vous pouvez utiliser la mise en miroir de bases de données, l'envoi de journaux ou les groupes de disponibilité AlwaysOn (AG). Les deux premiers sont sur le point de partir alors je suis allé avec les AG. Les groupes de disponibilité exigent que le nœud de secours fasse partie du même cluster que le nœud principal. Un assistant vous guide dans la configuration des bases de données pour participer à l'AG. C'est beaucoup plus facile que de configurer un serveur de secours physique Oracle.
- Pour ceux d'entre vous qui détestent la documentation Oracle, il est temps d'être reconnaissant. Plusieurs fois au cours de ce processus, j'ai constaté que la documentation MS manquait de très gros morceaux. Par exemple, je n'ai jamais découvert comment configurer mon nœud de secours pour qu'il n'ait aucun droit de vote. Heureusement, nous avons pu cliquer dessus.
En fin de compte, la mise en œuvre de la solution SQL Server n'a pas été si difficile. Parfois, je devais compter sur ma connaissance du clustering. D'autres fois, la terminologie de Microsoft a gêné. Par exemple, le reste du monde l'appelle "split brain" mais MS l'appelle "split cluster". Parfois, surmonter les différences de lexique était le plus gros obstacle.
