Scanda :)

NSX finalize the installation

Pubblicato il 16 Dicembre 2021 da scanda

Primo accesso eseguito!

Completiamo ora alcune configurazioni di base.

Per prima cosa sistemiamo le licenze, NSX-T presenta di default una licenza con funzionalità limitate.

Carichiamo quindi una licenza valida per abilitare le funzioalità che ci interessano.

E’ possibile utilizzare una licenza di valutazione di 60 giorni, potete richiederela a questo link.

Spostiamoci ora sotto System -> Appliances

Per ambienti di produzione è consigliato il deploy di altri 2 manager per formare un cluster di management, lascio a voi provare il wizard per aggiungerli (non è necessario farlo dal vcenter). E’ possibile configurare un virtual IP che verrà sempre assegnato al nodo master.

Possiamo vedere alcuni messaggi che indicano che non è ancora stato configurato un compute manager e nemmeno il backup delle configurazioni.

Il compute manager non è altro che il vcenter che gestisce i nodi esxi che verranno preparati come transport nodes.

Clicchiamo su COMPUTE MANAGER e successivamente su +ADD COMPUTE MANAGER

accettiamo il thumbprint del vcenter

attendiamo che il vcenter si registri correttamente con il manager

ora possiamo vedere gli hosts andando sotto System -> Fabric -> Nodes, selezioniamo il vcenter appena aggiunto su Managed By e compariranno i nodi.

Resta solo da configurare il backup! Andiamo sotto System -> Backup & Restore

Attualmente l’unica modalità supportata è la copia via SFTP, inserire i parametri necessari

Naturalmente è possibile schedulare il processo di backup a seconda delle proprie esigenze

In caso di perdita o danneggiamento del manager sarà possibile rieseguire il deploy dell’appliance passando il percorso di backup per un rapido ripristino.

Questo completa la configurazione di base del nostro manager 🙂

Pubblicato in nsx, vmug | Contrassegnato nsx, vmug | Commenti disabilitati

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 nsx, vmug | Commenti disabilitati

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	Protocol	Port	Service Description
External LDAP server	TCP	389,636	Active Directory/LDAP
NSX Manager	TCP	9000, 5671, 1234, 443, 8080, 1235, 9040	Distributed Datastore Install-upgrade HTTP repository NSX messaging Distributed Datastore
KVM and ESXi host	TCP	443	Management and provisioning connection
vCenter Server	TCP	443	NSX Manager to compute manager
Traceroute Destination	UDP	33434-33523	Traceroute (Troubleshooting)
Intermediate and Root CA Servers	TCP	80	Certificate Revocation Lists (CRLs)
Syslog Servers	TCP/UDP	6514, 514	Syslog
SNMP Servers	TCP/UDP	161, 162	SNMP
NTP Servers	UDP	123	NTP
Management SCP Servers	TCP	22	SSH (upload support bundle, backups, etc.)
DNS Servers	TCP/UDP	53	DNS
Public Cloud Gateway (PCG)	TCP	443	NSX RPC channel(s)
github.com	TCP	443	Download IDS Signature from Trustwave Signature Repository.

Stesso esercizio per i Transport nodes e ESXi

Destination	Protocol	Port	Service Description
Intermediate and Root CA servers	TCP	80	Certificate Revocation Lists (CRLs)
NSX Manager	TCP	1234, 8080, 1235, 5671, 443	NSX Messaging channel Install and upgrade HTTP repository Management and provisioning connection
Syslog Servers	TCP/UDP	6514, 514	Syslog
NSX-T Data Center transport node	UDP	3784, 3785	BFD Session between TEPs, in the datapath using TEP interface
GENEVE Termination End Point (TEP)	UDP	6081	Transport 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 firewall, nsx | Commenti disabilitati

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:

Review the NSX Manager installation requirements.
Configure the necessary ports and protocols.
Install the NSX Manager.
Log in to the newly created NSX Manager.
Configure a compute manager.
Deploy additional NSX Manager nodes to form a cluster.
Create transport zones.
Review the NSX Edge installation requirements.
Install NSX Edges.
Create an NSX Edge cluster.
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

Hypervisor	CPU Cores	Memory
vSphere ESXi	4	16GB

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 Size	Memory	vCPU	Disk Space	Note
NSX Manager Extra Small	8GB	2	300GB	only for the Cloud Service Manager (da NSX-T 3.0)
NSX Manager Small VM	16GB	4	300GB	lab and proof-of-concept deployments (da NSX-T 2.5.1)
NSX Manager Medium VM	24GB	6	300GB	typical production environments - max 64 hypervisor
NSX Manager Large VM	48GB	12	300GB	large-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?

	vCPU	Memory	Storage
NSX Manager Medium	6	24GB	300GB
Total x 3 Manager	18	72GB	900GB

NSX Edge Medium	4	8GB	200GB
Total x 2 Edge	8	16GB	400GB

Total resources	26	88GB	1.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 nsx, vmug, vmware | Commenti disabilitati

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 nsx, vmug, vmware, VMware_Learning_Zone | Commenti disabilitati

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 livefire, nsx, vmug, vmware | Commenti disabilitati

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 cloning, dhcp, photonos, vmug | Commenti disabilitati

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 PCI-DSS TLS | Commenti disabilitati

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 vmca, vmug | Commenti disabilitati

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 startup | Commenti disabilitati