Cette page a été traduite par l'API Cloud Translation.

Configurer une interconnexion multizone

Cette page décrit la configuration nécessaire à effectuer sur les zones existantes d'un déploiement multizone lorsqu'une nouvelle zone rejoint le déploiement. Cette configuration vous permet d'établir des connexions à la nouvelle zone.

1. Avant de commencer

Pour configurer l'interconnexion multizone sur Google Distributed Cloud (GDC) sous air gap, vous devez disposer des éléments suivants :

Un fichier kubeconfig généré et une variable d'environnement. Pour en savoir plus, consultez le runbook IAM-R0004.
Un opérateur d'infrastructure (OI) disposant d'un accès temporaire au cluster d'administrateur racine. Pour en savoir plus, consultez le runbook IAM-R0005.

2. Configurer une interconnexion multizone

Configurez une ressource MultiZoneNetworkConfig dans chaque zone du déploiement multizone :
1. Trouvez le bon cluster avec lequel interagir. Si le cluster d'administrateur racine est en cours d'exécution, utilisez kubeconfig pour le cluster d'administrateur racine. Sinon, utilisez kubeconfig pour le cluster kind d'amorçage. Pour en savoir plus, consultez le runbook IAM-R0004. Renseignez le chemin d'accès kubeconfig :
```
KUBECONFIG=KUBECONFIG_PATH
```
2. Créez un fichier YAML nommé multizone_network_config.yaml.
3. Ajoutez le contenu suivant au fichier :
```
apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkConfig
metadata:
  name: multizone-network-config
  namespace: gpc-system
spec:
  carrierType: CARRIER_TYPE
  zones:
    - zoneID: ZONE_1_ID
      asn: ZONE_1_ASN
      externalSubnets:
        - METERING_SUBNET_1
    - zoneID: ZONE_2_ID
      asn: ZONE_2_ASN
      externalSubnets:
        - METERING_SUBNET_2
  ports:
    - port: PORT_1
    - port: PORT_2
  portSetting:
    mtu: MTU
```
  Remplacez les éléments suivants :
  - CARRIER_TYPE : type de transporteur backbone multizone. La valeur doit être L2 ou L3.
    
    Important : Pour le type de transporteur L2, Google vous recommande vivement de ne pas dépasser trois zones.
  - ZONE_1_ID : ID de la première zone de la région GDC.
  - ZONE_1_ASN : numéro ASN (Autonomous System Number) BGP du réseau de données de la première zone de la région GDC.
  - METERING_SUBNET_1 : sous-réseau avec facturation à l'utilisation de cette zone. Ce champ doit être renseigné avec le sous-réseau de la ressource zone-infra-cidr CIDRClaim dans le cluster d'administrateur racine de la zone associée. Ce champ n'est utilisé qu'à des fins de mesure et n'a aucun effet sur le contrôle de la publicité du sous-réseau. Vous devez synchroniser ce champ avec les sous-réseaux réellement annoncés. Si ce champ n'est pas spécifié, aucun trafic n'est mesuré pour cette zone.
  - ZONE_2_ID : ID de la deuxième zone de la région GDC.
  - ZONE_2_ASN : numéro ASN BGP du réseau de données de la deuxième zone de la région GDC.
  - METERING_SUBNET_2 : sous-réseau avec facturation à l'utilisation de cette zone. Ce champ doit être renseigné avec le sous-réseau de la ressource zone-infra-cidr CIDRClaim dans le cluster d'administrateur racine de la zone associée. Ce champ n'est utilisé qu'à des fins de mesure et n'a aucun effet sur le contrôle de la publicité du sous-réseau. Vous devez synchroniser ce champ avec les sous-réseaux réellement annoncés. Si ce champ n'est pas spécifié, aucun trafic n'est mesuré pour cette zone.
  - PORT_1 : premier port participant à l'interconnexion multizone. Pour en savoir plus, consultez Configurer les ports.
  - PORT_2 : deuxième port participant à l'interconnexion multizone . Pour en savoir plus, consultez Configurer les ports.
  - MTU : valeur MTU appliquée à tous les ports. Si aucune valeur n'est spécifiée, la valeur par défaut est 9216.
  Attention : Toutes les zones, y compris la zone actuelle, doivent être incluses dans le champ zones.
  Remarque : Les ASN de zone doivent être identiques à dataASN des zones associées.
  
  Consultez Exemples de configuration multizone pour obtenir des exemples de déploiement courants.
