Você pode anexar o Amazon EBS a várias instâncias?

Atualmente, usamos vários servidores da web acessando um servidor mysql e um servidor de arquivos. Observando a mudança para a nuvem, posso usar essa mesma configuração e anexar o EBS a várias instâncias da máquina ou qual é a outra solução?

ATUALIZAÇÃO (abril de 2015) : para este caso de uso, você deve começar a olhar para o novo Amazon Elastic File System (EFS) , projetado para ser anexado de várias maneiras exatamente da maneira que deseja. A principal diferença entre o EFS e o EBS é que eles fornecem abstrações diferentes: o EFS expõe o protocolo NFSv4, enquanto o EBS fornece acesso à IO do bloco bruto.

Abaixo, você encontrará minha explicação original sobre por que não é possível montar com segurança um dispositivo de bloco bruto em várias máquinas.

POST ORIGINAL (2011):

Mesmo se você conseguisse anexar um volume EBS a mais de uma instância, seria um _REALLY_BAD_IDEA_. Para citar Kekoa, "é como usar um disco rígido em dois computadores ao mesmo tempo"

Por que isso é uma má ideia? ... O motivo pelo qual você não pode anexar um volume a mais de uma instância é que o EBS fornece uma abstração de "armazenamento em bloco" na qual os clientes executam um sistema de arquivos como ext2 / ext3 / etc. A maioria desses sistemas de arquivos (por exemplo, ext2 / 3, FAT, NTFS, etc) são gravados assumindo que eles têm acesso exclusivo ao dispositivo de bloco. Duas instâncias acessando o mesmo sistema de arquivos quase certamente terminariam em lágrimas e corrupção de dados.

Em outras palavras, a montagem dupla de um volume EBS funcionaria apenas se você estivesse executando um sistema de arquivos em cluster projetado para compartilhar um dispositivo de bloco entre várias máquinas. Além disso, mesmo isso não seria suficiente. O EBS precisaria ser testado para esse cenário e garantir a mesma garantia de consistência que outras soluções de dispositivos de bloco compartilhado ... ou seja, que os blocos não sejam armazenados em cache em níveis intermediários não compartilhados, como o kernel do Dom0, a camada Xen, e kernel do DomU. Além disso, há as considerações de desempenho da sincronização de blocos entre vários clientes - a maioria dos sistemas de arquivos em cluster é projetada para funcionar em SANs dedicadas de alta velocidade, não em uma commodity de melhor esforço. Parece tão simples, mas o que você está pedindo é uma coisa muito trivial.

Como alternativa, veja se o seu cenário de compartilhamento de dados pode ser NFS, SMB / CIFS, SimpleDB ou S3. Todas essas soluções usam protocolos de camada superior que se destinam a compartilhar arquivos sem ter um subsistema de dispositivo de bloco compartilhado. Muitas vezes, essa solução é realmente mais eficiente.

No seu caso, você ainda pode ter uma única instância / servidor de arquivos MySql que é acessada por vários front-ends da web. Esse servidor de arquivos pode armazenar seus dados em um volume EBS, permitindo que você faça backups instantâneos noturnos. Se a instância que está executando o servidor de arquivos for perdida, você poderá desanexar o volume EBS e reconectá-lo a uma nova instância do servidor de arquivos e voltar a funcionar em minutos.

"Existe algo como o S3 como um sistema de arquivos?" - sim e não. Sim, existem soluções de terceiros, como s3fs, que funcionam "ok", mas ainda precisam fazer chamadas de serviço da Web relativamente caras para cada leitura / gravação. Para um diretório de ferramentas compartilhadas, funciona muito bem. Para o tipo de uso de FS em cluster que você vê no mundo da HPC, não há chance. Para melhorar, você precisaria de um novo serviço que forneça um protocolo binário orientado a conexão, como o NFS. Oferecer um sistema de arquivos com várias montagens com desempenho e comportamento razoáveis ​​seria um ótimo complemento para o EC2. Há muito que sou defensor da Amazon para criar algo assim.

