1. Vorbemerkung... 3. 2. Beschreibung und Standorte des vertragsgegenständlichen IT-Systems und der Systemumgebung*... 3

Seite 1 von 24 Anlage 1 zum EVB-IT Servicevertrag: Ergänzende Angaben Inhalt 1. Vorbemerkung... 3 2. Beschreibung und Standorte des vertragsgegenständlichen IT-Systems und der Systemumgebung*... 3 2.1. Standorte und Zugänglichkeit des IT-Systems... 3 2.2. Beschreibung des IT-Systems und seiner Systemumgebung*... 4 3. Ergänzende Angaben zu den zu erbringenden Leistungen... 6 3.1. Wiederherstellung der Betriebsbereitschaft* des IT-Systems... 6 3.1.1. Erstqualifizierung von Störungen*... 6 3.1.2. Störungsebene und Maßnahmen zur Störungsbeseitigung... 7 3.1.2.1. Störungsebene 1: Störungen* der Middleware**... 7 3.1.2.2. Störungsebene 2: Störungen* der ITDLZ-Infrastruktur... 7 3.1.2.3. Störungsebene 3: Störungen* im Bereich der mebis-anwendungen... 7 3.1.3. Störungsklassifizierung (Kritikalität)... 8 3.1.4. Anderweitige Kenntniserlangung von Störungen* (Monitoring und Reporting)... 10 3.2. Aufrechterhaltung der Betriebsbereitschaft*... 11 3.2.1. Allgemeine Regelung... 11 3.2.2. Monitoring und Reporting... 11 3.2.2.1. Ziel des Monitorings... 11 3.2.2.2. Technische Infrastruktur... 12 3.2.2.3. Verfügbarkeits-Monitoring... 12 3.2.2.4. Performance-Reporting... 14 3.2.3. Betrieb** der IT-Systeme... 15

Seite 2 von 24 3.2.3.1. Betrieb** Basis-Systeme... 15 3.2.3.2. Betrieb** Middleware**-Komponenten... 16 3.2.3.3. Betrieb** mebis-anwendungen... 17 3.2.4. Datensicherung*... 18 3.3. Vor Ort-Service, regelmäßige Anwesenheit beim Auftraggeber... 18 3.3.1. Art und Umfang der Leistung, Ort und Zeiten der Leistung... 18 3.4. Einrichten von neuen oder ausgewechselten Systemkomponenten*... 19 3.5. Sonstige Serviceleistungen... 20 4. Besondere Anforderungen an Mitarbeiter des Auftragsnehmers... 21 5. Kündigung von Serviceleistungen... 23 6. Begriffsbestimmungen... 23

Seite 3 von 24 1. Vorbemerkung Die Angebote von "mebis Landesmedienzentrum Bayern" werden im IT-Dienstleistungszentrum des Freistaats Bayern (ITDLZ, vormals RZ-Süd) auf dort angesiedelten physikalischen sowie virtuellen Systemen betrieben. Das ITDLZ erbringt die Housing**-Leistungen für die dort betriebenen Systeme. Das ITDLZ ist für den Basis-Betrieb** der Hardware, der RZ-Infrastruktur, des Netzwerks, der Firewalls und des Loadbalancer verantwortlich. Alle darüber hinausgehenden Aufgaben, wie z. B. die Administration der Basis-Systeme, das Einspielen von Betriebssystem-Updates und -Patches*, der Betrieb** der Middleware**, die Installation und Konfiguration der Anwendungen, sind vom Auftragnehmer zu übernehmen. Der Betrieb** der Linux-Systeme (Installation, Konfiguration, Updates), die Installation, die Konfiguration und der Betrieb** der Middleware** sowie der Anwendungsbetrieb** liegen voll oder teilweise im Aufgabenbereich des Auftragnehmers. Die genaue Verantwortungsabgrenzung wird in den weiteren Kapiteln definiert. 2. Beschreibung und Standorte des vertragsgegenständlichen IT- Systems und der Systemumgebung* 2.1. Standorte und Zugänglichkeit des IT-Systems Das vertragsgegenständliche IT-System verteilt sich auf folgende Standorte: Landesamt für Digitalisierung, Breitband und Vermessung (ITDLZ) IT-Dienstleistungszentrum des Freistaats Bayern St.-Martin-Straße 47 81541 München Akademie für Lehrerfortbildung und Personalführung Dillingen (ALP) Kardinal-von-Waldburg-Str. 6-7 89407 Dillingen Das vertragsgegenständliche IT-System ist wie folgt zugänglich: Standort ITDLZ Das ITDLZ bietet einen VPN-Service auf Basis einer Citrix-Server Umgebung an. Die Authentifizierung erfolgt per Smartcard. Ein direkter Zugriff auf die Server vom Client des Administrators ist nicht möglich. Alle Zugriffe erfolgen indirekt über die Server der Citrix-Umgebung. Voraussetzung auf Seiten des Dienstleisters ist ein Windows-Client mit Smart-Card-Reader.

