cybermod ha scritto:Quindi, questo tipo di soluzione serve più che altro perchè ho due storage condivisi e 3 nodi che vi accedono in contemporanea, non è che realmente aumento la banda passante?
Si e no. Un esempio due nodi in lan un webserver con 4 nic aggregate e un client con 4 nic aggregate:
- quando il client accede al server come file server per copiarvi un file con programmi non in grado di creare sessioni multiple es il copy del dos su unità mappata non avrai vantaggi: unica sessione quindi un 1Gb usato e gli altri tre morti in standby. Tutti i pacchetti vengono instradati sempre sulla stessa connessione in modo da non generare problemi di ordinamento dei pacchetti, molto più pesante da gestire in termini di performance.
- per i stessi due nodi però quando un browser del client accede al web server, scaricata la prima ossatura della pagina (il codice html), poi crea sessioni multiple per scaricare ogni filmato, foto e altro elemento componente la pagina (es l'argomento src e/o href di molti tag html). Tutte queste sessioni contemporanee fra i due ip verranno bilanciate nella connessione aggregata sfruttando tutti i canali quindi si avrà un incremento di banda tuttavia ogni singola sessione non potrà eccedere il 1Gb, limite del singolo canale.
Quindi la risposta è: dipende da come l'iscsi con multipath gestisce la comunicazione. Occhio che esiste sia il multipath (MPIO) che il MC/S (Multiple Connections per Session) verifica quale dei due è più adatto al tuo scopo.
Le connessioni multiple da singola sessione vanno abilitate anche sul nas nella configurazione del target.
cybermod ha scritto:
(sempre che tu non voglia usarli in HA: anche il nas può essere un single point of failure),
assolutamente d'accordo con te, infatti nel progetto su carta i synology hanno due volumi ognuno, uno di produzione e uno di replica (si incrociano, e lavorano entrambi)
L'HA dei nas non è attivo-attivo ma attivo-passivo ... quindi non c'è bilanciamento di carico, ma al guasto del attivo il passivo subentra al suo posto (con lo stesso ip ovviamente).
Il fatto di avere le vm distribuite sui due nas sicuramente ne bilancerà il carico (devi però valutare anche l'impatto delle repliche incrociate fra i due se frequenti e come gestirle). Il SO del nas è in grado di fare backup/snapshot delle lun sia locale che su altro nas, ma nel secondo caso credo che il nas ricevente debba esser configurato come target di backup e non credo quindi tu le possa fare incrociate.
cybermod ha scritto:negli switch configura i trunk verso i nas in LACP. Ovviamente dovresti creare anche un terzo trunk (statico questa volta) fra i due switch con almeno 2(meglio 4) porte altrimenti i client di uno switch che accedono al nas sull'altro avranno il collo di bottiglia della singola connessione fra gli switch.
Mica tanto ovviamente.... avevo il sospetto di una cosa del genere, ma non ne ero sicuro. Però ho dei dubbi e te li pongo: non ho client che si collegano a questi due switch, essi sono dedicati solo ed unicamente per la parte storage. Quindi vi si collegheranno gli storage stessi e i nodi di vmware (sia i vKernel Switch per ISCSI che i vKernel per la gestione di vMotion etc etc).
La parte di produzione si appoggia ad un altro switch core con i vari rilanci in fibra per i building.
che dici, devo implementare lo stesso questo tipo di collegamento tra gli switch?
In datacenter è sicuramente corretto avere la san fisicamente indipendente dalla lan sia per motivi di sicurezza che di performances (evitando cosi tutto il traffico multicast/broadcast dei client). Credo però che in un ambiente modesto con budget limitato la stessa cosa possa esser ottenuta creando una VLAN per la san che allo stesso modo isolerà i domini broadcast/multicast.
Semplificando la configurazione poniamo un nas con le sue 4 nic collegate ai due switch (2 ciascuno) e alla pari un virtualizzatore con 4 nic (2 per switch). Con il multipath configurato per 4 ip del target il host dovrebbe gestire il load-balancing e le nic non andrebbero aggregate, avremmo 4 subnet e sfrutteremo tutta la banda delle 4 connessioni cosi formate
senza bisogno di trunk fra i due switch (che comunque non hanno nessuna controindicazione).
L'aggregazione (delle 4 coppie cosi formate: 2 nas 2 server) in questo caso potenzialmente dimezzerebbe la banda: il server probabilmente creerebbe solo due connessioni verso i due ip del target rendendo così utilizzabile solo un canale della singola aggregazione e demandando all'altro il solo compito di failover, il load-balancing dei due canali aggregati non si realizzerebbe. Qui credo ti serva il MC/S con connessioni multiple pari al numero delle nic.
Se però a questa configurazione aggiungiamo un secondo virtualizzatore il fatto di aver spezzato il load balancing a meta fra server (i multipath) e switch (gestione delle aggregazioni) garantirebbe a ciascuno dei nodi virtualizzatori sempre il 50% della banda totale del nas.
Con l'aggiunta il terzo nodo (2 nic per nodo viste le 4 totali del nas) l'aggregazione pur penalizzando le performance massime del singolo nodo (nel caso anche questo abbia 4 nic) probabilmente garantirebbe una più equa distribuzione delle risorse del nas ai tre nodi( fra 25 e 50% ciascuno). Con due nas le 4 nic per nodo farebbero di nuovo la differenza sempre che lo storage delle vm sia equamente distribuito su di essi.
Queste però sono considerazioni fatte dal punto di vista del networking non conoscendo nello specifico le opzioni di configurazione di VMWare che potrebbero dipendere anche dai servizi in esecuzione nelle varie VM ed il loro carico di IO.
Non so se il cluster VMWare abbia qualche gestione centralizzata della banda dei nodi rispetto allo storage condiviso nel qual caso sarebbe probabilmente meglio evitare del tutto l'aggregazione in ogni caso .... che fra le altre cose (LACP) e dinamica, basata su un protocollo di continuo monitoraggio delle linee e di conseguenza genera anche un minimo di traffico di per se.
Dando un occhiata al sito ufficiale ho notato che anche li hai un paio di guide su MPIO e MC/S
Quante nic hai su ogni nodo vmware e come pensavi ripartirle fra storage e lan?
I 90MB corrispondono quasi alla saturazione della singola nic da 1G. Potresti eventualmente aumentare la MTU a 9000 (Jumbo Frame) per aumentare il payload del pacchetto ricordando che in una subnet tutti i partecipanti devono supportarlo.
