Instalando e Utilizando o VMM Network Builder

Esta nova ferramenta criada pelo time de produtos do VMM (Anjay Ajodha e Matt McGlynn) disponibiliza um ambiente gráfico para criação de redes virtuais com o System Center Virtual Machine Manager 2012 R2. Download: http://www.microsoft.com/en-us/download/details.aspx?id=43975 Instalação Após fazer o download do instalador, que é muito simples de ser utilizado, será criado um arquivo zip no desktop que deverá ser importado pelo console do VMM: Não é necessário fazer a extração do arquivo XML dentro do zip, basta ir no console do VMM em Settings –> Console Add-ins e importar o wizard indicando o zip criado pelo instalador:     Utilizando o VMM Network Builder O passo seguinte é utilizar o Network Builder, e é muito simples, podendo ser feito no menu Fabric –> Networking ou pelo botão Build Network na barra de tarefas: Neste momento será possível ver a inicialização do wizard, onde ele irá procurar o servidor e validar os dados existentes para a criação de uma nova rede virtual: A primeira configuração que o administrador precisa definir é se esta nova rede virtual deverá ter segregação de tráfego administrativo e de dados, o que normalmente não criamos a cada nova rede virtual. Mas se o seu design for para redes segregadas (NVGRE ou outra) valerá a pena criar a rede de gerenciamento especifica: Observação: A rede criada será chamada de “Management Network”. Se renomeá-la após criada será necessário verificar as dependências com outros objetos. Defina se os hosts terão placas de rede físicas (NIC) separadas para gerenciamento ou se serão também placas virtuais (vNIC): O passo seguinte é definir o range de IPs que será utilizado para a rede de gerenciamento segregada: Por fim, passamos a definir a rede de dados que as VMs irão receber ao utilizar esta rede virtual, primeiro definindo um nome para esta rede: O próximo passo é a definição do nome da rede virtual, as VLANs (se houver) e o range IPv4 e/ou Ipv6: Observação: O range de IPs de gerenciamento (Management Network) e de dados (Logical Network) não podem estar dentro do mesmo intervalo, no meu caso utilizei os valores apenas como exemplo (veja Dicas no final do artigo) Verifique se o desenho ficou correto e se deseja que seja criado um script para ser executado nos hosts. Este passo do script é importante, pois o Network Builder não irá alterar os hosts para criar os vSwitches. Sendo assim, solicite que o script seja criado e execute-o nos hosts que utilizarão esta nova rede virtual que está sendo criada. Obviamente que você também poderá criar os vSwitches manualmente em cada host utilizado a interface gráfica:   Dicas Cuidado ao criar as redes lógicas, pois o VMM Network Builder não valida as informações, por exemplo se o range de IPs da rede de gerenciamento for o mesmo da rede de dados ele só acusará o erro na execução dos scripts de criação Cuidado ao renomear objetos após a criação da rede pelo assistente, pois as dependências e o script para o host não irão funcionar, a menos que totalmente verificados e editados Conclusão Apesar de muito simples, o VMM Network Builder nos ajuda muito no gerenciamento de redes virtuais, evitando que administradores que estão se familiarizando com a ferramenta esqueçam de alguma configuração.

Microsoft Azure (Iaas) Cost Estimator Tool

Ontem a Microsoft liberou uma ferramenta interessante para calculo de custos de migração das maquinas virtuais (a partir do VMM ou ESX) ou fisicas. A instalação da ferramenta pode ser feita pelo link http://www.microsoft.com/en-us/download/details.aspx?id=43376 Na tela inicial escolhemos se o inventário será pelo VMM, ESX, direto no Hyper-V ou com os IPs de maquinas fisicas. Para cada um dos tipos de inventário ele pedirá os dados do gerenciador (VMM, Hyper-V ou vCenter) ou os IPs de maquinas fisicas. No meu exemplo utilizei maquinas fisicas e selecione pelo tipo (Windows/Linux), o IP, usuário e senha. Podemos incluir até 25 maquinas por ciclo: O passo seguinte é escolher a frequencia com que deseja que a ferramenta faça a pesquisa. Como no meu caso a maquina está ligada não preciso definir recorrencias. Na sequencia a ferramenta irá listar os recursos das maquinas que foram analisadas e indica os dados de inventário qeu são relevantes para a confecção do custo. Finalmente, temos o relatório com os custos estimados para cada Azure VM, podendo escolher qual a região e o perfil de hardware para cada VM escolhida, alem do perfil de preço:   Essa ferramenta é muito útil para permitir que o cliente tenha ideia do investimento que será necessário na migração, utilizando dados reais!

