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 
. On ne pourra vous le reprocher.
Donc, aprés un telle préambule que faut il savoir, retenir, pour éviter le trou béant ?
- Concevoir SharePoint comme un offre vaste et globale
==> avoir une vision MACRO et non micro du contenu
- 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
- 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
- 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.
- 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 :
