O primeiro artigo desta série seguiu a migração de um único servidor físico para um único servidor na nuvem. Entretanto, apesar de todo o trabalho que você realizou, o aplicativo não ficou em uma situação melhor, principalmente porque foram introduzidos mais pontos únicos de falha.

Até mesmo em um único servidor físico, é possível ter fontes de alimentação redundantes, RAM para correção de erros, discos redundantes e amplo monitoramento de indicadores pré-falha. Em um servidor de nuvem, você não sabe o que há nele—ou, mais especificamente, não sabe a quais recursos você tem acesso. De modo geral, os servidores de nuvem são confiáveis, mas é conveniente tomar precauções — principalmente porque o Amazon fornece serviços extras para aumentar a confiabilidade.

Ao implementar em um ambiente de nuvem, é conveniente pressupor que existe a possibilidade de perder uma instância virtual em qualquer ponto. Isso não significa que os serviços de nuvem não são confiáveis — só quer dizer que os tipos de falha que podem acontecer são diferentes das coisas com as quais você está acostumado em um ambiente físico. Portanto, você deve colocar inteligência no seu aplicativo para lidar com a perda de comunicações e escalar em vários servidores. Esse tipo de pensamento cria um aplicativo melhor, independentemente do tipo de ambiente para o qual você está construindo.

Neste artigo, você aprenderá a melhorar o armazenamento efêmero do banco de dados por meio do Amazon Elastic Block Store (EBS). Você melhora ainda mais a proteção dos dados configurando backups. Você protege contra a perda do servidor de aplicativos balanceando a carga ao longo de várias instâncias, o que permite recuperar-se depois de várias falhas.

A Figura 1 mostra a arquitetura do aplicativo no ponto em que você parou.

Tudo está em uma instância do Amazon Elastic Compute Cloud (Amazon EC2). O servidor da Web de front-end, nginx, faz a proxy de solicitações a instâncias do mongrel ou serve os arquivos estáticos propriamente ditos. Os servidores de aplicativos do mongrel acessam um banco de dados do PostgreSQL no mesmo host.

Configurando discos persistentes

O armazenamento de instância é a maior diferença entre o Amazon EC2 e as tecnologias de virtualização como VMware e Xen. Lembre que uma instância de Amazon EC2 oferece uma partição de raiz fixa de 10 GB e um disco de instância dimensionado de acordo com o tipo de instância que é lançado. A partição de raiz é clonada a partir da Amazon Machine Image (AMI) no boot, e o armazenamento de instância está vazio. Quando você desliga o servidor, o armazenamento de instância se perde.

A posição inicial da Amazon foi orientar as pessoas a fazer frequentemente o backup dos servidores no Amazon Simple Storage Service (Amazon S3). Se o servidor travasse, os outros servidores pegariam a carga ou você obteria os dados a partir do Amazon S3. No final, a Amazon ofereceu o EBS, um serviço que fornece discos persistentes. Se o servidor trava, é possível reconectar o volume do EBS a outro servidor. A Amazon criou até mesmo um mecanismo de captura instantânea para facilitar os backups.

O principal problema do servidor de banco de dados no aplicativo SmallPayroll é o fato de ser um ponto único de falha. Existem duas abordagens gerais para corrigir isso. Uma delas é criar dois servidores de banco de dados que possam substituir um ao outro; a outra abordagem é reduzir o possível tempo de inatividade a um nível razoável. A primeira opção tem menos tempo de inatividade, mas é complexa. A segunda opção é muito mais prática nessa situação. Se o servidor de banco de dados travar, será iniciada uma nova instância para substituí-la. O EBS cuida da segurança dos dados. O tempo total para iniciar um novo servidor de banco de dados e apontar novamente os clientes deve ser inferior a 10 minutos a partir do momento em que a falha é percebida. Como bônus final, o armazenamento do EBS tem uma capacidade de E/S mais alta que a do armazenamento da instância.

Para usar o EBS, você realiza as etapas a seguir:

1. Crie o volume com o comando ec2-create-volume .
2. Conecte o volume a uma instância em execução com o comando ec2-attach-volume .
3. Crie um sistema de arquivos no volume.
4. Monte o sistema de arquivos em um diretório.

Configurando o EBS pela primeira vez

O primeiro passo para configurar um EBS é dizer ao Amazon que você quer criar um volume. É preciso saber duas coisas: o tamanho da sua imagem (em gigabytes) e a zona de disponibilidade na qual você quer usar a imagem. A zona de disponibilidade é algo que a Amazon criou para descrever o local do servidor. As zonas que começam com us-east ficam no norte da Virgínia e, em seu conjunto, são chamadas deregião. Existem três zonas desse tipo na região us-east neste momento: us-east-1a, us-east-1b, e us-east-1c. Cada zona de disponibilidade foi projetada para estar isolada das falhas nas outras zonas de disponibilidade. Mesmo assim, as zonas de cada região estão próximas umas das outras e, portanto, a latência entre elas é baixa.

Uma das restrições do EBS é que o volume só pode ser montado na zona de disponibilidade na qual ele foi criado. Existem formas de movê-lo, mas é preciso criar os volumes na mesma zona de disponibilidade do servidor.

Execute o comando:

ec2-create-volume -s 20 -z us-east-1a

para criar um volume de 20 GB na zona us-east-1a. Se você não sabe onde está o servidor, o comando ec2-describe-instances lhe dá essa informação. É possível usar o mesmo parâmetro -z para ec2-run-instance a fim de especificar onde o servidor deve ser iniciado. A Listagem 1 mostra esse comando e a sua saída.

	
$ ec2-create-volume -s 20 -z us-east-1a
VOLUME  vol-c8791ca1    20              us-east-1a      creating     
2010-07-01T02:52:52+0000

A saída da Listagem 1 mostra que o volume está sendo criado e que o ID do volume é vol-c8791ca1. Sabendo disso, é possível conectar o volume a uma instância em execução do Amazon EC2 se você souber qual é o Identificador de instância do servidor e o dispositivo com o qual quer que o servidor considere o volume. Execute o comando:

ec2-attach-volume vol-c8701ca1 -i i-fd15e097 -d /dev/sdj

para conectar esse volume recém-criado à instância de serviço i-fd15e097. Lembre-se de que é possível localizar o Identificador de instância por meio do comando ec2-describe-instances e ver a lista de volumes com ec2-describe-volumes.

Agora o servidor virtual tem um disco chamado /dev/sdj que parece um disco rígido normal. Como acontece com qualquer disco, é necessário criar um sistema de arquivos no disco bruto. Existem várias opções, dependendo das necessidades:

• Criar um sistema de arquivos third extended (ext3) padrão.
• Criar um sistema de arquivos XFS. Dessa forma, é possível congelar o sistema de arquivos para obter uma captura instantânea para fins de backup.
• Colocar o Logical Volume Manager (LVM) em uma camada entre o disco e o sistema de arquivos. Dessa forma, é possível estender o volume do EBS posteriormente.
• Use o software Linux® RAID para criar faixas em vários volumes do EBS e colocar o XFS ou o ext3 sobre o conjunto de RAID. Dessa forma, você obtém um desempenho ainda melhor do disco.

Embora o RAID e o LVM forneçam recursos interessantes, o XFS é a opção mais simples para um volume de EBS relativamente pequeno. Você poderá usar os recursos de congelamento do XFS junto com as capturas instantâneas do EBS para fazer backups consistentes. A Listagem 2 mostra como criar um sistema de arquivos XFS e montá-lo no host.

	
# mkfs.xfs /dev/sdj
meta-data=/dev/sdj               isize=256    agcount=8, agsize=32768 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=262144, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096
log      =internal log           bsize=4096   blocks=2560, version=1
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0
# mkdir /ebsvol
# mount /dev/sdj /ebsvol