Novo Ebook gratuito: Microsoft System Center: Network Virtualization and Cloud Computing

Este eBook explica em detalhes como implementar SDN (Software Defined Network) que é uma das tecnologias que deverá crescer muito nos próximos anos. O livro é muito bom, o que já pude ver é que está separado em parte conceitual, diversos exemplos práticos (2 VMs com o mesmo Range, 2 VMs com o mesmo IP, etc) e também uma seção ensinando passo a passo como configurar os hosts e o VMM.

Treinamento sobre SDN (Software Defined Network) com Windows e System Center

Este evento que será apresentado no MVA em 19/Março das 12:00 as 17:00 no horário brasileiro responde a uma pergunta importante: O que é SDN? Aproveite!!!!   Software-Defined Networking with Windows Server and System Center Jump Start Free online event with live Q&A with the networking team: http://aka.ms/SftDnet Wednesday, March 19th from 8am – 1pm PST Are you exploring new networking strategies for your datacenter? Want to simplify the process? Software-defined networking (SDN) can streamline datacenter implementation through self-service provisioning, take the complexity out of network management, and help increase security with fully isolated environments. Intrigued? Bring specific questions, and get answers from the team who built this popular solution! Windows Server 2012 R2 and System Center 2012 R2 are being used with SDN implementations in some of the largest datacenters in the world, and this Jump Start can help you apply lessons learned from those networks to your own environment. From overall best practices to deep technical guidance, this demo-rich session gives you what you need to get started, plus in-depth Q&A with top experts who have real-world SDN experience. Don't miss it! Register here: http://aka.ms/SftDnet

Novo MVA: Automatizando Processos com System Center Orchestrator

