Voici un tableau, avec les liens de mise en oeuvre correspondant, des services les plus couramment déployés:

STOCKAGE

Pour tous savoir, lancez gcm –module Storage

Disque Physique

[powershell]

Get-PhysicalDisk # lister tous les disques

Get-PhysicalDisk | Sort Size -Descending # lister tous les disques par décroissance

Get-StoragePool -IsPrimordial $false | Get-PhysicalDisk # lister les disques associés à un pool

[/powershell]

Les pools

[powershell]

Get-StoragePool # lister les pools de stockage

$pDisks= Get-PhysicalDisk $s=Get-StorageSubSystem New-StoragePool -FriendlyName « Monpool » -PhysicalDisks $pDisks[0] , $pDisks[1] -StorageSubSystemFriendlyName $s.FriendlyName # créer un nouveau pool « Monpool » composé de 2 disques

[/powershell]

Disques virtuels

[powershell]

New-VirtualDisk -FriendlyName « VD1″ -StoragePoolFriendlyName « Pool1″ -Size 100GB -ResiliencySettingName « Mirror » -ProvisioningType Thin # créer un disque virtuel de 100 Go en miroir et Thin Provisonné

New-VirtualDisk -FriendlyName « VD1″ -StoragePoolFriendlyName « Pool1″ -ResiliencySettingName « Parity » -UseMaximumSize # créer un disque virtuel le plus gros possible en parité

Remove-VirtualDisk -FriendlyName « VD1″ # supprimer un disque virtuel

[/powershell]

Volumes

[powershell]

Get-VirtualDisk -FriendlyName « VD1″ | get-disk | Initialize-Disk -PartitionStyle « MBR » # initialiser un disque en MBR

Get-VirtualDisk -FriendlyName « VD1″ | get-disk | New-Partition -Size 500GB -DriveLetter P # créer une partition de 500 Go avec la lettre P

Format-Volume -DriveLetter P -FileSystem NTFS -NewFileSystemLabel « Données” # formater le disque P avec le label Données

Format-Volume -DriveLetter Z -FileSystem ReFS -Confirm:$false # formater Z en ReFS sans confirmation

[/powershell]

Partages

Pour tous savoir, lancez gcm –module SMBShare

Partage SMB

[powershell]

Get-smbshare # lister tous les partages

New-SmbShare -Name « Partage1″ -Path « D:\partage1″ -FullAccess « e-novatic\cgeorgeot » # créer un partage « Partage1″ sur d:\partage1 avec un accès total pour e-novatic\cgeorgeot

Remove-SmbShare -Name « partage1″ # supprimer le partage « partage1″

[/powershell]

Server SMB

[powershell]

Get-SmbClientConfiguration # obtenir la configuration cliente SMB

Get-SmbServerConfiguration # obtenir la configuration server SMB

[/powershell]

Deduplication

Pour tous savoir, lancez gcm –module Deduplication

Volume

[powershell]

Get-DedupVolume # lister les volumes dédupliqués

Enable-DedupVolume P: # activer la déduplication sur P

Set-DedupVolume P: -ExcludeFileType « txt », « log » -MinimumFileAgeDays 10 # configurer la déduplication sur P en excluant les fichiers txt et log avec un age de 10 jours

Get-DedupStatus P: # obtenir le status

[/powershell]

Planification

[powershell]

Get-DedupSchedule # obtenir le status

Set-DedupSchedule ThroughputOptimization-2 -Type Optimization -Start « 8:00 AM » -Days « Sunday », »Friday » # créer une tâche d’optimisation à 08h tous les vendredi et dimanche

[/powershell]

Jobs

[powershell]

Start-DedupJob P: -Type Optimization # démarrer un job d’optimisation

Get-DedupJob # obtenir les jobs en cours

[/powershell]

iSCSI Target

Pour tous savoir, lancez gcm –module iSCSITarget

Disque iSCSI virtuel

[powershell]

Get-IscsiVirtualDisk # lister les disques iSCSI

New-IscsiVirtualDisk -Path « c:\stockage\VM1.vhd » -size 400GB # créer un disque iSCSI de 400 Go

