Voici donc quelques éléments techniques et fonctionnels relatifs à la réplication.

Dans le cadre de PRA, les sauvegardes sont encore couramment utilisées, mais restent contraintes pas des limites géographiques. Les temps de reprise peuvent être considérablement allongés, alors le choix d’avoir un site de secours d’une distance assez faible de celui de production est réalisé, mais ce choix géographique ne prends pas en compte d’éventuelles catastrophes naturelles, comme des tremblements de terre, etc…. De plus, certaines entreprises doivent respecter des conformités HIPAA, Sarbanes-Oxley …. Les solutions de type « Cloud » (attention si vous hébergez vos données chez une société Américaine, la loi Patriotic Act peut potentiellement être dangereuse pour la confidentialité de vos données !) et de virtualisation apportent des réponses concrètes ! En effet, la virtualisation de  serveurs ne sont que de « simples » fichiers à manipuler, sauvegardable comme un simple fichier WORD, ou presque mais ce n’est pas l’objet du thème abordé ici.

Pour palier aux sauvegardes et leurs contraintes associées, une réplication peut être déployée de façon synchrone ou asynchrone, mais cela alourdit beaucoup le trafic WAN. Il existe des appliances/solutions appelées accélérateurs WAN qui permettent d’optimiser de façon incroyable le trafic généré sur les WAN, ce qui facilité grandement le déploiement de PCA/PRA.

Il convient d’avoir à l’esprit qu’une réplication n’inclut pas (forcément) des notions de reprise/bascule automatique, et n’est pas une sauvegarde ! En effet, une erreur faite à la source sera répliquée vers les cibles ! Une réplication a pour seule fonction de répliquer les données d’un point vers un autre, en s’assurant bien entendu, que celle-ci soit cohérente d’un point de vue données. Les solutions de réplications sont nombreuses sur le marché EMC SRDF/A, Hitachi True Copy, Netapp SnapMirror, Dell Auto-Replication, etc… pour les données et VMWARE SRM, Veeam Backup & Replication, Platespin Protect, vReplicator, etc… pour les serveurs.

Cette étude menée en 2009 (donc pas si lointaine que cela) montre que les moyens mis en oeuvre sont assez rudimentaires… On est loin d’une disponibilité des applications et des données efficaces: la réplication est employée à hauteur de 20% des serveurs virtualisés !

Plusieurs types de protection et de disponibilité de services: High Availability, Business Continuity, Disaster Recovery. HA – haute disponibilité – représente les moyens locaux: disques durs en RAID, carte réseaux double ports, …. BC – continuité d’activité -  fait appel à des notions de clustering (CSV, …) de synchronisation de baie de stockage, VMware HA en local ou sur une distance relativement courte (limite d’une fibre optique, par exemple). DR, ou reprise après sinistre, s’opère la plupart du temps à une échelle WIDE (réseau étendu WAN) de façon asynchrone et demeure complexe à mettre en oeuvre du fait que les paramètres réseaux diffèrent (DNS, …), bande passante relativement faible, appréhender la bascule (failover / failback), …

Nous l’aurons bien compris, la qualité nos liaisons WAN sera une critère déterminant pour la mise en oeuvre de PCA/PRA. Ces PCA/PRA doivent tenir compte de notions de RPO et RTO. Le schéma ci-dessous montre comment déterminer son plan, la situation  idéale est le résultat du recoupement des coûts associés à la mise en oeuvre un PCA/PRA et des coûts liés à une perte de données et/ou d’indisponibilité. Si le coût d’une solution type VMware SRM (Site Recovery Manager) permettant une haute disponibilité du système coûte 100.000 € et que l’indisponibilité du système mettrait 40 salariés au chômage technique d’un coût de 50.000 € par heure, votre objectif doit être de reprendre en 2 heures. Voici un peu l’esprit du schéma présenté ci-dessous.

L’organisme SNIA, Storage Networking Industry Association, nous gratifie également d’un joli tableau prenant en compte les TIER, si vous désirez vous lancez dans l’hébergement d’application ou pour respecter les standards.

Bien entendu, les niveaux de disponibilité sont liés à la fréquence et à la rapidité des transferts entre les sites ! La définition d’un lien WAN pourrait être la suivante: lien réseau disposant d’une bande passante limitée avec une latence non constante, voire hasardeuse, qui peut envoyer les paquets dans le désordre. Bref, tout pour mettre en péril les objectifs RPO/RTO. Le nouveau challenge consiste  à prendre en compte la croissance ininterrompue des données, la criticité des applications et l’augmentation des distances entre les datacenters. Nous avons à l’esprit que la réplication génère un trafic soutenu en plus des éventuelles applications métiers.

Quelles solutions s’offrent à nous ? Deux. L’un consiste à optimiser les liaisons, l’autre d’implémenter des appliances d’accélérations WAN et/ou de déduplication. La plupart du temps, les DSI commandent des liens plus gros, sans mener des investigations préalables, et bien souvent ces nouveaux liens, loués très cher, ne solutionnent pas leur problème de performance ! Mais dans un premier temps, il est important de classifier les données et les applications par criticité, il est inutile d’avoir un RPO/RTO très faible pour une application ne servant qu’une fois par mois, tandis qu’une logiciel de facture ou CRM sera très important et impactant pour l’activité d’une entreprise. De plus, il convient d’analyser les moyens/protocoles employés, certaines technologies propriétaires ou reposant sur de l’encapsulation (FCIP, FCoE) peuvent affecter les performances d’une appliance du fait que les données soient déjà compressées, par exemple. Il est également important de connaître le trafic généré en moyenne, les pics et leur fréquences, combien est-il nécessaire pour transférer un élément ou son delta, …

Allez, rentrons un peu dans la technique

Impacts sur la bande passante

Il existe deux principaux ennemis qui dégradent la bande passante, la latence et la perte de paquets (voir même la réception dans le désordre). L’oversubscription consiste pour un routeur a mettre en file d’attente des paquets (dans le désordre ou inutilisables) en évitant de les perdre et si possible sans dégrader les performances (cela dépend des capacités du routeur). Une retransmission excessive entraine une baisse du GOODPUT. Cette notion fait référence à de la bande passante utile et non théorique. Par exemple, une liaison 2 Mb ne délivre pas 2 Mb, mais peut-être 1.8 Mb, c’est ce que l’on appelle le GOODPUT (voir la définition ici et ici).

Imagine that a file is being transferred using HTTP over a switched Ethernet connection with a total channel capacity of 100 megabits per second. The file cannot be transferred over Ethernet as a single contiguous stream; instead, it must be broken down into individual chunks. These chunks must be no larger than the maximum transmission unit of Ethernet, which is 1500 bytes. Each packet requires 20 bytes of IP header information and 20 bytes of TCP header information, so only 1460 bytes are available per packet for the file transfer data itself (Unix systems, Linux, and Mac OS X are further limited to 1448 bytes as they also carry a 12 bytes time stamp[1]). Furthermore, the data are transmitted over Ethernet in a frame, which imposes a 26 byte overhead per packet. Given these overheads, the maximum goodput is 1460/1526 × 100 Mbit/s which is 95.67 megabits per second or 11.959 megabytes per second. Source: http://en.wikipedia.org/wiki/Goodput

Ce schéma montre bien l’impact des pertes des paquets sur le GOODPUT.

Il convient d’analyser tous vos flux et s’ils sont soumis à des règles de QoS ? Limiter les bandes passantes par flux de façon à assurer le service ou afin de se prémunir de la monopolisation d’une application au détriment d’une autre, demeure essentiel. La paramètre « latence » est également nécessaire d’être pris en compte car plus la distance est grande  plus le chemin à parcourir pour les paquets est important ! (avec le risque de pertes, etc….)

