Microservices, Integration

Die Microservices Architektur bietet den Vorteil der freien Technologieauswahl bei jedem Microservice. Ein wichtiger Punkt unseres Evaluierungsprojektes war die Prüfung der Integrationsfähigkeit von Softwarekomponenten, welche nicht Java, bzw. Spring Cloud im Technologiestack enthalten. Dazu möchte ich in diesem Beitrag unserer Blogserie zeigen auf welche Art und Weise wir legacy Software, wie zum Beispiel Fedora4 Content Repository in die „Platform Service“ der Microservices Welt integriert haben.

 

Integration

Für die Integration solcher “nicht Java basierten Softwarekomponenten” stellt Netflix Open Source Stack (Netflix OSS) das Projekt Prana bereit. Prana ist eine sogenannte Sidecar Anwendung. Durch die Nutzung von Prana ist es möglich die “Platform Service“, wie zum Beispiel Eureka, Circuit Breaker und Ribbon in solchen Projekten zu verwenden. Wie der Name “Beistellwagen” schon verrät wird das Prana Projekt lediglich neben den nicht Netflix fähigen Microservice gestellt und konfiguriert. Wie genau das funktioniert, möchte ich gerne an folgendem konkreten Beispiel demonstrieren.

 

Dazu haben wir im ersten Schritt ein Spring Boot Projekt aufgesetzt und Spring Cloud Sidecar durch folgende Annotation an der “main” Klasse aktiviert.

 

@EnableSidecar

@SpringBootApplication

public class SideCarApplication {

 

public static void main(String[] args) {

SpringApplication.run(SideCarApplication.class, args);

}

}

 

Anschließend müssen im Sidecar Projekt noch folgende Properties gesetzt werden:

 

spring.application.name=Fedora4-Sidecar

server.display-name=Staatsbibliothek Fedora Sidecar

server.port=9080

sidecar.health-uri=http://localhost:8080/rest/health.json

sidecar.port=8080

sidecar.home-page-uri=http://localhost:8080/

 

Mit der Angabe der health-uri wird auf einen REST Endpunkt der Fedora4 Anwendung verwiesen, aus welchem Sidecar die Statusinformation zur Übermittlung an Eureka erhält. Dazu haben wir im Fedora4 folgendes triviales JSON Dokument hinterlegt:

health.json

{“status”:”UP”}

Bei erreichbarem Fedora4 kann Sidecar nun diese Statusinformation an Eureka übermitteln. Sidecar muss auf demselben Server laufen wie Fedora4. Zusätzlich zur Sidecar Konfiguration müssen natürlich noch die Konfigurationswerte für Eureka, Hystrix und Ribbon gesetzt werden. Um Fedora4 in Eureka sichtbar zu machen haben wir daher für die Service Registry folgende Werte gesetzt:

 

eureka.instance.leaseRenewalIntervalInSeconds=10

eureka.client.healthcheck.enabled=true

eureka.client.serviceUrl.defaultZone=http://localhost:8761/serviceregistry/eureka/

eureka.client.registryFetchIntervalSeconds=5

 

Ist Fedora4 gestartet zeigt Eureka die Integration wie folgt an:

fedora-sidecar

Ist das Sidecar Projekt gestartet und verfügbar, kann anschließend Fedora4 über folgende URL angesteuert werden:

 http://<hostname>:9080/fedora4-sidecar/

 

Welche Vorteile bringt uns diese Integration nun aber ganz konkret.

 

  • ohne Fedora4 anpassen zu müssen, lässt es sich in die “Platform Services” von Netflix integrieren,
  • Fedora4 ist damit in der Service Registry sichtbar und abrufbar,
  • ein Aufruf von Fedora4 über die Sidecar URL wird als Circuit Breaker Command ausgeführt,
  • es werden Hystrix Metriken generiert welche im Hystrix Dashboard sichtbar sind,
  • es kann Load Balancing verwendet werden, sobald Fedora4 mehrfach installiert ist,
  • es kann die zentrale Configuration Management Instanz verwendet werden.

 

Obwohl Fedora4 kein Microservice ist können Client Anwendungen die Service Registry nach der Einstiegs URL von Fedora4 fragen. Anschließend wird jede Anfrage der Clients via Hystrix abgesichert und aufgezeichnet. So konnten wir zum Beispiel die Antwortzeiten der Fedora4 REST API im Hystrix Dashboard aufzeichnen und auswerten.

hystrix-fedora

