Fim do suporte do Windows Server 2003 #2

Em nosso primeiro artigo sobre o fim do suporte do Windows Server 2003 falamos sobre os pontos positivos para migrar para o Windows Server 2012 R2. Neste artigo vamos abordar como planejar a migração e ajudá-lo também a reduzir os custos com licenciamento.

O processo de migração do Windows Server 2003 para o Windows 2012 seguirá as 04 etapas abaixo.

servercloud-aug26-1.png-550x0

Levantamento

Nesta etapa iremos focar os nossos esforços em fazer o levantamento de todos os servidores Windows Server 2003 que possui e os serviços que cada um roda.

Existe uma ferramenta da Microsoft gratuita que pode ajudar muito nessa tarefa, é o Microsoft Assessment and Planning Toolkit. Com esta ferramenta você poderá fazer um levantamento automatizado de todo o seu ambiente de servidores, incluindo hardware e serviços que rodam em cada servidor. Você pode fazer o download do arquivo com a demonstração dos relatórios que são gerados em http://go.microsoft.com/fwlink/?LinkID=266487.

Existe um curso no MVA da Microsoft (O canal de cursos de graça da Microsoft), feito pelo nosso parceiro e MVP da Microsoft Rafael Bernardes, que ensina passo a passo a usar o MAP. Acesse em http://www.microsoftvirtualacademy.com/training-courses/migrando-sua-rede-com-map.

É importante nessa etapa envolver todo o seu staff de TI, inclusive sua equipe de desenvolvimento para ajudá-lo a identificar as aplicações feitas in house e que talvez sejam impactadas pela migração.

Avalie o ambiente

A fase de avaliação é extremamente crucial e exige que você analise cada workload e aplicação para identificar a utilização, a importância e a sustentabilidade de cada instância. Através deste processo, você provavelmente vai encontrar redundâncias que são incompatíveis com as suas necessidades. Ao longo do tempo os ambientes podem ser sujeitos a expansão sem o nível adequado de controles de TI, esta é uma grande oportunidade para abordar isto e instituir melhores controles.

Talvez durante o processo de avaliação você encontre serviços ou aplicações que antes eram tratados como críticos, mas que talvez hoje não sejam plenamente utilizados. Por outro lado, você também identificará aplicações ou serviços realmente críticos e que precisam de atenção e um SLA alto.

Esta é uma oportunidade de reunir-se com o proprietário da empresa para reconfirmar o nível de serviço exigido para cada aplicação e para informar sobre os custos associados. A maioria das partes interessadas no negócio, sempre pedem 99,9% de disponibilidade para as suas aplicações mas quando informados sobre os custos reais deste tipo de SLA, preferem mover estas cargas de trabalho críticas para alternativas de nuvem altamente disponíveis, concordando em manter as aplicações não-críticas em um ambiente de menor custo e menor disponibilidade.

Esta fase requer que você olhe atentamente para o seu catálogo de aplicações e cargas de trabalho no levantamento que você fez na primeira fase. Não há um processo automatizado que possa ajudá-lo com isso, pois é necessário uma análise detalhada da relevância dos serviços e aplicações de cada servidor para o negócio da empresa.

Dependendo do número de itens que você precisa para avaliar, esta fase pode levar uma quantidade substancial de tempo e você precisará estar alinhado com as áreas de negócio de sua empresa, identificando os novos recursos que precisam, o quanto eles precisam expandir e onde eles planejam crescer geograficamente. Você vai precisar identificar os proprietários de cada função no servidor e aplicação, e identificar o impacto de cada um.

A fim de agilizar o processo, sugerimos que você comece organizando o inventário de cada carga de trabalho e aplicação por Tipo e Criticidade, bem como a Complexidade e Risco.

Clique para ampliar

 

  • Por Tipo:

Organizando seus workloads e aplicações desta forma você conseguirá engajar as pessoas corretas para determinar a melhor forma de migração. Por exemplo, se você tem vários bancos de dados no Windows Server 2003, então você vai precisar se envolver com a equipe de aplicativos, para discutir uma atualização do banco de dados para uma versão com suporte.

  • Por Criticidade:

O que os departamentos ou clientes usam desses recursos hoje? Será que eles se encaixam nos objetivos de negócio da sua organização? Quem mais usa isso? Qual disponibilidade eles precisam e quanto tempo de inatividade é aceitável? Esta categorização vai revelar algumas oportunidades potenciais, bem como os possíveis problemas, como mostrado no diagrama abaixo:

  • Por complexidade e risco:

Categorizar a complexidade e o risco indicará quais as migrações podem ser mais fáceis e rápidas de realizar. Uma consideração importante é sobre as dependências que possam existir, uma vez que existem reações em cadeia quando, por exemplo, se aposenta um banco de dados que ainda está ligado a uma carga de trabalho em separado. A análise cruzada através dessas categorias pode ajudar muito nas decisões de migração, por exemplo, uma aplicação importante com baixa complexidade e risco médio pode ser um bom candidato para uma migração precoce.

Depois de ter concluído essa fase, você deve ter descoberto com sucesso as cargas de trabalho verdadeiramente importantes e aplicativos que exigem o seu foco. Da mesma forma, a avaliação irá ajudá-lo a identificar quais serviços ou aplicações podem ser facilmente migrados, bem como aqueles que devem ser aposentados.

Colocar tudo isso em uma planilha compartilhada irá ajudar você e sua equipe a ter uma visão mais objetiva sobre seu ambiente e ajudá-lo a definir sua prioridades e para onde os recursos serão migrados.

Veja abaixo um exemplo de como pode ficar a sua planilha.

Para onde migrar

Você já entendeu como está o seu ambiente, sabe exatamente quais serviços você precisa ter um SLA bem definido e quais não são prioritários. Já tem todos os recursos que precisará durante a migração mapeados e todas as dependências. Agora é a hora de determinar para onde migrar os seus sistemas e serviços.

Durante o processo de levantamento você tomou conhecimento do inventário dos seus servidores. O próprio MAP pode te ajudar a avaliar qual hardware você pode aproveitar e é compatível com o Windows Server 2012.

Utilize uma planilha em Excel ou, de preferência, o Project, para criar um cronograma que defina as datas, tarefas, os recursos, as dependências e etc. Lembre do ditado: “Se quiser derrubar uma árvore na metade do tempo, passe o dobro do tempo amolando o machado”. O planejamento correto e bem feito fará com que o processo de migração seja o menos traumático possível.

Pense na possibilidade de usar a virtualização a seu favor. O Windows Server 2012 R2 já vem com a mais nova versão do Hyper-V de graça, com isso você pode ter recursos interessantes de alta disponibilidade e uma facilidade maior para controlar o seu ambiente. A virtualização pode permitir que você consolide seu servidores e gaste bem menos na compra do hardware novo.

Considere também a possibilidade de levar alguns dos seus serviços para a nuvem. Abaixo algumas sugestões:

  • Migração de E-mail:

Se na sua infraestrutura existir algum servidor de e-mail que seja incompatível com o Windows Server 2012, considere migra-lo para o Office 365.

  • Banco de dados SQL Server:

Considere a possibilidade de migrar o seu banco de dados para o SQL Server como serviço do Azure ou mesmo uma máquina virtual do Azure com Windows Server 2012 R2 e o SQL Server, conectado a sua infraestrutura por uma VPN site-to-site.

  • Site público ou outras aplicações WEB

Considere a possibilidade de hospedar a sua aplicação WEB no Azure da Microsoft. É possível manter a conectividade através de VPN, da sua aplicação WEB no Azure com a sua rede local.

Utilize o Hyper-V para fazer laboratórios que simulem o seu ambiente. Assim você pode fazer os testes de migração sem impactar o seu ambiente de produção.

Prefira começar o processo de migração por serviços que não estão ligados ao seu AD mas que seriam incompatíveis com um servidor Windows Server 2012.

Durante a migração

Agora é a hora de por a mão na massa. Revise tudo que você planejou, tenha certeza que todos que sofrerão algum tipo de impacto durante o processo de migração estão cientes disso e só comece a migração quando tiver certeza que os recursos necessários estão disponíveis.

Ainda sobre os impactos, tenha certeza que o processo de migração ocorra em um período que, acontecendo algum imprevisto, a empresa não sofrerá nenhuma consequência. Não agende a migração para data que seja a mesma do fechamento de vendas da empresa, por exemplo.

Apesar do planejamento, imprevistos podem acontecer. Por isso, tenha uma plano de rollback bem definido para que possa reiniciar a migração quando tiver a remediação para o imprevisto.

Defina um plano de testes para cada etapa da migração e só depois de executado todos os testes é que você definirá a etapa como entregue no seu cronograma.

Mantenha o seu cronograma sem atualizado e acessível a todos os envolvidos no processo.

Conclusão

O foco desse artigo era dar uma linha de como planejar e gerenciar o processo de migração do Windows Server 2003 para o 2012 R2 de forma que seja a menos traumática possível para sua empresa.

Fiquem à vontade para deixar nos comentários como foi o seu processo de migração ou mesmo qualquer dúvida que tenham.

Sucesso a todos.

 

Eduardo Passos
Eduardo Passos
Diretor de serviços e produtos na Infobusiness Informática, com mais de 12 anos de experiência no mercado de TI brasileiro.