A prática recomendada da nuvem ainda é ter vários discos (volumes) para um servidor?

Question

NoVelhos temposdos servidores físicos, era considerada uma boa prática (pelo menos nos locais onde trabalhei) que um servidor sempre tivesse pelo menos dois discos (volumes), não importando o quão simples um aplicativo estivesse sendo hospedado.

Um disco para o Sistema Operacional (SO) e outro para o Aplicativo. Houve uma série de razões para isso:

1. Se o aplicativo matasse seu disco, enchendo-o ou martelando-o com E/Ss, normalmente você ainda poderia fazer logon e ver o que estava acontecendo e o sistema operacional seria capaz de continuar registrando eventos para informar o que poderia ter acontecido.
2. Ele impediu que o sistema operacional impactasse o desempenho do aplicativo, disputando as E/S disponíveis em um único volume.
3. O Backup/Restauração pode se preocupar apenas com o disco do aplicativo, pois o sistema operacional pode ser reconstruído.
4. O disco do aplicativo pode ser gerenciado (por exemplo, desmontado) porque isso não afeta o sistema operacional.

Por padrão, os servidores em nuvem possuem apenas um disco. O que me fez pensar se essa abordagem de múltiplos discos ainda fazia sentido na nuvem? Considerando os pontos acima: (1), (3) e (4) provavelmente ainda se aplicam, mas (2) menos, pois os discos são virtuais: mapeados em um subsistema de armazenamento que o fornecedor de nuvem gerencia de maneiras que não consigo ver.

Então parece que ainda vale a pena seguir essa prática recomendada na nuvem?

Ou perdi um motivo pelo qual não é tão importante usar vários volumes em um ambiente de nuvem?

Answer 1

O aluguel de computadores como serviço não altera significativamente a decisão de usar discos de dados separados.

É claro que você pode alterar os padrões; por que outro motivo existiria a API para criar e adicionar discos adicionais às instâncias?

Um disco é mais simples de gerenciar. Especialmente para imagens relativamente estáticas em que a instância é a instalação do sistema operacional e do aplicativo, não há muitos dados dinâmicos.

Evitar que o sistema de arquivos fique cheio continua útil. Embora sejam possíveis outras soluções além de vários discos físicos. Volumes lógicos separados com LVM. Ou registro ou mensagens centralizadas, de modo que algumas instâncias não tenham arquivos de dados crescentes.

Exceder cotas de IOPS e tamanho pode exigir a combinação de vários discos em volumes lógicos. (Pelo menos a cota tende a ser bem definida na nuvem, mesmo que a matriz física permaneça misteriosa.) Existem bancos de dados escalonáveis.

Volumes de dados separados permitem alguns truques em nível de bloco. Imagine uma grande atualização do sistema operacional para uma instância de banco de dados, mas não existe nenhum armazenamento secundário para replicar. Prepare uma instância atualizada, mas sem dados. Durante o tempo de inatividade, desmonte e desconecte os volumes de dados, apresente-os à nova instância e monte-os. Atualização rápida, sem cópia de dados, sem segunda cópia do volume.