All diese Vorteile sind ohne eine einzige Anpassung des Fedora4 Systems möglich. Auf dieselbe Art  und Weise haben wir einen reinen Javascript Microservice eingebunden.

 

Fazit

Wie dieser Beitrag zeigt, ist die Integration einer Softwarekomponente, welche nicht den Netflix Stack via Bibliotheken Integration nutzen kann, sehr einfach. Die aufgezeigten Möglichkeiten, welche sich dadurch bieten finde ich beeindruckend. Hinzufügen muss ich allerdings, dass sich auf diese Art und Weise nur Softwarekomponenten integrieren lassen, welche über eine REST API angesprochen werden können. Da alle Aufrufe dieser REST API über Sidecar geroutet werden. Für Softwarekomponenten ohne REST API ist die Integration ebenfalls möglich aber etwas aufwendiger.

Werkstattgespräch zu den Kalligrafischen Druckschriften Hermann Zapfs am 7.6.

Wissenswerkstatt
Kalligrafische Druckschriften Hermann Zapfs – von “Virtuosa” bis “Zapfino”
Werkstattgespräch mit Dr. Nikolaus Weichselbaumer, Johannes Gutenberg-Universität Mainz

Dienstag, 7. Juni
18.15 Uhr
Konferenzraum 4, Haus Unter den Linden (Eingang über Dorotheenstraße 27)
Treffpunkt in der Eingangshalle (Rotunde)

Eintritt frei, Anmeldung erbeten

 

Hermann Zapf (1918-2015) war einer der einflussreichsten Kalligrafen, Buch- und Schriftgestalter des 20. Jahrhunderts. Sein Werk überspannt mehr als sieben Jahrzehnte, in denen er für alle Schrifttechnologien der Druckgeschichte gearbeitet hat – vom Bleisatz bis zur modernen Font-Datei. Eine zentrale Rolle in diesem Oeuvre nehmen kalligrafische Schriften ein, die für Gestalter durch ihre ausladenden und unregelmäßigen Formen eine besondere Herausforderung darstellen. Der Vortrag stellt Zapfs wichtigste kalligrafische Schriftentwürfe in die Traditionslinien der Typographiegeschichte und rekonstruiert auf Basis erhaltener Entwurfszeichnungen und ergänzender Quellen Zapfs Arbeitstechniken. Besondere Aufmerksamkeit liegt auf der Bedeutung von Technologie für die Formgebung von Schriften.

Eine Veranstaltung aus der Reihe “Die Materialität von Schriftlichkeit

Prima zum Imprimatur: Publikationsberatung für Promovierende

Nicht zuletzt die mehr als 100 strukturierten Graduiertenprogramme, die das Portal Doctoral Programs in Berlin verzeichnet, machen die Hauptstadt mit ihren vier großen Universitäten und zahllosen Forschungseinrichtungen zu einem beliebten Pflaster für Promotionswillige. Da aber der Weg zum Doktorhut nicht selten schmerzhaft hart gepflastert ist – bekanntlich geht es ja immer nur per aspera ad astra – , sind informationspraktische “Blasenpflaster” auch in den Graduiertenschulen und -kollegs gerne willkommen. Und in genau dieser Absicht hat die Staatsbibliothek zu Berlin bereits vor einiger Zeit in ihrer Wissenswerkstatt ein zielgruppenspezifisches Veranstaltungsformat zum wissenschaftlichen Publizieren für Promovierende entwickelt oder – um im Bild zu bleiben – zusammengeschustert. Dieses möchte dazu beitragen, drückende Hemmschuhe aufzuschnüren und Sie möglichst leichtfüßig auf die letzte Etappe zur Erlangung Ihres akademischen Ritterschlags zu schicken. Denn erst mit der fristgerechten Veröffentlichung der Dissertationsschrift – darin sind sich die Promotionsordnungen aller Fakultäten einig – hat das Promotionsverfahren seinen formalen Endpunkt erreicht. Schließlich muss sich Ihre eigenständige Forschungsleistung, um überhaupt als solche gelten zu können, nicht nur in der Disputation – mithin im Kreuzverhör einer universitätsinternen Fachöffentlichkeit – behaupten, sondern später auch im Säurebad von Wissenschaftsdiskurs und Plagiatserkennungssoftware bestehen.

