En direct de Barcelone, jour  2 !

 

 

Que retenir du jour 2 de l’OpenStack Summit de Barcelone ?

Prenez un café, installez-vous confortablement et profitez de l’OpenStack Summit de Barcelone comme si vous y étiez: voici le résumé des faits marquants de la journée retenus par l’équipe d’Objectif Libre sur place.
Faites une pause OpenStack !TasseVintage

 

Au menu aujourd’hui :

Keynotes

Le jour 2 commence à l’auditorium pour la traditionnelle Keynote, et c’est Jonathan Bryce qui officie ce matin.

La matinée s’ouvre sur 2 chiffres qui montrent l’explosion des données – et bien sûr la nécessité d’avoir des infrastructures gérant d’immenses puissances de calcul.

> 5k Pb de données. Si jusqu’aux années 2000, il avait fallu 5000 ans pour produire 5 Petabytes de données, d’ici peu, il faudra bientôt à peine quelques heures pour produire la même quantité.

> 2 millions de m2. C’est la surface couverte par chacun des 2 DC que vient de construire China Mobile – soit 5x la taille du ranch de Jonathan Bryce.

 

Jonathan Bryce revient en Europe et à l’avenir d’OpenStack. Il se félicite des 15 clouds publics européens tournant sur OpenStack.

Quant à l’avenir, 3 points doivent concentrer les efforts de la communauté :

  • Continuer à innover
  • Collaborer
  • Savoir reproduire les succès

 

Le reste de la Keynote sera consacré à montrer en quoi “The future is multi-cloud”.

L’avenir est multi-cloud. Très bien, mais à quoi est-ce que ça ressemble ?

 

 

Infrastructure CI/CD d’OpenStack

Par Elisabeth K. Joseph de l’Infrastructure Core Team d’OpenStack détaille l’infra CI/CD d’OpenStack.

Les caractéristiques de l’infrastructure – qui sert à l’ensemble des commits :

  • 10-20k VMs par jour
  • 12 régions cloud sur 8 clouds : 7 aux US, 1 en France (OVH)
  • utilisant uniquement les APIs d’OpenStack
  • Chaîne : Git / Gerrit / Zuul / Nodepool pour les tests
  • +2000 tâches (jobs) sont lancées par heure sur cette infrastructure CI
  • +2K instances de tests tournent en continu
  • Et évidemment, une infratructure multi-clouds full-OpenStack !

Ceux utilisés par la démonstration sont OVH, Rackspace, HPE, Internap, OSIC.

La démonstration vise à ajouter en direct de plusieurs régions au cloud de production de l’infrastructure CI d’OpenStack en Allemagne, Suède, Suisse et UK – la review est validée par 2 cores en direct depuis l’auditorium.

Et… cela fonctionne parfaitement.

 

Interop Challenge – Deploy application on multicloud

Par Brad Topol, IBM

Le challenge, décidé à Austin, est relevé par 16 cloud providers, en direct. Il consiste à déployer, chacune sur son propre cloud, la même application d’entreprise avec le même Playbook Ansible, afin de montrer comment ces clouds OpenStack sont bien interopérables.

Sur scène : Open Telekom Cloud (T System), Cisco, Fujitsu, Huawei, HPE, Mirantis, Intel, OVH, rackspace, RedHat, Suse & vmware, Ubuntu (Canonical), IBM, Linaro – représentant 11 pays, et surtout 16 entreprises concurrentes, et pourtant qui sont impliquées côte à côte auprès de la communauté.

Et sur tous les postes, ça fonctionne, et plutôt rapidement, puisque tous ont déployé l’application en moins de 5 minutes.

Pour Don Rippert d’IBM, difficile de taxer les vendeurs de cloud de manque d’interopérabilité après cette démonstration.

Conclusion : le vrai gagnant, c’est le client 🙂

 

Use-case Client : Materna

Par Uwe Scariot, executive VP de Materna.

Materna est une société de services d’intégration allemand, qui développe des systèmes de tests, des applications ainsi que des solutions de management et qui est « vendor-agnostique » au niveau des clouds.

Concernant les critères qui ont guidé leur choix d’OpenStack pour leur offre de déploiement d’infrastructure, on retrouve encore une fois le quatuor gagnant : scalabilité, rapidité, coût et interopérabilité.

 