Remove-IscsiVirtualDisk –Path « c:\stockage\VM1.vhd » # supprimer un disque iSCSI

[/powershell]

Serveur CIBLE

[powershell]

New-IscsiServerTarget -TargetName « VMDisques » # créer une cible VMDisques

Set-IscsiServerTarget -TargetName « VMDisques » -initiatorId « IQN: iqn.2009-05.local.e-novatic:hv-1.e-novatic.local », »DNSNAME:hv-2.e-novatic.local » # association (unmask) des initiateurs à la cible VMdisques

Get-iscsiTarget # liste toutes les cibles

Remove-IscsiServerTarget –TargetName « VMdisques » # supprimer une cible

[/powershell]

Mapping

[powershell]

Add-IscsiVirtualDiskTargetMapping -Path « c:\stockage\DC.vhd » -TargetName VMDisques # mapper un disque à une cible

Get-IscsiServerTarget | where {$_.Status -eq « Connected »} | fl LunMappings # lister les LUNs connectées

[/powershell]

Initiateur ISCSI

Pour tous savoir, lancez gcm –module iSCSI

[powershell]

$Target=New-iSCSITargetPortal -TargetPortalAddress “192.168.0.1” # découverte du portail à l’adresse 192.168.0.1

$Portal = Get-iSCSITargetPortal # détail d’un portail

Connect-iSCSITarget -NodeAddress $Target.NodeAddress # connexion à un portail

Get-IscsiSession | where IsConnected -eq $true # lister les sessions actives

Register-IscsiSession -SessionIdentifier (Get-IscsiSession)[1].SessionIdentifier # faire d’une connexion iSCSI en persistente

[/powershell]

Pour tout savoir sur les cmdlets Windows Server 2012, rendez-vous ici.

Les versions les plus récentes de Windows Server (2008 R2 et 2012 pour être précis) n’utilisent plus cette convention au moment du formatage de nouveaux volumes. Néanmoins lors de migration sans reformatage, on continuera à se trainer cette convention de nommage. Microsoft a publié un benchmark intéressant:

Voici un exemple sur ma propre configuration:

Voyons les différents états du registre:

• 0 – Création de noms 8.3 activé sur tous les volumes du système
• 1 – Désactiver la création de noms 8.3 sur tous les volumes du système
• 2 – Création de noms 8.3 par volume
• 3 – Désactiver la création de noms 8.3 sur tous les volumes à l’exception du volume système

La clé de registre affectée est la suivante HKLM\System\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation

Lorsqu’un volume est spécifié l’opération met à jour le volume individuel. Cette opération est significative que si la valeur de Registre est définie sur 2, c’est à dire que vous devez définir le comportement du système de fichiers par défaut à 2 avant d’activer ou de désactiver le 8.3 sur un volume donné.

• 0 – Création de noms 8.3 activer sur ce volume
• 1 – Désactiver la création de noms 8.3 sur ce volume

Un redémarrage est nécessaire pour Windows Server 2003 et 2003 R2 uniquement.

Désactivation sur le volume:

[powershell]
fsutil 8dot3name set 1
[/powershell]

Désactivation sur le disque C:
[powershell]
fsutil 8dot3name set C: 1
[/powershell]

Toute la syntaxe de FSUTIL ici.

Ce mécanisme de cache sera donc plus efficace dans des scénarios où les lectures sont prédominantes, typiquement des usages VDI mais également pour réduire « les tempêtes » de démarrage de VMs, Scale-Out File Servers, … Microsoft recommande de l »utiliser pour tous vos scénarios, a noter qu’il désactivé par défaut ! Une présentation au TechEd a démontré des gains de performances très appréciables dans un environnement VDI. Le test a été réalisé sur 5120 VMs dans un cluster 16 noeuds avec 320 VMs par noeud, le temps de boot est ainsi passé de 211 secondes à seulement 29 dont 90% bootent en moins de 40 secondes !

La recommandation Microsoft est d’attribuer 20% de la mémoire totale au CSV-Cache, les test Microsoft ont démontrés qu’à partir de 512 Mo les résultats sont déjà très bons (meilleur rapport coût ressource/performance), c’est d’ailleurs la valeur par défaut Bien entendu, selon votre pattern I/O ou votre charge (workload) vous pouvez augmenter cette valeur.

