Runbooks Opérationnels¶

Introduction¶

Les runbooks documentent les procédures opérationnelles standardisées pour gérer l'infrastructure OpenStack. Ils permettent une exécution cohérente et réduisent les erreurs humaines lors des opérations de maintenance.

Prérequis¶

• Accès administrateur OpenStack
• Monitoring en place
• Troubleshooting maîtrisé
• Procédures de communication définies

Points à apprendre¶

Structure d'un runbook¶

graph TD
    subgraph "En-tête"
        t1[Titre]
        t2[Version / Date]
        t3[Auteur]
        t4[Approbateur]
    end

    subgraph "Contexte"
        c1[Objectif]
        c2[Prérequis]
        c3[Impacts]
        c4[Temps estimé]
    end

    subgraph "Procédure"
        p1[Étapes numérotées]
        p2[Commandes exactes]
        p3[Vérifications]
        p4[Points de décision]
    end

    subgraph "Rollback"
        r1[Critères rollback]
        r2[Procédure retour]
    end

    subgraph "Post-opération"
        po1[Validation]
        po2[Communication]
        po3[Documentation]
    end

    t1 --> c1
    c1 --> p1
    p1 --> r1
    r1 --> po1

RB-001: Ajout d'un compute node¶

# RB-001: Ajout d'un Compute Node

## Métadonnées
| Champ | Valeur |
|-------|--------|
| Version | 1.2 |
| Date | 2024-12-01 |
| Auteur | Ops Team |
| Temps estimé | 45 minutes |
| Impact | Aucun (capacité additionnelle) |

## Objectif
Ajouter un nouveau serveur compute au cluster OpenStack pour augmenter la capacité.

## Prérequis
- [ ] Serveur provisionné avec Ubuntu 22.04
- [ ] Réseau configuré (management, tenant, storage)
- [ ] Accès SSH depuis le deploy node
- [ ] Entrée dans /etc/hosts ou DNS
- [ ] Clé SSH déployée

## Procédure

### Phase 1: Préparation (10 min)

1. **Vérifier la connectivité**
   ```bash
   ssh root@compute-new "hostname && ip a | grep -E '^[0-9]|inet '"
   ```

2. **Mettre à jour l'inventaire**
   ```bash
   vi /etc/kolla/inventory
   # Ajouter sous [compute]:
   # compute-new ansible_host=10.0.0.24
   ```

3. **Vérifier l'inventaire**
   ```bash
   ansible -i /etc/kolla/inventory compute-new -m ping
   ```

### Phase 2: Bootstrap (15 min)

4. **Bootstrap du serveur**
   ```bash
   kolla-ansible -i /etc/kolla/inventory bootstrap-servers --limit compute-new
   ```
   **Validation:** Pas d'erreur rouge dans l'output

5. **Vérifier Docker**
   ```bash
   ssh compute-new "docker info | grep 'Server Version'"
   ```
   **Attendu:** Version >= 24.0

### Phase 3: Déploiement (15 min)

6. **Déployer les services compute**
   ```bash
   kolla-ansible -i /etc/kolla/inventory deploy --limit compute-new
   ```
   **Validation:** PLAY RECAP avec 0 failed

7. **Vérifier les containers**
   ```bash
   ssh compute-new "docker ps --format 'table {{.Names}}\t{{.Status}}'"
   ```
   **Attendu:** nova_compute, neutron_openvswitch_agent UP

### Phase 4: Intégration (5 min)

8. **Vérifier l'enregistrement dans Nova**
   ```bash
   openstack compute service list | grep compute-new
   ```
   **Attendu:** State = up, Status = enabled

9. **Vérifier les ressources**
   ```bash
   openstack hypervisor show compute-new
   ```

10. **Test de création VM**
    ```bash
    openstack server create --flavor m1.tiny --image cirros \
        --availability-zone nova:compute-new \
        test-compute-new --wait
    openstack server delete test-compute-new
    ```

## Validation finale
- [ ] Service nova-compute UP
- [ ] Agent neutron UP
- [ ] VM de test créée et supprimée
- [ ] Monitoring actif sur le nouveau node

