Andrew FileSystem (AFS)

Table of Contents

Warum AFS?

Die Computer-Installation am Institut und im Computerraum Physik hat eine Größe erreicht, bei der die NFS-Server unter Linux bereits deutliche Performance-Probleme zeigen:

  • zu viele Clients (> 70)
  • hoher Datendurchsatz
  • hoher Speicherbedarf

Wie viel Dokumentation ist für Administratoren notwendig?

Jeder Admin sollte mindestens die Kapitel 1-8 aus dem AFS Administrator Guide gelesen (und verstanden) haben, damit er grundlegende Aufgaben (Volumes anlegen und verschieben, backup, …) erledigen kann.

Zum grundsätzlichen Verständnis hilfreich ist dieAFS Programmer’s Reference: Architectural Overview

Installation eines neuen Fileservers

apt-get install openafs-fileserver

# insert key
scp ${MASTER}:/etc/openafs/server/KeyFile \
    /etc/openafs/server/KeyFile
service openafs-fileserver stop
service openafs-fileserver start

# create file server instance
bos create -server faepsv03.tu-graz.ac.at -instance fs -type fs \
    -cmd /usr/lib/openafs/fileserver /usr/lib/openafs/volserver /usr/lib/openafs/salvager     

Ich kümmere mich zu diesem Zeitpunkt noch nicht um das Tuning der Filserver, die entsprechenden Parameter werden später von der Configuration Engine automatisch gesetzt.

Monitoring der Server

Die Verfügbarkeit der Server kann relativ einfach mit den Plugins für Nagios geprüft werden:

#!/bin/sh
NAGIOSDIR=/usr/lib/nagios/plugins

for host in afs1 afs2 afs3; do
    echo
    echo "### AFS DB server: $host"
    ${NAGIOSDIR}/check_afs_bos      -H $host || continue
    echo -n "ptserver: "
    ${NAGIOSDIR}/check_afs_udebug   -H $host -p 7002
    echo -n "vlserver: "
    ${NAGIOSDIR}/check_afs_udebug   -H $host -p 7003
    echo -n "buserver: "
    ${NAGIOSDIR}/check_afs_udebug   -H $host -p 7021
done

for host in $(vos listaddrs | sort); do
    echo
    echo "### AFS file server: $host"
    ${NAGIOSDIR}/check_afs_bos      -H $host || continue
    ${NAGIOSDIR}/check_afs_space    -H $host
    ${NAGIOSDIR}/check_afs_rxdebug  -H $host
done

Zusätzlich werden diese Module von unserer Icinga-Umgebung verwendet.

Tuning der Fileserver

Zur Überwachung einiger kritischer Parameter der Fileserver verwende ich ein einfaches Skript TEST-AFS-performance:

NAGIOSDIR=/usr/lib/nagios/plugins

for host in $(vos listaddrs | sort); do
    echo "### AFS file server: $host"
    ${NAGIOSDIR}/check_afs_bos -H $host || continue

    rxdebug $host 7000 -noconns             | grep "wait"
    xstat_fs_test $host -collID 3 -onceonly | grep 'GotSomeSpaces\|nFEs\|nCBs\|nblks'
done

Problematisch dabei ist, daß manche Werte meist nur kurz auftreten (“x calls waiting for a thread”) oder über die Laufzeit des Servers summiert werden (“xx calls have waited for a thread”). Daher kann im Nachhinein oft nicht festgestellt werden, ob der Mangel an Resourcen massiv über einen kurzen Zeitraum oder nur gelegentlich und einigermaßen zufällig verteilt auftritt. Vorläufig wird das Skript über watch in kurzen Abständen aufgerufen; in der Folge sollten diese und einige weitere Parameter in ihrem zeitlichen Verlauf auch grafisch dargestellt1 werden, um auch vorübergehende Performanceprobleme analysieren zu können.

Einbindung in Ganglia

Zur Zeit werden einge Metriken der AFS Fileserver in unser Performance Monitoring System Ganglia eingebunden. Ein Beispiel sieht man in der Gruppe “AFS FS metrics” auf https://itp.tugraz.at/ganglia/?c=Theoretische Physik - Serverraum Chemie&h=faepsv09.tu-graz.ac.at.

