Azure File Sync–Otimizando seu File Server e Storage

28 agosto 2019 msincic Azure, Cloud computing, Hardware, Microsoft Azure, Virtualizaçao
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 Tierização: Tecnologia onde os dados são separados conforme regras de performance em discos mais caros ou mais baratos. Por exemplo, arquivos pouco usados ficam em discos SATA, arquivos com acesso ocasional em discos SAS e arquivos que são acessados diariamente em discos SSD. 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 Storage Account – Um storage virtual onde os dados serão armazenados File Share no Storage Account – Pasta dentro do Storage Account para receber os arquivos que serão enviados 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 File Sync Service – É o serviço no painel do Azure onde podemos criar os grupos, incluir os servidores e configurar storage Registered Services (servidores) – São os servidores que serão sincronizados, onde os arquivos estão armazenados e servirão de cache 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: 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. 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 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.

Azure Virtual Datacenter (VDC) Parte I- Migração AS IS e TO BE

06 março 2019 msincic Azure, Cloud computing, Hardware, Log Analytics, Microsoft Azure, Virtualizaçao
Quando trabalhamos em um projeto de migração para Public Cloud e o desenho é voltado a Azure, é muito comum os cenários de “AS IS”. AS IS Para os não iniciados com este termo, “AS IS” significa levar como está me ingles, ou seja copiar as VMs de um ambiente a outro sem qualquer alteração, utilizando o Azure como um virtualizador. Em geral os modelos de migração AS IS não são eficientes, pois consomem muito recursos em IaaS (VMs) que custam caro, não aproveitando nada de serviços (SaaS ou PaaS) que são mais baratos. Porem, a vantagem é que é mais rápido e não exige mudanças. TO BE (ou LIft and Shift) Já as boas migrações são as “TO BE”, que em tradução livre seria “SERÁ” no sentido de transformação. O modelo de migração TO BE tem como premissa usar os serviços e não apenas migrar VMs. Migrações TO BE são trabalhosas e mais demoradas, uma vez que esse mapeamento envolve entender o que está DENTRO DAS VMs. O custo de execução é muito menor pois SaaS e PaaS tem vantagens financeiras grandes quando comparados ao modelo de IaaS. Por exemplo, no AS IS um servidor IIS e outro de SQL serão simplesmente copiados os discos virtuais e iniciados. Já no modelo TO BE iremos isolar cada uma das aplicaçÕes que o IIS executa e criar Web Plan para isolamento e Web Services para cada site, e no caso do SQL Server usariamos o serviço de Banco de Dados (SaaS ou PaaS). Utilizando o Service MAP O primeiro passo para fazer uma migração é mapear o que cada VMs ou servidor fisico executa no ambiente. Para isso utilizamos o Service MAP: http://www.marcelosincic.com.br/post/Azure-Log-Insigths-Service-Map.aspx Com ele será possivel ver as interligações e serviços que cada servidor utiliza entre no ambiente e mapear qual serviço temos para substituir. Entendendo o Conceito de Datacenter do Azure Para desenhar um datacenter usando VMWare, Hyper-V ou KVM é necessário que o desenho dos hosts, rede e outros detalhes sejam feitos por especialistas no hypervisor. O mesmo vale para Azure, precisamos entender os diferentes componentes para desenhar um datacenter com seus recursos. Para isso, é necessário estudar, e muito.   Tambem é necessário quebrar os paradigmas de datacenter fisico e pensar em serviços. Uma das formas de fazer isso é utilizar o Guide da própria Microsoft disponivel em https://docs.microsoft.com/en-us/azure/architecture/vdc/ Esse guia tem todas as perspectivas de um datacenter virtual, o ajudará a entender a camada de virtualização, rede, segurança, serviços e o lift and shift, ou seja a transformação para um modelo mais eficiente. Para começar baixe a apresentação disponivel em https://aka.ms/VDC/Deck Conclusão Não é fácil fazer uma migração correta, mas é possivel e o resultado será muito melhor. Ao longo do mês iremos explorar os itens que compõe o VDC e verá que é possivel fazer esse tipo de migração com recursos novos, mais eficientes e custos apropriados.

Microsoft ATA–Recuperação e Migração