## Rollback
Si problème lors du déploiement:
```bash
kolla-ansible -i /etc/kolla/inventory destroy --limit compute-new --yes-i-really-really-mean-it

Post-opération¶

• Mettre à jour la documentation du cluster
• Ajouter au monitoring
• Notifier l'équipe

  ### RB-002: Remplacement d'un disque OSD Ceph
  
  ```markdown
  # RB-002: Remplacement Disque OSD Ceph
  
  ## Métadonnées
  | Champ | Valeur |
  |-------|--------|
  | Version | 1.0 |
  | Temps estimé | 30-60 minutes |
  | Impact | Dégradation temporaire |
  | Maintenance | Non requise |
  
  ## Objectif
  Remplacer un disque OSD défaillant dans le cluster Ceph.
  
  ## Prérequis
  - [ ] Disque de remplacement disponible
  - [ ] Cluster Ceph HEALTH_WARN ou OK
  - [ ] Backup récent vérifié
  
  ## Procédure
  
  ### Phase 1: Identification (5 min)
  
  1. **Identifier l'OSD défaillant**
     ```bash
     ceph osd tree
     ceph health detail
     ```
     Note: OSD.XX = _______
  
  2. **Identifier le serveur et le disque**
     ```bash
     ceph osd find <OSD_ID>
     ```
     Serveur: _______ Disque: _______
  
  ### Phase 2: Préparation (5 min)
  
  3. **Marquer l'OSD out**
     ```bash
     ceph osd out <OSD_ID>
     ```
     **Validation:** `ceph -s` montre rebalancing
  
  4. **Attendre la migration (optionnel)**
     ```bash
     ceph -w
     # Attendre HEALTH_OK ou continuer si urgent
     ```
  
  ### Phase 3: Retrait (10 min)
  
  5. **Arrêter l'OSD**
     ```bash
     ssh <HOST> "systemctl stop ceph-osd@<OSD_ID>"
     ```
  
  6. **Supprimer l'OSD**
     ```bash
     ceph osd crush remove osd.<OSD_ID>
     ceph auth del osd.<OSD_ID>
     ceph osd rm <OSD_ID>
     ```
  
  7. **Nettoyer le disque (si réutilisation)**
     ```bash
     ssh <HOST> "ceph-volume lvm zap /dev/<DISK> --destroy"
     ```
  
  ### Phase 4: Remplacement physique (variable)
  
  8. **Remplacer le disque physiquement**
     - Suivre la procédure du datacenter
     - Attendre que le nouveau disque soit détecté
  
  9. **Vérifier le nouveau disque**
     ```bash
     ssh <HOST> "lsblk"
     ```
     Nouveau disque: _______
  
  ### Phase 5: Création nouvel OSD (10 min)
  
  10. **Créer le nouvel OSD**
      ```bash
      ceph orch daemon add osd <HOST>:/dev/<NEW_DISK>
      ```
      ou avec cephadm:
      ```bash
      cephadm shell -- ceph orch daemon add osd <HOST>:/dev/<NEW_DISK>
      ```
  
  11. **Vérifier le nouvel OSD**
      ```bash
      ceph osd tree
      ceph -s
      ```
  
  ### Phase 6: Validation (5 min)
  
  12. **Attendre recovery**
      ```bash
      ceph -w
      # Attendre HEALTH_OK
      ```
  
  ## Validation finale
  - [ ] Nouvel OSD UP et IN
  - [ ] Cluster HEALTH_OK
  - [ ] Pas de PGs unclean
  
  ## Rollback
  Pas de rollback possible une fois l'ancien disque retiré.
  En cas de problème avec le nouveau disque, répéter la procédure.
  
  ## Post-opération
  - [ ] Documenter le changement (S/N ancien et nouveau)
  - [ ] Vérifier les alertes
  - [ ] Ticket maintenance datacenter fermé
  

RB-003: Rotation des certificats TLS¶

# RB-003: Rotation Certificats TLS

## Métadonnées
| Champ | Valeur |
|-------|--------|
| Version | 1.1 |
| Temps estimé | 30 minutes |
| Impact | Coupure brève par service |
| Maintenance | Fenêtre recommandée |

## Objectif
Renouveler les certificats TLS avant expiration.

## Prérequis
- [ ] Nouveaux certificats générés
- [ ] Certificats validés (dates, SAN)
- [ ] Backup des anciens certificats

## Procédure

### Phase 1: Préparation (10 min)

1. **Vérifier les certificats actuels**
   ```bash
   openssl x509 -in /etc/kolla/certificates/haproxy.pem -noout -dates
   ```
   Expiration actuelle: _______

2. **Valider les nouveaux certificats**
   ```bash
   openssl x509 -in /path/to/new/haproxy.pem -noout -text | grep -E "(Not|Subject|DNS)"
   ```

3. **Backup des anciens certificats**
   ```bash
   cp -r /etc/kolla/certificates /etc/kolla/certificates.bak.$(date +%Y%m%d)
   ```

