Estimando Custos na AWS

Uma das principais considerações que devemos levar em conta antes de migrar um ambiente (ou parte dele) para a nuvem é o valor monetário a ser pago por isso. Graças ao utilitário AWS Calculator, disponibilizado pela própria Amazon gratuitamente, é possível estimar este custo antes mesmo de ter o ambiente rodando.

O passo inicial para definirmos o futuro ambiente é escolhermos a região na qual o mesmo rodará. O conceito de região nada mais é que o local onde o Datacenter da Amazon está fisicamente. Os custos e servidores irão variar de uma região para outra, bem como os serviços disponíveis. Até o presente momento (março de 2016), temos 10 regiões disponíveis e uma 11ª que só pode ser utilizada pelo governo dos Estados Unidos. No Brasil temos uma região hospedada em São Paulo, o que facilita para quem deseja taxa de latência mais baixa. Muitos optam por hospedar seu ambiente em alguma região dos EUA por conta do custo menor e também pelo fato de que nessas regiões são disponibilizadas máquinas mais modernas e poderosas.

Após decidir sobre a região, deve-se verificar quais instâncias EC2 serão utilizadas. Para tomada de decisão podemos comparar a memória RAM e o clock da CPU do hardware atual para se adequar a um dos tipos de instâncias. Todas elas, assim como suas características, estão especificadas em: https://aws.amazon.com/pt/ec2/instance-types/. Também será necessário verificar o volume de armazenamento desejado para estimarmos os custos com os discos EBS (disco padrão da Amazon).

Após as considerações acima, é possível dar os primeiros passos dentro da calculadora da Amazon. O link de acesso é: http://calculator.s3.amazonaws.com/index.html

interface_aws_calculator

Vamos a um exemplo prático. Supondo que há um ambiente em São Paulo com duas máquinas:

1) 2 vCPUS com 4 Gb de Memória e 100 Gb de disco

2) 1 vCPU com 2 Gb de memória e 50Gb de disco

Verificando o link de tipos de instâncias, vemos que a instância que melhor se encaixa no perfil da máquina 1 seria a t2.medium e para a máquina 2 uma t2.small.
Na tabela Compute: Amazon EC2 Instances, clique em Add New Row. Em description seria recomendável colocar o nome ou função da máquina para posteriormente sabermos do que se trata a alocação do hardware. Na engrenagem cinza do lado de Linux on t1.micro é possível alterar o tipo de instância. Clicamos nela e alterarmos para t2.medium. Adicione mais uma máquina alterando sua instância para t2.small.

Em Storage: Amazon EBS Volumes clique em Add New Row – aqui altera-se a Description: pode ser algo como “disco da máquina x” e o volume de storage, especificando os valores que já pré-definimos (100Gb e 50 Gb).

O resultado final será:
interface_aws_final

Em Estimate your Monthly Bill é possível verificar o valor em dólares mensal que será cobradom Save and Share podemos salvar o link para consultas posteriores.

Com este artigo vimos como estimar custos de um ambiente simples na AWS. É possível estimar ambientes mais complexos também inserindo mais informações, bem como realizar estimativas com outras formas de pagamentos, o que irá alterar o custo mensal, dependendo da disponibilidade desejada das máquinas.

Usando Amazon SQS como sistema de mensagens (2/2)

Em post anterior, explicamos os conceitos por trás do Amazon Simple Queue Service, mais conhecido como SQS, e deixamos para um post futuro a demostração de exemplos sobre como postar e consumir mensagens de uma fila. E agora o post futuro finalmente chegou.

Como o próprio nome do serviço diz,  a utilização dos serviços SQS é bem simples e direto.

Vamos começar pelos pré-requisitos para trabalhar com uma fila específica, utilizando Java como linguagem e Maven para build.

Será necessário inicialmente adicionar a dependência correta ao seu projeto para que o SDK do SQS esteja disponível, como apresentado abaixo:

<dependency>
   <groupId>com.amazonaws</groupId>
   <artifactId>aws-java-sdk-sqs</artifactId>
   <version>1.10.56</version>
</dependency>

Note que esta dependência irá trazer diversas outras dependências da Amazon por transitividade. Mas não se assuste, é normal.

Agora precisamos descobrir a URL da fila para onde iremos enviar mensagem. Isto pode ser obtido direto do console SQS na AWS, conforme indicado na Figura 1, a seguir:

Figura 1 - Obtendo a url de uma fila
Figura 1 – Obtendo a url de uma fila

Note que a url da fila neste caso é https://sqs.us-west-1.amazonaws.com/536311044217/reset-password-queue.