Ontem foi publicado mais um curso sobre System Center 2012 no MVA, agora para o Orchestrator em complemento aos já produzidos sobre Patch Management e Proteção de dados (http://www.marcelosincic.com.br/blog/post/Novos-MVAe28099s-Disponiveis-Gerenciamento-de-Infraestrutura-de-Updates-e-Protecao-de-Dados-e-Servidores-para-Nuvem-Privada.aspx) O foco neste treinamento não foi fornecer exemplos complexos de automação, mas sim ajudar nos primeiros passos, abordando: Ferramentas – Designer, Console e Deployment Manager Criação e organização de Runbooks Chamada e criação de variáveis Passagem de parametros e dados entre atividades Integração do Orchestrator com o Service Manager Publicação de Runbooks no Service Manager para automação de processos Configuração dos Integrations Pack no Orchestrator Espero que gostem: www.microsoftvirtualacademy.com/training-courses/automatize-processos-com-system-center-orchestrator?mtag=MVP4029139 Na sequencia já estamos trabalhando em um MVA para automação de processos de Private Cloud com criação de VMs automáticas!

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

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.

Novos MVA’s Disponíveis: Gerenciamento de Infraestrutura de Updates e Proteção de Dados e Servidores para Nuvem Privada

Os dois MVAs que foram disponibilizados hoje tem por objetivo ajudar no uso da suite System Center em dois pontos bem específicos e que muitos sentem dificuldade em utilizar e entender: Infraestrutura de Updates – Aborda o uso do SCCM como alternativa mais completa que o WSUS em um ambiente gerenciado e como integrar o WSUS ao VMM para aplicar os updates de forma inteligente e escalonada em farm de servidores Hyper-V Proteção de Dados – Como o DPM pode ser a solução ideal para proteção de ambientes Microsoft, principalmente voltado a Nuvem Privada e infraestrutura de virtualizazação Microsoft Clique nos prints abaixo para abrir os cursos diretamente no MVA. Em fase de produção tenho outros MVA’s: Gerenciamento de Infraestrutura de Rede para Nuvem Privada Automatizando processos em Nuvem Privada Gerenciamento de Infraestrutura de Storage para Nuvem Privada  

Administrando Windows Azure com o System Center AppController

Um dos produtos da suite System Center pouco conhecidos é o AppController. Sua função é tornar o uso de ambientes Private Cloud reais, por proporcionar um portal de auto-atendimento simples com uma interface web. É importante ressaltar que o AppController não é apenas uma atualização do Virtual Machine Manager Self-Portal, pois ele tem as funcionalidades novas do VMM 2012 SP1 como controle de cotas, instânciamento de serviços e integração com o Windows Azure, que será tratado neste post. Configurando a conta Windows Azure no AppController O primeiro passo é integrar no AppController a conta do Azure e para isso é necessário primeiro cadastrar um certificado digital no portal do Azure, opção Settings –> Management Certificates onde poderá fazer o upload do certificado: Este certificado é utilizado para autenticar o acesso e pode ser emitido por qualquer IIS na opção Certificates –> Self-Signed e depois fazer a exportações e upload no Azure. O passo seguinte é cadastrar esta conta do Azure e o certificado no AppController: Realizados estes passos já será possivel ver a conta no AppController: Ao clicar na conta do Azure, terá uma lista das VMs criadas no ambiente, com o nome de cada VM, a localização geográfica do Datacenter selecionado e as instâncias criadas: No menu Virtual Machines podemos ver a lista de VMs disponiveis, onde tanto VMs locais (Private Cloud) como as VMs no Azure podem ser administradas de forma integrada: Note que na tela acima temos na parte de baixo dois paineis, o esquerda mostra os dados básicos da VM e na direita o serviço que serviu de origem para esta instância, uma vez que as VMs no Azure podem ser criadas por se fazer o upload de um VHD pronto. No exemplo acima, ao clicar no design vemos detalhes e podemos alterar os dados: Criando VMs no Azure com o AppController A criação de maquinas virtuais pelo AppController é muito simples e permite um nivel de customização maior que pelo próprio Windows Azure Portal. A primeira forma de fazer isso e também a mais simples, é no menu Virtual Machines usar o Add: Uma segunda forma é por utilizar a lista de contas ou selecionando na Library a imagem que será utilizada para instanciar a nova maquina virtual, com a opção Deploy: Será aberta a janela de design para definição dos componentes da VM, como mostrado abaixo: Note que os links permitem selecionar os itens como a imagem de máquina virtual desejada, a rede e a localização geográfica do Datacenter desejado: Conclusão Utilize o System Center AppController para administrar de forma integrada seus ambiente de Private Cloud e Public Cloud em um único console de forma simples, baseada em serviços e funcional.

Conceitos de Storage para IT Pro 3 – Virtualização e Tierização

No primeiro artigo desta série Conceitos de Storage para IT Pros–Tipos de RAID e IOPS abordamos alguns conceitos importantes e básicos para profissionais de TI sobre os tipos de RAID disponiveis e utilizados hoje em storages e também como calcular IOPS (operaçoes de leitura e escrita) para cada tipo de disco e aplicações. No segundo artigo http://www.marcelosincic.com.br/blog/post/Conceitos-de-Storage-para-IT-Pro-2-e28093-Controladoras-e-Modelos.aspx abordamos os tipos de controladoras e tecnologias de storage mais comuns hoje existentes no mercado. Neste terceiro artigo veremos o que são conceitos de tierização e virtualização de storages. Virtualização A virtualização de storage conceitualmente é diferente da virtualização de computadores. Na virtualização de storages o conceito é utilizarmos um produto que faça a conexão com vários tipos e modelos de storage. Por exemplo, o System Center Virtual Machine Manager 2012 é capaz de ser a interface entre os diferentes storages e as máquinas virtuais. Mais detalhes sobre isso podem ser vistos no post http://www.marcelosincic.com.br/blog/post/Gerenciamento-de-Storage-com-o-System-Center-Virtual-Machine-2012.aspx O mesmo recurso pode ser alcançado com o SMB 3.0 do Windows Server 2012, onde podemos apontar todas as LUNs disponíveis em um File Server e por meio do SMB 3.0 mapear as VMs entre os diferentes storages. Tierização Este recurso está presente em alguns storages de mercado e pode ser simulado pelo VMM. Significa ter a possibilidade de termos diversos storages com performances diferentes e ter a capacidade de mover uma VM de um storage mais lento para outro mais rápido de forma transparente a operação. Isso pode ser simulado pelo VMM e pelo Hyper-V 3.0 com o recurso Storage Migration, onde podemos mover as VMs com Live Storage Migration permitindo que a operação não seja interrompida quando movemos entre os diferentes modelos de storage disponíveis. Porem, alguns modelos storage como, por exemplo Compellent e Equallogic, podem conter “gavetas” de discos de diferentes tipos e mover os dados entre as gavetas conforme a performance necessária da aplicação ou maquina virtual. Neste caso o software do storage faz isso automaticamente conforme a carga que cada VM ou aplicação impõe ao storage. Fonte: http://www.dellstorage.com/storage-tiering-archiving/storage-tiering.aspx Para mais informações sobre o Windows Server 2012, acesse: http://clk.atdmt.com/MBL/go/425205719/direct/01/

Conectando os Produtos System Center para Melhor Integração

Muitos que usam os produtos System Center 2012 ainda utilizam as ferramentas como nas versões 2007 e 2008, ou seja, de forma autônoma. Assim, o Service Manager recebe incidentes manualmente quando algum tipo de alerta é gerado no Operations Manager. Os relatórios e dados de inventário (CI) precisam ser consultados no Configuration Manager. Utilizando os conectores do Service Manager podemos integrar todos os produtos como mostra o diagrama abaixo: Como pode ser visto no diagrama, é o Service Manager que faz o papel de integrador entre os diferentes produtos System Center. O Orchestrator também atua, porem por meio dos Runbooks que podem interagir com o desenho de atividades, mas já comentei em outro post http://www.marcelosincic.com.br/blog/post/Orchestrator-Integration-Packs-para-System-Center-2012.aspx Criação de Conectores no Operations Manager Os conectores precisam ser criados dos dois lados, inicialmente pelo Operations Manager em Administration –> Internal Connectors, como pode ser visto abaixo, onde os diversos conectores já estão criados, sendo que apenas um é criado no assistente e os outros criados automaticamente conforme o número de Management Packs: O primeiro passo é definir o nome do conector e quais os grupos de computadores do SCOM serão integrados: No passo seguinte definimos quais são os Management Packs que serão integrados com o Service Manager, sendo que no momento de criação do conector pode-se escolher todos e fazer a manutenção após o conector já criado e testado, como será mostrado no próximo tópico: O ultimo passo ao criar o conector é definir critérios de filtro. Este item é mais importante que os dois acima (Computer Groups e Management Packs), pois permite definir de forma granular quais alertas irão gerar os incidentes no Service Manager. Por exemplo, apenas os erros são importantes em incidentes, assim como a prioridade e o estado do alerta no SCOM. Também é importante notar que os incidentes no Service Manager podem ser abertos pelos estados resultantes dos Healthy Monitors do Operations Manager, o que amplia em muito o número de incidentes que serão gerados: Edição do Conector no Service Manager Criado o conector no console do Operations Manager é possivel ver o mesmo conector replicado no Service Manager em Administration –> Conectors. Se for necessário alterar como os incidentes são abertos, registrados e auto-atualizados é necessário alterar o conector pelo console do Service Manager, como mostrado na tela abaixo: Na tela de configuração do template definimos os critérios dos incidentes que serão sincronizados, lembrando que caso não seja configurado corretamente o conector no Service Manager, ao fechar um incidente este não será encerrado no Operations Manager e vice-versa. No exemplo abaixo, selecionei todos os computadores pelo grupo, mas poderia ser feito um filtro pelo Management Pack, nivel de severidade, prioridade ou mesmo um campo personalizado: Criando Conectores de Itens (CI) no Service Manager Note que a importação dos Management Packs tem a ver com os itens de configuração e não com os alertas definidos anteriormente. Neste caso, o que será importado são itens, computadores e dados recolhidos dos agentes pelo Operations Manager, para formar a biblioteca de dados de configuração junto com o próprio System Center Configuration Manager. Sendo assim, criar o conector de itens de configuração não é tão importante quanto criar o conector para os alertas, principalmente em ambientes onde o System Center Configuration Manager também foi implementado e sincronizado. De qualquer forma, recomendo que se crie o conector de CI para que máquinas monitoradas pelo Operations Manager e que não contenham agente do Configuration Manager estejam contempladas no banco de dados do Service Manager ao abrir um chamado. Alem disso, o conector permitirá ver aplicações como sites do IIS e outros serviços do Windows pelo Service Manager. Para criar e administrar este conector, basta definir quais os Management Packs que irão enviar dados e o agendamento para esta tarefa: Outros Conectores Mais detalhes de cada um dos conectores pode ser vista no TechNet em http://technet.microsoft.com/en-us/library/hh524326.aspx     Para mais informações sobre o Windows Server 2012, acesse: http://clk.atdmt.com/MBL/go/425205719/direct/01/