VMware Global Community
Linoxmandy
Contributor
Contributor
Jump to solution

Virtual Infrastructure HA

Salve,
all'interno della mia organizzazione stiamo prevedendo l'implementazione di una virtual infrastructure, con hypervisor Vmware, che supporti Alta Affidabilità, Vmotion, Fault Tollerance come principi cardine.

L'architettura sarà così composta:

nr.2 server già in ns. possesso, con processore Xeon E54XX, equipaggiati con due schede iscsi ognuno, hd sas 10k 2,5'';

nr.1 server da acquistare, con processore Xeon E56XX, equipaggiato con due schede iscsi, hd sas 15k 3,5'';

nr.1 storage iscsi dual controller da acquistare (fujitsu dx60, dx80 oppure ibm ds3512) su cui andare a collegare i server in direct attach (soprattutto nel caso di dx80 o ibm ds3512 che hanno 8 porte iscsi)

Vmware Vsphere Essential Plus o probabilmente Vsphere Advanced (per sfruttare il Fault Tollerance)

Vorrei condividere con voi le seguenti scelte:

1) Ho appreso che è best practice avere architetture hardware dei nodi server quanto più simili per avere una virtual infrastructure efficace. Avere una sostanziale differenza nei processori (E54XX ed E56XX) e negli hard disk interni ai server (2,5'' e 3,5'') può costituire un problema serio di performance ed affidabilità?


2) Il protocollo di connessione tra server e storage sarà ISCSI 1.0Gb/s. Come posso sapere e capire se questo non costituirà un collo di bottiglia all'infrastruttura considerando che questa supporterà un totale di 8 server virtuali per servizi di exchange 2007, sql, file server, dc, dns per un totale di 40 utenti?

Grazie.

Reply
0 Kudos
1 Solution

Accepted Solutions
ldelloca
Virtuoso
Virtuoso
Jump to solution

Ciao,

"a livello di principio" qualsiasi switch è sufficiente, ma se vogliamo essere corretti, no.

Tra le varie caratteristiche che dovresti controllare nello scegliere un prodotto io annovererei:

- full-wire speed/non-blocking: produttori diversi usano termini diversi, in sostanza è la capacità dello switch di garantire la massima velocità contemporanea su tutte le porte

- supporto per vlan tagging, se le usi anche su ESX e storage, così puoi usare gli stessi switch per iscsi

- supporto per jumbo frames

Altre funzioni sono sicuramente gradite se presenti ma non obbligatorie.

Inizierei ad annoverare le porte 10Gbit o almeno le porte gbic per prevedere un'espansione futura, oramaci si sta iniziando a diffondere.

Ciao,

Luca.

--
Luca Dell'Oca
[Assegnare punti a una risposta utile è un modo di dire grazie]
Luca Dell'Oca | vExpert 2011-2012-2013-2014-2015-2016-2017, VCAP-DCD, CISSP #58353 | http://www.virtualtothecore.com | @dellock6 | http://www.linkedin.com/in/lucadelloca | If you find this post useful, please consider awarding points for "Correct" or "Helpful"

View solution in original post

Reply
0 Kudos
10 Replies
logiboy123
Expert
Expert
Jump to solution

Ciao

Sto utilizzando un traduttore, come io non parlo italiano quindi se tutto è confuso le mie scuse.

Il problema con l'utilizzo di hardware diversi non è tanto la velocità del processore, ma l'architettura del processore. Se si hanno due host in un cluster, uno basato su AMD e un altro basato su Intel, quando si vMotion le probabilità sono buone macchine virtuali che la VM non riuscirà, perché le chiamate sottostante alla CPU non funzionerà. Si consiglia di attaccare con lo stesso core su tutti gli host in un cluster, ma fintanto che lo stesso tipo di chip che dovrebbe essere a posto. La velocità del disco collegato in locale non è un problema, sto presumendo che si sta usando solo questo per l'installazione ESXi e nient'altro.

Per iSCSI; maggior parte dei tipi di stoccaggio in questi giorni hanno all'incirca lo stesso tipo di throughput di banda, sia essa NFS, iSCSI o FC. FC è ovviamente più sicuro e ha la più bassa latenza se questa è una preoccupazione. Si dovrebbe costruire la tua rete di storage di essere separati dal resto del contesto e tutti i nodi dovrebbero utilizzare una singola subnet. Inoltre è necessario assicurarsi di iSCSI in un metodo di installazione ridondante e carico equilibrato. Il seguente link è in inglese quindi potrebbe essere necessario tradurre;
http://virtualgeek.typepad.com/virtual_geek/2009/09/a-multivendor-post-on-using-iscsi-with-vmware-vs...

Saluti,
Paolo