Konkret versuchen wir im Rahmen unseres quartalsweise angebotenen zweiteiligen Workshops Publish or Perish!? Wissenschaftliches Publizieren für Promovierende, Ihnen einige Tipps zur strategischen Wahl des für Sie „richtigen“ Publikationsorts zu geben – sei dieser nun möglichst reputationsförderlichen oder vielleicht besonders kostengünstig –, den Paragraphendschungel des Verlagsvertragsrechts zu lichten, juristische Fragen bei der Nutzung von Bildern zu klären und Ihnen die Akquise von Druckkostenzuschüssen zu erleichtern. Mit Blick auf den gegenwärtigen Strukturwandel der Wissenschaftskommunikation und die daraus resultierende Vervielfachung neuer Publikationsformen zielt Publish or Perish!? zugleich darauf, die Felder von Open Access, Forschungsdatenmanagement und (alternativer) Bibliometrie zumindest in groben Zügen zu kartieren.

Allerdings legt es gerade die erst kürzlich angesprochene neue Unübersichtlichkeit des wissenschaftlichen Publikationsmarkts nahe, mit einer Öffnung dieses Veranstaltungsformats zu experimentieren, zumal die Staatsbibliothek zu Berlin bei der Konzeption innovativer Beratungsangebote ohnehin im Netzwerk Informationskompetenz Berlin/Brandenburg mit zahlreichen anderen wissenschaftlichen Bibliotheken kooperiert. Im Rahmen dieser regionalen Zusammenarbeit haben wir daher das Programm von Publish or Perish!? in selbstständige Module gesplittet, um den Aspekt der Literaturverwaltung erweitert und mit unseren Berliner Partnerbibliotheken an der Freien, Technischen und Humboldt-Universität vereinbart, die inhaltliche Verantwortung für die einzelnen Veranstaltungen zu verteilen – und zwar in Abhängigkeit der Kompetenzschwerpunkte der jeweiligen Einrichtung. Klar, dass beispielsweise der Beitrag zum Forschungsdatenmanagement insofern geradezu zwingend von den Universitätsbibliotheken der Technischen Universität sowie der Humboldt-Universität zu leisten ist, haben doch beide Einrichtungen nicht nur vielfältige Beratungsservices (HU | TU) in diesem Bereich aufgebaut, sondern darüber hinaus auch technische Infrastrukturen – darunter institutionelle Forschungsdatenrepositorien sowie entsprechende disziplinäre Angebote für die historische Linguistik oder die Akustikwissenschaften.

Um dem gemeinsamen Vorhaben einen angemessenen Rahmen zu geben und der rasant zunehmenden Bedeutung von digitalen Informationsinfrastrukturen für den Forschungsprozess gerecht zu werden, eröffnet Prof. Dr. Reinhard Förtsch, IT-Direktor des auf den Feldern von eResearch und Open Science dynamisch agierenden Deutschen Archäologischen Instituts, die Veranstaltungsreihe mit dem Keynote-Vortrag Dissertation als empfohlene Insellösung? Individualismus versus Infrastruktur.

Seien Sie also recht herzlich eingeladen, zwischen 15. Juni und 11. Juli an der insgesamt sechsteiligen Veranstaltungsreihe für Promovierende Lost in Dissertation? Von der Literaturverwaltung bis zur Publikation teilzunehmen – ganz gleich, ob durchgängig oder gezielt zu einzelnen Terminen. In jedem Fall aber freuen wir uns schon auf Sie und hoffen, dass Ihre Dissertation mit Hilfe unserer bibliothekarischen List von einer Last zur reinen Lust werden wird.

Microservices, Widerstandsfähigkeit

Widerstandfähigkeit eines Microservices Systems in Bezug auf Serviceausfälle oder Netzwerklatenz war ein wichtiger Aspekt, welchen wir in unserem Microservices Projekt eingehend untersuchen wollten. Daher freue ich mich dieses Thema und unsere Erfahrungen in unserer Blogserie etwas eingehender beleuchten zu können.

Widerstandsfähig bezieht sich hierbei auf die Client Anwendung, welche die einzelnen nachgelagerten Microservices verwendet. Dieser Begriff meint dabei, dass die Client Anwendung auch im Fall von Netzwerk- bzw. Serviceausfällen nicht blockiert und immer noch durch den Anwender verwendet werden kann. Blockieren kann die Anwendung zum Beispiel, wenn diese einen Microservice verwendet, welcher sehr viel Zeit benötigt, um eine Antwort im Netzwerk bereit zu stellen. Warum dieser Microservice nicht schnell genug antwortet, spielt bei dieser Betrachtung keine Rolle. Die Client Anwendung wartet solange bis entweder die Antwort eintrifft oder aber ein zuvor definierter Timeout einen Fehler erzeugt. Eine hohe Wartezeit einer Anfrage kann bei starker Verwendung der Client Anwendung dazu führen, dass immer mehr Anfragen der Nutzer das System immer stärker blockieren. Ein Blockieren der Client Anwendung kann aber auch durch eine Überlastung des Netzwerks ausgelöst werden. Die Client Anwendung fühlt sich in solchen Fällen für den Nutzer träge und langsam an. Im Falle von Webanwendungen verlässt der Nutzer in der Regel dann sehr schnell die Seite.

 

