Amazon

Backup Gratuito VMware e Hyper-V – Unitrends Free – 1 TB pra suas máquinas virtuais

Unitrends Free - 1 TB de Backup Gratuito pra VMware e Hyper-V
Backup gratuito VMware e Hyper-V
Já falamos aqui algumas vezes sobre alternativas de backup para ambientes virtuais VMware e Hyper-V, inclusive destacando algumas soluções gratuitas.
Como parte do processo de atualização do treinamento VMware do Tecnologia que Interessa!, resolvi que vou abordar soluções gratuitas de backup, além das versões 5.5 e 6 do vSphere, de forma pioneira aqui no Brasil.
Então resolvi estudar mais a solução Unitrends, que provavelmente será a solução escolhida para abordar no treinamento, junto com o Veeam Backup.
Abaixo algumas características da versão gratuita da solução de backup que me chamaram a atenção:
  • Proteção ilimitada de VMs;
  • Integração com nuvens da Amazon e Google;
  • Agendamento automático;
  • Recuperação instantânea de VMs;
  • Backups incrementais “forever” (otimizam espaço em disco e reduzem janela de backup);
  • Limite de 1 TB de dados armazenados na versão gratuita.

 

Você sabia que pode baixar GRATUITAMENTE algumas das melhores soluções de backup para VMware e HYPERV do mercado?

Algumas são GRATUITAS PRA SEMPRE!!!

Veeam Availability Suite

Veeam Backup & Replication

Veeam Availability Orchestrator

Veeam backup for Agents: Linux & Windows

Veeam Backup for Microsoft Office 365

Veeam Backup for Nutanix AHV

Veeam Backup for Azure

Conclusão

O modelo Freemium é cada vez mais comum nos mais diversos mercados, e as soluções de backup não seriam exceção.
O momento é extremamente interessante para pequenas e médias empresas, que podem aproveitar uma infinidade de soluções de maneira gratuita e adiar seus custos para o momento em que a empresa crescer e tiver efetivamente mais condições de arcar com soluções de maior porte.
E você, está usando alguma solução gratuita de backup pro seu ambiente virtual ? Diz aí!Quer ter mais dicas essenciais pra administrar melhor seu backup? Clique AQUI.
SAIBA MAIS…O erro #1 que sysadmins cometem ao fazer backup de seus servidores virtuais
Veeam Endpoint Backup – ferramenta gratuita para backup de estações e servidores físicos e virtuais
4 ferramentas gratuitas para backup de VMware (inclusive ESXi gratuito) e Microsoft Hyper-V
Onde obter entre 100 GB e 10 TB gratuitamente na nuvem (atualizado!)
Alternativas de #backup para ambientes virtualizados
Backup múltiplo automágico com Dropbox, Skydrive e Google Drive
#Backup gratuito do seu ambiente virtual com o #Veeam Backup Free Edition
#FISL 13: Tape’s not dead
O problema da deduplicação
Veeam oferece soluções para ambiente VMWare ESX
FISL 9: Backup prático, porque precisamos evoluir!
Back In Time simplifica backup do Linux
Faça backup dos seus dados na nuvem
Sincronize suas pastas e computadores com simplicidade
Restore: backup multiplataforma com software livre
Backup online
Wuala une backup online e rede social
Veeam SureBackup faz verificação automática de backups no #VMware
Backup simplificado de GPOs

Amazon Web Services: Tudo que Você Deve Saber – Parte 10 (Arquitetura Lambda/Serverless)

Amazon Web Services: Tudo que Você Deve Saber



Serverless Computing

Serverless Computing é uma arquitetura tecnológica que permite abstrair as questões físicas ao desenhar e implementar aplicações, de forma que não é necessário se preocupar “tanto” com questões como a quantidade de memória, cpu e armazenamento necessários. Para saber mais a respeito, vale a pena consultar este ótimo guia.

Vamos descrever, na parte final deste tutorial sobre a Amazon Web Services, um serviço que oferece a possibilidade de adotar esta nova arquitetura para o desenvolvimento dos seus projetos. Este serviço se chama Lambda.
AWS Lambda

  • 📒 Página InicialGuia de DesenvolvimentoFAQPreços
  • Lambda é um serviço relativamente novo (lançado no final de 2014) que oferece um tipo diferente de abstração de computação: uma função definida pelo usuário que pode executar uma pequena operação, onde a AWS gerencia provisionamento e agendamento de como é executado.

Dicas de Lambda





  • O que significa serverless (sem servidor)? Essa idéia de usar Lambda para a lógica da aplicação cresceu para ser chamada sem servidor, pois você não gerencia explicitamente qualquer instância do servidor, como faria com o EC2. Este termo é um pouco confuso, uma vez que as próprias funções trabalham, naturalmente, em servidores gerenciados pela AWS. A Serverless, Inc. também usa essa palavra para o nome de sua empresa e seu próprio framework de código aberto, mas o termo geralmente é usado de forma mais geral. O lançamento de Lambda e do API Gateway em 2015 desencadeou uma adoção surpreendentemente rápida em 2016, com muitas pessoas escrevendo sobre arquiteturas sem servidor em que muitas aplicações tradicionalmente resolvidas pelo gerenciamento de servidores EC2 podem ser criadas sem gerenciar explicitamente servidores.
  • Frameworks: Muitos frameworks para criar e gerenciar implantação sem servidor estão surgindo.
  • A Estrutura sem servidor é uma nova abordagem dirigida para ajudar a agrupar e gerenciar funções Lambda. Está se aproximando da versão 1 a partir de agosto de 2016 e é popular entre um pequeno número de usuários.

Alternativas Lambda e Lock-in

Problemas e Limitações do Lambda



  • Lambda é uma nova tecnologia. Desde 2016, apenas algumas empresas estão usando isso para aplicações de produção em larga escala.
  • Gerenciando muitas funções da Lambda é um desafio de fluxo de trabalho, e as ferramentas para gerenciar implantações de Lambda ainda são imaturas.
  • Atualmente, desde outubro de 2016, a Lambda às vezes pode parar de funcionar por 2-3 minutos para as alertas de recuperação de falhas, de acordo com uma resposta do suporte da equipe de desenvolvimento da Lambda. A Amazon está trabalhando para evitar isso no futuro.
  • Lambda tem vários limites de recursos até 2017-06:
    • Um tamanho de carga de solicitação ou resposta de 6MB.
    • Um limite de 50 MB no tamanho de pacote de implantação de arquivo .zip / .jar compactado.
    • Um limite de 250 MB no código / dependências no pacote antes da compressão.
Amostras de Código Lambda

  • Fan-out é um exemplo de usar Lambda para copiar dados de um serviço, neste caso Kinesis, para vários outros serviços de dados AWS. Os destinos para dados de fan-out na amostra incluem IoT, SQS e muito mais.
  • Este monitor de limite AWS usando Lambdas mostra o uso de vários Lambdas para monitoramento.
  • Este Lambda ECS Worker Pattern mostra o uso de Lambda em um fluxo de trabalho onde os dados de S3 são retirados pela Lambda, empurrados para uma fila, depois enviados para a ECS para mais processamento.
  • O Secure Pet Store é uma aplicação Java de exemplo que usa Lambda e API Gateway com o Cognito (para a identidade do usuário).

Amazon Web Services: Tudo que Você Deve Saber – Parte 9 (Big Data com EMR)

Amazon Web Services: Tudo que Você Deve Saber

Amazon EMR
É óbvio que, dentre a infinidade de serviços que a Amazon oferece através da sua plataforma de computação em nuvem, haveria algum serviço voltado para análise de grandes volumes de dados.
Sim. Este serviço existe.
E atende pelo nome de Elastic Map Reduce (EMR).

A rigor, hoje o serviço se estende para muito além do map-reduce, oferecendo implantação gerenciada de Hadoop, HBase e Spark e reduzindo o ônus de gerenciamento de configurar e manter esses serviços você mesmo.

Alternativas ao EMR e Lock-in


  • A maioria dos componentes do EMR é baseada em tecnologia de código aberto que, em princípio, pode ser implantada por qualquer um, em qualquer lugar. No entanto, os fluxos de trabalho e muitas outras ferramentas são específicos do AWS. A migração de EMR para seus próprios clusters é possível, mas nem sempre simples.

Dicas de EMR


  • A EMR conta com muitas versões do Hadoop e outros softwares de suporte. Certifique-se de verificar quais versões estão em uso para usar as ferramentas mais adequadas ao seu projeto.
  • O EMR e o Hadoop disponíveis podem ter sobrecarga significativa quando comparados com o processamento eficiente em uma única máquina. Se seus dados forem pequenos e o desempenho for importante, você pode considerar alternativas, como esse post ilustra.
  • Os programadores Python podem querer dar uma olhada na mrjob da Yelp.
  • Uma vez que os trabalhos de EMR são faturados em uma granularidade de uma hora, considerando a alteração do número e/ou do tipo de instâncias que o trabalho executa para melhor fazer uso desse tempo (instâncias menores para fazer uso mais eficiente de uma hora não subscrita, instâncias maiores para reduzir o tempo de execução do seu trabalho).
  • É preciso tempo para ajustar o desempenho dos trabalhos EMR, e é por isso que serviços de terceiros como o Qubole’s data service estão ganhando popularidade como formas de melhorar o desempenho ou reduzir custos.

