aggregazione rete - trunk switch - vmware

[cybermod]

mi faccio un up, mi avete dimenticato?

[stefanox]

mi faccio un up, mi avete dimenticato?

Personalmente mi stò godendo questa discussione.... uppo anch'io [popcorn]

[cybermod]

in che senso stefanox, sei anche tu interessato al discorso?

Se vuoi, appena so qualcosa di più (anche da altri forum) ti tengo informato. Ho anche cominciato ad eseguire qualche test di performance

ciao

[dMajo]

Presumo che vmware come concetti cluster sia simile a hyperv. L'HA non è attivo/passivo perché è in realtà un cluster di nodi (ferri) che ospitano le VM con storage esterno (su san), e funziona già da due. E ovvio che più ne hai e "minore" è l'investimento nel ferro ... nel senso che con 2 entrambi i server devono esser dimensionati per poter sostenere tutte le VM. Con ad esempio 10 nodi, che eseguano 9 VM (richiedenti pari risorse) ciascuno, se uno si guastasse i rimanenti si ritroverebbero a dover eseguire soltanto una VM in più ... quindi basta sovradimensionarli del 10% (rispetto al 100% nel caso di 2) oppure accettare la pari perdita di performances sino alla riparazione del guasto. Le VM vengono rese disponibili quasi istantaneamente sul nuovo nodo proprio perché lo storage che usano è esterno quindi rimane sempre la stessa VM ad accedere allo stesso storage, cambia solo il nodo di provenienza. Il carico è così per definizione bilanciato sui vari nodi.

Nel caso del Syno (che giustamente vuoi ridondato l'HA è attivi/passivo ovvero l'unità passiva rimane in sincronia con quella attiva pronta a subentrarvi (prendendone gli ip) in caso di guasto, quindi non c'è bilanciamento di carico. Questo è quello che trovi servito dalle funzioni del sistema operativo. Altrimenti dovresti usare i due nas come unità indipendenti distribuendo tu equamente le lun dello storage sui due e gestire tu la loro coppia sincronizzata sui nas incrociati. Qui avresti tutte le nic a disposizione (l'HA ne richiede una o più (possono esser aggregate) dedicate al heartbeat e sincronia), avresti un effettivo bilanciamento del carico dell lun sui nas, ma bisognerebbe poi sommarvi il traffico (e carico) delle sincronie incrociate (oltre alla maggiore complessità di gestione) e vedere se alla fine risulti davvero vantaggioso in termini di performances.
La seconda ipotesi, dove le vm al guastarsi di uno storage passano all'altro (nel frattempo mantenuto sincrono) nello spazio di un ping, esiste ma a differenza di un paio di migliaia di euro fra nas e dischi costerebbe diverse decine di migliaia.

La cosa strana è che, usando tre schede di rete delle diskstation, due sullo switch1 e 1 sullo switch2, avevo performance minori che usandone solo due (!).

solo due: sempre una per switch o entrmbe sullo stesso sw?

Stessa cosa se tutte le schede di rete appoggiavano sulo stesso switch.... c'è qualcosa che mi sfugge?

Stessa cosa: nel senso che le performance erano sempre minori con 3 nic sullo stesso switch o così va?

Di che performance (transfer rate) stiamo parlando?
Quanti nodi?
Potresti postare le configurazioni delle nic dei nas e dei server e loro collegamenti agli switch?

[cybermod]

Presumo che vmware come concetti cluster sia simile a hyperv. L'HA non è attivo/passivo perché è in realtà un cluster di nodi (ferri) che ospitano le VM con storage esterno (su san), e funziona già da due. E ovvio che più ne hai e "minore" è l'investimento nel ferro ... nel senso che con 2 entrambi i server devono esser dimensionati per poter sostenere tutte le VM. Con ad esempio 10 nodi, che eseguano 9 VM (richiedenti pari risorse) ciascuno, se uno si guastasse i rimanenti si ritroverebbero a dover eseguire soltanto una VM in più ... quindi basta sovradimensionarli del 10% (rispetto al 100% nel caso di 2) oppure accettare la pari perdita di performances sino alla riparazione del guasto. Le VM vengono rese disponibili quasi istantaneamente sul nuovo nodo proprio perché lo storage che usano è esterno quindi rimane sempre la stessa VM ad accedere allo stesso storage, cambia solo il nodo di provenienza. Il carico è così per definizione bilanciato sui vari nodi.

