Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 

De la Théorie à la pratique











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Big Data : quatre questions à vous poser au sujet de vos réseaux, et à poser à votre équipementier

novembre 2012 par Bruno Durand, vice-président Europe du Sud chez Juniper Networks

Le Big Data transforme significativement la manière dont les organisations collectent les données et utilisent les outils décisionnels, en donnant accès à des informations qui améliorent considérablement la productivité, l’innovation et la compétitivité. C’est donc sans surprise qu’il figure en bonne place parmi les priorités de nombreuses organisations IT. Toutefois, mettre en œuvre le Big data comporte quelques défis.

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 noeud dans un rack, puis la réplique sur deux noeuds différents, dans des racks différents. HDFS ayant connaissance de la topologie, les répliques sont placées sur des noeuds 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 noeud de données perde la connectivité avec le noeud 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 noeuds 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 coeur de réseau est significativement plus grande.

Le problème est amplifié par la sursouscription introduite au niveau de la distribution et du coeur 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 noeud 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.




Voir les articles précédents

    

Voir les articles suivants