EMR – Problemas e Limitações


  • Os custos de EMR podem aumentar rapidamente, pois envolvem muitos fatores, a eficiência pode ser fraca, dependendo da configuração do cluster e da escolha da carga de trabalho, e os acidentes como os trabalhos suspensos podem custar caro. Vale a pena avaliar o uso das instâncias Spot e evitar o faturamento por hora. Este post tem dicas adicionais.
  • Cuidado com o “mergulho duplo”. Com EMR, você paga pela capacidade da EC2 e as taxas do serviço. Além disso, o EMR sincroniza registros de tarefas para S3, o que significa que você paga o armazenamento e as solicitações PUT nas taxas padrão de S3. Enquanto os arquivos de registro tendem a ser relativamente pequenos, todo trabalho Hadoop, dependendo do tamanho, gera milhares de arquivos de log que podem somar milhares de dólares na conta da AWS.  O log de dados da YARN  não está disponível no EMR.

Amazon Web Services: Tudo que Você Deve Saber – Parte 8 (IPs Elásticos)

Amazon Web Services: Tudo que Você Deve Saber

IPs Elásticos

  • 📒 DocumentaçãoFAQPreços
  • Os IP Elásticos são endereços IP estáticos que você pode alugar da AWS para atribuir a instâncias EC2.

Dicas de IPs Elásticos



  • Prefira balanceadores de carga para IPs Elásticos: para implementações de instância única, você poderia simplesmente atribuir IP elástico a uma instância, dar a esse IP um nome DNS e considerar sua implantação. Na maioria das vezes, você deve fornecer uma balanceador de carga:
    • É fácil adicionar e remover instâncias de balanceadores de carga. Também é mais rápido adicionar ou remover instâncias de um balanceador de carga do que reatribuir um IP Elástico.
    • É mais conveniente apontar registros de DNS para carregar balanceadores, em vez de apontá-los para IPs específicos que você gerencia manualmente. Eles também podem ser alias de Route 53, que são mais fáceis de mudar e gerenciar.
    • Mas em algumas situações, você precisa gerenciar e corrigir endereços IP de instâncias EC2, por exemplo, se um cliente precisar de um IP fixo. Essas situações exigem IP elásticos.
  • Os IPs Elásticos são limitados a 5 por conta. É possível requisitar mais.
  • Se um IP Elástico não estiver conectado a um recurso ativo, há uma pequena taxa horária.
  • IP Elásticos não tem carga extra desde que você os esteja usando. Eles tem um custo (pequeno) quando não está em uso, que é um mecanismo para evitar que pessoas se criem números excessivos de endereços IP.

IP Elástico: Problemas e Limitações



  • oficialmente nenhuma maneira Para alocar um bloco contíguo de endereços IP, algo que você pode desejar ao fornecer IPs para usuários externos. Embora ao alocar de uma só vez, você pode ter sorte e fazer parte do mesmo bloco CIDR.

Amazon Web Services: Tudo que Você Deve Saber – Parte 7 (Auto Escala)

Amazon Web Services: Tudo que Você Deve Saber

Auto Escala

Os recursos de Auto Escala da Amazon são os responsáveis pela “mágica da elasticidade”, talvez a maior vantagem ao migrar serviços para a nuvem.

Com a elasticidade, é possível aumentar (e diminuir!) automática e dinamicamente, com base em diversos critérios, o tamanho da infraestrutura que deve estar disponível para os usuários do seu serviço.
Todo mundo conhece alguma história de um site/serviço que caiu porque não aguentou a demanda num momento de pico.
Com recursos de Auto Escala, é possível se preparar e evitar este tipo de incidente altamente danoso para a imagem da empresa.
Sabe o que é pior? Muitas pessoas, ao terem uma experiência ruim num site, nem reclamam. Simplesmente não voltam mais. Nunca mais.
Então, é hora de saber como usar este recurso valioso pra garantir alta disponibilidade pro seu site, não acha?

Informações básicas sobre Auto Escala


  • Grupos de Auto Escala (ASGs) São usados para controlar o número de instâncias em um serviço, reduzindo o esforço manual para fornecer ou desprovisionar instâncias EC2. Eles podem ser configurados através de políticas de escalas para aumentar ou diminuir automaticamente a quantidade de instâncias com base em métricas como a utilização de CPU, ou com base em um cronograma.
  • Existem três maneiras comuns de usar ASGs – dinâmico (ajuste automático da quantidade de instâncias com base em métricas como a utilização da CPU), estático (mantenha uma quantidade de instâncias específica em todos os momentos), agendada (mantenha diferentes quantidades de instâncias em diferentes horários do dia ou em dias da semana).
  • ASGs não tem custo adicional simplesmente pela ativação do recurso. Você paga pelos serviços EC2 e CloudWatch subjacentes, ou seja, paga pela capacidade a mais que usar e pelo monitoramento das instâncias para identificar o momento de aumentar ou diminuir a sua quantidade.

Dicas de Auto Escala

  • Combinar o tamanho do seu cluster com seus requisitos de recursos atuais através do uso de ASGs pode resultar em economia de custos significativa para muitos tipos de carga de trabalho. Ou seja, usar Auto Escala evita desperdício!
  • Emparelhar ASGs com balanceadores de carga (CLBs) é um padrão comum usado para lidar com mudanças na quantidade de tráfego que recebe um serviço.
  • O dimensionamento automático dinâmico é mais fácil de usar com serviços horizontalmente escaláveis (Scale Out).
  • Mesmo se você não estiver usando ASGs para aumentar ou diminuir dinamicamente a quantiadade de instâncias, você deve considerar seriamente manter todas as instâncias dentro de ASGs – dada uma contagem de instância de destino, o ASG trabalhará para garantir que o número de instâncias em execução seja igual a esse destino, substituindo instâncias para você caso elas “morram” ou sejam marcadas como não saudáveis. Isso resulta em capacidade consistente e melhor estabilidade para o seu serviço.
  • O recurso de Auto Escala pode ser configurado para terminar casos onde um CLB ou ALB marcaram como insalubres.

Problemas e Limitações de Auto Escala

  • ReplaceUnhealthy: Por padrão, os ASGs matarão instâncias que o gerenciador de instâncias EC2 considera que não respondem. É possível que alguma instância cuja CPU esteja completamente saturada por alguns minutos pareça não responder, de forma que um ASG com a configuração ReplaceUnhealthy padrão ativada vai substituí-la. Quando as instâncias que são geridas por ASGs são consistentemente executadas com uso de CPU muito alto, considere desativar essa configuração. Se você fizer isso, no entanto, detectar e desativar nós não saudáveis se tornará sua responsabilidade.

Amazon Web Services: Tudo que Você Deve Saber – Parte 6 (Gerenciando Servidores e Aplicações)

Amazon Web Services: Tudo que Você Deve Saber

Gerenciando Servidores e Aplicações

Filosofia

  • Os princípios do aplicativo Twelve-Factor da Heroku listam algumas práticas recomendadas gerais para a implantação de aplicativos na nuvem. Recomendo a leitura, mesmo para sysadmins, afinal são tempos de DevOps! 🙂
  • Animais de estimação vs gado: trate os servidores como gado, como não animais de estimação. Ou seja, desenhe seus sistemas para que os componentes de infraestrutura sejam descartáveis (lembre isso aos devs, sysadmin!). Deve ser minimamente preocupante se um servidor for destruído inesperadamente.
  • O conceito de infraestrutura imutável é uma extensão dessa ideia.
  • Minimize o estado da aplicação nas instâncias EC2. Em geral, as instâncias devem poder ser mortas ou morrer inesperadamente com impacto mínimo. O estado que está em seu aplicativo deve se mover rapidamente para RDS, S3, DynamoDB, EFS ou outros armazenamentos de dados que não estejam na instância. O EBS também é uma opção, embora geralmente não seja o volume inicializável, e o EBS exigirá uma nova montagem manual ou automática.

Gerenciamento de Configuração do Servidor

  • Há um  grande conjunto de ferramentas de código aberto para gerenciar a configuração das instâncias do servidor.
  • Geralmente, eles não são dependentes de nenhuma infraestrutura de nuvem específica e trabalham com qualquer variedade de Linux (ou em muitos casos, uma variedade de sistemas operacionais).
  • As principais ferramentas de gerenciamento de configuração são: Puppet, Chef, Ansible e Saltstack. Estes não são o foco aqui, mas podemos mencioná-los conforme eles se relacionam com a AWS.

