Virtualisierung des Bibliothekssystems Aleph 500. ITEK Präsentation Uwe Sujata

Größe: px

Ab Seite anzeigen:

Download "Virtualisierung des Bibliothekssystems Aleph 500. ITEK Präsentation 10.02.2010 Uwe Sujata"

Elizabeth Schräder
vor 8 Jahren
Abrufe

1 Virtualisierung des Bibliothekssystems Aleph 500 ITEK Präsentation Uwe Sujata

2 Agenda 1. Ausgangslage 2. Ziele 3. Meilensteine 4. Projektverlauf 5. Systemdesign 6. Abgleich DLV / OLA 7. Risiken / Entscheidungen 8. Fazit 2

3 Ausgangslage Das Bibliothekssysten Aleph 500 wird auf einem Sun Sparc System unter dem Betriebssystem Solaris betrieben. Dieses System entspricht den Ansprüchen an Leistung und Zuverlässigkeit nicht mehr, zudem verursacht es hohe Wartungskosten. Es soll daher spätestens Ende 2009 durch ein System aktueller Architektur ersetzt werden. Für die ETH Bibliothek stellen sich folgende Fragen: Ist es möglich Aleph 500 auf virtuellen Servern unter dem Betriebssystem Linux zu betreiben? Kann der systemtechnische Teil des Betriebs an die Informatikdienste ausgelagert werden, um den Applikations und Datenbankspezialisten der Bibliothek die Konzentration auf die Betreuung der Applikation Aleph 500 zu ermöglichen? Im Rahmen des Projekts sollen diese Fragen anhand einer Pilotinstallation von Aleph 500 auf der virtuellen Infrastruktur der Informatikdienste beantwortet werden. 3

Es soll daher spätestens Ende 2009 durch ein System aktueller Architektur ersetzt werden.

4 Ziele Installation von Aleph 500 auf der virtuellen Infrastruktur der Informatikdienste Nachweis von Funktionalität, Leistungsfähigkeit und Stabilität Erarbeiten eines SLAs, welches den Betrieb von Aleph 500 und die diesbezügliche Zusammenarbeit zwischen Bibliothek und Informatikdiensten regelt. 4

Stabilität Erarbeiten eines SLAs, welches den Betrieb von Aleph 500 und

5 Meilensteine Q3 2007: Projektstart, Machbarkeitsabklärungen mit den Softwareherstellern Q2 2008: Pilotinstallation für Last, Funktionalitäts und Stabilitätstests bereit Q4 2008: Technische Machbarkeit nachgewiesen und betriebliche Aufgabenteilung zwischen Bibliothek und Informatikdiensten definiert Q2 2009: SLA erarbeitet und verabschiedet, Beschluss der Migration des produktiven Aleph 500 Systems auf die virtuelle Infrastruktur Q4 2009: Beginn des Produktionsbetriebs 5

Aufgabenteilung zwischen Bibliothek und Informatikdiensten definiert Q2 2009: SLA erarbeitet und verabschiedet,

6 Überblick Projektverlauf Lasttests mit 4 CPUs VM Server zeigen ungenügende Performance Erneuter Versuch mit VMWare ESX Release mit 8 CPUs im Juni 2009 ist erfolgreich Oracle Lizenzierung geklärt Operating Level Agreement unterzeichnet Infrastrukturaufbau, Installationen und Migrationsvorbereitung aller 3 Systeme waren bis November 2009 abgeschlossen Terminverschiebung durch ZB auf Januar

Operating Level Agreement unterzeichnet Infrastrukturaufbau, Installationen und

7 System Design VBA500 Produktion 7

8 System Design VBA500 Test 8

9 System Design VBA500 Schulung 9

10 Abgleich DLV/OLA Operating Level Agreement (OLA) Service Levels Verantwortlichkeiten Technologische Infrastruktur beschaffen und warten Kontinuierlichen Betrieb sicherstellen IT Performance monitoren Patches und Changes installieren Betrieb, Daten, Performance, Changes, Konfiguration, Incidents und Problems managen Service Desk bzw. Ansprechpersonen Leistungen von Dritten managen Security sicherstellen Kosten identifizieren und verrechnen DLV und OLA werden gemeinsam zu einer Vereinbarung abgeglichen 10

Performance, Changes, Konfiguration, Incidents und Problems managen Service Desk bzw.

11 Risiken/Entscheidungen Neuer VMWare ESX Release mit 8 CPUs Oracle Lizenzierung basierend auf dedizierten Servern Oracle Support Statement Verhalten der Legacy Anwendung Aleph 500 Gemäss Hersteller Ex Libris ist dies die erste Virtualisierung dieser Art 11

Support Statement Verhalten der Legacy Anwendung Aleph 500

12 Fazit Die technischen Projektziele waren nicht einfach zu erreichen Die neue Infrastruktur läuft stabil Erfreuliche Zusammenarbeit mit den Kollegen der ID Es konnte nicht alles im Vorfeld mit vertretbarem Aufwand getestet werden Weiterer Tuningbedarf Performanceproblem bei ca. 5 % der Transaktionen sogenannte Longrunner Aufwändige Analysen mit eigenen Testprogrammen Kommunikation zwischen Applikations und DB Server Alte Legacy Anwendungen können sich sich unberechenbar verhalten Weiteres Leistungspotenzial durch Tuningmassnahmen sichtbar (PreFetch) Anforderung an die Skalierung der Systemleistung wird mit dem Projekt Zürcher Katalog stark erhöht 12

5 % der Transaktionen sogenannte Longrunner Aufwändige Analysen mit eigenen Testprogrammen Kommunikation zwischen Applikations und DB Server Alte Legacy

13 e1000 vs. vmxnet 13

Ähnliche Dokumente

Pasolfora Database Appliance PDA

Pasolfora Database Appliance PDA pasolfora GmbH An der Leiten 37 D-91177 Thalmässing Web: www.pasolfora.com Steffan Agel Andreas Prusch steffan.agel@pasolfora.com andreas.prusch@pasolfora.com 26/01/2016