...virtuelle Webserver managed und unmanaged...
Servicebeschreibung
Die Hauptaufgabe des Service ist die Bereitstellung von virtuellen Webservern oder virtuellen Webserver-Clustern. Diese können beispielsweise zur Auslieferung von statischen Dateien wie unveränderlichen HTML- oder Bild-Dateien oder dynamisch erzeugter Daten genutzt werden.
Die Webumgebung ist eine so genannte "Shared-Hosting"-Umgebung, d. h. die einzelnen Webauftritte teilen sich eine Webserver-Installation. Die einzelnen Webauftritte sind unter eigenen Internet-Adressen erreichbar.
Dieser Service wird in einer 'unmanaged' oder einer 'managed' Variante (siehe Service-Optionen) angeboten, die virtualisiert unter VMware läuft.
Neben dem Ausliefern von Dokumenten erfüllen die Webserver folgenden Funktionen:
- Zugriffsbeschränkung über HTTP-Authentifizierung
- Verschlüsselung der Server-Client-Kommunikation via HTTPS-Verfahren
- Fehlerverwaltung (HTTP-Statuscodes)
- Protokollierung via Logdatei
Zum Einsatz kommt eine klassische LAMPPP-Installation unter CentOS 7:
- Speicherplatz: 5 GB
- MySQL-Datenbankserver
- PHP-Programmiersprache
- Perl-Programmiersprache
- Python-Programmiersprache
- PHP, Perl und Python sind mit einer Vielzahl an Modulen ausgestattet
Eine Liste der installierten Module finden Sie unter: http://modules.cgi-host2.rz.uni-frankfurt.de.
Der Betrieb der meisten modernen Opensource-Webanwendungen wie Blogs, Foren oder Wikipedia ist möglich.
Dieser Service beinhaltet:
- Betrieb und Support des zentralen Web-Server-Clusters der Goethe-Universität
- Zeitnahes Einspielen aktueller Updates und Patches
www.rz.uni-frankfurt.de/virtuelle_webserver
| Service-Optionen | |
|---|---|
| Unmanaged | Managed |
| Art.-Nr.: 07-03-01 | Art.-Nr.: 07-03-02 |
Der*die Auftraggeber*in ist verpflichtet kontinuierlich für die zeitnahe Installation verfügbarer Updates seiner Webapplikation zu sorgen (insbesondere Sicherheitsupdates) | Das HRZ behält sich vor, die installierte Software der Kund*innen auf einem aktuellen und sicheren Level zu halten (Installation regelmäßiger Updates). Dadurch etwaige entstehende Inkompatibilitäten mit von dem*der Kund*in installierten Webanwendungen müssen von dem*der Kund*in aufgelöst werden. |
| Serviceteam | Artikelnummer | Zielgruppen |
|---|---|---|
| Team Web | Siehe Service-Optionen | Universitätsangehörige |
| Buchen des Service | Serviceregelungen | Kündigungsbedingungen |
| Per E-Mail | Siehe Service-Optionen |
|
| Bereitstellungszeit | Leistungsübergabepunkt | Monitoring/Reporting |
|
|
|
| Servicelevel | Servicelevelwerte | Kostenmodell |
| Verfügbarkeit | 98%/Monat in der bedienten Servicezeit |
|
| Dienstleister zum Service | Drittdienstleisterverträge/-beziehungen | |
Team Web | Kein Drittdienstleister involviert |
Zuständigkeitsmatrix
| Aufgaben | Nutzer*in | HRZ |
|---|---|---|
| Betrieb sowie Update und Upgrade des Server-Cluster | X | |
| Anforderung an Webserver/Webauftritt übermitteln | X | |
Update und Upgrade des Betriebssystems, PHP-Versionen, Perl & Phyton Programmiersprachen | X | |
| Update und Upgrade der Datenbanken (SQLSERVER) | X | |
| Updates der SSL-Zertifikate | X | |
Monitoring der Systemumgebung (Diskspace, CPU-Auslastung usw.); Bearbeiten von etwaigen Alarmmeldungen und ggf. Ableiten proaktiver Maßnahmen | X | |
| Einsatz und Umstellung auf HTTPS (Secure Web) | X | |
Regelmäßiges Update und Upgrade der Web-Applikationen bei managed Servern | X | |
| Regelmäßiges Update und Upgrade der Web-Applikationen bei unmanaged Servern | X |
7 Comments
Unknown User (earp)
Kündigungsbedingungen?
Wartungsfenster?
Bereitstellungszeit Tage = Werktage?
Bdiente Servicezeit?
Kostenmodelle: was denn nun? Kapitel 1.7 oder die Homepage? welche der in Kapitel 1.7 genannten Kostenmodelle gilt???
Ich sehe unheimlich viele Abkürzungen und Fachwörter: sind überall Erklärungen dran? braucht ihr weitere Worte im Glossar, weil sie häufiger als 1x im Servicekatalog vorkommen?
Unknown User (battenbe)
Hi, Ich habe noch nachgebessert. Waren auch noch ein paar andere Sachen nicht ganz in Ordnung. Beim Wartungsfenster sollte eigentlich der Verweis auf die allgemeinen Infos aus 1.9 reichen. Das ist mir tatsächlich auch lieber, als die Zeiten explizit reinzuschreiben. Sollte sich das allgemeine Wartungsfenster ändern, muss dann hier nicht nachgepflegt werden.
Bei den Abkürzungen brauchen wir eigentlich keine weiteren Einträge, das meiste sind Programme/Dienste, die auf den Servern zur Verfügung stehen und die bei Webanwendungen üblicherweise in den Systemanforderungen auftauchen. Höchstens SSL und HTTPS könnten noch rein. Hier ginge vielleicht sowas wie dieser Satz von Wikipedia:
SSL (Secure Sockets Layer), ist ein Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet.
Bei HTTPS würde ich dann sowas schreiben:
HTTPS (Hypertext Transfer Protocol Secure) ist ein Protokoll für den abhörsicheren Zugriff auf Webseiten, die Verbindung wird dabei via SSL verschlüsselt.
Jan Wauschkuhn
Unknown User (battenbe) Unknown User (kphilipp) Hi, kannst Du nochmal unter Servicellevel checken? Wollen wir da den allgemeinen Verweis auf 1.9. und 1.11 lassen? Damit sind eingie Sachen festgelegt. Ich hätte die Neigung das rauszunehmen und stattdessen nur aufzunehmen, wie lange Vorlauf wir uns nach der Bestellung bis zur Auslieferung eines vWebServ ausbedingen.
Unknown User (earp)
Der allgemeine Verweis ist ohnehin zu entfernen (siehe Unterstützende Dokumente).
Lieferzeiten werden unter "Bereitstellungszeit" angegeben:
"Bereitstellungszeit für zu erbringende Leistungen: X Werktage"
Jan Wauschkuhn
Unknown User (earp) Unknown User (laramart) Hi, ich hatte vorhin nochmal mit CL gesprochen und demnach meint "Bereitstellungszeit" genau nicht die Lieferzeit/Vorlaufzeit, sondern wann der Dienst zur Verfügung steht, aufgeteilt in bediente und unbediente Servicezeit.
Unknown User (earp)
zwei von 3 Punkten richtig
Zitat aus den Unterstützenden Dokumenten:
"Bereitstellungszeit (muss ausgefüllt werden)
Beispiele:
Jan Wauschkuhn
Alles klar, sehe ich jetzt auch. In der Beispieltabelle ist es nicht genannt und ich habe nur auf die geachtet.