Proxmox TLS certificaat via LetsEncrypt

Kort stappenplan:

  • Emailalias aanmaken voor het account
  • Account via certificates/ACME/create account
  • Accountnaam = nodenaam + staging, email = alias, directory = staging v2
  • Domein voor certificaat toevoegen op datzelfde scherm, certificates/ACME/Add
  • Publiek toegankelijk? Dan werkt HTTP als challenge makkelijk. Interne domeinnamen? Dan is DNS eenvoudiger.
  • Klaar? “Order Certificates Now”
  • Alles OK? Dan nieuw account maken met de productie-URL
    • Ga naar het tweede tabje, “ACME Accounts”
    • “Add” onder accouns
    • Gebruik nu nodenaam zonder staging als toevoeging, en “Let’s Encrypt V2” als directory
    • Terug naar tabje “Certificates”
    • Ververs de pagina, kies nu “Using Account:” de zojuist toegevoegde. Niet beschikbaar? Dan pagina (nogmaals) verversen.
    • “Order Certificates Now”
    • En klaar!

De node is nu bereikbaar onder de domeinnaam, zonder een beveiligingsuitzondering in je browser te maken.

Print this entry

LVM cache aan bestaande LVM RAID1 mirror toevoegen

Een nieuwe HP Microserver gen8 is ingericht met Proxmox.

Proxmox is geinstalleerd op een RAID1 LVM dat draait op twee uSD-kaartjes: eentje in het op het moederbord geintegreerde slot, en eentje via een adapter in de op het moederbord geintegreerde USB A aansluiting.

Dat was ik volledig vergeten, tot ik me realiseerde waarom `apt dist-upgrade` zo langzaam liep.

In het verdere reilen en zeilen van de server is er weinig aan te merken. Ik maak me wel enige zorgen over het schrijven van logbestanden, en swap heb ik nog niet aangemaakt.

Om het wat te verlichten voor de geheugenkaartjes, voeg ik 1 GB SSD cache toe (op een volume van 18 GB).

Uit te voeren stappen:

  • SSD partitioneren
    • fdisk /dev/sdh
    • bij een ongebruikt/nieuw opslagmedium, g voor GPT partitielabel
    • n voor nieuwe partitie, t voor type lvm, w om op te slaan
  • Partitie aanmerken als LVM-partitie
    • pvcreate /dev/sdh1
  • Fysiek volume toevoegen aan de volumegreop van de rootpartitie
    • vgextend usbsdraid /dev/sdh1
  • Toekomstig caching volume toevoegen aan bestaande volumegroep
    • lvcreate -vn cache_mt_usbsdraid -l254 mt_usbsdraid /dev/sdh1
  • Volume omzetten naar gecached volume, verwijzend naar het caching volume
    • lvconvert --type cache --cachepool cache_mt_usbsdraid /mt_usbsdraid mt_prox_sys

Dat is alles. Bekijk het resultaat met lvs mt_usbsdraid:

# lvs mt_usbsdraid
  LV          VG           Attr       LSize  Pool                       Origin              Data%  Meta%  Move Log Cpy%Sync Convert
  mt_prox_sys mt_usbsdraid Cwi-aoC--- 18.00g [cache_mt_usbsdraid_cpool] [mt_prox_sys_corig] 0.04   2.10            0.00     

Bovenstaand cache heet in LVM-termen ‘dm-cache’. Het cached in de eerste plaats veelgebruikte data voor snellere toegang, en voorziet bovendien in cache voor schrijfacties.

Daarnaast is er ‘dm-writecache’, specifiek voor het cachen van schrijfoperaties. Ik weet niet of een combinatie van dm-cache en dm-writecache mogelijk is, en of er dan een cascade van caches ontstaat bij het schrijven.

Juist voor het schrijven naar de uSD-kaartjes wil ik caching hebben; aan de ene kant voor de snelheid, maar vooral omdat ik bang ben dat de willekeurige schrijfacties naar verschillende logbestanden funest zijn voor de geheugenkaartjes.

Helaas is het voor het toepassen van dm-writecache nodig het volume offline te halen (vgchange -an mt_usbsdraid/mt_prox_sys), waarmee het systeem z’n rootpartitie kwijtraakt. Misschien probeer ik wat de gevolgen zijn op een VM, maar voor een live systeem heb ik er niet zoveel zin in. Wordt allicht vervolgd.

Print this entry

Containers met internet, maar Proxmox zonder

Het lukte niet meer om Proxmox de upgraden. Het bleek dat er geen internettoegang meer was. Specifieker: het hele lan, behalve de (interne kant) router was bereikbaar. Bij nader onderzoek bleek PBS, de backupserver, hetzelfde probleem te hebben.

Het lukte ook niet om vanaf de router die twee machines te bereiken. Ondertussen werkten de containers gewoon en waren bereikbaar vanaf internet, en konden er ook gewoon backups verstuurd worden.

Na toch wel een tijdje puzzelen met DNS, DHCP/statisch, bonds en bridges, kwam ARP in beeld als boosdoener. arping gaf niet thuis op het IP dat ik voor ogen had, en gaf een incorrect MAC bij een IP wat wel een reactie gaf.

De oorzaak zat er in dat ik voor enkele hosts een statische MAC/IP koppeling in de ARP-tabel van OPNSense had laten vastleggen, met het idee de MAC-adressen niet uit het hoofd te hoeven leren voor wake-on-lan.

De boosdoener: een statisch ARP record

Na uitvinken van de vinkjes, toepassen van de wijzigingen en leeggooien van de ARP-tabel, werkte het weer!

Print this entry

Schijfmigratie met LVM – huidige/doel-indeling

De computer heeft zes SATA-aansluitingen. Ze zijn allemaal in gebruik en de schijven leken opgebruikt – helemaal vol.
Bij nader onderzoek bleek dat niet helemaal het geval, maar met een set nieuwe en eerder bestelde lege schijven beschikbaar, toch de stoute schoenen aangetrokken.

Dat is de NAS/mediaserver. De andere computer, met Proxmox virtualisatie, heeft een aantal virtuele machines met Yunohost-websites draaien. Met aanvankelijk 0 ervaring met Proxmox, heb ik nu ook andere gedachten over de inrichting van de opslagruimte daar.

De huidige inrichting, wat fysieke schijven betreft:

  • NAS/mediaserver (6/6 SATA bezet)
    • 1x 0,1TB Intel 320 SSD TLC
    • 1x 2TB Western Digital Green(CMR)
    • 2x 2TB Western Digital Red(CMR)
    • 1x 3TB Toshiba/Hitachi Deskstar (CMR)
    • 1x 6TB Western Digital Red (CMR)
  • Proxmox virtualisatieserver (4/4 SATA bezet)
    • 1x 1TB Samsung SSD QLC
    • 1x 1TB Samsung Spinpoint (CMR)
    • 1x 4TB Seagate Barracuda (CMR)
    • 1x 6TB Seagate Barracuda (SMR)
  • Beschikbare opslagmedia
    • 1x 0,1TB Intel X25 SSD MLC
    • 1x 0,5TB Crucial MX SSD TLC
    • 1x 8TB Western Digital ‘Pink’ (white label, red internals) (CMR)

Met passen en meten kan in beide servers 12TB+SSD caching geplaatst worden. Er blijft dan 9TB, verdeeld over 3x2TB + 1x3TB, over voor externe backup, uitbreiding, noodgevallen, of een derde server.

NAS/Mediaserver

De huidige inrichting in meer detail is:

RAID (HDD)
           /   1G R1-PV md0 VG boot   LV boot
 2TB \    |/ 900G R5-PV md2 VG data\  
 2TB - - - - 900G R5-PV md3 VG data-- LV foto
 2TB /    |\ 900G R5-PV md4 VG data/    ,geluid
           \\850G R5-PV md5 VG home   LV wbk,home
            \ 85G R5-PV md1 VG sys    LV /,usr,var
                                        ,log,cache
Single disk (HDD)
       - 1100GB VG film
     / -  100GB VG home
 3TB - -  100GB VG muziek  
     \ -  100GB VG mail
       -  100GB VG pub
       \ 1500GB free

      /- 5000GB incremental backup
 6TB -
      \- 1000GB data rescue oude schijven

Single disk (SSD) 
 0,1TB handmatig toegewezen config, databases, cache

De nieuwe inrichting wordt:

SSD
 0,1TiB
   - Swap
   - LVM metadatacache 1% van LVM cache
   - LVM writecache? 
   - MD RAID1 /boot
   - Databases
 0,5TiB
   - Swap
   - LVM datacache ~5% van LVM data
     - 230G voor PMR 5,5TiB
     -  30G voor VG system
     -  20G voor VG homes
     -  50G voor VG data
   - MD RAID1 /boot

Disk drive
 5,5TiB SMR: bestaande data -> veel lezen
  - 5200G VG data  : 
          LV foto
           , film
           , muziek
           , rom
   - 200G VG home
          LV per user, LVM thin
   - 100G VG system : 
          LV root 
           , usr
           , var 
           , varlog
           , varcache
   -  0,5G MD RAID1 /boot

 5,5TiB CMR: nieuwe data -> veel schrijven
   - 2000G VG data
           LV als boven, LVM thin
   - 1200G VG home 
           LV per user, LVM thin
   - 2000G VG infra 
           LV mail
            , vm 
            , backup 
   -  100G VG system
           LV als boven

Waar blijft de opslagruimte

De getallen tellen niet helemaal lekker op. Een HDD van 6TB heeft 5,5TiB beschikbare ruimte.
LVM metadata gebruikt een deel van de VG, waardoor de optelsom van alle PV/VG meer is dan de optelsom van de toegewezen ruimte in de LV’s.
Het bestandssysteem op de LV’s die als partitie beschikbaar komen, gebruikt ook weer wat administratieve ruimte.

Na krap tien jaar hebben de LV’s in de system-VG een stabiele grootte:

  • Gebruikt vs toegewezen per LV / mountpoint
    • / 2G gebruikt van 15G toegewezen
    • /usr 15G gebruikt van 15G toegewezen
    • /var 18G gebruikt van 20G toegewezen
      • /var/www is voor een groot deel op andere partities gemount, onder LV’s in VG data
    • /var/log 3G gebruikt van 7G toegewezen
    • /var/cache 2G gebruikt van 3G toegewezen
  • Totaal 40G gebruikt van 60G toegewezen in LV’s; de VG heeft een grootte van 80G (dus 25% overhead).
  • In de nieuwe inrichting wordt de VG 100G, is er dus enige ruimte voor groei.

Van alle LV’s is ‘foto’ het meeste gegroeid, en neemt de groei per jaar toe. De afgelopen 20+ jaar neemt 3000G in beslag, gemiddeld 150G per jaar, maar alles van voor 2009 zit daar een orde van grootte onder, terwijl 2012 het laatste jaar met minder dan 200G is. Vanaf 2019 fotograferen we met z’n tweeen, en neemt de beschikbare opslagruimte versneld af. Komende jaren zal het aantal mediaproducenten verdubbelen. Als ik reken met 500G per jaar, dan kunnen we met het voorstel hierboven tot 2025 uit.

Caching

LVM kan zowel voor de data als voor de metadata cache inzetten. Met het bulk aan opslagruimte op trage HDD’s en enkele procenten daarvan op snellere SSD’s, ligt het voor de hand om het cache op SSD’s onder te brengen. Door het data-cache en het metadata-cache op verschillende media te zetten, kunnen ze snel parallel gelezen en geschreven worden.

Als voorbereiding op het configureren van LVM cache heb ik een aantal blogs doorgenomen:

Over LVM writecache heb ik weinig gevonden. Vooral voor de data-VG’s op de PMR-schijf zou ik dat willen inzetten.

Als maatstaf wordt voor metadatacache 0,1 procent van datacache aangehouden. Dat komt overeen met grootte van de bestanden die ik vind in /etc/lvm/archive. Voor datacache heb ik geen cijfers gevonden.

De SSD’s van 120GB en 480GB gebruik ik als cache voor de HDD’s; de eerste voor LVM metadata, de tweede voor de data zelf.

In totaal is er ongeveer 10TiB beschikbare ruimte in de bestandssystemen. De SSD is met 0,44TiB nog geen 5% daarvan. De systeem-VG’s zijn veel kleiner dan de data-VG’s, terwijl er vaker van gelezen en naar geschreven wordt.
De systeem-VG is een van de kleinste VG’s, en staat op de langzaamste HDD. De VG krijgt daarom relatief ruime caching, 30G cache op 100G VG.
De data-VG’s worden vrijwel niet met random reads bestookt. Sequentieel lezen van een SMR-disk mag geen probleem zijn, dus LV’s met foto’s en films hebben vooral baat bij schrijfcache. Dat mag, ten opzichte van de volledige grootte van de LV’s, relatief heel klein zijn: 10G cache per TB opslagruimte. Bij de initiele grootte van 3000G dus 30G, voldoende om het grootste deel van SD-kaartjes te cachen bij het importeren.
Home-directories vallen tussen data- en systeem-VG’s in: er zijn vrij veel kleine bestanden en er worden relatief veel bestanden willekeurig geopend. Er worden geregeld aan willekeurige bestanden wijzigingen gedaan. De VG is te groot om naar rato veel cache aan toe te wijzen. Omdat er zowel bij het schrijven als bij het lezen winst te behalen is, wordt de toewijzing wel ruimer dan bij de data-VG’s

In de eerste instantie doe ik een vrij grove toewijzing op de helft van de SSD voor de SMR schijf. Die schijf wordt als eerste in gebruik genomen, en heeft het meeste baat bij caching. Dus:

  • 230GB cache toewijzen aan volume groups op de PMR schijf
  • system: 30G cache op 100G volume group
  • home: 20G op 200G volume group
  • data: 50G cache op 5200G volume group
  • latere toewijzing: 100G over voor deze schijf
  • cachemode instellen met lvconvert –cachemode wrideback om enkel naar cache te schrijven

RAID

Er komen twee software RAID devices via mdadm. Voorheen deed ik het inrichten van mdadm zelf. In dit geval laat ik het management aan LVM over, door lvmraid te gebruiken via

  • RAID1 /boot, over vier schijven. Het is maar een paar honderd MB. Op die manier maakt het niet uit welke opslagmedium uit het systeem gehaald wordt, er kan in ieder geval een begin met de start van het systeem gemaakt worden.
  • RAID1 ‘systeem’-partities over de twee HDD’s. Het resulterende RAID-device wordt als PV vrijgegeven in de system-VG, daarin LV’s voor /, /usr, /var, /var/log en /var/cache.
  • Zorg dat er geschreven wordt naar de snelste schijf, –write-mostly en –write-behind
  • commando: lvcreate –type raid1 VG [PV’s]
  • lvcreate –type raid1 system /dev/sdxn /dev/sdym
  • Zorgen dat de writes initieel (–write-mostly) naar PMR gaan, en lezen van hetzij PMR of SMR. Is te combineren met –write-behind ‘aantal’. Het is me niet duidelijk of write-mostly betekend “deze PV vooral voor schrijven gebruiken, de rest is niet zo snel”, of “deze PV niet voor lezen gebruiken, want het is een traag beestje”.
  • commando: lvchange –writemostly PV LV
  • VG ‘system’ opnemen in RAID1 met de CMR-schijf. Voor hints, zoek naar ‘–write-mostly’ en ‘–write-behind’ opties voor mdadm.

OverlayFS

De partities in de data-VG wil ik via bind mount beschikbaar maken in de home-directories als read-only. Wijzigingen en eigen toevoegingen zouden met AUFS toegevoegd worden aan een geintegreerde weergave.

AUFS is niet meer in ontwikkeling, in plaats daarvan is OverlayFS beschikbaar in de kernel.

Thin provisioning

Thin provisioning betekent eigenlijk ‘meer beloven dan je hebt’. Uit een pool van 100G worden bijvoorbeeld drie logische volumes van 50G gemaakt. Ieder van die partities mag naar hartelust beschreven worden, er wordt telkens een stukje van de gemeenschappelijke reserve afgesnoept. Zolang de VG op tijd verruimd wordt, en er op tijd schijven bijgeplaatst worden om PV’s toe te voegen, is er niets aan de hand.