Você precisará também de credenciais – access key e secret key – para se autenticar no SQS programaticamente. Estas credenciais devem ser fornecidas pelo responsável pelo gerenciamento de usuários no seu ambiente ou, caso você tenha este acesso, podem ser geradas pelo IAM, conforme instruções em [1].

Vamos agora ao código, começando por um exemplo comentado de como enviar uma mensagem:

public static void main(String[] args) {
		final String accessKey = "sua-access-key";
		final String secretKey = "sua-secret-key";

		/**
		 * Note que aqui estamos usando BasicAWSCredentials, onde as chaves são
		 * informadas programaticamente. Existem outras implementações de
		 * AWSCredentials que leem as credenciais de system properties ou de
		 * arquivos de configuração. Procure explorar estas alternativas.
		 */
		AWSCredentials credentials = new BasicAWSCredentials(accessKey, secretKey);

		/**
		 * Aqui criamos o cliente do Amazon SQS com as credenciais.
		 */
		AmazonSQS amazonSqs = new AmazonSQSClient(credentials);
		/**
		 * Indicando a url onde queremos trabalhar
		 */
		amazonSqs.setRegion(Region.getRegion(Regions.US_WEST_1));

		/**
		 * URL da fila onde iremos colocar a mensagem
		 */
		final String QUEUE_URL = "https://sqs.us-west-1.amazonaws.com/536311044217/reset-password-queue";

		/**
		 * Mensagem propriamente dita
		 */
		final String message = "hello world";

		/**
		 * Criação do request para envio da mensagem
		 */
		SendMessageRequest request = new SendMessageRequest(QUEUE_URL, message);

		/**
		 * Envio da mensagem propriamente dito
		 */
		amazonSqs.sendMessage(request);

	}

Veja que o código é bem direto: criamos o client, construímos a mensagem e a enviamos.

Existem, entretanto, outras opções para envio de mensagens, úteis especialmente para trabalhar com grandes volumes. Procure explorar o método sendMessageBatch para envio de diversas mensagens simultaneamente.

E agora vamos ao código comentado para recebimento da mensagem enviada anteriormente.


 

	 final String accessKey = "sua-access-key";
	 final String secretKey = "sua-secret-key";

	 /**
	 * Repetimos o código para construção do client
	 */
	 AWSCredentials credentials = new BasicAWSCredentials(accessKey, secretKey);
	 AmazonSQS amazonSqs = new AmazonSQSClient();
	 amazonSqs.setRegion(Region.getRegion(Regions.US_WEST_1));

	 /**
	 * URL da fila onde iremos buscar a mensagem
	 */
	 final String QUEUE_URL = "https://sqs.us-west-1.amazonaws.com/536311044217/reset-password-queue";

	 /**
	 * Criação do request para recebimento de mensagens
	 */
	 ReceiveMessageRequest request = new ReceiveMessageRequest(QUEUE_URL);

	 /**
	 * Limitando o numero de mensagens a serem retornadas Note que a própria
	 * Amazon estabelece um limite próprio de 10. Assim, configurar valores
	 * maiores do que 10 aqui não tem efeito.
	 */
	 request.setMaxNumberOfMessages(10);

	 /**
	 * Chamada do serviço de consulta. As mensagens retornadas por esta
	 * consulta ficarão invisíveis para outras chamdas durante o tempo
	 * configurado no Console SQS - o visibility timeout. Isto garante que
	 * eu tenha tempo suficiente para processar a mensagem sem que outra
	 * chamada a leia também.
	 */
	 ReceiveMessageResult result = amazonSqs.receiveMessage(request);

	 /**
	 * Tratando as mensagens
	 */
	 List messages = result.getMessages();
	 for (Message m : messages) {
	 System.err.println(m.getBody());

	 /**
	 * Uma vez processada a mensagem, precisamos apagá-la do SQS para
	 * que não seja consumida por outros processos
	 */
	 DeleteMessageRequest deleteRequest = new DeleteMessageRequest(QUEUE_URL, m.getReceiptHandle());
	 amazonSqs.deleteMessage(deleteRequest);
	 }

O ponto a chamar a atenção aqui é a chamada ao deleteMessage após o processamento da mensagem. Caso isto não seja feito, a mensagem ficará disponível novamente para leitura e poderá causar processamento duplicado. Assim, reforçamos  que caso o processamento da mensagem seja demorado, o visibility timeout seja configurado com um valor também alto para evitar problemas.

