Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

The Mit's Blog

En plus d'intégrer et skier, il sait même écrire !
(Blog de Renaud Comte)

Actualités

SharePoint : Revenons sur la problématique de l'architecture, la volumétrie et des Site Collections

J'insiste souvent mais la structuration du contenu dans SharePoint est un point I M P O R T A N T.

Une fois l'architecture logique acquise, il faut habilement jouer entre

  • Best Practices
  • Fonction natives
  • Methodologies de travail
  • Catégorisation et contenu
  • La volumétrie

Ayant participé a moultes projets comme bien des collégues de toutes sociétés, j'ai personnellement vu déraper et partir en live de jolies projets car soit la volumétrie avait été largement sous estimé et/ou des architecture logiques bien simplistes.

Exemple ?

Simple : 5 divisions dans une société, un seul portail MOSS et hop, on crée plein de sous site dans la Site Directory, on déplace les partage réseau en boucle dans le Document Center, on monte des blogs, on utilise la content query de partout

Ca marche TRES bien au début, c'est même trés joli et apres quelques temps

Boum boum boum

Saviez vous qu'à petites doses la nitroglycérine est un trés bon médicament contre les problémes de crise d'angine mais en dose plus importante et mal manipulé .... BOUM

Point culture

Le saviez-vous? Angine: conseils sur la prise de la nitroglycérine
Diane Lamarre

Vidéo : http://www.radio-canada.ca/television/375sante/videos/14092004_video2.asx

Nitroglycérine Explosif détonant sous l'effet d'un choc. Placé sur un support absorbant et inerte, il est stabilisé et constitue la dynamite.
Médicament destiné à traiter l'angine de poitrine, commercialisé sous le nom de trinitrine (conversion métabolique en oxyde nitrique NO qui provoque une vasodilatation des artères notamment cardiaques).

Attention,je ne dis pas que SharePoint est aussi instable que de la Nitro. Bien au contraire !!!!

Seulement, une fois que l'ensemble de vos données sera à terme déplacé dans une infrastructure SharePoint, il faudra en prendre bien soin.

Il y a un grande différence entre un simple site collaboratif, des milliers d'instance et une reflexion entreprise de la gestion de contenu.

Eh oui, l'analyse, toujours l'analyse de la situation et du besoin reste l'étape souvent la plus importante.

Dernier point sur la notion de volumétrie, ayez toujours à l'esprit qu'un serveur MOSS a souvent une croissance VIRAL
>>> Tout à chacun veut créer son espace de collaboration, de projet. Tranfere sa vie dans son MySite ou génére plein d'espace de réunion ou de dashboard BI.

Multiplier ce genre de besoin par autant d'utilisateur et vous aurez vite faite d'être dépassé !

Bref, estimez la volumétrie finale d'un SharePoint peut être complexe et difficilement prévisible
>>> soyez un poil pessimiste, limite paranoiaque/hypocondriaque smile_regular. On ne pourra vous le reprocher.

Donc, aprés un telle préambule que faut il savoir, retenir, pour éviter le trou béant ?

  1. Concevoir SharePoint comme un offre vaste et globale
    ==> avoir une vision MACRO et non micro du contenu

      
  2. Connaitre et bien envisager les capacités de SharePoint 2007
    ==> Le  Capacity Planning
     *
    WSS 3.0, c'est ici.
     * MOSS 2007, c'est par la.

    Et surtout le "magic number" 2000 !
    http://blogs.developpeur.org/phil/archive/2007/05/22/sharepoint-2007-pourquoi-une-limite-2000-elements.aspx
  3. Pondérer la charge et les volumes utiles
    ==> Attention, il ne faut pas confondre un seuil maximum, seuil conseillé et seuil toléré
    Exemple
     
    Eh oui, les 50 000 SC ne sont pas un absolue
    http://technet2.microsoft.com/Office/en-us/library/6a13cd9f-4b44-40d6-85aa-c70a8e5c34fe1033.mspx?mfr=true
     
  4. Apprennez à concevoir votre stockage SharePoint en Site Collection et Sous Sites Web : ne soyez pas forcement exclusif
    ==>> comme toujours, point d'abus point de dérapage.
  5. Limiter les groupe "à pouvoir" aux seules personnes formées et apte à créer des containeurs de contenu
    ==>> Un auteur sait créer du contenu mais n'a pas forcement un vision compléte de son environnement
     

Afin de limiter un peu la taille du post et eviter de la redite, j'aimerais vous orienter vraiment vers les posts de

