Rappelez-vous le battage médiatique de NFV?Qu'est-ce qui s'est passé avec ça?

Approche des systèmes Depuis nos récents articles, il a été de retracer l'histoire et de raconter les leçons, de réseautage défini par les logiciels, cela semble être le bon moment pour faire de même avec l'autre changement de mer dans la mise en réseau au cours de la dernière décennie: la virtualisation des fonctions du réseau,ou nfv.

Most people trace NFV back to the call-to-action [PDF] several network operators presented at the Layer123 SDN & OpenFlow World Congress in October 2012.

Mon implication s'est produite sur plusieurs mois avant cette présentation, en travaillant avec des collègues de BT, Intel, HP, Wind River et Tailf sur une preuve de concept qui a donné à l'idée suffisamment de crédibilité pour que ces opérateurs mettent la participation du NFV dans le sol.

Qu'est-ce que NFV?

En termes simples, la virtualisation des fonctions du réseau est un moyen d'exécuter divers services de réseau dans une collection de machines virtuelles qui s'exécutent sur des serveurs hôtes.Cela signifie que vous pouvez construire, par exemple, une opération de télécommunications ou votre épine dorsale du réseau d'entreprise hors des boîtes de marchandises, et exécuter tous vos charges de travail de routage, de mise en cache et de surveillance, et ainsi de suite dans les machines virtuelles sur ce matériel.Votre réseau peut être mis à l'échelle au besoin, vous n'avez pas besoin de matériel coûteux dédié et vous pouvez former votre propre cloud.Ou si le rêve est allé.

À l'époque, j'étais au CDN Software StartUp Verivue, qui a contribué ce que nous croyons être la fonction de réseau virtualisé canonique (VNF) - un cache Web évolutif.Don Clarke, qui a dirigé tout l'effort au nom de BT, a une excellente histoire en 4 parties du voyage, dont ma propre expérience directe était limitée à la première partie.

Deux choses se distinguent sur la preuve de concept.Le premier est la bonté technique évidente de colocaliser une technologie de réseau d'accès (comme une passerelle à large bande virtualisée) et un service cloud (comme un cache évolutif) sur un rack de serveurs de produits.La preuve de concept elle-même, comme c'est souvent le cas, a été paralysée par le fait que nous devons concoller les composants logiciels existants qui ont été développés pour différents environnements.Mais cela a fonctionné et c'était une réalisation technique impressionnante.

La seconde est que les esprits de l'entreprise dans la salle ont travaillé dur pour construire un cas de retour sur investissement à jumeler avec l'histoire technique.Le service des lèvres a été donné à la valeur de l'agilité et à l'amélioration de la vitesse des fonctionnalités, mais les économies de coûts étaient quantifiables, ils ont donc reçu la majeure partie de l'attention.

En dépit d'être largement annoncé au début, NFV n'a pas été à la hauteur de sa promesse.Il y a eu beaucoup d'analyses pour savoir pourquoi (par exemple, voir ici et ici), mais ma prise est assez simple.

Les opérateurs considèrent le NFV comme un moyen d'exécuter des appareils spéciaux dans des machines virtuelles sur le matériel de marchandise, mais c'est la partie facile du problème.Le simple fait d'insérer un hyperviseur entre le logiciel d'appareil et le matériel sous-jacent peut entraîner des économies de coûts modestes en permettant la consolidation du serveur, mais elle ne redevient de la gestion de la gestion zéro-touch que les opérateurs de données modernes apprécient lors du déploiement des services cloud.

Remember the hype for NFV? Whatever happened with that?

In practice, telco operators still had to deal with N one-off VM configurations to operationalize N virtualized functions.L'attente que le NFV déplacerait leur défi opérationnel de la prise en charge des animaux de compagnie à l'élevage de bétail ne s'est pas concrétisé;Les opérateurs ont été laissés prendre soin des animaux de compagnie virtualisés.

En dépit d'être largement annoncé au début, NFV n'a pas été à la hauteur de sa promesse

Streamlining operational processes is hard enough under the best circumstances, but the operators approached the problem with the burden of preserving their legacy O&M practices (ie, they were actively avoiding changes that would enable streamlining).Essentiellement, les opérateurs ont décidé de construire un cloud de télécommunications grâce à l'adoption fragmentaire des technologies cloud (à commencer par les hyperviseurs).Il s'est avéré, cependant, NFV a mis en mouvement une deuxième voie d'activité qui se traduit désormais en un télécommunications basées sur le cloud.Laissez-moi expliquer la différence.

