Wissen

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Sie befinden sich hier: Start » openqrm
Zuletzt angesehen: • samba • erlang • syslog-ng • elive • openqrm
openqrm

Inhaltsverzeichnis

openQRM

OpenQRM ist eine Data-Center Management Plattform, die auch als Cluster Manager eingesetzt werden kann. Um ein modernes Data-Center effektiv zu verwalten benötigt man eine robuste und flexible Management Plattform die alle Aspekte der IT-Infrastruktur berücksichtigt und Administration mittels einer zentralen Management Console erlaubt. Mithilfe der modularen Architektur erlaubt openQRM Anpassungen an beliebige vorhandene Umgebungen und konsolidiert Monitoring und Administration sowohl der physikalischen Systeme als auch der virtuellen Maschinen.

https://sourceforge.net/projects/openqrm/develop

wissenswertes

Namenskonventionen

  1. um Fehler in PHP-Dateien von openQRM zu suchen, muss "export RUN_IN_BACKGROUND=true" gesetzt werden;
  2. openQRM / Base / Components / Storage: es dürfen im Namen keine Bindestriche verwendet werden;
  3. openQRM / Base / Components / Images: es dürfen im Namen keine Bindestriche verwendet werden;
  4. openQRM / Base / Appliances: es dürfen im Namen keine Unterstriche verwendet werden;

DropBear Schlüsselpaar

Dieses Schlüsselpaar wird bei der Installation generiert bzw. beim Update neu generiert!

privater Schlüssel

/usr/share/openqrm/etc/dropbear/dropbear_rsa_host_key

öffentlicher Schlüssel

Damit openQRM Befehle auf der eigenen Maschine absetzen kann, muss der öffentlichen DropBear-Schlüssel auch in der /root/.ssh/authorized_keys liegen: 

cat /usr/share/openqrm/web/boot-service/openqrm-server-public-rsa-key >> /root/.ssh/authorized_keys

die Schlüssel müssen im Cluster-Verbund gleich sein

betreibt man aus Sicherheitsgründen zwei openQRM-Rechner, dessen Aufgaben bei einem Ausfalopenqrm02:l vom jeweils anderen übernommen werden, dann müssen diese Schlüssel identisch sein: 

root@openqrm01:~# scp /usr/share/openqrm/etc/dropbear/dropbear_rsa_host_key openqrm02:/usr/share/openqrm/etc/dropbear/dropbear_rsa_host_key
root@openqrm01:~# scp /usr/share/openqrm/web/boot-service/openqrm-server-public-rsa-key openqrm02:/usr/share/openqrm/web/boot-service/openqrm-server-public-rsa-key

Standardinstallation zum KVM-Host machen

Es ist gegen die openQRM-Philosophie, das ein Plugin Pakete installiert. Deswegen müssen wir das machen, bevor wir das Plugin auf der Maschine nutzen können. 

# aptitude install kvm procmail

KVM-VM

In der Datei /usr/share/openqrm/plugins/kvm-storage/sbin/openqrm-kvm-storage-monitord auf dem openQRM-Rechner, kann man sehen wie eine VM ihren Status aktiv schaltet. Es wird per HTTP das PHP-Script action/resource-monitor.php aufgerufen und ihm werden per GET die gewünschten Variablen übergeben.

Die KVM-VM's bekommen eine Resourcen-Konfigurationsdatei beim hochfahren: /var/openqrm/openqrm-resource.conf

In der alle Werte aus der MySQL-DB zur VM drin stehen.

Die nötigen Zugangsdaten zur openQRM-DB stehen in der Datei /usr/share/openqrm/etc/openqrm-server.conf, diese kann man in Scripte einfach importieren. Dann kann man im Script z.B. so die IP-Adresse der VM mit der resource_id=10 ermitteln: 

#!/bin/sh

. /usr/share/openqrm/etc/openqrm-server.conf

echo "SELECT resource_ip FROM resource_info WHERE resource_id='10' LIMIT 1;" | mysql -t -h ${OPENQRM_DATABASE_SERVER} -u${OPENQRM_DATABASE_USER} -p${OPENQRM_DATABASE_PASSWORD} ${OPENQRM_DATABASE_NAME}