A Listagem 2 executa o comando mkfs.xfs para formatar /dev/sdj. (Execute gem install -y xfsprogs se você não tem o comando mkfs.xfs .) A saída desse comando descreve os parâmetros do sistema de arquivos. Desde que não haja erros, a saída pode ser ignorada. Os dois últimos comandos da Listagem 2 criam um ponto de montagem chamado /ebsvol e em seguida monta o sistema de arquivos no ponto de montagem.

Agora o sistema de arquivos é utilizável. Os arquivos sob /ebsvol persistirão inclusive quando o servidor estiver inativo.

Usando o volume do EBS

Você tem um volume do EBS montado em /ebsvol e precisa mover os dados de PostgreSQL. A forma mais direta de fazer isso é copiar o armazenamento de dados existente e corrigir as coisas com um symlink. Embora essa técnica funcione, uma opção mais limpa é clonar os dados do volume do EBS para /var/lib/pgsql. A Listagem 3 mostra esse procedimento.

	
# service postgresql stop
# mv /var/lib/pgsql /ebsvol
# mkdir /var/lib/pgsql
# chown postgres:postgres /var/lib/pgsql
# mount /ebsvol/pgsql /var/lib/pgsql -o bind
# service postgresql start

A sequência de comandos da Listagem 3 é a seguinte:

1. Pare o daemon do PostgreSQL para garantir a consistência de dados.
2. Mova toda a árvore de diretórios para o armazenamento do EBS.
3. Crie o diretório PostgreSQL novamente.
4. Redefina a propriedade do diretório PostgreSQL.
5. Monte /ebsvol/pgsql sobre /var/lib/pgsql com a opção bindde mount .
6. Reinicie o banco de dados.

A opção bind de mount clona o primeiro diretório no segundo. As alterações em um aparecem no outro—afinal, são os mesmos blocos no mesmo disco. Usar bind é diferente de montar o mesmo dispositivo duas vezes, porque é possível montar subdiretórios em vez de todo o sistema de arquivos.

Recuperando-se depois de um travamento

Se o servidor travar, realize as etapas a seguir:

1. Inicie uma nova instância usando o AMI.
2. Conecte o volume do EBS à instância com ec2-attach-volume.
3. Monte o dispositivo de EBS em /ebsvol.
4. Execute os quatro últimos comandos da Listagem 3.

O seu sistema de banco de dados estará atualizado se você tiver empacotado o AMI recentemente.

Voltar para parte superior

Trabalhando com o servidor de aplicativos

Um dos benefícios que a computação em nuvem oferece é a facilidade de acesso á capacidade do servidor. Neste momento, o ambiente do SmallPayroll.ca está com o banco de dados e o servidor de aplicativos na mesma instância virtual — a mesma situação antes da migração para o Amazon EC2. A próxima etapa é separar o servidor de aplicativos do servidor de banco de dados.

Escalamento e balanceamento de carga

O termo escalamento geralmente está associado à capacidade. Se o aplicativo é considerado escalável, ele pode ser ampliado para tratar da carga de uma quantidade maior de usuários. Se o escalamento é obtido adicionando servidores, é chamado de escalamento horizontal. Se você substitui um servidor por outro maior para tratar da carga, o aplicativo escala verticalmente.

É possível combinar escalamento horizontal e vertical em combinação. Pode ser mais fácil resolver os problemas de capacidade do banco de dados com servidores maiores e discos mais rápidos e distribuir os cálculos em uma quantidade maior de servidores. A capacidade de escalar horizontal ou verticalmente é função principalmente do design do aplicativo. Alguns aplicativos não podem ser distribuídos em vários computadores, e algumas operações demoram um certo tempo, independentemente da velocidade do computador. Além disso, aplicativos podem escalar horizontalmente até um certo ponto, no qual um gargalo anula o ganho marginal do acréscimo de um servidor.

Quando você distribui o aplicativo ao longo de vários servidores, surge o problema da distribuição das solicitações recebidas. O dispositivo mais usado para fazer isso é um balanceador de carga, um dispositivo que aceita solicitações do ambiente externo e os entrega ao próximo servidor de aplicativos disponível. Como essa tarefa não é intensiva, um único dispositivo pode tratar um grande número de conexões ou a função pode ser tratada em software.

