SQL Azure sous le capot

Une session de Jeff Currier, Senior Dev Lead.

Il y a eu des changements majeurs dans le service depuis ce qui a été présenté à la PDC l’année dernière.

Modèle conceptuel:

• Un abonnement permet de faire correspondre l’usage à une facturation; un compte peut avoir plusieurs abonnements
• Serveur “logique”: comme une instance SQL Server, unité de géo-localisation et de facturation; relation 1-1 entre abonnement et serveur logique
• Base de données: avec un usage restreint de T-SQL, ainsi que des vues catalogue additionnelles comme firewall_rules, bandwidth_usage, etc.

L’on voit alors la topologie réseau du service. Les librairies client classiques (ADO.NET, etc.) parlent à un équilibreur de charge qui redirige les sessions TDS. On a alors une couche de passerelles qui renvoient les sessions TDS vers les serveurs SQL.

Que fait cette passerelle TDS? (Le protocole TDS est ouvert)

• Le Listener TDS gère les aspects sécurité, inspecte les paquets pour vérifier leur validité d’un point de vue sécurité et gère la partie Login.
• La passerelle utilise un catalogue de données pour faire la relation vers le serveur SQL physique où se trouve la base
• C’est un niveau de défense

L’on a des points d’accès TDS, ainsi que des services SOAP pour l’administration et le provisioning. Puis, une logique qui inspecte le protocole TDS et prend les décisions.

Ajout de serveurs:

• Initié depuis le Portail d’administration
• La passerelle reçoit une requête
  • l’on ajoute l’info dans le catalogue de métadonnées
  • l’on crée l’enregistrement DNS
  • l’on crée la Master DB
• A la fin, le catalogue de métadonnées est complété

Création de bases: très similaire, mais l’on peut aussi le faire depuis T-SQL. Dans ce cas l’inspection de protocole isole les messages concernant les créations de bases et intercepte la demande pour gérer la création. L’on prend une partition prête à l’emploi, (buffer pool) et l’on marque l’entrée dans le metadata catalog. L’on isole également les instances de secours.

Le processus de login SQL Azure est spécifique car la passerelle intercepte la demande au niveau protocole pour valider les credentials auprès de la bonne MasterDB et initie la connexion TDS.

Jeff montre une passerelles tournant sur sa machine de développement, ce qui nous permet de voir le processus de connexion en traçant les paquets TDS!

Surveillance du service:

• Des compteurs sont utilisés au niveau du cluster
• Ces valeurs sont utilisées pour notifier les équipes d’exploitation avant qu’un problème n’apparaisse
• Des agents exécutent des actions de routine pour tester la santé des noeuds, et en cas de problèmes lancent des diagnostics approfondis (réseau, dépendances, …)
• La surveillance se fait égalememnt entre différents centre d’hébergements, ce qui permet de mesure des éléments comme la latence réseau, etc.

En termes de sécurité:

• SSL est obligatoire, on trace les attaques de type DOS, et l’on inspecte les paquets
• L’on a un firewall intégré avec les IP autorisées, l’on coupe les connexions inutilisées, les noms de serveurs sont générés aléatoirement
• Les uid les plus attaqués sont désactivés (SA, Admin, root, guest, etc.), et l’on s’appuie sur l’authentification/autorisation standard SQL Server