Afin de se prémunir de ce type de problèmes, il existe FEC (Forward Error Correfction), POC (Packet Order Correction), l’optimisation de la fenêtre TCP, etc… Ce lien détaille les différentes optimisations WAN possibles.

À titre d’exemple, augmenter la bande passante devient inopérant en cas de forte latence due à des distances trop importantes entre les équipements sources et cibles.  De même, la bande passante importe peu si les paquets sont perdus ou fournis de manière non-séquencée compte tenu des phénomènes de congestion, comme c’est souvent le cas au sein des environnements Cloud et MPLS plus économiques, mais de moindre qualité.

Enfin, lorsque tous les facteurs sont considérés, le coût de l’ajout plus de bande passante est souvent nettement plus élevé que le coût du déploiement d’une solution d’accélération WAN. Mis à part une augmentation spectaculaire des dépenses de la bande passante récurrents (30% à 60% en moyenne),

Certaines appliances spécialisées dans l’optimisation comme SRDF/A  EMC, Symmetrix Remote, Data Facility/Asynchronous FCIP, etc… promettent:

• Accélère de 5 à 50 fois les applications sur le WAN et même jusqu’à 100 fois dans certains cas
• Réduit de 65 à 95 % la congestion du réseau et l’utilisation de la bande passante du WAN
• Fournit des performances de type LAN aux employés mobiles du monde entier

Riverbed met à disposition un outil permettant de calculer les gains, disponible ici.

Plus le débit WAN est important, meilleur pourra être le RPO/RTO. En effet, la capacité à reprendre d’un site à l’autre et la capacité de sauvegarder le plus vite possible impactent directement la possibilité de mise en oeuvre d’une continuité d’activité et/ou de récupération après sinistre. La diminution de la perte de données maximale admissible (RPO) et la réduction de la durée maximale d’interruption admissible (RTO) s’opère en optimisant les WAN et les VPN.

Considérations liées au stockage

Certains dispositifs de stockage disposent de mécanismes qui leurs sont propres et dédiés à la réplication, comme la déduplication (très bon rendement), la compression, Packet Striping, … Cela peut apparaitre étonnant, mais il convient la plupart du temps de désactiver ces options qui peuvent rendre les algorithmes des appliances inopérants ou moins efficaces. Prenons l’exemple de la compression, en désactivant la fonctionnalité sur la baie, on déporte le calcul CPU vers l’appliance qui est spécialisée pour ce traitement. A noter qu’une appliance d’accélération WAN sera également incapable de traiter une encryption activée au niveau d’une baie. Voici le schéma a respecter:

OPTIMISER -> ENCRYPTER -> DECRYPTER -> DELIVRER

Pour une réplication synchrone, la latence est un facteur très important car les lectures s’effectuent en local mais les écritures sont envoyées vers la baie distante dont l’ acknowledgment est nécessaire !

Prenons le cas d’une fibre noire qui ne nous posera pas de problèmes particuliers jusqu’à 10km (1300nm laser) ou 35km (1550nm laser). On peut partir sur une perte de 5 μs par kilomètres. Une transaction iScsi typique traverse le lien 8 fois, soit 4 roundtrips. Ce qui équivaut donc à donc 5 μs * 35 kms * 8(trips)= 1400 μs soit 1.4 ms. Il faut avoir en tête que les connexions iSCSI longues distances (inter-site) qui traversent des équipements WAN ou de type FC avec IP (iFCP, FCIP, FCoE, …) alourdissent la latence !

Le cas CISCO WAAS / Veeam

Prenons l’exemple concret des apports de Cisco Wide Area Application Services. Cette technologie optimise les performances des applications basées sur TCP. Voici les données: sites reliés en 10 Mb MPLS avec 40 ms de latence (données CISCO/Veeam).

SANS WAAS:

Replica initial — 12.8GB transférés via WAN — Temps total: 3 heures 12min 17sec
Second Replica — 948MB transférés via WAN — Temps total: 23min 45sec

AVEC WAAS:

Replica initial — 4.8GB transférés via WAN — Temps total: 2 heures 22 minutes
Second Replica — 149MB transférés via WAN — Temps total: 11min 21sec

CONCLUSION:

Replica initial — Veeam a transféré 12.8GB, WAAS a optimisé de 4.8GB — Compression totale 62%
Second Replica — Veeam a transféré 901MB, WAAS a optimisé de 149MB — Compression totale 83%

Quelques liens complémentaires:

http://forums.veeam.com/viewtopic.php?f=2&t=2608&start=0#p10774

http://forums.veeam.com/viewtopic.php?f=2&t=2607#p15480

Témoignages

Je suis désolé de faire un peu de pub, mais ces témoignages me semblent tout à fait pertinent à propos d’un retour d’expérience.

Avant, de nombreux clients pensaient que la seule solution adaptée à leur demande croissante était d’ajouter en permanence de la bande passante dans l’espoir de rester en phase avec les besoins de l’entreprise. Un client explique : « Lors du premier déploiement, notre utilisation de la bande passante a chuté. Nous avons pu renégocier nos contrats et nous allons économiser plus de 2 millions de dollars ces deux prochaines années ». En moyenne, les clients interrogés économisent 979 973 $ par an en coûts de bande passante depuis le déploiement de Riverbed Steelhead.

Concernant les bandes de sauvegarde, un client a déclaré : « Nous effectuons des sauvegardes à distance, ce que nous ne pouvions pas faire auparavant. Nous évitons l’utilisation de bandes et le coût de trois ou quatre lecteurs par site. » Certains clients réduisent le nombre de lecteurs de bandes dont ils ont besoin, tandis que d’autres les suppriment complètement : « Nous sommes sur le point d’éliminer tous nos lecteurs de bande et de centraliser nos sauvegardes », annonce un responsable. « Avant, lorsque nous transférions beaucoup de données, nous avions souvent trois ou quatre semaines de retard sur les sauvegardes. Mais depuis le déploiement de Riverbed, il est extrêmement rare que nous ayons plus d’un jour de retard ». Nos économies annuelles sur les bandes, les lecteurs de bande et les sauvegardes à distance sont en moyenne de 84 639 $.

Grandes fenêtres TCP (TCP Window Size)

C’est un paramètre important, voire même le plus important, pour maximiser la bande passante d’un réseau, la bande passante peut être doublée ! Prenons un exemple pour bien différencier les termes: le tuyau d’arrosage représente le lien, le diamètre représente la bande passante, la longueur du tuyau la latence (ou RTT Round Trip Time) et la fenêtre TCP définit la quantité d’eau (données) nécessaire pour remplir le tuyau.

Calcul de la fenêtre TCP optimale

Voici la formule pour calculer la fenêtre: ( bande passante * RTT ) / 8 / 1024 donc pour un lien 2 Mb/sec et 20 ms de latence => ( 2.000.000 * 0.02 )  / 8 / 1024 = 48 Kb – attention il faut convertir le ping exprimé en ms en sec !

Calcul du débit TCP

Pour calculer le débit, la formule suivante s’applique: Taille de la fenêtre en bits / latence en sec = débit en bits. Exemple d’une fenêtre de 64 Kb  avec 30 ms de latence => 65536 * 8 / 0.030 => 17.4 Mbps

La taille de la fenêtre correspond au nombre maximal de paquets qui peut être envoyé sans attendre un accusé de réception positif. Les grandes fenêtres TCP améliorent les performances TCP/IP lorsque des quantités importantes de données transitent entre l’émetteur et le récepteur. Dans les communications TCP classiques, la taille maximale de la fenêtre est généralement fixée sur l’ensemble des connexions et limitée à 64 kilo-octets (65,535 octets). Donc si votre calcul renvoi à un fenêtre de 85 Kb sur un lien 4 Mb, la fenêtre par défaut (64 Kb) sous-utilisera le lien => 64/85 => 75% soit 3 Mb.

