X

Neuigkeiten, Best Practices, Hinweise auf Events zu Oracle Solaris auf Deutsch.

Solaris Cluster 4.4 in VirtualBox (3) - HA NFS Data Service und Failover Zones

Detlef Drewanz
Master Principal Sales Consultant

Und hier folgt der 3.Teil aus der Reihe Solaris Cluster in (Virtual)Box. Dieses Mal geht es um:

  • HA Cluster Data Service für NFS
  • Failover Native Zones

Konfigurationsbild

Nach dem Setup von Teil 2 liegt die folgende Konfiguration vor, mit der hier weitergearbeitet wird.

Cluster Data Service für NFS

Nachdem der Global Cluster in Teil 2 eingerichtet wurde, ist es jetzt an der Zeit, den nächsten Service in den Cluster zu bringen. HA NFS ist einer der oft benutzten Services im Custer für HA Filesharing. Also los ! Zunächst ein bischen Planung:

  • Der NFS Service soll im Global Cluster als Failover Service laufen.
  • Die Daten des NFS Service sollen in dem HA-Zpool HApool liegen, der aus c2t0d0 erzeugt wird.
  • Als NFS-Share soll /HApool/export dienen.
  • Der NFS-Server soll über den Logischen Hostnamen hanfs (192.168.175.165 - siehe verteilte /etc/hosts Datei aus Teil 1) erreichbar sein.
  • Als Test-NFS-Client wird der einzige andere Host srv in diesem Test-Setup verwendet, an dem als root-User geschrieben und gelesen werden soll.

Ok, soweit die Planung. Jetzt geht es an die Umsetzung:

  1. Zunächst wird der Zpool HApool auf c2t0d0 erzeugt. Auch hier wird aus Gründen der Ressourcenknapppheit und zur Vereinfachung auf Redundanz verzichtet. Vorher wird sichergestellt, daß für c2t0d0 auf beiden Cluster Nodes der Pfad identisch.
    @nodea # cldev list -v | grep c2t0d0
    d5                  nodea:/dev/rdsk/c2t0d0
    d5                  nodeb:/dev/rdsk/c2t0d0
    
    @nodea # zpool create HApool c2t0d0
    
  2. Nun sind an den beiden Cluster Knoten zwei "kosmetische Operationen" zu erledigen, damit später die Einrichtung des NFS Cluster Service funktioniert.

    1. In Solaris 11.4 enthält /etc/vfstab u.U. zu diesem Zeitpunkt nur Kommentarzeilen. Damit kommt später die Einrichtung des NFS Cluster Service nicht klar (Bug 28546356). Als Workaround kommentiert man an beiden Cluster Knoten einfach /proc aus. Diese Zeile hat hier ohnehin nur informativen Charakter.

    2. Für die spätere Registrierung des Logischen Hostnamen muß die zugehörige Netzmaske gesetzt sein. Dazu wird /etc/netmasks entsprechend ergänzt.
    # vi /etc/netmasks
         192.168.175.0   255.255.255.0
    
  3. Nun werden der NFS-Share und Konfigurationsfiles für den NFS Cluster Service eingerichtet. Die dfstab für den Cluster Service bekommt als Datei-Extension den geplanten Namen von der NFS Ressource im Cluster. In die dfstab wird eingetragen, was exportiert wird und mit welchen Rechten. Hier wird an srv=192.168.175.200 mit root-Rechten exportiert.
    @nodea # zfs create HApool/export
    @nodea # zfs create -p HApool/nfs/SUNW.nfs
    @nodea # vi /HApool/nfs/SUNW.nfs/dfstab.HAnfs-rs
                share -F nfs -o root=@192.168.175.200 /HApool/export
    
  4. Nach Abschluß der vorbereitenden Arbeiten geht es an die Registrierung der Cluster Resource Typen SUNW.nfs (der Cluster Service) und SUNW.HAStoragePlus (der wird für den HA-Zpool benötigt).
    # clrt register SUNW.nfs
    # clrt register SUNW.HAStoragePlus
    
  5. Jetzt wird der NFS Cluster Service konfiguriert. Dafür wird eine Ressource Gruppe HAnfs-rg erzeugt und der PathPrefix festgelegt, unter dem die Konfiguration für den Cluster Service abgelegt ist.
    # clrg create -p PathPrefix=/HApool/nfs HAnfs-rg
  6. Der Ressource Gruppe werden drei Cluster Ressourcen zugewiesen:
    1. Der Logische Hostname hanfs in der Ressource HAnfs-lh-rs.

    2. Der Zpool HApool in der Ressource HAnfs-hasp-rs. HAStoragePlus stellt sicher, daß dieser Zpool nur jeweils an einem Cluster Knoten importiert ist.

    3. Die eigentliche NFS Service Ressource HAnfs-rs, die von HAnfs-hasp-rs abhängig ist, kann erst erzeugt werden, wenn die Ressource Gruppe mit der HAStoragePlus Ressource online ist.
    # clrslh create -g HAnfs-rg -h hanfs HAnfs-lh-rs
    # clrs create -g HAnfs-rg -t SUNW.HAStoragePlus -p Zpools=HApool HAnfs-hasp-rs
    # clrg online -M HAnfs-rg
    # clrs create -g HAnfs-rg -t SUNW.nfs -p resource_dependencies_offline_restart=HAnfs-hasp-rs HAnfs-rs
    
  7. Fertig ! Die Überprüfung der Ressource Gruppe und der Ressourcen sieht gut aus. In diesem Fall wird der Service von dem Cluster Knoten nodeb erbracht.
    #  cluster status -t rg,rs
    === Cluster Resource Groups ===
    Group Name       Node Name       Suspended      State
    ----------       ---------       ---------      -----
    HAnfs-rg         nodeb           No             Online
                     nodea           No             Offline
    
    === Cluster Resources ===
    Resource Name       Node Name      State        Status Message
    -------------       ---------      -----        --------------
    HAnfs-rs            nodeb          Online       Online - Service is online.
                        nodea          Offline      Offline
    HAnfs-hasp-rs       nodeb          Online       Online
                        nodea          Offline      Offline
    HAnfs-lh-rs         nodeb          Online       Online - LogicalHostname online.
                        nodea          Offline      Offline
    
  8. Jetzt kann  man den NFS-Share mounten und ggf. einen Failover Test wie in Teil 2 durchführen (VM Power off von nodeb). Danach müssten alle drei Ressourcen und die Ressource Gruppe auf nodea online sein, aber der NFS-Share ohne erneutes Mounten an srv immer noch verfügbar sein.
    @srv # mount -F nfs hanfs:/HApool/export /a