4. Appliquez le fichier multizone_network_config.yaml au cluster :
```
kubectl apply -f multizone_network_config.yaml --kubeconfig=KUBECONFIG_PATH
```
5. Vérifiez que la création de la ressource MultiZonetNetworkConfig a réussi :
```
kubectl get multizonenetworkconfig -n gpc-system --kubeconfig=KUBECONFIG_PATH
```
  L'exemple suivant montre un résultat avec des liens d'interconnexion :
```
NAME                       AGE   READY
multizone-network-config   26h   True
```
6. Facultatif : Vérifiez la ressource MultiZoneNetworkPeeringConfig pour connaître la configuration et l'état BGP de l'interconnexion.
  
  La configuration BGP réelle est définie par le réconciliateur de réseau et stockée dans la ressource MultiZoneNetworkPeeringConfig. Chaque ressource MultiZoneNetworkPeeringConfig représente toutes les configurations BGP d'une zone à l'autre. Exemple :
  - Une ressource MultiZoneNetworkPeeringConfig nommée zone-1-zone-2-peering-config peut ressembler à ce qui suit :
```
apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkPeeringConfig
metadata:
  name: zone-1-zone-2-peering-config
  namespace: gpc-system
spec: ...
status:
  borderLeafSwitches:
  - blswID: 1
    blswName: aa-aa-blsw01
    evpnBGPSessions:
    - bgpSessionConfig:
        addressFamily: EVPN
        bfdConfig:
          bfdMode: MultiHopBFD
        localASN: 65501
        localIP: 192.168.201.65/32
        md5SecretRef:
          name: zone-1-blsw-1-zone-2-blsw-1-evpn-bgp-password
          namespace: gpc-system
        peerASN: 65502
        peerIP: 192.168.202.65
        sourceInterface: loopback2
      bgpSessionStatus:
        prefixCounters:
          received: 4
          sent: 23
        sessionStatus: Up
        uptime: P6DT20H26M59S
    ipv4BGPSessions:
    - bgpSessionConfig:
        addressFamily: IPv4
        bfdConfig:
          bfdMode: PlainBFD
        localASN: 65501
        localIP: 192.168.208.0/31
        md5SecretRef:
          name: zone-1-blsw-1-zone-2-blsw-1-ipv4-bgp-password
          namespace: gpc-system
        peerASN: 65502
        peerIP: 192.168.208.1
      bgpSessionStatus:
        prefixCounters:
          received: 11
          sent: 11
        sessionStatus: Up
        uptime: P6DT20H27M1S
      port:
        port: 6
```
  L'état de cet exemple contient toutes les configurations de session BGP et les états de session BGP de la zone 1 à la zone 2.
  - Pour le mode opérateur de niveau 3, une ressource MultiZoneNetworkPeeringConfig nommée zone-1-ipv4-peering-config représentant toutes les sessions BGP IPv4 d'une zone vers l'opérateur de niveau 3 peut se présenter comme suit :
```
apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkPeeringConfig
metadata:
  name: zone-1-ipv4-peering-config
  namespace: gpc-system
spec: ...
status:
  borderLeafSwitches:
  - blswID: 1
    blswName: aa-aa-blsw01
    ipv4BGPSessions:
    - bgpSessionConfig:
        addressFamily: IPv4
        bfdConfig:
          bfdMode: PlainBFD
        localASN: 65501
        localIP: 192.168.208.0/31
        md5SecretRef:
          name: zone-1-blsw-1-port-6-ipv4-bgp-password
          namespace: gpc-system
        peerASN: 65502
        peerIP: 192.168.208.1
      bgpSessionStatus:
        prefixCounters:
          received: 11
          sent: 11
        sessionStatus: Up
        uptime: P6DT20H27M1S
      port:
        port: 6
```

2.1. Configurer les ports

La configuration ports dépend du type d'opérateur. Suivez ces règles lorsque vous définissez votre ports :

