Tag: lvmcache

Geplaatst op

PBS-migratie – valse start

Update: onderstaand stappenplan is de prullenbak ingegaan nadat ik van RAID0 naar RAID5 ging, ipv RAID10. Herzien: rechtstreeks naar RAID10 met een kleine hardware-aanpassing.

Oude situatie: 1x 4TB in gebruik + 3x 4TB ongebruikt
Nieuwe situatie: RAID10 over 4x 4TB + LVM caching over 4x 0,2TB SSD

Stappen:

  • HDD’s identificeren en overbrengen naar nieuwe behuizing
  • LVM RAID0 over 2x 4TB, caching toevoegen
  • 8TB RAID0 LVM toevoegen aan PBS
  • PBS sync van ZFS op 1x 4TB naar 8TB RAID0 LVM
  • Mirror toevoegen aan beide schijven, van 2x 4TB naar 4x 4TB

Praktische uitvoering:

  • 1x 4TB SAS blijkt defect, voorlopig vervangen met beschikbare 3TB of 6TB SATA schijf
  • LVM voorbereiden:
    • fdisk /dev/sde
      • g – nieuw GPT disklabel
      • n – nieuwe partitie (partitie 1, vanaf default sector 2048 tot default laatste sector, en dan van de laatste sector een stukje afhalen om ~1% vrije ruimte over te laten)
      • t – type: lvm
      • p – print indeling ter controle
      • w – schrijf de indeling naar schijf
    • pvcreate /dev/sde1 /dev/sdf1
    • vgcreate backup /dev/sde1 /dev/sdf1
    • Striped LV over de twee HDD’s, stripesize van 1 MB
      • Niet de volle 100% vrije ruimte gebruiken om toekomstige mutaties niet te blokkeren (Volume group "backup" has insufficient free space (0 extents): 8 required
      • lvcreate -n localbaks -vt -i2 -l95%VG backup -I 1M /dev/sdf1 /dev/sde1
    • Tijdelijk de huidig beschikbare SSD toevoegen als dmcache
      • vgextend backup /dev/sda1
    • Cachevol maken en toevoegen aan de striped LV; gebruik niet %VG, dat gaat over de volledige VG, niet over de aangewezen PV
      • lvcreate -vt -n localbaks_cache -L 70G backup /dev/sda1
      • lvconvert --type cache --cachepool localbaks_cache backup/localbaks
    • Is het nodig om cache te verwijderen?
      • lvconvert --uncache backup/localbaks
  • Het gecreerde volume toevoegen aan PBS; omdat het geen raw disk device is, kunnen we niet het disk subcommand van proxmox-backup-manager gebruiken. Daarom handmatig een bestandssysteem aanmaken, mounten en vervolgens een datastore maken:
    • mkfs.ext4 /dev/mapper/backup-localbaks
    • mkdir -p /mnt/datastore/localbaks
    • echo '/dev/mapper/backup-localbaks /mnt/datastore/localbaks ext4 defaults 0 0' >> /etc/fstab
    • proxmox-backup-manager datastore create localbaks /mnt/datastore/localbaks

Vervolgstappen

sync-job: ingericht via de web-GUI:

  • Gecreëerd vanuit de nieuwe ‘localbaks’ datastore, als ‘sync pull job’
  • ‘remote’ uitgevinkt, locale oude datastore als bron aangewezen
  • volledige namespace
  • jaarlijks (want eenmalig) gepland
  • vervolgens met ‘run now’ handmatig gestart

De actie trekt volgens de ‘administration’ sectie van PBS zo’n 100% CPU met IO wait op 80% en 6 van 16 GB geheugen bezet; htop geeft 10-15% belasting op elk van de 4 cores bij een bescheiden geheugengebruik van <700 MB

Transfersnelheid zit op zon 80 MB/s via PBS en 100 MiB/s via htop wat redelijk bij elkaar in de buurt komt.

Er is wel een groot verschil in het aantal IOPS op de oude disk tegenover de nieuwe gecachte RAID0: volgens PBS ongeveer 20 IOPS op de oude schijf, tegelijkertijd zo’n 700 IOPS op de nieuwe schijf. Zelfs als de oude schijf 4k sectors zou hebben en de nieuwe 512b, is dat verschil niet te verklaren.

De verhouding tussen bandbreedte en IOPS op de nieuwe RAID0 is 1 MB/s voor elke 10 IOPS, dus 100 kB per I/O. Later nog eens naar kijken, wordt vervolgd.

Todo’s

  • RAID0 –> RAID10
  • 1x 80 GB SSD vervangen door deel van 4x 200 GB SSD
  • 1x 100 GB system SSD vervangen door deel van 4x 200 GB SSD

Print this entry

Geplaatst op

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