Architecture de Windows SharePoint Services.

L'architecture pour SharePoint™ Team Services "v1.0" de Microsoft a été amélioré et conçue pour Windows SharePoint Services Bêta 2. Dans Windows SharePoint Services Bêta 2, les paramètres du site et les informations, sont avec tous les informations du site - comme les listes de données, tous les documents dans la bibliothèque des documents, et d'autres contenu de pages sont maintenant stockées dans le serveur Microsoft SQL Server™ ou dans des bases de données MSDE. Elles ne sont plus partagées entre les fichiers systèmes et la (les) base(s) de données. Ce changement a été fait en premier lieu pour les raisons suivantes:

• Pour permettre à Windows SharePoint Services Bêta 2 de bien travailler dans de plus grandes installations. Les données dans la base de données peuvent être triées plus rapidement que celles dans le système de fichiers.
• Pour améliorer la disponibilité des serveurs. Si vous avez plusieurs serveurs WEB sans écrans dans une ferme de serveurs[1], quand l'un tombe en panne, un autre peut prendre la relève sans perdre l'accès à quelque page que ce soit .
• Pour améliorer l'intégrité des données stockées. La possibilité d'un conflit entre les informations du système de fichier et la base de données est supprimée, et la base de donnée peut être facilement sauvegardée.

De plus, puisque la nouvelle architecture réduit la dépendance au registres de Windows et la métabase de Internet Information Services (IIS) pour chaque serveur sur lequel fonctionne Windows SharePoint Services Bêta 2, Vous pouvez maintenant créer un système de ferme de serveurs avec de multiple serveurs et héberger bien plus de site Web que vous ne le pouviez avec SharePoint Team Services "v1.0".

Configuration de Windows SharePoint Services Beta 2

Vous pouvez choisir entre deux configurations pour Windows SharePoint Services Bêta 2 : Serveur autonome ou ferme de serveurs. Si vous prévoyez seulement une utilisation légère de votre site, vous pouvez utiliser une configuration de serveur autonome. Si vous hébergez des sites Web d'une grande organisation ou en tant que Fournisseur d'Accès Internet (ISP) et Prévoyez un usage lourd et un grand volume de données vous voudrez plus probablement utiliser la configuration de ferme de serveurs.

Ci-dessous la description d'une configuration de serveurs autonome:

• Il y a un seul serveur fonctionnant avec Windows SharePoint Services Bêta 2.
• Des Sites multiples et des sous sites sont groupés dans des bibliothèques de sites sur chaque serveur virtuel dans IIS qui est prolongé par Windows SharePoint Services Bêta 2. Un Programme d'Interface de Serveur Applicatif Internet (ISAPI) filtre et aiguille les URLs entrantes vers les sites spécifiques sur ce serveur virtuel.
• La graduation est obtenue en ajoutant des collections de sites à un serveur virtuel existant, ou en ajoutant des serveurs virtuels.
• Chaque serveur virtuel a son propre lot de base de donnée de stockage dans SQL Server ou MSDE. La configuration des bases de données pour la ferme de serveurs dirige chaque serveur vers la base de donnée de contenu appropriée pour un site Web donné. Le contenu pour le Site de plus haut niveau et tous les sous sites d'une collection sont stockés dans la même base de donnée de contenu (voir le schémas ci-dessous).

Le diagramme suivant illustre l'architecture pour une configuration de serveur indépendant de Windows SharePoint Services Bêta 2.

Le diagramme ci-dessus montre une architecture similaire à celle utilisée pour SharePoint Team Services "v1.0", à l'exception que toutes les données sont dans la base de donnée de SQL Server plutôt que séparées entre la base de donnée et le système de fichier.

Ci-dessous, la configuration d'une ferme de serveurs:

• Il y a plusieurs serveurs séparés fonctionnant avec Windows SharePoint Services Bêta 2 et SQL Server.
• Plusieurs sites et sous sites sont groupés dans les collections de sites sur chaque serveur virtuel dans IIS qui est prolongé par Windows SharePoint Services Bêta 2. Un Programme d'Interface de Serveur Applicatif Internet (ISAPI) filtre et aiguille les URLs entrantes sur les sites spécifiques sur ce serveur virtuel.
• Chaque serveur virtuel à son propre lot de base de donnée de stockage dans SQL Server. La base de donnée de configuration de la ferme de serveurs dirige chaque serveur vers la base de donnée de stockage appropriée pour un site donné. Le contenu pour le site Web de plus haut niveau et tous sous-sites dans une collection de site stocké dans la même base de donnée de contenu.
• Performance et capacité sont augmentées en ajoutant des serveurs additionnels fonctionnant avec Windows SharePoint Services Bêta 2 et SQL Server.
• La graduation est faite en ajoutant plus de serveurs Web en frontal (pour augmenter le débit de sortie pour le contenu existant), et en ajoutant des sites Web de plus haut niveau, de même que les sous-sites (pour supporter plus de contenu).
• Le ‘Load balancing’ est exécuté en utilisant des commutations et des solutions matériels (CLUSTER), ou des solutions programmes, comme Windows Network Load Balancing Service.

