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:

image

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:

Imagem1

Realizados estes passos já será possivel ver a conta no AppController:

Imagem2

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:

image

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:

image

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:

Azure2

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:

Azure3

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:

Imagem4

Imagem8

Será aberta a janela de design para definição dos componentes da VM, como mostrado abaixo:

Imagem5

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:

image

image

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 2 – Controladoras e Modelos

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.

Neste artigo iremos abordar os tipos mais comuns de controladoras e modelos de storages.

A tabela a seguir retirada do documento da Microsoft “Analyzing Characterizing and IO Size Considerations” disponivel em http://bit.ly/18nlbTg mostra como o tipo de barramento da controladora fisica utilizada para o seu storage influencia diretamente na performance:

image

HBA – Host Bus Adapter

Este é um tipo de barramento muito utilizado antes do iSCSI e muito eficiente, interligando o storage diretamente com o servidor por uma placa dedicada, sendo utilizado pelo Fibre Channel (exemplo Compellent) ou modelo de conexão direta (exemplo MD3000).

Como pode ser visto na tabela acima, por ser um barramento dedicado temos toda a performance sem concorrencia, diferente do iSCSI, pois no HBA cada servidor se conecta a uma saida do storage ou a um switch dedicado e no iSCSI usamos duas saidas de rede para todos os servidores.

Alem disso, em um storage dedicado são pelo menos duas controladoras, sendo elas redundantes e simultaneas para acesso, garantindo segurança e alta performance.

A desvantagem dos modelos HBA se dá por conta da limitação de conexões possiveis, uma vez que em alguns modelos (exemplo MD3000) são 4 portas, limitando a 4 servidores. Para este modelo utilizar HBA e montar um cluster de 4 nós é uma boa alternativa.

Fibre Channel

O FC é um dos modelos de HBA muito utilizado por conta da alta performance e numero ilimitado de hosts que podem ser conectados pelo switch Fibre Channel.

Alem disso, o FC permite boot de servidores sem disco local, o que garante a substituição de um host apenas colocando outro hardware identico e alterando o WWN no storage.

Nos storages FCs utilizamos o WWN (World Wide Name) para indicar qual LUNs será utilizado por cada servidor, sendo muito simples de ser realizado e configurado. Com o Windows 2012 podemos entregar storages diretamente as VMs por criar um WWN virtual no Hyper-V:

image

A desvantagem do FC se dá pelo custo mais alto que as outras soluções envolvendo HBA e, principalmente, iSCSI. Porem, as vantagens técnicas, administrativas e performance fazem do FC o melhor tipo de conexão a storage.

iSCSI

O iSCSI (Internet SCSI) é o modelo mais utilizado hoje por conta do custo acessivel, diversas opções de fabricantes, modelos e tamanhos. Basicamente o iSCSI utiliza comunicação pela rede ethernet comum, porem com algumas vantagens que melhoram a performance se seguidos:

  • Utilizar switches de rede separados apenas para a rede de storage
  • Trabalhar com 2 placas de rede em cada servidor para configurar o recurso de MPIO (Multipath I/O) que permite utilizar as duas placas simultanêas no acesso aos dados, duplicando a velocidade de acesso
  • Configurar o Jumbo Frame para trabalhar com pacotes de dados de 9K ao invés de 1.5K, uma vez que storage sempre trafega dados em pacotes maiores diferentemente da comunicação comum em rede

A desvantagem do iSCSI se dá exatamente pelos pontos acima, já que a estrutura de rede precisa ser dedicada para ter melhor performance e redundância.

O suporte ao iSCSI pode ser pelo storage ou até por softwares que habilitam um servidor comum a se tornar um storage iSCSI, o que é chamado de iSCSI Initiator Server e o cliente de iSCSI Initiator. A Microsoft tem este software disponivel, mas é muito conhecido no mercado o StarWind iSCSI Initiator Server.

NAS com SMB 3.0

A tecnologia de NAS (Network Attached Server) é baseada no Windows Server 2012 que com o SMB 3.0 torna ele compativel com virtualização, permitindo que o Hyper-V utilize um File Server para armazenar as maquinas virtuais, possibilitando que seja montado um Cluster baseado apenas em File Server.

As vantagens deste modelo são o baixo custo, facilidade na administração e entrega para novos servidores.

