Frontpage

Rolling back-ups van VM’s met Proxmox

In de afgelopen weken is Tuxis bezig geweest met het testen van Proxmox als vervanger van Archipel, wat op dit moment gebruikt wordt om de VM’s van klanten aan te maken en te bedienen. Proxmox is een product dat al meer ontwikkelingstijd heeft en goed geschikt is om complete clusters mee te beheren. Daarnaast zouden klanten ook zelf een login kunnen krijgen om op die manier op eenvoudige wijze hun VM te bedienen.

Proxmox heeft ook back-upfunctionaliteit ingebouwd. De back-ups worden niet gemaakt vanuit de VM, wat Tuxis Online Back-up wel doet, maar de back-up wordt van de gehele disk gemaakt, zonder dat dat te merken is in de VM zelf. Voor dagelijkse back-ups heeft dit wat nadelen. Zo kun je geen losse files restoren, waardoor je eigenlijk de complete disk terug moet zetten. Online back-up blijft dus nog steeds een belangrijk onderdeel van de dienstverlening van Tuxis (u krijgt bij iedere VM die u afneemt, 10GB back-upopslag tot uw beschikking). Maar voor disaster-recovery is de back-up van de gehele disk (en de configuratie van de VM voor Proxmox) wel heel erg handig!

Proxmox laat je instellen wanneer je back-ups wilt maken, en waarvan. Maar in de praktijk houdt dat in dat je zelf moet bijhouden wie je back-upt, en wanneer. Je kunt ook niet aangeven wanneer de back-up moet stoppen met draaien. En dat kan weer (negatieve) gevolgen hebben voor de snelheid van de centrale storage. Daarom heeft Tuxis pmrb geschreven.

Wat doet pmbr?

pmbr staat voor “ProxMox Rolling Backups”. Het is de bedoeling dat het script op iedere machine die Proxmox draait geinstalleerd en geconfigureerd wordt zodat het door Cron op gezette tijden gedraaid wordt.
root@proxmox1-1:~# pmrb --help

This script will provide you with rotating backups of your VMs. It will make
sure to create backups if the oldest backup is too old. However, it will not
start new backups if it is too late to avoid performanceissues with your
storage.

Options:
pmrb [--dry-run] [--verbose] [--notafter <HH:MM>] [--maxage <weeks>] [--storage <pool>] [--email <emailaddress>]
--dry-run Don't actually run the backup. Just show which machines would be backed up
--verbose Add some extra output
--notafter Do not start a backup after HH:MM
--maxage Run new backups if the last VM-backup is older than <weeks> weeks
--storage Don't autodetect any storagepool that allows backups, use <pool>
--email Send an email to <emailaddress> for each backup
--help This help

Het accepteert een aantal opties waardoor het z’n doel bereikt: Zorg dat we van iedere VM een diskimage hebben van maximaal X-weken oud, maar voorkom onnodige load op de productiestorage op productiemomenten.

Als je pmbr start, gaat het twee dingen doen:

  1. Bepaal in welke Proxmox storagepool we de back-ups gaan plaatsen
  2. Inventariseer welke VM’s er op deze machine draaien en zet die in een lijst
  3. Sorteer de volgorde van te back-uppen machines op basis van deze voorwaarden
    • Als er een back-up van de VM is die jonger is dan <weeks>, haal de machine dan uit de lijst van te back-uppen machines
    • Als er nog geen back-up van de VM is, zorg dan dat deze bovenaan het lijstje van te back-uppen machines komt te staan
    • Sorteer de rest van de machines op basis van ‘hoe jonger de back-up, hoe lager op de lijst’
  4. Begin met het maken van back-ups, maar alleen als het niet later is dan <HH:MM>

Je kunt pmbr dagelijks draaien. Het gaat namelijk niets doen op het moment dat de back-ups jong genoeg zijn. Zodra er een nieuwe VM op het platform bijkomt, zal deze automatisch bij de eerst volgende run geback-upt worden. Als een back-up wel te oud is, zal er een nieuwe back-up gemaakt worden. Omdat het (in de meeste gevallen) niet zal lukken om alle machines in één run te back-upppen, ontstaat er vanzelf een verdeling van de load van het back-uppen over de verschillende momenten dat pmbr draait.

Cool, hoe kom ik aan pmbr?!

Je kunt pmbr downloaden via Tuxis z’n publieke HG-repository. Tips en feature-requests zijn natuurlijk altijd welkom. 🙂

Algemeen

OTRS in Nginx met FCGI

OTRS is een Trouble Ticketing Systeem wat erg uitgebreid is. Het is geschreven in Perl, wat een heel aantal voordelen heeft, maar vooral op het gebied van performance is dat een nadeel.
Een oplossing daarvoor is om OTRS in mod_perl te draaien. Daar gaat de performance van OTRS behoorlijk van vooruit, maar ook mod_perl brengt weer een nadeel met zich mee. Het is namelijk niet te combineren met mod_itk, een module om verschillende sites als verschillende gebruikers te laten draaien. Als je dus mod_perl zou kiezen ben je genoodzaakt om alles als www-data (of het equivalent in jouw distributie) te laten draaien.