O Amazon EC2 fornece um balanceador de carga de nuvem chamado Elastic Load Balancing que é adequado para a maioria dos propósitos. Ele distribui as solicitações, pode ser reconfigurado para adicionar ou remover servidores por meio de uma API e realiza verificações de integridade nos servidores de backend.

Uma alternativa ao uso do Elastic Load Balancing é executar o seu próprio software de balanceamento de carga em uma instância do Amazon EC2, como o HAProxy ou o Varnish (consulte Recursos para obter links para mais informações). Esse processo seria mais complexo do que o uso do Elastic Load Balancing, mas forneceria um nível mais alto de controle sobre o seu próprio tráfego. O Elastic Load Balancing é mais do que adequado para um aplicativo como SmallPayroll.ca.

A Figura 2 mostra a nova estrutura do aplicativo SmallPayrol.ca.

As solicitações recebidas chegam ao Elastic Load Balancing e são enviadas a um dos dois servidores. Os servidores propriamente ditos executam o nginx, que trata de solicitações estáticas e faz proxy das solicitações dinâmicas para instâncias de mongrel. Os mongrels se conectam a um único servidor de banco de dados.

Se um dos dois servidores fica incapacitado, o Elastic Load Balancing redireciona todo o tráfego ao outro servidor.

Iniciando as novas instâncias

Para construir os servidores de aplicativos separados, é necessário iniciar mais duas instâncias. É possível usar o mesmo AMI de antes, pois ele deve ter todo o software necessário. Pode-se iniciar mais de uma instância de cada vez: a Listagem 4 mostra duas instâncias sendo iniciadas com um comando.

	
$ ec2-run-instances ami-147f977d -k main -z us-east-1a \
-d 'role=web,db=10.201.207.180' -n 2
RESERVATION     r-9cc240f7      223410055806    default
INSTANCE        i-81ee2eeb      ami-147f977d    pending main ...
INSTANCE        i-87ee2eed      ami-147f977d    pending main ...

O comando ec2-run-instances é semelhante aos comandos que eram usados no passado. A zona de disponibilidade é escolhida com -z us-east-1a, porque o servidor de banco de dados está na mesma região. Neste momento, é conveniente manter o servidor de banco de dados e os servidores de aplicativos nas mesmas zonas de disponibilidade para reduzir a latência e as cargas de largura da banda.

Entretanto, os parâmetros -d e -n são novos. O parâmetro -n 2 simplesmente instrui o Amazon a iniciar duas instâncias, o que é confirmado na saída. O parâmetro -d permite passar informações para a instância. A Lista5, tomada a partir da nova instância, mostra como recuperar essas informações.

	
[root@domU-12-31-39-0C-C5-B2 ~]# DATA=`curl -s http://169.254.169.254/latest/user-data`
[root@domU-12-31-39-0C-C5-B2 ~]# echo $DATA
role=web,db=10.201.207.180

O comando curl recupera uma página da Web a partir dos serviços do Amazon EC2 que contêm os dados do usuário. Esse processo é semelhante à forma como o servidor recuperou a sua chave de Secure Shell (SSH) no artigo anterior desta série.

Configurando os servidores de aplicativos

Não há muito o que fazer nos servidores de aplicativos, porque a chave de AMI a partir do qual eles foram clonados já tem capacidade de executar o aplicativo com relação a um banco de dados local. Um aplicativo do Rails lê a configuração do banco de dados a partir de config/database.yml, que diz ao aplicativo qual servidor de banco de dados ele deve usar. Em forma padrão, o aplicativo se conecta ao localhost.

Primeiro, crie um alias de DNS adicionando uma entrada a/etc/hosts. Por exemplo: 10.201.207.180 dbserver é alias do nome dbserver para o endereço 10.201.207.180. É importante usar o endereço privado do banco de dados, que é o endereço designado para eth0, em vez do endereço público ao qual você se conecta. O tráfego entre os endereços privados das instâncias do Amazon EC2 na mesma zona de disponibilidade é grátis, mas o tráfego de uma instância do Amazon EC2 para o endereço público de outra instância é passível de cobrança.