Atualização (2020) Agora é possível!

Isso é possível agora com os tipos de instância mais recentes em execução no AWS Nitro na mesma zona de disponibilidade. Existem algumas ressalvas, mas isso é ótimo para certos casos de uso que precisam da velocidade do EBS e onde o EFS não é viável.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html

Correio Original (2009)

Não, é como usar um disco rígido em dois computadores.

Se você deseja dados compartilhados, pode configurar um servidor que todas as suas instâncias possam acessar. Se você deseja uma área de armazenamento simples para todas as suas instâncias, pode usar o serviço de armazenamento S3 da Amazon para armazenar dados distribuídos e escalonáveis.

Movendo-se para a nuvem, você pode ter exatamente a mesma configuração, mas pode substituir o servidor de arquivos pelo S3 ou ter todas as suas instâncias conectadas ao servidor de arquivos.

Você tem muitas opções, mas o compartilhamento de um disco rígido entre instâncias provavelmente não é a melhor opção.

Não, de acordo com os documentos do EBS: "Um volume pode ser anexado apenas a uma instância por vez".

Como você está usando o armazenamento compartilhado atualmente? Se é apenas para servir arquivos do servidor de arquivos, você já pensou em configurar um sistema para poder proxy de determinadas solicitações para um processo no servidor de arquivos, em vez de os servidores da web servirem esses arquivos?

Tenho certeza que você não pode, mas pode clonar um EBS e anexá-lo a outra instância.

Isso é útil para conjuntos de dados fixos ou para testar dados 'reais', mas não permite que mais de uma instância opere em um único armazenamento de bloco

Vários servidores da Web que acessam o servidor MySQL e o servidor de arquivos são normais na AWS. Algumas das melhores práticas a serem seguidas para a arquitetura mencionada acima são:

Ponto 1) O MySQL no EC2 pode ser configurado como Master-Slave no modo assíncrono / semi-sincronizado na AWS. O EBS-OPT + PIOPS no RAID 0 é recomendado para DB de alto desempenho

Ponto 2) Como alternativa, você pode usar o modo Amazon RDS + Multi-AZ. Para escala de leitura Múltiplas réplicas de leitura de RDS podem ser anexadas ao MySQL RDS.

Ponto 3) O volume EBS não pode ser conectado a vários EC2 simultaneamente. Você pode criar um servidor de arquivos com base no GlusterFS no Amazon EC2 usando o EBS. Vários servidores da Web podem conversar com um único GlusterFS simultaneamente na AWS infra.

Ponto 4) Caso seu aplicativo possa ser integrado ao S3 como armazenamento de arquivos, é preferível devido à estabilidade que ele traz à arquitetura. Você também pode acessar o S3 usando ferramentas como o S3fuse e também do seu aplicativo.

O EBS acaba de anunciar que isso é possível: https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/

Existe algo no mundo da TI conhecido como Sistema de Arquivos em Cluster, Redhat GFS, Oracle OCFS2, Veritas CFS ...

A resposta curta é um "Não" categórico. Outros já disseram isso acima.

Aqueles que disseram "sim" não responderam à pergunta, mas uma pergunta diferente. Se o EFS for apenas um serviço NFS, não será a resposta para a pergunta, conforme declarado originalmente. E não importa se o EFS é "implementado em todas as zonas" ou não, porque você pode executar sua própria instância do NFS e ter vários servidores montando o NFS. Isso não é novidade, já fizemos isso em 1992. SMB e sshfs, todas essas são apenas maneiras de montar unidades como um sistema de arquivos remoto.

Aqueles que disseram "por que você quer fazer isso" ou "tudo terminará em lágrimas" estão errados. Temos montado vários discos em vários servidores há décadas. Se você já trabalhou com uma SAN (Storage Area Network), a capacidade de conectar o mesmo dispositivo a vários nós geralmente através do FibreChannel SAN é completamente normal. Portanto, qualquer pessoa que tenha executado servidores uma década atrás antes de os servidores de virtualização / nuvem se tornarem onipresentes tem alguma exposição a isso.