Als Lösung für solche Situationen bietet der Netflix OSS das Projekt Hystrix, als sogenannte „Circuit Breaker“ Bibliothek, an. Ein „Circuit Breaker“ ist eine Sicherung, welche ausgelöst wird, sobald gewisse Umstände eintreten. Hystrix bietet darüber hinaus viele zusätzliche Funktionalitäten:

 

  • kapselt ein Kommando und bietet synchrone und asynchrone Ausführung,
  • löst nach definiertem Timeout die Sicherung aus,
  • führt jedes Kommando in einem definierten Thread Pool aus,
  • auslösen der Sicherung bei zu hoher Fehlerrate eines Kommandos,
  • ermöglicht die Ausführung eines Fallbacks im Fehlerfall,
  • erzeugt Performance Metriken,
  • ermöglicht die Nutzung eines Caches.

 

Alle diese Funktionalitäten stehen zur Verfügung, sobald ein in der Client Anwendung ausgeführtes Kommando in ein “HystrixCommand” überführt wird. Meiner Meinung nach ist es wichtig, den nachfolgend abgebildeten Ablauf der Ausführung eines Hystrix Kommandos zu verstehen.

Abbildung .1: Netflix, Hystrix Command Fflow Chart, Web URL: https://github.com/Netflix/Hystrix/wiki/How-it-Works [Stand 2016-05-25]

Abbildung .1: Netflix, Hystrix Command Flow Chart, Web URL: https://github.com/Netflix/Hystrix/wiki/How-it-Works [Stand 2016-05-25]

Die detaillierte Beschreibung des Ablaufs finden Sie hier. Der Grund, warum ich diese Abbildung hier aufgeführt habe ist, dass diese sehr schön zeigt, dass Hystrix nicht nur ein reiner Ciruit Breaker ist. Wie zu erkennen ist, bietet Hystrix ein definiertes Verfahren zur Absicherung eines Netzwerkkommandos. Es besteht mit Hilfe der Hystrix Metriken die Möglichkeit sehr einfach und bequem Antwortzeiten auszuwerten. Durch die Integration konnten wir in unserem Projekt die Antwortzeiten eines Fedora4 Content Repository Servers, eines EMC S3 Object Storage Servers und des lokalen Dateisystems vergleichen. Die Hystrix Metriken konnten wir sehr einfach mittels des Hystrix Dashboards visualisieren und in Echtzeit auswerten. So kann auch in produktiven Umgebungen die Reaktions- bzw. Widerstandsfähigkeit einzelner Systeme optimal bewertet werden. Dies ersetzt natürlich keine umfassende Monitoringlösung, bietet aber die Möglichkeit, die Auslastung einzelner Systeme schnell zu erkennen und richtig zu behandeln.

 

Die Integration

Die Integration von Hystrix ist, wie auch bei den anderen “Platform Services” Komponenten, einmal mittels der nativen Netflix Bibliothek oder aber auch über das Spring Cloud Projekt möglich. In unserem Projekt haben wir beide Möglichkeiten erfolgreich durchgeführt.Spring Cloud bietet eine sehr einfache und leichte Integration via Annotation:

 

Beispiel:

@HystrixCommand(commandKey = “DMS->EMCS3:findObjectContent”, groupKey = “DMS->EMCS3”)

 

Hierbei wird lediglich der Name des Kommandos und des Threadpools definiert. Es ist über die Zusatzbibliothek hystrix-javanica zusätzlich möglich, alle Konfigurationswerte direkt in der Annotation aufzuführen. Wir haben uns allerdings dazu entschieden, die Konfiguration in der zentralen „application.properties“ Datei durchzuführen.

 