Le diagramme suivant illustre l'architecture pour le Windows SharePoint Services Bêta 2 dans une configuration de ferme de serveurs.

Dans le diagramme ci-dessus, vous pouvez voir les plus grands effets du changement d’architecture. Puisque les informations sont stockées dans la base de données de contenu, vous pouvez distribuer le chargement parmi quelques serveurs Web frontaux sur lesquels Windows SharePoint Services Bêta 2 fonctionne, et ils communiquent tous avec la base de donnée appropriée. Ainsi, une requête venant d'un client peut aller sur n'importe quel serveur web frontal et encore se connecter aux données du site web correct.

Dans une ferme de serveurs, chaque serveur web frontal sur lequel fonctionne Windows SharePoint Services Bêta 2 peut avoir de multiples serveurs virtuels. Chaque serveur virtuel, en tour, peut avoir plusieurs collections de site, qui peuvent avoir un site Web de haut niveau et de multiple site subalternes.

Le diagramme suivant illustre cette hiérarchie.

A propos des serveurs virtuels

Un serveur virtuel est une manière de dépasser la structure d'un serveur Web, en vous donnant un control plus fin sur les paramètres pour des groupes de sites Web particuliers. Ainsi, plutôt que de configurer les paramètres pour un serveur entier, vous pouvez le configurer pour juste un serveur virtuel. Vous pouvez aussi configurer une authentification sur la base d'un serveur virtuel, de telle sorte que différents serveurs virtuels pourront utiliser différentes méthodes d’authentification. Si vous avez quelques sites internes à votre société ou organisation, et d'autres accessible par l’Internet, vous pouvez les héberger sur des serveurs virtuels séparés et utiliser l'authentification appropriée pour chaque environnement. L'utilisation de serveurs virtuels dans Internet Information Services 6.0 (IIS) peut aussi permettre d'isoler un site web des autres.

Ci-dessous la copie écran illustre de IIS 6.0 et MSDE

Vous pouvez spécifier différents jeux d'applications pour chaque serveur virtuel, et être sûr que les changements fait sur un site dans un serveur virtuel ne seront pas reportés accidentellement sur un autre site dans un autre serveur virtuel. Pour plus d'information à propos de jeux d'application et de processus, voir Model de sécurité de Windows SharePoint Services ou l'aide de IIS 6.0.

SharePoint Team Services v1.0 supporte approximativement 1000 serveurs virtuels par serveur physique. Windows SharePoint Services Bêta 2 supporte beaucoup moins de serveurs virtuels par serveur web frontal (approximativement 10). Cette différence est due à l'utilisation de ASP.NET, qui crée un jeu de DLLs compilées distinct sur chaque serveur virtuel. Du fait que Windows SharePoint Services Bêta 2 utilise quelques grosses DLLs, il n'est pas très pratique de les avoir toutes en mémoire au même moment (quand vous étendez un serveur virtuel, approximativement 50MB de mémoire est réquisitionné par le travail de base des processus, incluant ASP.NET). Pourtant, puisque vous pouvez héberger de multiples collections de sites sur chaque serveur virtuel, vous ne devriez pas avoir besoin de créer autant de serveurs virtuels distincts dans Windows SharePoint Services Bêta 2 qu'il n'en était nécessaire dans SharePoint Team Services v1.0.

Structurer l'espace alloué à une URL

Windows SharePoint Services Bêta 2 peut être utilisé dans une variété d'environnement : du petit, du serveur de département, à la grosse ferme de serveurs chez un FAI[2]. Pour s'adapter à ces environnements, Windows SharePoint Services Bêta 2 sur une plate forme IIS 6.0 vous permet de créer l'espace alloué à votre URL en quelques configurations, dont toutes sont basées sur le type de site que vous voulez créer. Windows SharePoint Services Bêta 2 supporte les types de site suivants :

