|
| |
Avant propos
Je ne suis pas l'auteur de cet
article.
Merci
à ZIP DAVIS et ZD NET FRANCE pour ces Informations.
Les promesses
de Windows NT 5.0
Après avoir combattu Novell
NetWare et IBM OS/2, Windows NT s’attaque à plus gros. Car l’ambition de
Microsoft est de faire de son système d’exploitation professionnel une alternative
aux serveurs applicatifs UNIX, voire à moyen terme aux mainframes. Un pari audacieux.
Voyons ensemble le premier jet de cette version 5.0 de Windows NT.
Par Olivier Caussin
Sommaire
1) Les ambitions de
NT 5.0
2) Une
architecture chahutée
3) Le réseau
repensé de A à Z
4) Administration et
TCO
5) Le clustering
Les
ambitions de NT 5.0
Par Olivier Caussin
Plus d’un an et
demi après le lancement officiel de Windows NT 4.0, voici venir Windows NT 5.0. Mais
attention aux promesses et espérances données par Microsoft plusieurs mois avant la
commercialisation de son produit phare. Souvenons-nous seulement que Microsoft aime
claironner à qui veut l’entendre que la prochaine version de son produit sera la
bonne… Car au bout du chemin, les promesses ne sont pas toutes toujours tenues.
Microsoft est coutumier du fait. Il suffit pour s’en convaincre d’entendre à
nouveau le discours qu’il tenait au sujet d’un certain Windows NT 4.0 et des
technologies qui étaient alors baptisées Cairo.
Cette fois-ci, l’éditeur donne à Windows NT une nouvelle dimension. Avec cette
ultime version de son système d’exploitation réseau, Microsoft cherche à toucher
une nouvelle population : ceux qui ont maille à partir avec les systèmes UNIX.
L’enjeu, on le comprend, est de taille… Pour ne pas dire majeur.
Grand écart…
Mais Microsoft ne peut pas se
permettre d’oublier la base installée! Car avec Windows NT 5.0, l’éditeur en
question fera le grand écart et occupera la quasi-totalité du spectre informatique
actuel. Windows NT 5.0 sera également le préambule à l’unification des diverses
versions de Windows. Après cette version de NT, il n’y aura plus de Windows 9.x
basé en partie sur l’ancestral noyau de MS-DOS. C’est, tout du moins, ce
qu’indiquent aujourd’hui les représentants de la firme de Redmond.
Ce grand virage a été amorcé il y a quelques mois de cela. Le département marketing a
presque davantage travaillé que la Recherche & Développement. Plusieurs versions de
NT ont, depuis, vu le jour. En plus de la version Workstation et Server, Microsoft
segmente la gamme “serveur” avec une version Small Business – pour les
petites PME/ PMI n’ayant pas plus de 25 postes – regroupant NT avec quelques
applications de la gamme BackOffice. Pour le haut de gamme, la version Entreprise intègre
déjà quelques-unes des nouveautés de NT 5.0 : Wolfpack 1.0 pour le clustering,
intégration de Microsoft Transaction Server, davantage de mémoire adressée
(jusqu’à 3 Go pour les applications), etc. Cette segmentation de Windows NT se
perpétuera dans la prochaine version 5.0. D’ores et déjà, une licence de la
version Entreprise coûte deux fois plus cher qu’une licence de la version standard.
L’écart de prix entre NT et UNIX se creuse, tout du moins en ce qui concerne le prix
du système d’exploitation.
Les enjeux de Windows NT 5.0 sont énormes… A tel point que Bill Gates a annoncé
jouer le futur de sa société sur ce produit! La première bêta-version a été
distribuée à 10 000 exemplaires lors de la “Conférence Développeur” de San
Diego, en septembre 97. Elle contenait déjà plus de 27 millions de ligne de code! Et
bien que certaines technologies clés soient absentes, il est déjà possible d’avoir
une idée générale de ce que sera NT 5.0 (la sortie de la version définitive étant
prévue pour le second semestre 1998).
Innovations
Nous avons choisi de regrouper les
innovations de cette version en trois chapitres. Dans le premier, nous détaillerons les
nouveautés de l’architecture, où de nombreux points sont partagés entre NT
Workstation et Server, ou même avec Windows 98. Dans le deuxième, nous aborderons les
fonctionnalités réseau avec les Active Directory. Enfin, le troisième chapitre traitera
de l’administration et de la problématique du TCO (Total Cost of Ownership), à
laquelle Microsoft tente d’apporter une réponse en faisant appel à plusieurs
technologies. Pour l’heure, la plus intéressante semble être IntelliMirror.
Nous avons volontairement passé sous silence l’intégration entre le bureau et le
browser Internet Explorer, qui sera proposée en standard dans Windows 98 et NT 5.0.
C’est d’ailleurs déjà le cas avec Windows NT 4.0 et Windows 95, à condition
d’installer Internet Explorer 4.0. Bien des choses ont déjà été dites à ce
sujet, et nous avons préféré nous focaliser sur les fonctionnalités professionnelles
de Windows NT Server, inédites à ce jour.
A l’issue de cette première prise en main, le bilan est pour l’heure positif.
NT 5.0 s’est doté de fonctionnalités robustes qui en font véritablement une
alternative “technique” à UNIX. C’est une condition nécessaire au succès
commercial. Cependant, d’au-tres facteurs peuvent intervenir, comme la capacité de
Microsoft à accompagner les clients sur des applications stratégiques. Mais là,
c’est une autre histoire…
Une
architecture chahutée
Par Olivier Caussin
Une fois encore,
l’architecture de Windows NT a été modifiée. Les améliorations portent sur le
stockage des données, le support des périphériques et l’infrastructure de
composants objets COM+. Détails.
Pour des raisons de
compatibilité, Windows NT 5.0 supportera la FAT 32, introduite avec la version OSR2 de
Windows 95 et présente en standard dans Windows 98. Rappelons que la FAT 32 permet de
gérer des partitions de plus de 2 Go, alors que la vieille structure FAT héritée du DOS
était limitée à 2 Go sous Windows et à 4 Go sous Windows NT. La FAT
“classique” reste bien entendu supportée, et elle est préconisée pour les
petits supports tels que disquette et disque ZIP, ou sur les configurations pourvues
d’un système “multiboot” (Windows NT, DOS, Windows 16 bits et autres
systèmes).
Le format de stockage utilisé pour les CD-ROM était traditionnellement CDFS.
L’apparition du DVD requiert un format plus adapté, baptisé UDF (Universal Disk
Format) et présent sur Windows 98 et NT 5.0. Sa principale caractéristique est
d’être “bootable” et de supporter les noms longs Unicode.
NTFS version 5 Les principales évolutions concernent NTFS, présent uniquement sous
Windows NT. Outre des améliorations de performance, NTFS version 5 inclut des
caractéristiques très attendues liées à l’administration. Le support des quotas
de disque par utilisateur et par volume – effectif depuis de nombreuses années sous
Novell NetWare – est enfin présent, et il s’administre directement depuis
l’Explorer. Quant à l’administration à distance, elle n’était pas
présente dans la version que nous avons testée, mais elle est prévue pour la prochaine
bêta. En analysant dans le détail l’architecture technique de NTFS version 5, on
découvre au moins trois caractéristiques intéressantes.
Tout d’abord, il devient possible d’associer des propriétés personnalisables
aux fichiers et répertoires. En plus des classiques dates de création ou de
modification, les applications pourront stocker des annotations directement au sein du
système de fichier. Des mots clés peuvent être utilisés pour effectuer des recherches.
Microsoft a d’ores et déjà annoncé que son moteur d’indexation et de
recherche Index Server saura exploiter l’ensemble des propriétés associées aux
fichiers.
Deuxième caractéristique, le gestionnaire de volume. Il s’agit d’une couche
logicielle située entre le système de fichier et le disque physique. Il permet, par
exemple, d’étendre les volumes NTFS v.5 sans avoir à rebooter le serveur. Les
disques Plug & Play sont gérés via ce gestionnaire. C’est aussi le cas du
mirroring. Troisième point remarquable, Microsoft a prévu l’ajout de “drivers
filtrants” au sein de l’architecture NTFS, qui s’intercalent entre les
applications et le système de fichier. Ces briques logicielles fournies par Microsoft ou
par des éditeurs tiers (les spécifications sont publiques) permettront un cryptage
transparent, la compression, la surveillance de bas niveau des disques durs et surtout la
protection contre les virus.
Sauvegarde améliorée
Au niveau des outils, notons la
présence d’une nouvelle version de Windows NT Backup, issue de la collaboration avec
Seagate. Celle-ci utilisera une nouvelle interface graphique à la mode Explorer,
permettant de voir et le serveur et le voisinage réseau. Elle disposera en outre
d’assistants graphiques qui viendront faciliter la sauvegarde et la récupération
des données sur disque, sur bande ou même sur CD-ROM. Précisons que cet utilitaire de
sauvegarde sera bien entendu compatible avec les DFS (Distributed File System – voir
le chapitre consacré aux innovations réseau dans ce dossier). Autre outil attendu, un
défragmenteur devrait faire son apparition, développé par Executive Software et
supportant à la fois FAT, FAT 32 et NTFS. Enfin, ultime technologie relative au stockage,
et directement issue du monde mainframe, Microsoft Windows NT 5.0 supportera HSM
(Hierarchical Storage System). Cette technologie consiste à faire migrer automatiquement
les fichiers les moins utilisés sur des supports moins chers (disque optique ou bande),
en toute transparence pour l’utilisateur. Lorsque celui-ci souhaite accéder à un
fichier peu usité, il ne constatera qu’un ralentissement du temps de réponse, le
fichier étant automatiquement rapatrié et recopié sur un disque magnétique. HSM
nécessite une infrastructure matérielle onéreuse et il n’est adapté qu’à
des cas bien particuliers, par exemple pour des applications transac- tionnelles
manipulant d’énormes volumes de données, avec un souci d’historisation.
Deux objectifs président aux évolutions de Windows NT 5.0 en termes de standards
matériels. Le premier est la mise à niveau avec Windows 95 et Windows 98. Le second est
le bon fonctionnement du système d’exploitation sur un portable, ce qui était loin
d’être le cas avec Windows NT 4.0 à cause notamment du non-support des technologies
de conservation de l’énergie ou du Plug & Play.
Un meilleur support des
périphériques
Grâce au Plug & Play,
l’utilisateur peut ajouter ou enlever des périphériques dynamiquement, sans aucune
étape de configuration ou de lecture de manuel technique, et surtout sans connaissance
technique du périphérique concerné. Par exemple, un portable connecté à sa station
d’accueil utilisera la carte réseau de la station. Plus tard, déconnecté et sur la
route, il utilisera son modem pour accéder au réseau de l’entreprise, et cela sans
reconfiguration manuelle.
Le premier système Plug & Play fut Windows 95. Depuis, Microsoft, Toshiba et Intel
ont travaillé à unifier les problématiques de la gestion de configuration et de la
gestion de l’énergie, le tout sous le contrôle complet du système
d’exploitation. Baptisée OnNow, cette initiative a donné naissance à ACPI 1.0
(Advanced Configuration and Power Interface), définissant des spécifications de carte
mère et de BIOS. Une première conclusion à tirer est que le support du Plug & Play
dans Windows NT 5.0 et dans Windows 98 ne reposera pas exclusivement sur des systèmes au
BIOS compatible APM (Advanced Power Management) ou au BIOS Plug & Play, comme
c’était le cas avec Windows 95.
Le support du Plug & Play dans Windows NT 5.0 concerne la reconnaissance des
périphériques à l’installation du système, la reconnaissance de tout changement
intervenu entre deux “boots”, ainsi que des événements matériels survenant
sur une machine allumée tels que l’arrimage d’un portable à sa station
d’accueil. Il concerne également l’allocation automatique des ressources de la
machine (ports E/S, IRQ, DMA, plage de mémoire) aux périphériques, ainsi que
l’interaction avec la gestion de l’énergie sous forme d’événements comme
la mise en sommeil ou le réveil d’un périphérique. Il est nécessaire de disposer
simultanément de périphé- riques compatibles ACPI et de pilotes pour ces
périphériques eux-mêmes Plug & Play. Cela signifie que, bien que les drivers de
Windows NT 4.0 soient supportés, ils ne permettront pas d’avoir accès au Plug &
Play. La première bêta-version de Windows NT 5.0 que nous avons testée
n’intégrait pas encore toutes les fonctionnalités telles que l’insertion à
chaud de cartes PCMCIA; toutefois, cela devrait être résolu dans la prochaine bêta,
nous dit-on.
Mais le Plug & Play n’est pas la seule avancée de Windows NT 5.0 en termes de
support matériel. ATM (Asynchronious Transfer Mode) est nativement supporté par le
système, ce qui devrait faciliter les déploiements de cette technologie de réseau à
haute vitesse. Les DVD (Digital Video Disc) et leurs variantes réinscriptibles seront
également supportés par le système.
L’Universal Serial Bus ou USB, qui autorise le chaînage théorique de 127
périphériques tels que clavier, souris, écran, est également au programme de cette
version 5. Tout comme DirectX 5.0, qui permettra d’exécuter des jeux à grande
vitesse. Notons que le Service Pack 3 de Windows NT 4.0 introduisait déjà cette
technologie sur la plate-forme professionnelle de Microsoft. Les cartes graphiques 3D
s’intégrant dans le nouveau slot AGP seront aussi supportées. De plus, il deviendra
possible d’utiliser plusieurs moniteurs simultanément, avec plusieurs cartes vidéo.
Enfin, Microsoft a travaillé à l’unification des drivers pour Windows NT et Windows
98. Baptisés WDM (Win32 Driver Model), ces pilotes sont compatibles ACPI 1.0 mais ne
concernent pour l’instant que bien peu de périphériques. Il s’agit
essentiellement des cartes son, des cartes d’acquisition et de compression vidéo, et
des matériels USB. Ne sont donc pas concernés : les pilotes de carte vidéo ou de
contrôleur disque, les modems, les imprimantes, etc.
Dans un tout autre registre, Microsoft s’attaque au marché des cartes à puce ou à
bande magnétique, en intégrant des interfaces de programmation (SmartCard API) pour
développer des applications basées sur ces cartes.
Si toutes les évolutions listées ci-dessus sont communes à Windows NT Workstation et
Server, et même souvent à Windows 98, il n’en va pas de même du support de VLM
(Very Large Memory) : exclusivement présente dans Windows NT 5.0 édition Entreprise, VLM
permet aux applications de disposer d’un maximum de 3 Go de mémoire vive sur les
machines équipées de processeurs Intel, et jusqu’à 32 Go pour les machines Alpha
64 bits.
Dès à présent, 8 Go de mémoire sont adressables sur les AlphaServer 8400. Microsoft et
Digital franchissent un nouveau pas en matière d’évolutivité. Il s’agit bel
et bien de la conquête du marché UNIX. La technologie Fx!32 sur serveurs Alpha permet
d’exécuter les binaires Intel x86 sans émulation et à pleine vitesse. Le meilleur
des deux mondes est ainsi réuni, c’est-à-dire les performances des stations Alpha
et l’extraordinaire variété de la bibliothèque de solutions sous Win32 Intel.
Pour accélérer les serveurs, une autre technologie baptisée I2O permet de déléguer
les accès disque à un processeur dédié, diminuant d’autant la charge du
processeur principal. C’est cette technologie qui est aujourd’hui suportée par
NT 5.0.
A signaler également que les machines SMP bénéficieront d’un surcroît de
performances dû à un nouvel algorithme gérant la priorité des process et la
répartition de chaque thread sur les processeurs pendant un certain temps appelé
quantum.
L’évolution de COM
COM est devenu une technologie
essentielle au cœur des systèmes d’exploitation 32 bits de Microsoft. Rappelons
qu’il s’agit d’une infrastructure de composants objets, indépendants du
langage et de l’emplacement (sur une machine distante ou sur une seule machine,
appelés au sein d’un unique process ou en dehors du process). COM est présent sur
le poste client, via les objets interface utilisateur que sont les ActiveX, ou via les
communications entre applications bureautiques comme l’OLE, ou l’OLE Automation.
A ce titre, il est en concurrence avec le modèle JavaBeans, qui est quant à lui purement
Java. Mais COM existe aussi du côté du serveur, avec DCOM et Microsoft Transaction
Server. Ce produit sait gérer des objets COM appelés par de nombreux clients via
Internet par exemple, mais introduit en outre le concept de transaction sur des bases de
données ou, plus généralement, entre objets. Notons qu’à l’heure actuelle,
MTS est encore un produit à part, qui ne fait pas réellement partie de COM. Sur le
serveur, COM est en concurrence avec CORBA. COM est souvent exclusivement associé à
Windows, alors que CORBA est davantage présent sous UNIX. Pourtant, le partenariat de
Microsoft avec Software AG a porté ses fruits en octobre 97, avec l’annonce de
Entire X, un middleware basé sur COM pour les environnements UNIX et même OS/390.
En septembre dernier, Microsoft a dévoilé – à l’occasion de la conférence
développeur de San Diego – les prochaines évolutions de COM, qui seront intégrées
à Windows NT 5.0. Les appellations successives de COM ont été OLE, Network OLE, DCOM,
ActiveX, et on attendait pour la nouvelle version COM3, ou COR… Microsoft a
finalement tranché pour COM+, en attendant une éventuelle prochaine dénomination!
L’objectif annoncé est de simplifier radicalement le travail du développeur, afin
de concevoir des applications et des composants distribués et multi-niveaux pour le Web,
“scalables” du poste client aux déploiements d’entreprise, et également
plus simples à administrer.
Il est essentiel de préciser en préambule que COM+ préserve la compatibilité avec COM,
tout en apportant un certain nombre d’innovations. Si le développeur ne souhaite pas
bénéficier de ces innovations, il peut continuer à programmer – au prix
d’efforts plus importants, il est vrai – des composants COM avec les méthodes
traditionnelles (en C++, en Visual Basic, en Java), qui fonctionneront parfaitement sous
COM+, puisque COM+ repose avant tout sur COM.
Du point de vue de l’architecture, la principale différence entre COM et COM+ est la
présence d’un runtime au niveau du système, qui est responsable d’un certain
nombre de services qu’il fallait auparavant développer à la main. L’un des
slogans de Microsoft pour COM+ est en effet “Auto everything”. Auto-transaction
tout d’abord, puisque Microsoft Transaction Server sera fourni en standard dans
Windows NT 5.0, gérant des transactions autour de composants COM, mais aussi un pool de
connexions vers des bases de données, ou encore le multi-threading automatique dès lors
que plusieurs clients se connectent simultanément depuis des postes Windows ou des
browsers Web. La répartition dynamique de charge entre serveurs MTS est également
prévue. Auto-Asynchrone ensuite grâce à l’intégration de Microsoft Message Queue
(ex Falcon). Lorsqu’un objet A appelle une méthode d’un objet B non disponible,
une pile d’attente est créée. Lors du réveil ou de la disponibilité de
l’objet B, celui-ci recevra l’appel de la méthode, et pourra l’exécuter
de manière asynchrone par rapport à l’invocation. “Auto-biding” signifie
que des classes pourront contenir des champs de sources de données ODBC ou OLE DB, COM+
se chargeant ici de masquer la complexité de l’accès aux données. Le seul travail
à faire est la déclaration des interfaces de l’objet, en utilisant des mots clés
tels que source=, column=, etc.
La gestion des versions sera améliorée en stockant au sein d’une base de données
les interfaces de chaque objet au fil de ses versions. Ces informations – baptisées
métadonnées – sont aujourd’hui très limitées, essentiellement stockées dans
la Registry. De plus, il sera possible de préciser que tel objet ne fonctionne
qu’avec une version particulière d’un autre composant, ou avec la dernière
version, etc. Avec COM+, des packages pourront regrouper logiquement des composants, en
étant certain que leurs versions respectives sont compatibles, et l’utilisateur
final pourra manipuler ces packages dotés de noms utilisateurs. Le format de la base de
données abritant les métadonnées COM+ n’est pas défini à ce jour, mais il
pourrait s’agir des Active Directory, ce qui permettrait de fusionner la
problématique de sécurité. Il s’agit de savoir gérer les rôles (quels
utilisateurs ont le droit?), les privilèges (quelles sont les ressources disponibles?),
l’authentification (d’où provient cet objet?), ainsi que les différentes zones
(Internet, au sein d’un réseau privé, etc.).
Toujours au sein du runtime COM+, la “Garbage collection”, à l’image de
celle de Java, est une fonctionnalité de libération automatique de la mémoire allouée,
et surtout des instances d’objets créés en mémoire ou à distance. Il ne sera plus
nécessaire de compter les instances appelées et libérées. Parallèlement, les objets
COM+ pourront utiliser une base de données virtuelle en mémoire, afin de stocker leurs
propriétés et données, avec des liens middleware vers des bases de données
relationnelles. L’objectif est bien la persistance des objets COM+. Microsoft
s’acheminerait ainsi vers une redéfinition des bases de données objet.
Le
réseau repensé de A à Z
Par Olivier Caussin
En intégrant un
nouveau service de répertoire dénommé Active Directory, Microsoft a complètement
repensé la gestion du réseau sous Windows NT 5.0. Explications.
Microsoft Windows NT 5.0 inclut
un nouveau service de répertoire baptisé Active Directory. Ce service étend les
fonctionnalités déjà disponibles avec la gestion des domaines de NT 4.0, mais rajoute
également des innovations telles que le renforcement de la sécurité, la réplication
entre domaines distribués et partitionnés ou encore la hiérarchisation. Ce service est
conçu pour fonctionner avec de petites installations où un seul serveur gère quelques
centaines d’objets (utilisateurs, etc.), mais aussi avec des installations
internationales où des milliers de serveurs répartis sur plusieurs continents gèrent
des millions d’objets. C’est d’ailleurs sur ce dernier segment que le
modèle de domaine présent dans le serveur NT 4.0 présentait le plus de lacunes,
comparativement à l’offre NDS de Novell. Le service Active Directory de Microsoft se
compose d’un ensemble d’outils pour les administrateurs, de services de
réplication et de sécurité, mais aussi d’API pour les développeurs, permettant de
bâtir des solutions accédant aux ADS.
Tout comme dans l’architecture de Windows NT 3.x et 4.0, l’élément central du
réseau ADS est le domaine. Tous les objets réseau existent au sein d’un domaine.
Les accès à ces objets sont contrôlés par des ACL (Access Control List), et les droits
d’administrateur s’exercent au sein d’un domaine. Les domaines sont aussi
l’unité de base de la réplication. Un seul domaine peut couvrir plusieurs
emplacements ou sites physiques. Contrairement aux PDC (Primary Domain Controller) et BDC
(Backup Domain Controller) présents dans NT 4.0, l’Active Directory sait utiliser
simultanément plusieurs contrôleurs maîtres, désormais baptisés DC (Directory
Controller). Tous ont autorité sur le domaine, peuvent recevoir des modifications
directement et les propagent aux autres DC. Cela permet des réplications inter-sites,
même si un quelconque DC ne fonctionne pas.
Plusieurs domaines sont ensuite regroupés dans un arbre de domaines. Les utilisateurs
d’un domaine peuvent accéder aux ressources d’autres domaines via des liens de
confiance transitifs au sein de l’arbre global. Néanmoins, les droits
d’administration ne sont pas toujours transitifs, et des couches de sécurité
additionnelles ont été rajoutées pour limiter les droits de l’administrateur.
Microsoft a essayé de faire une fusion des DNS (Domain Naming System) – cette base
de données qui sert à associer les noms de domaines avec des adresses IP – avec la
norme X500 qui est un format standard de stockage hiérarchique, sur lequel
s’appuient plus ou moins tous les services de répertoire existants, y compris celui
de Novell. «Le meilleur du DNS, avec le meilleur de X500», telle est l’ambition
avouée des ADS.
Les ADS stockent des objets, avec leurs attributs. Un objet symbolise quelque chose de
concret, par exemple un utilisateur, une imprimante ou une application. Les attributs
d’un utilisateur peuvent être son nom, son adresse E-Mail, etc. Certains objets sont
appelés “container” parce qu’ils peuvent contenir à leur tour
d’autres objets. Les objets sont référencés au sein des Active Directory Services
par un nom basé sur une convention proche de DNS. Par exemple,
PierreDurand@Marketing.Paris.MaSociete .fr, plus simple que l’appellation X500 qui
serait ici CN=PierreDurand, O=MaSociete, OU=Paris, OU=Marketing, C=fr. Le sigle OU
désigne le terme Organisation Unit et sert à regrouper logiquement les objets dans la
hiérarchie X500 et ADS. Au sein d’un domaine, les objets de l’Active Directory
sont organisés en OU. Ces OU ne sont pas des équivalents stricts des OU de la norme
X500, puisqu’ils servent aussi à des fins d’administration. Les droits pour un
utilisateur peuvent se spécifier sur tous les objets d’un OU. Inversement, il est
possible de donner des droits particuliers sur un objet à tous les utilisateurs d’un
OU. Au fil du temps, il peut être intéressant de réaliser des interfaces automatiques
entre les logiciels de production de l’entreprise (telle la paye) et les ADS, afin de
maintenir automatiquement les modifications apportées aux utilisateurs, de créer
automatiquement les nouveaux, de supprimer les anciens. Néanmoins, rien n’est
réellement prévu au sein de Windows NT 5.0 pour réaliser de telles interfaces.
Principe de l’Active
Directory
Le schéma de l’Active Directory
désigne la structure arborescente de l’arbre, la liste des objets possibles, les
parents auxquels chacun d’eux peut être raccordé et leur liste d’attributs. NT
5.0 permet, via la console d’administration, d’ajouter non seulement de
nouvelles classes d’objets, mais aussi des attributs aux objets. Que stocker dans
l’Active Directory? Microsoft définit deux règles simples : premièrement,
l’information doit être relativement statique et ne changer que rarement. Par
exemple, l’adresse E-Mail d’un utilisateur rentre dans ce cadre. Par contre, les
messages que reçoit ce même utilisateur ne seront pas de bons candidats pour le stockage
dans les ADS. Seconde règle, l’information doit être structurée et pouvoir être
représentée par une série d’attributs. Ainsi, un clip vidéo ne sera pas stocké
dans l’arbre des domaines. Ces deux règles laissent la place à de nombreuses
données, jusqu’ici stockées dans des bases de données ou plus souvent dans la
Registry de chacune des machines du réseau. Par exemple, les applications Client/Serveur
pourront stocker leurs paramètres de connexion ou les configurations courantes.
L’affichage des utilisateurs d’un domaine n’a jamais été le point fort de
NT 4.0. Faute de hiérarchisation, tous les utilisateurs étaient toujours tous affichés
en même temps. Pour simplifier cette vue, Windows NT 5.0 dispose d’un mécanisme de
recherche appelé catalogue global (GC). Ce catalogue est un index des objets d’une
sous-partie de l’arbre des domaines, mixé à un moteur de recherche. Pour trouver
une ressource, l’utilisateur fera désormais une requête auprès du GC, en
fournissant un ou plusieurs attributs connus. L’un des attributs associés à un
objet correspond aux droits d’accès. Ainsi, si un utilisateur n’a pas les
droits sur un objet, sa requête pour le trouver échouera.
Plusieurs interfaces de programmation sont disponibles. ADSI (Active Directory Service
Interface) servira globalement à gérer les ADS, et sera utilisée par les applications
nécessitant un haut niveau d’interaction avec les arbres réseaux. LDAP (Lightweight
Directory Access Protocol) est une interface standard, dérivée des protocoles
d’interrogation plus complexes pour X500. Elle sera utilisée pour interroger les
ADS. Notons que ce protocole est utilisé par les browsers Web de Microsoft et de Netscape
pour consulter des annuaires de manière générique. Hélas, LDAP n’a pas encore
été finalisée quant à ses spécification exactes, et plusieurs versions (2 et 3)
coexistent. Microsoft a annoncé qu’il supporterait les spécifications exactes de
LDAP version 3 lors de la sortie de NT 5.0.
L’icône Directory en action
Des outils sont également
disponibles pour les administrateurs, tout d’abord via une nouvelle icône sur le
bureau, baptisée Directory. Elle remplace le voisinage réseau. En double-cliquant sur
cette icône, il est possible d’explorer la hiérarchie de l’ADS et de
visualiser les propriétés des objets. Une autre interface Web existe (DS Web),
permettant de faire des recherches pour trouver des utilisateurs, des groupes, des
imprimantes ou des OU, ce qui signifie que les ADS sont disponibles depuis tout browser
Web, via Internet, depuis un PC, un Mac ou une station UNIX. Mais l’outil le plus
complet pour manipuler les ADS est un Snap-In pour MMC (Microsoft Management Console) avec
un spectre fonctionnel total. Nous abordons en détail cet outil dans le chapitre suivant.
Avant Windows NT 5.0, les relations de confiance entre domaines étaient
unidirectionelles. Avec les ADS, des relations transitives peuvent être définies entre
les domaines en utilisant le modèle de sécurité de Kerberos (voir texte page suivante),
mais il est toujours possible de définir des relations de confiance non transitives entre
des domaines n’appartenant pas à un même arbre de domaine, ou qui ne supportent pas
les ADS (par exemple, les serveurs NT 4.0 qui n’ont pas encore migré). Par contre,
un domaine NT 3.51 ou NT 4.0 ne pourra pas établir une relation de confiance envers un
arbre NT 5.0. En général, on placera au moins un DC (Domain Controller) par site. Un
site peut être défini comme un ou plusieurs sous-réseaux IP. De cette façon, la
réplication tire parti de la topologie physique du réseau. Par ailleurs, lorsqu’un
utilisateur se connecte au réseau, c’est un DC situé sur le même site qui va
l’authentifier. La réplication permet de propager les modifications de l’arbre
entre les différents DC (Domain Controller). Puisqu’il n’y a pas de hiérarchie
entre ces DC, il faut pouvoir gérer les conflits lorsque deux modifications sont faites
en même temps sur le même objet sur deux DC différents. Windows NT 5.0 permet même de
gérer ces conflits au niveau de l’attribut de l’objet. Certains changements,
tels que des modifications de structure ou encore la création ou la suppression de
domaines, ont des conséquences radicales, et il est nécessaire dans ce cas de promouvoir
temporairement un des DC comme FSM (Floating Single Master) qui a priorité sur les
autres. Un seul FSM est possible à un moment donné. Physiquement, la réplication
utilise les RPC (Remote Procedure Call) pour une réplication au sein d’un site, et
la messagerie (ou les RPC) pour les réplications inter-sites. On utilisera alors SMTP,
qui est un standard de messagerie Internet supporté nativement par Windows NT 5.0, mais
aussi, si Exchange est présent, d’autres protocoles comme X400.
Pour vous familiariser dès à présent avec les Active Directory, sachez que le modèle
de répertoire de MS Exchange en est assez proche. Il est possible d’importer le
répertoire Exchange au sein des ADS. La prochaine version d’Exchange devrait
d’ailleurs reposer exclusivement sur les ADS.
La migration
Comment migrer un réseau NT existant
pour pouvoir utiliser les Active Directory? Avant tout, il faut savoir que seuls les
serveurs NT 3.51 et NT 4.0 pourront directement migrer sous NT 5.0. Les machines
équipées de NT 3.1 ou NT 3.5 devront donc préalablement être converties en version
3.51 ou 4.0. Microsoft préconise de migrer d’abord le contrôleur de domaine
primaire (ou PDC). Il faudra spécifier si le domaine est la racine de l’arbre
réseau, ou s’il faut le raccorder à une branche existante. Lors de
l’installation de NT 5.0, la base de données de sécurité est transformée dans
l’ADS créé, les utilisateurs sont créés dans un container baptisé Users, tandis
que les ordinateurs sont stockés dans un container Computers. A ce moment, le résultat
obtenu est hybride. Il est possible d’utiliser les outils de NT 5.0 pour gérer le
domaine, de rajouter des OU ou d’autres hiérarchies dans l’arbre. Le problème
réside dans le Backup Domain Controller (BDC), qui n’est pas encore mis à jour et
ne supporte pas les processus de réplication symétrique. Il faut donc mettre à jour
tous les BDC. L’installation reconnaît la nature des BDC, crée une réplique
d’ADS et insère le serveur dans la topologie de réplication du serveur.
Les clients NT 4.0 Workstation devront migrer sous NT 5.0. Quant aux postes Windows 95, il
faudra installer un Service Pack qui leur permettra de s’intégrer au sein d’un
réseau Windows NT 5.0, c’est-à-dire de s’intégrer à la sécurité Kerberos,
de supporter les ADS par le biais des boîtes de dialogue et des extensions du bureau. La
migration est alors achevée. Cette première stratégie “officielle” de
migration ne parle pas d’un éventuel échec lors de l’installation du PDC,
échec dont le résultat serait un PDC corrompu. Il semble qu’une stratégie moins
risquée serait de migrer d’abord un BCD, puis de le promouvoir en PDC.
Une fois la migration à proprement parler achevée, il faut décider si les ADS de votre
réseau NT seront limités au strict minimum, avec les objets créés par NT, ou s’il
abritera d’autres répertoires de votre entreprise, depuis les simples listes de
téléphone jusqu’à des applications complexes utilisant les ADS comme support de
stockage.
Kerberos et la sécurité
Sur un réseau Windows NT 5.0,
plusieurs protocoles de sécurité sont utilisés. Le premier, qui s’appelle NTLM (NT
Lan Manager), est en fait déjà employé par les précédentes versions de NT. Ce
protocole subsistera pour des raisons de compatibilité et sera utilisé pour la
communication entre des domaines NT 5.0 et les serveurs NT 4.0 subsistants. Le second
protocole s’appelle Kerberos. Basé sur la définition Internet RFC 1510, il
constitue un standard mature en termes de sécurité. Lorsqu’un utilisateur se
connecte via la fenêtre de login classique, il envoie son nom et son mot de passe au
contrôleur de domaine. Celui-ci valide sa connexion en consultant les informations
stockées dans les ADS. Il renvoie au client un ticket signifiant qu’il s’est
effectivement connecté. Ce ticket contient des informations sur les droits de
l’utilisateur, mais il peut être limité dans le temps. Dans ce cas, des services
(tels que le redirecteur réseau) se chargeront de renouveler le ticket de manière
transparente pour l’utilisateur. Lorsque ce dernier essaie ensuite de se connecter à
un autre serveur de fichier, ou à un serveur applicatif, il présente son ticket au
serveur cible. Contrairement à la version NT 4.0, le serveur n’a pas besoin de
vérifier les droits auprès du contrôleur de domaine, le ticket lui suffit. Kerberos
permet ainsi de réduire la charge d’authentification des contrôleurs de domaine.
Seconde qualité de ce protocole, il permet de déléguer l’authentification dans un
environnement multi-niveau : supposons un client connecté à un serveur applicatif
A, qui lui-même a besoin de se connecter à un serveur B. En fait, le serveur A va
demander une connexion au nom du client auprès du serveur B. Enfin, dernier intérêt de
ce protocole, il autorise des relations de confiance transitives entre domaines, ce qui
était impossible avec NTLM.
On notera qu’il est également possible avec Kerberos, lors du login initial du
client auprès du contrôleur de domaine (DC), de ne pas envoyer le nom et le mot de
passe, mais de passer par une technologie de clé publique/clé privée :
l’utilisateur n’envoie que sa clé privée, tandis que le DC vérifie le compte
en utilisant la clé publique obtenue d’après un certificat X.509 stocké dans les
ADS. Le certificat peut aussi être obtenu auprès d’autorités tierces, telles que
VeriSign, ou en utilisant Microsoft Certificate Server. Toujours par le biais de ces
protocoles, Microsoft permet une authentification interactive via les cartes à puce ou à
bande magnétique.
Enfin, les protocoles SSL 3.0 (Secure Socket Layer) et TLS (Transport Level Security)
utilisés entre des browsers et des serveurs Web, et basés également sur des
technologies de clé privée/clé publique, seront nativement supportés par NT 5.0. Cela
permettra de bâtir des solutions Extranet en toute sécurité. Fournisseurs, clients et
partenaires pourront se connecter auprès de serveurs Web sous NT, et créer un canal de
sécurité SSL 3.0. Il sera ensuite possible de faire correspondre des certificats obtenus
par le couple clé privée/publique à des comptes NT pour permettre l’accès de ces
utilisateurs extérieurs à la société à certaines ressources des Active Directory.
DFS, le système de fichier
distribué
Le DFS (Distributed File System) est
un service de Windows NT 5.0 Server qui facilite la recherche et la gestion de données
sur un serveur. Le DFS permet de regrouper au sein d’une unique arborescence les
répertoires et partages situés sur plusieurs serveurs. Ainsi, au lieu de voir un réseau
physique composé de dizaines de serveurs, dont chacun comporte sa propre arborescence de
répertoires, les utilisateurs vont pouvoir voir des regroupements logiques
inter-serveurs. En fait, les DFS sont aux serveurs et aux partages ce qu’un système
de fichier (FAT, NTFS) est aux fichiers.
Historiquement, les répertoires ou disques partagés d’un serveur de fichier distant
sont associés à une lettre (unité logique) sur le poste client. La notation UNC
\\Serveur\partage\repertoire a permis de contourner la pénurie de lettre de
l’alphabet, mais le réel problème est ailleurs! Le problème c’est que
l’utilisateur final est surchargé d’emplacements réseau à retenir,
emplacements qui changent à chaque réorganisation du stockage… Or,
l’opération est très fréquente, à cause de l’éternelle croissance du volume
des données à stocker. DFS simplifie donc énormément la vision qu’aura
l’utilisateur final des ressources réseau disponibles. De plus, DFS est indépendant
du système de fichier sous-jacent (disque dur ou CD-ROM), et même du type de réseau
(NT, Novell ou même Web). Un DFS pourra contenir une première arborescence de fichiers
et une seconde arborescence pointant sur un Intranet, et on pourra même créer des
répertoires virtuels au sein d’un site Web. Seul oubli : on ne peut pas faire
pointer un dossier vers un dossier public Exchange ou, plus généralement, vers un lieu
de stockage géré par une application…
Mais bien d’autres avantages se cachent derrière cette nouvelle technologie. Des
portions entières de la hiérarchie DFS peuvent être déconnectées du réseau, par
exemple à des fins de maintenance administrative, sans que le reste du DFS en soit
affecté. Les administrateurs sont également libres de modifier la structure physique des
serveurs et de déplacer des pans entiers de répertoires d’un serveur vers un autre,
sans que les utilisateurs puissent s’en rendre compte… Plus intéressant encore,
plusieurs copies en lecture seule peuvent être associées à un même nœud du DFS.
Si un serveur physique tombe en panne, une autre source sera automatiquement
sélectionnée. Voilà un système de partage de fichier à haute disponibilité créé
très simplement et à peu de frais. Les DFS vont encore plus loin en permettant le
partage de charge entre ces différentes copies en lecture seule. Les utilisateurs seront
répartis successivement entre tous les serveurs physiques, de manière transparente. Il
devient possible de gérer du partage de fichier à une échelle de plusieurs dizaines de
milliers de clients simultanément.
DFS sur tous les clients Windows
Bien entendu, tout cela fonctionne en
symbiose avec le modèle de sécurité de NT. Les utilisateurs ne sont autorisés à
accéder à une portion du DFS que s’ils ont les droits sur le serveur physique
sous-jacent. Les clients du DFS pourront tout aussi bien être des machines NT 5.0 Server
et Workstation que des machines Windows NT 4.0 Workstation ou des clients Windows 95 via
un nouveau redirecteur réseau. (Dans ce dernier cas, il sera nécessaire – dans
l’état actuel du logiciel – d’utiliser Microsoft Gateway for NetWare pour
accéder, depuis Windows 95, à des portions de réseau Novell). Notons que
l’arborescence DFS est visualisée nativement dans l’explorateur Windows des
clients, et que l’on peut associer une lettre d’unité logique à ce partage
logique comme s’il s’agissait d’un partage physique. On peut même faire
des recherches avec les outils standard. Et les utilitaires de sauvegarde sont en mesure
de balayer d’un seul coup plusieurs serveurs physiques. Physiquement, DFS est un
service tournant sur NT 4.0 ou NT 5.0. Sur cette dernière version, il sera possible de
disposer de plusieurs hiérarchies DFS distinctes par Serveur NT.
Administration
et TCO
Par Olivier Caussin
Le TCO (Total Cost of
Ownership) est basé sur des outils encore très limités comme “Administration
Zero” ou les NetPC. Les technologies présentes dans le ZAK (Zero Administration Kit)
de Microsoft sont à ce jour embryonnaires, mais Windows NT 5.0 devrait marquer une
avancée significative dans ce domaine.
Les objectifs relatifs à la
gestion des réseaux, à l’administration des logiciels installés et à installer,
et à la gestion des utilisateurs connectés ou mobiles sont très ambitieux. Au cœur
de ce dispositif, IntelliMirror est une technologie qui procurera aux utilisateurs des
clients Windows 32 bits les avantages d’une informatique centralisée, ainsi que les
performances et la flexibilité d’une informatique mobile et distribuée.
Il s’agit de dupliquer les données utilisateurs, les applications et les paramètres
système au sein d’un serveur NT 5.0, en utilisant un système de cache intelligent
et une synchronisation centralisée. Les utilisateurs ont donc accès à leurs données et
applications, qu’ils soient connectés au réseau ou non, avec l’assurance que
leurs données sont en sécurité sur le serveur. IntelliMirror permettra plus facilement
de remplacer un poste client endommagé en retrouvant une configuration et des données
personnelles identiques. Il existe déjà des dossiers système un peu particuliers sous
Windows, notamment les profiles ou le bureau. Cette liste incluera désormais le dossier
personnel “Mes documents” qui existera réellement par utilisateur.
L’icône sera présente directement sur le bureau, et les boîtes de dialogue
d’ouverture et de sauvegarde de fichier comporteront un raccourci vers le dossier
“Mes documents”.
La technologie IntelliMirror n’était pas présente dans la première bêta-version
de Windows NT 5.0, et de nombreuses questions pratiques restent pour le moment sans
réponse. Quel sera le volume disque nécessaire sur le serveur, par utilisateur? Quels
seront les impacts de la réplication sur les performances réseau?
Le système d’exploitation client ainsi que les applications seront plus simples à
installer, avec une intervention minimale de l’utilisateur final. Tous les
paramètres d’installation auront été préparés par l’administrateur via des
scripts s’exécutant automatiquement lors du login et du logoff des clients. Les
mises à jour pourront également être transparentes, et les applications iront chercher
sur des serveurs d’installation leurs nouveaux modules et leurs mises à jour. Ceci
inclut les mises à jour des systèmes d’exploitation. Le tout s’appuiera sur
les Active Directory Service. Notons que les prérequis d’installation pour les
applications dans le cadre des logos Windows 98 et Windows NT 5.0 vont évoluer, de
manière à pouvoir s’intégrer dans le cadre d’IntelliMirror.
L’installation sera une composante à part entière du système d’exploitation,
ce qui imposera une unification des procédures. En particulier, il sera interdit pour les
applications d’écrire dans le répertoire \System32, et les composants partagés ne
pourront être mis à jour que via des Services Packs, centralisés par Microsoft. Le
cauchemar des DLL incompatibles entre elles et mises à jour en permanence serait donc sur
le point d’être résolu…
Aujourd’hui, lorsque vous double-cliquez – sous Windows 95 ou Windows NT 4.0
– sur un fichier dont l’extension n’est associée à aucune application,
apparaît une fenêtre qui vous demande avec quelle application il faut exécuter le
fichier. Windows NT 5.0 Server intégrera la technologie ClassStore qui contient un
référentiel d’applications (logiciels génériques, composants ActiveX ou programme
Java) sur le serveur. L’administrateur rendra certaines de ces applications
disponibles pour les utilisateurs. Du coup, ceux-ci seront libres d’utiliser –
dans le panneau de configuration – l’icône Ajouter/Supprimer une application,
qui saura alors se connecter à ClassStore. Les versions officielles de composants ActiveX
situés sur un Intranet pourront être stockées dans ClassStore. Il ne sera donc plus
nécessaire de mettre à jour toutes les pages HTML. De la même manière, si des messages
E-Mail contiennent des pièces jointes Visio ou Acrobat PDF, l’installation de ces
applications pourra se faire lors de l’ouverture des pièces jointes.
Microsoft Management
Console, alias MMC Microsoft
Management Console (MMC) est un outil fédérateur de l’ensemble des utilitaires
d’administration de la plate-forme NT 5.0. Jusqu’à la version 4.0, certains
outils étaient accessibles via le panneau de configuration, d’autres via des
applications spécialisées (dont les interfaces utilisateurs n’était pas toujours
harmonisées). MMC ne dispose à elle seule d’aucune fonctionnalité
d’administration : ce n’est qu’un container de Snap-In (autrement dit
d’outils), chaque Snap-In étant spécialisé dans l’administration d’un
composant système. Plusieurs Snap-In peuvent être combinés au sein de l’interface
MDI de MMC. Par exemple, un Snap-In gère les services NT, un autre remplace le
gestionnaire d’événement, un troisième administre les Active Directory, etc. MMC
est en fait déjà disponible, livré avec la bêta de IIS 4.0 dans l’option Pack
pour NT 4.0.
Toutes les briques d’administration de Windows NT 5.0 seront des Snap-In, et
Microsoft s’engage à en livrer régulièrement, couvrant un spectre fonctionnel de
plus en plus large. Une partie du site Web de Microsoft abritera la Snap-In Gallery, à
partir de laquelle on pourra télécharger les nouveautés. Les interfaces de
programmation des Snap-In sont publiques, elles reposent d’ailleurs entièrement sur
COM, et l’on peut s’attendre à ce que des éditeurs tiers fournissent leurs
propres modules d’administration. Ce sera probablement un prérequis pour obtenir le
logo “Compatible BackOffice”. Par ailleurs, les prochaines versions des
composants de BackOffice (SQL Server, Exchange, IIS…) seront utilisées via des
Snap-In. Enfin, des programmes qui ne sont pas des Snap-In standard, ou même des pages
Web, peuvent quand même être appelés via des raccourcis dans MMC (mais au prix
d’une intégration moindre).
MMC étant par nature très modulaire, il est possible de choisir une série de Snap-In
dans une liste (cette liste tenant compte des droits de l’utilisateur). Un fichier
d’extension .MSC enregistre cette configuration et permet d’ouvrir tous les
outils dans la même configuration que lors de la précédente sauvegarde. Dans la
première bêta de NT 5.0, le sous-menu “Outils d’administration” du menu
Démarrer ne contient d’ailleurs qu’une liste de raccourcis vers de tels
fichiers MSC.
MMC dispose d’un menu, d’une barre d’outils, et affiche dans une
arborescence les éléments gérés par chaque Snap-In. Chacun d’eux peut enrichir
les menus ou la barre d’outils. Lorsqu’un objet est sélectionné dans
l’arborescence, le Snap-In gère son affichage dans la partie de droite. On trouvera
des affichages spécialisés (le moniteur de performance affiche des graphes), des listes
de sous-objets ou plus généralement des contrôles ActiveX, voire même des pages Web
complètes, MMC n’étant dans ce cas qu’une encapsulation d’IE 4.
Windows Scripting Host
Autre technologie visant à réduire
les coûts d’administration, WSH (Windows Scripting Host) permet d’exécuter des
scripts directement sur le bureau Windows, ou dans une fenêtre DOS. On attendait en effet
depuis longtemps une alternative aux fichiers exécutables .BAT. WSH sera disponible pour
Windows NT 5.0 et Windows 98. Les scripts seront stockés dans des fichiers aux extensions
dédiées à chaque langage de script. Fonctionnellement, les scripts sauront manipuler le
bureau Windows et la Registry, au sein d’un langage procédural complet (variables,
boucles, tests, etc.).
La technologie est ouverte, abritant aujourd’hui deux langages – en
l’occurrence, VBScript et JavaScript fournis par Microsoft – mais des éditeurs
tiers ont déjà prévu de créer des extensions pour Perl, REXX ainsi que Python. En
fait, WSH sera disponible au sein de plusieurs hôtes, le premier étant le bureau
Windows, les autres étant Internet Explorer (qui sait exécuter des scripts au sein de
pages HTML), et IIS sur Windows NT au sein des pages ASP. Microsoft précise que
l’empreinte mémoire nécessaire à l’exécution de scripts devrait être
faible, et en aucun cas comparable à celle requise par Internet Explorer. Les
développeurs peuvent d’ores et déjà télécharger le SDK de Windows Scripting Host
sur le site Web de Microsoft.
Le projet de Terminal Windows
Windows NT Hydra est le nom de code
du projet de Terminal Windows. Ce terminal est un client “ultra-léger” capable
d’exécuter les applications Windows qui fonctionneront en réalité sur un serveur
distant. Trois composants sont impliqués. D’abord Windows NT Hydra Server, un noyau
multi-utilisateur capable d’abriter de multiples sessions utilisateurs
simultanément. Hydra Remote Protocol ensuite, qui est un protocole réseau basé sur le
standard de conférence multi-canal T.SHARE/T.120, permettant aux clients de se connecter
au serveur et d’utiliser l’interface utilisateur Windows. Troisième composant
enfin, le client Hydra permet d’accéder aux applications 16 ou 32 bits à partir de
nouveaux terminaux, baptisés “Terminaux Windows” (le prix annoncé de ces
terminaux est d’environ 500$), à partir de PC faisant fonctionner Windows 95,
Windows NT ou Windows 3.11. De plus, via des éditeurs tiers (tel Citrix), il sera
possible d’utiliser des terminaux X, des Mac, des PC sous DOS, des Network Computers
et même des stations UNIX. Il devient ainsi possible de recycler les vieux 286 ou 386
pour en faire des postes de travail tout à fait acceptables.
Avant de décrire plus précisément ces technologies, rappelons au passage que le concept
de Terminal Windows existe depuis plusieurs années, développé par Citrix et Prologue,
et qu’il fonctionne déjà sous Windows NT 3.51. Microsoft a souhaité
l’intégrer à son offre suite à l’engouement suscité par le concept de
Network Computer (NC) qui est clairement une offre concurrente. Des accords technologiques
ont ensuite été signés avec les deux sociétés Prologue et Citrix. En fait, le serveur
Hydra pour Windows NT 5.0 n’est que l’aboutissement de cette politique, et de la
technologie Winframe de Citrix en particulier.
En termes d’administration, cette solution est par nature extrêmement peu onéreuse,
puisqu’il n’est pas nécessaire de configurer des postes clients, toutes les
applications résidant sur un seul serveur centralisé. De même, tous les profils
utilisateurs sont gérés par le serveur, autorisant ou non les clients à utiliser telle
ou telle application. Quant aux terminaux, ils sont physiquement remplaçables sans
occasionner la moindre gêne pour les utilisateurs.
Contrairement aux NC qui intègrent principalement un browser Web (dans lequel toute
application Web peut s’exécuter), le client Hydra n’exécute rien du tout. Il
est possible de parcourir le Web, d’exécuter des applications Java, mais le browser
– ou la machine virtuelle – sera lancé sur le serveur.
Les applications susceptibles d’être exécutées par un utilisateur Hydra sont à
priori infinies. Néanmoins, il existe un certain nombre de points critiques concernant le
partage des ressources des serveurs, et il est probable que les logiciels existants ne les
respectent pas, ce qui signifie un gaspillage de ressources, et donc une configuration
très musclée du serveur Hydra pour quelques utilisateurs. Microsoft a d’ailleurs
annoncé que la prochaine version de sa suite Office serait optimisée en ce sens,
permettant une meilleure montée en charge. Les goulets d’étranglement sur le
serveur Hydra sont la CPU (il ne faut pas qu’un utilisateur puisse pénaliser un
autre client Hydra lorsqu’il utilise des fonctions gourmandes pour le processeur), la
mémoire, l’accès au disque et au réseau. Rappelons que l’environnement
n’est pas réparti, et que les terminaux ne pourront pas utiliser de stockage local,
ni à plus forte raison de lecteur de disquettes. Un seul lecteur de disquettes sera
visible, celui du serveur… Si certaines ressources comme l’écran sont
dupliquées, ce n’est pas le cas du fichier de pagination, unique pour tous les
clients. En somme, Hydra n’est pas, pour l’heure, abouti.
Le
clustering
Par Olivier Caussin
Pour les applications critiques qui se développent dans les
entreprises, la moindre panne peut causer de lourds préjudices financiers. Pour
concurrencer UNIX et les mainframes, Microsoft se devait de proposer une solution de
clustering offrant une tolérance de panne presque totale. Attention, des solutions
partielles de tolérance de panne existent depuis longtemps, qui concernent surtout les
disques durs. Ces technologies RAID sont supportées par Windows NT depuis les premières
versions. Et des solutions plus générales ont été développées sur des bases
propriétaires par certains constructeurs. Ce dont il est question ici, c’est
d’un standard global de disponibilité de systèmes, développé par Microsoft,
Digital, Compaq, HP, Tandem, Intel et NCR. Répondant au nom de code “Wolfpack”,
ce standard s’appelle désormais MSCS (Microsoft Cluster Server). Le principe est de
grouper deux serveurs (ou nœuds) au sein d’une seule machine logique. Tout ou
partie des unités de disque est partagé entre les serveurs, via par exemple une baie de
disque SCSI RAID1. Si l’une des deux machines tombe en panne, l’autre prend le
relais de manière transparente pour les utilisateurs connectés, et seule une
augmentation du temps de réponse pourrait mettre la puce à l’oreille du
client… Pour savoir si la machine principale est en panne, la machine de secours se
contente de scanner périodiquement l’autre serveur via le réseau, ou via une
liaison spécialisée établie entre les deux nœuds. Cette technologie est
d’ores et déjà disponible au sein de Windows NT 4.0 édition Entreprise, mais la
taille du cluster est limitée à deux nœuds. La version 5.0 de NT Entreprise portera
cette limite à 16 nœuds, et surtout permettra de répartir la charge entre les
différents nœuds du cluster. (Il est évident que disposer de 15 machines de secours
pour une seule machine en fonctionnement n’est pas l’objectif recherché; il est
donc nécessaire de répartir la charge entre toutes les machines).
Par défaut, toutes les applications peuvent fonctionner sur un cluster et basculer
d’une machine à l’autre. En fait, c’est NT lui-même qui organise le
transfert des API, permettant aux éditeurs d’aller plus loin, pour supporter les
transactions ou pour supporter le partage de charge introduit par MSCS 2.0. Par le biais
d’une DLL reposant sur ces nouvelles interfaces, l’application pourra
entreprendre des actions supplémentaires telles que la notification aux utilisateurs, la
répartition de la charge entre les nœuds du cluster, etc. En 1998, la version 7.0 de
SQL Server intégrera le support des clusters à deux nœuds et permettra de basculer
les requêtes et les transactions en cours. Il est probable que, petit à petit, toutes
les applications BackOffice de Microsoft sauront travailler sur une architecture cluster.
|
Les Bons Plans Gratuits
