De ces exigences ont émergé des termes appelés Plan de Reprise d’Activité (PRA) ou de continuité d’activité (PCA) qui sont intimement associés aux notions de RTO (Recovery Time Objective) et RPO (Recovery Point Objective). La première notion correspond à un temps maximal pour reprendre l’activité tandis que la deuxième exprime le delta temps entre la perte maximale de données tolérée au moment du sinistre et au moment où l’activité redémarre, soit la perte de données maximale acceptable.

Bien entendu, la situation rêvée de n’importe quelle entreprise est d’avoir une valeur la plus proche possible du zéro pour le RTO et le RPO. Plus la valeur désirée est proche du zéro, plus les coûts associés seront élevés. En fonction des valeurs désirées, le schéma suivant vous indiquera les moyens à mettre en œuvre.

Il existe plusieurs sinistres comme par exemple la panne d’un serveur, d’un commutateur de stockage, d’une baie ou pire, d’un site complet. Il convient dès la conception de votre infrastructure de définir la disponibilité de vos données qui conditionneront directement le budget à consacrer : achat d’un serveur doté d’alimentations redondantes, double contrôleur pour une baie de stockage, licence de virtualisation permettant le déplacement à chaud d’une machine virtuelle, etc…

Seulement la redondance des éléments physiques d’un serveur ou d’une baie permettent uniquement une certaine continuité (PCA) malgré un sinistre mais ne permettent pas de se prémunir d’un virus ou d’une corruption de données.

Commencez par identifier les services qui nécessitent la mise en œuvre de tels moyens. Un serveur de développement n’est pas une application critique et il serait totalement marginal de protéger ce service au même titre qu’un ERP.

Une valeur RTO proche de zéro nous indique qu’une solution de cluster ou de basculement automatique à chaud de machines virtuelles est certainement en place. Si la valeur s’en éloigne, une stratégie de PRA est certainement mise en application (procédure de restauration d’une sauvegarde, de remise en production de serveurs, …)

Une valeur RPO proche de zéro nous indique que la perte de données n’est pas acceptable, et qu’il convient donc de répliquer les données de façon synchrone. Plus on s’eloigne de la valeur zéro, on imagine que l’entreprise a déployé une replication asynchrone (ordre de grandeur de 15 minutes par exemple) où une stratégie de sauvegarde lui correspondant qui peut s’exprimer en heures.

Grâce à des mécanismes RAID, de double alimentations, etc… les données sont sécurisées mais ne sont pas redondées ! En fonction des exigences, la réplication répond à des problématiques de redondance des données en maintenant l’accès à des données consistantes sur plusieurs sites, mais ne répond pas à des problématiques de corruption de données ! En effet, une corruption qui survient sur une base de données sera répliquée sur l’autre baie de stockage.

La réplication existe sous forme synchrone et asynchrone, la première forme nécessite des prérequis lourds mais permet d’obtenir un RTO et RPO proche de zéro du fait de la réplication en temps réel des donnés. En revanche, la réplication asynchrone permet d’obtenir un RTO / RPO variable en fonction des besoins, comme une reprise après sinistre par exemple.

Réplication synchrone

La réplication synchrone garantit une correspondance parfaite à tout moment des données répliquées entre la source et la cible. Néanmoins, elle exige un débit important et garanti car, contrairement à la réplication asynchrone, elle attend l’acquittement de l’écriture avant de rendre la main. Pour cette raison, des liens dédiés sont fortement recommandés. Par exemple, certains constructeurs recommandent au minimum une fibre de 8 Gb !

La réplication synchrone ne rend la main qu’après avoir validé l’acquittement d’une opération d’écriture. Ainsi, si votre liaison subit un engorgement ou est faible, la synchronisation impactera les performances du stockage de façon très importante, avec pour conséquences des TimeOut au niveau des serveurs, entre autres. C’est pour cette raison, que les distances entre les sites à répliquer ne sont pas aussi éloignés qu’ils peuvent l’être avec une réplication de type asynchrone.

La réplication synchrone étant coûteuse à déployer, il est possible de réfléchir à des scénarios permettant de mixer les différentes réplications et technologies de sécurisation des données.

Prenons l’exemple d’un serveur SQL dont le système est installé sur un volume A et les données sur un volume B. Le système d’exploitation n’étant mis à jour qu’assez rarement, il est envisageable de répliquer les données de façon synchrone et le système de façon asynchrone.

Des stratégies peuvent être mises en œuvre pour limiter au maximum la bande que pourrait consommer une réplication. Par exemple, pour une base de données Oracle, ne répliquer que les Redo Logs serait une solution.

Réplication asynchrone

La réplication asynchrone transmet les données à intervalle régulier en s’accommodant d’une bande passante faible et demeure la solution idéale pour mettre en œuvre un PRA (Plan de Reprise d’Activité) sur un site distant.

Contrairement à la réplication synchrone, celle-ci n’attends pas l’acquittement pour rendre la main. Ainsi, l’augmentation du trafic ou la chute du débit de la ligne de la réplication n’entraine pas une baisse des performances.

Ainsi, il est tout à fait imaginable d’utiliser des stockages de performances différentes: un ERP sur le site principal sera hébergé sur des disques de type SAS tandis que le site secondaire hébergera le réplica de l’ERP sur des disques SATA.

Réplication asynchrone « temps réel »

Ce type de réplication est disponible selon les constructeurs de stockage. Cette réplication bénéficie du faible besoin en bande passante et de ses éventuelles fluctuations mais garantit également l’intégrité des données répliquées entre la source et la cible. Ce type de réplication est le plus souvent propriétaire et ne repose pas sur des mécanismes de groupe de consistance (IBM, Net APP, …) ou de snapshot qui peuvent faire chuter les performances.

Pour résumer, cette réplication présente sur le papier les avantages des réplications synchrones et asynchrones, à savoir réplica quasi temps réel et la bande passante requise est faible.

La reprise après sinistre

La reprise après sinistre s’associe à la notion de PRA et de RTO, c’est-à-dire que l’on prend en compte le pire des scénarios, la perte complète d’une salle serveurs (on parle aussi de Disaster Recovery).

Typiquement, un PRA s’associe à une réplication asynchrone tandis qu’une réplication synchrone, donc continue, s’applique à un PCA car on continue à produire malgré la perte d’un élément important de l’infrastructure.

La reprise après sinistre n’engage pas que les services informatiques d’une entreprise mais l’ensemble des services. En effet, l’entreprise ayant prévu l’incendie d’un site, ce sont les moyens de productions (machines-outils par exemple) qui représente l’activité commerciale, mais également l’outil informatique qui sert à produire des factures, qui seraient totalement détruits.

Un PRA est un plan d’urgence résultant d’une réflexion globale de l’entreprise visant à reprendre au plus vite une activité de production commerciale.

Mettre en œuvre un PCA demeure beaucoup plus onéreux qu’un PRA qui peut se permettre de remettre en production le minimum vital pour une entreprise, tandis que le PCA exige une transparence totale pour les utilisateurs en cas de sinistre. Ainsi, un plan de continuité d’activité nécessite d’acquérir le même matériel sur l’ensemble des sites pour garantir une cohérence de productivité.

Une entreprise plus modeste mettra en œuvre un plan de reprise d’activité. Par exemple, une entreprise dispose de quatre serveurs : un serveur pour la production, un pour les archives, un pour la vidéosurveillance et un dernier pour le site internet vitrine. Si un sinistre survient, il sera nécessaire de remettre en production le plus rapidement possible le serveur de production afin de pouvoir continuer à livrer et donc facturer.

Des outils spécifiques tels VMware SRM (Site Recovery Manager) ou DoubleTake permettent de simplifier la mise en place d’un plan de reprise d’activité. Ils permettent de simplifier, d’automatiser le basculement des applications critiques vers un site de secours.

