Azure Virtual Datacenter (VDC) Parte II-Conceitos Básicos
No post anterior falamos sobre a migração para Cloud http://www.marcelosincic.com.br/post/Azure-Virtual-Datacenter-(VDC)-Parte-I-Migracao-AS-IS-e-TO-BE.aspx
Neste post vamos entender os conceitos básicos, que são representados por esse diagrama:
Cada parte representa um dos pilares que sustentam um Datacenter Virtual:
- Encriptação – Todos os dados trafegados dentro de um datacenter onde vários clientes se hospedam precisam ser protegidos de forma que um não tenha acesso aos dados de outros. Isso envolve criptografia de comunicação, discos e trafégo
- Identity – Um modelo consistente de identidade onde os clientes consigam se logar e ver seus objetos com todos os recursos disponiveis. No caso do Azure isso é feito pelo Active Directory multi-tenant (multi locatário). Como já conhecido no mercado sistemas de diretório permitem que multiplas empresas estejam hospedadas e compartilhem o modelo de banco de dados e autenticação com total isolamento
- Software-Defined Networks – Como hospedar vários clientes se todos querem ter o mesmo range de IP e se comunicam pelos mesmos conjuntos de cabos?
Esse é o desafio das SDNs, permitir trafego isolado. No passado faziamos isso com o recurso de VLAN mas era limitado a 65535. Hoje isso é feito de forma lógica por usar recursos como o NVRE e outros onde os pacotes de rede são tageados (marcados) a quem pertence, similar ao que a VLAN fazia mas sem o limite de 32 bits.
Isso permite que multiplos clientes tenha o mesmo range de IP 10.0.0.0/24, já que cada rede virtual recebe um diferente TAG nos pacotes, com a criptografia e identidade garantindo a confiabilidade na entrega dos pacotes de dados - Compliance – De nada adiantaria se ao migrar para um datacenter público você ficasse preso a padrões que só funcionam lá. As clouds publicas precisam adotar os padrões de mercado para as redes se comunicarem. Isso não quer dizer que a forma como o Machine Learning da Microsoft é codificado é igual ao Machine Learning da AWS, mas sim que a parte básica segue padrões de interoperabilidade.
Por exemplo, uma VMs na AWS pode se comunicar por IP com uma VM no Azure ou no Google Cloud, pois todas usam os mesmos protocolos, mesmo que um provedor tenha serviços agregados diferentes.
O mesmo vale para uma aplicação em Moodle ou SAP, se está no Azure ou AWS não importa pois seguem os padrões de rede e comunicação (interchange) identicos.
Por conta do compliance que posso deixar metade dos meus servidores local e os outros espalhados em 3 diferentes datacenter publicos e todos se comunicando normalmente. - Logging, Audit e Report – Ao migrar de uma nuvem privada (local) para uma pública preciso saber os custos e ter certeza que meus dados estão seguros e acessados só pelos meus usuários.
Aqui não estamos tratando de log, auditoria e reports para o cliente e sim a infra interna para que o provedor tenha certeza que não há vazamento de dados, quem fez cada operação e reportar isso quando necessário.
Por isso os cockpits de provedores de cloud pública são gigantescos. Precisam controlar e serem capazas de se refazer em qualquer tipo de falha que ocorra.
Os primeiros datacenters surgiram do conceito de hosting, ou seja você tirava os servidores do seu rack em casa para levar ao provedor onde a eletrica, links e segurança fisica ficam por conta deles. Nesse modelo toda a responsabilidade de comunicação, segurança lógica e relatórios é sua.
No modelo público uma boa parte dos recursos são alocados para controlar os recursos, por exemplo ao criar o antigo Microsoft Azure Pack (atualmente descontinuado) várias VMs eram criadas com o objetivo de fornecer os itens de controle.
Conclusão
Nesse segundo post falamos sobre os componentes básicos que formam uma cloud pública.
Sinta-se seguro ao colocar seus dados nesses provedores, eles são preparados para garantir o isolamento e segurança dos seus dados.
Introdução ao Azure Stack em Video aula
Segue a apresentação em video aula criada para o Business Partner, agora disponivel público:
Azure Stack 1-Entenda a solução
Agora já disponivel na maior parte dos paises do mundo onde a Microsoft possui Datacenters, o Azure Stack passou a ser um tema constante.
Mas primeiro é preciso entender o foco e composição da solução.
Como é composto?
O Azure Stack é um rack de servidores com tamanhos e configuraçoes pre-determinados, hoje disponivel pela Dell, HP, Lenovo e Cisco.
O HW de cada fabricante foi homologado e padronizado, o que garante updates diretamente do Azure Stack tanto para o software quanto para hardware.
Isso quer dizer que não posso utilizar minhas próprias configurações? Exatamente, para garantir que o sistema fique atualizado e a hiperconvergencia funcione os drivers tem que ser homologados e testados.
É importante entender que todo o Azure Stack é baseado no modelo de hiperconvergencia, ou seja são utilizadas as tecnologias de SDN (Software Defined Network) e SDS (Software Defined Storage) ou SDx em geral como são chamadas.
Ou seja, não existe um storage dedicado. Cada servidor possui uma parte de discos SAS de 15k e discos SSD, com o Storage Space Direct (S2D) habilitado. Isso permite que os servidores tenham seus armazenamentos somados ao compartilhar os volumes entre sí.
A garantia de dados com o S2D é garantida pela distribuição de dados entre os servidores, como já faz o vSAM da VMWare ou o Nutanix.
Para quem se destina?
Diferente do que muitos pensam, o Azure Stack não visa o cliente que acha o Microsoft Azure caro e sim os que tem limitações em relação a nuvens públicas.
Por exemplo, alguns cases no Ignite foram da Swisscom e a KPMG da Suécia.
A KPMG o cenário foi a legislação e a exigencia de alguns clientes que não queriam seus dados de auditoria disponiveis em nuvem pública por mais que tente se justificar a segurança do dado. A solução foi o Azure Stack onde a KPMG teria os mesmos serviços utilizados por outras filiais no mundo, mas on-premisse.
Já o case da Swisscom foi o de ser um Datacenter local, já que o Azure não tem um DC no pais. Assim, aqueles clientes que querem utilizar serviços de nuvem pública podem utilizar a nuvem privada do Azure Stack para hospedar seus serviços localmente.
Ou seja, os principais clientes são, entre outros:
- Paises onde existem restrições legais quanto a armazenar dados em outros paises
- Datacenters interessados em fornecer serviços a seu usuário a mesma interface do Azure, mas localmente, por exemplo no Brasil só temos um DC Microsoft Azure e um provedor tradicional poderia usar o Azure Stack como ponto de Avaliability Group
- Empresas com alto uso de recursos computacionais baseados em IaaS e que possuem Datacenter próprios
- Empresas com tradição on-premisse que não querem ver seus dados fora do ambiente, mas desejam utilizar o modelo de Cloud Publica “in-loco” com facil manutenção e suporte de alto nivel
E aquele cliente que acha o Azure caro, vale a pena usar o Stack? Na ponta do lapis não, pois precisamos lembrar que é um rack e precisa de refrigeração, energia, piso elevado e todos os outros custos envolvidos em um DC fisico.
Quanto custa o Azure Stack?
Primeiro é necessário ver o custo do Hardware que pode ser vendido diferente por cada um dos atuais 4 fabricantes.
Por exemplo no caso da Dell as configuraçoes começam em 4 servidores de 20 CORE e 4.1TB, podendo chegar a doze servidores por rack, sendo a capacidade máxima de 4 Racks com 12 servidores cada um.
Alem disso, temos os servidores Low, Mid e High profille, onde um rack com os 12 servidores High Profile a capacidade é 336 Core, 6.1TB RAM, 138TB cache, 1.2PB de disco!!!!
Agora vamos falar do custo de Software. É importante lembrar que o Azure Stack não tem custo de software, ou seja ele é bilhetado como um serviço, que inclui:
- Atualizações do Software Stack
- Atualizaçoes de Drivers e componentes lógicos
- Disponibilização e pré-configuração dos componentes e templates
- Suporte Microsoft do Azure é o mesmo que atende Azure Stack
Ou seja, o Azure Stack tem um custo pelo consumo, não com licenciamento, na modalidade “Pay-As-You-Use”, baseado na tabela abaixo:
Referencia: https://azure.microsoft.com/pt-br/overview/azure-stack/how-to-buy/
Baseado nisso, temos como exemplo uma VM A2 que custa U$ 130/mês no Microsoft Azure, no Azure Stack sai por U$ 40/mês.
Claro que deve-se incluir no TCO a infra do Datacenter, garantia e suporte do HW, administração e energia elétrica que no Microsoft Azure não temos.
Mesmo assim, grandes ambientes que já contam com Datacenter a opção passa a ser vantajosa por já incluir muitos destes custos embutidos.
E se o cliente não quiser pagar por consumo?
Tambem é possivel adquirir o custo por CORE, mas pessoalmente não vejo vantagem pois o custo aumenta pelos seguintes motivos:
- No modelo variável “Pay-As-You-Use” a escalabilidade tambem reflete no preço quando diminuir a carga
- No modelo desconectado é necessário pagar em separado o licenciamento de Windows e SQL que no modelo “Pay-As-You-Use” está embutido
- No modelo desconectado o pagamento é anual e upfront
Todos os Serviços do Azure Estão Disponiveis no Azure Stack?
Ainda não. Como pode-se ver na tabela de preços os mais importantes sim.
Por exemplo, alguns tipos de VMs como G não poderiam rodar no Stack e o mesmo com alguns serviços de alta capacidade como Machine Learning e Cognitive Services.
É possivel criar planos e juntar diferentes soluções para criar workloads complexos, como documentado em https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-offer-services-overview
Conclusão
Azure se tornou o principal produto da Microsoft e com o Stack a integração entre as nuvens pública e privada realmente se torna uma experiencia unica!
Acesse o link da documentação e saiba detalhes do produto: https://docs.microsoft.com/en-us/azure/azure-stack/
Disponivel para Compra o Azure Reserved Instance
Em um post no inicio do mês comentamos sobre o Azure Reserved Instance em http://www.marcelosincic.com.br/post/Reducao-de-Custos-com-Azure-Reserved-Instance.aspx
Agora já está disponivel para compra e tambem na calculadora do Azure (Azure Pricing Calculator) para estimar a economia tanto apenas a VM quanto com o AHUB.
Para relembrar, o AHUB é o recurso que permite economia por utilizar as licenças já adquiridas que tenha Software Assurance http://www.marcelosincic.com.br/post/Software-Asset-Management-(SAM)-Convertendo-Licenciamento-para-Azure.aspx
Utilizando a Calculadora
Acesse a calculadora de custos do Azure e ao acrescentar uma VM verá a opção de incluir o AHUB e tambem o RI de 1 ou 3 anos.
Abaixo seguem as imagens demonstrando como escolher e a redução possivel onde de $102 para uma VM normal, caimos para $58 em uma VM RI de 3 anos e juntando o AHUB para U$ 24!!!!!
E por ultimo com a opção de AHUB:
Comprando Reserved Instance no Portal do Azure
A compra do RI pelo portal exige que primeiro seja ativada a oferta na assinatura.
É importante que assinaturas de beneficio MSDN ou EA Dev/test não possuem o RI pois já tem um custo de 40 a 60% menor nas VMs.
Resumindo: Agora podemos ter uma VM com mais de 80% de desconto juntando as ofertas de RI e AHUB!!!
Software Asset Management (SAM)–Convertendo Licenciamento para Azure
Este tópico é relevante no momento em que estamos de migração para Cloud Publica em muitas empresas.
Dando continuidade a série sobre SAM, vamos pular alguns outros tópicos e dar atenção a Azure. Para ver a lista de assuntos que já abordamos acesse http://www.marcelosincic.com.br/post/Software-Asset-Management-(SAM)-com-System-Center-Configuration-Manager.aspx
Atualização: Conheça o Reserved Instance no artigo http://www.marcelosincic.com.br/post/Reducao-de-Custos-com-Azure-Reserved-Instance.aspx
1 – Utilizando o Licenciamento Normal para VMs Windows (SPLA)
Ao criar maquinas virtuais no Azure já é possivel definir que o sistema operacional é Windows e pagar o licenciamento embutido como parte do serviço.
Esse modelo de licenciamento é chamado de SPLA e permite a um provedor (não existe apenas no Azure) licenciar VMs como serviços faturado ao invés do cliente comprar a licença perpétua como acontece em ambientes on-premisse.
O custo desse licenciamento é medido por comparar valores de VMs iguais com Windows e Linux em https://azure.microsoft.com/pt-br/pricing/details/virtual-machines/linux/ e https://azure.microsoft.com/pt-br/pricing/details/virtual-machines/windows/
No dia que montei esse post o valor hora de uma VM D2 v2 Linux é de U$ 0,159 e a mesma VM com Windows U$ 0,251. Ou seja uma diferença de 43% no preço da VM.
Por essa diferença de preço que temos opções de usar outras formas de licenciamento que falaremos a seguir.
2 – Utilizando AHUB (Azure Hybrid Use Benefit)
O AHUB nada mais é do que usar a sua licença já comprada em contrato com Software Assurance (SA) no Azure e assim não pagar o licenciamento SPLA.
Note porem que sua licença deve ter SA contratado, ou seja o direito de atualização e virtualização. Se não conhece o SA veja o post http://marcelosincic.com.br/post/Software-Asset-Management-(SAM)-com-System-Center-Configuration-Manager-Windows-Desktop.aspx onde temos um tópico sobre isso.
No caso de usar o AHUB a diferença de preço calculada no item anterior não existe, já que o licenciamento passa a ser feito em contratação em Enterprise Agreement, MPSA ou mesmo OPEN. O tipo de contrato depende do valor e é adquirido junto a um parceiro de licenciamento Microsoft (LSP).
A Microsoft já disponibiliza os templates para VMs AHUB mas tambem é possivel usar PowerShell com o parametro –licencetype. No caso se usar o portal, basta criar a VM informando isso:
Porém é importante ressaltar que o AHUB é uma maquina Windows criada com a camada de preço do Linux e não é possivel fazer a alteração pelo portal. Ou seja, será necessário recriar a VM caso ela já exista no modelo normal.
Claro que existem formas mais fáceis:
- Deleta a VM, mas não delete o disco
- Crie uma nova VM como AHUB
- Anexe o disco da VM que foi deletada
3 – Utilizando CPP (Compute Pre-Purchase)
O CPP é um velho conhecido de quem usa AWS, com o nome de RI (Reserved Instance), mas com uma diferença. Veja o link a seguir, mas ele não tem muitos detalhes: https://azure.microsoft.com/pt-br/overview/azure-for-microsoft-software/faq/
Enquanto no AWS o cliente compra uma VM de determinado tipo/camada, no CPP do Azure o cliente compra horas de computação de determinado tipo/camada de VM, seguindo algumas regras:
- Equivalem a compra de 744 horas de um deterninado tipo de VM
- São compradas por 12 meses independente do aniversário do contrato (não tem pró-rata)
- Não são vinculadas a uma VM especifica, funciona como um abatimento nas horas totais
- Não podem ser utilizadas ou realocadas para outros tipos de VM como se fosse proporcional
- É paga upfront, ou seja o valor de 12 meses
A redução de custo é significativa, mas o valor depende do tipo de contrato que o cliente possui e o nivel de desconto, em alguns casos chega a 60% para clientes EA.
Para entender o cáculo, vamos usar uma tabela simples de custo HIPOTÉTICO:
| VM | Quantidade | Horas Total | Valor Normal | Comprado em CPP | Pago em Commitment | Economia |
| D2 v2 | 5 | 3200 | 3200 horas a U$ 0,251
U$ 803,20 | 3 VMs equivalente a 2.232 horas a U$0,16
U$ 357,12 | Saldo de 968 horas
U$ 242,96 | U$ 203,12 |
Mais uma vez é importante ressaltar que essas VMs não podem ser atribuidas a outro tipo, o CPP cobre por 12 meses 744 horas mensais de um deterninado tipo de VM.
Porem, alguns clientes utilizam o CPP para upgrade uma vez que a redução de custo permite com o mesmo valor já provisionado para Azure subir de 2 a 3 camadas as VMs já existentes!
4 – Utilizando CPP + AHUB
É possivel combinar o CPP com AHUB? SIM!!!
Levando em conta que o cálculo acima do CPP foi hipotético, usamos o valor referencia de U$ 0,251 para VMs Windows no CPP com valor de U$ 0,16, ou seja uma VM com o licenciamento Windows SPLA.
Se juntar o desconto que o AHUB proporcional, você poderá comprar VMs Linux e usar o licenciamento que já possui em contrato, como exemplo o valor da mesma VM D2 v2 de U$ 0,159 Linux cairia para U$ 0,12 com Windows utilizando o licenciamento existente.
CONCLUSÃO
Com o CPP você pode economizar de 25 a 60% sem ter que fazer nenhum esforço, e com o AHUB você pode criar VMs muito mais em conta utilizando o contrato existente com Windows.
Claro que o CPP é muito mais atrativo, uma vez que ele não exige mudança no template da VM, mas tanto o AHUB quanto o CPP precisam ser incluidos em contratos de licenciamento.
Agora divirta-se, consulte seu parceiro de licenciamento e veja quanto poderá economizar com estas duas opções de licenças!!!