Reading Time: 3 minutes

Qualche giorno fa Microsoft ha annunciato alcuni cambiamenti nelle sue certificazioni oltre che all’introduzione di nuovi percorsi sui nuovi prodotti.

Tra i nuovi percorsi, in ambito virtualizzazione e cloud, c’è da segnalare la nuova certificazione MCSE: Private Cloud. I requisiti per conseguirla sono:

  • conseguire la certificazione MCSA: Windows Server 2008
  • passare l’Exam 247: Configuring and Deploying a Private Cloud with System Center 2012 (Until January 31, 2013, Exam 70-659 may be taken in place of 70-247)
  • passare l’Exam 246: Monitoring and Operating a Private Cloud with System Center 2012

Note The Private Cloud certification requires candidates to show continued ability to perform in this technology area by completing a recertification exam every three years.

Per quanto riguarda invece i cambiamenti relative alle certificazioni, si può notare la re-introduzione di vecche sigle, ora con nuovi significati, ma in sostanza equiparabili a quelli vecchi: MCSA e MCSE sono tornati (gli ultimi erano riferiti a Windows Server 2003). Per maggiori informazioni sulle nuove certificazioni è possibile consultare la pagina relativa alle certificazioni Microsoft.

continue reading…

Reading Time: 2 minutes

Benché ancora non sia arrivata alcuna conferma ufficiale via email, sembra che anche per quest’anno sono stato confermato come vExpert. O quanto meno appaio nella lista pubblicata sul sito: Announcing vExpert 2012 title holders.

Considerando i cambiamenti nel programma vExpert di quest’anno e che ho provato il percorso “Evangelist” (probabilmente quello più “gettonato” e dove veramente ci sono dei grandi evangelist) posso solo essere enormemente onorato di questa conferma. E’ passato meno di un anno dall’ultimo vExpert 2011, ma in realtà mi sembrano passati solo pochi giorni.

continue reading…

Reading Time: 4 minutes

Come scritto nel post precedente, l’interfaccia web di gestione è costruita tutta attorno alle funzionalità di load balacer di questo appliance. Ma molti dei termini e concetti rimangono comunque comuni a tutte le soluzioni di questo tipo:

  • Virtual Services (VS): è l’IP virtuale o VIP (o la coppia di IP e porta) per un specifico servizio “virtuale” che sarà gestito dal load balancer (in questo contesto virtuale è usato proprio nell’accezzione di non reale).
  • Real Server (RS): sono i server (fisici o virtuali) che ospitano i servizi a cui saranno redirette le richieste dirette al VIP.
  • Forwarding method: il modo con il quale i pacchetti passano dal VIP e vengono consegnati ai RS. VLM supporta NAT oppure Direct Server Route (DSR) a livello 4, mentre a livello 7 supporta solo il NAT.
  • Scheduling method: sono gli algoritmi con cui le connessioni vengono distribuite sui vari real server. VLM dispone di veramente tanti medodi diversi (LoadMaster Installation & Configuration Guide a pag. 18-19), alcuni decisamente initeressanti e inusuali (come ad esempio l’Agent Based Adaptive Balancing). Da notare che i metodi implementabili da Linux Virtual Server sono invece solo un sotto-insieme di questi.
  • Persistence: come è possibile mantenere i concetti di sessione e/o stato mandanendo sempre costante l’accoppiata client e real server (ovviamente solo quando veramente vi è bisogno, come ad esempio nelle connessioni https connections). In altri sistemi di load balancing (come ad esempio Linux Virtual Server) questo aspetto è di solito un vero punto debole, dati i limitati metodi per garantire la persistenza. VLM dispone di varie soluzioni (LoadMaster Installation & Configuration Guide a pag. 21-25) incluse soluzioni specifiche per Layer 7 Persistence.

La configurazione di un nuovo virtual service è veramente semplice e buona parte delle impostazioni di default sono già corrette o sufficientemente buone: spesso basta specificare un IP virtuale e una porta e il gioco è fatto. Volendo è possibile specificare il tipo di servizio (HTTP/HTTPS, generic, STARTTLS o Termina Server), ma questo viene normalmente individuato automaticamente. A questo punto è possibile aggiungere i vari real server specificandone l’IP, la port, il forward method e il “peso” (usato in alcuni particolari scheduling method). Da notare che la parte di controllo dello stato del server e/o del servizio (su questo si possono fare vari tipi di test) è globale per tutti i real server.

SSL Offload, L7 load balancing e tanti altri non sono altro che opzioni varie nella configurazione di un virtual service. Da notare che la parte di persistence e le varie opzioni di scheduler sono comuni sia usando il L7 che il L4 (abilitato nel momento in cui si disabilita il L7).

