PowerFlex: Deployment Fails -Network Configuration Mismatch - le interfacce sono connesse allo stesso switch
Riepilogo: Questo articolo include le procedure per PFxM (PowerFlex Manager) versione 3.x e PFMP (PowerFlex Management Platform) 4.x. Per PFxM 3.x, l'attività di assistenza potrebbe segnalare "le interfacce sono connesse allo stesso switch". Lo stesso vale per l'attività del gruppo di risorse (RG) PFMP 4.x. L'interfaccia utente potrebbe segnalare "Network Configuration Mismatch" anche quando il cablaggio fisico del server corrisponde alla configurazione del modello. ...
Sintomi
Il servizio viene rimosso da PFxM o RG in PFMP e il server viene cablato nuovamente per un deployment diverso, che potrebbe non riuscire con il seguente errore dell'interfaccia utente:
The port channel for interfaces NIC.Integrated.1-2-1 NIC.Slot.2-2-1 cannot be created because the interfaces are connected to the same switch % {switch_certname}.
exception.log
#/opt/asm-deployer/lib/asm/provider/switch/base.rb:462:in `validate_connectivity'
/opt/asm-deployer/lib/asm/provider/switch/nexus5k.rb:245:in `configure_server_interface'
/opt/asm-deployer/lib/asm/provider/switch/nexus5k.rb:216:in `block in provision_server_networking'
org/jruby/RubyArray.java:1735:in `each'
/opt/asm-deployer/lib/asm/provider/switch/nexus5k.rb:215:in `provision_server_networking'
/opt/asm-deployer/lib/asm/provider/switch/nexus5k.rb:153:in `configure_server'
/opt/asm-deployer/lib/asm/type/base.rb:413:in `delegate'
/opt/asm-deployer/lib/asm/type/switch.rb:173:in `configure_server'
/opt/asm-deployer/lib/asm/type/server.rb:3030:in `block in configure_networking!'
org/jruby/RubyArray.java:1735:in `each'
/opt/asm-deployer/lib/asm/type/server.rb:3023:in `configure_networking!'
/opt/asm-deployer/lib/asm/type/switch.rb:90:in `block in configure_server_networking!'
org/jruby/RubyArray.java:1735:in `each'
/opt/asm-deployer/lib/asm/type/switch.rb:89:in `configure_server_networking!'
/opt/asm-deployer/lib/asm/service/switch_collection.rb:337:in `block in configure_server_switches!'
org/jruby/RubyArray.java:1735:in `each'
/opt/asm-deployer/lib/asm/service/switch_collection.rb:329:in `configure_server_switches!'
/opt/asm-deployer/lib/asm/service/switch_collection.rb:429:in `configure_server_networking!'
/opt/asm-deployer/lib/asm/service_deployment.rb:4962:in `process_switches_via_types'
/opt/asm-deployer/lib/asm/service_deployment.rb:537:in `process'
/opt/asm-deployer/lib/asm.rb:220:in `block in process_deployment'
Impatto
Errore di deployment del servizio o del gruppo di replica.
Causa
La rimozione di un servizio o di un gruppo di replica non cancella i dati network_topology memorizzati nella cache.
I dati memorizzati nella cache potrebbero essere utilizzati nel successivo deployment del servizio o del gruppo di replica, causando l'esito negativo del deployment.
Risoluzione
Verificare che il server su cui si è verificato il problema sia cablato in modo AB-BA. Se il cablaggio è convalidato ma mostra dati errati nell'interfaccia utente, cancellare la cache per forzare un ricalcolo durante il successivo deployment del servizio o del gruppo di replica.
Seguire i comandi riportati di seguito, a seconda della versione, per cancellare le voci memorizzate nella cache.
Il formato del nome della risorsa è {rackserver-servicetag}
Per PFxM 3.x
Per PFxM versione 3.6.1 e precedenti, attenersi alla procedura riportata di seguito:
1. Eseguire questo comando:
env RUBYLIB=/opt/asm-deployer/lib pry
2. Dalla shell che si apre, eseguire i seguenti comandi Ruby:
Sostituire il codice di matricola con il codice di matricola del nodo, in lettere minuscole.
require "asm"
puppetdb = ASM::Client::Puppetdb.new(:logger => Logger.new("/dev/stdout")); nil
puppetdb.merge_facts_blocking!("rackserver-servicetag".downcase, "network_topology" => "{}"); nil
3. Eseguire nuovamente l'inventario sul server Il deployment successivo che utilizza tale server ricalcolerà la connettività dello switch da zero.
Per PFxM versione 3.6.2 e successive, seguire la procedura riportata di seguito:
1. Eseguire il seguente comando per accedere alla shell psql :
psql -U orion asm_dev
2. Il comando seguente elenca tutti i nodi e trova la voce che corrisponde all host necessario per cancellare la cache per:
asm_dev=> SELECT certname FROM factsets WHERE certname LIKE 'rackserver%';
Ad esempio:
asm_dev=> SELECT certname FROM factsets WHERE certname LIKE 'rackserver%';
certname
-------------------
rackserver-1a1b123
rackserver-1a1b124
rackserver-1a1b125
rackserver-1a1b126
rackserver-1a1b127
(5 rows)
3. Modificare il comando di esempio riportato di seguito e sostituire rackserver-xxxxxx con il valore corrispondente all'ID del nodo corretto:
asm_dev=> DELETE FROM factsets WHERE certname = LOWER('rackserver-xxxxxx');
4. Dalla shell psql, eseguire il comando seguente per salvare la transazione nel database:
asm_dev=> COMMIT;
5. Uscire dalla shell psql:
asm_dev=> \q
6. Verificare che non siano in esecuzione job in PFxM e riavviare il processo asmmanager:
systemctl restart asmmanager
7. Eseguire l'inventario sul server dalla scheda "Resources" di PFxM nell'interfaccia utente di Il successivo deployment con tale server ricalcolerà la connettività dello switch da zero.
Per PFMP 4.x
1. Eseguire il seguente comando da uno dei nodi di gestione Kubernetes (K8s), noto anche come "MVM" (Management Virtual Machine), per accedere alla shell PSQL connessa al database asm_dev:
Per PFMP versione 4.6 e precedenti
kubectl exec -it -n powerflex $(kubectl get pods -n powerflex -l='postgres-operator.crunchydata.com/role=master' | grep Running | cut -d' ' -f1) -- psql -U postgres -d asm_dev
Hotfix DCIS per PFMP versione 4,8 e successive
kubectl exec -it -n powerflex $(kubectl get pods -n powerflex -l='cnpg.io/instanceRole=primary, cnpg.io/podRole=instance' | grep Running | cut -d' ' -f1) -- psql -U postgres -d asm_dev
2. Il comando seguente elenca tutti i nodi e trova la voce che corrisponde all host necessario per cancellare la cache per:
SELECT certname FROM factsets WHERE certname LIKE 'rackserver%';
Ad esempio:
asm_dev=> SELECT certname FROM factsets WHERE certname LIKE 'rackserver%';
certname
-------------------
rackserver-1a1b123
rackserver-1a1b124
rackserver-1a1b125
rackserver-1a1b126
rackserver-1a1b127
(5 rows)
3. Modificare il comando di esempio riportato di seguito e sostituire rackserver-xxxxxx con il valore corrispondente all'ID del nodo corretto:
asm_dev=> DELETE FROM factsets WHERE certname = LOWER('rackserver-xxxxxx');
Ad esempio:
asm_dev=# DELETE FROM factsets WHERE certname = LOWER('rackserver-1a1b123');
DELETE 1
4. Verificare che la voce sia stata cancellata:
asm_dev=# SELECT certname FROM factsets WHERE certname LIKE 'rackserver-xxxxxx';
(0 rows)
5. Uscire dalla shell psql :
asm_dev=> \q
6. Riavviare tutti i pod nel namespace PowerFlex:
kubectl rollout restart deployment -n powerflex
7. Eseguire l'inventario sul server dalla scheda "Resources" di PFMP nell'interfaccia utente di Verificare che le porte dello switch riflettano correttamente la topologia cliccando su "View Details" sulla risorsa. Il successivo deployment del gruppo di replica utilizzando il server ricalcolerà la connettività dello switch da zero.
Versioni interessate
PFxM 3.x
PFMP 4.x