aggregazione rete - trunk switch - vmware

[dMajo]

Non so come tu operi, se ad esempio hai un altro pc collegato sullo switch per le configurazioni.
In ogni caso puoi:
1) non ricordo: se hai dei hp1910 che supportano funzioni base L3 abilitare le vlan e quindi il routing sullo switch; con gli hp1810 no
2) assegnare alla nic del pc un secondo ip sulla sottorete di una delle nic del nas (nella configurazione avanzata del ipv4)
3) infine ho detto "non necessariamente" quindi puoi anche lasciare ad esempio lo switch su 192.168.101.1/24 (sottorete della prima nic del nas)

Importante che tu provi a separare le 3 nic del nas ognuna nella sua sottorete, dal punto di vista dello storage non cambia nulla, tu hai 3 nic sul server con path 1:1 con le 3 nic del nas, non serve che siano tutte sulla stessa sottorete, basta che si vedano una ad una.

Non ho mai riscontrato problemi nell'universo windows, ma con il nas, che fondamentalmente è linux (OS che conosco solo discretamente ma non nei meandri più intimi) mi è capitato di avere diverse nic sulla stessa sottorete è quando indirizzavo un ip mi rispondeva l'altra nic rispetto alla configurazione fatta, come se gli ip venissero aggregati tutti sulla stessa nic .... me ne sono accorto analizzando l'attività sulle porte dello switch propio perche non mi tornavano alcuni numeri sulle prestazioni, non sono mai riuscito a capire perchè ... il problema si risolveva inserendo ognuna nella propria sottorete.
Devo anche dire che capito durante la prima sperimentazione del nas appena acquistato (e che posso aver anche sbagliato qualcosa da nubbio, anche se l'esperienza personale nel networking lo escluderebbe, comunque ...) durante i test per capire come configurarlo al meglio. Ora uso 3 nic aggregate sullo switch e la 4 porta sulla mirror del router a loggare il traffico in transito sulle wan, quindi il problema non si pone più.

[dMajo]

Un'altra considerazione che devi fare in previsione del HA è la banda della connessione heartbeat. Da li passa il traffico diagnostico delle due unità ma anche quello per tenere in sincronia la passiva con l'attiva. Non so se la sincronia venga fatta a livello di blocco o di file.

Ad ogni modo il rapporto 3:1 delle nic va sicuramente bene ad esempio nel caso le vm siano tutte web server ovvero macchine che accedano allo storage prevalentemente in lettura. Al contrario se fossero tutte file server o peggio ancora syslog o data logger in genere, dove l'attività principale è la scrittura/memorizzazione del dato la triplice banda in scrittura sullo storage rapportata a quella singola per la sincronia del cluster potrebbe far si che l'unità passiva non riesca mai a mettersi in sincronia. In questo caso dovresti forse considerare l'utilizzo di due nic singole per servire lo storage e due aggregate per la connessione heartbeat del cluster.

[cybermod]

scusate la lontananza, mi sono perso la notifica della risposta ed ho avuto un nodo con qualche problemi.

Confermo dMajo, l'heartbeat va considerato e come.

in realtà synology tiene sempre la sincronizzazione (per quanto ne abbia dedotto), però a discapito delle performance.
in pratica, se ho tre schede per l'iscsi e una per l'heartbeat, le performance verranno diminuite per stare dietro alla sincronizzazione.
inoltre, l'ha è piuttosto lento.

Sto seriamente rivalutando questo HA, piuttosto tengo delle replice, qualcosa mi studio insomma.
Devo capire bene il discorso di creare vlan dedicate per l'iscsi, e anche di ridistribuire bene il carico della rete sugli stessi switch.
In pratica, esempio mio che ho un 1810g-48 hp (48porte), sono ridistribuite in 4 gruppi da 12 porte l'una. Se affollo un gruppo, perdo anche in questo caso performance (effetto imbuto, come mi spiegavano in un altro forum).....

azz quanti parametri da considerare

Divento matto

[dMajo]

in realtà synology tiene sempre la sincronizzazione (per quanto ne abbia dedotto), però a discapito delle performance.
in pratica, se ho tre schede per l'iscsi e una per l'heartbeat, le performance verranno diminuite per stare dietro alla sincronizzazione.
inoltre, l'ha è piuttosto lento.
Sto seriamente rivalutando questo HA, piuttosto tengo delle replice, qualcosa mi studio insomma.

Si, a switchare sull'unità in stand-by ci mette parecchio. Come ti ho detto però, anche se devi metter mano alle vm per ritirarle su, è sempre un tempo infinitamente minore rispetto al recuperarle da qualche backup. Parliamo però di un notevole risparmio rispetto a san in fibrechannel.

Rispetto all'utilizzo dei due nas come unità indipendenti, una soluzione potrebbe essere, probabilmente sconsigliabile per prestazioni, quella di montare due lun dai due storage e far fare il mirroring al nodo, quindi al guasto di uno storage il mirror rimarrebbe su. Questo però raddoppierebbe il flusso dei dai sulle nic dei nodi in quanto accederebbero sempre ad entrambi i nas.

Devo capire bene il discorso di creare vlan dedicate per l'iscsi, e anche di ridistribuire bene il carico della rete sugli stessi switch.
In pratica, esempio mio che ho un 1810g-48 hp (48porte), sono ridistribuite in 4 gruppi da 12 porte l'una. Se affollo un gruppo, perdo anche in questo caso performance (effetto imbuto, come mi spiegavano in un altro forum).....

Il dato che devi guardare è la capacita di commutazione ("switching capacity") che per il G48 è di 104Gbps quindi (48+4spf)*2. Ciò significa le porte vanno in parallelo e lo switch è effettivamente in grado di commutare i dati su tutte le porte in contemporanea. Questa potrebbe esser la banda potenziale.

La banda effettiva è data invece dal "Throughput" ovvero la capacita di una data apparecchiatura di veicolare il dato dall'ingresso all'uscita. Se la precedente potrebbe in qualche modo dipendere dai media questa invece di solito dipende dai limiti del hardware (negli switch la larghezza del bus interno e la potenza della cpu che deve esaminare le intestazioni dei pacchetti, fare il lookup nelle proprie tabelle, risolvere la destinazione ed infine redirigere il dato alla porta giusta) e per il tuo si attesta a 77.4 mpps (milioni di pacchetti (generalmente 64byte) per secondo).
Come puoi vedere qui il parametro viene valutato in pps (pacchetti per secondo) in quanto è il frame che deve esser esaminato (per indirizzo sorgente/destinazione, protocollo, porta, servizio...) indipendentemente dalla quantità di dati utili (payload) che effettivamente trasporta. Così applicando la lunghezza minima del messaggio (64 byte) otteniamo 77.4mpps*64byte*8bit=ca 40Gbps. Se invece per lo stesso usiamo 1480 ecco che 77.4*1480*8 diverrebbero oltre 900Gbps, qui il limite ovviamente sarà quello fisico dato dalla somma delle porte quindi 104Gbps. Quindi lo switch a seconda del tipo di traffico potrebbe saturare la banda di tutte le porte introducendo solamente un po' di ritardo (latenza/jitter) dovuto al tempo di elaborazione del dato nel percorso ingresso/uscita.

Poi è vero che su switch importanti (tipo hp5400) normalmente le nic aggregate di un server vengono attestate su blocchi di porte distinti. Questo però perché i blocchi di porte sono attestati su schede modulari, sostituibili a caldo, e si vuole evitare il singolo punto di rottura.
Dell'effetto imbuto non sono a conoscenza. Forse se tu consideri un blocco di porte come switch assestante, gestito da un chipset comune con scarsa banda nei confronti del blocco/chipset successivo potrebbe accadere ... su prodotti SOHO non certo enterprise .... ripeto ipotizzo in quanto non sono a conoscenza del fenomeno.
Quello che so, un problema simile, ma non si tratta di porte o gruppi di porte, ma del switch nel suo complesso, è invece che in applicazioni multi client/server è sempre meglio usare uno switch dedicato piuttosto che quello integrato nei router soho. Qui le 4/6 porte, quando in gigabit, sono ampiamente sufficienti a gestire la banda della wan (ben che vada 100Mbps) ma insufficienti per capacita di switching e throughput a fornire le prestazioni del server ai client in gigabit.