Ciao dMajo, sono contento di rileggerti nel mio post!!
direi che i concetti siano molto simili, provo comunque a riassumerli per chiarirci questo aspetto e andare avanti (scusa il plurale, ormai ti sento parte della mia infrastruttura di lab )
Parlando di vmware abbiamo:

HA - in presenza di uno storage condiviso e due nodi vmware, le vm settate in HA vengono riavviate automaticamente nel nodo disponibile. Non rimangono sempre attive. Esempio pratico:
la vm1 'vive' sul nodo1 in termini di cpu e memoria, ed è salvata sullo storage condiviso. Nel caso muoia di colpo il nodo1, la vm1 verrà riavviata sul nodo2 automaticamente.
FAULT TOLLERANCE - sempre in uno scenario con due nodi vmware ed uno storage condiviso, la vm1 'vivrà' contemporaneamente sia sul nodo1 che sul nodo2, ma sarà accessibile solo da uno di questi. In pratica le operazioni vengono elaborate prima sul nodo1 e poi replicate sul nodo2. In caso di morte improvvisa del nodo1, la vm1 diverrrà direttamente accessibile sul nodo2.
Molto simile all'HA dei Syno. Questo ha dei vantaggi ma anche svantaggi: le risorse allocate sul nodo1 dalla vm1, risulteranno allocate anche sul nodo2, e viene generato molto più traffico a livello di switch. Chiaramente, è una soluzione adatta se si ha una macchina con compiti critici e che non può cadere in nessun caso.

