Um extra de 80 GB no EC2 EBS custa algo abaixo de US $ 12 por mês. Manipulações on-line provavelmente levarão mais de uma hora de seu trabalho e um risco de tempo de inatividade se algo der errado - quanto vale esse valor para você?
Pague por alguma capacidade extra, adicione-a à sua instância como um terceiro disco xvdc , inicialize-a como um PV do LVM (você não precisa nem colocar uma tabela de partição nela: apenas pvcreate /dev/xvdc será suficiente ). Em seguida, adicione o novo PV ao seu rootrhel VG ( vgextend rootrhel /dev/xvdc ) e agora você pode estender seu /storetmp com a capacidade adicionada.
lvextend -L +80G /dev/mapper/rootrhel-storetmp
xfs_growfs /storetmp #or the appropriate tool for your filesystem type
Com seu problema imediato resolvido, agora você pode agendar algum tempo de inatividade no momento adequado.
Se você estiver usando o sistema de arquivos XFS (como o RHEL / CentOS 7 faz por padrão), durante o próximo tempo de inatividade agendado, você criará tarballs do conteúdo atual de /store e /transient , desmontará e removerá todo o arquivo storerhel VG, adicione seu PV xvdb3 ao rootrhel VG e, em seguida, recrie os LVs para /store e /transient filesystems usando estimativas mais realistas para suas necessidades de capacidade e restaure o conteúdo dos tarballs. Fim do tempo de inatividade.
Agora, seu rootrhel VG tem três PVs: xvdb2 , xvdb3 e xvdc e muito espaço para suas necessidades.
Se você quiser parar de pagar por xvdc , poderá usar pvmove /dev/xvdc para migrar automaticamente os dados do VG em xvdc para o espaço não alocado em xvdb2 e / ou xvdb3 . Você pode fazer isso on-line; apenas não o faça no momento da carga de trabalho de E / S máxima para evitar um impacto no desempenho. Então vgreduce rootrhel /dev/xvdc , echo 1 > /sys/block/xvdc/device/delete para dizer ao kernel que o dispositivo xvdc está indo embora, e então diga à Amazon que você não precisa mais do seu disco xvdc .
Tenho quase 20 anos de experiência trabalhando com armazenamento em disco LVM (primeiro com o HP-UX LVM e mais tarde com o Linux LVM, uma vez que ele amadureceu o suficiente para ser usado em ambiente corporativo). Estas são as regras que eu vim usar com o LVM:
- Você nunca deve criar dois VGs quando um é suficiente.
Em particular, ter dois VGs em um único disco é provavelmente um erro que causará dor de cabeça. A realocação da capacidade de disco dentro de um VG é tão flexível quanto o tipo de sistema de arquivos permite; capacidade de movimentação entre VGs em partes menores do que uma PV já existente geralmente não vale a pena o incômodo.
- Se houver incerteza em seus requisitos de espaço em disco (e sempre há), mantenha seus LVs no lado pequeno e algum espaço não alocado na reserva.
Contanto que o seu VG tenha capacidade não alocada disponível, você pode estender os LVs e sistemas de arquivos on-line, conforme necessário, com um ou dois comandos rápidos. É um trabalho de uma banana para um administrador de sistemas
Se não houver capacidade não alocada no VG, adquira um novo disco, inicialize-o como um novo PV, adicione-o ao VG que precisa de capacidade e prossiga com a extensão como de costume. A redução dos sistemas de arquivos é mais propensa a erros, pode exigir tempo de inatividade ou pode até ser impossível sem o backup de & recriando o sistema de arquivos em tamanho menor, dependendo do tipo de sistema de arquivos. Assim, você desejará evitar situações que exigem encolhimento on-line de sistemas de arquivos o máximo possível.
- O microgerenciamento do espaço em disco pode ser arriscado e é muito trabalhoso. O trabalho é caro.
Ok. Tecnicamente, você poderia criar um arquivo de 80 GB em /store , losetup em um dispositivo de loop e transformá-lo em um PV que você poderia adicionar ao seu rootrhel VG ... mas fazendo isso resultaria em um sistema que provavelmente cairia em um modo de recuperação de usuário único na inicialização, a menos que você configurasse um script de inicialização personalizado para esses sistemas de arquivos e VGs e acertasse na primeira vez.
Errado, e da próxima vez que seu sistema for reinicializado por qualquer motivo, você terá que fazer um tempo de inatividade não planejado para solucionar problemas e corrigir ou recriar de forma mais realista os sistemas de arquivos a partir do zero e restaurar o conteúdo dos backups, porque é mais simples tentando solucionar problemas nesta bagunça do júri.
Ou se você estiver usando ext4 filesystem que pode ser on-line reduzido, você pode reduzir o sistema de arquivos /store , diminuir o LV, usar pvmove --alloc anywhere para consolidar o espaço livre para o final do xvdb3 PV, reduza o PV, reduza a partição, execute partprobe para efetivar as alterações sem reinicializar, crie uma nova partição xvdb4 , inicialize-a como um novo PV e adicione-a a rootrhel VG ...
MAS se você cometer um erro nesta seqüência para que seu sistema de arquivos / PV se estenda para além do seu contêiner LV / partição, e seu sistema de arquivos é alterado para o modo somente leitura com um sinalizador de erro que pode ser redefinido executando uma verificação do sistema de arquivos , resultando em tempo de inatividade não planejado obrigatório.