Connettere una macchina virtuale attraverso un proxy

Vediamo oggi come configurare una VM, ospitata all’interno di un sistema operativo host Windows, in modo da poterla collegare ad Internet passando attraverso un proxy. Ad esempio questo è necessario in alcuni ambienti dove la navigazione su Internet è possibile solo attraverso un proxy, per motivi di policy interne di sicurezza (aziendale per esempio…). […]

Difficoltà articolo (0->10): 5

Requisiti: conoscenze minime di software di virtualizzazione lato desktop.

Vediamo oggi come configurare una VM, ospitata all’interno di un sistema operativo host Windows, in modo da poterla collegare ad Internet passando attraverso un proxy. Ad esempio questo è necessario in alcuni ambienti dove la navigazione su Internet è possibile solo attraverso un proxy, per motivi di policy interne di sicurezza (aziendale per esempio…). Ecco un’immagine della nostra semplice infrastruttura:

Test infrastructure
Infrastruttura

Innanzitutto il nostro test è stato eseguito facendo uso di VMware Player, anche se può essere applicato bene anche nel caso di altri software di virtualizzazione lato desktop (Oracle VirtualBox …). Importante è anche bene conoscere come funziona la parte della connettività con un ambiente virtuale, e questo è un requisito fondamentale per poter poi andare a configurare i parametri corretti. E’ un argomento lungo, e necessiterebbe di un articolo a parte, ma in rete si trovano decine di post dettagliati come questo:

http://www.carbonwind.net/Virtualization/VMware-Player-Networking-Options/VMware-Player-Networking-Options.htm

Dunque, dobbiamo identificare qual’è la scheda di rete connessa ad Internet, se già non lo sappiamo, e per far ciò possiamo utilizzare il comando ipconfig come in figura.

Comando ipconfig
Comando ipconfig

In questo caso ci sono 3 schede di rete, e quella connessa ad Internet è quella con label “Local Area Connection”. Da notare che l’installazione di VMware Player\Workstation comporta la creazione di almeno due nuove schede di rete virtuali, come visibile sempre in figura. La creazione di questi 2 adapter virtuali è necessaria per il corretto funzionamento delle connessioni virtuali della VM, come è spiegato in dettaglio al link sopra indicato. In breve, la scheda di rete VMnet1 è usata dalla VM nel caso in cui sia selezionata l’opzione “Bridged” (vedere più sotto), mentre la VMnet8 nel caso venga usata l’opzione “NAT”.

Dunque, andiamo alla sezione di configurazione delle connessioni di rete di Windows, come in figura.

Network connections
Network connections di Windows

Selezioniamo le proprietà della schede di rete connessa ad Internet (“Local Area Connection”).

All’interno della finestra delle proprietà spostiamoci nel tab “Sharing“, e mettiamo una spunta alla proprietà “Allow other network users to connect through this computer’s Internet connection” controllando che sotto “Home networking connection” sia specificata la scheda di rete VMnet8 (la scheda di rete usata dalla VM). In questo modo i pacchetti inviati dalla VM potranno essere inoltrati verso il proxy e la rete esterna passando dalla scheda di rete specificata (qui appunto la “Local Area Connection”).

Internet Connection Sharing
Internet Connection Sharing

Adesso dobbiamo configurare la scheda di rete della VM. Apriamo VMware Player e la configurazione della nostra VM, e posizioniamoci all’interno delle proprietà alla voce “Network Adapter“. Qui selezioniamo le voci come nella figura sottostante, abilitando “Connect at power on” (praticamente è l’analogo del collegamento del cavo di rete alla scheda di rete, virtuale in questo caso) e scegliendo “NAT“.
VMware networking configuration

L’ultimo step è quello di avviare la VM e di configurare il sistema operativo della VM (Windows, XP, 7, 8, Linux, …) per l’utilizzo del proxy (ovviamente dobbiamo conoscere indirizzo IP e porta del proxy da usare):

oppure possiamo configurare le singole applicazioni all’interno della VM (browser, chat, …) per l’accesso tramite proxy.

roghan

Sizing di un’infrastruttura server con VMware