Si le type de transporteur est L2, vous devez spécifier n ports dans Spec.Ports, où n est égal au nombre de zones multiplié par deux. Le premier port doit se connecter au premier commutateur leaf de bordure (trié par nom de commutateur) de la première zone voisine (triée par ID de zone). Le deuxième port doit se connecter au deuxième commutateur leaf de bordure de la première zone voisine. Le troisième port se connecte au premier commutateur leaf de bordure de la deuxième zone voisine. Les autres connexions suivent ce modèle. Pour en savoir plus, consultez Déploiement d'un opérateur L2.

Important : Pour le type de transporteur L2, Google vous recommande vivement de ne pas dépasser trois zones.
Si le type de transporteur est L3, vous devez spécifier deux ports dans Spec.Ports. Les deux commutateurs de bordure de la zone actuelle doivent utiliser le premier port pour se connecter individuellement au premier périphérique de bordure du fournisseur, et le deuxième port pour se connecter individuellement au deuxième périphérique de bordure du fournisseur. Pour en savoir plus, consultez la section Déploiement de l'opérateur L3.

2.2. Exemples de configuration multizone

Cette section contient des exemples de déploiement courants.

2.2.1. Déploiement d'un opérateur L2

Ce déploiement présente la configuration suivante :

Trois zones avec les numéros ASN 65501, 65502 et 65503
Un opérateur L2
Les connexions logiques pour ce déploiement sont illustrées dans le schéma suivant :

Important : Cet exemple illustre le déploiement d'un opérateur L2 à trois zones. Google vous recommande vivement de ne pas dépasser trois zones pour les types de transporteur de niveau 2.

Voici un exemple de fichier YAML MultiZoneNetworkConfig :

apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkConfig
metadata:
  name: multizone-network-config
  namespace: gpc-system
spec:
  carrierType: L2
  zones:
    - zoneID: 1
      asn: 65501
    - zoneID: 2
      asn: 65502
    - zoneID: 3
      asn: 65503
  ports:
    - port: 10
    - port: 11
    - port: 12
    - port: 13

2.2.2. Déploiement d'un opérateur L3

Ce déploiement présente la configuration suivante :

Trois zones avec les numéros ASN 65501, 65502 et 65503
Opérateur L3
Les connexions logiques pour ce déploiement sont illustrées dans le schéma suivant :

Voici un exemple de fichier YAML MultiZoneNetworkConfig :

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: MultiZoneNetworkConfig
  metadata:
    name: multizone-network-config
    namespace: gpc-system
  spec:
    carrierType: L3
    zones:
      - zoneID: 1
        asn: 65501
        carrierASN: 60010
      - zoneID: 2
        asn: 65502
        carrierASN: 60010
      - zoneID: 3
        asn: 65503
        carrierASN: 60010
    ports:
      - port: 10
      - port: 11

2.3. Facultatif : configurez l'authentification BFD multizone.

La détection de transfert bidirectionnel (BFD) est configurée sur toutes les sessions IPv4 et EVPN multizones. Par défaut, le mode BFD simple à saut unique est configuré. Suivez les instructions de cette section pour déployer le protocole BFD multisaut avec authentification :

Activez l'authentification BFD (Bidirectional Forwarding Detection) pour les sessions BGP EVPN multizones. Pour établir et activer des sessions BFD, assurez-vous que les sessions BGP appairées dans les deux zones sont configurées avec le même ID de clé d'authentification BFD et la même chaîne de clé :

Définissez le type de clé. Nous vous recommandons d'exécuter cette commande sur la machine du programme d'amorçage. Pour des raisons de sécurité, utilisez au moins SHA-1 pour la clé. Si nécessaire, utilisez une clé plus sécurisée pour votre configuration :
```
export KEY_TYPE=SHA1
```
Définissez l'ID et la chaîne de clé. L'ID de clé doit être unique parmi les sessions d'interconnexion associées dans les zones. Déterminez un ID de clé inutilisé et attribuez-le à la variable :
```
export KEY_ID=1
```

Générez une clé d'authentification SHA-1 à l'aide de chronyc keygen :

