J’estime que toute personne, pour son ego personnelle, peux se considérer comme il se veut. Mais avant de parler architecture, il">
Resources For IT Professionals
J’estime que toute personne, pour son ego personnelle, peux se considérer comme il se veut. Mais avant de parler architecture, il">
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 :
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).&nbsurs 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’p; La plateforme Sharepoint reste néanmoins disponible en attendant que le problème qui a causé la dégradation soit réglé.
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 :
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/
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.
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.
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 :
Serveur SQL :
Egalement dans capacity planning aussi parler des aspects comme :
Par exemple : Le monitoring des serveurs de la solution Sharepoint se fait via des Sharepoint Server Applications et l’utilitaire SCOM ou SSCM.
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 »..