Ces posts établissent clairement quelques risques bien connus des architectures SharePoint comme :

  • Un seule et unique Site Collection n'est pas la solution idéale.
  • Une Site Collection appartient à une Base de contenu mais une Base de contenu peut contenir plusieurs Site Collection.
    ==>> préférez donc la creation de Bdd exclusive à vos Site Collection en fonction du besoin et de la volumétrie, evidemment
  • Certes SQL 2005 peut gérer des BDDs de plus de 100 TB mais aprés test, 15GB reste une limite conseillée pour un quota de Site Collection

Derniéres remarques :

  • Attention, il y a des différences de gestion, utilisation entre des sous Sites et de multiples Site Collections, ne vous faites pas surprendre en exportant/important !
    >>> monter des Proof Of Concept et validez les !
     
  • il est bon de penser à tester/éprouver vos architectures ainsi que les machines associées à vos fermes :
  • Malgré ce coté alarmiste, dites vous bien que SharePoint 2007 est quand même prévue pour monter et tenir des charges élevés. Il faut cependant en respecter les usages
    ==>> mon score en volumétrie ?
    Oh, juste plus d'un centaine de terabytes de données pour de la GED et du BI dans du MOSS 2007 donc pas de crainte...

Avec de la discipline, de l'analyse et de la méthodologie, toutes les limites se repoussent aisemment sous SharePoint.