CHRONY_OUTPUT=$(chronyc keygen ${KEY_ID:?} ${KEY_TYPE:?})

Exemple de résultat :

echo $CHRONY_OUTPUT
1 SHA1 HEX:887F1B88085BD0BDE4458EA7C2C4393C50A498EF

Extrayez la clé d'authentification et vérifiez-la :

export KEY_STR=$(echo ${CHRONY_OUTPUT:?} | awk '{ split($3,key,":"); print key[2]}')

echo $KEY_STR
887F1B88085BD0BDE4458EA7C2C4393C50A498EF

Corrigez les informations d'authentification BFD pour les sessions d'interconnexion sélectionnées :

kubectl --kubeconfig=KUBECONFIG_PATH patch secret zone-LOCAL_ZONE_ID-blsw-LOCAL_BLSW_ID-zone-REMOTE_ZONE_ID-blsw-REMOTE_BLSWID-bfd-auth-key -n gpc-system -p='{
  "stringData": {
    "bfdKeyID": "'"${KEY_ID}"'",
    "bfdKeyValue": "'"${KEY_STR}"'"
  }
}'

Vérifiez que la session BFD est en cours d'exécution :
```
switch# show bfd neighbors vrf default
```

Vérifiez que le champ State affiche la valeur Up et que le champ Type est défini sur SH ou MH :

OurAddr         NeighAddr       LD/RD                 RH/RS           Holdown(mult)     State       Int                   Vrf                              Type     BSID
192.168.208.31  192.168.208.30  1090519041/1090519042 Up              5237(3)           Up          Eth1/11               default                          SH       N/A
192.168.208.91  192.168.208.90  1090519042/1090519042 Up              5624(3)           Up          Eth1/12               default                          SH       N/A
192.168.202.66  192.168.201.65  1090519071/1090519060 Up              629(3)            Up          Lo2                   default                          MH       N/A
192.168.202.66  192.168.201.66  1090519072/1090519061 Up              545(3)            Up          Lo2                   default                          MH       N/A

2.4. Facultatif : Configurer le mot de passe BGP multizone

Il existe deux types de mots de passe BGP (Border Gateway Protocol) : le mot de passe de session BGP IPv4 et le mot de passe de session BGP EVPN.

Par défaut, tous les mots de passe BGP sont vides. Suivez les instructions de cette section pour modifier les mots de passe.

2.4.1. Modifier le mot de passe BGP IPv4

Si un opérateur L2 est utilisé, mettez à jour le mot de passe BGP IPv4 appliqué à la session BGP IPv4 entre un commutateur leaf de bordure dans la zone actuelle et un autre commutateur leaf de bordure dans une autre zone :

kubectl patch secret zone-LOCAL_ZONE_ID-blsw-LOCAL_BLSW_ID-zone-REMOTE_ZONE_ID-blsw-REMOTE_BLSWID-ipv4-bgp-password -p='{"stringData":{"password":"PASSWORD"}}'

Remplacez les éléments suivants :

LOCAL_ZONE_ID : ID numérique de la zone actuelle.
LOCAL_BLSW_ID : ID numérique du commutateur de feuille de bordure de la zone actuelle. Cette valeur doit être 1 ou 2.
REMOTE_ZONE_ID : ID numérique de la zone distante.
REMOTE_BLSW_ID : ID numérique du commutateur de feuille de bordure de la zone distante. Cette valeur doit être 1 ou 2.
PASSWORD : mot de passe BGP appliqué à la session BGP IPv4 entre le commutateur leaf de bordure local et le commutateur leaf de bordure distant.

Si un opérateur de couche 3 est utilisé, mettez à jour le mot de passe BGP IPv4 appliqué à la session BGP IPv4 entre un commutateur leaf de bordure dans la zone actuelle et un périphérique de bordure du fournisseur dans l'opérateur de couche 3 :

kubectl patch secret zone-LOCAL_ZONE_ID-blsw-LOCAL_BLSW_ID-port-PORT_ID-ipv4-bgp-password -p='{"stringData":{"password":"PASSWORD"}}' -n gpc-system --kubeconfig=KUBECONFIG_PATH

Remplacez les éléments suivants :