24 outubro 2018 msincic Active Directory, Windows ATA, Azure
Já falamos anteriormente sobre o Microsoft ATA (Advanced Threat Analytics) em http://www.marcelosincic.com.br/post/Microsoft-Advanced-Thread-Analytics-(ATA).aspx Agora houve uma grande atualização com a versão 9 que tornou o ATA mais leve em demanda de recursos e visualização dos reports. Porem, durante a migração é possivel que ocorram perdas de conexão ao MongoDB e ser necessário fazer o backup e restore. O mesmo processo talvez seja necessário quando se troca de servidor ATA. Importante: Os dados do Security Log do Windows é enviado ao Machine Learning para gerar os incidentes e alertas, mas ficam hospedados localmente. Portanto se perder o servidor não terá mais os reports e incidentes já registrados. Realizando o Backup do ATA Para fazer o backup da configuração do ATA é utilizado a cópia do arquivo SystemProfile_yyyymmddhhmm.json que fica na pasta de instalação do ATA em um subdiretório Backup junto com as ultimas 300 cópias dos dados. Esse arquivo SystemProfile é a base de dados do MongoDB em formato JSON, eliminando a necessidade de fazer backup a partir do Atlas ou outra ferramenta especifica para administração do MongoDB. Isso é muito bom, pois não é comum conhecermos adminsitração do MongoDB. Para funcionar deve-se ter a cópia do certificado usado para criptografia do arquivo JSON, que é gerado durante a instalação (Self-signed). A cópia do certificado só precisa ser feita uma vez, abra o console do MMC com o snap-in Certificados e encontre o certificado de nome Central do ATA na área de certificados Pessoas em Local Machine. Com estes passos temos o backup das configurações do servidor que são o JSON e o certificado. Mas e os dados do ATA? Para fazer backup do ATA é necessário como já falado conhecer as ferramentas do MongoDB e talvez você deva pensar se precisará deles uma vez já resolvidos. Se a sua necessidade é manter os alertas e incidentes, siga a documento em https://docs.mongodb.com/manual/core/backups/ de como fazer backups da base. Realizando o Restore do ATA A parte de restore do ATA em um novo servidor ou configuração de uma nova versão é um pouco mais complicado que o backup que é bem simples. Primeiro é necessário importar o certificado exportado no passo anterior na mesma árvore da qual fez no passo anterior. Em seguida é necessário reinstalar normalmente o novo servidor ATA com o mesmo nome e IP anterior e no momento que ele pedir o certificado desativar a opção Create Self-signed” para escolher o certificado original. Em sequencia precisamos parar o serviço Centro ATA para podermos abrir o MongoDB e importar o arquivo JSON com os seguintes comandos: mongo.exe ATA db.SystemProfile.remove({}) mongoimport.exe --db ATA --collection SystemProfile --file "<Arquivo JSON> --upsert Observação: Primeiro comando abre a instancia, o segundo remove as configurações vazias e o terceiro importa a nova configuração. Não é necessário recriar os Gateways pois eles são mapeados automaticamente quando se restaura as configurações. Caso você tenha feito backup da base de dados do MongoDB siga o procedimento de restore da base antes de reiniciar o serviço do ATA. Referencia: https://docs.microsoft.com/pt-br/advanced-threat-analytics/disaster-recovery

EOL do Windows e SQL 2008–Opções de Extensão

