Bruno Durand, vice-président Europe du Sud chez Juniper Networks
Les initiatives Big Data se traduisent par de grosses bases de données, horizontalement élastiques, déployées sur des grappes capables de s’étendre sur des milliers de serveurs. Le réseau qui relie ces serveurs et sa conception sont clés. Un réseau mal conçu peut inhiber le lancement et l’extension des initiatives Big Data, pénaliser la valeur qu’elles pourraient apporter. Voici donc quatre questions que vous devez vous poser (ainsi qu’à votre équipementier réseau).
1. Comment vais-je assurer la fiabilité des données ?
Le système de fichiers Hadoop Distributed File System (HDFS) place chaque donnée sur un nœud dans un rack, puis la réplique sur deux nœuds différents, dans des racks différents. HDFS ayant connaissance de la topologie, les répliques sont placées sur des nœuds connectés à différents commutateurs. Aucune intelligence supplémentaire n’a besoin d’être intégrée aux commutateurs.
En cas de défaillance, HDFS s’appuie sur le réseau pour maintenir la fiabilité. Toutefois, la réplication des données peut prendre des heures. Par exemple, il faut compter environ 66 minutes pour transférer 30 To de données sur un réseau 1 GbE – en tenant compte de la latence du réseau et selon les performances réelles du réseau, cela peut prendre bien plus longtemps. Si le réseau ne dispose pas d’une bande passante suffisante, le risque est grand que le nœud de données perde la connectivité avec le nœud de nommage et que HDFS perde alors sa fiabilité.
Avec une infrastructure 10 Gbps, la réplication d’un disque de 3 To ne prend que 7 minutes. Qui plus est, les performances réseau sont largement supérieures (voir plus loin), assurant la disponibilité de la bande passante nécessaire à la connexion fiable des nœuds de données et de nommage.
2. Comment puis-je m’assurer que les performances seront assez bonnes ?
Les réseaux multi-tiers traditionnels sont inefficaces par construction lorsqu’il s’agit de supporter les performances d’applications Big Data multi-racks. La latence d’un commutateur typique de châssis peut n’être que d’une microseconde, mais la latence des commutateurs de distribution et de cœur de réseau est significativement plus grande.
Le problème est amplifié par la sursouscription introduite au niveau de la distribution et du cœur de réseau. Un commutateur de châssis est susceptible de fonctionner avec un ratio de sursouscription de 3:1. Mais si l’on considère un ratio de sursouscription de 4:1 au niveau du commutateur de distribution, on obtient une sursouscription globale de 10:1. Dès lors, la bande passante effectivement disponible pour la réplication, sur un nœud de données configuré avec une connexion 20 Gbps, n’est plus que de 2 Gbps.
En outre, avec une application Big Data, il n’est pas acceptable de perdre des paquets alors que les données sont déplacées au sein du centre de calcul. Sur un réseau Ethernet, la réponse à cette problématique est généralement apportée par la technologie Data Center Bridging (DCB). Mais tous les commutateurs actuellement disponibles sur le marché ne la supportent pas.
Une infrastructure adaptée ne doit pas employer de commutateurs intermédiaires, afin que chaque serveur ne soit qu’à un hop de l’autre, ce qui réduit significativement la latence. Éliminer les commutateurs intermédiaires réduit également la sursouscription de manière substantielle. Ce qui induit des besoins plus faibles de temporisation du trafic et une augmentation des débits.
3. Comment m’assurer que mon projet Big data pourra être étendu ?
L’élasticité est essentielle aux initiatives Big Data. Toutefois, plus le réseau devient étendu, plus les restrictions propres aux infrastructures traditionnelles induiront latence et sursouscription.
Mais il faut également prendre en compte la question de la collecte des données. Qui dit initiative Big Data, dit collecte de données structurées et non-structurées en temps réel. En conséquence, le réseau doit supporter un accès direct, optimal, aux réseaux de stockage ; ce que certaines architectures réseau ne permettent pas.
Choisir une architecture capable d’élasticité jusqu’aux niveaux 2 et 3, pouvant être optimisée pour les réseaux de stockage FCoE, iSCSI et NFS, vous assurera de ne pas avoir à vous inquiéter de la croissance de vos besoins.
4. Comment puis-je l’administrer aisément ?
Les réseaux multi-tiers traditionnels sont complexes à administrer par nature. Le nombre de commutateurs intermédiaires augmente avec le nombre de serveurs et de racks. Dès lors, tant l’administration que la maintenance du réseau gagnent en complexité.
Une authentique matrice, basée sur un unique système d’exploitation, se comporte comme un commutateur Ethernet convergé et peut être administrée comme tel. Le provisioning, l’administration et la maintenance en sont grandement simplifiés.
Posez les bonnes questions
Il ne fait aucun doute que les initiatives Big Data produiront les informations nécessaires au pilotage de nouvelles activités et à l’émergence de nouvelles manières de faire des affaires, lorsqu’elles commenceront à se concrétiser. Mais pour s’assurer que les réseaux ne constituent pas un obstacle, les organisations doivent s’assurer d’avoir posé les bonnes questions à propos de la conception de leur réseau.
1. Comment vais-je assurer la fiabilité des données ?
Le système de fichiers Hadoop Distributed File System (HDFS) place chaque donnée sur un nœud dans un rack, puis la réplique sur deux nœuds différents, dans des racks différents. HDFS ayant connaissance de la topologie, les répliques sont placées sur des nœuds connectés à différents commutateurs. Aucune intelligence supplémentaire n’a besoin d’être intégrée aux commutateurs.
En cas de défaillance, HDFS s’appuie sur le réseau pour maintenir la fiabilité. Toutefois, la réplication des données peut prendre des heures. Par exemple, il faut compter environ 66 minutes pour transférer 30 To de données sur un réseau 1 GbE – en tenant compte de la latence du réseau et selon les performances réelles du réseau, cela peut prendre bien plus longtemps. Si le réseau ne dispose pas d’une bande passante suffisante, le risque est grand que le nœud de données perde la connectivité avec le nœud de nommage et que HDFS perde alors sa fiabilité.
Avec une infrastructure 10 Gbps, la réplication d’un disque de 3 To ne prend que 7 minutes. Qui plus est, les performances réseau sont largement supérieures (voir plus loin), assurant la disponibilité de la bande passante nécessaire à la connexion fiable des nœuds de données et de nommage.
2. Comment puis-je m’assurer que les performances seront assez bonnes ?
Les réseaux multi-tiers traditionnels sont inefficaces par construction lorsqu’il s’agit de supporter les performances d’applications Big Data multi-racks. La latence d’un commutateur typique de châssis peut n’être que d’une microseconde, mais la latence des commutateurs de distribution et de cœur de réseau est significativement plus grande.
Le problème est amplifié par la sursouscription introduite au niveau de la distribution et du cœur de réseau. Un commutateur de châssis est susceptible de fonctionner avec un ratio de sursouscription de 3:1. Mais si l’on considère un ratio de sursouscription de 4:1 au niveau du commutateur de distribution, on obtient une sursouscription globale de 10:1. Dès lors, la bande passante effectivement disponible pour la réplication, sur un nœud de données configuré avec une connexion 20 Gbps, n’est plus que de 2 Gbps.
En outre, avec une application Big Data, il n’est pas acceptable de perdre des paquets alors que les données sont déplacées au sein du centre de calcul. Sur un réseau Ethernet, la réponse à cette problématique est généralement apportée par la technologie Data Center Bridging (DCB). Mais tous les commutateurs actuellement disponibles sur le marché ne la supportent pas.
Une infrastructure adaptée ne doit pas employer de commutateurs intermédiaires, afin que chaque serveur ne soit qu’à un hop de l’autre, ce qui réduit significativement la latence. Éliminer les commutateurs intermédiaires réduit également la sursouscription de manière substantielle. Ce qui induit des besoins plus faibles de temporisation du trafic et une augmentation des débits.
3. Comment m’assurer que mon projet Big data pourra être étendu ?
L’élasticité est essentielle aux initiatives Big Data. Toutefois, plus le réseau devient étendu, plus les restrictions propres aux infrastructures traditionnelles induiront latence et sursouscription.
Mais il faut également prendre en compte la question de la collecte des données. Qui dit initiative Big Data, dit collecte de données structurées et non-structurées en temps réel. En conséquence, le réseau doit supporter un accès direct, optimal, aux réseaux de stockage ; ce que certaines architectures réseau ne permettent pas.
Choisir une architecture capable d’élasticité jusqu’aux niveaux 2 et 3, pouvant être optimisée pour les réseaux de stockage FCoE, iSCSI et NFS, vous assurera de ne pas avoir à vous inquiéter de la croissance de vos besoins.
4. Comment puis-je l’administrer aisément ?
Les réseaux multi-tiers traditionnels sont complexes à administrer par nature. Le nombre de commutateurs intermédiaires augmente avec le nombre de serveurs et de racks. Dès lors, tant l’administration que la maintenance du réseau gagnent en complexité.
Une authentique matrice, basée sur un unique système d’exploitation, se comporte comme un commutateur Ethernet convergé et peut être administrée comme tel. Le provisioning, l’administration et la maintenance en sont grandement simplifiés.
Posez les bonnes questions
Il ne fait aucun doute que les initiatives Big Data produiront les informations nécessaires au pilotage de nouvelles activités et à l’émergence de nouvelles manières de faire des affaires, lorsqu’elles commenceront à se concrétiser. Mais pour s’assurer que les réseaux ne constituent pas un obstacle, les organisations doivent s’assurer d’avoir posé les bonnes questions à propos de la conception de leur réseau.
