A algum tempo que já temos disponivel o recurso de comprar antecipadamente uma instância de maquina virtual, chamado de Reserved Instance.

Basicamente o processo se mantem (http://www.marcelosincic.com.br/post/Reducao-de-Custos-com-Azure-Reserved-Instance.aspx) mas temos algumas novidades e alertas:

1. Alteração do tipo de VM
2. Outros recursos que podem ser reservados
3. Mudança na forma de cobrança
4. O que não está incluido em uma reserva

Possibilidade de Alteração da Instância (perfil de VM)

Essa mudança é importante, pois na primeira versão (link acima) não era possivel mudar o tipo de VM.

O processo para mudar era pedir o reembolso da instância já paga (lembrar que existia um penalty) e refazer com outro tipo de VM da mesma familia, como por exemplo de D2 para D4.

Para isso basta utilizar o botão Exchange em uma reserva e será possivel escolher o novo tipo de VM como abaixo sem o penalty dos aproximadamente 12% do cancelamento.

Porem, obviamente que o custo de uma D2 é diferente de uma D4 e para isso temos uma tabela que pode ser usada no calculo para saber o valor da diferença que será pago quando trocar entre os tipos de VM em https://docs.microsoft.com/en-us/azure/virtual-machines/windows/reserved-vm-instance-size-flexibility?wt.mc_id=4029139 

Outros Tipos de Recursos Alem das VMs

Na versão inicial as RIs eram apenas VMs, mas agora é possivel fazer com diversos tipos de serviços. Atualmente segue a lista dos que são suportados:  

• Reserved Virtual Machine Instance
• Azure Cosmos DB reserved capacity
• SQL Database reserved vCore
• SQL Data Warehouse
• App Service stamp fee

Essa lista é alterada conforme novos recursos podem ser agregados e está disponivel em https://docs.microsoft.com/en-us/azure/billing/billing-save-compute-costs-reservations?wt.mc_id=4029139

Importante: Veja o tópico abaixo sobre o que é incluido ou não no RI.

Forma de Pagamento Mensal

Até 8/Setembro/19 só era possivel o pagamento antecipado a partir de créditos do Enterprise Agreeement ou pagamento em cartão de crédito.

Agora é possivel o pagamento mensal, ou seja todos os meses irá consumir o valor com desconto igual ao anual como se fosse uma subscrição mensal e não anual. O melhor para entender é que o compromisso continua anual, mas pago mensal ao invés de upfront.

As outras regras continuam as mesmas, penalty em caso de cancelamento, mudança do tipo de VM ou serviço, etc.

Para os que já tem reservas será necessário aguardar o prazo da compra, uma vez que foi pago antecipado e por isso haveria a cobrança da taxa de cancelamento.

https://docs.microsoft.com/en-us/azure/billing/billing-monthly-payments-reservations?wt.mc_id=4029139

Importante: O pagamento mensal não mudou a forma de reserva ser anual, ou seja haverá o penalty em caso de cancelamento.

Recursos Cobrados em Separado

Uma confusão muito comum nos clientes que compraram RIs é o fato de continuar havendo outras cobranças para as VMs e recursos aparecendo em seus extratos.

O que precisa estar claro é que reservas se referem apenas aos recursos computacionais e não os recursos agregados como licenças, armazenamento e trafego de rede.

Por exemplo, no tipo de reserva para VMs que são as mais comum:

• Incluido no RI: CPU, memória e alocação
• Não incluido no RI: Armazenamento (storage), tráfego de rede (network) e licenciamento do SO se não foi utilizado o AHUB

O motivo é que estes recursos não incluidos fazem parte da subscrição e são compartilhados ou opcionais (como é o caso da licença do Windows ou SQL) e não haveria como limitar ao uso apenas daquelas reservas especificas, alem de serem voláteis diferente do tipo de uma VM por exemplo.

Conclusão

Com os novos recursos que podem ser reservados, flexibilidade na alteração, a nova forma de cobrança e o entendimento correto pode-se gerar uma economia substancial para aqueles que migraram serviços.

Duas aplicações mais consomem storage em ambientes de TI:

• Banco de dados – Por conterem dados analiticos e indexados podemos utilizar tecnicas de drill down para separar os dados analiticos dos dados resumidos facilitando o acesso e otimizando custos
• File Server – Ao longo dos anos as empresas acumulam milhares de arquivos, o que custa caro e raramente é agrupado ou tierizado

Vamos abordar como utilizar o Azure File Sync para criar uma tierização dos dados em um File Server para permitir que arquivos mais acessados fiquem localmente guardados e os mais antigos apenas em nuvem.

Cenários Frequentes

O primeiro cenário é o de diminuir o tamanho total de espaço ocupado por arquivos antigos.

Nesse caso utilizamos as configurações de data do arquivo e espaço livre desejado para diminuir o espaço em disco que o File Server ocupa, liberando para uso com outras necessidades.

O segundo cenário é servidor de arquivos distribuidos, onde em cada filial da empresa é necessário ter um servidor para acessar os dados.

Nesse exemplo todos os servidores replicam a mesma pasta, o que não cria problemas de saturação local, já que o cache é apenas dos arquivos recentes e controlado pelo percentual desejado de espaço livre a ser mantido.

Componentes do Azure File Sync

1. Storage Account – Um storage virtual onde os dados serão armazenados
2. File Share no Storage Account – Pasta dentro do Storage Account para receber os arquivos que serão enviados
3. Azure File Sync Service no Market Place – É o serviço e deve ser habilitado, diferente de outros serviços nativos. Porem, apesar de estar no Market Place o AFS não tem um custo, trata-se apenas da inclusão de um serviço
4. File Sync Service – É o serviço no painel do Azure onde podemos criar os grupos, incluir os servidores e configurar storage
5. Registered Services (servidores) – São os servidores que serão sincronizados, onde os arquivos estão armazenados e servirão de cache
6. Sync Group – Forma a lista de servidores que irá receber a cópia dos arquivos a serem copiados e dar acesso aos arquivos em qualquer localidade

Criando um Storage

Esse é o primeiro passo e bem conhecido de quem já utiliza o Azure, uma vez que para tudo precisamos de um storage.

Para usar o AFS não é necessário qualquer configuração adicional, você poderá escolher qual região, tipo de storage e replicação que melhor se aplique ao seu ambiente. Obviamente algumas coisas precisam ser levadas em conta:

• O tipo de conta envolve a performance maxima e irá afetar tanto o download quanto upload quando os usuários utilizam os arquivos
• Replicação é importante se você terá servidores em várias localidades/paises
• Camada Hot or Cold envolve a performance diretamente e tambem o custo, já que o acesso é bem lento em discos Cold e não recomendaria para uma solução como essa

Na sequencia é necessário criar o File Share para onde os arquivos irão quando sincronizados, e o conceito é o mesmo de um servidor comum:

Quando sincronizado, os arquivos irão aparecer primeiro na pasta Sincronization e depois na pasta principal como podemos ver abaixo.

Lembrando que as duas telas acima se referem a sincronização já finalizada, a primeira para ver os arquivos sendo copiados e a segunda quando a primeira sincronização já finalizou.

Habilitando o Azure File Sync

Procure no Marketplace pelo Azure File Sync ou Serviço de Sincronização do Azure em portugues:

Nesse momento pode-se optar por utilizar um Resource Group existente ou um novo, não importando em qual Resource Group o Storage foi criado, uma vez que ele pode ter varios outros serviços atribuidos.

Criando o Serviço de Sincronização

A criação do grupo de sincronização é bem simples, bastante indicar a assinatura, storage e a pasta compartilhada definida anteriormente.

Registrando Servidores de Arquivos

Você poderá indicar servidores:

• Novos servidores que não tenham arquivos e incluí-los em um grupo já sincronizado para que ele sirva de cache dos arquivos que já estão na pasta compartilhada do Storage no Azure
• Servidor com dados onde o conteudo será copiado para o Azure e acrescentado

O primeiro passo é instalar as bibliotecas PowerShell do Azure (AZ) no servidor, o que pode ser feito seguindo os passos na página https://docs.microsoft.com/pt-br/powershell/azure/install-az-ps?view=azps-2.6.0&wt.mc_id=4029139

Após ter o Azure CLI instalado, baixe e instale o Agente de Sincronização que é muito simples de ser feito.

Após isso, já será possivel ver o servidor no painel do Azure:

Nesse passo não é necessário configurações nem qualquer definição adicional, já que se trata de uma operação simples de agente.

Criando o Endpoint (Servidores Cache)

Aqui é onde realmente criamos o serviço e vemos a mágica acontecer!

Entrando dentro do grupo de sincronização que criamos anteriormente e usar a opção Adicionar ponto de extremidade ou Add Endpoint para incluir o servidor no grupo que criamos.

Vamos ver as opções que estão listadas:

1. Caminho – É o diretório que queremos que fique sincronizado, lembrando que se estiver vazio para um grupo já existente ele irá baixar o conteudo conforme for sendo utilizado. Se for um servidor que já contem arquivos, esses serão carregadso para o Azure.
   Importante: Não é possivel usar a unidade root (C:) e sim um disca parte por conta dos arquivos de sistema.
2. Percentual livre no volume – Não definimos quanto irá ser usado para cache e sim quanto de espaço no volume deverá ficar livre. Pode parecer um calculo invertido mas não é por conta de outros arquivos que o mesmo disco contenha. Por exemplo, se o volume é de 100GB e contem outros arquivos totalizando 40GB e definirmos que queremos deixar 50% do disco livre, apenas 10GB será usado pelo cache (50% de 100GB=50GB sempre livre) e conforme o uso de outros arquivos aumentar que não sejam sincronizados, menos irá ter espaço para o cache.
   Dica: Por conta dessa dificuldade, prefira utilizar um volume dedicado para fazer o File Sync
3. Cache apenas de arquivos acessados ou modificados a x dias – Vimos que temos a opção de preservar um percentual do disco. Mas e se arquivos antigos ocupam muito espaço não irá adiantar muito. Nesse caso do meu exemplo qualquer arquivo com mais de 60 dias irá automaticamente para o Azure e será deletado no disco do servidor, ganhando espaço livre mesmo que o percentual de cache ainda esteja disponivel.

Ao finalizar essa configuração já é possivel acompanhar a sincronização clicando no servidor:

Assim que sincronizado, podemos usar os paineis de metricas abaixo da tela para criar alertas quando ocorrerem erros ou distorções:

No meu exemplo posso utilizar uma regra que se o numero de arquivos sincronizados for maior que 100 para upload no intervalo de 15 minutos pode ser uma alteração em massa causada por uma cópia indevida ou mesmo um malware.

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.