Nel caso del Syno (che giustamente vuoi ridondato l'HA è attivi/passivo ovvero l'unità passiva rimane in sincronia con quella attiva pronta a subentrarvi (prendendone gli ip) in caso di guasto, quindi non c'è bilanciamento di carico. Questo è quello che trovi servito dalle funzioni del sistema operativo.
Esatto, su questo pezzo sono d'accordo.

Altrimenti dovresti usare i due nas come unità indipendenti distribuendo tu equamente le lun dello storage sui due e gestire tu la loro coppia sincronizzata sui nas incrociati.

Ma è possibile farlo? eseguire questo tipo di sincronizzazione incrociata?

Qui avresti tutte le nic a disposizione (l'HA ne richiede una o più (possono esser aggregate) dedicate al heartbeat e sincronia), avresti un effettivo bilanciamento del carico dell lun sui nas, ma bisognerebbe poi sommarvi il traffico (e carico) delle sincronie incrociate (oltre alla maggiore complessità di gestione) e vedere se alla fine risulti davvero vantaggioso in termini di performances.

Ma in questo caso, se un Syno muore, le macchine che sono ostate in esso crollano rischiando sia la corruzione del dato oltre che il fermo stesso fino ad intervento manuale (perchè vmware gestisce l'ha ma sempre in presenza dello stesso storage vivo. Se non sente lo storage vivo, mantiene le macchine in ram che, dopo un po', andranno in blocco (così mi pare di aver vissuto un down a causa di uno switch bruciato)

La seconda ipotesi, dove le vm al guastarsi di uno storage passano all'altro (nel frattempo mantenuto sincrono) nello spazio di un ping, esiste ma a differenza di un paio di migliaia di euro fra nas e dischi costerebbe diverse decine di migliaia.

Questa frase, perdonami, non l'ho capita.
Io ho due synology 1815+, con 8 dischi da 3 tera, configurandoli nella medesima maniera e mettendoli in HA, dovrei avere la vm sempre disponibile in caso di fault dello storage attivo, giusto?
chiaramente, mi gioco almeno una scheda di rete per HeartBeat.

La cosa strana è che, usando tre schede di rete delle diskstation, due sullo switch1 e 1 sullo switch2, avevo performance minori che usandone solo due (!).

solo due: sempre una per switch o entrmbe sullo stesso sw?

scusa, due sullo stesso switch. Forse è il caso di concentrarsi prima su di uno switch solo, che dici?

Stessa cosa se tutte le schede di rete appoggiavano sulo stesso switch.... c'è qualcosa che mi sfugge?

Stessa cosa: nel senso che le performance erano sempre minori con 3 nic sullo stesso switch o così va?

Esatto!

Di che performance (transfer rate) stiamo parlando?

Intendi i valori? sto usando vmware I/O analyzer, misura throughput in lettura e scrittura, e IOPS ed altre ancora.

Quanti nodi?

uno solo, attualmente è solo un lab, non mi serve avere le performance anche di altri nodi. Per il momento voglio gestire il fault di storage, switch ed eventualmente di una scheda di rete del nodo (che, parlando di iscsi, si dicono di tipo vmkernel)

Potresti postare le configurazioni delle nic dei nas e dei server e loro collegamenti agli switch?

Volentieri, ma ti devo realizzare un piccolo visio.
Vorrei però precisare che attualmente sto concentrando il tutto su di uno nodo, uno switch e un synology solo, questo per fare i dovuti test di performance.
Se ti va bene, realizzo un piccolo schema iniziale, che poi modificherò a seconda degli step (tipo: step1 - tutto su di uno switch step2 - tutto su due switch step3 - abilitazione secondo storage in HA, e così via, a seconda della completezza dei dati che voglio misurare.)
Che ne dici?

[cybermod]

Ciao, nel frattempo posto uno schema. Purtroppo l'allegato che si può inserire è molto limitato, per tanto non si vedono in maniera particolareggiata le impostazioni, ma credo che quello che serva basti.
Nel caso, dimmelo che posto singolarmente degli screen nelle impostazioni, ok?

Questa è per la fase di test non di ridondanza, ma di performance.
Poi si aggiungerà il secondo switch, distribuendo le lan sia del nodo che dello storage, test, e poi implementazione dell'HA di synology, anche per vedere un po' come si comporta l'HA.

attendo fiducioso, ciao!

[burghy86]

Come mail il nas è in dhcp?

inviato con il mio topotalk

[cybermod]

mhhhh, me ne ero dimenticato, effettivamente non è corretto, comunque fa sempre parte della stessa rete.

A livello di performance non credo cambi qualcosa, ma adesso lo sistemo!!!

[dMajo]

Ovviamente gli ip devono essere statici. Inoltre disabilita ipv6 visto che non lo usi.

Sullo switch, verifica l'attività delle 3 porte del nas e del server (attraverso l'interfaccia di gestione).

Io proverei anche a mettere i 3 path su reti diverse (es 192.168.101/102/103.x, dove x sta ad es. 101 sulle 3 nic server e 10 sul nas), non necessariamente devono corrispondere alla rete dello switch che può anche essere ad esempio 192.168.200.1/24. Sullo switch disabilita le funzioni quali spanning tree, igmp.

[cybermod]

Ovviamente gli ip devono essere statici. Inoltre disabilita ipv6 visto che non lo usi.

Sullo switch, verifica l'attività delle 3 porte del nas e del server (attraverso l'interfaccia di gestione).

Io proverei anche a mettere i 3 path su reti diverse (es 192.168.101/102/103.x, dove x sta ad es. 101 sulle 3 nic server e 10 sul nas), non necessariamente devono corrispondere alla rete dello switch che può anche essere ad esempio 192.168.200.1/24. Sullo switch disabilita le funzioni quali spanning tree, igmp.

lo faccio subito, ma: come raggiungo poi l'interfaccia del synology se non metto un ip sulla stessa rete che uso come infrastruttura?

la 182.X, per intenderci?