### Phase 2: Déploiement (15 min)

4. **Copier les nouveaux certificats**
   ```bash
   cp /path/to/new/haproxy.pem /etc/kolla/certificates/haproxy.pem
   cp /path/to/new/haproxy-internal.pem /etc/kolla/certificates/haproxy-internal.pem
   ```

5. **Reconfigurer HAProxy**
   ```bash
   kolla-ansible -i /etc/kolla/inventory reconfigure --tags haproxy
   ```
   **Validation:** Pas d'erreur

6. **Vérifier HAProxy**
   ```bash
   docker exec haproxy haproxy -c -f /etc/haproxy/haproxy.cfg
   ```
   **Attendu:** Configuration valid

### Phase 3: Vérification (5 min)

7. **Tester les endpoints**
   ```bash
   curl -v https://cloud.example.com:5000/v3 2>&1 | grep -E "(SSL|expire)"
   ```

8. **Vérifier tous les services**
   ```bash
   openstack token issue
   openstack server list --limit 1
   ```

## Validation finale
- [ ] Certificats renouvelés (vérifier date expiration)
- [ ] Tous les endpoints accessibles
- [ ] Pas d'erreur TLS dans les logs

## Rollback
```bash
cp /etc/kolla/certificates.bak.*/haproxy*.pem /etc/kolla/certificates/
kolla-ansible -i /etc/kolla/inventory reconfigure --tags haproxy

Post-opération¶

• Supprimer le backup après 7 jours
• Mettre à jour le calendrier de rotation
• Documenter la nouvelle date d'expiration

  ### RB-004: Évacuation d'un hyperviseur
  
  ```markdown
  # RB-004: Évacuation Hyperviseur
  
  ## Métadonnées
  | Champ | Valeur |
  |-------|--------|
  | Version | 1.0 |
  | Temps estimé | Variable (dépend du nombre de VMs) |
  | Impact | Migration des VMs (transparent si live) |
  | Maintenance | Non requise |
  
  ## Objectif
  Évacuer toutes les VMs d'un hyperviseur pour maintenance.
  
  ## Prérequis
  - [ ] Capacité suffisante sur les autres hyperviseurs
  - [ ] Shared storage (Ceph) fonctionnel
  - [ ] VMs supportent live migration
  
  ## Procédure
  
  ### Phase 1: Préparation (5 min)
  
  1. **Identifier les VMs**
     ```bash
     openstack server list --host <COMPUTE_HOST> --all-projects
     ```
     Nombre de VMs: _______
  
  2. **Vérifier la capacité disponible**
     ```bash
     openstack hypervisor stats show
     ```
     VCPUs libres: _______ RAM libre: _______
  
  3. **Désactiver le scheduling**
     ```bash
     openstack compute service set --disable --disable-reason "Maintenance" <COMPUTE_HOST> nova-compute
     ```
  
  ### Phase 2: Migration (variable)
  
  4. **Live migrate toutes les VMs**
     ```bash
     # Une par une (contrôlé)
     for vm in $(openstack server list --host <COMPUTE_HOST> --all-projects -f value -c ID); do
         echo "Migrating: $vm"
         openstack server migrate --live-migration $vm --wait
         openstack server show $vm -f value -c OS-EXT-SRV-ATTR:host
     done
     ```
  
     **Ou en bloc (plus rapide):**
     ```bash
     nova host-evacuate-live <COMPUTE_HOST>
     ```
  
  5. **Suivre la progression**
     ```bash
     watch "openstack server list --host <COMPUTE_HOST> --all-projects"
     ```
  
  ### Phase 3: Vérification (5 min)
  
  6. **Confirmer évacuation complète**
     ```bash
     openstack server list --host <COMPUTE_HOST> --all-projects
     ```
     **Attendu:** Aucune VM
  
  7. **Vérifier les VMs migrées**
     ```bash
     openstack server list --all-projects --status ACTIVE
     ```
  
  ### Phase 4: Maintenance
  
  8. **Effectuer la maintenance**
     (Reboot, upgrade, remplacement hardware...)
  
  ### Phase 5: Remise en service (5 min)
  
  9. **Réactiver le scheduling**
     ```bash
     openstack compute service set --enable <COMPUTE_HOST> nova-compute
     ```
  
  10. **Vérifier le service**
      ```bash
      openstack compute service list | grep <COMPUTE_HOST>
      ```
  
  ## Validation finale
  - [ ] Toutes les VMs migrées et ACTIVE
  - [ ] Compute service enabled et up
  - [ ] Pas d'erreur dans les logs
  
  ## Rollback
  Si migration échoue:
  ```bash
  openstack server migrate --live-migration <VM_ID> --host <COMPUTE_HOST>
  

Post-opération¶

• Documenter la maintenance effectuée
• Vérifier les métriques post-maintenance

  ### Diagramme processus runbook
  
  ```mermaid
  flowchart TD
      Start([Start]) --> Identify[Opérateur:<br/>Identifier le besoin]
      Identify --> Select[Sélectionner le runbook]
  
      Select --> Verify[Validation:<br/>Vérifier prérequis]
      Verify --> PrereqOK{Prérequis<br/>OK?}
      PrereqOK -->|Non| Resolve[Résoudre les prérequis<br/>Escalader si nécessaire]
      Resolve --> Verify
      PrereqOK -->|Oui| Begin[Exécution:<br/>Début d'exécution]
  
      Begin --> CreateTicket[Créer ticket de suivi]
      CreateTicket --> Execute[Exécuter étape N]
      Execute --> Check[Vérifier résultat]
  
      Check --> ResultOK{Résultat<br/>OK?}
      ResultOK -->|Oui| CheckStep[Cocher étape]
      ResultOK -->|Non| RollbackPossible{Rollback<br/>possible?}
  
      RollbackPossible -->|Oui| DoRollback[Exécuter rollback<br/>Escalader]
      DoRollback --> End1([Stop])
      RollbackPossible -->|Non| EscalateNow[Escalader immédiatement]
      EscalateNow --> End2([Stop])
  
      CheckStep --> StepsRemaining{Étapes<br/>restantes?}
      StepsRemaining -->|Oui| Execute
      StepsRemaining -->|Non| FinalValidation[Clôture:<br/>Validation finale]
  
      FinalValidation --> Document[Documentation]
      Document --> Communicate[Communication]
      Communicate --> CloseTicket[Fermer ticket]
      CloseTicket --> End3([Stop])
  

Index des Runbooks¶

# runbooks-index.yml

categories:
  compute:
    - id: RB-001
      title: Ajout compute node
      frequency: Occasionnel
    - id: RB-004
      title: Évacuation hyperviseur
      frequency: Mensuel (maintenance)
    - id: RB-005
      title: Resize flavor
      frequency: Rare

  storage:
    - id: RB-002
      title: Remplacement disque OSD
      frequency: Sur incident
    - id: RB-006
      title: Extension pool Ceph
      frequency: Occasionnel
    - id: RB-007
      title: Création nouveau pool
      frequency: Rare

  network:
    - id: RB-008
      title: Ajout réseau provider
      frequency: Occasionnel
    - id: RB-009
      title: Debug connectivité VM
      frequency: Sur incident

  security:
    - id: RB-003
      title: Rotation certificats TLS
      frequency: Annuel
    - id: RB-010
      title: Rotation credentials
      frequency: Trimestriel
    - id: RB-011
      title: Audit accès
      frequency: Mensuel

  maintenance:
    - id: RB-012
      title: Upgrade OpenStack
      frequency: Semestriel
    - id: RB-013
      title: Backup manuel
      frequency: Sur demande
    - id: RB-014
      title: Restore base de données
      frequency: Sur incident

Exemples pratiques¶

Template de runbook¶

# RB-XXX: [Titre]

## Métadonnées
| Champ | Valeur |
|-------|--------|
| Version | 1.0 |
| Date | YYYY-MM-DD |
| Auteur | |
| Temps estimé | |
| Impact | |
| Maintenance requise | Oui/Non |

## Objectif
[Description claire de l'objectif]

## Prérequis
- [ ] Prérequis 1
- [ ] Prérequis 2

## Procédure

### Phase 1: [Nom] (X min)

1. **[Action]**
   ```bash
   [commande]
   ```
   **Validation:** [Résultat attendu]

### Phase N: [Nom] (X min)

N. **[Action]**
   ```bash
   [commande]
   ```

## Validation finale
- [ ] Check 1
- [ ] Check 2

## Rollback
[Procédure de retour arrière]

## Post-opération
- [ ] Action 1
- [ ] Action 2

Ressources¶

• OpenStack Operations Guide
• SRE Book - Runbooks
• Runbook Template

Checkpoint¶

• Runbooks créés pour opérations courantes
• Template standardisé adopté
• Index des runbooks maintenu
• Équipe formée sur les runbooks
• Runbooks testés et validés
• Processus de mise à jour défini
• Intégration avec ticketing
• Revue périodique planifiée