As desvantagens se dão por conta da rede que tem os mesmos requisitos listados do iSCSI, tendo algumas considerações adicionais:

  • O MPIO precisa ter placas de rede redundantes no servidor baseadas em SMB Direct e RDMA que não são modelos triviais em servidores atualmente
  • O Jumbo Frame impossibilita que maquinas de usuários (clientes) utilizem o servidor para guarda de arquivos, a menos que se habilite neles o modo Jumbo Frame com implicações em todos os switches da rede Core
  • Storages possuem recursos de multicontroladoras e fontes, o que nem sempre é presente em File Servers

Conclusão

Utilizando corretamente os tipos de storages disponiveis e pensando em sua necessidade é possivel ter um ambiente confiável e com boa performance e redundância.

Fonte: http://bit.ly/13uRbOs (Windows Server 2012 White Paper Storage)

image

Para mais informações sobre o Windows Server 2012, acesse: http://clk.atdmt.com/MBL/go/425205719/direct/01/

Novos Recursos de Rede no Windows Server 2012

Ao escolher uma placa de rede para utilizar com o Windows Server 2012 algumas considerações são importantes. A escolha de uma placa de rede ideal, seja para virtualização, File Server, SQL ou outra função.

A tabela abaixo demonstra como os recursos de placas de rede deve ser configurado conforme a função que o servidor fisico irá desempenhar:

Untitled

Saber como estes recursos funcionam pode não ser o desejo de consumo da maioria dos IT Pros, mas o ganho de performance é considerável e por isso se tornam um item que deve ser configurado.

Placas de rede para uso em servidores possuem um processador específico para desenvolver as tarefas de controle de interrupções, enfileiramento de mensagens e outras funções que liberam o processador (CPU) do computador de ter que lidar com o tráfego de rede.

Abaixo vemos a configuração de Interrupções (Ch0), onde podemos habilitar o processador da placa a realizar o controle de multiplos usos da placa ao invés da CPU. Isso acontece, por exemplo, no momento em que várias aplicações acessam a rede. Se a placa de rede é offboard vale a pena, se a placa é onboard sua CPU é menos eficiente que a CPU do computador, e o recurso não valeria a pena:

image

Os recursos Large Offload permitem indicar se a placa ou o SO irá fazer a transformação de pacotes em frames. Por exemplo, se um dado trafegado é maior que o pacote padrão de 1500 bytes (9000 em Jumbo Frame) ele é dividido em diversos pacotes. Os recursos de offload irão indicar que a placa é responsável por transformar o pacote em frames. Ligar este recurso para servidores de email e streaming não seria indicado, uma vez que estes tipos de pacote podem naturalmente ser perdidos e retransmitidos:

image

Já o RSS faz com que pacotes vindo de uma mesma conexão TCP/UDP sejam processadas sempre pelo mesmo processador principal. Em maquinas multiprocessadas ou mesmo multi-core este recurso faz com que cada conexão fique como que fidelizada ao mesmo processador, evitando que um pacote seja distribuido entre processadores e acabe por causa overload na CPU.

Para maquinas virtuais e NIC Team o recurso RSS é utilizado automaticamente quando se habilitou o SR-IOV no Virtual Switch, que permite que VMs no Windows 2012 acessem os recursos fisicos das placas de rede nativamente, como os que já abordei.

O recurso RSC junta pacotes pequenos para criar um unico pacote. Por exemplo, ele permitirá juntar 3 pacotes de 400 bytes em um unico de pacote de 1500 bytes, economizando cabeçalhos e pacotes na rede. Obviamente que com este recurso melhoramos o meio fisico de comunicação, jogando um numero menor de pacotes no cabo de rede.

O RDMA é um recurso que permite e dá suporte ao SMB Direct, um novo recursos dos File Servers. Este recurso permite que dados na memória de um servidor de arquivos seja transmitido diretamente a placa de rede, sem a necessidade da passagem pelo kernel do sistema operacional. Sua performance é similar ao Fibre Channel, que seria uma controladora dedicada (HBA). Sem o RDMA o recurso de Cluster Hyper-V baseado em SMB (File Share) fica comprometido em performance.

Importante: Quando em placas para acesso a storage iSCSI os recursos Offload, RSS e RDMA precisam estar desabilitados pois eles “seguram” os pacotes de dados, causando perda de pacotes e lentidão

Abordei alguns dos recursos existentes e que podem melhorar a performance de algumas funções como a tabela no inicio do artigo.

Se desejar detalhes sobre os recursos, acesse os links http://technet.microsoft.com/en-us/library/jj574168.aspx e http://technet.microsoft.com/pt-br/library/hh831795.aspx

image

Para mais informações sobre o Windows Server 2012, acesse: http://clk.atdmt.com/MBL/go/425205719/direct/01/