Hyper-V Replica est une des grosses nouveautés disponibles dans Hyper-V édition Windows Server 2012. Cette fonctionnalité est destinée à vous aider dans la mise en oeuvre d’un plan de reprise d’activité grâce à la réplication de machines virtuelles sur un environnement de secours.

Le schéma suivant illustre parfaitement un PCA sur deux sites. Ils sont strictement identiques, disposent de commutateurs redondants, de doubles contrôleurs au niveau du stockage, les données se répliquent de façon synchrone et la sauvegarde est externalisée sur l’un des sites. Le défaut majeur de cette architecture réside dans le fait qu’il n’existe qu’une seule baie de stockage pouvant mettre à mal la continuité d’activité, on parle ici de SPOF (Single Point Of Failure – point unique de défaillance).

Le zoning permet aussi de protéger les périphériques d’une zone contre les notifications, telles que les RSCN (Registered State Change Notification – changement d’état d’un périphérique), provenant d’autres zones. Ces notifications RSCN peuvent potentiellement provoquer une rupture de la communication, entrainant des pertes de données voire la corruption d’une base de données.

Lors de la création de zones, appliquez la règle: « un seul initiateur, plusieurs cibles » (connue sous le nom de “Single Initiator Zoning”) qui consiste à baser la création de zone par rapport à l’initiateur. Ainsi, de multiples périphériques de stockage peuvent être ajoutés à une zone sans violer la règle, par exemple, la séparation de la production et du développement. Vous pouvez baser votre zoning en fonction des systèmes d’exploitation, des ports, des applications, …

En fonction de l’accès de vos serveurs à vos baies de stockage, la topologie de vos fabriques doit être choisie de façon judicieuse afin d’obtenir les meilleures performances. Voici les différents types d’accès, et le tableau ci-dessous vous indiquera la topologie de fabrique à adopter selon le type d’accès:

• Local (one-to-one) : L’accès aux données s’effectue entre un serveur et un stockage connecté sur la même fabrique
• Centralisé (many-to-one) : L’accès aux données s’effectue entre une baie de stockage centralisée et plusieurs serveurs
• Distribué (many-to-many): L’accès aux données s’effectue entre plusieurs serveurs et de multiples baies de stockage

Le schéma représente une architecture typique Fiber Channel d’une baie de stockage, dotée de deux contrôleurs redondants actif/actif, accédée par deux serveurs. Les légendes indiquent comment le zoning et le stockage ont été paramétrés pour un environnement de virtualisation Hyper-V de Microsoft.

La sauvegarde et le zoning

Afin d’optimiser les débits et de garantir une fenêtre de sauvegarde stable, votre infrastructure de sauvegarde doit être configurée avec attention. L’utilisation d’une réservation permanente (Persistent Binding également appelée mappage/désignation permanente SCSI) est nécessaire afin de garantir la cohérence du chemin de communication et ainsi de prévenir les risques de phénomène de lecteur abandonné, généralement dû à un scan des périphériques aléatoires.

Il est préconisé de ne pas utiliser des dispositifs de sauvegarde sur la même fabrique ou dans la même zone que celle des disques (séparation des flux dits « tape I/O » et « disk I/O »), vous pourrez rencontrer des problèmes si les paquets de ces deux types d’unités coexistent. Afin d’anticiper ce problème, implémentez des adaptateurs fibre distincts ou dotés de plusieurs ports dans vos serveurs. En revanche, si vous ne disposez que d’un seul adaptateur, créez une zone dédiée à la sauvegarde.

Si vous envisagez une sauvegarde « serverless backup » (sauvegarde sans serveurs ou encore appelée « server-free ») vous devez alors créez une zone spécifique englobant votre librairie et votre stockage. Une librairie peut également disposer de plusieurs lecteurs de bande, et donc, en principe de plusieurs interfaces fibres. Configurez votre zoning en créant des zones distinctes par lecteur, et en connectant les interfaces fibres sur des fabriques différentes. Si vous désirez effectuer des sauvegardes pendant les heures de production, privilégiez des adaptateurs fibres dédiés pour la sauvegarde en appliquant la politique de zoning mentionnée précédemment.

Il convient également de désactiver la fonction Target Reset (réinitialisation de la cible). A l’origine, la fonction Target Reset a été conçue pour les unités de disque. Si un disque dur est suspecté d’avoir un problème, la fonction redémarre ce disque pour le remettre « online ». Un disque peut revenir à l’endroit où il s’est arrêté, tandis que le flux d’une unité de sauvegarde est continu (streaming), et ne dispose pas d’instructions de ce type. Pour résumer, si l’unité de bande subit une réinitialisation pendant une opération de sauvegarde, celle-ci devient inutilisable et l’application qui la pilote le fait passer en état hors-ligne.

Le schéma suivant détaille la configuration des zones d’une infrastructure comportant plusieurs serveurs, une baie de stockage double contrôleurs ainsi qu’une libraire de sauvegarde doté d’une interface fibre optique.

Selon les constructeurs et les modèles, vous pourrez choisir le type (fibre optique FC, iSCSI, 512 Mo de mémoire cache jusqu’à plusieurs Go) et le nombre de contrôleurs. La configuration la plus simple d’une baie ne dispose que d’un seul contrôleur tandis que les baies haute disponibilité embarquent deux contrôleurs. Ces contrôleurs peuvent être configurés en mode actif/actif ou actif/passif. Le choix de la configuration peut impacter les performances et la disponibilité des données. Nous allons analyser ces configurations et dans quel cas de figure il convient de les mettre en œuvre.

Configuration Actif/Passif

En mode actif/passif, les deux contrôleurs fonctionnent en mode redondant avec un cache mis en miroir. Si un contrôleur tombe en panne, le cache du contrôleur est commuté automatiquement. Chaque contrôleur dispose de ses propres LUN, un contrôleur est défini comme primaire et l’autre  comme secondaire pour accéder aux LUNs. Mais la baie de stockage ne donne pas accès à un LUN par le biais de chemins alternatifs. La baie doit changer l’appartenance (ownership) entre les contrôleurs pour emprunter des chemins alternatifs, ce qui peut dégrader fortement les performances.

Dans cette configuration, l’accès aux LUNs s’effectue via le contrôleur (Ctrl) A, et le contrôleur B entrera en fonction uniquement si le contrôleur A ne fonctionne plus. Si un port du contrôleur A est défaillant, l’accès se fera par un autre commutateur et/ou par un autre port mais pas via le contrôleur B.

Configuration Actif/Actif

En mode actif/actif, les deux contrôleurs fonctionnent en parallèle délivrant ainsi des performances de haut niveau. Néanmoins en cas de panne, les flux ne sont plus traités que par un seul contrôleur, et les performances peuvent être impactées de façon importante. Il est donc important de mettre en œuvre des technologies telles que le Multipathing (utilisation de plusieurs liens physiques), Load Balancing (répartition de charge), etc….

La configuration du cache impacte également les performances, il convient de bien le configurer, nous aborderons ce sujet au chapitre B.3. A noter que dans cette configuration les LUNs sont visibles par n’importe quel contrôleur.

Afin de mettre en œuvre le Multipathing, il convient d’équiper votre serveur d’une carte FC (Fiber Channel – fibre optique) double ports ou de deux cartes distinctes. Sauf pour certains cas particuliers, il n’est pas recommandé d’attacher un volume à un port d’un contrôleur, car en cas de problème de celui-ci, l’accès aux données sera impossible.

Dans un stockage de type Fiber Channel, les ports d’interconnexions agissent comme un commutateur interne à des fins de redondance. Lorsque la disponibilité des données prime sur la performance, il convient d’activer l’interconnexion de ports afin de relier « virtuellement » les deux contrôleurs et le serveur aura accès aux volumes par le biais de n’importe quel contrôleur et permettre ainsi de s’affranchir de l’acquisition de commutateur FC externe.

