Pagine

venerdì 5 aprile 2019

Steps to move primary NSX manager role within of a Cross-vCenter implementation

This post comes from this request asked to the vCommunity. Essentially, he/she wonder understand if is it possible to move the primary NSX manager role within a Cross-vCenter implementation.

The answer is "YES" and is written here in "How Cross-vCenter NSX Works". If you change the role of a primary NSX Manager to standalone and any universal objects exist in the NSX environment, the NSX Manager will be assigned the transit role. The universal objects remain, but they cannot be changed, and no other universal objects can be created. You can delete universal objects from the transit role. The transit role should only be used temporarily, for example, when changing which NSX Manager is the primary.

Briefly the steps are:
  1. Perform a Backup of the all NSX Managers you have deployed into your environment
  2. Perform Universal Synchronization (before doing any action)
  3. Select the Primary NSX Manager and Remove Primary role (Now all NSX manager change in Transit Mode)
  4. Now switch on "NSX Controller Nodes" and clean up (deleting) all the controllers.
  5. Then switch back to the tab "NSX Managers" and select the New NSX Manager that you want to become Primary and Assign the Primary Role.
  6. Create new Controllers assigned to the New Primary NSX Manager
  7. When correctly deployed.... switch back to the tab "NSX Managers"
  8. Select the New Primary NSX Manager and -> Actions -> Add Secondary Manager (Proceed accepting the certificate until the end)
  9. Repeat for the others NSX Manager .....
  10. Verify that the Communication Channel is healty


But, let's covering the process down here in detail, step by step, with screenshots. To do so, I used the HOL-1925-01-NET provided from VMware.

First of all, a quick check on Primary and Secondary NSX Managers that "Segment IDs" doesn't overlap. In our case we have only one primary and one secondary, we don't have more than one secondary NSX Manager.





... and that "Universal Segment ID Pool" must be the same cross-vCenter (in our case "10000-10999" as shown above).

I created two new objects (in our case Logical Switch), the first one "LM_local" assigned to local transport zone and second one "LM_Universal" assigned to a Universal Transport Zone (that span across vCenters); just to be sure that everything works fine.


the result is ...



Perform a "Universal Synchronization" from the Primary NSX Manager (192.168.110.42)






Select the Primary NSX Manager and Remove Primary role (Now all NSX manager change in Transit Mode)





Now switch on "NSX Controller Nodes" and clean up (deleting) all the controllers.





Then switch back to the tab "NSX Managers" and select the New NSX Manager that you want to become Primary (in our case 192.168.210.42) and Assign the Primary Role.






Create new Controllers assigned to the New Primary NSX Manager (192.168.210.42)







When correctly deployed.... switch back to the tab "NSX Managers"
Select the New Primary NSX Manager and -> Actions -> Add Secondary Manager (192.168.110.42) and proceed accepting the certificate until the end.








Repeat for the others NSX Manager .....
Verify that the Communication Channel is healthy



If the "Communication Channel Health" is not green wait few second .... or try to force the communication ... and everything will go UP




Let's check the Logical Switch previously created and, as aspected, we can see that the "LM_Universal" is present on the new Primary as Universal Object and that "LM_local" is present only locally on the new Secondary NSX Manager.




Now to verify that everything is working fine, let's create a new universal object, of course must be created on the Primary NSX Manager and we verify that will be properly propagated on the Secondary as well.




That's it.

martedì 2 aprile 2019

How to shrink VMware NSX Controllers for small environment...

Disclaimer: Don't try this on NSX production environment.

Essendo il mio Home Lab "temporarily out of service" ... quale migliore occasione per utilizzare gli Hands-On Lab di VMware?
Tutti conosciamo gli "Hands-on Labs", sono dei laboratori pre-configurati che VMware mette a disposizione degli utenti per testare/verificare ed/o imparare le nuove funzionalità messe a disposizione dei propri prodotti.

Problema
Ho la necessità di verificare delle procedure di migrazione in un ambiente di sviluppo NSX prima di replicarlo in produzione, ma le risorse degli HOL sono limitate. Per questo motivo mi trovo costretto a dover rivedere/risparmiare su risorse come CPU e RAM da assegnare alle varie componenti della soluzione. Nello specifico mostrerò come ridurre le risorse (CPU e RAM) delle VMware NSX Controller, che di Default sono rispettivamente di 4GB di Memoria e 4 vCPU come indicato negli "Hardware Requirement for Appliances".


Come possiamo vedere sotto, le risorse messe a disposizione dagli Host ESXi dell'ambiente di LAB sono rispettivamente di 5.60GHz per la CPU e di 5.00GB di RAM.


Se provassimo ad installare una Controller NSX su questo Host, otterremo un errore relativamente alla Memoria non sufficiente per far avviare la Virtual Appliance.


Soluzione
Accediamo in modalità "Tech Support Mode" alla console NSX Manager di riferimento tramite un SSH client come indicato nel mio precedente post.


muoviamoci nella cartella "/common/em/components/vdn/controller/ovf/"