Em seguida, adicione o arquivo database.yml para apontar o seu aplicativo para o alias de DNS que você criou anteriormente. A Listagem 6 mostra uma configuração desse tipo.

	
production:
  adapter: postgresql
  encoding: utf8
  database: payroll_prod
  pool: 5
  username: payroll
  password:  secret
  host: dbserver

Você deve poder iniciar o aplicativo de Rails e conectar-se a ele por meio do endereço IP público do servidor de aplicativos. Se houver algum erro, verifique o seguinte:

• O PostgreSQL está escutando todas as interfaces? O arquivo postgresql.conf deve ter uma linha semelhante a listen_addresses="*".
• O pg_hba.conf permite que endereços 10/8 se conectem usando a autenticação MD5?
• O seu grupo de segurança Amazon permite a conexão ao servidor de banco de dados?

Criando um balanceador de carga

O Elastic Load Balancing é um balanceamento de carga razoavelmente simples. As solicitações chegam ao balanceador de carga e são direcionadas a um servidor disponível no conjunto. O Elastic Load Balancing pode fazer algumas verificações básicas de integridade dos servidores da Web para evitar o envio de solicitações a servidores que estão inativos. Ele também tem alguns mecanismos básicos de afinidade que permitem manter os usuários nos mesmos servidores de backend. Atualmente não há suporte para recursos mais avançados, como redirecionamento com base na URL.

A configuração do Elastic Load Balancing é um processo com três etapas:

1. Crie a instância de balanceamento de carga.
2. Defina as verificações de integridade.
3. Configure o DNS para apontar para o nome do Elastic Load Balancing.

A Listagem 7 mostra as duas primeiras etapas em ação.

	
$ elb-create-lb smallpayroll-http \
	--listener "lb-port=80,instance-port=80,protocol=HTTP" \
	--availability-zones us-east-1a
DNS_NAME  DNS_NAME
DNS_NAME  smallpayroll-http-706414765.us-east-1.elb.amazonaws.com
$ elb-configure-healthcheck smallpayroll-http --target "HTTP:80/" \
     --interval 30 --timeout 3 --unhealthy-threshold 2 --healthy-threshold 2
HEALTH_CHECK  TARGET    INTERVAL  TIMEOUT  HEALTHY_THRESHOLD  UNHEALTHY_THRESHOLD
HEALTH_CHECK  HTTP:80/  30        3        2                  2

A Listagem 7 mostra dois comandos. O primeiro comando, elb-create-lb, cria o balanceador de carga. O primeiro parâmetro é o nome do balanceador de carga, que é exclusivo para você. O parâmetro --listener determina que a porta voltada para o público é 80, que também deve ser conectada à porta 80 na instância e que o protocolo a ser usado é HTTP. A saída desse comando é um nome de DNS,—nesse caso, smallpayroll-http-706414765.us-east-1.elb.amazonaws.com. Diferentemente do que acontece na maioria dos balanceadores de carga, você não recebe um endereço IP público para se conectar. O Amazon designa os seus próprios endereços IP e você se conecta por meio de um alias de DNS.

O segundo comando, elb-configure-healthcheck, primeiro faz referência ao nome do balanceador de carga e, em seguida, especifica que a verificação de integridade deve ser realizada com o protocolo HTTP na porta 80 usando a URL de raiz. Também é possível escrever uma ação e um controlador separados para tratar das verificações, como /status, mas, nesse caso, a URL de raiz fornece uma garantia suficiente de que o aplicativo está executando adequadamente.

A segunda linha de parâmetros especifica, na ordem, o seguinte:

• --interval 30. Testar a cada 30 segundos.
• --timeout 3. O tempo que o aplicativo deve esperar uma resposta para que se considere que não passou no teste.
• --unhealthy-threshold 2. Dois testes consecutivos com falha determinam que o servidor está fora de serviço.
• --healthy-threshold 2. Um serviço com falha requer duas verificações com êxito consecutivas para que o servidor volte ao conjunto.