Pour appliquer une fenêtre TCP, la formule est le suivante: taille de la fenêtre en bits * 2 ^ facteur d’échelle – Donc pour fenêtre de 32 Ko avec un facteur 3 => 32768 * (2*2*2) = 262.144. Cette valeur sera à appliquer dans le registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters – TcpWindowSize.

Le facteur d’échelle se trouve par le biais d’un analyse de trame et correspond à TCP: Window Scale Option – TCP: Option Type = Window Scale – TCP: Option Length = 3 (0×3) – TCP: Window Scale = 3 (0×3).

Plus d’informations ici.

Meilleure estimation RTT ou latence

Ce site est excellent, il permet de calculer les temps de transferts, etc… pour un débit => http://web.forret.com/tools/bandwidth.asp?speed=4&unit=Mbps

Prenons un exemple, vous devez sauvegarder 200 Go et vous disposez d’une liaison 4 Mbps. En théorie, cette liaison peut transmettre (théoriquement) 1.8 Go par heure, soit 200 / 1.8 = 111.11 heures pour transférer les données soit presque 5 jours ! Donc envoyer une cartouche de sauvegarde à l’autre bout du monde prendra moins et coûtera largement moins cher qu’acheter une liaison d’un débit plus important !

Prenons un autre exemple, 9 heures de travail génèrent 20 Go de données (ROC – Rate Of Change) et vous disposez d’une fenêtre de 24 heures – 9 heures de travail soit 15 heures disponibles pour réaliser la sauvegarde, soit au minimum 20 Go/ 15 heures = 1.33 Go/heure donc une ligne de 3 Mbps suffit pour atteindre l’objectif !

Il est important de connaitre le ROC et la fenêtre de sauvegarde disponible concernant les données à sauvegarder et/ou répliquer, bien entendu tout ceci est  directement influencé par le RPO ! Il est donc très important de définir une criticité des applicatifs par ordre d’importance – critique: AD, DNS, CRM – important: Sharepoint, … – peu important: archive, … – Il convient également de faire attention au type de serveur à prendre en compte, un serveur Exchange représente, par exemple 2 partitions, une système et l’autre contenant les fichiers EDB, c’est à dire qu’il est nécessaire de sauvegarder régulièrement les EDB, et moins souvent le système, en excluant par exemple le SWAP, les temps, … Le cas de la VDI est plus complexe, car il faut sauvegarder les profiles, cache web, … Pour un serveur Oracle, une réplication du redo log peut s’avérer suffisant !

Conclusion

Pour conclure, la réplication de données inter-sites et les éventuelles problèmes de performances associés ne se résolvent pas uniquement en louant une liaison plus importante, il est important de:

• Définir un niveau de criticité des applications et données à protéger
• Analyser et réaliser un tuning TCP de vos liaisons
• Mettre en oeuvre des appliances d’accélération WAN
• Analyser, au niveau serveur, ce qu’il est nécessaire de sauvegarder
• Connaitre sa fenêtre de sauvegarde et son ROC (par application, ….)
• Dans le cadre de PRA (réplication de VM en asynchrone, …), prioriser les flux (QoS, …)

Quelques liens supplémentaires

Livre Windows Server® 2008 TCP/IP Protocols and Services

TCP/IP Registry Values for Microsoft Windows Vista and Windows Server 2008

New Networking Features in Windows Server 2008 and Windows Vista

Réglage automatique de la fenêtre de réception TCP

Next Generation TCP/IP Stack

Bref, voici un billet regroupant l’ensemble des raccourcis clavier censés nous aidez à palier à la disparition du défunt menu démarrer, quelques How-To, mais aussi un tuyau pour faire réapparaitre le menu démarrer.

Les raccourcis clavier

– Retour à l’interface Metro

+ 1, + 2, … - Lance les programmes dans la barre des tâches en partant de la gauche vers la droite

+ C - Apparition du menu « Charms »

+ E – Affiche l’explorateur

+ F et/ou W - Lance la recherche

+ I - Lance la panneau de configuration rapide

+ L - Verrouillage de la session

+ M et/ou D – Minimise l’application sélectionnée – Basculer en mode classique – Cache/affiche toutes les applications

+ O - Modification/verrouillage de l’orientation (tablette)

+ P - Affiche le menu de projection / affichage

+ A - Affiche le panneau des applications

+ R - Lance une fenêtre de commande

+ U - Lance les options d’ergonomie

+ H - Lance le panneau de partage

+ X - Affichage des principales fonctionnalités

+ ← → ↑ ↓ - Manipulation de fenêtres

+ ← → - Bascule d’une fenêtre d’un écran à l’autre

+ HOME - Minimise toutes les fenêtres sauf celle active

+ K - Affiche les options de certains périphériques

+ ESPACE – Basculer la/les langue(s) du clavier

+ ENTREE – Affiche le narrateur

+ + / – - Affiche la loupe (zoom avant/arrière)

+ PAUSE – Affiche la fenêtre « système »

+ IMPR ECR – Capture l’écran et l’enregistre dans Mes Images au format PNG

CTRL + SHIFT + ESC - Affiche le gestionnaire des tâches

+ . – Basculer entre les applications du bureau (à droite de l’écran ajouter SHIFT pour la gauche)

+ TAB – Basculer entre toutes les applications (bureau & Metro)

Vous pouvez télécharger ici un document synthétique.

Les How-To – spécial Windows 8

Pour aider les utilisateurs à monter rapidement en puissance vis-à-vis de leur expérience de travail avec Windows 8 mais aussi de trouver des raccourcis, Microsoft vient de publier une  série de How-To sur Windows 8 ! Merci à Laurent Gébeau pour le lien !

Windows 8 How To: 1. Switch Between Metro UI and Desktop Mode
Windows 8 How To: 2. Switch Between Apps or Snap Apps
Windows 8 How To: 3. How to Power Off Your Device
Windows 8 How To: 4. Show and Access the Control Panel
Windows 8 How To: 5. Show and Access Administrative Tools
Windows 8 How To: 6. Show All Apps
Windows 8 How To: 7. Switch Between Windows Accounts and Local Accounts
Windows 8 How To: 8. Set up a Picture Password
Windows 8 How To: 9. Set Up a Printer
Windows 8 How To: 10. Customize Metro UI – App Tiles and Groups
Windows 8 How To: 11. Install Language Packs for Multilingual Support
Windows 8 How To: 12. Show and Use “Run” Command
Windows 8 How To: 13. Show and Use cmd Prompt (DOS Mode)
Windows 8 How To: 14. Show and Use PowerShell
Windows 8 How To: 15. Show and Use Desktop Applications
Windows 8 How To: 16. Install .NET 3.5 and Windows Live Essentials
Windows 8 How To: 17. Add New Tab or New InPrivate Tab in Metro Style IE Browser
Windows 8 How To: 18. Configure WiFi Connection and Airplane Mode
Windows 8 How To: 19. Show Hidden Files, Folders and Drives
Windows 8 How To: 20. How to Start Windows 8 in Safe Mode
Windows 8 How To: 21. Install and Uninstall Metro Style Apps
Windows 8 How To: 22. Enable or Disable Sharing Between PCs Using HomeGroup
Windows 8 How To: 23. Find and Use Windows Help and Support
Windows 8 How To: 24. Show and Configure Free Anti-Virus App (Windows Defender)
Windows 8 How To: 25. Show and Enable Split Touch Keyboard (On-Screen)
Windows 8 How To: 26. Set up Remote Desktop Connection
Windows 8 How To: 27. Backup your Files Using File History
Windows 8 How To: 28. Restore Files Using File History
Windows 8 How To: 29. Restore System to a Previous State Using Restore Point
Windows 8 How To: 30. Restore your Device using Refresh and Reset