Reply
0 Kudos
max_esprient
Enthusiast
Enthusiast
Jump to solution

Avere dei server eterogenei in un cluster non è mai una scelta ottimale, se capita è perchè si aggiunge un nuovo host a server già presenti, partire con un progetto proprio con server già diversi in partenza ....

I problemi non sono legati alla scelta dei dischi locali, ma hai processori ed alla quantità di memoria (quest'ultima per l'HA). Con i processori di famiglie diverse (es: 54xx e 56xx) per poter fare il vMotion devi abilitare l'EVC, ma (vado a memoria) questo non dovrebbbe permetterti il FT. Io considero l'EVC una cosa da usare solo in determinati casi, se posso la evito.

Le differenze di memoria tra host in caso di HA fanno considerare in caso di Adminssion Control attivato (magari con l'impostazione per n. di host disposti a perdere) che il cluster consideri che possano andare in crash i server con più ram e che quindi siano i più piccoli a dover supprtare il carico, e quindi potresti avere pochi slot (poche VM da attivare) nel cluster.

Sul discorso dell'ISCSI postresti non avere problemi però qui i fattori sono molteplici non so darti una indicazione assoluta, se non cerca di dedicare dei canali gigabit allo storage che non vadano in conflitto con altre reti (tipo vMotion o FT o VM).

max

ldelloca
Virtuoso
Virtuoso
Jump to solution

Ciao,

i commenti aggiunti precedentementi sono corretti, quindi evito di riperterli.

Ti aggiungo qualche informazione e opinione che potrebbe esserti utile.

Per FT, la tabella ufficiale cui fare riferimento è questa:

http://kb.vmware.com/kb/1008027

da qui si vede che le serie 5400 e 5600 non sono compatibili tra di loro. Al massimo potrai fare FT tra i due nodi 5400.

EVC funziona solo per vmotion e quindi DRS (ma se prendi le licenze advanced comunque non avresti DRS).

Relativamente al direct attach su iscsi, è una cosa che sinceramente non mi piace, indipendentemente che si possa o meno, principalmente perchè ti giochi tantissimi path che invece vedresti e potresti sfruttare se usassi un networking classico.

Usando connettività a 1 gbit, questo è ancora più importante dato che puoi abilitare il multipathing in round robin e migliorare le prestazioni.

Ciao,

Luca.

--
Luca Dell'Oca
[Assegnare punti a una risposta utile è un modo di dire grazie]
Luca Dell'Oca | vExpert 2011-2012-2013-2014-2015-2016-2017, VCAP-DCD, CISSP #58353 | http://www.virtualtothecore.com | @dellock6 | http://www.linkedin.com/in/lucadelloca | If you find this post useful, please consider awarding points for "Correct" or "Helpful"
Linoxmandy
Contributor
Contributor
Jump to solution

Quindi deduco che è condizione da evitare quella di avere server con processori diversi, ove si intendono diversi anche i server con CPU E54xx ed E56xx perchè appartengono a due "famiglie" diverse

La CPU 54xx appartiene alla 45nm Core 2 Microarchitecture Category.

La CPU 56xx appartiene alla  Core i7 Microarchitecture Categories, con sottocategoria Westmere Series Groups

Inoltre, condizione indispensabile è avere lo stesso quantitativo di memoria ram su ciascun nodo.

logiboy123 però asseriva che vi sono problemi solo se vi sono differenze strutturali (AMD vs Intel). O sbaglio?

Per ldelloca

alla fine opterò per non andare in direct attach. Utilizzerò due switch cisco serie 200 (codice SLM2024T). Possono andar bene o devo prevedere degli switch più specifici sul protocollo ISCSI?

Dal punto di vista del cablaggio,

avendo due schede ISCSI, oltre a due schede LAN Ethernet, sui server

avendo due switch (cisco o altro brand)

avendo uno storage con due controller iscsi

Qual'è il cablaggio suggerito per questa architettura?

Io pensavo di

collegare la scheda iscsi1 dei server allo switch1, e collegare il controller1 dello storage sia allo switch1 che allo switch 2 (se non erro il controller ha totali 8 porte iscsi (4 porte per ciascun controller).

collegare la scheda iscsi2 dei server allo switch2, e collegare il controller2 dello storage sia allo switch1 che allo switch 2 (se non erro il controller ha totali 8 porte iscsi (4 porte per ciascun controller).

Thanks!

Reply
0 Kudos
logiboy123
Expert
Expert
Jump to solution

Credo di avervi fatto un dis-servizio, rendendo tali commenti.

Se andavo a correre un cluster con diversa architettura della CPU livello allora avrei dovuto girare su EVC per assicurarsi che tutte le CPU esegue allo stesso livello. Infatti di default mi rivolgo EVC su ogni caso. Ciò significherebbe una perdita di alcune delle funzionalità più alto livello della CPU più costose di.

Saluti,
Paolo

Reply
0 Kudos
ldelloca
Virtuoso
Virtuoso
Jump to solution

Ciao,

la condizione di uguaglianza cpu è preferibile se non vuoi usare EVC, ma nel caso evc funziona e anche bene, anche che riduce lievemente le performance.

Discorso simile per la ram, uno sbilanciamento eccessivo tra i nodi incrementa lo slot size e rende quindi meno bilanciato il cluster, ma è in ogni caso gestibile. C'è volendo anche la possibilità di "truccare" lo slot size nel caso.

Per il networking: non conosco le apparecchiature cisco che citi, perdonami.

Per i flussi iscsi direi che è corretto il senso.

Ciao,

Luca.

--
Luca Dell'Oca
[Assegnare punti a una risposta utile è un modo di dire grazie]
Luca Dell'Oca | vExpert 2011-2012-2013-2014-2015-2016-2017, VCAP-DCD, CISSP #58353 | http://www.virtualtothecore.com | @dellock6 | http://www.linkedin.com/in/lucadelloca | If you find this post useful, please consider awarding points for "Correct" or "Helpful"
Reply
0 Kudos
Linoxmandy
Contributor
Contributor
Jump to solution

Grazie.

A livello di principio: per collegare dei nodi server ad uno storage iscsi 1Gb/s, è sufficiente un normale switch ethernet o bisogna andare su prodotti specifici?

Reply
0 Kudos
ldelloca
Virtuoso
Virtuoso
Jump to solution

Ciao,

"a livello di principio" qualsiasi switch è sufficiente, ma se vogliamo essere corretti, no.

Tra le varie caratteristiche che dovresti controllare nello scegliere un prodotto io annovererei:

- full-wire speed/non-blocking: produttori diversi usano termini diversi, in sostanza è la capacità dello switch di garantire la massima velocità contemporanea su tutte le porte

- supporto per vlan tagging, se le usi anche su ESX e storage, così puoi usare gli stessi switch per iscsi

- supporto per jumbo frames

Altre funzioni sono sicuramente gradite se presenti ma non obbligatorie.

Inizierei ad annoverare le porte 10Gbit o almeno le porte gbic per prevedere un'espansione futura, oramaci si sta iniziando a diffondere.

Ciao,

Luca.

--
Luca Dell'Oca
[Assegnare punti a una risposta utile è un modo di dire grazie]
Luca Dell'Oca | vExpert 2011-2012-2013-2014-2015-2016-2017, VCAP-DCD, CISSP #58353 | http://www.virtualtothecore.com | @dellock6 | http://www.linkedin.com/in/lucadelloca | If you find this post useful, please consider awarding points for "Correct" or "Helpful"
Reply
0 Kudos
AndreTheGiant
Immortal
Immortal
Jump to solution

Aggiungo il supporto del Flow Control (che in parte si collega al primo punto elencato da Luca).

Ma aggiungo anche che prima è meglio partire dal tipo di storage... alcuni prevedo due (o più) reti logiche diverse che ben si prestano ad essere implementare con degli switch completamente indipendenti (stile rete fabric FC).

Altri richiedono una sola rete logica, e allora diventa fondamentale prevedere switch con funzioni di stack o di LAG.

Andrea

Andrew | http://about.me/amauro | http://vinfrastructure.it/ | @Andrea_Mauro
Reply
0 Kudos
Tinto1970
Commander
Commander
Jump to solution

- full-wire speed/non-blocking: produttori diversi usano termini diversi, in sostanza è la capacità dello switch di garantire la massima velocità contemporanea su tutte le porte

- supporto per vlan tagging, se le usi anche su ESX e storage, così puoi usare gli stessi switch per iscsi

- supporto per jumbo frames

aggiungo, anche se può sembrare scontato:

- che abbia una doppia alimentazione 'vera'

su un altro progetto (xen con iscsi) solo dopo un disastro sono riuscito a convincere che gli switch che avevo preso per collegare i precedenti server fisici a un file server in nfs non andavano più bene.

Dopo una domenica mattina passata in ufficio si sono convinti che il fenomeno "mah gli switch è difficile che si rompano" aveva torto e abbiamo preso uno switch in cui entra sia la 220 sia la bassa tensione da alimentatore esterno.

--
Alessandro aka Tinto VCP-DCV 2023 | VVSPHT 2023 | VMCE 2024 | vExpert 2024 | Veeam Legend
please give me a "Kudo" if you find my answer useful
www.linkedin.com/in/tinivelli
my blog: https://blog.tinivelli.com
Reply
0 Kudos