Performances et planification de charge. Planification de charge Démarche consistant à évaluer une technologie par rapport aux besoins dune organisation,

Présentation au sujet: "Performances et planification de charge. Planification de charge Démarche consistant à évaluer une technologie par rapport aux besoins dune organisation,"— Transcription de la présentation:

1 Performances et planification de charge

2 Planification de charge Démarche consistant à évaluer une technologie par rapport aux besoins dune organisation, et de prendre une décision éclairée pour lacquisition de matériel permettant au système installé de répondre aux attentes en terme de montée en charge.

3 Questions courantes De combien de hardware ai-je besoin ? Ai-je besoin dune ferme de serveurs ? Ai-je besoin de SQL Server ? Quel volume de données puis-je stocker ? Combien de personne puis-je supporter ? Combien de sites vont pouvoir utiliser mes serveurs ? Comment puis-je valider mon architecture ?

4 Buts Fournir un cadre (framework) pour la planification de capacité. Mettre en lumière les principaux pièges à éviter. Identifier les outils disponibles pour valider des décisions de capacité dans votre environnement.

5 Agenda Framework : Utilisateurs : débit et latence. Données : volume et stockage. Caractéristiques matérielles. Autres facteurs. Le démontrer dans votre environnement.

6 Framework Utilisateurs – Débit Charge utilisateurs : typique versus crête : Typique = moyenne des requêtes durant une unité de temps standard (jour de travail). Crête = accès concurrents (versus type utilisateur) ; planifié pour une charge de crête. Profil utilisateur : comportement des utilisateurs : Distribution des requêtes à travers le contenu. Exploitez vos journaux IIS. Principe de base pour lusage ; hypothèse : 10% daccès concurrents. 1 RPS = * Note : Informations cohérentes avec WSSv2 et SPS 2003 ProfilTaux attendu (RPH) Utilisateurs simultanés Nb dutilisateurs total Léger201801 800 Typique361001 000 Lourd60 600 Extrême12030300

7 Framework Utilisateurs - Latence Eléments participant à la latence : Traitement processeur du serveur (bêta2 ~ 40%) : Traitements SQL, nombre de dialogues SQL, traitements AJAX, traitements supplémentaires pour la sécurité. Traitements processeur du client (bêta2 ~ 45%) : Javascript, CSS, requêtes AJAX, interprétation HTML, spécifications de la machine cliente. Transfert réseau (bêta2 ~ 5%) : Bande passante, taille du téléchargement. Recommandations : Ennemi n°1 en terme de latence = les Web Parts personnalisées : Attention : à la complexité des dialogues SQL, aux données inutiles, aux scripts clients trop lourds. Réutiliser du code client existant au lieu den rajouter dautres. Prendre en compte les performances dans la conception du code – ex : définitions des tables HTML. Profiler vos solutions.

8 Framework Données – Volume Combien dobjets ? Infrastructure : sites portails, sites déquipes, sites personnels, librairies de documents, etc. Données : documents, listes, profils, etc. Recommandations : Planifier prudemment la hiérarchie et le déploiement des sites : Limiter le nombre dapplications Web et de pools dapplications. Limiter le nombre de SSP (Services partagés). Planifier une augmentation de la taille de la base de données. Suivre les bonnes pratiques en termes de données et fonctionnalités, ainsi que les limites suggérées.

9 Framework Données – Limites suggérées (bêta 2) ObjetScopeRecommandation Collection de sitesBase de données50 000 Sites WebCollection de sites250 000 (sous) Sites WebSite Web2 000 ListesSite Web2 000 ElémentsListe10 M DocumentsLibrairie documentaire2 M DocumentsDossier2 000 Taille de documentFichier2 Go Documents indexés (MOSS) SSP50 M Scopes de recherche (MOSS) Collection de sites1 000 Nombre de profils (MOSS) SSP5 M

10 Framework Données – Prérequis Stockage Premier critère : stockage des documents : Planifier 1,2 – 1,5 x la taille des fichiers pour SQL Server note : critère dépendant aussi du niveau de RAID utilisé pour les disques SQL. Second critère : index Serveur dindexation : 30% de la taille totale du contenu total indexé. Serveur de recherche : 2 x la taille de lindex.