Restaurer le menu démarrer

L’excellent Lee Chantrey nous gratifie d’un utilitaire simple qui permet de restaurer le menu démarrer, pour ceux qui sont perdus. J’ai testé d’autres utilitaires, celui-ci fonctionne le mieux car les autres ne fonctionnent pas ou sont détectés comme étant des Malwares.

Notez bien que je ne suis pas un expert SQL, mais je pense que les méthodes décrites ci-dessous doivent être mises en oeuvre et considérées comme des bonnes pratiques. Si vous êtes expert SQL, n’hésitez pas à me remonter vos expériences et éventuelles omissions de ma part…

Stockage et les I/O

L’élément clé qui va impacter directement les performances d’un base de données transactionnelle est la notion d’IOPS (Entrées/sorties par seconde, le ratio associé, …), le débit n’étant absolument pas un critère de performance, mais une analyse des compteurs suivants seront déterminants: Moyenne lecture/écriture bytes/s, lecture/écriture par seconde, Lecture/écriture disque bytes/s, Moyenne disque lecture/écriture par seconde et enfin Moyenne disque de la file d’attente. Voici quelques Pattern I/O typiques:

• OLTP (Online Transaction Processing) => lectures/écritures aléatoires intensives entre 8k et 64k – le plus souvent read-ahead – IOPS prépondérant
• RDW (Relational Data Warehousing) => lectures séquentielles sur 64k et au-delà – écritures séquentielles sur 128-256k – débit prépondérant
• Journaux => I/O séquentiels intensifs en écriture – latence prépondérante
• Analysis Services => lectures sur 64k aléatoires
• Ou alors le reste (Mixed)

Il convient donc de correctement dimensionner votre système (pas de sur-dimensionnement et encore moins de sous-dimensionnement) qui sera capable d’atteindre vos attentes en termes d’I/O mais aussi de latence (généralement entre 5 et 20 ms) tout en prévoyant la croissance des données. En premier lieu, les placements des différents composants SQL sur des piles RAID distinctes est essentiel, à savoir:

La règle veut que s’il n’est pas possible de répartir sur plusieurs piles RAID distinctes (physiquement différentes), il convient de regrouper sur la même pile les bases ayant le même profile I/O (Pattern I/O).

Plusieurs outils permettent de benchmarker votre serveur SQL afin d’en déterminer l’empreinte (Pattern I/O) pour ensuite pourvoir dimensionner sereinement sont stockage. Les outils permettant de connaitre les performances et/ou limites d’un stockage sont SQLIO et IOMETER (voir mon article sur le formatage des résultats). Un outil comme SQLIOSim permet de simuler un type de Pattern I/O pour analyser le comportement du serveur SQL/stockage, la nuance est importante !

Alignez vos partitions

Déjà abordé dans un précédent billet, l’alignement des partitions est un facteur important de performance souvent négligé. Si les pistes ne sont pas alignées avec les partitions, une opération d’E/S peut s’étendre sur deux pistes, ce qui entraîne une altération des performances, jusqu’à 25% de perte. Bref, il est impératif de le faire POST-INSTALLATION car l’alignement ne peut pas être modifié ultérieurement sans perte de données.Historiquement, la taille du secteur a été fixé à 512 octets. Les nouveaux lecteurs peuvent offrir des secteurs de 1 Ko, 2 Ko ou 4 Ko. La plupart d’entre nous appellent l’unité d’allocation par un autre nom: le cluster. La taille du cluster est déterminée lorsque la partition est formatée par le système d’exploitation. Par exemple, si les secteurs d’un disque dur de 512 octets (soit une décalage de 32,256 octets (63 secteurs*512 octets), soit exactement 31,5 KB), un cluster de 4 Ko dispose de 8 secteurs, et un cluster de 64 Ko a 128 secteurs. Il peut être donc légitime de formater avec un alignement à 32 Ko soit 32,768 octets. Bien souvent, les fournisseurs prennent les 63 premiers secteurs (cachés).

Windows Server 2008 formate par défaut avec un alignement à 1024 Ko soit 1.048.576 octets, tandis que les versions précédentes réservaient automatiquement 63 Ko et la partition venait « se coller » directement après. Cette valeur fournit une solution pérenne (du fait des réservation de secteurs par certains fournisseurs de hardware) et adaptée à des tailles de 64 Ko, 128 Ko, ou encore 256 KB voire même (rarement usité) 512 Ko et 1024 Ko.

L’image ci-dessous représente se base sur une taille de cluster de 4 ko et met en avant deux cas de figures: alignement (4eme ligne) et non alignement (3eme ligne). Le non-alignement met en évidence que la partition étant collée directement après le secteur 63, il reste 1 secteur de 512 octets vide sur un stripe (de la pile RAID ndlr) d’où un décalage des écritures, à savoir qu’une opération E/S requiert plusieurs E/S. Par exemple, 8 opérations E/S d’une taille de secteur de 8 Ko reviendrait en fait à 10 opérations E/S à cause du misalignement (soit 20% de perte de performance).

Même exemple, mais avec une taille de cluster définie à 64 Ko.

Concernant le formatage NTFS de vos partitions, Microsoft recommande une taille d’allocation de bloc d’une valeur de 64k aussi bien pour la partition hébergeant tempDB, les journaux et les bases.

Profondeur de file d’attente de vos HBA (Queue Depth)

Ce paramètre important et souvent négligé désigne combien de commandes bloc vont être envoyés simultanément. Un paramétrage trop petit va restreindre, étouffer les performances et augmenter la latence car le stockage va passer son temps a envoyer pour une opération de lecture de table par exemple de multiples commandes alors qu’une seule aurait probablement suffit. Par exemple pour un paramètre trop faible, pour lire un table 10 commande blocs vont être envoyées, un paramétrage affiné n’enverra que 2 commandes pour la même opération ! Par défaut, et généralement, le paramètre est de 32 sur les HBA; Microsoft recommande au moins 64 mais au delà il faut benchmarker, car ce site a démontré que en passant d’un paramètre de 64 à 128 on perds 90 I/O. En effet, un paramétrage trop grand génère également de la latence car le stockage va attendre que la file d’attente soit remplie pour l’exécuter…

Les pilotes sont également importants, il convient de voir avec les constructeurs s’ils ont de recommandations à ce sujet, Storport doit être préféré dans le plupart des cas (obligatoire en x64 car c’est le seul supporté) à SCSIport. Pour rappel, le premier accepte une valeur maximale de 255 I/O par LUN tandis que le dernier (SCSIport) est de 255 pour la HBA… Le multipathing MPIO optimal est l mode Round-Robin. Je rappelle également qu’utiliser 2 HBA (FC ou iSCSI) distinctes permet de répartir la charge sur l’ensemble de l’architecture PCI et si possible de dédier les ports à SQL.

Il convient de monitorer la latence, la file d’attente actuelle (Current Disk Queue) doit être inférieure à 2 (3 au maximum) soit une valeur de 54 pour 23 disques => 54/23 = 2.34, attention donc ET les transferts disques/s doivent être inférieurs à 0.3.

Un benchmark a démontré qu’une Queue Depth à 32 délivre 48 IO tandis qu’à 64, on atteint 162 I/O !

Les FILEGROUPS