Containers e AWS

  • A Docker e a tendência de containers estão mudando a forma como muitos servidores e serviços são implantados em geral.
  • Os containers são projetados como forma de empacotar suas aplicações e todas as suas dependências de forma conhecida. Quando você constrói um container, você está incluindo todas as bibliotecas ou binários que sua aplicação precisa, fora do kernel. Uma grande vantagem desta abordagem é que é fácil testar e validar um container localmente sem se preocupar com alguma diferença entre o seu computador e os servidores em que você está implantado.
  • Uma consequência disso é que você precisará de menos AMIs e scripts de inicialização; Para a maioria das implantações, o único script de inicialização que você precisa é um modelo que obtém uma imagem do docker exportada e a executa.
  • Empresas que estão abraçando arquiteturas de microsserviço frequentemente irão se voltar para implantações baseadas em containers.
  • AWS lançou a ECS Como um serviço para gerenciar clusters via Docker no final de 2014, embora muitas pessoas ainda utilizem o Docker diretamente.

Visibilidade

  • Armazene e monitore dados de instância (como identificação de instância, zona de disponibilidade, etc.) e informações de implantação (ID de compilação de aplicativo, revisão Git, etc.) em seus logs ou relatórios. O serviço de metadados de instância pode ajudar a coletar alguns dos dados AWS que você precisará.
  • Use serviços de gerenciamento de logs: assegure-se de configurar uma maneira de visualizar e gerenciar logs externamente a partir de servidores.
    • Serviços baseados em nuvem, como a Sumo Logic, Splunk Cloud, Scalyr, e Loggly são os mais fáceis de configurar e usar (e também os mais caros, o que pode ser um fator dependendo da quantidade de dados de log que você possui).
    • Principais alternativas de código aberto incluem Elasticsearch, Logstash, Kibana (o “Elastic Stack”) e Graylog.
    • Se você pode pagar (você tem poucos dados ou muito dinheiro) e não tem necessidades especiais, faz sentido usar os serviços hospedados sempre que possível, uma vez que a configuração de seus próprios sistemas de processamento de log escalável é notoriamente demorada.
  • Métricas de rastreamento e gráfico: o AWS Console pode mostrar gráficos simples do CloudWatch, você normalmente vai querer rastrear e ver gráficos de muitos tipos de métricas do CloudWatch e seus aplicativos. Recolha e exporte métricas úteis em todos os lugares que você puder (e enquanto o volume for gerenciável o suficiente, você pode pagar).
    • Serviços como Librato, KeenIO, e Datadog tem recursos mais sofisticados ou melhores interfaces de usuário que podem economizar muito tempo. (Uma comparação mais detalhada está aqui).
    • Use Prometheus ou Graphite como bancos de dados de séries temporais para suas métricas (ambos são de código aberto).
    • A Grafana pode visualizar com os painéis as métricas armazenadas de ambos os bancos de dados da série temporal (também de código aberto).

Dicas para gerenciar servidores

  • Configurações do fuso horário nos servidores: a menos que seja absolutamente necessário, configure sempre o fuso horário nos servidores para UTC (veja as instruções para sua distribuição, como Ubuntu, CentOS ou Amazon Linux). Numerosos sistemas distribuídos dependem do tempo de sincronização e coordenação e a UTC fornece o plano de referência universal: não está sujeito a mudanças de horário de verão e ajustes na hora local. Também irá poupar-lhe muita depuração de dor de cabeça com problemas difíceis de fuso horários e fornecer uma linha de tempo coerente de eventos em seus sistemas de log e auditoria.
  • NTP e tempo preciso: se você não estiver usando o Amazon Linux (que vem pré-configurado), você deve confirmar que seus servidores configurem NTP corretamente, para evitar uma deriva de tempo insidiosa (o que pode causar todos os tipos de problemas, desde quebrar chamadas de API até registros enganadores). Isso deve ser parte de sua configuração automática para cada servidor. Se o tempo já deriva substancialmente (geralmente> 1000 segundos), lembre-se de que o NTP não o desligará, então talvez seja necessário corrigir manualmente (por exemplo, assim no Ubuntu).
  • Testando infraestrutura imutável: se você deseja ser pró-ativo ao testar a capacidade do seu serviço para lidar com a falha ou terminação da instância, pode ser útil testar o encerramento da instância aleatoriamente durante o horário comercial, o que irá expor esses problemas no momento em que os engenheiros estejam disponíveis para identificar e consertar. É o tipo de exercício que a Netflix recomenda e tem até ferramenta pra isso (especificamente, Chaos Monkey). Alternativamente, chaos-lambda da BBC é uma opção leve que é executada na AWS Lambda.

Amazon Web Services: Tudo que Você Deve Saber – Parte 5 (EC2)



Amazon Web Services: Tudo que Você Deve Saber

Elastic Compute Cloud (EC2)

EC2 é o serviço da AWS que fornece instâncias de processamento computacional, ou seja, as famosas, conhecidas e tradicionais máquinas virtuais (VMs para os íntimos).
Este serviço permite utilizar uma série de recursos e, a partir das características das instâncias que deseja ter acesso, é possível otimizar os custos e desempenho do ambiente na nuvem.
Eu tenho uma instância EC2 na Amazon que utilizo para hospedar vários sites com desempenho altamente satisfatório.
Inclusive é importante que você atende para outros serviços que podem ser agregados à sua instância para otimizar o desempenho dela. Eu instalei o Varnish na minha instância e utilizo ainda os serviços da Cloudfare, e com isso consigo desempenho muito melhor do que usando a instância (VM e S.O.) “pura”.
Vejamos a algumas características bem interessantes do serviço EC2 da Amazon.
  • Links importantes
  • Documentação 

  • FAQ 

    Preços (veja também ec2instances.info)

  • EC2 (Computação em nuvem elástica) é a peça mais fundamental de computação em nuvem: um servidor privado virtual. Essas “instâncias” podem ser executadas na maioria dos sistemas operacionais Linux, BSD e Windows. Internamente, eles usam virtualização Xen.
  • O termo “EC2” às vezes é usado para se referir aos próprios servidores, mas tecnicamente se refere mais amplamente a uma coleção completa de serviços de suporte, como o balanceamento de carga (CLBs / ALBs), endereços IP (EIPs), imagens inicializáveis (AMIs) , grupos de segurança e unidades de armazenamento em rede (EBS).
  • Preços e gerenciamento de custos: é um tópico complicado. Pode variar de grátis (no nível gratuito da AWS) até um preço bem elevado, dependendo do seu uso. O preço é por tipo de instância, por hora e muda de acordo com a região AWS e se você está comprando suas instâncias sob demanda, no Spot market (mercado mais econômico) ou pré-pago (Instâncias reservadas).
  • Desempenho da rede: para alguns tipos de instâncias, o AWS usa termos gerais como baixo, médio e alto para se referir ao desempenho da rede. Os usuários fizeram benchmarking para fornecer informações sobre o que esses termos podem significar.

Alternativas ao EC2 e Lock-In

  • A execução do EC2 é semelhante à execução de um conjunto de servidores físicos, desde que você não faça escala automática ou configurações de cluster. Se você apenas executa um conjunto de instâncias estáticas, a migração para outro VPS ou provedor de servidor dedicado não deve ser muito difícil.
  • Alternativas ao EC2: as alternativas diretas são o Google Cloud, o Microsoft Azure, o Rackspace, o DigitalOcean e outros provedores de VPS, alguns dos quais oferecem APIs similares para configurar e remover instâncias. (veja comparações aqui.)
  • Você deve usar o Amazon Linux? A AWS incentiva o uso de seu próprio Amazon Linux, que é desenvolvido a partir do Red Hat Enterprise Linux (RHEL) e do CentOS. É usado por muitos, mas outros são mais desconfiados. Faça o que fizer, faça esta decisão com cuidado. É verdade que o Amazon Linux é fortemente testado e melhor suportado no improvável caso de ter problemas mais profundos com sistema operacional e virtualização no EC2. Mas, em geral, muitas empresas estão usando uma distribuição padrão, que não a Amazon Linux, como Ubuntu ou CentOS. Usar uma distribuição Linux padrão significa que você tem um ambiente exatamente replicável se você usar outro provedor de hospedagem em vez da (ou além da) AWS. Também é útil se você deseja testar implantações em máquinas de desenvolvedores locais com a mesma distribuição padrão do Linux (uma prática cada vez mais comum com o Docker). Amazon agora tem um Amazon Linux Docker image, visando auxiliar no desenvolvimento local em um ambiente comparável, (embora este seja novo o suficiente para ser considerado experimental).