echo "SELECT appliance_id,resource_id FROM appliance_info,resource_info WHERE appliance_resources=resource_id AND resource_id="10" LIMIT 10;" | mysql -t -h ${OPENQRM_DATABASE_SERVER} -u${OPENQRM_DATABASE_USER} -p${OPENQRM_DATABASE_PASSWORD} ${OPENQRM_DATABASE_NAME}

dropbear/dbclient

/usr/share/openqrm/bin/dbclient -K 10 -y -i /usr/share/openqrm/etc/dropbear/dropbear_rsa_host_key -p 1667 root@[VM-IP] 'ls -la;uptime;hostname'

vBlade

/usr/share/openqrm/plugins/aoe-storage/include/openqrm-plugin-aoe-storage-functions:VBLADECONF=/etc/vblade.conf
/usr/share/openqrm/plugins/sanboot-storage/include/openqrm-plugin-sanboot-storage-functions:VBLADECONF=/etc/vblade.conf

openQRM-Resource auf lokales booten umstellen

web/base/class/resource.class.php:// resource_localboot = 0 -> netboot / 1 -> localboot
web/base/class/resource.class.php:function set_localboot($resource_id, $resource_localboot) {
web/base/class/resource.class.php:    $rs = $db->Execute("update $RESOURCE_INFO_TABLE set resource_localboot=$resource_localboot where resource_id=$resource_id");

Standard-Limit in den Listen-Ansichten

Voreinstellung ist "20": 

vi /usr/share/openqrm/web/base/class/htmlobject.table.class.php
...
var $limit = 50;
...

Das kann man dann nach eigenen Vorstellungen verändern.

Bootvorgang der VMs beeinflussen

notwendige Änderungen für Ubuntu 10.04

vi /usr/src/openqrm/trunk/src/etc/templates/openqrm-linuxrc
# diff /usr/src/openqrm/trunk/src/etc/templates/openqrm-linuxrc /usr/share/openqrm/etc/templates/openqrm-linuxrc
127,129c127,130
<     echo "none       /proc  proc     defaults          0 0" >> $IMAGE_FSTAB
<     echo "none       /dev/shm     tmpfs    defaults    0 0" >> $IMAGE_FSTAB
<     echo "/dev/fd0     /mnt/floppy  auto     noauto,owner,kudzu 0 0" >> $IMAGE_FSTAB
---
>     echo "none       /proc        proc     defaults           0 0" >> $IMAGE_FSTAB
>     echo "none       /dev/shm     tmpfs    defaults           0 0" >> $IMAGE_FSTAB
>     echo "none       /dev         tmpfs    rw                 0 0" >> $IMAGE_FSTAB
>     echo "/dev/fd0   /mnt/floppy  auto     noauto,owner,kudzu 0 0" >> $IMAGE_FSTAB
231a233,234
> # load usb drivers for keybord an mouse
> modprobe hid 2>/mplog
232a236
> #
416a421,428
>         hostname $appliance_name
>         # suchen und ersetzen
>         sed -i "s#127\.0\.1\.1.*##g" /mnt/etc/hosts
>         echo "127.0.1.1 $appliance_name.oqrm.victorvox.net $appliance_name" >> /mnt/etc/hosts
>         echo "$appliance_name.oqrm.victorvox.net" > /mnt/etc/mailname
>         echo "$appliance_name" > /mnt/etc/hostname
> 
> 
438a451,456
>     # disable plymouth
>     if [ -e /mnt/etc/init/plymouth-splash.conf ]; then
>             echo "Deactivate plymouth"
>             mv /mnt/etc/init/plymouth-splash.conf /mnt/etc/init/plymouth-splash.conf.disabled
>     fi

ein weiteres LV auf dem DRBD einrichten

Erstmal legen wir hier ein normales LV an und mounten es: 

# lvcreate -L 50M -n binary data
# mkfs -t jfs -L binary /dev/mapper/data-binary
# mkdir /opt/bin
# mount LABEL=binary /opt/bin

Das kritische ist jetzt, da es sich nicht um ein selbständiges Standard-Gerät handelt, dass dieses Volumen nicht per /etc/fstab sondern per Heartbeat gemountet werden muß!

Dazu müssen die nötigen Einträge in der folgenden Art und Weise gemacht werden: 

# vi /etc/ha.d/haresources
....
fsck_jfs::/dev/data/binary \
....
Filesystem::/dev/data/binary::/opt/bin::jfs \
....

Jetzt muß diese CFG-Datei noch auf den anderen DRBD-Cluster-Knoten kopiert werden: 

# scp /etc/ha.d/haresources root@10.10.2.221:/etc/ha.d/haresources

MEHFACH vergebene Ressourcen ermitteln

Leider ist es möglich, dass man in openQRM eine VM in mehreren Appliances einbindet. Um das zu verhindern, habe ich dieses Script geschrieben: 

#!/bin/bash

. /usr/share/openqrm/etc/openqrm-server.conf

echo "SELECT appliance_id, appliance_name, appliance_imageid, appliance_resources, appliance_state, appliance_comment FROM appliance_info ORDER BY appliance_resources;" | mysql -t -u${OPENQRM_DATABASE_USER} -p${OPENQRM_DATABASE_PASSWORD} openqrm

echo "MEHFACH vergebene Ressourcen:"
echo "SELECT appliance_resources FROM appliance_info ORDER BY appliance_resources;" | mysql -N -u${OPENQRM_DATABASE_USER} -p${OPENQRM_DATABASE_PASSWORD} openqrm | uniq -d
echo

FREIE Ressourcen ermitteln

. /usr/share/openqrm/etc/openqrm-server.conf

echo "FREIE Ressourcen:"
echo "SELECT resource_id, resource_hostname, resource_ip, appliance_name, resource_vncport, resource_mac, resource_state FROM resource_info, appliance_info WHERE resource_id NOT IN (SELECT appliance_resources FROM appliance_info) AND resource_vhostid=appliance_resources ORDER BY resource_id;" | mysql -t -u${OPENQRM_DATABASE_USER} -p${OPENQRM_DATABASE_PASSWORD} openqrm

Cloud-Portal

  1. URL zum Cloud-Portal: http://<openQRM-Server>/cloud-portal
  2. Folder "Login" anklicken.
  3. einloggen (Logindaten werden in einer automatischen Mail (nach anlegen des Users) zugestellt.)
  4. Folder "Cloud Request" anklicken.
  5. Laufzeit der Cloud festlegen:
    • "Start time"
    • "Stop time"
  6. Rechts unten auf "Create" klicken.
  7. Jetzt dauert es 2-5 Minuten, dann ist die Cloud hochgefahren und erreichbar.
  8. Folder "Cloud Appliances" anklicken.
  9. Hier kann man seine Clouds sehen. In der Spalte "Name" stehen die Hostnamen, die IP ändert sich bei fast jedem Neustart der Cloud, da sie von openQRM automatisch vergeben wird.
  10. Es sollte ein sprechender "Comment" vergeben werden, damit die Cloud bei den Admins auch den Respeckt bekommt, den sie verdient und nicht mal einer "Aufräumaktion" zum Opfer fällt.
  11. Auf der Cloud einloggen und arbeiten. Evtl. sind bei individuellen Bedürfnissen auch noch Packete nachzuinstallieren.
  12. Der SVN Checkout:
    • svn –username «username» –password «password» co "«Quelle»" "«Ziel»"
# svn --username fritz --password geheim co "http://svn/pfad/zum/repository/tags/release_20100305/" "svn_release_20100305"

Probleme

iSCSI steigt aus

Im Log sind dann folgende Einträge zu finden: 

Apr  6 07:43:36 iqserv02 kernel: [3095381.546222] device-mapper: snapshots: Invalidating snapshot: Unable to allocate exception.
Apr  6 07:43:36 iqserv02 apache2: openQRM resource-monitor: (update_info) Processing statistics from resource 23
Apr  6 07:43:36 iqserv02 kernel: [3095381.550077] printk: 98 messages suppressed.
Apr  6 07:43:36 iqserv02 kernel: [3095381.550082] Buffer I/O error on device dm-55, logical block 2006532
Apr  6 07:43:36 iqserv02 kernel: [3095381.550114] lost page write due to I/O error on dm-55
Apr  6 07:43:36 iqserv02 kernel: [3095381.550126] iscsi_trgt: fileio_sync(92) I/O error: syncing pages failed: -5
Apr  6 07:43:36 iqserv02 kernel: [3095381.550168] Buffer I/O error on device dm-55, logical block 2004634
Apr  6 07:43:36 iqserv02 kernel: [3095381.550198] lost page write due to I/O error on dm-55
Apr  6 07:43:36 iqserv02 kernel: [3095381.550202] iscsi_trgt: fileio_sync(92) I/O error: syncing pages failed: -5
Apr  6 07:43:36 iqserv02 apache2: openQRM resource-monitor: (update_info) Processing statistics from resource 7
Apr  6 07:43:36 iqserv02 apache2: openQRM resource-monitor: (update_info) Processing statistics from resource 12
Apr  6 07:43:36 iqserv02 kernel: [3095381.569742] Buffer I/O error on device dm-55, logical block 2006532
Apr  6 07:43:36 iqserv02 kernel: [3095381.569777] lost page write due to I/O error on dm-55
Apr  6 07:43:36 iqserv02 kernel: [3095381.569781] iscsi_trgt: fileio_sync(92) I/O error: syncing pages failed: -5
Apr  6 07:43:36 iqserv02 kernel: [3095381.570168] Buffer I/O error on device dm-55, logical block 2004634
Apr  6 07:43:36 iqserv02 kernel: [3095381.570198] lost page write due to I/O error on dm-55
Apr  6 07:43:36 iqserv02 kernel: [3095381.570202] iscsi_trgt: fileio_sync(92) I/O error: syncing pages failed: -5
Apr  6 07:43:36 iqserv02 kernel: [3095381.571850] Buffer I/O error on device dm-55, logical block 2006532
Apr  6 07:43:36 iqserv02 kernel: [3095381.571878] lost page write due to I/O error on dm-55
Apr  6 07:43:36 iqserv02 kernel: [3095381.571880] iscsi_trgt: fileio_sync(92) I/O error: syncing pages failed: -5
Apr  6 07:43:36 iqserv02 kernel: [3095381.572390] Buffer I/O error on device dm-55, logical block 2004634
Apr  6 07:43:36 iqserv02 kernel: [3095381.572432] lost page write due to I/O error on dm-55
Apr  6 07:43:36 iqserv02 kernel: [3095381.572435] iscsi_trgt: fileio_sync(92) I/O error: syncing pages failed: -5
Apr  6 07:43:36 iqserv02 kernel: [3095381.572904] Buffer I/O error on device dm-55, logical block 2006532
Apr  6 07:43:36 iqserv02 kernel: [3095381.572940] lost page write due to I/O error on dm-55
Apr  6 07:43:36 iqserv02 kernel: [3095381.572947] iscsi_trgt: fileio_sync(92) I/O error: syncing pages failed: -5
Apr  6 07:43:36 iqserv02 kernel: [3095381.573222] Buffer I/O error on device dm-55, logical block 2004634
Apr  6 07:43:36 iqserv02 kernel: [3095381.573251] lost page write due to I/O error on dm-55
Apr  6 07:43:36 iqserv02 kernel: [3095381.573254] iscsi_trgt: fileio_sync(92) I/O error: syncing pages failed: -5
Apr  6 07:43:36 iqserv02 kernel: [3095381.573637] Buffer I/O error on device dm-55, logical block 2006532
Apr  6 07:43:36 iqserv02 kernel: [3095381.573666] lost page write due to I/O error on dm-55
Apr  6 07:43:36 iqserv02 kernel: [3095381.573669] iscsi_trgt: fileio_sync(92) I/O error: syncing pages failed: -5
Apr  6 07:43:36 iqserv02 kernel: [3095381.573993] Buffer I/O error on device dm-55, logical block 2004634
Apr  6 07:43:36 iqserv02 kernel: [3095381.574022] lost page write due to I/O error on dm-55
Apr  6 07:43:36 iqserv02 kernel: [3095381.574025] iscsi_trgt: fileio_sync(92) I/O error: syncing pages failed: -5
Apr  6 07:43:36 iqserv02 kernel: [3095381.574472] iscsi_trgt: fileio_sync(92) I/O error: syncing pages failed: -5
Apr  6 07:43:36 iqserv02 kernel: [3095381.574845] iscsi_trgt: fileio_sync(92) I/O error: syncing pages failed: -5
Apr  6 07:43:36 iqserv02 apache2: openQRM resource-monitor: (update_info) Processing statistics from resource 9
Apr  6 07:43:36 iqserv02 apache2: openQRM resource-monitor: (update_info) Processing statistics from resource 26

Bug-Report

Hier steht wie man das Problem reproduzieren kann: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/177828/comments/7

Siehe ganzen Report: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/177828

Diagnose

Hier wird die Diagnose gestellt, dass der Snapshot zu klein gewählt wurde: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/177828/comments/12

Diagnose wird bestätigt

Hier wird bestätigt, dass das Problem ausbleibt, wenn der snapshot-Space größer gewählt wird: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/177828/comments/13

Füllstand des SnapShots

Damit soetwas nicht wieder passiert, sollte man den Füllstand im Auge behalten: 

# lvs
  LV                   VG     Attr   LSize    Origin               Snap%  Move Log Copy%
  4.cloud_5_1_         data   Swi-Io    7,95G golden_ubuntu_web    100,00
  4.cloud_7_1_         data   swi-ao    7,81G golden_ubuntu_web     21,63
  VirtualMachines2     data   -wi-ao  535,00G
  clone1_suse64_iscsi  data   swi-ao    1,95G mini_suse64_iscsi     90,75
  clone2_suse64_iscsi  data   swi-ao    1,95G mini_suse64_iscsi     57,33
  fedora_nfs           data   -wi-ao 1000,00M
  golden_ubuntu_web    data   owi-ao    7,81G
  iddc03_sanboot       data   -wi-ao   19,53G
  lamp_suse64_nfs      data   -wi-ao    1,95G
  lamp_ubuntu64_nfs    data   -wi-ao    1,95G
# lvs /dev/data/4.cloud_7_1_
  LV           VG   Attr   LSize Origin            Snap%  Move Log Copy% 
  4.cloud_7_1_ data swi-ao 7,81G golden_ubuntu_web  21,64                
# lvs -o snap_percent /dev/data/4.cloud_7_1_
  Snap% 
   21,64
# lvs -o lv_name,lv_size,origin,snap_percent
  LV                   LSize    Origin               Snap%
  4.cloud_5_1_            7,95G golden_ubuntu_web    100,00
  4.cloud_7_1_            7,81G golden_ubuntu_web     24,48
  VirtualMachines2      535,00G
  clone1_suse64_iscsi     1,95G mini_suse64_iscsi     90,75
  clone2_suse64_iscsi     1,95G mini_suse64_iscsi     57,33
  fedora_nfs           1000,00M
  golden_ubuntu_web       7,81G
  iddc03_sanboot         19,53G
  lamp_suse64_nfs         1,95G
  lamp_ubuntu64_nfs       1,95G
  mini_suse64_iscsi       3,91G

In diesem Beispiel ist 4.cloud_5_1_ schon gestorben, das LV kann man nur noch löschen und neu anlegen!

Aber bei clone1_suse64_iscsi ist es noch nicht zu spät, das kann noch vergrößert werden. 

# lvextend -L 4000M data/clone1_suse64_iscsi
  Extending logical volume clone1_suse64_iscsi to 3,91 GB
  Logical volume clone1_suse64_iscsi successfully resized
# lvs -o lv_name,lv_size,origin,snap_percent data/clone1_suse64_iscsi
  LV                  LSize Origin            Snap% 
  clone1_suse64_iscsi 3,91G mini_suse64_iscsi  45,38
/home/http/wiki/data/pages/openqrm.txt · Zuletzt geändert: von 127.0.0.1