Ik ben op zoek gegaan naar een oplossing om OTRS snel te laten draaien, maar wel met de mogelijkheid om OTRS als aparte user te draaien.
OTRS heeft zelf al rekening gehouden met de mogelijkheid om fcgi te gebruiken, maar de documentatie daarvan is erg beperkt en leverde mij niet het gewenste resultaat. Vooral het draaien als aparte user lijkt een uitdaging te zijn.
Ik ben uiteindelijk uitgekomen bij Nginx (een andere webserver zal waarschijnlijk ook prima voldoen) in combinatie met spawn-fcgi. Deze how-to gaat uit van Ubuntu en gaat alleen in op het installeren van OTRS voor wat betreft de webserver configuratie.

Installatie

  • Software:

    We maken naast wat programma’s die wel in Ubuntu zitten ook gebruik van multiwatch. Daar is wel een apt-repository voor beschikbaar. Voeg die als volgt toe aan je systeem:

    root@otrs:~# wget -O /etc/apt/sources.list.d/multiwatch.list http://www.tuxis.nl/uploads/howtos/otrs-fcgi/multiwatch.list
    root@otrs:~# apt-key adv --keyserver keys.gnupg.net --recv-keys 80121CD2479689D8
    root@otrs:~# apt-get update

    Installeer nu alle software:

    root@otrs:~# apt-get install mysql-server nginx spawn-fcgi libnet-dns-perl libio-socket-ssl-perl libnet-ldap-perl libgd-text-perl libgd-graph-perl libpdf-api2-perl libsoap-lite-perl libuser libcgi-fast-perl multiwatch
  • OTRS:
    • Maak een nieuwe gebruiker voor OTRS aan:
      root@otrs:~# adduser otrs --disabled-login
      Adding user `otrs' ...
      Adding new group `otrs' (1001) ...
      Adding new user `otrs' (1001) with group `otrs' ...
      Creating home directory `/home/otrs' ...
      Copying files from `/etc/skel' ...
      Changing the user information for otrs
      Enter the new value, or press ENTER for the default
              Full Name []: OTRS Webuser
              Room Number []: 
              Work Phone []: 
              Home Phone []: 
              Other []: 
      Is the information correct? [Y/n] y
      
    • Zorg nu dat je de nieuwe gebruiker wordt en download OTRS en pak het uit. Maak een symlink met de naam ‘otrs’, zodat je bij upgrades niet allemaal zaken hoeft te wijzigen. Zorg ook dat Kernel/Config.pm bestaat, en zorg dat het path naar OTRS daar juist staat.
      root@otrs:~# su - otrs
      otrs@otrs:~$ wget http://ftp.otrs.org/pub/otrs/otrs-2.4.7.tar.bz2
      otrs@otrs:~$ tar xjvf otrs-2.4.7.tar.bz2
      otrs@otrs:~$ ln -s otrs-2.4.7 otrs
      otrs@otrs:~$ mv otrs/Kernel/Config.pm.dist otrs/Kernel/Config.pm
      
    • Edit otrs/Kernel/Config.pm en zet het path juist, in dit geval “/home/otrs/otrs/”

Configuratie

Spawn-fcgi wordt niet per request gestart. Het doel is namelijk performance, en het iedere keer opnieuw starten van ‘index.pl’ is niet efficient. Dus moeten we van tevoren spawn-fcgi alle benodigde processen laten starten.
Je kunt daarvoor een eigen script maken maar je kunt ook dit script gebruiken. Het zorgt dat voor de gebruiker(s) die je opgeeft netjes de Nginx- en de Fcgi-setup gedaan wordt. Het gaat uit van Upstart van Ubuntu dus als je op een ander operatingsystem zit kan het niet zo goed werken..

Draai nu het script voor de gebruiker die je hebt aangemaakt. Het kan zijn dat het vraag om de hostname als wie je wilt dat de vhost draait:

root@otrs:~# ./ngfcgiotrs otrs
Created upstart config for customer.pl
Created upstart config for index.pl
Created upstart config for installer.pl
Created upstart config for public.pl
Starting service: customer.pl ... index.pl ... installer.pl ... public.pl ... Create vhost-config for otrs.tuxis.net

Er zijn nu voor iedere file in fcgi-bin upstart jobs aangemaakt. Dat houdt in dat deze altijd blijven draaien, ongeacht of de webserver draait. Als een proces crasht, zal een nieuw proces in de plaats gestart worden. Je kunt de files terugvinden in:

  • /etc/init/otrs/otrs/index.pl.conf
  • /etc/init/otrs/otrs/installer.pl.conf
  • /etc/init/otrs/otrs/customer.pl.conf
  • /etc/init/otrs/otrs/public.conf
  • /etc/nginx/sites-available/<vhost-naam>

Nu is het alleen nog een kwestie van de vhost in nginx aanzetten, en OTRS kan geinstalleerd worden.

root@otrs:~# cd /etc/nginx/sites-enabled/
root@otrs:/etc/nginx/sites-enabled# ln -s ../sites-available/otrs.tuxis.net 
root@otrs:/etc/nginx/sites-enabled# /etc/init.d/nginx restart
Restarting nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
configuration file /etc/nginx/nginx.conf test is successful
nginx.

Na de installatie draait OTRS volledig. Als het nodig is om de fcgi-services te stoppen of te starten, kun je dat doen met:

root@otrs:~# stop otrs/$username/index.pl
root@otrs:~# start otrs/$username/index.pl

Waar $username uiteraard de gebruiker is van wie je de service wilt herstarten.

installer.pl heeft een aangepaste versie van het init-script, waardoor het niet automatisch zal starten na de installatie. Als je de installatie nog eens nodig hebt of je wilt een upgrade doen, dan kun je de installer weer beschikbaar maken door het volgende te typen:

root@otrs:~# start otrs/$username/installer.pl