Renaud Comte aka TheMit (Ahhh l'architecture SharePoint)
Member of WygTeam
http://www.wygwam.com

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: jeudi 7 juin 2007 14:58 par themit

Commentaires

Frédéric Latour a dit :

On touche là un peu les limites de SharePoint.

La collection de sites s'avère particulièrement adapté pour partager un référentiel commun mis en oeuvre par l'utilisation de Content types, listes partagées, colonnes "lookup", agrégation, etc.

Ainsi, il n'est pas farfelu d'un point de vue fonctionnel de n'utiliser qu'une collection de sites (au moins pour un département ou encore pour l'ensemble des données de petites et moyennes entreprises).

Dans ce cadre, il est vraiment très facile d'atteindre 15Go de données même pour une petite structure.

Il est dommage que des problématiques de taille de BDD impose des grands écarts dans la mise en oeuvre d'une architecture fonctionnelle de l'intranet.

Une amélioration souhaitable des prochaines versions est :

Soit la mise en oeuvre de fonctionnalités transversales qui puissent être partagées par les collections de sites (plutôt que le relatif cloisonnement actuel).

Soit la possibilité de répartir les Sites Webs (au sens SPWeb) dans différentes bases de données.

Frédéric Latour

Enesys

# juin 8, 2007 10:44

themit a dit :

Entierement d'accord mais bon, il faut attendre la prochaine Beta

Perso, je reve de plus de communication entre les SPSite

Non ?

# juin 8, 2007 10:59

Frédéric Latour a dit :

En effet, cette limite de communication nous est apparue très tôt dans la mise en oeuvre de solutions sous SPS 2003. Nous avons d'ailleurs développé un petit outil de réplication de listes (disponible gratuitement sur notre site www.enesys.fr) qui permet d'avoir une liste maître dans un site et de la répliquer (ainsi que ses changements) dans d'autres sites ou sous-sites. L'objectif étant d'utiliser des colonnes "lookup" dans d'autres sites tout en ne maintenant la liste "référentiel" que dans un seul site.

Je pensais que ce développement ne devrait pas être reconduit dans la version 2007 mais il s'avère qu'il ne sera pas nécessairement inutile à la différence qu'il n'est plus nécessaire de répliquer dans les sous-sites d'une collection; l'utilisation d'une colonne de site "lookup" permettant ensuite d'exploiter la même liste dans l'ensemble des sous-sites.

Il est vrai, qu'il pourrait être intéressant de faire remonter au niveau web application les colonnes de sites (qui deviendraient des colonnes de web application), les types de contenu, les possibilités d'aggrégation...

Bien evidemment cela complexifie certainement d'autres problématiques comme le backup ou le restore de collections de sites (quid des éléments définis au niveau web application???).

Peut-êre le plus simple serait de supprimer le concept de collection de sites. Une collection de sites et une web application pourraient être fusionnées. Il est facile de créer 2 web applications si l'on désire vraiment cloisonner des collections de sites. Dans ces conditions l'architecture de stockage devrait nécessairement prendre en compte la possibilité d'avoir des masses de données considérables pour une collection de sites et l'ensemble des sites de la collection pourraient partager tout ou partie d'un référentiel commun de l'entreprise.

Frédéric Latour

Enesys

# juin 8, 2007 12:05

themit a dit :

Hum, je suis moins d'acccord

J'aime le notion d'isolation que permet les SPSites

Et honnetement multiplier les Web App seraient TRES couteuses en ressources.

la notion de site provisionning associé à Sites/* est franchement fondamental je trouve dans l'archi MOSS

Mais oui, un outil de replication des features/content type serait un vrai plus pour une approche referentiel

non ?

# juin 8, 2007 12:44

Frédéric Latour a dit :

Mon idée est qu'il ne devrait pas être nécessaire d'utiliser beaucoup de web apps car dans les faits il me semble assez rare qu'il ne soit pas nécessaire à un moment ou un autre d'utiliser un référentiel commun.

Je ne vois pas de scénario qui ne puisse être implémenté dans le cadre d'un sous-site plutôt qu'une collection de sites spécifique.

Un outil de réplication serait en l'état un outil appréciable mais être capable d'exploiter directement les features/content type/données de listes/etc d'un autre site (ou plutôt partagés au niveau de la web application) me semblerait plus pratique.

Evidemment, A partir du moment où il est possible de répartir les sous-sites d'une collection de sites sur différentes bases de données et ainsi avoir des collections de sites de plusieurs centaines de Giga et ainsi de permettre une démarche fonctionnelle sans considération de tailles de BDD, il n'est pas vraiment gênant de conserver la notion de collection de sites (cela ajoute néanmoins un concept qui n'est pas forcément utile). Mais à partir du moment où la contrainte précédente est levée, je pense qu'il deviendrait logique de n'avoir qu'une collection de sites et ainsi être à toute évolution et inteconnexion des données potentielles situées sur un site quelconque d'une même société.

Je trouve d'ailleurs (à titre personnel) que dans les argumentaires relatifs au choix de structuration des données soit en collections de sites indépendantes, soit en une seule collection de sites avec des sous-sites, que les "Cons" des collections de sites sont souvent plutôt techniques à comparer aux atouts fonctionnels des d'une collection unique.

Mais bon, des aspects peuvent m'échapper et il est possible que j'occulte des points fondamentaux qui pourraient contredire ma vision actuelle.

Frédéric Latour

Enesys

# juin 8, 2007 17:05

Frédéric Latour a dit :

La suppression de la notion de collection de sites nécessiterait quelques ajustements relatifs aux problématiques de sécurité.

En effet, chaque site personnel est une collection de sites dont le propriétaire est à juste titre l'utilisateur.

Si l'on imagine les sites personnels comme des sous-sites d'une collection de sites unique (dans sa propre web application), un tel mécanisme devrait pouvoir être mis en oeuvre également. Ce qui n'est pas le cas en l'état.

# juin 8, 2007 17:19

themit a dit :

Vrai : si finalement la notion de stockage revient a provisionner la DB avec des Web tout se simplifie a l'extreme

Ce serait un chamboulement complet de la structuration SharePoint mais c'est loin d'être absurde

Ca compliquerait la compatibilité SharePoint mais on en a l'habitude avec le temps

Cependant, je ne sais pas vraiment les impacts niveau BDD d'une telle granularisation.

Vivement la prochaine beta :)

# juin 8, 2007 17:31
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- L’application des MiniDrones Parrot est aussi disponible pour Windows 8.1 par Blog de Jérémy Jeanson le 10-28-2014, 15:01

- L’application des MiniDrones Parrot est enfin disponible pour Windows Phone par Blog de Jérémy Jeanson le 10-27-2014, 09:49

- Mise à jour Samsung 840 EVO sur core server par Blog de Jérémy Jeanson le 10-27-2014, 05:59

- MVP Award 2014 ;) par Blog de Jérémy Jeanson le 10-27-2014, 05:42

- « Naviguer vers le haut » dans une librairie SharePoint par Blog de Jérémy Jeanson le 10-07-2014, 13:21

- PowerShell: Comment mixer NAGIOS et PowerShell pour le monitoring applicatif par Blog Technique de Romelard Fabrice le 10-07-2014, 11:43

- ReBUILD 2014 : les présentations par Le blog de Patrick [MVP Office 365] le 10-06-2014, 09:15

- II6 Management Compatibility présente dans Windows Server Technical Preview avec IIS8 par Blog de Jérémy Jeanson le 10-05-2014, 17:37

- Soft Restart sur Windows Server Technical Preview par Blog de Jérémy Jeanson le 10-03-2014, 19:43

- Non, le certificat public du CA n’est pas un certificat client !!! par Blog de Jérémy Jeanson le 10-03-2014, 00:08