NSX Manager Installation

Pubblicato il 14 Dicembre 2021 da scanda

Vediamo ora l’installazione di NSX Manager, se avete verificato tutti i prerequisiti questa è la parte più semplice 🙂

Per prima cosa scarichiamo l’OVA dal nostro account VMware, ad oggi l’ultima release disponibile è la 3.1.3.3

Spostiamoci ora sul vcenter ed andiamo ad eseguire il deploy dell’OVA

Selezioniamo l’OVA appena scaricato

Impostiamo il nome VM del manager e il datacenter di destinazione

Selezioniamo il cluster

NOTA: per PoC o cluster di tipo collapased possiamo installare NSX manager sullo stesso cluster che andremo successivamente a preparare per NSX-T, per infrastrutture di produzione è consigliabile utilizzare un cluster dedicato al managment.

Viene riproposto un dettaglio delle configurazioni del template

Selezioniamo il size del nostro manager, per il lab utilizzeremo la Small ma per ambienti di produzione è consigliabile utilizzare almeno la Medium.

Selezioniamo il datastore

Colleghiamo il portgroup alla nic del manager

Andiamo ora ad inserire le password delle utenze utilizzate dall’appliance e i parametri di rete:

utenza root

utenza admin

utenza audit

viene chiesta anche una password ad uso interno

hostname utilizzare l’opportuno FQDN

Rolename NSX Manager (il ruolo di NSX Global Manager è da utilizzare solo per la Federation)

Indirizzo ip di management, netmask e default GW

Indirizzi DNS e Domain search list

Indirizzi NTP

Attivazione di SSH (utile per il troubleshooting)

Eventuali permessi di accesso via SSH all’utenza root

NOTA : le Internal Properties non vanno toccate

Se avete inserito corettamente tutti parametri vi verrà proposta una finestra di riepilogo

Ora resta solo da attendere il completamento del deploy

Successivamente sarà possibile collegarsi al manager per il completamento delle configurazioni.

 

Pubblicato in nsx, vmug | Contrassegnato , | Commenti disabilitati su NSX Manager Installation

NSX-T Ports and Protocols

Pubblicato il 6 Dicembre 2020 da scanda

Nella maggior parte dei casi, le componenti di infrastruttura (vcenter, esxi, nsx, etc.) risiedono sulla stessa rete. Quindi dialogano tra loro all’interno della stessa subnet senza dover attraversare router e firewall.

Normalmente è così … ma se invece operate all’interno di grandi realtà strutturate è probabile che esistano dei cluster di management che gestiscono altri cluster dedicati alla sola esecuzione computazionale.

Questi cluster possono risiedere su reti separate da diversi apparati Layer3 (router) o Layer 4-7 (firewall). In questo caso è necessario dialogare con degli specialisti di rete perchè venga garantita piena visibilità tra tutti gli oggetti dell’infrastruttura.

Difficilmente vi verrà permessa una visibilità del tipo any any permit, è più probabile che dobbiate fornire una lista dettagliata con indirizzi sorgenti e di destinazione e porte TPC/UDP su cui permettere l’accesso.

Vi è mai capitato di dover fornire questa lista di indirizzi e porte?  A me si e vi posso assicurare che non è semplice come sembra, gli oggetti da far dialogare sono tanti e su diversi servizi, dimenticarsi alcune regole può dar seguito a parecchio tempo speso in troubleshooting 🙁

Le cose sono cambiate negli anni e ora non è più necessario andare a cercare nei manuali d’installazione gli elenchi con tutte le porte necessarie.

Un grazie a vmware che ha realizzato questo utilissimo sito VMware Ports and Protocols 🙂

Prendetevi un pò di tempo per curiosare tra tutti i prodotti vmware, vi accorgerete di quanti servizi e porte sono necessarie a far dialogare le varie soluzioni.

Ma torniamo a noi! In quest’articolo ci limiteremo a scoprire quali porte servono per NSX! Dalla homepage del sito precedente selezioniamo NSX-T Data Center.

E’ possibile applicare dei filtri e selezionare le regole per versione e oggetto specifico.

Una volta applicati i filtri è anche possibile esportare l’elenco in pdf o excel 🙂

Filtrando con version 3.1 e source Manager otteniamo l’elenco delle regole necessarie a NSX Manager per dialogare con tutti gli oggetti di cui ha bisogno.

Le riassumo di seguito, la sorgente sono ovviamente gli ip degli NSX Managers:

Destination
ProtocolPortService Description
External LDAP server
TCP389,636Active Directory/LDAP
NSX ManagerTCP9000, 5671, 1234, 443, 8080, 1235, 9040Distributed Datastore
Install-upgrade HTTP repository
NSX messaging
Distributed Datastore
KVM and ESXi host
TCP443
Management and provisioning connection
vCenter Server
TCP443NSX Manager to compute manager
Traceroute DestinationUDP33434-33523Traceroute (Troubleshooting)
Intermediate and Root CA ServersTCP80Certificate Revocation Lists (CRLs)
Syslog Servers
TCP/UDP6514, 514Syslog
SNMP Servers
TCP/UDP161, 162
SNMP
NTP Servers
UDP123NTP
Management SCP Servers
TCP22SSH (upload support bundle, backups, etc.)
DNS Servers
TCP/UDP53DNS
Public Cloud Gateway (PCG)
TCP443NSX RPC channel(s)
github.com
TCP443Download IDS Signature from Trustwave Signature Repository.

Stesso esercizio per i Transport nodes e ESXi

Destination
ProtocolPortService Description
Intermediate and Root CA servers
TCP80Certificate Revocation Lists (CRLs)
NSX ManagerTCP1234, 8080, 1235, 5671, 443NSX Messaging channel
Install and upgrade HTTP repository
Management and provisioning connection
Syslog Servers
TCP/UDP6514, 514Syslog
NSX-T Data Center transport node
UDP3784, 3785
BFD Session between TEPs, in the datapath using TEP interface
GENEVE Termination End Point (TEP)UDP6081Transport network

NOTA: queste sono le porte necessarie a NSX, per gli host ESXi serviranno chiaramente altre porte per la normale operatività (NPT, DNS, SSH, etc.)

Alcune regole possono sembrare ridondanti ma ricordate che bisogna distinguere tra oggetti che iniziano la sessione e le relative destinazioni, a volte sono necessarie regole che permettano il traffico da ambo i lati sulle stesse porte.

Per la sola versione 3.1 l’elenco è di circa 50 servizi, dateci un occhio … conoscerle potrebbe risparmiarvi qualche brutto quarto d’ora 🙂

Pubblicato in firewall, nsx | Contrassegnato , | Commenti disabilitati su NSX-T Ports and Protocols

NSX-T Manager installation requirements

Pubblicato il 18 Novembre 2020 da scanda

Impazzienti di mettere le mani su NSX-T? Volete curiosare tra tutte le voci della web console del Manager? Preferite l’approcio imparare facendo?

Se siete come me credo proprio di si 🙂

Tuttavia l’esperienza mi ha insegnato che partire direttamente con l’installazione, saltando le verifiche sui requisiti e un opportuno dimensionamento, presto o tardi porta inevitabilmente a dover rifare tutto 🙁

Niente paura, la guida di NSX-T Data Center mette a disposizione i Workflows per ogni tipo di installazione, questa quella per vSphere:

  1. Review the NSX Manager installation requirements.
  2. Configure the necessary ports and protocols.
  3. Install the NSX Manager.
  4. Log in to the newly created NSX Manager.
  5. Configure a compute manager.
  6. Deploy additional NSX Manager nodes to form a cluster.
  7. Create transport zones.
  8. Review the NSX Edge installation requirements.
  9. Install NSX Edges.
  10. Create an NSX Edge cluster.
  11. Create host transport nodes.

Questo l’articolo va ad approfondire il primo punto, in successione pubblicherò gli articoli di tutti gli altri punti 🙂 La versione di NSX-T di riferimento è la 3.1.

Le informazioni riportate sono tratte da NSX-T Data Center Installation Guide, paragrafo System Requirements.

Versioni di ESXi supportate per il ruolo di Host Transport Nodes

Per maggiori dettagli consultare direttamente la Product Interoperability Matrices

Requisiti minimi di CPU e RAM per il profilo di Transport Node

HypervisorCPU CoresMemory
vSphere ESXi416GB

Nota : i requisiti HW sono gli stessi anche per KVM su Linux

Requisiti Network

Ogni Host Transport Node deve essere dotato di NIC supportate dalla versione di ESXi installata, non si fa cenno alla velocità minima ma è buona pratica utilizzare almeno 2 NIC da 10G per questioni di performance e ridondanza.

Nota : 2 NIC sono sufficienti ma 4 possono facilitare la migrazione da VSS/VDS al nuovo NVDS. Approfondirò quest’aspetto in un prossimo articolo.

Requisiti per NSX Manager

Il Manager è il cuore di NSX, oltre a permettere la gestione di tutte le configurazioni ingloba anche il ruolo di controller, questi i requisiti per il deploy.