Retour d’expérience : conteneurs sur Ironic

Par José Avila de Crowdstar

Crowdstar a créé une plateforme mobile de jeux à destination des femmes qui a eu 300 millions d’installations de leurs 25 applications depuis 2008.

Les challenges de départ du projet :

  • L’utilisation de KVM
  • Les coûts
  • Le ‘bootstrapping’
  • Une petite équipe nécessitant de faire plus avec moins.

L’utilisation du baremetal a permis de relever ces challenges en apportant les bénéfices suivants :

  • performance
  • efficacité des coûts
  • rapidité de déploiement

Les avantages des conteneurs pointés par Crowdstar:

  • Rendre le contrôle aux développeurs
  • Faciliter le bootstrapping
  • Rendre les déploiements plus sûrs en packageant les images
  • La possibilité de mixer plusieurs stacks

Grâce à cette infrastructure, Crowdstar pu réduire le nombre de serveurs qu’ils utilisaient.

 

 

Démonstration : une forme de multi-cloud… plutôt innovante

api

Par Madhura Maskasky, co-fondatrice de Platform9 Systems

 

D’après les résultats du User Survey, pour 92% des répondants, le choix d’OpenStack est motivé par « avoir une plateforme standardisée et des APIs pour pouvoir avoir un réseau global de clouds privés et publics. »

 

Partant de ce postulat, l’idée de la démonstration et de créer une API pour pouvoir gérer toutes les APIs – “One API to rule them all”.

La démonstration se focalise sur le pilotage conjoint d’un cloud OpenStack et d’un cloud AWS.

La création commence depuis OpenStack : création d’un objet “réseau”, d’un réseau privé, d’un routeur… depuis Horizon. Après vérification, ces éléments sont automatiquement créés sur AWS.

La démonstration continue depuis Horizon : création et lancement d’une instance, création et rattachement d’un volume, d’une IP, … Et c’est également créé sur le cloud AWS !
Le management multi-clouds, y compris hors OpenStack, est donc bien possible via les APIs d’OpenStack.

 

 

Security & OpenStack

Par Marcus Streets de la Fondation Linux

Après le bug Heartbeed en 2014, la Core Infrastructure Initiative (CII) a été créée avec le support de 19 grands industriels afin de trouver un moyen d’améliorer la qualité des logiciels Open Source sans gaspiller d’argent et en responsabilisant les différents projets Open Source car : la sécurité c’est le problème de tous.

Afin de récompenser les projets ayant fait les efforts nécessaires (selon des critères établis par la CII), un Badge de Bonnes Pratiques a été mis en place.

40 projets ont déjà pu obtenir ce badge, parmi lesquels OPNFV et LibreOffice, OpenSSL, …

securitybadgetweet
Et c’est maintenant au tour d’OpenStack de l’obtenir pour les efforts faits par la communauté pour respecter les critères édicter. Congratulations !
En savoir plus :

https://www.coreinfrastructure.org/programs/badge-program

 

PTLs Panel autour des conteneurs

Interview des PTLs de Kolla, Magnum & Kuryr

Kolla : sert à déployer OpenStack dans des conteneurs Docker. Kolla utilise aujourd’hui Ansible pour le déploiement des conteneurs.

Magnum : sert déployer une infrastructure de conteneurs au-dessus d’OpenStack.  Grâce à Magnum, sur OpenStack vous pouvez choisir le type de conteneurs que vous déployez (k8s, Docker swarm, IC2…), y compris si vous voulez déployer des clusters de conteneurs différents.

Kuryr : a pour objectif d’amener les services de virtualisation d’OpenStack (neutron, nova, etc.) aux conteneurs, par exemple pour créer un réseau commun aux machines virtuelles et aux conteneurs.

 

Evolutions à venir des projets :

Kolla : déploiement via k8s, introduction d’autres outils d’orchestration pour déployer Kolla (Chef, Puppet, …).

Magnum : possibilité de faire des upgrades plus facilement.

Kuryr : support de k8s.

Prochains Summits

La Keynote s’achève par l’annonce des changements pour les prochains Summits.

Comme annoncé, le Design Summit va être coupé en 2 :

  • Project Team Gathering (20 feb 2017) : il y sera question de la release Ocata
  • Forum @ the Summit (May 8 2017) à Boston où seront traités les retours utilisateurs et le plan stratégique.

