Qual é a melhor maneira de criar instâncias do EC2 com volumes do EBS que em breve precisarão ser muito grandes?

Question

Ao lançar instâncias do EC2, parece que a maioria das AMIs da comunidade vêm com um volume de EBS de 8GB anexado como a unidade raiz. Definitivamente, precisaremos de mais de 8 GB à medida que o tamanho do nosso banco de dados aumentar. Qual é a maneira aconselhável de projetar nosso sistema? As opções que vejo são:

1. Use o armazenamento de 8 GB até precisarmos expandir e, em seguida, siga um dos vários tutoriais on-line para expandir o tamanho da unidade raiz.

2. Anexe um segundo volume de EBS à instância maior (por exemplo, 60 GB) e armazene todos os dados nesse volume. Se eu quiser usar o MongoDB ou o MySQL como banco de dados, será fácil instalar os arquivos do aplicativo de banco de dados no volume raiz, mas armazenar os dados em outro volume?

Qual é a solução de melhores práticas?

    

Answer 1

A menos que você esteja usando uma instância do EC2 com suporte a EBS, a imagem da AMI é extraída para uma imagem de unidade de 10 GB que é recriada quando a instância é iniciada. Eu uso instâncias do EC2 armazenadas por instância em vez de instâncias do EBS para todas as instâncias do meu servidor. Eu, então, simplesmente faço os volumes do EBS de qualquer lado que eu precise e monte-os como drives secundários.

Com os volumes do EBS, descobri que usar o sistema de arquivos xfs e simplesmente usar todo o volume do EBS sem qualquer particionamento era o melhor curso de ação. Para aumentar o volume quando necessário, eu executaria um instantâneo do volume do EBS existente e, em seguida, criaria um novo volume maior criado a partir do instantâneo. Você simplesmente desanexa o volume do EBS existente e anexa o novo. Uma vez que o novo volume é montado, ele será mostrado como o tamanho atual do volume até que você execute o comando xfs expand utility que deve ser executado enquanto o sistema de arquivos estiver ativo. A verificação da capacidade depois disso é mostrada para mostrar o novo tamanho maior.

Agora, se você estiver usando uma AMI do Ubuntu, poderá instalar o pacote ebsmount e criar um diretório oculto no volume do EBS e configurar o sistema para realmente usar o udev automaticamente quando o volume do EBS estiver anexado à instância do EC2.

    

Answer 2

Acho que existem três opções:

1. É muito fácil expandir um volume do EBS - instantâneo, criar volume do EBS do tamanho desejado, desanexar o original, anexar um novo sistema de arquivos, redimensionar, certamente pode ser feito em um volume raiz, mas eu sugiro que é muito melhor para ir com a opção 2.
2. Segundo volume do EBS - essa é minha preferência pessoal (não posso garantir que seja uma "melhor prática"). Eu mantenho bancos de dados em um volume (e montá-lo em / var / data) e arquivos da web em outro (e montar em / var / www / html) e, claro, tenho o meu volume de raiz. A vantagem é que a) você pode redimensionar e capturar instantaneamente cada unidade independentemente, b) você tem leituras / gravações independentes (ainda limitadas pela rede), c) mesmo que, hipoteticamente, o volume raiz esteja danificado (ex. etc) os dados são facilmente movidos para uma nova instância (mesmo com snapshots, o mesmo não acontece se tudo estiver no volume raiz).
3. Um sistema de arquivos em cluster (por exemplo, gluster) que permite distribuir seus arquivos em vários volumes e adicionar mais volumes, conforme necessário. Essencialmente, você escolheria um tamanho (digamos, 10GB) e como está ficando sem espaço, adicione outro volume de 10GB, etc. O Gluster distribuirá os arquivos pelos seus volumes - isso funcionaria para uma única instância (ou seja, vários volumes anexados a uma instância) ou em várias instâncias (ou seja, vários volumes compartilhados em várias instâncias). Há um grau de complexidade (e sobrecarga de desempenho), embora nesta configuração, embora teoricamente ofereça a melhor versatilidade.

(Há uma quarta opção, mas realmente não é prática para algo como um banco de dados - você pode montar o S3 como um sistema de arquivos de fusível - e já que você não precisa pré-alocar espaço no S3, você teria armazenamento que cresce com as suas necessidades. No entanto, é bastante lento em comparação com EBS ou armazenamento efêmero, e sua confiabilidade é questionável na melhor das hipóteses.)

    

Answer 3

Geralmente, é recomendável ter sua unidade de inicialização e sua unidade de dados como sistemas de arquivos diferentes, para que, por exemplo, um arquivo de log com excesso de zelo que preencha a unidade de inicialização não consiga vincular a capacidade do cliente de carregar conteúdo ou vice-versa). Eu nunca instalei o Mondo, mas com o MySQL, é muito fácil designar onde você deseja armazenar os dados. É ainda mais fácil mover os dados mais tarde na linha com um rsync, uma alteração de configuração e apenas alguns minutos de tempo de inatividade se você precisar expandir as unidades novamente.

Se você estiver indo para a rota mysql, provavelmente deve ser mencionado que o Relational Database Service da Amazon faz um bom trabalho ao criar um banco de dados escalável estável sem todas as dores de cabeça de gerenciar o seu próprio.

    

Answer 4

Coloque seus dados importantes em (pelo menos um) volume de EBS externo. Para qualquer coisa que você realmente precise de desempenho, use o Linux MD RAID-10 em um lote de volumes do EBS.