Businesshighlight Conseiller Agilité Réseau : de la lumière au bout du tunnel! sommaire Quels enjeux autour de l agilité réseau? Frein n 1 : le mystérieux adressage IP Frein n 2 : la fameuse matrice des flux SDN : un nouveau paradigme L architecture Software Defined Network La vision Beijaflore L agilité IT dans les Data Centers a beaucoup progressé grâce à la virtualisation des serveurs. Désormais, une ressource serveur n est plus liée à un hardware donné, il est possible de gérer systèmes, applications et stockages en toute flexibilité. Mais qu en est-il du réseau? Dans le Time-to-Market, l infrastructure IP reste encore trop souvent un «caillou dans la chaussure». A l heure où le temps est une ressource critique, il convient donc de se pencher sur l amélioration des fondations, ce qui passe à la fois par un travail sur les processus mais aussi par un outillage adapté. Quels sont les leviers? Comment concrétiser ces améliorations? Au-delà de la «simple amélioration» de l existant, SDN, une nouvelle technologie en rupture, fait le buzz, avec comme promesse le lien dynamique tant attendu entre applications et réseaux. Quelles sont les perspectives? Comment s y préparer? Au final, comment éviter l effet tunnel? n 10072013.../...
Agilité Réseau : de la lumière au bout du tunnel! Quels enjeux autour de l agilité réseau? Presque tout projet d évolution SI met en jeu un même triptyque réseau : l attribution de nouvelles adresses IP, l ouverture des flux, le déploiement des configurations réseau. Force est de constater que, depuis les années 90, le provisionning des réseaux se fait toujours de la même façon : équipement par équipement, un opérateur déploie des configurations, avec ou sans script, ce qui peut prendre des jours voire des semaines, avec le risque d erreur qui en résulte. Par configuration réseau, on entend : les règles de routage, la QoS IP, le load-balancing et les règles de sécurité (anti-spoofing, access-lists, règles de pare-feux, ). Quant aux volets «adressage IP» et «ouverture de flux», ce sont deux processus souvent sur le chemin critique, avec la particularité d être élastiques et obscurs, ce qui entraine des dérives récurrentes sur les délais et sur la qualité. Dans un contexte Cloud, l aspect dynamique est trop souvent mis à mal par l aspect statique de l environnement réseau. Pour y remédier, les opérateurs de Cloud sur-provisionnent les ressources virtuelles : les extensions réseaux sont déclenchées au-delà d un seuil de capacité virtuelle, ce qui revient au final à investir dans une marge de ressources sousutilisées. Et même sans parler de Cloud, l identification et l implémentation des configurations réseau, qui interviennent tardivement dans le cycle, ont une fâcheuse tendance à ralentir les projets par surprise. Dans votre organisation, avez-vous formalisé les SLA de ces processus réseau? Ces délais sont-ils maîtrisés? En quoi impactent-ils vos projets de déploiement? Examinons comment IPAM, une sécurité IP adaptée et SDN peuvent changer la donne. Frein n 1 : le mystérieux adressage IP Tout projet connaît son passage obligé par le plan d adressage IP, sorte de cartographie de l utilisation des adresses, qui constitue l un des patrimoines les moins en vue et pourtant l un des plus précieux. La gestion de ressources IP est un processus au cœur du déploiement des besoins métiers, il doit donc être considéré non seulement sous un angle technique mais aussi sous un angle business. En pratique, classiquement dans la phase de spécification détaillée, il s agit pour le pilote du projet ou le responsable de la conception d obtenir des ressources IP auprès d une entité spécialisée garante du plan d adressage global. Celle-ci se chargera de trouver et d allouer des espaces d adressage IP libres pour compléter la spécification du projet, selon des règles de gestion spécifiques et via un processus centralisé, long et obscur pour un non initié. Il se joue à ce stade plusieurs enjeux : ne pas générer de conflit d adressage (erreur pouvant avoir de lourdes conséquences) et minimiser les ressources IP inutilisées (tailler au plus proche des besoins les blocs attribués pour éviter les «adresses mortes»). Le second point génère souvent des allers retours chronophages avec les sachants du projet pour challenger le besoin. Les ressources IP ne sont pas infinies pour le garant du plan d adressage, à cela s ajoute le besoin de faire du prévisionnel sur le remplissage des blocs IP, et, en cas de pénurie, de générer des demandes d extension vers les RIR (Registre Internet Régional). Le temps nécessaire pour boucler le processus peut donc 2
n 10 juillet 2013 varier de quelques heures à plusieurs semaines voire plusieurs mois en fonction du niveau de maturité des équipes, du mode de fonctionnement en place et de l outillage à disposition. L IPAM (IP Address Management) se propose d apporter des améliorations sur toutes ces dimensions : optimiser la consommation d adresses, standardiser et automatiser les procédures d attribution IP, positionner des délégations aux bons endroits en passant d un modèle centralisé et laborieux de spécialiste à un modèle collaboratif, réduire les coûts de gestion, accroître la productivité, automatiser le provisionning d adresses IP et enfin réduire les risques d erreur. Qu est-ce que l IPAM? L «IP Address Management» désigne une solution d administration, de suivi et de planification du référentiel d adressage IP d une entreprise. Le marché tend à regrouper dans la même infrastructure les fonctions de DNS, DHCP et IPAM (trio parfois nommé DDI), sous la forme d appliances dédiées. Ces trois services IP constituent un ensemble étroitement lié et dont la réunion permet une meilleure efficacité opérationnelle. Aujourd hui, environ 75% des entreprises gèrent encore leur plan d adressage IP via des fichiers plats, des applications maison ou une combinaison des deux. Selon Gartner, pour 60% des entreprises, le principal driver d un projet DDI est l IPAM. Pour les 40% restant, il s agit d améliorer la stabilité ou la sécurité du DNS et du DHCP (ex : déploiement de DNSSec), ou la consolidation des solutions hétérogènes (ex : DNS Windows + BIND). Le support d IPv6 est vu comme un prérequis mais pas encore comme un driver. Comment choisir et déployer son IPAM? Du fait de la nature critique des outils DDI et des workflows associés, tout projet d évolution dans ce domaine (sourcing, architecture, ) doit s opérer avec précaution, en considérant le périmètre global DNS+DHCP+IPAM, et en visant une pérennité de 5 à 10 ans. Déployer une solution d IPAM est un projet à la fois technique et organisationnel, dont le succès passe par une identification précise voire une réaffectation des rôles dans la gestion des espaces d adressage, impliquant à la fois les équipes d ingénierie et de production de la DSI. Avec la raréfaction des adresses IPv4 et l introduction d IPv6, l IPAM prend aujourd hui une importance croissante : la pénurie d IPv4 nécessite d être en mesure de faire facilement des audits et d optimiser plus que jamais les découpages ; IPv6 apporte un nouveau format d adresse plus complexe à lire et à maîtriser, l outillage de gestion devient alors critique. Frein n 2 : la fameuse matrice des flux Un autre irritant en matière d agilité est la mise à jour des filtres de sécurité réseau. Historiquement, le filtrage réseau se positionne en sécurité périmétrique, autorisant une liste de sources, de destinations et de protocoles à traverser des frontières logiques reflétant des espaces de confiance. Potentiellement, chaque évolution d architecture, qu elle soit applicative ou réseau, chaque déplacement de ressource, implique de revoir ces barrières logiques dans leur positionnement et leur contenu. Ce qui engendre une double lourdeur : établir la matrice des flux, reconfigurer les équipements réseau. Un premier niveau de simplification consiste à s affranchir des sources et destinations unitaires (serveur par serveur) au profit de filtrages dits «vectoriels» : des scopes IP entiers sont autorisés Construire 3
Agilité Réseau : de la lumière au bout du tunnel! à communiquer entre eux et selon une liste de protocoles déterminés (exemple : vers ce sousréseau, toutes les machines sont joignables en NFS, RPC et RDP). Le gain réside dans la mobilité transparente des ressources au sein d un sous-réseau donné, supprimant alors une adhérence entre un grand nombre d opérations de production et l équipe d ingénierie IP en charge du plan d adressage et du filtrage, tout en maintenant une faible exposition des services hébergés. Mais la principale difficulté réside dans la construction de la matrice des flux, souvent inconnue ou mal maîtrisée. C est pourquoi les architectures de sécurité tendent à évoluer vers un modèle de défense en profondeur. L idée est d utiliser une combinaison d outils de sécurité, chacun spécialisés dans des fonctionnalités différentes (IPS, Reverse-Proxy, ALG, outils systèmes, ), en se focalisant sur la protection de la donnée, son intégrité et la réduction des conséquences d une compromission, plutôt que d implémenter des filtrages périmétriques rigides et binaires dans la couche transport. C est la sécurité en profondeur, qui vient progressivement remplacer la sécurité périmétrique. Pour autant, est-ce que cela résout tout? Non, car il reste la problématique du provisionning des règles réseau, certes allégée mais pas négligeable, et parce que la sécurité n est qu un aspect parmi d autres, notamment le maintien des règles de QoS, de routage et de load-balancing. C est pourquoi le marché planche sur SDN. SDN : un nouveau paradigme Et si les applications prenaient le pouvoir? L idée de SDN est de rendre le réseau programmable, c est-à-dire de permettre aux applications d interagir Le Software Defined Network (SDN) n est peut-être pas pour l instant dans le top des priorités de votre Data Center, mais il pourrait bien le devenir si vous comptez tirer pleinement parti du Cloud privé. directement avec les réseaux, avec une coopération à double sens : l application informe le réseau du comportement désiré, le réseau informe les applications de ses capacités. Le tout permettant d établir un service avec des conditions définies a Jusqu à aujourd hui, les applications et le réseau priori et non a posteriori. se sont copieusement ignorés. Dans le monde des applications, la technique classique consiste à supposer ou à découvrir les capacités du réseau, par l utilisation de sondes au sein même des applications (entre clients et serveurs), puis à Pour une mise en œuvre de SDN, la première étape consiste à caractériser les besoins réseau des serveurs virtuels, ou mieux des applications : quelle bande passante, quel débit adapter le comportement applicatif au fil du temps. Dans le monde des réseaux, En toile de fond, derrière cette approche en rupture, se joue une guerre stratégique entre équipementiers réseau et fournisseurs de contenus/services pour le contrôle de l intelligence des réseaux. pic, quel SLA, quel niveau de priorité, etc. Décrire ces besoins au niveau applicatif il est courant d inspecter le trafic pour découvrir et comprendre les applications, puis a posteriori de leur assurer un transport plus adapté, appliquer des méthodes d optimisation applicative ou des règles signifie que vous pouvez par exemple spécifier différents niveaux de QoS pour la VoIP et pour la messagerie, s ils résident sur des machines virtuelles différentes. spécifiques. Ensuite, SDN se charge de fournir Tout cela engendre un évident problème de dynamicité au mieux ces contrats techniques et de complexité. de façon automatisée, en 4
n 10 juillet 2013 déployant les configurations réseau adéquates aux endroits adéquats. Cela est valable au moment du déploiement initial, mais aussi de façon dynamique et automatique dans la vie de l application. Par exemple, quand un administrateur migre des machines virtuelles vers un nouvel emplacement, le logiciel de management SDN reconfigure spontanément l ensemble des équipements réseau en conséquence pour maintenir le contrat de service initial. En cas d évolution du contrat de service, le déploiement réseau est un «simple réglage» en central, repercuté automatiquement dans les infrastructures techniques. Si SDN ne peut bien sûr pas magiquement créer la capacité nécessaire, il peut toutefois vous aider à voir où sont les contraintes et à prendre des décisions de second choix. Dans la mesure où les contrats de service deviennent explicites et négociés, SDN est aussi un vecteur de simplification : l application n a plus besoin d embarquer de mécanismes de sondes réseau ou de codecs adaptatifs, le réseau peut être allégé de ses fonctions d inspection applicatives avancées. La promesse principale de l architecture SDN réside donc dans l accélération et la fiabilisation du déploiement des configurations réseau. Cela peut conduire à changer radicalement la vie des exploitants réseaux : le provisionning devient une affaire d heures et non de jours. L agilité globale de l IT est alors démultipliée, les coûts d exploitation réseau sont fortement réduits. SDN constitue aussi un moyen d être proactif plutôt que réactif. En cas de redéploiement ou via une simulation préalable, si le contrat de service applicatif ne peut être reconduit partout, l administrateur en aura connaissance. Une autre vertu du SDN, dans un contexte de Cloud externe, est la maîtrise de la facture. Si votre contrat Cloud vous garantit un débit ou un volume inclus en sortie du Cloud, cela est généralement assorti d une pénalité en cas de dépassement (exemple : +5 par tranche de 100 Mo supplémentaire). Avec SDN, le Client aurait la possibilité de fixer à l avance le contrat de débit par application, et donc de calquer le pic de débit global ou le volume mensuel sortant sur celui de son offre Cloud. L architecture Software Defined Network Une architecture SDN repose sur un hyperviseur central spécifique, le contrôleur SDN, qui fait la jonction entre les applications au Nord et les équipements réseau au Sud. L interface Sud peut s appuyer sur le standard OpenFlow, largement adopté par les principaux constructeurs réseau. L implémentation repose sur 3 niveaux bien distincts. Ce triple niveau, adossé à une API standard résout ce qu un orchestrateur de Cloud pourrait difficilement faire seul dans un environnement réseau hétérogène. application layer control layer infrastructure layer Business Applications API API API SDN Control Software Network Services Control Data Plane interface (e.g., OpenFlow) 5 Conseiller
Agilité Réseau : de la lumière au bout du tunnel! 1. La couche Applicative Elle exprime des besoins aux couches inférieures : des applications SDN et/ou des orchestrateurs de cloud interagissent avec le contrôleur SDN via API ouvertes, comme par exemple des API OpenStack. L ONF (Open Networking Forum) travaille sur la normalisation de ces API. A noter qu une application doit donc être rendue «compatible SDN», par l intégration de cette API au sein de l application. 2. La couche de contrôle Il s agit du contrôleur SDN, qui fait la jonction entre les applications au Nord et les équipements réseau au Sud. Il traduit les requêtes faites par les applications en langage compréhensible par les composants d infrastructure réseau. Inversement, elle remonte aux applications SDN les événements détectés par les composants actifs. 3. La couche d infrastructure Elle contient les nœuds réseau, qui échangent des instructions et informations avec la couche de contrôle au travers d un protocole dédié, classiquement OpenFlow. Les ordres logiques du contrôleur SDN sont traduits en actions compréhensibles par les commutateurs, routeurs, AP WiFi, etc, qu ils soient physiques ou virtuels. Qu est-ce qu OpenFlow? décisions de forwarding sont entièrement déléguées à un organe central : le contrôleur SDN. Celui-ci a la visibilité complète des flux car il est sollicité à chaque nouveau flux vu par les nœuds réseau. C est lui qui décide, selon les algorithmes positionnés par l administrateur, le comportement à appliquer sur chaque flux : choix du port de sortie, marquage, blocage, Ainsi, dans un monde complètement SDN, les nœuds réseau n ont plus à implémenter de protocoles de routage, seulement un lien OpenFlow vers le contrôleur qui leur délivre les décisions en temps réel. C est un changement conséquent car jusque-là chaque équipement réseau devait embarquer lui-même de quoi décider ce qu il faut faire de chaque paquet, via des protocoles toujours plus nombreux et complexes, ce qui générait d une part une puissance de calcul locale croissante et d autre part une évolutivité difficile car un changement protocolaire impliquait une mise à jour globale des nœuds réseau, avec un impact sur le trafic. SDN Controller Routing Trafic Engineeriing Network OS Mobility Control Plane Data Plane Openflow est une API ouverte entre les applications et le réseau. Elle donne un accès direct au «Data Plane», qui opère la gestion des flux (routage, filtrage, marquage, ). Il devient alors possible de piloter les flux par une entité externe au réseau, typiquement un contrôleur SDN. Les spécifications d OpenFlow sont pilotées par l ONF (Open Networking Foundation), la 1 ère version est parue en février 2011. Elles continuent d évoluer, mais déjà de nombreux équipementiers commercialisent des produits intégrant ce protocole : Juniper, Cisco, Arista, Brocade, Extreme Networks, IBM, NEC, Network Nodes Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding L idée majeure de l architecture SDN est d extraire les Control Plane des équipements réseau pour les regrouper en central. Par ce biais, les règles et Autre changement majeur : un unique Control Plane a désormais une vision globale et temps réel sur l ensemble du réseau en termes de flow (source + destination + application), de charge et d état (et non plusieurs Control Plane indépendants ayant seulement la connaissance vague de l état du voisin). 6
n 10 juillet 2013 Cela veut dire que le routage, qui jusque-là s appliquait le plus souvent sur un critère de destination, devient possible flow par flow, sur la base d une source, d une destination et/ou d une application (ex : tous les appels VoIP ou les flux de tel utilisateur) ou même selon un événement réseau comme le niveau de charge d un lien ou son indisponibilité. Cela ouvre comme perspective des logiques de routage avancées, développées au sein même du contrôleur SDN, sous la forme d application de Control Plane. SDN : déjà une réalité chez Google! Dès mi-2012, Google a «redesigné» ses Datacenter et son WAN interne autour d OpenFlow puis utilisé SDN comme solution de Traffic Engineering centralisé, avec des gains substantiels : meilleure utilisation de la bande passante, gestion rapide et prédictible des pannes, upgrade du Control Plane sans impact sur le trafic, vue unifiée des flux, simulations software d événements, puissance de calcul quasi-illimité du Control Plane. Comment ça marche? La collecte en temps réel des usages sur le WAN via OpenFlow alimente un contrôleur SDN qui, en fonction des données observées ou sur événement réseau, réassigne automatiquement des règles de routage sur les flux WAN, via un dialogue en direct avec les équipements réseau. La vision Beijaflore Il était temps que le marché propose de vraies solutions d agilité réseau! les Use Case du SDN vont bien au-delà et restent à inventer. L IPAM fait partie des chantiers d infrastructure à forte valeur ajoutée, et ce d autant plus que votre environnement est complexe et dynamique. Ceux qui ont franchi le cap bénéficient d améliorations opérationnelles majeures : réduction de 75% des OPEX de gestion DNS, amélioration du TTM, simplification de l administration, Pour l établissement de contrats de service directement depuis les applications, la nécessité de rendre au préalable compatibles les applications est un travail de fond à ne pas sous-estimer, comme l était en son temps l urbanisation vers les architectures SOA. Il sera raisonnable d attendre que l interface Nord (du contrôleur SDN vers les applications) soit aussi normalisée. «Les gains sont maximisés quand un projet d IPAM est couplé à une évolution des architectures DNS/ DHCP, créant ainsi l opportunité de basculer vers une solution DDI globale, cohérente, optimisée, fiable et sûre. Parmi les solutions de type «appliance», celles en GRID (plusieurs nœuds synchronisés) apportent le plus haut niveau de résilience. Quant à SDN, c est certainement une révolution dont on ne mesure pas encore tous les avantages. Cette technologie ouvre la porte dès maintenant à des «applications réseau» nouvelles telles que le Traffic Engineering centralisé et avancé, comme l a déjà implémenté Google. Les environnements Data Center et WAN sont les premiers concernés. Mais Pour ce qui est de l avenir, il ne s agit pas de le prévoir, mais de le rendre possible.» Antoine de Saint-Exupéry SDN et OpenFlow ont l énorme avantage d être ouverts. La standardisation de l Open Networking Forum rend plausible une nécessaire interopérabilité entre constructeurs et un management unifié. L ensemble des acteurs du marché s investit pleinement dans cette direction. Le déploiement de SDN peut tout à fait être progressif et en overlay par rapport au réseau traditionnel, les deux plans de contrôle pouvant fonctionner en parallèle dans les commutateurs et les routeurs réseau. Il est crucial de s y préparer dès maintenant : rendre le réseau compatible, identifier les Business Case pertinents dans votre contexte, sélectionner une solution de contrôleur SDN adaptée à vos besoins. 7
Agilité Réseau : de la lumière au bout du tunnel! Vous accompagner Besoin d optimiser vos processus de delivery IP? Un projet de sourcing IPAM? En recherche d expertise pour un Data Center NG et la virtualisation de vos réseaux? Envie d y voir plus clair dans les possibilités offertes par SDN? Fort de son expérience dans l évolution et la performance des DSI, Beijaflore est un partenaire fiable pour vous accompagner dans vos projets d agilité réseau. Depuis plus de 10 ans, nous accompagnons nos clients dans la conception de leurs architectures réseau. Experts dans les technologies réseau, nos consultants bénéficient de retours d expérience concrets et d une vision large du marché, appuyée par notre R&D interne, les «B.Communities». Notre valeur ajoutée est d être à même de porter à la fois les enjeux techniques et organisationnels, et ce des phases conseil jusqu à la mise en œuvre, pour vous assurer une transformation réussie et durable. glossaire Acronyme Définition IPAM IP Address Management SDN Software Defined Network ONF Open Networking Forum DDI DNS, DHCP, IPAM DNS Domain Name System DHCP Dynamic Host Configuration Protocol DNSSec Domain Name System Security Extension BIND Berkeley Internet Name Daemon QoS Quality of Service contacts Beijaflore Paris - Siège social Pavillon Bourdan 11-13 avenue du Recteur Poincaré 75016 Paris www.beijaflore.com skreib442@beijaflore.com sdurey596@beijaflore.com /01.44.30.92.75 Design et Impression : Solution