Cluster-Benutzerverwaltung: erste Schritte mitShibboleth

Steffen Hau, Reinhard Mayer, Sabine Richling, Tobias Kienzle,Heinz Kredel

Rechenzentrum Universitat MannheimUniversitatsrechenzentrum Heidelberg

ZKI AK Supercomputing, Dusseldorf20./21. September 2012

Inhalt

1 bwGRiDin Baden-Wurttembergin Mannheim/Heidelberg

2 Cluster-Benutzerverwaltung Mannheim/HeidelbergAdministrationBenutzerverwaltung bisherFoderative Authentifizierung und AutorisierungZugang uber Shibboleth

3 Zusammenfassung und Ausblick

4 Demo

Was ist bwGRiD?

Virtuelle Organisation (VO) bwGRiDD-Grid Projekt der Universitaten in Baden-WurttembergVO bwGRiD ist offen fur alle Mitglieder der beteiligtenUniversitaten und deren Partner in wissenschaftlichenProjekten

bwGRiD RessourcenRechencluster an 8 StandortenZentraler Speicher in Karlsruhe

bwGRiD ZieleNachweis der Funktionalitat und des Nutzens vonGrid-Konzepten fur das Hochleistungsrechnen inBaden-WurttembergUberwindung von Organisations-, Sicherheits- undLizenz-ProblemenEntwicklung von neuen Cluster- und Grid-Anwendungen

bwGRiD – Ressourcen

Rechencluster:

Mannheim/Heidelberg:280 KnotenDirekte Kopplung

Karlsruhe: 140 Knoten

Stuttgart: 420 Knoten

Tubingen: 140 Knoten

Ulm (Konstanz): 280KnotenHardware in Ulm

Freiburg: 140 Knoten

Esslingen: 180 Knotenneuere Hardware

Zentraler Speicher:

Karlsruhe:128 TB (mit Backup)256 TB (ohne Backup)

HeidelbergMannheim

Frankfurt

München

Ulm(joint cluster

with Konstanz)

Freiburg

Stuttgart

Tübingen

Karlsruhe

(interconnected to a single cluster)

Esslingen

bwGRiD – Nachfolge

HPC Konzept von Baden-Wurttemberg:

Ende 2012 ist die bwGRiD Hardware 5 Jahre alt

Ersatzbeschaffungen angestrebt in 2012 bis 2015

Kopplung der bwGRiD Cluster MA/HD

Antrag in 2008

Beschaffung und Aufbau bis Mai 2009

in Betrieb seit Juli 2009

Infiniband uber Glasfaser: Obsidian Longbow

Latenz ist hoch:145 µsec = Lichtlaufzeit (28 km) + 2 µsec lokale Latenz

Bandbreite wie wartet: etwa 930 MB/secLokale Bandbreite 1200-1400 MB/sec

bwGRiD Cluster Mannheim/Heidelberg

Grid spare

InfiniBand InfiniBand

MA

bwFS

Lustre

bwFS

HD

Lustre

PBS

passwd

Admin

Obsid

ian

28 km

Obsid

ian

LDAP AD

Cluster Cluster

HeidelbergMannheim

VOMRS

User HDUser MA

140 nodes cluster Directory service StorageLogin/Admin ServerInfiniBand Network

Gemeinsame System-Administration

Aufgaben des Admin-Servers:

DHCP+PXE Service fur die KnotenNFS Export des Root-Filesystems fur die KnotenNFS Verzeichnis fur Software-PaketeBatch System und Job Scheduler

Administration der Knoten:

uber Shell-Skriptemit IBM Management-Modul (CLI und Web-GUI)

Jobmanagement:Kopplung (hohe Latenz, begrenzte Bandbreite)

bietet genug Bandbreite fur Zugriff auf Storagesystemereicht nicht fur MPI Jobs mit hoher Kommunikation

Jobs laufen auf Knoten in HD oder in MAVor der Kopplung:

In Mannheim: hauptsachlich 1-Knoten-Jobs → freie KnotenIn Heidelberg: viele MPI-Jobs → lange Wartezeiten

Nach der Kopplung: Bessere Auslastung

Gemeinsame Benutzerverwaltung

Benutzer bekommen exklusiven Zugang zu den Knoten

Kennungen und User-IDs mussen eindeutig seinDirekte Verbindung zu PBS und Autorisierung uber einPAM-Modul

Authentifizierung am Zugangsrechner

gegen LDAP (MA) und AD (HD)mit D-Grid Zertifikat

Aktivierung von Kennungen

Setzen eines Attributs im LDAP bzw. AD (Authentifizierung)Update der Benutzerdaten auf dem Cluster (Autorisierung)

Erstellung der Dateien fur die Benutzerverwaltung

Prefix “ma”, “hd” oder “mh” fur GruppenOffsets fur Group-IDsOffsets fur User-IDsKennungen von MA und HD mussen verschieden sein!

Erstellung der Dateien fur die Benutzerverwaltung

unique!

group−id

group

user−id

useruser

group

user−idADLDAP

+prefix hd

+100.000 +200.000

+100.000 +200.000

+prefix ma

group−id

Directory service MA Directory service HD

user

group

user−id

group−id

+2.000.000

+2.000.000

+prefix mhVOMRS

Adminserver

/etc/passwd /etc/group

VO registration service

bwGRiD – Nutzung

0

200000

400000

600000

800000

1e+06

1.2e+06

1.4e+06

1.6e+06

1.8e+06

07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06

CP

U [

h]

Monat

bwGRiD Cluster MA/HD 07/2010 - 06/2012

lokalbwGRiD VO

andere D-Grid VOsMaximum

Warum neuer foderativer Zugang?

D-Grid lauft eventuell Ende des Jahres 2012 aus (keine VODienste mehr)

Grid-Zugang sehr komplex (siehe Modellierung)Grid-Zertifikat und VO RegistrierungViele Arbeitsschritte fur Nutzer und RechenzentrumEinarbeitung in die Nutzung einer Middleware

Zugang weiterhin Baden-Wurttemberg weit gewunscht

Neubeschaffungen im Rahmen des HPC Konzeptes

Foderativer Zugang als einfachere Alternative furssh-ZugangbwGRiD-Portal

keine zentrale Benutzerverwaltung notwendig

keine Eingriffe in die Organisation der Benutzerverwaltung derUniversitaten

die Foderation der Benutzerverwaltungen stellt nur dieIdentitaten sicher

Modellierung Grid-ZugangB

enu

tzer

bwGRiD ZUGANG

Betreits VO Mitglied

Nein

JaSSH-login

DFN Zertifikat beantragen

VO-Mitgliedschaft beantragen

Globus einrichten

Login Portal

Globus bereitseingerichtet

Grid benutzen

Grid benutzen

Ben

utz

erR

UM

DFN DFN Black Box

DFN GRID CA besuchen

Sich mit ID ausweisen

DFN Zertifikat

Identität prüfen

Ablehnen

Web-Formular ausfüllen

Web-Formular abschicken

Root-Zertifikat in Browser importieren

Antrag entgegennehmen

PDF-Formular ausdrucken

Papier-Formular unterschreiben

Zur Prüfstelle gehen

Zertifikat installieren

RA-Seite aufrufen

Papier-Antrag ausfüllen

Antrag final prüfen

Antrag genehmigen

Zertifikat erstellenGenehmigung

entgegennehmen

Signiertes Zertifikat

Ben

utz

erR

UM

Sonderfall Mannheim/Heidelberg

Bwgrid-user-provisioning.sh

D-Grid-Seite besuchen(Jülich)

Bwgrid >„Member registration“

besuchen

„Registration (Phase 1)“ auswählen

Repräsentant auswählen&&

Daten eingeben wie zuvor bei der Zertifizierung

Subgroup VO auswählen

/bwgrid/unimannheim

Formular abschicken

Mail-Adresse bestätigen Projekt-Information

