Como você pode mapear as dependências do servidor em um ambiente não documentado?

Question

Imagine essa situação:

A CompanyA está adquirindo uma subdivisão da CompanyB. A Empresa B distribui a maior parte de sua equipe por essa subdivisão e não é útil ao solicitar documentação. Agora, você deve usar o ADMT para migrar usuários, grupos, estações de trabalho e servidores do domínio filho da CompanyB para o Active Directory da Empresa A.

Como você pode determinar quais servidores que hospedam aplicativos LOB personalizados ou pré-empacotados têm dependências em outros servidores no ambiente para que uma estratégia de migração possa ser planejada adequadamente? Algo como o o VMware vCenter Infrastructure Navigator pode fazer parte disso, mas existem outras maneiras além gastando uma grande quantidade de tempo apenas bisbilhotando?

As respostas podem pressupor um ambiente totalmente Windows em execução no vSphere 5.1, embora as respostas para outras situações também sejam aceitáveis.

    

Answer 1

Eu estive no seu lugar. Não há uma resposta única que faça tudo.

Você pode gastar muito dinheiro em um produto de descoberta e esperar que ele saiba tudo sobre seus aplicativos. Eles existem e alguns são supostamente bons.

Claro, pode não ser tão bom quanto você precisa ou quer. E nada encontrará a "dependência" introduzida por um script agendado diário ou semanal em um servidor aparentemente não relacionado, que é responsável por extrair um extrato de um sistema de pedidos de trabalho e enviá-lo por FTP para um sistema de folha de pagamento. Ou a linha de fax física na caixa do Linux que você de alguma forma não notou durante o seu inventário ...

Eu gosto muito da resposta de Joe - começando de cada departamento e trabalhando com seus "usuários avançados" (que definitivamente podem não ser "usuários avançados" de computador) é uma parte vital de um projeto de descoberta abrangente. Essa é a abordagem de baixo para cima. Também é nesse local que você encontrará pessoas executando aplicativos essenciais aos negócios em suas próprias máquinas, possivelmente compartilhadas com seu próprio grupo de trabalho.

Outra parte da abordagem é entrar em cada máquina e executar algo que mostre, ou até mesmo melhores registros, conexões TCP e UDP por $ period_of_time e ver se você pode pegar tráfego (portas e terminais, provavelmente não quer um captura de rede completa) relacionada a aplicativos desconhecidos. Da mesma forma com a inventariação de tarefas agendadas, contas de serviço, etc. Essa é a abordagem top-down do BFMI.

Devido à possibilidade de processos assíncronos não orientados à conexão e coisas que não são executadas em servidores (ou aplicativos clientes que simplesmente executam a partir de compartilhamentos de arquivos), não acho que possa haver uma única abordagem automatizada para esse problema. . Vai ser mão-de-obra intensiva para fazer o certo. É claro, você pode simplesmente apontar para 80% e começar a migrar ou descompactar, com comunicação suficiente para capturar as coisas que fazem os usuários gritarem quando quebram.

    

Answer 2

A maneira mais eficaz é desligar cada servidor, um a um, e observar o que quebra e o que reclama (mas ainda funciona).

É especialmente útil se você tiver um bom monitoramento, alertas, análise de log (logstash, splunk etc.) e métricas pré-estabelecidas.

Esta não é uma prática recomendada.

Ou ...

Outra abordagem é tomar nota de todos os serviços e processos em execução em cada servidor, excluindo os comuns a todas as máquinas (processos / serviços básicos do Windows, Antivírus, etc ...)