Logo, havia sistemas de arquivos em cluster nos quais dois sistemas podiam ler e gravar exatamente no mesmo volume. Acredito que isso já começou com o tempo VAX e Alpha VMS na história. Os sistemas de arquivos em cluster usam um esquema de exclusão mútua distribuído para poder manipular blocos diretamente.

A vantagem de montar o mesmo disco em vários nós é a velocidade e a redução de pontos únicos de falhas.

Agora, os sistemas de arquivos em cluster não se tornaram muito populares no negócio de hospedagem de "consumidores", isso é verdade. E eles são complicados e têm algumas armadilhas. Mas você nem precisa de um sistema de arquivos em cluster para usar um disco conectado a vários nós de computação. E se você quiser uma unidade somente leitura? Você nem precisa de um sistema de arquivos em cluster! Você acabou de colocar no / etc / fstab o mesmo dispositivo físico que somente leitura (ro). Em seguida, você monta em 2 ou 10 servidores EC2 e todos eles podem ler diretamente desse dispositivo!

Há um caso de uso óbvio para isso no mundo dos servidores em nuvem ao criar farms de dimensionamento rápido. Você pode preparar todo o disco do sistema principal e usar apenas um disco de inicialização e configuração muito pequeno para cada um dos servidores. Você pode até ter todos eles inicializados a partir do mesmo disco de inicialização e, pouco antes da remontagem do / no modo de leitura e gravação, você pode inserir um Union-FS com 3 camadas:

1. O principal disco do sistema somente leitura, com inicialização, kernel e instalação da terra do usuário
2. Um sistema de arquivos de configuração, com apenas alguns arquivos (principalmente em / etc) específicos para o servidor individual. Este disco pode ser gravado por outro servidor para preparar a inicialização de uma nova instância. Os arquivos de exemplo aqui seriam / etc / hostname e apenas muito poucos arquivos de configuração que precisam permanecer diferentes por nó.
3. O disco gravável, que talvez você não precise, pode ser apenas / tmp como um sistema de arquivos de memória.

Então, sim, a pergunta fazia muito sentido e, infelizmente, a resposta é (ainda) "Não". E nenhum NFS não é um ótimo substituto para esse caso de uso, pois penaliza todas as atividades de leitura do disco do sistema. No entanto, a inicialização da rede a partir de um disco do sistema NFS é a única alternativa para implementar o caso de uso descrito acima. Infelizmente, desde a configuração do NFS e do agente de inicialização de rede é muito mais complicado do que acessar o mesmo dispositivo de bloco físico.

PS: Eu gostaria de enviar uma versão mais curta disso como comentários, mas não posso por causa do tolo limite de 51 pontos de crédito, por isso tenho que escrever uma resposta com o mesmo "Não" essencial, mas incluir meu ponto de vista por que isso é uma pergunta relevante que não recebeu uma resposta merecida.

PPS: Acabei de encontrar alguém no StackExchange mencionar o iSCSI. O iSCSI é um pouco como o NFS, mas logicamente como uma SAN FibreChannel. Você pode acessar (e compartilhar) dispositivos de bloco físico. Isso tornaria o compartilhamento de disco de inicialização mais fácil, para que você não precise configurar a inicialização da rede de inicialização, o que pode ser complicado. Mas na AWS, também não há inicialização de rede disponível.

Embora o EBS anteriormente tenha permitido apenas uma única instância do EC2 ser anexada a um determinado volume, agora é possível a conexão múltipla, pelo menos para volumes io1. Para obter mais informações, consulte esta postagem no blog da AWS .

Por que você não cria uma instância com volume e sshfs para esse volume em outras instâncias?

Você pode usar totalmente uma unidade em vários servidores na AWS. Uso sshfs para montar uma unidade externa e compartilhá-la com vários servidores no EC2.

A razão pela qual eu precisava conectar uma única unidade a vários servidores é ter um único local para colocar todos os meus backups antes de removê-los localmente.