+
SharePoint ed il mondo dei Load Balancer
Pubblicato il: 15/09/2012
Da: Igor Macori
Lingua: Italiano
Livello: 200

Perché bilanciare?

La maggior parte delle infrastrutture SharePoint che mi è capitato e mi capita di implementare per i clienti (parlo di esperienze su SharePoint 2001/2003/2007/2010/2013) è spesso composta da almeno due Web Front-End (WFE).

Questo sia per ragioni di bilanciamento di carico, e quindi incremento delle prestazioni, che per porre in alta affidabilità quantomeno i servizi di WFE, facendo sì che se anche uno dei due server dovesse “esplodere” almeno l’altro possa continuare a rispondere, dando continuità al servizio e consentendo agli utenti di navigare il portale e accedere a contenuti e documenti.

E’ così che si compone la forma classica della SharePoint Farm, composta da una topologia di 2 o 3 server, dove l’eventuale terzo server si “specializza” nell’erogare ruoli applicativi (seppur spesso considerati meno critici, come ad esempio il crawler del motore di ricerca, e quindi non in alta affidabilità).

Topologia Farm

Nella stragrande maggioranza dei casi viene implementato il servizio NLB (Network Load Balancing), nativo su Windows Server, per gestire la composizione del “cluster” di bilanciamento di carico.

Il servizio NLB è croce e delizia per molti sistemisti. Il suo principale vantaggio è quello del costo: è compreso nel prezzo di Windows Server, quindi virtualmente gratis.

Ma quali sono le caratteristiche (ed i difetti)?

  • Multicast o Unicast?
    A questa domanda alcuni sistemisti cominciano a fare lo sguardo del pesce lesso… suggerisco di dare un’occhiata a questo articolo: http://support.microsoft.com/kb/291786 e questo video.
  • Ve lo ricordate lo stack ISO/OSI?
    NLB opera sul layer 3, ossia quello di rete. Di conseguenza se uno dei tuoi WFE è acceso, con il cavo di rete attaccato allo switch, ma IIS è (per assurdo) stoppato… per NLB sarà tutto OK, e continuerà allegramente a distribuire le richieste dei client anche verso quel nodo… client che ovviamente cercando di navigare il portale riceveranno un bell’errore!
  • Performance e affinità
    NLB è un servizio molto “basic”, senza quindi logiche applicative o meccanismi orientati all’incremento delle performance (ad es. cache). E’ un po’ un “passacarte”.
    E’ tuttavia possibile attivare le logiche di affinity, che tenderanno a portare un certo client (IP) sempre verso lo stesso WFE. I benefici sono molteplici, sia di natura applicativa (le sessioni) che di materia prestazionale (SharePoint sfrutta molto le logiche di cache sui WFE, e se un client venisse fatto saltare da un WFE all’altro… si perderebbero parte dei benefici legati alle risorse in cache prodotte dalla navigazione precedente).
    Per sfruttare al meglio questo fattore ti suggerisco di verificare che l’affinità sia attiva e di configurarla per allungarne la durata (se non hai specifiche criticità applicative, anche 20 minuti al posto del default, che è 20 secondi).

Ma ci sono alternative?

Naturalmente sì, anche se parliamo di soluzioni “non comprese nel prezzo”, e che quindi comporteranno qualche acquisto da fare.

Non vorrei scrivere qui un elenco di prodotti, che risulterebbe sicuramente non esaustivo e potrebbe far risentire qualche produttore. Tuttavia posso descrivere la mia esperienza principale con soluzioni di load balancing alternative a NLB.

In un paio di casi (parlo di siti Web pubblici) è stato fornito un servizio di bilanciamento utilizzando Microsoft TMG, che è in grado di fare anche questo tipo di mestiere… anche se non risolve tutti i difetti descritti.

Il salto di qualità lo ottieni salendo di livello, e passando dal livello 3 dell’ISO/OSI a layer 7.
Il layer 7 è quello applicativo (ricordi l’ABC delle reti?), e significa far sì che il dispositivo di bilanciamento sia in grado di “accorgersi” del reale stato di salute (e di risposta) della Web Application SharePoint. Indirizzando le richieste verso un nodo WFE solo quando è certo che quest’ultimo possa rispondere.

Si tratta sia di prodotti “server” che, spesso, di moduli “appliance” dedicati.

La soluzione che spesso trovi anche implementata negli scenari (quelli complessi) descritti sui case studies o sulla documentazione Microsoft fa ricorso a F5.
F5 rappresenta una famiglia di bilanciatori di fascia alta (come prestazioni e come prezzo), che puoi implementare sia per scenari di bilanciamento locale (due o più WFE in rete locale tra loro) e geografico (dove i WFE sono su reti diverse, come nei casi di Disaster Recovery geografico).
Per maggiori informazioni sui prodotti F5, clicca qui.

Altri prodotti per il bilanciamento che mi è capitato di utilizzare sono quelli di Juniper Networks, che offrono anche logiche di WAN accelerator e secure publishing. Per maggiori informazioni.

Infine, ma sottolineo che non si tratta di una recensione di prodotto, né di una lista esaustiva, mi è capitato di lavorare con Barracuda Load Balancer, anche questo, come Juniper, una buona combinazione prezzo/prestazioni. Per maggiori informazioni visita il sito.

Tags


Destinatari


Prodotti

Microsoft SharePoint Server 2010
SharePoint Foundation 2010
SharePoint Server 2013
Microsoft Office SharePoint Server 2007



Bookmark and Share