LOCAL_ZONE_ID : ID numérique de la zone actuelle.
LOCAL_BLSW_ID : ID numérique du commutateur de feuille de bordure de la zone actuelle. Cette valeur doit être 1 ou 2 :
PORT_ID : index du port Ethernet connecté à l'équipement de périphérie du fournisseur.
PASSWORD : mot de passe BGP appliqué à la session BGP IPv4 entre le commutateur leaf de bordure local et l'équipement de bordure du fournisseur.

2.4.2. Mettre à jour le mot de passe EVPN BGP

Pour mettre à jour le mot de passe EVPN BGP appliqué à la session EVPN BGP entre un commutateur leaf de bordure de la zone actuelle et un autre commutateur leaf de bordure d'une autre zone, exécutez la commande suivante :

kubectl patch secret zone-LOCAL_ZONE_ID-blsw-LOCAL_BLSW_ID-zone-REMOTE_ZONE_ID-blsw-REMOTE_BLSWID-evpn-bgp-password -p='{"stringData":{"password":"PASSWORD"}}' -n gpc-system --kubeconfig=KUBECONFIG_PATH

Remplacez les éléments suivants :

LOCAL_ZONE_ID : ID numérique de la zone actuelle.
LOCAL_BLSW_ID : ID numérique du commutateur de feuille de bordure de la zone actuelle. Cette valeur doit être 1 ou 2 :
REMOTE_ZONE_ID : ID numérique de la zone distante.
REMOTE_BLSW_ID : ID numérique du commutateur de feuille de bordure de la zone distante. Cette valeur doit être 1 ou 2 :
PASSWORD : mot de passe BGP appliqué à la session BGP EVPN entre le commutateur leaf de bordure local et le commutateur leaf de bordure distant.

3. Options de configuration avancées

Cette section présente les options de configuration avancées fournies par les API réseau multizones.

3.1. Configurer le remplacement de la configuration BGP de l'opérateur

Par défaut, les commutateurs de périphérie établissent des connexions d'appairage BGP avec les appareils PE du fournisseur à l'aide d'une allocation d'adresses IP par défaut. Pour trouver l'adresse IP d'appairage BGP spécifique utilisée, inspectez la ressource MultiZoneNetworkPeeringConfig zone-<ZONE_ID>-ipv4-peering-config. Exemple :

   apiVersion: system.private.gdc.goog/v1alpha1
   kind: MultiZoneNetworkPeeringConfig
   metadata:
     name: zone-1-ipv4-peering-config
     namespace: gpc-system
   spec: ...
   status:
     borderLeafSwitches:
     - blswID: 1
       blswName: aa-aa-blsw01
       ipv4BGPSessions:
       - bgpSessionConfig:
           addressFamily: IPv4
           bfdConfig:
             bfdMode: PlainBFD
           localASN: 65501
           localIP: 192.168.208.0/31
           md5SecretRef:
             name: zone-1-blsw-1-port-6-ipv4-bgp-password
             namespace: gpc-system
           peerASN: 65502
           peerIP: 192.168.208.1
   ...

Pour utiliser un plan d'adresses IP personnalisé, remplacez la configuration BGP de l'opérateur par défaut en suivant la procédure ci-dessous :

Exécutez kubectl edit MultiZoneNetworkPeeringConfig zone-<ZONE_ID>-ipv4-peering-config -n gpc-system en ajoutant la section carrierBGPConfigOverride sous spec.Peerings. Exemple :

apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkPeeringConfig
metadata:
  name: zone-1-ipv4-peering-config
  namespace: gpc-system
  ...
spec:
  peeringConfigType: L3-IPv4
  peerings:
  - carrierBGPConfigOverride:
      peeringIP:
        localIP: 192.168.78.5/31
        peerIP: 192.168.78.4
    peerA:
      blswID: 1
      port:
        port: 11
      zoneID: 1
    ...

Dans cet exemple, la spécification de carrierBGPConfigOverride.peeringIP remplace le sous-réseau d'appairage par 192.168.78.4/31.

3.2. Configurer le remplacement de port

Google recommande que tous les commutateurs leaf de bordure de toutes les zones utilisent le même ensemble de ports. Cette configuration de port est utile dans les scénarios où un contrôle précis des ports est requis.

