HAL Journées Réseaux de l'Enseignement Supérieur et de la Recherche
Not a member yet
1242 research outputs found
Sort by
Le chainage de fonctions réseau, une opportunité pour les réseaux de l'Enseignement/Recherche
No full textToday, the recentralisation on core business is one of the cause that forces companies outsourcing their information systems. Their hope is that they will gain flexibility and responsiveness.Hardware for implementing network functions is a constraint. Virtualisation and automation reduce the lead time of Network Virtualized Functions (NFV). However, some NFV devices (firewalls, etc.) need to be on the path.If we want to be free of geographical constraints and deploy the service in the cloud, for example, we have to redirect the traffic. It is also possible to chain several network functions, in other words, implement “service chaining”.Service chaining requires a large number of operations. To facilitate scalability, an automation mechanism is needed. The SDN (software-defined networking) solve these issues. The benefit for an operator is to offer new value-added services to its users. However, offering these services requires some adaptation because managing NFV requires cloud skills that are not naturally part of an operator’s activity.In our case, the provider create the function and supports it. The configuration is the responsibility of the users, who control of their own routing or security policy. We have been working on this proof of concept for six months. We were able to test and implement a platform based on the OpenStack Cloud Computing solution and Juniper’s SDN mechanism, CONTRAIL.Aujourd’hui, la recentralisation sur son corps de métier est l’une des raisons qui poussent les entreprises à externaliser leur SI. Elles espèrent ainsi gagner en flexibilité et en réactivité.Le matériel physique pour l’implémentation de fonctions réseau est une contrainte. La virtualisation et l’automatisation permettent de réduire le temps de provisionnement de service réseau virtualisé (NFV). Cependant, certaines NFV (Pare-feu, …) nécessitent d’être en coupure. Si l’on veut s’affranchir de la contrainte géographique et déployer le service par exemple dans un cloud, on est donc obligé de rediriger le trafic. On peut aussi chainer plusieurs fonctions réseau, c’est à dire réaliser un « service chaining ». Le service chaining nécessite un grand nombre d’opérations. Pour faciliter le passage à l’échelle, un mécanisme d’automatisation est nécessaire et le SDN répond à ces problèmes.L’intérêt pour un opérateur est de proposer de nouveaux services à valeur ajoutée à ses utilisateurs. Proposer ces services demandent cependant des adaptations, car la gestion des NFV dans le cloud requiert des compétences qui ne sont pas natives dans le coeur de métier d’un opérateur.L’opérateur fournit la fonction et son support ; la configuration est du ressort de l’utilisateur qui reste ainsi maître de sa politique de routage ou de sécurité.Nous avons mis en place cette preuve de concept pendant six mois. Nous avons pu tester et mettre en place une plate-forme basée sur la solution de Cloud Computing OpenStack et le mécanisme de SDN de Juniper, CONTRAIL
Le SD-WAN pour les nuls
No full textTwo phenomena are drastically changing WAN networks. The first one is the migration of applications to the cloud, either to a Software-as-a-Service (SaaS) model or to organizations’ private datacenter. Secondly, professional organizations are demanding the introduction of new services in their offices, shops, production sites, etc. These services digitalize remote sites and require new features such as “guest access”, the distribution of video for various uses, applications ported to tablets or smartphones, and so on.In addition to these two categories, the increased use of internet resources from the workstation for professional uses as well as for leisure has to be considered. The network must therefore be redefined to absorb these new trends:•Application visibility and performance management by application•Managing multiple WAN access points in active-active mode•Ability to access the Internet directly from a remote site without backhauling to the datacenter.The WAN is therefore evolving more than ever to guarantee application performance and security, going far beyond simply connectivity. The SD-WAN (Software-Defined WAN) is the solution presented to these observed trends. It is a matter of putting the WAN at the service of the applications, while simplifying its management.What is the SD-WAN? What are the criteria for an SD-WAN solution? You will find all the answers in our presentation entitled “The SD-WAN for Dummies”.Deux phénomènes amènent les réseaux WAN à devoir s’adapter. Il s’agit tout d’abord de la migration des applications vers le Cloud, en mode SaaS ou bien sur les datacenters privés des organisations. D’autre part, les organisations métiers demandent la mise en place de nouveaux services sur les agences, magasins, sites de production… Ces services digitalisent les sites distants et amènent de nouveaux usages comme le « guest access », la distribution de la vidéo pour des usages variés, des applications portées sur tablettes ou smartphones…A ces deux catégories s’ajoute l’augmentation de la consommation des ressources internet depuis le poste de travail pour des usages professionnels mais aussi loisir. Le réseau doit donc être redéfini pour absorber ces nouvelles tendances :•Visibilité applicative et gestion des performances par application•Gestion de plusieurs accès WAN en mode actif-actif•Possibilité d’accéder à l’internet directement depuis le site distant sans repasser par le datacenter.Le WAN évolue donc plus que jamais pour permettre de garantir performance et sécurité des applications, bien au-delà de la simple connectivité. Le SD-WAN (Software-Defined WAN) est la réponse affichée à ces tendances observées. Il est question de mettre le WAN au service des applications, tout en simplifiant son management.Qu'est-ce que le SD-WAN ? Quels sont les critères d'une solution SD-WAN ? Vous aurez toutes les réponses lors de cette présentation "Le SD-WAN pour les Nuls"
Machine Learning
No full textColin de la Higuera est professeur à l'Université de Nantes et chercheur au Laboratoire des Sciences du Numérique de Nantes (LS2N). Son domaine de recherche est l'apprentissage machine et en particulier l'inférence grammaticale, c'est à dire les méthodes permettant d'apprendre automatiquement une grammaire à partir de textes.Colin de la Higuera a été président de la Société informatique de France, espace de réflexion, de concertation sur les enjeux de l’informatique.Colin de la Huguera est Trustee de la fondation Knowledge for All et titulaire de la Chaire UNESCO en technologies pour la formation des enseignants par des ressources éducatives libres à l'Université de Nantes.Colin de la Higuera est l'auteur du livre “Grammatical Inference: Learning Automata and Grammars” [edition Cambridge University Press ISBN:0521763169, 9780521763165
Virtualisation des réseaux en environnement VMWare avec NSX
No full textBased on the experience gained during the //Federal University of Toulouse Midi-Pyrénées Private Cloud// project, the aim of this presentation is to provide an overview of the concept of network virtualisation as implemented by VMware. We will focus on the //NSX-V version dedicated to ESXi hypervisors//, comparing it briefly to the NSX-T version (for KVM hypervisors) and to other similar technologies provided by other solutions (OpenStack Neutron, Cisco ACI).In the first part, we will explain how this platform works in general and how it integrates into a vSphere environment. We will focus on the concept of //VXLAN// and //VTEP// that allow the abstraction of the physical network layer. We will detail the advantages and disadvantages of this solution in terms of implementation and operation, compared to traditional networks.In the second part, we will focus on security, presenting the concepts of //micro-segmentation// and contextual security provided by the //distributed firewall//. We will see how this component can improve segmentation compared to historical solutions such as perimeter firewalls or private VLANs. We will also explain its benefit in relation to provisioning virtual machines in a cloud environment, in conjunction with vRealize Automation.We will end by describing an essential component of the NSX architecture: the //Edge Service Gateway//, a perimeter router on the boundary of physical and virtual networks, detailing the different services that it allows to be implemented on virtualised networks (filtering, NAT, VPN, routing and high availability).In our conclusion, we will present our assessment of operating VMware NSX in a production environment for two years.Basée sur l'expérience acquise dans le cadre du projet de //Cloud privé de l'Université Fédérale de Toulouse Midi-Pyrénées//, cette présentation a pour objectif de faire un tour d'horizon du concept de virtualisation des réseaux tel qu'il est implémenté par VMWare. Nous nous focaliserons sur la version //NSX-V dédiée aux hyperviseurs ESXi//, en la comparant brièvement avec la version NSX-T (pour hyperviseurs KVM) et les technologies similaires proposées par d'autres solutions (OpenStack Neutron, Cisco ACI).En première partie, nous expliquerons le fonctionnement général de cette plateforme et la façon dont elle s'intègre dans un environnement vSphere. Nous nous attarderons sur le concept de //VXLAN// et de //VTEP// permettant l'abstraction de la couche réseau physique. Nous détaillerons les avantages et inconvénients de cette solution en termes d'implémentation et d'exploitation, en comparaison avec les réseaux traditionnels.La deuxième partie se focalisera sur la sécurité, présentant les notions de //micro-segmentation// et de sécurité contextuelle apportées par le //pare-feu distribué//. Nous verrons en quoi ce composant permet d'améliorer la segmentation par rapport aux solutions historiques : pare-feux périmétriques ou private VLANs. Nous expliquerons également son intérêt dans un contexte de provisionnement de machines virtuelles en environnement Cloud, en association avec vRealize Automation. Nous terminerons par la description d'un composant essentiel de l'architecture NSX : l'//Edge Service Gateway//, routeur périmétrique à la frontière des réseaux physiques et virtuels, en détaillant les différents services qu'il permet d'implémenter sur les réseaux virtualisés (filtrage, NAT, VPN, routage et haute-disponibilité).La conclusion présentera le bilan de deux ans d'exploitation de VMWare NSX sur un environnement de production
Sensor Observation System : optimisation d'un système d'information environnemental dédiés capteurs - exemple du SI du réseau d'observation ReefTEMPS
No full textReefTEMPS is a network of temperature, pressure and salinity sensors in the coastal area of the South, West and South-West Pacific, operated by GOPS (South Pacific integrated observatory for the environment, terrestrial and marine biodiversity). One of the initial objectives of the project was to provide different types of interoperable services, each tailored to a specific scientific user community. It also needed to incorporate a database of measurements from the sensors, some of which had been deployed for more than 40 years.Thus, the information system was created in 2011 and the use of SOS (Sensor Observation Service - http://www.opengeospatial.org/standards/sos) has seemed relevant to us since its creation. In 2016, this information system was updated.This poster will present the migration to Docker that took place in 2016. This makes it possible to simplify the deployment processes and implement the latest versions of the technologies used.The poster will also show how we moved from SOS version 1 to version 2 and how we reorganised the application both in terms of content (concept of offerings, components and systems rethought, new SOS 2.x specifications considered) and form (REST instead of SOAP, JSON preferred to XML for the exchange of data).The new version has been in production since June 2017: http://reeftemps.observatoire-gops.org. All data acquired are publicly accessible without any restriction.ReefTEMPS est un réseau de capteurs de température, pression et salinité dans le domaine côtier du Pacifique Sud, Ouest et Sud-Ouest, opéré par le GOPS (Grand Observatoire de l'environnement et de la biodiversité terrestre et marine du Pacifique Sud). Un des objectifs initiaux du projet était de fournir différents types de services interopérables adaptés pour chacun d’eux à une communauté scientifique utilisatrice particulière. Il devait aussi être intégré une base de données de mesures issues de capteurs déployés pour certains depuis plus de 40 ans.Ainsi, le système d’information a été créé en 2011 et l'utilisation de SOS (Sensor Observation Service - http://www.opengeospatial.org/standards/sos) nous a semblé pertinente dès sa création. En 2016, ce système d’information a été modernisé.Ce poster présentera le portage sous Docker réalisé en 2016. Celui-ci permet ainsi de simplifier les processus de déploiement et de mettre en place les dernières versions des technologies utilisées.Le poster montrera également comment nous sommes passés de la version 1 à la version 2 de SOS et avons réorganisé l’application tant sur le fond (notions d'offering, component et systems reconsidérées, nouvelles spécifications SOS 2.x prises en compte) que sur la forme (REST au lieu de SOAP, JSON privilégié à XML pour l’échange de données).La nouvelle version est en production depuis juin 2017 : http://reeftemps.observatoire-gops.org. Toutes les données acquises sont accessibles publiquement sans restriction
Anti-spam mutualisé "sortant" : enjeux et complexité
No full textThe shared anti-spam service, provided by RENATER (the French research and education network), was launched in 2009 to filter inbound mail flows only. By the start of 2017, this service was handling more than 2,500,000 mailboxes.The increase and sophistication of compromise vectors (phishing, hacking, including personal devices, etc.) generating malicious emails, and not forgetting the increase in the varied anti-spam mechanisms among the recipients, has significantly increased demand within the community for extending filtering services to include outgoing flows.The simple solution might have been to extend the existing infrastructure for "outgoing" filtering.The aim of this article is to explain the complexity of implementing this new service.The major challenge is obviously to avoid the shared platform being blacklisted, thus blocking all user establishments.We therefore propose to study the challenges faced in implementing the filtering of outgoing flows for the entire Teaching and Research community by addressing the concrete problems that it presents in a large-scale shared service context.In the introduction, we will detail the background to the shared anti-spam service, looking back in particular at the infrastructure put in place.We will then present the risks associated with the large-scale sharing of the outgoing filtering service and the necessary interactions with user establishments (who alone control their upstream infrastructure).Finally, we will detail the service offered to the community, both technically and organisationally.Le service anti-spam mutualisé, proposé par RENATER, a vu le jour en 2009, pour filtrer les flux de messagerie entrants uniquement. Ce service couvre, début 2017, plus de 2 500 000 boîtes aux lettres.Avec l'augmentation et la sophistication des vecteurs de compromission (phishing, piratage y compris des périphériques personnels, etc.), générant des envois de courriels malveillants, mais également la multiplication des mécanismes anti-spam de nature variée chez les destinataires, l'extension du service de filtrage, aux flux sortants, est devenue une demande forte de la communauté.Il aurait pu paraître simple d'étendre l’infrastructure existante au filtrage « sortant ». L'objet de cet article est d'exposer la complexité de la mise en place de ce nouveau service. L'enjeu majeur est bien évidemment d'éviter que la plate-forme mutualisée ne soit mise en liste noire et bloque ainsi l'ensemble des établissements utilisateurs.Nous proposons donc d'étudier les défis à relever pour la mise en place d'un filtrage des flux sortants pour l'ensemble de la communauté Enseignement Recherche en abordant les problèmes concrets qu'il pose dans un contexte de mutualisation à grande échelle.En introduction, nous préciserons les éléments de contexte du service anti-spam mutualisé, en rappelant notamment l’infrastructure mise en place.Nous présenterons ensuite les risques liés à la mutualisation à grande échelle du filtrage de flux sortant et les nécessaires interactions avec les établissements utilisateurs (qui maîtrisent, seuls, leur infrastructure en amont).Nous détaillerons enfin le service proposé à la communauté, tant du point de vue technique qu’organisationnel
Scality et le stockage distribué objet
No full textIn the context of the MyCore service at CNRS (the French National Centre for Scientific Research), this presentation will provide feedback on the selection and implementation of an innovative distributed object storage project with significant availability and capacity scalability constraints.The reasons for selecting a Software Defined Storage solution, and in particular one from Scality (www.scality.com), will be explained in detail, along with an introduction to the operating principles of this type of infrastructure.The different phases of the project will then be discussed:- definition of the hyperconverged architecture;- implementation;- importance of the pilot phase;- common operations (running, capacity planning, security).The presentation will also address the cost-related aspects of the project and its operation. To conclude, the planned changes to the infrastructure, to improve the service and develop new uses, will be outlined.Dans le contexte du service MyCore du CNRS, cette présentation fera un retour d'expérience sur le choix et la mise en place d'un projet innovant de stockage distribué objet à fortes contraintes de disponibilité et d'évolutivité de la volumétrie. Il sera présenté en détail les raisons du choix d'une solution de type "Software Defined Storage", et en particulier de Scality (www.scality.com), avec une introduction aux principes de fonctionnement de ce type d'infrastructure. Il sera ensuite abordé les différentes phases du projet :- la définition de l'architecture hyper-convergée ;- la mise en œuvre ;- l'importance de la phase pilote ;- l'exploitation actuelle (run, capacity planning, sécurité). La présentation abordera également les aspects coûts liés au projet et à son exploitation.Pour conclure, il sera exposé les évolutions envisagées de l'infrastructure afin d'améliorer le service et de développer de nouveaux usages
Utilisation de sympa pour une communication syndicale à grande échelle.
No full textThe French civil service organises its dialogue with trade unions in a very formal way.In 2014, it considered the emergence of new technologies and issued a decree that determines their use. Information for staff is an important aspect of union activity. Its dematerialisation (“going paperless”) involves message broadcasting and “Sympa” is the tool that naturally emerged in our context.Widely used in our higher education and research community, Sympa is optimised to create large numbers of lists and establish roles for everyone (owner, publisher, subscriber, etc.). Nevertheless, working out social partners was carried out before considering the technology, and we had to setup a distribution platform based on unworkable constraints: no limit on list creation, apart from the size and number of messages sent; totally anonymous unsubscribing.Given our large size (70 trade unions, 1 million subscribers), we had to find technical boundaries compatible with implementing the decree, and automate as much as possible the process of requesting lists to meet the constraints imposed.After eight months in operation, the platform broadcasts 7 million messages per month and the outcome is satisfactory, except for managing unsubscribe requests and updating subscriber lists. From the perspective of the messaging managers, dissatisfaction is due to the volume of messages transmitted, which is a direct consequence of managing the unsubscribe requests. The technology therefore has to navigate between the regulations, social agreements and its production constraints!La fonction publique française organise de manière très formelle son dialogue avec les syndicats. En 2014, elle a pris en compte l'émergence des nouvelles technologies et publié un décret qui fixe leur usage. L'information du personnel est un volet important de l'activité syndicale : sa dématérialisation passe par la diffusion de messages, et "sympa" est l'outil qui s'est naturellement imposé dans notre contexte.Largement utilisé dans notre communauté enseignement supérieur et recherche, sympa est optimisé pour créer massivement des listes et fixer des rôles à chacun (propriétaire, éditeur, abonné...). Néanmoins, la négociation des partenaires sociaux a été faite avant d'aborder la technique, et nous avons dû mettre en place une plate-forme de distribution basée sur des contraintes peu exploitables : aucune limite à la création de liste, si ce n'est la taille et le nombre de messages envoyés ; désabonnement totalement anonyme. Compte tenu de nos volumétries (70 syndicats, un million d'abonnés), il a fallu trouver des bornes techniques compatibles avec le décret d'application, et automatiser au mieux le processus de demande de listes, pour répondre aux contraintes imposées. Après 8 mois de fonctionnement, la plate-forme émet 7 millions de message par mois et le bilan est satisfaisant, à l'exception de la gestion des désabonnements et des mises à jours des listes d'abonnés. Du côté des gestionnaires de messagerie, l'insatisfaction porte sur la volumétrie transmise, conséquence directe de la gestion du désabonnement. La technique doit donc se faufiler entre la réglementation, les accords sociaux et ses contraintes de production
Migration de FUN-MOOC et ses marques blanches vers un cloud public OpenStack : retour d’expérience
No full textSince 2013, France Université Numérique (FUN) has enabled higher education institutions to develop their MOOC strategies by sharing infrastructure and services. The technology used is an open source solution called Open edX.In 2016, the migration of the platforms, from a VMware infrastructure to an OpenStack public cloud, was started.The aim of this presentation is to show how this transition took place while ensuring data security, service availability and functional continuity.This presentation will discuss the choices of architecture, the modifications made to the Open edX components to ensure their smooth operation with OpenStack, as well as the migration and automation operations, two points that are essential to getting the maximum benefit from the transition to the cloud.The chosen architecture follows a mono-services approach built on a base of virtual machines (one machine = one service).The infrastructure was industrialised into “Infrastructure as a Code” using orchestration solutions.Two different migration strategies were adopted. Firstly, a “blue/green” method to migrate the main, large-audience FUN-MOOC platform; and secondly, a “rolling release” method to migrate the “White Label” platforms to overcome the constraint of being able to replicate these platforms quickly and easily.We will detail the tools used in both cases, along with their benefits:- Automation using Ansible/Heat- Image building using Packer- Security using Vault Hashicorp- Replicability and optimisation with Docker and Rancher.We will conclude with relevant use cases, the advantages of each method and the lessons learnt from this project.Depuis 2013, France Université Numérique permet aux établissements d’enseignement supérieur de développer leurs stratégies MOOC en mutualisant les infrastructures et les services.La technologie utilisée est une solution Open Source Open edX.En 2016, la migration des plateformes, d’une infrastructure VMware vers un cloud public OpenStack, a été lancée. L’objectif de cette présentation est de montrer comment s’est opérée cette transition, tout en garantissant la sécurité des données, la disponibilité des services et la continuité fonctionnelle.Cette présentation abordera les choix d’architecture retenus, les adaptations réalisées sur les composants Open edX pour assurer leur bon fonctionnement avec OpenStack, ainsi que les opérations de migration et d’automatisation, deux points essentiels pour tirer le maximum de bénéfices du passage dans le cloud.L'architecture choisie suit une approche de mono-services reposant sur un socle de machines virtuelles (une machine = un service). L'infrastructure a été industrialisée en "Infrastructure as a code" avec des solutions d'orchestration.Deux stratégies de migration différentes ont été adoptées : d’une part une méthode « blue/green » pour migrer la plateforme principale FUN-MOOC, à forte audience ; d’autre part une méthode «rolling release» pour migrer les plateformes de Marques Blanches, pour répondre à la contrainte de pouvoir répliquer facilement et rapidement ces plateformes.Nous détaillerons les outils utilisés dans les deux cas et leur intérêt :- Automatisation avec Ansible / Heat- Construction d’images avec Packer- Sécurisation avec Vault Hashicorp- Réplicabilité et optimisation avec Docker et RancherNous conclurons sur les cas d’usage pertinents, les avantages de chaque méthode et les enseignements à tirer de ce projet
Réalisation d'expériences avec Grid'5000
No full textGrid’5000 is an infrastructure for research and experimentation of computing systems. Its main objective is to provide a testbed to carry out experiments, which can be of very different types. For example: validating that a software program, a piece of hardware or a particular configuration behaves correctly.Its use is particularly suited to the deployment of large-scale and complex systems (for example: an entire OpenStack infrastructure, a large-scale network topology, etc.), which is often difficult to achieve with the resources and tools available internally.To do this, Grid’5000 provides a large number of wide-ranging hardware resources, which can be fully reserved and reconfigured by its users, as well as a suite of software to help with experimentation setup.After introducing how the platform works and its main services, our presentation will show in a practical way how to carry out an experiment with the help of Grid’5000.We will use an example scenario that involves evaluating the hardware resources required to deploy a web application that has to satisfy a large number of client requests.The various stages required to set up this scenario will be described: reserving the hardware resources, deploying the operating system, setting up the web application within replicated Docker instances, generating the client requests and using the Grid’5000 API to collect performance metrics. We will also explain how this experiment can be scripted in a high-level language such as Python.Grid'5000 est une infrastructure pour la recherche et l'expérimentation des systèmes informatiques. Son principal objectif est de proposer une plateforme pour réaliser des expériences, pouvant être de natures très diverses : par exemple, valider le bon comportement d'un logiciel, d'un matériel ou d'une configuration.Son utilisation est particulièrement adaptée au déploiement de systèmes large échelle et complexes (une infrastructure OpenStack complète, une topologie réseau de grande envergure, etc.), souvent difficilement réalisable avec les ressources et outils disponibles en interne.Pour cela, Grid'5000 met à disposition des ressources matérielles abondantes et variées, entièrement réservables et reconfigurables par ses utilisateurs, ainsi qu'une suite logicielle pour aider à la réalisation des expériences.Après avoir introduit le fonctionnement et les principaux services rendus par la plate-forme, notre présentation montrera de manière pratique comment réaliser une expérience à l'aide de Grid'5000.Pour cela, nous nous appuierons sur un scénario d'exemple, qui consiste à évaluer les ressources matérielles nécessaires au déploiement d'une application Web devant satisfaire un grand nombre de requêtes clientes.Les différentes étapes nécessaires à la mise en place de ce scénario seront décrites : réservation des ressources matérielles, déploiement des systèmes d'exploitation, mise en place de l'application Web au sein d'instances Docker répliquées, génération des requêtes clientes et utilisation de l'API Grid'5000 pour collecter les mesures de performance. Nous expliquerons également comment cette expérience peut être scriptée dans un langage de haut niveau tel que Python