Bom, terminamos aqui a exemplificação das chamadas básicas do SQS e deixamos para o leitor a exploração de outros métodos e mesmo frameworks que integram com o SQS. Fica como recomendação o estudo e testes da integração Spring x AWS[2], pois facilitam ainda mais o uso da ferramenta.

Links

  1. http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSGettingStartedGuide/AWSCredentials.html
  2. Integração Spring x AWS: https://github.com/spring-projects/spring-integration-aws

Usando Amazon SQS como sistema de mensagens (1/2)

Nos últimos anos tem sido cada vez mais comum o uso da chamada arquitetura de microsserviços, em especial quando se fala de sistemas para a Internet, em que se espera um volume grande de acessos, mesmo que em horários específicos. A adoção desta arquitetura permite que o software seja construído a partir de componentes menores e com próposito específico, fazendo com que cada módulo possa ser escalado de forma independente e conforme a necessidade de negócio. Um caso típico é um site de e-commerce, em que os sistemas responsáveis pelo catálogo de produtos e pelo fechamento da compra precisam ter uma resposta mais rápido do que o sistemas que fazem a cobrança, emitem nota fiscal e liberam o pacote para a entrega.

E neste cenário de sistemas distribuídos, como fica a comunicação entre os componentes?

Uma solução bastante tradicional neste sentido consiste no uso de um middleware de gerenciamento de mensagens. O middleware atua como um ponto centralizador, onde cada sistema envia ou recebe mensagens de filas específicas. No mundo Java EE, temos a especificação JMS que trata justamente deste assunto, e que os diversos application servers precisam implementar para dar suporte este tipo de serviço. Como cada application server tem características próprias e alguns casos custo elevado, nem sempre a adoção desta ferramenta será viável, dado o timing ou o orçamento do projeto.

Fora do mundo Java EE, temos outras ferramentas, e uma bastante interessante é o Amazon SQS (Simple Queue Service). Como o próprio nome diz, o SQS é um sistema bem simples, porém bastante eficiente, para gerenciamento de filas, oferecido no modelo de Software as a Service dentro da suíte AWS, com custo bastante competitivo – chega ser gratuito até um certo volume mensal.

A seguir iremos mostrar como configurar uma fila SQS, e em um próximo post iremos escrever uma aplicação Java enviar e receber mensagens desta fila.

Para nosso exemplo, vamos supor uma funcionalidade do tipo “esqueci minha senha” em um portal. Quando o usuário clicar no link solicitando uma nova senha, o sistema do frontend irá postar uma mensagem em uma fila. Em paralelo, outro sistema ficará monitorando esta fila e enviando os emails solicitados.

Configurando uma fila SQS

Para utilizar o SQS, você deve criar uma conta no Amazon AWS, caso você ainda não tenha. Criada a conta, faça login e você verá o console da AWS, onde poderá selecionar o serviço desejado:

Figura 1 – Console de entrada da AWS

 

Selecione a opção SQS e você será levado ao console de administração de filas:

Figura 2 – Console de entrada do SQS

Veja que ainda não temos nenhuma fila criada. Selecione “Create New Queue” para criar sua primeira fila. Será mostrada a seguinte tela de configuração:

Figura 3 – Configuração de fila SQS

Nesta você irá definir os poucos, mas importante, parâmetros de cada fila, descritos a seguir:

  • Region: é a região da AWS onde sua fila será criada. A região com que você está trabalhando é definida no console principal da AWS, no canto superior direito;
  • Queue Name: é o nome da fila propriamente dita, e que será referenciado no código. Vamos utilizar no nosso exemplo “reset-password-queue”;
  • Default Visibility Timeout: este parâmetro está diretamente ligado ao modus operandi do SQS. Quando solicitamos as mensagens de uma fila através de um comando do tipo “ReceiveMessages”, as mensagens não são removidas da fila. Elas apenas ficam invisíveis para que não sejam reprocessadas por uma segunda instância da mesma aplicacão consumidora. Quando a aplicação que recebeu a mensagem fizer o processamento com sucesso, ela deva enviar uma requisição do tipo “DeleteMessage”, para que aí sim ela seja removida. Este tempo configurado é o timeout para que se receba o comando de “Delete”. Passado este tempo, o SQS assume que houve algum erro no processamento da mensagem e a deixa novamente disponível. Para o caso de envio de emails, podemos considerar que 30 segundos é um tempo adequado para o timeout.
  • Message Retention Period: é o tempo máximo que uma mensagem ficará disponível no SQS;
  • Maximum Message Size: este é o tamanho máximo da mensagem a ser postada na fila.
  • Delivery Daley: este é o tempo mínimo que o SQS irá esperar antes de tornar uma mensagem recém-postada na fila visível.
  • Receive Message Wait Time: este tempo está ligado à otimização de código do cliente do SQS. Quando a fila estiver vazia, e receber uma requisição de “Receive” o SQS irá esperar o tempo configurado pelo recebimento de uma mensagem antes de retornar uma lista vazia.
  • Use Redrive Policy/Dead Letter Queue/Maximu Receives: estes três parâmetros estão relacionados ao tratamento de erros fatais. Quando habilitados, o SQS irá considerar que a mensagem possui um erro fatal quando atingir N tentativas de processamento sem o comando de Delete correspondente. E irá movê-la para a Dead Letter Queue, possivelmente para tratamento manual.

Agora que conhecemos e configuramos todos os parâmetros, basta criar nossa fila. O resultado é mostrado abaixo:

Figura 4 – Fila SQS criada

Nesta tela temos a coluna “Messages Available”, que mostra quantas mensagens estão disponíveis na nossa fila, e “Messages In Flight”, que são as mensagens já recebidas por um consumidor, mas ainda não removidas. Estão aguardando o comando de Delete ou o Visibility Timeout. Já no fim da tela temos os detalhes da fila, incluindo a URL. Esta URL será utilizada em nosso código para envio e recepção de mensagens.

Antes de partir para o código, devemos configurar as permissões na nossa fila, para que só usuários devidamente autorizados possam executar ações sobre a mesma. Para isso, clique com o botão direito na fila e selecione Add a Permission.

Figura 5 – Menu de opções da fila

Será então mostrada a tela:

Figura 6 – Configuração de permissões

Nesta configuração você deve dar as permissões explícitas para que cada conta da AWS execute as ações necessárias sobre a fila. Para efeito de demonstração, iremos conceder todas as permissões a Everybody. Em um ambiente de produção, claro, as permissões deverão ser mais refinadas.

Bom, finalizamos esta introdução ao SQS por aqui. No próximo post iremos abordar o uso do Amazon Java SDK para o envio de recepção de mensagens do SQS.

Links externos

Um Script Criador de Máquinas

No meu Post Anterior, expliquei alguns conceitos básicos para usarmos as ferramentas em Shell para a AWS. Nesse texto, dou umas idéias básicas de como criar um script que cria máquinas dentro do ambiente AWS (VPC/EC2).

Antes de mais nada, já aviso que talvez essa não seja a maneira mais fácil de criar um servidor na AWS, pois pode-se criar um servidor, deixá-lo configurado e gerar uma AMI que seria a base para futuras instalações. O objetivo aqui, é demonstrar o conceito. Você pode decidir posteriormente se é melhor ou não.

Além disso, outro ponto importante é que os comandos AWS shell serão relativamente poucos. O restante é puro Shell Script. No entanto, vale a pena analisarmos alguns trechos importantes, o mesmo, pois a criação e instalação de máquinas possui várias pegadinhas. Como ponto a favor, pode-se adaptar esse script para ambientes non-cloud ou servidores físicos de sua rede interna. Um conceito que passamos a adotar dentro da MATERA.

Inicialmente, vamos descrever nosso ambiente no servidor MASTER, onde ficará o script instalador. Aqui sugerimos alguns arquivos importantes.

  • amazon.defaults: arquivo com diversas definições de variáveis que serão usadas para a criação de máquinas.
  • create-machine.sh: Script de criação do computador na AWS (EC2).
  • install-machine.sh: Chamado pelo script anterior, fica em separado, caso precise ser chamado em separado (em caso de erros na execução do script anterior, ou de parâmetros de uso).
  • stage/ :subdiretório com as pastas e arquivos que serão copiados para o servidor criado. Dentro do mesmo, devem ficar tudo que não for default do servidor E que não seja instalado via RPM/yum. Exemplos são ajustes em arquivos de configuração, usuários que devem existir no servidor, chaves SSH, etc. Cada arquivo/pasta deve seguir a estrutura que estaria no rootdir do servidor a ser criado. ex: stage/etc/passwd, stage/etc/http/conf.d/ssl.conf, etc.
  • stage/tmp/postinstall.sh: Script customizado para seu servidor. Será chamado a partir do servidor criado, para finalizar a instalação do computador.

Bom, primeiramente vamos olhar o conteúdo do arquivo de amazon.defaults do seu ambiente:

# sobreescreve o rootbase 
ROOTBASE=/installers 
# regiao da maquina 
REGION=us-west-2 
# chave de acesso 
KEY=AWS_MASTER 
KEYFILE=$ROOTBASE/$KEY.pem 
# tipo do servidor 
SIZE=m3.medium 
# Security group 
SECURITYGROUPS=sg-fe5718cd 
# AMI a ser usada 
AMI=ami-b5a7ea85 
# Usuario para conexao 
RMTUSER=ec2-user

Note que são apenas definições de variáveis simples. Elas serão chamadas no script propriamente dito através do comando shell source (vulgo .). Vamos analisar partes essenciais de um script assim:

Pegar os parâmetros da linha de comando. O primeiro parâmetro deve ser o arquivo com os defaults do seu ambiente. O segundo será o nome da máquina, no console EC2.

DEFAULTS=$1
source $DEFAULTS
# Nome do servidor na AWS
 TAG=$2
#Arquivo com informacoes do servidor (apos criado)
 INFOFILE=$ROOTBASE/$TAG.info

Criação da máquina propriamente dita. O resultado do comando é jogado no arquivo .info.

#Cria a maquina
ec2-run-instances $AMI -t $SIZE -k $KEY -b $PART --region $REGION $SECGROUP > $INFOFILE
#Verifica qual o ID da instancia
INSTANCIA=`awk 'NR==2{print $2}' $INFOFILE`
#Cria a Tag
ec2-create-tags $INSTANCIA --tag "Name=$TAG"

O ip dinâmico fica arquivado dentro do arquivo .info. Você pode pegar esse dado usando suas ferramentas favoritas de texto (grep, cut, sed, aws, etc).

IP=`cat $INFOFILE|...`

Por fim, rodamos uma conexão para testar (e salvar a chave no known_hosts). Por fim, roda o comando install-machine.sh. Como dito, esse script fica em separado, para que possa ser executado em separado, em caso de problemas. Além disso, note um novo sleep que é usado para aguardar o boot desse servidor.

sleep 300
 # Aguarda um tempo, antes de começar a instalar
 # Faz uma conexao de testes
 $ssh -i $KEYFILE $RMTUSER@$IP id
# Roda o script de configuracao
 $ROOTBASE/install-machine.sh $DEFAULTS $IP

Agora bastar criarmos uma nova máquina:

./create-machine.sh ./amazon.defaults AWS-MATERA-TST1

Continuando, agora veremos detalhes de um script install-machine.sh:

Primeiro deve-se pegar os parâmetros novamente, pois como disse, o script pode ser executado separadamente:

Definimos onde está a estrutura a ser copiada e o arquivo temporário a ser enviado para o servidor.

# Algumas variaveis globais
# Localizacao do stage
STAGEBASE=$ROOTBASE/stage
# Arquivo de stage, sera usado para compactar e copiar o $STAGEBASE
STAGEFILE=/tmp/stage.tgz

Aqui geramos um arquivo .tgz do stage e copiamos o mesmo para o servidor. Após isso abrimos o .tgz lá.

# Faz a copia
cd $STAGEBASE
$tar  cfz $STAGEFILE .
$scp -q -i $KEYFILE $STAGEFILE $RMTUSER@$IP:$STAGEFILE
# abre a imagem
$ssh -t -i $KEYFILE -l $RMTUSER $IP "(cd /;sudo $tar xfz $STAGEFILE)"

Por fim rodamos um outro script, agora dentro do servidor instalado. Esse script está dentro do stage e pode ser customizado de acordo com as necessidades específicas do seu servidor. Na MATERA, cada tipo de servidor (appserver, bdserver, webserver, etc) tem seu próprio script:

# roda o postinstall
 echo -n "Rodar o script de de post-install. ok? [Y] "
 read RUNSCRIPT
 if [ "$RUNSCRIPT" = "y" -o "$RUNSCRIPT" = "Y" -o "$RUNSCRIPT" = "" ]; then
  $ssh -t -i $KEYFILE -l $RMTUSER $IP "sudo /tmp/postinstall.sh"
 fi

Vamos olhar um exemplo de script postinstall.sh.

Primeiramente, atualizamos o servidor com novos pacotes da AWS. Além disso, podemos instalar os pacotes que não vem por default e que nosso servidor possa precisar:

#!/bin/sh
# postinstall.sh: Roda comandos apos a instalacao
yum -y update
yum -y install emacs xinetd rrdtool sysstat

Devemos iniciar os serviços na máquina. Também devemos configurar os mesmos para subirem no boot do servidor, caso o mesmo tenha que ser reiniciado. Ex:

chkconfig --add tomcat
chkconfig tomcat on
chkconfig nrpe on
/etc/rc.d/init.d/xinetd start
/etc/rc.d/init.d/tomcat start

Por fim, não esqueça da limpeza da casa:

rm -f /tmp/stage.tgz
rm -f /tmp/postinstall.sh

Prontinho. Essas são ideias que devem ser lembradas ao se fazer um script nesse sentido.

MATERA Systems: experiência para seu negócio na nuvem da Amazon

A computação em nuvem é uma realidade. Muitas vezes, nem sequer sabemos, mas muitos aplicativos e serviços que utilizamos no dia a dia rodam em servidores que estão “na nuvem” – ou seja – hospedados nos Datacenters de provedores que fornecem a infraestrutura para essa tecnologia.

Entre os provedores, um dos maiores e mais populares é a Amazon, com a marca AWS (Amazon Web Services) – uma das referências mundiais da computação em nuvem. A Amazon popularizou essa forma de serviço e hoje é comum empresas do ramo de TI a considerarem como uma das opções mais seguras para quem quer migrar sua infraestrutura para a nuvem.

No entanto, quando a computação em nuvem ainda era uma incógnita, a MATERA já dava seus primeiros passos com a Amazon. Aproveitando o seu know-how de mais de 28 anos em tecnologias como bancos de dados e sistemas operacionais, a MATERA foi uma das primeiras empresas a implementar infraestrutura robusta utilizando instances EC2 na Amazon.

Em 2012, a MATERA já implementava a primeira infraestrutura de um grande cliente na Amazon. Os desafios eram imensos, pois além do receio natural de se portar à infraestrutura física para algo ainda incipiente, existiam requisitos de alta disponibilidade e performance. O sucesso foi total – além de garantir ao cliente o cumprimento dos requisitos desejados, a MATERA desenvolveu técnicas específicas para criação de máquinas via scripts, com a utilização de APIs disponibilizadas pela Amazon. Assim, sempre que necessário, podiam ser criadas em questões de minutos máquinas prontas, como todos os softwares necessários instalados e operacionais, para pronto uso pelo cliente. Além da rapidez, esse processo acompanha a evolução constante que a própria Amazon traz em seus servidores e SOs – as máquinas são criadas nas instances mais modernas e atualizadas, sem o engessamento das imagens normalmente usadas.

Outro fator de sucesso vem sendo a experiencia de muitos anos da MATERA em Linux, que por sinal é a base da infraestrutura na Amazon. Soma-se a isso o profundo conhecimento em tecnologia de bancos de dados (Oracle, SQL Server, Mysql) – o que permitiu à MATERA realizar projetos de migração de grande porte, com transferência de mais de 1Tb de dados de um ambiente de um provedor convencional para a nuvem, com ganhos de performance e redução expressiva de custos.

Diferentemente do ditado popular “em casa de ferreiro, o espeto é de pau”, na própria MATERA as tecnologias da nuvem são exploradas na alavancagem de seus negócios. Exemplos são o seu Portal de Atendimento aos clientes, que roda em servidores Amazon, e o serviço de CDN da Amazon (Amazon Cloudfront), que é utilizado para servir as imagens do site corporativo da MATERA, garantindo alto desempenho de carregamento das imagens em qualquer localidade geográfica. Alguns dos produtos da empresa já são oferecidos no modelo SaaS, com toda a infraestrutura rodando dentro da AWS.

Por esses e outros motivos, podemos dizer com absoluta tranquilidade que a MATERA hoje  é uma empresa madura na computação em nuvem, pois não se trata de uma novidade tecnológica, mas sim de algo que está totalmente incorporado em nossos negócios e no nosso leque de tecnologias.


Para mais informações visite:

http://www.matera.com/br/solucoes/nuvem/

Transformando uma partição root Instance Store em EBS

A Amazon possui dois tipos de AMI (“Amazon Machine Image”): uma baseada em instâncias do tipo EBS, e outra do tipo instance store. Se você é um completo iniciante no mundo da AWS e está em dúvida sobre qual escolher, não precisa ter: escolha sempre EBS, as vantagens são inúmeras.

O que é Instance Store?

O Instance Store fornece volumes de armazenamento de nível de blocos temporários. Todos os dados são perdidos quando a máquina é desligada ou reiniciada; por conta disso, caso a partição root seja instance store e a máquina for reiniciada ela entra direta no modo “terminated” (máquina destruída e irrecuperável da amazon). Sim, todos os dados são perdidos e NÃO há como recuperá-los caso não tenha sido feito backup em outro local como um disco EBS ou até mesmo o serviço S3. Uma vantagem que esse disco tem com relação ao EBS é que ele é totalmente gratuito, não gerando o menor custo ao cliente.