Interessante il fatto che si possa configurare il load balancer in una configurazione one-armed senza bisogno di configurazioni particolari lato Real Server (chi ha mai provato as usare Linux Virtual Server con il Direct Route sa i vari problemi legati all’interfaccia non arpable…).

Ho provado ad esempio una configurazione con load balancer nella stesse rete dei real server e con IP virtuali anch’essi nella stessa rete: tutto ha funzionato egregiamente sia da client della stesse rete, che da client esterni e passando attraverso regole di NAT verso gli IP virtuali (in questo caso però ho dovuto togliere la funzione L7 Transparency).

In realtà usando il L4 e la modalità di forward DSR occorre comunque seguire delle regole particolari (esattamente come in Linux Virtual Server con il Direct Route): The VIP address on a Real Servers must be configured so that the server does not respond to arp requests on the VIP address. Vedere LoadMaster Installation & Configuration Guide a pag. 137-147.

Conclusioni

Strumento molto completo e potente, sufficientemente intuitivo che si rivela essere un’ottima soluzione come load balancer. Molto apprezzabile il ridotto footprint, la semplicità dell’appliance, la sua velocità. Peccato per la mancaza di VMware Tools (e Integration Services in Hyper-V).

Benché disponga di funzioni di filtraggio e soprattutto di proxy-cache, non va a sostituirsi a prodotti di questo tipo, visto che rimangono comunque limitate (e integrate) alle funzioni di load balancing.

Post precedenti

Reading Time: 4 minutes

Come già scritto nel post precedente, VLM dispone di 2 vNIC perché sono previsti due scenari differenti di topologie di rete (per maggiori dettagli vedere, in inglese, la LoadMaster Installation & Configuration Guide a pag. 12-13): one-armed (equivalente ad un firewall di tipo bastion host) o two-armed (equivalente ad un firewall dual-homed).

Guardando le configurazioni si potrebbe pensare che la prima implementa solo il Direct Server Return (DSR) method (e in effetti per Linux Virtual Server è l’unica prevista per il direct routing) e la seconda solo il metodo NAT (e in effetti per Linux Virtual Server è l’unica prevista peri il NAT). Ma in realtà in KEMP i metodi non sono strettamente correlati dal tipo di topologia di rete. L’unico vero vincolo è usare il NAT se si utilizza il load balacing a livello 7.

Il primo passo per configurare l’appliance è collegarsi via web o via console ed usare le credenziali di defaul (bal/1fourall). Entrambe le schede di rete possono essere usate (successivamente è possibile forzare la gestione solo su una scheda) e in teoria entrambe dovrebbero usare il DHCP per autoconfigurarsi, ma nel mio caso non è successo (l’IP di default dell’eth0 è 192.168.1.101). Ho quindi optato per la configurazione via console abbastanza veloce ed intuitiva tramite il Quick Setup.

Una nota sulla configurazione della rete: in teoria VLM supporta sia il formato four-octet (tipo 255.255.255.0 per una Class C) o il formato  CIDR (tipo /24 per una Class C). Nel mio caso solo il formato CIDR ha funzionato, l’altro veniva accettato ma non configurava correttamente la rete (e in effetti poi non accettava il default gateway).

A questo punto è possibile collegarsi all’interfaccia di gestione via web (notare che non sarà disponibile fintanto che la password standard non sarà stata cambiata).

L’interfaccia è sufficientemente intuitiva e funzionale con una pagina di statistiche che riassume efficacemente sia alcuni contantori che lo stato dei servizi e dei server.

Come si nota dalle voci nei menu, tutta l’interfaccia di gestione è progettata attorno alla funzione di load balancing mettendo in evidenza i server virtuali e quelli reali (con i relativi servizi). Tutte le altre funzioni non sono altro che opzioni o sottomenu.

Il manuale è sufficientemente dettagliato, ma esiste anche un help contestuale (che però non ho trovato troppo intuitivo), sotto forma di tool-tip visualizzabile lasciando il mouse per qualche secondo sull’opzione:

HA Configuration

Come discusso nel post precedente, la presenza di 2 vCPU non rende possibile l’uso di VMware FT per una soluzione ad altra disponibilità (in realtà ho provato ad abbassare ad una sola vCPU e non riscontrato problemi, ma ovviamente in situazioni di alto carico e tanti servizi attivi si potrebbero verificare rallentamenti). Sono comunque previste delle specifiche configurazioni (come anche spiegato nel LoadMaster Installation & Configuration Guide a pag. 14-17), a seconda delle topologie di rete, per disporre di una configurazione “clusterizzata” di tipo attivo/standby. In casi semplici non è strettamente necessario, considerando anche che il tempo di avvio dell’appliance è molto ridotto e quindi potrebbe essere persino sufficiente VMware HA (o il restart delle VM in Hyper-V).