Appliance SizeMemoryvCPUDisk SpaceNote
NSX Manager Extra Small8GB2300GBonly for the Cloud Service Manager (da NSX-T 3.0)
NSX Manager Small VM16GB4300GBlab and proof-of-concept deployments (da NSX-T 2.5.1)
NSX Manager Medium VM24GB6300GBtypical production environments - max 64 hypervisor
NSX Manager Large VM48GB12300GBlarge-scale deployments - more than 64 hypervisor

Requisiti latenza di rete

Latenza massima tra i Managers di un cluster : 10ms

Latenza massima tra i Managers e i Transport Nodes : 150ms

Dati forse scontati ma spesso sottovalutati, soprattutto su installazioni distribuite geograficamente.

Prerequisiti di indirizzamento e configurazioni DNS

Un’installazione di NSX comprende un cluster di 3 NSX Manager e un cluster Edge con almeno 2 nodi. Questo per ambienti di produzione, per PoC o demo si può tralasciare l’alta affidabilita delle componenti.

Vanno previsti indirizzi IP per ogni oggetto e relativi FQDN sulle zone DNS di pertinenza.

Nota : oltre ai record A è importante prevedere anche delle zone di reverse lookup, la mancanza di questi record può introdurre problemi di raggiungibilità e comunicazione tra le varie componenti.

Se è presente anche l’overlay GENEVE va allocata una subnet (IP pool) per i TEP da assegnare ai Transport Nodes. Anche su questo tema avremo modo di fare un approfondimento 🙂

Dimensionamento Totale

Ed in fine tiriamo le somme! Quante risorse vanno allocate per una tipica installazione NSX-T in produzione?

vCPUMemoryStorage
NSX Manager Medium624GB300GB
Total x 3 Manager1872GB900GB
NSX Edge Medium48GB200GB
Total x 2 Edge816GB400GB
Total resources2688GB1.3 TB

Le risorse richieste da NSX-T non sono trascurabili, su piccole infrastrutture possono avere un forte impatto. Su ambienti di una certa entità NSX Manager viene installato su un apposito cluster di Management assieme ad altri oggetti quali vRealize Log Insight e vRealize Network Insight.

Conoscere i requisiti di NSX-T e fare un corretto dimensionamento è di certo il primo punto da cui partire per una corretta installazione.

Concludo l’articolo lasciandovi un piccolo compito, verificate se la vostra infrastruttura ha le risorse per installare NSX! Non le avete? Allora progettate un nuovo cluster di Management 🙂

Pubblicato in nsx, vmug | Contrassegnato , , | Commenti disabilitati su NSX-T Manager installation requirements

NSX … Ogni lungo viaggio inizia con un primo passo

Pubblicato il 27 Ottobre 2020 da scanda

Titolo forse un pò scontato ma credo molto azzecato.

E’ da un pò di tempo che sto cercando il modo giusto su come iniziare una serie di articoli su NSX, ogni volta che trovo un’idea mi rendo conto che c’è sempre qualcosa prima che andrebbe spiegato e raccontato.
E’ un pò come smontare qualcosa per capirne il funzionamento … ti fermi solo quando hai tolto l’ultima vite e hai sul tavolo decine di piccoli pezzi 🙂
Stessa cosa è per NSX, da dove si parte per comprendere e fare propria questa tecnologia? Cosa bisogna sapere prima?Quali sono i mattoncini fondamentali che compongono NSX?

Iniziamo proprio da queste semplici domande per tracciare un percorso che spero possa aiutare chi si sta avvicinando a NSX.

Cos’è NSX?
Perchè non chiederlo direttamente a vmware? Questo il link dove andare a curiosare :

VMware NSX Data Center

Si tratta certamente di una pagina introduttiva ma per questo studiata per dar subito risalto ai punti di forza di NSX :

– Agility Through Automation
– Consistent Multi-Cloud Operations
– Intrinsic security
– Save on Both CapEx and OpEx

Ok, l’ultima è molto commerciale … ma capirete che è la conseguenza di consolidare le funzioni di rete e di sicurezza in un’unica piattaforma di virtualizzazione distribuita!

Probabilmente qualcuno si aspettava definizioni tipo SDN o simili, sorpresi nel trovare argomenti come multi-cloud e automation?

E qui andiamo un pò più nel dettaglio :

vmware-nsx-solution-brief

Nel datasheet troviamo le key features e uno schema delle funzionalità suddivise per tipologia di licenza

vmware-nsx-datasheet

NOTA: molte aziende scelgono NSX soprattutto per la micro-segmentazione … attenzione che il Distributed Firewalling è compreso solo a partire dalla Professional!