Facciamo una copia del file ".ovf" originale che andremo a modificare -> "#cp nsx-controller-6.4.1-build8409915.ovf nsx-controller-6.4.1-build8409915.ovf.orig"


Tramite editor "vi" andiamo modificare le righe del file "nsx-controller-6.4.1-build8409915.ovf" come indicato di seguito:

vCPU
Per quello che riguarda le vCPU, andiamo a ridurre da 4 vCPU (default) a 2 vCPU. Di seguito le impostazioni originali del file "nsx-controller-6.4.1-build8409915.ovf".


Di seguito le righe modificate.

  1. Sostituito il '4' con il '2' nella riga:
    '<rasd:ElementName xmls:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData>"2 virtual CPUs</rasd:ElementName>'
    Questa entry in realtà poteva anche non essere cambiata in quanto si tratta di una descrizione e non di una impostazione di sistema.
  2. Rimuovere la riga "<rasd:Reservation>2</rasd:Reservation>" relativa alle reservation.
  3. La riga "<rasd:VirtualQuantity>4</rasd:VirtualQuantity>" è stata sostituita con "<rasd:VirtualQuantity>2</rasd:VirtualQuantity>"


Memory
Per quello che riguarda la Memoria da utilizzare, andiamo a ridurre le impostazioni da 4GB (4096 di default) a 1GB (1024). Di seguito le impostazioni originali del file "nsx-controller-6.4.1-build8409915.ovf".


Di seguito le righe modificate.

  1. Sostituito il valore '4096' con '1024' nella riga:
    '<rasd:ElementName xmls:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData>"1024 MB of memory</rasd:ElementName>'
    Questa entry in realtà poteva anche non essere cambiata in quanto si tratta di una descrizione e non di una impostazione di sistema.
  2. Rimuovere la riga "<rasd:Reservation>4096</rasd:Reservation>" relativa alle reservation.
  3. La riga "<rasd:VirtualQuantity>4096</rasd:VirtualQuantity>" è stata sostituita con "<rasd:VirtualQuantity>1024</rasd:VirtualQuantity>"

Salvare le modifiche ed eseguire il deploy delle controller da interfaccia grafica GUI nell'area dedicata NSX.


Vediamo le impostazioni Hardware della VM ...


Perfettamente funzionante :-)


mercoledì 20 marzo 2019

VxRail vSAN - Time is synchronized across hosts and VC


Problema
Inserendo dei nuovi nodi VxRail ad un cluster esistente .... lo status del cluster in vSAN -> Health -> Cluster -> "Time is synchronized across hosts and VC" ... cliccando il pulsante "Ask VMware" non ottengo informazioni utili alla risoluzione del problema.



Verificato che l'NTP server sia lo stesso e correttamente impostato su tutti gli host ESXi, vCenter compreso; verifico ulteriormente se l'orario riportato sugli host differisce di qualche minuto. Ahii me tutto gli hosts ed il vCenter sono perfettamente allineati.

Soluzione
Il problema nel mio caso è stato risolto riavviando PSC e vCenter.

venerdì 15 marzo 2019

NSX Manager - Access to PostgreSQL

Disclaimer: Don't try this on NSX production environment.

In un precedente post "NSX Manager - Tech Support Access" ho descritto come accedere in modalità "engineering" alla console di NSX Manager.

In questo post mostro come poter accedere al PostgresSQL della console NSX Manager per reperire informazioni contenute all'interno delle varie tabelle.

Ripeto, quanto indicato nel disclaimer: quanto descritto non va testato in un ambiente in produzione in quanto qualsiasi modifica al sistema sottostante se non con l'aiuto del supporto tecnico di VMware potrebbe avere come risultato che il sistema non venga più supportato dal GSS. Consiglio di effettuare un backup dell'appliance, unica modalità valida per salvarsi le impostazioni dell'intera infrastruttura NSX.

Quanto descritto di seguito l'ho testato on line utilizzando i laboratori "nested" pre-configurati da VMware per valutare le diverse funzionalità dei prodotti; nel mio caso ho utilizzato uno di quelli relativi a NSX. Per accedere agli Hands on Lab (HOL) è necessario disporre di un account. Se non si dispone dell'account, per poter accedere ai LABs è possibile compilare la form di registrazione in modo gratuito.

Procediamo nel seguente modo:
  1. Accedere tramite "Putty" e/o SSH alla console NSX Manager con l'utenza "admin" ed immettere la rispettiva password


  2. Ottenuto l'accesso in modalità "Engineering" ....


  3. Per accedere al DataBase PosrgreSQL dobbiamo utilizzare l'utenza "secureall". Procediamo digitando dal prompt dei comandi "psql -U secureall"


  4. Ottenuto l'accesso al database digitare "\d" per ottenere la lista delle tabelle presenti ...



    Segue la lista delle tabelle presenti nel DB. Dal prompt è possibile interagire con il DB tramite i comandi standard SQL, quindi interrogare le tabelle tramite SQL e/o effettuare inserimenti, modifiche, cancellazioni ecc. ecc.


Per il momento questo è tutto, ma immaginate quante cose sono possibili fare avendo accesso al DB principale .....