Le site YUSUFOZTRUK.INFO a réalisé des benchmarks à l’aide de IOMTER sur une VM avec un cache de 4 Go et sans, les résultats sont bons malgré l’usage d’une seule VM ! Un autre benchmark est disponible ici.

Voici les commandes pour définir la taille du cache de la fonctionnalité CSV-Cache:

[powershell]

(Get-Cluster). SharedVolumeBlockCacheSizeInMB = 512

[/powershell]

Ensuite, il convient de l’activer à l’aide de cette commande:

[powershell]
Get-ClusterSharedVolume “Votre disque cluster” | Set-ClusterParameter  CsvEnableBlockCache 1
[/powershell]

Versions

• CIFS – Microsoft Windows NT 4.0
• SMB 1.0  – Windows 2000, Windows XP, Windows Server 2003 et Windows Server 2003 R2
• SMB 2.0  – Windows Vista (SP1) et Windows Server 2008
• SMB 2.1  –  Windows 7 et Windows Server 2008 R2
• SMB 3.0 (ou SMB2.2) – Windows 8 and Windows Server 2012

L’historique

• De SMB 1.0 à SMB 2.0 – Redesign majeur
  • Increased file sharing scalability
  • Performances accrues
    • Request compounding
    • Asynchronous operations
    • Larger reads/writes
  • Plus sécurisé et robuste
    • Small command set
    • Signing now uses HMAC SHA-256 instead of MD5
    • SMB2 durability
• De SMB 2.0 à SMB 2.1
  • File leasing improvements
  • Support MTU large
  • BranchCache
• From SMB 2.1 to SMB 3.0
  • Disponibilité
    • SMB Transparent Failover
    • SMB Witness
    • SMB Multichannel
  • Performances
    • SMB Scale-Out
    • SMB Direct (SMB 3.0 over RDMA)
    • SMB Multichannel
    • Directory Leasing
    • BrachCache V2
  • Sauvegarde
    • VSS pour Remote File Shares
  • Sécurité
    • Encryption SMB
  • o Management
    • SMB PowerShell
    • Compteurs de Performances améliorés
    • Evénements améliorés

Correspondance client/serveur

Vérifier la version SMB employée

Il convient de lancer la commande suivante:

Pour en  savoir davantage, rendez-vous ici et ici.

Windows Server 2012 R2 propose des nouvelles fonctionnalités et améliorations à travers de la virtualisation, stockage, réseaux, infrastructure de bureau virtuel, accès et protection de l’information.

Les nouvelles fonctionnalités et améliorations permettent aux clients de profiter de meilleures performances et d’une utilisation plus efficace de la capacité du centre de données, aide à accroître la réactivité de votre entreprise. Windows Server 2012 R2 offre une plateforme de cloud et virtualisation, qui s’adapte pour exécuter continuellement les charges de travail plus importantes tout en permettant aux options de récupération robuste pour protéger contre les pannes de service.

Windows Server 2012 R2 supportera 320 processeurs logiques, 4 To de mémoire, 1024 VM par hôte, 64 noeuds et 8000 VM par cluster, 64 To de disque virtuel ! Le décor est planté…

Les performances de Windows Server 2012 R2 passent à la vitesse supérieures: la compression de la migration en direct (Live Migration Compression) est une nouvelle fonctionnalité qui accélère la vitesse de transfert de la migration en direct en compressant les fichiers VHD / VHDX, l’amélioration des performances à peu près multiplié par 2x pour la plupart des charges de travail. Et la migration en direct avec RDMA est une autre nouvelle fonctionnalité de Windows Server 2012 R2, il offre les meilleures performances pour les migrations en direct sur des connexions réseau 10 Gbits, avec des vitesses de transfert allant jusqu’à 56 Go / s.

Une infrastructure Microsoft Exchange Server 2013 déployée sur douze machines virtuelles fonctionnant sur un seul serveur physique, a appuyé les exigences d’E / S à 48.000 utilisateurs simulés, les temps de réponse variaient entre 5,02 et 15,31 millisecondes, bien en dessous de la recommandation Microsoft limite de 20 millisecondes. Dans un autre cas de test, ESG Lab a pris un SQL Server 2012 OLTP. Le temps moyen de réponse des transactions sont également améliorées par cinq fois de quatre processeurs virtuels à 64 processeurs virtuels pour le cadre d’un déploiement SQL 2012.