La release d’OpenStack tous les 6 mois va être conservée, juste un peu avancée pour Ocata.

 

Conférences et ateliers « Hands On »

Dynamic over provisionning

Les calculs de placement de workload dans OpenStack sont actuellement basés sur le chiffres relatifs à la réservation des ressources. Une autre approche, développée chez Tata Communications, consiste à utiliser la consommation réelle des ressources pour effectuer ces calculs de placement.

 

Grâce à un nouveau filtre pour le scheduler Nova (UtilizationFilter), les équipes de Tata Communication peuvent planifier le placement de nouvelles instances sur des hyperviseurs en fonction de leur utilisation réelle. Couplée aux outils de memory ballooning et d’allocation CPU dynamique, cette méthode permet d’allouer des ressources supplémentaires aux workloads qui en ont besoin.

 

La méthode développée par Tata Communication permet de maximiser l’utilisation des ressources (CPU, RAM) et donc de réduire encore les coûts d’opération du cloud.

 

 

Can OpenStack beat Amazon AWS in price ?

 

Par Bruno Lago de Catalyst IT et Bruno Morel d’Internap

 

Cette conférence intéresse beaucoup de monde : on va comparer les prix d’Amazon AWS, d’un cloud OpenStack public, et d’un cloud OpenStack privé.

Comparer Amazon AWS et OpenStack, c’est comme comparer une orange et une pomme nous dit-on.
Il est difficile d’avoir des offres fonctionnellement identiques, l’un ou l’autre offrant plus de stockage ou de mémoire. Pour le comparatif, lorsqu’il n’était pas possible d’avoir une “offre similaire”, Amazon AWS a donc été légèrement ‘avantagé’ et c’est son offre supérieure qui était prise en compte pour la comparaison.

3 critères sont retenus pour établir les prix des clouds (voir premier lien):

  • Hardware (achat de matériel, salle, etc…)
  • Emplacement
  • Services (support pour Amazon, ou les ingénieurs du client en cas de cloud privé)

Une fois que nous avons les prix, des exemples sont présentés afin de voir les différences entre les offres.

 

 

Configuration 1

Pour une application web composée de 2 instances, d’un load balancer, de stockage et 1TB de bande passante en sortie :

  • Amazon AWS : $ 493 par mois, $ 5 910 par an
  • Internap, cloud public OpenStack : $ 243 par mois, $ 2 913 par an
  • Cloud privé OpenStack : $ 334 par mois, $ 4 008 par an

Sur une offre assez basique, Amazon AWS est le plus cher, le cloud privé arrive en 2ème position. En effet, il n’y a pas assez de ressources utilisées pour qu’un cloud privé soit moins cher à ce niveau-là.

 

Configuration 2

Un deuxième exemple est proposé avec cette fois-ci une application web beaucoup plus conséquente composé d’un load balancer, 3 web serveurs sans stockage, 2 app servers avec du stockage, une base de données NoSQL et un MYSQL ainsi que 120 Gb de bande passante en sortie par mois.

  • Amazon AWS : $ 1 421 par mois, $ 17 061 par an
  • Internap : $ 1 123 par mois, $ 13 478 par an
  • Cloud privé : $ 145 par mois, $ 1 740 par an

Sur une application aussi conséquente, les prix varient beaucoup plus et c’est le cloud privé qui arrive en tête. Les différences s’amplifient encore lorsqu’on fait du Big Data, Amazon AWS revenant alors dix fois plus cher qu’un cloud privé.

En conclusion: OpenStack peut être moins cher qu’Amazon AWS sur des applications conséquentes, avec une infrastructure qui n’a pas de problème, et des ingénieurs compétents – et pour ces 2 derniers points, vous pouvez faire appel à nous !
En savoir plus :

 

 

Automating your manual test suite with a tempest plugin, scenario tests and rally

Par David Paterson et Dellet Daniel Mellado, Red Hat

Tester son application, c’est bien. La tester manuellement peut cependant poser quelques problèmes sur le long terme. Dans cette conférence, on nous présente l’utilisation de Tempest avec Rally.

