====== 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. * {{http://www.openqrm-enterprise.com/fileadmin/DATA/Whitepapers/openQRM-documentation-24022010.pdf|offizelle Dokumentation}} * [[http://www.openqrm.com/?q=node/33|Online Doku]] * [[openQRM - installieren]] * [[openQRM - einrichten einer KVM-VM]] * [[openQRM - Client installiert beim Start fehlende Pakete]] * [[openQRM - Client per Upstart starten]] * [[openQRM - Cloud]] * [[openQRM - Cloud/VM per Skript stoppen]] * [[openQRM - Cluster]] * [[openQRM - Grundinstallation Management]] * [[openQRM - Grundinstallation Storage]] * [[openQRM - Grundinstallation KVM-Host]] * [[openQRM - HardWare-Info's]] * [[openQRM - InitRD]] * [[openQRM - KVM]] * [[openQRM - LXC]] * [[openQRM - Maschine duplizieren]] * [[openQRM - Nagios]] * [[openQRM - Plugins]] * [[openQRM - PXE-Kernel]] * [[openQRM - Tabellen für weitere IP-Gruppen]] * [[openQRM - User einrichten]] * [[openQRM - Z-IP's]] * [[Einrichtung einer Ressource für den Boot als local-server]] * [[Änderungen gegen den Source code abgleichen und nach bedarf übernehmen]] * [[VM's laden ihre HW-Infos beim Start in die DB]] * [[MTU size abhängig von der Hostanbindung setzen]] * [[Host-Kernel mit aktiviertem vhost_net um das Gastnetzwerk zu beschleunigen]] * [[manuelles Einbinden eines AOE Volumes]] * [[openQRM - DHCPD]] * [[openQRM - DNS]] * [[openqrm-linuxrc]] [[https://sourceforge.net/projects/openqrm/develop]] ===== wissenswertes ==== ==== Namenskonventionen ==== - um Fehler in PHP-Dateien von openQRM zu suchen, muss "export RUN_IN_BACKGROUND=true" gesetzt werden; - openQRM / Base / Components / Storage: **es dürfen im Namen //keine// ''Bindestriche'' verwendet werden**; - openQRM / Base / Components / Images: **es dürfen im Namen //keine// ''Bindestriche'' verwendet werden**; - 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 ===== - URL zum Cloud-Portal: [[http:///cloud-portal]] - Folder "Login" anklicken. - //einloggen// (Logindaten werden in einer automatischen Mail (nach anlegen des Users) zugestellt.) - Folder "Cloud Request" anklicken. - Laufzeit der Cloud festlegen: * "Start time" * "Stop time" - Rechts unten auf "Create" klicken. - Jetzt dauert es 2-5 Minuten, dann ist die Cloud hochgefahren und erreichbar. - Folder "Cloud Appliances" anklicken. - 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. - 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. - Auf der Cloud einloggen und arbeiten. Evtl. sind bei individuellen Bedürfnissen auch noch Packete nachzuinstallieren. - Der SVN Checkout: * svn --username <> --password <> co "<>" "<>" # 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