Perguntas e problemas da arquitetura do Active Directory e do Exchange


11

Aqui está o pano de fundo da nossa situação ...

No momento, estamos configurados como três empresas distintas, com três sistemas completos do Active Directory e Exchange. Os três escritórios (um nos EUA e dois na Europa) são conectados através de uma configuração de VPN de três vias (para que cada escritório tenha comunicação segura com os outros dois). Há uma configuração de relação de confiança bidirecional no Active Directory para cada instalação. Todos os sistemas estão executando o Server 2003 e o Exchange 2003.

Existem cerca de 160 caixas de correio entre as empresas e 80 usuários (as caixas de correio adicionais são para subsistemas de TI, contas de encaminhamento ou outros usos).

As empresas estão se unindo oficialmente (em vez de apenas terem um relacionamento de confiança). Portanto, estamos procurando uma solução combinada (com base em um novo nome) em que cada escritório esteja nos mesmos sistemas (Exchange e Active Directory), além de consolidar nossa infraestrutura de TI (há muita duplicação).

Eles contrataram uma empresa externa para entrar e auditar nossa infraestrutura de TI. Eles fizeram uma recomendação oficial para terceirizar a infraestrutura de TI (e adivinhem, eles querem fornecer o serviço).

Fui encarregado de descobrir o que fazer. Eu pensei bastante sobre isso e criei duas opções. A diferença básica é onde o Exchange está hospedado (internamente, nosso terceirizado). Como a terceirização é fácil de entender, apenas detalharei a configuração interna.

Como a alta disponibilidade é necessária, queremos que haja redundância geográfica incorporada. Então, o que eu criei é o seguinte (chamarei os escritórios Site1, Site2 e Site3):

Site1:

  • Função FSMO do Active Directory
  • Função de Caixa de Correio do Exchange - Principal
  • Acesso para Cliente do Exchange, Funções de Servidor de Transporte de Hub
  • Função de compartilhamento de arquivo DFS (para unidades compartilhadas)

Site2:

  • Função do Active Directory - Replicada do Site1
  • Função de Caixa de Correio do Exchange - Secundária, replicada usando a Replicação de CCR
  • Acesso para Cliente do Exchange, Funções de Servidor de Transporte de Hub
  • Função de compartilhamento de arquivo DFS

Site3:

  • Função do Active Directory - Replicada do Site1
  • Acesso para Cliente do Exchange, Funções de Servidor de Transporte de Hub
  • Testemunha de compartilhamento de arquivo (para failover)
  • Função de compartilhamento de arquivo DFS

Portanto, basicamente, o cluster deve sobreviver a uma falha de site único sem derrubar nenhum dos outros sites (ou qualquer um dos sistemas). No caso de uma falha de site duplo, o Exchange parava completamente.

Então, minhas preocupações são as seguintes:

  1. Essa é uma configuração razoável? Ou eu estou complicando as coisas?
  2. O número de servidores necessários (3 em cada site desde que as funções da Caixa de Correio CCR devem ser a única função instalada).
  3. Funcionará mesmo como resumido (onde ocorrerá failover automático para o nó disponível caso um site ou servidor seja desativado)?
  4. Como cada escritório especificaria um servidor local de Acesso para Cliente para seus usuários, esse servidor se tornaria um ponto único de falha para todas as solicitações locais (mas isso pode ser solucionado por uma alteração manual do DNS)
  5. Todos esses servidores precisam estar na mesma sub-rede IP para que isso funcione? Ou posso usar um DNS de pesquisa (clientaccess.site1.foo.com, etc)?
  6. Isso permitirá que eu defina cada escritório como um registro MX (como existe um servidor de transporte de hub em cada escritório para conectar-se à Internet). Portanto, se um escritório falhar, ainda poderemos receber e-mails nos outros, correto?
  7. Manutenção. Receio que essa configuração seja muito complicada para manter a longo prazo (adição de escritórios, remoção de escritórios, atualização de servidores (SO e hardware), etc.). Isso é um medo justificado?

Agora, há também a questão de optar pelo servidor 2003 ou 2008 ... Se seguirmos a rota interna do Exchange, acho que posso convencer os poderes de atualizar para 2008 (na verdade, precisaríamos atualizar para usar o Exchange 2010) ... Mas é realmente necessário ou é que apenas um dos meus "desejos" entrem nos planos (em vez de uma atualização justificável) ...

Agora, parte de mim só quer usar o Exchange terceirizado, pois aliviará alguns desses problemas (ou a maioria deles). No entanto, depois de analisar os custos, o ponto de equilíbrio é de cerca de 1 ano; portanto, a terceirização será consideravelmente mais cara. Junte isso ao fato de que alguns recursos dos quais dependemos não são possíveis terceirizados - pelo menos com as empresas que analisamos - (como Caixas de Correio Compartilhadas, acoplamento do Active Directory incluindo SSO, gerenciamento centralizado, segurança de dados etc.). Então, eu estou realmente dividida sobre onde ir com isso ...

Este é o primeiro projeto dessa escala que estou tentando, então qualquer ajuda seria muito apreciada ...

Agradecemos antecipadamente (e desculpe pelo livro) ...


+1 para a pergunta extremamente bem escrita e documentada. Daria a você +2 para o seu avatar, se eu pudesse.
pauska

Respostas:


6

