Prérequis de la plateforme Operator Nexus
Les opérateurs doivent satisfaire les conditions préalables avant de déployer le logiciel de la plateforme Operator Nexus. Certaines de ces étapes peuvent prendre beaucoup de temps. Un examen de ces prérequis peut donc s’avérer utile.
Pour les déploiements ultérieurs d’instances Operator Nexus, vous pourrez passer à la création de la structure réseau locale et du cluster.
Conditions préalables pour Azure
Lorsque vous déployez Operator Nexus pour la première fois ou dans une nouvelle région, vous devez d’abord créer un contrôleur de structure réseau, puis un gestionnaire de cluster comme indiqué ici. En outre, il est nécessaire d’effectuer les tâches suivantes :
- Configurer des utilisateurs, des stratégies, des autorisations et un contrôle d’accès en fonction du rôle (RBAC)
- Configurer des groupes de ressources pour placer et regrouper des ressources d’une manière logique qui sera créée pour une plateforme Operator Nexus.
- Établir une connectivité ExpressRoute de votre réseau étendu vers une région Azure
- Pour activer Microsoft Defender for Endpoint pour le matériel nu local, vous devez avoir sélectionné un plan Defender pour serveurs dans votre abonnement Operator Nexus avant le déploiement. Des informations supplémentaires sont disponibles ici.
Prérequis en local
Dans le cadre du déploiement d’une instance locale d’Operator Nexus dans votre centre de données, il est probable que diverses équipes remplissent des rôles variés. Pour une installation réussie du logiciel de la plateforme, il est indispensable d’effectuer les tâches suivantes de manière précise.
Configuration du matériel physique
Un opérateur désireux de tirer parti du service Operator Nexus doit acheter, installer, configurer et exploiter des ressources matérielles. Cette section du document décrit les composants et les démarches nécessaires pour acheter et implémenter les systèmes matériels appropriés. Cette section évoque la nomenclature, le diagramme d’élévation de rack, le diagramme de câblage et les étapes nécessaires à l’assemblage du matériel.
Utilisation de la nomenclature (BOM)
Pour assurer à l’opérateur une expérience fluide, Operator Nexus s’accompagne d’une nomenclature qui indique quel matériel acquérir pour les besoins du service. Cette nomenclature dresse la liste complète des composants et des quantités nécessaires pour mettre en place l’environnement et assurer une mise en œuvre et une maintenance efficaces de l’instance locale. La nomenclature est structurée de façon à indiquer à l’opérateur les références SKU qu’il peut commander auprès des fournisseurs de matériel. La question des références SKU est abordée plus loin dans ce document.
Utilisation du diagramme d’élévation
Le diagramme d’élévation de rack est une référence graphique qui montre comment les serveurs et les autres composants s’intègrent dans les racks assemblés et configurés. Le diagramme d’élévation de rack est fourni dans le cadre des instructions globales d’installation. Il vise à aider les opérateurs à configurer et installer correctement tous les composants matériels nécessaires au bon fonctionnement du service.
Diagramme de câblage
Les diagrammes de câblage sont des représentations graphiques des connexions de câbles nécessaires pour fournir les services réseau aux composants installés dans les racks. Pour assurer une bonne mise en œuvre des différents composants de l’installation, il convient de respecter le diagramme de câblage.
Comment passer commande en fonction de la référence SKU
Référence SKU : définition
Une référence SKU est une méthode de gestion et de suivi d’inventaire qui permet de regrouper plusieurs composants sous une même désignation. Une référence SKU permet à un opérateur de commander tous les composants nécessaires à partir d’un seul numéro de référence SKU. La référence SKU permet d’accélérer l’interaction entre l’opérateur et le fournisseur tout en limitant les erreurs de commande associées aux listes de pièces complexes.
Passer une commande en fonction de la référence SKU
Operator Nexus a créé une série de références SKU avec des fournisseurs tels que Dell, Pure Storage et Arista auxquelles l’opérateur peut se référer au moment de passer commande. Autrement dit, il suffit à l’opérateur d’indiquer les informations SKU d’Operator Nexus au fournisseur pour recevoir la liste des pièces nécessaires à l’installation.
Comment créer l’empreinte matérielle physique
L’installation du matériel physique s’exécute en suivant une série d’étapes qui sont détaillées dans cette section. Il existe trois étapes préalables à la mise en œuvre de l’installation. Cette section traite également des compétences que les employés de l’opérateur sont supposés disposer pour mener à bien l’installation.
Commande et réception de la référence SKU d’infrastructure matérielle spécifique
La commande de la référence SKU appropriée et la livraison du matériel sur le site doivent intervenir avant le début de l’installation. Il convient de prévoir suffisamment de temps pour cette étape. Nous recommandons à l’opérateur de communiquer avec le fournisseur de matériel à un stade précoce du processus pour garantir et appréhender les délais de livraison.
Préparation du site
Le site d’installation peut prendre en charge l’infrastructure matérielle du point de vue de l’espace, de l’alimentation et du réseau. Les exigences spécifiques du site varient en fonction de la référence SKU achetée pour le site. Cette étape peut être effectuée entre la passation de la commande et la réception de la référence SKU.
Planification des ressources
Le processus d’installation proprement dit fait appel à plusieurs compétences différentes, notamment des ingénieurs pour l’alimentation, l’accès réseau et le câblage, le personnel en charge des systèmes pour l’assemblage des racks, des commutateurs et des serveurs, etc. Pour assurer une installation dans les temps, nous vous recommandons de retenir ces membres de l’équipe à l’avance en fonction du planning de livraison.
Compétences supposées du personnel chargé de l’installation
Le personnel réalisant l’installation doit être expérimenté en matière d’assemblage de matériel système tel que racks, commutateurs, PDU et serveurs. Les instructions fournies décrivent les étapes du processus, tout en renvoyant aux diagrammes de câblage et d’élévation de rack.
Vue d’ensemble du processus d’installation
Une fois le site préparé et validé pour la prise en charge de la référence SKU commandée, le processus d’installation se compose des étapes suivantes :
- Assemblage des racks en fonction de l’élévation de rack de la référence SKU. Des instructions d’assemblage de rack spécifiques seront fournies par le fabricant de racks.
- Une fois les racks assemblés, installation des appareils de structure dans les racks conformément au diagramme d’élévation.
- Câblage des appareils de structure en connectant les interfaces réseau conformément au diagramme de câblage.
- Assemblage et installation des serveurs conformément au diagramme d’élévation de rack.
- Assemblage et installation du dispositif de stockage conformément au diagramme d’élévation de rack.
- Câblage des appareils de serveur et de stockage en connectant les interfaces réseau conformément au diagramme de câblage.
- Connexion des câbles d’alimentation sur chaque appareil.
- Vérification/validation de l’installation en suivant les listes de contrôle fournies par Operator Nexus et les autres fournisseurs.
Comment inspecter visuellement l’installation du matériel physique
Il est recommandé d’étiqueter tous les câbles selon les normes ANSI/TIA 606 suivantes (ou celles de l’opérateur) pendant le processus d’installation. De même, il est conseillé de créer un schéma de câblage inversé depuis le port d’un commutateur jusqu’à la connexion finale. Le schéma inversé peut être comparé au diagramme de câblage afin de valider l’installation.
Configuration de Terminal Server et de la baie de stockage
Maintenant que l’installation physique et la validation sont terminées, les étapes suivantes consistent à configurer les paramètres par défaut nécessaires préalablement à l’installation du logiciel de la plateforme.
Configurer Terminal Server
Terminal Server a été déployé et configuré comme suit :
- Terminal Server est configuré pour la gestion hors bande
- Les informations d’identification d’authentification ont été configurées
- Le client DHCP est activé sur le port de gestion hors bande
- L’accès HTTP est activé
- L’interface Terminal Server est connectée aux routeurs de périphérie de fournisseur (PE) locaux des opérateurs et configurée avec les adresses IP et les informations d’identification
- Terminal Server est accessible à partir d’un réseau privé virtuel de gestion
Étape 1 : configuration du nom d’hôte
Pour configurer le nom d’hôte de votre serveur terminal, procédez comme suit :
Utilisez la commande suivante dans l’interface CLI :
sudo ogcli update system/hostname hostname=\"$TS_HOSTNAME\"
Paramètres :
| Nom du paramètre | Description |
|---|---|
| TS_HOSTNAME | Nom d’hôte du serveur Terminal Server |
Pour plus d’informations, consultez les références CLI.
Étape 2 : configuration du réseau
Pour configurer les paramètres réseau, procédez comme suit :
Exécutez les commandes suivantes dans l’interface CLI :
sudo ogcli create conn << 'END'
description="PE1 to TS NET1"
mode="static"
ipv4_static_settings.address="$TS_NET1_IP"
ipv4_static_settings.netmask="$TS_NET1_NETMASK"
ipv4_static_settings.gateway="$TS_NET1_GW"
physif="net1"
END
sudo ogcli create conn << 'END'
description="PE2 to TS NET2"
mode="static"
ipv4_static_settings.address="$TS_NET2_IP"
ipv4_static_settings.netmask="$TS_NET2_NETMASK"
ipv4_static_settings.gateway="$TS_NET2_GW"
physif="net2"
END
Paramètres :
| Nom du paramètre | Description |
|---|---|
| TS_NET1_IP | Du serveur Terminal Server PE1 à l’adresse IP NET1 TS |
| TS_NET1_NETMASK | Du serveur Terminal Server PE1 au masque de réseau NET1 TS |
| TS_NET1_GW | Du serveur Terminal Server PE1 à la passerelle NET1 TS |
| TS_NET2_IP | Du serveur Terminal Server PE2 vers l’adresse IP NET2 TS |
| TS_NET2_NETMASK | Du serveur Terminal Server PE2 vers le masque réseau NET2 TS |
| TS_NET2_GW | Du serveur Terminal Server PE2 vers la passerelle NET2 TS |
Remarque
Veillez à remplacer ces paramètres par des valeurs appropriées.
Étape 3 : effacement de l’interface net3 (le cas échéant)
Pour effacer l’interface net3, procédez comme suit :
- Recherchez une interface configurée sur l’interface physique net3 et « Adresse statique IPv4 par défaut » à l’aide de la commande suivante :
ogcli get conns
**description="Default IPv4 Static Address"**
**name="$TS_NET3_CONN_NAME"**
**physif="net3"**
Paramètres :
| Nom du paramètre | Description |
|---|---|
| TS_NET3_CONN_NAME | Nom de connexion NET3 du serveur Terminal Server |
- Supprimez l’interface si elle existe :
ogcli delete conn "$TS_NET3_CONN_NAME"
Remarque
Veillez à remplacer ces paramètres par des valeurs appropriées.
Étape 4 : configuration de l’utilisateur administrateur du support technique
Pour configurer l’utilisateur administrateur de support, procédez comme suit :
- Pour chaque utilisateur, exécutez la commande suivante dans l’interface CLI :
ogcli create user << 'END'
description="Support Admin User"
enabled=true
groups[0]="admin"
groups[1]="netgrp"
hashed_password="$HASHED_SUPPORT_PWD"
username="$SUPPORT_USER"
END
Paramètres :
| Nom du paramètre | Description |
|---|---|
| SUPPORT_USER | Utilisateur administrateur de support |
| HASHED_SUPPORT_PWD | Mot de passe de l’utilisateur administrateur de support codé |
Remarque
Veillez à remplacer ces paramètres par des valeurs appropriées.
Étape 5 : ajout de la prise en charge sudo pour les utilisateurs administrateurs
Pour ajouter la prise en charge sudo pour les utilisateurs administrateurs, procédez comme suit :
- Ouvrez le fichier de configuration sudoers :
sudo vi /etc/sudoers.d/opengear
- Ajoutez les lignes suivantes pour accorder l’accès sudo :
%netgrp ALL=(ALL) ALL
%admin ALL=(ALL) NOPASSWD: ALL
Remarque
Veillez à enregistrer les modifications après avoir modifié le fichier.
Cette configuration permet aux membres du groupe « netgrp » d’exécuter n’importe quelle commande en tant qu’utilisateur et membres du groupe « admin » pour exécuter n’importe quelle commande en tant qu’utilisateur sans nécessiter de mot de passe.
Étape 6 : garantir la disponibilité du service LLDP
Pour vous assurer que le service LLDP est disponible sur votre serveur terminal, procédez comme suit :
Vérifiez si le service LLDP est en cours d’exécution :
sudo systemctl status lldpd
Vous devez voir une sortie similaire à ce qui suit si le service est en cours d’exécution :
lldpd.service - LLDP daemon
Loaded: loaded (/lib/systemd/system/lldpd.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2023-09-14 19:10:40 UTC; 3 months 25 days ago
Docs: man:lldpd(8)
Main PID: 926 (lldpd)
Tasks: 2 (limit: 9495)
Memory: 1.2M
CGroup: /system.slice/lldpd.service
├─926 lldpd: monitor.
└─992 lldpd: 3 neighbors.
Notice: journal has been rotated since unit was started, output may be incomplete.
Si le service n’est pas actif (en cours d’exécution), démarrez-le :
sudo systemctl start lldpd
Activez le service pour démarrer le redémarrage :
sudo systemctl enable lldpd
Remarque
Veillez à effectuer ces étapes pour vous assurer que le service LLDP est toujours disponible et démarre automatiquement lors du redémarrage.
Étape 7 : vérification de la date et l’heure du système
Vérifiez que la date et l’heure du système est correctement définie et que le fuseau horaire du serveur terminal est au format UTC.
Vérifiez le paramètre de fuseau horaire :
Pour vérifier le paramètre de fuseau horaire actuel :
ogcli get system/timezone
Définissez le fuseau horaire sur UTC :
Si le fuseau horaire n’est pas défini sur UTC, vous pouvez le définir à l’aide de :
ogcli update system/timezone timezone=\"UTC\"
Vérifiez la date et l’heure actuelles :
Vérifiez les date et heure actuelles :
date
Corrigez la date et l’heure si elle est incorrecte :
Si la date ou l’heure est incorrecte, vous pouvez la corriger à l’aide de :
ogcli replace system/time
Reading information from stdin. Press Ctrl-D to submit and Ctrl-C to cancel.
time="$CURRENT_DATE_TIME"
Paramètres :
| Nom du paramètre | Description |
|---|---|
| CURRENT_DATE_TIME | Date ou heure actuelles au format hh:mm JJ MMM AAAA |
Remarque
Assurez-vous que la date et l’heure du système est exacte pour éviter tout problème lié aux applications ou aux services qui s’y appuient.
Étape 8 : étiquetage des ports Terminal Server (s’ils sont manquants ou incorrects)
Pour étiqueter les ports Terminal Server, utilisez la commande suivante :
ogcli update port "port-<PORT_#>" label=\"<NEW_NAME>\" <PORT_#>
Paramètres :
| Nom du paramètre | Description |
|---|---|
| NEW_NAME | Nom d’étiquette du port |
| PORT_# | Numéro de port Terminal Server |
Étape 9 : paramètres nécessaires pour les connexions série PURE Array
Pour configurer les connexions série PURE Array, utilisez les commandes suivantes :
ogcli update port ports-<PORT_#> 'baudrate="115200"' <PORT_#> Pure Storage Controller console
ogcli update port ports-<PORT_#> 'pinout="X1"' <PORT_#> Pure Storage Controller console
Paramètres :
| Nom du paramètre | Description |
|---|---|
| PORT_# | Numéro de port Terminal Server |
Ces commandes définissent le débit en bauds et le brochage pour la connexion à la console du Pure Storage Controller.
Étape 10 : vérification des paramètres
Pour vérifier les paramètres de configuration, exécutez les commandes suivantes :
ping $PE1_IP -c 3 # Ping test to PE1 //TS subnet +2
ping $PE2_IP -c 3 # Ping test to PE2 //TS subnet +2
ogcli get conns # Verify NET1, NET2, NET3 Removed
ogcli get users # Verify support admin user
ogcli get static_routes # Ensure there are no static routes
ip r # Verify only interface routes
ip a # Verify loopback, NET1, NET2
date # Check current date/time
pmshell # Check ports labelled
sudo lldpctl
sudo lldpcli show neighbors # Check LLDP neighbors - should show data from NET1 and NET2
Remarque
Vérifiez que les voisins LLDP sont comme prévu, ce qui indique les connexions réussies à PE1 et PE2.
Exemple de sortie des voisins LLDP :
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface: net2, via: LLDP, RID: 2, Time: 0 day, 20:28:36
Chassis:
ChassisID: mac 12:00:00:00:00:85
SysName: austx502xh1.els-an.att.net
SysDescr: 7.7.2, S9700-53DX-R8
Capability: Router, on
Port:
PortID: ifname TenGigE0/0/0/0/3
PortDescr: GE10_Bundle-Ether83_austx4511ts1_net2_net2_CircuitID__austxm1-AUSTX45_[CBB][MCGW][AODS]
TTL: 120
-------------------------------------------------------------------------------
Interface: net1, via: LLDP, RID: 1, Time: 0 day, 20:28:36
Chassis:
ChassisID: mac 12:00:00:00:00:05
SysName: austx501xh1.els-an.att.net
SysDescr: 7.7.2, S9700-53DX-R8
Capability: Router, on
Port:
PortID: ifname TenGigE0/0/0/0/3
PortDescr: GE10_Bundle-Ether83_austx4511ts1_net1_net1_CircuitID__austxm1-AUSTX45_[CBB][MCGW][AODS]
TTL: 120
-------------------------------------------------------------------------------
Remarque
Vérifiez que la sortie correspond à vos attentes et que toutes les configurations sont correctes.
Configurer la baie de stockage
- L’opérateur doit installer le matériel de la baie de stockage comme spécifié par la nomenclature et l’élévation de rack dans le rack d’agrégation.
- L’opérateur doit fournir au technicien chargé de la baie de stockage les informations nécessaires pour qu’il puisse se rendre sur le site afin de configurer l’appliance.
- Données requises spécifiques à l’emplacement partagées avec le technicien chargé de la baie de stockage :
- Nom du client :
- Date de l’inspection physique :
- Numéro de série du châssis :
- Nom d’hôte du tableau de la baie de stockage :
- Code CLLI (Common Language Location Identifier) :
- Adresse de l’installation :
- Emplacement des FIC/rack/grille :
- Données fournies à l’opérateur et partagées avec le technicien chargé de la baie de stockage, qui seront communes à toutes les installations :
- Niveau du code de pureté : 6.5.1
- Mode sans échec : désactivé
- Fuseau horaire de la matrice : UTC
- Adresse IP du serveur DNS (Domain Name System) : 172.27.255.201
- Suffixe de domaine DNS : non défini par l’opérateur durant la configuration
- Adresse IP du serveur réseau NTP (Network Time Protocol) ou nom de domaine complet : 172.27.255.212
- Syslog primaire : 172.27.255.210
- Syslog secondaire : 172.27.255.211
- Adresse IP ou nom de domaine complet de la passerelle SMTP : non défini par l’opérateur lors de la configuration
- Nom de domaine de l’expéditeur de l’e-mail : nom de domaine de l’expéditeur de l’e-mail (example.com)
- Adresses e-mail à alerter : non définies par l’opérateur pendant la configuration
- Serveur proxy et port : non définis par l’opérateur lors de la configuration
- Gestion : Interface virtuelle
- Adresse IP : 172.27.255.200
- Passerelle : 172.27.255.1
- Masque de sous-réseau : 255.255.255.0
- MTU : 1 500
- Liaison : non définie par l’opérateur lors de la configuration
- Gestion : Contrôleur 0
- Adresse IP : 172.27.255.254
- Passerelle : 172.27.255.1
- Masque de sous-réseau : 255.255.255.0
- MTU : 1 500
- Liaison : non définie par l’opérateur lors de la configuration
- Gestion : Contrôleur 1
- Adresse IP : 172.27.255.253
- Passerelle : 172.27.255.1
- Masque de sous-réseau : 255.255.255.0
- MTU : 1 500
- Liaison : non définie par l’opérateur lors de la configuration
- Numéro de réseau local virtuel/Préfixe : 43
- ct0.eth10 : non défini par l’opérateur lors de la configuration
- ct0.eth11 : non défini par l’opérateur lors de la configuration
- ct0.eth18 : non défini par l’opérateur lors de la configuration
- ct0.eth19 : non défini par l’opérateur lors de la configuration
- ct1.eth10 : non défini par l’opérateur lors de la configuration
- ct1.eth11 : non défini par l’opérateur lors de la configuration
- ct1.eth18 : non défini par l’opérateur lors de la configuration
- ct1.eth19 : non défini par l’opérateur lors de la configuration
- Pure Tunable à appliquer :
- puretune -set PS_ENFORCE_IO_ORDERING 1 "PURE-209441";
- puretune -set PS_STALE_IO_THRESH_SEC 4 "PURE-209441";
- puretune -set PS_LANDLORD_QUORUM_LOSS_TIME_LIMIT_MS 0 "PURE-209441";
- puretune -set PS_RDMA_STALE_OP_THRESH_MS 5000 "PURE-209441";
- puretune -set PS_BDRV_REQ_MAXBUFS 128 "PURE-209441";
Attribution d’adresse IP iDRAC
Avant le déploiement de Nexus Cluster, il est préférable pour l’opérateur de définir les adresses IP iDRAC pendant l’organisation des racks matériels. Voici comment mapper des serveurs aux adresses IP :
- Attribuez des adresses IP en fonction de la position au sein du rack de chaque serveur.
- Utilisez le quatrième bloc /24 à partir du sous-réseau /19 alloué pour Fabric.
- Commencez par attribuer des adresses IP du serveur inférieur vers le haut dans chaque rack, à partir de 0.11.
- Continuez à attribuer des adresses IP dans l’ordre au premier serveur en bas du rack suivant.
Exemple
Portée Fabric : 10.1.0.0-10.1.31.255 – Le sous-réseau iDRAC au quatrième /24 est 10.1.3.0/24.
| Rack | Serveur | Adresse IP iDRAC |
|---|---|---|
| Rack 1 | Worker 1 | 10.1.3.11/24 |
| Rack 1 | Worker 2 | 10.1.3.12/24 |
| Rack 1 | Worker 3 | 10.1.3.13/24 |
| Rack 1 | Worker 4 | 10.1.3.14/24 |
| Rack 1 | Worker 5 | 10.1.3.15/24 |
| Rack 1 | Worker 6 | 10.1.3.16/24 |
| Rack 1 | Worker 7 | 10.1.3.17/24 |
| Rack 1 | Worker 8 | 10.1.3.18/24 |
| Rack 1 | Contrôleur 1 | 10.1.3.19/24 |
| Rack 1 | Contrôleur 2 | 10.1.3.20/24 |
| Rack 2 | Worker 1 | 10.1.3.21/24 |
| Rack 2 | Worker 2 | 10.1.3.22/24 |
| Rack 2 | Worker 3 | 10.1.3.23/24 |
| Rack 2 | Worker 4 | 10.1.3.24/24 |
| Rack 2 | Worker 5 | 10.1.3.25/24 |
| Rack 2 | Worker 6 | 10.1.3.26/24 |
| Rack 2 | Worker 7 | 10.1.3.27/24 |
| Rack 2 | Worker 8 | 10.1.3.28/24 |
| Rack 2 | Contrôleur 1 | 10.1.3.29/24 |
| Rack 2 | Contrôleur 2 | 10.1.3.30/24 |
| Rack 3 | Worker 1 | 10.1.3.31/24 |
| Rack 3 | Worker 2 | 10.1.3.32/24 |
| Rack 3 | Worker 3 | 10.1.3.33/24 |
| Rack 3 | Worker 4 | 10.1.3.34/24 |
| Rack 3 | Worker 5 | 10.1.3.35/24 |
| Rack 3 | Worker 6 | 10.1.3.36/24 |
| Rack 3 | Worker 7 | 10.1.3.37/24 |
| Rack 3 | Worker 8 | 10.1.3.38/24 |
| Rack 3 | Contrôleur 1 | 10.1.3.39/24 |
| Rack 3 | Contrôleur 2 | 10.1.3.40/24 |
| Rack 4 | Worker 1 | 10.1.3.41/24 |
| Rack 4 | Worker 2 | 10.1.3.42/24 |
| Rack 4 | Worker 3 | 10.1.3.43/24 |
| Rack 4 | Worker 4 | 10.1.3.44/24 |
| Rack 4 | Worker 5 | 10.1.3.45/24 |
| Rack 4 | Worker 6 | 10.1.3.46/24 |
| Rack 4 | Worker 7 | 10.1.3.47/24 |
| Rack 4 | Worker 8 | 10.1.3.48/24 |
| Rack 4 | Contrôleur 1 | 10.1.3.49/24 |
| Rack 4 | Contrôleur 2 | 10.1.3.50/24 |
Exemple de conception de trois instances locales de la même paire NFC/CM en utilisant des réseaux /19 séquentiels dans un /16 :
| Instance | Portée Fabric | Sous-réseau iDRAC |
|---|---|---|
| Instance 1 | 10.1.0.0-10.1.31.255 | 10.1.3.0/24 |
| Instance 2 | 10.1.32.0-10.1.63.255 | 10.1.35.0/24 |
| Instance 3 | 10.1.64.0-10.1.95.255 | 10.1.67.0/24 |
Configuration par défaut pour les autres appareils installés
- Tous les appareils de structure réseau sont définis en mode
ZTP(sauf pour Terminal Server) - Les serveurs ont les paramètres de structure par défaut
Règles de pare-feu entre Azure et Nexus Cluster.
Pour établir des règles de pare-feu entre Azure et Nexus Cluster, l’opérateur doit ouvrir les ports spécifiés. Cela permet une connectivité et une communication correctes pour les services requis en utilisant les protocoles TCP (Transmission Control Protocol) et UDP (User Datagram Protocol).
| N° | Source | Destination | Port (TCP/UDP) | Bidirectionnel | Objectif de la règle |
|---|---|---|---|---|---|
| 1 | réseau virtuel Azure | Cluster | 22 TCOP | Non | Pour SSH vers des serveurs undercloud à partir du sous-réseau CM. |
| 2 | réseau virtuel Azure | Cluster | TCP 443 | Non | Pour accéder à iDRAC de nœuds undercloud |
| 3 | réseau virtuel Azure | Cluster | TCP 5900 | Non | Gnmi |
| 4 | réseau virtuel Azure | Cluster | TCP 6030 | Non | Certificats Gnmi |
| 5 | réseau virtuel Azure | Cluster | TCP 6443 | Non | Pour accéder au cluster K8S undercloud |
| 6 | Cluster | réseau virtuel Azure | TCP 8080 | Oui | Pour le montage d’une image ISO dans iDRAC, mise à jour de runtime NNF |
| 7 | Cluster | réseau virtuel Azure | TCP 3128 | Non | Proxy pour se connecter à des points de terminaison Azure globaux |
| 8 | Cluster | réseau virtuel Azure | TCP et UDP 53 | Non | DNS |
| 9 | Cluster | réseau virtuel Azure | UDP 123 | Non | NTP |
| 10 | Cluster | réseau virtuel Azure | TCP 8888 | Non | Connexion au service web Cluster Manager |
| 11 | Cluster | réseau virtuel Azure | TCP et UDP 514 | Non | Pour accéder aux journaux undercloud à partir de Cluster Manager |
Installer des extensions CLI et se connecter à votre abonnement Azure
Installez la dernière version des extensions CLI nécessaires.
Connexion à l’abonnement Azure
az login
az account set --subscription $SUBSCRIPTION_ID
az account show
Notes
Le compte doit des autorisations nécessaires pour lire/écrire/publier dans l’abonnement
Commentaires
Prochainement : Tout au long de l'année 2024, nous supprimerons progressivement les GitHub Issues en tant que mécanisme de retour d'information pour le contenu et nous les remplacerons par un nouveau système de retour d'information. Pour plus d’informations, voir: https://aka.ms/ContentUserFeedback.
Soumettre et afficher des commentaires pour