J’estime que toute personne, pour son ego personnelle, peux se considérer comme il se veut. Mais avant de parler architecture, il faut déjà savoir écrire document d’architecture technique.  Ce blog post a pour but de décrire l’architecture technique d’une plateforme Sharepoint qui sera mise en place via un projet.  Pour tout développement dans le cadre de Sharepoint 2010, la société en question, doit imposer que les bonnes pratiques en matière de développement Sharepoint soient suivies. 
Ces bonnes pratiques sont disponibles sur le site de Microsoft.
  • http://msdn.microsoft.com/en-us/Sharepoint/ff660756 
  • http://msdn.microsoft.com/en-us/library/gg552614.aspx 

 

Architecture Overview

La toute première chose à déterminer est l’architecture que l’on à choisie pour son projet. Vous pouvez voir toutes sortes de topologies sur le site suivant : http://www.microsoft.com/en-us/download/details.aspx?id=30377  
Les aspects les plus importants à respecter sont :

  • * Les nombres d’utilisateurs
  • * Les nombres d’utilisateurs concurrents
  • * La taille des fichiers (surtout pour l’architecture de la recherche)
  • * Si l’on veut une continuité (NLB)
  • * …

Exemple Demande :
Supposons que la demande est tellement large et que y’aura plus de 1000 utilisateurs et approximatif 1TB en données et on veut une certaine continuité. On peut considérer cette topologie. Il faut surtout savoir détailler votre « choix »  

Exemple détaillé de votre choix :

Cette architecture contient 3 serveurs Sharepoint et 1 SQL server 2008 R2. Il y a 2 serveurs Sharepoint frontaux et un serveur Sharepoint applicatif.  Du load balancing est prévu au niveau des serveurs frontaux par le principe de Network Load balancing (NLB).  Cette technique est activée au niveau de l’OS et tient compte du nombre de serveurs présents concernés par le load balancing.
Si un des 3 serveurs Sharepoint devait tomber, la charge de travail serait redistribuée sur les 2 serveurs restants.  Dans le cas où le serveur applicatif  tombe, il est possible de redémarrer la console d’administration Sharepoint depuis un des 2 serveurs frontaux.  Dans le cas où un serveur frontal tombe, l’index de recherche sera complété sur le serveur frontal restant.  Au niveau de l’utilisation de Sharepoint (moteur de recherche) il y aura potentiellement une dégradation puisqu’il y a moins de ressources système pour effectuer le même travail.  La plateforme ne pourra pas gérer la même charge qu’avant (nombre de connexions simultanées).  La plateforme Sharepoint reste néanmoins disponible en attendant que le problème qui a causé la dégradation soit réglé.


  • Architecture  Contraints

Après avoir cité votre choix en architecture, il faut aussi dire en toute honnêteté les points à faire attentions. Voici quelques exemples des contraintes dont la solution sharepoint doit tenir compte :

  • * Chaque logiciel installé doit être compatible avec Windows 2008 R2 64 bit
  • * Chaque logiciel installé de la Platform SharePoint doit être compatible avec Microsoft System Center * Operations Manager (SCOM)  ou de System Center Configuration Manager (SSCM)
  • * Chaque logiciel installé de la Platform SharePoint doit pouvoir tourner dans une machine virtuelle VMWare ou Hyper-V
  • * Si une base de données doit être intégrée dans l'infrastructure de SharePoint, elle doit pouvoir tourner sur version SQL server 2008 R2 64 bit.  .
  • * Si une page web doit être disponible pour les utilisateurs, elle doit être compatible avec Internet Explorer 7 ou plus et/ou Firefox 4.0 ou plus

 


 

Design Overview

Les bonnes practices de MSFT ou par expérience professionnelle doivent-être détaillé dans ce point. 

3.1 Database

Si je dois donner un exemple, il faut déjà se mettre d’accord sur la nomenclature des bases des données. Il faut déterminer pour chaque base de données une structure assez claire.

Par exemple : Technology_Scope_DatabaseType_DB

Voici quelques exemples:
SPS2010_Farm_ManagedMetadataService_DB 
SPS2010_Farm_PowerPointService_DB 
SPS2010_Farm_ProfileService_Profile_DB 
SPS2010_Farm_ProfileService_Social_DB 
SPS2010_Farm_ProfileService_Sync_DB

3.2 Team Fondation Server

