Serveur épileptique

Un serveur de fichiers dans les entreprises actuelles, peuvent souvent desservir une clientèles dans l'ordre de quatre à cinq milliers d'utilisateurs.

L'expérience m'a démontré qu'un serveur Windows 2003 Standard commence à subir du stress et des symptômes d'équisement professionnel dans les entreprises de cette taille.

Le problème n'est pas dû à un manque de ressource physiques car ces symptômes sont apparents sur des serveurs ayant suffisamment de cycles CPU, de mémoire ou de bande passante réseau et stockage de disponible...

La cause de cette dépression est plutôt un débordement dans la plage mémoire allouée à la gestion des connexions RPC dans le processus du service serveur.

En effet, un serveur x86 a une plage mémoire limitée pour la gestion des connexions RPC puisque ce processus s'exécute en mémoire Kernel.  Comme ce processus est en compétition avec tous les pilotes et tous les autres processus Windows pour les adresses mémoires de la plage Kernel, une limite a dû être prévue dans les versions 32bits de Windows 2003.

Lorsque cette limite est atteinte, il n'y a pas beaucoup de solutions disponibles.  Même un serveur Windows 2003 Entreprise subira les même symptômes.

La solution : Windows 2003 x64 (ou Windows 2008 x64).

La version x64 de Windows n'ayant pas la limitation pour l'adressage de la mémoire Kernel à 2Go, la plage mémoire allouée à la gestion des connexions RPC peut augmenter afin de combler les besoins, tant que suffisamment de mémoire physique est disponible.

Rongé par la sID !

Mon histoire commence par un problème de performance avec un serveur de fichiers comprenant presque 2TB de données et supportant presque 5000 utilisateurs.

Le serveur en question éprouve des problèmes qui causent la déconnections des clients lors des périodes de grande utilisation.

La solution envisagée pour palier au problème est la migration du serveur Windows 2003 32bits vers la version x64, qui promet une meilleure gestion de la mémoire, des disques, du réseau et des CPU.

Le défi de la migration réside dans le fait que la sécurité sur les données de ce serveur a été faite selon la méthode à la mode à l'époque de NT4, soit en utilisant des groupes locaux.

La méthode choisie consiste à copier les groupes locaux du serveur source (x86) au serveur destination (x64) à l'aide de l'outil "SecurCopy".

Les travaux en laboratoire ont sont faits sur un environnemnet virtuel.  Suite à l'utilisation de l'outil "SecurCopy" pour copier les groupes d'un serveur à l'autre, le disque contenant les données est détaché du serveur source et attaché au serveur cible.

Avec cette procédure, nous nous attendions à un échec...  mais ce ne fut pas le cas.  La migration semble bien fonctionner. 

En théorie, la copie des groupes locaux d'un serveur à l'autre permet d'obtenir à la destination des groupes portant le même nom, cependant, le nouvau serveur doit émettre de nouveaux sID pour ces groupes.  De ce fait, les permissions (ACL) appliquées sur les données ne devraient pas être reconnues par le nouveau serveur.

Les permissions (ACL) sur le disque sont (contrairement à nos attentes) reconnues par le nouveau serveur.  L'outil semble avoir copié les sID des groupes...  fantastique... (incroyable?)

Maintenant... allons en production.  Exécution de l'outil "SecurCopy", détachement du disque de données, attachement sur le nouveau serveur....   BANG !  aucun sID n'est reconnu par le nouveau serveur.  DEUUUUUHHH ?????

Que s'est-il passé...???

Vous n'avez pas oublié que l'environnemnet de laboratoire était virtuel?...  Les machine virtuelles utilisées étaient des "clones" générées à partir d'un gabarit commun, sans qu'une quelconque personnalisation machine n'ait été effectuée (sysprep, newsid).

Il semble donc que "SecurCopy" lirait le sID du serveur de destination et effectuerait un "restore" des sID originaux des groupes si les sID des deux serveurs concordent.  Lorsque le sID est différent, il laisse Windows générer de nouveaux sID pour les groupes.

Hypothèse : pourrait-on utiliser newsid et spécifier le sID de l'ancien serveur ?  Ça reste à confirmer.

En attendant, la méthodologie sera révisée... une solution moins "dangereuse" sera élaborée...