Guide de planification de l’optimisation des performances ......Guide de planification de l’optimisation des performances d’EMC NetWorker version 8.1 7 Préface Notes techniques

EMC® NetWorker®

Version 8.1

Guide de planification de l’optimisation des performancesRÉF. 302-000-558RÉV. 02

Guide de planification de l’optimisation des performances d’EMC NetWorker version 8.12

Copyright © 2000- 2013 EMC Corporation. Tous droits réservés.

Publié en juillet 2013

EMC estime que les informations figurant dans ce document sont exactes à la date de publication. Ces informations sont modifiables sans préavis.

Les informations contenues dans ce document sont fournies « en l'état ». EMC Corporation ne fournit aucune déclaration ou garantie d’aucune sorte concernant les informations contenues dans cette publication et rejette plus spécialement toute garantie implicite de qualité commerciale ou d’adéquation à une utilisation particulière. L’utilisation, la copie et la distribution de tout logiciel EMC décrit dans cette publication exigent une licence logicielle en cours de validité.

EMC2, EMC et le logo EMC sont des marques déposées ou des marques commerciales d’EMC Corporation aux États-Unis et dans d’autres pays. Toutes les autres marques citées dans le présent document sont la propriété de leurs détenteurs respectifs.

Pour obtenir les informations légales les plus récentes concernant votre famille de produits, consultez la rubrique Documentations et conseils techniques du site Web du Support en ligne EMC.

SOMMAIRE

Préface

Chapitre 1 Présentation

Entreprise ................................................................................................... 10 Flux de données NetWorker......................................................................... 10

Chapitre 2 Dimensionnement de l'environnement NetWorker

Attentes ...................................................................................................... 14Détermination des performances attendues au niveau de l'environnement de sauvegarde ...................................................................................... 14Détermination des configurations de sauvegarde requises.................... 15

Composants système.................................................................................. 15Intrusion dans....................................................................................... 16Mémoire requise ................................................................................... 17Configuration requise du bus système .................................................. 18

Considérations relatives au stockage .......................................................... 20Besoins en E/S par seconde pour le stockage ....................................... 21Temps de latence des opérations en écriture sur les disques du noeud de stockage et du serveur NetWorker ......................................................... 21Recommandations en matière de performances de stockage ................ 24Exigences relatives aux tâches de sauvegarde ...................................... 25Réseau.................................................................................................. 33Périphérique cible................................................................................. 34Règle des 70 % du composant .............................................................. 34

Composants d'un environnement NetWorker............................................... 35Zone de données .................................................................................. 36NetWorker Management Console .......................................................... 36Base de données de la Console............................................................. 37serveur EMC NetWorker ......................................................................... 39nœud de stockage EMC NetWorker........................................................ 41client EMC NetWorker............................................................................ 41Bases de données NetWorker................................................................ 42Modules d’application facultatifs NetWorker ......................................... 42Environnements virtuels........................................................................ 42Noeuds de déduplication EMC NetWorker ............................................. 43

Facteurs déterminant les performances de la restauration........................... 43 Connectivité et goulots d'étranglement ....................................................... 43

Goulots d'étranglement au niveau des bases de données NetWorker .... 48

Chapitre 3 Paramètres de réglage

Optimisation du parallélisme NetWorker ..................................................... 52parallélisme du serveur......................................................................... 52parallélisme du client............................................................................ 52Parallélisme du groupe ......................................................................... 53multiplexage ......................................................................................... 53

Densité du système de fichiers.................................................................... 53 Optimisation des disques ........................................................................... 55

Guide de planification de l’optimisation des performances d’EMC NetWorker version 8.1 3

Sommaire

Méthodes de réglage des performances du périphérique ............................ 55Vitesse de transfert d’entrée/sortie ....................................................... 55Compression intégrée ........................................................................... 55Diffusion en continu (streaming) sur le lecteur ...................................... 56Équilibrage de la charge de périphérique .............................................. 56Fragmentation des lecteurs de disque................................................... 56

Périphériques réseau .................................................................................. 57Temps de latence Fibre Channel............................................................ 57DataDomain.......................................................................................... 58Nombre de sessions cible et nombre maximal de sessions de périphérique AFTD ..................................................................................................... 60Comparaison entre nombre de lecteurs virtuels et nombre de lecteurs physiques ............................................................................................. 61

Optimisation des réseaux ........................................................................... 62Optimisation de la configuration avancée ............................................. 62Optimisation de la pile TCP du système d’exploitation .......................... 63Réglage avancé ..................................................................................... 63Temps de latence réseau....................................................................... 64Modes Duplex des liaisons Ethernet...................................................... 65Pare-feu ................................................................................................ 65Trames Jumbo ....................................................................................... 66Notification de congestion .................................................................... 66Mémoires tampons TCP/IP .................................................................... 67Augmentation de la taille de tampon du reliquat TCP............................. 68Taille de mémoire tampon des sockets NetWorker ................................ 68Équilibrage IRQ et affinité CPU............................................................... 69Modération des interruptions................................................................ 70Déchargement TCP ................................................................................ 70Résolution de noms .............................................................................. 71

Chapitre 4 Test des performances

Identification des symptômes ..................................................................... 74 Surveillance des performances ................................................................... 74 Identification des goulots d'étranglement à l'aide d'un test FTP générique .. 75 Test des performances de l'installation à l'aide d'une commande dd........... 76 Test des performances du disque à l'aide des directives bigasm et uasm .... 76

Directive bigasm ................................................................................... 76Directive uasm ...................................................................................... 76

4 Guide de planification de l’optimisation des performances d’EMC NetWorker version 8.1

PRÉFACE

En vue d’améliorer la qualité de ses gammes de produits, EMC publie régulièrement des révisions de ses logiciels et de son matériel. Par conséquent, il se peut que certaines fonctions décrites dans le présent document ne soient pas prises en charge par l’ensemble des versions des logiciels ou du matériel actuellement utilisés. Pour obtenir les informations les plus récentes sur les fonctions des produits, consultez les notes de mise à jour de vos produits.

Si un produit ne fonctionne pas correctement ou ne fonctionne pas de la manière décrite dans ce document, contactez un responsable de compte EMC.

Remarque : les informations figurant dans ce document sont exactes à la date de publication. De nouvelles versions de ce document peuvent être publiées sur le site Web du Support en ligne EMC. Consultez ce site afin de vous assurer que vous utilisez la version la plus récente de ce document.

ObjectifCe document explique comment planifier, tester et optimiser l’environnement NetWorker.

AudienceCe document est destiné à l’administrateur de sauvegarde impliqué dans la configuration et l’optimisation de l’environnement EMC NetWorker.

Documentation connexeLes publications EMC suivantes apportent des informations complémentaires :

◆ Guide de compatibilité du logiciel EMC NetWorker Présente la liste des systèmes d’exploitation des clients, des serveurs et des nœuds de stockage pris en charge par les versions logicielles de protection des informations EMC.

◆ Guide d’installation d’EMC NetWorkerFournit des instructions pour installer et mettre à jour le logiciel NetWorker pour les clients, la console et le serveur sur toutes les plates-formes prises en charge.

◆ Guide d’intégration avec le cluster d’EMC NetWorker Contient des informations relatives à l’installation du logiciel NetWorker sur des serveurs et des clients de cluster.

◆ Guide d’administration d’EMC NetWorkerExplique comment configurer et gérer le logiciel NetWorker.

◆ Guide d’intégration des EMC Data Domain Deduplication Devices avec EMC EMC NetWorkerFournit des informations de planification et de configuration sur l’utilisation de périphériques Data Domain pour la sauvegarde et le stockage de déduplication dans un environnement NetWorker.


Préface

◆ Guide d’intégration d’EMC NetWorker avec VMwareFournit des informations de planification et de configuration relatives à l’utilisation de VMware dans un environnement NetWorker.

◆ Guide d’intégration d’EMC NetWorker avec EMC AvamarFournit des informations de planification et de configuration relatives à l’utilisation des périphériques Avamar dans un environnement NetWorker.

◆ Notes de mise à jour d’EMC NetWorkerFournit des informations sur les nouvelles fonctions, les modifications, les problèmes résolus, les limitations connues, les configurations requises par l’environnement et le système pour la dernière version du logiciel NetWorker.

◆ Guide d’octroi des licences d'EMC NetWorkerFournit des informations sur l’octroi des licences pour les produits et les fonctions NetWorker.

◆ EMC NetWorker License Manager 9th Edition Installation and Administration GuidePrésente les informations d’installation et de configuration du produit NetWorker License Manager.

◆ Guide des messages d’erreur d’EMC NetWorkerFournit des informations sur les messages d’erreur NetWorker les plus courants.

◆ Guide de référence des commandes d’EMC NetWorkerFournit des informations de référence pour les commandes et les options NetWorker.

◆ Guide des bonnes pratiques de disponibilité et de reprise après sinistre d’EMC EMC NetWorker ServerExplique comment concevoir et planifier une reprise après sinistre NetWorker. Cependant, il ne fournit pas d’instructions détaillées sur la reprise après sinistre. La section Reprise après sinistre de NPG (NetWorker Procedure Generator) fournit des instructions de reprise après sinistre étape par étape.

◆ Aide en ligne d’EMC NetWorker Management ConsoleExplique comment effectuer les tâches d’administration quotidiennes dans NetWorker Management Console ainsi que dans la fenêtre Administration de NetWorker.

◆ Aide en ligne d’EMC NetWorker UserExplique comment utiliser le programme NetWorker User (l’interface cliente Microsoft Windows pour le NetWorker Server) pour sauvegarder, restaurer, archiver et récupérer des fichiers sur un réseau.

◆ EMC NetWorker Procedure GeneratorNetWorker Procedure Generator (NPG) est une application Windows autonome utilisée pour générer des procédures utilisateur précises pour les tâches très complexes réalisées par les clients, le support technique et le personnel de terrain. Avec NPG, chaque procédure est adaptée et générée à base d’invites pouvant être sélectionnées par l’utilisateur. La procédure générée rassemble les parties les plus importantes des guides produit de NetWorker et fusionne les conseils des experts dans un document unique au format standardisé.

Pour accéder à NetWorker Procedure Generator, connectez-vous au site https://support.emc.com/ et recherchez l'application. Vous devez disposer d'un contrat de services pour utiliser ce site.


https://support.emc.com/

Préface

◆ Notes techniques et livres blancsOffrent une étude technique approfondie d'un ou de plusieurs produits en fonction des problèmes ou besoins métiers critiques. Les documents de type notes techniques et livres blancs décrivent des concepts technologiques, des considérations métiers et des technologies appliquées, et fournissent des analyses détaillées ainsi qu’une planification des bonnes pratiques.

Conventions utilisées dans ce documentEMC utilise les conventions suivantes pour attirer l’attention du lecteur sur certains points particuliers :

Un AVERTISSEMEN donne une information vitale.

Remarque : une remarque donne une information importante, mais non vitale.

Conventions typographiques

EMC utilise les conventions typographiques suivantes dans le présent document :

Normal Dans le texte courant (autre que les procédures) pour :• les noms d’éléments d’interface (tels que les noms de fenêtres, de

boîtes de dialogue, de boutons, de champs et de menus),• les noms de ressources, d’attributs, de pools, d’expressions

booléennes, de boutons, d’instructions DQL, de mots-clés, de clauses, de variables d’environnement, de fonctions et d’utilitaires ;

• les URL, les noms de chemins d’accès, les noms de fichiers, les noms de répertoires, les noms d’ordinateurs, les noms de fichiers, les liens, les groupes, les clés de service, les systèmes de fichiers et les notifications.

Gras Utilisé dans le texte courant (autre que les procédures) pour les noms de commandes, d’options, de programmes, de processus, de services, d’applications, d’utilitaires, de noyaux, de notifications, d’appels système et de pages man.

Utilisé dans les procédures pour :• les noms d’éléments d’interface (tels que les noms de fenêtres, de

boîtes de dialogue, de boutons, de champs et de menus),• les éléments avec lesquels l’utilisateur interagit spécifiquement (via

une sélection, une saisie, un clic de la souris ou une frappe au clavier).

Italique Utilisé dans tout le texte (y compris les procédures) pour :• les titres complets de publications citées dans le texte,• la mise en valeur (par exemple, un nouveau terme),• les variables.

Courier Utilisées pour :• les données de sortie du système, telles que les messages d’erreur ou

les scripts ;• les URL, les chemins d’accès complets, les noms de fichiers, les invites

et la syntaxe ne faisant pas partie du texte courant.

Courier Gras Utilisé pour les entrées utilisateur spécifiques (par exemple, les commandes).

Courier Italique Utilisé dans les procédures pour :• les variables de la ligne de commande,• les variables entrées par l’utilisateur.


Préface

Obtenir de l’aidePour plus d'informations sur le support, les produits et les licences EMC, procédez comme suit :

Informations sur les produits — Pour toute information sur la documentation, les notes de mise à jour, les mises à jour logicielles ou sur les produits EMC, consultez le Support en ligne d’EMC à l’adresse :

http://support.emc.com

Support technique — Pour accéder au support technique, rendez-vous sur le site du Support en ligne EMC et choisissez Support. La page Support affiche différentes options. L’une d’entre elles permet de créer une demande de service. Notez que pour pouvoir ouvrir une demande de service, vous devez disposer d’un contrat de support valide. Pour savoir comment obtenir un contrat de support valide ou pour toute question concernant votre compte, contactez un responsable de compte EMC.

Communauté en ligne

Visitez la communauté EMC Community Network à l’adresse https://community.EMC.com, pour obtenir des contacts homologues, des entretiens et du contenu sur les solutions et la prise en charge des produits. Engagez-vous en ligne de manière interactive avec les clients, les partenaires et les professionnels certifiés pour tous les produits EMC.

Vos suggestions contribuent à améliorer la précision, l’organisation et la qualité d’ensemble des publications destinées à nos utilisateurs. Nous vous invitons à envoyer votre avis sur ce document à l’adresse suivante :

[email protected]

< > Les chevrons simples entourent les valeurs de paramètres ou de variables indiquées par l’utilisateur.

[ ] Les crochets entourent les valeurs facultatives.

| Une barre verticale indique les sélections alternatives (la barre signifie « ou »).

{ } Les accolades entourent le contenu que l’utilisateur doit spécifier, c’est-à-dire x, y ou z.

… Les points de suspension indiquent des informations non essentielles omises dans l’exemple.


http://support.emc.com

CHAPITRE 1Présentation

Le logiciel EMC NetWorker est une application de gestion du stockage en réseau optimisée pour la sauvegarde et la restauration ultra rapides d’importants volumes de données complexes sur des zones entières de données. Le présent guide traite des options de réglage sans perturbation pour l’environnement qui permettent d’optimiser les performances. Bien que les performances de certains périphériques n’atteignent pas toujours les niveaux escomptés, il est avéré que le remplacement d’un composant physique par un périphérique plus performant transforme un autre composant en goulot d’étranglement. L’objectif du présent guide est de parvenir à régler les performances du logiciel NetWorker tout en occasionnant le moins de perturbations possibles à l’environnement existant. Il contient des directives et recommandations qui permettent d’optimiser les performances d’un même ensemble de solutions matérielles par un réglage fin des fonctions et aident les administrateurs à :

◆ Comprendre les principes fondamentaux du transfert des données

◆ Identifier les impératifs à respecter

◆ Identifier les goulots d’étranglement

◆ Optimiser et régler les performances de NetWorker

Ce chapitre contient les sections suivantes :

◆ Entreprise ............................................................................................................... 10◆ Flux de données NetWorker..................................................................................... 10

Présentation 9

Présentation

EntrepriseLe présent guide contient les chapitres suivants :

◆ Le Chapitre 2, « Dimensionnement de l'environnement NetWorker », contient des informations détaillées sur les modalités à suivre pour identifier les exigences à respecter.

◆ Le Chapitre 3, « Paramètres de réglage », contient des informations détaillées sur les modalités à suivre pour optimiser les performances de sauvegarde et de restauration via un réglage adapté de l’environnement de sauvegarde.

◆ Le Chapitre 4, « Test des performances », contient des informations détaillées sur les modalités à suivre pour tester et identifier les causes de goulot d’étranglement à l’aide des outils disponibles.

Flux de données NetWorkerLa Figure 1 à la page 11 et la Figure 2 à la page 12 illustrent le flux de données de restauration et de sauvegarde des composants au sein d’une zone de données EMC® NetWorker.


Présentation

La Figure 1 et la Figure 2 étant des schémas simplifiés, toutes les communications interprocessus ne sont pas présentes. De nombreuses configurations pour le flux de données de restauration et de sauvegarde sont possibles.

Figure 1 Flux de données de sauvegarde de NetWorker

Flux de données NetWorker 11

Présentation

Figure 2 Flux de données de restauration de NetWorker


CHAPITRE 2Dimensionnement de l'environnement NetWorker

Ce chapitre explique comment déterminer les besoins en termes de configuration matérielle et de sauvegarde. La première étape consiste à appréhender l'environnement. Les problèmes de performances sont généralement liés au matériel ou à l'environnement. Il est important de bien comprendre l'ensemble du flux de données de sauvegarde afin de déterminer les performances optimales pouvant être obtenues grâce au logiciel NetWorker.

Ce chapitre propose les rubriques suivantes :

◆ Attentes .................................................................................................................. 14◆ Composants système .............................................................................................. 15◆ Considérations relatives au stockage ...................................................................... 20◆ Composants d'un environnement NetWorker........................................................... 35◆ Facteurs déterminant les performances de la restauration....................................... 43◆ Connectivité et goulots d'étranglement ................................................................... 43

Dimensionnement de l'environnement NetWorker 13

Dimensionnement de l'environnement NetWorker

AttentesCette section décrit les performances attendues au niveau de l'environnement de sauvegarde ainsi que les configurations de sauvegarde requises.