La zone locale est celle dans laquelle vous effectuez le déploiement.

Les zones distantes sont d'autres zones du même univers multizone.

Par défaut, vous devez utiliser les mêmes ports pour les deux commutateurs leaf de bordure d'une zone afin de vous connecter à une autre zone ou au fournisseur. Toutefois, vous pouvez activer l'option de remplacement du port pour spécifier un autre port à utiliser pour cette connexion entre les zones.

Pour configurer la fonctionnalité de remplacement de port, procédez comme suit :

Activez la fonctionnalité portOverride :

kubectl patch MultiZoneNetworkConfig multizone-network-config -n gpc-system --type='merge' -p '{"spec":{"enablePortOverride":true}}' --kubeconfig=KUBECONFIG_PATH

Identifiez le commutateur feuille de bordure de zone locale et le commutateur feuille de bordure de zone distante, puis modifiez le port du commutateur feuille de bordure locale :

kubectl edit MultiZoneNetworkPeeringConfig zone-ZONE_1_ID-zone-ZONE_2_ID -n gpc-system --kubeconfig=KUBECONFIG_PATH

Remplacez les éléments suivants :

ZONE_1_ID : ID de la zone la plus petite entre l'ID de la zone locale et l'ID de la zone distante. Par exemple, si l'ID de la zone locale est 1 et que l'ID de la zone distante est 2, indiquez la valeur 1 ici.
ZONE_2_ID : ID de zone le plus grand entre l'ID de zone locale et l'ID de zone distante.

Voici à quoi peut ressembler une ressource MultiZoneNetworkPeeringConfig :

apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkPeeringConfig
metadata:
  name: zone-2-zone-3-peering-config
  namespace: gpc-system
spec:
  peeringConfigType: L2
  peerings:
  - peerA:
      blswID: 1
      port:
        port: 12
      zoneID: 2
    peerB:
      blswID: 1
      port:
        port: 12
      zoneID: 3
    secrets:
    - secretRef:
        name: zone-2-blsw-1-zone-3-blsw-1-ipv4-bgp-password
        namespace: gpc-system
      type: ipv4-bgp-password
    - secretRef:
        name: zone-2-blsw-1-zone-3-blsw-1-evpn-bgp-password
        namespace: gpc-system
      type: evpn-bgp-password
    - secretRef:
        name: zone-2-blsw-1-zone-3-blsw-1-bfd-auth-key
        namespace: gpc-system
      type: bfd-auth-key
  - peerA:
      blswID: 1
      port:
        port: 12
      zoneID: 2
    peerB:
      blswID: 2
      port:
        port: 12
      zoneID: 3
    secrets:
    - secretRef:
        name: zone-2-blsw-2-zone-3-blsw-2-ipv4-bgp-password
        namespace: gpc-system
      type: ipv4-bgp-password
    - secretRef:
        name: zone-2-blsw-2-zone-3-blsw-2-evpn-bgp-password
        namespace: gpc-system
      type: evpn-bgp-password
    - secretRef:
        name: zone-2-blsw-2-zone-3-blsw-2-bfd-auth-key
        namespace: gpc-system
      type: bfd-auth-key

Vous devez mettre à jour la valeur du port de l'un des commutateurs feuilles de bordure qui constituent le peering entre les zones. Dans le champ Spec.peerings, recherchez le peering qui s'étend sur plusieurs zones. Dans l'exemple, nous avons cette connexion d'appairage entre la zone 2 et la zone 3 :

peerA:
  blswID: 1
  port:
    port: 12
  zoneID: 2
peerB:
  blswID: 2
  port:
    port: 12
  zoneID: 3

Le résultat affiche deux commutateurs de feuille de bordure, identifiés par blswID: 1 et blswID: 2. Pour le premier commutateur de feuille de bordure identifié par blswID: 1, remplacez le port par la nouvelle valeur 20 :

peerA:
  blswID: 1
  port:
    port: 20
  zoneID: 2
peerB:
  blswID: 2
  port:
    port: 12
  zoneID: 3

Dans l'exemple, nous mettons à jour la valeur du port du premier commutateur de feuille de bordure sur port: 20.