Ich richte eine redhat ec2-Instanz ein und standardmäßig hat die von mir verwendete Software ( qradar genannt ) die folgenden Volumes auf den beiden an die Instanz angeschlossenen 500-g- ebs-Speichergeräten erstellt:
$ lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
storetmp rootrhel -wi-ao---- 20.00g
varlog rootrhel -wi-ao---- <20.00g
store storerhel -wi-ao---- <348.80g
transient storerhel -wi-ao---- <87.20g
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda2 500G 1.4G 499G 1% /
devtmpfs 16G 0 16G 0% /dev
tmpfs 16G 0 16G 0% /dev/shm
tmpfs 16G 17M 16G 1% /run
tmpfs 16G 0 16G 0% /sys/fs/cgroup
/dev/mapper/storerhel-store 349G 33M 349G 1% /store
/dev/mapper/storerhel-transient 88G 33M 88G 1% /transient
/dev/mapper/rootrhel-storetmp 20G 33M 20G 1% /storetmp
/dev/mapper/rootrhel-varlog 20G 35M 20G 1% /var/log
tmpfs 3.2G 0 3.2G 0% /run/user/1000
Ich muss storetmp
100g sein. Wie kann ich 80 g Speicher von store
nach verschieben storetmp
?
Es scheint auch, dass ich möglicherweise etwas Platz von xvdb3 nach xvdb2 verschieben muss:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 500G 0 disk
├─xvda1 202:1 0 1M 0 part
└─xvda2 202:2 0 500G 0 part /
xvdb 202:16 0 500G 0 disk
├─xvdb1 202:17 0 24G 0 part [SWAP]
├─xvdb2 202:18 0 40G 0 part
│ ├─rootrhel-varlog 253:2 0 20G 0 lvm /var/log
│ └─rootrhel-storetmp 253:3 0 20G 0 lvm /storetmp
└─xvdb3 202:19 0 436G 0 part
├─storerhel-store 253:0 0 348.8G 0 lvm /store
└─storerhel-transient 253:1 0 87.2G 0 lvm /transient
Beachten Sie, dass die Verzeichnisse derzeit von der auf der Box ausgeführten Software verwendet werden und nicht leer sind. Daher kommt das Löschen nicht in Frage. Ich muss dies im laufenden Betrieb tun:
$ ls -l /dev/mapper/storerhel-transient
lrwxrwxrwx 1 root root 7 Aug 10 16:00 /dev/mapper/storerhel-transient -> ../dm-3
$ ls -l /dev/mapper/rootrhel-varlog
lrwxrwxrwx 1 root root 7 Aug 10 16:00 /dev/mapper/rootrhel-varlog -> ../dm-0
$ ls -l /dev/mapper/storerhel-store
lrwxrwxrwx 1 root root 7 Aug 17 04:10 /dev/mapper/storerhel-store -> ../dm-2
rootrhel-storetmp
,storerhel-store
undstorerhel-transient
leeren? (Dh kann ich Ihnen die Befehle geben, um sie zu löschen, bevor Sie sie neu erstellen?)Antworten:
Weitere 80 GB in EC2 EBS kosten weniger als 12 USD pro Monat. Online-Manipulationen dauern wahrscheinlich mehr als eine Stunde Ihrer Arbeit und es besteht die Gefahr von Ausfallzeiten, wenn etwas schief geht - wie viel ist das für Sie wert?
Bezahlen Sie für zusätzliche Kapazität, fügen Sie sie Ihrer Instanz als dritte Festplatte hinzu
xvdc
und initialisieren Sie sie als LVM-PV (Sie müssen nicht einmal eine Partitionstabelle darauf platzieren: reicht einfachpvcreate /dev/xvdc
aus). Fügen Sie dann die neue PV zu Ihrerrootrhel
VG (vgextend rootrhel /dev/xvdc
) hinzu und jetzt können Sie Ihre/storetmp
mit der zusätzlichen Kapazität erweitern.Nachdem Ihr sofortiges Problem behoben ist, können Sie jetzt zu einem geeigneten Zeitpunkt Ausfallzeiten einplanen.
Wenn Sie XFS - Dateisystem verwenden (wie RHEL / CentOS 7 standardmäßig der Fall ist), dann bei der nächsten geplanten Ausfallzeiten, werden Sie erstellen tarballs der aktuellen Inhalt
/store
und/transient
, Aushängen und die gesamte entfernenstorerhel
VG, fügen Sie seine PVxvdb3
zumrootrhel
VG und Erstellen Sie dann die LVs für/store
und/transient
Dateisysteme mit realistischeren Schätzungen für ihren Kapazitätsbedarf neu und stellen Sie den Inhalt der Tarballs wieder her. Ende der Ausfallzeit.Jetzt ist Ihre
rootrhel
VG hat drei PVs:xvdb2
,xvdb3
undxvdc
, und viel Platz für Ihre Bedürfnisse.Wenn Sie nicht mehr bezahlen möchten
xvdc
, können Siepvmove /dev/xvdc
die Daten innerhalb der VG automatisch vonxvdc
und auf nicht zugewiesenen Speicherplatz innerhalbxvdb2
und / oder migrierenxvdb3
. Sie können dies online tun; Tun Sie dies nur nicht zum Zeitpunkt Ihrer maximalen E / A-Arbeitsbelastung, um Leistungseinbußen zu vermeiden. Dannvgreduce rootrhel /dev/xvdc
, umecho 1 > /sys/block/xvdc/device/delete
den Kernel zu sagen , dass dasxvdc
Gerät entfernt wird, und dann Amazon sagen , dass Sie nicht brauchen , Ihrexvdc
Festplatte mehr.Ich habe fast 20 Jahre Erfahrung in der Arbeit mit LVM-Festplattenspeicher (zuerst mit HP-UX LVM und später mit Linux LVM, sobald es so ausgereift ist, dass es in Unternehmensumgebungen verwendet werden kann). Dies sind die Faustregeln, die ich bei LVM angewendet habe:
Insbesondere das Vorhandensein von zwei VGs auf einer einzelnen Festplatte ist höchstwahrscheinlich ein Fehler, der Kopfschmerzen verursacht. Die Neuzuweisung der Festplattenkapazität innerhalb einer VG ist so flexibel, wie es Ihr Dateisystemtyp zulässt. Das Verschieben der Kapazität zwischen VGs in Blöcken, die kleiner als eine bereits vorhandene PV sind, ist normalerweise nicht die Mühe wert.
Solange in Ihrer VG nicht zugewiesene Kapazität verfügbar ist, können Sie LVs und Dateisysteme in ihnen online nach Bedarf mit ein oder zwei Schnellbefehlen erweitern. Es ist ein Ein-Bananen-Job für einen
ausgebildeten Affen-Junior-Systemadministrator.Wenn in der VG keine nicht zugewiesene Kapazität vorhanden ist, holen Sie sich eine neue Festplatte, initialisieren Sie sie als neue PV, fügen Sie sie der VG hinzu, die Kapazität benötigt, und fahren Sie dann wie gewohnt mit der Erweiterung fort. Das Verkleinern von Dateisystemen ist fehleranfälliger, erfordert möglicherweise Ausfallzeiten oder ist sogar unmöglich, ohne das Dateisystem in kleinerer Größe zu sichern und neu zu erstellen, je nach Dateisystemtyp. Sie sollten daher Situationen vermeiden, in denen Dateisysteme online so weit wie möglich verkleinert werden müssen.
Okay. Technisch gesehen könnten Sie eine 80-GB-Datei erstellen
/store
,losetup
sie in ein Loop-Gerät umwandeln und diese dann in eine PV verwandeln, die Sie Ihrerrootrhel
VG hinzufügen könnten. Dies würde jedoch zu einem System führen, das höchstwahrscheinlich in einen Wiederherstellungsmodus für einen einzelnen Benutzer übergeht beim Booten, es sei denn, Sie haben ein benutzerdefiniertes Startskript für diese Dateisysteme und VGs eingerichtet und es beim ersten Mal richtig gemacht.Verstehen Sie es falsch, und wenn Ihr System aus irgendeinem Grund das nächste Mal neu gestartet wird, müssen Sie ungeplante Ausfallzeiten für die Fehlerbehebung und -behebung in Kauf nehmen oder die Dateisysteme realistischer von Grund auf neu erstellen und den Inhalt aus Sicherungen wiederherstellen, da dies einfacher ist als die Fehlerbehebung dieses von der Jury manipulierte Durcheinander.
Wenn Sie ein
ext4
Dateisystem verwenden, das online reduziert werden kann, können Sie das/store
Dateisystem verkleinern, den LV verkleinern,pvmove --alloc anywhere
den freien Speicherplatz am hinteren Ende desxvdb3
PV konsolidieren , den PV verkleinern, die Partition verkleinern und ausführenpartprobe
, um das zu erstellen Änderungen werden ohne Neustart wirksam, erstellen Sie dann eine neue Partitionxvdb4
, initialisieren Sie sie als neue PV und fügen Sie sierootrhel
VG hinzu ...ABER wenn Sie einen Fehler in dieser Sequenz machen, so dass Ihr Dateisystem / PV über seinen LV / Partitionscontainer hinausgeht und Ihr Dateisystem in den schreibgeschützten Modus mit einem Fehlerflag geschaltet wird, das nur durch Ausführen einer Dateisystemprüfung zurückgesetzt werden kann obligatorische ungeplante Ausfallzeiten.
quelle