Ma non è ancora finita … ci sono degli aspetti che vanno approfonditi prima di lanciarsi nella prima installazione!
Troviamo chiare indicazioni proprio nel corso ICM (Install, Configure and Manage) di NSX Data Center :

Prerequisites:

Solid understanding of concepts presented in the following courses:
– VMware Data Center Virtualization Fundamentals
– VMware Introduction to Network Virtualization with NSX
– VMware Network Virtualization Fundamentals
– Network and Security Architecture with NSX ( questo l’ho aggiunto io 🙂 )

Si tratta di corsi tutti gratuiti a cui potete accedere con una sottoscrizione base a vmware learning zone!

– Good understanding of TCP/IP services and network security and working experience with firewalls
– Working experience of enterprise switching and routing

Questi ultimi due punti sono forse i più impegnativi per chi non ha esperienza di networking ma se siete arrivati a leggere fin qua la curiosità probabilmente non vi manca!

NSX è un prodotto completo e complesso e non basta certo qualche veloce lettura per comprenderlo a fondo.

In base alla mia esperienza posso dire che lavorare su ambienti Linux e corsi sul networking (CCNA like) possono facilitare l’apprendimento di NSX.

Vi lascio tutti questi spunti e ci vediamo al prossimo articolo!

Pubblicato in nsx | Contrassegnato , , , | Commenti disabilitati su NSX … Ogni lungo viaggio inizia con un primo passo

VMware Livefire

Pubblicato il 1 Dicembre 2019 da scanda

Cos’è un livefire?

Questo termine viene spesso associato all’addestramento militare. Si tratta di esercitazioni dove i partecipanti possono vivere un’esperienza molto simile ad uno scontro reale.

Calato in ambito tecnico possiamo paragonarlo ad un evento di formazione dove si opera su ambienti reali, affiancati e guidati da un istruttore esperto.

Associamo VMware a Livefire e capiamo subito di cosa stiamo parlando.

VMware Livefire viene lanciato agli inizi del 2012 come un importante strumento di supporto all community dei partner VMware. Ebbene si, è uno strumento pensato per i partner e non per i clienti finali. La partecipazione avviene esclusivamente per invito diretto da parte del team Livefire quindi, se siete partner VMware e volete partecipare ad un corso Livefire, non vi resta che chiedere informazioni al vostro partner manager VMware.

Quest’anno ho avuto l’occasione di partecipare a due corsi Livefire :

  • NSX-V Livefire – Architecture and Design
  • NSX-T Livefire – Next Generation Cloud Networking

Due corsi molto interessanti ma molto differenti, il primo (NSX-V) incentrato più sull’architettura e la progettazione, il secondo (NSX-T) molto più tecnico e corredato di laboratori sullo stile Hands-on Lab.

Potete consultare il catalogo dei corsi qui, ce n’è per tutti i gusti!

Se consultate i datasheet dei corsi vi accorgerete che servono dei prerequisiti precisi, normalmente una certificazione di livello VCP. E’ interessante notare che parole come “Advanced” e “Complex” spuntano un pò ovunque.

I corsi sono indubbiamente impegnativi e richiedono una certa esperienza (nulla a che vedere con un normale corso install configure and manage) ma vi posso assicurare che se volete mettervi alla prova e confrontarvi con docenti e tecnici di respiro internazionale questa è l’esperienza che fa per voi!

Con quest’articolo desidero iniziare a condividere la mia esperienza in ambito NSX e raccontarvi quest’affascinante tecnologia che continua ad evolvere giorno dopo giorno.

un saluto, Scanda

 

Pubblicato in livefire, nsx, vmug | Contrassegnato , , , | Commenti disabilitati su VMware Livefire

Clearing the Machine ID

Pubblicato il 14 Giugno 2019 da scanda

 

Recentemente ho avuto a che fare con uno strano problema legato a conflitti di indirizzi IP. Una VM Linux presentava problemi di raggiungibilità, le sessioni cadevano di continuo.

La VM non aveva un indirizzo IP statico ma utilizzava il DHCP per ottenerne uno. Da una prima analisi è emerso un conflitto di indirizzi IP, un’altra VM utilizzava lo stesso indirizzo. Fino a qua nulla di strano, capita spesso che vengano utilizzati come statici indirizzi riservati a pool dinamici di un DHCP server.

Non è questo il caso, l’altra VM utilizzava anch’essa il DHCP come metodo di assegnazione dell’indirizzo IP. Le due VM erano dei cloni identici.

Ho pensato ad un conflitto dovuto allo stesso MAC address della virtual NIC ma modificato l’indirizzo il problema persisteva.

