Netzwerk-Bridge ohne IP-Adresse mit Debian einrichten

Es gibt Xen-Setups wo es notwendig ist eine Network-Bridge ohne IP-Adresse einzurichten. Statt mit den Xen-eigenen Scripten (network-script more-network-bridges) zu arbeiten, kann man die Bridge mit Debian Boardmitteln konfigurieren. Dafür müssen lediglich die bridge-utils installiert sein. Funktioniert mit Lenny und Squeeze.

Setup eth2 als Bridge: /etc/network/interfaces

auto br2
iface br2 inet manual
      bridge_maxwait 5
      bridge_ports eth2

Xen-Domain „myxen“, Konfiguration in /etc/xen/<myxenconfig>:

[...]
vif = [ 'bridge=br2' ]
[..]

Die IP-Adresse wird dann direkt in der Xen-Domain konfiguriert.

Debian Etch 4.0 mit NFSv3 ohne ACLs

Leider unterstützt Debian Etch 4.0 im Gegensatz zu Ubuntu, RedHat und SuSE die Mount-Option „noacl“ in Verbindung mit NFS-Mounts nicht. Der Verzicht auf ACLs ist aber gerade in Verbindung mit Solaris und ZFS im Backend hilfreich, denn dann muss auf den Linux-Clients zwangsläufig NFSv3 ohne ACLs oder gleich NFSv4 genutzt werden, um nicht in Probleme zu laufen (mehr Infos zum Thema: Solaris ZFS+NFSv3 Server und Debian Etch 4.0 als NFS-Client)

Pakete zum Compilieren

Um sich aus den Sourcen der nfs-utils einen geeigneten „Mount-Client“ zu bauen, sind einige Development-Libraries notwendig:

$ apt-get install libwrap0-dev libevent0-dev libevent-dev libnfsidmap libnfsidmap-dev pkg-config librpcsecgss-dev librpcsecgss-dev librpcsecgss3 libgssapi-dev libgssapi2

Compilieren

Es reicht aus nach dem Konfigurieren make im Unterverzeichnis ./utils auszuführen:

$ wget http://www.sfr-fresh.com/fresh/linux/misc/nfs-utils-1.1.3.tar.gz
$ tar -xzf nfs-utils-1.1.3.tar.gz
$ cd ./nfs-utils-1.1.3/
$ ./configure --enable-gss=no
$ cd utils
$ make
[...]

Das fertige „mount.nfs“ muss dann nur noch aus dem Ordner ./utils/mount/ nach /sbin kopiert werden.

Test

NFS-Mount in /etc/fstab eintragen:


myserver:/proj            /proj         nfs    rw,noacl,noatime 0 0

NFS-Share einbinden


$ mount /proj
$ mount
myserver:/proj on /proj type nfs (rw,noatime,noacl,addr=192.168.1.72)
[...]

Mit strace sieht man, dass „mount“ automatisch prüft, ob es das Binary „/sbin/mount.nfs“ gibt. Sofern es vorhanden ist, wird es auch benutzt.

Solaris ZFS+NFSv3 Server und Debian Etch 4.0 als NFS-Client

Wenn ein Solaris ZFS-Filesystem per NFSv3 auf einen Debian Etch Client exportiert wird, gibt es Probleme beim Kopieren von Dateien und Verzeichnissen mit „cp -p“. Eine Kopie wird zwar erzeugt, aber mit der Fehlermeldung „cp: preserving permissions … Operation not supported“ quittiert. Beispiel:


keller@nfs-client:/projekte/ake$ cp -p alex2 alex7
cp: preserving permissions for alex7: Die Operation wird nicht unterstutzt
cp: preserving ACL for alex7: Die Operation wird nicht unterstutzt

Ein ziemlicher Show-Stopper, wenn man zahlreiche Debian-Clients hat und darauf angewiesen ist, dass „cp -p“ in automatischen Workflows einwandfrei funktioniert und nicht mit Fehler 1 aussteigt ;-)

Ursache

Die Diagnose ist nach etwas Suchen gefunden: NFSv3 unterstützt die ACLs von ZFS nicht. Das ist eigentlich alles…

Lösung

Es gibt mehrere Möglichkeiten mit dem Problem umzugehen:

  • von NFSv3 auf NFSv4 umsteigen, denn NFSv4 unterstuetzt die ZFS ACLs.
  • Debian 4.0 durch Ubuntu 8.04 ersetzen und die Mountoption „noacl“ mit NFSv3 benutzen. Keine Ahnung woher die Option bei Ubuntu genau kommt, aber bei Debian Etch gibts diese nicht (evtl. ältere mount utilities…)
  • theoretisch lassen sich ZFS-ACLs ausschalten (zfs set aclinherit=discard und
    zfs set aclmode=discard). Praktisch war das Ergebnis aber unverändert.
  • ZFS durch UFS ersetzen. Ja klar – sonst noch was ;-)
  • cp, mv usw. patchen ;-)

