System Center Technical Preview (vNext) – Features Removidas

19 fevereiro 2015 msincic Configuration Manager, AppController, MSARC, Outros, System Center, Windows Azure Pack
Já a algum tempo que temos disponíveis para download as versões preview do System Center, e uma pergunta que em enviam com freqüência é sobre o SCCM e o AppController. Onde está o SCCM TP? Primeiro tratamos do Configuration Manager (SCCM). Apesar de fazer parte da família (suite) de produtos System Center, o SCCM é tratado por um grupo separado. Enquanto o grupo de Program Managers de CDM (Cloud and Datacenter Management) cuida da inteira suite, o SCCM está debaixo do grupo de Enterprise Client Management já que está mais ligado a camada cliente do que servidores e operações de TI como os outros produtos. Sendo assim, o SCCM não está ainda disponível na versão Technical Preview. AppController Agora vamos falar do AppController. Esta ferramenta é uma que particularmente eu gostava muito (http://www.marcelosincic.com.br/search.aspx?q=appcontroller), pois integra a administração do ambiente privado (via VMM) com o ambiente público no Azure, permitindo utilizar os mesmos templates e uma única ferramenta administrativa. Na versão vNext do System Center ele será descontinuado, e o motivo é que poucas empresas utilizaram o AppController para gerenciar ambientes híbridos, usando o AppController como portal de auto-atendimento. Com o lançamento do Windows Azure Pack (WAP), os principais clientes do AppController passaram a ter uma ferramenta de auto-atendimento muito mais robusta e completa para IaaS, PaaS e SaaS (AppController só fornecia IaaS). Server App-V Abordei esta ferramenta no passado (http://www.marcelosincic.com.br/post/Virtualizacao-de-Aplicacoes-de-Servidores-com-o-Server-App-V-do-VMM-2012.aspx) e sua funcionalidade sempre foi pouco utilizada. Com a telemetria de uso e pesquisas da Microsoft constatou-se que os clientes utilizam muito mais templates com as aplicações e softwares instalado do que o seqüenciamento de aplicações/serviços. Baseado neste baixo uso e duplicidade de maneiras de embutir aplicações, a Microsoft decidiu pelo mais econômico que é descontinuar o desenvolvimento. Outras Remoções Existem ainda alguns outros itens, mas são menos relevantes e óbvios, como por exemplo, versões mais antigas de vCenter e Xen. Todas as remoções estão disponíveis em https://technet.microsoft.com/en-us/library/dn806370.aspx

Windows 2003 EOL (End Of Live) – Parte 1: Primeiros Passos e Usando o Simulador Microsoft

24 agosto 2014 msincic Cloud computing, Hardware, Governança, Microsoft Azure, IIS, MSARC, Outros, Projeto, Segurança, Virtualizaçao, Windows, Windows 2003, Windows Azure
Em 14 de Julho de 2015, menos de um ano da data de hoje, o suporte ao Windows 2003 acaba e muitas empresas ainda não estão tomando os passos necessários. A Microsoft disponibilizou um site onde podemos baixar os datasheets e utilizar um assistente para gerar relatórios: http://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/ Quais os Riscos e Problemas Fim das Atualizações (Updates) – Apenas os sistemas operacionais Windows Server 2008 e superiores receberão atualizações No Compliance – Operadoras de cartão de crédito e sistemas bancários internacionais (SOX, Basiléia, etc) não permitiram transações a partir desta versão Segurança Afetada – Todos os novos métodos de invasão, falhas de protocolo ou problemas de SO não receberão correção, significando maior investimento em ferramentas adicionais ou inviabilização de métodos e aplicações Alto Custo de Manutenção – Os novos servidores e hypervisors não irão mais fornecer drivers para o Windows 2003, impossibilitando refresh de hardware e atualização de versão do hypervisor/VM tools Como Começar a Partir de Agora O primeiro passo é realizar um Assessment no ambiente para descobrir todas as aplicações, para isso podemos utilizar o MAP (Microsoft Assessment and Planning) que gera relatórios muito bons para migração. Ele até mesmo gera os dados de compliance de hardware e indicações para virtualização. Para utilizar o MAP foi criado um MVA no ano passado, o foco era migração de Windows XP, mas o funcionamento da ferramenta e geração de dados é similar: http://www.marcelosincic.com.br/blog/post/MVA-sobre-MAP-%28Microsoft-Assessment-Planning-and-Toolkit%29.aspx O segundo passo é analisar compatibilidade das aplicações existentes, o que inclui a versão do web server e dos componentes de aplicações que estejam nestes servidores, versões de banco de dados, etc. É aqui que está o grande risco, muitos dos profissionais de TI que converso e empresas estão focando em migrar AD, File Server e outros papeis do Windows, que a Microsoft preparou métodos fáceis de migração já que são Roles do sistema operacional. O problemas são as aplicações desenvolvidas internamente ou não. Por exemplo, o SQL Server 2005 executado no Windows 2003 precisará ser migrado para SQL Server 2008 R2, aplicações escritas em .NET 1.x-2.x executando no IIS do Windows 2003 precisarão ser avaliadas muito criteriosamente, SharePoint 2003 e 2007 precisarão ser migrados para SharePoint 2010 ou 2013… Estes exemplos deixam claro que o trabalho da migração vai muito além de apenas virtualizar! Para isso existem muitos softwares que fazem o papel de analisador, como por exemplo, o Dell ChangeBase e o AppZero. O primeiro analisa todas as aplicações instaladas (similar ao Microsoft ACT) e testa automaticamente os métodos padrão e nativos de compatibilização. O segundo possui diversos métodos adicionais de compatibilização e faz um tracking de uma aplicação, gerando um pacote MSI, o que é extremamente útil em cenários onde não temos um instalador e não sabemos as dependências de uma aplicação. O terceiro passo é analisar as opções, onde podemos avaliar um P2V (migração de máquina física para virtual) on-premisse, migração de sites ou banco de dados para o Microsoft Azure, criação de VMs em ambiente cloud com transferência de serviços e dados, etc. Esta fase é onde precisamos criar planos bem definidos de migração para cada uma das aplicações e funções que hoje estão no Windows 2003. É a fase onde devemos nos concentrar em parada de serviços, seqüencia das operações, processos de migração, etc. Conclusão Deixar para depois a migração dos servidores é muito mais sério do que a migração de estações. Até hoje muitas empresas ainda possuem XP e sentem as dificuldades e custos de manter um sistema operacional sem suporte. Comece desde já a se preparar e será muito mais fácil. Em um próximo artigo irei falar mais sobre o MAP e outras ferramentas para o Assessment.

System Center Advisor Preview–Novidades

14 maio 2014 msincic Advisor, Cloud computing, MSARC, System Center
Já por alguns anos estamos assistindo sobre o System Center Advisor, desde que seu nome era Atlanta: Março e Abril, 2011 – Quando o produto era beta com o nome do Atlanta: http://www.marcelosincic.com.br/blog/post/System-Center-Advisor-%28Projeto-Atlanta%29.aspx http://www.marcelosincic.com.br/blog/post/Familia-System-Center-Crescendo-Novidades-!!!.aspx Abril de 2013 – Utilizando o System Center Advisor: http://www.marcelosincic.com.br/blog/post/Monitoracao-de-Servidores-com-o-System-Center-Advisor.aspx Julho de 2013 – MVA oficial da Microsoft sobre a utilização do System Center Advisor http://www.marcelosincic.com.br/blog/post/MVA-Gerenciamento-de-pequenas-e-medias-empresas-com-System-Center-Advisor.aspx Março de 2014 – Integrando o System Center Advisor com o System Center Operations Manager (SCOM) http://www.marcelosincic.com.br/blog/post/Integrando-o-SCOM-ao-System-Center-Advisor.aspx Agora temos uma nova fase deste produto que mostra a evolução da monitoração de serviços e servidores utilizando Cloud Computing. No TechEd deste ano em Houston o time de produtos anunciou o Preview da nova versão, que irei detalhar aqui após os testes Beta. A tabela no próprio site mostra a evolução de recursos: Ativação e Custo Até o momento como Preview, o SCA continua como um produto gratuito, bastando utilizar um Microsoft Account (antigo Passport) para ativar a conta. Para os clientes que já tinham o SCA integrado com o SCOM, o update do agente é realizado automaticamente. Caso não conheça, veja instruções nos artigos acima para ativação e integração com o SCOM. Nova Interface A interface do SCA Preview é muito similar ao Preview do Microsoft Azure e mostra a tendencia dos novos produtos em termos de design, sendo que ao abrir a Home temos uma interface baseada em webparts, com um resumo de todos os Intelligence Packs ativos e a situação resumida de cada item: Intelligence Packs Os Intelligence Packs são pacotes de monitoração que podem ser adicionados na conta, como adicionais ao “Configuration Assessment” que já existe na versão atual. Lembrando que os Intelligence Packs ainda não tem a definição do custo de ativação. Para acrescentar novos Intelligence Packs ou remover os já ativos utilizamos o botão +/- no canto superior direito da tela e teremos a lista dos Intelligence Packs disponíveis para ativação, com alguns ainda não disponiveis e com o tempo novos serão acrescentados: Como exemplo, ativei o Intelligence Pack de “Gerenciamento de Log’'” Ao ativar um Intelligence Pack este aparece na Home com a instrução de que precisa ser configura se necessário. No caso do “Gerenciamento de Log” realizei a configuração por incluir o nome do log do Windows que seria adicionado e o filtro de eventos, se desejado: No dia seguinte, depois de ativar a monitoração por algumas horas já temos os dados disponiveis, como a Home no inicio deste artigo. Ao cliente am “Log Management” podemos ver os detalhes de dados e utilizar as Queries para acessar os dados do Log detalhado como a segunda imagem abaixo onde podemos ver o tipo de evento mais comum em um determinado log: Outro Intelligence Pack adicionado que traz um retorno valioso é o “Antimalware” que analise eventuais falhas de segurança, updates não aplicados e até virus/trojans conhecidos: Para as funções já existentes no Advisor, houve melhoras substanciais como podemos ver no resumo abaixo, onde temos alem dos mais de 300 alertas disponiveis agora temos as recomendações baseadas em KBs e a análise de workloads, por tipo de produto como pode ser visto abaixo no resumo de configuração e detalhamento dos alertas: Conclusão O System Center Advisor agora é maduro e com certeza receberá grandes inclusões de recurso com o lançamento do produto final. Para quem já tem a conta, basta ativar o Preview em https://preview.systemcenteradvisor.com e se utiliza integrado ao SCOM automaticamente terá os novos recursos sendo monitorados com a ativação dos Intelligence Packs.

Utilizando o Hyper-V Replica Parte II - Boas Práticas para RTO e RPO

18 janeiro 2014 msincic Hyper-V, MSARC, System Center, Virtual Machine Manager, Virtualizaçao, Windows, Windows 2012
No primeiro post sobre Hyper-V Replica abordamos as vantagens sobre réplica de storage e como iniciar a configuração e réplica http://www.marcelosincic.com.br/blog/post/Utilizando-o-Hyper-V-Replica-Parte-1e28093Vantagens-e-Primeira-Replica.aspx Neste segundo post vamos abordar como o RTO e RPO são importantes e como o Hyper-V Replica se encaixa nestes conceitos. Recovery Time Objective e Recovery Point Objective Basicamente os termos RTO e RPO indicam os objetivos que uma solução de desastre deve cumprir: RTO – Tempo máximo para se recolocar o serviço em produção RPO – Tempo máximo de dados que podem ser “perdidos” entre o evento de desastre e o ambiente restaurado Um bom exemplo de como estes valores se relacionam e o que significam pode ser explicado no gráfico abaixo: No exemplo acima conseguimos “enxergar” claramente o RTO e o RPO: RTO foi de 5 horas e 3 minutos, entre as 05:15 e as 10:18 RPO foi de 3 horas e 15 minutos, entre as 02:00 e as 05:15, uma vez que o backup foi realizado as 2 da manhã Como determinar o RTO e RPO Estes valores são determinados por um plano que é chamado de DRP (Disaster Recovery Plan) que é orquestrado por consultorias especializadas neste tipo de processo. Geralmente é realizado quando uma organização está atualizando seu datacenter e, consequentemente revendo suas políticas de recuperação dos dados ou montagem do datacenter redundante. O processo de levantamento destes dados se baseia em entrevistas e dados do ambiente de TI e, entre outras coisas, coleta: Porque o Hyper-V Replica é uma ótima opção O processo de backup é uma das formas que o RPO e RTO podem ser cumpridos, porem as práticas normais de restore muitas vezes são impeditivas levando em conta o tempo que é perdido entre o ultimo backup e a falha (RPO) e o tempo necessário para se restaurar um servidor a partir de backups (RTO). Com o Hyper-V Replica o tempo de RTO é minimo, uma vez que as réplicas mantem a maquina virtual (VM) no ambiente de redundância integra. E o RPO? Em um ambiente de backup o RPO é facilmente calculado e mantido. Por exemplo, se o RPO da aplicação CRM tem perda máxima calculada em 30 minutos, podemos fazer o backup incremental a cada 15 ou 30 minutos. No caso do Hyper-V Replica este tempo não é determinado de forma simples, uma vez que o tempo de replicação (Replication Frequency) de cada VM indica o intervalo e não o periodo desejado de proteção. Seria muito bom ter uma opção onde pudesse ser indicado qual o tempo máximo em que uma réplica pode estar desatualizada… Um segundo item importante é levar em conta o grupo de uma aplicação, por exemplo mais de um servidor que forma a mesma aplicação e precisa estar com a réplica sincronizada por igual. Como o Hyper-V Replica não tem o conceito de grupo de serviço, não temos como garantir a integridade do conjunto da aplicação. Outra dificuldade no Hyper-V Replica é o baixo número de opções de intervalo da réplica (Windows 2012 a cada 5 minutos, Windows 2012 R2 a cada 30 segundos, 5 minutos ou 15 minutos): Imagine um cluster com 80 VMs, sendo que cada VM tem impacto diferente no negócio ou requisitos técnicos particulares. Destas 80 VMs algumas são servidores web que podem ser replicadas uma vez por dia, outras são servidores de aplicação que só precisam ser replicados quando sofrem algum tipo de atualização e, por fim temos os servidores que precisam ser replicados continuamente. Como configurar diferentes RPO? Uma prática que pode ser adotada de forma simples, é colocar as máquinas em grupos de criticidade e configurar utilizando as 3 janelas de réplica do Windows 2012 R2 (30 segundos, 5 minutos e 15 minutos). O problema é que se a VM que será replicada a cada 30 segundos for, por exemplo um banco de dados e o ambiente de redundância for por WAN, o consumo do link será muito alto e as outras VMs entrarão em intervalo de réplica e com isso todas as réplicas ocorrerão simultaneamente. Com isso, o RPO ficará prejudicado para todas as VMs críticas e muito baixo para as maquinas não criticas. Uma boa prática neste caso é configurar as VMs com RPO maior que 2 horas para serem replicadas manualmente por meio de PowerShell abaixo: Resume-VMReplication MaquinaVirtual –Resynchronize –ResynchronizeStartTime “8/1/2012 05:00 AM” Este comando pode ser executado pelo Task Scheduler ou utilizando o Orchestrator com schedule embutindo o comando. No exemplo citado anteriormente, as VMs de banco de dados ou informações como File Server ficariam com a configuração do próprio Hyper-V a cada 5 ou 15 minutos. As VMs estáticas poderiam ser configuradas com replicação manual, e com tarefas ou runbook agendados e recorrentes replicar pontualmente conforme o grupo de criticidade. Conclusão Este segundo post abordamos como alcançar o RTO e RPO. O próximo post irei abordar os comandos e a sequencia de comandos PowerShell que podem ser executados como script ou com Runbook no Orchestrator.

Utilizando o Hyper-V Replica Parte I–Vantagens e Primeira Réplica

18 janeiro 2014 msincic Hardware, Hyper-V, MSARC, Outros, Windows 2012
O segundo artigo sobre Hyper-V Replica abordando RPO e RTO esta disponivel em http://www.marcelosincic.com.br/blog/post/Utilizando-o-Hyper-V-Replica-Boas-Praticas-para-RTO-e-RPO.aspx Apesar de muito noticiado como novidade no Windows Server 2012, o Hyper-V Replica não está sendo tão utilizado pelos profissionais de TI como esperado. Muito provavelmente temos o desconhecimento e a restrição a ser uma nova tecnologia, o que é natural. Porem, uma das formas hoje usadas para réplica de VMs e que no Hyper-V criam diversos problemas é a réplica de storage, ou seja, a replicação que ocorre entre os storages em casos de datacenter de redundância (DR). A tabela abaixo mostra alguns motivos pelo qual Hyper-V Replica é melhor opção a réplica de storage: Storage Hyper-V Replica Performance da Réplica Performance da cópia usa algoritmos dedicados de compressão Boa performance, só replica alterações no VHDX, Windows 2012 R2 oferece compressão Consistência Assegura consistência na réplica Replica baseada em NTFS, permitindo ativo/passivo e Live Migration RPO Permite a réplica em agendamentos regulares ou contínuos Permite agendar a primeira réplica, as atualizações são a cada 5 minutos no Windows 2012 RTM e 30 segundos, 5 minutos ou 15 minutos no Windows 2012 R2 RTO Necessita que os discos sejam ativados e os hosts Hyper-V inicializados Imediatamente os hosts ativam as VMs no DR Replica de Novas VMs É necessário criar manualmente no site DR Replica qualquer alteração no XML da VM Admin Tools Storage console Console do Cluster/Hyper-V Nivel de Especialização Conceitos de Storage geral e do fabricante Hyper-V e Microsoft Cluster Cancelamento da Réplica Permite cancelar réplica de uma LUN Permite cancelar a réplica apenas de uma VM ou até mesmo um VHDX Inversão Necessário reconfigurar a réplica Permite a inversão em modo gráfico Cluster Mode Ativo/Passivo Ativo/Ativo Ação de Recover Recriar/Reiniciar os algoritmos de réplica Menu de contexto para reiniciar ou inverter O maior problema da réplica de storage para Hyper-V é que a LUN replicada no site DR está offline. Sendo assim, não dá para alterar ou mesmo ver no Hyper-V as VMs no site DR, uma vez que a LUN não está acessivel e só pode ficar no momento de uma virada de operação. Já o Hyper-V Replica permite inverter as VMs sem qualquer passo adicional, incluindo a reversão (inverter primário com secundário). Porem, iremos falar disso em outro post. Vamos focar no momento da primeira réplica. Existem duas formas de a primeira réplica ser realizada sem utilizar o link entre os sites do exemplo abaixo: A primeira forma é fazer local a configuração do Hyper-V Replica e esperar o secundário ter todas as VMs prontas. Este método tem a desvantagem da montagem do storage e servidores em dois momentos, o que pode encarecer o serviço e em muitos casos não haver espaço ou recursos de energia elétrica suficientes. A outra forma é fazer isso por usar o próprio wizard do Hyper-V Replica escolhendo exportar a VM. Para isso, ao configurar a réplica de uma VM escolha a opção "Send initial copy using external media” e defina um local para exportar os arquivos como abaixo: O passo seguinte é importar a VM no host onde ela foi criada. Note que a VM é criada no final do wizard acima no host destino, mas sem os arquivos e sem ativar a réplica: Escolha a localização criada pelo wizard e aguarde a importação: Completado este item no servidor destino o status estará Warning e no servidor de origem Normal indicando que está ok. O próximo passo é clicar no servidor de origem na VM e usar a opção Resume Replica para que ele inicie a cópia de sincronização. Uma dica importante é que o Hyper-V Replica funciona criando um snapshot e enviando o arquivo de snapshot da origem para o destino, portanto não demore muito tempo para fazer a sincronização inicial pois poderá ter problemas de espaço e performance por conta do uso de um disco diferencial do snapshot. Nos próximos posts iremos abordar melhores configurações e como montar um ambiente de Hyper-V Replica.