A próxima etapa é conectar instâncias ao balanceador de carga (consulte a Listagem 8). É possível adicionar e remover instâncias à vontade.

	
$ elb-register-instances-with-lb smallpayroll-http --instances i-87f232ed,i-85f232ef
INSTANCE_ID  INSTANCE_ID
INSTANCE_ID  i-85f232ef
INSTANCE_ID  i-87f232ed
$ elb-describe-instance-health smallpayroll-http --headers
INSTANCE_ID  INSTANCE_ID  STATE      DESCRIPTION  REASON-CODE
INSTANCE_ID  i-85f232ef 	InService  N/A					N/A
INSTANCE_ID  i-87f232ed		InService  N/A					N/A

A Listagem 8 mostra primeiramente duas instâncias sendo adicionadas ao balanceador de carga smallpayroll-http . Execute o comando elb-describe-instance-health para ver o status de cada servidor no conjunto. InService significa que o serviço pode tratar de solicitações por meio do balanceador de carga.

Finalmente, navegue até o nome de DNS do seu balanceador de carga. Você deve ver o aplicativo funcionando em dois servidores. Para fazer com que o balanceador de carga funcione para o nome de DNS real do seu aplicativo, altere o registro de DNS do seu aplicativo de um registro A para um CNAME que aponta para o nome de DNS do balanceador de carga. Consulte Recursos para ver mais detalhes sobre os requisitos de DNS, inclusive algumas advertências. Embora o método de DNS seja trabalhoso, ele permite tratar de um número de solicitações muito maior do que a quantidade de soluções que você conseguiria tratar ao construir um balanceador de carga em uma instância do Amazon EC2. A alteração do DNS pode acontecer a qualquer momento, pois não haveria interrupção no serviço.

Voltar para parte superior

Fazendo o backup dos dados

Agora o aplicativo está distribuído em dois nós e é possível iniciar o servidor de banco de dados do zero em menos de meia hora. Isso é bom para a disponibilidade, mas não ajuda se o administrador destruir dados críticos acidentalmente ou se o volume do EBS falhar. Felizmente, há soluções disponíveis para resolver esses problemas.

Fazendo o backup do banco de dados

O EBS fornece um recurso de captura instantânea que armazena uma cópia do volume no Amazon S3. Mais precisamente, uma captura instantânea do EBS armazena as diferenças desde a última captura instantânea. Um banco de dados complica a questão porque armazena em cache algumas gravações no disco e isso pode ter como resultado uma captura instantânea inconsistente. Portanto, você deve se certificar de que tudo esteja no disco em um estado consistente (consulte a Listagem 9). A ordem dos backups será a seguinte:

1. Faça o PostgreSQL entrar em modo de backup.
2. Congele o sistema de arquivos.
3. Solicite uma captura instantânea do Amazon.
4. Descongele o sistema de arquivos.
5. Informe ao PostgreSQL que o backup foi concluído.

Embora esse procedimento possa levar um ou dois minutos, o Amazon está fazendo spool da captura instantânea para o Amazon S3 em segundo plano. Entretanto, as alterações feitas depois da etapa 3 não aparecerão na captura instantânea.

	
#!/bin/sh
export EC2_HOME=/usr/local/
export JAVA_HOME=/usr
export EC2_CERT="/root/.ec2/cert.pem"
export EC2_PRIVATE_KEY="/root/.ec2/pk.pem"
echo "select pg_start_backup('snapshot')" | su - postgres -c psql
/usr/sbin/xfs_freeze -f /ebsvol/
/usr/local/bin/ec2-create-snapshot vol-93f77ffa --description "`date`"
/usr/sbin/xfs_freeze -u /ebsvol/
echo "select pg_stop_backup('snapshot')" | su - postgres -c psql

É possível verificar o status da captura instantânea com o comando ec2-describe-snapshots , como na Listagem 10.

	
$ ec2-describe-snapshots --headers
                SnapshotId      VolumeId        Status          StartTime
SNAPSHOT        snap-298cb741   vol-93f77ffa    completed       2010-06-29T02:50:55
SNAPSHOT        snap-a2b959c9   vol-93f77ffa    completed       2010-07-13T15:14:54

A Listagem 10 mostra duas capturas instantâneas concluídas, juntamente com os horários.

Você deve automatizar a criação das capturas instantâneas ao executar a Listagem 9 a partir de cron. Também é necessário limpar periodicamente a lista de capturas instantâneas com o comando ec2-delete-snapshot .

Restaurando o banco de dados

Se o volume do EBS falha ou se você precisa restaurar dados antigos a partir do EBS, é necessário restaurar a partir da última captura instantânea. O procedimento para recuperar um volume do EBS é quase idêntico à criação de um volume novo. A Listagem 11 mostra como restaurar a última captura instantânea a partir da Listagem 10.

	
$ ec2-create-volume --snapshot snap-a2b959c9 -z us-east-1a -s 20
VOLUME  vol-d06b06b9    20      snap-a2b959c9   us-east-1a      creating

Em seguida, é possível montar esse volume em qualquer instância para restaurar os dados.

Fazendo o backup dos arquivos e restaurando-os

Uma forma simples de fazer o backup dos arquivos a partir dos servidores é copiá-los para o Amazon S3 ou transformá-los em parte do seu AMI do dia-a-dia. Este O segundo método é mais efetivo para binários e pacotes de software; copiar para o Amazon S3 é mais adequado para dados dos usuários. A ferramenta S3Sync fornece algumas ferramentas de linha de comando do Amazon S3, juntamente com um utilitário prático semelhante ao rsync.

Faça o download dos utilitários do S3Sync (consulte Recursos para ver o link). A Listagem 12 mostra como criar um depósito para os backups e como fazer upload de arquivos para o Amazon S3.

	
$ s3cmd.rb  createbucket smallpayroll-backup
$ s3cmd.rb listbuckets
ertw.com
smallpayroll-backup
$ s3sync.rb  -r /var/uploads smallpayroll-backup:`date +%Y-%m-%d`
$ s3cmd.rb list smallpayroll-backup:2010-07-12
--------------------
2010-07-12/uploads
2010-07-12/uploads/file1.txt

A Listagem 12 começa pela criação de um depósito chamado smallpayroll-backup. É possível armazenar com segurança vários backups de vários horários no mesmo depósito — portanto, você só executa essa etapa uma vez. O segundo comando se certifica de que o depósito foi criado; é possível ver o depósito que foi criado recentemente e o depósito ertw.com, no qual os AMIs residem.

O comando s3sync.rb copia recursivamente o diretório /var/uploads para o depósito de backup, prefixando todos os arquivos com a data atual. O comando final mostra todos os arquivos que estão dentro desse depósito.

A restauração dos arquivos é tão simples quanto o backup. É possível usar o S3Sync com os parâmetros reservados ou recuperar um arquivo individual por meio de outra ferramenta, como o Amazon S3 File Manager (consulte Recursos).

Voltar para parte superior

Conclusão

O aplicativo SmallPayroll está executando na nuvem e está mais bem projetado para o crescimento futuro. Embora o tempo médio entre falhas do hardware não tenha mudado, os backups e scripts estabelecidos significam que os dados estão seguros e que é possível reconstruir rapidamente o ambiente, se for necessário.

A maioria das limitações originais da migração direta para a nuvem foi resolvida. Entretanto, há pouca visibilidade em relação à integridade do ambiente e seria conveniente poder escalar os recursos de servidor em resposta à demanda. Esses problemas serão abordados nos dois próximos artigos desta série.

Recursos

Aprender