Détermination des performances attendues au niveau de l'environnement de sauvegarde

Les considérations sur le dimensionnement de l'environnement de sauvegarde sont répertoriées ci-après :

◆ Prenez connaissance des informations relatives à l'infrastructure de stockage et au réseau avant de définir vos attentes au niveau des performances de votre environnement de sauvegarde, qui comprend les clients, les noeuds de stockage et le serveur NetWorker.

◆ Vérifiez et définissez l'objectif de temps de restauration (RTO) pour chaque client.

◆ Déterminez la fenêtre de sauvegarde pour chaque client NetWorker.

◆ Répertoriez la quantité de données à sauvegarder pour chaque client lors des sauvegardes complètes et incrémentielles.

◆ Déterminez le taux de croissance des données pour chaque client.

◆ Déterminez les besoins en matière de politique de rétention des index et des médias.

Il n'est pas facile de répertorier avec précision les performances attendues tout en gardant à l'esprit l'environnement et les périphériques utilisés. Il est important de connaître les goulots d’étranglement de l'installation et de définir les performances attendues en conséquence.

Voici quelques suggestions pour vous aider à identifier les goulots d'étrangement et à définir les performances attendues :

◆ Créez un schéma. ◆ Répertoriez tous les composants du système, du dispositif de stockage, du réseau et

du périphérique cible. ◆ Répertoriez les chemins de données. ◆ Identifiez le composant faisant office de goulot d'étranglement dans le chemin de

données de chaque client.

La section « Connectivité et goulots d'étranglement », page 43 fournit des exemples d'éventuels goulots d'étrangement dans l'environnement NetWorker.

Il est très important de connaître la période d'interruption possible pour chaque client NetWorker. Cela permet de déterminer le RTO. Vérifiez et documentez le RTO pour chaque client NetWorker.

Pour déterminer la fenêtre de sauvegarde pour chaque client :

1. Vérifiez la fenêtre de sauvegarde disponible pour chaque client NetWorker.

2. Répertoriez la quantité de données à sauvegarder à partir des clients dans le cadre de sauvegardes complètes ou incrémentielles.

3. Répertoriez la croissance des données quotidienne/hebdomadaire/mensuelle moyenne sur chaque client NetWorker.



Détermination des configurations de sauvegarde requises

Les méthodes permettant de déterminer les configurations de sauvegarde requises pour l'environnement sont répertoriées ci-après :

◆ Vérifiez les politiques de sauvegarde existantes et assurez-vous qu'elles permettent d'atteindre l'objectif de temps de restauration (RTO) pour chaque client.

◆ Estimez la fenêtre de sauvegarde pour chaque client NetWorker en fonction des informations recueillies.

◆ Déterminez l'organisation des groupes de clients NetWorker distincts à partir des paramètres suivants :

• Fenêtre de sauvegarde • Degré de criticité de l’activité• Emplacement physique • Rétention des index

◆ Assurez-vous que le RTO peut être atteint avec la sauvegarde créée pour chaque client.

Plus la période d'interruption acceptable est courte, plus les sauvegardes sont onéreuses. Il peut être impossible de construire une image de sauvegarde à partir d'une sauvegarde complète et de plusieurs sauvegardes incrémentielles si la période d'interruption acceptable est très courte. Des sauvegardes complètes peuvent être requises plus fréquemment, ce qui entraînera un allongement de la fenêtre de sauvegarde. Cela augmentera également les exigences en matière de bande passante réseau.

Composants systèmeTous les environnements de sauvegarde ont un goulot d'étrangement. Il peut s'agir d'un goulot d'étrangement rapide, mais celui-ci déterminera toujours le débit maximal pouvant être obtenu au niveau du système. Les opérations de sauvegarde et de restauration seront aussi rapides que le composant le plus lent dans la chaîne de sauvegarde.

Les problèmes de performances sont généralement liés à des périphériques matériels de la zone de données. Dans le présent guide, nous partons du principe que les périphériques matériels sont correctement installés et configurés.

Cette section explique comment déterminer la configuration requise. Par exemple :

◆ Quelle est la quantité de données déplacée ?◆ Quelle est la fenêtre de sauvegarde ? ◆ Combien de disques sont requis ? ◆ Combien de CPU sont requis ?

Les périphériques situés sur les réseaux de sauvegarde peuvent être regroupés en quatre types de composant, selon la manière et l'endroit où les périphériques sont utilisés. Un réseau de sauvegarde classique contient les quatre composants suivants :

◆ Intrusion dans◆ Stockage◆ Réseau◆ Périphérique cible

Composants système 15


Intrusion dans

Les composants de configuration système ayant une incidence sur les performances sont les suivants :