Zusätzlich wird am Ende des Tages eine Übersicht der verwendeten CallbackSlots in https://itp.tugraz.at/Comp/Stat_AFS/nCBs/ abgelegt.

Volumes mit vielen Zugriffen

Zusätzlich wird jeweils Abends eine Übersicht der Volumes mit besonders vielen Zugriffen generiert:

vos listvol faepsv09 -format | grep 'dayUse\|weekUse'
# --> ~/ITP/Utilities/afs_monitoring/afs_find_busy_volumes

Volumes mit vielen CallBacks

Wenn der Debug-Level auf 25 gesetzt wurde (3 mal ausführen killall -TSTP fileserver) kann man aus dem Log die gebrochen CallBacks filtern:

# collect some log file content
killall -HUP  fileserver
killall -TSTP fileserver
killall -TSTP fileserver
killall -TSTP fileserver
sleep 3600
killall -HUP  fileserver

# most active volumes
awk '/BreakCallBack/ {print $13}' /var/log/openafs/FileLog \
    | cut -c 2-10 \
    | sort \
    | uniq  -c \
    | sort -nr

# most active writing hosts
awk '/BreakCallBack/ {print $12}' /var/log/openafs/FileLog \
    | sort \
    | uniq  -c \
    | sort -nr

Es gibt daneben noch eine Reihe weiterer EInträge, die man auswerten könnte. Hinderlich ist das nicht einheitliche Format der verschiedenen Typen:

Fri Apr  8 23:00:17 2016 fssync: breaking all call backs for volume 536881506
Tue Apr 19 15:28:56 2016 [264] CCB: deleting timed out call back 60a11b81 (129.27.161.96:22811), (536886526,36280,57337)
Tue Apr 19 15:30:17 2016 [246] DCB: No call backs for fid (536885134, 37184, 2939565)
Tue Apr 19 15:30:17 2016 [246] SAFS_GiveUpCallBacks (Noffids=32)
Tue Apr 19 15:30:11 2016 [249] BCB: BreakCallBack(Host 00007F0FA03C35D8 all but 129.27.161.99:7001, (536879622,1062,864808))

Vergleich unserer Serverparameter mit anderen Zellen

In der Tabelle vergleiche ich die Fileserver-Parameter unserer Installation (ITP) mit veröffentlichten Werten einiger anderer Institutionen:

Parameter ITP Stanford CERN Telmate Kommentar
-L ja ja ja ja immer noch zu wenige Resourcen
-p 256 128 256 128 128 war zu niedrig: 32 calls have waited for a thread
-cb 1048576 200000 524288 8000000 1 Mi ist zu niedrig: “142 GotSomeSpaces”
-udpsize 16777216 1048576 16777216 12582912 Default 64k; sollte erhöht werden
-rxpck   800   3600 autotunes?
-s   1000 32768 50000  
-l   1000 8192 15000  
-b     4096 6000  
-vc   1000 16384 1000  
-busyat   200   1200  
-vattachpar   4   4  
-sendsize       512000  

Diese Daten von Telmate sind vermutlich auf Bulk-Transfers optimiert. Die Daten der Uni Stanford sollten eher unserem Benutzerprofil entsprechen: “… and a bunch of those are probably still too small”. Die Daten des CERN kommen aus dem CERN Site Report (S. 33) der Europäischen AFS-Konferenz 2012.

Ideen

TODO Home-Volumes “zufälliger” verteilen

  • Homedirectories anhand von modulus(md5(volname), anz(server)) besser auf die vorhandenen Server verteilen?
  • Oder ist es sinnvoll, über die Zugriffsstatistik wie in https://www.eyrie.org/~eagle/software/afs-balance/ oder ftp://ftp.andrew.cmu.edu/pub/AFS-Tools/ optimieren. Dagegen spricht, daß die Statistiken tage- oder wochenweise akkumuliert werden; wir aber eine optimale Verteilung dann brauchen, wenn sich in den Computerräumen gleichzeitig viele Studierende anmelden.