Si l’un des deux contrôleurs venait à faillir, l’interconnexion de ports (Host Port Interconnect) permet l’accès continu aux données sans intervention. Cette configuration doit être activée si vous désirez faire du Direct Attachment (attachement direct, sans passer par un commutateur FC additionnel, au maximum 2 hôtes par baie). Bien entendu, cette fonction n’existe pas dans les baies disposant d’un seul contrôleur.

Dans le cas où l’interconnexion de ports n’est pas activée, les données appartiennent à l’un des contrôleurs, selon la configuration et permet une configuration de type point à point. Cette configuration résulte typiquement d’une topologie double contrôleur qui sont connectés à un ou plusieurs commutateurs Fiber Channel

Dans cette configuration, le serveur connait tous les chemins de chaque LUN et s’assure qu’il est capable de les atteindre. Vous pouvez atteindre un LUN depuis n’importe quel HBA et les deux contrôleurs accèdent simultanément à cette LUN.

L’importance de la mémoire cache

La mémoire cache (antémémoire) est bien entendu un élément important dans le choix de vos contrôleurs mais sa configuration doit être judicieuse. Je vous recommande, selon les usages les plus courants, de choisir un contrôleur doté d’un cache embarquant beaucoup de mémoire. Voici les différents paramètres de gestion de cache le plus souvent rencontrés:

• Write Trough (antémémoire à écriture directe): En choisissant ce paramétrage de gestion de cache, les données présentes dans le cache sont immédiatement écrites vers les disques durs. Son usage le destine principalement à des bases de données ou des applications nécessitant un état de consistance applicative (application consistent) à tout moment.
• Write Back (antémémoire à écriture différée) : Avec ce paramétrage, les données présentes dans la cache sont écrites de façon différée vers les disques durs. Les données en lecture sont délivrées par le cache (qui est beaucoup plus rapide qu’une pile RAID) et les données en écriture (bien plus lentes qu’en lecture) sont ainsi différées, vous permettant ainsi d’obtenir les meilleures performances.  Il est essentiel de  coupler  à votre contrôleur une batterie, appelée BBU (Battery Backup Unit), afin de se prémunir d’une perte de données suite à une défaillance électrique. Cette batterie assurera le rôle d’envoyer les données présentes en cache vers la pile RAID, sans cette batterie, vous perdez le contenu des données (par exemple 2 Go si votre contrôleur embarque 2 Go de mémoire cache).
• Ahead Cache Settings (antémémoire à lecture anticipée): il s’agit d’une fonctionnalité permettant d’anticiper les lectures sur le stockage.  Ce mode de gestion de cache peut être très intéressant, mais malheureusement, il est incapable de « prédire » par avance les données qui vont être lues. Ce mode convient donc principalement aux accès séquentiels conséquents tels que le streaming vidéo ou l’accès à des fichiers de taille importante par exemple. La capture d’écran ci-dessous provient de l’interface d’administration d’une baie qui analyse l’efficacité du paramètre. Certains contrôleurs proposent une option appelée Adaptive, qui permet de commuter en fonction des accès (séquentiels ou aléatoires), d’un mode de cache anticipé à normal.

Je vous recommande l’usage du cache en mode Write Back qui améliore énormément les performances si vous disposez d’une batterie sur votre contrôleur, bien sûr. Selon certains constructeurs, pour obtenir des snapshots consistants, le mode Write Through est obligatoire car selon eux, un snapshot ne peut pas être consistant si des données sont présentes dans la mémoire du cache au moment du snapshot.

Néanmoins, il est impératif de sécuriser votre infrastructure en l’associant à des onduleurs intelligents capables d’éteindre proprement vos serveurs et vos baies de stockage afin de « vider » (flush) les données qui sont présentes dans le cache.

Certaines baies sont capables d’analyser l’efficacité de la mémoire cache anticipée. Dans la capture suivante, l’analyse nous informe que 10% des requêtes peuvent être anticipées pour une efficacité globale de 5%.

Depuis quelques années, les volumes à sauvegarder sont de plus en plus importants, on parle maintenant de plusieurs To (Téraoctets). Les temps de sauvegarde sont donc importants, et automatiquement la restauration également. Plus le temps de restauration est long, plus l’arrêt de production est important et impactera financièrement l’entreprise.

Il ne faut jamais négliger la sauvegarde à cause de considérations financières. Le coût d’une centaine de salariés au chômage technique, de pertes de transactions commerciales, d’une image de marque écornée, sera certainement supérieur à celui d’un dispositif de sauvegarde. Certains cabinets d’études statistiques mettent en avant le constat suivant: « une entreprise sur deux fermera ces portes dans les deux années à venir consécutif à un sinistre ayant entrainé une perte de données majeure ».

Une notion importante à ne pas négliger dans le monde de la sauvegarde est la Data Protection Windows (DPW) qui correspond au temps dont on dispose pour réaliser une sauvegarde consistante des données. En effet, si votre chaine de production ne s’arrête jamais, la DPW est nulle, et il faudra alors analyser des solutions telles que le CDP, réplication, …

Nous avons vu que certaines techniques comme les snapshots sont capables de réaliser une sauvegarde consistante. Si votre DPW est nul, mais qu’il vous est impératif de sauvegarder, les agents d’un logiciel de sauvegarde pourront réaliser une sauvegarde à chaud.

L’exemple le plus courant dans le monde Windows est l’agent de type Open Files (fichiers ouverts). En effet, si vous n’utilisez pas les clichés instantanés et que vous désirez sauvegarder un fichier ouvert, la sauvegarde n’en sera pas capable. Il faut avoir recourt à cet agent, spécialisé dans la sauvegarde à chaud de fichiers ouverts. Selon les logiciels de sauvegarde, les éditeurs disposent d’un catalogue plus ou moins étoffé d’agents disponibles pour des bases de données comme Oracle, DB2, etc…. Avant de choisir un logiciel de sauvegarde, assurez-vous qu’il est possible d’acquérir un agent spécifique pour votre applicatif.

Néanmoins en environnement virtualisé, la plupart des éditeurs commercialisent des agents spécifiques ou reposent sur les API des hyperviseurs. Ainsi, l’agent est capable non seulement de sauvegarder à chaud l’intégralité de la machine virtuelle mais également son contenu. Ainsi il est possible de restaurer l’intégralité d’une machine virtuelle à son emplacement d’origine ou sur un autre serveur, pour répondre à une problématique de RTO ou simplement de restaurer un fichier d’une machine virtuelle.

L’agent spécialisé dans la virtualisation permet d’économiser de l’argent car il intègre une « sorte » d’agent Open Files mais nécessite toujours des agents spécialisés pour Microsoft Exchange, par exemple. Des applications de sauvegarde dédiées à la sauvegarde d’hyperviseurs existent comme Veeam Backup, ou vRanger de VizionCore.

Comment calculer la fenêtre d’une sauvegarde, comment estimer l’espace de ma stratégie de sauvegarde, …. ? Autant de questions auxquelles les infrastructures de stockage de type SAN répondront. En effet, les stockages SAN nécessitent un réseau qui leur est propre et indépendant et surtout isolé du réseau de production. Abordé dans le chapitre C.1.C, l’environnement idéal d’une sauvegarde dans un environnement SAN est de créer un réseau dédié ou une zone afin de séparer les différents flux.

Calcul de taille d’une sauvegarde d’une machine virtuelle:

Taille de la sauvegarde = espace disque utilisé + mémoire vive (prévoir une marge de 10 %)

Calcul de taille d’une sauvegarde d’une machine virtuelle avec des clichés:

Taille de la sauvegarde = espace disque utilisé + mémoire vive + taille totale des clichés (prévoir une marge de 10 %)

Calcul de la taille d’une sauvegarde complète

Taille de la sauvegarde = espace disque utilisé * nombre de jours de rétention

Calcul de la taille d’une sauvegarde complète et incrémentale:

Taille de la sauvegarde = (espace disque utilisé * nombre de jours de rétention) + ((espace disque utilisé * taux de changement) * nombre de sauvegarde d’incrémentale)