Dicas de EC2

  • Região: quando você configurar pela primeira vez, considere quais regiões você quer usar primeiro. Muitas pessoas na América do Norte apenas configuram automaticamente na região us-east-1 (N. Virginia), que é o padrão, mas vale a pena considerar se essa é a melhor opção ao longo do tempo. Você deve avaliar a disponibilidade do serviço (alguns serviços não são disponíveis em todas as regiões), os custos (custos também variam por região de 10 a 30% – geralmente mais baixo em us-leste-1 para fins de comparação) e a conformidade (vários países têm regulamentos diferentes em relação à privacidade de dados, por exemplo).
  • Tipos de instância: as instâncias EC2 podem ser de vários tipos, correspondentes às capacidades da máquina virtual na arquitetura e velocidade do CPU, RAM, tamanhos e tipos de disco (SSD ou magnético) e largura de banda da rede.
    • Selecionar tipos de instância é complexo, pois existem tantos tipos. Além disso, existem diferentes gerações, lançadas ao longo dos anos.
    • Use a lista no ec2instances.info Para rever custos e recursos. A própria lista da Amazon dos tipos de instâncias é difícil de usar, e não lista as características e o preço em conjunto (de propósito?), o que o torna duplamente difícil. Os preços variam muito, então use o ec2instances.info para determinar o conjunto de máquinas que atendem às suas necessidades e ec2price.com para encontrar o tipo mais barato na região em que você está trabalhando. Dependendo do tempo e da região, pode ser muito mais barato alugar uma instância com mais memória ou CPU.
  • Desligue suas instâncias quando elas não estiverem sendo usadas. Para muitas situações, como testes ou implementação de recursos, você não precisará de suas instâncias em 24/7, e você não precisará pagar custos por hora do EC2 quando elas estiverem suspensas. Dado que os custos são calculados com base no uso horário, este é um mecanismo simples para economzar bastante. Isso pode ser alcançado usando Lambda CloudWatch, uma solução de código aberto como Scalr ou o provedor SaaS como GorillaStack. (nota: se você desligar instâncias com uma unidade de disco efêmera, qualquer estado será perdido quando a instância for desligada. Por isso, para aplicações com estado, é mais seguro desligar as instâncias suportadas pelo EBS).
  • Instâncias dedicadas e hosts dedicados são hardwares exclusivos, em vez de instâncias virtuais usuais. Eles são mais caros do que instâncias virtuais, mas podem ser preferíveis por desempenho, conformidade, modelagem financeira ou licenciamento.
  • 32 bit vs 64 bit: algumas instâncias micro, pequenas e médias ainda estão disponíveis para usar com a arquitetura de 32 bits. Você usará muito provavelmente as instâncias EC2 de 64 bits (“amd64”) hoje em dia, até pelo desempenho. Portanto, use 64 bits, a menos que você tenha restrições específicas ou outros bons motivos para usar 32 bits.
  • HVM vs PV: existem dois tipos de tecnologia de virtualização usada pela EC2: máquina virtual de hardware (HVM) e paravirtual (PV). Historicamente, PV era o tipo mais comum, mas agora a HVM está se tornando o padrão. Se você quiser usar os tipos de instância mais recentes, você deve usar HVM. Veja a matriz de tipo de instâncias para detalhes.
  • Sistema operacional: para usar o EC2, você precisará escolher um sistema operacional básico. Pode ser o Windows ou o Linux, como o Ubuntu ou o Amazon Linux. Você faz isso com AMIs, que são modelos da Amazon que simplificam a criação de instâncias.
  • Limites: você não pode criar números arbitrários de instâncias. Os limites padrão nos números de instâncias EC2 suportados variam de acordo com o tipo de instância, conforme descrito nesta lista.
  • Use a proteção de encerramento. Para todas as instâncias que são importantes e duradouras (em particular, não fazem parte da auto-escala), habilite a proteção de encerramento. Esta é uma importante linha de defesa contra erros de usuários, como, por exemplo, encerrar acidentalmente muitas instâncias ao invés de apenas uma devido a um erro humano.
  • Gerenciamento de chave SSH:
    • Quando você inicia uma instância, você precisa ter pelo menos uma Par de chaves ssh  para configurar, inicializar, ou seja, permitir-lhe o ssh na primeira vez.
    • Além do bootstrapping, você deve gerenciar as chaves você mesmo nas instâncias, atribuindo chaves individuais a usuários ou serviços individuais, conforme apropriado.
    • Evite reutilizar as chaves de inicialização originais, exceto pelos administradores, ao criar novas instâncias.
    • Evite compartilhar chaves e adicione chaves ssh individuais para usuários individuais.
  • Suporte a GPU: você pode alugar instâncias habilitadas para GPU no EC2 para uso em tarefas de processamento de máquinas ou renderização de gráficos (e até minerar Bitcoins! 🙂 – brincadeira, há opções bem mais baratas pra isso).
    • três gerações de instâncias habilitadas para GPU disponíveis:
      • A série P2 de terceira geração oferece GPUs NVIDIA K80 em configurações de 1, 8 e 16 GPUs visando o aprendizado da máquina e as cargas de trabalho científicas.
      • A série G2 de segunda geração oferece GPUs NVIDIA K520 em configurações de 1 ou 4 GPU visando gráficos e codificação de vídeo.
      • As instâncias CG1 de primeira geração ainda estão disponíveis em algumas regiões em uma única configuração com uma GPU NVIDIA M2050.
    • A AWS oferece uma AMI (do Amazon Linux) com a maioria dos drivers NVIDIA e software auxiliar (CUDA, CUBLAS, CuDNN, TensorFlow) instalados para reduzir a barreira ao uso. Note, no entanto, que isto leva a restrições de customização devido ao Amazon Linux e ao fato de você não ter acesso direto à configuração ou versão de software.
    • Tal como acontece com os tipos de instâncias EC2 mais caros, instâncias específicas podem oferecer economias significativas, e com carga de trabalho GPU quando as interrupções são toleráveis.
  • Todos os tipos de instâncias EC2 atuais podem aproveitar o endereçamento IPv6, desde que sejam lançados em uma sub-rede com um intervalo CIDR alocado em um VPC habilitado para IPv6.

EC2: Problemas e Limitações

  • Nunca use senhas ssh. Apenas não faça isso; é muito inseguro e as consequências de um comprometimento muito severas. Use as chaves em vez disso. Leia aqui e desabilite totalmente o acesso de senhas ssh ao seu servidor ssh, certificando-se de que ‘PasswordAuthentication no’ esteja no seu arquivo /etc/ssh/sshd_config. Se você tiver cuidado ao gerenciar chaves privadas do ssh em todos os lugares que eles são armazenados, terá uma grande melhoria na segurança em relação à autenticação baseada em senha.
  • Para todos os  tipos de instâncias mais recentes, ao selecionar o AMI para usar, certifique-se de selecionar o HVM AMI, ou simplesmente não funcionará.
  • Quando criando uma instância e usando um novo par de chaves ssh, certifique-se de que as permissões da chave ssh estejam corretas.
  • Às vezes, certas instâncias EC2 podem ser agendadas para aposentadoria pela AWS devido a “degradação detectada do hardware subjacente”, caso em que você tem poucas semanas para migrar para uma nova instância
    • Se o seu dispositivo de armazenamento principal da instância for um volume EBS, normalmente você pode parar e, em seguida, iniciar a instância que o move para o hardware do host saudável, dando-lhe controle sobre o tempo deste evento. Note, no entanto, que você perderá qualquer dado da instância (drives efêmeros) se seu tipo de instância tiver volumes locais.
    • O IP público da instância (se tiver um) provavelmente mudará a menos que você esteja usando IPs elásticos. Isso pode ser um problema se outros sistemas dependerem do endereço IP.
  • Periodicamente, você pode achar que seu servidor ou balanceador de carga está recebendo tráfego para (presumivelmente) um servidor EC2 anterior que estava sendo executado no mesmo endereço IP que você é distribuído agora (isso pode não importar, ou pode ser corrigido migrando para outro Nova instância).
  • Se a API EC2 em si é uma dependência crítica da sua infra-estrutura (por exemplo, para a substituição automática do servidor, algoritmos de dimensionamento personalizados, etc.) e você está executando em grande escala ou fazendo muitas chamadas da API EC2, certifique-se de que você entenda quando elas podem falhar (chamadas para isso têm limitações de taxas e os limites não são publicados e sujeitos a alterações),  codifique e teste contra essa possibilidade.
  • Muitos tipos de instâncias EC2 mais recentes são somente EBS. Certifique-se de levar em conta o desempenho e os custos do EBS quando planejar usá-los.
  • As instâncias são de dois tipos: instâncias de desempenho fixo (por exemplo, M3, C3 e R3) e Instâncias de Performance Burstable (Por exemplo, T2). Uma instância T2 recebe créditos de CPU continuamente, cuja taxa depende do tamanho da instância. As instâncias T2 acumulam créditos de CPU quando estão inativas e usam créditos de CPU quando estão ativas. No entanto, uma vez que uma instância fica sem créditos, você notará uma grave degradação no desempenho. Se você precisar de um alto desempenho da CPU para aplicativos como codificação de vídeo, sites de alto volume ou aplicativos HPC, recomenda-se usar instâncias de desempenho fixo.
  • Contas muito novas podem não ser capazes de iniciar alguns tipos de instâncias, como instâncias GPU, devido a um “limite soft” inicialmente imposto de zero. Esse limite pode ser aumentado fazendo uma solicitação de suporte. Veja o limites de serviços da AWS para fazer a solicitação de suporte. Observe que este limite de zero não está atualmente documentado.

