This post is also available in: Inglese

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

Share

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.