Prenons l’exemple d’une librairie qui dispose des caractéristiques suivantes: un débit LTO4-HH théorique natif de 2.16 To/heure avec 3 lecteurs et de 4.32 To/heure. Le débit réaliste d’un lecteur LTO-4 est de 120 MB/s et dispose d’une capacité native de 800 Go sans compression. Nous devons sauvegarder 12 To d’un SAN en fibre optique et 1 To via un réseau Ethernet Gigabit.

La bande passante de la fibre optique 4 Gb est de 800 MB/s (en full duplex) soit 2.88 To par heure, donc dans notre exemple, le flux de sauvegarde ne saturera pas le réseau de stockage fibre optique. Le temps estimé sera de 12 To / 2.16 To/heure soit 25.92 heures en natif  sans compression.

Pour sauvegarder 1 To (1000 Go) en Gigabit, la bande passante théorique est de 125 MB/s soit 450 Go/heure, mais partons plutôt sur un débit réaliste de 70 % soit environ 87.5 Mo/s ou encore 315 Go / heure. Le temps estimé de la sauvegarde par ce média sera de 1000 Go / 315 Go/heure soit 3.17 heures.

Une autre formule, plus réaliste que je vous recommande, tient compte des changements de cartouches au sein de la librairie:

Taille de la sauvegarde en Mo / débit de la sauvegarde en Mo/sec / 60 / 60 + (temps de changement  de cartouche en minute(s) * nombre de cartouches utilisées)

Détail du calcul:

12000000 / 120 / 60 / 60 + (2 * (12000 Go / 800 Go)) soit 28h30 environ.

Alors que les lecteurs actuels dépassent le débit réalisable par les disques durs, leurs performances sont considérablement ralenties lors d’opérations de restauration dues aux opérations de chargement de la bande, de positionnement, … En réalité, les restaurations effectuées à partir de disques durs peuvent être de deux à dix fois plus rapide !

Le schéma suivant synthétise le découpage des temps d’un lecteur de bande pendant une opération de restauration. Le temps où le lecteur restaure les données ne représente que 8% du temps au total, le lecteur passant la plupart de son temps à des opérations non productives de chargement de média, de localisation des données sur la bande, ….

Si les disques accélèrent les temps de sauvegarde et de restauration, n’utiliser que ce média comporte des risques. La sauvegarde étant stockée sur un serveur relié au réseau, les données sont vulnérables aux virus, pannes disques, sinistre, … de plus, il sera très difficile de l’externaliser.

La sauvegarde disque doit être employée dans une stratégie disk-to-disk-to-tape (disque vers disque puis sur bande ou D2D2T), pour diminuer les temps de restauration et de sauvegarde ou lorsque celle-ci doit être déportée sur un autre site.

Bien entendu, les disques servant à héberger la sauvegarde peuvent être de type SATA à 7.200 tours par minutes, le flux étant séquentiel, ce type de disque correspond tout à fait à cet usage. Bien logiquement, la sauvegarde sur bande prends plus de temps qu’une sauvegarde sur disque, mais les clichés est la technique, à ce jour, qui dispose de la fenêtre la plus courte.

Les administrateurs de sauvegarde s’aperçoivent que la plupart des demandes de restauration concernent des données vieilles de 24 à 48 heures. La sauvegarde sur disque prend toute sa dimension dans ce cas de figure en adoptant la stratégie d’une rétention de 72 heures sur disque et au-delà un stockage sur bande.

On parle alors de Virtual Tape Library (VTL) qui sont en fait des Appliances dédiées aux opérations de sauvegarde sur disque qui émulent des lecteurs de bande de façon transparente pour les logiciels de sauvegarde.

L’avantage évident des Appliances VTL réside dans le fait qu’elles s’insèrent dans des environnements de librairies déjà en place sans remettre en cause la politique de sauvegarde et des investissements déjà réalisés. Techniquement les VTL permettent une augmentation des débits, une diminution des fenêtres de sauvegarde et du RTO tout en conservant une possibilité d’évolution de la capacité de sauvegarde par l’ajout de disques durs supplémentaires.

Il est possible de répliquer le contenu d’une VTL sur un autre site et bien entendu d’y adjoindre une solution de déduplication.

La Protection Continue (CDP)

Le CDP (Continuous Data Protection) représente une sauvegarde en continu dont le mécanisme est similaire à une réplication en temps réel en mode bloc ou en mode fichier pour certains logiciels.  La technique consiste à capturer chaque changement en les copiant automatiquement vers un autre stockage et permet ainsi une restauration immédiate depuis n’importe quel moment dans le temps.

Certains éditeurs les appellent solutions de sauvegarde en temps réel ou sauvegarde continue permettant une restauration à n’importe quel moment dans le temps. Les avantages sont multiples, le RPO (Recovery Point Objective) est proche de zéro, suppression des fenêtres de sauvegarde, restauration immédiate, délocalisation de la sauvegarde sur un autre site, restauration d’une version non corrompue, …

Ce schéma illustre la différence entre une sauvegarde traditionnelle et continue. En environnement traditionnel, nous avons une perte de données (deux heures de RPO) entre la dernière sauvegarde et le moment où le désastre est intervenu. Suite à ce désastre, il convient de restaurer les données à partir de bandes, ce qui peut prendre beaucoup de temps (3h45 de RTO) selon la volumétrie. La sauvegarde continue est censée offrir un RTO de zéro, et le temps de restauration est quasi-instantané ou peut prendre quelques instants selon la volumétrie ou si il convient de rapatrier le snapshot depuis une autre baie, dans notre exemple l’arrêt de production (RTO) est de 10 minutes.

Il convient de noter qu’il existe deux variantes de ces solutions: le True CDP (le vrai CDP) et Near Continous (presque continu). La première peut assurer une restauration dans le temps quasi infinie grâce à une journalisation de chaque écriture en mode bloc contrairement à la dernière qui se base sur une planification à intervalle définie (toutes les quinze minutes, par exemple).

Là encore, il convient de connaître l’importance des données à sauvegarder, utiliser une protection de type True CDP pour des courriers électroniques serait surdimensionné, disposer d’une sauvegarde à la seconde est inutile pour un courriel, mais pour une base de données de commerce électronique, True CDP apporte de vrais arguments.

Le problème majeur du True CDP est qu’il ne connait pas en temps réel les changements de données qui interviennent sur le stockage tant que le cache n’est pas vidé (flush) vers les piles RAID. Pour contourner ce défaut, il conviendrait de vider le cache à tout moment, ce qui est impossible techniquement, ou alors si le cache du contrôleur de votre baie de stockage est paramétré en Write Thru, et encore.

Dans le monde UNIX, la commande SYNC permet de vider le cache manuellement, un certain nombre d’éditeurs ont porté l’outil sur d’autres plateformes. Cet outil s’utilisant de façon ponctuelle, il est difficilement envisageable de le mettre en œuvre avec une protection de type True CDP. Pour cette raison, un CDP doté d’une fenêtre de quelques minutes parait tout à fait convenable et réalisable.

Quelques acteurs du marché comme A-Tempo ou DataDomain répondent à des problématiques de sauvegarde continue. Le point le plus important à valider est la consistance des données éventuelles surtout en mode True CDP. En effet, True CDP capture chaque écriture sans ce souci d’un état cohérent de la donnée contrairement au Near CDP qui repose sur des snapshots planifiés (typiquement VSS pour Microsoft Data Protection Manager). Cependant, plusieurs éditeurs ont développé leur système en se reposant sur les API des éditeurs d’applications confirmant ainsi un état dit « application consistent »  des sauvegardes.

La déduplication

La déduplication joue un rôle essentiel pour « lutter » contre l’explosion des données. Nous désirons tous obtenir une sauvegarde complète à tout moment mais il en résulte une capacité de sauvegarde qui croit de façon incroyable.