TODO RO-Kopien von common/local erzeugen

  • vorher Inhalte von opt/local dorthin migrieren
  • Inhalte von /proj/edv/bin/ und /proj/edv/sbin/ dorthin migrieren
  • RO-Clones erzeugen
  • einmal pro Tag per cron freigeben
  • Link-Erzeugung von opt/local, /proj/edv/bin/ und /proj/edv/sbin/ nach common/local umleiten
  • Makefiles umschreiben: neues Ziel ist /afs/.itp.tugrazt.at/common/local/...

RO-Kopien von common/www erzeugen

  • Arbeiten/Bakk/*.zip als Attachments in die entsprechenden PDFs importieren –> ankündigen im JourFixe.html
  • Import der Dokumente in Greenstone Digital Library, ebenso Vorlesungsunterlagen und der dgl.
  • Makefiles umschreiben: neues Ziel ist /afs/.itp.tugrazt.at/...
  • alle 4 oder 6 Stunden per cron freigeben

TODO UDP buffer overruns in Ganglia protokollieren

  • netstat -su | grep RcvbufErrors legt nahe, daß es im Moment (16 MiByte) keine tragischen Probleme gibt. Allerding ist der Fehlercounter auf faepsv00 zwischen [2016-06-01 Mit 18:00] und [2016-06-02 Don 08:30] von 672530 auf 893141 gestiegen, zumindest eine Überwachung dieser Fehlermöglichkeit in Ganglia ist jedenfalls sinnvoll. Die anderen Server haben nach ebenfalls etwa zwei Monaten Uptime nur Fehlerzahlen zwischen 3000 und 40000.
  • Anpassung des Parameters ist vermutlich für fileserver und volserver angebracht.
  • reicht es aus, eim Aufruf der Server die Option “-udpsize” anzugeben oder ist es notwendig, mehrere Einträge in /etc/sysctl.d/afs_server.conf zu setzen?
net.core.rmem_default = 65536
net.core.rmem_max = 16777216
net.core.wmem_default = 65536
net.core.wmem_max = 16777216
net.ipv4.tcp_mem = 16777216 16777216 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.udp_mem = 16777216 16777216 16777216
net.ipv4.udp_rmem_min = 65536
net.ipv4.udp_wmem_min = 65536
net.ipv4.route.flush = 1

Aktivieren von directory indexing auf den Serverpartitionen

Erhöhen von -sendsize

Benutzergruppen für Arbeitsgruppen / Projekte

Für jede Arbeitsgruppe wird ein Projektverzeichnis /afs/.../proj/name/ und einige passende Gruppen im PTS angelegt. Alle Gruppennamen sind nach dem Muster proj.name.x gebildet; die Gruppen werden von uns erzeugt, aber die Mitgliedschaft soll weitgehend innerhalb der Gruppe selbst geregelt werden. Die Anhängsel haben folgende Bedeutung:

a
Die Mitglieder der Gruppe sind die Leiter der Arbeitsgruppe oder des Projekts und haben administrative Rechte sowohl im Projektverzeichnis /afs/.../proj/name/ (dürfen also ACLs setzen), als auch über die Mitglieder der anderen Projektgruppen.
w
Die Mitglieder dieser Gruppe haben Schreibzugriff auf das Projektverzeichnis.
r
Die Mitglieder dieser Gruppe haben Lesezugriff auf das Projektverzeichnis. Die Gruppe wurde für die bisher erzeugten Projekte micht angelegt.

Einen Überblick über definierte Gruppen erhält man dem Kommando pts listentries:

$ pts listentries -groups | grep ^proj | sort
proj.edv.a                  -225   -225     400 
proj.edv.w                  -226   -225     400 
proj.manybody.a             -220   -220     400 
proj.manybody.w             -221   -220     400 
proj.plasma.a               -207   -207     400 
proj.plasma.dipl            -210   -207     400 
proj.plasma.diss            -209   -207     400 
proj.plasma.w               -208   -207     400 
proj.sekretariat.a          -222    400     400 
proj.sekretariat.w          -223   -222     400 
proj.transport.a            -218   -218     400 
proj.transport.w            -219   -218     400 

Zur Verwaltung der Gruppen durch Berechtigte dienen die folgenden Kommandos:

  • pts membership gruppe
  • pts adduser -user name -group gruppe
  • pts removeuser -user name -group gruppe

Was ist ein Projekt

Um eine neues Projekt zu eröffnen, müssen mehr als 2 Personen zusammenarbeiten, Das Projektverzeichnis kann dann von einem AFS-Administrator mit afs_proj_create erzeugt werden.

Benutzergruppen für Netzwerkadressen

Gruppe Beschreibung
admin:www alle Webserver
admin:net_tu gesamtes Netzwerk der TU Graz
admin:net_itp Netzwerk des Institutes
admin:net_fub Netzwerk des “Computerraums Physik”

Typen von Volumes

Die Einteilung ist von den Richtlinien zur AFS Disk Space Administation des CERN inspiriert. Zur konsequenten Einhaltung dieser Policy könnte eventuell die AFS Tool Suite (MITRE Corporation) hilfreich sein.

Die Angaben zur maximalen Größe der Volumes entspringen keinen harten technischen Begrenzungen, sondern kommen aus den verfügbaren Kapazitäten zu Backup und Festplattenspeicher.

In den folgenden Beschreibungen sind variable Teile des Volumenamens und Mountpoint in [eckigen Klammern] angegeben.

Benutzer - Homedirectories

Volume user.[user]
Mount point /afs/itp.tugraz.at/user/[user]
Backup ja (täglich)
redundanter Speicher geplant
RO-clones nein
max. Größe [GiByte] 64
initiale Größe [GiByte] 8

Die Volumes werden beim Anlegen der Benutzer mit createuser.pl erzeugt und gemountet und mit afs_user_remove loginname gemeinsam mit dem Account wieder entsorgt.

Benutzer - Scratch

Volume scratch.[user]_[??]
Mount point /afs/itp.tugraz.at/user/[user]/scratch_[??]
Backup nein
redundanter Speicher nein
RO-clones nein
max. Größe 64 GiByte

Volumes und mount points dieses Types können mit afs_scratch_create [user] [quota] (afsadmintools) erzeugt und mit afs_scratch_remove [user] (afsadmintools) wieder entfernt werden. Jeder Benutzer kann höchstens 100 (00 bis 99) dieser Volumes erhalten.

Es werden keine neuen Scratch-Volumes angelegt - dafür haben wir seit geraumer Zeit MooseFS. Der Transfer von vorhandenen Scratch-Volumes sollte mittelfristig ins Auge gefasst werden.

TODO Scratch-Volumes nach /temp/ migrieren

  • zugunsten von /temp/user/scratch_??/ oder /temp/user_scratch_??.tar.bz2/
  • Ankündigung im JourFixe.html notwendig!

Projektplatz

Für den gemeinsamen Zugriff von Arbeitsgruppen bzw. Verwaltungsstrukturen (z.B. Sekretariat)

Volume proj.[projektname] bzw. p.[projektname]
Mount point /afs/itp.tugraz.at/proj/[projektname]
Backup ja (täglich)
redundanter Speicher geplant
RO-clones nein
max. Größe [GiByte] 256
initiale Größe [GiByte] 32

Installierte Programme

Volume opt.[programmname]_[version]
Mount point /afs/itp.tugraz.at/opt/[programmname]/[version]
Backup ja (monatlich)
redundanter Speicher wünschenswert, nicht zwingend
RO-clones ja
max. Größe nach Bedarf

Volumes und mount points für diesen Typ werden mit afs_opt_create programm version quota (afsadmintools) erzeugt. Links zum bequemeren Aufrufen werden danach gegebenenfalls mit Hilfe der Configuration Engine aus dem Directory /usr/local/[s]bin heraus erzeugt.

globale Daten

Speicherbereich für gemeinsam benutzte Daten, die im Allgemeinen nicht oft verändert werden (z.B. für den FTP-Server). Könnte auch als Ergänzung für die Daten in /usr/local/share (z.B. Bibliografien, emacs-lisp, zusätzliche tex/latex-styles, …) dienen.

Volume common.[name]
Mount point /afs/itp.tugraz.at/common/[name]
Backup ja (monatlich)
redundanter Speicher wünschenswert, nicht zwingend
RO-clones ja
max. Größe nach Bedarf

Dies und Das

  • Könnte es sein, daß einige übriggebliebene RO-Clones ohne RW-Instanz vorhanden sind: besser löschen
  • Eventuell gibt es einige Backup-Volumes, deren RW-Instanz bereits gelöscht ist: vos remove
  • udebug <server> 700x UBIK-Status
  • Cachegröße: 4 MB optimal in 100 MBit-Netz? RAM-Disk? Memory-Cache?
  • vos listvldb -locked
  • Unterschied: gssapi vs. gssapi-with-mic (nur ticket forwarding?)
  • Was muss man beachten, wenn man Server mit mehreren IP-Adressen betreibt? http://www.angelfire.com/hi/plutonic/afs-faq.html#sub3.15

Volumes mit RW und RO-Kopien wiederherstellen

Nach einem Defekt eines Servers müssen Volumes ohne RO-Clones aus dem Backuop zurückgespielt werden. Volumes mit RO-Clones können wesentlich einfacher wiederhergestellt werden. Dabei gibt es 2 unterschiedliche Fälle:

RW-Volume ist auf einem gesunden Server
es ist nur notwendig, das Volume neu zu releasen (vos release ...), um die zusätzlich Kopie zu erzeugen.
RW-Volume war auf dem defekten Server/Partition
mit vos convertROtoRW wird eine der vorhandenen RO-Instanzen zu einem RW-Volume umgebaut; danach wird neu released.

Am effizientesten wird es sein, diese beiden Schritte kombiniert durchzuführen, damit nur einmal über die Liste der Volumes iteriert werden muß. In unserem Fall sind das alle Volumes, deren Name mit [o.|opt.|root.] beginnen.

#!/bin/sh
SRVDEFEKT=faepsv06
SRVGOOD=faepsv09

for VOLUME in $(vos listvldb -localauth | grep ^o )
do
    if (vos listvldb -name $VOLUME -localauth | grep $SRVDEFEKT | grep --quiet "RW")
    then
        echo "# RW-volume should be on $SRVDEFEKT -      volume: $VOLUME"
        echo "# create new RW and RO volumes on $SRVGOOD"
        vos convertROtoRW -server $SRVGOOD -partition /vicepa -id $VOLUME -localauth -force
        vos addsite       -server $SRVGOOD -partition /vicepa -id $VOLUME -localauth
    else
        echo "# RW Volume was not on server $SRVDEFEKT - Volume: $VOLUME"
    fi

    vos release -id $VOLUME -localauth
    vos examine -id $VOLUME -localauth
done

Alternativen

Alternativen wie CODA oder InterMezzo sind leider nicht soweit entwickelt, daß problemloser Einsatz im Netzwerk des Instituts zu erwarten ist. Der Einsatz von network attached storage (NAS) und einem entsprechendem Filesystem (z.B. GFS) ist im Rahmen unseres Budgets nicht möglich.

In Zukunft werden mit neuen verteilten Dateisystemen vermutlich einige Möglichkeiten entstehen.

Footnotes:

1
Übersicht über Systeme zum Speichern/Analysieren von Zeitreihen: http://prometheus.io/docs/introduction/comparison/. Für uns käme auch in Frage, diese Werte gleich in Ganglia einzubinden und mit Grafana oder eigenen Skripten dann alle Server besser vergleichbar in einer gemeinsamen Grafik darzustellen. Um ad hoc eine Lösung zu finden ist wahrscheinlich Graphite für die Datenspeicherung und Grafana für die Präsentation am einfachsten - sauberer vermutlich InfluxDB mit Grafana.

Author: Andreas Hirczy

Created: 2017-11-08 Mit 18:27

Validate