Shibboleth-IdP-Clustering Memcached vs. Terracotta

Transkript

1 Shibboleth-IdP-Clustering Memcached vs. Terracotta Manuel Haim, Stand 10/2011 (IdP 2.3.2)

2 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 2

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

4 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 4

5 Jetzt: Aufbau eines eigenen StorageService! 5

6 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); Ein Key-Value-Store Hinweis: Man greift hier auf mehrere benannte Partitionen (Maps) zu (siehe ff. Folien) 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) 6

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

8 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 8

9 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 9

10 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 10

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

12 Funktionsweise: Pound mit mit sticky session. StorageService speichert alle alle Objekte immer in in lokaler Map. (wg. Java-Objektreferenzen) StorageService wird bei bei get()- und und put()-operationen mit mit memcached abgeglichen. (BeanUtils.copyProperties()) Ein Ein ServletFilter wird nach jedem IdP-Servlet ausgeführt, um um Änderungen am am Session- Objekt explizit zurück in in den den StorageService zu zu schreiben. Daten werden per per Hash- Funktion auf auf mehrere memcached-instanzen verteilt. Bei Bei Ausfall eines Servers ist ist schlimmstenfalls ein ein neues Login am am IdP IdP erforderlich. 12

13 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; 13

14 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; 14

15 Jetzt: Lasttest mit The Grinder 15

16 Lasttest saml2_sso (IdP 2 Worker) 16

17 Lasttest Load Balancer Debian Squeeze, KVM (4 (4 17

18 Lasttest Worker 1 von 2 Debian Squeeze, KVM (4 (4 (Worker 2 von 2 analog) 18

19 Lasttest mit The Grinder Ergebnisse Anzahl Worker Cluster- Methode -Xmx RAM Speicherverbrauch der jeweiligen Cluster-Methode pro Worker TPS* m 3GB 65 2 Memcached (disjunkt) 2 Terracotta m 3GB 10 MB RAM permanent, 13 MB RAM pro Logins** 1536m 4GB 800 MB RAM permanent, 300 MB HD pro Logins * Transaktionen pro Sekunde, hier: Anmeldungen pro Sekunde. ** Bei Verwendung von nur einem Memcached-Server: ca. 25 MB RAM pro Logins. Der Speicherverbrauch des geteilten Speichers entwickelte sich in in den Tests linear. Memcached arbeitete auch nach Anmeldungen munter weiter. Terracotta lief lief im im Modus permanent-store (wie im im Shibboleth-Wiki vorgegeben) und wurde vermutl. durch die die Festplattennutzung ausgebremst. Nur Logins getestet

20 Weiterführende Links Shibboleth: Föderation DFN-AAI: Shibboleth Single Sign-On an der Uni Marburg: IdP Memcached StorageService (Eigenentwicklung): siehe dort auch Link zur Diskussion in der Shibboleth Users Mailing List 20

21 Danke für Ihre Aufmerksamkeit! Noch Fragen? Gern jetzt im Anschluss :-) sonst per Manuel Haim, Quellennachweis: Viele Icons in dieser Präsentation entstammen dem Crystal Project (GNU LGPL). 21