11 Framework Hardware – Montée en charge de SharePoint Conçu pour accompagner la croissance des besoins des organisations : Ressources serveur : x32, x64, CPU, RAM, disque dur : Recommandations : 64 bits pour les services de « back-end » qui peuvent exploiter ladressage mémoire supplémentaire. SQL : la configuration du disque dur est critique. Ferme de serveurs : Les restrictions en termes de topologie ont été supprimées. Front-End Web, requêtes, index, services Excel, Project, SQL. Services partagés : Actifs par défaut (jusquà 20 par ferme). Adage WSS : le contenu est uniquement limité par les capacités matérielles* : Sites : les portails sont « juste dautres sites ». * Voir les limitations sur les données.

12 Framework Hardware – Serveur unique SQL Express approprié jusquà 500 utilisateurs (typiques). SQL approprié jusquà 5 000 utilisateurs (typiques) : Héberge : 1 000 sites déquipes, portails, et sites personnels. Stocke :10 000 documents. Indexe :100 000 docs (11 docs/sec). 10 rps pour des opérations « courantes ». Type de serveurRAMDisqueCPU Serveur unique2 Go100 Go1 x 2.8 Ghz Pentium-4 (32bits) Un serveur avec : Front-end WEB Application Base de données

13 Framework Hardware – Ferme 4x1x1 Hautement disponible : Utilisateurs :des centaines de milliers. Héberge :des dizaines de milliers de sites déquipes, personnels ou de portails. Stocke :des millions de documents. Indexe :des millions de documents. Type de serveurRAMDisqueCPU Serveurs Front-end2 Go200 Go2 x 2.8 Ghz AMD 64 bits Serveurs dindexation4 Go200 Go2 x 2.8 Ghz AMD 64 bits Serveurs SQL Server4 Go200 Go4 x 2.8 Ghz, dual core, AMD 64 bits front end Web + Requêtes + Services Excel Index SQL Server en cluster

14 Bien dimensionner votre installation Ai-je besoin dune ferme de serveurs ? Type de fermeNombre utilisateurs Commentaires Serveur unique (SQL Express) 500Pas de haute disponibilité Serveur unique (SQL) 5,000Pas de haute disponibilité Ferme moyenne (2 x 1 x 2) 100,000 Pas de point unique de défaillance Ferme importante (4 x 3 x 2) 500,000 Pas de point unique de défaillance Principes de base pour les fermes :* * : le nombre dutilisateurs peut varier suivant les profils dusage, le mix des opérations et le HW.

15 Bien dimensionner votre installation Ai-je vraiment besoin dune ferme de serveurs ? Tout le monde veut une ferme … Utiliser le framework – comprendre les utilisateurs, les données et le matériel. Comprendre les coûts et bénéfices de la haute disponibilité. La plupart des pertes de services sont dues à des problèmes de configuration : TESTER les scénarios de restauration / bascule. S assurer que les périphériques réseau sont correctement configurés. Utiliser MOM pour superviser les fonctions critiques. Métriques pour la bêta 2 : 30 RPS/Front-end Web (~ 200 000* pages/jour/serveur). Scale Out : 8 Front-end Web => 1 serveur SQL. * Requêtes sur les pages qui ne sont pas en cache

16 Autres facteurs Nouvelles fonctionnalités : Sécurité au niveau des éléments. Enrichissement de linterface. Audit. Indexation de grandes listes. Mise en cache : BLOB, Outputs. Réduction de la taille des pages. Sécurité : SSL et IPSec. Sélection de lauthentification : Kerberos, autres providers, etc. Réseau : Cartes, switches, routeurs, pare-feux, etc. Contrôleurs de domaine / Front end Web.

17 Résolution de problèmes Débit faible : SQL – Utiliser les bonnes pratiques SQL pour les performances, spécialement les performances disques. Conflits entre les opérations asynchrones et le timer job. Contention de ressources : nombre dapplications Web, de pools dapplications, de bases de données, etc. Analyser dans tous les codes maisons ou modifiés les dialogues SQL et charges utiles. Rechercher les composants réseau mal configurés (cartes, routeur, etc.). Temps de réponse élevé pour les utilisateurs : Taille des pages : OOB, téléchargement de la 1 ère page ~ 200 Ko ; ne devrait pas être beaucoup plus élevé. Utiliser la compression des pages si possible. Stratégie de cache : activer la mise en cache des BLOB et Output lorsque cest possible. Spécification des machines clientes. Problèmes réseau (voir ci-dessus).

18 Tester votre environnement Outils : Visual Studio Team System (VSTS-T). Microsoft Operations Manager (MOM). Usages : Créer des utilisateurs. Charger des données. Créer des tests simulant des pourcentages dusage. Varier les tests, les facteurs denvironnement, etc. pour identifier les points de blocage. Quand ? Déploiements initiaux. Nouvelles configurations HW. Validation de solutions personnalisées.

19