Illustration de quelques problèmes avec les tests manuels :

  • La complexité de tester sur différents systèmes d’exploitation, avec différents hardware
  • La gestion des erreurs
  • Le gaspillage des ressources : lancer les tests manuellement – au lieu de travailler sur autre chose…

Pour pallier ces problèmes, Tempest et Rally fournissent une réponse viable.

Tempest est l’outil phare d’OpenStack pour faire des tests d’intégration : il est utilisé sur les plateformes de développement d’OpenStack, et plus de 1 000 tests y sont lancés par jour.
Pour pouvoir utiliser Tempest dans votre projet, il vous faut écrire un plugin. La plupart des projets OpenStack ont leur plugin Tempest (Ironic, Murano, Neutron, etc…)

Quant à Rally, c’est un outil polyvalent. Il est composé de trois fonctionnalités principales: déploiement avec DevStack, Fuel, Anvil.

 

 

Benchmark

Vérification : en utilisant Tempest, vous pouvez créer vos “scénarios” pour tester votre OpenStack. Par exemple après un déploiement, s’assurer qu’il est possible de créer un réseau, une instance dans ce réseau, etc..
L’avantage de combiner Rally avec Tempest est multiple :

  • La persistance des données : on lance les tests et on sauvegarde le résultat dans une base de données.
  • Les rapports : possibilité de créer des graphiques avec le résultat des tests
  • Le support Multi-cloud : Rally peut être installé sur un de vos serveurs et vous pouvez tester plusieurs OpenStack avec.
  • La facilité de prise en main.

La démonstration aurait été appréciée, mais des problèmes techniques l’ont empêché…

 

En conclusion : allier Tempest et Rally semble être une très bonne idée pour tester votre projet et votre OpenStack.

 

Feeling deprecated ? We are too! Let’s work together to embrace the OpenStack Unified CLI!

Par Darrin Sorentino et Chris Janiszewski

Aujourd’hui, les clients des différents projets OpenStack sont dépréciés en faveur du client unique.

Le but de l’openstackclient est d’être explicite et plus instinctif pour l’utilisateur final : un « openstack server start » est plus intuitif qu’un « nova boot ».

La syntaxe du client unique est unifiée, et un « openstack help <COMMAND> » permet d’obtenir des informations sur chaque commande disponible.

Des choix ont également été faits concernant la clarté des différentes commandes. Là où la sortie d’un « glance image-list » avait 6 colonnes, celle d’un « openstack image list » n’en a que 2. Il est aussi possible de spécifier les colonnes souhaitées pour chaque commande, ainsi que le format de sortie (JSON, CSV, yaml, shell…)

 

Le client unique propose aussi de nouvelles fonctionnalités agréables, comme le flag « –os-cloud », qui permet de remplacer les divers fichiers openrc lorsqu’on souhaite gérer plusieurs clouds. Une  auto-complétion a également été intégrée.

Des efforts ont également été faits en faveur des développeurs, avec notamment le « chargement de code à la volée » (dynamic code loading), qui facilite la création de plugins pour le client, permettant ainsi l’intégration de projets Big Tent tels que CloudKitty.

 

OpenStack is an Application! Deploy and Manage Your Stack with Kolla-Kubernetes

Par Ken Wronkiewicz (Cisco), Michał Jastrzębski (Intel) et Serguei Bezverkhi (Cisco)

OpenStack ♡ Kubernetes : déployer son OpenStack avec Kolla-Kubernetes

Le PTL de Kolla nous présente le projet de déploiement d’OpenStack dans des conteneurs. Kolla est un projet de la Big Tent très prometteur, permettant de déployer son OpenStack dans des conteneurs applicatifs Docker.

 

En partant du postulat qu’OpenStack est une application composée de nombreuses briques, les développeurs du projet Kolla nous présentent les nombreux avantages que ce type de déploiement peut apporter à OpenStack.

> Fiabilité

Les images de chacun des services d’OpenStack sont construites indépendamment et en amont du déploiement. L’image Docker à déployer en production est ainsi créée, testée et validée avant toute mise en production, ce processus assure l’administrateur que ce qui est préparé est ce qui sera déployé, et en tout point conforme à l’original.

Le mot d’ordre : « Run exactly the way you want ».

> Mises à jour sans peine