Pour rappel, SQL génère trois types de fichiers différents: les données primaires MDF, secondaire NDF et les logs LDF. La fonctionnalité FILEGROUP permet de regrouper des données pour des raisons d’administration mais aussi de performances (voir plus bas). A noter que les journaux de transactions ne font jamais partis d’un FILEGROUP. Dans l’exemple ci-dessous une base MaBase est crée avec deux fichiers dans un FILEGROUP MaBase_FG_2 et pour terminer on définit ce FILEGROUP comme étant par DEFAULT.

[sql]

CREATE DATABASE [MaBase] ON PRIMARY
( NAME = ‘MaBase’, FILENAME = ‘D:\MSSQL\DATA\MaBase.mdf’ , SIZE = 4096KB , FILEGROWTH = 1024KB ),
FILEGROUP [MaBase_FG_2]

( NAME = ‘MaBase_2′, FILENAME = ‘D:\MSSQL\DATA\MaBase_2.ndf’ , SIZE = 4096, FILEGROWTH = 1024KB ),

( NAME = ‘MaBase_3′, FILENAME = ‘D:\MSSQL\DATA\MaBase_3.ndf’ , SIZE = 4096, FILEGROWTH = 1024KB )
LOG ON
( NAME = ‘MaBase_journaux’, FILENAME = ‘E:\MSSQL\DATA\MaBase_journaux.ldf’ , SIZE = 2048, FILEGROWTH = 10%)
GO
ALTER DATABASE MaBase
MODIFY FILEGROUP MaBase_FG_2 DEFAULT
[/sql]

Ou encore pour ajouter un fichier à un FILEGROUP:

[sql]
ALTER DATABASE MaBase
ADD FILE (NAME = MaBase_4, FILENAME = ‘D:\MSSQL\DATA\MaBase_4.ndf’)
TO FILEGROUP PRIMARY;
GO
[/sql]
L’avantage permet d’étendre une base sur d’autre piles RAID/disques et donc, de pouvoir gérer un manque de place par l’ajout de stockage mais aussi de répartir les écritures sur plusieurs stockage d’une même base, de plus SQL équilibre l’ensemble des lectures/écritures sur un FILEGROUP ! Par exemple il est ainsi possible de place une table très sollicité sur un RAID-10 et les autres sur un RAID-5 ou séparer les tables des index. L’intérêt des stockages utilisant la fonctionnalité AUTO-TIERING est remarquable pour ce type d’application, il convient néanmoins de s’assurer du bloc minimal pris en charge par l’algorithme, à 5 Mo il ne servira à rien !

L’idée des FILEGROUP est de répartir les données sur plusieurs FILEGROUP placés sur des stockage distincts (deux partitions sur une même LUN ne sert à rien…) afin d’accroitre les performances. Ainsi pour une table répartie sur 4 FILEGROUPS, SQL utilisera 4 threads pour accéder à la table, soit 1 par FILEGROUP qui bien sont placés sur des piles RAID distinctes, d’où l’obtention d’excellentes performances !

• Il est recommandé de mettre de .25 à 1 fichier par FILEGROUP par CPU
• RECOMMANDE pour la base tempDB d’avoir 1 fichier par CPU
• Tous les fichierrs d’un même FILEGROUP doivent avoir la même taille
• Un processeur quadri-coeurs compte comme 4 CPU, l’Hyperthreading ne compte PAS
• Si le compteur File D’attente Disque est supérieur à 3, réduisez le nombre de fichier par disque

Vous trouverez ici comment manipuler les FILEGROUP et ici une discussion intéressante sur la ratio FILEGROUP par CPU.

NUMA

Depuis SQL Server 2005 (et SQL Server 2000 SP4 , avec limitations), la prise en charge de NUMA (soft-NUMA ou NUMA dans le hardware) est effective. Beaucoup d’encre a coulée à ce sujet, et je vous recommande la lecture de plusieurs sites à ce sujet.

La requête suivante permet de savoir si NUMA est utilisé de façon matérielle ou non.

[sql]
SELECT DISTINCT memory_node_id
FROM sys.dm_os_memory_clerks
[/sql]

Ces sites vous permettront de vous documenter à propos de NUMA:

• http://technet.microsoft.com/fr-fr/library/ms345357%28v=sql.110%29.aspx
• http://msdn.microsoft.com/fr-fr/library/ms178144.aspx
• http://blogs.msdn.com/b/slavao/archive/2005/08/02/446648.aspx

Voici les sites que je vous recommande de lire pour approfondir vos connaissances:

• http://blogs.technet.com/b/beatrice/archive/2008/04/21/to-numa-or-not-to-numa.aspx
• http://sqlskills.com/blogs/jonathan/post/SQL-Server-and-Soft-NUMA.aspx
• http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-i-o-completion-thread-lazy-writer-workers-and-memory-nodes.aspx
• http://blogs.codes-sources.com/christian/archive/2011/06/10/sql-server-parall-liser-une-requ-te-avec-les-processeurs-intel-xeon-nehalem-ou-processeur-serveur-amd.aspx

Quelques astuces

• Formatez toujours votre stockage en NTFS en rapide et créer vos bases en Instant File Initialization
• La fonction AUTOGROW peut/doit être laissée active (pour des raisons de sécurité) à condition de suivre l’évolution de vos bases !
• Pré-définissez la taille de vos bases et des jounaux (environ 20 à 30% de la taille d’une base)
• Définissez une taille maximale pour ne pas excéder le stockage en place au détriment d’une autre base
• Votre strize size doit être de 64 ou 256k
• Activez le Page Checksum – allez chez le MVP Christian Robert pour en savoir plus.

Les compteurs de performances

Le stockage