Lorsque l’on procède à une analyse des données, beaucoup d’entre elles sont redondantes. Nous nous accordons tous sur le fait que stocker un ou plusieurs fichiers est inutile et contre-productif. La première technique de déduplication à ne stocker qu’une seule fois un fichier était SIS (Single Instance Storage). Celle-ci est embarquée dans les systèmes d’exploitation Microsoft dédiés au stockage comme les versions Storage Server et Exchange. Sur le papier, cette technique est miraculeuse. Dans les faits, SIS agit au niveau fichier, ainsi une modification d’un seul mot dans un fichier de plusieurs Méga-Octets génère un nouvel enregistrement, et ne le considère pas comme un doublon.

Avec le logiciel de messagerie Exchange, SIS est implémenté au niveau du message, ce qui est beaucoup plus intéressant. Imaginez un responsable de service qui envoie une note de service de 10 Mo à l’ensemble de son service, soit 100 personnes. Un serveur de messagerie n’intégrant pas SIS stockera ainsi 1 Go d’espace disque pour le même courriel. Tandis qu’un système de messagerie incluant SIS ne stockera ce courriel qu’une seule fois, soit 10 Mo !

L’évolution du Single Instance Storage a mené à la déduplication. L’idée de cette technique est de générer des pointeurs vers un objet si nécessaire, c’est-à-dire que la donnée unique n’est stockée qu’une seule fois.

La déduplication agit au niveau bloc et découpe une donnée en de multiples tronçons grâce à un algorithme et à l’issue génère une signature unique qui sera stocké dans un index. Ainsi, lorsqu’un tronçon existe déjà dans l’index, un pointeur (sorte de lien symbolique) est généré dans le système de fichiers.

Prenons un exemple qui illustrera le schéma : un courriel de 10 Mo envoyé à 100 utilisateurs ne représentera que 10 Mo avec la technique de déduplication. On obtient un ratio de 100 :1 ce qui est énorme et le stockage ainsi économisé pour laisser entrevoir une politique de rétention beaucoup plus importante.

Etant donné que la déduplication agit au niveau bloc, contrairement au Single Instance Storage, un fichier qui subit une modification verra son nombre de blocs modifiés de façon insignifiante et pertinente. Par exemple, un fichier de 100 blocs qui subit une modification verra seulement 2 blocs de modifiés. D’un point de vue stockage, 98 blocs seront identiques et feront l’objet d’une création de pointeurs, et seuls 2 blocs seront réellement écrits.

La plupart des acteurs du marché utilise un hash MD5 ou SHA-1 comme algorithme pour générer des signatures. Le critère de performance d’une solution de déduplication réside dans l’algorithme qui va segmenter les données. Plus le découpage en segment d’une donnée est petit, plus le ratio que l’on pourra obtenir sera élevé. La taille des signatures doit être la plus réduite possible car plus la taille de votre index est importante, plus les temps pour savoir si un segment est unique ou non seront importants.

Selon les solutions de déduplication, la segmentation peut être déterminée automatiquement par l’algorithme (généralement des solutions haut de gamme et donc coûteuse) soit de façon fixe (8k par exemple) ou aléatoire. Les ratios annoncés par les éditeurs et constructeurs sont souvent impressionnants, mais dans la pratique il convient de diviser au moins par trois ou quatre les ratios annoncés.

Nous l’avons bien compris, la déduplication représente un avantage de taille dans le domaine de la sauvegarde sur disque. Mais le domaine où elle s’avèrera être la plus performante est la sauvegarde d’environnements virtuels. En effet, la plupart du temps, dans les centres de données, on dénombre entre deux à cinq systèmes d’exploitation différents. Si vous disposez au sein de votre datacenter de cinquante machines virtuelles Windows 2008 Service Pack 2, il est évident que plusieurs centaines de milliers fichiers, tels que des DLL (Dynamic Link Library) seront exactement les mêmes et seront donc très bien pris en compte par une solution de déduplication. Je vous recommande bien entendu d’avoir recours à un déploiement de vos systèmes d’exploitation effectué par l’intermédiaire de modèles (templates).

La déduplication apporte de nombreux avantages, dont le principal est d’économiser l’espace disque. Par déduction, votre stratégie de sauvegarde nécessitera moins de disques durs, donc une consommation électrique réduite, une fenêtre de sauvegarde amoindrie, une puissance en climatisation moindre, une occupation en nombre de U de vos baies en baisse.

Ces solutions sont disponibles sous forme de solution logicielle, de complément logiciel (plugin) ou d’Appliance dédiée. Beaucoup d’acteurs sont présents sur ce marché comme : Avamar, DataDomain, HP, FalconStor ou encore Bakbone.

La déduplication se déploie sous diverses formes : à la source, à la destination (target), en ligne (in-line) ou post-processus (back-end ou post-process). Voyons quelques scénarios d’applications avec les schémas suivants.

Afin d’augmenter la disponibilité des données, le contenu d’un serveur de déduplication peut être répliqué en vue d’être externalisé. Cela correspond tout à fait aux nouveaux usages tels que le Cloud Computing (infrastructure délocalisée sur internet). Le Cloud Computing reposant sur l’architecture internet, soit des bandes passantes faibles et non garanties, la déduplication du fait de son implémentation au niveau bloc, demeure une solution de premier ordre.

Les snapshots

Les snapshots, appelés clichés instantanés, constituent une copie en lecture seule des données à un instant donné (on parle de Point-In-Time) sans en interrompre l’accès avec un état de  consistance de niveau application. Les clichés instantanés ne sont pas des sauvegardes à part entière, ils nécessitent pour restaurer des données la présence des données initiales. En revanche, il est possible de restaurer un cliché à un autre emplacement que celui d’origine, ce qui peut s’avérer être très pratique pour des tests applicatifs, par exemple.

Les snapshots représentent un excellent moyen de sécuriser les données sans pour autant être une sauvegarde à part entière, mais est le compagnon idéal d’une sauvegarde. Ainsi, il est possible de sauvegarder les clichés sur une bande à des fins d’externalisation.

Grâce à ce système de clichés, les stratégies de sauvegarde sont souvent remaniées en profondeur en entreprise. Ainsi, des clichés réalisés à plusieurs moments de la journée permettent de se rapprocher d’un RPO de zéro et qu’une sauvegarde sur bande des clichés diminue la fenêtre de sauvegarde.

Certains d’entre nous s’en servent comme de la pseudo-réplication en déclenchant un instantané de l’ensemble du volume pour le copier sur un autre stockage. L’espace disque consommé ne représentant que le delta des données modifiées, la bande passante requise reste faible et présente les caractéristiques d’une réplication asynchrone.

Le système de clichés peut être implémenté au niveau logiciel via Microsoft VSS, Linux LVM, VMware ou directement au niveau du stockage. Selon les systèmes d’exploitation et les baies de stockage, les snapshots peuvent être copiés d’une baie à une autre (intra-baie) ou d’un volume à un autre au sein d’un même stockage (inter-baie) et peuvent être à même d’agir au niveau fichier, LUN, volume, …

Le but des snapshots est d’obtenir un état consistant des données à un instant T. D’un point de vue logiciel, Microsoft VSS utilise les API Exchange, SQL, … la cohérence est donc garantie et la mise en œuvre demeure simple.

En revanche d’un point de vue matériel, obtenir un état consistant est beaucoup moins évident car certains constructeurs embarquent un système de cliché mais agissant uniquement au niveau du stockage, sans tenir compte des applications présentes. Donc, si vous utilisez un système d’exploitation du type Linux et une base de données Oracle, il vous faudra impérativement valider que votre baie de stockage dispose de mécanismes de clichés compatibles avec votre plateforme, SnapView de EMC est un exemple.

Voici une définition de ces termes:

• Spindle: disque dur
• Secteur (ou unité d’allocation): ensemble d’octets
• Bloc: ensemble de secteurs
• chunk: équivalent au bloc dans le monde RAID
• Stripe (ou stripe unit): certains l’assimile à un bloc ou chunk sur un même spindle
• Stripe Width (largueur de bande): nombre de disques composants une pile RAID
• Stripe Size (taille de bande): certains l’assimilent à un ensemble de chunks (ou blocs) sur un même disque ou répartis sur plusieurs disques (nous allons retenir cette dernière définition)

Le chunk correspond à la taille des données contigües qui sont écrites sur un disque dur avant que le contrôleur RAID ne passe à un autre disque dans la bande.

Notez également que si vous comptez utiliser une taille relativement petite, prenez le soin de bien choisir votre contrôleur (doté d’un processeur ASIC puissant) car celui-ci va être très sollicité pour découper les données. Pour définir correctement votre paramètre chunk, faîtes correspondre votre Pattern I/O à la taille du chunk, dans la mesure du possible.

La taille de la bande (stripe size) définit la taille d’un bloc (ou chunk) dont les secteurs sont répartis sur plusieurs disques. Par exemple, un fichier de 1M représentera seize blocs sur un RAID dont le stripe size est de 64k. A l’inverse, si le fichier est inférieur à la taille de la bande, le contrôleur RAID enverra la donnée sur un seul disque ne sachant pas la découper, entrainera l’occupation de la bande et une baisse de performance.

Prenons un exemple, une base de données lit ou écrit en une opération de petites données contenues dans les tables, comme des numéros de carte de crédit, des coordonnées de clients, … Une taille de 64k parait surdimensionné, car il est rare qu’une coordonnée pèse 60k, de plus l’espace réservé de 64k ne sera pas consommé, d’où une perte de performances et d’espace disque.

Tandis que pour des opérations de serveurs de fichiers, il convient d’envoyer le maximum de données en une opération, il convient alors de prendre une taille importante, 128k voire 256k, par exemple.

La taille de la bande s’obtient en multipliant le nombre de disques dans votre pile RAID (en capacité utile, c’est à dire un disque en moins dans votre calcul pour un RAID de niveau 5) par la taille de chunk, ou doit être un multiple de votre Pattern I/O.

Exemple: 32k de données sur un stripe de 8k = 4k de taille de chunk

Exemple: 1M de données sur un chunk de 64k = 16k de taille de stripe

Pour résumer, une petite taille favorisera les temps d’accès et les opérations d’entrée/sortie alors qu’une taille importante favorisera les débits de transfert.

Si vos accès sont en moyenne de 16k sur un stockage paramétré avec un chunk de 64k, les serveurs accéderont à un seul disque dans la pile RAID, ce qui n’est pas recommandé car le but est de répartir les données sur plusieurs disques afin d’en accélérer le traitement.

Dans l’exemple suivant, je compare un RAID composé de 4 disques durs, l’un avec un largueur de bande de 64 k, l’autre avec un largueur à 256k, avec des fichiers de tailles différentes. Le fichier de 128k est réparti sur l’ensemble des disques, et les autres fichiers sont également répartis sur l’ensemble des disques ne laissant que peu d’espace disque disponible.

Dans l’exemple ci-dessous, le fichier de 128k est stocké sur un disque seulement, celui de 256k sur deux disques et le fichier de 1M demeure sur quatre disques mais on constate que nous disposons de plus d’espace disque (disque dur 3 et 4).

Il est essentiel de retenir deux notions, les bases de données requièrent des opérations d’entrée/sortie par seconde très élevées tandis qu’un serveur de fichier requiert du débit. En règle générale, il convient de choisir une taille comprise entre 64 k et 1 M (nombreux gros chunks lus sur un même stripe) pour les accès séquentiels et 512B à 8 k pour les accès aléatoires.

Les schémas suivants comparent les débits en fonction de la taille du chunk et du Pattern I/O.

Ces tests démontrent que pour des bases de données (4 à 8k), la taille de chunk idéale est 32 ou 64k, tandis que pour des Pattern I/O « classique » (256 à 1M), la taille idéale du chunk est 128 ou 256k; et que pour les accès séquentiels intensifs la valeur idéale est 256 ou 512 et pour applications vidéo, streaming celle-ci est de 1024.

Ces tests ont été réalisés sur des accès séquentiels, pour des accès aléatoires, les conclusions tirées de l’analyse des schémas précédents s’appliquent également.

Vous avez constaté qu’il est important de tenir compte des paramètres abordés ici, sous peine de perdre inutilement de l’espace disque et d’obtenir des performances médiocres. Certaines baies analysent pour vous la taille de vos requêtes. Dans la capture suivante, la baie nous informe que les accès en lecture ont en moyenne une taille de 4k et 1M et 64k en écriture. On peut en déduire que cette baie de stockage héberge certainement une base de données, des fichiers de taille moyenne et importante.

Il existe plusieurs protocoles dans le monde des réseaux Ethernet comme le LACP (Link Aggregation Control Protocol – norme IEEE 802.3ad) et le Trunking qui peuvent grandement optimiser et sécuriser les environnements iSCSI au niveau des commutateurs. Les techniques comme MPIO (Multi Path I/O) et MCS (Multiple Connections per Session) s’occupent de rendre le stockage hautement disponible au niveau de l’initiateur.

Le pilote MPIO de Microsoft autorise les initiateurs iSCSI d’ouvrir plusieurs sessions vers la même cible en la présentant de façon unique. Chaque session peut être établie en utilisant des cartes réseaux ou des commutateurs différents. En cas d’échec de l’une des sessions, les autres continuent de traiter les opérations d’entrée/sortie sans interruption. Cette technologie est la plus répandue à ce jour.

MCS fait partie intégrante du protocole iSCSI et permet l’agrégat de plusieurs connexions dans une seule session. Ainsi, les opérations d’entrée/sortie sont envoyées sur n’importe quelle connexion TCP/IP de la cible.

Pour conclure, MCS est le plus performant bien que ses avantages demeurent marginaux à l’heure actuelle et s’utilise lorsque MPIO n’est pas supporté (Windows XP, 2000 et Vista). MCS et MPIO agissent au niveau SCSI et ne peuvent pas partager une commande SCSI sur plusieurs liens mais permettent uniquement d’obtenir une redondance de liens. Il convient de mettre en œuvre les techniques de Trunking et de LACP en vue d’obtenir une augmentation des débits et une redondance sur plusieurs liens.

L’agrégation de liens permet à plusieurs liens distincts d’être vu comme un seul et même lien et permet d’obtenir une bande passante démultipliée mais aussi une redondance et une répartition de charge sur ce groupe de liens. Généralement le Trunking (configuration statique) est couplé à LACP.

Politique de répartition de charge

La répartition de charge MPIO (Multipath I/O) est destinée à accroitre la disponibilité des accès à stockage partagé en établissant plusieurs connexions, par l’intermédiaire d’un DSM (Device Specific Module). Ces modules peuvent être spécifiques selon les baies de stockage, EMC PowerPath et Infortrend EonPath ou encore un DSM Datacore pour les logiciels de virtualisation de stockage, sont quelques exemples.

Si vous désirez mettre en œuvre une architecture hautement disponible, il vous faudra impérativement doubler les équipements à tous les niveaux: cartes HBA, commutateurs, liens réseaux, contrôleurs actif/actif,…

Non seulement, le doublement de ces équipements vous permettra d’obtenir d’excellentes performances mais éliminera un éventuel SPOF (Single Point Of Failure – point unique de défaillance).

Selon l’hyperviseur, le DSM ou la baie de stockage, des politiques de répartition de charge différentes seront paramétrables. Voici celles que vous retrouverez le plus souvent:

• Fail Over (basculement uniquement): utilise un chemin d’accès actif et désigne tous les autres chemins d’accès comme étant en attente. En cas de défaillance du chemin d’accès actif, tous les chemins d’accès en attente sont essayés à tour de rôle
• Round Robin (répartition alternée): La stratégie de répartition alternée consiste à répartir uniformément les flux sur tous les chemins