Links

Linux multipath-tools mit Sun StorageTek 6540

Linux-Systeme an einer Sun StorageTek 6540 zu betreiben ist gar nicht so einfach. Für Redhat und Suse gibt es von Sun zwar RDAC-Treiber, aber eine funktionierende Konfiguration für die multipath-tools habe ich nirgends gefunden.

Die 6540-Storage sieht stark nach dem Nachfolger der StorageTek FlexLine FLX380 aus. Unter der Haube steckt wohl das LSI/Engenio 6998 System (gibts z.B. auch von IBM als DS4800).

Hardware

  • Sun StorageTek 6540 (Engenio/LSI)
  • Sun Fire X4150 mit 32 GByte RAM und 2xQuadCore Xeon E5440
  • 2x Sun/Qlogic 2460 4 GBit HBAs

Software

  • Ubuntu LTS 8.04.1 AMD64
  • multipath-tools 0.4.8

Multipath-tools

Es werden unbedingt die multipath-tools in der Version 0.4.8 benötigt, da hier der Path-Checker rdac (mpath_prio_rdac) enthalten ist (früher mal mpath_prio_tur).
Die Storage selbst meldest sich als „STK FLEXLINE 380“.

Konfiguration /etc/multipath.conf (Beispiel)


defaults {
      multipath_tool                  "/sbin/multipath -v0"
      udev_dir                        /dev
      polling_interval                5
      default_selector                "round-robin 0"
      default_path_grouping_policy    failover
      default_features                "1 queue_if_no_path"
      default_getuid_callout     "/lib/udev/scsi_id -g -u -s /block/%n"
      rr_weight                       priorities
      failback                        immediate
}
blacklist {
   devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
   devnode "^hd[a-z][[0-9]*]"
   devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]"
   devnode "^sda"  # local disk
}
multipaths {
     multipath {
        alias           stk-test-lun
        wwid            3600a0b80004725e800000570xxxxxxxxx
        path_selector   "round-robin 0"
        failback        immediate
    }
}
devices {
    device {
      vendor                  "STK"
      product                 "FLEXLINE 380"
      product_blacklist       "Universal Xport"
      path_grouping_policy    group_by_prio
      prio_callout            "/sbin/mpath_prio_rdac /dev/%n"
      path_checker            rdac
      hardware_handler        "1 rdac"
    }
}

Test

Da der Server 2 Single-Port-HBAs hat und zudem an 2 FC-Switches an der Storage angebunden ist, gibt es vier Pfade, 2 über HBA-A (sdc/sdt) und 2 HBA-B (sdbs/sdcj).

# multipath -ll
stk-test-lun (3600a0b80004725e800000570xxxxxxxxx) dm-1 STK     ,FLEXLINE 380
[size=200G][features=1 queue_if_no_path][hwhandler=1 rdac]
\_ round-robin 0 [prio=6][active]
 \_ 1:0:0:1  sdc  8:32    [active][ready]
 \_ 1:0:1:1  sdt  65:48   [active][ready]
\_ round-robin 0 [prio=0][enabled]
 \_ 2:0:0:1  sdbs 68:96   [active][ghost]
 \_ 2:0:1:1  sdcj 69:112  [active][ghost]

Links

Sun Common Array Manager CLI unter Debian

Der Sun Comman Array Manager ist zwar eine JAVA-Anwendung – der Installer funktioniert aber nur unter Solaris 9/10, Windows, Redhat und Suse Linux.

Aber das Command Line Interfaces (sscs) lässt sich auch mit Debian oder Ubuntu Linux installieren und nutzen.

Download CAM als TAR-Archive

StorageTek Common Array Manager Software 6.1.1 Revenue Release:
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_SMI-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=SSTKCAM-6.1.1-OTH-G-F@CDS-CDS_SMI

Archive entpacken

$ tar -xzf host_sw_linux_6.1.1.10.tar.gz

RPM-Paket in ein TGZ-Archive umwandeln

Archive von RPM in TGZ umwandeln und den Inhalt nach /opt/sun/cam kopieren.

$ cd ./HostSoftwareCD_6.1.1.10/components/em_cli
$ alien -t sun-cam-cli-6.1.1-10.i386.rpm
$ tar -xzf sun-cam-cli-6.1.1.tgz
$ cp -rp opt /

Korn-Shell und Ausführungsrechte

Korn-Shell ksh installieren und Scripte sscs/pclient ausführbar machen

$ apt-get install ksh
$ cd /opt/sun/cam/se6x20/cli/bin
$ chmod +x sscs pclient

Testen

