Production SQL Server: Suivi et Contrôle du parc

Mercredi, mai 2, 2012
By Benjamin VESAN in SQL Server (bvesan@capdata-osmozium.com) [41 article(s)]

Huitième article de la série Une approche pragmatique de la production SQL Server, il est question ici de suivre le parc d’instances SQL Server.

Ce sujet est bien trop vaste pour un billet de blog, je me contenterai donc d’aborder le sujet.

Que suivre ?

L’objectif du suivi est double : s’assurer que le Service « disponibilité de la base de données » est offert à l’utilisateur, et Maîtriser les instances du parc afin que leur exploitation reste simple. Les points à suivre sont donc disponibilité et performance pour la partie Service, et maintient de la configuration pour la partie Maîtrise.
Disponibilité :

  • L’instance tourne et accepte les connexions des utilisateurs sur les différentes bases
  • Les bases utilisateurs sont pleinement opérationnelles (pas de corruption de données, pas de problème de saturation d’espace)
  • Le temps de réponse des requêtes est satisfaisant (performances acceptables)

Maîtrise :

  • La configuration de chaque instance/machine est connue, ainsi que son évolution dans le temps
  • Chaque instance déployée est suivie

Pour répondre à ces besoins, il existe, entre autres, deux approches : Le développement interne, et les outils Microsoft.

Le développement interne
Il est possible et relativement simple de mettre en place une gestion centralisée de votre parc.
Une base de données sur une instance SQL Server, une dizaine de tables, et vous disposez d’un référentiel contenant les informations de chaque instance déployée.
Via l’utilisation de serveurs liés, vous pouvez simplement depuis votre instance de gestion consulter les données de chaque instance du parc, donc récupérer les informations de configuration, volumétrie et performance de ces instances.
Via les rapports SQL Server (construits graphiquement avec report Builder 3), vous avez la possibilité de générer des tableaux de bord reprenant les informations collectées.

Avantages :

  • le référencement peut être scripté dans votre procédure de déploiement, ce qui le rend automatique.
  • Votre base de gestion peut être hébergée par une instance en édition Express de SQL Server, donc pas de coût de licence.
  • Puisqu’il s’agit d’un développement interne, l’ajout de fonctionnalités (gestionnaire de sauvegardes/restaurations, rapports personnalisés, ) est possible. Vous disposez en outre d’un référentiel unique, donc pas de problème de redondance d’information et de maintient de cohérence entre sources différentes.

Inconvénients :

  • Outre la partie base de données, cette méthode requiert des connaissances de programmation (php, asp), ne serait-ce que pour obtenir une interface graphique descente.

Outils Microsoft
Plusieurs outils de Microsoft, intégrables à la console Management Studio, offrent des fonctionnalités intéressantes pour le suivi :

SQL Server Utilities permet de collecter et d’historiser les compteurs de performance de vos instances SQL Server.  Il offre en outre un tableau de bord orienté « état de santé de l’utilisation des instances » donnant une vue synthétique de l’utilisation des ressources de vos instances.  Plusieurs rapports fournis donnent une vue historique des performances d’une instance. SQL Server Utilities fonctionne pour des instances en version 2008R2 et supérieure.

Avec Management Policies, un modèle de  configuration est créé et peut être évalué régulièrement sur les instances du parc. Lorsque des différences entre le modèle et l’instance sont trouvées, elles peuvent être notifiée ou corrigée automatiquement. Plusieurs modèles (en fonction des versions de SQL Server, par exemple) peuvent être définis.
Le modèle peut contenir des conditions sur une instance(paramètres de configuration),  ses objets (logins, serveurs liés, endpoints, …), une base et ses objets (options de la base, tables, procédures stockées, indexes,…).
Il est donc possible par exemple de vérifier qu’aucun login autre que ceux des DBAs ne dispose du privilège sysadmin, que le nom des tables et procédures stockées des bases utilisateurs suit la politique de nommage, et qu’il existe bien une clé primaire pour chaque  table utilisateur.

Dans un Central Management Server, vous enregistrez la chaîne de connexion vers une instance SQL Server. Dans Management Studio, la liste des instances SQL Server référencées (panneau Registered Servers) peut inclure un ou plusieurs Central Management Servers. Donc lorsqu’une nouvelle instance SQL Server est déployée, il suffit de la référencer dans l’un de ces Servers pour que tous les DBAs de l’équipe puissent s’y connecter.

Le mécanisme de Job Multi Serveurs MSX/TSX vous permettra de créer un job unique par type de tâche et de le « pousser » sur toutes les instances de votre parc. Les jobs sont automatiquement mis à jour sur les instances du parc lorsque vous modifiez le job de référence, et déployer les jobs sur une nouvelle instance consiste simplement à référencer cette instance dans MSX.

Avantages :

  • Ces mécanismes s’interfacent avec SQL Server Management Studio, leur utilisation est donc simplifiée.

Inconvénients :

  • Vous multipliez les référentiels, il peut être délicat de les maintenir tous à jour.

Comment gérer les déploiements/suppressions d’instances ?

Que ce soit via un développement interne ou avec les outils Microsoft, si votre référentiel n’est pas à jour, le suivi n’est pas complet. Il faut donc que toute nouvelle instance soit incluse au plus tôt dans le réferentiel, et que toute instance supprimée n’y apparaisse plus.

Si vous avez industralisé le déploiement (voir article précédent Banalisation des instances), il suffit de créer un script Transact-SQL de post installation qui ajoute l’instance au référentiel (votre développement interne doit idéalement fournir une procédure stockée d’ajout d’instance, et tous les outils Microsoft présentés ci-dessus ont une interface Transact-SQL pour gérer l’ajout d’une instance).

Si le déploiement  n’est pas industralisé, il faut penser à ajouter l’instance manuellement…

La suppression doit suivre le même principe, même si dans les faits une suppression d’instance n’est pas nécessairement gérée correctement. Il est donc utile de vérifier régulièrement les instances apparaissant comme « non joignables » dans les différents outils et de les dé-référencer au plus vite.

Continuez votre lecture sur le blog :




Cliquer pour partager cet article sur Viadeo
Cliquer sur "CAPTURER" pour sauvegarder cet article dans Evernote Clip to Evernote

Tags: ,

Leave a Reply