Failover Native Zones im Cluster

Jetzt soll es an die Erzeugung einer Failover Zone gehen. Genau genommen heisst dieser Service in den Handbüchern "Data Service for Oracle Solaris Zones", wird aber oft einfach auch als Failover Zonen bezeichnet. Dieser Service ist sehr einfach und behandelt Solaris Zonen wie eine "Black Box", die zwischen Cluster Knoten hin- und hergeschoben wird. Ist die Failover Zone eine Kernel Zone, so kann die Verschiebung auch als Live Migration erfolgen. Dieses Setup benutzt VirtualBox und kann deshalb keine Kernel Zones erzeugen.

Services in der Zone werden durch den Cluster nicht durch Cluster Agenten überwacht. Deshalb werden Failover Zonen oft dort eingesetzt, wo sehr einfach Workloads hochverfügbar gemacht werden sollen, ohne daß ein Cluster Agent für den Workload verfügbar ist. Diese Einfachheit hat jedoch auch seinen Preis, denn ein "Blick" in die Failover Zone und der dort laufende Services ist für das Cluster Framework kaum möglich. Außerdem besteht nur eine "BlackBox" die verschoben wird, was für das Patchen eines Clusters mit Failover Zonen eine besondere Behandlung erfordert. Trotzdem werden Failover Zonen wegen ihrer Einfachheit im Solaris Cluster gerne eingesetzt.

Einen vergleichbaren Failover Service gibt es auch für SPARC LDOMs. Siehe dazu "Data Service for Oracle VM Server for SPARC".

Jetzt aber zurück zu diesem Cluster in VirtualBox ! Eine Failover Zone muss natürlich auch hier ausprobiert werden. Also los ! Zunächst ein bischen Planung:

  • Die Zone soll eine Zone on Shared Storage (ZOSS) sein und c2t1d0 für seinen rpool benutzen. So übernimmt das ZOSS-Framework zusammen mit dem Cluster Framework das Erzeugung des rpool und den Export und Import des Zpool beim Verschieben der Zone. Die Storage Konfiguration ist dabei Bestandteil der Zonenkonfiguration.
  • Die Zone soll ha-zone heißen (hostname: hazone=192.168.175.166)

