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 :-)