MS SQL Server 2005 on Zwindler's Reflection

Installer 3 plugins Nagios dans EON 1.2, coupé d’Internet, level 3

Wed, 15 Sep 2010 08:47:41 +0000

Pour le dernier plugin, check_mssql_health, j’ai vraiment dû faire face à de gros ennuis. Ce script Perl, très bien fait une fois installé, permet de vérifier à peu près tout ce qu’on pourrait vouloir vérifier dans une base de donnée MS SQL. C’est vraiment très impressionnant, et assez bien documenté une fois qu’on est sur le site officiel, heureusement en anglais (certains sites ne référencent que la partie allemande de l’aide, ce qui peut s’avérer particulièrement inutile quand on ne connait pas plus d’Allemand que quelques paroles de Rammstein).

Même si c’est probablement dû à mon cas particulier, j’ai souvent dû faire face à des documentations incomplètes pour l’installation des différents composants. J’ai passé un bon moment à tâtonner, chercher de la doc à droite à gauche, tester, râler… C’est pourquoi un passage en revue de tous les aspects de la chaine me parait utile.

D’abord, commençons par redire qu’il s’agit d’un script Perl. Pour fonctionner, celui-ci nécessite plusieurs choses. D’abord, il utilise un module Perl permettant de communiquer avec des bases de données. Mais ce module nécessite bien sûr d’un client de base de données, et enfin, ce client de base de données nécessite les bibliothèque qui vont bien pour s’installer.

Voyons cela plus en détails… Le plugin check_mssql_health nécessite du module DBD::Sybase, qui est en fait un module permettant de s’interfacer avec des base de données Sybase, en passant par l’intermédiaire d’un client fournit par Sybase. On pourrait se dire que c’est un choix curieux sachant qu’on veut communiquer avec une base MSSQL, mais en fait, le module permet également d’utiliser un autre client, FreeTDS (qui est une réimplémentation ce précédent client), qui gère également les bases MSSQL 2000 ou supérieure (le vCenter 2.5 utilise une base de données MS SQL Server 2005 Express).

La première chose à faire est d’installer le client FreeTDS. Pour ce faire, il faut d’abord ajouter les paquets suivant avec Yum :

# yum install unixODBC
# yum install unixODBC-devel

Si vous vous en tenez à la documentation de FreeTDS, vous ne lirez nulle part qu’il faut installer unixODBC-devel, et si vous ne le faites pas, le script d’installation continuera inlassablement à vous indiquer que vous n’avez pas installé unixODBC (alors que si!).

Une fois que ceci est fait, il faut télécharger les sources de freetds, car le DVD d’EyesOfNetwork qui nous sert de répository local ne contient pas le paquet pour l’installer. Pour fonctionner correctement, notre script Perl nécessitera au moins la version 6.2 de FreeTDS, sachant que je n’ai testé que la version que la 8.2. De préférence, choisir la version dite stable.

# tar xvzf freetds-stable.tgz
#cd freetds-[version_stable]
# ./configure
# make
# make install

Maintenant que FreeTDS est installé, il faut le configurer. Si on lit la documentation de check_mssql_health, il est indiqué que pour des raisons de sécurité, il vaut mieux passer le protocole de communication de FreeTDS de la version 4.2 (par défaut) à la version 8.0. Pour ma part, ce n’est pas un conseil, c’est une obligation. check_mssql_health n’a jamais fonctionné tant que je n’ai pas modifié de paramètre. Et ce n’est pas plus mal, quand on sait que cette version 4.2 du protocole envoie votre mot de passe en clair sur le réseau, lors des authentifications avec la base de données (O_o).

Pour changer cette version de protocole, éditez le fichier /etc/freetds.conf pour qu’il ressemble à ça :

[global]
#TDS protocol version
tds version = 8.0
[...]

Maintenant que nous disposons du client, que celui-ci est correctement configuré, il faut installer les dépendances Perl. Par rapport à la dernière fois, il ne m’en manquait que deux :