Windows Server 2012 R2 propose désormais également des fichiers VHDX partagés. Les fichiers VHDX partagés peuvent être stockées sur un cluster de serveurs fichier scale-out ou sur un cluster CSV​​. Shared VHDX conserve également la mémoire dynamique, la migration en direct et la migration de  stockage en direct pour une machine virtuelle qui fait partie du groupe d’hôtes.

Grosse nouveauté de Windows Server 2012 R2, Hyper-V Replica permet maintenant de variables fréquences de réplication de 30 secondes jusqu’à 15 minutes. Une autre innovation autour de Windows Server 2012 R2 est Windows Azure Hyper-V Recovery Manager, un service connexe qui offre une solution de reprise qui tire parti de la technologie Hyper-V Replica.

La hiérarchisation du stockage, une nouvelle fonctionnalité de Windows Server 2012 R2, est un excellent exemple de la façon dont les performances de stockage peut être considérablement améliorée en utilisant du matériel standard de l’industrie à moindre coût.

Pleins d’autres nouveautés: Storage QoS, SMB Direct with RDMA, Dynamic Memory pour Linux, retrouvez un livre blanc ici.

Le phénomène de fragmentation s’explique du fait qu’une requête I/O s’exécute sur plusieurs blocs répartis sur différentes endroits du disque, on parle de bloc non contigus. Le but de la défragmentation est de réduire le temps de « voyage » sur les plateaux du disque (positionnement, lecture, continuation de la requête). Prenons un exemple simple, vous devez chercher un dossier de 4 classeurs dans votre bureau qui comporte 10 armoires espacées l’une de l’autre de 5 mètres, la fragmentation s’expliquerait de la façon suivante, vos 4 classeurs sont répartis dans 4 armoires différentes, il va falloir du temps pour constituer l’ensemble de dossier… La défragmentation consisterait à ranger ces 4 classeurs dans une même armoire, les uns à côté des autres Le gain de temps est considérable !

La taille de la mémoire cache des baies de stockage actuelles est telle que la fragmentation impacte peu les performances. Mais il faut savoir qu’une baie de stockage gère des blocs et est incapable de distinguer quelle I/O est relatif à telle donnée, et encore moins de répartir intelligemment les fragments sur la pile RAID, car la baie de stockage travaille avec de LUNs qui n’ont pas de rapport direct avec la géométrie des disques (plateaux, têtes, secteurs, …)

Un processus de défragmentation sur un disque local alourdit considérablement le travail du disque dur, sur une baie de stockage, cela va être encore pire ! Si vous décidez de défragmenter une partition située sur un RAID-5, tous les autres serveurs accédant à cette ressource seront pénalisés également. A noter que les logiciels de défragmentation agissent uniquement sur le système de fichier du serveur sur lesquel il est installé, et n’a même pas connaissance de quel autre serveur pourrait éventuellement être connecté sur le même LUN… La dégradation est performances peut être dramatique si la taille de la fragmentation est inférieure à la taille de stripe de votre RAID, car une I/O pourrait générer deux requêtes ! Première conclusion, une défragmentation doit être exécutée en dehors des plages de production !

La communauté est perplexe sur le fait qu’une défragmentation pourrait ou non avoir des effets positifs sur les performances. Pour ma part, je suis assez mitigé sur la question, un même RAID-5 pour être découpé en plusieurs LUNs que se partageraient le serveur, comment le processus de défragmentation serait capable de répartir les fragments d’un fichier sur plusieurs disques tout en tenant compte de la taille de stripe de la pile RAID, sachant que les contrôleurs des baies de stockage agissent au niveau bloc… Qui serait en mesure de prouver qu’une défragmentation assurait à coup sûr que les fragments serait répartis de façon optimale sur l’ensemble des disques d’une pile RAID ?

De même, la défragmentation sur les Pools de stockage virtuels ou volume Thin « Provisionné » serait inutile et non recommandé. Dans le premier cas, défragmenter un volume d’un pool contenant plusieurs RAID-10 n’apporterait rien car la couche physique et logique du système disque est complétement abstraite, elle est virtualisée, aucune corrélation entre les secteurs et les blocs ! De même que défragmenter un volume Thin « Provisionné » pourrait nuire à sa fonction première du fait que le processus allouerait inutilement des nouveaux secteurs !

J’amène une autre question sur le tapis: quid de l’Auto Tiering ? Certains algorithmes sont basés au niveau fichier, d’autre au niveau bloc, quoiqu’il en soit il ne faut pas défragmenter un type de volume, car une défragmentation pourrait promouvoir ou rétrograder une donnée inutilement. En principe les algorithmes font de la ré-allocation de façon intelligente et placent la donnée promue ou rétrogradée de façon optimale sur le système de disque approprié.

De la même façon, les volumes repliqués ne doivent pas être défragmentés, car une opération sur un site entraine la même sur l’autre site en plus des opérations de production, idem pour les volume CDP, car les journaux pourraient « exploser » ainsi que pour la déduplication.

Le schéma ci-dessus nous montre plusieurs choses:

• Un fichier VHD est crée sur l’ensemble de la stripe composant la pile RAID, la fragmentation est donc faible, mais techniquement nous pourrions parler de fragmentation du fait qu’il est réparti sur plusieurs disque au lieu d’un seul, mais en environnement SAN/RAID, il est bien plus optimal de lire d’un coup un stripe dans son ensemble ! (augmentation des débits, IOPS, …)
• Par contre, défragmenter « l’intérieur » d’un fichier VHD présenterait de l’intérêt mais n’agit qu’au niveau du système de fichier de la VM
• ce que nous montre ce schéma, et montre bien qu’une défragmentation apporte peu de chose, c’est qu’une donnée fragmentée ou non au niveau du système de fichiers peut être répartie d’un point de vue physique n’importe où sur le RAID, qui dépend de taille de stripe, chunk, etc…
• Néanmoins nous sommes tous d’accord sur le fait qu’une défragmentation consomme moins de ressources…

Certaines solutions, Diskeeper, avancent que leur technologie prends en compte les fonctions avancées des SAN, j’en pas convaincu, Windows ne voit qu’un type de partition et sa taille, mais n’a aucune idée des caractéristiques physiques du disque (IDE, SCSI, RAID, SAN) ! Comment peut t’il savoir qu’un RAID-5 est découpé en plusieurs LUNs ? Est-ce que Windows, lorsqu’il lit un fichier WORD, sait qu’il se trouve sur 3 des 5 disques composants la pile RAID, NON…  C’est pourtant leur promesse…

Pour conclure…

Les contrôleurs des baies de stockage ont déjà pour mission de répartir intelligemment et de façon optimale la localisation des blocs sur le système disque. De plus, la rapidité des disques (15.000 tours, SAS, NCQ, …), la taille des mémoire caches et autres optimisations gomment/diminuent les effets néfastes de la fragmentation.

En fait nous aurions 3 niveaux de fragmentation, à l’intérieur d’une VM, au niveau du VHD, et au niveau du RAID… Une défragmentation agirait beaucoup au niveau des blocs logiques sur l’ensemble des disques composant la pile RAID sans pour autant améliorer les performances, les blocs devant être accéder fréquemment pourraient être déplacés vers des secteurs lents.

L’idéal serait une solution qui ferait la corrélation entre les fichiers (logique) et les blocs au niveau SAN (physique). NetApp propose via sa commande reallocate de ré-allouer via un schedule les blocs !

La défragmentation est clairement nécessaire pour des systèmes DAS ou NAS, sachant que certaines technologies des éditeurs de solution de défragmentation jugent à la volée la rapidité des secteurs logiques avant de faire une ré-allocation des blocs… Pour le reste, j’estime que ce n’est pas nécessaire contrairement à tous les arguments marketing de certains éditeurs, à moins de me convaincre des points évoqués ci-dessus

Voici quelques éléments de réponse complémentaires concernant VMWARE, Hyper-V, et SQL.

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.