Spazio su disco insufficiente '/' nell'istanza AWS


28

sto eseguendo l'istanza di Ubuntu 11.04 per il mio server Web su cloud AWS, ora sto arrivando non c'è spazio su disco nella / partizione del mio server. df -ah dire questo

Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.9G  7.8G   97M  99% /
proc                     0     0     0   -  /proc
none                     0     0     0   -  /sys
fusectl                  0     0     0   -  /sys/fs/fuse/connections
none                     0     0     0   -  /sys/kernel/debug
none                     0     0     0   -  /sys/kernel/security
none                  3.7G  112K  3.7G   1% /dev
none                     0     0     0   -  /dev/pts
none                  3.7G     0  3.7G   0% /dev/shm
none                  3.7G   80K  3.7G   1% /var/run
none                  3.7G     0  3.7G   0% /var/lock
/dev/xvdb             414G   16G  377G   4% /mnt

Ora ho provato queste cose per ottenere spazio extra su / partizione

  • Pulisci tutti i file di registro per Apache.
  • Rimossi tutti i file non necessari dal server.
  • Pulizia directory home.

Ma ancora non sto ottenendo abbastanza spazio. Questo tipo di istanza è m1.large con EBS da 8 GB. Ora sto ricevendo abbastanza spazio su disco in / dev / xvdb .

C'è un modo in cui posso allocare spazio su disco da / da / dev / xvdb o qualsiasi altro modo. Per favore, suggeriscimi la possibile soluzione per questo. È possibile usare la stessa partizione / dev / xvdb con un'altra istanza.


1
Aggiornamento 2017: Amazon consente di ridimensionare le tue unità (anche unità di avvio) al volo al giorno d'oggi! vedere la mia risposta così qui: stackoverflow.com/a/42791031/7022062
Dmitry Shevkoplyas

Risposte:


26

La risposta è duplice.

Soluzione alternativa: utilizzare / dev / xvdb (/ mnt) per i dati temporanei

Questo è il cosiddetto spazio di archiviazione effimero della tua istanza Amazon EC2 e le sue caratteristiche sono molto diverse da quelle del persistente spazio di archiviazione Amazon EBS in uso altrove. In particolare, questa memoria effimera andrà persa nei cicli di arresto / avvio e generalmente può andare via , quindi sicuramente non vuoi mettere lì qualcosa di valore duraturo, cioè solo mettere lì dati temporanei che puoi permetterti di perdere o ricostruire facilmente , come un file di scambio o dati strettamente temporanei in uso durante i calcoli. Ovviamente potresti archiviare enormi indici lì per esempio, ma devi essere pronto a ricostruirli dopo che l'archiviazione è stata cancellata per qualsiasi motivo (riavvio dell'istanza, errore hardware, ...).

Soluzione: ridimensionare / dev / xvda1 (/) per ottenere la memoria desiderata

Questo è il cosiddetto Root Device Storage della tua istanza EC2 supportata da Amazon EBS , che facilita Amazon EBS per la flessibilità e la durata in particolare, vale a dire che i dati messi lì sono ragionevolmente sicuri e sopravvivono ai guasti delle istanze; puoi aumentare ulteriormente la flessibilità e la durata acquisendo istantanee regolari del tuo volume EBS, che sono archiviate su Amazon S3 , con la ben nota 99,999999999% di durata.

Questa funzionalità di istantanea ti consente di risolvere il tuo problema a sua volta, nella misura in cui puoi sostituire il tuo attuale archivio root EBS da 8 GB (/ dev / xvda1) con uno più o meno grande quanto desideri. Il processo è descritto nell'eccellente articolo di Eric Hammond Ridimensionamento del disco di root su un'istanza di avvio EBS EC2 in esecuzione :

Fintanto che si va bene con un po 'di tempo morto sull'istanza EC2 (pochi minuti), è possibile cambiare il volume EBS di root con una copia più grande, senza bisogno di avviare una nuova istanza.

Se prepari correttamente i passaggi che descrive (ti consiglio vivamente di testarli prima con un'istanza EC2 eliminabile per familiarizzare con la procedura, o automatizzarla anche con uno script su misura), dovresti essere in grado di completare il processo con alcuni minuti di inattività solo davvero.

La maggior parte dei passaggi descritti può essere eseguita anche tramite la Console di gestione AWS , il che evita di trattare con gli strumenti API Amazon EC2 ; questo si riduce a:

  • interrompere (non terminare!) l'istanza EC2
  • scollegare il volume EBS dall'istanza arrestata
  • creare un'istantanea del volume EBS staccato
  • crea un nuovo volume EBS (più grande) dall'istantanea creata
  • collega il nuovo volume EBS all'istanza EC2 ( Importante ! Se questo è il tuo dispositivo root assicurati di nominarlo esattamente come il dispositivo root dell'istanza come è stato menzionato ad esempio (/ dev / sda1) o (/ dev / xdva1) in caso contrario verrà collegato come dispositivo a blocchi e non come dispositivo root e non sarà possibile avviare l'istanza poiché non verrà elencato alcun dispositivo root per l'istanza.)
  • SSH nell'istanza in esecuzione e confermare che tutto sia in ordine tramite df -ah
    • nel caso in cui il tuo sistema non abbia ridimensionato automaticamente il file system, dovrai farlo manualmente come spiegato nell'articolo di Eric

