Shibboleth-IdP-Clustering – Memcached vs. Terracotta · Memcached arbeitete auch nach 150.000...

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


Funktionsweise:● Terracotta synchronisiert alle Objekte sowie set()/get()-Methodenaufrufe der JVMs.

Funktionsweise:● Terracotta synchronisiert alle Objekte sowie set()/get()-Methodenaufrufe der JVMs.


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


Jetzt:

Aufbau eines eigenen StorageService!


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)


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)


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


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


… 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


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)


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.


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;


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;


Jetzt:

Lasttest mit „The Grinder“


Lasttest „saml2_sso“ (IdP – 2 Worker)Lasttest „saml2_sso“ (IdP – 2 Worker)


Lasttest – Load BalancerDebian Squeeze, KVM (4 CPUs @2,5GHz)

Lasttest – Load BalancerDebian Squeeze, KVM (4 CPUs @2,5GHz)


(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)


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.


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“

http://www.shibboleth.net/

https://wiki.shibboleth.net/confluence/display/SHIB2/Home

https://www.aai.dfn.de/

https://idp.hrz.uni-marburg.de/

https://wiki.shibboleth.net/confluence/display/SHIB2/Memcached+StorageService


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).

mailto:[email protected]

Shibboleth-IdP-Clustering – Memcached vs. Terracotta · Memcached arbeitete auch nach 150.000...

Documents

Transcript of Shibboleth-IdP-Clustering – Memcached vs. Terracotta · Memcached arbeitete auch nach 150.000...