À propos des connexions d'appairage

Cette page présente l'administration des connexions d'appairage de réseaux VPC.

Connexion d'appairage

Une connexion d'appairage connecte deux réseaux de cloud privé virtuel (VPC). Pour établir une connexion d'appairage, chaque côté crée séparément une configuration d'appairage qui fait référence à l'autre réseau.

Pour demander à vous connecter à un autre réseau VPC, vous devez créer une configuration d'appairage. Une fois que l'autre réseau possède une configuration d'appairage avec votre réseau, la connexion d'appairage est établie et l'état de l'appairage passe à ACTIVE dans les deux réseaux. L'état d'appairage reste INACTIVE si l'autre réseau ne dispose pas d'une configuration d'appairage correspondante, ce qui indique que votre réseau n'est pas connecté à l'autre.

La création d'une connexion d'appairage ne vous attribue aucun rôle Identity and Access Management sur l'autre réseau VPC. Par exemple, si vous disposez du rôle Administrateur de réseaux Compute (roles/compute.networkAdmin) ou Administrateur de sécurité Compute (roles/compute.securityAdmin) pour un réseau, vous ne devenez pas administrateur réseau ni administrateur de sécurité pour l'autre réseau.

Une fois la connexion d'appairage établie, les deux réseaux VPC échangent toujours des routes de sous-réseau IPv4 qui utilisent des plages d'adresses IPv4 privées. Pour en savoir plus sur les options d'échange de routes, consultez les pages suivantes :

Mode de connexion

Le mode de connexion détermine la façon dont une connexion d'appairage est administrée. L'appairage de réseaux VPC est compatible avec deux modes de connexion :

Pour les déploiements standards, le mode indépendant est généralement préférable. Toutefois, pour les déploiements qui prennent en charge un service critique et où la suppression accidentelle de la connexion d'appairage entraînerait une interruption de service, nous vous recommandons d'utiliser le mode Consensus. Ce mode nécessite l'accord des deux réseaux et empêche toute modification unilatérale de l'état effectif de la connexion d'appairage.

Lorsque vous créez une connexion d'appairage, les deux configurations d'appairage doivent spécifier le même mode de connexion : indépendant ou consensus.

Pour modifier le mode d'appairage d'une connexion existante et passer du mode indépendant au mode consensus, les deux configurations d'appairage doivent être mises à jour. Il n'est pas possible de passer du mode de connexion "consensus" au mode "indépendant".

Mode indépendant

Lorsqu'une connexion d'appairage est en mode indépendant (par défaut), l'un ou l'autre des réseaux peut mettre à jour ou supprimer la connexion à tout moment. Vous pouvez éventuellement limiter ce comportement en définissant le mode de connexion sur "consensus".

Mode Consensus

Le mode Consensus empêche les modifications accidentelles et unilatérales du comportement du réseau. Lorsqu'une connexion d'appairage est en mode consensus, chaque demande de mise à jour ou de suppression de la connexion d'appairage nécessite l'accord des deux réseaux.

Configurer le mode Consensus pour une connexion

Vous pouvez configurer une connexion d'appairage nouvelle ou existante pour utiliser le mode Consensus en définissant le paramètre update_strategy :

  • Nouvelle connexion. Les deux réseaux doivent définir la stratégie de mise à jour sur CONSENSUS. Si la stratégie de mise à jour n'est pas spécifiée, la connexion est créée en mode indépendant.

  • Connexion existante : Les deux réseaux doivent modifier la stratégie de mise à jour en CONSENSUS. Tant que les deux valeurs ne correspondent pas, la stratégie de mise à jour effective reste INDEPENDENT et les demandes unilatérales de mise à jour et de suppression sont autorisées.

    Les demandes en attente de modification du mode de connexion n'entraînent pas de temps d'arrêt. La connexion reste active pendant le traitement de la demande.

De plus, pour configurer le mode consensus pour une connexion, chaque option d'échange de route de votre configuration doit avoir la même valeur que l'indicateur complémentaire dans la configuration du pair. Si les valeurs des indicateurs suivants ne correspondent pas, la demande de création ou de mise à jour de la connexion est refusée.

Drapeau local Signalement complémentaire par un pair
import_custom_route export_custom_route
export_custom_route import_custom_route
import_subnet_routes_with_public_ip export_subnet_routes_with_public_ip
export_subnet_routes_with_public_ip import_subnet_routes_with_public_ip
stack_type stack_type

Par exemple, si votre réseau importe des routes personnalisées, le réseau appairé doit exporter des routes personnalisées. Si l'une de ces valeurs ne correspond pas à une connexion existante, l'un ou l'autre réseau peut les mettre à jour avant ou lors du changement de mode de connexion.

Pour annuler une demande en attente de configuration du mode Consensus pour une connexion existante, le réseau demandeur doit réinitialiser la stratégie de mise à jour sur INDEPENDENT.

Pour en savoir plus, consultez Créer une connexion d'appairage en mode Consensus et Mettre à jour une connexion vers le mode Consensus
.

Mettre à jour une connexion en mode consensus