Im Bereich der nativen Netflix Bibliothek ist die Integration ebenfalls sehr leicht. Nach dem Einbinden der Abhängigkeiten hystrix-core und hystrix-metrics-event-stream kann die Integration durchgeführt werden. Die Klasse, mit welcher ein Kommando im Netzwerk ausgeführt wird, muss lediglich die Klasse HystrixCommand erweitern und die Methode run() implementieren. Die Konfiguration erfolgt über die Datei “eureka-client.properties”.

Bei einigen Standardwerten der Konfiguration mussten wir Anpassungen vornehmen, da Hystrix die Sicherung für unseren Anwendungsfall zu schnell ausgelöst hat. Dies ist uns bei Belastungstests mit dem Werkzeug JMeter aufgefallen. Letztendlich konnten wir mit folgenden Einstellungen ein sehr gutes Antwortverhalten bei einer stark belasteten Komponente erzeugen:

 

hystrix.command.default.execution.isolation.strategy=THREAD

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=120000

hystrix.command.default.execution.isolation.thread.maxConcurrentRequests=1024

hystrix.command.default.fallback.isolation.thread.maxConcurrentRequests=1024

hystrix.threadpool.default.coreSize=1024

hystrix.threadpool.default.maxQueueSize=1024

hystrix.threadpool.default.keepAliveTimeMinutes=2

hystrix.threadpool.default.queueSizeRejectionThreshold=15

hystrix.threadpool.default.metrics.rollingStats.numBuckets=12

hystrix.threadpool.default.metrics.rollingStats.timeInMilliseconds=1440  

 

Sich diese Konfigurationswerte genau zu betrachten und diese festzulegen, ist ein wichtiger Schritt bei der Integration von Hystrix. Allerdings muss natürlich jeder selbst entscheiden, welche Werte für welches Kommando sinnvoll sind.

 

Fazit

Die Integration ist, wie bereits bei den anderen “Platform Services” des Netflix OSS, nicht sehr aufwendig. Dieses Werkzeug, finde ich persönlich, wegen der vielen zusätzlichen Funktionalitäten sehr interessant und nützlich. Es bietet eine standardisierte Lösung, um ein Netzwerkkommando gesichert auszuführen, ein Fallback zur Verfügung zu stellen, einen Cache zu nutzen und Performancemesswerte zu erzeugen. In Zukunft werde ich für mich persönlich daher immer bewerten, ob nicht die Verwendung dieser Bibliothek bei jeglichen Netzwerkzugriffen eines Projektes sinnvoll ist.

Von Hamburgern und Kahlenbergern

Zu den angenehmen Aufgaben des Inkunabelreferats gehört es, Präsentationen und Seminare für auswärtige Gäste und Studierende zu veranstalten. Ein schon zur Tradition gewordener Termin für solche Workshops ist die Pfingstwoche – der klassische Exkursionszeitraum an vielen deutschen Universitäten. Dabei ermöglicht die außerordentliche Breite und Tiefe der Handschriften- und Inkunabelbestände der Staatsbibliothek, (fast) alle konkreten Seminarthemen und Forschungsvorhaben mit Anschauungsmaterial zu versorgen.

Weiterlesen

Dank an die Mitarbeiter/innen der Bibliothek

Mit großer Freude nahmen die Vertreter der Staatsbibliothek zu Berlin am Abend des 18. Mai den vom Historiker, Publizisten und Kulturmanager Oliver Hilmes öffentlich ausgesprochenen Dank für die inzwischen 20-jährige Unterstützung bei seiner vielfältigen Arbeit entgegen. An dem Abend stellte er sein Buch “Berlin 1936. Sechzehn Tage im  August” vor. Bevor es jedoch zur eigentlichen Lesung kam, würdigte Oliver Hilmes die nun schon viele Jahre dauernde enge Beziehung zu ‘seiner Bibliothek’. Hier träfe er nicht nur stets auf hilfsbereite Bibliothekare sondern ebenso auf genau jene Literaturbestände, die er für seine Arbeiten benötige.

DEUTSCH-RUSSISCHER BIBLIOTHEKSDIALOG AM 23. MAI IN DRESDEN

Seit dem Jahr 2009 finden regelmäßig Treffen des Deutsch-Russischen Bibliotheksdialogs statt, um über die Auswirkungen des Zweiten Weltkrieges, die Verlagerungen von Buchbeständen und neue Möglichkeiten der Zusammenarbeit zu sprechen. Nach Treffen in Moskau, Berlin, Perm, Leipzig und Saratow findet der sechste Bibliotheksdialog am kommenden Montag, 23. Mai 2016, ganztägig in der Sächsischen Landesbibliothek – Staats- und Universitätsbibliothek Dresden (SLUB) statt.