bereitstellen

Phase 2: Policy lesen und

akzeptieren

Fehlen

Benutzer auf „approved“ setzen

Ablehnen

Bestätigen

Benutzer auf „denied“ setzen

Cronjob || manuell:GridMapFile laden

Benutzer erscheint im

GridMapFile

Provisionierung:/etc/

[group|passwd|shadow] aktualisieren

Grid-home – Verzeichnisanlegen

Deployment auf alle Frontend-&

Lustre-Server

„deny“ an Benutzer

Sonderfall Mannheim/HeidelbergPrüfen sind

Projektinformationen vorhanden/vollständig

&&Zugehörigkeit

Informationen anfragen

Vorhanden & Komplett,falsche Zughörigkeit,

oder sonst.

Eintragen in Projektliste

Aliases aktualisieren

Mitgliedschaft in der VO bwGRiD

Projekt-Informantion

Bestätigung

Bestätigungenempfangen

Hierfür wird das Zertifikat benötigt

An Repräsentant

An alle Vertreter der SubVO

Hauptarbeitsschritte

��������

@@@@@@R

Benutzer Rechenzentrum

Foderative Authentifizierung und Autorisierung

bwGRiD “Erganzende Maßnahmen”

Verbesserung der Nutzbarkeit und Weiterentwicklung des Angebotsvon bwGRiD in verschiedenen Arbeitspaketen in Zusammenarbeitmit bwIDM und bwLSDF

Ein Ziel

Vereinfachung der Anmelde-Prozeduren

Aufgaben

Machbarkeit und Konzept

Prototyp in HD-MA lauffahig

allgemeine Verfugbarkeit

Koordination mit bwIDM und DFN

Losungen: Shiboleth und eduroam

Technische Moglichkeiten

Untersuchung und Evaluation im Rahmen von bwIDM in 2011(Nussbaumer, Simon aus KA, Grandpre, Becker aus KO, MA):

Eduroam (Radius): hat keine / zu wenige Attribute uber dieBenutzer, zum Beispiel ist Mitarbeiter und Student nichtunterscheidbar

Moonshot: zur Zeit noch nicht produktiv Einsetzbar, großeEingriffe in die Infrastruktur notwendig (spezielles ssh)

Shibboleth: Attribute vorhanden, kleine Eingriffe in dieInfrastruktur notwendig (spezielles PAM ECP, NSSWITCH), evtl.Abstriche beim Datenschutz wegen des SSHD

Ergebnis

Shibboleth ist zur Zeit am besten geeignet.

Zugang uber Shibboleth

Konzept

Anforderung: es soll alles Datenschutz-konform sein

Service Provider (SP), Diensteanbieter wie zum BeispielbwForCluster, bwUniCluster, bwGRiD

Identity Provider (IDP), Identitaten garantiert durchBenutzerverwaltungen der Universitaten

Benutzer muss dem IDP der Heimateinrichtung vertrauen

auch dem SSHD muss vertraut werdenEinmal-Passworter oder SSH-Keys als Alternative

Beantragung eines Shibboleth Zugangs zu einem Dienst, wiez.B. bwGRiD, uber ein Web-Formular

keine weiteren Formulare und Unterschriften

Dienst kann Benutzer ablehnen oder Bedingungen stellen

Benutzer kann die Bedingungen ablehnen oder einwilligen

Zugang uber Shibboleth

Registrierung ssh-Zugang

Zugang uber Shibboleth

Aufgaben bei der Realisierung

Ersatz Login-Server wird Shibboleth Zugangsrechner

ssh-Zugang mit kennung@einrichtung unter Verwendungund Anpassung des PAM ECP Moduls aus Karlsruhe

Aufbau einer Datenbank, die mit dem Web-Portal verbundenist und die, die fur den Betrieb notwendigen Infos enthalt

Erzeugung von passwd.shib, group.shib undaliases.shib aus der Datenbank

Uberarbeitung des Deployments damit diese Dateienentsprechend integriert werden