◆ CPU◆ Mémoire◆ Bus système (qui détermine la bande passante d'E/S disponible maximale)

CPU requisDéterminez le nombre optimal de CPU requis, si 5 MHz sont nécessaires pour déplacer 1 Mo de données du périphérique source vers le périphérique cible. Par exemple, la sauvegarde d'un noeud de stockage ou d'un serveur NetWorker sur un lecteur de bande local à une vitesse de transfert de 100 Mo par seconde, nécessite 1 GHz de puissance de CPU :

◆ 500 MHz sont nécessaires pour déplacer les données du réseau vers un noeud de stockage ou un serveur NetWorker.

◆ 500 MHz sont nécessaires pour déplacer les données du noeud de stockage ou du serveur NetWorker vers le périphérique cible de sauvegarde.

Remarque : il n'est pas possible de comparer 1 GHz sur un type de CPU donné par rapport à un CPU d'un autre fournisseur.

La charge du CPU d'un système est affectée par plusieurs autres facteurs. Par exemple :

◆ Une charge de CPU élevée n'est pas forcément le résultat direct d'une puissance de CPU insuffisante, mais peut être un effet secondaire de la configuration d'autres composants du système.

◆ Pilotes :

Veillez à tester des pilotes provenant de différents fournisseurs car les performances varient. Les pilotes placés sur le même système d'exploitation assurent le même débit avec toutefois une différence significative au niveau de la quantité de CPU utilisée.

◆ Performances d’un disque dur :

• Sur un serveur de sauvegarde doté de 400 clients ou plus dans le répertoire /nsr, un disque dur fortement sollicité entraîne généralement une utilisation du CPU supérieure à 60 %. Le même serveur de sauvegarde placé dans le répertoire /nsr sur une baie de disques faiblement utilisée, entraînera une utilisation du CPU inférieure à 15 %.

• Sous UNIX et sous Windows, si une grande partie du temps processeur se déroule en mode privilégié ou si la charge du processeur (en %) est plus élevée dans le temps système que dans le temps utilisateur, cela indique souvent que les processus NetWorker attendent la fin des E/S. Si les processus NetWorker attendent la fin des entrées/sorties, le goulot d'étrangement n'est pas le CPU, mais le système de stockage utilisé pour héberger le serveur NetWorker.

• Sous Windows, si les appels de procédure différés monopolisent beaucoup de temps, cela indique généralement un problème au niveau des pilotes de périphériques.



◆ Surveillez l'utilisation du processeur selon les classifications suivantes :

• Mode utilisateur• Mode système

◆ Les arrêts des composants matériels entraînent une utilisation élevée du processeur du système, ce qui dégrade les performances. Si le nombre d'arrêts de périphérique est supérieur à 10 000 par seconde, vérifiez le périphérique.

Mémoire requise

Le Tableau 1 à la page 17 indique la mémoire minimale requise pour le serveur NetWorker. Cela garantit que la mémoire n'est pas un goulot d'étranglement.

Valeur de parallélisme 1024 Compte tenu des performances observées pour les groupes de sauvegarde présentant une configuration similaire à la suivante, la mémoire minimale requise est de 1 Go sous Linux, de 600 à 700 Mo sous Solaris et de 250 à 300 Mo sous Windows :

◆ 25 clients

◆ Parallélisme du client = 8

◆ 5 nœuds de stockage distants avec 32 périphériques AFTD

◆ Sessions cibles de périphérique par défaut (4)

◆ Sessions maximales de périphérique par défaut (32)

Remarque : l’augmentation de la valeur de parallélisme du serveur influe sur les E/S par seconde du serveur NetWorker dans les bases de données d’index et de médias.

Surveiller le fichier d'échange ou l'utilisation de la permutation La pagination de la mémoire ne doit pas être effectuée sur un serveur de sauvegarde dédié car elle aurait des répercussions négatives sur les performances de l'environnement de sauvegarde.

Considérations pour Windows 2003Suivez ces recommandations spécifiques au serveur Windows 2003 :

◆ Par défaut, les serveurs Windows 2003 32 bits allouent 2 Go de mémoire aux processus en mode noyau et en mode application. Vous pouvez allouer de la mémoire supplémentaire pour augmenter les performances du logiciel NetWorker. Pour plus d'informations, consultez l'article 283037 de la Base de connaissances Microsoft.

Tableau 1 Mémoire minimale requise pour le serveur NetWorker

Nombre de clients Mémoire minimale requise

Moins de 50 4 Go

Entre 51 et 150 8 Go

Plus de 150 16 Go



◆ Si la pagination est nécessaire, il est conseillé d'utiliser un fichier d'échange d'une taille maximale égale à 1,5 fois la quantité de RAM physique installée sur le serveur Windows. Pour plus d'informations, consultez l'article 2267427 de la Base de connaissances Microsoft.

Attribut Client Direct pour un accès direct aux fichiers (DFA)Tenez compte des points ci-après lors de l'activation du DFA à l'aide de l'attribut Client Direct :

◆ Assurez-vous que la puissance de CPU présente sur le client est suffisante pour bénéficier pleinement de la fonction de performances accrues DFA-DD. Dans la majorité des cas, l'attribut Client Direct améliore considérablement les performances de la sauvegarde. La sauvegarde DFA-DD nécessite environ 2 à 10 % de charge CPU supplémentaire pour chaque session simultanée.

◆ Chaque session de sauvegarde utilisant DFA-DD nécessite jusqu'à 70 Mo de mémoire. Si 10 flux DFA s'exécutent simultanément, la mémoire requise sur un client pour toutes les sessions DFA est de 700 Mo.

◆ Les sessions de sauvegarde via DFA-AFTD utilisent moins de mémoire et de cycles processeur qu'une sauvegarde DFA-DD utilisant Boost. Les sessions de sauvegarde via DFA-AFTD utilisent un peu plus de mémoire et de cycles processeur que les sauvegardes traditionnelles avec mmd.

Configuration requise du bus système

Bien que le placement HBA/NIC soit critique, le bus interne est probablement le composant le plus important du système d'exploitation. Le bus interne assure la communication entre les composants informatiques internes, tels que le processeur, la mémoire, le disque et le réseau.

Critères de performances du bus : ◆ Type du bus◆ Largeur de données◆ Fréquence d'horloge◆ Carte mère

Considérations relatives au bus système◆ Un bus plus rapide ne garantit pas des performances plus élevées◆ Les systèmes haut de gamme disposent de plusieurs bus pour améliorer les

performances ◆ Le bus est souvent le goulot d'étranglement dans un système

Recommandations relatives au bus systèmeIl est recommandé d'utiliser PCIeXpress pour les serveurs et les noeuds de stockage afin de réduire le risque de goulot d'étranglement au niveau des entrées/sorties.

Remarque : évitez d'utiliser des types de bus anciens ou des composants à grande vitesse optimisés pour un type de bus ancien car ils génèrent de trop nombreux arrêts, entraînant des pics d'utilisation du CPU durant les transferts de données.



Considérations relatives à PCI-X et PCIeXpress :◆ PCI-X est un bus parallèle de 64 bits bidirectionnel en semi-duplex.

◆ La vitesse du bus PCI-X peut être limitée au périphérique le plus lent du bus. Soyez vigilant lors du positionnement de la carte.

◆ PCIeXpress est un bus série bidirectionnel en duplex intégral utilisant un codage 8/10.

◆ La vitesse du bus PCIeXpress peut être déterminée par chaque périphérique.

◆ Ne connectez pas un adaptateur HBA/NIC rapide sur un bus lent. Tenez toujours compte des caractéristiques du bus. Des pertes de paquets silencieuses peuvent se produire sur une carte réseau PCI-X 1.0 10 GbE, et les conditions requises au niveau du bus ne peuvent pas être satisfaites.

◆ Un matériel qui relie un système de stockage rapide à un adaptateur HBA/NIC plus lent ralentira les performances globales du système.

La section « Règle des 70 % du composant », page 34 fournit des informations détaillées sur les niveaux de performances adaptés aux composants.

Exigences en termes de vitesse de busLes besoins en termes de vitesse de bus sont répertoriés ci-après :

◆ Fibre Channel 4 Gb nécessite 425 Mo/s◆ Fibre Channel 8 Gb nécessite 850 Mo/s ◆ Fibre Channel 10 Gb nécessite 1 250 Mo/s

Caractéristiques du busLes caractéristiques du bus sont répertoriées dans le Tableau 2 à la page 19.

Tableau 2 Caractéristiques du bus (page 1 of 2)

Type de bus MHz Mo/seconde

PCI 32 bits 33 133

PCI 64 bits 33 266

PCI 32 bits 66 266

PCI 64 bits 66 533

PCI 64 bits 100 800

PCI-X 1.0 133 1 067

PCI-X 2.0 266 2 134

PCI-X 2.0 533 4 268

PCIeXpress 1.0 x 1 250

PCIeXpress 1.0 x 2 500

PCIeXpress 1.0 x 4 1 000





Considérations relatives au stockageLes composants suivants ont une incidence sur les performances des configurations du stockage :

◆ Connectivité de stockage :

• Local contre SAN contre NAS

• Utilisation des snapshots de stockage :

La technologie de snapshot utilisée détermine les performances de lecture

◆ Réplication du stockage :

Certaines technologies de réplication ajoutent une latence importante à l'accès en écriture, ralentissant l'accès au système de stockage.

◆ Type de stockage :

• Un bus informatique SATA (Serial ATA) est une interface de stockage permettant de connecter des adaptateurs de bus hôte à des périphériques de stockage tels que des lecteurs de disque dur et des lecteurs optiques.

• La technologie Fibre Channel (FC) est une technologie réseau à très haute vitesse (gigabit) principalement utilisée pour le stockage en réseau.

• Flash est un système de stockage informatique non volatile utilisé pour le stockage général et le transfert de données entre des ordinateurs et des supports numériques.

◆ Taux de transfert d’E/S du stockage :

Les différents niveaux RAID ont un impact sur le taux de transfert d'E/S du stockage ; le meilleur niveau RAID pour le serveur de sauvegarde étant RAID1 ou RAID5. La sauvegarde sur disque doit utiliser le niveau RAID3.

◆ Entrées/Sorties planifiées :

Si le système cible est planifié pour effectuer des tâches intensives d'E/S à une heure donnée, planifiez les sauvegardes afin qu'elles s'effectuent à un autre moment.

◆ Données d'E/S :

• L'accès aux données brutes offre le niveau de performances le plus élevé, mais ne trie pas les données sauvegardées de manière logique pour les prochains accès.

• Un système de fichiers contenant un grand nombre de fichiers voit ses performances altérées en raison du traitement supplémentaire qu’il nécessite.





Tableau 2 Caractéristiques du bus (page 2 of 2)

Type de bus MHz Mo/seconde



◆ Compression :

Si les données sont compressées sur le disque, le système d’exploitation ou l’application, celles-ci sont décompressées avant la sauvegarde. Le CPU a alors besoin de temps pour recompresser les fichiers, et la vitesse du disque en est affectée.

Besoins en E/S par seconde pour le stockage

Le système de fichiers utilisé pour héberger les données NetWorker (/nsr) doit être un système de fichiers natif, pris en charge par le fabricant du système d’exploitation pour le système d’exploitation sous-jacent et doit être parfaitement compatible avec Posix.

Si les exigences relatives aux performances du stockage, mesurées en IOPS (E/S par seconde) et documentées dans la présente section ne sont pas satisfaites, le serveur NetWorker en subit les conséquences et peut rester sans réponse pendant de brefs instants.

Si les performances du stockage chutent au-dessous de 50 % des besoins en IOPS souhaitées :

◆ Les performances du serveur NetWorker peuvent devenir peu fiables ◆ Le serveur NetWorker peut rester sans réponse pendant de longues périodes◆ Les tâches de sauvegarde peuvent échouer

Les exigences du serveur NetWorker en matière de performances du stockage sont déterminées par les éléments suivants :

◆ Surveillance de la zone de données NetWorker◆ Procédures de sauvegarde◆ Tâches de maintenance◆ Tâches de reporting◆ Tâches manuelles

Temps de latence des opérations en écriture sur les disques du noeud de stockage et du serveur NetWorker

Cette section présente les impératifs à respecter pour les temps de latence des opérations en écriture du noeud de stockage et du serveur NetWorker. Les temps de latence des opérations d’écriture /nsr du serveur NetWorker et des noeuds de stockage jouent un rôle plus important pour les périphériques /nsr d’hébergement du stockage que la quantité de bande passante globalement disponible. La raison en est que NetWorker utilise un très grand nombre de petites E/S aléatoires pour accéder aux bases de données internes.Le Tableau 1 à la page 17 répertorie les conséquences des temps de latence des opérations d’écriture des disques sur les performances des opérations de sauvegarde NetWorker.

Considérations relatives au stockage 21


Remarque : évitez d’utiliser les technologies de réplication synchrone ou toute autre technologie ayant des effets contraires sur les temps de latence.

Paramètres recommandés pour les disques du noeud de stockage et du serveurCette section présente les recommandations à suivre pour optimiser les performances des disques du noeud de stockage et du serveur NetWorker :

◆ Pour les serveurs NetWorker dont la charge de travail augmente (plus de 100 sessions intervenant en parallèle pendant une opération de sauvegarde), dédiez un périphérique de disque rapide à l’hébergement des bases de données NetWorker.

◆ Pour le stockage sur disque du serveur NetWorker, utilisez la technologie RAID-10.

◆ Pour les grands serveurs NetWorker Server traitant plus de 400 sessions en parallèle, divisez les systèmes de fichiers utilisés par NetWorker Server. Divisez par exemple le dossier /nsr d’un seul montage en plusieurs points de montage comme suit :

/nsr

/nsr/res

/nsr/index

/nsr/mm

◆ Pour les sauvegardes NDMP sur le serveur NetWorker, stockez le dossier /nsr/tmp dans un emplacement distinct pour permettre le traitement de fichiers temporaires volumineux.

Tableau 3 Résultats et recommandations concernant les temps de latence des opérations d’écriture des disques

Temps de latence des opérations d’écriture des disques en millisecondes (ms) Conséquences sur les performances Recommandé

25 ms et moins • Performances de sauvegarde stables

• Vitesses de sauvegarde optimales

Oui

50 ms • Performances de sauvegarde peu élevées (le serveur NetWorker est contraint de réguler les mises à jour des bases de données)

• Mises à jour NMC retardées ou en échec

Non

100 ms Sessions et groupes de sauvegarde en échec

Non

150 à 200 ms • Démarrage processus NetWorker retardé

• Performances de sauvegarde instables

• Volumes non préparés aux opérations d’écriture

• Communication des processus instable

Non



◆ Utilisez le système d’exploitation pour gérer les E/S parallèles du système de fichiers, même si tous les points de montage se trouvent au même emplacement physique. Le système d’exploitation gère les E/S parallèles du système de fichiers plus efficacement que le logiciel NetWorker.

◆ Utilisez la technologie RAID-3 pour le stockage sur disque AFTD.

◆ Pour le logiciel de protection antivirus, désactivez l’analyse des bases de données NetWorker. Si le logiciel de protection antivirus peut analyser le dossier /nsr, une détérioration des performances, des temporisations ou une corruption des bases de données NetWorker peuvent en résulter en raison des fréquentes demandes d’ouverture/de fermeture de fichiers. La liste d’exclusion du logiciel en question doit également inclure les emplacements du noeud de stockage NetWorker utilisés par les périphériques AFTD.

Désactiver l’analyse antivirus d’emplacements spécifiques peut ne pas être efficace si tous les emplacements sont inclus pendant l’accès aux fichiers, et ce malgré la liste d’exclusion et si cette désactivation ignore l’analyse des fichiers auxquels le système a déjà accédé. Prenez contact avec le fournisseur concerné pour obtenir une version à jour de votre logiciel de protection antivirus.

◆ Le cache agressif du système de fichiers peut engendrer des problèmes de validation pour :

• Le serveur NetWorker : toutes les bases de données NetWorker peuvent être concernées (nsr\res, nsr\index, nsr\mm).

• Le noeud de stockage NetWorker : lorsque configuré pour utiliser des périphériques AFTD.

Assurez-vous de désactiver les opérations d’écriture retardées et d’utiliser à la place les commandes Flush et Write-Through des pilotes.

◆ Les temps de latence des disques jouent un rôle plus important pour le serveur NetWorker que pour les applications de serveur plus classiques, le serveur NetWorker recourant à des E/S garanties : chaque opération d’écriture dans les bases de données internes de NetWorker doit être acquittée et vidée avant que la prochaine opération d’écriture ne puisse avoir lieu, ceci afin d’éviter tout risque de perte de données dans les bases de données internes de NetWorker. Pour les périphériques /nsr, prenez en compte les consignes suivantes en cas de réplication ou de mise en miroir du stockage :

• N’utilisez pas la réplication logicielle, celle-ci ajoutant une couche supplémentaire au débit des E/S et provoquant un comportement imprévisible de la part de NetWorker.

• Dans le cadre des réplications matérielles, la méthode privilégiée est la réplication asynchrone, celle-ci n’ajoutant pas de temps de latence aux opérations d’écriture.

• N’effectuez pas de réplication synchrone sur des liaisons longue distance ou sur des liaisons ne garantissant pas les temps de latence.

• Les réseaux SAN limitent la réplication locale à 12 km. Les distances plus longues nécessitent par conséquent une gestion spécifique.

• N’utilisez pas les réseaux TCP pour la réplication synchrone, ceux-ci ne garantissant pas de temps de latence spécifiques.



• Prenez en compte le nombre de hops, chaque composant matériel ajoutant un temps de latence supplémentaire.

Recommandations en matière de performances de stockage

Le même sous-système de stockage physique peut fonctionner de différentes manières selon la configuration. Par exemple, scinder un point de montage NetWorker unique (/nsr) en plusieurs points de montage peut accroître considérablement les performances grâce au parallélisme du gestionnaire de système de fichiers du système d’exploitation.

Le logiciel NetWorker n’utilise pas d’E/S directes, mais il émet une demande de synchronisation pour chaque opération d’écriture afin de s’assurer que les données sont vidées sur le disque et d’éviter toute perte de données en cas de défaillance du système (ces écritures sont également appelées écritures d’E/S validées). Par conséquent, la mise en cache des écritures sur le système d’exploitation a un impact minime, voire nul. Toutefois, la mise en cache à écriture différée (write-back) basée sur le matériel peut fortement améliorer les performances du serveur NetWorker.

Les processus peuvent être monothread ou multithread (en fonction du processus lui-même et de ses possibilités de configuration), mais les E/S sont toujours des E/S bloquantes (MMDB, RAP) pour fournir une protection optimale des données. L’exception est la base de données d’index où chaque client dispose de son propre flux d’E/S.

Les recommandations générales de stockage des métadonnées du NetWorker Server sont regroupées en fonction du type de base de NetWorker :

◆ La base de données RAP est en mode fichier avec des opérations de lecture de fichier complet et des E/S moyennes supérieures à 1 Ko.

◆ La base de données MMDB est en mode bloc avec une taille de bloc fixe de 32 Ko, et de nombreuses opérations de lecture et des opérations d’écriture inférieures.

◆ Définissez des points de montage distincts pour chaque base de données sur le disque flash pour éviter les goulots d’étranglement d’E/S lors de la mise à jour des bases de données RAP, MMDB et d’index par le NetWorker Server.

◆ La base de données d’index utilise principalement des opérations d’écriture séquentielles sans taille de bloc fixe et peu d’opérations de lecture. Un niveau de stockage inférieur tel que le stockage SAS ou SATA est suffisant pour la base de données d’index.

◆ Le dossier NetWorker temporaire (/nsr/tmp) est fortement sollicité lors des opérations de fusion d’index des sauvegardes NDMP. Il doit résider sur un niveau de stockage supérieur tel que des disques FC.

Considérations relatives au modèle d’E/SLe modèle d’E/S utilisé par NetWorker pour accéder aux bases de données de configuration et de métadonnées varie en fonction de la base de données et de son utilisation. Cependant, il comprend généralement les éléments suivants :

◆ opérations de sauvegarde normales : 80 % en écriture/20 % en lecture ;

◆ opérations de contrôle d’intégrité : 20 % en écriture/80 % en lecture ;

◆ opérations de reporting : 100 % en lecture.



Compte tenu de ces informations, le contrôle d’intégrité quotidien doit être effectué en dehors de la fenêtre de sauvegarde principale. Par ailleurs, il est recommandé de configurer les solutions externes qui fournissent des informations de reporting de telle sorte qu’elles évitent de créer des charges excessives sur les bases de métadonnées NetWorker lors d’une fenêtre de sauvegarde de production.

La taille des blocs d’E/S varie également en fonction de la base de données et de l’utilisation prévue, mais elle correspond généralement à des demandes de 8 Ko environ.

Exigences relatives à la surveillance de la zone de données NetWorkerLe système de stockage doit fournir un minimum de 30 IOPS au serveur NetWorker. Ce nombre augmente avec la charge appliquée au serveur NetWorker.

Exigences relatives aux tâches de sauvegarde

Les opérations de démarrage et d'exécution de la sauvegarde représentent l'essentiel de la charge de travail exécutée par le logiciel NetWorker :

◆ Selon la charge, ajoutez aux IOPS requises le nombre maximal de sessions simultanées exécutées sur le serveur NetWorker et divisez ce nombre par 3.

Le parallélisme maximal du serveur NetWorker est de 512. Par conséquent, la charge optimale est de 170 IOPS.

◆ Les besoins en IOPS augmentent si le logiciel NetWorker doit effectuer les sauvegardes de l'index et des données d'amorçage simultanément. Dans ce cas, ajoutez :

• 50 IOPS pour les serveurs de petite taille • 150 IOPS pour les serveurs de taille moyenne • 400 IOPS pour les serveurs volumineux

Le Tableau 4 à la page 30 fournit des instructions pour les serveurs NetWorker de toutes tailles : petits, moyens et grands.

Ajoutez d'autres IOPS uniquement si la sauvegarde des données d'amorçage s'exécute simultanément aux opérations de sauvegarde habituelles. Si la sauvegarde des données d'amorçage est configurée pour s'exécuter lorsque le serveur NetWorker est inactif, l'ajout d'IOPS supplémentaires n'est pas nécessaire.

◆ Les besoins en IOPS augmentent si le logiciel NetWorker est configuré pour démarrer un grand nombre de tâches simultanément.

Pour prendre en charge les pics de charge, ajoutez 1 IOPS pour chacune des sessions démarrées en parallèle.

Il est recommandé de ne pas démarrer plus de 40 clients par groupe avec un parallélisme client par défaut de 4. Le résultat est de 160 IOPS lors du démarrage du groupe.

Démarrer un grand nombre de clients simultanément peut entraîner un manque au niveau du système des E/S.

◆ Chaque volume nécessite des résultats dans un bref pic de charge de 200 IOPS environ, pendant quelques secondes.



Pour les environnements exécutant un petit nombre de volumes, l'effet est minime. Toutefois, pour les environnements avec de fréquentes demandes de montage, une charge significative est ajoutée au serveur NetWorker. Dans ce cas, ajoutez 100 IOPS pour une activité élevée (plus de 50 demandes de montage par heure). Pour éviter une charge excessive, utilisez un plus petit nombre de volumes de grande capacité.

◆ Les sauvegardes NDMP ajoutent une charge supplémentaire en raison du post-traitement de l'index.

Pour les sauvegardes d'environnement NDMP volumineuses avec plus de 10 millions de fichiers, ajoutez 120 IOPS supplémentaires.

Exigences relatives au paramètre de noyau NetWorkerCréez un script de démarrage séparé pour les NetWorker Servers gérant des charges importantes, en activant les variables d’environnement suivantes avant le démarrage des services NetWorker :

◆ tcp_backlog_queue : ajoutez les paramètres de noyau appropriés dans le script de démarrage en fonction du système d’exploitation.

◆ Descripteurs de fichier ouvert : remplacez la valeur du paramètre des descripteurs de fichier ouvert par le minimum de 8192 nécessaire sur les NetWorker Servers gérant des charges importantes.

Utilisez le script de démarrage par défaut sur les nœuds de stockage NetWorker et les NetWorker Clients. La variable tcp_backlog_queue et les paramètres de descripteur de fichier ouvert ne sont pas nécessaires sur les nœuds de stockage et les clients.

Considérations relatives aux flux de sauvegarde parallèlesDans NetWorker version 8.1 ou supérieure, la fonction de flux de sauvegarde parallèle (PSS) permet de sauvegarder les savesets de ressource Client en plusieurs flux parallèles sur un ou plusieurs périphériques de sauvegarde de destination. L’entrée de saveset est également appelée « point de sauvegarde ». Il s’agit généralement d’un répertoire de montage de système de fichiers UNIX ou Linux.

Remarque : Actuellement, la fonction PSS n’est pas prise en charge pour les sauvegardes de redémarrage de point de contrôle et les sauvegardes synthétiques complètes. De même, la version 8.1 ou supérieure de NetWorker Server et NetWorker Client est requise pour que la fonction PSS puisse être utilisée pour les sauvegardes incrémentielles et complètes, la récupération et le clonage.

Lorsqu’une valeur de parallélisme d’une ressource Client activée pour la fonction PSS, est supérieure au nombre de points de sauvegarde de la ressource, le processus du groupe de sauvegardes effectué selon la sauvegarde planifiée, divise le parallélisme entre les points de sauvegarde et démarre les processus de sauvegarde PSS pour tous les points de sauvegarde quasiment au même moment. Toutefois, cela s’effectue dans les limites des contrôles de NetWorker Server, du parallélisme du groupe et de la disponibilité d’une session de périphérique de médias. Il est recommandé de définir la valeur du parallélisme PSS de la ressource Client sur le double du nombre de points de sauvegarde, minimum.



Le nombre de flux pour chaque point de sauvegarde PSS est déterminé avant la sauvegarde et reste inchangé pendant toute la sauvegarde. Ce nombre varie de 1 à 4 (maximum), où 1 indique un seul flux avec un processus PSS distinct qui consulte le système de fichiers du point de sauvegarde afin de déterminer les fichiers à sauvegarder. La séparation des processus destinés à la collecte des données et à la consultation du système de fichiers peut améliorer les performances. De même, le nombre de processus de « sauvegarde » qui s’exécutent pendant la sauvegarde d’un point de sauvegarde PSS est égal au nombre de processus de flux de sauvegarde attribués plus deux processus de sauvegarde supplémentaires correspondant aux processus de consultation des systèmes de fichiers et de répertoires.

Lorsque le parallélisme du client est inférieur à son nombre de points de sauvegarde, certaines sauvegardes de points de sauvegarde s’exécutent en mode PSS, avec un seul flux. Les autres points de sauvegarde s’exécutent en mode par défaut (non-PSS). Par conséquent, pour utiliser la fonction PSS de manière cohérente, définissez le parallélisme du client sur le double du nombre de points de sauvegarde, au minimum. Ainsi, chaque point de sauvegarde disposera de plusieurs flux. Il est recommandé que les systèmes de fichiers rapides et volumineux qui doivent bénéficier de PSS soient placés dans une nouvelle ressource Client compatible PSS distincte, planifiée séparément par rapport aux autres points de sauvegarde du client. La planification séparée est obtenue en utilisant deux groupes de sauvegarde différents. Le même groupe de sauvegarde peut toutefois être utilisé si vous évitez que le parallélisme des disques du client lise les conflits. Il est également recommandé d’être prudent lors de l’activation de PSS sur une seule ressource Client avec le mot-clé « Tous ». Le mot-clé « Tous » se développe afin d’inclure plusieurs petits systèmes de fichiers d’exploitation qui résident sur le ou les mêmes disques d’installation. Ces systèmes de fichiers ne bénéficient pas de PSS mais plutôt des précieuses ressources multistreaming PSS gaspillées.

Exemple 1 Avec le parallélisme du client défini sur 8 et trois points de sauvegarde /sp1, /sp2 et /sp3 explicitement répertoriés ou développés par le mot-clé « Tous », le nombre de flux PSS pour chaque point de sauvegarde s’élève à 3, 3 et 2 respectivement. Le nombre d’enregistrements de point de sauvegarde de la base de données des médias mminfo est également de 3, 3 et 2 respectivement. Pour un point de sauvegarde donné, /sp1, mminfo et la requête de saveset NMC affichent chacun trois enregistrements de point de sauvegarde nommés "/sp1", "<1>/sp1" et "<2>/sp1". Les enregistrements connexes ont des durées d’enregistrement uniques, proches les unes des autres. L’enregistrement « /sp1 » a toujours la dernière durée d’enregistrement, c’est-à-dire la durée d’enregistrement maximale, qui commence en dernier. Dès lors, l’agrégation de restauration basée sur le temps associée à l’ensemble du point de sauvegarde /sp1 fonctionne automatiquement.

Basé sur Exemple 1, l’enregistrement du saveset /sp1 est appelé « maître » et son temps de saveset est utilisé dans la navigation et les opérations de restauration basées sur le temps. Il référence les deux enregistrements connexes (dépendants) via l’attribut « *mbs dependents ». Cet attribut répertorie les ID de saveset portable de format long des dépendants. Chaque dépendant référence indirectement son maître via le nom du saveset et les associations de durée d’enregistrement. Son maître correspond à l’enregistrement du saveset avec la prochaine durée d’enregistrement la plus élevée et le nom du saveset sans préfixe. De même, chaque enregistrement maître a un attribut « *mbs anchor save set time », qui référence son dépendant avec la première durée de saveset.

PSS est plus efficace que la division manuelle du point de sauvegarde /sp1 en plusieurs sous-répertoires, « /sp1/sub dir A », « /sp1/subdirB »... et la saisie de chaque sous-répertoire séparément dans la ressource Client. Grâce à PSS, ces opérations ne sont



plus nécessaires. PSS effectue automatiquement une meilleure optimisation de l’équilibrage des charges au niveau des fichiers, et non au niveau des répertoires comme dans la méthode manuelle. PSS crée des pseudo-sous-répertoires correspondant aux noms des enregistrements de saveset de média, par exemple « /sp1 », « <1>/sp1 » et « <2>/sp1 ».

La restauration basée sur le temps et le clonage des groupes de sauvegarde agrègent automatiquement les multiples savesets physiques d’une sauvegarde PSS de points de sauvegarde. Les multiples savesets dépendants physiques restent cachés. Cependant, il n’y a pas d’agrégation automatique lors de l’utilisation d’une restauration basée sur un saveset, d’un scanner, d’une ligne de commande manuelle nsrmm ou nsrclone -S. L’option de commande -S exige que les ID de saveset PSS du maître et des dépendants soient spécifiés sur la ligne de commande. L’option -S est toutefois rarement requise avec PSS.

Lorsque des configurations client PSS similaires à celles-ci sont modifiées, le nombre de flux de sauvegarde peut changer pour la prochaine sauvegarde de point de sauvegarde :

◆ Nombre de points de sauvegarde

◆ Valeur de parallélisme

PSS tente de détecter automatiquement les différences dans le nombre de flux de sauvegarde et réinitialise la sauvegarde à un niveau complet, en conséquence. Une nouvelle séquence de sauvegarde <full, incr, incr, … > démarre avec le même nombre de savesets de base de données de médias pour chaque sauvegarde de point de sauvegarde PSS. La fenêtre de session des détails du groupe NMC affiche le niveau incrémentiel initialement tenté. Les fenêtres de demande de listes des savesets complets et des sessions de sauvegardes actives affichent, quant à elles, le véritable niveau de la réinitialisation : Complet. Le même principe s’applique aux numéros attribués aux niveaux incomplets allant de 1 à 9, et non au niveau incrémentiel qui correspond également au niveau 10.

Exemples de ligne de commande

Cette section fournit des exemples de ligne de commande à la suite d’une sauvegarde PSS pour l’exemple de point de sauvegarde « /sp1 ».

◆ Pour afficher les informations consolidées du fichier log associé à la tâche après une sauvegarde planifiée de /sp1 :

# tail /nsr/logs/sg/<save group name>/<job#>…

parallel save streams partial completed savetime=1374016342parallel save streams partial completed savetime=1374016339parallel save streams partial completed savetime=1374016345parallel save streams summary test.xyx.com: /sp1 level=full, 311 MB 00:00:08 455 filesparallel save streams summary savetime=1374016345

◆ Pour répertorier uniquement le saveset maître pour toutes les sauvegardes /sp1 full/incr :

# mminfo -ocntR -N "/sp1" -r "client,name,level,nsavetime,savetime(25),ssid,ssid(53),totalsize,nfiles,attrs"

◆ Pour agréger automatiquement « <i>/sp1 » avec les savesets « /sp1 » :



# recover [-t <now or earlier_master_ss_time] [-d reloc_dir] -a /sp1

◆ Pour répertorier les savesets maître et dépendants pour toutes les sauvegardes /sp1 full/incr :

# mminfo -ocntR -r "client,name,level,nsavetime,savetime(25),ssid,ssid(53),totalsize,nfiles,attrs" | grep " /sp1"

Prenez en compte les considérations et les recommandations suivantes pour bénéficier des améliorations de performances de la fonction PSS :

◆ La fonction PSS dynamise les performances des sauvegardes en partageant les savesets en plusieurs flux basés sur le parallélisme du client. La répartition uniforme des tailles de répertoire et de fichier dans les savesets optimise les avantages des performances apportés par la fonction PSS.

◆ Les volumineux savesets résidant sur des systèmes de stockage présentant un débit global net suffisamment élevé avec des flux de lecture simultanés fonctionnent beaucoup mieux avec la fonction PSS. Évitez d’utiliser des systèmes de stockage lents avec un temps de latence de lecture de disque élevé lorsque la fonction PSS est activée.

◆ Vérifiez que les périphériques cibles sont suffisamment rapides pour éviter les conflits d’écriture ou une mise en file d’attente, car la fonction PSS divise un saveset unique en plusieurs flux de sauvegarde.

◆ Si le périphérique cible est de type Data Domain, assurez-vous que la fonction PSS ne sature pas la limite maximale de sessions autorisées sur le DDR. Chaque périphérique Boost autorise un maximum de 60 sessions simultanées NetWorker.

Exigences relatives aux tâches de maintenance interneLes exigences visant à la réalisation des tâches de maintenance peuvent ajouter une charge significative au logiciel NetWorker :

◆ Les vérifications quotidiennes de la cohérence de la base de données des médias et de l'index nécessitent 40 IOPS supplémentaires dans le cas d'environnements de petite taille, et jusqu'à 200 IOPS supplémentaires pour les environnements de grande taille avec plus de 1 000 clients configurés.

◆ Les environnements dont les périodes de rétention des médias et les périodes de sauvegarde sont très longues (1 an ou plus) connaissent une importante croissance de la base de données interne, générant des besoins supplémentaires allant de 100 à 200 IOPS.

◆ Les opérations de purge peuvent nécessiter 30 IOPS pour les environnements de petite taille avec jusqu'à 1 000 tâches de sauvegarde par jour, 100 IOPS pour les environnements de taille moyenne et jusqu'à 200 IOPS pour les environnements de grande taille avec de lourdes charges de 50 000 tâches par jour.



Exigences relatives aux tâches de reportingLes outils de surveillance tels que le serveur NMC, Data Protection Advisor, le reporting personnalisé ou les scripts de surveillance alourdissent la charge du serveur NetWorker :

◆ Pour chaque serveur NMC, ajoutez 100 IOPS supplémentaires.◆ Pour le reporting DPA, ajoutez 250 IOPS supplémentaires.◆ Les scripts de surveillance ou de reporting client peuvent ajouter des charges

supplémentaires selon la conception.

Par exemple, un reporting en continu sur les bases de données des médias et l'index NetWorker peut nécessiter jusqu'à 500 IOPS supplémentaires.

Exigences relatives aux tâches manuelles du serveur NetWorkerLes tâches manuelles exécutées sur le serveur NetWorker peuvent générer une charge supplémentaire :

◆ Chaque session de restauration devant énumérer des objets sur le serveur de sauvegarde ajoute une charge supplémentaire au serveur NetWorker.

Par exemple, pour énumérer entièrement 10 000 tâches de sauvegarde, le serveur NetWorker peut nécessiter jusqu'à 500 IOPS.

◆ Pour les pics de charge et les charges de travail du système d'exploitation indépendantes, le nombre total d'IOPS calculés doit être augmenté de 30 %.

◆ Les performances d'un seul disque sont souvent insuffisantes pour les serveurs NetWorker volumineux.Le Tableau 5 à la page 32 fournit des informations sur les performances d'un seul disque. Pour atteindre un nombre d'IOPS plus élevé, associez plusieurs disques pour un accès en parallèle. Dans le cas de disques standard, vous obtiendrez des performances optimales avec RAID 0+1. Toutefois, les baies de stockage modernes sont souvent optimisées pour un accès RAID 5 dans le cas de charges de travail aléatoires sur le serveur NetWorker. La mise en cache à écriture différée (Write-back) basée sur le matériel peut considérablement améliorer les performances du serveur NetWorker.Le Tableau 4 à la page 30 fournit des informations sur les besoins en IOPS du serveur NetWorker.

Tableau 4 Nombre d'IOPS requis pour les opérations du serveur NetWorker (page 1 of 2)

Type d'opération

Environnement NetWorker de petite taille 1

Environnement NetWorker de taille moyenne 2

Environnement NetWorker de grande taille 3

Sauvegardes simultanées 30 80 170

Sauvegardes des données d’amorçage

50 150 400

Démarrage de groupe de sauvegarde

50 150 250

Gestion des volumes 0 0 100

Sauvegardes NDMP volumineuses

100 100 200

Tâches de maintenance standard quotidiennes

40 75 100



Considérations relatives aux valeurs IOPS

Cette section répertorie les considérations et les recommandations relatives aux valeurs IOPS :

◆ Le logiciel NetWorker ne limite pas le nombre de clients par zone de données, mais un maximum de 1 000 clients est toutefois recommandé du fait de la complexité inhérente à la gestion de zones de données volumineuses, et aux exigences matérielles accrues que cela génère au niveau du serveur NetWorker.

Remarque : lorsque la charge d'E/S augmente sur le serveur NetWorker, le temps de service au niveau de la couche de stockage augmente également. Si les temps de service dépassent les valeurs requises, cela a un impact direct sur les performances et la fiabilité du serveur NetWorker. Pour plus d'informations sur les exigences relatives aux temps de service maximum, reportez-vous à la section « Temps de latence des opérations en écriture sur les disques du noeud de stockage et du serveur NetWorker », page 21.

◆ Le serveur NetWorker réalise lui-même le déplacement des données (si le périphérique de sauvegarde réside sur le serveur plutôt que sur le noeud de stockage NetWorker), ce qui se répercute directement sur les performances de la sauvegarde.

L’Exemple 2 et l’Exemple 3 reposent sur les exigences précédemment mentionnées.

Exemple 2 Zone de données NetWorker de taille petite à moyenne :

◆ Optimisée : 200 clients s'exécutant en parallèle avec les caractéristiques suivantes :

• 100 tâches avec jusqu'à 1 000 tâches de sauvegarde par jour• sauvegardes réparties dans le temps• aucun reporting externe • aucune tâche de maintenance se chevauchant

◆ Nombre minimal d'IOPS requis : 200, Nombre d'IOPS recommandé : 400

Importante opération de maintenance de la base de données interne

0 100 200

Opérations de purge 30 100 200

Reporting NMC 50 75 100

Reporting DPA 50 100 250

Restauration 30 200 500

1. Un environnement de serveur NetWorker de petite taille comprend moins de 100 clients, ou 100 sessions de sauvegarde simultanées.

2. Un environnement de serveur NetWorker de taille moyenne comprend de 100 à 400 clients, ou 250 sessions de sauvegarde simultanées.

3. Un environnement de serveur NetWorker de grande taille comprend plus de 400 clients, ou 500 sessions de sauvegarde simultanées.

Tableau 4 Nombre d'IOPS requis pour les opérations du serveur NetWorker (page 2 of 2)

Type d'opération

Environnement NetWorker de petite taille 1

Environnement NetWorker de taille moyenne 2

Environnement NetWorker de grande taille 3



◆ Non optimisée : la même charge de travail, toutefois :

• la plupart des tâches de sauvegarde démarrent au même moment. • les sauvegardes de production chevauchent les tâches relatives à la maintenance

et aux données d'amorçage.• un reporting supplémentaire existe.• Nombre minimal d'IOPS requis : 800, Nombre d'IOPS recommandé : 1 000

Exemple 3 Zone de données NetWorker de grande taille :

◆ Optimisée : 1 000 clients s'exécutant en parallèle avec les caractéristiques suivantes :

• 500 tâches avec jusqu'à 50 000 tâches de sauvegarde par jour • sauvegardes réparties dans le temps • sauvegardes sur disque ou d'importants volumes de bandes• aucun reporting externe• aucune tâche de maintenance se chevauchant

◆ Nombre minimal d'IOPS requis : 800, Nombre d'IOPS recommandé : 1 000

◆ Non optimisée : la même charge de travail, toutefois :

• la plupart des tâches de sauvegarde démarrent au même moment.• un grand nombre de petits volumes est utilisé.• les sauvegardes de production chevauchent les tâches relatives à la maintenance

et aux données d'amorçage.• un reporting supplémentaire existe.

◆ Nombre minimal d'IOPS requis : 2 000, Nombre d'IOPS recommandé : 2 500

Cet exemple montre qu'une différence au niveau de la configuration de NetWorker peut générer jusqu'à 250 % de charge supplémentaire sur le serveur NetWorker. De plus, l'impact sur le dimensionnement est tel que les grands environnements optimisés obtiennent de meilleures performances que les environnements de taille moyenne qui ne sont pas optimisés.

Valeurs IOPS pour les technologies de disque durLe Tableau 5 à la page 32 répertorie les différents types de disque dur et les valeurs IOPS correspondantes.

Tableau 5 Valeurs IOPS par disque dur (page 1 of 2)

Type de disque dur Valeurs par périphérique

Disques Flash (EFD) 2 500 E/S par seconde pour les petits blocs d'E/S aléatoires ou 100 Mo/s pour les blocs volumineux séquentiels

Disques FC (Fibre Channel - 15 000 t/min)

180 E/S par seconde pour les petits blocs d'E/S aléatoires ou 12 Mo/s pour les blocs volumineux séquentiels

Disques FC (10 000 t/min) 140 E/S par seconde pour les petits blocs d'E/S aléatoires ou 10 Mo/s pour les blocs volumineux séquentiels



Traitement de l'historique de fichier

L'historique de fichier est traité par NDMP à la fin de l'opération de sauvegarde, et non durant la sauvegarde elle-même. Cela entraîne des temps d'inactivité perçus comme longs.

Le temps réel de traitement de l'historique de fichier est linéaire malgré le nombre de fichiers contenus dans le Dataset. Toutefois, le temps de traitement dépend d'autres facteurs liés au système de stockage, tels que :

◆ Type RAID

◆ Le nombre de disques configurés

◆ La taille du cache

◆ Le type du système de fichiers hébergeant /nsr/index et /nsr/tmp

Remarque : les résultats attendus sont environ de 20 minutes pour chaque série de 10 millions de fichiers.

Le traitement de l'historique de fichier crée une charge d'E/S significative sur le serveur de sauvegarde, et accroît les besoins en IOPS de 100 à 120 opérations d'E/S par seconde au cours du traitement. Si les besoins en IOPS minimum ne sont pas satisfaits, le traitement de l'historique de fichier peut en être considérablement ralenti.

Réseau

Les composants ayant une incidence sur les performances de la configuration du réseau sont répertoriés ci-après :

◆ Réseau IP :

Réseau informatique constitué de périphériques prenant en charge le protocole Internet (IP) pour déterminer la source et la destination des communications réseau.

◆ Réseau de stockage :

Système sur lequel réside le dispositif de stockage physique tel qu'une bande, un disque ou un système de fichiers.

◆ Vitesse du réseau :

Vitesse à laquelle les données circulent sur le réseau.

◆ Bande passante réseau :

Débit maximal d'un réseau informatique.

Disques SATA2 ou LCFC (7 200 t/min)

80 E/S par seconde pour les petits blocs d'E/S aléatoires ou 8 Mo/s pour les blocs volumineux séquentiels

Disques SATA (7 200 t/min) 60 E/S par seconde pour les petits blocs d'E/S aléatoires ou 7 Mo/s pour les blocs volumineux séquentiels

Disques PATA (5 400 t/min) 40 E/S par seconde pour les petits blocs d'E/S aléatoires ou 7 Mo/s pour les blocs volumineux séquentiels

Tableau 5 Valeurs IOPS par disque dur (page 2 of 2)

Type de disque dur Valeurs par périphérique



◆ Chemin de réseau :

Chemin de communication utilisé pour le transfert des données au sein d'un réseau.

◆ Charge simultanée du réseau :

Point où les données sont placées dans un réseau afin d'optimiser la bande passante en bout de chaîne.

◆ Latence du réseau

Mesure du délai relatif au transfert de données entre des périphériques source et cible au sein d'un réseau.

Périphérique cible

Les composants suivants ont une incidence sur les performances des configurations du périphérique cible :

◆ Type de stockage :

• Comparaison entre disque brut et appliance de disques :

– Disque brut : accès au disque dur à un niveau binaire, brut, inférieur au niveau des systèmes de fichiers.

– Appliance de disques : système de serveurs, de noeuds de stockage et de logiciels.

• Comparaison entre bande physique et librairie de bandes virtuelle :

– La librairie de bandes virtuelle (VTL) présente un composant de stockage (généralement un stockage sur disque dur) comme les librairies de bandes ou les lecteurs de bandes, pour qu'il soit utilisé comme moyen de stockage avec le logiciel NetWorker.

– La bande physique est un type de média de stockage amovible, généralement un volume ou une cartouche, qui contient une bande magnétique.

◆ Connectivité :

• Local, SAN :

Réseau informatique, distinct des réseaux LAN ou WAN, conçu pour connecter des périphériques de stockage partagés tels que des baies de disques et des librairies de bandes, à des serveurs.

• IP :

Chaque périphérique de stockage possède sa propre adresse IP, qui est unique.

Règle des 70 % du composant

Les performances et le débit indiqués par les fabricants et mesurés à partir d'environnements théoriques ne sont rarement, voire jamais, atteints dans des environnements de sauvegarde réels. La meilleure pratique consiste à ne jamais dépasser les 70 % de la capacité indiquée d'un composant. Composants :

◆ CPU◆ Disque



◆ Réseau◆ Bus interne◆ Mémoire◆ Fibre Channel

Les performances et le temps de réponse sont considérablement altérés lorsque le seuil d'utilisation de 70 % est dépassé.

Les lecteurs de bandes physiques et les disques SSD sont les seules exceptions à cette règle, et doivent être utilisés autant que possible à 100 % de leur capacité. Ni les lecteurs de bandes, ni les disques SSD ne subissent de dégradation de leurs performances lors d'une utilisation intensive.

Composants d'un environnement NetWorkerCette section décrit les composants d'une zone de données NetWorker.La Figure 3 à la page 36 illustre les principaux composants d'un environnement EMC NetWorker. Les composants et les technologies qui constituent un environnement NetWorker sont répertoriés ci-après :

◆ « Zone de données », page 36

◆ « NetWorker Management Console », page 36

◆ « serveur EMC NetWorker », page 39

◆ « nœud de stockage EMC NetWorker », page 41

◆ « client EMC NetWorker », page 41

◆ « Bases de données NetWorker », page 42

◆ « Modules d’application facultatifs NetWorker », page 42

◆ « Environnements virtuels », page 42

◆ « Noeuds de déduplication EMC NetWorker », page 43

Composants d'un environnement NetWorker 35


Figure 3 Composants d'une zone de données EMC NetWorker

Zone de données

Une zone de données correspond à un serveur EMC NetWorker seul et ses ordinateurs client. Il est possible d'ajouter des zones de données à mesure que les besoins en matière de sauvegarde augmentent.

Remarque : il est recommandé de ne pas posséder plus de 1 500 clients ou 3 000 instances de client par zone de données NetWorker. Ce nombre correspond à un serveur NetWorker moyen et ne constitue pas une limite ferme et définitive.

NetWorker Management Console

NMC (NetWorker Management Console) permet de gérer le serveur de sauvegarde et fournit des fonctions de reporting de sauvegarde.

NMC s'exécute généralement sur le serveur de sauvegarde et lui ajoute une charge importante. Pour les environnements de grande taille, il est recommandé d'installer NMC sur un ordinateur distinct. Un seul serveur NMC peut être utilisé pour gérer plusieurs serveurs de sauvegarde.

Serveurs EMC

NetWorker

Interface utilisateur de Console

périphériqueserveur de Console

Noeud de stockage

Clients EMC NetWorker

Zones de données



Composants déterminant les performances de NMCLes composants suivants déterminent les performances de NMC :

◆ Connectivité réseau TCP vers le serveur de sauvegarde : Toutes les communications entre NMC et le serveur NetWorker s'effectuent via TCP et une connectivité réseau de ce type, à faible latence et haute vitesse est essentielle.

◆ Mémoire : Les tâches relatives aux bases de données dans des environnements de plus grande taille consomment beaucoup de mémoire. Assurez-vous que le serveur NMC en possède suffisamment.

◆ CPU : Si le serveur NMC est utilisé par plusieurs utilisateurs, assurez-vous que la puissance de CPU est suffisante pour que chaque utilisateur dispose d’une partie suffisante de temps CPU.

Configuration système minimale requise pour le serveur NMCCette section fournit des informations sur la configuration minimale requise pour le serveur NMC :

◆ Mémoire :

1 GHz au minimum et 512 Mo de RAM sont nécessaires. Ajoutez 512 Mo de RAM supplémentaire pour exécuter des rapports.

◆ Espace disque disponible :

Double coeur 2 GHz et 2 Go de RAM avec un tampon d’espace disque pour une base de données de console volumineuse avec plusieurs utilisateurs.

◆ JRE avec Web Start<:hs>:

55 Mo, et au fur et à mesure que le nombre de serveurs surveillés par NetWorker augmente, accroissez les capacités du processeur comme suit :

• Pour 50 serveurs : processeur double 1 GHz avec au moins 2 Go de RAM• Pour 100 serveurs : processeur double 1 GHz avec au moins 4 Go de RAM• Pour 200 serveurs : quatre processeurs 1 GHz avec au moins 8 Go de RAM

Base de données de la Console

Cette section fournit des informations permettant d’estimer les contraintes en termes de taille et d’espace requis pour la base de données de la Console :

◆ « Formule pour estimer la taille de la base de données de EMC NetWorker Management Console », page 38

◆ « Formule permettant d’estimer l’espace requis pour les informations de la base de données de la Console », page 38



Formule pour estimer la taille de la base de données de EMC NetWorker Management ConsoleLe serveur de Console collecte des données des serveurs EMC NetWorker de l’entreprise et les stocke dans la base de données locale de la Console. Par défaut, la base de données est installée sur le système de fichiers local pouvant fournir le plus d’espace disponible. La Console intègre et traite ces informations pour produire des rapports qui facilitent l’analyse des tendances, la planification des capacités et la détection des problèmes. Le guide d'administration EMC NetWorker fournit des informations sur les rapports.

Pour stocker les données recueillies, allouez suffisamment d’espace disque à la base de données de la Console. Plusieurs facteurs affectent la quantité d’espace disque requise<:hs>:

◆ le nombre de serveurs EMC NetWorker surveillés pour les rapports ;◆ le nombre de groupes de sauvegarde exécutés par chacun de ces serveurs ;◆ la fréquence d’exécution des groupes de sauvegarde ;◆ la durée de conservation des données du rapport (rétention des données).

Remarque : la quantité d’espace disque requise étant en rapport direct avec la quantité de données historiques enregistrées, les besoins sont très variables, et s’échelonnent en moyenne entre 0,5 et plusieurs Go. Tenez compte de ceci lors de la planification de la configuration matérielle.

Formule permettant d’estimer l’espace requis pour les informations de la base de données de la Console

Utilisez ces formules pour estimer l’espace requis pour les différents types de données ainsi que l’espace total.

Base de données des médias du saveset

Pour estimer l’espace requis par la base de données des médias du saveset, multipliez la quantité hebdomadaire de savesets par le nombre de<:hs>:

◆ serveurs EMC NetWorker contrôlés par la Console ;◆ semaines indiqué dans la règle de création de saveset.

Le résultat indique le temps nécessaire à la bonne exécution d’un saveset. Les résultats identifient également le nombre de fichiers sauvegardés, et la quantité de données enregistrées pendant l’opération.

Création de savesets

Pour estimer l’espace requis par la base de données des médias du saveset, multipliez la quantité hebdomadaire de messages générés par le nombre de<:hs>:

◆ serveurs EMC NetWorker contrôlés par la Console ;◆ politique de rétention des médias associées à la création de savesets.

Le résultat indique combien de tentatives d’émissions de groupes et de savesets ont été effectuées et l’issue de ces opérations.



Données finales du groupe de sauvegarde

Pour estimer l’espace requis par la base de données des médias du saveset, multipliez la quantité hebdomadaire de groupes de sauvegarde par le nombre de<:hs>:

◆ serveurs EMC NetWorker contrôlés par la Console ;◆ semaines indiqué dans la politique de rétention des données finales.

Les résultats obtenus peuvent être utilisés pour résoudre les problèmes de sauvegarde.

serveur EMC NetWorker

Les serveurs EMC NetWorker fournissent des services permettant de sauvegarder et restaurer des données pour les ordinateurs client EMC NetWorker dans une zone de données. Le serveur NetWorker peut également servir de noeud de stockage et contrôler plusieurs noeuds de stockage distants.

Les opérations de gestion de l'index et des médias font partie des principaux processus exécutés par le serveur NetWorker :

◆ L'index des fichiers client assure le suivi des fichiers qui appartiennent à un saveset. Il existe un fichier d’index en ligne pour chaque client.

◆ La base de données des médias assure le suivi des éléments suivants :

• le nom du volume ;

• l'emplacement de chaque fragment de saveset sur le média physique (numéro de fichier/enregistrement de fichier) ;

• les dates de sauvegarde des savesets sur le volume ;

• les systèmes de fichiers dans chaque saveset.

◆ Contrairement aux fichiers d’index client, il existe une seule base de données des médias par serveur.

◆ L'index des fichiers client et la base de données des médias peuvent croître à tel point que leur taille peut devenir excessive avec le temps et avoir une incidence négative sur les performances de la sauvegarde.

◆ Le serveur NetWorker planifie et place en file d'attente toutes les opérations de sauvegarde, effectue le suivi des activités relatives à la restauration et à la sauvegarde en temps réel, et de toutes les communications NMC. Ces informations sont stockées pour un laps de temps limité dans la base de données des tâches dont l'incidence sur les performances du serveur de sauvegarde est la plus critique, pour les opérations en temps réel.

Remarque : les données stockées dans cette base de données ne sont pas nécessaires pour les opérations de restauration.

Composants déterminant les performances du serveur de sauvegardeLe service nsrmmdbd est gourmand en ressources CPU lorsque des milliers de savesets sont traités en une seule opération. Par conséquent, les opérations de clonage comportant des savesets volumineux et les activités de maintenance NetWorker doivent être exécutées en dehors de la fenêtre de sauvegarde principale.



Les composants suivants déterminent les performances de la sauvegarde du serveur NetWorker :

◆ Utilisation d'un système 64 bits pour le serveur NetWorker.

◆ Utilisation de matériel actuel pour le serveur NetWorker. Par exemple, la version actuelle du logiciel NetWorker Server ne fonctionnera pas correctement sur un matériel de plus de 10 ans.

◆ Minimisez les opérations à forte consommation de ressources système sur le serveur NetWorker pendant les charges importantes, comme un grand nombre de flux de sauvegarde/clonage/restauration simultanés :

• nsrim• nsrck

◆ Disque utilisé pour héberger le serveur NetWorker (/nsr) :

La charge de travail classique du serveur NetWorker est constituée de nombreuses petites opérations d'E/S. C'est pourquoi les disques dotés d'une forte latence offrent de faibles performances malgré une bande passante élevée. Les taux de latence élevés sont les goulots d'étranglement les plus courants pour un serveur de sauvegarde placé dans un environnement de grande taille.

◆ Évitez d'ajouter des couches logicielles supplémentaires car cela augmente la latence au niveau du stockage. Par exemple, le logiciel antivirus doit être configuré avec les bases de données NetWorker (/nsr) dans sa liste d'exclusions.

◆ L'utilisation d'une technologie de réplication doit être envisagée avec prudence car cela accroît de manière significative la latence au niveau du stockage.

◆ Assurez-vous que la puissance de CPU est suffisante pour permettre aux serveurs volumineux d'effectuer toutes les tâches de base de données interne.

◆ Utilisez un moins grand nombre de CPU, car les systèmes dotés de quelques CPU hautes performances surclassent les systèmes dotés de nombreux CPU à plus faibles performances.

◆ Ne connectez pas trop de lecteurs de bande hautes performances ou de périphériques AFTD directement à un serveur de sauvegarde.

◆ Assurez-vous que la mémoire est suffisante pour permettre au serveur d'effectuer toutes les tâches de base de données interne.

◆ Déchargez les sauvegardes vers des noeuds de stockage dédiés lorsque cela est possible pour les clients qui doivent servir de noeud de stockage, en sauvegardant directement les données sur le serveur de sauvegarde.

Remarque : la charge système issue du traitement du noeud de stockage n'est pas négligeable dans les environnements de grande taille. Pour les environnements d'entreprise, le serveur de sauvegarde doit sauvegarder uniquement ses bases de données internes (index et données d'amorçage).



nœud de stockage EMC NetWorker

Un noeud de stockage EMC NetWorker peut être utilisé pour améliorer les performances en déchargeant du serveur EMC NetWorker une grande partie de la transmission des données effectuée dans le cadre d'une opération de sauvegarde ou de restauration. Les noeuds de stockage NetWorker nécessitent une importante bande passante d'E/S pour gérer le transfert de données à partir de clients locaux ou de clients réseau vers des périphériques cibles.

Composants déterminant les performances d'un noeud de stockageLes composants suivants déterminent les performances d'un noeud de stockage :

◆ Performances du périphérique cible utilisé pour stocker la sauvegarde.

◆ Connectivité du système. Par exemple, un noeud de stockage utilisé pour des sauvegardes réseau de type TCP peut sauvegarder des données uniquement à la vitesse à laquelle il est capable de recevoir des données envoyées par les clients.

◆ Bande passante d'E/S : assurez-vous que la bande passante d'E/S est suffisante car chaque noeud de stockage utilise la bande passante disponible du système. Par conséquent, les performances de la sauvegarde de tous les périphériques sont limitées par la bande passante d'E/S du système lui-même.

◆ CPU : assurez-vous que les capacités du CPU sont suffisantes pour envoyer et recevoir d'importants volumes de données.

◆ Veillez à ce que les opérations de staging et de sauvegarde ne se chevauchent pas avec une solution VTL ou AFTD, en utilisant des disques ATA ou SATA. Malgré les performances de la baie, la technologie ATA subit une dégradation significative des performances sur des flux de lecture et d'écriture parallèles.

client EMC NetWorker

Un ordinateur client EMC NetWorker correspond à tout ordinateur dont les données doivent être sauvegardées. Le serveur EMC NetWorker Console, les serveurs EMC NetWorker et les noeuds de stockage EMC NetWorker sont également des clients EMC NetWorker. Les clients NetWorker contiennent des données critiques et consomment énormément de ressources. Les applications situées sur les clients NetWorker sont les principales utilisatrices des ressources de CPU, de réseau et d'E/S. Seules les opérations de lecture effectuées sur le client ne nécessitent pas de traitement supplémentaire.

La vitesse du client est déterminée par toutes les instances actives d'une sauvegarde de client spécifique, à un instant donné.

Composants déterminant les performances du client NetWorkerLes composants suivants déterminent les performances du client NetWorker :

◆ Les sauvegardes de clients sont des opérations à forte consommation de ressources et altèrent les performances des applications principales. Lors du dimensionnement des systèmes pour les applications, tenez compte des sauvegardes et des besoins en bande passante qui en découlent. De même, les applications clients utilisent une quantité importante de ressources de CPU et d'E/S, ce qui ralentit les sauvegardes.

Si un client NetWorker ne dispose pas de suffisamment de ressources, les performances des applications, comme celles des sauvegardes, en seront altérées.



◆ Clients NetWorker disposant de millions de fichiers. Étant donné que la plupart des applications de sauvegarde sont des solutions basées sur des fichiers, le traitement de la totalité des fichiers créés par le système de fichiers requiert beaucoup de temps. Ceci nuit aux performances de sauvegarde de NetWorker Client. Par exemple :

• La sauvegarde complète de 5 millions de fichiers de 20 Ko prend plus de temps que la sauvegarde d'un demi-million de fichiers de 200 Ko, bien que toutes deux génèrent un saveset de 100 Go.

• Pour le même volume global de données modifiées, une sauvegarde incrémentielle/différentielle d'un millier de fichiers de 100 Mo avec 50 fichiers modifiés prend beaucoup moins de temps que celle d'une centaine de milliers de fichiers de 1 Mo avec 50 fichiers modifiés.

◆ Le chiffrement et la compression sont des opérations à forte consommation de ressources sur le client NetWorker et peuvent considérablement altérer les performances de la sauvegarde.

◆ Les données de sauvegarde doivent être transférées vers le système de stockage cible et traitées sur le serveur de sauvegarde :

• Performances du client/noeud de stockage :

– Un noeud de stockage local : utilise une mémoire partagée et ne nécessite pas de temps système supplémentaire.

– Un noeud de stockage distant : voit ses performances en matière de réception limitées par les composants du réseau.

• Charge du serveur de sauvegarde/client :

ne ralentit généralement pas les performances de la sauvegarde du client, à moins que le serveur de sauvegarde ne soit réellement sous-dimensionné.

Bases de données NetWorker

Les facteurs qui déterminent la taille des bases de données NetWorker sont répertoriés dans la section « Goulots d'étranglement au niveau des bases de données NetWorker », page 48.

Modules d’application facultatifs NetWorker

Les modules d’application NetWorker sont utilisés pour des tâches de sauvegarde en ligne spécifiques. Un réglage supplémentaire côté applications peut être nécessaire pour augmenter les performances de la sauvegarde des applications. Pour plus d'informations, consultez la documentation relative aux modules d’application NetWorker.

Environnements virtuels

Les clients EMC NetWorker peuvent être créés pour les machines virtuelles en vue de réaliser des sauvegardes traditionnelles ou VADP (VMware vStorage API for Data Protection). De plus, le logiciel EMC NetWorker peut découvrir automatiquement les environnements virtuels et les modifications apportées à ces environnements, que ce soit de façon planifiée ou à la demande, et fournit une vue graphique de ces environnements.



Noeuds de déduplication EMC NetWorker

Un noeud de déduplication EMC NetWorker est un serveur EMC Avamar® qui stocke des données de sauvegarde dédupliquées. La sauvegarde initiale vers un noeud de déduplication doit être une sauvegarde complète. Lors des sauvegardes ultérieures, l'infrastructure d'Avamar balise les segments de données redondants à la source et ne sauvegarde que les segments uniques et non pas l'intégralité des fichiers comportant des modifications. Ainsi, le temps requis pour effectuer des sauvegardes est réduit, mais aussi la bande passante du réseau et l’espace de stockage utilisés pour les sauvegardes NMC (NetWorker Management Console).

Facteurs déterminant les performances de la restaurationLes performances de la restauration peuvent être altérées par le trafic réseau, les goulots d'étranglement, les fichiers volumineux, etc. En conséquence, les points ci-après doivent être pris en compte :

◆ Les performances d'une restauration basée sur des fichiers dépendent des performances du serveur de sauvegarde, en particulier l'index des fichiers client. Pour plus d'informations sur l'index des fichiers client, reportez-vous à la section « serveur EMC NetWorker », page 39.

◆ La méthode la plus rapide pour restaurer des données de manière efficace consiste à exécuter plusieurs commandes de restauration simultanément en utilisant la restauration d'un saveset. Par exemple, trois opérations de restauration de saveset fournissent le meilleur parallélisme possible compte tenu du nombre de processus, du volume et de l’agencement du saveset.

◆ Si plusieurs opérations de restauration simultanées s'exécutent à partir de la même bande, assurez-vous que la bande n'est pas montée ni démarrée tant que toutes les demandes de restauration ne sont pas prêtes. Si la bande est utilisée avant que toutes les demandes ne soient prêtes, elle sera lue plusieurs fois, ce qui ralentira les performances de la restauration.

◆ Le multiplexage des sauvegardes sur une bande ralentit les performances de la restauration.

Connectivité et goulots d'étranglementUn environnement de sauvegarde est constitué de nombreux périphériques, dont des composants du périphérique cible, du réseau, du dispositif de stockage et du système, sélectionnés parmi des centaines de modèles disponibles auprès de divers fabricants.

Les facteurs ayant une incidence sur les performances relatives à la connectivité sont répertoriés ci-après :

◆ Certains composants peuvent fonctionner parfaitement en tant que périphériques autonomes, mais ce qui rend la configuration optimale, c'est leur comportement lorsqu'il y a d'autres périphériques sur la chaîne.

◆ Les composants situés sur la chaîne ne sont d'aucune utilité s'ils ne peuvent pas communiquer les uns avec les autres.

Facteurs déterminant les performances de la restauration 43


◆ Les sauvegardes sont des opérations à forte consommation de données et peuvent générer d'importants volumes de données. Les données doivent être transférées à des vitesses optimales afin de répondre aux besoins métiers.

◆ Le composant le plus lent de la chaîne est considéré comme un goulot d'étranglement.

Sur la Figure 4 à la page 44, le réseau ne parvient pas à collecter et à envoyer autant de données que les composants. Dans ce cas, le réseau est le goulot d'étranglement, qui ralentit l'ensemble du processus de sauvegarde. Tout périphérique de réseau unique sur la chaîne, comme un hub, un switch ou une carte réseau, peut être le goulot d'étranglement et ralentir l'ensemble de l'opération.

Figure 4 Goulot d'étranglement au niveau du réseau

Comme illustré sur la Figure 5 à la page 45, le réseau est mis à niveau d'un réseau 100 Base-T vers un réseau GigE, et le goulot d'étranglement s'est déplacé vers un autre périphérique. À présent, l'hôte est incapable de générer des données assez rapidement pour utiliser la bande passante réseau disponible. Les goulots d'étranglement du système peuvent être générés par un manque de CPU, de mémoire ou d'autres ressources.



Figure 5 Réseau mis à jour

Comme illustré sur la Figure 6 à la page 46, le client NetWorker est mis à niveau vers un système plus grand afin qu'il ne soit plus le goulot d'étranglement. Avec un meilleur système et plus de bande passante réseau, le périphérique cible est désormais le goulot d'étranglement. Généralement, les unités de bande ne fonctionnent pas aussi bien que les autres composants. Les facteurs suivants limitent les performances des unités de bande :

◆ Bande passante SCSI limitée◆ Performances maximales de l'unité de bande atteintes

Améliorez les performances de l'unité de bande à l'aide d'unités de bande plus performantes, telles que des unités FC (Fibre Channel). De même, les environnements SAN peuvent améliorer considérablement les performances.

Connectivité et goulots d'étranglement 45


Figure 6 Client mis à jour

Comme illustré sur la Figure 7 à la page 47, des unités de bande plus performantes sur un système SAN ne constituent plus un goulot d'étranglement. À présent, le goulot d'étranglement se situe au niveau des périphériques de stockage. Bien que les volumes locaux fonctionnent aux vitesses optimales, ils ne parviennent pas à utiliser les ressources disponibles au niveau du système, du réseau et du périphérique cible. Pour améliorer les performances du stockage, déplacez les volumes de données vers des baies RAID externes plus performantes.



Figure 7 Réseau SAN dédié

Bien que les volumes locaux fonctionnent aux vitesses optimales, ils ne parviennent pas à utiliser les ressources disponibles au niveau du système, du réseau et du périphérique cible. Pour améliorer les performances du stockage, déplacez les volumes de données vers des baies RAID externes plus performantes.

Comme illustré sur la Figure 8 à la page 48, les baies RAID externes ont amélioré les performances du système. Les baies RAID fonctionnent presque aussi bien que les autres composants de la chaîne, garantissant ainsi les performances attendues. Il existera toujours un goulot d'étranglement. Toutefois, l'impact est limité car tous les périphériques fonctionnent quasiment au même niveau que les périphériques de la chaîne.



Figure 8 Baie RAID

Remarque : cette section ne suggère pas la mise à niveau de tous les composants pour améliorer les performances, mais tente d'expliquer le concept de goulot d'étranglement et de souligner l'importance d'avoir des périphériques qui fonctionnent à des vitesses similaires à celles des autres périphériques de la chaîne.

Goulots d'étranglement au niveau des bases de données NetWorker

Cette section répertorie les facteurs déterminant la taille des bases de données NetWorker :

◆ Base de données des ressources NetWorker /nsr/res ou networker install dir/res : le nombre de ressources configurées.

◆ Base de données des tâches NetWorker (nsr/res/jobsdb) : le nombre de tâches telles que les sauvegardes, les restaurations, les clones multiplié par le nombre de jours définis pour la rétention. Ce nombre peut dépasser 100 000 enregistrements dans les plus grands environnements, ce qui constitue le principal goulot d'étranglement en matière de performances. La taille globale n'est jamais significative.

◆ Base de données de médias NetWorker (nsr/mm) : le nombre de savesets en rétention et le nombre de volumes libellés. Dans les environnements les plus vastes, cela peut atteindre plusieurs gigaoctets de données.



◆ Base de données d'index des fichiers client NetWorker (nsr/index) : le nombre de fichiers indexés et soumis à la politique de rétention des index. Il s'agit normalement de la plus volumineuse des bases de données NetWorker. Pour le dimensionnement du système de stockage, utilisez la formule suivante :

Taille du catalogue d'index = (n+(i*j))*c*160*1,5

où :

n = nombre de fichiers à sauvegarder

j = nombre de jours d'un cycle (période entre deux sauvegardes complètes)

i = modification des données incrémentielles par jour, en pourcentages

c = nombre de cycles en ligne (politique de rétention des index)

La moyenne statistique est de 160 octets par entrée dans le catalogue.

Multipliez par 1,5 pour tenir compte de la croissance et des erreurs.

Remarque : la base de données d'index peut être répartie sur plusieurs emplacements, et les emplacements sont déterminés pour chaque client, individuellement.

La Figure 9 à la page 49 illustre la dégradation globale des performances lorsque le disque sur lequel réside la base de données des médias NetWorker constitue un goulot d'étranglement. Le graphique de droite illustre le débit net d'écriture des données (saveset + index + données d'amorçage) et le graphique de gauche présente le débit d'écriture des savesets.

Figure 9 Dégradation du débit d'écriture du serveur NetWorker




CHAPITRE 3Paramètres de réglage

Doté de diverses fonctionnalités d’optimisation, le logiciel NetWorker permet de régler l’environnement de sauvegarde et d’optimiser les performances des processus de sauvegarde et de restauration.

Ce chapitre contient les sections suivantes :

◆ Optimisation du parallélisme NetWorker ................................................................ 52◆ Densité du système de fichiers............................................................................... 53◆ Optimisation des disques ...................................................................................... 55◆ Méthodes de réglage des performances du périphérique ....................................... 55◆ Périphériques réseau ............................................................................................. 57◆ Optimisation des réseaux ...................................................................................... 62

Paramètres de réglage 51

Paramètres de réglage

Optimisation du parallélisme NetWorker Cette section présente les bonnes pratiques générales appliquées pour régler le parallélisme du client, groupe et serveur.

parallélisme du serveur

L’attribut Parallélisme du serveur contrôle le nombre de flux de sauvegarde simultanément acceptés par le serveur. Plus le serveur accepte un grand nombre de flux de sauvegarde, plus les périphériques et disques clients peuvent s’exécuter rapidement. Les disques clients peuvent s’exécuter à la limite de leurs propres performances ou en fonction des limites de performance des connexions établies entre eux.

Le parallélisme du serveur ne contrôle pas le démarrage des tâches de sauvegarde, mais définit le nombre maximal de sessions qu’un serveur de sauvegarde peut accepter. La valeur de cet attribut doit être aussi élevée que possible sans surcharger le serveur de sauvegarde lui-même.

parallélisme du client

Pour configurer cet attribut de manière optimale, suivez les recommandations ci-après :

◆ Pour les clients standard, utilisez les valeurs de parallélisme les plus basses possibles ; vous obtiendrez ainsi le meilleur compromis entre débit et nombre de savesets.

◆ Pour le serveur de sauvegarde, utilisez en revanche la valeur de parallélisme la plus élevée possible ; cela évitera le report des sauvegardes d’index et garantira l’exécution adéquate des groupes.

Les reports de sauvegarde ont souvent lieu lorsque le parallélisme client du serveur NetWorker est défini sur une valeur trop basse. Pour optimiser les performances du client NetWorker, la meilleure solution consiste à supprimer le parallélisme client en définissant sa valeur sur 1 et à augmenter le parallélisme du serveur en tenant compte de la configuration matérielle du client et de la configuration des données.

Attribuer au serveur NetWorker une valeur de parallélisme suffisamment élevée est essentiel pour éviter que les sauvegardes d’index n’empiètent sur l’exécution des groupes.

Les valeurs de parallélisme client définies pour le client représentant le serveur NetWorker doivent respecter les consignes suivantes :

◆ Ces valeurs ne doivent jamais être définies sur 1.◆ Pour les environnements de petite taille (moins de 30 serveurs), les valeurs de

parallélisme doivent être définies sur 8 au minimum.◆ Pour les environnements de taille moyenne (entre 31 et 100 serveurs), les valeurs de

parallélisme doivent être définies sur 12 au minimum.◆ Pour les environnements de grande taille (plus de 100 serveurs), les valeurs de

parallélisme doivent être définies sur 16 au minimum.

Ces consignes reposent sur le principe que le serveur de sauvegarde est un serveur de sauvegarde dédié. Pour obtenir les meilleures performances possibles, veillez à ce que le serveur de sauvegarde soit toujours un serveur de sauvegarde dédié.



Parallélisme du groupe

Pour configurer cet attribut de manière optimale, suivez les recommandations ci-après :

◆ Créez des groupes de sauvegarde comportant un maximum de 50 clients avec le parallélisme de groupe activé. Les groupes de sauvegarde qui dépassent cette limite peuvent provoquer le démarrage simultané de nombreux processus et ainsi entraîner l’épuisement temporaire des ressources sur le système d’exploitation concerné.

◆ Espacez de quelques minutes le démarrage des groupes de sauvegarde pour réduire la charge pesant sur le système d’exploitation. Il est, par exemple, préférable d’avoir 4 groupes de sauvegarde de 50 clients chacun démarrant à 5 minutes d’intervalle plutôt qu’un seul groupe de sauvegarde comportant 200 clients.

multiplexage

L’attribut Sessions cibles permet de définir le nombre de flux de sauvegarde effectuant simultanément des opérations d’écriture sur un périphérique. Cette valeur ne correspondant pas une limite, le périphérique en question peut accepter un nombre de sessions supérieur à celui spécifié par l’attribut. Plus le nombre de sessions cibles spécifié est élevé, plus le nombre de savesets qui peuvent être multiplexés (ou entrelacés) sur le même volume est important.

La section « Nombre de sessions cible et nombre maximal de sessions de périphérique AFTD », page 60 contient de plus amples informations sur le nombre de sessions cibles que peut accepter un périphérique.

Les tests et l’évaluation des performances peuvent aider à déterminer si le recours au multiplexage est ou non adapté au système. Suivez les recommandations ci-dessous lorsque vous évaluez l’utilisation du multiplexage<:hs>:

◆ Identifiez la vitesse maximale de chaque périphérique. Pour ce faire, utilisez le test bigasm présenté à la section « Directive bigasm », page 76.

◆ Identifiez la vitesse de sauvegarde de chacun des disques présents sur le client. Pour ce faire, utilisez le test uasm présenté à la section « Directive uasm », page 76.

Si la somme des vitesses de sauvegarde de tous les disques est supérieure à la vitesse maximale du périphérique, n’augmentez pas le parallélisme du serveur. Multiplexer, dans un tel cas, un plus grand nombre de groupes de sauvegarde ne permet pas d’améliorer les performances de sauvegarde et risque au contraire de dégrader les performances de restauration.

Densité du système de fichiersLa densité du système de fichiers a un impact direct sur le débit des opérations de sauvegarde. La durée des opérations de sauvegarde du logiciel NetWorker dépend largement de la densité du système de fichiers, en particulier lorsque des fichiers de petite taille sont présents en très grand nombre. Si le système de fichiers présente une densité élevée, les performances du logiciel NetWorker dépendent du temps de latence des disques, du type de système de fichiers et du nombre de fichiers figurant dans le saveset.La Figure 10 à la page 54 illustre l’impact que la densité du système de fichiers peut avoir sur le débit des opérations de sauvegarde.

Densité du système de fichiers 53


Figure 10 Comparaison entre nombre de fichiers et débit



Optimisation des disquesLa version 8.0 du logiciel NetWorker présente une nouvelle fonctionnalité qui permet d’optimiser les opérations de lecture des données d’un client pendant les sauvegardes standard du système de fichiers.

NetWorker 7.6 et ses versions antérieures utilisent des blocs d’une taille fixe de 64 Ko pour lire les fichiers depuis un client. NetWorker 8.0 utilise en revanche un algorithme intelligent qui sélectionne, en fonction des performances de lecture du système du client, une taille de bloc comprise entre 64 Ko et 8 Mo. Cette sélection dynamique, qui intervient pendant le transfert effectif des données, n’ajoute pas de temps système aux processus de sauvegarde et peut au contraire augmenter sensiblement les performances de lecture des données sur les disques.

Remarque : la taille des blocs de lecture est indépendante de la taille des blocs utilisée sur les périphériques à l’occasion des sauvegardes, laquelle n’est pas modifiée.

Totalement invisible des autres processus de sauvegarde, cette nouvelle fonctionnalité ne requiert aucune configuration supplémentaire, quelle qu’elle soit.

Vous pouvez remplacer ce paramètre dynamique en attribuant à la variable d’environnement NSR_READ_SIZE la valeur de votre choix. À titre d’exemple, si vous définissez la variable NSR_READ_SIZE sur 65536, le logiciel NetWorker sera contraint d’utiliser, pour les opérations de lecture, une taille de bloc de 64 Ko.

Méthodes de réglage des performances du périphériqueLes sections qui suivent abordent des domaines spécifiques aux périphériques qui permettent d’en améliorer les performances.

Vitesse de transfert d’entrée/sortie

Les vitesses de transfert d’entrée/sortie (E/S) peuvent affecter les performances des périphériques. Ces vitesses correspondent aux vitesses auxquelles les données sont écrites sur les périphériques. En fonction de la technologie de périphérique et de média déployée, les vitesses de transfert des périphériques peuvent aller de 500 Ko/s à 200 Mo/s. Ces vitesses de transfert sont également affectées par les tailles de bloc et de mémoire tampon utilisées par défaut sur les périphériques. Si les limites d’E/S nuisent aux performances du serveur EMC NetWorker, tentez d’obtenir une meilleure vitesse de transfert en mettant à niveau les périphériques.

Compression intégrée

Pour augmenter le débit effectif des périphériques, activez leur compression. Certains périphériques ont une fonction de compression intégrée. Selon le degré de compressibilité des données de sauvegarde, cela peut améliorer le débit de données effectif, d’un rapport de 1,5:1 à 3:1.

Optimisation des disques 55


Diffusion en continu (streaming) sur le lecteur

Pour optimiser les performances de la plupart des périphériques, activez le streaming des lecteurs en utilisant le débit maximum supporté. En l’absence de streaming, les lecteurs doivent s’arrêter et patienter jusqu’à ce que leur mémoire tampon soit de nouveau remplie ou repositionner les médias avant de pouvoir reprendre leurs activités d’écriture. Cela peut provoquer un retard dans le temps de cycle d’un lecteur, selon le type de périphérique.

Équilibrage de la charge de périphérique

Répartissez les charges de données des sessions simultanées de manière plus égale entre les périphériques disponibles en ajustant leurs paramètres respectifs de sessions cibles et de sessions max. Ce paramètre spécifie le nombre minimal de sessions de sauvegarde à créer avant que le serveur EMC NetWorker tente d’allouer des sessions de sauvegarde à un autre périphérique. Pour de plus amples informations sur les paramètres de sessions cibles et maximum, reportez-vous à la section « Nombre de sessions cible et nombre maximal de sessions de périphérique AFTD », page 60.

Fragmentation des lecteurs de disque

Sur les clients Windows, la fragmentation du système de fichiers, selon son niveau d’importance, peut altérer les performances de manière considérable. Pour garantir des performances optimales lors de la sauvegarde du système de fichiers :

1. Vérifiez les performances du système de fichiers sur le client en procédant à une opération de copie ou à une opération FTP sans utiliser NetWorker. Vous pourrez ainsi déterminer si la fragmentation des disques est en cause.

2. Pour consolider les données et permettre aux disques de mieux fonctionner, exécutez l’outil Défragmenteur de disque des clients :

a. Pour ce faire, cliquez sur Défragmenteur de disque.

b. Sous l’onglet État actuel, sélectionnez le disque à défragmenter.

c. Cliquez ensuite sur Analyser le disque pour vérifier que la fragmentation est bel et bien à l’origine du problème. Si une invite s’affiche vous demandant de saisir le mot de passe de l’administrateur ou de confirmer l’opération, saisissez ce mot de passe ou confirmez l’opération.

d. Une fois l’analyse du disque terminée par Windows, vérifiez le pourcentage de fragmentation dans la colonne Dernière exécution. Si ce pourcentage dépasse 10 %, procédez à la défragmentation du disque.

e. Cliquez sur Défragmenter le disque. Si une invite s’affiche vous demandant de saisir le mot de passe de l’administrateur ou de confirmer l’opération, saisissez ce mot de passe ou confirmez l’opération.

Le processus de défragmentation peut durer quelques minutes ou au contraire prendre quelques heures : tout dépend de la taille et du degré de fragmentation du disque dur. Pendant le processus de défragmentation, vous pouvez continuer d'utiliser l’ordinateur.



Périphériques réseauSi vous sauvegardez des données de clients distants, les routeurs, câbles de réseau et cartes réseau affectent les opérations de sauvegarde et de restauration. La section qui suit dresse la liste des variables susceptibles d'affecter les performances des dispositifs matériels réseau, et suggère quelques réglages de base. Les éléments suivants sont liés à des problèmes de réseau spécifiques<:hs>:

◆ Bande passante d’E/S réseau :

La vitesse maximale de transfert des données sur un réseau approche rarement la spécification du fabricant en raison du temps système supplémentaire engendré par le protocole réseau.

Remarque : l’affirmation suivante concernant le dimensionnement de l’ensemble du système doit être prise en compte lors du traitement de la bande passante réseau.

Chaque lecteur de bande rattaché (AFTD ou VTL physique) utilise de la bande passante d’E/S et consomme des ressources CPU ; le traitement en continu des données étant nécessaire.

◆ Chemin de réseau :

Les composants réseau, tels que routeurs, passerelles et hubs, consomment également de la bande passante et nuisent donc à ses performances en termes de débit.

◆ Charge réseau :

• Ne rattachez pas un trop grand nombre de cartes réseau rapides directement au serveur NetWorker, chaque adresse IP consommant des quantités significatives de ressources CPU. Par exemple, un système de taille moyenne équipé de quatre cartes réseau de 1 Go utilise plus de 50 % de ses ressources pour traiter des données TCP au cours d’une opération de sauvegarde.

• Les autres sources de trafic réseau limitent la bande passante que le serveur EMC NetWorker peut utiliser et détériorent les performances de sauvegarde. Lorsque la charge de réseau atteint un seuil de saturation, les collisions entre les paquets de données dégradent davantage encore les performances.

• Le service nsrmmdbd est très gourmand en ressources CPU lorsque des milliers de savesets sont traités en une seule opération. Par conséquent, les opérations de clonage comportant des savesets très volumineux et les activités de maintenance NetWorker doivent être exécutées en dehors de la fenêtre de sauvegarde principale.

Temps de latence Fibre Channel

Pour limiter les répercussions des temps de latence de liaison sur les performances, augmentez la taille du bloc de volume NetWorker.

Cette augmentation permet aux données d’affluer en continu vers les périphériques sans nécessiter de fréquents accusés de réception aller-retour.

Pour les liaisons présentant un faible temps de latence, une telle augmentation est en revanche sans effet.

Périphériques réseau 57


Si, pour les liaisons présentant un temps de latence élevé, l’impact de cette augmentation est important, celle-ci ne permet toutefois pas d’atteindre le même niveau de performances que celui offert par les liaisons locales.

Remarque : Lorsque le ralentissement des données est dû à des temps de latence élevés, une bande passante plus importante n’améliore pas directement les performances.

Le Tableau 6 à la page 58 compare les performances de sauvegarde en fonction des différentes tailles de bloc utilisées sur un lecteur de bande physique LTO-4 connecté localement via une liaison DWDM de 8 Gbits sur une distance de 15 km.

La Figure 11 à la page 58 montre que le débit de sauvegarde du logiciel NetWorker chute de 100 à 0 % lorsque le retard dû aux temps de latence passe de 0,001 ms à 2 ms.

Figure 11 Répercussions des temps de latence Fibre Channel sur le débit des données

DataDomain

Les sauvegardes vers le stockage Data Domain peuvent être configurées à l’aide de différentes technologies :

◆ NetWorker version 8.1 ou supérieure prend en charge DDBoost over Fibre Channel. Cette fonction tire parti du protocole Boost dans une infrastructure SAN. Elle offre les avantages suivants :

Tableau 6 Répercussions des différentes tailles de bloc d’un lecteur de bande LTO-4 sur les performances

Taille de blocPerformances de sauvegarde locale

Performances de sauvegarde distante

64 Ko 173 Mo/s 60 Mo/s

128 Ko 173 Mo/s 95 Mo/s

256 Ko 173 Mo/s 125 Mo/s

512 Ko 173 Mo/s 130 Mo/s

1 024 Ko 173 Mo/s 130 Mo/s



• La sauvegarde DDBoost over Fibre Channel (DFC) avec Client Direct est de 20 à 25 % plus rapide que celle réalisée avec DD VTL.

• La sauvegarde complète suivante est 3 fois plus rapide que la première sauvegarde complète.

• La restauration via DFC est 2,5 fois plus rapide que la restauration à l’aide de DD VTL.

◆ Sauvegarde sur VTL :

Les périphériques NetWorker sont configurés comme des unités de bande et le transfert des données s’effectue via une liaison Fibre Channel.

Pour de plus amples informations sur les modalités d’optimisation des sauvegardes sur VTL, reportez-vous à la section « Comparaison entre nombre de lecteurs virtuels et nombre de lecteurs physiques », page 61.

◆ Sauvegarde sur AFTD via système CIFS ou NFS :

• Le débit global du réseau dépend des performances des systèmes CIFS et NFS, lesquelles dépendent à leur tour de la configuration réseau.

Pour de plus amples informations sur les bonnes pratiques à suivre en matière de sauvegarde sur AFTD via système CIFS ou NFS, reportez-vous à la section « Optimisation des réseaux », page 62.

• Le manque d’efficacité au niveau du transport sous-jacent limite les performances de sauvegarde à 70-80 % de la vitesse des liaisons. Pour obtenir des performances optimales, vous devez utiliser NetWorker 7.5 Service Pack 2 ou une version supérieure.

◆ Attribut Client Direct permettant l’accès direct aux fichiers (DFA), introduit sur NetWorker 8.0 :

• Les sauvegardes Client Direct vers le stockage Data Domain (DD) à l’aide de la commande Boost offrent des performances bien supérieures aux sauvegardes DFA-AFTD via système CIFS/NFS.

• Lorsque l’attribut Client Direct (DFA-DD/DFA-AFTD) est activé, les performances de sauvegarde sont de 20 à 60 % supérieures à celles des sauvegardes traditionnelles effectuées à l’aide de la commande mmd.

• Lorsque le nombre de flux vers un même périphérique augmente, DFA gère les flux de sauvegarde beaucoup plus efficacement que la commande mmd.

◆ Sauvegarde sur Data Domain à l’aide d’un type de périphérique natif :

• NetWorker 7.6 Service Pack 1 propose un nouveau type de périphérique qui prend spécifiquement en charge les communications natives acheminées, via des liaisons TCP/IP, vers le stockage Data Domain.

• Lorsque le réseau est configuré de manière optimale, ce protocole de transport peut utiliser jusqu’à 95 % de la vitesse des liaisons et ce même lorsque cette vitesse atteint 10 Gbit/s. Ce protocole de transport est actuellement le plus efficace.



• Sur NetWorker 7.6.1, chaque périphérique Data Domain configuré peut prendre en charge un maximum de 10 flux de sauvegarde en parallèle. Si vous avez besoin d’une valeur de parallélisme plus élevée, définissez autant de périphériques que la limite de l’édition du serveur NetWorker utilisée le permet.

• Si vous utilisez NetWorker 7.6.2 ou l’une de ses versions supérieures, limitez le nombre de sessions par périphérique à 60.

Indépendamment de la méthode de sauvegarde utilisée sur le stockage Data Domain, le cumul des performances est limité par le débit maximum en entrée du modèle Data Domain utilisé.

◆ Lorsque le nombre total de flux acceptés par chaque périphérique est défini sur 10, l’espace mémoire minimum requis s’élève environ à 160 Mo pour un périphérique NetWorker DataDomain-OST. Chaque flux OST avec commande BOOST nécessite 16 Mo d’espace mémoire supplémentaire.

◆ Comparée aux sauvegardes dédupliquées non clientes effectuées dans un laps de temps beaucoup plus court, la commande DDBoost peut nécessiter de 2 à 40 % de temps CPU supplémentaire. La charge CPU globale des sauvegardes DD Boost est toutefois inférieure à celle générée par les sauvegardes mmd classiques effectuées à l’aide d’un système CIFS/NFS.

Nombre de sessions cible et nombre maximal de sessions de périphérique AFTD

Cette section décrit, pour tous les systèmes d'exploitation, les paramètres facultatifs de sessions cible et max de périphérique AFTD du logiciel NetWorker. Des informations pour les logiciels NetWorker versions 7.6 et antérieures et 7.6 Service Pack 1 et ultérieures sont incluses.

NetWorker 7.6 et versions antérieuresLes valeurs par défaut, respectivement 4 et 512, de NetWorker 7.6 et versions antérieures pour le nombre de sessions cibles et le nombre de sessions maximum ne sont pas optimales pour les performances AFTD.

Pour optimiser ces performances, vous devez modifier ces paramètres par défaut comme suit :

◆ Définissez le nombre de sessions cibles sur 1 au lieu de 4.◆ Définissez le nombre de sessions max. par périphérique sur 32 au lieu de 512 pour

éviter une sollicitation excessive des disques.

NetWorker 7.6 Service Pack 1 et versions ultérieuresLes valeurs par défaut des sessions cible et max. de périphérique AFTD sont désormais définies sur les valeurs optimales des performances de périphérique AFTD :

◆ Le nombre de sessions cibles est réglé sur 1.◆ Le nombre maximal de sessions est réglé sur 32 pour éviter l’emballement du disque.

Si nécessaire, ces deux attributs peuvent être modifiés pour prendre en compte les spécificités de l’environnement.



NetWorker 8.0 et versions supérieuresL’attribut Dynamic nsrmmd du noeud de stockage NSR est désactivé par défaut. Activer cet attribut permet d’activer le provisionnement dynamique nsrmmd.

Remarque : L’attribut Dynamic nsrmmd pour les périphériques AFTD et DD Boost est activé par défaut dans NetWorker 8.1. Dans les versions précédentes de NetWorker, cet attribut était désactivé par défaut.

Lorsque l’attribut de provisionnement nsrmmd dynamique est activé et que le nombre de sessions transmises à un périphérique dépasse le nombre de sessions cibles, plusieurs processus nsrmmd sont générés sur le périphérique en question. Cette multiplication se poursuit jusqu’à ce que le nombre de processus nsrmmd max. ou le nombre de sessions max. soit atteint, la valeur la plus basse des deux attributs prévalant.

Pour activer la sauvegarde sur disque et définir ces deux attributs comme requis, sélectionnez l’onglet Configuration :

◆ L’attribut de sessions cibles définit le nombre total de sessions gérées par un périphérique avant qu’un autre périphérique (disponible) ne prenne le relais. Pour des performances optimales, cet attribut doit être défini sur une valeur peu élevée. Les valeurs par défaut sont 4 pour les périphériques FTD/AFTD et 6 pour les périphériques DD Boost. La valeur maximale ne doit pas dépasser 60.

◆ Les valeurs par défaut de l’attribut de sessions max. sont 32 pour les périphériques FTD/AFTD et 60 pour les périphériques DD Boost. Ces deux valeurs offrent dans la plupart des cas des performances optimales. Cet attribut ne peut pas être défini sur une valeur supérieure à 60.

◆ Le nombre de processus nsrmmd max. est un paramètre avancé qui limite le nombre de processus de sauvegarde que le noeud de stockage peut exécuter en simultané, permettant ainsi d’augmenter le débit des données. Lorsque les attributs de sessions cibles ou de sessions max. sont modifiés, le nombre de processus nsrmmd max. est automatiquement ajusté en conséquence à l’aide de la formule sessions max./sessions cibles + 4. Les valeurs par défaut de ce paramètre avancé sont 12 pour les périphériques FTD/AFTD et 14 pour les périphériques DD Boost.

Remarque : il est déconseillé de modifier simultanément les deux attributs de sessions de même que le nombre de processus nsrmmd max. Si vous avez toutefois besoin de modifier cette dernière valeur, redéfinissez d’abord les valeurs des deux attributs de sessions. Elle est alors automatiquement mise à jour.

Comparaison entre nombre de lecteurs virtuels et nombre de lecteurs physiques

Les données qui suivent s’appuient sur une utilisation à 70 % d’un port Fibre Channel :

◆ Sauvegarde sur LTO-3 : 3 périphériques virtuels pour chaque lot de deux périphériques physiques envisagés.

◆ Sauvegarde sur LTO-4 : 3 périphériques virtuels pour chaque périphérique physique envisagé.



Les performances de chacun de ces lecteurs de bande rattaché au port diminuent à chaque périphérique. Par exemple :

◆ Si le premier lecteur virtuel atteint la limite de 150 Mo/s,

◆ le deuxième lecteur virtuel ne pourra pas dépasser 100 Mo/s et

◆ le troisième ne pourra pas dépasser 70 Mo/s.

Optimisation des réseauxLa section qui suit aborde les points suivants :

◆ « Optimisation de la configuration avancée », page 62

◆ « Optimisation de la pile TCP du système d’exploitation », page 63

◆ « Réglage avancé », page 63

◆ « Débits de carte réseau escomptés », page 63

◆ « Temps de latence réseau », page 64

◆ « Modes Duplex des liaisons Ethernet », page 65

◆ « Pare-feu », page 65

◆ « Trames Jumbo », page 66

◆ « Notification de congestion », page 66

◆ « Mémoires tampons TCP/IP », page 67

◆ « Augmentation de la taille de tampon du reliquat TCP », page 68

◆ « Taille de mémoire tampon des sockets NetWorker », page 68

◆ « Équilibrage IRQ et affinité CPU », page 69

◆ « Modération des interruptions », page 70

◆ « Déchargement TCP », page 70

◆ « Résolution de noms », page 71

Optimisation de la configuration avancée

Annexe B : Prise en charge de la protection pare-feu du Guide d’Administration de NetWorker version 8.1 (ou supérieure) contient des instructions sur les options de configuration avancée telles que les systèmes à hébergement multiple, le trunking, etc.

Les paramètres par défaut TCP du système d’exploitation sont définis pour garantir une compatibilité optimale avec les anciennes infrastructures réseau, mais pas pour garantir des performances optimales en matière de sauvegarde.



Optimisation de la pile TCP du système d’exploitation

Les règles les plus courantes à appliquer pour optimiser la pile TCP du système d’exploitation, tous scénarios d’utilisation confondus, sont énoncées ci-après :

◆ Désactivez le contrôle du flux logiciel.◆ Augmentez la taille de la mémoire tampon TCP.◆ Augmentez la longueur de la file d’attente TCP.◆ Utilisez PCIeXpress pour les cartes réseaux 10 Go. La bande passante offerte par les

autres architectures E/S n’est en effet pas suffisante.

Pour de plus amples informations sur PCIeExpress, reportez à la section « Considérations relatives à PCI-X et PCIeXpress : », page 19.

Les règles à appliquer en fonction des capacités spécifiques de l’environnement sont répertoriées ci-après :

◆ Certains systèmes d’exploitation sont dotés en interne d’une fonction d’ajustement automatique de la pile TCP. Si cette fonction permet d’obtenir de bons résultats dans les environnements homogènes, ce n’est pas le cas dans les environnements hétérogènes ou routés. Désactivez par conséquent cette fonction pour ce type d’environnement.

◆ Activez les trames Jumbo lorsque possible. Pour de plus amples informations sur les trames Jumbo, reportez-vous à la section « Trames Jumbo », page 66.

Remarque : tous les composants réseau du chemin de données doivent être capables de gérer les trames Jumbo. Si ce n'est pas le cas, n’activez pas les trames Jumbo.

◆ Lorsqu’il fonctionne correctement, le déchargement matériel TCP peut être avantageux. Il peut toutefois provoquer des correspondances CRC erronées. Si vous choisissez d’activer ce paramètre, faites attention aux éventuelles erreurs.

◆ À condition d’être pris en charge par tous les équipements réseau de la chaîne, l’ajustement dynamique des fenêtres TCP peut être avantageux.

◆ L’envoi de notification en cas de congestion TCP peut être source de problèmes. Activez uniquement cette option dans les environnements à système d’exploitation unique.

Réglage avancé

Le traitement IRQ pour cartes réseau haute vitesse coûte très cher, mais permet d’améliorer les performances grâce à la sélection de coeurs CPU spécifiques. Les recommandations à suivre dépendent de l’architecture CPU.

Débits de carte réseau escomptésLes débits les plus courants de carte réseau se trouvent dans les plages de valeurs suivantes :

◆ Liaison 100 Mbit = de 6 à 8 Mo/s◆ Liaison 1 Gbit = de 45 à 65 Mo/s◆ Liaison 10 Gbit = de 150 à 350 Mo/s

Optimisation des réseaux 63


En utilisant des valeurs optimisées, le débit des liaisons haute vitesse peut atteindre les niveaux suivants :

◆ Liaison 100 Mbit = 12 Mo/s◆ Liaison 1 Gbit = 110 Mo/s◆ Liaison 10 Gbit = 1 100 Mo/sUne liaison Ethernet 10 Gbit peut atteindre en théorie un débit de 1,164 Go/s par direction. Cette valeur est obtenue en convertissant les bits en octets et en éliminant les temps système supplémentaires minimum générés par TCP, IP et Ethernet.

Temps de latence réseau

Une augmentation des temps de latence TCP impacte négativement le débit global du réseau, indépendamment de la quantité de bande passante offerte par la liaison. Des distances accrues ou davantage de hops entre les hôtes réseau peuvent également provoquer une baisse du débit global.

Les temps de latence réseau influent très fortement sur l’efficacité de la bande passante.

Les Figure 12 à la page 64 et Figure 13 à la page 65 illustrent, par exemple, les débits de sauvegarde enregistrés sur une même liaison réseau en fonction de différents temps de latence.

Notez que dans le cadre de ces exemples, des paramètres TCP non optimisés ont été utilisés.

Figure 12 Temps de latence réseau sur une liaison 10/100 Mo/s



Figure 13 Temps de latence réseau sur une liaison 1 Go/s

Modes Duplex des liaisons Ethernet

Les liaisons réseau qui s’exécutent en mode semi-duplex provoquent un ralentissement du trafic NetWorker. Sur une liaison 100 Mbit en mode semi-duplex, par exemple, les performances de sauvegarde sont inférieures à 1 Mo/s.

En matière de modes Duplex, les systèmes d’exploitation sont pour la plupart, et ainsi que recommandé par la norme IEEE802.3, définis par défaut sur l’autonégociation. Ce paramètre requiert toutefois le respect des conditions suivantes :

◆ Câblage adapté ◆ Adaptateur de carte réseau compatible ◆ Switch compatible

L’activation de l’autonégociation peut provoquer l’exécution de la liaison en mode semi-duplex.

Pour éviter la survenue de tels problèmes, forcez l’activation du mode Full duplex sur la carte réseau. Ce mode doit être activé de part et d’autre de la liaison. L’activation forcée d’un seul côté uniquement provoque l’échec de l’autonégociation de l’autre côté de la liaison.

Pare-feu

La couche supplémentaire sur le chemin d’E/S d’un pare-feu matériel accroît les temps de latence réseau et diminue l’utilisation globale de la bande passante.

Utiliser un pare-feu logiciel sur le serveur de sauvegarde est déconseillé. Le serveur traite en effet un grand nombre de paquets et l’utilisation d’un tel pare-feu augmenterait de manière sensible les temps système.

De plus amples informations sur la configuration des pare-feu et leurs répercussions sont disponibles dans l’Annexe B : Prise en charge de la protection pare-feu du Guide d’Administration de NetWorker version 8.1 (ou supérieure).



Trames Jumbo

Dans les environnements capables de les gérer, il est conseillé d'utiliser des trames Jumbo. Si la source, les ordinateurs et tous les équipements se trouvant sur le chemin des données sont en mesure de traiter les trames Jumbo, augmentez la MTU en la redéfinissant sur 9 Ko.

Les exemples ci-après se rapportent à des systèmes d’exploitation Linux et Solaris :

◆ Linux : ifconfig eth0 mtu 9000 up

◆ Solaris : Pour configurer les trames Jumbo sur un périphérique nxge, utilisez la commande suivante :

ndd -set /dev/nxge<#> accept-jumbo 1

Remplacez <#> par le numéro d’instance du pilote.

Remarque : pour identifier le numéro d’instance d’un périphérique suivant, exécutez la commande nxge /etc /path_to_inst.

Notification de congestion

La section qui suit explique les modalités à suivre pour désactiver les algorithmes de notification de congestion.

◆ Windows 2008 R2 uniquement :

1. Désactivez les algorithmes facultatifs de notification de congestion :

C:\> netsh interface tcp set global ecncapability=disabled

2. L’algorithme TCP avancé offre les meilleurs résultats sous Windows. Si les deux côtés de la conversion réseau ne sont toutefois pas en mesure de traiter la négociation, désactivez cet algorithme :

C:\> netsh interface tcp set global congestionprovider=ctcp

◆ Linux :

1. Vérifiez la présence d’algorithmes non standard :

cat /proc/sys/net/ipv4/tcp_available_congestion_control

2. Désactivez ECN :

echo 0 >/proc/sys/net/ipv4/tcp_ecn

◆ Solaris :

Désactivez la fusion TCP, si présente :

set ip:do_tcp_fusion = 0x0



Mémoires tampons TCP/IP

Pour les cartes réseau haute vitesse, augmentez la taille des mémoires tampons d’envoi/de réception TCP :

◆ Linux :

Pour modifier les paramètres de mémoire tampon TCP sur Linux, ajoutez les paramètres suivants au fichier /etc/sysctl.conf, puis exécutez la commande /sbin/sysctl -p :

net.core.rmem_default = 262144net.core.wmem_default = 262144net.core.rmem_max = 16777216net.core.wmem_max = 16777216net.ipv4.tcp_rmem = 8192 524288 16777216net.ipv4.tcp_wmem = 8192 524288 16777216

Définissez la valeur RPC recommandée :

sunrpc.tcp_slot_table_entries = 64

L’autre solution consiste à activer l’ajustement dynamique des fenêtres TCP. Les équipements présents sur le chemin des données doivent être compatibles :

sysctl -w net.ipv4.tcp_window_scaling=1

◆ Solaris :

tcp_max_buf 10485760 tcp_cwnd_max 10485760 tcp_recv_hiwat 65536 tcp_xmit_hiwat 65536

◆ AIX

Modifiez les valeurs des paramètres dans /etc/rc.net si les valeurs définies sont inférieures à celles recommandées. Nombre d’octets qu’un système peut placer dans la mémoire tampon du noyau, sur la file d’attente de réception des sockets :

no -o tcp_recvspace=524288

Nombre d’octets qu’une application peut placer dans la mémoire tampon du noyau avant blocage de l’application à réception d’appel d’envoi :

no -o tcp_sendspace=524288

◆ Windows :

• Les tailles de mémoire tampon utilisées par défaut sous Windows sont suffisantes :

• Définissez l’entrée du registre comme suit :

AdditionalCriticalWorkerThreads: DWORD=10

• Si les pilotes de carte réseau peuvent créer plusieurs mémoires tampons ou files d’attente, définissez les paramètres correspondants au niveau même de ces pilotes. À titre d’exemple, le paramètre de files d’attente RSS des pilotes de carte réseau 10 Gbit Intel est défini par défaut sur 2. Or, la valeur recommandée pour obtenir des performances optimales est de 16.



• Windows 2008 Server est doté d’une nouvelle fonction qui permet de régler automatiquement la pile TCP. Si un serveur sur le réseau LAN ou un périphérique réseau dans la zone de données, par exemple un routeur ou un switch ne prennent pas en charge l’ajustement dynamique des fenêtres TCP, les opérations de sauvegarde peuvent échouer. Pour éviter ce problème et permettre le fonctionnement optimal des opérations NetWorker, appliquez Microsoft Hotfix KB958015 à Windows 2008 Server, puis définissez le réglage automatique sur le niveau très restreint :

1. Vérifiez les paramètres TCP actuels :

C:\> netsh interface tcp show global

2. Si nécessaire, limitez le niveau de réglage automatique pour l’ajustement dynamique, côté réception, des fenêtres TCP :

C:\> netsh interface tcp set global autotuninglevel=highlyrestricted

Remarque : si le hot fix KB958015 n’est pas appliqué, le paramètre de réglage automatique doit être désactivé plutôt que défini sur un niveau très restreint.

Augmentation de la taille de tampon du reliquat TCP

Pour augmenter la taille de tampon de reliquat TCP, définissez la file d’attente de backlog de connexion sur la valeur maximale autorisée :

net.ipv4.tcp_max_syn_backlog = 8192net.core.netdev_max_backlog = 8192

Par défaut, la valeur net.core.somaxconn est définie sur 128. Augmentez considérablement cette valeur pour prendre en charge les pics de demandes. Par exemple, pour prendre en charge un pic de 1 024 demandes, définissez net.core.somaxconn sur 1 024 :

net.core.somaxconn = 1024

Taille de mémoire tampon des sockets NetWorker

Pour forcer l’utilisation de fenêtres d’envoi/de réception TCP plus grandes sur NetWorker 7.6.x et versions antérieures, insérez ces éléments dans le script de démarrage NetWorker :

NSR_SOCK_BUF_SIZE=65536export NSR_SOCK_BUF_SIZE

◆ Pour une liaison 1 Go, la taille optimale de la mémoire tampon pour les sockets TCP est 64 Ko.

◆ Pour une liaison 10 Go, la taille optimale de la mémoire tampon pour les sockets TCP s’élève à 256 Ko. Intégrez ces éléments dans le script de démarrage de NetWorker :

NSR_SOCK_BUF_SIZE=262144



Remarque : définir la taille de la mémoire tampon des sockets NetWorker n’est plus obligatoire sur NetWorker 8.0 et ses versions supérieures. Déployé dans le logiciel, ce paramètre est configuré pour utiliser une taille de mémoire tampon de socket de 256 Ko.

Équilibrage IRQ et affinité CPU

Une carte réseau haute vitesse qui utilise plusieurs connexions 1 Gbit ou une seule connexion 10 Gbit profite de la désactivation de l’équilibrage IRQ et du traitement par un coeur CPU spécifique.

Remarque : la règle générale veut qu’un seul coeur par CPU physique traite les interruptions de carte réseau. Utilisez plusieurs coeurs par CPU uniquement si le nombre des cartes réseau dépasse celui des CPU. Notez toutefois que la transmission et réception doivent toujours être traitées, sans exception, par le même CPU.

Les exemples ci-après se rapportent à des systèmes d’exploitation Linux et Solaris :

◆ Linux :

1. Désactivez l’équilibrage IRQ et définissez l’affinité CPU manuellement :

service irqbalance stopchkconfig irqbalance off

2. Réglez l’affinité CPU pour la carte réseau eth0 :

grep eth0 /proc/interrupts

3. Réglez l’affinité SMP de la valeur la plus élevée à la valeur la plus basse. Par exemple :

echo 80 > /proc/irq/177/smp_affinityecho 40 > /proc/irq/166/smp_affinity

L’affinité SMP est uniquement disponible sur les pilotes de périphérique compatibles avec la fonction IO-APIC. Pour savoir si un périphérique est doté de la fonction IO-APIC, utilisez la commande cat /proc/interrupts ou consultez la documentation fournie avec ce périphérique.

◆ Solaris :

Interrompez un seul coeur par CPU. Par exemple, pour un système doté de 4 CPU et de 4 coeurs par CPU, utilisez la commande suivante :

psradm -i 1-3 5-7 9-11 13-15

Les autres réglages à effectuer dépendent de l’architecture système utilisée.

Les exemples ci-après correspondent à des paramètres qui permettent d’obtenir de bons résultats sur un système Solaris doté d’un CPU T1/T2 :

ddi_msix_alloc_limit 8 tcp_squeue_wput 1 ip_soft_rings_cnt 64 ip_squeue_fanout 1



Pour réduire les pics d’utilisation du CPU, certains pilotes de carte réseau limitent de manière artificielle les taux d’interruption. Cette limite artificielle restreint toutefois également le débit maximum qu’il est possible d’obtenir. Pour obtenir un débit réseau optimal, désactivez ce paramètre de modération des interruptions sur les pilotes de carte réseau sur lesquels il est activé.

Modération des interruptions

Pour les liaisons 10 Go s’exécutant sous Windows, il est conseillé de désactiver la modération des interruptions de l’adaptateur réseau en vue d’améliorer les performances du réseau.

Déchargement TCP

Pour les cartes réseau capables de gérer les paquets TCP à un niveau inférieur, activez le déchargement TCP sur le système d’exploitation. Cette activation :

◆ augmentera l’utilisation de la bande passante globale ;◆ diminuera la charge CPU du système.

Remarque : toutes les cartes réseau se vantant d’offrir une fonctionnalité de déchargement ne sont pas nécessairement entièrement conformes à la norme.

◆ Sous Windows 2008 Server, activez le déchargement TCP à l’aide de la commande suivante :

C:\> netsh interface tcp set global chimney=enabled

◆ Sous Windows 2008 R2 Server, activez le déchargement TCP à l’aide des commandes suivantes et de propriétés supplémentaires :

C:\> netsh interface tcp set global dca=enabledC:\> netsh interface tcp set global netdma=enabled

◆ Désactivez le déchargement TCP pour les anciennes cartes réseau qui provoquent la mise en suspens ou l’échec des sessions de sauvegarde et génèrent des erreurs RPC ou de réinitialisation de la connexion (CRC) proches du message suivant :

Connection reset by peer

Remarque : Lorsqu’il fonctionne correctement, le déchargement TCP peut être avantageux. Il peut toutefois provoquer des correspondances CRC erronées. Si vous choisissez d’activer ce paramètre, faites attention aux éventuelles erreurs.



Résolution de noms

Le serveur NetWorker compte fortement sur les fonctions de résolution de noms du système d’exploitation.

Définissez un accès au serveur DNS à faible temps de latence pour éviter les problèmes de performance via la configuration de l’un ou l’autre des paramètres suivants :

◆ Cache DNS local

ou

◆ Serveur local DNS ne faisant pas autorité avec transferts de zone depuis le serveur DNS principal

Assurez-vous que le nom du serveur et les noms d'hôtes attribués à chaque adresse IP du système sont définis dans le fichier des hôtes pour éviter les recherches DNS de tels noms.




CHAPITRE 4Test des performances

Ce chapitre explique comment tester et comprendre les goulots d'étranglement en utilisant les outils disponibles, dont les programmes NetWorker tels que bigasm et uasm. Ce chapitre propose les rubriques suivantes :

◆ Identification des symptômes ................................................................................. 74◆ Surveillance des performances ............................................................................... 74◆ Identification des goulots d'étranglement à l'aide d'un test FTP générique .............. 75◆ Test des performances de l'installation à l'aide d'une commande dd....................... 76◆ Test des performances du disque à l'aide des directives bigasm et uasm ................ 76

Test des performances 73

Test des performances

Identification des symptômesLes éléments permettant de déterminer la cause des faibles performances de la sauvegarde sont répertoriés ci-après :

◆ Les performances sont-elles régulières tout au long de l'opération de sauvegarde ?

◆ Les sauvegardes sont-elles plus performantes lorsqu'elles démarrent de manière échelonnée ?

◆ Sont-elles régulières pour tous les savesets des clients ?

◆ Sont-elles régulières pour tous les clients dotés d'une configuration système similaire utilisant un noeud de stockage spécifique ?

◆ Sont-elles régulières pour tous les clients dotés d'une configuration système similaire dans le même sous-réseau ?

◆ Sont-elles régulières pour tous les clients dotés d'une configuration système et d'applications similaires ?

Observez le fonctionnement du client avec différents paramètres. Une vitesse de sauvegarde irrégulière peut indiquer des problèmes au niveau du logiciel ou du microprogramme.

Pour chaque client NetWorker, répondez aux questions suivantes :

◆ Les performances sont-elles régulières tout au long de l'opération de sauvegarde ?

◆ Les performances évoluent-elles lorsque la sauvegarde est démarrée à un autre moment ?

◆ Sont-elles régulières pour tous les clients qui utilisent un noeud de stockage spécifique ?

◆ Sont-elles régulières pour tous les savesets d'un client ?

◆ Sont-elles régulières pour tous les clients du même sous-réseau ?

◆ Sont-elles régulières pour tous les clients dotés de systèmes d'exploitation, de service packs et d'applications similaires ?

◆ Les performances sont-elles améliorées ou dégradées pendant la sauvegarde ?

Ces questions, et d'autres similaires, peuvent vous aider à identifier des problèmes de performances spécifiques.

Surveillance des performancesSurveillez les performances des E/S, du disque, du CPU et du réseau à l'aide des outils de surveillance des performances natifs, tels que :

◆ Windows : Perfmon ◆ UNIX : commandes iostat, vmstat ou netstat

Une activité inhabituelle avant, pendant et après les sauvegardes peut indiquer une utilisation excessive des ressources par les périphériques.



En observant les performances sur une période donnée à l'aide des outils susmentionnés, vous pourrez clairement identifier les ressources consommées par chaque application, dont NetWorker.

S'il s'avère que les sauvegardes lentes sont dues à une utilisation excessive du réseau par d'autres applications, une modification du calendrier des sauvegardes peut permettre de régler le problème.

Une utilisation élevée du CPU est souvent due à une attente des E/S externes, et non à une puissance de CPU insuffisante. Cela est caractérisé par une utilisation élevée du CPU à l'intérieur du SYSTÈME, plutôt que dans l'espace utilisateur.

Sous Windows, si les appels de procédure différés monopolisent beaucoup de temps, cela indique généralement un problème au niveau des pilotes de périphériques.

Identification des goulots d'étranglement à l'aide d'un test FTP générique

Sans utiliser de composants NetWorker, déterminez si le goulot d'étranglement se situe au niveau du réseau ou de l'unité de bande à l'aide du test FTP générique suivant :

1. Créez un fichier de données volumineux sur le client NetWorker et envoyez-le vers le noeud de stockage via FTP.

2. Notez le temps nécessaire au transfert du fichier.

3. Comparez le temps noté à l'étape 2 avec les performances actuelles de la sauvegarde :

• Si le transfert via FTP s'effectue beaucoup plus rapidement que les sauvegardes, alors le goulot d'étranglement se situe probablement au niveau des unités de bande.

• Si le transfert via FTP s'effectue dans un délai similaire, alors le goulot d'étranglement se situe probablement au niveau du réseau.

4. Comparez les résultats en utilisant un transfert FTP actif contre un transfert FTP passif. Les performances d'une sauvegarde NetWorker sont considérablement altérées par les capacités du réseau sous-jacent et des paquets de réseau utilisés par le logiciel NetWorker.

Si la vitesse de transfert est très différente, ou si l'un des types de transfert FTP montre des pics de charge, cela peut indiquer la présence de composants réseau qui effectuent un réassemblage de paquets TCP. La liaison s'effectue alors en mode Semi-duplex, alors même que toutes les pièces physiques fonctionnent en mode Full duplex.

Remarque : n'utilisez pas de volumes locaux pour créer et transférer des fichiers pour les tests FTP, mais utilisez des volumes de sauvegarde.

Identification des goulots d'étranglement à l'aide d'un test FTP générique 75


Test des performances de l'installation à l'aide d'une commande dd

Sans utiliser de composants NetWorker, utilisez le test dd générique pour comparer le débit des périphériques à celui indiqué par le fabricant :

1. Créez un fichier de données volumineux sur le noeud de stockage et envoyez-le vers le périphérique cible à l'aide du test dd.

date; dd if=/tmp/5GBfile of=/dev/rmt/0cbn bs= 1MB; date

2. Notez le temps nécessaire au transfert du fichier, et comparez-le avec les performances actuelles des bandes.

Test des performances du disque à l'aide des directives bigasm et uasm

Les directives bigasm et uasm sont des tests basés sur NetWorker permettant de vérifier les performances.

Directive bigasm

La directive bigasm génère un fichier de taille spécifique et le transfère via un réseau ou une connexion SCSI. Le fichier est alors écrit sur une bande ou un autre périphérique cible. La directive bigasm crée un flux d'octets en mémoire et les sauvegarde sur le périphérique cible, éliminant ainsi l'accès au disque. Cela permet de tester la vitesse des clients NetWorker, du réseau et des unités de bande, tout en ignorant l'accès au disque.

Créez une directive bigasm pour générer un saveset très volumineux.

La directive bigasm ignore l'accès au disque pour tester les performances du client, du réseau et de la bande.

Directive uasm

La directive uasm lit les données sur le disque à la vitesse maximale afin d'identifier les goulots d'étranglement au niveau du disque. Par exemple :

uasm –s filename > NUL

La directive uasm teste les vitesses de lecture du disque, et peut identifier les goulots d'étranglement au niveau du disque en écrivant des données sur un périphérique fictif.


Documents

Guide de planification de l’optimisation des performances ......Guide de planification de l’optimisation des performances d’EMC NetWorker version 8.1 7 Préface Notes techniques