Estamos em uma situação semelhante, exceto pelo fato de que, no nosso caso, já somos uma empresa. Mas temos escritórios em Cambridge, Londres, Estocolmo, Xangai e Atlanta. Tudo conectado via VPN. Três deles têm servidores Exchange (2 no Exchange 2010, o terceiro será atualizado em breve). A maioria de nossos controladores de domínio executa o Windows 2003, mas estamos no caminho de atualizá-los para o Windows 2008. Temos cerca de 150 funcionários, espalhados por todo o lugar. Muito parecido com a sua situação.

Então, aqui estão algumas respostas do meu ponto de vista:

  1. Se você tem uma equipe de TI decente, nunca consideraria a terceirização. De fato, mesmo que sua equipe não seja decente, prefiro dedicar algum esforço a torná-la decente. Seus tempos de resposta serão muito melhores, sua configuração de segurança é mais simples, mas o mais importante de tudo: sua equipe de TI terá seu foco principal em manter a infraestrutura de TI funcionando da melhor maneira possível. O foco principal do provedor de terceirização é tirar o máximo proveito de você, não fornecendo o melhor serviço.
  2. Sua configuração planejada é muito viável. Seu principal desafio será migrar tudo para um domínio comum, mas isso pode ser feito passo a passo.
  3. Servidores para a maioria do que você precisa não custam um braço e uma perna. Se você precisar comprar servidores adicionais, o investimento de capital será pequeno.
  4. Se funciona ou não conforme resumido, depende de quão bem você tem seu DNS público e seu roteamento interno configurado. Definitivamente, pode ser feito para funcionar.
  5. Eu recomendo ter sub-redes separadas para cada escritório. Torna a vida como um sysadmin um LOT mais fácil. Use uma sub-rede de tamanho decente para cada escritório e, em seguida, use o roteamento estático para o tráfego entre os sites ou o OSPF (a maioria dos roteadores VPN decentes oferecerá o OSPF pronto para uso). Na verdade, temos 2 sub-redes separadas na maioria dos escritórios, mantendo o tráfego corporativo normal separado do tráfego de engenharia (já que nossos engenheiros costumam fazer muitas coisas estranhas com DNS, DHCP, streaming de vídeo e outras coisas). E funciona lindamente. De fato, chegamos ao ponto em que os engenheiros de qualquer escritório podem usar um fluxo de vídeo de uma serpentina em qualquer outro lugar, sem precisar saber de onde vem.
  6. NÃO tente ter todos os computadores em uma grande sub-rede. Você vai arrancar seu cabelo. Promessa.
  7. Temos três gateways de correio público (localizados nos escritórios com a maior largura de banda de conexão com a Internet), todos configurados exatamente da mesma maneira e encaminhados para o servidor Exchange mais próximo, de onde o email é distribuído para as caixas de correio finais. Sem problema algum.
  8. Depois de ter uma noção básica de roteamento e coisas do gênero, você descobrirá que isso não é difícil de manter. Tenho um total de cerca de 150 servidores espalhados por todos esses sites, cerca de meia dúzia de roteadores VPN, várias dezenas de comutadores gerenciados. Somos uma configuração mista (30% Windows, 70% Linux, em servidores e estações de trabalho) e tenho 4 pessoas se reportando a mim. Não um problema de todos.

Confie na sua capacidade de aprender e terá sucesso. O plano é bom. Eu iria com o Windows Server 2008 e migraria os Exchange Servers um a um para o Exchange 2010. Para a migração do Exchange, você pode precisar de ajuda externa (é necessária, e minha equipe geralmente é muito boa com o Exchange), mas se você estiver com medo do layout inicial de capital, você também pode migrar tudo um por um. Não é necessário fazer tudo isso de uma só vez.


Uau! Que resposta! Bem, deixe-me responder a alguns dos pontos que você faz. Primeiro, eu não colocaria tudo em uma sub-rede, a menos que seja absolutamente necessário. O que estou pensando é colocar tudo em uma sub-rede de classe C, com sub-redes específicas para cada escritório (por exemplo, 172.25.50.0 para computadores do site1, 172.25.55.0 para servidores do site1, 172.25.60.0 para computadores do site2, etc.) Então, tudo pode ser gerenciado simplesmente especificando a máscara ... Uma observação, você sugere vários servidores de caixa de correio (um por site)? Ou um único servidor de caixa de correio monolítico replicado para redundância?
precisa saber é o seguinte

Ou é exatamente contra isso que você estava alertando em relação às sub-redes? Seria melhor dar a cada escritório uma sub-rede completamente separada (nem mesmo parte do mesmo \ C)?
precisa saber é o seguinte

Sub-rede: o que você descreve é ​​o que é muito parecido com o que fazemos e o que eu tinha em mente, não queria ser prescritivo, pois as circunstâncias determinam o layout dos detalhes.
wolfgangsz

E-mail: sugiro ter caixas de correio locais para todos os usuários no local, com DAGs para as caixas de correio de outros sites (esse é um conceito do Exchange 2010 e muito útil).
wolfgangsz

É justo (notei isso em 2010, e parece ser exatamente o que queremos). Sou desenvolvedor por profissão. Mas quando nosso administrador de sistemas saiu cerca de um ano atrás, assumi as responsabilidades (pelo meu site). Eu gosto e aprendi muito, mas ainda tenho muito o que aprender ... Por isso, é realmente bom e útil verificar a sanidade dessas coisas ... Muito obrigado!
Ircmaxell
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.