• RightScale sobre o EBS: O pessoal do RightScale fez uma análise aprofundada do EBS, fornecendo mais informações sobre as capturas instantâneas e as zonas de disponibilidade.
  
  
• Desempenho do EBS: é possível conectar vários volumes de EBS a um servidor. O blog de desempenho do MySQL tem uma comparação excelente do uso do RAID para melhorar o desempenho do EBS que também é relevante para outros bancos de dados.
  
  
• Backups on-line do PostgreSQL: esses backups são importantes, mas é necessário ter um certo nível de entendimento para assegurar a consistência.
  
  
• Usando dados de instância: uma instância do Amazon EC2 tem vários metadados de instância que ajudam a instância a obter informações sobre o ambiente. Pesquise este capítulo da documentação do Amazon EC2 para obter ideias a respeito de coisas que podem ser feitas.
  
  
• Introdução ao Elastic Load Balancing: o serviço Elastic Load Balancing opera de uma forma diferente da maneira com a qual você talvez esteja acostumado, porque requer o uso de um CNAME de DNS para ser o alias do seu aplicativo para o nome do host do Amazon.
  
  
• ELB e CNAMEs para a discussão sobre a "ponta da raiz": se você está tentando usar o Elastic Load Balancing para balancear a raiz do seu domínio, como example.com (também conhecida como ponta da raiz) essa discussão do fórum de discussão Amazon Web Services destaca os problemas e fornece soluções alternativas.
  
  
• Na área sobre Computação em Nuvem no developerWorks, obtenha os recursos necessários para desenvolver e implementar aplicativos na nuvem e ficar por dentro das novidades sobre nuvem.
  
  
• Na zona Linux no developerWorks, você encontra centenas de artigos de instruções e tutoriais, além de downloads, fóruns de discussão e uma série de outros recursos para desenvolvedores e administradores de Linux.
  
  
• Fique por dentro dos eventos técnicos e webcasts no developerWorks voltados para uma série de produtos IBM e assuntos do segmento de mercado de TI.
  
  
• Participe de uma reunião informativa grátis em Live! do developerWorks para se atualizar rapidamente em relação a produtos e ferramentas IBM e tendências do segmento de mercado de TI.
  
  
• Veja demos on demand do developerWorks que vão de demos de instalação e configuração de produtos para iniciantes até funcionalidades avançadas para desenvolvedores experientes.
  
  
• Siga o developerWorks no Twitter ou inscreva-se na alimentação de tweets sobre Linux no developerWorks.
  
  

Obter produtos e tecnologias

• HAProxy e Varnish: se está procurando alternativas ao Elastic Load Balancing, veja esses dois projetos. O HAProxy é um proxy reverso baseado em eventos, e o Varnish usa um modelo de encadeamento e também armazena em cache.
  
  
• Amazon S3 File Manager: agora que você tem vários AMIs dentro do Amazon S3, é conveniente remover alguns AMIs antigos. O Amazon S3 File Manager é um gerenciador de arquivos baseado na Web que rivaliza com os recursos de vários aplicativos independentes e plug-ins de navegador. Se você excluir um AMI, não se esqueça de usar o comando ec2-deregister .
  
  
• S3Sync: O S3Sync é uma ferramenta útil para copiar arquivos do Amazon S3 e para ele e para manipular os seus depósitos.
  
  
• Avalie produtos IBM da forma que você preferir: faça o download de uma versão de avaliação do produto, experimente um produto on-line, use um produto em um ambiente de nuvem ou passe algumas horas no SOA Sandbox aprendendo a implementar a Arquitetura Orientada a Serviços de forma eficiente.
  
  

Discutir

• Participe da comunidade My developerWorks. Conecte-se a outros usuários do developerWorks e explore os blogs, fóruns, grupos e wikis feitos por desenvolvedores.
  
  

Sobre o autor

Sean Walberg trabalha com Linux e UNIX desde 1994 em ambientes acadêmicos, corporativos e de provedores de serviço de Internet. Escreveu muito sobre administração de sistemas nos últimos anos. É possível entrar em contato com ele pelo e-mail sean@ertw.com.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Configurando discos persistentes
• Trabalhando com o servidor de aplicativos
• Fazendo o backup dos dados
• Conclusão
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais