Best practice per la topologia HA di Exchange 2010 considerando 6 licenze Exchange e TMG 2010


8

Quale sarebbe la migliore topologia visto che:

  1. 6 licenze Exchange 2010 standard
  2. 2 x posizioni separate che dovrebbero supportare la ridondanza in caso di problemi di collegamento
  3. 4 x Forefront TMG 2010 con Forefront Security e Forefront Protection / Security

Più sedi in tutto il mondo utilizzando tali Exchange. La maggior parte delle posizioni sarà connessa con il tunnel VPN (quelli che ospitano Exchange sicuramente).

Stavo pensando a qualcosa del genere:

Posizione PRINCIPALE (circa 70-100 persone):

  1. 2x TMG 2010 in NLB
  2. 1x ruolo Exchange 2010 CAS / HUB
  3. 2x ruolo cassetta postale di Exchange 2010 (attivo + passivo)

Posizione SUPPORTO (circa 20 persone):

  1. 2x TMG 2010 in NLB
  2. 1x ruolo Exchange 2010 CAS / HUB
  3. 2x ruolo cassetta postale di Exchange 2010 (attivo + passivo)

La direzione vuole assicurarsi che in caso di problemi nella posizione principale (mancanza di corrente, perdita di collegamento ecc.) La seconda posizione possa supportare tutto il traffico proveniente da tutto il mondo e viceversa. Abbiamo 6-7 posizioni e più in arrivo (non grandi, ma come 10+ persone per ogni posizione).

So che CAS / HUB è un singolo punto di errore (e non NLB), ma semplicemente mi mancano più licenze per fare un po 'di ridondanza su questo.

Cosa ne pensi di questo approccio? Quale sarebbe un approccio migliore secondo te?

Risposte:


5

Quella configurazione non mi sembra troppo ridicola e non cambierei molto. Suppongo che tutto il lavoro preparatorio sia stato svolto (come più siti di Active Directory, controller di dominio in ciascun sito, ecc.), Quindi non entrerò nei dettagli. Se riesci ad aumentare un po 'il tuo budget, modificherei un po' la tua topologia CAS per eliminare lo SPOF.

Puoi installare il ruolo Trasporto Hub sui tuoi server Cassette postali e questi si caricheranno automaticamente in base al sito di Active Directory in cui risiedono. È una vittoria facile e veloce e non riesco a vedere un motivo in più per non farlo .

Se il budget può contenere 2 bilanciatori del carico hardware, è possibile installare anche il ruolo CAS sui server Cassette postali. Dovresti quindi creare record A in DNS per i tuoi sistemi di bilanciamento del carico e configurare i database delle cassette postali appropriati in ciascun sito per utilizzare l'array CAS per il sito.
A tale scopo, emettere il comando New-ClientAccessArray -Fqdn "ex-sitename-casarray.acme-widgets.com" -Site "AD-Site-MAIN"per ciascun sito (sostituendo i record A e i nomi dei siti AD reali, a seconda dei casi).
Quindi rilasciare Set-MailboxDatabase "<<Appropriate Database>>" -RpcClientAccessServer <<site-casarray-name.acme-widgets.com>>per assicurarsi che i database delle cassette postali utilizzino l'array CAS.

È meglio avere una copia locale di una cassetta postale degli utenti nello stesso sito dell'utente, quindi vorrei creare 2 database delle cassette postali, ciascuno replicando su un server Cassette postali nello stesso sito, così come l'altro sito (ho fatto un diagramma per visualizzarlo per te). Per gli utenti nel sito PRINCIPALE, home la loro casella di posta sul DB delle cassette postali principale e per gli utenti nel sito SUPPORT, home le loro caselle di posta sul DB delle cassette postali di supporto. testo alternativo


1
Non sono davvero sicuro di essere d'accordo con la tua affermazione che il server di cassette postali dell'utente dovrebbe trovarsi nello stesso sito. Questo potrebbe essere vero 10 anni fa, ma tutte le versioni di Exchange a partire dal 2003 supportano la modalità cache. Combinalo con il numero limitato di utenti sul sito di supporto e dubito che qualcuno noterebbe una differenza. È meglio creare database basati su fattori diversi dalla posizione fisica. Limiti di archiviazione, livello di classificazione, necessità di archiviazione o obiettivi relativi al tempo di recupero sono tutti meglio utilizzati per separare le cassette postali nei database.
Jason Berg,

Grazie per il commento @Jason Berg, apprezzo il tuo contributo. Se il sito SUPPORTO è pronto a gestire il traffico dal sito PRINCIPALE, suppongo che il collegamento WAN sarebbe piuttosto buono, quindi sì, gli utenti probabilmente non noterebbero una differenza. Il motivo per cui lo metto è semplice ed è perché l'istruttore del mio corso di formazione ha detto di farlo. Ad essere onesti, è stato più che un passaggio "quando si crea un database delle cassette postali, inserirlo nello stesso sito degli utenti" e poi è passata a qualcos'altro. Non sembrava uno stupido suggerimento, quindi non ci pensavo più.
Ben Pilbrow,

TMG 2010 (nuovo ISA) ha un bilanciamento del carico, quindi non sarebbe un grosso problema, ma mettere ogni ruolo su ogni scatola sembra un po 'eccessivo. So che il ruolo CAS è uno SPOF e non sono davvero sicuro di cosa fare con questo senza mettere tutto in un paniere. Stiamo ottenendo le 6 licenze dalla partnership gratuitamente e dovremo acquistare dell'hardware, oltre ad alcune CAL, quindi non credo che il mio cliente vorrebbe pagare un prezzo aggiuntivo per questo. Ma mi assicurerò di inserirlo nel documento per assicurarmi che comprendano i rischi (tempo di inattività che è).
MadBoy,

Se TMG è in grado di bilanciare il carico dei server CAS, va benissimo (non pretendo di sapere nulla di TMG). Posso chiederti perché non ti va di mettere tutti i ruoli in tutte le scatole, pensi che ci sarà un grande successo? Senza provare a sembrare un coglione (non voglio proprio imbattermi in quello), secondo me non esiste una cosa eccessiva - crei una soluzione più ridondante, che è dopo tutto ciò che cerchi. Potresti suggerire di mettere il Trasporto Hub aggiuntivo su 1 server Cassette postali e CAS sull'altro per alleggerirlo un po '? (Tenendo presente che il CAS necessita ancora del bilanciamento del carico).
Ben Pilbrow,

Potrei farlo anche 4 server nella posizione principale e 2 con tutti i ruoli nell'altro con bilanciamento del carico. Ciò potrebbe fornire la posizione principale con i libri delle migliori pratiche e la posizione di supporto con una soluzione all-in-one.
MadBoy,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.