Stiamo ricevendo un paio di nuovi switch da 8 Gb per il nostro tessuto a canale in fibra. Questa è una buona cosa poiché stiamo esaurendo le porte nel nostro datacenter primario e ci permetterà di avere almeno un ISL da 8 Gb in esecuzione tra i nostri due datacenter.
I nostri due datacenter distano circa 3,2 km mentre la fibra scorre. Stiamo ricevendo un solido servizio da 4 Gb da un paio d'anni e ho grandi speranze che possa sostenere anche 8 Gb.
Attualmente sto scoprendo come riconfigurare il nostro tessuto per accettare questi nuovi switch. A causa di decisioni costare un paio di anni fa siamo non in esecuzione di un tessuto a doppio anello completamente separata. Il costo della piena ridondanza era considerato più costoso dell'improbabile tempo di inattività di un guasto dell'interruttore. Quella decisione è stata presa prima del mio tempo, e da allora le cose non sono migliorate molto.
Vorrei cogliere l'occasione per rendere il nostro tessuto più resiliente di fronte a un guasto allo switch (o all'aggiornamento di FabricOS).
Ecco un diagramma di ciò che sto pensando per un lay-out. Gli elementi blu sono nuovi, gli elementi rossi sono collegamenti esistenti che verranno (ri) spostati.
(fonte: sysadmin1138.net )
La linea con la freccia rossa è l'attuale collegamento dello switch ISL, entrambi gli ISL provengono dallo stesso switch. L'EVA6100 è attualmente collegato a entrambi gli switch 16/4 che dispongono di un ISL. I nuovi switch ci consentiranno di avere due switch nel DC remoto, alcuni degli ISL a lungo raggio si stanno spostando sul nuovo switch.
Il vantaggio è che ogni switch non è più di 2 hop da un altro switch, e i due EVA4400, che saranno in una relazione di replica EVA, sono 1 hop l'uno dall'altro. L'EVA6100 nella tabella è un dispositivo più vecchio che verrà eventualmente sostituito, probabilmente con l'ennesimo EVA4400.
La metà inferiore del grafico è dove si trovano la maggior parte dei nostri server e sto avendo delle preoccupazioni sull'esatto posizionamento. Cosa deve andare lì dentro:
- 10 host VMWare ESX4.1
- Accede alle risorse su EVA6100
- 4 server Windows Server 2008 in un cluster di failover (cluster di file server)
- Accede alle risorse sia su EVA6100 che su EVA4400 remoto
- 2 server Windows Server 2008 in un secondo cluster di failover (contenuto della lavagna)
- Accede alle risorse su EVA6100
- 2 server di database MS-SQL
- Accede alle risorse sull'EVA6100, con esportazioni notturne di DB che vanno sull'EVA4400
- 1 libreria di nastri LTO4 con 2 unità nastro LTO4. Ogni unità ha la propria porta in fibra.
- I server di backup (non in questo elenco) eseguono lo spooling
Al momento il cluster ESX è in grado di tollerare fino a 3, forse 4, host che si arrestano prima che dobbiamo iniziare a chiudere le macchine virtuali per spazio. Fortunatamente, tutto ha attivato MPIO.
Gli attuali collegamenti ISL da 4 GB non si sono avvicinati alla saturazione che ho notato. Ciò potrebbe cambiare con la replica di due EVA4400, ma almeno uno degli ISL sarà 8Gb. Per quanto riguarda le prestazioni, sto uscendo da EVA4400-A Sono molto sicuro che anche con il traffico di replica avremo difficoltà a attraversare la linea da 4Gb.
Il cluster che serve file a 4 nodi può avere due nodi su SAN1SW4 e due su SAN1SW1, in quanto ciò metterà entrambi gli array di archiviazione a un salto di distanza.
I 10 nodi ESX sono un po 'graffianti. Tre su SAN1SW4, tre su SAN1SW2 e quattro su SAN1SW1 sono un'opzione e sarei molto interessato a sentire altre opinioni sul layout. La maggior parte di questi ha schede FC a doppia porta, quindi posso eseguire due nodi. Non tutti , ma abbastanza per consentire a un singolo interruttore di fallire senza uccidere tutto.
Le due caselle MS-SQL devono andare su SAN1SW3 e SAN1SW2, poiché devono essere vicine alla loro memoria principale e le prestazioni di esportazione db sono meno importanti.
Le unità LTO4 sono attualmente su SW2 e 2 hop dal loro streamer principale, quindi so già come funziona. Quelli possono rimanere su SW2 e SW3.
Preferirei non trasformare la metà inferiore del grafico in una topologia completamente connessa in quanto ciò ridurrebbe il nostro conteggio delle porte utilizzabili da 66 a 62 e SAN1SW1 sarebbe ISL del 25%. Ma se è fortemente raccomandato, posso seguire questa strada.
Aggiornamento: alcuni numeri delle prestazioni che saranno probabilmente utili. Li ho avuti, ho appena distinto che sono utili per questo tipo di problema.
EVA4400-A nella tabella sopra fa quanto segue:
- Durante la giornata lavorativa:
- Le operazioni di I / O hanno una media inferiore a 1000 con picchi a 4500 durante le istantanee di ShadowCopy del cluster di file server (dura circa 15-30 secondi).
- Gli MB / s generalmente rimangono nell'intervallo 10-30 MB, con picchi fino a 70 MB e 200 MB durante ShadowCopies.
- Durante la notte (backup) è quando pedala davvero veloce:
- Le operazioni di I / O sono in media intorno a 1500, con picchi fino a 5500 durante i backup del DB.
- Gli MB / s variano molto, ma funzionano circa 100 MB per diverse ore e pompano ben 300 MB / s per circa 15 minuti durante il processo di esportazione SQL.
EVA6100 è molto più occupato, poiché ospita il cluster ESX, MSSQL e un intero ambiente Exchange 2007.
- Durante il giorno le operazioni di I / O sono in media circa 2000 con picchi frequenti fino a circa 5000 (più processi di database) e una media di MB / s tra 20-50 MB / s. I picchi di MB / s si verificano durante le istantanee di ShadowCopy sul cluster di elaborazione file (~ 240 MB / s) e durano meno di un minuto.
- Durante la notte, Exchange Online Defrag, che va dalle 1 alle 5, pompa gli I / O ops sulla linea a 7800 (vicino alla velocità del fianco per l'accesso casuale con questo numero di mandrini) e 70 MB / s.
Gradirei qualsiasi suggerimento tu possa avere.