Il faut définir un endroit centralisé et un outil de base pour le développement en Sharepoint est Visual Studio 2010 (C#).  
Toutes les sources du projet doivent être répertoriées dans notre outil de gestion de sources Team Foundation Server (TFS).  Tout déploiement se fait via des « features » (.wsp) qui sont générés sur base des sources dans TFS.  Ces features sont ensuite packagés afin d’être déployés.


3.3 Url convention.

Il faut aussi définir qu’il y’a une certaine définition au niveau des noms que l’on va donner aux sites sharepoint. Ceci est surtout pour éviter d’avoir des sites du genre :
http://house.sppirate.net/SitePages/newcar.aspx 
http://portal/ 
http://srv-spsql-gkm:8888/


 

Infrastructure Design

Normalement, l’infrastructure de votre projet devrait mettre à disposition plusieurs environnements : Un environnement de production et un environnement de test conformément aux règles. 
Il sera préférable de décrire tous les environnements de votre projet de dire comment ces environnements seront utilisés.  Je vais vous montrer comment faire la distinction, par des exemples concrets.

Exemple Test : 
L’environnement de test est constitué de 2 serveurs virtuels ou tous les composants sont installés sur un même serveur excepté la base de données.
Le serveur de base de données SQL serveur 2008 est dédié à l’environnement de test.
Cet environnement sert essentiellement à tester la solution fournie par le tiers effectuant le développement.

Exemple Production:
A priori, cet environnement est constitué de 5 serveurs virtuels. 2 serveurs front end, 1 cluster de base de données SQL Serveur 2008, dédié uniquement à Sharepoint.
En plus des serveurs il faut prévoir de l’espace disque dédié à l’archivage Sharepoint.
Dans le cas où il est décidé de choisir Microsoft System Center Data Protection Manager (DPM) comme logiciel de backup Sharepoint, il faudra aussi prévoir un serveur dédié à DPM.

Capacity Planning

Comme pour chaque projet il faut également prévoir une section pour vos biens matériels dans votre document architecture. Bien évidemment il ne faut jamais sortir hors de son budget ni de son Baseline défini par le chef de projet. 
Un exemple sera: 

Serveur Applicatif :

    1. Biprocesseur Quad core
    2. 16Go mémoire RAM
    3. 80Go de disque dur

Serveur SQL :

    1. Biprocesseur Dual core
    2. 16Go mémoire RAM
    3. Taille du disque dur à définir (60Go (SQL server) + taille database) => 120Go

Egalement dans capacity planning aussi parler des aspects comme :

 

Monitoring

Par exemple : Le monitoring des serveurs de la solution Sharepoint se fait via des Sharepoint Server Applications et l’utilitaire SCOM ou SSCM.

Backup

Voici quelques besoins auxquels tout utilitaire de backup de la plateforme Sharepoint doit pouvoir répondre en exemple :

1) Il est indispensable d’avoir un utilitaire de backup qui tienne compte des spécificités des Sharepoint 2010.  Comme l’essentiel des données se trouve dans les bases de données SQL Server 2008 R2, il ne suffit pas de simplement restaurer une base de données.   La fonctionnalité de backup doit permettre de restaurer, par exemple, une collection de site, voir même un site ou un document.  Ces éléments se trouvent dans une base de données de type « Content ».

2) Sharepoint, c’est du dotNet, ce qui implique que les pages sont compilés et mis en mémoire.  Si un serveur Sharepoint est redémarré, il perd toutes les pages qui étaient en mémoire.  Cela prend, en fonction du volume, un certain temps pour recompiler toutes les pages afin qu’elles soient à nouveau disponible en mémoire.  Une ferme Sharepoint ne s’arrête par conséquent qu’exceptionnellement.  Il y a, en plus, des activités de base 24h sur 24 et 7 jours sur 7.  L’utilitaire de backup doit pouvoir être en mesure de faire des « hot backups » de la ferme Sharepoint.
La version SP1 de Sharepoint Enterprise 2010 permet de recouvrir un site ou une collection de site via la corbeille.  Comme il y a des quotas sur les corbeilles, à moins de s’en rendre compte rapidement, il n’est pas toujours possible de récupérer ce qui a été détruit par erreur via la corbeille.  Un backup le permet.

3) La démarche de sauvegardes dans SharePoint 2013 en ce qui concerne la Corbeille à légèrement changée, notamment en ce qui concerne la corbeille de second niveaux.

Restaurer une collection de sites supprimée dans SharePoint 2013 - Voici des commandes que j'ai enfin trouvées : Restore-SPDeletedSite [-Identity] <SPDeletedSitePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-ContentDatabase <SPContentDatabasePipeBind>] [-WebApplication <SPWebApplicationPipeBind>] [-WhatIf [<SwitchParameter>]]

Lorsqu’une collection de sites (c’est-à-dire, un objet SPSite) est supprimée par inadvertance dans SharePoint 2013, celle-ci est stockée dans l’objet SPDeletedSite, pas dans l’objet SPSite. http://technet.microsoft.com/fr-fr/library/ff678226.aspx 

   

Avec toutes ces infos, vous serez capable de créer votre « document d’architecture technique » et ferez un grand pas vers l’architecture..

Prière de faire attention : « Ce contenu est typiquement destiné pour les novices architect en SharePoint, il se peut que d’autre manière existent pour créer un tel document, mais moi je vous offre juste un « guideline » pour vous aider »..