Reading Time: 4 minutes

KEMP Virtual LoadMaster (VLM) è disponibile in tre diversi formati: uno per Microsoft Hyper-V (che è un file zip con tutti i file che compongono la VM) e due per VMware (uno per vSphere e uno per Workstation). Tutti sono decisamente piccoli (meno di 40MB), quindi veramente veloci da scaricare e distribuire.

Ho scelto di provare la versione per vSphere, distribuita nel formato OFV (in realtà il file zip contiene l’OVF e un VMDK). Veramente veloce da installare (benché la scelta di un singolo file non zippato sarebbe stata la scelta ottimale).

Sul sito sono descritti i primi 3 passi fondamentali per attivare l’appliace. Si parte dallo Step 1 che è semplicemente quello di scaricare il software dal virtual-loadbalancer download site, scegliendo ovviamente la piattaforma utilizzata:

Lo Step 2 dipende dal tipo di formato scelto, ma di fatto consisten nel fare un deploy della VM e di accenderla. Dalla documentazione il VLM dovrebbe ottenere la configurazione di rete via DHCP (ma stanamente nel mio caso non ha funzionato, anche su reti diverse, forse un qualche limite legato a vSphere 5?) oppure con il suo IP di default 192.168.1.101 (oppure configurandolo a mano successivamente). A questo punto è possibile accedere o via web all’URL https://IP o tramite la vSphere Console. La prima richiesta sarà l’insierimento di una licenza valida e la visualizzazione dell’Access Code (necessario per procedere allo Step 3).

Lo Step 3 prevede l’ottenimento della licenza, anche per un utilizzo in trial mode. La licenza è generata tramite una form che richiede l’Access Code. Questo è evidentemente generato su caratteristiche peculiari del virtual appliance (sicuramente i vNIC MAC Address che non possono essere cambiati). Non pare essere invece rilevante la versione di virtual hardware, visto che anche aggiornandola alla v8 l’appliance continua a funzionare perfettamente.

A questo punto sarà necessario procedere alla configurazione dell’appliance e primi step sono descritti nella Quick start guide (che include anche user e the password di default). Notare che la guida descrive anche configurazione degli appliance fisici (quindi non tutto è applicabile ad un appliance virtuale).

Riguardo alla VM è uan versione modificata di una Ubuntu Linux a 32 bit (o almeno così viene riportato nel tipo di OS, che però potrebbe non essere significativo) con 1 GB di vRAM (l’uso può variare a seconda dei servizi) e 2 vCPU (questa scelta limita l’uso ad esempio di VMware FT, ma in realtà esistono configurazioni specifiche per ambienti di HA). Per quanto riguarda il disco, è previsto un vmdk da 512 MB in formato thin veramente molto compatto (basta guarda lo spazio usato e togliere 1 GB che è rappresentato dal VM swap file). Per quanto riguarda il virtual networking vi sono 2 vNIC per due tipi di scenario diversi (descritti nel post successivo).

Da notare che le VMware Tools non sono installate e/o configurare e questa è una grande (a mio parere) pecca. Ad esempio la procedura di shutdown può essere fatta solo da interfaccia web e pare persino che non faccia uno shutdown completo (visto che poi la VM va spenta da vSphere Client). Forse la scelta è dettata da risparmiare spazio o avere un’immagine unica…

Una curiosità che ho notato durante le varie prove di riavvio / shutdown… il browser rimane comunque autenticato anche dopo un’interruzione… sembra quindi che i dati autenticazione siano memorizzati in cookie e/o variabili di sessione permanenti.

Per informazioni generali su KEMP LoadMaster vedere il post precedente.

Reading Time: 4 minutes

KEMP’s LoadMaster è una famiglia di appliance specifici per le funzioni di load balancer con diverse funzioni interessanti:

  • Server Load Balancing for TCP/UDP based protocols
  • NAT-based forwarding or Direct Server Return (DSR) configurations
  • Layers 4-7 Load Balancing
  • Layer 7 Content Switching
  • Server Persistence
  • Windows Terminal Services load balancing and persistence with Session Directory integration
  • SSL Termination/Offload/Acceleration
  • Application Front-end (Caching, Compression and IPS security)
  • Advanced, App-Transparent Caching Engine for HTTP/HTTPS protocols
  • Optimized Compression for Static and Dynamic HTTP/HTTPS Content
  • Layer 7 Intrusion Prevention System (IPS), SNORT-Rule (HTTP) Compatible
  • Configurable S-NAT support
  • Web User Interface (WUI) for easy administration & configuration
  • Industry leading price/performance value
  • Supports cloning and relocating with native Virtualization Framework management tools