• Round Robin with a subset of paths (répartition alternée avec sous-ensemble): La stratégie de répartition alternée avec sous-ensemble de chemins est similaire à Round Robin à la différence que l’on peut définir des chemins actifs et passifs
• Weighted Path (chemins d’accès mesurés): La stratégie des chemins d’accès mesurés prend en compte une charge de traitement spécifique  relative à chaque chemin d’accès. Un nombre élevé représente une priorité faible du chemin d’accès
• Least Queue Depth (longueur minimale de la file d’attente: Uniquement supporté par MCS): La stratégie de longueur minimale de file d’attente compense les charges non uniformes en répartissant proportionnellement davantage de demandes d’entrée/sortie aux chemins d’accès de traitement les moins chargés

Après des tests intensifs, la politique la plus performante aussi bien en terme de débit que d’opérations d’entrée/sortie, est Round Robin with a subset of paths suivie de près par le Failover.

Je savais que nVidia n’était pas réputé pour la qualité de ses pilotes, Linus Torvalds l’a d’ailleurs fait savoir d’une manière peu conventionnelle Voici les tests que j’ai menés:

• Désinstallation des pilotes via le panneau de configuration
• Suppression des dossiers c:\program files\NVIDIA*
• 64 Bits => Suppression des dossiers c:\programdata\NVIDIA*
• Suppression des fichiers NV* dans c:\windows\system32\driverstore\filerepository
• Redémarrage en mode sans échec et suppression de ce qu’il reste à l’aide de Driver Fusion
• Installation des nouveaux pilotes NVIDIA

Après un redémarrage, même problème… Je teste ma mémoire (outil Windows, memtest, …), chkdsk, etc… Rien d’anormal. J’en conclus donc que ma carte graphique est morte. Je commande donc une nouvelle carte nVidia, et là c’est le drame, le problème persiste…

Après quelques recherches sur Internet, je m’aperçois que je ne suis pas le seul dans ce cas, que c’est très courant !

Microsoft a d’ailleurs posté et crée un Fix IT pour cela, et ça parle d’une augmentation le temps de traitement GPU  en ajustant la valeur de registre délai d’expiration de la détection et de récupération, qui joue avec un paramètre, nommé TDR (TIMEOUT DETECTION & RECOVERY). Introduit depuis Windows Vista, cette fonctionnalité est censée corriger des problèmes matériels liés à la carte graphique sans avoir à rebooter, avant sous XP, sans TDR on avait droit à un BSOD ou un freeze !

Le problème touche toutes les cartes graphiques, y compris ATI ! Voici les différents causes pouvant provoquer le problème:

• Paramètres mémoire incorrects (timing, tensions,…) => lancez un diagnostic MEMTEST, Windows Memory Diagnostic…
• Problème d’alimentation (insuffisance, …) => Calibrez votre alimentation ici et ici
• Pilotes corrompus
• Surchauffe => regardez avec SpeedFan et GPUZ ou encore MSI Afterburner, EVGA Precision
• Tensions Nothbridge et Southbridge incorrects
• Overclocks instable => stressez votre PC pour vérifier la stabilité avec OCCT, Prime95, 3DMark, VideoCardStability
• Carte graphique HS
• Conflits de pilotes avec les Webcam Logitech, Realtek HD Audio

Un post sur Technet recense toutes les solutions, pour ma part, voici ce que j’ai fais:

Modification du registre concernant TDR, quelques liens MSDN à ce propos ici et là.

Forcer le pilote PhysX sur la carte graphique

Passer d’une gestion d’alimentation Adaptive à Maximale

Désactivation de l’accélération matérielle dans Firefox.

J’espère que ce post vous aidera dans la résolution du problème. Pour le moment, cela ne s’est pas reproduit chez moi…

Si un ordinateur virtuel est configuré pour utiliser 12 Go de RAM, le système doit utiliser la mémoire d’un autre nœud. Le franchissement de la limite NUMA peut réduire les performances virtuelles jusqu’à 8 %, une bonne pratique consiste à configurer un ordinateur virtuel pour utiliser les ressources d’un seul nœud NUMA.

Plutôt qu’un long discours, voici deux schémas permettant de bien comprendre la technologie NUMA.

Le script suivant permet de forcer une affinité NUMA pour une machine virtuelle

[powershell]
################################################
# Developer: Anthony F. Voellm
#          : Taylor Brown
# Copyright (c) 2008 by Microsoft Corporation
# All rights reserved
#
# This is « demonstration » code and there are no
# warrantees expressed or implied
################################################

# This script will set the Virtual Machine to run
# on a specific NUMA node

# Check command line arguments

if (($args.length -lt 1) -or
(($args[0] -ne « /list ») -and
($args[0] -ne « /set ») -and
($args[0] -ne « /clear »)) -or
(($args[0] -eq « /set ») -and ($args.length -lt 3)) -or
(($args[0] -eq « /clear ») -and ($args.length -lt 2))) {
Write-Host « numa.ps1 /list [<Hyper-V host>] »
Write-Host « numa.ps1 /set <vm machine name> <required node> [<Hyper-V host>] »
Write-Host « numa.ps1 /clear <vm machine name> [<Hyper-V host>]`n »
Write-Host « Options: »
Write-Host « `t/list – show configured VM’s »
Write-Host « `t/set <vm machine name> <required node> – set the NUMA node for the VM »
Write-Host « `t/clear <vm machine name> – clear NUMA node seting for the VM »
exit;
}

# just display VM’s
if ($args[0] -eq « /list ») {
if ($args.length -gt 1) {
$HyperVHost = $args[1];
}
Get-WmiObject -Namespace ‘root\virtualization’ -Query « Select * From Msvm_ComputerSystem » | select ElementName
exit;
}

# Set or clear

$HyperVHost = ‘.’;
if ($args[0] -eq « /set ») {
if ($args.length -gt 3) {
$HyperVHost = $args[3];
}
$VMName = $args[1];
$RequiredNode = $args[2];
} elseif ($args[0] -eq « /clear ») {
if ($args.length -gt 2) {
$HyperVHost = $args[2];
}
$VMName = $args[1];
}

#Main Script Body
$VMManagementService = Get-WmiObject -Namespace root\virtualization -Class Msvm_VirtualSystemManagementService -ComputerName $HyperVHost

$Query = « Select * From Msvm_ComputerSystem Where ElementName=’ » + $VMName + « ‘ »

$SourceVm = Get-WmiObject -Namespace root\virtualization -Query $Query -ComputerName $HyperVHost

$VMSettingData = Get-WmiObject -Namespace root\virtualization -Query « Associators of {$SourceVm} Where ResultClass=Msvm_VirtualSystemSettingData AssocClass=Msvm_SettingsDefineState » -ComputerName $HyperVHost

if ($args[0] -eq « /set ») {
$VMSettingData.NumaNodesAreRequired = 1
$VMSettingData.NumaNodeList = @($RequiredNode)
} else {
$VMSettingData.NumaNodesAreRequired = 0
}

$VMManagementService.ModifyVirtualSystem($SourceVm, $VMSettingData.PSBase.GetText(1))

[/powershell]

La syntaxe est très simple:

[powershell]

numa.ps1 /set NOMVM noeudnuma => numa.ps1 /set sql2012 2

numa.ps1 /? => obtenir l’aide

[/powershell]

Un compteur de performance permet de vérifier l’afinité d’une machine virtuelle à noeud NUMA, il se nomme Preferred NUMA Node Index

Si vous désirez monter une infrastructure de type SAN, il est important d’avoir à l’esprit quelques données importantes à propos des architectures physiques des serveurs et des différents composants.Si vous devez traiter un nombre important d’IOPS, préférez des serveurs dotés de bus quie leur seront propres plutôt que des serveur de types blades dont le fond de panier n’a pas le design pour soutenir des IOPS élevées.Au niveau des HBA (FC, iSCSI), il existe des cartes simples ports/double ports/quatre ports. Les écarts de performances sont assez faibles pour en faire un critère de choix.