Recomenda-se utilizar esse tipo de partição apenas fora da partição root e para arquivos que não há problemas em perder. Ex: SWAP, arquivos de logs descartáveis, etc.

O que é EBS?
O Amazon Elastic Block Store (Amazon EBS) fornece volumes de armazenamento de nível de blocos persistentes para uso com instâncias do Amazon EC2 na nuvem da AWS. Cada volume do Amazon EBS é replicado automaticamente na sua zona de disponibilidade para protegê-lo de falha de um componente, oferecendo alta disponibilidade e durabilidade. Os volumes do Amazon EBS oferecem o desempenho com a consistência e latência baixas necessárias para executar suas cargas de trabalho. Com o Amazon EBS, você pode aumentar ou reduzir a utilização em poucos minutos – ao mesmo tempo que paga um preço reduzido apenas pelo que for provisionado. Os dados apenas são apagados caso o volume do EBS seja deletado.

Devemos utilizar esse tipo de instância para todos os arquivos que precisam ser mantidos e não podemos perdê-los.

 Transformando Instance Store em EBS

Ok, eu não sou tão iniciante em Amazon assim, não tinha lido ainda esse blog, fui lá e criei uma máquina a partir de uma AMI Instance Store, teria jeito de mudar essa partição para EBS?

Pela console da amazon não é possível, mas com a técnica abaixo conseguiremos sim rodar uma nova máquina com todos os dados que estavam no antigo Instance Store. Para começar devemos acessar a console da Amazon e criar um volume do mesmo tamanho que a partição root original (geralmente 8 GB), que dará base a nova AMI que vamos construir posteriormente (atentar para criar o disco com a mesma Availability Zone (AZ) da máquina instance store criada:

figura1 - criando volume
figura1 – criando volume

Após criar o novo volume na Amazon, iremos atachar (anexar) esse novo disco à máquina que transformaremos:

figura 2 - atachando disco
figura 2 – atachando disco

Tendo em vista que o disco foi criado, o próximo passo seria entrar nessa máquina e executar alguns comandos para formatar o disco e montá-lo. Note que no nosso exemplo consideramos que o disco atachado à máquina ficou na partição /dev/xvdf; isso pode variar caso contenha mais volumes, por isso, verifique bem qual é a partição antes de executar os próximos comandos:

mkfs.ext4 /dev/xvdf
mkdir /ebs
mount /dev/xvdf /ebs

Estamos prontos para a próxima etapa, que nada mais é que sincronizar o disco Instance Store com esse novo EBS:

rsync -avHx / /ebs
rsync -avHx /dev /ebs
sync;sync;sync;sync && umount /mnt/ebs

O disco base  ebs está pronto. Para quem nunca trabalhou com AMI na AWS, elas são geradas a partir de um outro serviço, chamado snapshot. Então basicamente para se fazer uma ami, é feito um snapshot desse disco e a partir deste, cria-se uma imagem:

figura 3 - Criando snapshot
figura 3 – Criando snapshot

O snapshot, quando feito pela primeira vez, costuma demorar uns minutos; o que pode ser feito, para ir adiantando, seria verificar a versão do kernel que a atual máquina utiliza, pois será necessário para criar a AMI:

figura 5 - kernel id
figura 4 – kernel id

Com o snapshot pronto, podemos criar a imagem (AMI).

Preencha os campos Name e Description com algo elucidativo, pois essa AMI pode ser utilizada posteriormente na construção de novas máquinas se assim desejar. Já no campo Kernel-ID, escolha a opção que foi retirada no passo anterior. Os demais campos podem ser deixados como default, ao menos que tenha preferência para aumentar o tamanho da partição root, ou EBS de outros tipos (sobre isso, falaremos em artigos posteriores). Finalmente, clique no botão create:

figura 6 - criando ami
figura 5 – criando uma nova instância

Criando a AMI
Após todos os passos acima, iremos apenas criar uma máquina; para isso, clique com o botão direito em cima da nova AMI – Create Image (EBS AMI). E sua nova máquina será exibida em Instances.

Considerações Finais

O texto teve como objetivo mostrar uma saída para os administradores cloud que criaram uma partição Instance Store, arrependeram-se e não querem começar uma máquina nova do zero, poder transferir todo o conteúdo para uma nova máquina, já trabalhando da maneira desejada.

Lembrando que todos os comandos que foram  passados nesse tutorial via interface amazon, também podem ser feitos pela linha de comando. Para saber mais sobre como usar linha de comando para os serviços da AWS, acesse: http://www.matera.com/br/2014/12/16/gerenciando-seus-servicos-aws-via-shell-script/

Baseado e traduzido de:
http://blog.ianbeyer.com/2012/05/10/converting-ec2-s3instance-store-image-to-ebs/

Amazon Web Services cresce no Brasil

A MATERA foi citada em um artigo da revista Valor Econômico sobre o crescimento da Amazon Web Services no Brasil. Leia na íntegra a matéria escrita por Cibelle Bouças:

foto13emp-201-amazon-b3
Terry Wise, diretor global de alianças da AWS: 2013 será um ano decisivo

O americano Terry Wise demonstra ânimo, mesmo após mais de 24 horas de voo entre Seattle, no Estado de Washington, na Costa Oeste dos Estados Unidos, até São Paulo. “Só não sabia que encontraria tanto tráfego.

Estou mal-acostumado com Seattle”, disse. Wise é diretor global de alianças e canais da Amazon Web Services (AWS) – braço de infraestrutura de TI da Amazon – e fica no Brasil até sexta-feira para negociar parcerias e anunciar novos serviços no país.

O ânimo do executivo está baseado em fortes fundamentos. A companhia, que iniciou suas operações no
Brasil em dezembro de 2011 , cresceu de forma vertiginosa no país e na América Latina. Além disso, existe a perspectiva de apresentar uma expansão significativa das suas operações na região este ano. “O Brasil, particularmente, foi um dos países em que mais crescemos em número de clientes e parceiros”, disse Wise ao Valor. Segundo o executivo, o crescimento no país e na América Latina superou as suas expectativas em 2012.

Wise não divulga o número de empresas clientes no Brasil, mas disse que já atende “algumas dezenas de milhares de companhias” de todos os portes no país. “No começo havia muita procura de companhias novatas e de internet, mas a AWS conquistou contas grandes, como Pão de Açúcar, Gol e SulAmérica “, afirmou. O número de parceiros na América Latina passou de 30 para 300 entre 2011 e 2012. No Brasil, a companhia possui 200 parceiros para oferta de serviços. Entre eles estão Dedalus, ArtSoft Sistemas, MATERA e Softek.

Entre os motivos citados pelo executivo para o crescimento na região estão o reforço da atuação dos parceiros de vendas, investimentos em infraestrutura e segurança, e uma redução de custos repassada aos preços na região. Em 2012, os preços de arte dos seus serviços diminuíram de 15% a 32%, o que teria tornado a oferta mais atrativa para companhias brasileiras. “Atualmente, conseguimos oferecer preços tão competitivos quanto os das companhias locais, mesmo com as tarifas de importação”, afirmou.

Outro fator que o executivo considerou decisivo para o desempenho da AWS no país foi o aumento da adesão de companhias ao modelo de computação em nuvem, no qual softwares e servidores ficam armazenados em centros de dados em lugares remotos e são acessados via internet. “Este será um ano decisivo. A expectativa é que haja uma adoção massiva dos serviços em nuvem em todo o mundo”, disse.

“Tecnologias como essas levam dois anos para serem compreendidas pelo mercado e depois são adotadas em larga escala”, afirmou Fernando Belfort, analista sênior da consultoria Frost & Sullivan. O analista projeta para 2013 um crescimento de 74% no mercado de computação em nuvem no Brasil, para US$ 302 milhões.

Com base nesse cenário, Wise prevê um aumento das vendas de serviços para empresas este ano, com a migração da infraestrutura de TI das companhias para a nuvem. O executivo também prevê uma demanda aquecida nas próximas semanas com a oferta do serviço de “nuvem privada virtual”, que consiste na montagem de uma infraestrutura isolada de armazenagem de dados em centros de dados da Amazon Web Services, com níveis mais altos de segurança.

O executivo da Amazon afirmou que o Brasil e o restante da América Latina apresentaram crescimento acima da média global em 2012 e a expectativa é que a região continue crescendo acima da média mundial este ano. A Amazon não divulga dados de receita dos negócios da AWS. A consultoria americana Macquarie estima que o negócio de computação em nuvem da Amazon tenha crescido 59% no ano passado, atingindo uma receita de US$ 2,1 bilhões. Para este ano, a expectativa da consultoria é de um aumento de 81% em receita, para US$ 3,8 bilhões.