• Sites de domaines. Vous pouvez créer de multiples collections de sites Windows SharePoint Services Bêta 2 avec un nom de domaine réseau comme URL. par exemple, http://monsite or http://monsite.masociete.com. Utilisez des sites avec des noms de domaines pour permettre aux utilisateurs de créer des URL courtes et simples.
• Les sites avec des sous répertoires. Vous pouvez aussi créer de multiples collections de sites qui sont nommées comme des sous répertoires d'une URL de domaine. Par exemple, http://myserver/sites/mysite ou http://www.mycorp.com/myOffice/MyGroup/mysite. Utilisez des sites nommés avec des sous répertoires pour montrer la hiérarchie des sites dans votre organisation ou société.

Vous pouvez choisir parmi ces types de sites, selon les besoins de votre organisation. Après que vous ayez décidé quel type de site à la base vous allez faire, vous pouvez choisir à partir des configurations de la configuration d'espace de nom suivant:

• Un site avec nom de domaine par serveur virtuel.

Par exemple, Server1 contient http://site1, http://site2, et ainsi de suite. Chaque Site Web de plus haut niveau est un serveur virtuel indépendant et a ses propres bases de données. Ce scénario permet à chaque site d'être isolé pour des raisons de facturation ou de sécurité.

• Plusieurs Sites nommés par des sous répertoires sur chaque serveur virtuel.

Par exemple, Server1 contient les sites suivants: http://server1/portal1, http://server1/portal2, http://server1/webapp, et ainsi de suite. Chaque serveur virtuel peut héberger de multiples sites basés sur Windows SharePoint Services Bêta 2, et le même serveur virtuel peut aussi héberger des applications Web. Tous les sites de ce serveur virtuel peuvent partager la même base de donnée de contenu. Cela permet aux équipes des sites Web de coexister avec des portails et d'autres applications Web.

• un site avec un nom de domaine et plusieurs autres avec des noms de sous répertoires par serveur virtuel.

Par exemple, Server1 contient les sites suivants: http://portal/teams/site1, http://portal/teams/site2, http://portal/webapp, et ainsi de suite. Le serveur virtuel contient un site Web de plus haut niveau basé sur Windows SharePoint Services Bêta 2. Les sous répertoires de ce site peuvent être des sites Web basés sur Windows SharePoint Services Bêta 2, ou être utilisés pour des applications Web. Tous les sites basés sur Windows SharePoint Services Bêta 2 pour le serveur virtuel partagent la même base de données.

• Deux serveurs virtuels hébergeant le même contenu (Extranet scénario).

Far exemple, Server1 héberge http://portal et Server2 héberge https://portal.company.com. Les deux serveurs virtuels (et ils peuvent être sur des ordinateurs séparés) partagent la même base de données de contenu, et desservir le même contenu de site pour créer un Extranet. Les deux serveurs peuvent avoir des configuration de sécurité différentes dans IIS (Par exemple, demander un accès SSL sur le site externe, et anonyme pour l’interne), mais partagent leur contenu. Il est à noter que la fonctionnalité de recalcules des liens hypertexte de FrontPage 2003 (Bêta) ne peut pas fonctionner dans ce scénarios, car réparer les liens pour le chemin d'une URL revient à les briser pour une autre.

