11
mai

En direct de Boston jour 3 !

Que retenir du jour 3 de l’OpenStack Summit de Boston ?

Prenez un café et 5 minutes pour vous mettre à jour des faits marquants de la journée retenus par l’équipe d’Objectif Libre présente à Boston:
faites une pause OpenStack !

 

Au menu aujourd’hui :TasseVintage

Project Updates : quoi de neuf sur les projets ?

Neutron

Quelques chiffres pour commencer :

  • 350 contributeurs
  • 95% d’adoption (chiffres issus du User Survey)

Les nouveautés sur Pike :

  • vers les rolling upgrades avec le versionning des objets
  • attachements multiples de ports
  • log des security groups (DROP/ACCEPT)
  • API pour la consommation des quotas
  • API de diagnostics (pourquoi mon réseau ne fonctionne pas ?)

Octavia

Le projet Octavia remplace l’extension LBaaS de Neutron. Le projet fournit du Load Balancing as a Service, en consolidant ce qui existe sur Neutron.

Nouveautés pour Pike :

  • API v2 : support keystone, RBAC, quotas
  • intégration dans les outils de déploiement (OpenStack Ansible et TripleO)
  • création d’un load balancer en 1 unique appel d’API
  • suppression en cascade (au lieu de supprimer les éléments d’un load balancer un à un)
  • intégration de l’API LBaaS v2 de Neutron

Nova

Nouveautés pour Pike :

  • documentation pour Cells V2 et l’API de placement
  • tag des ressources gérées par nova pour améliorer les recherches
  • meilleure vue sur les ressources partagées par les services et tenants
  • réduction du temps de retry pendant le scheduling
  • cells V2 :
    • meilleure visibilité des services actifs dans chaque cell
    • amélioration de l’intégration continue
    • ajouter une nouvelle cell devrait fonctionner dans Pike
  • calcul des quotas à la volée, pour éviter des désynchronisations entre la réalité et l’info en base

Unlocking the performance secrets of Ceph object storage

Cette session était une présentation de tests et benchmarks réalisés par RedHat sur le stockage objet de Ceph (Rados Gateway ou RGW). Les résultats complets seront publiés dans 3 semaines.

Des préconisations pour 4 types d’usages ont été définies :

  • Pour des petits objets, il est préférable d’utiliser une faible densité de disques (12 OSD / machine), et de stocker les pools d’index sur SSD
  • Pour une forte densité d’objets : densité plus forte (35 OSD / machine), et accélération du cache (logiciel Intel)
  • Pour gérer des gros objets : faible densité de disques, rgw_max_chunk_size passé à 4M
  • 1 hôte RGW pour 100 OSD pour des gros objets, 1 hôte RGW pour 50 OSDs pour de petits objets

Résultat surprenant mais très agréable pour les opérateur Ceph : les paramètres par défaut donnent les meilleures performances dans la très grande majorité des cas !


Pit stop at 100 mph: how to upgrade a large scale public cloud from Juno to Mitaka

Cette session présente un retour sur la migration de Juno à Mitaka d’un cloud public T-System avec l’aide de Huawei.

Préparation

Premier point primordial si vous souhaitez faire des mises à jour automatisées, la préparation :

  • Le déploiement de votre OpenStack doit être automatisé – avec Ansible
  • Une architecture miroir de validation doit être en place pour faire des tests de régression et valider la mise à jour

NDLR: La présentation est axée sur les outils Huawei mais Mistral et/ou Tempest peuvent être utilisés pour ces tests de régression.

Migration

Pour minimiser le temps d’indisponibilité, quelques retours :

  • La migration se fait en 2 étapes: 1er jour migration du control plane, les jours suivants migration du data plane
  • Mise en place de Load Balancer devant les APIs pour une mise à jour sans arrêt : ne marche que si les APIs sont retro-compatibles et que les schémas de BDD ne changent pas.
    Lors de la mise à jour Juno vers Mitaka : 40 minutes d’arrêt dues aux incompatibilités de tous les composants.

Sur les computes :

  • Une tentative de hotfix de l’hyperviseur a été présentée mais elle semble dangereuse pour les applications hébergées, et assez limitée
  • La meilleure solution semble la migration à chaud (15 s d’arrêt) : besoin de stockage décentralisé (NDLR : Ceph par exemple)
  • Dernier recours : arrêt de la machine (autour de 35 minutes d’arrêt)

Communication

Un point à bien prendre en compte : la communication vers les clients.

  • Proactive : annoncer les indisponibilités longtemps à l’avance
  • Qualitative : expliquer ce qui est fait
  • Transparente : parler ouvertement des problèmes et bugs rencontrés

Bugs rencontrés

  • Bug neutron : les VMs se lancent plus rapidement que les ports neutron. La VM n’a pas de réseaux, donc lance cloud-init, génère un nouvel UUID et clé SSH (message d’alerte SSH)
  • Problème de dernière minute bloquant : ne pas hésiter à stopper le processus même si la communication a été faite
  • Importance des tests de régression : 85 bugs OpenStack identifiés et patchés lors de cette migration

Dynamic and Continuous Auditing, Controlling, and Monitoring of all Tenant Network Flows in OpenStack at Scale

Cette session est une présentation du processus d’audit et de supervision du cloud OpenStack de Time Warner.

Le pitch

Les solutions de sécurité existantes ne sont pas adaptées au cloud :

  • Il est difficile pour les équipes sécurité d’auditer/superviser ce qui se passe sur le cloud
  • Les outils de sécurité ne sont pas « cloud ready » : ils ne sont ni scalables, ni dynamiques
  • Comment s’assurer que les règles de conformité sont en place sur l’ensemble du cloud ?

La solution à mettre en place ne doit pas limiter le « self service » utilisateur ni impacter les performances du cloud.

Quelques solutions existent mais ont des modes de fonctionnement qui ne sont pas acceptables :

  • Installation d’une VM sur chaque hyperviseur ou installation d’un agent sur chaque VM ou installation d’un module noyau
  • Prise de contrôle du SDN

Le drame

On le sentait venir, le reste de la session est une présentation marketing d’une solution commerciale… qui de plus ne répond pas au besoin et permet juste de faire du troubleshooting de réseau et security groups.

NDLR

Ne nous trompons pas, malgré l’échec de cette session, la sécurité dans le cloud est un sujet majeur.
Un des meilleurs conseils qu’on puisse donner est d’intégrer la sécurité dans les process « cloud ready » : par exemple avec l’intégration continue de la sécurité dont nous vous avions parlé lors du webinaire sur la sécurité des conteneurs, disponible en replay ici.


Les conteneurs au CERN

Après un rappel sur les fonctionnalités de Magnum, cette session s’est concentrée sur les raisons de l’utilisation de conteneurs dans l’infrastructure du CERN.

Les conteneurs sont utilisés principalement pour de l’intégration continue et de l’analyse de données. Les premiers tests de conteneurisation de services OpenStack ont été faits en conteneurisant Horizon.

Les conteneurs apportent certains avantages :

  • Isolation
  • Performance
  • Meilleur contrôle de l’utilisation des ressources
  • Facilité d’utilisation

Une des complexités du projet était l’intégration des conteneurs dans l’infrastructure existante : authentification, réseau et stockage.

2 drivers Docker spécifiques sont utilisés pour le stockage : CernVM FS et EOS FS.

Quelques chiffres :

  • déploiement d’un cluster Kubernetes de 1000 nœuds en 23 minutes
  • le cluster Kubernetes peut répondre à 7 millions de requêtes par seconde