KEMP LoadMaster è un appliance basato su un Linux modificato (e sottoposto ad hardening) che sfutta in parte Linux Virtual Server per il load balancing, ma poi implementa diversi demoni per te diverse funzioni, quali il proxy, Layer 7 operations, IDS, …

L’appliance è disponibile sia in versione fisica che in versione virtuale (per meggiori informazioni vedere la scheda di confronto). Nella verisone virtuale esitono due edizioni che si differenziano in base al carico massimo:

  • VLM-100: Max. 100 Mbps Throughput, max. 100 SSL TPS, everything else unrestricted. Actual performance will depend on allocated resources to Virtual Machine.
  • VLM-1000: Up to 1000 SSL TPS, everything else unrestricted. Actual performance will depend on allocated resources to Virtual Machine.

Da notare che esistono numerosi distributori di questi prodotti, ma in alcuni casi persino i grossi vendor di hardware li includono nei propri cataloghi (ad esempio vedere questa pagina nell’area accessori di Dell… non è che magari sarà uno dei prossimi acquisti?)

Perché servono i load balancer?

In ambiente enterprise diventa sempre più frequente usare soluzioni di load balancer per definire architettura ad alta disponibilità (o anche ad elevata scalabilità). Benché esistano a volte soluzioni integrate nel sistema operativi (ad esempio Microsoft NLB), spesso si preferisce l’uso di soluzioni esterne, anche per una questione di semplicità e “pulizia”.

Per citare alcuni esempi di servizi che richiedono soluzioni di load balancer:

  • VMware View: richiede dei load balancer sia per gestire il pool di Security Servers sia per quello dei View Connection Servers
  • Exchange: richiede un load balancer per alcuni ruoli, in particolare per quello CAS
  • Pool di Terminal Server/RDS Host: benché sia possibile usare la soluzione Windows (NLB), spesso si preferisce usare load balancer esterni.

Perché KEMP?

Visto che già esistono tante soluzioni (o che volendo si possono costruire a partire da una distribuzione Linux), ci si potrebbe chiedere perché scegliere le soluzioni di KEML. Soprattuto nel caso delle soluzioni basate su virtual appliance, dove in effetti vi sono tanti altri VA già pronti e simili (alcuni anche free) e volendo vi sono anche le soluzioni di VMware (vShield Zones /vShied Edge).

Una possibile ragione è che la maggior parte delle soluzioni esistenti sono più orientate alla pare di firewall (incluse le soluzioni vShield citate in precedenza), con funzioni invece spesso molto limitate nella parte load balancing. D’altro canto VLM è orientato prevalentemente sulla parte load balancing, includendo tra l’altro diversi documenti e raccomandazioni di come configurare i diversi servizi rendendolo quindi una scelta naturale e spesso vincente (ad esempio,vedere questa valutazione di soluzioni per Exchange: Differences in Exchange Load Balancing recommendations by Microsoft and vendors).

Le altre funzioni di VLM (come SSL acceleration, proxy, application check and protection) spess0 sono sono il giusto (e a volte necessario) complemento della parte di load balancer, rendendo questo strumento molto completo.

Per concludere c’è anche l’aspetto legato alla piattaforma: al momento KEMP è uno dei pochi a supportare sia VMware che Hyper-V, e questo può essere sicuramente un vantaggio per chi gestisce o tratta ambienti multi-hypervisor.

Reading Time: 2 minutes

Come scritto un post precedente, un possibile criterio per valutare la bontà di una certificazione IT è compararla con la reale richiesta che potrebbe avere nel mercato IT. Forse può sembrare un approccio troppo materiale, ma in realtà otterene una buona certificazione e poi non aver modo di metterla in pratica è decisamente controproducente (come già scritto, le certificazioni vanno considerate come dei continui percorsi, mai come singoli obiettivi fini a sé stessi). La pratica e l’esperienza nel mondo IT sono probabilmente il valore maggiore ed è quindi opportuno considerare anche questi aspetti.

Normalmente la richiesta (e l’offerta) sono legati al tipo di salari: se sono alti, spesso significa tanta richiesta e probabilmente un numero di persone disponibili inferiori a quelle necessarie… o semplicemente una posizione valuta realmente per quel valore.

continue reading…

© 2025-2011 vInfrastructure Blog | Disclaimer & Copyright