À propos de la migration à chaud
La migration à chaud vous permet de contrôler l'annonce BGP des préfixes délégués publics régionaux v1. La migration à chaud n'est pas disponible par défaut. Pour demander l'accès, contactez votre ingénieur client Google Cloud.
Pour les nouvelles configurations, nous vous recommandons de créer un préfixe public annoncé v2, qui vous permet de créer des préfixes délégués publics régionaux qui provisionnent plus rapidement et vous offrent un meilleur contrôle sur l'annonce BGP.
Pour en savoir plus sur la différence entre les préfixes délégués publics v1 et v2, consultez la page Configurer l'utilisation de vos propres configurations d'adresse IP.
Migration à chaud
La migration à chaud est une fonctionnalité puissante qui nécessite une planification et une exécution minutieuses.
La migration à chaud permet d'importer un préfixe BYOIP lorsqu'une partie du préfixe est déjà annoncée publiquement. L'importation d'un préfixe annoncé sans migration à chaud peut entraîner une perte de paquets et un routage inattendu.
La migration à chaud a une disponibilité limitée. Contactez votre ingénieur client Google Cloud pour obtenir l'accès avant de créer un préfixe délégué public avec la migration à chaud activée.
Vous activez la migration à chaud lorsque vous créez un préfixe délégué public. Pour empêcher Google d'annoncer le préfixe public annoncé aux pairs, vous devez vous assurer que :
Tous les préfixes délégués publics au sein du préfixe annoncé public sont configurés avec un champ d'application régional, et non un champ d'application global. Pour en savoir plus, consultez la section Recommandations de migration à chaud.
Aucune adresse IP comprise dans la plage du préfixe public annoncé n'est attribuée aux ressources.
La figure 2 affiche le même projet avec des configurations différentes, l'une empêche l'annonce du préfixe et l'autre déclenchant l'annonce du préfixe public.
La figure 2 illustre les scénarios suivants :
Dans le premier exemple de projet, tous les préfixes publics délégués du préfixe public annoncé sont configurés avec la migration à chaud activée. Aucune VM n'est configurée avec les adresses IP de ce préfixe.
Résultat : le préfixe public annoncé n'est pas annoncé.
Dans le deuxième exemple de projet, tous les préfixes publics délégués du préfixe public annoncé sont configurés avec la migration à chaud activée. Une VM est configurée avec une adresse IP de ce préfixe.
Résultat : le préfixe public annoncé est annoncé.
Dans le troisième exemple de projet, un préfixe public délégué du préfixe public annoncé n'est pas configuré avec la migration à chaud activée. Aucune VM n'est configurée avec les adresses IP de ce préfixe.
Résultat : le préfixe public annoncé est annoncé.
Vous contrôlez le moment où l'annonce commence en attribuant des adresses IP de votre préfixe délégué public aux ressources Google Cloud. Pour en savoir plus, consultez la section Utiliser la migration à chaud.
Une fois la migration à chaud terminée, contactez votre ingénieur client Google Cloud pour qu'il puisse désactiver la migration à chaud pour votre préfixe. Par défaut, la migration à chaud est désactivée 30 jours après le lancement de l'annonce du préfixe public annoncé. Si vous avez besoin de l'option de migration à chaud pendant plus de 30 jours, contactez votre ingénieur client.
Limites de la migration à chaud
Lors de la planification d'une migration à chaud, il est important de connaître les exigences et limitations suivantes :
La création d'un préfixe délégué public avec la migration à chaud activée n'est pas disponible si le champ d'application est défini sur "global". Consultez la section Recommandations de migration à chaud pour en savoir plus sur la gestion de la migration à chaud des ressources globales.
Le préfixe le plus long pouvant être migré est
/24, car/24est la longueur maximale de préfixe pouvant être routée sur Internet.Ne partez pas du principe que tous les pairs de Google respectent le préfixe le plus long entre deux sites. Il est possible que certains pairs ne disposent pas de tables de routage complètes. Par conséquent, un préfixe plus court annoncé par Google à ces pairs est le seul préfixe (et donc le plus long) visible par le pair. Par conséquent, l'existence de tout préfixe de Google est prioritaire, même si vous annoncez d'une route plus spécifique depuis votre emplacement sur site.
Exemple :
Un client dispose d'un
/23qui est acheminé activement à partir de son emplacement sur site. Le client prévoit de dissocier/23en deux préfixes/24et annonce les routes plus spécifiques à partir de son emplacement sur site. À la suite de la désagrégation, ils prévoient de configurer un préfixe public annoncé/23pour la BYOIP. Ils partent du principe que les routes plus spécifiques de leur emplacement sur site sont prioritaires sur le préfixe BYOIP le plus court et que le trafic continue à acheminer vers les préfixes sur site plus spécifiques.Malheureusement, ce cas de figure ne fonctionne que partiellement :
Les pairs Google disposant de tables de routage complètes préfèrent les préfixes
/24sur site plus spécifiques.Les pairs Google qui ne possèdent pas de table de routage complètes préfèrent le préfixe public annoncé par Google, car leurs tables de routage n'incluent pas les préfixes plus spécifiques.
Votre trafic n'est pas distribué si Google reçoit du trafic pour un préfixe public annoncé pour lequel vous n'avez pas provisionné de services, même s'il existe une annonce sur site active pour ce préfixe.
Exemple :
Un client dispose d'un réseau sur site composé de deux préfixes
/24. Le préfixe annoncé public qui lui est associé est l'agrégation/23.Le client migre un seul
/24vers Google et supprime le préfixe sur site, mais conserve l'autre/24actif dans l'emplacement sur site.Cette configuration entraîne une partie du routage du trafic vers Google pour l'intégralité du préfixe
/23, même s'il existe toujours un préfixe/24plus spécifique annoncé depuis l'emplacement sur site. Ce scénario est difficile à analyser, car différents systèmes autonomes acheminent du trafic vers votre emplacement sur site, tandis que d'autres le transmettent à Google, auquel cas le trafic est interrompu.
Recommandations pour la migration à chaud
Nous vous recommandons de suivre ces recommandations lorsque vous utilisez la migration à chaud.
Dissociez tous les préfixes de migration à chaud par les préfixes les plus longs correspondant à la manière dont vous souhaitez annoncer ces préfixes lors de la migration. Dans les exemples précédents,
/23doit être dissocié en deux préfixes/24et annoncés comme tel à partir de leur emplacement sur site avant de créer le préfixe annoncé public.Créez des requêtes ROA exactes de longueur de préfixe et ne comptez pas sur le paramètre de longueur maximale à respecter.
Assurez-vous que les requêtes RPKI ROA existent pour le numéro ASN d'origine sur site et pour le numéro ASN d'origine de Google. En l'absence de ROA pour le préfixe sur site, la création d'une ROA d'origine Google peut entraîner l'exclusion par des FAI tiers ces préfixes sur site s'ils utilisent le filtre automatique RPKI.
Créez des préfixes annoncés publics séparés pour les ressources globales et les ressources régionales si vous devez utiliser la migration à chaud. Lorsque vous activez la migration à chaud sur un préfixe délégué public, vous devez spécifier une région pour le champ d'application. La spécification du champ d'application global d'un préfixe délégué public pour lequel la migration à chaud est activée n'est pas disponible. Si vous créez un préfixe délégué public avec le champ d'application global et la migration à chaud activées, le préfixe est immédiatement annoncé.
Le fait d'avoir des préfixes régionaux dans un préfixe public annoncé et des préfixes globaux dans un autre préfixe annoncé public vous permet de les gérer séparément. Vous pouvez gérer la migration à chaud des ressources régionales et contacter votre ingénieur client Google Cloud pour gérer la migration à chaud des ressources globales.