Ho terminato la scrittura di un piccolo manuale in cui spiego come dimensionare un’infrastruttura di server/storage per passare da un ambiente fisico ad uno virtuale con VMware vSphere 4.1 (da poco è uscita la versione 5!). Dato che in Rete non ho trovato nessun documento per il dimensionamento della parte server (per la parte desktop invece ci sono alcune ottime guide) che sia leggibile e abbastanza immediato, me lo sono scritto da solo, in modo da poterlo usare come punto di riferimento :-). […]

Ho terminato la scrittura di un piccolo manuale in cui spiego come dimensionare un’infrastruttura di server/storage per passare da un ambiente fisico ad uno virtuale con VMware vSphere 4.1 (da poco è uscita la versione 5!).

matriosche

Dato che in Rete non ho trovato nessun documento per il dimensionamento della parte server (per la parte desktop invece  ci sono alcune ottime guide) che sia leggibile e abbastanza immediato, me lo sono scritto da solo, in modo da poterlo usare come punto di riferimento :-).  Anzi, in Rete ci sono tantissimi documenti che trattano l’argomento, e sono anche di gran lunga migliori del mio, ma spesso il loro problema è che sono troppo lunghi ed elaborati, risultando difficili da decifrare, con decine e decine di grafici, istogrammi, studi di performance, e 10000 tabelle. Di seguito riporto un estratto del manuale:

Vediamo una serie di best practices per progettare e dimensionare un’infrastruttura di server virtuali con VMware. I punti da tenere in considerazione durante la progettazione sono i seguenti (ordinati in base all’importanza):

  1. tipo di server (entry level, enterprise, …), al quale sono strettamente legati tutti i punti successivi, e l’espandibilità futura (scale-out e scale-up);
  2. RAM, l’elemento più critico che può limitare fortemente le VM e le loro performance all’interno dell’infrastruttura;
  3. CPU, in termini di numero di core, socket, e frequenza;
  4. storage, quantità dello spazio necessario e tecnologia usata;
  5. networking.

Il manuale è liberamente scaricabile dal link sottostante oppure dalla sezione Download, ed è la prima versione (spero presto di aggiornarlo con la nuova versione di vSphere 5, e di renderlo ancora più immediato da utilizzare ma anche completo di spiegazioni ed esempi).

DOWNLOAD del manuale (v1.1)

roghan

p.s.: se ti è piaciuto il mio manuale e reputi interessante il mio lavoro puoi offrirmi da bere… Grazie mille!!!
pulsante paypal

Cosa contiene il database di vCenter Server

In questo articolo verrà esaminato il database utilizzato da vCenter Server, per informare coloro che si chiedono quali dati memorizza o che non hanno mai controllato il suo contenuto ;-). Il database crea principalmente alcune tabelle per memorizzare dati relativi ad eventi, allarmi, informazioni su HA, DRS, sui nodi ESX/ESXi (statistiche, capacità dello storage, spazio libero, …), informazioni sulle VM e sui processi schedulati. […]

In questo articolo verrà esaminato il database utilizzato da vCenter Server, per informare coloro che si chiedono quali dati memorizza o che non hanno mai controllato il suo contenuto ;-). Il database crea principalmente alcune tabelle per memorizzare dati relativi ad eventi, allarmi, informazioni su HA, DRS, sui nodi ESX/ESXi (statistiche, capacità dello storage, spazio libero, …), informazioni sulle VM e sui processi schedulati.

what-is-database

Da notare che le configurazioni dei nodi e delle VM sono invece memorizzate sui singoli nodi, e sono solamente mostrate da vSphere Client al momento della connessione al vCenter Server. Infatti è possibile collegarsi direttamente ad uno dei nodi ESX/ESXi senza vCenter Center, e modificare le configurazioni. Al momento che un nodo viene aggiunto ad un datacenter, vengono lette tutte le informazioni dal nodo e aggiunte al database del vCenter Server. E’ importante ricordare che il database non è essenziale per il funzionamento dei nodi o delle VM, infatti continueranno a funzionare tranquillamente anche se vCenter Server o il suo database non dovessero essere più disponibili: non sarebbero più funzionanti DRS e vMotion, mentre HA continuerebbe a funzionare senza alcun problema. Qualora il database avesse un crash si potrebbe creare una sua nuova istanza, aggiungendo nuovamente gli ESX/ESXi al vCenter Server in modo da ripopolare le informazioni del database. In quest’ultimo caso gli unici dati persi sarebbero le varie statistiche, eventi, allarmi, resource pool, i processi schedulati, e poche altre informazioni non essenziali.

