Mettre en place une architecture OVHcloud Connect résiliente

Voir en Markdown

Connectez votre infrastructure à OVHcloud via deux liens OVHcloud Connect redondants pour assurer la haute disponibilité et la bascule automatique.

Objectif

Ce tutoriel vous guide pour connecter votre infrastructure à OVHcloud à l’aide de deux liens OVHcloud Connect indépendants afin d’obtenir la haute disponibilité. Si un lien tombe en panne, le trafic bascule automatiquement vers l’autre.

En pratique

Vous trouverez ci-dessous les prérequis et les instructions pour cinq cas d’usage distincts, que vous pouvez choisir selon l’architecture souhaitée.

On-Premises
WAN
AWS
Azure
GCP

Prérequis

  • Deux services OVHcloud Connect (Direct, Provider ou un mix) se terminant sur des PoPs différents
  • Un routeur (ou deux routeurs) capable de gérer plusieurs sessions BGP avec bascule
  • Un plan d’adressage IP couvrant deux AZ chez OVHcloud
  • Un vRack avec des ressources dans les deux AZ

Architecture

Schéma d’architecture résiliente On-Premises

Quand utiliser cette architecture

✅ Recommandée pourDétails
Production critique pour l’activitéWorkloads ne tolérant aucune indisponibilité
Environnements réglementésCadres de conformité exigeant la haute disponibilité
Exigences de SLA ≥ 99,99 %Architecture multi-chemins nécessaire pour un SLA premium
Reprise après sinistreBascule automatique sans intervention manuelle

1. Commander deux liens OVHcloud Connect

Commandez deux services OVHcloud Connect distincts sur des PoPs différents pour assurer la diversité physique :

  • Lien 1 (principal) : commandez sur le PoP A — voir Commander Direct ou Commander Provider.
  • Lien 2 (secours) : commandez sur le PoP B — même processus, PoP différent.

Conseil de diversité : utilisez des datacenters différents ou, à défaut, des chemins physiques distincts pour éviter un point de défaillance partagé.

2. Installer les deux connexions physiques

Pour chaque lien :

  • Direct : installez les cross-connects sur chaque PoP. Voir LOA Cross Connect.
  • Provider : partagez les clés d’appairage respectives avec votre ou vos opérateurs.

3. Configurer BGP avec bascule

Mettez en place deux sessions BGP — une par lien — avec des politiques de routage qui définissent le chemin préféré.

Exemple actif/passif (Cisco IOS)
router bgp 65001
 ! Primary link via PoP A
 neighbor 192.0.2.1 remote-as 35540
 neighbor 192.0.2.1 description OVHcloud-Primary
 neighbor 192.0.2.1 route-map PRIMARY-IN in
 neighbor 192.0.2.1 route-map PRIMARY-OUT out

 ! Backup link via PoP B
 neighbor 198.51.100.1 remote-as 35540
 neighbor 198.51.100.1 description OVHcloud-Backup
 neighbor 198.51.100.1 route-map BACKUP-IN in
 neighbor 198.51.100.1 route-map BACKUP-OUT out

! Prefer primary path using Local Preference
route-map PRIMARY-IN permit 10
 set local-preference 200

route-map BACKUP-IN permit 10
 set local-preference 100

! Influence OVHcloud's return traffic using AS-path prepending on backup
route-map PRIMARY-OUT permit 10

route-map BACKUP-OUT permit 10
 set as-path prepend 65001 65001
Attributs BGP clés pour la bascule
AttributEffetCas d’usage
Local PreferenceContrôle la préférence du chemin sortant (plus élevé = préféré)Rendre le chemin principal préféré pour le trafic sortant de votre réseau
AS-path prependingFait paraître un chemin plus long (moins préféré)Influencer le choix du chemin de retour par OVHcloud
MEDSuggère une préférence au côté distantPeut ne pas être pris en compte dans toutes les configurations OVHcloud

4. Associer les deux liens à votre vRack

Associez les deux services OVHcloud Connect au même vRack. Voir Associer à un vRack.

5. Configurer les sous-réseaux dans les deux AZ

Configurez des sous-réseaux privés dans les deux Availability Zones. Voir Configurer votre réseau vRack.

6. Tester la bascule

Cette étape est critique. Ne sautez pas les tests de bascule.

  1. Vérifiez le fonctionnement normal :

    • Les deux sessions BGP sont à l’état Established.
    • Le trafic transite par le lien principal.

  2. Simulez la défaillance du lien principal :

    • Arrêtez la session BGP principale ou déconnectez physiquement le lien principal.
    • Vérifiez que le trafic bascule vers le lien de secours dans le délai de convergence BGP (généralement 30 à 90 secondes ; cela peut être plus rapide avec BFD).
    • Confirmez l’absence de perte de paquets au-delà de la fenêtre de convergence.

  3. Restaurez le lien principal :

    • Remettez le lien principal en service.
    • Vérifiez que le trafic revient sur le chemin principal.

  4. Testez l’inverse :

    • Simulez une défaillance du lien de secours pendant que le principal est actif. Cela confirme que les deux liens fonctionnent indépendamment.

7. Mettre en place la supervision

Supervisez les deux liens indépendamment. Configurez des alertes pour :

  • Les chutes de session BGP sur l’un ou l’autre lien
  • Le déséquilibre de trafic (tout le trafic sur un seul lien peut indiquer une défaillance de l’autre)
  • La bande passante approchant la capacité maximale sur l’un ou l’autre lien

Voir Superviser.

Avancé : configuration actif/actif

Pour un débit maximal et une bascule plus rapide, vous pouvez exploiter les deux liens en mode actif/actif :

  • Définissez une Local Preference égale sur les deux chemins.
  • Utilisez ECMP (Equal-Cost Multi-Path) s’il est pris en charge.
  • Le trafic est réparti sur les deux liens.
  • Si un lien tombe en panne, l’intégralité du trafic transite immédiatement par le lien restant.

Le mode actif/actif offre une bande passante agrégée plus élevée mais nécessite une planification de capacité rigoureuse — chaque lien doit être en mesure d’absorber seul la totalité de la charge en cas de défaillance.

Et ensuite ?

Aller plus loin

Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

Échangez avec notre communauté d’utilisateurs.

Cette page vous a-t-elle aidé ?