Seite 4 von 24 Standort ALP Die IT-Abteilung der ALP bietet einen VPN-Service auf Basis von OpenVPN an. Dieses authentifiziert mit einer Kombination aus Zertifikaten und User/Passwort. Der Zugriff auf die Server an der ALP erfolgt direkt ohne andere zwischengeschaltete Systeme. Voraussetzung auf Seite des Dienstleisters ist die Installation des VPN-Clients. Für alle gängigen Betriebssysteme existieren VPN-Clients für OpenVPN. 2.2. Beschreibung des IT-Systems und seiner Systemumgebung* Insgesamt werden aktuell 73 Linux-Server (48 im ITDLZ, 25 an der ALP) auf Ubuntu-Basis betrieben. Folgende Umgebungen sind an diesen Standorten eingerichtet: ITDLZ Umgebung Beschreibung Komponenten Server (Anzahl) Produktiv Liveumgebung von mebis Landesmedienzentrum Bayern) CP, IP, M, PA, LMS, IDM, Beta-LMS, SSO 16 (14 virtuell + 2 physikalisch) Test Tests von Minor- Releases/Zertifizierungen CP, IP, M, PA, LMS, IDM, Beta-LMS, SSO 16 Entwicklung Vorbereitung/Tests neuer Major- Releases CP, IP, M, PA, LMS, IDM, SSO 16 Abkürzungen: Cockpit (CP), Infoportal (IP), Mediathek (M), Prüfungsarchiv (PA), Lernplattform (LMS), Nutzerverwaltung (IDM), Beta-Lernplattform (Beta-LMS), Shibboleth (SSO) Die Umgebungen am ITDLZ sind jeweils identisch aufgebaut, wobei Test- und Entwicklungsumgebung mit entsprechend weniger Ressourcen ausgestattet sind. Abweichend davon ist in Test- und Produktivumgebung jeweils eine Beta-Lernplattform eingerichtet, die in das gemeinsame SSO eingebunden ist. ALP Umgebung Beschreibung Komponenten Server (Anzahl) Gemeinsame Basis-Systeme DB, IDM, LDAP, NFS 8 Referenz Entwicklung Lernplattform LMS, IDM, SSO 4

Seite 5 von 24 Entwicklung 1 Entwicklung Lernplattform LMS, IDM, SSO 4 Entwicklung 2 Entwicklung Nutzerverwaltung IDM, SSO 5 Versionsverwaltung und Ticketsystem GIT, GitLab, Kanboard 1 Entwicklungsmanagement Management- Systeme Monitoring, Administration 3 Die an der ALP angesiedelten Umgebungen sind deutlich flexibler aufgebaut als am ITDLZ, da hier die Loadbalancer/Reverse-Proxy-Komponenten in Eigenregie betrieben werden. Die Loadbalance- und Reverse-Proxy-Systeme an der ALP sind durch den Auftragnehmer in Eigenregie zu betreiben. Der DNS-Dienst wird von den Technikern der ALP betrieben. Zuweisung von IP-Adressen und Dokumentation erfolgt ebenfalls durch die Techniker der ALP. Zudem bestehen auf diese Umgebungen flexible VPN-Zugriffe für externe Entwicklungsdienstleister, die in dieser Form organisatorisch am ITDLZ nicht möglich wären. Die virtuellen und physikalischen Server werden auf Basis des Betriebssystems Ubuntu 12.04 LTS betrieben. Folgende Softwarekomponenten auf Ebene Middleware** finden Verwendung und sind im Verantwortungsbereich des Betriebsdienstleisters: Software-Komponente Version (Stand: 12.08.2015) Quelle Apache-Server 2.2.22 Ubuntu-Repository Percona MySQL Server 5.5.41 Percona-Repository OpenLDAP 2.4.28 Ubuntu-Repository Tomcat 6.0.35 Ubuntu-Repository Shibboleth SP 2.5.4 Switch-AAI Repository Perl-Runtime 5.14.2 Ubuntu-Repository Python-Runtime 2.7.3 Ubuntu-Repository Shibboleth IdP 2.3.8 Manuell aus Original- Quellen von shibboleth.org installiert uapprove 2.5.0 Manuell aus Original- Quellen von Switch-AAI