La création des images en amont est une chose, la bascule en est une autre. Le lancement d’un conteneur Docker prend peu de temps et engendre donc peu d’interruption de service lors d’une bascule entre version 1 et une version 2.

La préparation des images en amont anticipe tous les conflits de version de paquets. De plus, les mises à jour unitaires de chacun des services peuvent être faites sans souci. Seul le conteneur concerné (et donc le service associé) est modifié, pas ses voisins.

> Rapidité

Finies les installations de 6 heures, les images contiennent l’essentiel ; reste seulement la configuration. Une erreur lors du déploiement ? Aucun problème dans le cas de l’utilisation des conteneurs, on détruit et on recommence, c’est rapide.

 

Pour l’histoire, les développeurs du projet Kolla ont tergiversé entre plusieurs méthodes de déploiement :

  • Kubernetes dans ses premiers pas (solution non retenue)
  • Docker Compose (solution non retenue)
  • Ansible a été la première méthode efficace pour le déploiement, son utilisation est simple et il permet d’orchestrer efficacement les conteneurs Docker

 

 

Et maintenant ?

Le projet Kolla se tourne de nouveau vers Kubernetes. La solution a bien évolué depuis et offre de nombreuses fonctionnalités très intéressantes pour la gestion et l’orchestration des conteneurs Docker.
Pourquoi retourner à Kubernetes ?

Tout d’abord pour l’auto-scaling. Chaque conteneur peut-être répliqué autant de fois que nécessaire, que ce soit sur un même serveur physique ou non.
Kubernetes intègre de plus la notion de PetSets (cf. « Pets vs. Cattle »), cette fonctionnalité est exploitée principalement pour la base de données dans OpenStack. Et d’autres fonctionnalités telles que le service registry, et la gestion du stockage entre plusieurs conteneurs.
La présentation se finit en beauté sur une démonstration. Serguei Bezverkhi fait l’état des lieux d’un OpenStack déjà déployé : 3 nœuds de contrôle, 2 nœuds de compute.

Pour la démonstration, il localise le nœud de contrôle hébergeant le Pod « MariaDB » responsable de la base de données d’OpenStack, et éteint ce serveur.
Résultat ? Sans aucune action de sa part, le Pod est évacué de ce serveur et relancé sur l’un des contrôleurs disponibles. Après environ 5 minutes, l’OpenStack est à nouveau fonctionnel.

 

Suite à cette présentation et à cette démonstration réussie, l’équipe rappelle que le projet Kolla-Kubernetes est encore en voie de progression, et que Kolla (kolla-ansible) s’est perfectionné dans cette dernière release (Newton).

 

Call to arms ! La communauté de Kolla à besoin de vous.

 

En savoir plus :
http://governance.openstack.org/reference/projects/kolla.html

 

 

HPC, unikernels and openstack

Par Gregor Berginc and Daniel Vladusic, XLAB

Le projet européen H2020 MIKELANGELO a pour objectif l’exécution de calculs intensifs, de jobs bigdata et d’applications gourmandes en I/O sur des infrastructures de type cloud en réduisant aux maximum l’inpact de la virtualisation. Cela devrait apporter aux grands centres de calculs plus de flexibilité tant au niveau gestion de l’infrastructure que des offres de services.

L’un des axes de travail présenté est l’utilisation d’une image système appelée unikernel: il s’agit d’embarquer dans l’image non pas un OS complet mais uniquement les composants noyaux et système strictement nécessaires à l’exécution d’une application.

 

Cette technologie apporte son lots d’avantages (+) et d’inconvénients (-):
+ images de très petites tailles (gain an stockage, transfert réseau, etc)
+ démarrage de l’image en moins d’une demi-seconde en moyenne
+ sécurité accrue en retirant l’ensemble des composants non nécessaires et donc en limitant la surface d’attaque
– 1 seul et unique processus est exécuté (fork non supporté)
– absence de certaines fonctions systèmes
– processus complexe d’élaboration des images

 

Basé sur le système unikernel OVs, le projet a développé le système de packaging et de construction d’images Capstan, une version spécifique du système de calcul parallèle OpenMPI (pour utiliser des threads à la place de processus multiples), l’intégration de cloud-init pour la configuration d’une instance par les orchestrateurs cloud via REST, etc.

 

Grâce à cela, il a été possible des déployer des applications HPC ou des infrastructures Hadoop avec le minimum de modifications (voire même en utilisant directement le binaire linux quand c’était possible) avec les outils usuels d’Openstack. Les performances obtenues étaient sensiblement meilleures qu’avec l’utilisation d’images classiques et pourraient même approcher les performances natives en utilisant Ironic pour du déploiement sur machine physique.
Pour plus de détails, voir le site du projet MIKELANGELO:

https://www.mikelangelo-project.eu

 

Comment construire des images pour Trove ?

Amrith Kumar, actuel PTL de Trove, Mariam John, Gregory Haynes et Nourhene Bziouech nous ont montré les différentes manières de créer une image pour le projet de Database-as-a-Service, Trove.

 

Trove permet de déployer et de gérer le cycle de vie des bases de données dans OpenStack. Avec Trove, vous pouvez provisionner, sécuriser, gérer et mettre à jour une base de donnée.

 

Comme tous les composants dans OpenStack, son architecture est composée de plusieurs services qui communiquent à travers une file de messages (RabbitMQ), d’une base de données qui stocke les informations relatives à Trove et d’un accès API qui permet à un utilisateur d’interroger le service.

 

Lorsque vous créez une base de données via le composant de Trove, vous créez une machine virtuelle qui contient :

  • Un OS (Ubuntu, CentOS…)
  • Une application de base de données (MySQL, PostGreSQL …)
  • Un agent Trove. Ceui-ci se connecte au plan de contrôle de Trove.

 

Cela permet d’interagir avec la base de données via les APIs de Trove. Donc, pour créer une image opérationnelle pour Trove, il faut l’ensemble de ces éléments.

 

Il existe plusieurs outils pour créer des images Trove :

  • DIB (Disk Image Builder)
  • WeeWee
  • Packer
  • image-bootstrap
  • imagefactory
  • KIWI
  • etc.

Dans cette session, DIB et cloud-init ont été mis en exergue.

DIB est un outil qui est couramment utilisé dans les autres projets OpenStack pour créer des images custom (Ironic, Sahara, Octavia…). La construction de l’image se fait dans un chroot, un ensemble de scripts est exécuté.

L’autre méthode utilise cloud-init. Lorsque vous lancez une instance dans OpenStack, au moment de sa création, celle-ci exécute cloud-init qui va chercher un certain nombre d’éléments (hostname, clé SSH…) pour son instanciation. Il est possible d’ajouter des étapes comme l’installation d’une base de données, d’un agent… Le gros avantage par rapport à la première méthode, c’est que vous n’avez pas plusieurs images pour plusieurs types de base de données.

Comme vous pouvez le constater, la création d’image est loin d’être triviale. Le PTL a ajouté que la priorité pour Trove dans Ocata (la prochaine release), est d’améliorer son utilisation.

 

En savoir plus:

 

Snapdeal’s Journey from Public to Hybrid Cloud

Gaurav Gupta, VP de l’ingénierie chez Snapdeal, nous a présenté le trajet qu’a pris sa société dans le domaine du cloud computing.

 

A l’origine, le site Snapdeal été déployé sur une infrastructure basée sur du cloud public.

Un virage vers le cloud privé a été effectué récemment et la conférence revient sur les raisons qui ont poussé ce géant du e-commerce Indien à passer du cloud public au cloud privé.

 

 

Snapdeal est le leader Indien du e-commerce et présente des statistiques impressionnantes :

  • 50 millions de produits à vendre
  • 300 000 vendeurs dans 500 villes
  • 69 centres de logistique

 

 

La croissance de Snapdeal suit la croissance insolente du nombre d’internautes Indiens :

  • juillet 2016 : 371 millions d’internautes dont 306 millions sur des plateformes mobiles
  • prévisions pour 2018 : 526 million d’internautes dont la plupart seront sur des plateformes mobiles

 

 

Snapdeal est né dans le cloud public, mais ce dernier cesse d’être rentable après l’atteinte d’un point d’inflexion correspondant à la taille critique de l’infrastructure. Pour le VP : « les clouds publics sont adaptés pour des croissances imprévisibles ».

 

 

L’année dernière, Snapdeal a décidé de construire son propre cloud privé, choix dicté donc d’abord par des raisons financières.

 

 