Chacune des parties d'une connexion d'appairage peut envoyer une demande de modification. Une demande de mise à jour en attente n'entraîne pas de temps d'arrêt et la connexion reste active. Si une demande de suppression est en cours, toutes les demandes de mise à jour (y compris l'acceptation ou l'annulation d'une demande de mise à jour en attente) sont refusées.

Pour mettre à jour une connexion d'appairage configurée en mode consensus, l'administrateur réseau local met d'abord à jour la configuration locale. Ensuite, l'administrateur du réseau pair doit effectuer une mise à jour complémentaire de la configuration de l'homologue. Par exemple, si vous définissez l'indicateur --export-custom-routes sur true, le réseau pair doit définir l'indicateur --import-custom-routes sur true. L'état effectif de la connexion d'appairage ne change pas tant que le réseau homologue n'a pas mis à jour la configuration correspondante.

Une fois la configuration de l'appairage local mise à jour, aucune des deux parties de la connexion ne peut envoyer d'autres demandes de mise à jour tant que la mise à jour initiale n'est pas acceptée ou annulée. Les mises à jour partielles ne sont pas acceptées. Si une demande met à jour plusieurs paramètres, ils doivent tous être acceptés ou annulés. Pour annuler une modification, le réseau demandeur rétablit la valeur précédente de chaque paramètre modifié.

Le schéma suivant montre comment l'état d'une connexion d'appairage change lorsqu'une demande de mise à jour est envoyée.

Mettre à jour une connexion d'appairage en mode consensus
Mise à jour d'une connexion d'appairage en mode Consensus (cliquez pour agrandir).

Dans le diagramme précédent, une fois que le réseau A a envoyé la demande de mise à jour, l'état de mise à jour de la connexion passe de IN_SYNC à PENDING_PEER_ACKNOWLEDGMENT dans la configuration locale et à PENDING_LOCAL_ACKNOWLEDGMENT dans la configuration du pair.

Pour revenir à l'état IN_SYNC, le réseau B doit effectuer le changement complémentaire ou le réseau A doit annuler sa demande. Pour en savoir plus sur ces états de connexion, consultez État de la connexion.

Pour mettre à jour une connexion d'appairage, consultez Mettre à jour une connexion (mode Consensus).

Supprimer une connexion en mode consensus

Pour supprimer une connexion d'appairage en mode consensus, les deux parties de la connexion doivent envoyer une demande de suppression. Vous pouvez annuler une demande de suppression avant ou après qu'elle a été acceptée par le réseau pair.

Les conditions suivantes s'appliquent aux demandes de suppression :

  • Si une demande de mise à jour est en attente, vous pouvez toujours supprimer la connexion d'appairage.
  • Si une demande de suppression est en attente, toutes les demandes de mise à jour, y compris l'acceptation ou l'annulation d'une mise à jour en attente, sont refusées. Pour finaliser une mise à jour en attente, vous devez d'abord annuler la demande de suppression.

Pour en savoir plus, consultez Supprimer une connexion (mode Consensus).

État de la connexion

La commande gcloud compute networks describe affiche à la fois l'état effectif d'une connexion de peering et votre configuration de peering locale.

Vous pouvez consulter l'état de la connexion effective en examinant le champ peerings.connectionStatus. Le tableau suivant décrit les états de configuration disponibles. La coche  indique que le champ est disponible.

Champ Mode indépendant Mode Consensus Description
trafficConfiguration Affiche les options d'échange de routes effectives de la connexion d'appairage.
updateStrategy Affiche le mode de connexion effectif : INDEPENDENT ou CONSENSUS.
consensusState.deleteStatus
  • UNSPECIFIED : aucune demande requestRemovePeering n'est en attente pour cette connexion d'appairage. Le champ deleteStatus ne s'affiche pas dans la sortie lorsque l'état est UNSPECIFIED.
  • LOCAL_DELETE_REQUESTED : le propriétaire de cet appairage a demandé la suppression de la connexion d'appairage.
  • PEER_DELETE_REQUESTED : le propriétaire de l'appairage correspondant a demandé la suppression de la connexion d'appairage.
  • DELETE_ACKNOWLEDGED : les deux propriétaires de l'appairage de cette connexion ont demandé la suppression de la connexion d'appairage. Les requêtes removePeering ultérieures aboutiront pour l'appairage.
  • LOCAL_CANCEL_REQUESTED : la connexion d'appairage était à l'état DELETE_ACKNOWLEDGED, mais le réseau local a annulé la suppression.
  • PEER_CANCEL_REQUESTED : la connexion d'appairage était à l'état DELETE_ACKNOWLEDGED, mais le réseau pair a annulé la suppression.
consensusState.updateStatus
  • IN_SYNC : aucun des propriétaires du peering n'a de mises à jour en attente.
  • PENDING_PEER_ACKNOWLEDGMENT : le propriétaire du peering local a apporté une modification, mais le propriétaire du peering correspondant n'a pas appliqué les modifications correspondantes à son peering.
  • PENDING_LOCAL_ACKNOWLEDGMENT : le propriétaire du peering correspondant a apporté une modification, mais le propriétaire du peering local n'a pas appliqué les modifications correspondantes à ce peering.

Pour répertorier toutes les configurations d'appairage dans un projet Google Cloud , consultez Lister les connexions d'appairage.

Étapes suivantes