 Bonjour tout le monde et bienvenue. Merci d'être avec nous aujourd'hui. Nous allons commencer et je vais laisser mon collègue l'introduction. Ah non. Ok, c'est Alexandre. Je suis Gaitan. Nous travaillons pour Red Hat depuis le début de l'innovation. Nous sommes des départements du CIP, donc la pratique de l'innovation de l'innovation. Nous sommes des consultants de cloud technique. Alex est basé en Paris et basé en Montréal. Comme consultant de cloud technique, nous avons eu de nombreux plateformes de cloud, comme public, privé, utilisant différentes méthodes, manualement, automatiquement, etc. Nous avons dû soutenir la plateforme que nous avons déployée. Nous avons eu des problèmes pendant ce soutien et ce sera le objectif de ce talk. Nous allons commencer par présenter à vous notre software de déployement. A Red Hat, nous utilisons un produit qui s'appelle OSP Director. Je ne sais pas si vous avez entendu ceci. OSP Director utilise Triple-O. Triple-O est un projet d'open stack. La logique de Triple-O est d'utiliser l'open stack pour déployer l'open stack. Vous avez un cloud qui est le premier open stack et un autre cloud qui est l'open stack qui est déployé. On utilise le module Puppet pour déployer la configuration. Nous parlerons de notre architecture standard pour déployer l'open stack. Tout le monde veut déployer l'open stack. Nous parlerons de la software que nous utilisons pour déployer l'open stack. Comment nous configurons les réseaux et ce qui est possible avec OSP Director. Nous parlerons aussi de la manière dont nous configurons les components. Ensuite, nous parlerons de 3 très importants goals pour tous les guys d'open stack. La première est de logger. Comment logger votre déployement d'open stack. La seconde est de monitorer. Comment monitorer votre cloud. La dernière est de backup. Nous allons partager avec vous pour ces 3 sujets. Il y a des outils que nous avons écrit qui sont disponibles sur GitHub. Nous sommes très heureux de le partager avec vous. La dernière partie du talk, qui est en fait l'alve de notre talk, est de partager notre expérience avec les operators d'open stack pour les dernières années. Parce que nous utilisons triple O, nous avons un cloud et un autre cloud. Ce cloud peut être un serveur bar métallique ou un serveur virtuel. Vous devez installer une distribution simple, un rail, un Fedora, selon les projets que vous utilisez. Quand le serveur est installé, vous devez installer triple O par l'OccS plugin. C'est un project RDO, un projet de communauté, comme Fedora est pour rail. Quand le cloud est prêt, vous devez pouvoir déployer le cloud. Avant de déployer, vous devez customiser des templates triple O. Les templates triple O sont juste un file. Il sera assez facile de comprendre comment changer quelque chose d'intérieur. Quand la customisation du template sera prête, vous devez pouvoir déployer l'application du cloud. L'application du cloud sera installée par IT comme un stack. IT crée des ressources, comme en déployant des nouvelles instances par l'application ironique et triple O. C'est tout. Quand votre cloud est prêt, la première chose que vous devez faire c'est de donner des informations sur les serveurs que vous devez déployer à l'ironique. Pour faire ça, vous devez avoir d'autres simples files comme l'application IPMI d'informations comme username, password etc. Et aussi, vous devez utiliser l'adresse de l'interface et vous devez utiliser l'application PIXI booting. Quand c'est terminé, l'ironique sera capable de faire des actions sur votre service. La première chose que vous devez faire est d'installer l'aspect. La première chose est de découvrir le hardware de votre service. La deuxième chose est de benchmarker votre hardware. Le benchmark n'est pas mandatory, mais c'est très recommandé. Dans le processus de benchmarking chaque partie de votre service sera testée et vous devez avec ces résultats faire sure que chaque partie de votre service est actuellement expérimentée. C'est très important de faire ça avant de déployer parce qu'à la fin d'un déployement, si quelque chose ne va pas, et je ne sais pas, le hardware est très lent, il sera plus difficile de débarquer que si vous le faites au début. Et quand la discovery, la discovery du hardware est terminée, c'est un spécial qui est appelé et que la discovery va faire est d'appliquer toutes ces informations à Swift et aussi d'updater le database et avec toutes ces informations sur le hardware de votre service installé dans le Swift dans le cloud, vous devez assurer un nouveau flavor pour des nodes ironiques. Parce qu'avant d'actuellement de faire le déployement, l'ironique doit savoir quel type de nodes ce service sera. Et vous devez bien sûr faire ça manuellement mais vous devez aussi faire ça automatiquement si vous avez 1000 services et vous devez faire ça avec un outil appelé A-H-C pour Automated Health Check et cela va utiliser la information installée dans le Swift et de cette façon, vous devez assurer un nouveau flavor pour un node ironique dans un outil automatique. L'inspection est terminée vous devez pouvoir déployer votre cloud comme je l'ai dit avant. Mais la customisation doit être performée avant le command déployé La customisation peut être de changer les choses dans le network, dans le storage ou ce que vous devez changer. Par exemple, pour le network, il peut être l'isolation du network. Vous devez utiliser un single-nick, un bonding avec VLAN, sans. La configuration peut être utilisé pour l'apprentissage et pour le network. La configuration de storage est plus utilisé pour la glace ou le cinder. Par exemple, le cinder de la back end devrait être utilisé. L'RBD1, l'NFS1, l'ISQZ1. Ce que vous devez définir. Peut-être des choses novases comme, je veux la migration de la vie entre les compétences donc vous devez définir cette option dans la configuration de template et quand toute cette configuration est faite si nécessaire, vous devez utiliser l'apprentissage et le processus de déployement de poste. Dans le OOA, l'apprentissage sera la première bout et l'apprentissage sera l'extra-configure La première bout peut être quelque chose comme avant d'établir le pipette je veux juste être sûr que tous les disques sont frais donc ça peut être une protection. Et l'action de post déployement peut être comme, je ne sais pas juste ajouter un code pour la plateforme de monitoring envoyer l'email à l'opening de l'opening pour dire que je suis déployé quand la customisation est faite vous devez pouvoir déployer le cloud déployer le cloud c'est juste une commande de commande avec quelques arguments comme la méthode tenante NTP-server tout ce que vous voulez donc vous déployez la commande de commande et crée des ressources comme, par exemple, des ressources pour NOVA pour l'instance spawner NOVA s'appuie à Ironic pour provisioner un ODE, un controller 1 un computer 1 et un storage 1 par l'utilisation d'une image glense que l'on applique avant le déployement et quand le déployement est fait il crée de nouvelles ressources à ce moment qui est lié à la configuration donc on va juste demander à Puppet de passer sur les nœuds pour configurer les contrôles, les compétences et la saison Nous utilisons les modules Puppet de la communauté et Puppet est installé dans la configuration parce que vous ne voulez pas que Puppet soit un bottleneck donc, en fait, dans les nœuds vous trouverez tous les manifestations et quand les ressources s'appliquent en utilisant la configuration Puppet on va juste déployer un Puppet sur les nœuds Les modules Puppet sont aussi déjà installés dans l'image glense que l'on utilise pour déployer et une chose qui est assez cool c'est que vous pouvez override tous les paramètres de vos modules Puppet dans les templates triple low et vous n'avez pas besoin de mettre les modules et les manifestations sur les nœuds et l'AIRA est en train d'obtenir toutes les variables sur les templates triple low et de les mettre à Puppet et la dernière fois sur l'orchestration Puppet c'est fait step by step donc, par exemple, dans step 1 on va faire sure que le database le service MySQL est correctement installé avant d'aller au step 2 et au step 3 et au step 2, par exemple pour faire la synchronisation pour tous les services OpenStack donc, c'est vraiment très rapidement comment on déploie les softwares donc, vous pouvez déployer beaucoup de nœuds comme vous voulez bien sûr, vous pouvez déployer un storage comme vous voulez être sûr d'avoir à moins de 3 nœuds pour atteindre un Corem pour le contrôleur donc, par défaut, on déploie 3 contrôleurs et pour les databases on utilise Galera dans le setup de 3 contrôleurs et on aussi utilise MongoDB et Redis, mais seulement pour 1 km avant de l'arrière vous trouverez un load balancer qui est HAProxy donc, HAProxy est en train de déployer la Galera c'est aussi en train de déployer le bus messenger et en train de déployer les services OpenStack et tous les services sont en train de déployer un pacemaker donc, par exemple, si vous voulez déployer juste un service, vous devez le faire par pacemaker et ne pas avec SystemD ou n'importe quoi dans le script c'est la liste network qui est offerte et supportée par OSP directeur, bien sûr vous pouvez ajouter un plus par juste éditing les templates la première sera la nette de provisioning et de management la nette de provisioning sera utilisée par Aronic, pour provisioner un ODE un compute, un storage ou un contrôleur quand la provisioning est faite cette nette de provisioning va devenir une nette de management parce que c'est celle que vous utilisez pour la monitoring, pour la backup ou juste pour le performer l'opérateur, l'admin la prochaine, vous avez l'API internal cette nette est relativement à la communication de clusters donc, celle-ci sera utilisée par Galera pour la sync node celle-ci est utilisée par RabbitMQ celle-ci est utilisée par OpenStack Component pour la communication entre les deux et ce sera l'endpoint dans le catalogue de Keystone la nette de provisioning est utilisée par la communication de provisioning par défaut par défaut nous utilisons la VixLan mais vous pouvez utiliser GRE ou VLAN si vous préférez la nette de provisioning c'est plus sur Nova, Glance, Cinder, Communication management de provisioning seulement édicé pour la réplication entre la safe node et la Swift node et la dernière la nette de provisioning donc, celle-ci que vous voulez utiliser par exemple, si vous voulez acheter le dashboard horizon ou peut-être juste pour acheter le public QR et ce sera aussi utilisé par la nette de provisioning donc, maintenant vous avez un OpenStack déployé et la première chose que vous voulez faire c'est faire un système centralisé donc, currently le logiciel centralisé est un prévu au directeur OSP mais pour certains projets que nous avons travaillés c'était un mandatari donc, notre recommandation c'est d'utiliser Flu&D, Kibana, Elastic Search Stack donc, Flu&D va être rendu sur chaque service et va coller tous les logs et les envoyer à Elastic Search ce qui est le bas-end où tous les logs vont être installés installés et au-dessus vous avez Kibana qui va déployer une très belle interface avec très belles graffes et vous pourriez être capable de chercher tous les logs pour une pattern spécifique et c'est vraiment vraiment utile quand vous avez à débug et vous devez le faire rapidement la plupart du temps par exemple, si une machine virtual n'est pas ponant l'app encore plus vous serez capable de chercher tous les logs et ça va être très utile de débug votre OpenStack comme pour le logging le monitoring est en prévu nous avions de l'utiliser dans certains projets donc pour faire ça nous utilisons Senseu avec le Dashboard avec des chevaux communs par rapport à le système par exemple, juste pour savoir si le CPU la mémoire le disque le TP etc. est correcte et nous utilisons les chevaux sur le Stackforge Git Repository pour monitorer la plateforme OpenStack donc sur cette Git Repository vous trouverez que vous trouverez beaucoup de chevaux par rapport à RabbitMQ Safe Swift etc. et vous trouverez un bunch de chevaux end-users comme upload une image en glace spawn en instance assigné un IP floating créé volume attaché en instance etc. donc ces chevaux sont très utiles pour être sûr que vos end-users sont prêts à performer comme toujours. Donc avoir un monitoring système c'est une chose c'est génial pour les opérateurs mais quelque chose qu'on veut acheter c'est d'exposer ces informations pour vos utilisateurs et vous ne voulez pas leur donner accès à votre sensor dashboard parce que c'est peut-être trop compliqué pour eux et il peut être risqué pour votre sécurité donc un projet qu'on a travaillé juste de la monitoring de la sensor a écrit un simple handler qui apportera un dashboard et pour déployer un dashboard on utilise on utilise un projet qu'on a trouvé sur GitHub qui s'appelle Whiskerboard et vous pourrez déployer ce genre de très simple status page et donc nous n'avons pas des développeurs web et il y a seulement 3 statues la première sera gris donc ça signifie le service est en train tout est bien le bleu est le service est encore en train mais il y a des problèmes donc peut-être il sera un petit peu plus plus que d'habitude il sera un peu lat sur le réseau quelque chose se passe mais c'est encore en train et la dernière est rouge et c'est critique le service est en train de l'utiliser nous avons écrit un tool pour laisser l'utiliser pour pouvoir remercier ses instances ou volumes ce tool doit être emmené sur un service externe un bar métal ou un virtual avec une distribution Fedora CentOS pique ce que vous voulez à ce moment ce tool n'est qu'il faut remercier ses volumes donc quand l'utiliser est en train de remercier ses volumes il doit remercier ses volumes il doit remercier ses volumes et il doit définir si c'est vrai ou pas c'est vrai pour le backup et le fausse pour le backup si vous décidez de remercier quelque chose un account unique sera créé sur le service externe avec son nom email et ses keys et cette information sera envoyée par email et il sera capable de connecter sur le service pour obtenir le backup data en fait nous supportons 3 filesystems XFS X3 et X4 et nous nous utilisons le full et les méthodes incrementales les tools peuvent être configurés avec un file à l'intérieur de celui-là l'attention du backup le credential le service de service le login vous pouvez ajouter quelque chose et ce tool est disponible sur GitHub déjà disponible sur GitHub donc vous pouvez le faire et ajouter quelque chose à l'intérieur c'est pas officiellement mais vous verrez le lien à la fin donc maintenant je vais commencer la deuxième partie de notre talk et c'est vraiment de partager nos expériences et les issues d'être des opérateurs et des plateformes pour les dernières plusieurs années donc la première chose qu'on veut partager avec vous c'est vraiment important et assez stupide mais vous pouvez l'inforcer vraiment facilement c'est de avoir une synchronisation entre tous vos services et bien sûr vous voulez le faire avec les services NTP et les clients parce que si l'un de vos nodes Galera est en train de rejoindre il ne va pas pouvoir le faire et en fait il n'y aura pas des messages explicites dans les logs Galera donc vous pouvez prendre plusieurs heures tentant de débarter et c'est juste parce que le temps n'est pas synchronisé c'est le même avec RabbitMQ si pour exemple vous voulez l'authentifier à Kiston et la troisième partie du temps il sera dédié c'est à dire que l'un d'entre vous est en train mais encore une fois il n'y a pas des messages dans les logs et c'est le même avec des monitors mais j'espère que le safe est un peu plus verbaux et vous trouverez des messages très explicites en disant quelque chose avec les temps entre tous les services beaucoup d'issues que nous avons c'est-à-dire d'être sûr qu'on définit le même MTU donc si pas et vous utilisez un safe cluster vous avez des issues comme des performances comme les modes n'ont pas de connecteur au SD donc juste payez attention à cet paramètre l'autre issue était relativement du nord-south et de l'ouest trafic donc le nord-south c'est quand vous êtes dans la machine virtuelle dans l'instance et vous voulez par exemple juste à la date vous allez avoir le package mais c'est très lent donc il peut y avoir quelque chose sur notre issue et le sud-south sera la communication entre les instances et les compétences donc si vous avez ce genre d'issues ou oui l'issue vous devez faire 2 flags le TSO et le GSO et le QR QBR QVO et le QVB interface et normalement cette issue devrait être certaine autre issue dépendant de votre architecture c'est le filter pass de river c'est comme le trafic entre sur une interface et entre une autre par défaut ce n'est pas possible c'est possible mais c'est disable donc si vous voulez des protections de filter vous devez utiliser une commande CCTL donc c'est assez simple et la dernière que nous avons dépendant de la version de kernel que vous utilisez et seulement si vous utilisez le VXLAN c'est pour dédibler le GRO GSO et les flags sur la interface physique sur les compétences donc dépendant du VXLAN et c'est un peu dédiblé donc si vous avez payez attention à ces flags comme je l'ai dit nous utilisons HAProxy mais c'est validé pour tous les balancers et c'est vraiment stupide mais parfois vous n'oubliez pas ceci et vous avez par exemple avec la connexion max et les paramètres et aussi le time out vous voulez les mettre en accord entre votre balancère et votre basse et quand vous utilisez HAProxy vous devez faire cela dans le configuration HAProxy parce que par exemple si vous avez un très high time out pour let's say Gallera setup sur Gallera et un très très low time out sur votre HAProxy HAProxy sera le bouton de votre basse et vous ne voulez votre balancère pour être le bouton donc si vous ne voulez pas expérimenter beaucoup de blocs et de piles payez attention à ceci je suis assez sûr que beaucoup de vous ont déjà eu des problèmes avec FabitMQ si vous n'avez pas vos liens donc l'un d'entre eux est relative à l'escripteur par défaut FabitMQ vient avec un peu plus que 1.000 FabitMQ c'est une valeur donc pour éviter ce genre d'issues vous devez juste augmenter cette valeur ça dépend de la taille de votre plateforme la activité de votre plateforme donc si vous ne voulez pas expérimenter trop vite vous devez juste monitorer ceci cette fois c'est plus lié à la configuration de la compagnie donc FabitMQ c'est pas facile mais vous devez être sûr que sur votre compagnie la configuration de FabitMQ est correcte donc vous devez enlever la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la de la MySQL est aussi un softwares très critiquant quand vous déploiez l'open stack. Et comme je l'ai dit, les limites et l'accordance sont les mêmes, mais plus systémiques pour MySQL, par exemple. Les deux paramètres qu'on veut faire attention à sont, bien sûr, les limites open files et les connections max. Mais quand vous changez un paramètre dans la configuration MySQL, parfois ce n'est pas suffisant de faire ça dans le file de configuration. Vous avez aussi à faire ça, par exemple, ici, pour les limites open files. Dans les units system d, vous utilisez à commencer le service MySQL. Donc payez attention, dépendant de votre distribution et de votre set-up, pour poursuivre les updates sur votre configuration, across all servers that can be involved in the start process, for example, of the server, sorry. Nous faisons ça avec SENSU. Oui, nous utilisons SENSU to monitor everything, as the only monitoring tool. So the other parameters you want to pay attention to is max connection, and as for the RabbitMQ parameters Gaiton told you about before, you have to set them in accordance to the activity of your cloud, and you have to monitor all the values we talked about, actually not only the number of active connections. It's one of the most important for me, but monitor everything. And be sure to set the limits according to the activity of your cloud. And also be sure to take actions before you are actually eating the limits, because when you are eating the limits, the open stack will be stuck and it will be very painful to set it running again. So pay attention to that and take action before the open stack is stuck. One issue that we had with Keystone, not only one, but this one is the one who comes every time before Juno, of course. It's about the token flash. So before Juno, the Keystone token flash command was a little bit stupid. Like, okay, I see token in the tables. In the table, it's okay. I will delete, but one by one. So it's okay if you have a few tokens. But if you have thousands, of thousands, of thousands, of thousands, expired token, it will be very painful for the Keystone, for the database. So if you're running an older open stack version, you will have to use ptarchiver, so pt for Percona Toolkit, to delete the token by bulk of, for example, here, 500. So it will be quicker and safer for your Keystone and your database. Only if you're running a nice iOS or a Grizzly version. So MongoDB and Cilometer can be also a big issue. I'm sure everybody already experienced that. A lot of open stack components are sending metrics to Cilometer and Cilometer is storing it to MongoDB backend, so that's fine. But if you are just using one replica set and you have a lot of activities in your cloud, after several weeks, it will not be sufficient and MongoDB will run very slowly and Cilometer will be slow too. So one thing which is really easy to do, and I'm sure everybody heard about that before, but for those who don't, set up a sharding instead of a replica set in your MongoDB. And if you can, and if you already know before deploying that Cilometer will be very important and all those metrics will be very useful for you, do that before doing the actual deployment. You can switch from a replica set to sharding afterwards, but it will be way more difficult and it will take a long time. And for those of you who don't know which is sharding, I will try to explain it really quickly. Let's say you are storing documents about people. You will have the last name, for example, of the people. And you will say to MongoDB, instead of writing everything to one replica set with just one primary node, it will take all the rights. You say to MongoDB, ok, we have two replicas sets. And for people, for example, with their last name beginning between A and N, you will write documents about them in the first replica set. And for the other people, you will write to the other replica set. So it's quite easy to set up and Cilometer will be way more faster and you will be able to use all those metrics. By default, Cef is resilient by design. So when a node crashes, Cef is perfectly able to handle this crash and your end user will not be aware about that. An issue that we had was when the node who crashed came back in the cluster. By default, Cef wants to synchronize as fast as he can. And it's cool. But sometimes it can be very aggressive depending of the hardware that you are using. So to avoid this kind of degradation, we just tweak some value. You have a list of them on the screen. So for example, the recovery thread by default is set to 2 and we reduce to 1. And as the other, it was very benefit for the nodes and the user was not disturbed about the safe synchronization. Other issue that we had, it was very weird. We had a processor CPU stock to 200 MHz and we tried to find out if it was a Linux bug or whatever and we saw that the hardware profile defined was in power saving. So we changed it to performance and we never had this issue again. It's not only related about Cef, it's related about all your servers. So for the compute, for the storage or the controller, just be sure that you have defined the right hardware profile. So the last advice is about Glance. And especially when you are using the same backend set for example for Glance, Cinder and Nova. And by default, Glance will not show the image direct URL to the component who asked Glance. So for example, when you are spawning a new virtual machine it will download the image to Glance. So Glance is running for example on the controller so from the backend to Glance, try to convert it from QQ2 for example to RAW or even from RAW to RAW because it's like that. And upload it back to the backend but it was the same backend so it was quite useless to download it and upload it again. So by enabling copy and write, setting show image direct URL to true, you will be able to expose to Nova or any other components where the image is actually stored and it will be way more faster to spawn a new virtual machine. Be advised that it can be a security risk. Don't do that on public cloud for example because you don't want to expose information about your backend on a public cloud but if you can do that on a private cloud it will be a big improvement in terms of performance when you are starting a virtual machine. So this is all the links of all the software we talked about. So the first one is LDO project, second one is OSP director. Then you have the link to the GitHub to the board we used and then the handler we wrote. The next one is Stackforge which is a Git repository for the monitoring for OpenStack checks we used for Sensu and the last one is about Stackup, the backup tool we talked about. I will upload this presentation to SCAD or make it available somewhere in the OpenStack website so you will be able to download it. Now, if you have any questions there's a mic under the camera. So feel free to ask any question. I think you had the questions just before. So the question is do we have a white paper for the safe tuning? Maybe. I never checked about that. We did some tuning depending of the hardware if we are using SSD etc. I think we should have the official documentation of safe pretty well. We can check. If you have already an NTP server I will repeat. Please next time if you have a question please use the mic. The question is are we using a local NTP or an external NTP server? Do what you want. It depends on your setup if your server has access to an internet you can use external one but I will say if I have to choose an internal one it will be better for your security. For example, you can set up it on the undercloud so it's easy and it's more secure. Okay, so thank you and have a nice summit. Thanks.