L’infrastructure étant devenue trop importante, il était primordial de changer de stratégie cloud, comme en témoignent les chiffres ci-dessous du nouveau cloud privé :

  • 10 PB de stockage bloc et objet
  • 3 régions de datacenter
  • 3500 cœurs par rack
  • 100 % des déploiements sont automatisés
  • 500 TB de mémoire
  • Réseau fibré de 100 et 40 Gbps

 

Le choix a été également guidé par la recherche performance et de sécurité.

Snapdeal souhaitait optimiser les performances de son cloud pour ses propres usages tout en maîtrisant ses coûts, et souhaitait aussi ré-internaliser ses données pour des raisons de souveraineté nationale. Le cloud privé était donc la réponse adaptée à ces nouvelles contraintes.

Une fois le choix et l’état des lieux réalisés, il fallait pouvoir passer aisément d’un cloud public vers un cloud privé, la contrainte majeure étant que le site était en production et qu’il était inenvisageable d’avoir une interruption de service.

Les équipes techniques de Snapdeal ont fait le choix de basculer sur une infrastructure de cloud hybride, le temps de migrer les données. Une fois cette migration réalisée, l’infrastructure de cloud public ne servirait plus que lors des pics de charges prévisibles.

 

En conclusion : le cloud public est tout a fait adapté pour des plateformes dont on ne connaît pas le trafic et dont le volume n’est pas trop important. Passée une taille critique d’infrastructure, il n’est plus viable économiquement de rester sur des clouds publics. Et si on souhaite optimiser et/ou customiser son cloud, le cloud privé est la réponse adaptée aux entreprises de e-commerce.

 

Des chiffres, pourquoi faire ?

Par Ildiko Vancsa

Pour les entreprises

Un des points d’attention lorsqu’on fait le choix d’un produit Open Source dans le cadre d’un projet, est la santé du produit lui-même.

Pour se faire une idée de l’évolution d’OpenStack, la fondation OpenStack met à disposition plusieurs outils de statistiques, le plus connu étant stackalytics.

Grâce à cet outil, il est possible de se rendre compte de la santé des projets de la Big Tent. Par exemple, il est possible de connaître la liste des entreprises qui participent à tel ou tel projet. Quelles personnes ont fait le plus de code review sur glance pour la version Newton par exemple ?

Il ne faut pas perdre de vue que ces indicateurs sont imparfaits et ce pour plusieurs raisons:

  • certaines personnes / entreprises ne jouent pas le jeu et tentent de grossir ces statistiques qui sont essentiellement basées le code applicatif
  • une entreprise peut intervenir sur un projet à un instant T pour un besoin spécifique et ne pas prendre le temps de maintenir ce code dans le futur
  • essentiellement basés sur les changements de code, ces indicateurs ne prennent pas en compte tous les autres efforts nécessaires pour faire fonctionner un projet Open Source (intervention sur les mailing lists, participation sur IRC, etc.)

Pour pouvoir affiner les tendances, la Fondation met en place un autre portail de statistiques qui prend en compte un éventail plus large, notamment la participation aux mailing lists : http://activity.openstack.org/dash/browser/

Toutes ces statistiques permettent d’approcher plus finement la réalité du projet et de mieux comprendre le fonctionnement de la communauté OpenStack.

Il est possible au travers de ces outils de déterminer sur quel fuseau horraire travaillent les contributeurs. Cela peut surprendre, mais lorsqu’il faut participer à un projet d’envergure mondiale, ce type de détails a son importance pour une optimisation des communications et donc plus d’efficacité.

Ces données peuvent aussi faire partie du management de vos équipes de développement. En effet, elles peuvent entrer en jeu dans l’appréciation du travail réalisé, voire dans la liste des objectifs à atteindre.

 

Pour les contributeurs

L’utilisation de ces données est intéressante à titre personnel en facilitant le suivi de l’évolution de ses propres contributions au sein d’un ou plusieurs projets.

Ainsi, il est possible de réaliser que sur certains projets on fait essentiellement du code review tandis que sur d’autres on contribue.

Enfin, pour celles et ceux qui souhaiteraient travailler dans l’Open Source, le fait de contribuer activement à des projets peut faire la différence.

QoS dans neutron