DBD::Sybase
- DBI

Par contre, avant de pouvoir installer DBD::Sybase, il est nécessaire de le configurer (contrairement aux autres modules Perl installés jusqu’à présent). Dans les fichiers d’aide README et README.freetds contenus dans l’archive DBD::Sybase, il est indiqué que le chemin vers FreeTDS doit être connu par le script Makefile.PL. Cette valeur doit normalement être renseignée en enregistrant le chemin vers FreeTDS dans la variable d’environnement SYBASE.

Pour des raisons qui me sont totalement inconnues, je n’ai jamais réussi à faire fonctionner ce script avec cette méthode. La variable n’était jamais prise en compte, et même si l’installation continuait, le module n’était pas fonctionnel, puisqu’il n’avait pas accès au client. Pour contourner ce problème, j’ai utilisé une solution radicale et pas très élégante. Dans Makefile.PL, j’ai remplacé les lignes

Sub configure{
my $sybase_dir = $ENV{SYBASE};
[...]

par

Sub configure{
my $sybase_dir = '[chemin_vers_freetds]';

Après cela, l’installation du module s’est déroulée sans encombres, et le script à pu être compilé :

# tar xvzf check_mssql_health_[version].tar.gz
# cd check_mssql_health_[version]
# ./configure --prefix'/srv/eyesofnetwork/nagios-3.0.6' --with-nagios-group=eyesofnetwork
# make
# make install

Une fois encore, il est important de ne pas mettre de / final dans le chemin indiqué dans la ligne ./configure. Une fois les commandes exécutées avec succès, le script est installé dans le dossier /srv/eyesofnetwork/nagios-3.0.6/libexec.

Ca y est ? Non…

Même si maintenant tout est correctement configuré et installé côté plugin, il est encore nécessaire de configurer votre base MSSQL pour qu’elle accepte les connexions. Je ne traiterai pas de l’aspect création d’un utilisateur avec des droits suffisant pour lire l’état de la base, je ne suis vraiment pas un expert, et j’imagine qu’on trouve de très bon tutos sur le net, expliquant bien chaque type de droit, et la manière de bien le faire. Vous pouvez soit chercher du côté de MS SQL Server Management Studio, soit effectuer les autorisations manuellement via le tuto du site de mssql_health_check.

Pour que la base accepte les connexions distantes de notre client FreeTDS, il faut d’abord s’assurer que le pare feu Windows laisse bien entrer les connexions TCP sur le port 1433, et que le serveur les accepte, lui aussi.

Pour se faire, il suffit d’utiliser l’utilitaire SQL Server Configuration Manager, installé par défaut avec la base de données, puis d’aller dans Configuration du réseau SQL Server 2005/Protocole pour [nom_base_données]/TCP/IP. Dans l’onglet Protocoles, choisir Oui pour la valeur Activer. Le serveur doit ensuite être redémarré pour que les modifications soient bien prises en compte.

Ouf… Il ne reste plus qu’à lancer vos sondes depuis Nagios, maintenant!

SQL Server 2005 : PowerShell > Batch – Episode 3

Wed, 28 Apr 2010 16:52:16 +0000

Batch – Episode 3" />

Dernier article là-dessus et on en parle plus (jusqu’à ce que je change d’avis). Dans l’article précédent, je vous indiquais mon désespoir quand j’ai découvert que je faisais tout mal (lien mort, j’utilise Internet archive). En regardant de plus près, je me suis aperçu que ça ne marchait pas vraiment comme il le disait, surtout pour ce qui est des sauvegardes incrémentales, et je me suis empressé d’écrire une nouvelle version de mon script pour qu’il soit plus beau, plus fort, plus efficace…

Une petite note aussi, les problèmes que j’ai eu avec le script du monsieur de databasejournal est peut-être dû au fait que j’ai une version Express et non pas complète comme je le pensais au début.

En fait, quand vous faites un backup complète, un fichier .bak est créé, et celui ci est autosuffisant et peut être restauré facilement. Cependant, pour pouvoir utiliser les sauvegardes incrémentales, il faut que la sauvegarde soit faite dans le même fichier, qui est concaténé (en quelque sorte). Or, le script donné à la fin de l’article créé des backups .diff qui sont séparées de leur backup complète, que je n’ai pas réussi à réimporter avec MS SQL Server 2005 Express.

Pour ceux d’entre nous qui ont les mêmes problèmes que j’ai eus avec les « differential backups », voici un nouveau script qui permet de faire proprement ce que je voulais faire depuis le début, c’est-à-dire:

disposer d’un script qui automatise la sauvegarde de la base de donnée de mon vCenter (mais aussi de n’importe quelle autre base de données compatible MS SQL Server 2005)
avoir la possibilité de faire des backups complètes, datées pour pouvoir être différenciées
avoir la possibilité de faire des backups incrémentales
toutes les opérations et éventuelles erreurs sont journalisées (ça se dit?)

Pour ce qui est des contrôles du script:

dans le cas où une backup complète n’est pas trouvée, le script fait une backup complète plutôt qu’une incrémentale
dans le cas où plusieurs backup complètes existent, la backup incrémentale se greffe sur la backup complète la plus récente (ça m’a paru assez logique comme façon de faire, mais vous n’êtes pas obligés d’être d’accord)

Il s’utilise de la façon suivante :

powershell.exe C:\Scripts\MSSQLBackup2.ps1 HOMESQLSERVER MyDB \\SERVER\BackupFolder FULL
powershell.exe C:\Scripts\MSSQLBackup2.ps1 HOMESQLSERVER MyDB C:\Backup DIFF

La première ligne exécute le script pour une backup complète de MyDB depuis l’ordinateur HOME (en local svp, je n’ai pas testé à distance, mais il doit y avoir des problèmes d’authentification) qui dispose d’un serveur SQLSERVER vers un dossier partagé BackupFolder sur le réseau par l’ordinateur SERVER. La seconde ligne fait plus ou moins là même chose (sauvegardé localement et pas dans un dossier partagé) mais avec une sauvegarde incrémentale.

Je suis vengé :-D

Internet 1 - Zwindler 1

SQL Server 2005 : PowerShell > Batch – Episode 2

Tue, 27 Apr 2010 13:09:43 +0000

Batch – Episode 2" />

A quoi ça sert de faire du PowerShell si on continue à utiliser de vieux exécutables tout pourris ?

Dans le précédent article, je vous ai donné un script home-made qui permet de faire une backup automatisée d’une base de données SQL Server 2005, en me basant sur l’appel du mécanisme de backup par l’interpréteur de T-SQL (beurk!) SQLCMD.EXE. Ceci est un bon exemple des dangers d’être autodidacte. Si seulement j’avais gratté un peu plus avant de foncer tête baissée, j’aurai découvert (ce que je viens de faire par hasard) qu’il existe des objets pour ça : SMO!

SMO?

La collection d’objets SMO (SQL Server Management Objects) est conçue pour la programmation de tous les aspects de la gestion de Microsoft SQL Server. La collection d’objets RMO (SQL Server Replication Management Objects) encapsule la gestion de la réplication SQL Server.

En fouillant un peu sur cette piste, je suis tombé sur cet article de Database journal (lien mort, j’utilise Internet archive). Il nous explique cordialement que toute cette ligne de commande moche que j’utilisais pour enclencher la backup peut être évité en utilisant des objets manipulables dans PowerShell. « Cool, me dis-je, je vais pouvoir proprifier mon script. C’est dommage de ne pas avoir trouvé ça dès le début! »

En fouillant un peu plus, je suis tombé sur le dernier article (lien mort, j’utilise Internet archive). En gros, tout l’article explique pas à pas comment faire pour faire mieux en moins de lignes (backups incrémentales for dummies).

Pour garder la tête haute, je vais quand même héberger une nouvelle version du script, qui proposera de faire des backups incrémentales ou non, en m’inspirant fortement du code disponible sur databasejournal pour améliorer le mien.

Zwindler 0 - Internet 1

SQL Server 2005 : PowerShell > Batch

Fri, 23 Apr 2010 17:38:58 +0000

Batch" />

Il y a quelques jours, j’ai commencé la rénovation de notre vCenter (il tournait en machine virtuelle avec très peu de RAM sur un vieux VMWare server 2.0, lui même hébergé par un PC toussotant).

Outre les opérations de migration, je me suis penché sur les conséquences de la perte de ce vCenter, et donc les moyens à mettre en œuvre pour s’assurer de vite pouvoir remettre le système en marche. Si on met de côté le débat machine physique/machine virtuelle pour héberger le vCenter, la communauté semblait unanime sur le fait que pour le vCenter, les 2 choses importantes à sauvegarder sont les fichiers de licences et la base de données.

Dans notre cas, la base de données est simplement un Microsoft SQL Server 2005 (configuration des plus classiques). La version complète du SQL Server Management Studio permet en quelques clics de programmer une sauvegarde. N’étant pas capable de mettre la main sur les fichier d’installation de la version complète du Manager, j’ai cherché une solution alternative.

J’ai trouvé assez facilement un script batch qui utilise sqlcmd.exe, un programme fournit dans toutes les versions de SQL Server 2005 (même la version Express) et qui est en fait un interpréteur de requête T-SQL (si j’ai bien compris). La solution pour automatiser la sauvegarde de la base de données du vCenter (où de n’importe quelle autre base SQL Server d’ailleurs) consiste simplement à créer une tâche planifiée qui lance ce script aussi souvent que vous le souhaitez.

J’aurai pu m’arrêter là, mais pour plusieurs raisons, j’ai préféré réécrire ce script :

D’abord, batch, ça commence à dater un peu, il serait temps de passer à autre chose!
Ensuite, je ne suis pas du tout à l’aise avec les scripts batch. Comme je voulais améliorer ce script, cela impliquait que je m’y mette sérieusement, et je n’avais pas vraiment envie :-p
Enfin, certaines actions relativement complexe en batch sont grandement simplifiées par les usines à gaz que sont VBScript et PowerShell.

Les deux problèmes majeurs de ce script batch sont le gaspillage d’espace disque et l’absence de contrôle sur ce qui est fait. Certes, on vérifie certaines choses pour éviter des erreurs bêtes lors de l’exécution, mais bon, j’en attendais un peu plus.

J’ai donc sorti mon interpréteur PowerShell, un papier et un crayon, et je me suis créé un petit script qui permet de sauvegarder une base de données MS SQL exactement de la même manière, mais également qui ne garde que les fichiers backups de la veille et des 2 derniers « 1er jour du mois », qui vérifie que le fichier a bien été copié, et qui journalise le tout.

Ainsi, pas de gaspillage avec 200 versions pratiquement similaires de la base de données (le vCenter n’en a pas besoin, et on pourrait même se contenter d’une seule backup du mois dernier), et un contrôle un peu plus « propre » de ce qui se passe lors de l’exécution de la tâche planifiée.

Alors forcément, c’est sûr que c’est loin d’être aussi bien qu’une sauvegarde incrémentale planifiée par un outil tiers ou par le SQL Server Management Studio (je ne sais pas si il le fait, mais j’ai du mal à imaginer que non). C’est sûr aussi qu’on pourrait contrôler de façon encore plus complète tout ce qui se passe lors de l’exécution du script (plutôt que simplement vérifier que le fichier existe), notamment en traitant les éventuelles erreurs renvoyées par SQLCMD (qui ne sont pas vraiment prises en compte).

J’ai voulu écrire rapidement un petit script, et je n’ai pas besoin de plus que ce que j’ai déjà fais. On ne peut pas tout gérer non plus…