Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
Manuel Haim - Hochschulrechenzentrum
Shibboleth-IdP-Clustering –Memcached vs. Terracotta
Manuel Haim, Stand 10/2011 (IdP 2.3.2)
2Manuel Haim - Hochschulrechenzentrum
Einführung: Shibboleth-IdP-Clustering
• Grundidee: Mehrere Server bilden hochverfügbaren Cluster
→ Die Gesamtlast verteilt sich auf die Knoten (Lastverteilung)
→ Kein Dienstausfall bei Ausfall eines Knotens (Ausfallsicherung)
• Knoten müssen Zustands-Informationen teilen
→ Shibboleth-IdP speichert alle Zustandsdaten im StorageService
→ Problem: Java-Map (Objektänderungen ohne Zurückschreiben)
→ Standardlösung: Java-VMs per Terracotta abgleichen
3Manuel Haim - Hochschulrechenzentrum
Funktionsweise:● Terracotta synchronisiert alle Objekte sowie set()/get()-Methodenaufrufe der JVMs.
Funktionsweise:● Terracotta synchronisiert alle Objekte sowie set()/get()-Methodenaufrufe der JVMs.
4Manuel Haim - Hochschulrechenzentrum
Nachteile von Terracotta
• Komplexe Installation und Konfiguration
→ entpacken, Zusatzmodule installieren, xml-Config anpassen
→ dann jar-Library erzeugen und in Tomcat-Java-Opts einbinden
→ jar-Library abhängig von Java-Version und xml-Config
• Fragwürdige Performance
→ Synchronisation / Replikation von Java Virtual Machines
→ standardmäßig Festplattenspeicherung der Java-Objekte
5Manuel Haim - Hochschulrechenzentrum
Jetzt:
Aufbau eines eigenen StorageService!
6Manuel Haim - Hochschulrechenzentrum
Methoden des StorageService (Interface)
public interface StorageService<K,V> {
public V get(String partition, K key);
public V put(String partition, K key, V value);
public V remove(String partition, K key);
public boolean contains(String partition, K key);
public Iterator<String> getPartitions();
public Iterator<K> getKeys(String partition);}
Iteratoren für den ExpiringObject-Sweeper (löscht veraltete Objekte)
Ein „Key-Value-Store“
Hinweis:Man greift hier auf mehrere benannte Partitionen (Maps) zu(siehe ff. Folien)
7Manuel Haim - Hochschulrechenzentrum
Grundidee: Beliebigen Key-Value-Store anbinden
Hier ein paar Möglichkeiten:
• Datenbanken→ denkbar, aber keine persistente Speicherung gewünscht
• EhCache, Infinispan, Hazelcast, ...→ bieten Java-basierten Cache („JSR 107 Cache“) bzw. Map→ Replikation über Netzwerk möglich→ Problem besteht: Replikation nur bei Aufruf von get() und put()
• Memcached→ häufig genutzte, sehr performante Cache-Lösung im www→ wenig Overhead, daher von uns im folgenden gewählte Lösung→ Variante: Repcached (bietet Replikation über Netzwerk)
8Manuel Haim - Hochschulrechenzentrum
Partitionen (Maps) im StorageService
Der Shibboleth-IdP 2.3.x legt folgende Maps im StorageService an:
• loginContexts→ erhält Kontext zwischen Redirects beim Login-Vorgang aufrecht→ kurzlebig; bei Loadbalancer mit sticky-session nur lokal benötigt
• session→ aktive Benutzersitzung mit Statusinformationen, genutzte Dienste...
• transientId→ kurzlebige anonyme ID, ggf. für Backchannel-Attributanfrage nötig
• replay→ Replay-Cache, verhindert missbräuchliche Request-Wiederholung
9Manuel Haim - Hochschulrechenzentrum
Probleme beim Austausch des StorageService
Es genügt nicht, die Methoden get() und put() auf Memcached umzubiegen:
• get() ohne anschließendes put()→ ein mit get() geholtes Java-Objekt kann beliebig verändert werden→ der StorageService bekommt von diesen Änderungen aber nichts mit!
• mehrere Keys (Indices) für dasselbe Objekt (bei Session-Objekten)→ in einer lokalen Java-Map dank Objektreferenzen kein Problem→ aber in Memcached nicht vorgesehen
• serialisierte Objekte unterscheiden sich ggf. von Original-Objekten→ nicht alle Felder serialisierbar (publicCredentials, privateCredentials)→ keine Objekt-Identität gewährleistet (mc.put(name,obj) → obj!=mc.get(obj))
• Synchronisation zwischen lokalem und globalem Objekt erforderlich
10Manuel Haim - Hochschulrechenzentrum
… und unsere Lösungen
• get() ohne put(): Session-Objekte nachträglich speichern→ Objekte werden weiterhin in lokaler Map gehalten→ Post-Processing: per ServletFilter aktuelles Session-Objekt schreiben→ loginContext nur lokal (sticky-session), andere Objekte problemlos
• zusätzliche Session-Indices separat speichern→ Session-Objekt wird in Memcached nur unter SessionID gespeichert→ weitere Keys verweisen auf die SessionID und werden dereferenziert
• Deserialisierung: globales Objekt feldweise in lokales Objekt kopieren→ BeanUtils.copyProperties() kopiert alle sichtbaren Felder automatisch → nicht-serialisierbare Felder separat speichern bzw. zurückkopieren
• Synchronisation bei Zugriff:→ bei jeder get()- und put()-Anweisung: Lock+Merge mit globalem Objekt
11Manuel Haim - Hochschulrechenzentrum
Kleinigkeiten
• veraltete Objekte löschen→ Iteratoren angepasst: nur lokale Objekte (für den lokalen Sweeper)→ Memcached: Absoluter Ablaufzeitpunkt (expirationTime) der Objekte wird für mc.put() in relative Noch-Lebensdauer umgerechnet
• Datenabgleich lokal/global→ Welches Objekt ist neuer? (Vergleich der expirationTime)→ Abgleich auch bei get(), da put() vom IdP evtl. noch nicht ausgeführt→ beim Speichern von Session-Objekten auch Indices aktualisieren
• Memcached-Bibliothek für Java: spymemcached→ Anbindung mehrerer Memcached-Server (Hash-Buckets)→ fällt ein Server aus, werden Anfragen auf andere Server verteilt→ keine Replikation (worst case: Nutzer muss sich erneut anmelden)
12Manuel Haim - Hochschulrechenzentrum
Funktionsweise:
● Pound mit „sticky session“.
● StorageService speichert alle Objekte immer in lokaler Map. (wg. Java-Objektreferenzen)
● StorageService wird bei get()- und put()-Operationen mit memcached abgeglichen. (BeanUtils.copyProperties())
● Ein ServletFilter wird nach jedem IdP-Servlet ausgeführt, um Änderungen am Session-Objekt explizit zurück in den StorageService zu schreiben.
● Daten werden per Hash-Funktion auf mehrere memcached-Instanzen verteilt.
● Bei Ausfall eines Servers ist schlimmstenfalls ein neues Login am IdP erforderlich.
Funktionsweise:
● Pound mit „sticky session“.
● StorageService speichert alle Objekte immer in lokaler Map. (wg. Java-Objektreferenzen)
● StorageService wird bei get()- und put()-Operationen mit memcached abgeglichen. (BeanUtils.copyProperties())
● Ein ServletFilter wird nach jedem IdP-Servlet ausgeführt, um Änderungen am Session-Objekt explizit zurück in den StorageService zu schreiben.
● Daten werden per Hash-Funktion auf mehrere memcached-Instanzen verteilt.
● Bei Ausfall eines Servers ist schlimmstenfalls ein neues Login am IdP erforderlich.
13Manuel Haim - Hochschulrechenzentrum
Wesentliche Implementierung – put(key,value)
mc.lock(key);globalValue = mc.get(key);
if(globalValue!=null) { if(value.isNewerThan(globalValue)) { mc.set(key,value); } else { merge(value,globalValue); }} else { mc.set(key,value);}store.set(key,value);mc.unlock(key);return value;
14Manuel Haim - Hochschulrechenzentrum
Wesentliche Implementierung – get(key)
mc.lock(key);globalValue = mc.get(key);localValue = store.get(key);
if(localValue==null && globalValue!=null) { store.set(key,globalValue); localValue = globalValue;} else if(localValue!=null && globalValue!=null) { if(localValue.isNewerThan(globalValue)) { mc.set(key,localValue); } else { merge(localValue,globalValue); }}mc.unlock(key);return localValue;
15Manuel Haim - Hochschulrechenzentrum
Jetzt:
Lasttest mit „The Grinder“
16Manuel Haim - Hochschulrechenzentrum
Lasttest „saml2_sso“ (IdP – 2 Worker)Lasttest „saml2_sso“ (IdP – 2 Worker)
17Manuel Haim - Hochschulrechenzentrum
Lasttest – Load BalancerDebian Squeeze, KVM (4 CPUs @2,5GHz)
Lasttest – Load BalancerDebian Squeeze, KVM (4 CPUs @2,5GHz)
18Manuel Haim - Hochschulrechenzentrum
(Worker 2 von 2 analog)(Worker 2 von 2 analog)
Lasttest – Worker 1 von 2Debian Squeeze, KVM (4 CPUs @2,5GHz)
Lasttest – Worker 1 von 2Debian Squeeze, KVM (4 CPUs @2,5GHz)
19Manuel Haim - Hochschulrechenzentrum
Lasttest mit „The Grinder“ – Ergebnisse
Anzahl Worker
Cluster-Methode
-Xmx RAM Speicherverbrauch der jeweiligen Cluster-Methode pro Worker
TPS*
2 – 1536m 3GB – 65
2 Memcached(disjunkt)
1536m 3GB 10 MB RAM permanent,13 MB RAM pro 5.000 Logins**
63
2 Terracotta 3.5.1
1536m 4GB 800 MB RAM permanent,300 MB HD pro 5.000 Logins
22
● Der Speicherverbrauch des „geteilten“ Speichers entwickelte sich in den Tests linear.● Memcached arbeitete auch nach 150.000 Anmeldungen munter weiter.● Terracotta lief im Modus „permanent-store“ (wie im Shibboleth-Wiki vorgegeben) und
wurde vermutl. durch die Festplattennutzung ausgebremst. Nur 5.000 Logins getestet.
● Der Speicherverbrauch des „geteilten“ Speichers entwickelte sich in den Tests linear.● Memcached arbeitete auch nach 150.000 Anmeldungen munter weiter.● Terracotta lief im Modus „permanent-store“ (wie im Shibboleth-Wiki vorgegeben) und
wurde vermutl. durch die Festplattennutzung ausgebremst. Nur 5.000 Logins getestet.
* Transaktionen pro Sekunde, hier: Anmeldungen pro Sekunde.** Bei Verwendung von nur einem Memcached-Server: ca. 25 MB RAM pro 5.000 Logins.
20Manuel Haim - Hochschulrechenzentrum
Weiterführende Links
• Shibboleth:http://www.shibboleth.net,https://wiki.shibboleth.net/confluence/display/SHIB2/Home
• Föderation DFN-AAI:https://www.aai.dfn.de
• Shibboleth Single Sign-On an der Uni Marburg:https://idp.hrz.uni-marburg.de
• IdP Memcached StorageService (Eigenentwicklung):https://wiki.shibboleth.net/confluence/display/SHIB2/Memcached+StorageService→ siehe dort auch Link zur Diskussion in der „Shibboleth Users Mailing List“
21Manuel Haim - Hochschulrechenzentrum
Danke für Ihre Aufmerksamkeit!
Noch Fragen?
→ Gern jetzt im Anschluss :-)
→ sonst per E-Mail: Manuel Haim, [email protected]
Quellennachweis:Viele Icons in dieser Präsentation entstammen dem „Crystal Project“ (GNU LGPL).