Altra cosa strana era che il server DHCP continuava a rilasciare lo stesso indirizzo ad entrambe le VM, questo nonostante avessero due MAC address diversi. Naturalmente ho riavviato il server DHCP e cancellato più volte l’assegnazione dell’IP, nulla da fare.

Le VM in questione erano basate su Photon OS e per il clone avevo utilizzato le solite best practices : cancellazione delle chiavi SSH, pulizia dei log e history, rimozione delle configurazioni post installazione, etc.

Cercando in rete ho trovato altri utenti che segnalavano le stesso problema ma nulla di utile a risolverlo. Il sospetto era che qualcosa rimanesse sporco con la clonazione, una configurazione o un qualche valore. Affinando la ricerca ho trovato informazioni su un parametro utilizzato dai client DHCP per ottenere un indirizzo : il DHCP unique identifier (DUID). In un primo momento non l’ho preso in considerazione perché sembrava riguardare solo i metodi di assegnazione del DHCPv6.

Le VM utilizzavano solo IPv4 quindi ho pensato di essere fuori strada. Non trovando altro che mi potesse aiutare ho voluto approfondire l’argomento e ho cercato DHCP unique identifier associato a Photon OS … Beccato!

il primo risultato è un link alla documentazione ufficiale di Photon OS :

Clearing the Machine ID of a Cloned Instance for DHCP

Photon OS utilizza un UUID, creato durante l’installazione, come valore del DUID inserito nelle richieste DHCP. Il valore è memorizzato all’interno del file /etc/machine-id.

Questo valore va per tanto azzerato nel caso di clonazione, systemd lo rigenera in automatico.

Mal di testa passato e nuova best practice da aggiungere alle altre in caso di clonazione di VM Linux.

scanda

 

Pubblicato in troubleshooting, vmug | Contrassegnato , , , | Commenti disabilitati su Clearing the Machine ID

Disabilitare TLS v 1.0

Pubblicato il 29 Giugno 2018 da scanda

Per chi è coinvolto in compliance PCI-DSS il 30 giugno 2018 rappresenta la deadline per disabilitare il protocollo TLS v. 1.0, l’operazione va eseguita su tutti i sistemi che rientrano all’interno del perimetro PCI, infrastruttura vSphere compresa.

Questo il link alla KB 2145796 che documenta le azioni necessarie per passare a TLSv1.1 o TLSv1.2.

L’operazione non è indolore, soprattutto per chi utilizza ancora il vecchio client vSphere.

Sul blog vmware se ne parlava già più di un anno fa.

Buon lavoro a tutti 🙂

Pubblicato in vmug | Contrassegnato | Commenti disabilitati su Disabilitare TLS v 1.0

VMUGIT Meeting Padova – 5 Aprile 2017

Pubblicato il 6 Aprile 2017 da scanda

 

 

Ho avuto il piacere di tenere una sessione all’ultimo VMUG Meeting tenutosi a Padova lo scorso 5 aprile.

La sessione aveva lo scopo di fare un pò di luce sulla pratica di sostituire i certificati SSL creati di default con l’installazione di vSphere.

Come ben sapete i certificati di default sono selfsigned e, in ambienti di produzione, ritenuti non sicuri.

E’ buona pratica utilizzare una Certificate Authority interna e rilasciare certificati SSL “fidati” a tutti i servizi dell’infrastruttura, vSphere non sfugge di certo alla regola.

Dalla versione 6 di vSphere è stata introdotta la VMCA, la sessione introduce i concetti di base di questo nuovo componente pensato da vmware per facilitare tutte le operazioni legate ai certificati SSL.

Ho cercato di dare una visione di insieme all’argomento integrando il tutto con della documentazione esterna (ufficiale e non).

Resta comunque un argomento complesso e affascinante, mi ripropongo di ritornare sul tema con altri articoli.

A breve sarà disponibile la presentazione sul sito ufficiale del VMUG IT, inserirò il link nei prossimi giorni.

Ringrazio ancora lo staff del VMUG IT per la professionalità e la passione con cui portano avanti questo importante angolo dell’IT nazionale.

See you at the next event!

scanda

Pubblicato in vmug | Contrassegnato , | Commenti disabilitati su VMUGIT Meeting Padova – 5 Aprile 2017

Under construction

Pubblicato il 25 Settembre 2013 da scanda

Come da buona tradizione italiana questo sito è Under Construction da molto tempo … finalmente mi sono deciso ad installare WordPress e spero a breve di iniziare a pubblicare qualcosa. to be continued!

Pubblicato in news | Contrassegnato | Commenti disabilitati su Under construction