• Plusieurs sites avec nom de domaine par serveur virtuel (Scénario d'hébergement à grande échelle).

Par exemple, Server1 héberge http://user1.company.com, http://user2.company.com, http://user3.company.com, etc.  Chacun de ces sites est un site Web de haut niveau sur le même serveur virtuel, mais sont adressés à des URLs différentes. Il peut y avoir une ou plusieurs bases de données de contenu, selon l'échelle.

Communication entre Client et Server

Le FrontPage 2003 (Bêta) client communique avec Windows SharePoint Services Bêta 2 en utilisant HTTP, le même protocole que les navigateurs et les serveurs Web utilisent pour communiquer. FrontPage 2003 implémente un mécanisme d'appel de procédure à distance au dessus de la requête HTTP POST, de sorte que le client FrontPage 2003 puisse demander les document, faire les mises à jours de la liste des Taches, ajouter les nouveaux utilisateurs, etc. .

On voit dans la copie écran les extensions FrontPage qui sont installées avec IIS

Le serveur Web voit les requêtes POST adressées au filtre du Programme Interface du Serveur Applicatif Internet (ISAPI filter) pour Windows SharePoint Services Bêta 2 et dirige ces requêtes en conséquences. FrontPage 2003 communique correctement entre client et serveur par les serveurs Proxy (firewalls).

Note : FrontPage 2003 n'utilise pas la requête http PUT. Comme décrit dans les Spécifications HTTP, PUT envoi un document à un serveur Web ; Pourtant, quelques serveurs Web implémentent PUT. Par conséquent, le client FrontPage utilise la requête HTTP POST universellement implémentée pour toute communication avec un Windows SharePoint Services Bêta 2.

Windows SharePoint Services Bêta 2 n'autorise pas le modèle "créer et publier après" dont vous pourriez avoir l'habitude avec d'autres Sites Web. Au moment où vous créez un site Web basé sur Windows SharePoint Services Bêta 2 il est disponible sur le serveur ; vous n'avez pas besoin de le publier sur un autre serveur. Vous pouvez toujours éditer le site Web dans un éditeur de page Web compatible, comme FrontPage 2003 (Bêta), ou ajouter des pages et des documents au site, mais vous n'avez pas besoin de publier les changements— ils prennent effets immédiatement quand vous sauvegardez les fichiers.

Adresser les URLs à des chemins physiques

Windows SharePoint Services Bêta 2 gère l'adressage des URLs entrantes au contenu du site dans la base de données. Quand l'on utilise la configuration ferme de serveurs, plusieurs sites sont stockés dans chaque base de données de contenu. Une base de données de configuration data base garde la trace de quels sites sont adressés à quels base de données de contenu. Les bases de données de contenu elles-mêmes stockent tous le contenu des sites et délivrent le contenu approprié quand le serveur frontal le demande. Dans SharePoint Team Services v1.0, étant donné que le contenu de site était stocké à la fois dans le système de fichier et dans la métabase de IIS, IIS était responsable de l'adressage des URLs.

Puisque l'adressage entre un site et la base de contenu est basé sur l'URL du site, deux Urls ne peuvent pointer sur le même site. Par exemple, vous ne pouvez utiliser à la fois http://www.server_name.com/site1 et http://www.server_name.com/site2 pour pointer sur le même contenu dans la base de donnée. Vous pouvez pourtant obtenir le même effet en configurant http://www.server_name1.com/site1 pour faire une redirection vers http://www.server_name2.com/site1. L'exception à cette règle est un scénario intranet/extranet, où vous pouvez avoir deux serveurs virtuels qui adressent le même contenu de site avec des URLs telle que http://server_name/sites/site_name et http://extranet.company_name.com/sites/site_name. Pour plus d'informations à propos de la configuration d'un scénario Intranet/Extranet, voir Installer et Configurer Windows SharePoint Services Pour un Intranet et un Extranet.

Gérer des pages ASP.NET (Pages ASPX)

Windows SharePoint Services Bêta 2 utilise des pages ASP.NET (Active Server Pages ou pages ASPX) pour les formulaires et les listes. Ces pages peuvent être personnalisées, et vous pouvez ajouter des pages ASP.NET additionnelles pour faire fonctionner des solutions personnalisées au dessus de Windows SharePoint Services Bêta 2.

Les pages ASP.NET dans le répertoire _layouts pour un site SharePoint fonctionnent en mode direct, ce qui signifie qu'elles sont autorisées à fonctionner directement. Le répertoire _layouts contient des pages applicatives tutorielles pour Windows SharePoint Services Bêta 2, telles que les pages Créer une Liste, Créer un champs, et Paramètres du Site, etc. Ce répertoire est considéré comme en dehors du site Web, et ces pages sont fournies directement par IIS à la demande.

Les pages ASP.NET dans un site Web fonctionnent en mode sécurité. En mode sécurité, les pages ASP.NET ne se compilent pas en DLL et seulement un jeux de contrôles spécifiques (préalablement identifiés comme "sûr") sont autorisés à fonctionner. Vous pouvez modifier la liste des contrôles "sûr" autorisés à fonctionner dans les sites Web sur un serveur virtuel spécifique en modifiant le fichier web.config pour un serveur virtuel. Pour plus d'information à propos de la personnalisation ou l'ajout de page ASP.NET dans Windows SharePoint Services Bêta 2, voir le kit de développement logiciel de Windows SharePoint Services.

 

Traduction de François LEBAUDY MVP et Erol GIRAUDY MVP.

http://perso.wanadoo.fr/erolsps/

Extrais de HELP Administrateur en Anglais de Windows SharePoint Services (c) Microsoft.

 

Une autre information, il existe un Guide sur SharePoint (en Anglais). Il permet de mieux cerner certains aspects de cette extraordinaire solution de GED et de KM avec son portail (principal) et ses sous-portails (des espaces de projets et de GED textuelle et iconographique). Dans notre Livre sur SharePoint 2003 nous allons faire une description de ce guide et du SDK, il sera aussi sur le site MSDN de Microsoft http://download.microsoft.com/download/7/1/3/713D186C-4738-4AF6-97BB-8C5C843A56ED/SharepointPSAdmin.chm