https://www.systutorials.com/docs/linux/man/8-lvconvert/Het voordeel is, dat je voor een set van 7 logische volumes niet van tevoren hoeft te bedenken hoeveel ruimte ze gaan gebruiken. In de oude opstelling was thin provisioning een uitstekende keuze voor de system-VG geweest, met als enig nadeel dat een defect stuk hardware of een klapperende verbinding veel logging zou kunnen veroorzaken. Met vast toegewezen LV’s is dan op een gegeven moment /var/log vol, met (beperkte) gevolgen van dien. Met thin provisioned LV’s is niet alleen de ruimte op /var/log vol, maar ook de vrije ruimte op de overige partities in de volumegroep.

Documentatie en voorbeelden heb ik in blogs gevonden:

Trim

Zowel voor SSD’s als voor SMR-HDD’s geldt dat beschreven ruimte niet ineens overschreven kan worden.

Voor beide opslagtypes is daarom ’trim’ support in alle lagen van de opslag gewenst: in het bestandssysteem, LVM en, indien van toepassing, RAID.

In hoeverre die ondersteuning er is, moet ik nog uitzoeken/uitvinden. Zoektermen lijken ‘fstrim’, ‘discard’, ‘cascade down’ ; serverfault suggereerd lsblok -D , man 5 lvm.conf, mdmtrim script van cyberax op Github, ‘don`t enable discard, use fstrim.timer’. Zelfde post: (in 2012) Linux kernel became able to support block discards in the setup.

Ook aan denken

Ontdubbeling met lvmdo (data optimizer, deduplication + compression); lvmdo is een project dat onder Red Hat valt door overname van de ontwikkelaar ervan. Op Debian is de benodigde programmatuur nog niet beschikbaar. Op Stackexchange staat een pointer over het bouwen van de kernenmodule onder Debian:

# apt-get install -y build-essential libdevmapper-dev libz-dev uuid-dev python3-yaml 
# git clone https://github.com/dm-vdo/vdo.git 
# make && make install && sudo apt install -t stretch-backports linux-headers-$(uname -r) 
# git clone https://github.com/dm-vdo/kvdo.git 
# make -C /usr/src/linux-headers-`uname -r` M=`pwd` 
# cp vdo/kvdo.ko /lib/modules/$(uname -r) cp uds/uds.ko /lib/modules/$(uname -r) 
# depmod && modprobe kvdo && modprobe uds
# vdo create --name=vdo-data --device=/dev/md0 --vdoLogicalSize=8T
# systemctl start vdo
# vdo status

Algemene LVM links

LVM internals
Development/LVM support

Stappenplan

PMR-schijf indelen

Welke data waar

Ik wil de PMR-schijf eigenlijk vullen met de meest statische data vooraan, en de meest variabele data aan het einde.
Hoe de firmware het intern afhandeld is me niet bekend. Het lijkt me dat er begonnen wordt met schrijven aan de buitenkant (draait het snelste, geeft voor nieuwe gebruikers van de schijf de beste indruk) en dat er telkens verder naar binnen geschreven wordt.

Als de buitenste 80% van de platters beschreven zijn, en bestanden in de buitenste 1% worden gewijzigd, dan moeten gewijzigde sectoren daar gelezen worden en ergens anders herschreven worden. Of op dezelfde plaats, maar dan moet meteen de hele set ‘dakpannen’ vervangen worden.

Aan de andere kant, als de buitenste 80% beschreven zijn en iets aan de binnenste 1% daarvan wordt gewijzigd, dan is er vlakbij nog een hoop vrije ruimte en hoeft er misschien minder geschoven te worden.

Ongeacht of er van buiten naar binnen, of van binnen naar buiten geschreven wordt, ik ben bang voor fragmentatie (of contstante defragmentatie) als datasets met veel wijzigingen erg goed ingepakt zijn.

De voorlopig meest statische data zijn foto’s. (Update april 2021: dat zijn ze niet: bijwerken van tags in Digikam en die wegschrijven naar EXIF van de jpg’s heeft wijzigingen tot gevolg. Zonder daar verder in te duiken, verwacht ik dat slechts een deel van de data wijzight als er tags naar EXIF en dergelijke geschreven worden, en dat de wijzigingen op blokniveau worden afgehandeld, dus niet voor de hele foto op bestandsniveau.) Dat is meteen een grote set, dus een mooie benchmark voor de schijf. Het is te hopen dat er niet altijd eerst een CMR-cache volgeschreven wordt, voordat de schijf gegevens gaat overzetten naar SMR. Als dat cache 50G zou zijn, dan wordt er telkens voor een paar minuten snel geschreven, tot dat cache vol zit, daarna lang wachten om het cache te kopieren en te wissen, en dan opnieuw.

Ongeacht de interne caching: ik denk niet dat externe LVM-caching daarbij gaat helpen: er is alleen een extra emmertje met data dat moet wachten totdat de SMR-schijf z’n werk gedaan heeft.

Methode

Ik heb niet vaak volledig uit te wisselen schijven. Data groeit, maar verplaatst niet vaak van plaats. Waar nodig, volstond dan een move op bestandssysteem niveau.

Voor volledige partities verplaatsen zou rsync een goede optie zijn, of een backup maken en die terugzetten.

In het geval van LVM is er een optie om een schijf (PV) aan een volumegroep (VG) toe te voegen, vervolgens alle extends van een logisch volume (LV) te spiegelen op extends in dezelfde VG op die nieuwe PV, en vervolgens de spiegeling aan de kant van de PV’s op de oude schijf ongedaan te maken.

Het voordeel is ook het nadeel. De huidige LV’s gaan volledig identiek over, ik weet niet zeker of ik voor de systeem-VG dezelfde werkwijze volg: dan heeft root op / nog steeds een hoop vrije ruimte, en is /usr wat krap.

Stap 1, partitionering

# fdisk /dev/sdf
g voor een nieuwe GPT partitietabel; gooit alles weg
n voor nieuwe partities
t voor het type, 20 voor 'Linux filesystem' 
w om wijzigingen op te slaan

Stap 2, Fysiek volume aanmaken en toewijzen aan volumegroep

# # eerst eens in test-modus
# pvcreate -vt /dev/sdf1 
...
# # dan aanmaken
# pvcreate -v /dev/sdf1 
Wiping signatures on new PV /dev/sdf1. Set up physical volume for "/dev/sdf1" with 10485760000 available sectors. Zeroing start of device /dev/sdf1. Writing physical volume data to disk "/dev/sdf1".
Physical volume "/dev/sdf1" successfully created.

# # toevoegen aan volumegroep
# vgextend -vt data /dev/sdf1
... 
# # zonder test 
# vgextend -v data /dev/sdf1
Wiping signatures on new PV /dev/sdf1.
Archiving volume group "data" metadata (seqno 16).
Adding physical volume '/dev/sdf1' to volume group 'data'
Volume group "data" will be extended by 1 new physical volumes
Creating volume group backup "/etc/lvm/backup/data" (seqno 17).
Volume group "data" successfully extended

Er is onvoldoende ruimte (0 extends) beschikbaar om het mirrorlog aan te leggen op de bestaande PV’s van VG data. Er moet eerst ruimte vrijgemaakt worden.

Met lvs is te zien welke LV’s er op VG data huizen. Met df is te zien waar vrije ruimte is.

root@fractal:~# df -hT |grep 'File|foto|geluid'
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/data-fotos ext4 2.7T 2.6T 2.8G 100% /home/wbk/photos
/dev/mapper/data-geluid ext4 46G 39G 5.4G 88% /home/wbk/sounds

vgresize kan de boel kleiner maken, met -r wordt het bestandssysteem ook op maat gemaakt. Zonder -r wordt het bestandssysteem ‘afgeknipt’, en is de boel mogelijk stuk.

lvresize -rvL -5G /dev/data/geluid
Executing: /sbin/fsadm --verbose check /dev/data/geluid
fsadm: "ext4" filesystem found on "/dev/mapper/data-geluid".
fsadm: Filesystem has not been checked after the last mount, using fsck -f
fsadm: Executing fsck -f -p /dev/mapper/data-geluid
fsck from util-linux 2.33.1
geluid: 7763/3055616 files (1.1% non-contiguous), 10199026/12206080 blocks
Executing: /sbin/fsadm --verbose resize /dev/data/geluid 43581440K
fsadm: "ext4" filesystem found on "/dev/mapper/data-geluid".
fsadm: Device "/dev/mapper/data-geluid" size is 49996103680 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/data-geluid"
fsadm: Resizing filesystem on device "/dev/mapper/data-geluid" to 44627394560 bytes (12206080 -> 10895360 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/data-geluid 10895360
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/data-geluid to 10895360 (4k) blocks.
The filesystem on /dev/mapper/data-geluid is now 10895360 (4k) blocks long.
Archiving volume group "data" metadata (seqno 17). Reducing logical volume data/geluid to 41.56 GiB
Size of logical volume data/geluid changed from 46.56 GiB (11920 extents) to 41.56 GiB (10640 extents).
Loading table for data-geluid (253:4).
Suspending data-geluid (253:4) with device flush
Resuming data-geluid (253:4).
Creating volume group backup "/etc/lvm/backup/data" (seqno 18).
Logical volume data/geluid successfully resized.
# # spiegelen instellen; default type=raid
# # lvconvert --type raid1 /dev/data/fotos
# # bij m1 wordt er 1 kopie gemaakt, dus op
# # de nieuw toegevoegde PV
# # lvconvert -m1 /dev/data/fotos
# # samengesteld commando:
# lvconvert -m1 /dev/data/fots /dev/sdf1
Are you sure you want to convert linear LV data/fotos to raid1 with 2 images enhancing resilience? [y/n]: yes
Logical volume data/fotos successfully converted.

Sync van de LV’s gaat meteen van start. Na tien minuten:

lvs
LV    VG   Attr       LSize    ...   Cpy%Sync 
boot  boot -wi-ao---- 188.00m
fotos data rwi-aor--- 2.68t          2.19

Volgens htop is vooral rsyslog -n -iNone heel druk, met enkele tientallen procenten CPU. Dat heeft, volgens mij, niets met deze actie te maken (er zit al meerdere uren CPU-tijd in); iotop heeft schrijfsnelheden in tientallen kB/s… niet heel snel.

Aan de andere kant, als het zo doorgaat, dan zit er nog 500 minuten in, en zou er in een halve dag 3TB overgezet zijn. Acht uur later staat de teller op 75%, en laat iotop pieken van 30MB/s zien als ik de machine uit z’n rust haal. Daarna zakt de snelheid weer in naar de kB/s-range. Ik heb het idee dat mdadm/LVM te low-level is voor iotop: firefox is het proces dat meestal bovenaan staat, qua bandbreedte en totaal gebruik, en dat loopt niet in de GB’s.

Het juiste commando blijkt niet iotop, maar iostat:

# # geef eXtended info, in Human-readable formaat over
# # Devices (in tegenstelling tot -c, CPU), ververs na
# # 10 seconden
# iostat -hdx 10 -g read /dev/sd[abc] /dev/md2 -g write /dev/sdf

Daarmee is te zien dat van /dev/sda, /dev/sdb en /dev/sdc telkens zo’n 25MB/s gelezen wordt, uit /dev/md1 die door die drie gevormd wordt zo’n 75MB/s en dat er met dezelfde snelheid naar /dev/sdf1 geschreven wordt.

Uiteindelijk heeft de synchronisatie zo’n 10 uur geduurd voor 3TB, dus de 75MB/s heeft de schijf grofweg volgehouden.

Volgende LV: geluid. Op dezelfde manier:

# lvconvert -m1 /dev/data/geluid /dev/sdf1

In de geluid-partitie zit niet alleen geluid. Er staan een paar ISO’s met C’t-jaargangen. Dat is de helft van de ruimte en moet eigenlijk opgeruimd worden. Daarom een swap-truc tussendoor:

  • SSD 480GB hot-unplug
  • HDD 3TB hot-plug
  • verplaats ISO’s /home/wbk/geluid naar /home/nonraid/tijdelijk
  • verklein (opnieuw) het geluid LV in VG data
    • lvresize -rvL -25G /dev/data/geluid

Vervolg-spiegelacties:

  • lvconvert -m1 /dev/data-nonraid/muziekNR /dev/sdf1
  • lvconvert -m1 /dev/data-nonraid/pubNR /dev/sdf1
  • lvconvert -m1 /dev/data-nonraid/homesNR /dev/sdf1
  • lvconvert -m1 /dev/data-nonraid/video /dev/sdf1

Wat blijkt? LV’s kunnen alleen binnen dezelfde VG gespiegeld worden. VG’s kunnen ook alleen binnen dezelfde VG verplaatst worden van PV naar PV.

De eenvoudigste optie om de data met LVM-boordmiddelen te kopieren, lijkt:

  • de bestaande VG ‘data’ op /dev/sdf1 te verkleinen van 5TB naar 3TB
  • de PV op dezelfde manier te verkleinen
  • de fysieke partitie net zo verkleinen
  • nieuwe partitie creeren
  • nieuwe PV creeren
  • de nieuwe PV aan VG ‘data-nonraid’ toevoegen
  • vervolgens via RAID de LV’s spiegelen
  • RAID-spiegeling voor alle LV’s in VG’s ‘data’ en ‘data-nonraid’ uitzetten
  • (misschien de ‘oude’ VG’s van naam veranderen)
  • nieuwe VG ‘data-nonraid’ inactief maken met vgchange -an
  • nieuwe VG ‘data-nonraid’ en VG ‘data’ samenvoegen met vgmerge

Volgende obstakel: er is geen eenvoudige manier om de grootte van een PV te sturen in een kleinere richting.

Ik denk dat de juiste manier is:

  • alle physical extends (PE’s) naar het begin van de PV schuiven met pvmove
  • fysieke partitie kleiner maken, maar niet te klein (voorkom ‘afknippen’ aan de achterkant)
  • PV automatisch op maat maken met pvresize /dev/sdf1
    • als ik pvresize -tv –setphysicalvolumesize 5700000s /dev/sdf1 doe, krijg ik een onduidelijke waarschuwing
    • de onduidelijke waarschuwing blijkt expres toegevoegd te zijn, er is een nieuwe prompt om alsnog de resize door te voeren:
      • [root@virt-365 ~]# pvresize –setphysicalvolumesize 100G /dev/sdj -y WARNING: /dev/sdj: Overriding real size 40.00 GiB. You could lose data. WARNING: /dev/sdj: Pretending size is 209715200 not 83886080 sectors. Physical volume “/dev/sdj” changed 1 physical volume(s) resized / 0 physical volume(s) not resized

Over verkleinen van LV’s is een hoop te vinden, over verwijderen van PV’s uit VG’s ook nog wel en hier en daar wat over het vergroten van een PV met pvresize. Verkleinen maar heeeel weinig.

Ik heb mijn geluk beproeft met (KDE) partitionmanager. Tot mijn blijde verrassing wist de partitionmanager niet alleen LVM-volumes te herkennen, maar ook te kunnen beheren. Omdat alle gebruikte PE’s aan het begin van de PV stonden, was de actie snel doorgevoerd.

Verder met het kopieren van data-nonraid LV’s. Voor het uitbreiden van de VG test ik het automatisch aanmaken van de PV:

# vgextend -v data-nonraid /dev/sdf2
Wiping signatures on new PV /dev/sdf2.
Archiving volume group "data-nonraid" metadata (seqno 13).
Adding physical volume '/dev/sdf2' to volume group 'data-nonraid'
Volume group "data-nonraid" will be extended by 1 new physical volumes
Creating volume group backup "/etc/lvm/backup/data-nonraid" (seqno 14).
Volume group "data-nonraid" successfully extended

In een keer raak, behalve dat ik 1.4G, in plaats van 1.4T als partitiegrootte had gekozen. Dus: PV weghalen uit VG, partitie verwijderen, opnieuw toevoegen en VG uitbreiden.

# vgreduce -v data-nonraid /dev/sdf2
Archiving volume group "data-nonraid" metadata (seqno 12). Removing "/dev/sdf2" from volume group "data-nonraid" Creating volume group backup "/etc/lvm/backup/data-nonraid" (seqno 13).
Removed "/dev/sdf2" from volume group "data-nonraid"

Het gaat niet helemaal lekker na het verwijderen en toevoegen van een grotere partitie. Misschien is er ergens cache blijven hangen, een stukje metadata of het toevoegen van PV’s gaat niet helemaal lekker via vgextend. Als melding:

# vgextend -v data-nonraid /dev/sdf2
Physical volume '/dev/sdf2' is already in volume group 'data-nonraid'
Unable to add physical volume '/dev/sdf2' to volume group 'data-nonraid'
/dev/sdf2: physical volume not initialized.

Na verwijderen uit de VG, opnieuw initialiseren en weer toevoegen, werkte het naar behoren:

# pvcreate /dev/sdf2
Can't initialize physical volume "/dev/sdf2" of volume group "data-nonraid" without -ff
/dev/sdf2: physical volume not initialized.
# vgreduce -v data-nonraid /dev/sdf2
Archiving volume group "data-nonraid" metadata (seqno 14).
Removing "/dev/sdf2" from volume group "data-nonraid"
Creating volume group backup "/etc/lvm/backup/data-nonraid" (seqno 15).
Removed "/dev/sdf2" from volume group "data-nonraid"
# pvcreate /dev/sdf2
Physical volume "/dev/sdf2" successfully created.
root@fractal:/var/log# vgextend -v data-nonraid /dev/sdf2
Wiping signatures on new PV /dev/sdf2.
Archiving volume group "data-nonraid" metadata (seqno 15).
Adding physical volume '/dev/sdf2' to volume group 'data-nonraid'
Volume group "data-nonraid" will be extended by 1 new physical volumes
Creating volume group backup "/etc/lvm/backup/data-nonraid" (seqno 16).
Volume group "data-nonraid" successfully extended
# pvs /dev/sdf2
PV VG Fmt Attr PSize PFree
/dev/sdf2 data-nonraid lvm2 a-- 1.39t 1.39t

Misschien niet de handigste beslissing, maar tijdens het synchroniseren van LV ‘musiek’ ben ik met de KDE partition manager de overige LV’s en PV’s gaan verkleinen, waar mogelijk. Onder water doet die hetzelfde als ik met de hand had moeten doen, zoals in het log te zien is:

Shrink partition ‘/dev/sde2’ from 632.05 GiB to 359.53 GiB
Job: Check file system on partition ‘/dev/sde2’
Command: lvm pvck --verbose /dev/sde2
Found label on /dev/sde2, sector 1, type=LVM2 001
Found text metadata area: offset=4096, size=1044480
Check file system on partition ‘/dev/sde2’: Success

Job: Resize file system on partition ‘/dev/sde2’ to 753993728 sectors
Resizing file system from 1325512704 to 753993728 sectors.

Command: lvm pvmove --alloc anywhere /dev/sde2:92040-161804 /dev/sde2:0-92039
No data to move for data-nonraid.

Command: lvm pvresize --yes --setphysicalvolumesize 386044788736B /dev/sde2
WARNING: /dev/sde2: Pretending size is 753993728 not 1325512704 sectors.
Physical volume "/dev/sde2" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized
Resize file system on partition ‘/dev/sde2’ to 753993728 sectors: Success

Job: Set geometry of partition ‘/dev/sde2’: Start sector: 2237691904, length: 753993728
Set geometry of partition ‘/dev/sde2’: Start sector: 2237691904, length: 753993728: Success

Job: Check file system on partition ‘/dev/sde2’
Command: lvm pvck --verbose /dev/sde2
Found label on /dev/sde2, sector 1, type=LVM2 001
Found text metadata area: offset=4096, size=1044480
Check file system on partition ‘/dev/sde2’: Success
Shrink partition ‘/dev/sde2’ from 632.05 GiB to 359.53 GiB: Success

Resize van LV pubNR in VG data-nonraid lukte niet met de KDE partition manager. Niet aangekoppeld, en niet na ontkoppelen. De LV is 100G groot, de ext4 partitie ook, en de gebruikte ruimte is 5G. Zou dus een stuk vanaf kunnen.

Op de command line lukt het wel het ontkoppelde bestandssysteem te minimaliseren met de -M optie:

# # eerst zien wat de minimale grootte (in 'blocks', van 4k voor deze schijf) wordt met -P 
# resize2fs -P /dev/mapper/data--nonraid-pubNR
resize2fs 1.44.5 (15-Dec-2018)
Estimated minimum size of the filesystem: 1852946
# # daarna verkleinen 
# resize2fs -Mp /dev/mapper/data--nonraid-pubNR
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/data--nonraid-pubNR to 1852946 (4k) blocks.
Begin pass 2 (max = 735986)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 800)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 29)
Updating inode references XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/mapper/data--nonraid-pubNR is now 1852946 (4k) blocks long.

Daarna alsnog met lvresize het LV verkleind, en het bestandssysteem vergroot:

# lvresize -vrL8G /dev/data-nonraid/pubNR
Executing: /sbin/fsadm --verbose check /dev/data-nonraid/pubNR
fsadm: "ext4" filesystem found on "/dev/mapper/data--nonraid-pubNR".
fsadm: Filesystem has not been checked after the last mount, using fsck -f
fsadm: Executing fsck -f -p /dev/mapper/data--nonraid-pubNR
fsck from util-linux 2.33.1
pubNR: 645/466944 files (28.1% non-contiguous), 1375989/1852946 blocks
Executing: /sbin/fsadm --verbose resize /dev/data-nonraid/pubNR 8388608K
fsadm: "ext4" filesystem found on "/dev/mapper/data--nonraid-pubNR".
fsadm: Device "/dev/mapper/data--nonraid-pubNR" size is 107374182400 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/data--nonraid-pubNR"
fsadm: Resizing filesystem on device "/dev/mapper/data--nonraid-pubNR" to 8589934592 bytes (1852946 -> 2097152 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/data--nonraid-pubNR 2097152
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/data--nonraid-pubNR to 2097152 (4k) blocks.
The filesystem on /dev/mapper/data--nonraid-pubNR is now 2097152 (4k) blocks long.
Archiving volume group "data-nonraid" metadata (seqno 23). Reducing logical volume data-nonraid/pubNR to 8.00 GiB
Size of logical volume data-nonraid/pubNR changed from 100.00 GiB (25600 extents) to 8.00 GiB (2048 extents).
Loading table for data--nonraid-pubNR (253:16).
Suspending data--nonraid-pubNR (253:16) with device flush
Resuming data--nonraid-pubNR (253:16).
Creating volume group backup "/etc/lvm/backup/data-nonraid" (seqno 24).
Logical volume data-nonraid/pubNR successfully resized.
root@fractal:~# lvs /dev/data-nonraid/pubNR
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
pubNR data-nonraid -wi-a----- 8.00g
# mount /dev/data-nonraid/pubNR
# df -h /dev/data-nonraid/pubNR
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/data--nonraid-pubNR 7.8G 5.1G 2.4G 69% /home/wbk/pubNR

Aansluitend spiegelen:

# lvconvert -m1 /dev/data-nonraid/pubNR /dev/sdf2

De laatste LV in deze VG, homesNR, wil ik niet in de uiteindelijke data-VG hebben, maar in een home-VG. Dus nu eerst de spiegeling ongedaan maken maar LV’s behouden. Dan aan de ‘nieuwe’ kant op /dev/sdf de VG data-nonraid inactief maken en die opnemen in VG data. Als dat klaar is, opnieuw een VG data-nonraid aanmaken om homesNR te spiegelen en die later met een home-VG samen te voegen.

Slitsen lukt niet direct:

lvconvert -tvm0 /dev/mapper/data--nonraid-homesNR /dev/sde1 /dev/sde2
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Test mode: Skipping archiving of volume group.
Extracting 1 image from data-nonraid/homesNR.
Are you sure you want to convert raid1 LV data-nonraid/homesNR to type linear losing all resilience? [y/n]: y
Accepted input: [y]
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rmeta_0_extracted.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rimage_0_extracted.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rmeta_0.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rimage_0.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rmeta_0_extracted.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rimage_0_extracted.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rmeta_0.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rimage_0.
Internal error: Removing still active LV data-nonraid/homesNR_rmeta_0. 

Het enige wat ik kan bedenken om het probleem te verhelpen, is de volume groep inactief te maken:

# umount /home/wbk/movies
# umount /home/wbk/music
# umount /home/wbk/pubNR
# vgchange -an data-nonraid
0 logical volume(s) in volume group "data-nonraid" now active

Ok, dat is niet de oplossing:

# lvconvert -tvm0 /dev/mapper/data--nonraid-homesNR /dev/sde1 /dev/sde2
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
data-nonraid/homesNR must be active to perform this operation 

Veel gezocht, niets gevonden. De andere LV’s geven dezelfde fout, of ik nu de oude (sde) schijf opgeef om te verwijderen of de nieuwe (sdf).
Uiteindelijk de stoute schoenen aangetrokken, en niet als test gedaan. Meteen klaar, zonder error. Nu alleen nog bekijken wat er gebeurt is en uitzoeken wat het resultaat is:

lvconvert -vm0 /dev/mapper/data--nonraid-homesNR
Archiving volume group "data-nonraid" metadata (seqno 30). Extracting 1 image from data-nonraid/homesNR.
Are you sure you want to convert raid1 LV data-nonraid/homesNR to type linear losing all resilience? [y/n]: y
Accepted input: [y]
Loading table for data--nonraid-homesNR (253:33).
Loading table for data--nonraid-homesNR_rimage_0 (253:30).
Loading table for data--nonraid-homesNR_rimage_1 (253:32).
Suppressed data--nonraid-homesNR_rimage_1 (253:32) identical table reload.
Loading table for data--nonraid-homesNR_rmeta_0 (253:29).
Suppressed data--nonraid-homesNR_rmeta_0 (253:29) identical table reload.
Loading table for data--nonraid-homesNR_rmeta_0 (253:29).
Suppressed data--nonraid-homesNR_rmeta_0 (253:29) identical table reload.
Loading table for data--nonraid-homesNR_rmeta_1 (253:31).
Suppressed data--nonraid-homesNR_rmeta_1 (253:31) identical table reload.
Not monitoring data-nonraid/homesNR with libdevmapper-event-lvm2raid.so
Unmonitored LVM-qWbAa7jLmjPwVOFo54BePGqvqLAHDaf2luAq0nIxGTlOt0H0BznSULeI8m3K9eVJ for events
Suspending data--nonraid-homesNR (253:33) with device flush
Suspending data--nonraid-homesNR_rimage_1 (253:32) with device flush
Suspending data--nonraid-homesNR_rmeta_1 (253:31) with device flush
Suspending data--nonraid-homesNR_rimage_0 (253:30) with device flush
Suspending data--nonraid-homesNR_rmeta_0 (253:29) with device flush
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rmeta_1_extracted.
Loading table for data--nonraid-homesNR_rmeta_1 (253:31).
Suppressed data--nonraid-homesNR_rmeta_1 (253:31) identical table reload.
Renaming data--nonraid-homesNR_rmeta_1 (253:31) to data--nonraid-homesNR_rmeta_1_extracted
Resuming data--nonraid-homesNR_rmeta_1_extracted (253:31).
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rimage_1_extracted.
Loading table for data--nonraid-homesNR_rimage_1 (253:32).
Suppressed data--nonraid-homesNR_rimage_1 (253:32) identical table reload.
Renaming data--nonraid-homesNR_rimage_1 (253:32) to data--nonraid-homesNR_rimage_1_extracted
Resuming data--nonraid-homesNR_rimage_1_extracted (253:32).
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rmeta_0.
Loading table for data--nonraid-homesNR_rmeta_0 (253:29).
Suppressed data--nonraid-homesNR_rmeta_0 (253:29) identical table reload.
Resuming data--nonraid-homesNR_rmeta_0 (253:29).
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rimage_0.
Resuming data--nonraid-homesNR_rimage_0 (253:30).
Resuming data--nonraid-homesNR (253:33).
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rmeta_1_extracted.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rimage_1_extracted.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rmeta_0.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/homesNR_rimage_0.
Removing data--nonraid-homesNR_rmeta_1_extracted (253:31)
Removing data--nonraid-homesNR_rimage_1_extracted (253:32)
Removing data--nonraid-homesNR_rmeta_0 (253:29)
Removing data--nonraid-homesNR_rimage_0 (253:30)
Loading table for data--nonraid-homesNR (253:33).
Suppressed data--nonraid-homesNR (253:33) identical table reload.
Suspending data--nonraid-homesNR (253:33) with device flush
Loading table for data--nonraid-homesNR (253:33).
Suppressed data--nonraid-homesNR (253:33) identical table reload.
Resuming data--nonraid-homesNR (253:33).
Creating volume group backup "/etc/lvm/backup/data-nonraid" (seqno 32).
Creating volume group backup "/etc/lvm/backup/data-nonraid" (seqno 32).
Logical volume data-nonraid/homesNR successfully converted.

Er is gebeurd wat de bedoeling was, al is het net andersom van wat ik van plan was. De oude PV heeft nu de homesNR-LV, ongespiegeld.

Voor deze LV is dat in orde, maar de andere LV’s van data-nonraid wil ik graag op de nieuwe PV /dev/sdf2 houden, in plaats van op de partities op /dev/sde.

Omdat ik niet weet hoe ik de ‘hoofd’ LV van een gespiegeld volume kan wisselen, moet ik het op een andere manier doen. Met lvconvert –splitmirror wordt de spiegel in twee functionerende LV’s gesplitst. De afgesplitste LV krijgt een nieuwe naam, de oorspronkelijke naam blijft behouden aan de bron-LV die de origine van de gespiegelde LV was. Weer net verkeerdom, wel minder destructief dan met het verwijderen van de spiegel van zonet.

Test-modus geeft weer een fout; misschien zitten er controles in het proces die niet goed kunnen lopen, omdat een eerdere stap in het proces als test uitgevoerd is. Dus op een rijtje: lvconvert –splitmirror, lvrename (oorspronkelijk naar oud), lvrename (nieuw naar oorspronkelijk)

# lvconvert -v --splitmirrors 1 --name pubNR2 /dev/data-nonraid/pubNR
Are you sure you want to split raid1 LV data-nonraid/pubNR losing all resilience? [y/n]: y
Accepted input: [y]
Losing all resilience for logical volume data-nonraid/pubNR.
Extracting 1 image from data-nonraid/pubNR.
Loading table for data--nonraid-pubNR (253:28).
Loading table for data--nonraid-pubNR_rimage_0 (253:25).
Loading table for data--nonraid-pubNR_rimage_1 (253:27).
Suppressed data--nonraid-pubNR_rimage_1 (253:27) identical table reload.
Loading table for data--nonraid-pubNR_rmeta_0 (253:24).
Suppressed data--nonraid-pubNR_rmeta_0 (253:24) identical table reload.
Loading table for data--nonraid-pubNR_rmeta_0 (253:24).
Suppressed data--nonraid-pubNR_rmeta_0 (253:24) identical table reload.
Loading table for data--nonraid-pubNR_rmeta_1 (253:26).
Suppressed data--nonraid-pubNR_rmeta_1 (253:26) identical table reload.
Not monitoring data-nonraid/pubNR with libdevmapper-event-lvm2raid.so
Unmonitored LVM-qWbAa7jLmjPwVOFo54BePGqvqLAHDaf2yBJS9YTOPHFu8zXGKtjSTe7pSBCQnSSO for events
Suspending data--nonraid-pubNR (253:28) with device flush
Suspending data--nonraid-pubNR_rimage_1 (253:27) with device flush
Suspending data--nonraid-pubNR_rmeta_1 (253:26) with device flush
Suspending data--nonraid-pubNR_rimage_0 (253:25) with device flush
Suspending data--nonraid-pubNR_rmeta_0 (253:24) with device flush
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/pubNR2.
Loading table for data--nonraid-pubNR_rimage_1 (253:27).
Suppressed data--nonraid-pubNR_rimage_1 (253:27) identical table reload.
Renaming data--nonraid-pubNR_rimage_1 (253:27) to data--nonraid-pubNR2
Resuming data--nonraid-pubNR2 (253:27).
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/pubNR_rmeta_1_extracted.
Loading table for data--nonraid-pubNR_rmeta_1 (253:26).
Suppressed data--nonraid-pubNR_rmeta_1 (253:26) identical table reload.
Renaming data--nonraid-pubNR_rmeta_1 (253:26) to data--nonraid-pubNR_rmeta_1_extracted
Resuming data--nonraid-pubNR_rmeta_1_extracted (253:26).
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/pubNR_rmeta_0.
Loading table for data--nonraid-pubNR_rmeta_0 (253:24).
Suppressed data--nonraid-pubNR_rmeta_0 (253:24) identical table reload.
Resuming data--nonraid-pubNR_rmeta_0 (253:24).
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/pubNR_rimage_0.
Resuming data--nonraid-pubNR_rimage_0 (253:25).
Resuming data--nonraid-pubNR (253:28).
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/pubNR_rmeta_1_extracted.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/pubNR_rmeta_0.
activation/volume_list configuration setting not defined: Checking only host tags for data-nonraid/pubNR_rimage_0.
Removing data--nonraid-pubNR_rmeta_1_extracted (253:26)
Removing data--nonraid-pubNR_rmeta_0 (253:24)
Removing data--nonraid-pubNR_rimage_0 (253:25)
Creating volume group backup "/etc/lvm/backup/data-nonraid" (seqno 35).
root@fractal:/var/log# lvs -ao+devices |grep pub
pubNR data-nonraid -wi-a----- 8.00g /dev/sde2(0)
pubNR2 data-nonraid -wi-a----- 8.00g /dev/sdf2(323587)
# lvrename /dev/data-nonraid/pubNR pubNR_oud
Renamed "pubNR" to "pubNR_oud" in volume group "data-nonraid"
# lvrename /dev/data-nonraid/pubNR2 pubNR
Renamed "pubNR2" to "pubNR" in volume group "data-nonraid" 
# lvs -ao+devices |grep pub
pubNR data-nonraid -wi-a----- 8.00g /dev/sdf2(323587)
pubNR_oud data-nonraid -wi-a----- 8.00g /dev/sde2(0)

Aansluitend:

  • Voor de overige LV’s hetzelfde uitvoeren
  • de PV’s van volumegroepen data en data-nonraid splitsen naar nieuwe volumegroepen
  • de nieuwe volumegroepen samenvoegen
# lvconvert --splitmirrors 1 --name video2 /dev/data-nonraid/video
Are you sure you want to split raid1 LV data-nonraid/video losing all resilience? [y/n]: y
# lvconvert --splitmirrors 1 --name video2 /dev/data-nonraid/
homesNR muziekNR pubNR pubNR_oud video video2
# lvconvert --splitmirrors 1 --name muziekNR2 /dev/data-nonraid/muziekNR
Are you sure you want to split raid1 LV data-nonraid/muziekNR losing all resilience? [y/n]: y
# lvconvert --splitmirrors 1 --name muziekNR2 /dev/data-nonraid/
homesNR muziekNR muziekNR2 pubNR pubNR_oud video video2
# lvrename /dev/data-nonraid/video video_oud
Renamed "video" to "video_oud" in volume group "data-nonraid"
# lvrename /dev/data-nonraid/video2 video
Renamed "video2" to "video" in volume group "data-nonraid"
# lvrename /dev/data-nonraid/muziekNR muziekNR_oud
Renamed "muziekNR" to "muziekNR_oud" in volume group "data-nonraid"
# lvrename /dev/data-nonraid/muziek2 muziekNR
Existing logical volume "muziek2" not found in volume group "data-nonraid"
# lvrename /dev/data-nonraid/muziekNR2 muziekNR
Renamed "muziekNR2" to "muziekNR" in volume group "data-nonraid"
# lvs -ao+devices |grep nonraid
homesNR data-nonraid -wi-a----- 90.00g /dev/sde1(262144)
homesNR data-nonraid -wi-a----- 90.00g /dev/sde2(84109)
muziekNR data-nonraid -wi-a----- 150.00g /dev/sdf2(1)
muziekNR_oud data-nonraid -wi-a----- 150.00g /dev/sde2(25600)
pubNR data-nonraid -wi-a----- 8.00g /dev/sdf2(323587)
pubNR_oud data-nonraid -wi-a----- 8.00g /dev/sde2(0)
video data-nonraid -wi-a----- <1.09t /dev/sdf2(38402)
video_oud data-nonraid -wi-a----- <1.09t /dev/sde1(0)
video_oud data-nonraid -wi-a----- <1.09t /dev/sde1(277504)
video_oud data-nonraid -wi-a----- <1.09t /dev/sde2(64000) 

So far, so good. Nu voor VG ‘data’ hetzelfde riedeltje:

# lvs -ao+devices |grep aor
fotos data rwi-aor--- 2.68t 100.00 fotos_rimage_0(0),fotos_rimage_1(0)
[fotos_rimage_0] data iwi-aor--- 2.68t /dev/md3(0)
[fotos_rimage_0] data iwi-aor--- 2.68t /dev/md3(214575)
[fotos_rimage_0] data iwi-aor--- 2.68t /dev/md4(119208)
[fotos_rimage_0] data iwi-aor--- 2.68t /dev/md3(190735)
[fotos_rimage_0] data iwi-aor--- 2.68t /dev/md4(0)
[fotos_rimage_0] data iwi-aor--- 2.68t /dev/md4(36229)
[fotos_rimage_0] data iwi-aor--- 2.68t /dev/md4(10629)
[fotos_rimage_0] data iwi-aor--- 2.68t /dev/md2(0)
[fotos_rimage_1] data iwi-aor--- 2.68t /dev/sdf1(1)
[fotos_rmeta_0] data ewi-aor--- 4.00m /dev/md3(213295)
[fotos_rmeta_1] data ewi-aor--- 4.00m /dev/sdf1(0)
geluid data rwi-aor--- 16.56g 100.00 geluid_rimage_0(0),geluid_rimage_1(0)
[geluid_rimage_0] data iwi-aor--- 16.56g /dev/md3(202655)
[geluid_rimage_1] data iwi-aor--- 16.56g /dev/sdf1(703333)
[geluid_rmeta_0] data ewi-aor--- 4.00m /dev/md3(213296)
[geluid_rmeta_1] data ewi-aor--- 4.00m /dev/sdf1(703332)
# lvconvert --splitmirrors 1 --name fotos2 /dev/data/fotos
Are you sure you want to split raid1 LV data/fotos losing all resilience? [y/n]: y
root@fractal:/var/log# lvconvert --splitmirrors 1 --name geluid2 /dev/data/geluid
Are you sure you want to split raid1 LV data/geluid losing all resilience? [y/n]: y
root@fractal:/var/log# lvrename /dev/data/geluid geluid_oud
Renamed "geluid" to "geluid_oud" in volume group "data"
root@fractal:/var/log# lvrename /dev/data/geluid2 geluid
Renamed "geluid2" to "geluid" in volume group "data"
root@fractal:/var/log# lvrename /dev/data/fotos fotos_oud
Renamed "fotos" to "fotos_oud" in volume group "data"
root@fractal:/var/log# lvrename /dev/data/fotos fotos
/dev/data/fotos2 /dev/data/fotos_oud
root@fractal:/var/log# lvrename /dev/data/fotos2 fotos
Renamed "fotos2" to "fotos" in volume group "data"

Dat ziet er best goed uit. Op sdf staan nu twee volumegroepen met de logische volumes die ik daar wil hebben. Wat er nog moet gebeuren:

  • hernoem VG ‘data’ naar ‘data_oud’ met vgrename
  • splits de sdf1-LV’s af van VG data_oud naar nieuwe VG ‘data’
  • hernoem VG ‘data-nonraid’ naar data-nonraid_oud met vgrename
  • splits de sdf2-LV’s af van data-nonraid_oud en stop ze in bestaande VG ‘data’
# vgrename data
data data-nonraid
# vgrename data data_oud
Volume group "data" successfully renamed to "data_oud"
root@fractal:/var/log# vgrename data data_oud
data-nonraid data_oud
# vgrename data-nonraid data-nonraid_oud
Volume group "data-nonraid" successfully renamed to "data-nonraid_oud"
# vgsplit -tv data_oud data /dev/sdf1
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Checking for new volume group "data"
Checking for volume group "data_oud"
Test mode: Skipping archiving of volume group.
Logical volume data_oud/fotos must be inactive.
root@fractal:/var/log# vgchange -an data_oud
Logical volume data_oud/fotos_oud contains a filesystem in use.
Can't deactivate volume group "data_oud" with 2 open logical volume(s)
# umount /home/wbk/sounds
# umount /home/wbk/photos
# vgchange -an data_oud
0 logical volume(s) in volume group "data_oud" now active
# vgsplit -tv data_oud data /dev/sdf1
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Checking for new volume group "data"
Checking for volume group "data_oud"
Test mode: Skipping archiving of volume group.
Writing out updated volume groups
Test mode: Skipping archiving of volume group.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
New volume group "data" successfully split from "data_oud"
# vgsplit -v data_oud data /dev/sdf1
Checking for new volume group "data"
Checking for volume group "data_oud"
Archiving volume group "data_oud" metadata (seqno 35).
Writing out updated volume groups
Archiving volume group "data" metadata (seqno 0).
Creating volume group backup "/etc/lvm/backup/data" (seqno 1).
Creating volume group backup "/etc/lvm/backup/data_oud" (seqno 36).
Creating volume group backup "/etc/lvm/backup/data" (seqno 2).
New volume group "data" successfully split from "data_oud"
# mount |grep non
# vgchange -an data-nonraid_oud
0 logical volume(s) in volume group "data-nonraid_oud" now active
# vgsplit -v data-nonraid_oud data /dev/sdf2
Checking for new volume group "data"
Checking for volume group "data-nonraid_oud"
Archiving volume group "data-nonraid_oud" metadata (seqno 46).
Writing out updated volume groups
Archiving volume group "data" metadata (seqno 2).
Creating volume group backup "/etc/lvm/backup/data" (seqno 3).
Creating volume group backup "/etc/lvm/backup/data-nonraid_oud" (seqno 47).
Creating volume group backup "/etc/lvm/backup/data" (seqno 4).
Existing volume group "data" successfully split from "data-nonraid_oud"
# vgs
VG #PV #LV #SN Attr VSize VFree
boot 1 1 0 wz--n- 1.39g 1.21g
data 2 5 0 wz--n- <3.97t <28.27g
data-nonraid_oud 2 4 0 wz--n- 1.42t 92.98g
data_oud 3 2 0 wz--n- <2.73t 30.00g
homes 1 1 0 wz--n- <839.84g 744.71g
mailtemp 1 1 0 wz--n- 12.77g 0
system 1 6 0 wz--n- 83.81g 0

Alleen homesNR moet nog uit VG data-nonraid_oud naar de nieuwe schijf.

Alleen /dev/sde3 van de 3TB-schijf heeft nu nog data die niet op de nieuwe schijf staat. Er staat maar een VG (mailtemp) op, met een enkele LV (mail). De VG doet z’n naam eer aan, want die gaat nu weer tijdelijk naar /dev/sdf3 met pvmove, voordat ik de andere 6TB schijf inricht. Ondertussen is die LV al weer een tijd de mailstore van de mailserver op deze machine, ‘niets zo permanent als een tijdelijke oplossing’.

Er is nog 1,5TiB vrij van de nieuwe schijf. Voor de verschillende home-partities is nog een kleine 250TiB nodig; een deel daarvan zijn ROMs en ISO’s die eigenlijk in de data-VG geschoven moeten worden. Stappen daarvoor:

  • LV homesNR hernoemen naar rom met lvrename
  • Nieuwe partitie /dev/sdf3 op de nieuwe schijf met fdisk
  • Partitie als PV kenmerken met pvcreate
  • Partitie toekennen aan data-nonraid_oud met vgextend
  • LV rom spiegelen van /dev/sde[12] naar /dev/sdf3 met lvconvert -m1
  • Spiegeling splitsen met lvconvert –splitmirrors 1 –name rom2 /dev/data-nonraid_oud/rom
fdisk /dev/sdf
pvcreate /dev/sdf3
vgextend data-nonraid_oud /dev/sdf3
lvconvert -m 1 /dev/data-nonraid_oud/rom /dev/sdf3
lvrename /dev/data-nonraid_oud/rom rom2
lvconvert --splitmirrors 1 --name rom /dev/data-nonraid_oud/rom
umount /home/nonraid
vgchange -an data-nonraid_oud
vgsplit -tv data /dev/sdf3
root@fractal:/var/log# vgsplit data-nonraid_oud data /dev/sdf3
Existing volume group "data" successfully split from "data-nonraid_oud"
vgchange -ay data
vi /etc/fstab
mount -a
df -ht ext4
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/system-root 14G 1.2G 12G 9% /
/dev/mapper/system-usr 14G 14G 0 100% /usr
/dev/mapper/system-homesltd 28G 26G 108M 100% /home
/dev/mapper/boot-boot 167M 56M 98M 37% /boot
/dev/mapper/system-var 18G 15G 2.4G 86% /var
/dev/mapper/homes-wbk 94G 88G 940M 99% /home/wbk
/dev/mapper/system-varlog 6.3G 4.6G 1.5G 77% /var/log
/dev/mapper/system-varcache 2.9G 1.2G 1.6G 44% /var/cache
/dev/mapper/mailtemp-mail 13G 12G 310M 98% /var/vmail
/dev/mapper/data-fotos 2.7T 2.6T 2.8G 100% /home/wbk/photos
/dev/mapper/data-geluid 17G 11G 4.4G 72% /home/wbk/sounds
/dev/mapper/data-video 1.1T 1.1T 18G 99% /home/wbk/movies
/dev/mapper/data-rom 89G 84G 968M 99% /home/nonraid

Voor de home-directories is het lastig dat die van wbk gemount is terwijl ik bezig ben. Daarvoor dus uitloggen en su via een andere gebruiker.

Nog lastiger is het met de homesltd-LV. Die is onderdeel van de system-VG, waarvan alle extends gebruikt zijn. Er kan pas gespiegeld worden als er minimaal een PE beschikbaar is in de bron-VG.

Na een hoop puzzelen, lijkt de eenvoudigste manier om de LV voor de /var/cache-partitie weg te gooien.

——— // lange break offline, in rescue mode om system VG met root te migreren // ——–

–> hier plakken: aantekeningen uit rescue modus: migratie, bootproblemen na ontbrekende GPT BIOS boot-partitie voor GRUB

——- // hier weer online, met sechts 1 hdd in bedrijf, de 6T PMR-schijf // ———

SSD van 480G ingeplugd, met fdisk /dev/sdc partities toegevoegd:

  • 8G swap
  • 30G voor VG system
  • 20G voor VG homes
  • 50G voor VG data
root@fractal:~# fdisk -l /dev/sdc
Disk /dev/sdc: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk model: CT500MX500SSD1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: B480C1C9-E7CB-D04D-BDCD-C797ED5F0512
Device Start End Sectors Size Type
/dev/sdc1 2048 16779263 16777216 8G Linux swap
/dev/sdc2 16779264 79693823 62914560 30G Linux LVM
/dev/sdc3 79693824 121636863 41943040 20G Linux LVM
/dev/sdc4 121636864 226494463 104857600 50G Linux LVM

Swap bruikbaar maken met makeswap /dev/sdc1 && swapon /dev/sdc1, ook aan /etc/fsctab toevoegen.

blkid /dev/sdc1
/dev/sdc1: UUID="f6eb076b-f587-4bf7-b307-9b75260a8bab" TYPE="swap" PARTUUID="d2a5a9b8-903f-4141-96d7-f931e93be283"


Partities beschikbaar maken voor LVM met pvcreate en toevoegen met vgextend:

root@fractal:~# pvcreate /dev/sdc2
Physical volume "/dev/sdc2" successfully created.
root@fractal:~# pvcreate /dev/sdc3
Physical volume "/dev/sdc3" successfully created.
root@fractal:~# pvcreate /dev/sdc4
Physical volume "/dev/sdc4" successfully created.
root@fractal:~# vgextend system /dev/sdc2
Volume group "system" successfully extended
root@fractal:~# vgextend homes /dev/sdc3
Volume group "homes" successfully extended
root@fractal:~# vgextend data /dev/sdc4
Volume group "data" successfully extended

Inrichten als cache volgens man 7 lvmcache. Om twee gescheiden apparaten in te zetten voor cache en cache-metadata (via een cachepool) is het makkelijker om ze tegelijkertijd beschikbaar te hebben. Daarvoor moet ik eerst wat schujven in de toewijzing van de SATA-poorten, toch liever off-line dus eerst de boel weer uitschakelen.

Opslagapparaten zitten er nu min of meer netjes in. De drie 2TB-schijven zitten er ‘draadloos’ in, de twee vrijgekomen SATA-poorten zijn vooralsnog op de DVD-schijvers aangesloten (er staan nog een paar spindels blanco DVD’s op foto’s te wachten, wie weet…).
De overige vier apparaten :

root@fractal:~# fdisk -l|grep 'Disk /dev/sd'
Disk /dev/sda: 967.5 MiB, 1014497280 bytes, 1981440 sectors
Disk /dev/sdb: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Disk /dev/sdc: 101.3 GiB, 108711411200 bytes, 212326975 sectors
Disk /dev/sdd: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk /dev/sde: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors

Nu op de kleine SSD de partities voor LVM metadatacache aanleggen. Met een factor duizend kleiner dan het datacache gaat het over tientallen MB’s, niet echt de moeite. De LV’s voor het metadatacache moeten in dezelfde VG zitten als het datacache en de data zelf, maar naast de LV’s voor het metadatacache kunnen er natuurlijk meer LV’s op gezet worden, bijvoorbeeld voor databases (in data?) of configuratie- en thumnaildirectories in de home VG. Het idee van een bootpartitie op elke schijf heb ik, ondanks het lage opslagruimtegebruik, laten varen. Het komt maar zo zelden voor dat onvoorzien alle schijven uit het systeem zijn behalve ‘die ene’ schijf, en dan heeft een bootpartitie in z’n eentje ook niet veel zin meer. Bovendien heb ik de USB-stick met Debian-installer in de interne USB-poort geprikt. In geval van nood is daarop terug te vallen (zoals vandaag dus een paar keer aan de orde was).
Omdat cachetoewijzing op LV-niveau gedaan wordt, hoe ik de indeling van de kleine SSD bij nader inzien helemaal anders.

  • 2GB swap
  • 30G voor VG system
    • enkele MB’s aan metadatacache voor partities niet op SSD
    • 2GB voor root
    • 20GB voor usr
    • overige ruimte voor toekomstig gebrui
  • 20G voor VG homes
    • enkele MB’s aan metadatacache
    • ruimte voor thumbnails in homedirs
    • ruimte voor vaak geraakte bestanden in homedirs (browsercache, desktopcachebestanden)
    • ruimte voor databases van bijvoorbeeld Digikam en Calibre
  • 50G voor VG data
    • enkele MB’s aan metadatacache
    • ruimte voor databasebestanden van generieke processen
  • De overige ruimte ongepartitioneerd, als vrije ruimte voor de SSD

Eerst secure erase. Volgens horen zeggen, worden daarmee alle cellen leeggemaakt, en kan er voorlopig op volle snelheid geschreven worden.

// schrijf hier het stukje over ATA secure erase, verwijs naar Arch-wiki

# hdparm -I /dev/sdc|grep frozen
# dhparm --user-master u --security-set-pass 7yde7yk /dev/sdc
# hdparm -I /dev/sdc
# hdparm --user-master u --security-erase wankel78 /dev/sdc
# hdparm -I /dev/sdc

Cache inrichten

De volumegroepen, bestaande uit PV’s op de SMR-schijf zijn nu uitgebreid met PV’s uit telkens twee SSD’s. Nu kan ik datacache en metadatacache daarop inrichten. Voor de LV’s op de system-VG maak ik hier een notitie, de rest gaat op dezelfde manier. De hints in man 7 lvmcache zijn goed leesbaar, ik volg de stappen 1-op-1.

Voor de system-VG heb ik voor ogen:

  • raid 1 mirror voor root en usr over de HDD en de kleine SSD
  • schrijfcache van 8G voor die mirror
  • partities /var en /var/log op de HDD met 20G LVM-r/w-cache op de grote SSD, en 50M metadatacache op de kleine SSD.
# # creeer het datacache op de grote SSD
#lvcreate -vn sys_cache -L20G system /dev/sdd2
Archiving volume group "system" metadata (seqno 4). Creating logical volume sys_cache Creating volume group backup "/etc/lvm/backup/system" (seqno 5). Activating logical volume system/sys_cache. activation/volume_list configuration setting not defined: Checking only host tags for system/sys_cache. Creating system-sys_cache Loading table for system-sys_cache (254:13). Resuming system-sys_cache (254:13). Wiping known signatures on logical volume "system/sys_cache" Initializing 4.00 KiB of logical volume "system/sys_cache" with value 0.
Logical volume "sys_cache" created.
# # schakel het cache voor de LV's var en varlog in
# lvconvert --type cache --cachepool sys_cache system/var
WARNING: Converting system/sys_cache to cache pool's data volume with metadata wiping.
THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert system/sys_cache? [y/n]: y
Converted system/sys_cache to cache pool.
Logical volume system/var is now cached.
# # LV var laten cachen:
# lvconvert --type cache --cachepool sys_cache system/var
WARNING: Converting system/sys_cache to cache pool's data volume with metadata wiping.
THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert system/sys_cache? [y/n]: y
Converted system/sys_cache to cache pool.
Logical volume system/var is now cached.
# # LV varlog laten cachen
# lvconvert --type cache --cachepool sys_cache system/varlog
Cache pool sys_cache is already in use.
# # Dan maar weer ongedaan maken:
# lvconvert --splitcache system/sys_cache
Logical volume system/var is not cached and cache pool system/sys_cache is unused.
# lvconvert --splitcache system/sys_cache
Cannot find cache LV from system/sys_cache.
# lvremove /dev/system/sys_cache
Logical volume "sys_cache" successfully removed

Dat is niet wat ik had verwacht: een cachepool in een VG kan maar door een LV gebruikt worden, niet gedeeld. Omdat de bestanden op de LV’s in de system VG nog geen 50G in beslag nemen, gooi ik het helemaal over een andere boeg: alles in lvmraid 1.

De opdrachten voor het initieren van de RAID-LV’s wijken iets af van die hierboven, omdat het nu niet ter synchronisatie naar de ‘enige andere’ schijf in de VG is, maar naar ‘een van de meerdere PVs in de VG’, waarbij ik voor elke VG een specifieke SSD in gedachten heb. Daarnaast wil ik dat de HDD zo min mogelijk direct gebruikt wordt, om niet als een rem te werken. Dus: vooral lezen van de SSD’s, en bij schrijven niet wachten op de HDD. Voor de HDD betekend dat: ‘writemostly’, ‘raid_write_behind’.

# lvconvert -v --type raid1 -m1 /dev/system/root /dev/sdc2
Are you sure you want to convert linear LV system/root to raid1 with 2 images enhancing resilience? [y/n]: y
Accepted input: [y]
Archiving volume group "system" metadata (seqno 14).
Creating logical volume root_rmeta_0
Creating logical volume root_rmeta_1
Creating logical volume root_rimage_0
activation/volume_list configuration setting not defined: Checking only host tags for system/root_rmeta_0.
Creating system-root_rmeta_0
Loading table for system-root_rmeta_0 (254:13).
Resuming system-root_rmeta_0 (254:13).
activation/volume_list configuration setting not defined: Checking only host tags for system/root_rmeta_1.
Creating system-root_rmeta_1
Loading table for system-root_rmeta_1 (254:14).
Resuming system-root_rmeta_1 (254:14).
Wiping metadata area system/root_rmeta_0.
Wiping known signatures on logical volume "system/root_rmeta_0"
Initializing 512 B of logical volume "system/root_rmeta_0" with value 0.
Wiping metadata area system/root_rmeta_1.
Wiping known signatures on logical volume "system/root_rmeta_1"
Initializing 512 B of logical volume "system/root_rmeta_1" with value 0.
Removing system-root_rmeta_0 (254:13)
Removing system-root_rmeta_1 (254:14)
Creating logical volume root_rimage_0
Creating system-root_rmeta_0
Loading table for system-root_rmeta_0 (254:13).
Resuming system-root_rmeta_0 (254:13).
Creating system-root_rimage_0
Loading table for system-root_rimage_0 (254:14).
Resuming system-root_rimage_0 (254:14).
Creating system-root_rmeta_1
Loading table for system-root_rmeta_1 (254:15).
Resuming system-root_rmeta_1 (254:15).
Creating system-root_rimage_1
Loading table for system-root_rimage_1 (254:16).
Resuming system-root_rimage_1 (254:16).
Loading table for system-root (254:0).
Suspending system-root (254:0) with device flush
Loading table for system-root_rmeta_0 (254:13).
Suppressed system-root_rmeta_0 (254:13) identical table reload.
Loading table for system-root_rimage_0 (254:14).
Suppressed system-root_rimage_0 (254:14) identical table reload.
Loading table for system-root_rmeta_1 (254:15).
Suppressed system-root_rmeta_1 (254:15) identical table reload.
Loading table for system-root_rimage_1 (254:16).
Suppressed system-root_rimage_1 (254:16) identical table reload.
Resuming system-root (254:0).
Monitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKZZWgBeA6ZJIDMIpaqAnjsS6M7HF5BjyC for events
Creating volume group backup "/etc/lvm/backup/system" (seqno 16).
Creating volume group backup "/etc/lvm/backup/system" (seqno 17).
Logical volume system/root successfully converted.
# # aansluitend kijken hoever de sync is
# lvs /dev/system/root
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root system rwi-aor--- 5.00g 21.46

Daarna de sync voor var, usr en varlog aanzetten:

# lvconvert --type raid1 -m1 /dev/system/var /dev/sdc2
Are you sure you want to convert linear LV system/var to raid1 with 2 images enhancing resilience? [y/n]: y
Logical volume system/var successfully converted.
# lvconvert --type raid1 -m1 /dev/system/usr /dev/sdd2
Are you sure you want to convert linear LV system/usr to raid1 with 2 images enhancing resilience? [y/n]: y
Logical volume system/usr successfully converted. 
root@fractal:~# iostat -hd 3 /dev/sd[cd]2 /dev/sda6
Linux 4.9.0-0.bpo.11-amd64 (fractal) 08/11/20 x86_64 (4 CPU)
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
182.67 89.1M 8.5k 267.4M 25.5k sda6
99.33 0.0k 48.1M 0.0k 144.2M sdc2
83.67 0.0k 41.3M 0.0k 123.9M sdd2
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
161.67 78.6M 13.3k 235.7M 40.0k sda6
97.67 0.0k 47.4M 0.0k 142.2M sdc2
64.33 0.0k 31.0M 0.0k 92.9M sdd2
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
199.34 100.4M 0.5k 302.1M 1.5k sda6
99.67 0.0k 49.8M 0.0k 149.9M sdc2
100.00 0.0k 50.6M 0.0k 152.2M sdd2
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
224.00 93.5M 13.3k 280.6M 40.0k sda6
33.33 0.0k 14.9M 0.0k 44.7M sdc2
191.00 0.0k 78.9M 0.0k 236.6M sdd2
# lvconvert --type raid1 -m1 /dev/system/varlog /dev/sdd2
Are you sure you want to convert linear LV system/varlog to raid1 with 2 images enhancing resilience? [y/n]: y
Logical volume system/varlog successfully converted.
root@fractal:~# iostat -hd 3 /dev/sd[cd]2 /dev/sda6
Linux 4.9.0-0.bpo.11-amd64 (fractal) 08/11/20 x86_64 (4 CPU)
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
205.00 85.0M 21.0k 255.1M 63.0k sda6
2.33 0.0k 12.0k 0.0k 36.0k sdc2
204.00 0.0k 85.3M 0.0k 255.8M sdd2
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
269.33 100.0M 12.5k 300.1M 37.5k sda6
1.67 0.0k 11.5k 0.0k 34.5k sdc2
268.00 0.0k 100.0M 0.0k 300.1M sdd2
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
251.00 95.6M 7.0k 286.9M 21.0k sda6
2.33 0.0k 5.7k 0.0k 17.0k sdc2
250.33 0.0k 95.6M 0.0k 286.9M sdd2
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
315.33 100.4M 12.5k 301.3M 37.5k sda6
2.67 0.0k 12.5k 0.0k 37.5k sdc2
314.00 0.0k 100.4M 0.0k 301.3M sdd2

RAID-conversie is nu klaar voor alle system-LV’s, nu afstemmen om vooral de SSD’s aan te spreken om zo min mogelijk last van de HDD te hebben.

Optie ‘writemostly’: de genoemde PV wordt ontzien bij leesacties, niet bij schrijven. Daardoor krijgt die drive minder I/O-acties voor z’n kiezen. Met het instellen van ‘writemostly’, komt de optie ‘writebehind’ beschikbaar.

Optie ‘writebehind’: voor een PV waarop ‘writemostly’ actief is, kan ingesteld worden hoeveel schrijfacties de PV achter mag lopen.

Stel dat de SSD vijf keer zo snel is als de HDD, en ze respectievelijk 50 en 5 schrijfacties per seconde kunnen doen. In het reguliere geval zijn de schrijfacties synchroon (write-through): een schrijfactie wordt pas als gereed gemarkeerd, als het opslagmedium ‘OK’ teruggeeft.
Zolang er op het systeem minder dan 5 schijfacties per seconde plaatsvinden, is er geen probleem. Als dat aantal stijgt, is er wel een probleem: doordat de schrijfacties synchroon gebeuren, moet het systeem wachten op iedere schrijfactie die boven die 5 per seconde uitgaat. Als er vanaf de CPU in een seconde 40 schrijfacties komen, betekent het dat die CPU vervolgens 7 seconden extra moet wachten voordat er een OK terug is op alle schrijfacties.
In dat voorbeeld is er wat betreft de SSD geen probleem: die presteert op 80%, en kan de schrijfacties makkelijk aan. Hier komt de ‘writebehind’ optie om de hoek kijken: door die, in het voorbeeld, op 45 te zetten, kan de CPU de SSD in de hoogste versnelling laten werken, voor een seconde in ieder geval.
Zodra het aantal achtergebleven schrijfacties (45 in dit geval) overschreden wordt, wisselt de hele LV naar synchroon schrijven. Als er dus 4 seconden lang, 50 schrijfacties per seconden gedaan zouden worden, zou na de eerste seconde de LV omslaan naar synchroon. De overige 150 schrijfacties geven pas OK nadat zowel de SSD als de HDD klaar zijn. De SSD kan gelijke tred met de CPU houden, maar de HDD heeft veel meer tijd nodig. Het hele systeem wordt voor ruim een halve minuut opgehouden, totdat de HDD alle 200 acties verwerkt heeft.

Het inschakelen van ‘writemostly’ -v geeft veel meer output dan ik op basis van -t verwacht had, maar is zo gedaan:

# lvchange -tv --writemostly /dev/sda6 /dev/system/*
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Test mode: Skipping archiving of volume group.
Logical volume system/root changed.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
Logical volume system/usr changed.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
Logical volume system/var changed.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
Logical volume system/varlog changed.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
Test mode: Skipping backup of volume group.
# lvchange -v --writemostly /dev/sda6 /dev/system/*
Archiving volume group "system" metadata (seqno 26).
Logical volume system/root changed.
Loading table for system-root_rimage_1 (254:16).
Suppressed system-root_rimage_1 (254:16) identical table reload.
Loading table for system-root_rmeta_1 (254:15).
Suppressed system-root_rmeta_1 (254:15) identical table reload.
Loading table for system-root_rimage_0 (254:14).
Suppressed system-root_rimage_0 (254:14) identical table reload.
Loading table for system-root_rmeta_0 (254:13).
Suppressed system-root_rmeta_0 (254:13) identical table reload.
Loading table for system-root (254:0).
Not monitoring system/root with libdevmapper-event-lvm2raid.so
Unmonitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKZZWgBeA6ZJIDMIpaqAnjsS6M7HF5BjyC for events
Suspending system-root (254:0) with device flush
Suspending system-root_rimage_1 (254:16) with device flush
Suspending system-root_rmeta_1 (254:15) with device flush
Suspending system-root_rimage_0 (254:14) with device flush
Suspending system-root_rmeta_0 (254:13) with device flush
Loading table for system-root_rimage_1 (254:16).
Suppressed system-root_rimage_1 (254:16) identical table reload.
Loading table for system-root_rmeta_1 (254:15).
Suppressed system-root_rmeta_1 (254:15) identical table reload.
Loading table for system-root_rimage_0 (254:14).
Suppressed system-root_rimage_0 (254:14) identical table reload.
Loading table for system-root_rmeta_0 (254:13).
Suppressed system-root_rmeta_0 (254:13) identical table reload.
Resuming system-root_rimage_1 (254:16).
Resuming system-root_rmeta_1 (254:15).
Resuming system-root_rimage_0 (254:14).
Resuming system-root_rmeta_0 (254:13).
Resuming system-root (254:0).
Monitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKZZWgBeA6ZJIDMIpaqAnjsS6M7HF5BjyC for events
Creating volume group backup "/etc/lvm/backup/system" (seqno 27).
Creating volume group backup "/etc/lvm/backup/system" (seqno 27).
Creating volume group backup "/etc/lvm/backup/system" (seqno 27).
Logical volume system/usr changed.
Loading table for system-usr_rimage_1 (254:24).
Suppressed system-usr_rimage_1 (254:24) identical table reload.
Loading table for system-usr_rmeta_1 (254:23).
Suppressed system-usr_rmeta_1 (254:23) identical table reload.
Loading table for system-usr_rimage_0 (254:22).
Suppressed system-usr_rimage_0 (254:22) identical table reload.
Loading table for system-usr_rmeta_0 (254:21).
Suppressed system-usr_rmeta_0 (254:21) identical table reload.
Loading table for system-usr (254:1).
Not monitoring system/usr with libdevmapper-event-lvm2raid.so
Unmonitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKPYY1qvCEtimgOktNFgWC7GHCZMCD1kne for events
Suspending system-usr (254:1) with device flush
Suspending system-usr_rimage_1 (254:24) with device flush
Suspending system-usr_rmeta_1 (254:23) with device flush
Suspending system-usr_rimage_0 (254:22) with device flush
Suspending system-usr_rmeta_0 (254:21) with device flush
Loading table for system-usr_rimage_1 (254:24).
Suppressed system-usr_rimage_1 (254:24) identical table reload.
Loading table for system-usr_rmeta_1 (254:23).
Suppressed system-usr_rmeta_1 (254:23) identical table reload.
Loading table for system-usr_rimage_0 (254:22).
Suppressed system-usr_rimage_0 (254:22) identical table reload.
Loading table for system-usr_rmeta_0 (254:21).
Suppressed system-usr_rmeta_0 (254:21) identical table reload.
Resuming system-usr_rimage_1 (254:24).
Resuming system-usr_rmeta_1 (254:23).
Resuming system-usr_rimage_0 (254:22).
Resuming system-usr_rmeta_0 (254:21).
Resuming system-usr (254:1).
Monitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKPYY1qvCEtimgOktNFgWC7GHCZMCD1kne for events
Creating volume group backup "/etc/lvm/backup/system" (seqno 28).
Creating volume group backup "/etc/lvm/backup/system" (seqno 28).
Creating volume group backup "/etc/lvm/backup/system" (seqno 28).
Logical volume system/var changed.
Loading table for system-var_rimage_1 (254:20).
Suppressed system-var_rimage_1 (254:20) identical table reload.
Loading table for system-var_rmeta_1 (254:19).
Suppressed system-var_rmeta_1 (254:19) identical table reload.
Loading table for system-var_rimage_0 (254:18).
Suppressed system-var_rimage_0 (254:18) identical table reload.
Loading table for system-var_rmeta_0 (254:17).
Suppressed system-var_rmeta_0 (254:17) identical table reload.
Loading table for system-var (254:3).
Not monitoring system/var with libdevmapper-event-lvm2raid.so
Unmonitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKmSXVL0bFAndQH51ED0RIy91IgYM1DaRD for events
Suspending system-var (254:3) with device flush
Suspending system-var_rimage_1 (254:20) with device flush
Suspending system-var_rmeta_1 (254:19) with device flush
Suspending system-var_rimage_0 (254:18) with device flush
Suspending system-var_rmeta_0 (254:17) with device flush
Loading table for system-var_rimage_1 (254:20).
Suppressed system-var_rimage_1 (254:20) identical table reload.
Loading table for system-var_rmeta_1 (254:19).
Suppressed system-var_rmeta_1 (254:19) identical table reload.
Loading table for system-var_rimage_0 (254:18).
Suppressed system-var_rimage_0 (254:18) identical table reload.
Loading table for system-var_rmeta_0 (254:17).
Suppressed system-var_rmeta_0 (254:17) identical table reload.
Resuming system-var_rimage_1 (254:20).
Resuming system-var_rmeta_1 (254:19).
Resuming system-var_rimage_0 (254:18).
Resuming system-var_rmeta_0 (254:17).
Resuming system-var (254:3).
Monitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKmSXVL0bFAndQH51ED0RIy91IgYM1DaRD for events
Creating volume group backup "/etc/lvm/backup/system" (seqno 29).
Creating volume group backup "/etc/lvm/backup/system" (seqno 29).
Creating volume group backup "/etc/lvm/backup/system" (seqno 29).
Logical volume system/varlog changed.
Loading table for system-varlog_rimage_1 (254:28).
Suppressed system-varlog_rimage_1 (254:28) identical table reload.
Loading table for system-varlog_rmeta_1 (254:27).
Suppressed system-varlog_rmeta_1 (254:27) identical table reload.
Loading table for system-varlog_rimage_0 (254:26).
Suppressed system-varlog_rimage_0 (254:26) identical table reload.
Loading table for system-varlog_rmeta_0 (254:25).
Suppressed system-varlog_rmeta_0 (254:25) identical table reload.
Loading table for system-varlog (254:4).
Not monitoring system/varlog with libdevmapper-event-lvm2raid.so
Unmonitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGK3TNMGJWyr6sO9HNm13KjBhRF1m4eqOcc for events
Suspending system-varlog (254:4) with device flush
Suspending system-varlog_rimage_1 (254:28) with device flush
Suspending system-varlog_rmeta_1 (254:27) with device flush
Suspending system-varlog_rimage_0 (254:26) with device flush
Suspending system-varlog_rmeta_0 (254:25) with device flush
Loading table for system-varlog_rimage_1 (254:28).
Suppressed system-varlog_rimage_1 (254:28) identical table reload.
Loading table for system-varlog_rmeta_1 (254:27).
Suppressed system-varlog_rmeta_1 (254:27) identical table reload.
Loading table for system-varlog_rimage_0 (254:26).
Suppressed system-varlog_rimage_0 (254:26) identical table reload.
Loading table for system-varlog_rmeta_0 (254:25).
Suppressed system-varlog_rmeta_0 (254:25) identical table reload.
Resuming system-varlog_rimage_1 (254:28).
Resuming system-varlog_rmeta_1 (254:27).
Resuming system-varlog_rimage_0 (254:26).
Resuming system-varlog_rmeta_0 (254:25).
Resuming system-varlog (254:4).
Monitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGK3TNMGJWyr6sO9HNm13KjBhRF1m4eqOcc for events
Creating volume group backup "/etc/lvm/backup/system" (seqno 30).
Creating volume group backup "/etc/lvm/backup/system" (seqno 30).
Creating volume group backup "/etc/lvm/backup/system" (seqno 30).
# 

Het instellen van writebehind geeft netzoveel output bij -v, zonder valt het mee:

# lvchange --raidwritebehind 255 /dev/system/root
Logical volume system/root changed.
# lvchange --raidwritebehind 255 /dev/system/usr
Logical volume system/usr changed.
# lvchange --raidwritebehind 255 /dev/system/var
Logical volume system/var changed.
# lvchange --raidwritebehind 255 /dev/system/varlog
Logical volume system/varlog changed.

De waarde van 255 heb ik vrij willekeurig gekozen. Voor draaiende schijven kunnen de prestaties inzakken tot 3 schrijfacties per seconde, maar dat is bij een schrijfpatroon dat totaal willekeurig is (4k random reads, dus ~10kB/s). Om bij sequentieel schrijven aan 100MB/s te komen met blokken van een paar MB, moet de schijf zo’n 50 bewerkingen per seconde (IOPS) halen.
Op die twee aannames gebaseerd, zit je met 255 op 5 seconden wachten als er grote bestanden geschreven worden, of een paar minuten met honderden kleine bestandjes op willekeurige plaatsen op de schijf.

Ik kijk het eerst een tijdje op deze manier aan. De LV’s zijn nu gespiegeld, ik kan ze eventueel weer loskoppelen en de SSD-helft van de spiegel vervolgens als cache inzetten.

Voor de overige VG’s houd ik nog wel een cachingmechanisme aan.

# # eerst voor /home/wbk/
# lvcreate -vn cache_wbk -L18G homes /dev/sdd3
Logical volume "cache_wbk" created.
lvcreate -vn cache_meta_wbk -L100M homes /dev/sdc3
Logical volume "cache_meta_wbk" created.
# vconvert -v --type cache --cachepool cache_wbk --poolmetadata cache_meta_wbk /dev/homes/wbk
Setting chunk size to 64.00 KiB.
Preferred pool metadata size 100.00 MiB.
Pool metadata extents 25 chunk_size 128
WARNING: Converting homes/cache_wbk and homes/cache_meta_wbk to cache pool's data and metadata volumes with metadata wiping.
THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert homes/cache_wbk and homes/cache_meta_wbk? [y/n]: y
Converted homes/cache_wbk and homes/cache_meta_wbk to cache pool.
Logical volume homes/wbk is now cached.
# # daarna voor de overige homedirectories op /home/
# lvcreate -vn cache_homes -L7G homes /dev/sdc3
Logical volume "cache_homes" created.
#lvcreate -vn cache_meta_homes -L100M homes /dev/sdd3
Logical volume "cache_meta_homes" created.
# lvconvert --type cache --cachepool cache_homes --poolmetadata cache_meta_homes /dev/homes/home
WARNING: Converting homes/cache_homes and homes/cache_meta_homes to cache pool's data and metadata volumes with metadata wiping.
THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert homes/cache_homes and homes/cache_meta_homes? [y/n]: y
Converted homes/cache_homes and homes/cache_meta_homes to cache pool.
Logical volume homes/home is now cached.

Voor de data-VG is het dubbel jammer dat het cache per LV toegewezen moet worden. De verhouding is al schever dan bij de andere twee VG’s en er zijn meer LV’s tevreden te houden. Aan de andere kant is het vooral de foto-LV waar wat gebeurt, en de pub-LV waar random geschreven zou kunnen worden. Ik ga voor een cache op de foto-LV. Als de prestaties van een van de overige LV’s erg tegenvallen, schuif ik alsnog met de toewijzing.

# lvcreate -n cache_fotos -L48G data /dev/sdd4
Logical volume "cache_fotos" created.
# lvcreate -n cache_meta_fotos -L100M data /dev/sdc4
Logical volume "cache_meta_fotos" created.
# lvconvert --type cache --cachepool cache_fotos --poolmetadata cache_meta_fotos /dev/data/fotos
WARNING: Converting data/cache_fotos and data/cache_meta_fotos to cache pool's data and metadata volumes with metadata wiping.
THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert data/cache_fotos and data/cache_meta_fotos? [y/n]: y
Converted data/cache_fotos and data/cache_meta_fotos to cache pool.
Logical volume data/fotos is now cached. 

Losse eindjes

De basis staat er nu wel. Losse eindjes die zo bij me opkomen:

  • De bestanden die van de kleine SSD afkomen en aangekoppeld zijn op /home/ssdata, met databases van Calibre (SQLite) en Digikam (in MySQL). Die mogen weer terug naar een nieuw te maken LV in VG data.
  • De bestanden die nog op de 6TB WD-schijf staan. Ongeveer 2,5TB aan backups, HDD-images en overige ‘bestanden die ergens geparkeerd moesten worden’. Uitzoeken en kijken wat er nog op de SMR-schijf gearchiveerd kan worden.
  • Als de 6TB schijf leeg is, die indelen op zo’n manier dat daar de komende ‘live’ data op terechtkomt. Misschien /home/wbk/ en de verschillende system-LV’s daarheen verplaatsen
  • Functionaliteit om mee te experimenteren:
    • lvmthin: thin provisioning
    • lvmdo: dataoptimalisatie, compressie en deduplicatie
  • Inrichting overig
    • data-LV’s aankoppelen onder /home/ en via bind-mount beschikbaar maken in ieders homedirectory, via die weg ook in Nextcloud
    • OverlayFS, om ieders wijzigingen aan de data-LV’s in de eigen homedirectory op te slaan

Eerst de data van /home/ssdata verplaatsen:

# lvcreate -n ssdata -L40G data /dev/sdc4
# mkfs.ext4 /dev/data/ssdata
# mount /dev/data/ssdata /mnt/p1
# service mysql stop
# cp -vr --preserve /home/ssdata/mysql/ /mnt/p1/
# cp -vr --preserve /home/ssdata/calibre/ /mnt/p1/
# # aankoppelpunt wijzigen 
# vi /etc/fstab
# umount /home/ssdata
# umount /mnt/p1
# mount /dev/mapper/data-ssdata
# mount|grep ssd
/dev/mapper/data-ssdata on /home/ssdata type ext4 (rw,noatime,data=ordered)
# service mysql start

De 2,2TiB data bestaan voor 1,6TiB uit een backup van foto’s van twee jaar geleden. Een nieuwe backup kan nu naar de, ondertussen vrije, 3TB schijf. De resterende <600GiB kan op het staartje van de SMR-schijf:

# fdisk /dev/sdb
# # --> n, enter, enter, +1.1T enter, t 31 enter, w enter
# pvcreate /dev/sdb9
# vgextend data /dev/sdb9
# # het logische volume niet willekeurig (en misschien deels op de SSD plaatsen): stuur lvcreate met /dev/sdb9 
# lvcreate -n archief -L 800G /dev/data /dev/sdb9
# mkfs.ext4 /dev/mapper/data-archief
# vi /etc/fstab 
# cat /etc/fstab|grep arch
/dev/mapper/data-archief /home/data/archief ext4 noatime,noexec,auto 0 2
# mount -a 
# cp -vr --preserve /mnt/p1/backup/* /home/data/archief/
# iostat -hd 3 /dev/sdb9 /dev/sde1
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
153.33 0.0k 102.5M 0.0k 307.6M sdb9
362.67 90.7M 0.0k 272.0M 0.0k sde1
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
164.33 0.0k 114.6M 0.0k 343.9M sdb9
472.00 117.5M 0.0k 352.4M 0.0k sde1
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device 80.67 0.0k 55.4M 0.0k 166.1M sdb9
262.00 65.5M 0.0k 196.5M 0.0k sde1
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device
141.00 0.0k 94.0M 0.0k 282.0M sdb9
324.00 81.0M 5.3k 243.0M 16.0k sde1
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device

Huishoudelijk: disk repartitioneren tot:

Device     Start     End          Sectors Size Type
/dev/sde1      2048   4294969343 4294967296 2T Linux LVM
/dev/sde2 4294969344  6442452991 2147483648 1T Linux LVM
/dev/sde3 6442452992 10737420287 4294967296 2T Linux LVM
/dev/sde4 10737420288 10947135487 209715200 100G Linux LVM 
          10947135488 11721045134 773909647 369G  free
# # grappig... 
# pvcreate /dev/sde[1234]
WARNING: atari signature detected on /dev/sde3 at offset 454. Wipe it? [y/n]:
Wiping atari signature on /dev/sde3.

Toewijzing aan VG’s gaf een opvallende waarschuwing:

# pvcreate /dev/sde[1234]
WARNING: atari signature detected on /dev/sde3 at offset 454. Wipe it? [y/n]:
Wiping atari signature on /dev/sde3.

Verder niets noemenswaardigs bij het toewijzen:

# vgextend data /dev/sde1
Volume group "data" successfully extended
# vgextend homes /dev/sde2
Volume group "homes" successfully extended
# vgcreate infra /dev/sde3
Volume group "infra" successfully created
# vgextend system /dev/sde4
Volume group "system" successfully extended 

Tussentijdse conclusies en overwegingen

Het systeem draait nu zo’n week met /home/ op de SMR-schijf. Het valt me mee wat er het aan vertraging veroorzaakt, maar ik denk dat een groot deel van de bruikbaarheid aan het SSD-cache te danken is.

Voorafgaand aan en net na het configureren van cache, duurde het tientallen seconden voordat bijvoorbeeld Dolphin geopend werd; in sommige gevallen ben ik weggelopen bij de machine om m’n tijd nuttiger te besteden.

Nu het cache een paar dagen actief is, start Dolphin niet in een flits, maar is er wel op te wachten; in minder dan twee seconden is het programma bruikbaar.

Gigabytes aan gegevens verplaatsen van de ene partitie op de SMR-schijf naar de andere is te overzien, maar gaat ook niet vliegensvlug. Als het om enkel schrijven naar de schijf gaat, zag ik vaak snelheden van 80-90MB/s, met uitschieters naar 120MB/s. Dat is bij het initieel vullen van de schijf, waarbij er geen lees-schrijf-schijf actie nodig is. Bij het verplaatsen nu de schijf voller zit, moet er zowel gelezen als geschreven worden, en mogelijk moet bij het schrijven data herschreven worden.

Ik denk dat ik de inrichting van de schijven nog wat ga aanpassen bij het daadwerkelijk in gebruik nemen van de PMR-schijf. Video’s, en muziek/foto’s in mindere mate, zijn grote blokken data die sequentieel geschreven worden en weinig daarna vrij statisch zijn. SMR-schijven lenen zich daar prima voor.

Home-directories, met documenten die telkens aangepast worden, configuratiebestanden, tijdelijke bestanden en downloads, zijn in dat opzicht veel dynamischer. Een PMR-schijf is daarvoor meer geschikt.

Het ‘begin met een lege schijf en schrijf die van begin tot eind vol’ is, ook met meerdere LV’s, goed te doen dankzij lvmthin: daarbij worden juist de fysieke datablokken pas aangesproken op het moment dat ze nodig zijn, en dus in volgorde van leeg naar vol, zonder gaten. De resulterende LV kan wel gefragmenteerd raken, maar dat is in brokken van meerdere MB’s omdat de bestanden in dat patroon geschreven worden.

De PMR-schijf blijft daarmee beschikbaar voor home-directories en ander dynamischer gebruik.

Een ander gevolg van die indeling is dat de toewijzing van SSD-cache meer geconcentreerd kan worden op de PMR-schijf: het bulk aan data op de SMR-schijf wordt zo laagfrequent aangesproken, dat caching daarvan weinig nut heeft. Een schijfcache is nog te overwegen, bovenop de 128/256MB disk-cache en het PMR-cache op de SMR-schijf. Dat is vooral voor de foto-LV interessant, zodat SD-kaartjes op volle snelheid gelezen kunnen worden.

Eerst de system-VG van PMR naar SMR, respectievelijk op sdb en sde.

# lvconvert -m1 /dev/system/root /dev/sde4 
# lvconvert -m1 /dev/system/varlog /dev/sde4
# lvconvert -m1 /dev/system/var /dev/sde4
# lvconvert -m1 /dev/system/usr /dev/sde4
# pvs /dev/sde4
PV VG Fmt Attr PSize PFree
/dev/sde4 system lvm2 a-- <100.00g <100.00g

Raar… Er is niets geschreven naar /dev/sde3; met iostat was er ook nauwelijks verkeer te zien. Misschien is het mechanisme in de war door het cache wat er tussen zit. Morgen opnieuw proberen, nadat het cache uitgeschakeld is.

“De volgende dag…”

Het cache zorgt er inderdaad voor dat het spiegelen anders loopt dan ik verwacht. LV root is een virtuele LV op basis van de feitelijke data (op sdb6) en het cache (op sdc2). Dat volume is omgezet naar type=raid1, maar er is geen fysieke drager aangehangen omdat die op een lager niveau ligt. Als ik de LV op het lagere niveau probeer te spiegelen, krijg ik als foutmelding:

# lvconvert -tm1 /dev/system/root_rimage_0 /dev/sde4
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Operation not permitted on hidden LV system/root_rimage_0. 

Twee opties, naast het erbij laten:

  • Caching ongedaan maken, daarna LV kopieren via lvm-raid en spiegeling vervolgens ongedaan maken, caching weer activeren;
  • de system-LV’s gebruiken voor lvm-thin met external origin (waarschijnlijk hetzelfde probleem, dat loopt ook via lvconvert;
  • of nietsdoen

De eerste optie is even irritant, maar zonder cache disablen zit het vast in het huidige stramien. Gelukkig gaat het verwijderen van cache even moeiteloos als het inschakelen ervan. Bij het controleren van de inrichting met

# lvs -a -o name,segtype,devices 
root raid1 root_rimage_0(0),root_rimage_1(0)
[root_rimage_0] linear /dev/sdb6(1)
[root_rimage_1] linear /dev/sdc2(1)
[root_rmeta_0] linear /dev/sdb6(10343)
[root_rmeta_1] linear /dev/sdc2(0)

… realiseerde ik me hoe de vork in de steel zit. De system-LV’s zijn, zoals een paar pagina’s naar boven beschreven, al ingericht als lvmraid. Mijn actie om een enkelvoudige spiegel aan te leggen, slaat nergens op als er al een spiegel is. Aanleggen van een extra spiegel, dus -m2, heeft wel effect:

# lvconvert -m2 /dev/system/root /dev/sde4
Are you sure you want to convert raid1 LV system/root to 3 images enhancing resilience? [y/n]: y
Logical volume system/root successfully converted.
root@fractal:~# lvs -a /dev/system/root
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root system rwi-aor--- 5.00g 16.70
iostat -hd 5 /dev/sdb6 /dev/sde4 /dev/sdc2 /dev/sdd2
Linux 4.9.0-0.bpo.11-amd64 (fractal) 21/11/20 x86_64 (4 CPU)
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device 
9.00 0.0k 88.8k 0.0k 444.0k sdb6
602.80 85.9M 78.3k 429.2M 391.5k sdc2
1.40 0.0k 10.4k 0.0k 52.0k sdd2
594.60 0.0k 86.2M 0.0k 431.2M sde4
tps kB_read/s kB_wrtn/s kB_read kB_wrtn Device 
8.40 51.2k 332.3k 256.0k 1.6M sdb6
588.20 85.4M 328.9k 426.9M 1.6M sdc2
3.40 102.4k 3.4k 512.0k 17.0k sdd2
579.00 25.6k 84.9M 128.0k 424.4M sde4 
# lvconvert -m2 /dev/system/varlog
Are you sure you want to convert raid1 LV system/varlog to 3 images enhancing resilience? [y/n]: y
Logical volume system/var successfully converted.
# lvconvert -m2 /dev/system/var /dev/sde4
Are you sure you want to convert raid1 LV system/var to 3 images enhancing resilience? [y/n]: y
Logical volume system/var successfully converted.
# lvconvert -m2 /dev/system/usr /dev/sde4
Are you sure you want to convert raid1 LV system/usr to 3 images enhancing resilience? [y/n]: y
Logical volume system/usr successfully converted.

Nu weer een LV eruithalen, namelijk de spiegel op /dev/sdb6. De voorbeelden in de manpages zijn net iets te summier om te herleiden welke PV nu uit RAID gehaald wordt, eerder verwijderde ik juist de verkeerde. De documentatie van Red Hat geeft hetzelfde voorbeeld, maar omdat erbij verteld wordt wat het gevolg is (in plaats van alleen wat de wens is) kan ik dat wel plaatsen. Zo gelezen, zo gedaan:

# lvconvert -m1 system/varlog /dev/sdb6
Are you sure you want to convert raid1 LV system/varlog to 2 images reducing resilience? [y/n]: yes
Logical volume system/varlog successfully converted.
# lvs -a /dev/system/varlog
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
varlog system rwi-aor--- <6.52g 100.00 
# lvs -a /dev/system/varlog -o devices
Devices
varlog_rimage_0(0),varlog_rimage_1(0)
# lvs -a /dev/system/varlog_rimage_0 -o devices
Devices
/dev/sdd2(4374)
# lvs -a /dev/system/varlog_rimage_1 -o devices
Devices
/dev/sde4(1282) 

Ja, het juiste PV is verdwenen.

Dezelfde truc voor LV’s root, usr en var. Daarna usr uitbreiden, en kijken of ik var uitbreid of subdirectories op een losse partitie/LV zet (zoals voorheen /var/cache).

# lvs -a /dev/system/var_rimage_0 -o devices
Devices
/dev/sdb6(5655)
# lvs -a /dev/system/var_rimage_1 -o devices
Devices
/dev/sdc2(1282)
# lvs -a /dev/system/var_rimage_2 -o devices
Devices
/dev/sde4(2951)
# lvconvert -m1 system/var /dev/sdb6
Are you sure you want to convert raid1 LV system/var to 2 images reducing resilience? [y/n]: y
Logical volume system/var successfully converted.
# lvs -a /dev/system/var_rimage_2 -o devices
Failed to find logical volume "system/var_rimage_2"
# lvs -a /dev/system/var_rimage_1 -o devices
Devices
/dev/sde4(2951)
# lvs -a /dev/system/var_rimage_0 -o devices
Devices
/dev/sdc2(1282) 
# lvconvert -m1 system/usr /dev/sdb6
Are you sure you want to convert raid1 LV system/usr to 2 images reducing resilience? [y/n]: yes
Logical volume system/usr successfully converted.
# lvconvert -m1 system/root /dev/sdb6
Are you sure you want to convert raid1 LV system/root to 2 images reducing resilience? [y/n]: y
Logical volume system/root successfully converted.
# lvextend -vtr /dev/system/usr -L+3G
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Extending 2 mirror images.
Executing: /sbin/fsadm --dry-run --verbose check /dev/system/usr
fsadm: "ext4" filesystem found on "/dev/mapper/system-usr".
fsadm: Skipping filesystem check for device "/dev/mapper/system-usr" as the filesystem is mounted on /usr
/sbin/fsadm failed: 3
Test mode: Skipping archiving of volume group.
Extending logical volume system/usr to <20.08 GiB Size of logical volume system/usr changed from <17.08 GiB (4372 extents) to <20.08 GiB (5140 extents). Test mode: Skipping backup of volume group. Logical volume system/usr successfully resized. Executing: /sbin/fsadm --dry-run --verbose resize /dev/system/usr 21053440K fsadm: "ext4" filesystem found on "/dev/mapper/system-usr". fsadm: Device "/dev/mapper/system-usr" size is 18337497088 bytes fsadm: Parsing tune2fs -l "/dev/mapper/system-usr" fsadm: Resizing filesystem on device "/dev/mapper/system-usr" to 21558722560 bytes (3690496 -> 5263360 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/system-usr 5263360
# lvextend -vr /dev/system/usr -L+3G
Extending 2 mirror images.
Executing: /sbin/fsadm --verbose check /dev/system/usr
fsadm: "ext4" filesystem found on "/dev/mapper/system-usr".
fsadm: Skipping filesystem check for device "/dev/mapper/system-usr" as the filesystem is mounted on /usr
/sbin/fsadm failed: 3
Archiving volume group "system" metadata (seqno 61).
Extending logical volume system/usr to <20.08 GiB Size of logical volume system/usr changed from <17.08 GiB (4372 extents) to <20.08 GiB (5140 extents). Loading table for system-usr_rimage_1 (254:47). Resuming system-usr_rimage_1 (254:47). Loading table for system-usr_rmeta_1 (254:46). Suppressed system-usr_rmeta_1 (254:46) identical table reload. Loading table for system-usr_rimage_0 (254:8). Resuming system-usr_rimage_0 (254:8). Loading table for system-usr_rmeta_0 (254:7). Suppressed system-usr_rmeta_0 (254:7) identical table reload. Loading table for system-usr (254:9). Not monitoring system/usr with libdevmapper-event-lvm2raid.so Unmonitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKPYY1qvCEtimgOktNFgWC7GHCZMCD1kne for events Suspending system-usr (254:9) with device flush Suspending system-usr_rimage_1 (254:47) with device flush Suspending system-usr_rmeta_1 (254:46) with device flush Suspending system-usr_rimage_0 (254:8) with device flush Suspending system-usr_rmeta_0 (254:7) with device flush Loading table for system-usr_rimage_1 (254:47). Suppressed system-usr_rimage_1 (254:47) identical table reload. Loading table for system-usr_rmeta_1 (254:46). Suppressed system-usr_rmeta_1 (254:46) identical table reload. Loading table for system-usr_rimage_0 (254:8). Suppressed system-usr_rimage_0 (254:8) identical table reload. Loading table for system-usr_rmeta_0 (254:7). Suppressed system-usr_rmeta_0 (254:7) identical table reload. Resuming system-usr_rimage_1 (254:47). Resuming system-usr_rmeta_1 (254:46). Resuming system-usr_rimage_0 (254:8). Resuming system-usr_rmeta_0 (254:7). Resuming system-usr (254:9). Monitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKPYY1qvCEtimgOktNFgWC7GHCZMCD1kne for events Creating volume group backup "/etc/lvm/backup/system" (seqno 62). Logical volume system/usr successfully resized. Executing: /sbin/fsadm --verbose resize /dev/system/usr 21053440K fsadm: "ext4" filesystem found on "/dev/mapper/system-usr". fsadm: Device "/dev/mapper/system-usr" size is 21558722560 bytes fsadm: Parsing tune2fs -l "/dev/mapper/system-usr" fsadm: Resizing filesystem on device "/dev/mapper/system-usr" to 21558722560 bytes (3690496 -> 5263360 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/system-usr 5263360
resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/mapper/system-usr is mounted on /usr; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/mapper/system-usr is now 5263360 (4k) blocks long.

Bij het uitbreiden van de root-LV, was ik nogal verbaasd dat de gebruikte ruimte afnam van 85% naar nog geen 30%, met 4G beschikbaar in plaats van 300M. Ik kwam erachter dat er stiekum nog een hoop ruimte in de LV zat, die niet in het bestandssysteem opgenomen was:

# df -hTt ext4
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/system-root ext4 2.0G 1.6G 289M 85% /
# lvextend -vr /dev/system/root -L+1G
Extending 2 mirror images.
Executing: /sbin/fsadm --verbose check /dev/system/root
fsadm: "ext4" filesystem found on "/dev/mapper/system-root".
fsadm: Skipping filesystem check for device "/dev/mapper/system-root" as the filesystem is mounted on /
/sbin/fsadm failed: 3
Archiving volume group "system" metadata (seqno 63).
Extending logical volume system/root to 6.00 GiB
Size of logical volume system/root changed from 5.00 GiB (1280 extents) to 6.00 GiB (1536 extents).
Loading table for system-root_rimage_1 (254:41).
Resuming system-root_rimage_1 (254:41).
Loading table for system-root_rmeta_1 (254:40).
Suppressed system-root_rmeta_1 (254:40) identical table reload.
Loading table for system-root_rimage_0 (254:3).
Resuming system-root_rimage_0 (254:3).
Loading table for system-root_rmeta_0 (254:2).
Suppressed system-root_rmeta_0 (254:2) identical table reload.
Loading table for system-root (254:4).
Not monitoring system/root with libdevmapper-event-lvm2raid.so
Unmonitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKZZWgBeA6ZJIDMIpaqAnjsS6M7HF5BjyC for events
Suspending system-root (254:4) with device flush
Suspending system-root_rimage_1 (254:41) with device flush
Suspending system-root_rmeta_1 (254:40) with device flush
Suspending system-root_rimage_0 (254:3) with device flush
Suspending system-root_rmeta_0 (254:2) with device flush
Loading table for system-root_rimage_1 (254:41).
Suppressed system-root_rimage_1 (254:41) identical table reload.
Loading table for system-root_rmeta_1 (254:40).
Suppressed system-root_rmeta_1 (254:40) identical table reload.
Loading table for system-root_rimage_0 (254:3).
Suppressed system-root_rimage_0 (254:3) identical table reload.
Loading table for system-root_rmeta_0 (254:2).
Suppressed system-root_rmeta_0 (254:2) identical table reload.
Resuming system-root_rimage_1 (254:41).
Resuming system-root_rmeta_1 (254:40).
Resuming system-root_rimage_0 (254:3).
Resuming system-root_rmeta_0 (254:2).
Resuming system-root (254:4).
Monitored LVM-NiTSIQGq3LyqIcdz06lZ54wlha0p0jGKZZWgBeA6ZJIDMIpaqAnjsS6M7HF5BjyC for events
Creating volume group backup "/etc/lvm/backup/system" (seqno 64).
Logical volume system/root successfully resized.
Executing: /sbin/fsadm --verbose resize /dev/system/root 6291456K
fsadm: "ext4" filesystem found on "/dev/mapper/system-root".
fsadm: Device "/dev/mapper/system-root" size is 6442450944 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/system-root"
fsadm: Resizing filesystem on device "/dev/mapper/system-root" to 6442450944 bytes (563154 -> 1572864 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/system-root 1572864
resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/mapper/system-root is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/mapper/system-root is now 1572864 (4k) blocks long.
# df -hTt ext4
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/system-root ext4 5.8G 1.6G 4.0G 29% /

‘So be it’; als er nog eens per ongeluk een groot bestand in / valt, stort de boel niet meteen in wegens ruimtegebrek. Tot slot van deze exercitie de nu ongebruikte PV sdb6 weghalen uit VG system:

# vgreduce -va system
Archiving volume group "system" metadata (seqno 62).
Removing "/dev/sdb6" from volume group "system"
Creating volume group backup "/etc/lvm/backup/system" (seqno 63).
Removed "/dev/sdb6" from volume group "system"
Physical volume "/dev/sdd2" still in use
Physical volume "/dev/sdc2" still in use
Physical volume "/dev/sde4" still in use

so far… so good.

Data VG fatsoeneren

Het begint er al aardig op te lijken, met de system-VG op een schijfcombinate waar ik me geen zorgen over extreme prestatie-dips hoef te maken en vrije schijfruimte beschikbaar is.

De data- en home-LV’s zijn nog niet in de vorm die ik voor ogen heb. Ik denk dat een deel van het doel wat ik voor ogen had met AUFS/OverlayFS bereikt kan worden met ‘lvmthin with external origin’.

Print this entry

Proxmox op Debian

Proxmox biedt een ‘bare metal’ installer, waarmee automatisch het hele systeem klaargezet wordt. Mijn eerste Proxmox-server heb ik op die manier geinstalleerd.

Voor de huidige server zou ZFS een goede keuze kunnen zijn, maar met slechts 4GB aan RAM is het al wat krap voor alleen Proxmox en enkele containers. ZFS staat er om bekend beter te werken als het zwemt in beschikbaar geheugen, omdat ik dat onvoldoende kan inschatten wil ik voor deze installatie geen ZFS gebruiken.

‘Geen ZFS’ betekent ‘geen kant-en-klare’ installer. Gelukkig is het niet heel veel werk om een standaard Debian-installatie uit te breiden met Proxmox. De kale Debian installatie zat rond 100MB geheugengebruik. Ik volg een stappenplan van de Proxmox-website. In grote lijnen:

  • Machine in elkaar zetten
  • Debian installeren.
  • Afhankelijkheden in inrichting goedzetten:
    • /etc/hosts aanpassen om het externe IP terug te geven
    • /etc/apt/sources* uitbreiden met de repositories van Proxmox
  • Proxmox installeren met apt install proxmox-ve postfix open-iscsi
    • De download is ~350MB, installatie voegt ~1800MB toe.
  • Klaar!
    • Nog te doen: rechten instellen, containers maken, systeem gebruiken
# df -hTt ext4
Filesystem                   Type  Size  Used Avail Use% Mounted on
/dev/mapper/snelsys-root     ext4  2.7G   13M  2.6G   1% /
/dev/mapper/snelsys-usr      ext4  7.3G  1.1G  5.9G  15% /usr
/dev/sde2                    ext4  163M   83M   68M  55% /boot
/dev/mapper/slowsys-var      ext4  2.7G  153M  2.4G   6% /var
/dev/mapper/slowsys-varcache ext4  1.8G   77M  1.7G   5% /var/cache
/dev/mapper/slowsys-varlog   ext4  1.8G   24M  1.7G   2% /var/log
root@thuis:~# apt install proxmox-ve postfix open-iscsi
0 upgraded, 494 newly installed, 1 to remove and 0 not upgraded.
Need to get 342 MB of archives.
After this operation, 1,742 MB of additional disk space will be used.
Do you want to continue? [Y/n] 

Het liep fout; er was niet voldoende ruimte op /boot. Op de andere server is er 800MB in gebruik voor ’tig’ kernels, dat leek me wat overdreven. Hier zijn het er drie, daarvan kan er op zijn minst eentje per direct weg.

# dpkg -l | grep linux-image | awk '{print$2}'
linux-image-4.19.0-13-amd64
linux-image-4.19.0-6-amd64
linux-image-amd64
root@thuis:~# uname -a
Linux thuis 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux
# apt remove --purge linux-image-4.19.0-6-amd64
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  linux-image-4.19.0-6-amd64*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 269 MB disk space will be freed.
Do you want to continue? [Y/n] 
...
update-initramfs: Deleting /boot/initrd.img-4.19.0-6-amd64
/etc/kernel/postrm.d/zz-pve-efiboot:
Re-executing '/etc/kernel/postrm.d/zz-pve-efiboot' in new private mount namespace..
No /etc/kernel/pve-efiboot-uuids found, skipping ESP sync.
/etc/kernel/postrm.d/zz-update-grub:
Generating grub configuration file ...
...
update-initramfs: Generating /boot/initrd.img-5.4.78-2-pve
Running hook script 'zz-pve-efiboot'..
Re-executing '/etc/kernel/postinst.d/zz-pve-efiboot' in new private mount namespace..
No /etc/kernel/pve-efiboot-uuids found, skipping ESP sync.
# 

Op / is er nauwelijks wat geinstalleerd, het iz vooral /usr waar ~1500MB aan toegevoegd is (1200 netto verschil, na purge oude kernel).

Rechten toewijzen

De Proxmox-installer maakt geen gebruikers aan. De Debian-installer wel. Bovendien heb laat ik de Debian-installer root-login uitschakelen. Zodoende is de bestaande gebruiker geen gebruiker die toegang tot Proxmox heeft.

Om Proxmox via de web-interface te bedienen, moet de gebruiker ingericht worden:

# pveum user add ikzelf@pam
# pveum groupadd beheer -comment "Proxmox en containers instellen"
# pveum aclmod / -group beheer -role Administrator
# pveum usermod ikzelf@pam -group beheer

De nieuwe rechten worden on-the-fly toegekend, maar bij het switchen tussen niveau’s op de web-interface komen maar enkele knoppen beschikbaar als je al ingelogd was voordat je aan de groep met ‘Administrator’-rol toegevoegd bent. Het was daarvoor in mijn geval niet voldoende uit- en in te loggen, of de pagina te verversen. De nieuwe eigenschappen werden pas zichtbaar na uitloggen, tab sluiten en inloggen in een nieuw tab.

Gegevensruimte / opslag

De servers heeft vier fysieke opslagmedia:

  • 1x SSD /dev/sde, 80GB
    • 9M BIOS boot, GPT-partitie voor GRUB
    • 170M /boot
    • 5.6G swap
    • 13G LVM PV
      • 13G VG ‘snelsys’
        • 2.8G LV root
        • 7.5G LV usr
    • 56G vrije ruimte
      • 3G ‘overprovisioning’, om de firmware ruimte te geven verwijderde bestanden op bestandssysteem-niveau, via LVM-pass-through als fysieke toewijzingen, de als leeg gemarkeerde sectoren te wissen. Als het goed is past de SSD-firmware dynamische wear-leveling toe, zodat die 3G vrije ruimte nomadisch over de flash-cellen rondwaart.
      • 50G+ voor read/write caching, ongeveer 10G/TB aan HDD-ruimte. Niet veel, maar het scheelt. Waarschijnlijk maak ik een enkele VG uit de twee vrije HDD’s, zodat de caching ineens voor alle LV’s voorbereid is. Misschien 1G voor VG slowsys, zodat alles onder /var SSD-caching heeft.
  • 1x HDD /dev/sda, 2TB, deels gebruikt:
    • 28G LVM PV
      • 28G VG ‘slowsys’
        • 2.8G LV var
        • 1.8G LV varcache
        • 1.8G LV varlog
    • ~2TB vrij, ik denk om een VG voor backups te maken
  • 2x HDD /dev/sdb en /dev/sdc, ieder 2TB, leeg
    • Op beide schijven LVM PV’s van ~450TB, tot 98% van de volledige ruimte
      • Bij sommige LVM-bewerkingen is een paar MB aan vrije ruimte nodig, er is nu 40G per schijf beschikbaar voor noodgevallen.

Schijven inrichten

Zoals beschreven, op iedere schijf partities van 450GB met (in fdisk) type 31 (Linux LVM):

# fdisk -l /dev/sdb
Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD20EFRX-68A
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 2DF239C2-BCE1-674A-ACCA-F6D6C45B5649

Device          Start        End   Sectors   Size Type
/dev/sdb1        2048  951757283 951755236 453.9G Linux LVM
/dev/sdb2   951758848 1903514564 951755717 453.9G Linux LVM
/dev/sdb3  1903515648 2855271850 951756203 453.9G Linux LVM
/dev/sdb4  2855272448 3807029134 951756687 453.9G Linux LVM

In de eerste instantie een enkele partitie aan een VG toekennen

# pvcreate /dev/sdb1
  Physical volume "/dev/sdb1" successfully created.
# vgcreate yunohost /dev/sdb1
  Volume group "yunohost" successfully created
# pvesm lvmscan
yunohost
snelsys
slowsys

Nu in de Proxmox GUI, via Datacenter –> Storage –> Add –> LVM

Het is verwarrend dat zowel ID als Volume group leeg en verplicht zijn. Bij ID geef je zelf een naam voor de Proxmox-storage op (yunohost, hier), bij Volume group kies je de LVM VG waar de opslagruimte in terechtkomt. Het resultaat:

ISO’s wil ik op een los volume zetten, maar Proxmox gebruikt LVM-volumes als block-storage; ISO’s moeten kunnen enkel op file-storage opgeslagen worden. Het voorbeeld voor directory-opslag laat zien dat de standaardlocatie /var/lib/vz is, daar staat nu een lijstje lege directories. Ik maak een LV met bestandssysteem, kopieer de data en koppel het op die locatie:

# ls -ls /var/lib/vz
total 20
4 drwxr-xr-x 2 root root 4096 Jan  9 19:08 dump
4 drwxr-xr-x 2 root root 4096 Dec  3 18:14 images
4 drwxr-xr-x 2 root root 4096 Jan  9 19:08 private
4 drwxr-xr-x 2 root root 4096 Jan  9 19:08 snippets
4 drwxr-xr-x 5 root root 4096 Jan  9 19:02 template
# lvcreate -n isosetc -L 4G slowsys
  Logical volume "isosetc" created.
# mkfs.ext4 /dev/mapper/slowsys-isosetc 
mke2fs 1.44.5 (15-Dec-2018)
Creating filesystem with 1048576 4k blocks and 262144 inodes
Filesystem UUID: 020be116-ab3f-474b-b407-a7301e59399c
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done 

root@thuis:~# mount /dev/mapper/slowsys-isosetc /mnt/
root@thuis:~# cp -r /var/lib/vz/* /mnt/
# echo '/dev/mapper/slowsys-isosetc /var/lib/vz    ext4 defaults 0 2' >> /etc/fstab 
# touch /mnt/ok
# mount /var/lib/vz
# ls /var/lib/vz
dump  images  lost+found  ok  private  snippets  template
# 

Nu kan ik met de ingebouwde template-downloader templates van Proxmox ophalen, bijvoorbeeld Debian 10 (voor het screenshot opnieuw geopend; het template is al te zien in de achtergrond)


Op het samenvattingsscherm voor dit stukje opslag is te zien dat de hoeveelheid vrije ruimte en de hoeveelheid gebruikte ruimte schommelt. Tot het aankoppelen van het nieuwe volume bestonden de totale vrije ruimte en de gebruikte ruimte uit alles op LV var, aangekoppeld op /var. De vrije ruimte neemt toe van 3G (vrij op LV var) tot 4G (de vrije ruimte op LV isosetc). De gebruikte ruimte neemt af van ‘alles op /var, behalve /var/cache en /var/log’ (op hun eigen LV) naar 0, en daarna weer tot halverwege 500MB na het downloaden van het Debian-template.

Netwerk – bridge

Op de andere machine heb ik een Open vSwitch bridge gemaakt. Deze keer probeer ik het met een Linux bidge, die schijnt eenvoudiger te werken, ik gok dat dat minder resourceverbruik betekent.

De machine heeft twee fysieke netwerkpoorten, een er van is aangesoten (enp3s0). Via ‘Create –> Linux Bridge’ heb ik de bridge toegevoegd. Zowel de netwerkkaart zelf als de bridge heb ik op autostart gezet, bij enp3s0 was dat initieel niet actief. Het resultaat in de GUI:

De configuratie kan vanuit de GUI toegepast worden als ifupdown2 beschikbaar is. Vanuit de CLI ziet het resultaat eruit als:

root@thuis:~# apt install  ifupdown2
Reading package lists... Done
Building dependency tree       
...
dpkg: ifupdown: dependency problems, but removing anyway as you requested:
dpkg: ifenslave: dependency problems, but removing anyway as you requested:
Saved in /etc/network/interfaces.new for hot-apply or next reboot.
root@thuis:~# cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto enp3s0
iface enp3s0 inet manual
# This is an autoconfigured IPv6 interface

iface enp2s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.168.6/24
        gateway 192.168.168.1
        bridge-ports enp3s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
#even kijken of dat zo werkt, moet later aangepast worden naar correcte IP's

iface vmbr0 inet6 static
        address 2001:985:b79a:1:225:90ff:fe33:1189/128
        gateway 2001:985:b79a:1::

root@thuis:~# 

Container toevoegen

Met de blauwe ‘Create CT’-knop voeg je een container toe. Hierboven heb ik aan de voorwaarden om er een aan te kunnen maken voldaan:

  • Template – er is een template beschikbaar

Screenshots van de installatiestappen (todo…):

Login

Inloggen zou makkelijk moeten gaan: IP via DHCP,de machinenaam heb ik opgegeven, moet via lokale DNS op naam bereikbaar zijn, SSH public key heb ik meegegeven, dus login met root@fakraz zou meteen moeten werken.

Niet dus. IP opzoeken in de GUI geeft geen resultaat, er staat alleen ‘DHCP’. In de router/dhcp-server staat onder het MAC adres van de container het IP van de host. Login via console en via shell in de GUI gaat op twee manieren mis: soms is er geen login-prompt, als hij er wel is dan wordt het wachtwoord niet herkend. Blijkbaar herinner ik me niet goed wat ik ingevuld heb.

Gelukkig kan ik vanuit de host toegang krijgen tot de container, met pct:

root@thuis:~# pct enter 100
root@fakraz:~# passwd
New password: 
Retype new password: 

Na een reboot van de container werkt ‘opeens’ de login via public key ook, maar de login via console blijft wisselend. Het wil wel eens een paar minuten duren voordat de login-prompt op het scerm staat, maar als die er eenmaal is, lukt het wel in te loggen.

Installatie Yunohost

Het kan allemaal niet in een keer goed gaan natuurlijk. Yunohost heeft last van een DDoS-aanval, waardoor https://install.yunohost.org niet beschikbaar is. Bij het ophalen van de pagina via web.archive.org kreeg ik een certificaat-fout. Google’s cache was wel beschikbaar, maar daar krijg ik 403, geen toegang, met wget.

Tekst kopieren en in een los installatiebestandje plakken lukt wel.

Bij het uitvoeren komen er veel locale-errors voorbij:

perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory                                                                     
locale: Cannot set LC_MESSAGES to default locale: No such file or directory                                                                  
locale: Cannot set LC_ALL to default locale: No such file or directory

In de container mag dpkg-reconfigure locales niet schrijven naar die locatie, gok ik, want toevoegen van de locale geeft in dpkg dezeldfe fout.

Daarom op de host de locale en_US.UTF-8 toegevoegd (naast en_IE.UTF-8); de installatie start nu en verloopt op de normale manier.

Klaar!

Daarmee draait alles:

  • Debian geinstalleerd
  • Proxmox op Debian geinstalleerd
  • Container met Debian op Proxmox
  • Yunohost op Debian in de container

Het draait, met weliswaar lage belasting op het moment, als een zonnetje. Qua hardware heeft Supermicro 2U Twin3 2015TA-HTRF 8x precies deze configuratie. Op hoofdlijnen:

  • Supermicro X7SPA-H-D525
  • Atom D525, 2 cores / 4 threads@1.8GHz
  • 4GB RAM
  • 80GB SSD
  • 3x 2TB HDD

Print this entry