Jusqu’à présent, il était difficile de faire de la QoS de qualité dans OpenStack.
Effectivement, les paramètres permettaient uniquement de mettre en place du rate limiting. Le rate limiting a la facheuse tendance d’être bête et méchant et de limiter le débit sur le lien peut importe l’utlisation du média ou le type de trafic. Il n’était donc pas possible d’appliquer des priorités comme on en trouve dans le monde réseau classique.

Depuis la release de la version Newton d’OpenStack, Neutron est capable de gérér le marquage des paquets via DSCP. Ce marquage permet d’effectuer le traitement de la QoS sur les équipements réseau et donc d’utiliser les mêmes règles que dans un déploiement physique. En outre ce marquage est appliqué même au dessus des réseau d’overlay afin de ne pas perdre l’information.
C’est un grand pas en avant dans la gestion des services de type VoIP dans OpenStack.

Holistic security for OpenStack Cloud

par Major Hayden – Rackspace

« storm is coming » – les équipes sécurité se sentent souvent seules pour gérer les vagues successives d’attaques. C’est d’autant plus vrai sur les systèmes OpenStack vu la complexité des architectures.

Une approche holistique de la sécurité est donc de plus en plus souvent appliquée:

  • Assumer qu’un attaque aboutira (le tout n’est pas de savoir si mais quand)
  • Les attaquants peuvent se tromper souvent mais une erreur de la défense et c’est fini
  • Les différentes briques du système forment un tout cohérent, une petite amélioration de la sécurité sur une des briques améliore celle de l’ensemble
  • La vision de la sécurité périmétrique (le chateau fort) n’a plus lieu d’etre, il faut aller plus loin

C’est la La défense en profondeur : c’est à dire renforcer de l’exterieur vers l’interieur par couche tel un onion

  • Périmètre exterieur
  • Control & data planes
  • Services openstack
  • Services d’arrière plan

Nous allons détailler les différents concepts…

Périmètre exterieur
Le but est de convaincre l’attaquant d’aller attaquer un autre cloud. Rendre votre cloud trop couteux à attaquer et faire passer l’attaquant au cloud suivant. Plusieurs approches peuvent être mises en oeuvre:

  • Restreindre les accès : utiliser un VPN
  • Ségrégger les réseaux internes
  • Mettre en place des règles de filtrage
  • Auditer les journaux et la supervision pour réagir au plus vite
  • Surveiller la bande passante (avec Netflow par exemple)

Control plane et data plane
Le control plane est constitué des briques de controle d’OpenStack (nova, keystone…) et le data plane est constitué des hyperviseurs et des backends de données.
Le but est de limiter les accés au control plane et de le protéger d’attaques venant des machines guest. Pour celà on mettra en oeuvre:

  • Séggrégation du control plane, des hyperviseurs et des tenants d’infrastructure par des VLANs et firewall
  • Utilisation de SELinux ou Apparmor !!! et ne pas les désactiver !!!

Services OpenStack
C’est la partie la plus difficile à mettre en oeuvre. Quelques règles simples peuvent améliorer la situation:

  • Connaitre toutes les communications valides, filtrer et alerter sur toutes les autres : la plupart des interactions entre services sont prédictibles (en général seulement quelques ports par services)
  • Utiliser des comptes Keystone différents pour chaque services
  • Superviser les accès

Services d’arrière plan : Ne donner pas l’accès à vos bijoux
Les services d’arrière plan sont les services hébergeant les données sensibles permettant à OpenStack de fonctionner (Mysql, RabbitMQ, Memcached…)
Le but est de bien séggréger en différents cercles les services vous donnant des informations sur la localisation de vos bijoux (services openstack) de vos bijoux (service d’arrière plan). Quelques règles de bases existent pour celà:

  • Principe du moindre privilège : restriction forte d’accès à ces services (règle de filtrage par adresses IP et Ports source et destination)
  • Containerisation des services : permet un control plus fin des restrictions
  • Utiliser des credentials différents pour chaque compte de base de données et queue de messages

A noter que ce n’est pas si douloureux à mettre en place si c’est pris en compte dans les outils de déploiement comme openstack-ansible

En résumé

  • Analyser, isoler, surveiller, recommencer
  • Utiliser openstack-ansible ou toute autres solution en oeuvre une bonne partie de ces conseils