Ihsan Dogan's Solaris Blog

Kürzlich habe ich einen Pool mit Solaris 10 Update 3 exportiert und bei Solaris 10 Update 4 wieder importiert. zpool status meinte nach dem importieren:

root@cnd-35:~# zpool status
  pool: pool0
 state: ONLINE
status: The pool is formatted using an older on-disk format.  The pool can
        still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
        pool will no longer be accessible on older software versions.
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        pool0       ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            c1t2d0  ONLINE       0     0     0
            c1t3d0  ONLINE       0     0     0

errors: No known data errors

Der Upgrade ist schmerzlos, kann während dem Betrieb gemacht werden und einfacher gehts wohl nicht mehr:

root@cnd-35:~# zpool upgrade pool0
This system is currently running ZFS version 4.

Successfully upgraded 'pool0' from version 3 to version 4

Auf BigAdmin ist Perl Script erhältlich, mit dem man ZFS Storage Pools überwachen und überprüfen kann. In einem Fehlerfall wird dann ein Mail an root geschickt, was wie folgt aussehen kann:

zpool tank on host zhadum is status DEGRADED.

Meine Arbeitskollegen Szedi und Raphi haben mich auf folgende iostat Optionen aufmerksam gemacht, damit iostat nur die aktiven Disks anzeigt. Disks auf denen es im Moment keine I/O Operationen gibt, werden nicht angezeigt.

ihsan@enterprise:~$ iostat -xnzC 3 | grep c
                    extended device statistics
    r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
    0.5   21.1    3.6  132.4  1.1  0.7   51.5   34.1   1   4 c0
    0.5   21.2    3.6  132.5  1.2  0.8   54.0   37.5   1   4 c2
    0.0    2.6    0.2    6.6  0.0  0.0    0.3   12.7   0   1 c2t4d0
    0.1   13.2    0.5   93.6  1.2  0.7   87.3   49.5   3  11 c2t5d0
    0.1   13.2    0.5   93.7  1.1  0.6   82.3   44.9   3  10 c0t1d0
    0.0    2.4    0.2    6.5  0.0  0.0    0.4   13.1   0   1 c0t0d0
    0.2    2.8    1.5   16.1  0.0  0.1    2.7   17.4   0   2 c0t2d0
    0.2    2.7    1.4   16.2  0.0  0.1    3.2   19.1   0   2 c0t3d0
    0.2    2.8    1.5   16.1  0.0  0.1    2.6   17.1   0   2 c2t6d0
    0.2    2.7    1.4   16.2  0.0  0.1    3.1   26.7   0   3 c2t7d0

Bis an hin wurde der IP Stack einer Zone immer mit der globalen Zone geteilt, was, je nach Anwendungszweck, zu gewissen Problemen geführt hat. Beispielsweise ist es mit einem shared IP Stack das benutzen von snoop oder das betreiben eines NFS Servers innerhalb einer Zone nicht möglich. Seit Solaris 10 8/07 (Update 4) ist es nun möglich, dass eine Zone einen getrennten IP Stack hat, welcher nur von dieser Zone benutzt wird und nicht mit anderen Zonen geteilt wird.

Für einen exklusiven IP Stack muss man im Moment der Zone ein separates Interface zuweisen, welches einen GLD basierenden Treiber haben muss. Neuere Netzwerkkarten wie das bge oder die e1000g sind GLD basierend; ältere wie z.B. ce oder eri nicht. In zukünftigen Releases wird die ein Interface pro Zone Einschränkung wegfallen, da Sun im Moment an einer vNIC Implementation arbeitet.

Die Konfiguration ist denkbar einfach. Zu beachten ist nur, dass man mit zonecfg der Zone keine IP Adresse mehr zuweisen muss.

zonecfg:test0> set ip-type=exclusive
zonecfg:test0> add net
zonecfg:test0:net> set physical=e1000g1
zonecfg:test0:net> end

Beim ersten Booten der Zone wird man dann nach den gleichen Netzwerkeinstellungen gefragt wie bei einer regulären Solaris Instalaltion.

Wie man sehen kann, fühlt sich das so an, als wäre man in der globlen Zone:

# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 172.16.192.140 netmask ffffff00 broadcast 172.16.192.255
        ether 0:c:29:a3:a5:7f

Das Interface e1000g1 ist unter der Kontrolle der lokalen Zone und wird mit ifconfig nicht in der globalen Zone angezeigt. Es wird ganz normal über die /etc/hostname.e1000g1 konfiguriert. Tools wie snoop funktionieren in der lokalen Zone, es können andere Routen als in der globalen Zone gesetzt werden und man kann endlich in einer Zone einen NFS Server betreiben.

Golem berichtet, dass Sun den StarOffice 8 Server vorgestellt hat. StarOffice 8 ist ein Dokumenten-Server, welcher über ein Webinterface bzw. einem J2EE Web Service Dokumente aus unterschiedlichen Formaten in PDF konvertiert.

StarOffice bzw. OpenOffice kann man schon seit längerem headless als daemon laufen lassen. Mit dem StarOffice Server bietet Sun jetzt eine Lösung an, welche out of the box funktioniert und in andere Applikationen integriert werden kann.

Ich hatte gestern über das Project Indiana geschrieben. Ãœber einen Eintrag in Otmanix’ Blog bin ich auf den Indiana Paketmanager gestossen, welcher sehr viel versprechend aussieht.

Aus den Medien konnte man vor einiger Zeit entnehmen, dass Sun unter dem Namen Project Indiana ein weiteres OpenSolaris Projekt vorgestellt.

Bei Project Indiana geht es darum, eine OpenSolaris Distribution nach dem Vorbild der Linux Distribution zu erstellen. Sun strebt dabei an, neue Technologien in Indiana schnell verfügbar zu machen, welche dann bei einem Release, welcher alle 6 Monate stattfinden soll, der breiten Masse verfügbar gemacht werden soll.

Wie es Ian Murdock, Sun’s OS Stratege und Gründer von der Linux Distribution Debian, bei einem Vortrag erklärt, möchte Sun mit einer OpenSolaris Distribution auch die Verbreitung von Solaris fördern. Linux hat in den vergangenen Jahren immer mehr an Bedeutung gewonnen und drängt, neben Windows, auch langsam in den Enterprise Markt ein. Sun möchte dem entgegen wirken und setzt genau dort an, wo Linux stark ist. Indiana ist, einfach und böse gesagt, eine Linux Distribution auf einem Solaris Kernel. Das ganze über dem Kernel wird von einem Paket-Management verwaltet, welcher wie man es von den Linux Distributionen her kennt, schmerzlose Upgrades ermöglicht.

Sun hat in der Vergangenheit immer wieder betont, dass an Solaris selber nichts ändern wird und deshalb wird Sun hier eine 2-Tier Strategie fahren. Daran dürfte sich auch in Zukunft nichts ändern.

Ich habe Indiana in einer VMware Maschine installiert und ausprobiert. Die Installation ist schnell, einfach und schmerzlos. Obwohl es sich um eine Developer Preview handelt und einige Sachen fehlen, fühlt es sich bereits doch recht solide an.

Solaris bietet leider von Haus aus keine Möglichkeit lokale Zonen miteinander zu verbinden, ohne das man ein physisches Interfaces benutzt. Je nach den Anforderungen der Sicherheit oder dem vorhanden sein von Hardware, kann es wünschenswert sein, Zonen mit virtuellen Interfaces miteinander zu verbinden.

Der TAP Treiber emuliert ein Ethernet Interface, welches normalerweise für VPNs benutzt wird. Man kann allerdings den TAP Treiber auch zum verbinden von mehreren Zonen missbrauchen.

Nachdem man den TUN Treiber geladen hat, muss als erstes mit tunctl ein  neues Interface erzeugen und plumben:

# tunctl -t tap0
# ifconfig tap0 plumb

Das sieht dann so aus:

# ifconfig tap0
tap0: flags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
        inet 0.0.0.0 netmask 0
        ether a:0:20:b3:d0:84

Beim für das Interface benutzten Mac Adresse aus dem a:0:20 Range, handelt es sich um eine Adresse für den privaten Gebrauch, wie man es von den IP Adressen her kenn.

Mit zonecfg muss man dann nur noch das Netzwerkinterface der Zone auf tap0 legen und schon sind die Zonen mit einem virtuellen Ethernet Interface verbunden.

# zonecfg -z test0 info net
net:
        address: 192.168.123.1
        physical: tap0
# zonecfg -z test1 info net
net:
        address: 192.168.123.2
        physical: tap0

WICHTIG: Das ganze funktioniert nicht mit einem exklusiven IP Stack.

… ist in greifbare Nähe gerückt: 6421958

Die ZFS Entwickler haben bis an hin immer wieder betont, dass es sich bei ZFS um ein single Host File System handle. In der ZFS FAQ bin ich nun auf folgendes gestossen:

In the long term, we plan on investigating ZFS as a native cluster file system to allow concurrent access. This work has not yet been scoped.

Ich denke, dass auf längere Sicht wird ZFS den Platz von UFS und Solaris LVM einnehmen und das Leben von Veritas schwer machen, da Sun weitere Enterprise Features in ZFS implementieren wird. Bald dürfte es vermutlich gar keine Gründe mehr geben, warum man die komplexe, schwer verständliche und überteuerte Kombination von VxFS und VxVM einsetzen sollte.