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