Domande e problemi relativi all'architettura di Active Directory e Exchange

Ecco lo sfondo della nostra situazione ...

In questo momento, siamo configurati come tre società distinte con tre sistemi completi di Active Directory ed Exchange. I tre uffici (uno negli Stati Uniti, due in Europa) sono collegati tramite una configurazione VPN a tre vie (quindi ogni ufficio ha comunicazioni sicure con gli altri due). Esiste una configurazione della relazione di trust bidirezionale in Active Directory per ciascuna configurazione. Tutti i sistemi eseguono Server 2003 ed Exchange 2003.

Esistono circa 160 cassette postali tra le aziende e 80 utenti (le cassette postali aggiuntive sono per sottosistemi IT, inoltro di account o altri usi).

Le società si stanno unendo ufficialmente insieme (invece di avere solo una relazione di fiducia). Quindi stiamo cercando una soluzione combinata (basata su un nuovo nome) in cui ogni ufficio si troverà sugli stessi sistemi (Exchange e Active Directory) oltre a consolidare la nostra infrastruttura IT (c'è molta duplicazione).

Hanno assunto una società esterna per entrare e controllare la nostra infrastruttura IT. Hanno formulato una raccomandazione ufficiale per esternalizzare l'infrastruttura IT (e indovinare cosa, vogliono fornire il servizio).

Mi è stato assegnato il compito di capire cosa fare. Ci ho pensato un bel po 'e ho trovato due opzioni. La differenza di base è dove è ospitato Exchange (internamente il nostro outsourcing). Dal momento che l'outsourcing è facile da capire, mi limiterò a dettagliare l'installazione interna.

Poiché è richiesta l'alta disponibilità, desideriamo un po 'di ridondanza geografica integrata. Quindi, quello che ho escogitato è il seguente (chiamerò gli uffici Site1, Site2 e Site3):

site1:

• Ruolo di Active Directory di FSMO
• Ruolo della cassetta postale di Exchange: primario
• Accesso client di Exchange, ruoli del server Trasporto Hub
• Ruolo di condivisione file DFS (per unità condivise)

site2:

• Ruolo di Active Directory: replicato dal sito 1
• Ruolo cassetta postale di Exchange: secondario, replicato mediante replica CCR
• Accesso client di Exchange, ruoli del server Trasporto Hub
• Ruolo di condivisione file DFS

site3:

• Ruolo di Active Directory: replicato dal sito 1
• Accesso client di Exchange, ruoli del server Trasporto Hub
• Testimone condivisione file (per failover)
• Ruolo di condivisione file DFS

Quindi in sostanza il cluster dovrebbe essere in grado di sopravvivere a un singolo errore del sito senza far cadere nessuno degli altri siti (o nessuno dei sistemi). In caso di errore di doppio sito, Exchange si arresterebbe completamente.

Quindi, le mie preoccupazioni sono le seguenti:

1. È una configurazione ragionevole? O sto complicando le cose?
2. Il numero di server richiesti (3 in ciascun sito poiché i ruoli della cassetta postale CCR devono essere l'unico ruolo installato).
3. Funzionerà anche come sommato (dove eseguirà automaticamente il failover sul nodo disponibile in caso di arresto di un sito o di un server)?
4. Poiché ogni ufficio specifica un server Accesso client locale per i propri utenti, quel server diventa un unico punto di errore per tutte le richieste locali (ma questo è risolvibile con una modifica DNS manuale)
5. Tutti questi server devono trovarsi sulla stessa sottorete IP per funzionare? Oppure posso cavarmela usando un DNS hiearchial (clientaccess.site1.foo.com, ecc.)?
6. Questo mi permetterà di impostare ogni ufficio come record MX (poiché esiste un server di trasporto hub in ogni ufficio per connettersi a Internet), quindi se un ufficio va in crash dovremmo comunque essere in grado di ricevere e-mail negli altri, giusto?
7. Manutenibilità. Temo che questa configurazione sarà troppo complicata da mantenere a lungo termine (aggiunta di uffici, rimozione di uffici, aggiornamento di server (sia OS che hardware), ecc.). È una paura giustificata?

Ora, c'è anche la domanda se andare con il server 2003 o 2008 ... Se seguiamo la route interna di Exchange, penso di poter convincere i poteri per l'aggiornamento a 2008 (in effetti dovremmo aggiornare per utilizzare Exchange 2010) ... Ma è davvero necessario o è solo uno dei miei "desideri" che si intrufola nei piani (piuttosto che un aggiornamento giustificabile) ...

Ora, una parte di me vuole solo andare con Exchange in outsourcing poiché allevierà alcuni di questi problemi (o la maggior parte di essi). Tuttavia, dopo aver esaminato i costi, il punto di pareggio è di circa 1 anno, quindi dopo tale esternalizzazione sarà considerevolmente più costoso. Abbinalo al fatto che alcune funzionalità da cui dipendiamo non sono possibili in outsourcing - almeno con le aziende che abbiamo esaminato - (come caselle di posta condivise, accoppiamento di Active Directory incluso SSO, gestione centralizzata, sicurezza dei dati, ecc.). Quindi sono davvero lacerato su dove andare con questo ...

Questo è il primo progetto di questa scala che sto tentando, quindi qualsiasi aiuto sarebbe molto apprezzato ...

Grazie in anticipo (e scusate il libro) ...

Ci troviamo in una situazione simile, tranne per il fatto che nel nostro caso siamo già un'unica società. Ma abbiamo uffici a Cambridge, Londra, Stoccolma, Shanghai e Atlanta. Tutti collegati tramite VPN. Tre di questi hanno server Exchange (2 su Exchange 2010, il terzo verrà aggiornato molto presto). La maggior parte dei nostri controller di dominio esegue Windows 2003, ma siamo sulla buona strada per aggiornarli tutti a Windows 2008. Abbiamo circa 150 dipendenti, distribuiti ovunque. Molto simile alla tua situazione.

Quindi, ecco alcune risposte dal mio punto di vista:

1. Se hai un team IT decente, non prenderei mai in considerazione l'outsourcing. In effetti, anche se la tua squadra non è decente, preferirei fare qualche sforzo per renderlo decente. I tempi di risposta saranno molto migliori, la configurazione della sicurezza è più semplice, ma soprattutto: il tuo team IT si concentrerà principalmente sul mantenimento dell'infrastruttura IT al meglio. L'obiettivo principale del fornitore di outsourcing è quello di ottenere il massimo da te, non fornendo il miglior servizio.
2. L'impostazione pianificata è molto fattibile. La tua sfida principale sarà migrare tutto su un dominio comune, ma ciò può essere fatto passo dopo passo.
3. I server per la maggior parte di ciò di cui hai bisogno non costeranno un braccio e una gamba. Se è necessario acquistare server aggiuntivi, l'esborso di capitale sarà ridotto.
4. Se funziona o meno come riassunto dipende da quanto bene hai configurato il tuo DNS pubblico e il tuo routing interno. Sicuramente può essere fatto funzionare.
5. Consiglio vivamente di avere sottoreti separate per ogni ufficio. Rende la vita da amministratore di sistema MOLTO più semplice. Utilizzare una sottorete di dimensioni decenti per ciascun ufficio, quindi utilizzare il routing statico per il traffico tra i siti o OSPF (la maggior parte dei router VPN decenti offrirà OSPF immediatamente disponibile). In realtà abbiamo 2 sottoreti separate nella maggior parte degli uffici, mantenendo il normale traffico aziendale separato dal traffico di ingegneria (poiché i nostri ingegneri tendono a fare un sacco di cose stravaganti con DNS, DHCP, streaming video e quant'altro). E funziona magnificamente. In effetti, lo abbiamo persino al punto in cui gli ingegneri di qualsiasi ufficio possono utilizzare un flusso video da uno streamer in qualsiasi altro luogo, senza dover sapere da dove provenga.
6. NON tentare di avere tutti i computer su una grande sottorete. Ti strapperai i capelli. Promettere.
7. Disponiamo di tre gateway di posta pubblica (situati negli uffici con la massima larghezza di banda della connessione Internet), tutti configurati esattamente allo stesso modo e inoltrati al server Exchange più vicino, da cui la posta viene distribuita alle cassette postali finali. Nessun problema.
8. Una volta che hai una conoscenza di base del routing e simili, scoprirai che questo non è difficile da mantenere. Ho un totale di circa 150 server distribuiti su tutti questi siti, circa una mezza dozzina di router VPN, diverse decine di switch gestiti. Siamo una configurazione mista (30% Windows, 70% Linux, su server e workstation) e ho 4 persone che mi segnalano. Non è affatto un problema.

Fidati della tua capacità di apprendimento e avrai successo. Il piano è buono Vorrei andare con Windows Server 2008 e migrare i server Exchange uno per uno su Exchange 2010. Per la migrazione di Exchange potresti aver bisogno di un aiuto esterno (ne avevamo bisogno, e i miei ragazzi sono generalmente abbastanza bravi con Exchange), ma se lo sei temendo il layout iniziale del capitale, puoi anche migrare tutto uno per uno. Non è necessario eseguire tutto ciò in un'unica grande ondata.