Per ulteriori informazioni consultare i seguenti link (è stato preso spunto dal primo link per questo articolo):

roghan

VMware HA e nodi isolati

Vedremo in questo post il comportamento di un cluster virtualizzato in cui è stata abilitata la funzionalità HA. Da ricordare che un cluster può essere configurato unicamente tramite un vCenter Server, che resta necessario per il corretto funzionamento di funzionalità quali vMotion e DRS, ma non per l’HA: se il vCenter Server si blocca o ha un guasto, l’HA è comunque garantita per tutti i nodi del cluster. […]

Vedremo in questo post il comportamento di un cluster virtualizzato con VMware in cui è stata abilitata la funzionalità HA. Da ricordare che un cluster può essere configurato unicamente tramite un vCenter Server, che resta necessario per il corretto funzionamento di funzionalità quali vMotion e DRS, ma non per l’HA: se il vCenter Server si blocca o ha un guasto, l’HA è comunque garantita per tutti i nodi del cluster.

ha_p2p
Interrogazione dei nodi in un cluster con HA

L’architettura di funzionamento su cui è basata l’HA è di tipo p2p, ossia ogni nodo effettua a intervalli regolari un ping verso ogni altro nodo del cluster e anche verso il gateway. I ping vengono effettuati dalla scheda di management di un nodo e verso la management di ogni altro nodo (Service Console nel caso di ESX e CLI di management per ESXi). Il funzionamento dell’HA è quindi strettamente legato al networking e alle schede di rete, e qualora la scheda di rete della management di un nodo si guasti il nodo stesso diventa isolato. Studiamo questo caso:

  1. ogni nodo controlla se ogni altro nodo è raggiungibile;
  2. se in un nodo si guasta la scheda di rete di management questo diventa isolato;
  3. di default, un nodo isolato spegne tutte le sua macchine virtuali.

Il comportamento di default potrebbe essere ragionevole nel caso in cui un nodo abbia schede di rete ridondate per la management, ma è in generale altamente consigliato cambiare l’impostazione default. Proviamo a immaginare cosa succederebbe se si guastasse uno switch fisico a cui sono collegati tutti i nodi e pure il gateway? Tutti i nodi risulterebbero isolati, con la conseguenza che ogni nodo spegnerebbe tutte le sue macchine virtuali! E’ una situazione assolutamente da evitare. Pertanto è necessario modificare l’impostazione host isolation response durante la configurazione del cluster, visibile alla schermata seguente:

ha_vcenter
Modificare impostazioni default

Riepilogando, è buona norma modificare il comportamento default di un cluster HA per quanto riguarda l’isolamento del nodo, ed inoltre è buona cosa ridondare la NIC di management.

roghan

[Virtualizzazione] Cluster in HA e Disaster Recovery

Sempre più diffusi sono i sistemi cluster, costituiti da gruppi di computer (tipicamente server) collegati tra loro ed in grado di lavorare insieme. Il sistema cluster minimo prevede l’utilizzo di due nodi collegati tra loro. Nello specifico esistono tre tipi di cluster:

* attivo/passivo, detto anche cluster in HA (High Availability), o anche cluster failover;
* attivo/attivo ad alte performance, o cluster di nodi che lavorano in parallelo;
* attivo/attivo con bilanciatore di carico (NLB, Network Load Balancing).