Seite 6 von 24 installiert PHP-Runtime 5.4.42 Ubuntu-Repository Java-Runtime 1.6.0.35 Ubuntu-Repository 3. Ergänzende Angaben zu den zu erbringenden Leistungen 3.1. Wiederherstellung der Betriebsbereitschaft* des IT-Systems Zur Wiederherstellung der Betriebsbereitschaft* des IT-Systems oder von Systemkomponenten* gehören alle für die Störungsbeseitigung notwendigen Maßnahmen des Auftragnehmers. In jedem Fall nimmt der Auftragnehmer eine Erstqualifizierung einer Störungsmeldung vor (siehe 3.1.1.) Bei Störungen*, die auf Fehler in den eigenverantworteten Bereichen zurückzuführen sind, ist die Fehleranalyse und -behebung eigenverantwortlich durchzuführen (Störungsebene 1). Bei Störungen*, deren Ursache in der Infrastruktur des ITDLZ begründet liegen (Störungsebene 2), führt der Auftragnehmer eine entsprechende Fehleranalyse durch und koordiniert und unterstützt die Entstörung in Zusammenarbeit mit dem ITDLZ. Bei Störungen*, die auf Fehler in der Anwendungsebene (z. B. Cockpit/Infoportal, Lernplattform, Mediathek, Prüfungsarchiv) beruhen, findet im Rahmen der Fehleranalyse und der -behebung eine enge Zusammenarbeit mit dem jeweiligen Anwendungsverantwortlichen statt (Störungsebene 3). In jedem Fall sind Störungen* per E-Mail an die Mailing-Liste der Projektgruppe von "mebis Landesmedienzentrum Bayern" zu kommunizieren und die Projektverantwortlichen über den Stand der Arbeiten regelmäßig zu informieren. 3.1.1. Erstqualifizierung von Störungen* In jedem Fall nimmt der Auftragnehmer eine Erstqualifizierung einer Störungsmeldung vor, die es dem Auftraggeber transparent nachvollziehbar macht, in welche Störungsebene eine Störung* einzuordnen ist. Daraus leiten sich die zu ergreifenden Maßnahmen (siehe 3.1.2) ab. Die Erstqualifizierung beinhaltet: Kenntnisnahme/Entgegennahme der Störungsmeldung

Seite 7 von 24 Prüfung des Monitoring- und Reporting-Systems (siehe 3.2.2) auf Hinweise zur Störungsursache Manuelle Prüfung der betroffenen Anwendung auf Verfügbarkeit, z. B. durch Anmeldung und Aufrufen von Testseiten Erste Prüfung von Log-Files oder System-Meldungen der betroffenen Server-Systeme Festlegung der Störungsebene und der Kritikalität (Störungsklasse) 3.1.2. Störungsebene und Maßnahmen zur Störungsbeseitigung In Abhängigkeit von der Störungsebene sind folgende Maßnahmen zu ergreifen: 3.1.2.1. Störungsebene 1: Störungen* der Middleware** - Fehleranalyse und Behebung werden durchgeführt. - Störungsmeldung wird unter Angabe der Störungsebene an die Projektgruppe von "mebis Landesmedienzentrum Bayern" über Mail-Verteiler gesendet. 3.1.2.2. Störungsebene 2: Störungen* der ITDLZ-Infrastruktur - Ticket wird beim ITDLZ eröffnen und Störungsbehebung wird koordinieren. - Bei Bedarf unterstützt der Auftragnehmer den Service-Provider (ITDLZ/ALP IT) bei der Fehlersuche und Behebung, z. B. durch Bereitstellung von System-Protokollen oder notwendige Arbeiten an den betroffenen System, z. B. Neustart von Systemen oder Diensten. - Störungsmeldung wird unter Angabe der Störungsebene an die Projektgruppe von "mebis Landesmedienzentrum Bayern" über Mail-Verteiler gesendet. 3.1.2.3. Störungsebene 3: Störungen* im Bereich der mebis- Anwendungen

Seite 8 von 24 - Sollte die Störung* im Bereich der Anwendung selbst liegen, übermittelt der Auftragnehmer seine Analyseergebnisse mit möglichst detaillierter Problembeschreibung an die Anwendungs-Entwickler/-Koordinatoren zur weiteren Störungsanalyse und Beseitigung. - Die Anwendungs-Entwickler/Koordinatoren werden bei Bedarf bei der weiteren Störungsanalyse und Beseitigung unterstützt. - Störungsmeldung wird unter Angabe der Störungsebene an die Projektgruppe von "mebis Landesmedienzentrum Bayern" über Mail-Verteiler gesendet. 3.1.3. Störungsklassifizierung (Kritikalität) In Ergänzung zu der Störungsklassifizierung gem. Ziffer 6 EVB-IT-Service-AGB sieht folgende Matrix eine konkrete Einordnung in die Störungsklassen Betriebsverhindernde Störung, Betriebsbehindernde Störung, Leichte Störung in Abhängigkeit von Ergebnissen der unter 3.2.2.3 dokumentierten und zu implementierenden System-/Service-Checks vor. Die Variablen können durch den Auftraggeber bzw. durch den Auftragnehmer unter Zustimmung des Auftraggebers angepasst und ergänzt werden. Bewertungsmatrix Störungsklassen Service Betriebsverhindernde Störung Betriebsbehindernde Störung Leichte Störung Normalzustand Erreichbarkeit per Ping >20% Paketverlust oder > 100 ms Antwortzeit >10 % Paketverlust oder > 25ms Antwortzeit <10 % Paketverlust oder < 25ms Antwortzeit Update-Status Ubuntu >1 Update Keine Updates verfügbar Status Tivoli Backup- Agent Prozess nicht gestartet Prozess gestartet Korrekte Systemzeit Abweichung > 2 sec oder Abweichung > 1 sec Abweichung < 1 sec