22 julho 2018 msincic Azure, Microsoft Azure, Windows 2008, SQL Server, Windows
Como já é conhecido, o ciclo de vida de produtos da Microsoft para 2019 incluem o Windows e SQL 2008 RTM e R2. Fonte: https://support.microsoft.com/pt-br/lifecycle/search  Porque isso é importante? Esse é um problema típico nas grandes empresas, controlar o ciclo de vida do suporte dos produtos que estão implementados. Esse assunto não é de menos importancia, pois ter o suporte finalizado implica: Novas ameaças de segurança, mesmo as que envolvem brechas de software, não são mais disponibilizadas para os sistemas expirados Novos recursos em novos produtos não tem garantia de funcionamento nos produtos expirados O primeiro item é importantissimo. Imagine que sua empresa está vulnerável a um ataque como muitos que vimos, pois apenas UM SERVIDOR em seu ambiente é expirado!!! O que fazer se tenho produtos que expiram? Obviamente que a melhor opção é migrar (“TO-BE”), mas sabemos que nem sempre é possivel. O que pode ajudar é usar produtos como o Service Map do Log Insights (http://www.marcelosincic.com.br/post/Azure-Log-Insigths-Service-Map.aspx). Mas para quem não pode fazer o upgrade, uma das opções é comprar o suporte via Premier para mais 3 anos, que não é barato mas é possivel negociar através do seu time de contas Microsoft. O custo para extender o suporte POR ANO é equivalente a 75% do software full na versão mais atual. Porem, a Microsoft disponibilizou uma opção bem interessante que é migrar para Azure “AS-IS”!!!! Isso mesmo, quem migrar para Azure o Windows 2008 e SQL Server 2008 não precisará se preocupar pois terão gratuitamente o suporte por 3 anos adicionais. https://azure.microsoft.com/pt-br/blog/announcing-new-options-for-sql-server-2008-and-windows-server-2008-end-of-support/ Não precisamos nem discutir que é uma estratégia para aumentar o uso de Azure, mas muito boa financeiramente para qualquer workload que possua.

Adoção Assistida do Office 365 e Azure com o FastTrack

17 julho 2018 msincic Azure, Microsoft Azure, Office 365, Cloud computing
Ao convertermos novos clientes que tinham produtos on-premisse para produtos on-line sempre temos o impacto inicial da migração. Se o cliente comprou na modalidade CSP (Cloud Solution Provider) a configuração inicial é toda realizada pelo parceiro e a migração dos dados em geral tambem já é incluida como um serviço. Afinal, é importante lembrar que no modo CSP quem detem a conta é o parceiro pois é um modelo gerenciado. Já no modelo de Licensing Partners, seja com contrato MPSA ou Enterprise Agreement (EA) o dono da conta e do tenant é o próprio cliente. Isso quer dizer que cabe ao cliente criar a tenant, habilitar os serviços, configurar e migrar os dados. Como fazer o kickoff do Office 365 sem “dores” e com a melhor estrutura? A resposta obvia seria contratar um parceiro de serviços Microsoft especializado em Office 365 que fará todo o processo, mas muitas vezes não é o que será feito. Nestes casos, é possivel acionar o FastTrack. O que é o Microsoft FastTrack? Em termos básicos o FastTrack é um site contento todo um repertório de ferramentas para quem já tem ou adquiriu Office 365 em contrato direto (MPSA ou EA). https://fasttrack.microsoft.com  Ao entrar no site poderá iniciar vendo um Dashboard do seu estado atual como abaixo: Note que logo na primeira parte vemos o nome do meu tenant de testes, os dados incluindo algumas informações da empresa e o gerente do FastTrack, Engenheiro e Arquiteto. Quem são essas figuras? Alguns clientes, principalmente na adoção possuem o beneficio de engajar um time da MS para ajudar no planejamento e execução da migração. Isso não quer fizer que irão executar, mas sim orientar e apoiar no processo de criação do tenant, integração do AD (AADSYNC), configuração dos serviços e o processo de migração em sí. Para saber se você é elegivel, veja “Ofertas” e “Serviços”: O primeiro item “Ofertas” não são migrações e sim documentação gerada para compliance e arquivamento. Já o item “Serviços” é onde poderá solicitar que a Microsoft engaje o time para executar as funções desejadas. Note que não apenas Office 365, mas tambem Planning de deploy de Windows (neste caso é necessário ter voucher de Planning Services) e um parceiro para ajudar com Windows 10 se ainda não migrou. Tambem temos a opção de Azure, mas ela só é disponivel para alguns paises e o cliente precisa consumir no minimo U$ 5000 mês. Em qualquer dos casos, a Microsoft envia um email com mais informações para você e iniciará o processo conforme o tipo de solicitação. E se já tenho o tenant e utilizo, que valor tenho no FastTrack? Mesmo assim é interessante. Acesse o link https://myadvisor.fasttrack.microsoft.com Esse site tem uma lista de recursos onde você poderá baixar apresentações, guias, modelos de emails e videos educativos. A unica restrição é que todo o conteudo está em inglês    De qualquer forma, ferramentas como o “Network Planner” para validar necessidade de link é importantissimo para o primeiro momento. Tambem podemos destacar os videos e documentos onde podemos aprender mais sobre os recursos e o passo-a-passo de uma estória de sucesso! Desenho de Cenários (Planos de Sucesso) Uma opção bem interessante é a criação dos Planos de Sucesso que pode ser visto na primeira tela deste post. Ao criar um plano e escolher o produto, será guiado a um checklist completo onde poderá escolher o que irá fazer e o site irá ajudar a trilhar o caminho correto. Uma ajuda muito útil quando estamos fazendo a implementação e não queremos deixar algo passar! E um recurso interessante é que você poderá acessar videos para ajudar na adoção do produto desejado pelos usuários finais. Conclusão Se está implantado, já tem funcionando apenas com alguns produtos ou está evoluindo o ambiente, o FastTrack irá ser uma ajuda enorme para o sucesso!

Azure Log Insights–Service Map

03 julho 2018 msincic Log Analytics, Azure, Azure OMS
Muitos já conhecem o Log Insights que antes era chamado de Operations Management Suite. Nesse post vou destacar um dos muitos plug-ins de solução do Log Insights (chamados de Solutions no portal) que é o Service MAP NECESSIDADE Migrar um Datacenter não se resume a levar servidores de um lado para outro, muitas vezes é necessário migrar ambientes por perfil de aplicações. O objetivo nestes casos é saber quais servidores devem ser migrados juntos para não ter problemas de comunicação tanto entre a mesma aplicação como tambem entre o serviço e os clientes. O problema muitas vezes é conseguir mapear isso, pois poucas empresas possuem um mapa de aplicaçoes onde conste os servidores e serviços utilizados em cada aplicação, principalmente aplicações Web e Bancos de Dados. SOLUÇÃO A Solution Service Map do Log Insights resolve este problema! Ela mapeia todas as comunicações que são realizadas com os servidores com o agente instalado e monta um mapa completo do uso detalhando portas, nomes, serviços e permitindo drill-down para visualizar as conexões e um painel de detalhes para cada item selecionado. Segue abaixo alguns prints que utilizo para demonstrar o recurso: Visualização dos serviços em um dos servidores e detalhes do servidor selecionado. Note que do lado esquerdo é possivel ver a barra de detalhes do servidor mapeado a partir de outros Solutions ativos em seu Log Insights. Detalhes de um dos servidores que se comunica com o host, com detalhes da comunicação e do servidor. Ao abrir o servidor selecionado na tela anterior posso ver os detalhes dele, incluindo agora os desktops e outros servidores que tambem utilizam o target selecionado. Visualizando os detalhes de comunicação entre o servidor target e o servidro com SQL Server onde podemos ver as comunicações do SQL para autenticação, já que o target é meu Domain Controller. Aqui podemos visualizar no conceito de grupos onde os servidores que inclui o grupo são mapeados e pode ser utilizado para criar os mapas de determinada aplicação. Baseado no gráfico acima, consigo visualizar que o host T110 possui duas VMs principais que se comunicam com todos os clientes e entre eles constantemente. Se for criar um plano de migração do meu ambiente já saberia que elas são as duas principais VMs que precisam ser ativadas juntas na migração. UTILIZANDO O SERVICE MAP Para utilizar o Service Map você obviamente deve ter uma conta Log Analytics já habilitada e incluir a Solution. O levantamento dos dados não é realizado pelo agente normal do Log Insigths, é necessário baixar um agente especifico que pode ser encontrado no link abaixo: https://docs.microsoft.com/en-us/azure/monitoring/monitoring-service-map-configure Logo após instalar o agente do Service Map já será possivel visualizar os mapas e utilizar grupos. Importante: O Service Map só mantem dados de 1 hora no máximo, portanto é um portal para visualização imediata já que não possui histórico nem relatórios analíticos. Referencia completa: https://docs.microsoft.com/en-us/azure/monitoring/monitoring-service-map

Disponivel para Compra o Azure Reserved Instance

20 novembro 2017 msincic Azure, Microsoft Azure
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!!!