Il primo tipo di cluster viene anche definito HA (High Availability), e la sua funzionalità è quella di garantire sempre un determinato servizio. Tale servizio viene erogato dal computer attivo, ma qualora dovesse verificarsi un malfunzionamento, il sistema cluster provvederebbe ad avviare immediatamente uno degli altri nodi, che entrerebbe in sostituzione di quello appena guastato. Generalmente questo tipo di cluster adotta il supporto dei dischi di Quorum per condividere con tutti i nodi i dati precedentemente utilizzati dalla macchina che è andata in failure. Il secondo tipo di cluster è costituito da nodi che lavorano in parallelo per garantire elevate prestazioni. Ogni processo sottomesso al sistema cluster viene suddiviso tra le macchine che compongono il sistema. L’ultimo tipo di cluster è quello attivo/attivo, in cui tutti i nodi che lo compongono sono sempre attivi, e vi è un bilanciatore di carico che distribuisce le richieste al nodo meno occupato. […]

Sempre più diffusi sono i sistemi cluster, costituiti da gruppi di computer (tipicamente server) collegati tra loro ed in grado di lavorare insieme. Il sistema cluster minimo prevede l’utilizzo di due nodi collegati tra loro. Nello specifico esistono tre tipi di cluster:

  • attivo/passivo, detto anche cluster in HA (High Availability), o anche cluster failover;
  • attivo/attivo ad alte performance, o cluster di nodi che lavorano in parallelo;
  • attivo/attivo con bilanciatore di carico (NLB, Network Load Balancing).

Il primo tipo di cluster viene anche definito HA (High Availability), e la sua funzionalità è quella di garantire sempre un determinato servizio. Tale servizio viene erogato dal computer attivo, ma qualora dovesse verificarsi un malfunzionamento, il sistema cluster provvederebbe ad avviare immediatamente uno degli altri nodi, che entrerebbe in sostituzione di quello appena guastato. Generalmente questo tipo di cluster adotta il supporto dei dischi di Quorum per condividere con tutti i nodi i dati precedentemente utilizzati dalla macchina che è andata in failure. Il secondo tipo di cluster è costituito da nodi che lavorano in parallelo per garantire elevate prestazioni. Ogni processo sottomesso al sistema cluster viene suddiviso tra le macchine che compongono il sistema. L’ultimo tipo di cluster è quello attivo/attivo, in cui tutti i nodi che lo compongono sono sempre attivi, e vi è un bilanciatore di carico che distribuisce le richieste al nodo meno occupato.

I sistemi cluster sono fondamentali in un mondo in cui le persone vogliono sempre tutto e subito; sono fondamentali per molte aziende che devono rendere costantemente disponibili i propri servizi, e dove per costantemente si intende 24h su 24, tutti i giorni dell’anno! Ecco che entra in gioco il ruolo del cluster HA appena descritto, o meglio un insieme di più nodi organizzati in modo tale da offrire un servizio quanto più possibile continuo.laptop-fire L’errore che molto spesso viene fatto nelle aziende (ho saputo di casi reali avvenuti a clienti dell’azienda in cui lavoro :-(!), è quello di acquistare come nodo primario un sistema ultra-veloce, come potrebbe essere una Ferrari, ed adoperare invece come nodo secondario un vecchio computer, paragonabile ad una memorabile Panda. Mai commettere questo errore! In caso di disaster recovery il sistema super-veloce smetterebbe di funzionare, e tutte le richieste verrebbero dunque inoltrate al secondo nodo, la vecchia Panda: siamo sicuri che la Pandina una volta entrata in funzione sia in grado di gestire tutto il carico in arrivo? Molto spesso infatti il secondo nodo non è in grado di supportare neppure metà dei servizi di quello principale, con il risultato che tutto il sistema si potrebbe bloccare dopo non molto.

Pertanto, la soluzione migliore è di configurare il cluster con nodi tutti identici. Nel caso dell’esempio precedente la soluzione è di usare due belle BMW in grado di raggiungere buone prestazioni, anche se inferiori alla Ferrari, ma prestazioni sicuramente costanti (con e senza failover)!

Inoltre, un altro errore molto diffuso nelle aziende è quello di non simulare mai un disaster recovery, un po’ come avviene per i dati di backup. Quanti di voi controllano che i dati appena salvati sia coerenti e privi di errori?? Quindi, prevenire piuttosto che curare, e pianificare con attenzione ogni scelta da fare!

Alla prossima…

Matteo