Prérequis de la plateforme Operator Nexus

Article
04/24/2024

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

Les tableaux Pure Storage achetés avant 2024 ont des contrôleurs R3 de révision qui utilisent des câbles de console à effet de substitution et nécessitent les commandes de connexion de port série personnalisées ci-dessous :

Contrôleurs Pure Storage R3 :

ogcli update port ports-<PORT_#> 'baudrate="115200"' <PORT_#> Pure Storage Controller console
ogcli update port ports-<PORT_#> 'pinout="X1"' <PORT_#>	Pure Storage Controller console

Les appliances Pure Storage plus récentes et les systèmes mis à niveau de R3 vers le stockage Épuré R4, utilisent des câbles de console direct avec les paramètres mis à jour ci-dessous :

Contrôleurs Pure Storage R4 :

ogcli update port ports-<PORT_#> 'baudrate="115200"' <PORT_#> Pure Storage Controller console
ogcli update port ports-<PORT_#> 'pinout="X2"' <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 contrôleur Pure Storage.

Remarque

Tous les autres paramètres de configuration de port Terminal Server doivent rester identiques et fonctionner par défaut avec un câble de console RJ45 direct.

É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 de code de Purity : reportez-vous aux versions de Purity prises en charge
- 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

Installez la dernière version des extensions CLI nécessaires.

  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

Partage via

Prérequis de la plateforme Operator Nexus

Conditions préalables pour Azure

Prérequis en local

Configuration du matériel physique

Utilisation de la nomenclature (BOM)

Utilisation du diagramme d’élévation

Diagramme de câblage

Comment passer commande en fonction de la référence SKU

Référence SKU : définition

Passer une commande en fonction de la référence SKU

Comment créer l’empreinte matérielle physique

Commande et réception de la référence SKU d’infrastructure matérielle spécifique

Préparation du site

Planification des ressources

Compétences supposées du personnel chargé de l’installation

Vue d’ensemble du processus d’installation

Comment inspecter visuellement l’installation du matériel physique

Configuration de Terminal Server et de la baie de stockage

Configurer Terminal Server

Étape 1 : configuration du nom d’hôte

Étape 2 : configuration du réseau

Étape 3 : effacement de l’interface net3 (le cas échéant)

Étape 4 : configuration de l’utilisateur administrateur du support technique

Étape 5 : ajout de la prise en charge sudo pour les utilisateurs administrateurs

Étape 6 : garantir la disponibilité du service LLDP

Étape 7 : vérification de la date et l’heure du système

Vérifiez le paramètre de fuseau horaire :

Définissez le fuseau horaire sur UTC :

Vérifiez la date et l’heure actuelles :

Corrigez la date et l’heure si elle est incorrecte :

Étape 8 : étiquetage des ports Terminal Server (s’ils sont manquants ou incorrects)

Étape 9 : paramètres nécessaires pour les connexions série PURE Array

Étape 10 : vérification des paramètres

Configurer la baie de stockage

Attribution d’adresse IP iDRAC

Exemple

Configuration par défaut pour les autres appareils installés

Règles de pare-feu entre Azure et Nexus Cluster.

Installer des extensions CLI et se connecter à votre abonnement Azure

Connexion à l’abonnement Azure

Commentaires

Ressources supplémentaires