Cependant, préférez, afin de ne pas avoir de SPOF (point de défaillance unique) plusieurs cartes deux ports, par exemple, plutôt qu’une carte quatre ports. Car si jamais celle-ci jamais à faillir, c’est 4 ports qui ne seront plus accessibles au lieu de deux ports, et l’implémentation de Multipathing permettra un maintien des accès.Maintenant, pour correctement dimmensionner l’architecture, il convient de connaitre le type d’accès qui sera effectué. Cela se mesure en IOPS et/ou en MB/s, le premier désigne le nombre d’opérations par secondes (SQL, Exchange, …) et le second représente le volume de données transportées (vidéo, …)

Le tableau ci-dessous montre le IOPS et Débit maximum supportés par type d’interface.

Les débits de l’Infiniband:

Les débits des HBA:

Les débits des slots:

Les débits QPI:

Les débits mémoire:

Les IOPS par interface:

Concernant le protocole iSCSI, qui génère de la charge CPU dû à l’encapsulation des commandes SCSI dans le protocole IP (appelé Overhead), il convient de dédier un coeur pour 2 ports iSCSI, et un coeur pour 3 ports FC. Les processeurs et les bus actuels disposent de bande passante élevées, donc concernant le choix des processeurs, préférez deux CPU d’une fréquence moins élevée plutôt que 1 CPU d’une fréquence supérieure.

Dans l’exemple ci-dessus, la connectique Back-END est de type FC 4 Gbits et 2 liens Ethernet agrégés en Front-END. C’est typiquement ce schéma sur lequel il convient de se baser pour définir l’architecture.

Voici la configuration type du cluster, qui est composée de trois serveurs:

Premier noeud du cluster

Deuxième noeud du cluster

Configuration de l’ISCSI TARGET

En premier lieu, il convient de paramétrer la cible iSCSI, il convient d’ajouter le rôle iSCSI TARGET, et d’ajouter un disque virtuel iSCSI

Je ne saurais trop vous conseiller d’entrer les adresses IP des initiateurs (serveurs qui vont utiliser le stockage iSCSI), ou leurs adresses MAC, car MPIO gère mal les noms DNS…

Maintenant, nous allons créer un témoin pour le cluster, utilisé pour le Failover Clustering.

Répetez les étapes précédentes pour créer le disque témoin.

Configuration des initiateurs iSCSI

Nous allons maintenant configurer les initiateurs iSCSI: SRV-1 et SRV-2. Dans un premier temps, il faut installer la fonctionnalité MPIO. puis entrez la commande suivante pour activer MPIO pour iSCSI. Cette commande entraine un reboot du serveur !

[shell]

mpclaim -r -i -d « MSFT2005iSCSIBusType_0x9″

[/shell]

MPIO embarque bien désormais les périphériques iSCSI Microsoft.

Nous allons maintenant configurer le stockage iSCSI en utilisant MPIO. Dans l’initiateur SCSI, saisissez l’adresse IP de la cible iSCSI.

Nous allons maintenant définir les chemins MPIO. Pour cela, supprimer le premier chemin qui est crée par défaut. A noter que dans mon laboratoire, qui repose sur des machines virtuelles sous Hyper-V 3.0, j’ai crée des 2 switchs virtuels afin d’obtenir une véritable redondance des équipements. A noter que la carte iSCSI-1-MPIO est connectée sur un SWITCH-A et la carte iSCSI-2-MPIO connectée sur un SWITCH-B.

Nous allons ajouter des sessions manuellement. Noter qu’il faut activer absolument la prise en charge de plusieurs chemins d’accès !

Il faut donc définir les chemins en fonction des adresses IP, afin qu’elles n’utilisent pas les mêmes chemins ! Nous obtiendrons cela à l’issue de la configuration:

Nous avons bien deux chemins distincts. Cliquons sur périphériques pour avoir accès à la configuration MPIO.

Nous avons bien les deux chemins ainsi que la politique d’équilibrage de charge. A noter, que dans mon livre, j’explique les différences entre toutes les politiques ainsi que les différences en tre MCS et MPIO. Voici une brève explication.

La configuration automatique découvre bien nos 2 disques virtuels iSCSI.

Configuration du Failover Clustering

La fonctionnalité Failover Clustering doit être installée sur les deux serveurs composants le cluster, ici dans notre exemple, SRV-1 et SRV-2.

Après avoir installé la fonctionnalité, nous validons la bonne configuration du cluster. Je pars du principe que tous les pré-requis sont respectés. Pour plus d’informations à ce sujet, cliquez ici.

Maintenant, nous allons crée le cluster composé de SRV-1 et SRV-2.

Notre cluster s’appellera FILE-CLUSTER et sera joignable à l’adresse 192.168.0.240

Dans mon laboratoire, j’avais oublié le quorum au départ, si vous suivez mon tutoriel, vous ne devriez pas obtenir cet avertissement. Néanmoins, voici comment attacher un disque témoin à votre cluster.

Nous allons maintenant configurer les interfaces réseaux du cluster. Pour rappel nous avons trois type d’interfaces réseaux: production (réseau SMB) – iSCSI-X-MPIO (réseau dédié au stockage iSCSI) – Cluster Hearbeat (communication interne cluster).

Configuration du service de fichiers en cluster

Notre cluster étant désormais fin prêt, nous allons ajouter le rôle haute disponibilité / serveur de fichier.

Le cluster sera joignable via le nom SHARE-CLUSTER à l’adresse IP 192.168.0.199.

Il faut désormais créer un partage hautement disponible.

Notre partage hautement disponible est désormais actif !

Activation de la déduplication

La déduplication des données dans Windows Server 2012 permet de stocker davantage de données dans un espace physique inférieur. Cette fonctionnalité augmente nettement l’efficacité de stockage par rapport aux précédentes versions grâce au stockage d’instance simple (SIS, Single Instance Storage) ou à la compression NTFS (New Technology File System). La déduplication des données repose sur la segmentation à taille variable en sous-fichier et la compression. Utilisées ensemble, ces technologies permettent de diviser le stockage par 2 pour les serveurs de fichiers généraux et par 20 (au maximum) pour les données de virtualisation.

Voici un exemple des gains de la déduplication. J’ai crée trois dossiers où j’ai copié dans chacun d’entre eux, un fichier de 1,2 Go puis un seul fichier dans l’un des dossiers. J’ai ensuite forcé l’optimisation à l’aide commandes suivantes (en définissant une déduplication des fichiers à 0 jours). Le gain est de l’ordre de 85% !!!

[powershell]
Start-DedupJob –Volume E: –Type Optimization
Get-DedupJob
Get-DedupStatus
[/powershell]

Résolution de problème

Dans mon laboratoire, j’ai à peu près eu toutes les misères: opérations DNS refusée, Contrainte Kerberos, …. Je suis en configuration multi-domaine aussi…

Erreur Kerberos

Il faut autoriser la délégation Kerberos pour les ressources composant le cluster.

ERREUR network name resource ‘xxxx′ failed to create its associated computer object in domain ‘xxxx’ during: Resource online

Il faut modifier une GPO et créer une délégation dans l’UO des vos machines du cluster. En effet, le service Failover Clustering crée des objets AD dans l’UO où se trouvent les serveurs membres du cluster. D’ailleurs si un serveur n’est pas dans la même UO, la validation du cluster échoue. Cette résolution permettra au Failover Cluster de créer le compte machine de la ressource cluster.

Problème de création des enregistrements au niveau DNS

Il se peut également de le service de cluster soit incapable de créer lui-même l’enregistrement DNS du compte machine associé. Même en le créant manuellement, les soucis persistent. Il convient de modifier les autorisations pour la zone.