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.
Bindestriche verwendet werden;Bindestriche verwendet werden;Unterstriche verwendet werden;Dieses Schlüsselpaar wird bei der Installation generiert bzw. beim Update neu generiert!
/usr/share/openqrm/etc/dropbear/dropbear_rsa_host_key
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
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
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
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}
/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'
/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
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");
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.
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
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
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
. /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
# svn --username fritz --password geheim co "http://svn/pfad/zum/repository/tags/release_20100305/" "svn_release_20100305"
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
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
Hier wird die Diagnose gestellt, dass der Snapshot zu klein gewählt wurde: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/177828/comments/12
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
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