Die Antwort ist zweifach.
Umgehung: Verwenden Sie / dev / xvdb (/ mnt) für temporäre Daten
Dies ist der so genannte kurzlebige Speicher Ihrer Amazon EC2- Instanz, und seine Eigenschaften unterscheiden sich erheblich von denen des andernorts verwendeten dauerhaften Amazon EBS- Speichers. Insbesondere geht dieser kurzlebige Speicher bei Stopp- / Startzyklen verloren und kann in der Regel verloren gehen. Sie möchten also definitiv keinen dauerhaften Wert darauf legen , dh nur temporäre Daten, die Sie sich leisten können, einfach zu verlieren oder neu aufzubauen . wie eine Auslagerungsdatei oder streng temporäre Daten, die während der Berechnungen verwendet werden. Natürlich können Sie dort beispielsweise große Indizes speichern, müssen jedoch darauf vorbereitet sein, diese nach dem Löschen des Speichers erneut zu erstellen (Neustart der Instanz, Hardwarefehler usw.).
Lösung: Ändern Sie die Größe von / dev / xvda1 (/), um den gewünschten Speicherplatz zu erhalten
Dies ist der sogenannte Root-Gerätespeicher Ihrer von Amazon EBS unterstützten EC2-Instanz, der Amazon EBS insbesondere hinsichtlich Flexibilität und Haltbarkeit erleichtert , dh, die dort gespeicherten Daten sind relativ sicher und überstehen Instanzausfälle. Sie können die Flexibilität und Haltbarkeit noch weiter erhöhen, indem Sie regelmäßig Momentaufnahmen Ihres EBS-Volumes machen, das auf Amazon S3 gespeichert ist und über die bekannte Haltbarkeit von 99,999999999% verfügt.
Mit dieser Snapshot-Funktion können Sie Ihr Problem lösen, indem Sie Ihren aktuellen 8-GB-EBS-Root-Speicher (/ dev / xvda1) durch einen mehr oder weniger großen ersetzen. Der Prozess wird in Eric Hammonds ausgezeichnetem Artikel Größenänderung der Root-Festplatte auf einer laufenden EBS Boot EC2-Instanz beschrieben :
Solange Sie mit einer kurzen Ausfallzeit für die EC2-Instanz (einige Minuten) einverstanden sind, können Sie das Root-EBS-Volume durch eine größere Kopie ersetzen, ohne eine neue Instanz starten zu müssen.
Wenn Sie die von ihm beschriebenen Schritte richtig vorbereiten (ich empfehle dringend, sie zuerst mit einer EC2-Wurfinstanz zu testen, um sich mit der Prozedur vertraut zu machen, oder sie sogar über ein maßgeschneidertes Skript zu automatisieren), sollten Sie in der Lage sein, den Vorgang mit wenigen Schritten abzuschließen Minuten Ausfallzeit nur in der Tat.
Die meisten der beschriebenen Schritte können auch über die AWS Management Console ausgeführt werden, wodurch der Umgang mit den Amazon EC2-API-Tools vermieden wird . das läuft auf Folgendes hinaus:
- Stoppen (nicht beenden!) Sie die EC2-Instanz
- Trennen Sie das EBS-Volume von der gestoppten Instanz
- Erstellen Sie einen Snapshot des gelösten EBS-Volumes
- Erstellen Sie aus dem erstellten Snapshot ein neues (größeres) EBS-Volume
- Hängen Sie das neue EBS-Volume an die EC2-Instanz an ( Wichtig ! Wenn es sich um Ihr Root-Gerät handelt, stellen Sie sicher, dass es genau den Namen des Root-Geräts der Instanz trägt, wie es erwähnt wurde, z. B. (/ dev / sda1) oder (/ dev / xdva1). Andernfalls wird es als Block-Gerät und nicht als Root-Gerät angehängt, und Sie können die Instanz nicht starten, da für die Instanz kein Root-Gerät aufgeführt ist.)
- SSH in die laufende Instanz und bestätigen Sie alles ist in Ordnung über
df -ah
- Falls Ihr System die Größe des Dateisystems nicht automatisch geändert hat, müssen Sie dies manuell tun, wie in Erics Artikel erläutert
Viel Glück!
Alternative
In Anbetracht der Vielseitigkeit und Benutzerfreundlichkeit dieser EBS-Volumes besteht eine zusätzliche Option darin, mehr EBS-Volumes an Ihre Instanz anzuhängen und klar trennbare Problembereiche dorthin zu verschieben.
Zum Beispiel verwenden wir einige ziemlich schwere Java-Anwendungen, von denen jede 1 bis 2 GB Speicherplatz pro Version beansprucht. zu erleichtern Upgrade - Versionen und generell in der Lage sein , diese Anwendungen auf verschiedenen Instanzen in meinem Ermessen zu bewegen, habe ich sie auf dedizierten EBS - Volumes je platziert, montieren diese auf eine Instanz und Softlink sie an den gewünschten Ort, zB in der Regel /var/lib/<app>/<version>und /usr/local/<app>/<version>.
Mit dieser Methode führen wir derzeit EC2-Instanzen aus, wobei der Root-Gerätespeicher immer noch die Standardgröße von 8 GB aufweist (genau wie bei Ihnen), manchmal aber auch bis zu 8 EBS-Volumes mit unterschiedlichen Größen (1 bis 15 GB).
Sie müssen sich jedoch der potenziellen Netzwerkleistungsprobleme bewusst sein, sofern alle diese EBS-Volumes dasselbe LAN für ihre E / A verwenden, was in extremen Fällen sogar zu entsprechenden Leistungsgewinnen führen oder Ihr Netzwerk überlasten kann. Dies hängt also wie üblich davon ab auf den Anwendungsfall und die Arbeitsbelastung zur Hand.