Seite 9 von 24 (per NTP) Dienst nicht verfügbar Dienstverfügbarkeit SSH Dienstverfügbarkeit NRPE nicht nicht Füllstand Festplatten- Partitionen/NFS- Share freie Kapazität pro Partition < 10% freie Kapazität pro Partition < 15% frei Kapazität pro Partition > 15 % Dienstverfügbarkeit Web-Server HTTP/HTTPS nicht Web-Server Gültigkeit SSL- Zertifikate Zertifikat < 30 Tage gültig Zertifikat > 30 Tage gültig Erreichbarkeit DB- Server (inkl. Login) nicht Apache-Auslastung (Hits/s, etc.) Keine Schwellwerte definiert dient nur dem Kapazitätsmonitori ng Dienstverfügbarkeit MySQL-Server nicht/cluster Verfügbarkeit = 0 von 2 Nodes Cluster Verfügbarkeit = 1 von 2 Nodes Dienst antwortet/cluster Vergübarkeit = 2 von 2 Nodes Cluster-State PerconaDB Cluster Status < 2 Nodes verfügbar Cluster Sync Status nicht synchron Cluster ist synchron Status Memcache- Server nicht Vorliegen aktueller DB-Backups Alter Backup > 24 h Alter letztes Backup < 24 h Erreichbarkeit OpenLDAP-Server (inkl. Login) nicht Replikations-Status OpenLDAP LDAP Cluster nicht LDAP Cluster

Seite 10 von 24 synchron synchron Caching-Parameter OpenLDAP >= 1000000 Einträge >= 750000 Einträge < 750000 Einträge Anzahl Connections OpenLDAP Connections >= 75 active Connections >= 50 active Connections < 50 active Vorliegen aktueller LDAP-Backups Alter Backup > 24 h Alter letztes Backup < 24 h Status Deprovisionierungs- Umgebung/Queue Erreichbarkeit Mail- Gateway >= 50 Einträge in der Warteschlange >= 10 Einträge in der Warteschlange nicht < 10 Einträge in der Warteschlange Erreichbarkeit RZ- Proxy nicht Erreichbarkeit Internet Internet-Anbindung ITDLZ WAN Verbindung nicht verfügbar WAN Verbindung langsam WAN Verbindung besteht Erreichbarkeit aller Angebote aus dem Internet (externe Checks) Anwendung von extern nicht erreichbar Anwendung schlecht von extern erreichbar Anwendung erreichbar Login per Webinject- Skript um Funktionsfähigkeit der Anwendung sicherzustellen Gesamte Transaktion dauert > 10 Sekunden oder bricht mit Fehler ab Gesamte Transaktion dauert > 5 Sekunden Gesamte Transaktion dauert < 5 Sekunden 3.1.4. Anderweitige Kenntniserlangung von Störungen* (Monitoring und Reporting) Der Auftragnehmer ist verpflichtet, sich selbst Kenntnis von Störungen* zu verschaffen. Dies erfolgt mittels des im Rahmen der Aufrechterhaltung der Betriebsbereitschaft* vorgesehen Monitorings und Reportings (siehe 3.2.2).

Seite 11 von 24 3.2. Aufrechterhaltung der Betriebsbereitschaft* 3.2.1. Allgemeine Regelung Der Auftragnehmer ist für den Betrieb** aller Server-Systeme und der Middleware** verantwortlich. Darüber hinaus unterstützt der Auftragnehmer die Anwendungsverantwortlichen beim Betrieb** der Anwendungen des Projektes "mebis Landesmedienzentrum Bayern". Der Auftragnehmer hat die Verfügbarkeit der Anwendungen aus Benutzersicht (End-to-End Verfügbarkeit) sicherzustellen und alle dafür notwendigen betrieblichen Maßnahmen zu konzipieren und durchzuführen. Folgende Leistungen sind zur Aufrechterhaltung der Betriebsbereitschaft* zu erbringen. 3.2.2. Monitoring und Reporting 3.2.2.1. Ziel des Monitorings Aufgabe ist es, eine übergreifende Monitoring-Umgebung für alle Teilangebote/Teilsysteme des Projektes mebis Landesmedienzentrum Bayern bereitzustellen im Einzelnen: Cockpit Infoportal Mediathek Prüfungsarchiv Lernplattform Nutzerverwaltung Das Verfügbarkeits-Monitoring dient der Überwachung aller Server und Dienste und ermöglicht im Fehlerfall eine schnelle Benachrichtigung der zuständigen Dienstleister mit dem Ziel der Störungsbeseitigung. Das Performance-Reporting soll fortlaufend die Auslastung aller beteiligten Komponenten erfassen und so als Basis zur Kapazitätsplanung für notwendige Erweiterungen und die Analyse von Engpässen dienen.

Seite 12 von 24 3.2.2.2. Technische Infrastruktur Das Monitoring hat mittels der Anwendung Icinga zu erfolgen. Die technische Systemarchitektur ist so aufzubauen, dass folgende Prämissen erfüllt werden: - Es gibt ein zentrales System zum Abruf der Verfügbarkeitsdaten. - Es gibt ein zentrales System zum Abruf der Performance-Reports. - Die Datensammler stehen sowohl im ITDLZ als auch außerhalb im Internet und liefern die Daten an das zentrale Monitoring-System. Um einen schnellen und flexiblen Aufbau des Monitoring-Systems zu erreichen, ist das zentrale Monitoring/Reporting System am Standort der ALP Dillingen aufzusetzen. Dieses System hat über die Behördennetz-Anbindung der ALP Zugriff auf die Systeme im ITDLZ, um dort die notwendigen Daten abzufragen. Das externe Monitoring über den Internet-Weg hat sowohl von der ALP aus als auch über einen weiteren Monitoring-Agenten bei einem externen Provider im Internet zu erfolgen. 3.2.2.3. Verfügbarkeits-Monitoring Um die Verfügbarkeit der Gesamtumgebung aus Benutzersicht abzubilden, ist so vorzugehen, dass eine Reihe notwendiger System-Checks durchgeführt wird und die Ergebnisse anhand der Abhängigkeits-Struktur der Cluster- und Serverumgebungen aggregiert werden. So soll z. B. im Falle eines Webclusters so aggregiert werden, dass eine Service-Verfügbarkeit ablesbar ist. Wenn also im Web-Cluster mind. 1 Node verfügbar ist, gilt der gesamte Webcluster als funktionsfähig. Im Einzelnen sind folgende System/Service-Checks zu implementieren: - Alle Server o Erreichbarkeit per Ping o Update-Status Ubuntu o Status Tivoli Backup-Agent o Korrekte Systemzeit (per NTP)

Seite 13 von 24 o Dienstverfügbarkeit SSH NRPE o Füllstand Festplatten-Partitionen - Web-Server Lernplattform o Dienstverfügbarkeit HTTP/HTTPs auf allen genutzten Ports o Gültigkeit SSL-Zertifikate o Füllstand NFS-Share o Erreichbarkeit IDM-Server (inkl. Login) o Erreichbarkeit DB-Server (inkl. Login) o Apache-Auslastung (Hits/s, etc.) - DB-Server Lernplattform o Dienstverfügbarkeit MySQL-Server o Cluster-State PerconaDB o Status Memcache-Server o Vorliegen aktueller DB-Backups - Doku/Support-Server o Dienstverfügbarkeit HTTP/HTTPs o Cluster-State PerconaDB (Dummy-Node) - IDM-Server (Nutzerverwaltung) o Dienstverfügbarkeit OpenLDAP o Replikations-Status OpenLDAP

Seite 14 von 24 o Caching-Parameter OpenLDAP o Anzahl Connections OpenLDAP o Vorliegen aktueller LDAP-Backups o Status Deprovisionierungs-Umgebung/Queue - Webserver Infoportal & Cockpit o Dienstverfügbarkeit HTTP/HTTPs o Erreichbarkeit DB-Server (ggf. durch PHP-Skript) - Zentrale Dienste o Erreichbarkeit Mail-Gateway o Erreichbarkeit RZ-Proxy o Erreichbarkeit Internet - Internet-Anbindung o Erreichbarkeit aller Angebote aus dem Internet (externe Checks) o Login per Webinject-Skript um Funktionsfähigkeit der Anwendung sicherzustellen Maßnahmen zur Störungsbeseitigung erfolgen gem. 3.1.2. 3.2.2.4. Performance-Reporting Folgende Performance-Werte müssen 24x7 erhoben und in einem Reporting-System abgefragt werden können: - Alle Server - Web-Server o CPU-Auslastung o RAM-Auslastung/Swap-Usage o Disk-Auslastung o Apache-Statistiken (Prozesse, Abfragen/s, etc.)

Seite 15 von 24 - DB-Server o MySQL-Statistiken - LDAP-Server o LDAP-Abfragen o Caching-Auslastung o Aktive Connections - Externe Zugriffe o Response-Time Cockpit o Response-Time Infoportal o Response-Time Mediathek o Response-Time Prüfungsarchiv o Response-Time Lernplattform Zur Messung der Response-Times werden ggf. verschiedene Szenarien eingesetzt z. B. Login mit einem User und Abfrage eines bestimmten Kursinhalts die Abstimmung der dafür implementierten Checks erfolgt in Zusammenarbeit mit dem mebis-projektteam. Somit wird eine realistische End-to-End Zeitmessung aus User-Sicht gewährleistet. Technisch gesehen werden die Performance-Grafiken soweit möglich in Icinga integriert. Dies ist durch Nutzung von PNP4Nagios möglich ggf. müssen erweiterte Plugins herangezogen werden, die zusätzliche Performance-Daten für MySQL und Apache liefern. Ziel ist somit, dass es eine Plattform gibt, die sowohl die Verfügbarkeit als auch die Performance- Auslastung der mebis-umgebung anzeigt. 3.2.3. Betrieb** der IT-Systeme 3.2.3.1. Betrieb** Basis-Systeme Der Betrieb** der Basis-Systeme umfasst die in unter 2.2 genannten Systeme. Zum Betrieb** der Systeme gehören folgende Leistungen:

Seite 16 von 24 Anpassungen der Konfiguration der Linux-Systeme Anpassungen der Konfiguration der Netzwerkanbindung mit Loadbalancer-Anbindung Installation notwendiger Softwarepakete im Rahmen von geänderten Anforderungen seitens der Middleware** oder der Anwendungen Einspielen von Betriebssystemupdates*/Patches* o Sicherheitskritische Updates* sind schnellstmöglich je nach Verfügbarkeit durch den Hersteller in Abstimmung mit dem Auftraggeber durchzuführen. o Updates*, Patches*, Upgrades* sind zu installieren, sobald sie am Markt verfügbar sind. Die Verfügbarkeit muss mindestens einmal im Monat überprüft werden. Einrichtung und Überwachung der Datensicherung* in Zusammenarbeit mit dem ITDLZ/ALP Bereitstellung eingeschränkter Zugänge für Anwendungsbetreuer und ggf. externe Entwicklungsdienstleister mittels Jailkit-Umgebung 3.2.3.2. Betrieb** Middleware**-Komponenten Die folgenden Middleware**-Komponenten sind im Projekt mebis Landesmedienzentrum Bayern aktuell im Einsatz: Apache-Server auf allen Webserver-Nodes MySQL DB-Cluster/Einzelinstanzen OpenLDAP Server auf replizierenden Nodes Tomcat/Shibboleth für Single-Sign-On Perl-Runtime Umgebung Python-Runtime Umgebung PHP-Runtime Umgebung Java-Runtime Umgebung Der Betrieb** umfasst folgende Aufgabenfelder: Pflege und Konfigurationsanpassungen der Middleware**-Umgebung im Hinblick auf Verfügbarkeit, Stabilität und Skalierbarkeit Pflege und Konfigurationsanpassungen der MySQL-Clusterumgebung

Seite 17 von 24 Pflege und Konfigurationsanpassungen der Webserver-Clusterumgebung Optimierung der Middleware**-Komponenten in Abstimmung mit dem Auftraggeber Konfiguration der externen Zugangs-URLs in Abstimmung mit dem ITDLZ bzw. der ALP Dillingen Einrichten, Durchführen und Überwachen von Datensicherungen* von MySQL bzw OpenLDAP Datenbanken Einspielen von Updates*/Patches* o Sicherheitskritische Updates* sind schnellstmöglich je nach Verfügbarkeit durch den Hersteller in Abstimmung mit dem Auftraggeber durchzuführen. o Updates*, Patches*, Upgrades* sind zu installieren, sobald sie am Markt verfügbar sind. Die Verfügbarkeit muss mindestens einmal im Monat überprüft werden. 3.2.3.3. Betrieb** mebis-anwendungen Derzeit betreibt das Projekt mebis Landesmedienzentrum Bayern folgende Teilanwendungen: Cockpit auf Basis von Wordpress Infoportal auf Basis von Wordpress Mediathek Eigenentwicklung in PHP Lernplattform basierend auf einer angepassten Moodle-Installation IDM (ID-Management) mit Admin- und Selfservice-Portal auf Perl-Basis Shibboleth idp für zentrales Single-Sign-On auf Shibboleth/Tomcat-Basis Provisionierung/Deprovisionierung auf Python/XML Basis inkl. DB-basiertem Queueing Der Betrieb** der mebis-anwendungen umfasst folgende Aufgaben: Einspielen gelieferter Release*-Stände, ggf. über Schnittstellen zu Versionsverwaltungs- bzw. Paketierungssystemen des Entwicklungsdienstleisters Durchführung und Dokumentation der Anwendungs-Konfiguration nach Vorgaben und vorheriger Abstimmung

