csmart.swift
Swift
Ceci est un rôle pour mettre en place et gérer des clusters OpenStack Swift. Actuellement, il prend en charge des nœuds PACO exécutant tous les services Swift : Proxy, Compte, Conteneur et Objet.
Cela fera :
- Préparer les nœuds Swift, y compris la configuration de SELinux et s'assurer de l'accès SSH
- Ajouter des dépôts et installer des paquets
- Configurer les services dépendants, tels que le journalisation, rsyncd et memcached
- Configurer keepalived pour la bascule des VIPs proxy
- Configurer les services Swift PACO
- Créer des anneaux initiaux de compte, de conteneur et d'objet
- Préparer les disques sur chaque nœud, formater et monter selon les anneaux
- Construire et distribuer les anneaux
- Configurer la dispersion
- Effectuer des tâches opérationnelles simples telles que :
- Mettre à jour et distribuer les anneaux
- Reconfigurer les services PACO
- Générer des rapports de dispersion et de réplication
Exigences
Un inventaire de nœuds CentOS 8 Stream préexistants avec leur réseau configuré.
Le cluster nécessite une machine administrative (incluse dans le groupe swift_admin
) à partir de laquelle tous les nœuds Swift sont gérés. Cela peut être l'un de vos nœuds Swift, si vous n'avez pas de serveur d'administration séparé.
Si vous construisez un cluster Swift virtuel, envisagez d'utiliser le rôle Ansible csmart.virt_infra
à l'adresse https://github.com/csmart/ansible-role-virt-infra.
Un inventaire d'exemple et des playbooks peuvent être trouvés sur https://github.com/csmart/virt-infra-swift pour csmart.virt_infra
et csmart.swift
.
Variables de rôle
Ce rôle a un certain nombre de variables par défaut, qui sont réparties dans des fichiers individuels sous defaults/main/
.
Celles-ci incluent des paramètres communs pour un cluster Swift, ainsi que des valeurs par défaut pour des services Swift spécifiques.
- account-rings.yml
- account.yml
- container-rings.yml
- container.yml
- dispersion.yml
- hash.yml
- networks.yml
- object-rings.yml
- object.yml
- packages.yml
- proxy.yml
- swift.yml
- tempauth.yml
Les variables globales requises que l'utilisateur doit définir incluent :
swift_hash_suffix
- le suffixe de hachage du cluster, une fois défini, il ne doit pas être changé- par défaut
07b4ef9c-2e01-4ea2-a109-5ffc5273225f
- par défaut
swift_hash_prefix
- le préfixe de hachage du cluster, une fois défini, il ne doit pas être changé- par défaut
f9175259-ace0-48bb-af9d-e7ac505b89d2
- par défaut
swift_outward_subnet
- le sous-réseau CIDR routable pour les connexions externes (pour les nœuds proxy)- par défaut
203.0.113.0/24
- par défaut
swift_cluster_subnet
- le sous-réseau CIDR de communication du cluster- par défaut
192.0.2.0/24
- par défaut
swift_replication_subnet
- sous-réseau CIDR de réplication (peut être le même que le cluster)- par défaut
198.51.100.0/24
- par défaut
Les variables spécifiques aux nœuds requises que l'utilisateur doit définir incluent :
swift_outward_ip
- IP sur le réseau sortant- par exemple,
203.0.113.11
- par exemple,
swift_cluster_ip
- IP sur le réseau du cluster- par exemple,
192.0.2.11
- par exemple,
swift_replication_ip
- IP sur le réseau de réplication- par exemple,
198.51.100.11
- par exemple,
swift_vips
- liste des VIPs proxy, 4e octet de l'IP- Chaque nœud proxy doit lister le 4e octet de l'IP VIP par ordre de préférence. Par exemple, basé sur le sous-réseau sortant par défaut de
203.0.113.0/24
, voici un nœud qui veut les VIPs203.0.113.111
,203.0.113.112
et203.0.113.113
.
swift_vips: - 111 - 112 - 113
- Chaque nœud proxy doit lister le 4e octet de l'IP VIP par ordre de préférence. Par exemple, basé sur le sous-réseau sortant par défaut de
swift_rings_disks
- liste de dictionnaires définissant quels disques utiliser pour quel anneau- Les disques de chaque nœud doivent inclure le chemin et le poids qu'ils doivent avoir pour un anneau. Par exemple, voici un disque SCSI à utiliser pour les objets et un NVMe à utiliser pour le compte et le conteneur.
swift_rings_disks: - disk: device: sdb rings: - name: account weight: 0 - name: container weight: 0 - name: object weight: 100 - disk: device: nvme0n1 rings: - name: account weight: 100 - name: container weight: 100 - name: object weight: 0
Dépendances
Aucune.
Exemple de Playbook
Le répertoire virt-infra-swift
à l'adresse https://github.com/csmart/virt-infra-swift fournit un ensemble d'exemples de playbooks et un inventaire d'exemple.
Votre inventaire doit inclure les groupes suivants :
swift
(ouall
)swift_admin
swift_proxy
swift_account
swift_container
swift_object
Voici un exemple d'inventaire pour un cluster Swift PACO de trois nœuds avec les groupes requis.
swift:
hosts:
swift-admin:
swift-[01:03]:
children:
swift_admin:
hosts:
swift-admin:
swift_proxy:
hosts:
swift-[01:03]:
swift_account:
hosts:
swift-[01:03]:
swift_container:
hosts:
swift-[01:03]:
swift_object:
hosts:
swift-[01:03]:
Une fois que vous avez un inventaire de base, créer un playbook de base devrait être simple.
---
- hosts: swift
tasks:
- include_role:
name: csmart.swift
Exécuter le playbook exécutera tout le rôle et l'ensemble de tâches par défaut, dans l'ordre.
ansible-playbook -i inventory/ site.yml
Le rôle inclut également des tags pour chaque type de tâche, vous pourriez donc créer un ou plusieurs playbooks pour tous les tags ou des tags spécifiques.
---
- hosts: swift
tasks:
- include_role:
name: csmart.swift
tags:
- account
- common
- config
- container
- disks
- dispersion
- hosts
- keepalived
- logging
- memcached
- object
- packages
- prep
- proxy
- rings
- rsyncd
- selinux
- services
- system
- update
Ensuite, exécutez le playbook contre des tags spécifiques, par exemple, pour simplement reconfigurer les services de compte.
ansible-playbook -i inventory/ site.yml --tags account
Licence
GPLv3+
Informations sur l'auteur
Chris Smart https://blog.christophersmart.com
Define and manage guests and networks on a KVM host with Ansible
ansible-galaxy install csmart.swift