Les performances d’un stockage se mesurent à l’aide des indicateurs suivants: (référence Microsoft http://msdn.microsoft.com/en-us/library/ms191246.aspx)

• Moyenne des écritures et lectures disque par seconde (Average Disk Sec/Read et Write) => mesure les temps de réponses
• Lecture/écriture disque, octets/s (Disk Read/write Bytes/s) => mesure le débit (throughput) et permet ainsi de savoir si on sature une interface PCI-e, par exemple => IOPS
• Transferts par seconde => permet de savoir si une application et/ou son Pattern I/O génère plus de requêtes I/O que ne peut supporter le stockage
• Lectures et écritures par seconde => permet de déterminer le Pattern I/O
• Moyenne disque, octects/lecture & écriture (Average Disk bytes/read & write) => définit la taille des I/O
• Longueur moyenne de file d’attente (Average Disk Queue Length) => mesure les opérations disques en attente (2 par disque)
• Inactivité en % (% Idle Time) => mesure l’activité disque
• I/O partagées => mesure s’il faut plus d’une (1) commande pour traiter une I/O
• Taille de file d’attente du disque actuelle (Current Disk queue Length) => mesure les I/O en attente

Des temps de réponses élevés (Average Disk Sec/Read et Write – valeur supérieure à 15 ms) ou des I/O trop importants (Disk Transfers/s – IOPS au délà de ceux admis par le disque ou la pile RAID) sont généralement provoqués par un non-alignement des partitions.

Un débit faible (Transfers/s) mais un compteur Disk Bytes/s élevé indique une possible fragmentation du stockage (valeur I/O partagées ou Split I/O) du fait qu’une simple requête est divisée en plusieurs.Un nombre insuffisant de disque dans un pile RAID peut être détecté si la valeur Disk Queue Length est supérieure à 2 voire 3 dans certains cas (disque SAS ou FC – 10 ou 15k).

A noter également qu’une longueur de file importante et une latence faible indique que la file se vide et se rempli très vite, et que par conséquent la système est efficace ! (tout ça pour dire qu’une file importante n’est pas FORCEMENT un problème à part si la latence est élevée !)

La mémoire

Les problèmes mémoire souvent causé par une insuffisance, une fuite mémoire, ou des commutateurs inadéquats (/3GB). Voici les compteurs à prendre en compte pour une analyse

• % d’octets dédiés utilisés (% Committed in use) => mesure la mémoire utilisé
• Entrés libres en table des pages systèmes => mesure le nombre de pages NON utilisées par le système
• Pages par seconde => mesure les pages sont utilisés pour corriger des page faults

Les fuites mémoires sont repérables grâce aux deux derniers compteurs, à savoir une valeur inférieure à 5000 pour le premier compteur, et une valeur supérieure à 1000 pour le second. L’ajout de mémoire doit être opéré si le premier compteur renvoi une valeur supérieure à 80%.

Le processeur

Les compteurs suivants indiquent une saturation du processeur, à savoir:

• % temps processeur => une valeur supérieure à 85/90% indique que le processeur est saturé
• Longueur de la file processeur => une valeur supérieure au double des CPUs installés indique une saturation – exemple un quadri-coeur: 4*2=12 étant la valeur maximale

Le réseau

Les compteurs suivants permettent de mesurer un réseau, à savoir:

• Total des octets/s (Bytes Total/sec) => indique de débit (voici la formule de calcul: paquets/sec * 1500 * 8 / 1 000 000)
• Longueur de la file d’attente de sortie (Ouput Queue Length) => mesure la longueur d’une file en paquet. Une valeur supérieure à 2 indique une saturation

La formule suivante indique une saturation de l’interface: Total des octets/s / bande passante actuelle > 0.6

SQL Server

Les compteurs suivants permettent de mesurer la performance d’un serveur SQL:

• SQL Access Method\Pages Splits/s => mesure le nombre de pages partagées (dû à un index plein)=> doit être inférieur à 100
• SQL Statistics\Batch Requests/s => mesure l’activité globale du service SQL => une carte Gigabit supporte en 30000 !
• SQL Buffer Manager\Lazy Writers/s => mesure le nombre de pages « dirty » écrites sur le disque => idéalement, la valeur doit être le plus proche de zéro avec un maximum de 20/25
• SQL Buffer Manager\Page Life Expectancy => mesure la durée de vie d’une page dans le buffer => la valeur doit être inférieure à 300 secondes

Plusieurs documents sont à imprimer et à garder sous la main, ils récapitulent en détail les compteurs essentiels a surveiller. A télécharger dans l’ordre ici - ici et ici. Et en bonus, une vidéo

Les Dynamic Management Views – DMV

Les fonctions et vues de gestion dynamique renvoient des informations sur l’état du serveur, qu’il est possible d’utiliser pour surveiller l’état d’une instance du serveur, diagnostiquer des problèmes et régler les performances.

La DMV sys.dm_exec_query_stats fournit des statistiques de performances agrégées pour les plans de requête mis en cache, notamment des détails sur les lectures/écritures physiques et logiques et le nombre de fois que la requête a été exécutée. Il est ainsi possible de connaitre les requêtes les plus coûteuses en I/O ou encore en CPU, par exemple.

[sql]
SELECT TOP 10
[Average CPU used] = total_worker_time / qs.execution_count
,[Total CPU used] = total_worker_time
,[Execution count] = qs.execution_count
,[Individual Query] = SUBSTRING (qt.text,qs.statement_start_offset/2,
(CASE WHEN qs.statement_end_offset = -1
THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2
ELSE qs.statement_end_offset END -
qs.statement_start_offset)/2)
,[Parent Query] = qt.text
,DatabaseName = DB_NAME(qt.dbid)
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
ORDER BY [Average CPU used] DESC;
[/sql]

Autre exemple affichant les informations aux I/O et leurs tailles.

[sql]
SELECT db_name(database_id) AS Database_Name
, file_id
,CAST(num_of_reads AS BIGINT) AS [total_num_reads]
,CAST(num_of_writes AS BIGINT) AS [total_num_writes]
,CAST(io_stall_read_ms AS BIGINT)
/ CAST(CASE WHEN num_of_reads=0

THEN 1
ELSE num_of_reads
END AS BIGINT) AS [avg_read_stall]

,CAST(io_stall_write_ms AS BIGINT)
/ CAST(CASE WHEN num_of_writes=0

THEN 1
ELSE num_of_writes
END AS BIGINT) AS [avg_write_stall]

,CAST(num_of_bytes_read AS BIGINT) AS [total_bytes_read]
,CAST(num_of_bytes_written AS BIGINT) AS [total_bytes_written]
,CAST(num_of_bytes_read AS BIGINT)
/ CAST(CASE WHEN num_of_reads=0

THEN 1
ELSE num_of_reads
END AS BIGINT)

/ 1024 AS [avg_read_size_Kbytes]
,CAST(num_of_bytes_written AS BIGINT)

/ CAST(CASE WHEN num_of_writes=0
THEN 1
ELSE num_of_writes
END AS BIGINT)

/ 1024 AS [avg_write_size_Kbytes]
FROM sys.dm_io_virtual_file_stats(NULL,NULL)
[/sql]

Le DMV sys.dm_os_performance_counters affiche des compteur SQL par l’intermédiaire d’une requête. Dans l’exemple ci-dessous, un reporting des logins/s :

[sql]
SELECT valeur
FROM sys.dm_os_performance_counters
WHERE OBJECT_NAME = ‘serveur-sql’
AND counter_name = ‘Logins/sec’
[/sql]

La commande suivante permet de retourner tous les compteurs disponibles:

[sql]
SELECT *
FROM sys.dm_os_performance_counters;
GO
[/sql]

Quelques exemples de diagnostics

• Fragmentation: la DMV sys.dm_db_index_physical_stats retourne un pourcentage de fragmentation avg_fragmentation_in_percent qui ne doit pas excéder 25%
• Processeur: si la DMV sys.dm_os_wait_stats renvoi une valeur élevée, le processeur sature
• Engorgement des journaux de transactions: la DMV dm_os_wait_stats retourne des valeurs élevées parmi les compteurs WRITELOG et LOGBUFFER
• etc….

Bref, je vous recommande les lectures dans sites suivants:

• http://download.microsoft.com/download/4/7/a/47a548b9-249e-484c-abd7-29f31282b04d/Performance_Tuning_Waits_Queues.doc
• http://msdn.microsoft.com/fr-FR/library/ms188754.aspx
• http://msdn.microsoft.com/fr-FR/library/ms187743.aspx
• http://msdn.microsoft.com/fr-fr/magazine/cc135978.aspx
• http://sqlcat.com/sqlcat/b/technicalnotes/archive/2008/12/09/diagnosing-transaction-log-performance-issues-and-limits-of-the-log-manager.aspx

La mémoire cache des baies SAN

Beaucoup d’idées quant à la mémoire cache des baies de stockage, mais voici les principales règles:

• Le cache en écriture doit être activé car il permet de maintenir une latence faible et d’absorber d’éventuels pics (bursts)
• Le cache en lecture n’est que peu utilisé, si votre baie dispose d’un paramètre PREFETCH, activez-le, il s’avéra utile si un flux séquentiel est détecté. Un cache de type READ-AHEAD (lecture anticipée) ne sert à rien du fait que SQL utilise sont propre algorithme
• Un règle 80/20 ou 90/10 coule donc de source
• Afin de préserver l’intégrité des données, une batterie est obligatoire !

Ce document permettra d’en savoir plus à ce sujet.

Considérations spécifiques à Hyper-V

Outre le fait de me faire un peu de publicité quant à mon livre qui traite le sujet en profondeur, la planification de Microsoft SQL en environnement de virtualisation nécessite quelques bonnes pratiques:

• Le disques doivent être de préférence en PASS-THROUGH et marquer offline au niveau de la VM
• Le cas échéant, préférez des disques de taille fixe plutôt que dynamique (qui génère plus d’accès aux metadonnées et il résulte un nombre d’I/O plus important et un overhead CPU)
• Les périphériques en mode synthetic
• Les disques avec un contrôleur SCSI
• Evitez d’affecter plus de 4 CPU à une VM ou de la virtualiser….
• Tenez compte de l’overhead mémoire sur la partition parent (host) => 32 Mo jusqu’au premier Go puis 8 Mo par Go – une VM ayant 4 Go = 32 + 8*3 = 56 Mo (minime voire ridicule quant au regard du v-Index qui recense un ratio de 5:1 VM par serveur physique) => tout en compte, bien sûr, que Microsoft préconise 300 Mo pour l’hyperviseur et 512 Mo pour la partition parent
• Activez pour vos cartes réseaux la fonction Chimney offload et Virtual Machine Queues (VMQ)

Le débat revient souvent quant aux avantages et inconvénients d’utiliser un VHD ou un disque en direct (PASS-THROUGH), et d’après ces benchmarks, les différences sont minimes, un peu comme chez VMware qui avait réalisé ce test.

Voici deux liens permettant d’aller plus loin dans votre documentation, ici et ici.

Benchmarker avec SQLIO

Cliquer ici pour voir la vidéo.

Voici pour exemple un test SLQIO qui va mesurer les écritures aléatoires avec des I/O de 64k en utilisant 2 threads pendant 120 secondes sur la lettre M.

[shell]

sqlio -kW -t2 -s120 -dM -frandom -b64 (-LS: mesure la latence sans mesurer les I/O et le débit) test.txt

[/shell]

L’équipe de Quest met à disposition un script excellent pour formater tout ça, et pleins de vidéos sous forme « tutoriel » sont également disponibles.

Simuler une charge avec SQLIOsim

L’outil SQLIOsim (anciennement SQLIOstress) effectue des tests d’intégrité et de fiabilité sur des sous-systèmes de disque. Ces tests simulent en lecture, écriture, checkpoint, sauvegarde, tri et les activités de lecture anticipée. Il indique même les soucis rencontrés pendant le benchmark.

Pour allez encore plus loin, il existe un outil (SQLIOsimParser) pour « PARSER » les résultats obtenus et permet même un export au format CSV.

Pour terminer…

Des ressources intéressantes, l’une provient de la TEAM SQLCAT, l’autre recense les 30 mythes de SQL et un site dans le même esprit.

Cette application permet ainsi de passer naturellement d’un écran à un autre, c’est assez bluffant ! Et même d’en prendre le contrôle, de capturer des écrans (screenshots).

Les étapes d’installation sont très simples à mettre en oeuvre !

Lancez l’installation sur les Pc

Un code peut être trouvé en allant dans les settings (systray) du Pc distant

A télécharger ici.

Analyser les performances du stockage

• % d’inactivité => désigne la charge de travail => une valeur en-dessous de 20 % indique une surcharge probable.
• E/S partagées/s => désigne le taux de requête disque physique découpée en plusieurs requêtes pendant une intervalle. Il convient d’appliquer la formule suivante:
  • ( E/S partagées/s) / Transfert disques/s) * 100 => une valeur au-delà de 20 % indique une fragmentation  importante