Seite 18 von 24 Anbindung der Anwendungen an die Middleware** Durchführen von Upgrades *, etc. laut Anwendungsdokumentation Durchführung und Unterstützung bei Inbetriebnahme (Installation) neuer Anwendungen Unterstützung bei der Fehlersuche auf Anwendungsebene 3.2.4. Datensicherung* Die Datensicherung* erfolgt auf Basis des Datensicherungs-Service des ITDLZ nach abgestimmten Datensicherungsregeln. Der Auftragnehmer ist für die Überwachung der erfolgreichen Datensicherung* verantwortlich. Dafür ist dem Auftragnehmer ein täglicher Bericht der durchgeführten Datensicherungen* vom ITDLZ per E-Mail zur Verfügung zu stellen. Der Auftragnehmer muss die Ursache von fehlgeschlagenen Datensicherungen* analysieren und ggf. beim ITDLZ melden, um eine Fehlerbehebung einzuleiten. Darüber hinaus ist der Auftragnehmer für die Erstellung von Backups auf Middleware**- bzw. Anwendungsebene verantwortlich. Dies sind im konkreten Fall: Bereitstellung von täglichen DB-Dumps der MySQL-Datenbanken Bereitstellung von täglichen LDAP-Dumps Diese bereitgestellten Backups werden dann wiederum durch den Datensicherungs-Service des ITDLZ auf ein externes System gesichert. Der Auftragnehmer ist ebenfalls für die Rücksicherung von Daten zu gewünschten Zeitständen verantwortlich. Er nutzt dafür die Datensicherungssysteme des ITDLZ. 3.3. Vor Ort-Service, regelmäßige Anwesenheit beim Auftraggeber 3.3.1. Art und Umfang der Leistung, Ort und Zeiten der Leistung Der Auftragnehmer verpflichtet sich im Rahmen eines Vor-Ort-Services folgende Leistungen zu erbringen: Leistung Standort Beschreibung Häufigkeit, Zeiten Umfang Vor-Ort- ALP Regelmäßige Meetings mit der 1 x im Monat nach 4 Stunden

Seite 19 von 24 Leistung 1 Dillingen IT-Abteilung der ALP Dillingen im Rahmen der kontinuierlichen Weiterentwicklung der Systemlandschaft und der Prozesse sowie zur Einrichtung von neuen oder ausgewechselten Systemkomponenten* Terminvereinbarung Vor-Ort- Leistung 2 ITDLZ München Regelmäßige Teilnahme an Meetings im ITDLZ in München zur Bearbeitung (Steuerung des ITDLZ, Unterstützung bei der Analyse und Behebung, Nachbereitung) von technischen Problemen bzw. im Rahmen der kontinuierlichen Weiterentwicklung der Anwendungslandschaft und der Prozesse 1 x pro Quartal nach Terminvereinbarung 8 Stunden Vor-Ort- Leistung 3 ALP Dillingen Teilnahme an Workshops und Planungs-Sitzungen zur Konzeption und Weiterentwicklung von mebis- Teilanwendungen 1 x pro Quartal nach Terminvereinbarung durchschnittliche Dauer von 2 Tagen Diese Workshops finden in der Regel in der ALP Dillingen statt. 3.4. Einrichten von neuen oder ausgewechselten Systemkomponenten* Die Verpflichtung zum Einrichten von neuen oder ausgewechselten Systemkomponenten* ist auf folgende Systemkomponenten* beschränkt: Apache-Server Percona MySQL Server OpenLDAP

Seite 20 von 24 Tomcat Shibboleth SP Perl-Runtime Python-Runtime Shibboleth IdP uapprove PHP-Runtime Java-Runtime Weitere Regelungen zum Einrichten von neuen oder ausgewechselten Systemkomponenten*: Im Rahmen der Weiterentwicklung der Plattform und eventuell notwendiger Skalierung der Systeme aufgrund veränderter Anforderungen wird es zukünftig notwendig sein, neue Basis-Systeme in Betrieb** zu nehmen. Die notwendigen Leistungen bei der Inbetriebnahme von Basis-Systemen sind: Sizing des Systems nach den vorliegenden Anforderungen Unterstützung bei der Bestellung der Systeme Kontrolle des gelieferten Systems nach den geforderten Parametern Installation der Linux-Systeme Konfiguration der Linux-Systeme Aufnahme des Systems in die Dokumentation und das Monitoring Darüber hinausgehende Maßnahmen zur Erweiterung und Modifikation des Betriebssystems können durch den Auftraggeber verlangt werden, soweit dies dem Auftragnehmer zuzumuten ist. 3.5. Sonstige Serviceleistungen Zur Unterstützung einzelner Projektphasen, der Neukonzeption von Anwendungen oder Anwendungsbestandteilen und dem fortlaufenden Anwendungsbetrieb** werden fallbezogen Beratungs- und Unterstützungsleistungen durch den Auftraggeber eingefordert, die durch den Auftragnehmer zu erbringen sind.

