SQL Azure – Doit-on se préoccuper de la haute disponibilité ?

Si vous suivez ce blog, il ne vous aura pas échappé qu’une partie conséquente de mon activité de consultant indépendant est liée à la haute disponibilité de SQL Server. Que ce soit sur des machines physiques ou virtuelles, dans vos datacenters ou bien externalisé, voire hébergées sur un cloud public, la disponibilité de votre instance, de votre base ou bien d’une table revêt toute son importance … quand vous ne pouvez pas y accéder.

C’est un exercice très compliqué à réaliser, mais il est fondamental de quantifier l’indisponibilité de votre instance ou de votre base. Beaucoup de questions à se poser, j’utilise cette diapositive lors de mes formations et interventions, pour obtenir un maximum d’information. Une grande partie des réponses est issue du Business, côté technique on doit s’adapter.

Une fois l’indisponibilité quantifiée, en $ ou €, vous êtes en mesure de décider s’il est rentable / important de mettre en HA votre base de données, car la HA a forcément un coût, ainsi qu’un impact potentiel sur la performance de l’application.

OnPrem, ou bien en IaaS sur un cloud public, vous avez donc le choix entre du Cluster de Basculement ou bien des Groupes de Disponibilité. Je parle de HA, donc exit le Log Shipping qui est une solution de Disaster Recovery. En fonction de la granularité de protection, de la nécessité de disposer d’un RPO nul, d’un RTO très faible, de modèle de récupération simple, vous allez choisir entre du FCI ou AGs.

Sur le un Cloud Public tel qu’Azure, le problème se corse, car le niveau de service (SLA) promis est déjà élevé, généralement au moins de 99.9% voire 99.995%.

Ce qui, reporté au fameux tableau des « Nine », nous donne une indisponibilité annuelle comprise entre 52 minutes et 26 minutes pour un niveau de service General Purpose / Standard / Basique …. Est-ce suffisant ? Probablement dans une très grande majorité de cas.

Il faut bien faire la différence entre disponibilité et Uptime. L’OS et SQL Server peuvent être Up and Running, mais la disponibilité comprend également la capacité d’accéder à une donnée dans un temps imparti : par exemple, tel select doit se faire en x millisecondes ou secondes. On entrevoit donc l’impact sur la disponibilité d’un plan de maintenance qui reconstruit des index cluster sur une édition standard : le rebuild est offline ! Le tableau nous parles certes de disponibilité, mais globalement cela couvre Hardware+Network+OS+Service SQL.

On vous garanti l’accès à la donnée, ce que vous en faites est une autre histoire. Si vous avez des locks ou des performances qui ne sont pas au niveau attendu, cela n’est pas couvert par le SLA.

Mais ….

Que se passe t’il si votre base devient inaccessible durant …. 11 heures ? Les provider cloud ne sont pas a l’abris de tout problème, ils essaient seulement de prendre en considération plus de risque que vous dans votre Datacenter et s’en protègent du mieux qu’ils peuvent. Cependant, l’imprévu est toujours possible.

Imaginez que, le Lundi 14 septembre 2020, à compter de 13h30, votre base soit injoignable, et ce jusqu’à 00h41 le 15/09 … C’est ce qu’il s’et passé, sur la région UK South … Et ce n’est pas une seule base qui a été impacté, mais la connectivité globale de la région ! 11 heures d’indisponibilité, malgré la promesse d’un SLA de 99,99 %.

Microsoft n’est pas le seul cloud provider à avoir expérimenté de tels problèmes…

Il est donc important de ne pas se fier totalement au SLA annoncé et conserver les réflexes de haute disponibilité… D’un point de vue Azure, cela se traduit par des services redondants à l’intérieur d’une région (Availability Zones) voire inter régions (Regions pairs : France Central + France Sud par exemple).

Traduit pour SQL Server en mode PaaS, cela se présente sous forme de Géo-Réplication, Failover Groups et redondance de zone, ce dernier point étant encore en preview. Je ne traite pas le cas de la Managed Instance, mais sachez que la redondance de zone et les groupes de basculement automatiques sont disponibles.

Chacune de ces fonctionnalités a ses avantages et inconvénients. Le slide suivant, que j’utilise lors des formations, permet de visualiser rapidement les principales différences entre la géo-réplication et les groupes de basculement automatiques.

Je ne vous cache pas que le fait de disposer d’un failover automatique et d’une chaine de connexion inchangée pour un ensemble de bases me fait préférer le failover group. Mais il reste limité à 1 seul réplica secondaire, qui est cependant accessible en lecture seule pour offloader le reporting par exemple. Vous aurez reconnu un groupe de disponiblité, et, effectivement, les failover groups en sont dérivés.

Comme dit précédemment, la HA peut avoir un coût. La géo réplication tout comme les failover groups nécessitent la création d’une base ou d’un pool élastique. Il y a un coût additionnel.

Si vous n’avez pas besoin d’un réplica en lecture seule mais que vous souhaitez disposer d’une solution de continuité d’activité en niveau de service General Purpose, alors la redondance de zone est faite pour vous.

Sachant qu’en niveau General Purpose, le compute et le storage sont séparés, il est alors simple de déposer les fichiers MDF/LDF sur un stockage géographiquement redondant : des disques Azure Premium Storage ZRS (Zone Redundant). Ainsi en cas de problème sur une zone, une bascule automatique de zone sera effectuée. Si votre application suit les mêmes règles de disponibilité, par exemple vos VMs dans 2 ou 3 availability zones, la continuité de service est assurée.

Je ne l’ai pas encore mentionné mais la redondance de zone est également disponible sur les pools élastiques.

La capture montre le SLO General Purpose, mais cette option est bien entendu également disponible en Business Critical, bien qu’implémentée techniquement de manière différente car le BC utilise un stockage local SSD.

L’incident UK South donné en exemple ne concernait qu’une seule zone, en utilisant ce principe, notre base de données n’aurait subi qu’une légère perte de service, le temps de basculer les ressources vers la seconde zone.

Conclusion : oui, il faut encore se préoccuper de la haute disponibilité, même lorsque l’on est hébergé sur un cloud public.

Happy cloud HA !