$ export PATH=$PATH:/usr/local/java/bin
$ cd /opt/sun/cam/se6x20/cli/bin
$ ./sscs
$ You are not currently logged in. To log in, type:
$ sscs login -h|--hostname  [-s|--system-type ] [-t|--http] [-f|--force] [-u|--username ]

Links

Xen Live Migration ohne Cluster-Filesystem oder NFS

Im Xen-Domains im laufenden Betrieb auf einen anderen Host umzuziehen, ist eigentlich ein geshartes Filesystem notwendig (z.B. NFS, OCFS2 oder GFS). Mit Hilfe von DRBD kann man zumindest in einem 2 Cluster-Knoten darauf verzichten. Schicke Lösung, die sehr gut funktioniert. Mehr Infos siehe Link unten…

Systemvoraussetzungen

  • DRBD ab Version 8.0.6
  • Heartbeat ab Version 2.1.3 (aktuellstes Xen-OCF Script)
  • Xen 3.2 (evtl. reicht auch Version 3.0.3)

Links

Ubuntu 8.04 LTS mit DRBD und Xen – Pleiten, Pech und Pannen

Mein Plan war es mit dem neuen Ubuntu 8.04 LTS einen HA-Cluster auf Basis von Xen 3.2, DRBD v8 und Heartbeat 2.1.3 aufzusetzen. Theoretisch ein toller Plan, denn Ubuntu bringt alle notwendigen Pakete mit. Praktisch ist dieses Release aber ein einziger Blindgänger.

Hier die Einzelkritik:

Netzwerk in Xen-Domains

Der Xen-Kernel 2.6.24-16-xen hat den unschönen Bug, dass innerhalb der Xen-Domains kein Netz funktioniert:

DRBD mit Kernel 2.6.24

Ausserdem ist im Kernel 2.6.24 ein Bug drin, der in Verbindung mit DRBD 0.8.11 dafür sorgt, dass das Log voll mit Fehlermeldungen „drbd0: local disk flush failed with status -5“ ist.

Entweder man compiliert sich die neuste DRBD-Version 0.8.12 und benutzt die Optionen „no-diskflushes“ und „no-md-flushes“ oder baut sich gleich einen eigenen Kernel (2.6.25)

Shell

Ubuntu hat die Default-Shell auf /bin/dash umgestellt. Dumm nur, dass viele Heartbeat OCF-Skripte damit nicht mehr korrekt funktionieren. Jetzt kann man entweder in die Skripte „#!/bin/bash“ schreiben oder gleich /bin/sh mit /bin/bash verlinken.

Kernel Ooops

Der Xen-Kernel von Debian und Ubuntu scheint schon länger ein Problem auf SMP-Systemen zu haben.

Fazit

Wenn man mal einen Blick in den Bugtracker von Ubuntu vagt und die unzähligen weiteren Probleme sieht, dann muss man zugeben, dass das Release 8.04 ein schlechter Witz ist. Am 3.7.2008 soll der erste „ServicePack“ erscheinen. Kann ja nur besser werden…

Ubuntu 6.06.1 LTS an EMC Clariion CX3-40

Ubuntu 6.06.1 LTS an einer EMC Clariion CX3-40 zu betreiben ist eigentlich ganz einfach. Warum EMC Powerpath, wenn es auch die multipath-tools gibt (*ist natürlich nicht supported). Hier die notwendigen Configs:

Multipath Configuration /etc/multipath.conf

In der Blacklist sind alle Devicenamen aufgelistet, die von multipath nicht verwendet werden dürfen, z.B. die internen Systemdisks (/dev/sda … /dev/sdf):


blacklist {
        devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
        devnode "^hd[a-z][[0-9]*]"
        devnode "^sd[a-g][[0-9]*]"
        devnode "^hda[0-9]*"
        devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]"
        devnode "sd[a-f]$"   // internal disks
}

Die CX3-40 meldet sich unter der Bezeichnung „DGC“:

devices {
   device {
      vendor                  "DGC"
      product                 "RAID 5"
      path_grouping_policy    group_by_prio
      prio_callout            "/sbin/mpath_prio_emc /dev/%n"
      getuid_callout          "/lib/udev/scsi_id -g -s /block/%n"
      path_checker            emc_clariion
      features                "1 queue_if_no_path"
      no_path_retry           300
      hardware_handler        "1 emc"
      failback                immediate
      product_blacklist       "LUNZ"
   }
}

multipaths {
    # Storage 1, LUN 21
    multipath {
         wwid 3600601642d93190004d1fe31xxxxxxxxx
         alias                   rr1-lun21
         path_grouping_policy    failover
         failback                immediate
    }
    # Storage 3, LUN 22
    multipath {
         wwid 3600601642b9319004da05984xxxxxxxx
         alias                   rr3-lun22
         path_grouping_policy    failover
         failback                immediate
    }
}

Links