# OpenStack #### Vers l'infini et au delà 

## Qui sommes nous ?

## Pierre LIBEAU #### Team Leader RUN

## Arnaud MORIN #### Automatisation #### Déploiement #### Intégration

## Que fait-on ?

### Public Cloud Note: ARNAUD

### VPS Note: PIERRE

# OpenStack 

Scale

1. Jusqu'à combien ?
2. Pourquoi ?
3. Comment ?

## Architecture classique 

## Architecture classique 

## Architecture classique 

## Architecture classique 

## Architecture classique 

## Architecture classique 

## RabbitMQ

### Cluster * minimum 3 noeuds Note: * ARNAUD * Au départ 2 noeuds * problème déconseillé dans un mode cluster

### Tuning de conf * pause_minority VS autoheal * sysctl Note: * ARNAUD * pause_minority c'est mieux pour nous * augmentation des timeout TCP * impact d'un split : mauvaise communication dans l'infra openstack * les service impacté majoritairement impacté nova est neutron * Le système s'emballe à cause des timeout port en build / nova compute déconnecté

### Context switching * plus de 150k/s * sélection de 2 serveurs sur les 3

### Très sensible * latence * loss Note: * ARNAUD * Augementation du domaine de panne si noeud pas dans le meme réseau

## MySQL

### Cluster Galera * minimum 3 noeuds Note: * PIERRE * 2 à 3 noeuds * héberge les services cinder, nova, neutron, glance

### Pas de HA proxy * Mauvaise expérience * Performances ? * En cas de problème * mécanisme custom * désactivation des serveurs connectés Note: * PIERRE * Exemple metadata agent * controleur répartie sur les noeuds galera

### Deadlocks ? * Noeud dédié aux ecritures Note: * PIERRE * Keystones

### Long running requests * Ralentissent les APIs * Il faut les logger * Souvent dues à la taille des tables * Purge de temps en temps Note: * PIERRE *

## Nova

### Nova API * scale assez facile * multiplication des backends

### Nova custom scheduler * stack (versus spread) * race condition quand on scale * 1 host = 1 flavor Note: * il faut des autant de host que de flavor, on peut pas demarrer petit

### Nova compute * déconnexion de rabbitmq * pas toujours de reconnexion auto * robot Note: * probleme avec oslo.messaging, fixe upsteam, pas facile de backport

## Neutron

### Architecture standard 

### Architecture OVH 

### Points forts * pas de SPOF * tous les hosts font du routage * pas de neutron l3 agent * moins complexe * pas de NAT

### Points faibles * pas de NAT * pas de floating IP * IP Fail Over * /32 dans la VM (/128 pour IPv6)

## Python

## Python * multithread * GIL * eventlet (debug difficile) * multiprocess * tuning workers * memory leak Note: * GIL = Global Interpreter Lock * eventlet = implementation de green thread pour python * genial pour les perfs network * difficile a debug * tres utilisé dans openstack (neutron) * multiprocess plus lourd

## Automatisation Note: On ne peut pas parler de sclaing sans parler d'automatisation

## Deploy as a Service (DaaS) Note: * serveur = matiere premiere * api pour gerer les serveurs (install, reboot, config raid, postinstall, etc) * DaaS * gestion de flotte de serveurs (groupe, cluster) * scaling automatique des groupes * gestion cycle de vie d'un serveur auto

## Puppet Note: * puppet gere la partie config software, apres DaaS * 1500 hosts = facile pour puppet (un pm par region)

## Autres * integration continue * prodding chaque semaine

## Conclusion