Volume Management: Wie verschiebe ich Speicherplatz von einer Partition auf eine andere?

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 storetmp100g sein. Wie kann ich 80 g Speicher von storenach 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

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 xvdcund initialisieren Sie sie als LVM-PV (Sie müssen nicht einmal eine Partitionstabelle darauf platzieren: reicht einfach pvcreate /dev/xvdcaus). Fügen Sie dann die neue PV zu Ihrer rootrhelVG ( vgextend rootrhel /dev/xvdc) hinzu und jetzt können Sie Ihre /storetmpmit der zusätzlichen Kapazität erweitern.

lvextend -L +80G /dev/mapper/rootrhel-storetmp
xfs_growfs /storetmp  #or the appropriate tool for your filesystem type 

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 /storeund /transient, Aushängen und die gesamte entfernen storerhelVG, fügen Sie seine PV xvdb3zum rootrhelVG und Erstellen Sie dann die LVs für /storeund /transientDateisysteme 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 rootrhelVG hat drei PVs: xvdb2, xvdb3und xvdc, und viel Platz für Ihre Bedürfnisse.

Wenn Sie nicht mehr bezahlen möchten xvdc, können Sie pvmove /dev/xvdcdie Daten innerhalb der VG automatisch von xvdcund auf nicht zugewiesenen Speicherplatz innerhalb xvdb2und / oder migrieren xvdb3. Sie können dies online tun; Tun Sie dies nur nicht zum Zeitpunkt Ihrer maximalen E / A-Arbeitsbelastung, um Leistungseinbußen zu vermeiden. Dann vgreduce rootrhel /dev/xvdc, um echo 1 > /sys/block/xvdc/device/deleteden Kernel zu sagen , dass das xvdcGerät entfernt wird, und dann Amazon sagen , dass Sie nicht brauchen , Ihre xvdcFestplatte 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:

• Sie sollten niemals zwei VGs erstellen, wenn eine ausreicht.

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.

• Wenn Ihre Speicherplatzanforderungen ungewiss sind (und dies immer der Fall ist), halten Sie Ihre LVs auf der kleinen Seite und etwas nicht zugewiesenen Speicherplatz in Reserve.

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.

• Das Mikromanagement des Speicherplatzes kann riskant sein und ist viel Arbeit. Arbeit ist teuer.

Okay. Technisch gesehen könnten Sie eine 80-GB-Datei erstellen /store, losetupsie in ein Loop-Gerät umwandeln und diese dann in eine PV verwandeln, die Sie Ihrer rootrhelVG 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 ext4Dateisystem verwenden, das online reduziert werden kann, können Sie das /storeDateisystem verkleinern, den LV verkleinern, pvmove --alloc anywhereden freien Speicherplatz am hinteren Ende des xvdb3PV konsolidieren , den PV verkleinern, die Partition verkleinern und ausführen partprobe, um das zu erstellen Änderungen werden ohne Neustart wirksam, erstellen Sie dann eine neue Partition xvdb4, initialisieren Sie sie als neue PV und fügen Sie sie rootrhelVG 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.