Au début des années 1980, 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 qui consommait beaucoup de bande passante et manquait de fonctionnalités de sécurité de base pour empêcher les appels d'être interceptés ou interceptés. Aussi énervés qu'ils étaient à leur époque, personne de sensé ne les porterait aujourd'hui. Lorsque 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 ordinateurs clients d'accéder aux fichiers sur un seul serveur centralisé. À propos de l'auteur Björn Kolbeck est co-fondateur et PDG de Quobyte NFS était une avancée majeure à l'époque, mais personne sensé ne l'utiliserait aujourd'hui, n'est-ce pas ? À l’époque, les connexions commutées aux modems étaient mesurées en bits par seconde et les réseaux locaux Ethernet locaux atteignaient un maximum de 10 Mbps. Aujourd’hui, nous sommes confrontés à un volume exponentiel de données, à des réseaux plus rapides et à davantage de serveurs que dans les années 80 ou même 90. Avec l'avènement des architectures informatiques évolutives, ou de l'informatique à l'échelle de l'entrepôt, comme l'appelle Google, nous nous sommes retrouvés avec des environnements qui ne correspondent même pas au dernier et au meilleur NFSv4. En fait, c’est devenu un inconvénient. Plus gros problème : NFS est conçu pour un seul serveur centralisé, et non pour une mise à l'échelle horizontale. Le NFSv4 actuel et même le NFS parallèle sont toujours basés sur un modèle centralisé. NFS n'a pas seulement été conçu pour que les clients puissent communiquer avec un seul serveur, ces machines n'avaient qu'une capacité de quelques Mo, la taille des fichiers était relativement petite et les performances relativement faibles. Chaque DSI, DSI et data scientist dans le monde a deux objectifs : le premier, répondre aux besoins des utilisateurs et des applications à grande échelle, et le deuxième, assurer une sécurité adéquate des données pour garantir la sécurité et la conformité. et disponibilité. L'évolutivité horizontale nécessite une communication entièrement maillée (n am) entre les clients et les serveurs de stockage. Sinon, des goulots d'étranglement et des goulots d'étranglement existent pour réduire les performances, en particulier sur les charges de travail lourdes en lecture ou en écriture, qui constituent essentiellement toutes les charges de travail d'une entreprise moderne. Et c’est finalement son défaut critique : NFS lui-même est un goulot d’étranglement. Le périphérique NFS se trouve par nature directement dans le chemin de données et ne peut pas adapter ses performances pour répondre aux demandes d'E/S gourmandes en calcul ou à plusieurs requêtes simultanées. Toute passerelle constitue également un goulot d'étranglement et les passerelles NFS ne font pas exception. Les architectures basées sur une passerelle NFS présentent de sévères limitations de mise à l'échelle des performances 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 que la cohérence du cache est une aide coûteuse pour exécuter un protocole obsolète, plutôt que de résoudre le problème : NFS. Équilibrage de charge : j'utilise des guillemets car la plupart du temps, la sortie est loin d'être équilibrée, elle nécessite 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 fastidieux et perturbateur. Il ne pense tout simplement pas de cette façon. Ah, mais c'est là que le NFS parallèle entre en jeu. Les gens pensent que cela résout tous ces problèmes. Malheureusement, pNFS est toujours cassé et reste à l'opposé de l'augmentation. Seules les E/S sont distribuées sur plusieurs serveurs ; il existe toujours un seul serveur centralisé pour les métadonnées et le plan de contrôle. Il n’est pas surprenant que l’explosion des données d’entreprise s’accompagne d’une explosion correspondante des métadonnées. Les performances et l'évolutivité du traitement des métadonnées sont particulièrement importantes dans les applications Big Data telles que l'IA/ML et l'analyse. Malheureusement, comme je le constate sans cesse, pNFS ne résout qu'une petite partie du problème : le transfert de données. Il s’agit peut-être de la version la plus moderne, mais elle 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 obsolètes » 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é conçu pour y penser de cette façon) et s'appuie plutôt sur un basculement IP fragile, qui est lent. et perturbateur. Comme de nombreuses fonctionnalités critiques, la tolérance aux pannes doit être intégrée dans un protocole dès le départ, mais NFS a ensuite ajouté un basculement délicat, comme un bâtiment mal conçu attendant de s'effondrer. Cela m'amène au deuxième objectif de l'informatique d'entreprise: la sécurité des données, terme général 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 prévenir les violations de données ou de réguler le secteur. Récemment, des violations de données ont conduit à 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. Là encore, NFS est un handicap car ni pNFS ni NFSv4 n'offrent un chiffrement de bout en bout adéquat, et encore moins d'autres mécanismes de sécurité comme les certificats TLS et X.509, tous disponibles dans les technologies actuelles. des systèmes de stockage conçus pour l'évolutivité et la sécurité, y compris le système de fichiers du centre de données de Quobyte. En comparaison, NFS représente un risque commercial et de conformité important. pNFS et NFSv4 manquent également de sommes de contrôle de bout en bout pour identifier la corruption des données. Cela s’explique également en partie par l’ampleur croissante des opérations de données aujourd’hui par rapport à l’époque où le NFS a été développé. Dans les années 1980, l'intégrité des données à l'aide des sommes de contrôle n'était pas un problème, car les données transférées via des paquets IP étaient petites et les sommes de contrôle TCP étaient adéquates. Mais les sommes de contrôle TCP sont désormais trop faibles, en particulier à des échelles supérieures à 64 XNUMX par paquet. Aujourd’hui, une entreprise attend des gigaoctets par seconde. Des décennies plus tard, NFS ne prend toujours pas correctement en compte l’intégrité des données. Vous sous-estimez probablement la fréquence à laquelle vous obtenez des données corrompues de votre stockage NFS, et localiser le problème est difficile et prend du temps. Qu'il s'agisse d'exigences de hautes performances, de charges de travail générales aléatoires ou mixtes, ou de sécurité et d'accès aux données, nulle part dans l'entreprise moderne NFS n'excelle.