In bocca al lupo!


Alternativa

Data la versatilità e la facilità d'uso di questi volumi EBS, un'ulteriore opzione sarebbe quella di collegare più volumi EBS alla tua istanza e spostare aree di preoccupazione chiaramente separabili laggiù.

Ad esempio, stiamo usando un paio di applicazioni Java piuttosto pesanti, ognuna delle quali consuma 1-2 GB di spazio di archiviazione per versione; per facilitare l'aggiornamento delle versioni e in generale essere in grado di spostare queste app in diverse istanze a mia discrezione, le ho posizionate su volumi EBS dedicati ciascuna, montandole su un'istanza e collegandole alla posizione desiderata, ad esempio di solito /var/lib/<app>/<version>e /usr/local/<app>/<version>.

Con questo metodo, stiamo attualmente eseguendo istanze EC2 con l'archiviazione del dispositivo root ancora alla dimensione predefinita di 8 GB (proprio come la tua), ma a volte fino a 8 volumi EBS con dimensioni variabili (1-15 GB).

Tuttavia, è necessario essere consapevoli dei potenziali problemi di prestazioni della rete, nella misura in cui tutti questi volumi EBS utilizzano la stessa LAN per il loro I / O, il che potrebbe produrre anche i rispettivi guadagni in termini di prestazioni o saturare la rete in casi estremi, quindi come al solito dipende sul caso d'uso e sul carico di lavoro a portata di mano.


Sto usando / dev / xvdb per mantenere il mio database che è di dimensioni quasi 16 GB ora, un processo in background è in esecuzione per tenerlo aggiornato. Quindi quale dovrebbe essere la migliore memoria permanente per questo database. Dovrei andare per Amazon RDS o Amazon DynamoDB. qual è il tuo suggerimento. sto eseguendo il server PHP su questa istanza.
Sumant

2
@Sumant: Non va bene, quindi hai fatto esattamente ciò che è pericoloso, vale a dire mettere i dati su un disco persistente che può praticamente andare via in qualsiasi momento (di solito non lo è, mettere uno dovrebbe trattarlo in questo modo)? Spero che non ho ape fuorviante a questo proposito - si prega di essere molto attenti quando mitigare questo al fine di evitare di perdita di dati durante il processo (si fare avere i backup di database, indipendentemente, vero?)!
Steffen Opel,

@Sumant: per quanto riguarda la tua domanda - Non dovresti aver bisogno di cambiare l'architettura della tua app (o DB per quella materia) per risolvere il problema di archiviazione, ridimensiona il tuo disco di root o collega più volumi EBS come suggerito. Se, tuttavia, desideri migliorare e disaccoppiare anche il tuo livello DB, il che è una buona cosa in linea di principio con in mente la crescita futura (ma comporta costi rispettivi dall'inizio) e supponendo che stai attualmente eseguendo MySQL, quindi Amazon RDS sarebbe la scelta perfetta e conveniente. Amazon DynamoDB richiede una nuova architettura di app completa e si applica solo a casi d'uso specifici.
Steffen Opel,

1
@Sumant: tieni presente, tuttavia, che la migrazione del tuo DB a un'istanza RDS m1.small potrebbe effettivamente mostrare prestazioni più lente rispetto al tuo attuale MySQL su EC2, che esegue m1.large con i rispettivi vantaggi delle prestazioni della CPU e I / O - se questo si applica, dipende tuttavia dal carico di lavoro del DB corrente. Ovviamente, puoi anche utilizzare istanze RDS più grandi per rimediare, ma i tuoi costi aumenteranno di conseguenza.
Steffen Opel,

1

Sì, in un modo semplice per fstab e poi montarlo per dire / var / www / html / files2 /

quindi mkdir / var / www / html / files2 / website quindi ln -s -d / var / www / html / website / var / www / html / files2 / website


usa UUID per montare la partizione usando il comando blkids e fdisk dire '/ dev / vxds /' per creare la partizione. Usa il comandante di mezzanotte per spostare i file con F6 da una cartella all'altra, assicurati di scegliere la cartella corretta nella posizione di montaggio oh e ovviamente dovrai "montare -a" dopo aver aggiunto a fstab
Daniel Chay il

0

Oggi ho riscontrato lo stesso problema, quando si imposta la nuova intance ec2 per impostazione predefinita, EBS è di 8 GB. È possibile modificare le dimensioni di EBS collegato senza creare nuova intace o scattare un'istantanea o staccare EBS. Ecco i tre passaggi che è possibile seguire:

  1. Ridimensiona il volume EBS
  2. Ridimensiona la partizione
  3. Ridimensiona partizione Per il primo passaggio vai alla tua console AWS e fai clic su EBS e cambia la dimensione desiderata e fai clic su modifica.

Per il resto dei passaggi, segui questo articolo se hai qualche domanda non esitare a chiedere.

Grazie!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.