Die von der Kulturstiftung der Länder, der Stiftung Preußischer Kulturbesitz und dem russischen Kulturministerium geförderte Tagung wird von den beiden Sprechern Barbara Schneider-Kempf (Berlin) und Wadim Dudá (Moskau) eröffnet.

Die russischen und deutschen Beiträge sind der Rekonstruktion verlagerter Sammlungen, der Provenienzforschung und den Möglichkeiten digitaler Erschließung und Präsentation gewidmet. Ein Sammelband mit 36 Beiträgen zu den ersten fünf Tagungen dokumentiert bisherige Erkenntnisse und die inhaltliche Vielfalt des Dialogs, z.B. die Spurensuche nach der Wallenrodt´schen Bibliothek in Königsberg, die Arbeiten mit Verlustkatalogen, die Rückführung der Esterhazy-Sammlung nach Österreich oder die Erfahrungen des seit 2005 bestehenden russisch-deutschen Museumsdialogs. Dieses Buch ist der verstorbenen Bibliotheksdirektorin Jekaterina Genijewa (1946-2015) gewidmet, die den Bibliotheksdialog von Anfang an prägte.

Ihr Nachfolger Wadim Duda, Generaldirektor der Allrussischen Staatlichen Rudomino-Bibliothek für ausländische Literatur, berichtet bei der Dresdner Tagung über die Digitalisierung wertvoller Buchbestände. Die deutschen Bibliotheken in Berlin und Bremen, Dresden und Weimar, Gotha und Leipzig sehen viele Möglichkeiten kultureller und wissenschaftlicher Zusammenarbeit in digitalen Netzwerken. „Die Digitalisierung unserer reichen Bibliotheksbestände“, so Gastgeber Prof. Dr. Thomas Bürger von der SLUB Dresden, „hat der weltweit vernetzten kulturellen und wissenschaftlichen Forschung und Zusammenarbeit neue Impulse geben und innovative Möglichkeiten eröffnet. Umso mehr freuen wir uns auf den Wissensaustausch und die weitere Zusammenarbeit mit den russischen Kolleginnen und Kollegen.“

Ihr Pressekontakt in Dresden:
antonie.muschalek@slub-dresden.de, 0351 / 4677 342

Ihr Pressekontakt in Berlin:
jeanette.lamble@sbb.spk-berlin.de, 030 / 266 43 1444

„Wissenschaftler dieser Welt, kommt nach Berlin in diese Bibliothek und forscht!“ Barbara Schneider-Kempf ist neue Botschafterin für „Brain City“

Die Kampagne „Brain City“, initiiert vom Hauptstadtmarketing der Stadt Berlin, verfolgt – als Teil der Imagekampagne „be Berlin“ – das Ziel, Wissenschaft als Standortfaktor für Berlin besser sichtbar zu machen. Die Wissenschaft soll stärker in den Fokus der Standortvermarktung rücken. Dazu wurde gemeinsam mit vielen wissenschaftlichen Einrichtungen Berlins (Hochschulen, Forschungseinrichtungen, Zukunftsorte, Stiftungen, Institute) eine Botschafterkampagne entwickelt. Derzeit stehen 18 Wissenschaftlerinnen und Wissenschaftler aus diesen Einrichtungen als Testimonials bereit und verbreiten über ihre Kanäle Berlins exzellenten Ruf als Wissenschaft- und Forschungsmetropole. Ausführende Firma ist die Berlin Partner für Wirtschaft und Technologie GmbH.

Alsbald rückte auch die Staatsbibliothek in das Interesse von „BrainCity“: auch die größte wissenschaftliche Universalbibliothek in Deutschland böte, so stellten die Verantwortlichen fest, einen guten Ausgangspunkt für die Verbreitung von wissenschaftlicher Exzellenz „made in Berlin“. Vor diesem Hintergrund lud man Barbara Schneider-Kempf, Generaldirektorin der Staatsbibliothek, ein, ebenfalls als „Wissenschafts-Botschafterin“ zu fungieren. Der ‚Claim‘ nun hier:

e-day! Elektronische Ressourcen für das moderne wissenschaftliche Arbeiten am 1.6.

Wissenswerkstatt
e-day!
Elektronische Ressourcen für das moderne wissenschaftliche Arbeiten
Mittwoch, 1. Juni 2016
10 bis 16 Uhr
Haus Potsdamer Straße 33
Zentraler Treffpunkt in der Eingangshalle

Zur Webseite mit Programm
Flyer mit Programm

Wegen des großen Erfolgs in den vorhergehenden Jahren findet der e-day der Staatsbibliothek zu Berlin nun schon zum sechsten Mal statt. Mit jeweils 30-minütigen Vorträgen wird der ständig wachsende Bestand an elektronischen Aufsätzen, Zeitungen, Büchern, Bildern und bibliographischen Informationen vorgestellt. In diesem Jahr stehen die Themen Geschichte, Kunst, Sozialwissenschaften und Philologien im Zentrum. Mit den Demonstrationen zur wissenschaftlichen Internetrecherche, zu E-Books und Digitalisaten wird das breite Repertoire an Datenbanken, Internetportalen und Repositorien bekannt gemacht. Zu den besonderen Präsentationen gehören eine Erste-Schritte-Strategie zur Recherche oder Literaturverwaltung, aber auch zur Nutzung besonderer Medien wie Karten oder Zeitungen.

Zwischen und nach den Vorträgen ist Gelegenheit, das Gehörte gleich auszuprobieren und mit den Informationsspezialisten ins Gespräch zu kommen.

Wie immer ist der e-day ein kostenloser Service für alle Besucher, die gern auch künftige Benutzer sein können.

Fragen beantworten wir gern unter unserer Fachinfo-Mail  oder telefonisch unter 030 266 433 162.

Alle Termine der Wissenswerkstatt

 

Microservices, Load Balancing

Die Prüfung der Skalierbarkeit von Microservices war ein weiteres sehr wichtiges Thema in unserem Microservices Projekt. Im Rahmen unser dazugehörigen Blog Serie möchte ich hier das Thema Load Balancing im Kontext der Microservice Architektur näher beleuchten. Häufig werden im Bereich der Bibliothekssysteme zentrale Dienste, wie zum Beispiel ein zentrales Dokumentenmanagement wie Fedora oder eine zentrale Suche mit Solr oder Elasticsearch benötigt. In unserem Projekt wollten wir herausfinden, wie und mit welchem Aufwand Services dynamisch skaliert werden können. Dies bedeutet, dass in Situationen in welchen die Client Anwendungen durch die Nutzer der Bibliothek stark verwendet werden, die Services dynamisch auf zusätzliche Server installiert und anschließend verwendet werden. Dynamisch bedeutet an dieser Stelle automatisiert und damit ohne Administrations-, Konfigurations- bzw. Entwicklungsaufwand.

Wie in unserem ersten Beitrag beschrieben, bietet die Microservices Architektur unter anderem den Vorteil der einfacheren und genaueren Skalierung einzelner Microservices. Wird nun eine Softwarekomponente bzw. ein Service auf mehrere Server automatisiert installiert, müssen diese auch durch die Anwendungen genutzt werden können. Als Teil der „Platform Services“ bietet der Netflix Open Source Stack (Netflix OSS) auch hier eine sehr gute Lösung. Bevor ich die konkrete Lösung vorstelle, möchte ich noch etwas zur Theorie des Load Balancing sagen. Grundsätzlich gibt es zwei wesentliche Varianten um dieses aufzubauen.

 

Zentrales Load Balancing.

Dabei wird ein zentraler Load Balancer zwischen den Client Anwendungen und den Services aufgebaut. Alle Anfragen der Clients werden über den Load Balancer geroutet und dieser verteilt die Anfragen nach einem bestimmten Verfahren auf die einzelnen Service Instanzen. Ein Nachteil dieser Lösung ist, dass der Load Balancer ein Single Point of Failure ist. Dies bedeutet, dass wenn diese Komponente ausfällt bzw. stark überlastet ist, sie keine Anfragen mehr von den Anwendungen zu den Services weiterleitet.

Zentrales Load Balancing

Zentrales Load Balancing

Dezentrales Load Balancing

Hierbei hält die Client Anwendung alle Informationen, welche Service Instanzen verfügbar sind, bei sich lokal vor. Diese Informationen werden regelmäßig aktualisiert, sodass die aktuelle Situation der verfügbaren Services dem Client jederzeit bekannt ist. Die Client Anwendung entscheidet mit Hilfe eines eingebauten Load Balancing Mechanismus selbst, welche Service Instanz für eine Anfrage verwendet wird. Damit ist keine zentrale Load Balancer Instanz mehr notwendig und es gibt keinen Single Point of Failure. Auch bei dieser Lösung gibt es wiederum Nachteile, dass zum Beispiel die lokale Information, welche Instanzen der Services verfügbar sind, veraltet sein kann.