En regardant le NFV POC avec le recul, il est clair que se tenir debout un petit groupe de serveurs pour faire la démonstration de quelques VNFS a relevé le véritable défi, qui est de répéter ce processus au fil du temps, pour arbitrairement de nombreux VNFS.C'est le problème de l'intégration en continu, du déploiement en continu et de l'orchestration continue des charges de travail cloud, qui a stimulé le développement d'un riche ensemble d'outils indigènes cloud, notamment Kubernetes, Helm et Terraform.

Such tools weren't generally available in 2012, although they were emerging inside hyperscalers, and so the operators behind the NFV initiative started down a path of (a) setting up an ETSI-hosted standardization effort to catalyze the development of VNFs, and (b) retrofitting their existing O&M mechanisms to support this new collection of VNFs.Sans évaluer le point par point d'architecture de référence NFV, il semble juste de dire que l'emballage d'un VNF dans un système de gestion d'éléments (EMS), comme s'il s'agissait d'un autre appareil basé sur l'appareil, est un exemple parfait de la façon dont une telle approche faitpas les opérations à l'échelle.

Pendant ce temps, l'objectif louable de l'exécution de fonctions virtualisées sur le matériel de marchandises a inspiré un effort parallèle qui existait entièrement en dehors du processus de normalisation de l'ETSI: créer des implémentations natives dans le cloud des technologies de réseau d'accès, qui pourraient ensuite exécuter côte à côte avec d'autres charges de travail natives cloud.Cette piste parallèle, qui est devenue connue sous le nom de Office central, a recommandé comme un centre de données (cordon), a finalement conduit à des implémentations basées sur Kubernetes de technologies d'accès multiples (par exemple.Pon / gpon et a été couru).Ces réseaux d'accès s'exécutent comme des microservices qui peuvent être déployés par un graphique de barre sur votre plate-forme Kubernetes préférée, fonctionnant généralement au bord (par exemple, Aether).

Encore une fois, avec le recul, il est intéressant de revenir aux deux principaux arguments pour le NFV - des coûts inférieurs et une agilité améliorée - et voir comment elles ont été dépassées par les événements.Sur le front des coûts, il est clair que la résolution du défi opérationnel était une condition préalable à la réalisation de toute économie CAPEX.Ce que l'expérience native du cloud nous enseigne, c'est qu'une chaîne d'outils CI / CD bien définie et les moyens d'étendre facilement le plan de gestion pour intégrer de nouveaux services au fil du temps est le prix de l'admission pour profiter de l'économie du cloud.

Sur le front de l'agilité, l'approche de NFV consistait à soutenir le chaînage des services, un mécanisme qui permet aux clients de personnaliser leur connectivité en "chaînant ensemble" une séquence de VNFS.

Depuis que les VNF fonctionnent en machines virtuelles, en théorie, il semblait plausible que l'on puisse interconnecter programmatiquement une séquence d'entre eux.En pratique, fournir un mécanisme de chaînage de service à usage général s'est avéré insaisissable.En effet.

Il ne s'aligne tout simplement pas sur les réalités de la construction de services cloud.Le CDN canonique VNF est un excellent exemple.Les demandes HTTP ne sont pas tunnelles via un cache car elles ont été câblées (pratiquement ou physiquement) dans la chaîne de bout en bout, mais à la place, un service de redirection de demande complètement séparé assis en dehors du chemin de données dirige dynamiquement que HTTP obtienne des messages vers le cache le plus proche.(Ironiquement, cela était vrai pendant le POC, car le CDN Verivue était en fait basé sur un conteneur et construit selon les principes natifs de Cloud, même s'il prédédit Kubernetes.)

Un pare-feu est un autre exemple: dans un monde centré sur l'appareil, un pare-feu est une "Middlebox" qui pourrait être insérée dans une chaîne de services, mais dans le cloud, la fonctionnalité équivalente de contrôle d'accès est répartie sur les commutateurs virtuels et physiques.

Lorsque nous examinons le problème de l'agilité du service à travers l'objectif de la technologie actuelle, un maillage de service fournit un meilleur modèle conceptuel pour offrir rapidement aux clients de nouvelles fonctionnalités, avec la connectivité en tant que service s'avérant être un autre service cloud.

Mais la plus grande leçon de systèmes de NFV est que les opérations doivent être traitées comme une propriété de première classe d'un cloud.L'impact limité du NFV peut être directement retracé à la réticence de ses partisans à refacter leur modèle opérationnel dès le départ.®

Larry Peterson and Bruce Davie are the authors of Computer Networks: A Systems Approach and the related Systems Approach series of books.Tout leur contenu est open source et disponible sur github.Vous pouvez les trouver sur Twitter, leurs écrits sur substitution et passer les colonnes de registre ici.

Get our Tech Resources
Articles populaires