Installation de Contrail avec OpenStack et Kolla Ansible
Nous vous recommandons d’utiliser Contrail Command pour ajouter des nœuds de calcul aux clusters Contrail existants dans la plupart des déploiements Contrail Networking. Reportez-vous à la section Ajout d’un nouveau nœud de calcul à un cluster Contrail existant à l’aide de la commande Contrail Command.
La procédure décrite dans ce document ne doit être effectuée que par des administrateurs réseau possédant une expertise significative en matière de fichiers YAML dans des environnements n’utilisant pas l’interface graphique de Contrail Command.
L’objectif de cette rubrique est d’installer Contrail Networking avec OpenStack, à l’aide du playbook contrail-kolla-ansibleKolla Ansible .
Kolla est un projet OpenStack qui fournit des outils permettant de créer des images de conteneur pour les services OpenStack. Kolla Ansible fournit des playbooks Ansible pour déployer les images Kolla.
Le contrail-kolla-ansible playbook fonctionne conjointement avec contrail-ansible-deployer pour installer des conteneurs OpenStack et Contrail Networking.
Reportez-vous à la section Installation d’un cluster Contrail à l’aide de Contrail Command et instances.yml pour déployer un cluster Contrail à l’aide de Contrail Command.
Suivez la procédure pour déployer des conteneurs Kolla à l’aide contrail-kolla-ansible de conteneurs et des conteneurs Contrail Networking à l’aide de contrail-ansible-deployer:
Configurer l’hôte de base
Mettez à jour CentOS et la version du noyau. Pour obtenir la liste des plates-formes prises en charge, reportez-vous à https://www.juniper.net/documentation/en_US/release-independent/contrail/topics/reference/contrail-supported-platforms.pdf.
Le vRouter a une dépendance avec le noyau hôte.
Pour configurer l’hôte de base :
Téléchargez le package d’installation d’Ansible Deployer à partir de la page Téléchargements de Contrail .
Installez Ansible.
yum -y install epel-releaseyum -y install git ansible-2.7.10Installez python-pip.
yum install -y python-pipExécutez les commandes suivantes.
yum -y remove PyYAML python-requestspip install PyYAML requestsDécompressez le fichier tgz.
- tar xvf contrail-ansible-deployer-19<xx>.<NN>.tgzLe fichier instances.yaml se trouve à l’emplacementcontrail-ansible-deployer/config/
Configurez les paramètres Contrail et Kolla dans le fichier instances.yaml, en suivant les instructions suivantes :
La section Configuration du fournisseur (
provider_config) fait référence au fournisseur cloud sur lequel le cluster Contrail sera hébergé et contient tous les paramètres pertinents pour le fournisseur. Pour les serveurs bare metal, le fournisseur estbms.Cette
kolla_globalssection fait référence aux services OpenStack. Pour plus d’informations sur tous leskolla_globals, voir https://github.com/Juniper/contrail-kolla-ansible/.../globals.yml.Des configurations supplémentaires de Kolla (
contrail-kolla-ansible) sont possibles en tant quecontrail_additions. Pour plus d’informations sur tout ce qui est possiblecontrail_additionsà Kolla, voir https://github.com/Juniper/contrail-kolla-ansible/.../all.yml.Cette
contrail_configurationsection contient les paramètres des services Contrail.CONTAINER_REGISTRYspécifie le registre à partir duquel extraire les conteneurs Contrail. Il peut être défini sur votre registre Docker local si vous créez vos propres conteneurs. Si un registre n’est pas spécifié, il essaiera d’extraire les conteneurs du hub Docker.Si un registre personnalisé est spécifié, spécifiez-le également sous
kolla_globals.contrail_docker_registryCONTRAIL_VERSION, s’il n’est pas spécifié, utilisera par défaut la balise « latest ».Pour plus d’informations sur tous les paramètres possibles pour
contrail_configuration, reportez-vous à la section https://github.com/tungstenfabric/tf-container-builder/blob/master/containers/base/common.sh.Vous devez spécifier le roles dans le fichier instances.yaml . Dans le cas contraire, la procédure d’installation échouera.
S’il existe des valeurs spécifiques à l’hôte par hôte, par exemple, si les noms des interfaces utilisées pour « network_interface » sont différents sur les serveurs de votre cluster, utilisez l’exemple de configuration dans Exemple de configuration pour Multi Node OpenStack HA et Contrail (multi interface).
De nombreux paramètres sont automatiquement dérivés des valeurs par défaut saines (fonctionnement de la première configuration). Vous pouvez spécifier explicitement des variables pour remplacer les valeurs dérivées si nécessaire. Examinez le code pour voir la logique de dérivation.
Exemple : instances.yaml
Cet exemple est une configuration minimale pour un cluster tout-en-un à nœud unique, à interface unique et à un seul nud.
provider_config: bms: ssh_pwd: <password> ssh_user: root ntpserver: <IP NTP server> domainsuffix: local instances: bms1: provider: bms ip: <IP BMS> roles: config_database: config: control: analytics_database: analytics: analytics_alarm: analytics_snmp: webui: vrouter: openstack: openstack_compute: contrail_configuration: RABBITMQ_NODE_PORT: 5673 AUTH_MODE: keystone KEYSTONE_AUTH_URL_VERSION: /v3 kolla_config: kolla_globals: enable_haproxy: no kolla_passwords: keystone_admin_password: <Keystone admin password>Exemple : instances.yaml
Cet exemple est une configuration plus élaborée pour un cluster tout-en-un à nœud unique, à interface unique et à distance.
provider_config: bms: ssh_pwd: <password> ssh_user: root ntpserver: <IP NTP server> domainsuffix: local instances: bms1: provider: bms ip: <IP BMS> roles: config_database: config: control: analytics_database: analytics: analytics_alarm: analytics_snmp: webui: vrouter: openstack: openstack_compute: global_configuration: CONTAINER_REGISTRY: <Registry FQDN/IP>:<Registry Port> REGISTRY_PRIVATE_INSECURE: True contrail_configuration: CONTRAIL_VERSION: latest CLOUD_ORCHESTRATOR: openstack VROUTER_GATEWAY: <IP gateway> RABBITMQ_NODE_PORT: 5673 PHYSICAL_INTERFACE: <interface name> AUTH_MODE: keystone KEYSTONE_AUTH_URL_VERSION: /v3 kolla_config: kolla_globals: kolla_internal_vip_address: <Internal VIP> contrail_api_interface_address: <Contrail API Addr> enable_haproxy: no kolla_passwords: keystone_admin_password: <Keystone Admin Password>Exécutez les commandes suivantes à partir du contrail-ansible-deployer dossier :
ansible-playbook -e orchestrator=openstack -i inventory/ playbooks/configure_instances.ymlansible-playbook -i inventory/ playbooks/install_openstack.ymlansible-playbook -e orchestrator=openstack -i inventory/ playbooks/install_contrail.yml
Ouvrez le navigateur Web et tapez https://contrail-server-ip:8143 pour accéder à l’interface utilisateur Web Contrail.
Le nom d’utilisateur de connexion par défaut est admin. Utilisez le même mot de passe que celui qui a été saisi à l’étape 6
Exemple de configuration d’interfaces multiples pour OpenStack HA multinœud et Contrail
Il s’agit d’un exemple de configuration pour un déploiement à interfaces multiples et à plusieurs nœuds d’OpenStack et de Contrail Networking à haute disponibilité. Utilisez cet exemple pour configurer des paramètres spécifiques à votre système.
Pour plus d’informations ou pour connaître les mises à jour récentes, reportez-vous à la rubrique github Exemple de configuration pour Multi Node OpenStack HA et Contrail (multi interface).
Exemple de configuration : interfaces multiples
provider_config:
bms:
ssh_pwd: <Pwd>
ssh_user: root
ntpserver: <NTP Server>
domainsuffix: local
instances:
bms1:
provider: bms
ip: <BMS1 IP>
roles:
openstack:
bms2:
provider: bms
ip: <BMS2 IP>
roles:
openstack:
bms3:
provider: bms
ip: <BMS3 IP>
roles:
openstack:
bms4:
provider: bms
ip: <BMS4 IP>
roles:
config_database:
config:
control:
analytics_database:
analytics:
analytics_alarm:
analytics_snmp:
webui:
bms5:
provider: bms
ip: <BMS5 IP>
roles:
config_database:
config:
control:
analytics_database:
analytics:
analytics_alarm:
analytics_snmp:
webui:
bms6:
provider: bms
ip: <BMS6 IP>
roles:
config_database:
config:
control:
analytics_database:
analytics:
analytics_alarm:
analytics_snmp:
webui:
bms7:
provider: bms
ip: <BMS7 IP>
roles:
vrouter:
PHYSICAL_INTERFACE: <Interface name>
VROUTER_GATEWAY: <Gateway IP>
openstack_compute:
bms8:
provider: bms
ip: <BMS8 IP>
roles:
vrouter:
# Add following line for TSN Compute Node
TSN_EVPN_MODE: True
openstack_compute:
contrail_configuration:
CLOUD_ORCHESTRATOR: openstack
KEYSTONE_AUTH_URL_VERSION: /v3
IPFABRIC_SERVICE_HOST: <Service Host IP>
# Add following line for TSN Compute Node
TSN_NODES: <TSN NODE IP List>
# For EVPN VXLAN TSN
ENCAP_PRIORITY: "VXLAN,MPLSoUDP,MPLSoGRE"
PHYSICAL_INTERFACE: <Interface name>
kolla_config:
kolla_globals:
kolla_internal_vip_address: <Internal VIP>
kolla_external_vip_address: <External VIP>
contrail_api_interface_address: <Contrail API IP>
kolla_passwords:
keystone_admin_password: <Keystone Admin Password>
Exemple de configuration d’interface unique pour Multinode OpenStack HA et Contrail
Il s’agit d’un exemple de configuration pour un déploiement à plusieurs nuds et interface unique d’OpenStack et de Contrail Networking haute disponibilité. Utilisez cet exemple pour configurer des paramètres spécifiques à votre système.
Pour plus d’informations ou pour connaître les mises à jour récentes, reportez-vous à la rubrique github Exemple de configuration pour Multi Node OpenStack HA et Contrail (interface unique).
Exemple de configuration : interface unique
provider_config:
bms:
ssh_pwd: <password>
ssh_user: root
ntpserver: xx.xx.x.xx
domainsuffix: local
instances:
centos1:
provider: bms
ip: ip-address
roles:
openstack:
centos2:
provider: bms
ip: ip-address
roles:
openstack:
centos3:
provider: bms
ip: ip-address
roles:
openstack:
centos4:
provider: bms
ip: ip-address
roles:
config_database:
config:
control:
analytics_database:
analytics:
analytics_alarm:
analytics_snmp:
webui:
centos5:
provider: bms
ip: ip-address
roles:
config_database:
config:
control:
analytics_database:
analytics:
analytics_alarm:
analytics_snmp:
webui:
centos6:
provider: bms
ip: ip-address
roles:
config_database:
config:
control:
analytics_database:
analytics:
analytics_alarm:
analytics_snmp:
webui:
centos7:
provider: bms
ip: ip-address
roles:
vrouter:
openstack_compute:
centos8:
provider: bms
ip: ip-address
roles:
vrouter:
openstack_compute:
contrail_configuration:
CONTRAIL_VERSION: <contrail_version>
CONTROLLER_NODES: ip-addresses separated by comma
CLOUD_ORCHESTRATOR: openstack
RABBITMQ_NODE_PORT: 5673
VROUTER_GATEWAY: gateway-ip-address
PHYSICAL_INTERFACE: eth1
IPFABRIC_SERVICE_IP: ip-address
KEYSTONE_AUTH_HOST: ip-address
KEYSTONE_AUTH_URL_VERSION: /v3
kolla_config:
kolla_globals:
kolla_internal_vip_address: ip-address
contrail_api_interface_address: ip-address
network_interface: "eth1"
enable_haproxy: "yes"
kolla_passwords:
keystone_admin_password: <password>
Remplacez-le <contrail_version> par la valeur correcte contrail_container_tag pour votre version Contrail. Les valeurs respectives contrail_container_tag sont répertoriées dans README Access to Contrail Registry 19XX.
Foire aux questions
Cette section présente certaines situations d’erreur courantes et fournit des conseils sur la façon de résoudre la condition d’erreur.
- Utilisation de paramètres spécifiques à l’hôte
- Conteneurs du registre privé non accessibles
- Erreur : Échec de l’insertion du module noyau vrouter
- Erreur fatale lorsque vrouter ne spécifie pas OpenStack
- Besoin de HAProxy et d’IP virtuelle sur un seul cluster OpenStack
- Utilisation du conteneur kolla_toolbox pour exécuter des commandes OpenStack
Utilisation de paramètres spécifiques à l’hôte
Vous pouvez avoir une situation où vous devez spécifier des paramètres spécifiques à l’hôte, par exemple, les noms d’interface sont différents pour les différents serveurs du cluster. Dans ce cas, vous pouvez spécifier les noms individuels sous chaque rôle, et le paramètre le plus spécifique est prioritaire.
Par exemple, s’il n’y a pas de paramètre « network_interface » sous le rôle « openstack » par exemple « bms1 », alors il prendra son paramètre de la variable globale.
Un exemple détaillé est disponible à l’adresse suivante : Exemple de configuration pour Multi Node OpenStack HA et Contrail.
Conteneurs du registre privé non accessibles
Vous pouvez vous retrouver dans une situation dans laquelle les conteneurs extraits d’un registre privé nommé CONTAINER_REGISTRY ne sont pas accessibles.
Pour résoudre le problème, vérifiez que REGISTRY_PRIVATE_INSECURE est défini sur True.
Erreur : Échec de l’insertion du module noyau vrouter
Vous pouvez avoir une situation dans laquelle le module vrouter n’est pas installé sur les nœuds de calcul, avec le conteneur vrouter dans un état d’erreur et les erreurs sont affichées dans les journaux Docker.
[srvr5] ~ # docker logs vrouter_vrouter-kernel-init_1 /bin/cp: cannot create regular file '/host/bin/vif': No such file or directory INFO: Load kernel module for kver=3.10.0 INFO: Modprobing vrouter /opt/contrail/vrouter-kernel-modules/3.10.0-957.11.6.el7.x86_64/vrouter.ko total used free shared buff/cache available Mem: 62G 999M 55G 9.1M 5.9G 60G Swap: 0B 0B 0B total used free shared buff/cache available Mem: 62G 741M 61G 9.1M 923M 61G Swap: 0B 0B 0B insmod: ERROR: could not insert module /opt/contrail/vrouter-kernel-modules/3.10.0-957.11.6.el7.x86_64/vrouter.ko: Unknown symbol in module ERROR: Failed to insert vrouter kernel moduleDans cette version, le module vrouter nécessite que la version du noyau hôte soit 3.10.0-957.11.6.el7.x86_64. Pour obtenir cette version du noyau, avant d’exécuter le provisionnement, installez la version du noyau sur les nœuds cibles.
yum -y install kernel-3.10.0-957.11.6.el7.x86_64 yum update reboot
Erreur fatale lorsque vrouter ne spécifie pas OpenStack
Vous pouvez rencontrer une erreur fatale lorsque vrouter doit être provisionné sans nova-compute.
2018-03-21 00:47:16,884 p=16999 u=root | TASK [iscsi : Ensuring config directories exist] ******************** 2018-03-21 00:47:16,959 p=16999 u=root | fatal: [ip-address]: FAILED! => {"msg": "The conditional check 'inventory_hostname in groups['compute'] or inventory_hostname in groups['storage']' failed. The error was: error while evaluating conditional (inventory_hostname in groups['compute'] or inventory_hostname in groups['storage']): Unable to look up a name or access an attribute in template string ({% if inventory_hostname in groups['compute'] or inventory_hostname in groups['storage'] %} True {% else %} False {% endif %}).\nMake sure your variable name does not contain invalid characters like '-': argument of type 'StrictUndefined' is not iterable\n\nThe error appears to have been in '/root/contrail-kolla- ansible/ansible/roles/iscsi/tasks/config.yml': line 2, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n---\n- name: Ensuring config directories exist\n ^ here\n"} 2018-03-21 00:47:16,961 p=16999 u=root | to retry, use: --limit @/root/contrail-ansible- deployer/playbooks/install_contrail.retryIl existe un cas d’utilisation dans lequel vrouter doit être provisionné sans être accompagné par nova-compute. Par conséquent, le « openstack_compute » n’est pas automatiquement déduit lorsque le rôle « vrouter » est spécifié. Pour résoudre ce problème, le rôle « openstack_compute » doit être explicitement indiqué avec « vrouter ».
Pour plus d’informations sur ce cas d’utilisation, reportez-vous au bogue #1756133.
Besoin de HAProxy et d’IP virtuelle sur un seul cluster OpenStack
Par défaut, tous les services OpenStack écoutent sur l’interface IP fournie par les kolla_internal_vip_address/network_interface variables de la kolla_globals section config/instances.yaml. Dans la plupart des cas, cela correspond au réseau ctrl-data, ce qui signifie que même Horizon ne fonctionnera plus que sur le réseau ctrl-data. Kolla ne fournit un accès à Horizon sur le réseau de gestion qu’en utilisant HAProxy et keepalived. L’activation de keepalived nécessite une adresse IP virtuelle pour VRRP, et il ne peut pas s’agir de l’adresse IP de l’interface. Il n’y a aucun moyen d’activer HAProxy sans activer keepalived lors de l’utilisation des paramètres de configuration Kolla. Pour cette raison, vous devez fournir deux adresses IP virtuelles : une sur la gestion (kolla_external_vip_address) et une sur ctrl-data-network (kolla_internal_vip_address). Avec cette configuration, Horizon sera accessible sur le réseau de gestion à l’aide du kolla_external_vip_addressfichier .
Utilisation du conteneur kolla_toolbox pour exécuter des commandes OpenStack
Le répertoire /etc/kolla/kolla-toolbox de l’hôte de base sur lequel s’exécutent les conteneurs OpenStack est monté et accessible depuis /var/lib/kolla/config_files l’intérieur du kolla_toolbox conteneur. Si vous avez besoin d’autres fichiers lors de l’exécution de commandes OpenStack, par exemple la commande openstack image create a besoin d’un fichier image, vous pouvez copier les fichiers appropriés dans le /etc/kolla/kolla-toolbox répertoire de l’hôte de base et les utiliser à l’intérieur du conteneur.
L’exemple suivant montre comment exécuter des commandes OpenStack de cette manière :
# ON BASE HOST OF OPENSTACK CONTROL NODE
cd /etc/kolla/kolla-toolbox
wget http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img
docker exec -it kolla_toolbox bash
# NOW YOU ARE INSIDE THE KOLLA_TOOLBOX CONTAINER
(kolla-toolbox)[ansible@server1 /]$ source /var/lib/kolla/config_files/admin-openrc.sh
(kolla-toolbox)[ansible@server1 /]$ cd /var/lib/kolla/config_files
(kolla-toolbox)[ansible@server1 /var/lib/kolla/config_files]$ openstack image create cirros2 --disk-format qcow2 --public --container-format bare --file cirros-0.4.0-x86_64-disk.img
+------------------+------------------------------------------------------+
| Field | Value |
+------------------+------------------------------------------------------+
| checksum | 443b7623e27ecf03dc9e01ee93f67afe |
| container_format | bare |
| created_at | 2018-03-29T21:37:48Z |
| disk_format | qcow2 |
| file | /v2/images/e672b536-0796-47b3-83a6-df48a5d074be/file |
| id | e672b536-0796-47b3-83a6-df48a5d074be |
| min_disk | 0 |
| min_ram | 0 |
| name | cirros2 |
| owner | 371bdb766278484bbabf868cf7325d4c |
| protected | False |
| schema | /v2/schemas/image |
| size | 12716032 |
| status | active |
| tags | |
| updated_at | 2018-03-29T21:37:50Z |
| virtual_size | None |
| visibility | public |
+------------------+------------------------------------------------------+
(kolla-toolbox)[ansible@server1 /var/lib/kolla/config_files]$ openstack image list
+--------------------------------------+---------+--------+
| ID | Name | Status |
+--------------------------------------+---------+--------+
| e672b536-0796-47b3-83a6-df48a5d074be | cirros2 | active |
| 57e6620e-796a-40ee-ae6e-ea1daa253b6c | cirros2 | active |
+--------------------------------------+---------+--------+