Kann kennung@einrichtung auch als UID verwendetwerden?

wenn dies nicht moglich ist, muss ein Mapping zu ‘normalen’Kennungen entwickelt werden

bwGRiD Cluster Mannheim/Heidelberg mit Shibboleth

Grid Shibboleth

InfiniBand InfiniBand

MA

bwFS

Lustre

bwFS

HD

Lustre

PBS

passwd

Admin

Obsid

ian

28 km

Obsid

ian

LDAP AD

IDP

Cluster Cluster

HeidelbergMannheim

SP

VOMRS

User HDUser MA

140 nodes cluster Directory service StorageLogin/Admin ServerInfiniBand Network

Erstellung der Dateien fur die Benutzerverwaltung

unique!

group−id

group

user−id

useruser

group

user−idADLDAP

+prefix hd

+100.000 +200.000

+100.000 +200.000

+prefix ma

group−id

Directory service MA Directory service HD

user

user−id

group

group−id

user

group

user−id

group−id

+2.000.000

+2.000.000

+prefix mh +prefix sh

+3.000.000

+3.000.000

VOMRS

Shibboleth service

Adminserver

/etc/passwd /etc/group

SP

IDP

VO registration service

Zugang uber Shibboleth

Tests

Aufsetzen des Shibboleth bwGRiD SP

Anpassen des PAM ECP Moduls

Aufsetzen der Shibboleth IDPs der Universitaten

Probleme

@ in UID kennung@uni-heidelberg.de funktioniert nicht,wenn das @ eine Bedeutung fur die Anwendung hat, wie zumBeispiel bei PBS kennung@host

in UID kennung uni-heidelberg.de wurde funktionieren,aber evtl. Probleme mit Datenschutz

⇒ NSS Modul muss entwickelt werden

Zugang uber Shibboleth

Erste Ergebnisse

Generierung und Deployment der neuen Kennungen auf dieZugangsrechner und die Lustre Server funktioniert

Zugang funktioniert mit kennung@uni-heidelberg.de undkennung@uni-mannheim.de

PAM ECP Modul authentifiziert gegen Shibboleth IDP derjeweiligen EinrichtungNSS Modul bildet kennung@einrichtung auf neueKennungen sbwxxxxx abAbbildung der Kennungen sbwxxxxx auf reale Email-Adressenin /etc/aliases

Verwendung von Lustre funktioniertVerwendung von PBS einschließlich Email-Benachrichtigungfunktioniert ebenfalls

Zusammenfassung und Ausblick

InfiniBand Cluster-Kopplung uber 28 km ist stabil im Betrieb

bessere Auslastung durch Kopplung sowie vereinfachteAdministration und Benutzerverwaltung

Ziel: vereinfachter Zugang fur die Benutzer

Entwicklung von PAM ECP im Rahmen von bwIDM von M.Simon, KarlsruheAufsetzen der Shibboleth Infrastruktur: IDP und SPEntwicklung eines NSS Moduls zum Mapping auf generischeKennungenProof of Concept fur bwGRiD Cluster Heidelberg-MannheimFreigabe fur bwGRiD Nutzer aus Heidelberg-Mannheimgeplant fur Ende 2012

Produktiver Einsatz im bwUniCluster geplant fur Anfang 2013

Dank an

Nussbaumer, Simon (KIT, Karlsruhe)

Grandpre, Becker (Universitat Konstanz)

Mosch (Universitat Ulm)

Bogus, Skowronek, Maylein (Universitat Heidelberg)

Hanger, Wagner, Pfeffer (Universitat Mannheim)

Demo

1 Select IDP for registration

2 Registration login

3 Registration request

4 Approve request pending

5 Approve request processing

6 Approval status overview

7 User provisioning in the cluster

8 SSH login via Shibboleth

9 Job submission with PBS

Select IDP for registration

Registration login

Registration request

Approve request pending

Approve request processing

Approval status overview

User provisioning in the cluster

SSH login via Shibboleth

Job submission with PBS