Amazon Web Services: Tudo que Você Deve Saber – Parte 4 (Quando Usar AWS)

Amazon Web Services: Tudo que Você Deve Saber

Quando usar a AWS

  • AWS é o fornecedor dominante da computação em nuvem pública.
    • Em geral, “computação em nuvem” pode se referir a um dos três tipos de nuvem: “pública”, “privada” e “híbrida”. O AWS é um provedor de nuvem pública, pois qualquer um pode usá-lo. Nuvens privadas estão dentro de uma única organização (geralmente grande). Muitas empresas usam um híbrido de nuvens privadas e públicas.
    • Os principais recursos do AWS são infrastructure-as-a-service (IaaS) — isto é, máquinas virtuais e infra-estrutura de suporte. Outros modelos de serviços em nuvem incluem platform-as-a-service (PaaS), que são serviços totalmente gerenciados que implementam aplicativos de clientes, ou software-as-a-service (SaaS), Que são aplicativos baseados em nuvem. A AWS oferece alguns produtos que se encaixam nesses outros modelos também.
    • Em termos comerciais, com infrastructure-as-a-service você possui um modelo de custo variável – é  OpEx, não CapEx (em alguns contratos pré-pagos continua sendo CapEx).
  • A receita anual da AWS foi de $12.21 billhões a partir de 2016, ou aproximadamente 8,9% da receita total da Amazon.com em 2016.
  • Principais motivos para usar AWS:
    • Se a sua empresa estiver construindo sistemas ou produtos que possam precisar escalar;
    • E você tem know-how técnico;
    • E você quer as ferramentas mais flexíveis;
    • E você não está significativamente ligado a uma infra-estrutura diferente já;
    • E você não tem motivos internos, regulatórios ou de conformidade, você não pode usar uma solução pública baseada na nuvem;
    • E você não está em uma pilha Microsoft-first de tecnologia;
    • E você não tem um motivo específico para usar o Google Cloud;
    • E você pode pagar, gerenciar ou negociar seus custos um pouco maiores;
    • … então o AWS provavelmente é uma boa opção para sua empresa.

  • Cada um desses motivos acima pode indicar situações em que outros serviços são preferíveis. Na prática, muitas, se não a maioria, de startups de tecnologia, bem como uma série de grandes empresas modernas podem ou já se beneficiam com o uso da AWS. Muitas grandes empresas estão em parte migrando infraestrutura interna para Microsoft Azure, Google Cloud e AWS.
  • Custos: o faturamento e gerenciamento de custos são temas muito importantes. Não descuide disso!
  • EC2 vs. outros serviços: A maioria dos usuários do AWS está mais familiarizado com o Elastic Computing Cloud (EC2), o produto do servidor virtual da AWS, e possivelmente alguns outros como S3 e CLBs. Mas os produtos AWS agora se estendem muito além dos IaaS básicos, e muitas vezes as empresas não entendem ou apreciam adequadamente todos os muitos serviços AWS e como eles podem ser aplicados, devido ao forte crescimento do número de serviços, sua novidade e complexidade, confusão de marca e medo de lock-in para a tecnologia AWS proprietária. Embora um pouco assustador, é importante que os decisores técnicos das empresas compreendam a amplitude dos serviços da AWS e tomem decisões informadas.
  • AWS vs. outros provedores de nuvem: Enquanto a AWS é o provedor IaaS dominante (31% de participação de mercado nesta estimativa de 2016), existe uma concorrência significativa e alternativas que são mais adequadas para algumas empresas. Este relatório do Gartner tem uma boa visão geral dos principais jogadores da nuvem:
    • Google Cloud. Chegou mais tarde ao mercado do que a AWS, mas tem vastos recursos e agora é amplamente utilizado por muitas empresas, incluindo algumas grandes. Está ganhando participação de mercado. Nem todos os serviços AWS têm serviços semelhantes ou análogos no Google Cloud. E vice-versa: em particular o Google oferece alguns serviços mais avançados baseados em aprendizagem de máquinas como os APIs Vision, Speech, e Natural Language. Não é comum trocar uma vez que está funcionando, mas acontece: Spotify migrou da AWS para o Google Cloud. Há mais discussão quanto a Quora sobre seus benefícios relativos.
    • Microsoft Azure é a escolha certa para empresas e equipes que se concentram em uma pilha da Microsoft, e agora colocou ênfase significativa no Linux também.
    • Na China, o alcance da AWS é relativamente pequeno. O mercado é dominado pela Aliyun, da Alibaba.

    • As empresas em (muito) grande escala podem querer reduzir custos gerenciando sua própria infra-estrutura. Por exemplo, Dropbox migrou para a sua própria infra-estrutura.
    • Outros provedores da nuvem, como a Digital Ocean oferecem serviços similares, às vezes com maior facilidade de uso, mais suporte personalizado ou menor custo. No entanto, nenhum deles combina com a amplitude dos produtos, a visão compartilhada e a dominação do mercado que a AWS agora desfruta.
    • Provedores tradicionais de hospedagem gerenciada, como o Rackspace também oferecem soluções em nuvem.
  • AWS vs. PaaS: Se o seu objetivo é apenas colocar um único serviço que faça algo relativamente simples, e você está tentando minimizar o tempo gerenciando engenharia de operações, considere um platform-as-a-service como o Heroku. A abordagem da AWS para PaaS, Elastic Beanstalk, é indiscutivelmente mais complexa, especialmente para casos de uso simples.
  • AWS vs. web hosting: se o seu objetivo principal é hospedar um site ou blog, e você não espera estar criando um aplicativo ou um serviço mais complexo, você pode considerar uma das opções de serviços de hospedagem web especializados em WordPress, Joomla ou seu CMS favorito. Confesso que escolhi a Amazon por inexperiência e migrar pra outro depois de um monte de configurações feitas e funcionando dá aquele medinho. Deixa quieto 🙂
  • AWS vs. hosting gerenciado: tradicionalmente, muitas empresas pagam fornecedores de hosting gerenciado para manter servidores físicos para eles, então criam e implementam seu software em cima do hardware alugado. Isso faz sentido para as empresas que querem controle direto sobre o hardware, devido ao legado, desempenho ou restrições especiais de conformidade, mas geralmente é considerado antiquado ou desnecessário por muitas startups centradas no desenvolvedor e empresas de tecnologia mais jovens.
  • Complexidade: a AWS permitirá que você construa e dimensione os sistemas para o tamanho das maiores empresas, mas a complexidade dos serviços quando utilizados na escala requer grande profundidade de conhecimento e experiência. Mesmo casos de uso muito simples muitas vezes exigem mais conhecimento para fazer “certo” no AWS do que em um ambiente mais simples, como Heroku ou Digital Ocean.
  • Localizações geográficas: a AWS possui centros de dados em em mais de doze localizações geográficas, conhecidas como regiões, na Europa, Ásia Oriental, América do Norte e do Sul, e agora Austrália e Índia. Também tem muitos outros locais de ponta globalmente para latência reduzida de serviços como o CloudFront.

    • Se a sua infra-estrutura precisa ter proximidade física de outro serviço por razões de latência ou transferência (por exemplo, latência para uma troca de anúncios), a viabilidade da AWS pode depender da localização.
  • Lock-in: À medida que você usa AWS, é importante estar ciente quando você está dependendo dos serviços AWS que não possuem equivalentes em outros lugares. Lock-in pode ser completamente bom para a sua empresa, ou um risco significativo. É importante a partir de uma perspectiva de negócios fazer essa escolha explicitamente, e considerar o custo operacional, continuidade do negócio e riscos competitivos de estar vinculado à AWS. AWS é um fornecedor tão dominante e confiável, muitas empresas estão confortáveis com o uso da AWS em toda sua extensão. Outros podem contar histórias sobre os perigos de estar “preso na nuvem”.
    • Geralmente, quanto mais serviços AWS você usa, mais lock-in você precisa da AWS, ou seja, quanto mais recursos de engenharia (tempo e dinheiro) serão necessários para mudar para outros provedores no futuro.
    • Os serviços básicos como servidores virtuais e bases de dados padrão geralmente são fáceis de migrar para outros provedores ou nas instalações. Outros, como balanceadores de carga e IAM, são específicos do AWS, mas possuem equivalentes próximos de outros provedores. A principal coisa a considerar é se os mecanismos são sistemas de arquitetura em torno de serviços específicos da AWS que não são de código aberto ou relativamente intercambiáveis. Por exemplo, Lambda, API Gateway, Kinesis, Redshift e DynamoDB não possuem equivalentes de serviços comerciais ou de origem comercial substancialmente equivalentes, enquanto o EC2, RDS (MySQL ou Postgres), EMR e ElastiCache mais ou menos têm.
    • Veja mais sobre isso aqui.
  • Combinando AWS e outros fornecedores de nuvem: muitos clientes combinam AWS com outros serviços que não são AWS. Por exemplo, sistemas legados ou dados seguros podem estar em um provedor de hospedagem gerenciado, enquanto outros sistemas são AWS. Ou uma empresa só pode usar o S3 com outro fornecedor fazendo o resto. No entanto, pequenas startups ou projetos começando do zero geralmente ficarão em AWS ou Google Cloud somente.
  • Nuvem híbrida: em grandes empresas, é comum ter implantações híbridas englobando servidores de nuvem privada ou locais e AWS – ou outros provedores de nuvem corporativa como IBM/Bluemix, Microsoft/Azure, NetApp, ou EMC.
  • Principais clientes: quem usa AWS e Google Cloud?
    • A lista de clientes da AWS inclui um grande número de empresas convencionais e grandes marcas, como Netflix, Pinterest, Spotify (movendo-se para o Google Cloud), Airbnb, Expedia, Yelp, Zynga, Comcast e Nokia.
      • A lista de clientes da Azure inclui empresas como NBC Universal, 3M e Honeywell Inc.
    • A lista de clientes da Google Cloud também é grande, e inclui alguns sites convencionais, como Snapchat, Best Buy, Domino’s, e Sony Music.

Amazon Web Services: Tudo que Você Deve Saber – Parte 3 (EBS e RDS – MySQL e MariaDB)

Amazon Web Services: Tudo que Você Deve Saber
Dando continuidade à nossa série sobre os serviços da Amazon, dessa vez vamos falar sobre armazenamento de dados de bloco e em banco de dados (MySQL e MariaDB).


EBS

EBS (Elastic Block Store) fornece armazenamento em nível de bloco. Ou seja, oferece volumes de armazenamento que podem ser anexados como sistemas de arquivos, como unidades de rede tradicionais.
Os volumes EBS só podem ser anexados a uma instância EC2 por vez. Em contraste, o EFS pode ser compartilhado, mas tem um preço muito maior ( veja uma comparação aqui).


Dicas de EBS

  • Um pode provisionar IOPS (isto é, pagar por um nível específico de operações de E/S por segundo) para garantir um nível particular de desempenho para um disco.
  • Um único volume EBS permite 10k IOPS max. Para obter o máximo desempenho de um volume EBS, ele deve ser de um tamanho máximo e anexado a uma instância EC2 otimizada pelo EBS.
  • Um tamanho de bloco padrão para um volume EBS é 16kb.


EBS: Problemas e limitações


  • A durabilidade EBS é razoavelmente boa para uma unidade de hardware regular (taxa de falha anual entre 0.1% – 0.2%). Por outro lado, isso é muito ruim se você não possui backups! Em contrapartida, a durabilidade S3 é extremamente alta. Se você se preocupa com seus dados, faça backup do S3 com snapshots.
  • EBS tem um SLA Com 99,95% de disponibilidade.
  • Os volumes de EBS têm um tipo de volume que indica o tipo de armazenamento físico. Os tipos chamados de “padrão” (st1 ou sc1) são de discos antigos, que fornecem apenas centenas de IOPS – úteis apenas se você estiver realmente tentando reduzir os custos. Os gp2 ou io1 baseados em SSDs modernos são normalmente as opções que você deseja.

RDS

Amazon Relational Database Service (RDS) é o serviço de banco de dados na nuvem do Jeff Bezos, que oferece versões MySQL 5.5, 5.6 e 5.7, além do MariaDB, Aurora, PostgreSQL, Oracle e SQL Server.
O RDS é um serviço de banco de dados relacional gerenciado, permitindo que você implante e dimensione bancos de dados com mais facilidade.
RDS oferece suporte nativo para alta disponibilidade e failover para os seus bancos de dados.
Alguns links úteis


Dicas de RDS

  • O MySQL RDS permite o acesso a logs binários.
  • As instâncias Multi-AZ do MySQL replicam de forma transparente dados em AZs (Availability Zones – Zonas de Disponibilidade) usando DRBD. Backups automatizados de instâncias multi-AZ conduzem a instância de backup a reduzir picos de latência no primário.
  • Esquema de desempenho: enquanto Performance Esquema é habilitado por padrão no MySQL 5.6.6 e posterior, é desativado por padrão em todas as versões do RDS. Se você deseja habilitar o Esquema de Desempenho, será necessária uma reinicialização da instância RDS.
  • MySQL vs MariaDB vs Aurora: Se você preferir um banco de dados de estilo MySQL, mas está começando algo novo, você provavelmente deve considerar Aurora e MariaDB também. A Aurora aumentou a disponibilidade e é a solução de próxima geração. Dito isto, Aurora pode não ser tão mais rápido (5x?) que o MySQL para determinadas cargas de trabalho. MariaDB, o moderno community fork do MySQL, provavelmente agora tem a vantagem sobre o MySQL para muitos fins e é suportado pelo RDS.
  • Se você está procurando a conveniência gerenciada do RDS para outros bancos de dados, como MongoDB ou Cassandra, você pode querer considerar serviços de provedores como mLab, Compose, ou InstaClustr.
  • Certifique-se de criar um novo grupo de parâmetros e um grupo de opções para o seu banco de dados, uma vez que o grupo de parâmetros padrão não permite mudanças de configuração dinâmica.
  • As instâncias do RDS começam com um fuso horário padrão da UTC. Se necessário, isso pode ser mudado para outro fuso horário.

RDS: Problemas e Limitações


  • Sem  privilégios root. RDS fornece suporte a algumas stored procedures para executar algumas tarefas que exigem privilégios root, como iniciar ou parar a replicação.
  • Você pode replicar para instâncias não-RDS do MySQL, mas a replicação para essas instâncias será interrompida durante as falhas do AZ..
  • Não há habilidade de transferir manualmente o master de replicação nas réplicas, então elas devem ser todas reconstruídas após uma falha do master.
  • A maioria das opções globais são expostas apenas via grupos de parâmetros DB. Algumas variáveis que foram introduzidas em lançamentos de versões de MySQL posteriores, como avoid_temporal_upgrade no MySQL 5.6.24 não estão disponíveis no grupo de parâmetros 5.6.x do RDS e fazer uso deles exige uma atualização para o MySQL 5.7.x.
  • As instâncias RDS são executadas em volumes EBS (EOPs de propósito geral ou provisionados) e, portanto, são restritas pelo desempenho EBS.
  • Verifique quais recursos de banco de dados você precisa, pois nem tudo o que você pode querer está disponível no RDS.
  • Por exemplo, se você estiver usando PostgreSQL, verifique a lista de recursos e extensões suportadas. Se os recursos que você precisa não são suportados pelo RDS, você terá que implantar seu banco de dados você mesmo.
  • Se você usar o suporte de failover oferecido pelo RDS, lembre-se de que ele é baseado em mudanças de DNS e certifique-se de que seu cliente reage com essas mudanças adequadamente. Isso é particularmente importante para o Java, dado que o TTL do resolvedor de DNS é configurado por padrão.
  • Migração de banco de dados para RDS: ao importar seu banco de dados para o RDS, certifique-se de levar em consideração as configurações da janela de manutenção. Se um backup estiver sendo executado ao mesmo tempo, sua importação pode levar um tempo consideravelmente mais longo do que você esperava.
  • O tamanho das bases de dados é limitado a 6TB para todos os mecanismos de banco de dados, exceto o SQL Server, que possui um limite de 4 TB e Aurora, que suporta bancos de dados de até 64 TB.
Espero que esteja gostando da série. Deixe seus comentários!

Amazon Web Services: Tudo que Você Deve Saber – Parte 2 (S3)

Amazon Web Services: Tudo que Você Deve Saber
Continuando nossa série de posts sobre Amazon Web Services, hoje temos informações sobre o S3.
Se você não estava acompanhando a série, recomendo começar do início.
Amazon S3 (Simple Storage Service) é o serviço padrão de armazenamento em nuvem da AWS, oferecendo armazenamento de arquivos de números arbitrários de arquivos de quase todos os tamanhos, de 0 a 5 TB (antes de 2011 O tamanho máximo era de 5 GB; tamanhos maiores agora são bem suportados via multipart support).

Itens ou objetos são colocados em recipientes nomeados armazenados com nomes normalmente chamados de chaves. O conteúdo principal é o valor.

Os objetos (arquivos) podem ser criados, excluídos ou atualizados. Os objetos grandes podem ser transmitidos, mas você não pode acessar ou modificar partes de um valor; você precisa atualizar todo o objeto.

Todo objeto também tem metadados, que incluem pares de valores-chave arbitrários, usados de forma semelhante aos cabeçalhos HTTP. Alguns metadados são definidos pelo sistema, alguns são significativos ao fornecer conteúdo HTTP a partir de buckets ou CloudFront, e você também pode definir metadados arbitrários para seu próprio uso.

URIs S3: embora muitas vezes os nomes de bucket e chave sejam fornecidos nas APIs individualmente, também é prática comum escrever uma localização S3 no formato ‘s3://bucket-name/path/to/key’ (onde a chave aqui é ‘path/to/key’). Você também encontra os prefixos ‘s3n://’ e ‘s3a://’  em sistemas  Hadoop .
S3 vs Glacier, EBS e EFS: a AWS oferece muitos serviços de armazenamento, e vários além do S3 oferecem abstrações de tipo de arquivo.
Glacier é para armazenamento de arquivos mais baratos e menos acessados.
EBS, ao contrário do S3, permite o acesso aleatório ao conteúdo do arquivo através de um sistema de arquivos tradicional, mas só pode ser anexado a uma instância EC2 por vez.
EFS É um sistema de arquivos de rede em que muitas instâncias podem se conectar, mas a um custo maior. Veja a tabela de comparação mais abaixo.

Dicas para usar melhor o S3

  • Para fins mais práticos, você pode considerar a capacidade S3 ilimitada, tanto no tamanho total dos arquivos quanto no número de objetos. O número de objetos em um bucket é essencialmente ilimitado. Os clientes rotineiramente têm milhões de objetos.
  • Nomeação do bucket: há um espaço de nomes global (em todas as regiões, mesmo que o próprio S3 armazene dados em qualquer região S3 que você escolha), então você verá que muitos nomes de bucket já foram escolhidos. Criar um bucket significa adotar o nome até que você o exclua. Os nomes têm algumas restrições.
    • Os nomes podem ser usados como parte do nome do host ao acessar o bucket ou seus conteúdos, como .s3-us-east-1.amazonaws.com, contanto que o nome seja compatível com o DNS.
    • Uma prática comum é usar o acrônimo ou abreviatura do nome da empresa para o prefixo (ou sufixo, se você preferir a hierarquia do estilo DNS) todos os nomes do bucket (mas, por favor, não use isso como uma medida de segurança – isso não é muito seguro e facilmente burlado!).
    • Nomes de bucket com ‘.’ podem causar desajustes de certificados quando usado com SSL. Use ‘-‘, uma vez que isso está em conformidade com as expectativas de SSL e é compatível com DNS.
  • Versão: S3 tem suporte de versão opcional, de modo que todas as versões de objetos sejam preservadas em um bucket. Isto é útil se você quiser um controle de mudanças (mas cuidado: não se trata de um sistema de controle de versão completo como o Git).
  • Durabilidade: a durabilidade do S3 é extremamente alta, pois internamente ele mantém várias réplicas. Se você não o exclui por acidente, você pode contar que o S3 não vai perder seus dados (AWS oferece a taxa de durabilidade aparentemente improvável de 99.999999999%, mas este é um cálculo matemático baseado em taxas de falha independentes e níveis de replicação – não uma estimativa de probabilidade verdadeira. De qualquer forma, a S3 teve um recorde muito bom de durabilidade.) Observe que esta é uma durabilidade muito maior do que o EBS! Se a durabilidade for menos importante para sua aplicação, você pode usar o S3 Reduced Redundancy Storage, O que diminui o custo por GB, bem como a redundância.
    • Para transferência, colocar dados na AWS é gratuito. Transfira de S3 para EC2 na mesma região gratuitamente também. Transferir para outras regiões ou pela Internet em geral não é gratuito.
    • As exclusões são gratuitas.

  • S3 com redundância reduzida e acesso pouco frequente: a maioria das pessoas usa a classe de armazenamento padrão no S3, mas existem outras classes de armazenamento com menor custo:
    • Reduced Redundancy Storage (RRS) vem sendo efetivamente obsoleto, E tem menor durabilidade (99,99%) do que o padrão S3. Observe que já não participa nas reduções de preços S3, por isso oferece uma pior redundância por mais dinheiro do que o padrão S3. Como resultado, não há motivo para usá-lo.
    • Infrequent Access (IA) permite que você obtenha um armazenamento mais barato em troca de um acesso mais caro. Isso é ótimo para arquivos como logs que você já processou, mas pode querer ver mais tarde. Para ter uma idéia da economia de custos ao usar o Infrequent Access (IA), você pode usar a Calculadora S3 Infrequent Access.
    • Glacier é uma terceira alternativa que vai ser abordada em outro texto.
  • Desempenho: maximizar o desempenho do S3 significa melhorar o rendimento global em termos de largura de banda e número de operações por segundo.
    • S3 é altamente escalável, então, em princípio, você pode obter arbitrariamente alta taxa de transferência. (Um bom exemplo disso é o S3DistCp.)
    • Mas geralmente você é limitado pelo canal entre a fonte e S3  e/ou o nível de concorrência das operações.
    • O throughput é, naturalmente, o mais alto entre AWS e S3, e entre instâncias EC2 e buckets S3 que estão na mesma região.
    • A largura de banda da EC2 depende do tipo de instância. Veja a coluna “Desempenho de rede” no ec2instances.info.
    • A transferência de muitos objetos é extremamente alta quando os dados são acessados ​​de forma distribuída, de muitas instâncias EC2. É possível ler ou escrever objetos de S3 de centenas ou milhares de instâncias ao mesmo tempo.
    • No entanto, o throughput é muito limitado quando os objetos acessados ​​sequencialmente de uma única instância. As operações individuais levam muitos milissegundos e a largura de banda para e de instâncias é limitada.
    • Portanto, para executar um grande número de operações, é necessário usar vários segmentos e conexões de trabalho em instâncias individuais, e para trabalhos maiores, várias instâncias EC2 também.
    • Uploads de várias partes: para objetos grandes, você deseja aproveitar as capacidades de upload de múltiplas partes (começando com tamanhos mínimos de 5 MB).
    • Grandes downloads: também você pode fazer o download de pedaços de um único objeto grande em paralelo, explorando a capacidade de cabeçalho de intervalo HTTP GET.
      • Nós listamos isso como uma recomendação, pois muitas vezes é trabalhoso renomear em larga escala.
      • Observe que, infelizmente, o conselho sobre nomes de chaves aleatórias vai contra ter um layout consistente com prefixos comuns para gerenciar ciclos de vida de dados de forma automatizada.
    • Para dados fora da AWS, DirectConnect e S3 Transfer Acceleration podem ajudar. Para S3 Transfer Acceleration, você paga o equivalente a 1-2 meses de armazenamento para a transferência em qualquer direção para usar pontos de mais próximos.
  • Aplicativos de linha de comando: existem algumas maneiras de usar S3 a partir da linha de comando:
    • Originalmente, s3cmd foi a melhor ferramenta para o trabalho. Ainda é muito usado por muitos.
    • A interface de linha de comando da AWS  agora oferece suporte ao S3 bem, e é útil para a maioria das situações.
    • s4cmd é uma substituição, com maior ênfase no desempenho através de multi-threading, o que é útil para arquivos grandes e grandes conjuntos de arquivos, e também oferece compatibilidade com o Unix.
  • Aplicações GUI: você pode preferir uma GUI, ou deseja suportar acesso GUI para usuários menos técnicos. Algumas opções:
    • A AWS Console oferece uma maneira gráfica de usar o S3. Tenha cuidado para dizer às pessoas não-técnicas que o utilizem, pois, uma vez que sem permissões rígidas, oferece acesso a muitos outros recursos AWS.
    • Transmit é uma boa opção no MacOS para a maioria dos casos de uso.
    • Cyberduck É uma boa opção no MacOS e no Windows com suporte para carregamentos de várias partes, ACLs, versões, configuração do ciclo de vida, classes de armazenamento e criptografia do lado do servidor (SSE-S3 e SSE-KMS).
    • S3 e CloudFront: S3 está bem integrado com o CloudFront CDN.
  • Hospedagem estática de sites:
    • Considere usar o CloudFront antes da maioria ou de todos os recursos:
      • Como qualquer CDN, o CloudFront melhora significativamente o desempenho.
      • Se você estiver incluindo recursos em domínios, como fontes dentro de arquivos CSS, talvez seja necessário configurar o CORS para o bucket que serve esses recursos.
      • Uma vez que praticamente tudo está se movendo para o SSL atualmente, e você provavelmente deseja controlar o domínio, você provavelmente deseja configurar o CloudFront com seu próprio certificado antes do S3 (e ignorar o exemplo do AWS sobre isso como não é SSL apenas).
  • Permissões:
    • É importante gerenciar as permissões com cuidado no S3 se você tiver sensibilidade de dados, pois corrigir isso mais tarde pode ser uma tarefa difícil, se você tiver muitos ativos e usuários internos.
    • Descreva novos buckets se você tiver diferentes sensibilidades de dados, pois isso é muito menos propenso a erros do que regras de permissões complexas.
    • Se os dados são apenas para administradores, como dados de log, coloque-o em um bucket em que só os administradores podem acessar.
    • Limite o acesso individual do usuário (ou IAM) ao S3 ao mínimo exigido e catalogue os locais “aprovados”. Caso contrário, o S3 tende a se tornar o campo de despejo onde as pessoas colocam dados em locais aleatórios que não são limpos há anos, custando-lhe muito dinheiro.
  • Ciclos de vida dos dados:
    • Ao gerenciar dados, a compreensão do ciclo de vida dos dados é tão importante quanto a compreensão dos dados em si. Ao colocar os dados em um bucket, pense em seu ciclo de vida – o fim da vida, e não apenas o seu início.
    • Em geral, os dados com diferentes políticas de expiração devem ser armazenados sob prefixos separados no nível superior. Por exemplo, alguns registros volumosos podem precisar ser excluídos automaticamente mensalmente, enquanto outros dados são críticos e nunca devem ser excluídos. Ter o primeiro em um bucket separado ou pelo menos uma pasta separada é sábio.
    • Pense sobre isso na frente, você vai poupar dor. É muito difícil limpar grandes coleções de arquivos criados por muitos engenheiros com diferentes ciclos de vida e nenhuma organização coerente.
    • Alternativamente, você pode definir uma política de ciclo de vida para arquivar dados antigos para o Glacier. Tenha cuidado com o arquivamento de grandes quantidades de objetos pequenos para o Glacier, pois pode custar mais caro.
    • Há também uma classe de armazenamento chamada Infrequent Access Que tem a mesma durabilidade que o padrão S3, mas é descontado por GB. É adequado para objetos que são acessados com pouca frequência.
  • Consistência dos dados: entender consistência de dados é importante para qualquer uso de S3, onde existem vários produtores e consumidores de dados.
    • A criação de objetos individuais em S3 é atômica. Você nunca enviará um arquivo e terá outro cliente para ver apenas metade do arquivo.
    • Além disso, se você criar um novo objeto, você poderá lê-lo instantaneamente, o que é chamado consistência de leitura e gravação.
      • Bem, com a advertência adicional de que, se você fizer uma leitura em um objeto antes de existir, e então criá-lo, você obtém consistência (not read-after-write).
    • Se você sobrescrever ou excluir um objeto, você só terá garantia de consistência.
    • Note que até 2015, a região  ‘us-standard’ Teve um modelo de consistência eventual mais fraco, e as outras regiões (mais novas) foram read-after-write. Isso foi finalmente corrigido – mas observe vários blogs antigos que mencionam isso!
    • Na prática, a “eventual consistência” geralmente significa em segundos, mas casos raros de esperas de minutos ou horas.
  • S3 como um sistema de arquivos:
    • Em geral, as APIs do S3 têm limitações inerentes que tornam o S3 difícil de usar diretamente como um sistema de arquivos de estilo POSIX enquanto ainda preserva o próprio formato de objeto do S3. Por exemplo, anexar a um arquivo requer reescrever, o que afeta o desempenho e a renomeação atômica de diretórios, a exclusão mútua na abertura de arquivos e os links rígidos são impossíveis.
    • s3fs É um sistema de arquivos FUSE que vai adiante e tenta de qualquer maneira, mas tem limitações de desempenho e surpresas por essas razões.
    • Riofs (C) e Goofys (Go) são mais recentes e tentam adotar um formato de armazenamento de dados diferente para resolver esses problemas e, portanto, são prováveis melhorias em s3fs.
    • S3QL (discussão) é uma implementação Python que oferece deduplicação de dados, snapshots e criptografia, mas apenas um cliente por vez.
    • ObjectiveFS (discussion) é uma solução comercial que suporta funcionalidades do sistema de arquivos e clientes concorrentes.
  • Se você estiver usando um VPC (conexões privadas não acessíveis via Internet), considere configurar um VPC Endpoint para o S3, a fim de permitir que seus recursos hospedados pelo VPC acessem facilmente sem a necessidade de configuração de rede adicional ou de saltos.
  • Replicação entre regiões: S3 tem um recurso para replicar um bucket entre uma região e outra. Note-se que o S3 já é altamente replicado dentro de uma região, por isso geralmente isso não é necessário para durabilidade, mas pode ser útil para conformidade (armazenamento de dados distribuído geograficamente), menor latência ou como estratégia para reduzir os custos da largura de banda região-a-região refletindo dados altamente usados em uma segunda região.
  • IPv4 vs IPv6: por muito tempo, S3 apenas suportou IPv4 no ponto final padrão https://BUCKET.s3.amazonaws.com. Entretanto, a partir de 11 de agosto de 2016 Agora oferece suporte tanto IPv4 quanto IPv6! Para usar ambos, você tem que ativar dualstack no seu cliente de API preferido ou usando diretamente esse esquema de URL https://BUCKET.s3.dualstack.REGION.amazonaws.com. Isso se estende até a aceleração de transferência S3 também.

Problemas e Limitações

  • Durante muitos anos, houve um notório limite de 100 buckets por conta, que não poderia ser aumentado e causou muita dor de cabeça significativa nas empresas. Desde 2015, você pode solicitar aumentos. Você pode pedir para aumentar o limite, mas ainda será limitado (geralmente abaixo de ~ 1000 por conta).
  • Tenha cuidado para não fazer suposições implícitas sobre transacionalidade ou sequenciação de atualizações de objetos. Nunca assuma que, se você modificar uma sequência de objetos, os clientes verão as mesmas modificações na mesma sequência, ou se você carregar um monte de arquivos, todos aparecerão de uma só vez em todos os clientes.
  • S3 tem um SLA Com 99,9% de tempo de atividade. Se você usa o S3 pesadamente, você verá inevitavelmente erros ocasionais de acesso ou armazenamento de dados à medida que os discos ou outras infra-estruturas falharem. A disponibilidade geralmente é restaurada em segundos ou minutos. Embora a disponibilidade não seja extremamente alta, como mencionado acima, a durabilidade é excelente.
  • Depois de fazer o upload, qualquer alteração que você faz no objeto causa uma reescrita completa do objeto, de modo que evite o comportamento de anexação com arquivos regulares.
  • A consistência dos dados externos, como discutido acima, pode ser surpreendente às vezes. Se S3 sofre de problemas internos de replicação, um objeto pode ser visível a partir de um subconjunto das máquinas, dependendo do ponto final do S3 que eles atingiram. Esses geralmente resolvem em segundos; No entanto, há casos isolados quando a questão permaneceu por 20 a 30 horas.
  • MD5s e carregamentos de várias partes: no S3, o cabeçalho ETag da S3 é um hash no objeto. E em muitos casos, é o hash MD5. No entanto, isso não é geral quando você usa uploads de várias partes. Uma solução alternativa é calcular MD5s você mesmo e colocá-los em um cabeçalho personalizado (como é feito pelo s4cmd).
  • Custos incompletos de upload de várias partes: os carregamentos incompletos de várias partes causam taxas de armazenamentos mesmo se o upload falhar e nenhum objeto S3 for criado. Amazon (e outros) recomendam usar uma política de ciclo de vida para limpar carregamentos incompletos e economizar em custos de armazenamento.
  • Região padrão dos EUA: anteriormente, a região us-east-1 (também conhecida como a região padrão dos EUA) foi replicada em todas as costas, o que levou a uma maior variabilidade de latência. Em vigor desde 19 de junho de 2015, isso não é mais válido. Todas as regiões do Amazon S3 agora oferecem suporte à consistência de leitura e gravação. O Amazon S3 também renomeou a região padrão dos EUA para a região dos EUA (N. Virgínia) para ser consistente com as convenções de nomeação regional da AWS.
  • Quando configurar ACLs sobre quem pode acessar o bucket e conteúdo, existe um grupo predefinido chamado Usuários Autenticados. Esse grupo geralmente é usado, de forma incorreta, para restringir o acesso de recursos S3 a usuários autenticados da conta proprietária. Se concedido, o grupo AuthenticatedUsers permitirá o acesso de recursos S3 a todos os usuários autenticados, em todas as contas AWS. Um caso de uso típico desta ACL é usado em conjunto com o solicitador  que paga a funcionalidade do S3.

Durabilidade, Disponibilidade e Preço de Armazenamento

Como ilustração de características e preços comparativos, a tabela abaixo fornece S3 Standard, RRS, IA, em comparação com Glacier, EBS, e EFS, usando a região da Virgínia a partir de agosto de 2016.
Durabilidade (por ano)
Disponibilidade “projetada”
Disponibilidade SLA
Armazenamento (por TB por mês)
GET or retrieve (por milhão)
Escrever ou arquivar (por milhão)
Glacier
Onze 9s
Lento
$4
$50
$50
S3 IA
Onze 9s
99.9%
99%
$12.50
$1
$10
S3 RRS
99.99%
99.99%
99.9%
$24 (first TB)
$0.40
$5
S3 Standard
Onze 9s
99.99%
99.9%
$23
$0.40
$5
EBS
99.8%
Não informada
99.95%
$25/$45/$100/$125+ (sc1/st1/gp2/io1)
EFS
“Alta”
“Alta”
$300
Os itens especialmente notáveis estão em negrito. Fontes: S3 pricing, S3 SLA, S3 FAQ, RRS info, Glacier pricing, EBS availability and durability, EBS pricing, EFS pricing, EC2 SLA.