Au début des années 80, Motorola a lancé les premiers téléphones mobiles commerciaux. Ils étaient énormes, lourds, coûtaient des milliers de dollars et fonctionnaient sur un réseau analogique appelé AMPS, gourmand en bande passante et dépourvu de fonctionnalités de sécurité de base pour empêcher les appels d’être interceptés ou mis sur écoute.
Aussi avant-gardistes qu’ils l’étaient à leur époque, personne de sensé n’en utiliserait encore aujourd’hui.
À l’époque où le Motorola DynaTac 8000X a été introduit, Sun Microsystems a développé son système de fichiers réseau (NFS) en tant que protocole permettant aux machines client d’accéder aux fichiers sur un seul serveur centralisé.
A propos de l’auteur
Björn Kolbeck est co-fondateur et PDG de Quobyte
NFS était une percée à l’époque, mais personne de sensé ne l’utiliserait encore aujourd’hui, n’est-ce pas?
À l’époque, les connexions commutées via les modems étaient mesurées en bits par seconde, et les réseaux locaux Ethernet locaux atteignaient un pic à 10 Mbits / s. Aujourd’hui, nous traitons avec exponentiellement plus de données, des réseaux plus rapides et plus de serveurs que dans les années 1980 ou même 1990.
Avec l’avènement des architectures évolutives dans l’informatique – ou l’informatique à l’échelle de l’entrepôt comme l’appelait Google – nous nous sommes retrouvés avec des environnements qui ne conviennent même pas au dernier et meilleur NFSv4. En fait, c’est devenu un handicap.
Le plus gros problème: NFS est conçu pour un seul serveur centralisé, pas pour une montée en charge. Le NFSv4 actuel et même le NFS parallèle sont toujours basés sur un modèle centralisé. Non seulement NFS a été conçu pour que les clients puissent parler à un seul serveur, mais ces machines n’avaient que quelques Mo de capacité, la taille des fichiers était relativement petite et le débit relativement faible.
Chaque responsable informatique d’entreprise, CIO et Data Scientist dans le monde a aujourd’hui deux objectifs: un, répondre aux besoins d’échelle des utilisateurs et des applications, et deux, une sécurité des données appropriée pour assurer la sécurité, la conformité et la disponibilité.
La montée en charge nécessite une communication à maillage complet (n à m) entre les clients et les serveurs de stockage. Sinon, il y a des goulots d’étranglement et des blocages pour freiner les performances, en particulier dans les charges de travail lourdes en lecture ou en écriture – qui sont essentiellement toutes les charges de travail d’une entreprise moderne.
Et c’est finalement son défaut critique: NFS est lui-même un goulot d’étranglement. Le périphérique NFS se trouve intrinsèquement directement dans le chemin des données et ne peut pas faire évoluer les performances pour répondre aux demandes de calcul intensif d’E / S ou de plusieurs demandes simultanées.
Toute passerelle est également un goulot d’étranglement, et les passerelles NFS ne font pas exception. Les architectures basées sur des passerelles NFS ont des limites de mise à l’échelle des performances sévères en raison de la cohérence des caches entre les passerelles NFS pour créer l’illusion d’un seul serveur NFS. Parce que c’est tout ce que NFS peut faire, et la cohérence du cache est un pansement coûteux pour faire fonctionner un protocole obsolète, au lieu de résoudre le problème: NFS.
L ‘«équilibrage» de la charge – j’utilise des guillemets car la plupart du temps le résultat est loin d’être équilibré – exige intrinsèquement un environnement ou un système distribué, et comme NFS n’a jamais été conçu pour les systèmes distribués, l’équilibrage de charge est pénible et perturbateur. Il ne pense tout simplement pas de cette façon.
Ah, mais c’est là qu’intervient le NFS parallèle. Les gens pensent qu’il résout tous ces problèmes. Malheureusement, pNFS est toujours aussi cassé, et toujours le contraire de la montée en puissance. Seules les E / S sont réparties sur plusieurs serveurs; il n’y a toujours qu’un seul serveur centralisé pour les métadonnées et le plan de contrôle. Cela ne surprendra personne que l’explosion des données d’entreprise comprenne une explosion correspondante des métadonnées. Les performances et l’échelle dans le traitement des métadonnées sont particulièrement importantes dans les applications de «big data» telles que l’IA / ML et l’analyse.
Malheureusement, comme je le vois encore et encore, pNFS ne résout qu’une infime partie du problème: le transfert de données. C’est peut-être l’itération la plus moderne, mais il a 15 ans de retard sur le marché et laisse de nombreux problèmes réels non résolus.
NFS échoue également lors du basculement. Quiconque utilise NFS connaît le problème des «descripteurs de fichiers périmés» lorsqu’un basculement NFS se produit. Le protocole, même NFSv4, n’a aucune idée de ce qu’est le basculement – encore une fois, il n’a pas été créé pour penser de cette façon – et repose à la place sur un basculement IP fragile, qui est lent et perturbateur. Comme beaucoup de fonctionnalités critiques, la tolérance aux pannes doit être conçue dans un protocole dès le début, mais NFS a ajouté un basculement maladroit plus tard, comme un bâtiment mal conçu en attente de s’effondrer.
Cela m’amène au deuxième objectif de l’informatique d’entreprise: la sécurité des données – un terme fourre-tout pour l’intégrité des données, la gouvernance, la conformité, la protection, le contrôle d’accès, etc.
La sécurité des données est une préoccupation majeure, qu’il s’agisse de la prévention des violations de données ou de la réglementation de l’industrie. Récemment, les violations de données ont entraîné des amendes importantes pour les entreprises soumises au RGPD de l’Union européenne. Les entreprises qui traitent des informations personnellement identifiables ou des données de santé doivent mettre en œuvre une protection des données de pointe grâce au cryptage.
Ici encore, NFS est une responsabilité car ni pNFS ni NFSv4 n’offrent un cryptage de bout en bout approprié, sans parler d’autres mécanismes de sécurité tels que les certificats TLS et X.509, qui sont tous disponibles aujourd’hui dans des technologies de stockage conçues pour la montée en charge et la sécurité, y compris Système de fichiers du centre de données de Quobyte. En comparaison, NFS représente un risque commercial et de conformité grave.
pNFS et NFSv4 manquent également de sommes de contrôle de bout en bout pour identifier la corruption des données. Ceci est également en partie le résultat de l’échelle croissante des opérations de données aujourd’hui par rapport à l’époque où NFS a été développé. Dans les années 1980, l’intégrité des données via les sommes de contrôle n’était pas une question, car les données transférées sur des paquets IP étaient petites et les sommes de contrôle TCP étaient adéquates. Mais les sommes de contrôle TCP sont maintenant trop faibles, en particulier à des échelles supérieures à 64 ko par paquet. Aujourd’hui, une entreprise attend des gigaoctets par seconde. Des décennies plus tard, NFS n’aborde toujours pas l’intégrité des données de manière adéquate. Vous sous-estimez probablement la fréquence à laquelle vous obtenez des données corrompues de votre stockage NFS – et le suivi du problème est difficile et prend du temps.
Qu’il s’agisse d’exigences à haut débit, de charges de travail générales aléatoires ou mixtes, ou de sécurité et d’accès aux données, il n’y a nulle part dans l’entreprise moderne où NFS excelle. Il est temps d’abandonner les protocoles de l’ère Back to the Future au profit d’alternatives qui offrent aux utilisateurs et aux applications les performances et la fiabilité dont ils ont besoin.