Seite 21 von 24 Diese umfassen folgende Bereiche: Beratungsleistungen zu allen technischen Fragen des Betriebs** im ITDLZ Spezifikation neuer Anforderungen für neue Anwendungen bzw. Erweiterung bestehender Anwendungen Konzeption und Weiterentwicklung der System-Landschaft, des Cluster-Konzepts und der Middleware**-Komponenten Erstellung und Überwachung technischer Betriebskonzepte (z.b. Clusterumgebung MySQL) Kommunikation/Koordination ITDLZ zur Implementierung neuer Anforderungen Service-Management Zusammenarbeit ITDLZ Unterstützung bei der Implementierung neuer Features/Anforderungen Unterstützung bei der Fehlersuche auf Systemebene, in Anwendungen, etc. (z.b. Erstellung von PHP-Traces oder Performance-Analysen) Durchführung und Unterstützung bei Lasttests Durchführung und Unterstützung bei Security-Tests Pflege und Weiterentwicklung des Sicherheitskonzepts Erstellung von Skripten für statistische Auswertungen Konzeption und Implementierung Provisionierungs-/Deprovisionierungs-Umgebung zwischen allen mebis-anwendungen Unterstützung bei der Anbindung von Anwendungen an Shibboleth/SSO 4. Besondere Anforderungen an Mitarbeiter des Auftragsnehmers Folgende Mindestanforderungen an das einzusetzende Personal des Auftragnehmers garantiert der Auftragnehmer dem Auftraggeber: Ausgezeichnete Kenntnisse** in folgenden Bereichen: o Linux o MySQL

Seite 22 von 24 o LDAP o Cluster-Betrieb MySQL o Cluster-Betrieb OpenLDAP o Netzwerk o Loadbalancer/Reverseproxy o Virtualisierung o Monitoring, Icinga/Cacti o Performance-Optimierungen DB-Server/Web-Server o Jailkit-Umgebungen und Linux o PHP o Python o Perl o Tomcat o IT-Projektmanagement Projekterfahrung im Bereich Moodle: o Hosting von Moodle-Umgebungen >= 100.000 User o Performance-Analysen und Optimierungen o Skripting von Moodle mittels MOOSH Umfangreiche Erfahrung von Service-Management im RZ-Umfeld Umfangreiche Erfahrungen o im Betrieb** von Anwendungen und System in großen RZ-Infrastrukturen o in Implementierung und Betrieb** einer Shibboleth/SSO Umgebung Projektmanagement o Service Management im RZ-Umfeld

Seite 23 von 24 5. Kündigung von Serviceleistungen Der Vertrag kann mit einer Kündigungsfrist von sechs Monaten zum Ende eines Jahres gekündigt werden. 6. Begriffsbestimmungen Anwendungsbetrieb Hierunter wird die Installation, die Konfiguration von Anwendungen sowie deren Updates* verstanden. In diesen Zusammenhang fallen auch alle Schnittstellen zu ggf. vorhandenen Entwicklungsdienstleistern und deren Versionsverwaltungs- bzw. Paketierungssystemen. Ausgezeichnete Kenntnisse Das Personal des Auftragnehmers kennt alle wesentlichen Besonderheiten und Randbereiche des Gegenstandes, beherrscht theoretische und praktische Grundlagen und kann konzeptionelle Fragen eigenständig entwickeln und begründen. Auch schwierige Aufgaben können ohne Einweisung und Anleitung erledigt werden. Er hat die Fähigkeit, andere Mitarbeiter zu schulen und deren Arbeitsergebnisse zu bewerten und zu berichtigen. Betrieb Unter Betrieb wird die eigenverantwortliche Sicherstellung bestimmter Funktionalitäten verstanden. Wichtig ist die Abgrenzung gegenüber einzeln beauftragten Beratungsleistungen, bei denen die Steuerung beim Auftraggeber liegt. Bei der Vergabe von Betriebsaufgaben wird dauerhaft ein bestimmter Aufgabenbereich eigenverantwortlich an den Auftragnehmer vergeben. Dieser ist verpflichtet durch selbst definierte, geeignete Maßnahmen die vereinbarte Verfügbarkeit der übertragenen Aufgabenbereiche sicherzustellen.

Seite 24 von 24 Housing von physikalischen und virtuellen Systemen Hierunter wird die Bereitstellung von physikalischen und virtuellen Maschinen auf Infrastruktur des ITDLZ verstanden. Die Bereitstellung umfasst die Beschaffung von Hardware, das Konfigurieren virtueller Systeme und den Betrieb der gesamten dafür notwendigen RZ-Infrastruktur (Strom, Klimatisierung, Netz, etc.). Das Housing beinhaltet ebenfalls die Bereitstellung von Infrastruktur-Komponenten im Bereich Netzwerk, Firewall, Load-Balancer, Reverse-Proxy und NAS-Storage. Diese Komponenten werden durch das ITDLZ verwaltet und durch das Projekt als Managed-Service genutzt. Middleware Unter Middleware werden in dieser Ausschreibung alle Softwarekomponenten verstanden, die zwischen Betriebssystem und Anwendungsebene angesiedelt sind. Insbesondere fallen darunter: MySQL Datenbankserver inkl. Clusterfunktionalität OpenLDAP Directory Service inkl. Replikationsmechanismen Apache Webserver PHP Tomcat/Shibboleth für Single-Sign-On Perl-Runtime Umgebung Python-Runtime Umgebung Java-Runtime Umgebung