Fibre Channel vs iSCSI: la guerre continue

Au début, il y avait Fibre Channel (FC), et c'était bien. Si vous vouliez un vrai SAN - plutôt qu'un stockage SCSI à connexion directe partagé - FC est ce que vous avez. Mais FC était terriblement cher, nécessitant des commutateurs dédiés et des adaptateurs de bus hôte, et il était difficile à prendre en charge dans des environnements géographiquement répartis. Puis, il y a environ six ou sept ans, iSCSI a frappé le marché des PME de façon considérable et a lentement commencé sa montée dans l'entreprise.

Le temps écoulé a vu beaucoup de querelles mal informées pour savoir lequel est le meilleur. Parfois, le débat iSCSI-vs-FC a atteint le niveau d'une guerre de religion.

[Aussi sur .com: Téléchargez la plongée en profondeur d'archivage de Logan Harbaugh et obtenez les principes fondamentaux de la conformité réglementaire. | Découvrez comment la déduplication des données peut ralentir la croissance explosive des données avec le rapport Deep Dive de Keith Schultz. ]

Cette bataille a été le résultat de deux facteurs principaux: Premièrement, le marché du stockage était divisé entre les grands fournisseurs de stockage en place qui avaient fait un investissement important dans le marketing FC contre des fournisseurs plus jeunes proposant des offres à faible coût et uniquement iSCSI. Deuxièmement, les administrateurs ont tendance à aimer ce qu'ils savent et à se méfier de ce qu'ils n'aiment pas. Si vous exécutez des SAN FC depuis des années, vous êtes susceptible de croire que l'iSCSI est une architecture lente et peu fiable et qu'il mourrait plus tôt que d'exécuter un service critique dessus. Si vous exécutez des SAN iSCSI, vous pensez probablement que les SAN FC sont extrêmement coûteux et difficiles à installer et à gérer. Ni l'un ni l'autre n'est entièrement vrai.

Maintenant que nous sommes environ un an en bas du pique après la ratification de la norme FCoE (FC over Ethernet), les choses ne vont pas beaucoup mieux. De nombreux acheteurs ne comprennent toujours pas les différences entre les normes iSCSI et Fibre Channel. Bien que le sujet puisse facilement remplir un livre, voici un bref aperçu.

Les fondamentaux du FC

FC est une architecture de réseau de stockage dédiée qui a été normalisée en 1994. Aujourd'hui, elle est généralement implémentée avec des HBA (adaptateurs de bus hôte) et des commutateurs dédiés - ce qui est la principale raison pour laquelle FC est considérée comme plus chère que les autres technologies de réseau de stockage.

En ce qui concerne les performances, il est difficile de battre la faible latence et le débit élevé de FC, car FC a été conçu à partir de zéro pour gérer le trafic de stockage. Les cycles de traitement nécessaires pour générer et interpréter les trames FCP (protocole Fibre Channel) sont entièrement déchargés vers des HBA dédiés à faible latence. Cela libère le processeur du serveur pour gérer les applications plutôt que de parler au stockage.

FC est disponible à des vitesses de 1 Gbit / s, 2 Gbit / s, 4 Go / s, 8 Gbit / s, 10 Gbit / s et 20 Gbit / s. Les commutateurs et les appareils qui prennent en charge les vitesses de 1 Gbps, 2 Gbps, 4 Gbps et 8 Gbps sont généralement rétrocompatibles avec leurs frères plus lents, tandis que les appareils 10 Gbps et 20 Gbps ne le sont pas, en raison du fait qu'ils utilisent un mécanisme de codage de trame différent (ces deux sont généralement utilisés pour les liaisons inter-commutateurs).

De plus, FCP est également optimisé pour gérer le trafic de stockage. Contrairement aux protocoles qui s'exécutent sur TCP / IP, FCP est un protocole à usage unique beaucoup plus fin qui se traduit généralement par une latence de commutation plus faible. Il comprend également un mécanisme de contrôle de flux intégré qui garantit que les données ne sont pas envoyées à un périphérique (stockage ou serveur) qui n'est pas prêt à les accepter. D'après mon expérience, vous ne pouvez pas obtenir la même faible latence d'interconnexion avec aucun autre protocole de stockage existant aujourd'hui.

Pourtant, FC et FCP ont des inconvénients - et pas seulement des coûts élevés. La première est que la prise en charge de l'interconnectivité du stockage sur de longues distances peut être coûteuse. Si vous souhaitez configurer la réplication vers une baie secondaire sur un site distant, soit vous avez la chance de vous offrir la fibre noire (si elle est disponible), soit vous devrez acheter des passerelles de distance FCIP coûteuses.

En outre, la gestion d'une infrastructure FC nécessite un ensemble de compétences spécialisées, ce qui peut poser un problème aux administrateurs. Par exemple, le zonage FC fait un usage intensif de longs noms hexadécimaux de nœuds et de ports mondiaux (similaires aux adresses MAC dans Ethernet), ce qui peut être difficile à gérer si des modifications fréquentes sont apportées à la structure.

L'essentiel sur iSCSI

iSCSI est un protocole de réseau de stockage construit sur le protocole de réseau TCP / IP. Ratifié en tant que norme en 2004, la plus grande renommée de l'iSCSI est qu'il fonctionne sur le même équipement de réseau qui gère le reste du réseau de l'entreprise. Il ne nécessite pas spécifiquement de matériel supplémentaire, ce qui le rend relativement peu coûteux à mettre en œuvre.

Du point de vue des performances, iSCSI est en retard sur FC / FCP. Mais lorsque iSCSI est correctement implémenté, la différence se résume à quelques millisecondes de latence supplémentaire en raison de la surcharge requise pour encapsuler les commandes SCSI dans le protocole de réseau TCP / IP à usage général. Cela peut faire une énorme différence pour des charges d'E / S transactionnelles extrêmement élevées et est la source de la plupart des affirmations selon lesquelles iSCSI n'est pas adapté à une utilisation dans l'entreprise. De telles charges de travail sont rares en dehors du Fortune 500, cependant, dans la plupart des cas, le delta des performances est beaucoup plus étroit.

iSCSI place également une charge plus importante sur le processeur du serveur. Bien qu'il existe des HBA iSCSI matériels, la plupart des implémentations iSCSI utilisent un initiateur logiciel - chargeant essentiellement le processeur du serveur avec la tâche de créer, d'envoyer et d'interpréter les commandes de stockage. Cela a également été utilisé comme un argument efficace contre iSCSI. Cependant, étant donné que les serveurs d'aujourd'hui sont souvent livrés avec beaucoup plus de ressources CPU que la plupart des applications ne peuvent espérer utiliser, les cas où cela fait toute sorte de différence substantielle sont rares.

L'iSCSI peut se démarquer avec FC en termes de débit grâce à l'utilisation de plusieurs liaisons Ethernet 1 Gbit / s ou Ethernet 10 Gbit / s. Il a également l'avantage d'être TCP / IP dans la mesure où il peut être utilisé sur de grandes distances via les liaisons WAN existantes. Ce scénario d'utilisation est généralement limité à la réplication SAN vers SAN, mais il est nettement plus facile et moins coûteux à implémenter que les alternatives FC uniquement.

Outre les économies réalisées grâce à la réduction des coûts d'infrastructure, de nombreuses entreprises trouvent l'iSCSI beaucoup plus facile à déployer. Une grande partie des compétences requises pour mettre en œuvre iSCSI chevauche celle de l'exploitation générale du réseau. Cela rend iSCSI extrêmement attrayant pour les petites entreprises avec un personnel informatique limité et explique en grande partie sa popularité dans ce segment.

Cette facilité de déploiement est une arme à double tranchant. Étant donné que iSCSI est facile à mettre en œuvre, il est également facile à mettre en œuvre de manière incorrecte. L'échec de la mise en œuvre à l'aide d'interfaces réseau dédiées, pour assurer la prise en charge des fonctionnalités de commutation telles que le contrôle de flux et le tramage jumbo, et pour implémenter les E / S multitrajets sont des erreurs courantes qui peuvent entraîner des performances médiocres. Les histoires abondent sur les forums Internet de déploiements iSCSI infructueux qui auraient pu être évités en raison de ces facteurs.

Fibre Channel sur IP

FCoIP (Fibre Channel over Internet Protocol) est un protocole de niche qui a été ratifié en 2004. Il s'agit d'une norme d'encapsulation de trames FCP dans des paquets TCP / IP afin qu'elles puissent être expédiées sur un réseau TCP / IP. Il est presque exclusivement utilisé pour le pontage des structures FC sur plusieurs sites afin de permettre la réplication et la sauvegarde SAN vers SAN sur de longues distances.

En raison de l'inefficacité de la fragmentation de grandes trames FC en plusieurs paquets TCP / IP (les circuits WAN ne prennent généralement pas en charge les paquets de plus de 1 500 octets), il n'est pas conçu pour être à faible latence. Au lieu de cela, il est conçu pour permettre aux tissus Fibre Channel séparés géographiquement d'être liés lorsque la fibre noire n'est pas disponible pour le faire avec FCP natif. Le FCIP se trouve presque toujours dans les passerelles de distance FC - essentiellement des ponts FC / FCP-FCIP - et est rarement, voire jamais, utilisé nativement par les périphériques de stockage comme méthode d'accès serveur-stockage.

Fibre Channel sur Ethernet

FCoE (Fibre Channel over Ethernet) est le dernier protocole de mise en réseau de stockage du groupe. Ratifié en tant que norme en juin de l'année dernière, FCoE est la réponse de la communauté Fibre Channel aux avantages de l'iSCSI. Tout comme iSCSI, FCoE utilise des réseaux Ethernet polyvalents standard pour connecter les serveurs au stockage. Contrairement à iSCSI, il ne fonctionne pas sur TCP / IP - il s'agit de son propre protocole Ethernet occupant un espace à côté de IP dans le modèle OSI.

Ce différentiel est important à comprendre car il a à la fois de bons et de mauvais résultats. L'avantage est que, même si FCoE s'exécute sur les mêmes commutateurs à usage général qu'iSCSI, il subit une latence de bout en bout nettement inférieure en raison du fait que l'en-tête TCP / IP n'a pas besoin d'être créé et interprété. Le problème est qu'il ne peut pas être routé sur un réseau étendu TCP / IP. Comme FC, FCoE ne peut s'exécuter que sur un réseau local et nécessite un pont pour se connecter à une structure distante.

Du côté du serveur, la plupart des implémentations FCoE utilisent des CNA Ethernet FCoE 10 Gbit / s (adaptateurs réseau convergés), qui peuvent à la fois agir comme des adaptateurs réseau et des HBA FCoE - déchargeant le travail de communication avec le stockage de la même manière que les HBA FC. C'est un point important car l'exigence d'un FC HBA séparé était souvent une bonne raison pour éviter complètement FC. Au fil du temps, les serveurs peuvent généralement être livrés avec des CNA compatibles FCoE intégrés, ce qui en fait essentiellement un facteur de coût.

Les principaux avantages de FCoE peuvent être réalisés lorsqu'il est implémenté en tant qu'extension d'un réseau Fibre Channel préexistant. Malgré un mécanisme de transport physique différent, qui nécessite quelques étapes supplémentaires à mettre en œuvre, FCoE peut utiliser les mêmes outils de gestion que FC, et une grande partie de l'expérience acquise dans l'exploitation d'une structure FC peut être appliquée à sa configuration et à sa maintenance.

Mettre tous ensemble

Il ne fait aucun doute que le débat entre FC et iSCSI continuera de faire rage. Les deux architectures sont parfaites pour certaines tâches. Cependant, dire que FC est bon pour les entreprises tandis que iSCSI est bon pour les PME n'est plus une réponse acceptable. La disponibilité de FCoE contribue grandement à ronger l'argument de coût et de convergence d'iSCSI, tandis que la prévalence croissante de l'Ethernet 10 Gbps et l'augmentation des performances du processeur du serveur rongent l'argument de performance de FC.

Quelle que soit la technologie que vous décidez de mettre en œuvre pour votre organisation, essayez de ne pas vous laisser entraîner dans la guerre de religion et faites vos devoirs avant d'acheter. Vous pourriez être surpris par ce que vous trouvez.

Cet article, «Fibre Channel vs iSCSI: la guerre continue», a été initialement publié sur .com. En savoir plus sur le blog Information Overload de Matt Prigge et suivre les derniers développements en matière de stockage de données et de gestion de l'information sur .com.