Dezentrales Load Balancing

Dezentrales Load Balancing

Die einzelnen Load Balancing Verfahren, nach welchem Algorithmus eine von mehreren verfügbaren Service Instanzen ausgewählt wird, möchte ich hier nicht aufführen, da es in diesem Beitrag um die Integration im Bereich der Microservices Architektur geht und nicht um das Load Balancing als solches. Der Netflix OSS bietet mit der Bibliothek Ribbon eine Möglichkeit des dezentralen, client-seitigem Load Balancing. Die Information, welche Service Instanzen auf welchem Server verfügbar sind, basieren auf den Informationen aus der Service Registry Eureka. Durch die Integration von Eureka ist das Load Balancing dynamisch und wird jederzeit an die verfügbaren Instanzen angepasst. Es ist auch möglich, Ribbon ohne Eureka einzusetzen, was hier aber nicht näher erläutert werden soll, da es für den produktiven Einsatz nicht empfohlen werden kann.

 

Unsere Erfahrungen

Die Integration von Ribbon in eine Client Anwendung ist einmal mit der Spring Cloud oder aber durch die Einbindung der nativen Netflix Bibliothek möglich. Bei beiden Varianten gibt es jeweils die Möglichkeit mittels direkter Verwendung eines Ribbon Clients das Load Balancing zu integrieren oder die Methode REST Templates zu definieren und zu verwenden. Beide Varianten unterscheiden sich vom Aufwand nicht. Elegant bei der Template Variante ist aus meiner Sicht die Trennung der Definition der zur Verfügung stehenden Funktionalität und deren Verwendung. So können zentral alle zur Verfügung stehenden Templates definiert und diese anschließend an den unterschiedlichsten Stellen eingesetzt werden. Dies vereinfacht die Wartung der bestehenden Möglichkeiten sehr stark. Allerdings konnten wir beim Einsatz des REST Templates für einen HTTP POST Request mit Multipart Upload nicht erfolgreich umsetzen. Beim Absetzen des HTTP POST Request wurde jeweils folgender Fehler gemeldet:

the request was rejected because no multipart boundary was found

Bisher haben wir noch keine Antwort zu unsere Anfrage nach einer Lösung aus der ribbon usergroup erhalten. Zusätzlich zur Integration im Quellcode muss das Load Balancing noch konfiguriert werden. Hier kann zum Beispiel auch zwischen den möglichen Verteilungsverfahren gewählt werden. Ribbon unterstützt zum Beispiel folgende:

  • RoundRobinRule
  • AvailabilityFilteringRule
  • WeightedResponseTimeRule

Alle Details zur Konfiguration von Ribbon können im Wiki des Projektes nachgelesen werden. Zusammenfassend können wir sagen, dass die Integration von Ribbon in eine Anwendung ohne großen Aufwand umzusetzen ist und sehr zuverlässig funktioniert. Bis auf die Ausnahme des HTTP POST Multipart Request sind wir auf keine weiteren Schwierigkeiten gestoßen.

 

Einsatz des Load Balancing

Unsere Client Anwendungen im Pilotprojekt bietet die Funktion eines Upload von XML Dateien. Diese lädt die Dateien nach der Auswahl im Browser via einer REST Schnittstelle in ein Dokumentenmanagementsystem (Microservice). In die Client Anwendungen haben wir das Load Balancing mit Hilfe der nativen Netflix Bibliothek integriert. In einem Test eines Ausfalls von einem der Dokumentenmanagement Services während des Uploads von 1000 XML Dateien konnten wir zeigen, dass der Upload nicht beeinträchtigt wird. Der Anwender bemerkt nicht, dass zu Beginn des Uploads noch zwei und während des Uploads nur noch eine Service Instanz des Dokumentenmanagement Services die Daten speichert. Ohne den Einsatz von Eureka und Ribbon wäre der Upload bei Ausfall des Dokumentenmanagement Services abgebrochen.

 

Fazit:

Auch für das Thema Load Balancing kann ich den Einsatz für zentrale Services in Kombination mit einer Service Registry nur stark empfehlen. Der Aufwand der Integration in eine Java Anwendung ist meines Erachtens eher gering und lohnt sich. Nach Abschluss der Integration können die Microservices einfach skaliert und die Client Anwendung kann so jederzeit stärker verwendet werden und reagiert robuster auf Ausfälle.