EMC Mission-Critical Business Continuity for SAP 44
Oracle Grid Infrastructure
Dans Oracle Database 11g R2, Oracle Grid Infrastructure combine Oracle ASM et Oracle Clusterware en un ensemble de binaires distinctes du logiciel de la base de données. Cette infrastructure offre à présent le cluster et les services de stockage requis pour exécuter une base de données Oracle RAC.
Oracle Real Application Clusters 11g
Oracle RAC est principalement une solution haute disponibilité pour les applications de base de données Oracle dans le datacenter. Cette solution permet à plusieurs instances Oracle d’accéder à une base de données unique. Le cluster se compose d’un groupe de serveurs indépendants, fonctionnant
ensemble comme un système unique et partageant le même ensemble de
disques de stockage. Chaque instance s’exécute sur un serveur distinct du cluster.
RAC assure la haute disponibilité, l’évolutivité, la tolérance aux pannes, l’équilibrage de la charge et des gains de performances, et peut également supprimer tout point de défaillance unique de la solution de base de données.
Oracle Extended RAC
Oracle RAC sur clusters éloignés (Extended Distance Clusters), ou Oracle
Extended RAC, est une architecture qui permet aux serveurs du cluster de résider dans des emplacements physiques distincts. Ceci supprime le datacenter en tant que point unique de défaillance.
Oracle Extended RAC permet à tous les nœuds du cluster (indépendamment de leur emplacement) d’être actifs. Cette architecture assure une haute disponibilité et la continuité d’activité lors d’une panne réseau ou du site, comme suit :
• Le stockage et les données restent disponibles et actifs sur le site resté actif.
• Les services Oracle équilibrent la charge et basculent sur les nœuds Oracle RAC sur le site resté actif.
• Oracle Transparent Application Failover (TAF) permet aux sessions de basculer automatiquement vers les nœuds Oracle RAC sur le site resté actif.
• Les applications tierces gérées par Oracle Clusterware peuvent équilibrer la charge et basculer vers les nœuds Oracle RAC sur le site resté actif (par exemple, le processus httpd d’Apache ou de NFS).
• Les nœuds Oracle RAC du site resté actif continuent à traiter les transactions.
Oracle recommande d’utiliser l’architecture Oracle Extended RAC lorsque les deux datacenters sont relativement proches (à moins de 100 km l’un de l’autre)12. Oracle RAC s’exécute normalement dans un datacenter local en raison de l’impact potentiel de la latence entraînée par la distance et de la complexité qui en
découle, ainsi que des frais supplémentaires requis pour étendre Oracle RAC à tous les datacenters utilisant la mise en miroir basée sur l’hôte avec Oracle ASM.
Toutefois, avec EMC VPLEX Metro, un déploiement Oracle Extended RAC (du point de vue de l’administrateur de base de données Oracle) est une installation et une configuration Oracle RAC standard13.
12 Consultez le livre blanc Oracle : Oracle Real Application Clusters (RAC) on Extended Distance Clusters.
13 Consultez le livre blanc EMC : Oracle Extended RAC with EMC VPLEX Metro Best Practices Planning.
Oracle RAC et VPLEX
EMC Mission-Critical Business Continuity for SAP 46 Cette solution utilise quatre volumes ACFS montés sur le cluster Oracle RAC,
comme l’illustre la Tableau 8. Trois de ces volumes (SAPMNT, USRSAPTRANS et ASCS00) ont ensuite été exportés en tant que partages NFS vers les serveurs SAP, à l’aide d’une adresse IP virtuelle et d’une ressource NFS haute disponibilité gérées par Oracle Clusterware.
Tableau 8. Volumes Oracle ACFS et points de montage
Volume ACFS Taille (Go) Point de montage Description
SAP_O_HOME 16 /oracle/VSE/112 ORACLE_HOME pour base de données VSE, partagé sur tous les nœuds Oracle RAC
SAPMNT 16 /sapmnt/VSE Répertoire global SAP (où sont stockés les noyaux, profils, etc.) partagé sur toutes les machines virtuelles SAP
USRSAPTRANS 16 /usr/sap/trans Répertoire de transport SAP (où sont stockés les fichiers de transport) partagé sur toutes les machines virtuelles SAP Dialog Instance
ASCS00 16 /usr/sap/VSE/
ASCS00 Répertoire d’instance SAP ASCS (où sont stockés les fichiers liés aux instances) partagé sur les nœuds du cluster SUSE Linux Enterprise High Availability Extension
La Figure 41 fournit une représentation logique du déploiement d’Oracle Extended RAC sur VPLEX Metro pour la solution.
Configuration Oracle ACFS
Oracle Extended RAC sur VPLEX Metro
Figure 41. Oracle Extended RAC sur EMC VPLEX Metro
Les groupes de disques ASM de stockage ont été configurés de manière à refléter l’organisation de la base de données Oracle d’instance unique existante. Le Tableau 9 présente la configuration et l’organisation des groupes de disques ASM.
Tableau 9. Taille et configuration des groupes de disques Oracle ASM Groupe de disques
ASM*
Nombre de disques
Taille du groupe de
disques (Go) Redondance
OCR 5 40 Normale
EA_SAP_ACFS 4 64 Externe
EA_SAP_DATA 16 2 048 Externe
EA_SAP_REDO 4 64 Externe
EA_SAP_REDOM 4 64 Externe
EA_SAP_FRA 4 256 Externe
* Le préfixe EA_SAP_ est uniquement utilisé pour identifier les groupes de disques ASM associés à l’application SAP dans Extended Oracle RAC.
Configuration des groupes de disques Oracle ASM
EMC Mission-Critical Business Continuity for SAP 48 Dans le cadre de la solution, le processus en deux étapes suivant a permis de
migrer la base de données d’instance unique d’origine vers un cluster Oracle RAC sur ASM (voir Figure 42) :
1. Migrez la base de données du système de fichiers vers ASM en utilisant la méthode de duplication à partir de la base de données active d’Oracle Recovery Manager (RMAN).
2. Convertissez la base de données vers Oracle RAC à l’aide de l’utilitaire rconfig d’Oracle.
Figure 42. Processus de migration en deux étapes d’une base de données Oracle Ce processus en deux étapes suit les consignes fournies dans les livres blancs Oracle suivants :
• Moving your SAP Database to Oracle Automatic Storage Management 11g Release 2: A Best Practices Guide
• Configuration of SAP NetWeaver for Oracle Grid Infrastructure 11.2.0.2 and Oracle Real Application Clusters 11g Release 2: A Best Practices Guide Préparation des systèmes source et cible pour la duplication de la base de données Le Tableau 10 indique comment préparer les systèmes source et cible avant de procéder à la duplication de la base de données.
Tableau 10. Étapes de préparation des systèmes source et cible Préparation du système source
1 Assurez-vous que les principales variables d’environnement sont définies : ORACLE_SID, ORACLE_BASE et ORACLE_HOME.
2 Assurez-vous qu’une entrée tnsnames.ora est configurée pour les bases de données source et cible/auxiliaire à des fins d’utilisation lors de la duplication.
3 Assurez-vous que le fichier de mot de passe Oracle est configuré.
4 Assurez-vous que le paramètre compatible est défini sur 11.2.0.2.0 ou version supérieure.
Processus de migration de base de données Oracle
Préparation du système cible
1 Assurez-vous qu’Oracle Clusterware est disponible sur le nœud Oracle RAC local et que l’instance ASM est accessible.
2 Assurez-vous que les principales variables d’environnement sont définies : ORACLE_SID, ORACLE_BASE et ORACLE_HOME.
3 Assurez-vous qu’une entrée tnsnames.ora est configurée pour les bases de données source et cible/auxiliaire à des fins d’utilisation lors de la duplication.
4 Assurez-vous que le fichier de mot de passe Oracle est configuré.
5 Créez un fichier spfile sur le système cible pour les besoins de la duplication.
Dans le cadre de cette solution, les valeurs par défaut des paramètres suivants ont été modifiées :
*.db_domain='sse.ea.emc.com'
*.db_name='VSE'
*.db_create_file_dest='+EA_SAP_DATA'
*.db_create_online_log_dest_1='+EA_SAP_REDO'
*.db_create_online_log_dest_2='+EA_SAP_REDOM'
*.db_recovery_file_dest='+ES_SAP_FRA'
*.db_recovery_file_dest_size=53445918720
*.log_archive_format='VSEARC%t_%s_%r.dbf'
*.control_files='+EA_SAP_DATA/vse/cntrlVSE1.ctl', '+EA_SAP_REDO/vse/cntrlVSE2.ctl',
'+EA_SAP_REDOM/vse/cntrlVSE3.ctl'
*.log_file_name_convert=
'/oracle/VSE/origlogA/log_g11m1.dbf','+EA_SAP_REDO', '/oracle/VSE/mirrlogA/log_g11m2.dbf','+EA_SAP_REDOM', '/oracle/VSE/origlogB/log_g12m1.dbf','+EA_SAP_REDO', '/oracle/VSE/mirrlogB/log_g12m2.dbf','+EA_SAP_REDOM', '/oracle/VSE/origlogA/log_g13m1.dbf','+EA_SAP_REDO', '/oracle/VSE/mirrlogA/log_g13m2.dbf','+EA_SAP_REDOM', '/oracle/VSE/origlogB/log_g14m1.dbf','+EA_SAP_REDO', '/oracle/VSE/mirrlogB/log_g14m2.dbf','+EA_SAP_REDOM'
Remarque : par défaut, les logs d’archive sont écrits dans la zone FRA.
6 Démarrez l’instance cible en mode nomount :
SQL> connect sys/XXXXXXXXX@DUPVSE as SYSDBA Connected to an idle instance.
SQL> startup nomount
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
Oracle instance started
Total System Global Area 10689474560 bytes Fixed Size 2237776 bytes Variable Size 1644169904 bytes Database Buffers 8992587776 bytes Redo Buffers 50479104 bytes SQL>
EMC Mission-Critical Business Continuity for SAP 50 Migration de la base de données du système de fichiers vers ASM
La migration de la base de données vers ASM implique la création à l’aide de RMAN d’une instance en double sous ASM sur le système cible :
1. Démarrez RMAN, puis connectez les bases de données source (cible dans RMAN) et cible (auxiliaire dans RMAN) en tant que sys.
2. Exécutez les commandes RMAN indiquées sur la Figure 43.
connect target sys/xxxxxxx@ORGVSE connect auxiliary sys/xxxxxxxx@DUPVSE1 run {
ALLOCATE CHANNEL t1 DEVICE TYPE disk;
ALLOCATE CHANNEL t2 DEVICE TYPE disk;
ALLOCATE CHANNEL t3 DEVICE TYPE disk;
ALLOCATE CHANNEL t4 DEVICE TYPE disk;
ALLOCATE CHANNEL t5 DEVICE TYPE disk;
ALLOCATE CHANNEL t6 DEVICE TYPE disk;
ALLOCATE CHANNEL t7 DEVICE TYPE disk;
ALLOCATE CHANNEL t8 DEVICE TYPE disk;
ALLOCATE AUXILIARY CHANNEL a1 DEVICE TYPE disk;
duplicate target database to VSE
from active database nofilenamecheck;
}
Figure 43. Exemple de script de duplication RMAN
Dans l’environnement de la solution, la génération d’un réplica de l’instance unique dynamique de la base de données de 500 Go a pris 18 minutes à l’aide de cette méthode, comme indiqué sur la Figure 44.
Recovery Manager: Release 11.2.0.3.0 - Production on Fri Mar 2 09:39:33 2012
... ..
. contents of Memory Script:
{ Alter clone database open resetlogs;
} executing Memory Script database opened
Finished Duplicate Db at 02-MAR-2012 09:57:37 Figure 44. Extrait du fichier log du script RMAN
Validation de la migration
Une fois la migration terminée, il est important de valider le déplacement des fichiers de données, des fichiers redo log en ligne et des fichiers de contrôle, et de vérifier que la duplication n’a pas entraîné de corruption de données. La Figure 45 illustre le script RMAN utilisé pour valider la migration de la base de données pour la solution.
run {
ALLOCATE CHANNEL t1 DEVICE TYPE disk;
ALLOCATE CHANNEL t2 DEVICE TYPE disk;
ALLOCATE CHANNEL t3 DEVICE TYPE disk;
ALLOCATE CHANNEL t4 DEVICE TYPE disk;
ALLOCATE CHANNEL t5 DEVICE TYPE disk;
ALLOCATE CHANNEL t6 DEVICE TYPE disk;
ALLOCATE CHANNEL t7 DEVICE TYPE disk;
ALLOCATE CHANNEL t8 DEVICE TYPE disk;
ALLOCATE CHANNEL t9 DEVICE TYPE disk;
ALLOCATE CHANNEL t10 DEVICE TYPE disk;
validate database;}
Figure 45. Exemple de script de validation de base de données RMAN
Le temps de traitement de ce script de validation est d’environ cinq minutes.
Figure 46 illustre le résultat du script de validation RMAN pour l’un des fichiers de données clonés dans la base de données VSE.
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- --- --- --- --- --- 18 OK 0 97439 1280000 21966205 File Name: +EA_SAP_DATA/vse/datafile/psapsr3.259.776893807 Block Type Blocks Failing Blocks Processed
--- --- --- Data 0 786620
Index 0 347303 Other 0 48638
Figure 46. Résultat de la commande de validation de base de données RMAN Tâches postérieures à la duplication
Dès lors que la duplication est terminée et validée, il est nécessaire de créer un nouveau fichier spfile sur le système cible dans le cadre du processus postérieur à la duplication. La Figure 47 illustre la création du fichier spfile pour la solution ; un seul paramètre pointe du fichier pfile vers le fichier spfile.
SQL> alter system reset log_file_name_convert;
System altered.
SQL> create pfile='/home/oracle/initVSE.ora_gen' from memory;
File created.
SQL> REM check and change Oracle instance parameters as required SQL> !vi /home/oracle/initVSE.ora_gen
SQL> create SPFILE='+EA_SAP_DATA/VSE/spfileVSE.ora' from pfile='/home/oracle/initVSE.ora_gen';
File created.
Figure 47. Recréation du fichier spfile
EMC Mission-Critical Business Continuity for SAP 52 Conversion de la base de données d’instance unique vers Oracle RAC
Une fois le réplica de base de données, le fichier spfile et le fichier pfile créés, et la base de données non encore enregistrée auprès d’Oracle Clusterware, la base de données d’instance unique est démarrée à l’aide de sqlplus. Elle est prête pour être convertie par rconfig vers Oracle RAC :
1. Créez un fichier d’instructions rconfig pour les besoins de la conversion.
Dans le cadre de la solution, ce fichier a été créé à l’aide du modèle ConvertToRAC_AdminManaged.xml (situé dans le répertoire
$ORACLE_HOME/assistants/rconfig/sampleXMLs). Le Tableau 11 dresse la liste des paramètres et des valeurs associées requises.
Tableau 11. Valeurs requises pour les paramètres contenus dans le fichier d’instructions rconfig
Paramètre Valeur
Convert verify "YES"
SourceDBHome /oracle/VSE/112 TargetDBHome /oracle/VSE/112 SourceDBInfo SID "VSE"
User Sys
Password xxxxxxxxx
Role Sysdba
Node name <n:NodeList>
<n:Node name="sse-ea-erac-n01"/>
<n:Node name="sse-ea-erac-n02"/>
<n:Node name="sse-ea-erac-n03"/>
<n:Node name="sse-ea-erac-n04"/> </n:NodeList>
InstancePrefix VSE00*
SharedStorage type "ASM"
* Ce préfixe est conforme aux exigences SAP de convention de dénomination des instances Oracle.
2. Exécutez rconfig en tant qu’utilisateur Oracle.
Le temps de traitement de la conversion de la base de données et du déploiement des quatre instances sur le cluster est de 11 minutes. La Figure 48 illustre le résultat de rconfig.
oracle@sse-ea-erac-n01:~> rconfig ./VSE.xml
Converting Database "VSE.sse.ea.emc.com" to Cluster Database. Target Oracle Home: /oracle/VSE/112. Database Role: PRIMARY.
Setting Data Files and Control Files Adding Database Instances
Adding Redo Logs
Enabling threads for all Database Instances Setting TEMP tablespace
Adding UNDO tablespaces Adding Trace files
Setting Fast Recovery Area Updating Oratab
Creating Password file(s) Configuring Listeners
Configuring related CRS resources Starting Cluster Database
<?xml version="1.0" ?>
<RConfig version="1.1" >
<ConvertToRAC>
<Convert>
<Response>
<Result code="0" >
Operation Succeeded </Result>
</Response>
<ReturnValue type="object">
<Oracle_Home>
/oracle/VSE/112 </Oracle_Home>
<Database type="ADMIN_MANAGED" >
<InstanceList>
<Instance SID="VSE001" Node="sse-ea-erac-n01" >
</Instance>
<Instance SID="VSE002" Node="sse-ea-erac-n02" >
</Instance>
<Instance SID="VSE004" Node="sse-ea-erac-n03" >
</Instance>
<Instance SID="VSE003" Node="sse-ea-erac-n04" >
</Instance>
</InstanceList>
</Database> </ReturnValue>
</Convert>
</ConvertToRAC></RConfig>
Figure 48. Résultat de rconfig présentant les quatre nouvelles instances créées Standardisation d’Oracle RAC pour SAP
Une fois la base de données convertie, les modifications indiquées dans le Tableau 12 ont permis de rendre la base de données Oracle conforme aux exigences SAP.
Tableau 12. Mise en conformité de la base de données Oracle aux exigences SAP Description Nom de l’instance Modifications apportées Groupe de fichiers redo
log en ligne
VSE001 VSE002 VSE003 VSE004
Groupes de fichiers redo log 11 à 14 Groupes de fichiers redo log 21 à 24 Groupes de fichiers redo log 31 à 34 Groupes de fichiers redo log 41 à 44
EMC Mission-Critical Business Continuity for SAP 54 Description Nom de l’instance Modifications apportées
Annulation de la dénomination des tablespaces
VSE001 VSE002 VSE003 VSE004
PSAPUNDO PSAPUNDO_002 PSAPUNDO_003 PSAPUNDO_004
Listener.ora Ajout au fichier listener.ora de la ligne suivante sur chaque nœud, où VSE00x correspond au nom de l’instance pour ce nœud :
SID_LIST_LISTENER =
(SID_LIST=(SID_DESC=(SID_NAME=VSE00x) (ORACLE_HOME=/oracle/VSE/112)))
Connexion à Oracle RAC à partir de SAP
Pour permettre à SAP de se connecter à la base de données RAC que vous venez de créer, le fichier tnsnames.ora situé sur chacune des machines virtuelles SAP (SAPDI1 et SAPDI2) a été modifié, comme l’illustre la Figure 49. Les services SAP ont ensuite été redémarrés.
VSE.WORLD=
(DESCRIPTION =
(LOAD_BALANCE = OFF) (FAILOVER = ON) (ADDRESS_LIST = (ADDRESS =
(PROTOCOL = TCP)
(HOST = sse-ea-erac-scan-c01.sse.ea.emc.com) (PORT = 1521)
) )
(CONNECT_DATA =
(SERVICE_NAME = VSE.sse.ea.emc.com) (FAILOVER_MODE =
(TYPE = SELECT) (METHOD = BASIC)) )
)
Figure 49. Exemple d’entrée de fichier tnsnames.ora pour la base de données Oracle RAC TAF (Transparent Application Failover) est une fonction côté client qui permet aux clients de se reconnecter aux instances restées actives en cas de panne d’une instance de base de données. TAF peut être définie à l’aide d’une chaîne de connexion spécifiée côté client ou d’attributs de service côté serveur.
Dans le cadre de la solution, le service de base de données VSE.sse.ea.emc.com a été configuré pour TAF sur Oracle RAC. Il a également été configuré côté client pour permettre à SAP d’utiliser TAF. La fonction TAF a été définie pour établir des connexions lors du basculement sur incident et pour permettre aux utilisateurs ayant recours à des curseurs ouverts de poursuivre l’extraction après l’échec des opérations sélectionnées.
Infrastructure réseau Brocade
Présentation
Cette section décrit les réseaux IP et SAN déployés pour la solution dans les deux datacenters, ainsi que l’extension Layer 2 entre les datacenters.
L’infrastructure du réseau est constituée des composants Brocade suivants :
•
•
•
•
Brocade VDX 6720
Le switch pour datacenter Brocade VDX 6720 est un switch de port fixe hautes performances, à latence extrêmement faible et à vitesse câblée de 10 GbE. Il est spécialement conçu pour améliorer l’utilisation du réseau, optimiser la
disponibilité des applications, accroître l’évolutivité et simplifier drastiquement l’architecture réseau des datacenters virtualisés. Disposant de nombreuses fonctions Layer 2, Brocade VDX 6720 est une plate-forme idéale pour les déploiements de switches ToR (Top-of-Rack).
En fournissant la technologie Brocade VCS Fabric, Brocade VDX 6720 permet aux entreprises de concevoir un fabric Ethernet de datacenter, révolutionnant la conception des réseaux Layer 2, et proposant une base intelligente pour les datacenters optimisés pour le Cloud.
Gamme Brocade MLX
Les routeurs de la gamme Brocade MLX sont conçus pour créer des réseaux
optimisés pour le Cloud. Ils offrent une densité de vitesse câblée de 100 GbE, 10 GbE et 1 GbE ; de riches fonctionnalités IPv4, IPv6, Multi-VRF, MPLS (Multiprotocol Label Switching) et Carrier Ethernet, ainsi que des switches Layer 2 avancés.
En tirant parti de la gamme Brocade MLX, les datacenters critiques peuvent prendre en charge davantage de trafic, parvenir à une meilleure virtualisation et fournir des services basés sur le Cloud de haute qualité en utilisant moins
d’infrastructure, ce qui permet de simplifier les opérations et de réduire les coûts.
De plus, les routeurs de la gamme Brocade MLX simplifient les réseaux des grands campus en réduisant les couches d’agrégation et centrale, ainsi qu’en fournissant une connectivité entre les sites à l’aide de MPLS/VPLS. Tous les routeurs de la gamme Brocade MLX permettent de réduire les coûts
d’alimentation et de refroidissement grâce à la faible consommation électrique et à la dissipation thermique de leur classe.
Conçus pour une mise en réseau sans interruption, les routeurs de la gamme Brocade MLX disposent du Multi-Chassis Trunking (MCT), qui fournit plus de 30 To/s de bande passante à double châssis, des liaisons de routage en mode entièrement actif/actif et un flux de trafic ininterrompu en cas de basculement du nœud. Les entreprises peuvent atteindre une résilience élevée grâce aux fabrics de switch redondants, aux modules de gestion, aux alimentations et aux systèmes de refroidissement. Pour garantir davantage la disponibilité des applications et du réseau, le système d’exploitation Brocade IronWare propose des fonctions de basculement de gestion et de mises à niveau logicielles sans perturbation.
Introduction
Réseau IP
• Switches de datacenter Brocade VDX 6720
• Routeurs de la gamme Brocade MLX
• Adaptateurs CNA Brocade 1020
Réseau SAN
• Backbones Brocade DCX 8510
• Adaptateurs HBA Brocade 825
EMC Mission-Critical Business Continuity for SAP 56 Backbone Brocade DCX 8510
Les réseaux doivent évoluer pour prendre en charge les exigences croissantes des environnements hautement virtualisés et des architectures de Cloud privé.
Aujourd’hui, Fibre Channel (FC) est la norme de facto pour la mise en réseau du stockage dans le datacenter. L’introduction de Fibre Channel 16 Gbit/s prolonge la vie de cette technologie robuste, fiable et hautes performances. FC permet aux entreprises de continuer à tirer profit de leurs investissements informatiques existants lorsqu’elles relèvent leurs défis métiers les plus difficiles.
Les backbones Brocade DCX 8510 constituent l’infrastructure de switches Fibre Channel 16 Gbit/s la plus puissante du secteur. En outre, ils fournissent la base hautes performances la plus fiable et évolutive pour le stockage de Cloud privé et les environnements hautement virtualisés. Ils sont conçus pour améliorer la réactivité tout en fournissant un accès ininterrompu aux informations et en réduisant les coûts d’infrastructure et d’administration.
La fonction FC de 16 Gbit des systèmes Brocade DCX 8510 offre des avantages importants pour la connectivité SAN Metro de datacenter à datacenter :
• Sa capacité de 16 Gbit offre le débit maximal et la latence FC la plus basse pour les déploiements utilisant des connexions par fibre entre datacenters.
• Vitesse filaire FC de 10 Gbit facultative pour un taux d’utilisation filaire optimal si un réseau DWDM est déployé entre plusieurs sites. Cette fonction nécessite une licence.
• Trunking ISL (Inter-Switch Link) facultatif au niveau de la trame permettant un taux d’utilisation élevé par rapport au trunking DPS standard. Cette fonction nécessite une licence.
• Compression facultative pour les ISL entre les datacenters. Elle augmente la bande passante pour les déploiements où le nombre de connexions de site à site est limité.
• Chiffrement des données à la volée facultatif pour les ISL entre les
datacenters pour les déploiements nécessitant des niveaux de sécurité des données très élevés.
• Détection de la perte de buffer credit et restauration.
• FEC (Forward Error Correction) automatique, qui corrige proactivement jusqu’à 11 erreurs de bit par trames FC de 2 112 bits.
• Le mode de diagnostic pour les ports ISL entre les datacenters peut être utilisé sur n’importe quel port ISL (hors ligne) et offre les fonctions suivantes :
tests de boucles optiques et électriques ;
tests de la saturation des liaisons ;
précision de la mesure de la distance de liaison à 5 m près lors d’une utilisation avec SFP+ 8 Gbit et à 50 m près avec SFP+ 10 GbE.