• Lecture disque/s et Ecriture disque/s => désigne le nombre IOPS
• Longueur moyenne de file d’attente du disque => désigne le nombre de requête I/O => la valeur doit être inférieure à 2 sinon il existe un goulot d’étranglement => rajouter des disques à la pile RAID (si la valeur est supérieure au nombre de piles plus deux, cela signifie que le disque lui-même peut constituer le goulot d’étranglement)
• Moyenne disque s/écriture et Moyenne disque s/lecture et Moyenne disque s/transfert => Ce compteur mesure, en secondes, le temps moyen nécessaire pour lire les données du disque (temps d’accès) => la valeur doit être comprise entre 0 et 25 ms, maximum 10ms pour un serveur SQL. Si le chiffre est supérieur à 25 millisecondes (ms), cela signifie que le système de disque a des problèmes de latence lorsqu’il lit du disque.
• Octet disque/s => désigne le débit
• Mémoire\Octets du cache => Ce compteur indique la quantité de mémoire utilisée pour le cache du système de fichiers. Il peut y avoir un goulot d’étranglement de disque si cette valeur est supérieure à 200 Mo
• Pourcentage du temps de lecture/écriture du disque => désigne le Pattern I/O
• Transfert disque/s => désigne la charge IOPS

Analyser les performances de la mémoire

• % temps processeur => désigne la charge du processeur => une valeur au-delà de 80 % nécessite une surveillance accrue => un CPU peut être sollicité (dans la cadre d’une virtualisation par exemple) à hauteur de 75 à 90 % mais en surveillant bien entendu l’évolution
• Longueur de la file du processeur => désigne la file d’attente des threads du processeur => une valeur entre 5 et 10 indique une charge importante et au-delà une surcharge/saturation des performances processeur
• Pages/s => désigne la mémoire paginée transférée de la mémoire vive vers le système disque. Il convient d’appliquer la formule suivante:
  • Pages/s / Transfert disque/s => une valeur au-delà de 50% nécessite l’ajout de mémoire dans le système car le système consomme de la « puissance » disque uniquement pour la pagination (mesure la vitesse à laquelle les pages sont lues du disque ou écrites sur disque pour corriger les défauts des pages matérielles. Si la valeur est supérieure à 1 000, suite à une pagination excessive, il peut y avoir une fuite de mémoire)
• Mégaoctets disponibles => désigne la mémoire vive disponible immédiatement (si cette valeur est inférieure à 5 % de la mémoire RAM physique totale, cela signifie qu’il y a une insuffisance de mémoire, ce qui risque d’accroître l’activité de pagination)
• Entrées libres en table des pages système => ce compteur indique le nombre d’entrées de la table de pagination qui ne sont pas actuellement utilisées par le système. Si ce nombre est inférieur à 5 000, il est fort possible que vous ayez une fuite de mémoire
• Octets validés => désigne le volume mémoire alloué réservé. Il convient d’appliquer la formule suivante:
  • Octets validés / Mémoire installée => un ratio supérieur à 1.5 nécessitera un ajout de mémoire vive et une valeur de 1 indique qu’il convient de surveiller le système car le montant de la mémoire virtuelle « équivaut » à la mémoire vive installée (Ce compteur mesure le rapport octets validés/limite de mémoire dédiée soit la quantité de mémoire virtuelle utilisée. Il indique une mémoire insuffisante si le chiffre est supérieur à 80 %)

Analyser les performances du processeur

• % temps processeur => mesure le pourcentage de temps que le processeur passe à exécuter un thread actif. Si le pourcentage est supérieur à 85 %, cela signifie que le processeur est surchargé et que le serveur peut nécessiter un processeur plus rapide
• % temps utilisateur => mesure le pourcentage de temps que le processeur passe en mode utilisateur. Si cette valeur est élevée, cela signifie que le serveur est occupé par l’application. Une solution possible consiste à optimiser l’application qui utilise trop les ressources du processeur
• % temps d’interruption => mesure le temps que le processeur passe à recevoir et à traiter des interruptions matérielles durant des intervalles d’échantillonnage spécifiques. Ce compteur indique la possibilité d’un problème de matériel si la valeur est supérieure à 15 %
• Longueur de la file d’attente du processeur => indique le nombre de threads existant dans la file d’attente du processeur. Le serveur ne reçoit pas suffisamment de puissance processeur si la valeur est plus de deux fois supérieure au nombre de processeurs pendant un certain temps

Analyser les performances du réseau

• Total des octets/s => mesure la vitesse à laquelle les octets sont envoyés et reçus via chaque carte réseau, y compris les caractères de trame. Le réseau est saturé si vous découvrez que plus de 70 % de l’interface sont en utilisation. Pour une carte de 100 Mbits/s, l’interface utilisée est 8,7 Mo/s (100 Mbits/s = 100 000 Kbits/s = 12,5 Mo/s* 70 %). Dans une telle situation, vous devriez ajouter une carte réseau plus rapide ou segmenter le réseau
• Longueur de la file d’attente de sortie => mesure la longueur de la file d’attente de sortie, en paquets. Il y a saturation du réseau si la valeur est supérieure à 2. Vous pouvez résoudre ce problème en ajoutant une carte réseau plus rapide ou en segmentant le réseau

Analyser les performances processus

• Nombre de handles => mesure le nombre total de handles qui sont actuellement ouverts par un processus. Ce compteur indique la possibilité d’une fuite de handles si le nombre est supérieur à 10 000
• Nombre de threads => mesure le nombre de threads actuellement actifs dans un processus. Il peut y avoir une fuite de thread si ce nombre est supérieur à 500 entre le nombre minimum et maximum de threads
• Octets privés => indique la quantité de mémoire allouée au processus qui ne peut pas être partagée avec d’autres processus. Si la valeur est supérieure à 250 entre le nombre minimum et maximum de threads, il est possible qu’il y ait une fuite de mémoire

Je me suis basé, en plus de mon expérience , sur cet article pour rédiger ce billet.

L’utilitaire inclut netserver et netclient.

Netserver est un processus serveur (en écoute sur le port 12865 par défaut) qui va attendre les instructions de l’utilitaire netclient.

Netclient doit être lancé suivant cette syntaxe. Le résultat tombe peut après, ici dans notre exemple: 112.96 Mbytes par seconde.

A télécharger ici.

Quand on lance cet outil la première fois, on est frappé par la ressemblance avec un BPA ! Les paramètres à renseigner sont minimalistes et les informations fournies dans le rapport très complètes !

Les versions suivantes sont prises en charge :

• Microsoft Office Outlook 2007
• Microsoft Outlook 2010 (32-bit ou 64-bit)
• Windows 7
• Windows Vista Service Pack 2
• Windows XP Service Pack 3

A télécharger ici.

PAL dispose de compteurs pré-établis concernant Exchange, SQL, Hyper-V, Biztalk, Citrix XenAPP …. bref, pas moins de 35 catégories disponibles avec pour chacune des compteurs personnalisés !

Là où cet outil devient intéressant, c’est qui offre la possibilité de créer ses propres catégories avec ses propres compteurs. On peut tout à fait imaginer créer une catégorie Système disque qui regroupera tous les compteurs PhysicalDisk et LogicalDisk ! Il est bien entendu possible de modifier les compteurs existants, de les personnaliser !

Lorsqu’on lance la collecte, un fichier (powershell) préalablement généré s’exécute…. A noter qu’il est donc possible de copier le script !

Une fois le script terminé (ce qui peut durer assez longtemps…), un magnifique rapport HTML (par défaut et XML possible) s’affiche alors !

Bref, un outil indispensable pour tout consultant qui se respecte

A télécharger ici, et une documentation Microsoft disponible ici et même une formation vidéo ici.

A noter qu’il est possible de créer vos propres analyses en ligne de commande à l’aide de Logman (plus de détails ici) dont voici un exemple de syntaxe
[shell]
Logman.exe create counter Compteur-enovatic -f bincirc -v mmddhhmm -max 100 -c « \LogicalDisk(*)\* » « \Memory\* » « \Network Interface(*)\* » « \Paging File(*)\* » « \PhysicalDisk(*)\* »  -si 00:01:00
[/shell]

Voici le script à copier/coller dans un batch, et à améliorer à votre convenance. Celui-ci génère deux fichiers à la racine du lecteur C, repl.csv et diag.txt qui sont correctement formatés. Sinon, j’ai crée un EXE pour ce script.

[bash]

@echo off
title Diagnostic Active Directory
color 1F
echo.
echo ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
echo º                                º
echo º   Diagnostic Active Directory  º
echo º                                º
echo ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
echo.
echo Les diagnostics peuvent prendre un certain temps….
echo.
echo ———————————————
echo.
chcp 1252 >nul
echo ——————————————— >> c:\diag.txt
echo JOURNAL DES DIAGNOSTICS ACTIVE DIRECTORY >> c:\diag.txt
echo. >> c:\diag.txt
echo Generation du %date% %time% >> c:\diag.txt
echo ——————————————— >> c:\diag.txt
echo. >> c:\diag.txt
echo. >> c:\diag.txt
echo Diagnostics des services
echo.
echo ——————————————— >> c:\diag.txt
echo Diagnostics des services >> c:\diag.txt
echo ——————————————— >> c:\diag.txt
echo. >> c:\diag.txt
echo. >> c:\diag.txt
dcdiag /v >> c:\diag.txt
echo. >> c:\diag.txt
echo.
echo Diagnostics des DNS
echo.
echo ——————————————— >> c:\diag.txt
echo Diagnostics des DNS >> c:\diag.txt
echo ——————————————— >> c:\diag.txt
echo. >> c:\diag.txt
echo. >> c:\diag.txt
dcdiag /test:DNS /DNSALL /e /v >> c:\diag.txt
echo. >> c:\diag.txt
echo.
echo Diagnostics des enregistrements DNS
echo.
echo ——————————————— >> c:\diag.txt
echo Diagnostics des enregistrements DNS >> c:\diag.txt
echo ——————————————— >> c:\diag.txt
echo. >> c:\diag.txt
echo. >> c:\diag.txt
dcdiag /test:RegisterInDNS >> c:\diag.txt
echo. >> c:\diag.txt
echo.
echo Verification du service DHCP
echo.
echo ——————————————— >> c:\diag.txt
echo Verification du service DHCP >> c:\diag.txt
echo ——————————————— >> c:\diag.txt
echo. >> c:\diag.txt
echo. >> c:\diag.txt
netsh dhcp show server >> c:\diag.txt
echo. >> c:\diag.txt
echo.
echo Diagnostic de la replication
echo.
echo ——————————————— >> c:\diag.txt
echo Diagnostic de la replication >> c:\diag.txt
echo ——————————————— >> c:\diag.txt
echo. >> c:\diag.txt
echo. >> c:\diag.txt
repadmin /showreps >> c:\diag.txt
echo. >> c:\diag.txt
echo.
echo Diagnostic avance de la replication
echo.
echo ——————————————— >> c:\diag.txt
echo Diagnostic avancé de la replication >> c:\diag.txt
echo ——————————————— >> c:\diag.txt
echo. >> c:\diag.txt
echo. >> c:\diag.txt
repadmin /showrepl * /csv >> c:\repl.csv
echo. >> c:\diag.txt
echo.
echo Diagnostic des erreurs de replication
echo.
echo ——————————————— >> c:\diag.txt
echo Diagnostic des erreurs de replication >> c:\diag.txt
echo ——————————————— >> c:\diag.txt
echo. >> c:\diag.txt
echo. >> c:\diag.txt
repadmin /replsum /errorsonly >> c:\diag.txt
echo. >> c:\diag.txt
echo. >> c:\diag.txt
echo.
echo Fin des Diagnostics.
echo ——————————————— >> c:\diag.txt
echo Fin des diagnostics >> c:\diag.txt
echo ——————————————— >> c:\diag.txt
echo.
pause
call notepad c:\diag.txt
call notepad c:\repl.csv

[/bash]

Télécharger le fichier exécutable ici.