Ok, soweit die Planung. Jetzt geht es an die Umsetzung:

  1. Zunächst wird sichergestellt, daß für c2t1d0 auf beiden Cluster Nodes der Pfad identisch ist und der did Device Name ermittelt. Für die spätere ZOSS Konfiguration wird auch noch der Storage Uniform Resource identifier (SURI) ermittelt.
    # cldev list -v | grep c2t1d0
    d6                  nodea:/dev/rdsk/c2t1d0
    d6                  nodeb:/dev/rdsk/c2t1d0
    
    # suriadm lookup-uri /dev/dsk/c2t1d0
    dev:dsk/c2t1d0
    
  2. Nun wird die Ressource Gruppe HAzone-rg für die Failover Zone erzeugt und die HAStoragePlus Ressource HAzone-hasp-rs zugewiesen, die zwischen den Cluster Knoten für einen exclusiven Zugriff auf das did Device d6 sorgt.
    # clrg create HAzone-rg
    # clrs create -g HAzone-rg -t SUNW.HAStoragePlus \
                  -p GlobalDevicePaths=dsk/d6 HAzone-hasp-rs
    # clrg online -eM HAzone-rg
    
  3. Jetzt wird die Zone auf nodea konfiguriert und die Konfiguration auf nodeb übertragen. Das rootzpool Property gibt in der Konfiguration das ZOSS Device an. autoboot muß für die Zone auf false stehen, da ja der Cluster das Starten und Stoppen der Zone je nach Status der Ressource Gruppe übernehmen soll.
    @nodea # zonecfg -z HAzone
    zonecfg:HAzone> create
    zonecfg:HAzone> add attr; set name=osc-ha-zone;set type=boolean;set value=true;end;
    zonecfg:HAzone> add rootzpool;add storage dev:dsk/c2t1d0;end;
    zonecfg:HAzone> set autoboot=false
    zonecfg:HAzone> select anet 0;set lower-link=net0;end;
    zonecfg:HAzone> commit
    zonecfg:HAzone> exit
    
    @nodea # zonecfg -z HAzone export > /tmp/HAzone.zcf
    @nodea # scp /tmp/HAzone.zcf demo@nodeb:/tmp    
    @nodea # rm /tmp/HAzone.zcf
    @nodeb # zonecfg -z HAzone -f /tmp/HAzone.zcf
    @nodeb # rm /tmp/HAzone.zcf
  4. Je nachdem, wo die bis jetzt konfigurierte HAzone-rg online ist, wird nun die Zone wie üblich installiert. Das dauert auf einem Laptop mit VirtualBox je nach Speicherausstattung, Festplattentyp am Host und CPU Typ unterschiedlich lange.
    # clrg status HAzone-rg
    === Cluster Resource Groups ===
    Group Name       Node Name       Suspended      Status
    ----------       ---------       ---------      ------
    HAzone-rg        nodeb           No             Online
                     nodea           No             Offline
    
    @nodeb # zoneadm -z HAzone install
    Configured storage resource(s) from:
            dev:dsk/c2t1d0
    Created zpool: HAzone_rpool
    Progress being logged to /var/log/zones/zoneadm.20180924T080811Z.HAzone.install
           Image: Preparing at /system/zones/HAzone/root.
    
     Install Log: /system/volatile/install.2157/install_log
     AI Manifest: /tmp/manifest.xml.uC9S9b
      SC Profile: /usr/share/auto_install/sc_profiles/enable_sci.xml
        Zonename: HAzone
    Installation: Starting ...
    
            Creating IPS image
    Startup linked: 1/1 done
            Installing packages from:
                solaris
                    origin:  http://srv:10114/
                    origin:  http://srv:10440/
                ha-cluster
                    origin:  http://srv:10440/
    DOWNLOAD                           PKGS         FILES    XFER (MB)   SPEED
    Completed                        415/415   65388/65388  428.2/428.2  1.0M/s
    
    PHASE                                          ITEMS
    Installing new actions                   89401/89401
    Updating package state database                 Done 
    Updating package cache                           0/0 
    Updating image state                            Done 
    Creating fast lookup database                   Done 
    Updating package cache                           2/2 
    Installation: Succeeded
     done.
            Done: Installation completed in 854.353 seconds.
    
  5. Nach erfolgter Installation wird die Zone erstmalig gebootet und initial konfiguriert (Hostname: hazone=192.168.175.166/24).
    @nodeb # zoneadm -z HAzone boot
    @nodeb # zlogin -C HAzone
    ... initiale Zonenkonfiguration ...
    ~.
    
  6. Wenn alles läuft, wird nun die Zone wieder heruntergefahren und vom "Host" detached. Danach kann man noch bei Bedarf prüfen, ob die Zone auch auf dem anderen Cluster Node attached und gestartet werden kann. Bei diesem Test ist es wichtig, die Option "-x deny-zbe-clone" beim "zoneadm attach" anzugeben. So wird verhindert, daß beim Attach auf einem anderen "Host" ein weiteres Boot Environment erzeugt wird. Zwischen den Cluster Nodes wird so beim Schwenken ein identisches Zone Image benutzt.
    @nodeb # zoneadm -z HAzone shutdown
    
    @nodeb # zoneadm -z HAzone detach
      Exported zpool: HAzone_rpool
      Unconfigured storage resource(s) from:
            dev:dsk/c2t1d0
    
    @nodea # zoneadm -z HAzone attach -x deny-zbe-clone
      Configured storage resource(s) from:
            dev:dsk/c2t1d0
      Imported zpool: HAzone_rpool
          Zone BE root dataset: HAzone_rpool/rpool/ROOT/solaris
      Updating non-global zone: Linking to image /.
      Updating non-global zone: Auditing packages.
      No updates necessary for this image. (zone:HAzone)
      Updating non-global zone: Zone updated.
      Result: Attach Succeeded.
    
    @nodea # zoneadm -z HAzone boot
    
    @nodea # zlogin -C HAzone
      ~.
    
    @nodea # zoneadm -z HAzone shutdown
    
    @nodea # zoneadm -z HAzone detach
      Exported zpool: HAzone_rpool
      Unconfigured storage resource(s) from:
            dev:dsk/c2t1d0
    
  7. Jetzt sind alle Vorbereitungen abgeschlossen und die Zone kann in die Clusterkontrolle übergeben werden. Dazu wird eine HA Boot Ressource in einer Konfigurationsdatei vorbereitet, die Konfiguration importiert und anschließend die Ressource der Zone aktiviert.
    @nodea # cp /opt/SUNWsczone/sczbt/util/sczbt_config \
               /opt/SUNWsczone/sczbt/util/sczbt_config.HAzone
    
    @nodeb # vi /opt/SUNWsczone/sczbt/util/sczbt_config.HAzone
      RS=HAzone-rs
      RG=HAzone-rg
      SC_NETWORK=false
      SC_LH=
      FAILOVER=true
      HAS_RS=HAzone-hasp-rs
      Zonename="HAzone"
      Zonebrand="solaris"
      Zonebootopt=""
      Milestone="svc:/milestone/multi-user-server"
      Mounts=""
      Migrationtype="cold"
    
    # /opt/SUNWsczone/sczbt/util/sczbt_register \
           -f /opt/SUNWsczone/sczbt/util/sczbt_config.HAzone
      sourcing /opt/SUNWsczone/sczbt/util/sczbt_config.HAzone
      Registration of resource type ORCL.ha-zone_sczbt succeeded.
      Registration of resource HAzone-rs succeeded.
    
    # clrs enable HAzone-rs
    
  8. Fertig ! Nach der Prüfung der Ressource Gruppe HAzone-rg sieht man, auf welchem Cluster Node die Zone gestartet wurde. Zusätzlich kann das auch noch mit "zoneadm" geprüft werden.
    # clrg status HAzone-rg
    === Cluster Resource Groups ===
    Group Name       Node Name       Suspended      Status
    ----------       ---------       ---------      ------
    HAzone-rg        nodeb           No             Online
                     nodea           No             Offline
    
    @nodeb # zoneadm list -cv
      ID NAME             STATUS      PATH                         BRAND      IP    
       0 global           running     /                            solaris    shared
       3 HAzone           running     /system/zones/HAzone         solaris    excl
    
    @nodeb # zpool list HAzone_rpool
    NAME           SIZE  ALLOC   FREE  CAP  DEDUP  HEALTH  ALTROOT
    HAzone_rpool  15.9G   925M  15.0G   5%  1.00x  ONLINE  -
    
  9. Jetzt kann  man prüfen, ob auch ein Schwenk der Failover Zone funktioniert. Danach müsste die Zone auf dem jeweils anderen Knoten hochgefahren werden.
    - geplant ("clrg switch -n <anderer Cluster Node> HAzone-rg")

    - oder ungeplant wie in Teil 2 (VM Power off von nodeb).

    Der Prozeß des Schwenkens kann bei Failover Zonen eine gewisse Zeit in Anspruch nehmen, da nicht nur die Zone neu gebootet werden muss, sondern vorher auch der rpool der Zone schwenken und die Zone attached werden muß. Das übernimmt hier das Cluster Framework sehr zuverlässig. So stellt das Cluster Framework nach einem Reboot einer Cluster Nodes auch sicher, daß nicht irrtümlich die Zone wieder an dem Knoten importiert wird, wenn er sie vor seinem Ausfall importiert hatte.
     
  10. Nach Abschluß aller Tests ist es in diesem kleinen Setup sehr sinnvoll, die Ressource Gruppe wieder permanent abzuschalten, um Ressourcen für weitere Tests zu sparen.
    # clrs disable -g HAzone-rg +
    # clrg offline HAzone-rg
    # clrg unmanage HAzone-rg
    

Soweit in diesem Beitrag zur Einrichtung eines HA NFS Cluster Service und zu Native Failover Zones. Im nächsten Beitrag geht es mit Native Zone Clustern weiter.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha