Unfallkrankenhaus Cordoba

Pablo Hamann, Leiter der IT-Abteilung des Unfallkrankenhauses in Córdoba (Argentinien) benötigte dringend eine geeignete Virtualisierungslösung um die digitale Bildarchivierung zu erleichtern, sich aus der Hardware-Abhängigkeit zu lösen sowie um die Server-Verwaltungsaufgaben zu vereinfachen. Mit der Implementierung von Proxmox VE konnte dieses Ziel erfolgreich umgesetzt werden. Die Einführung der Software wurde in mehreren Etappen durchgeführt und das gesamte Personal ist mit dem Ergebnis und der neuen Virtualisierungslösung sehr zufrieden.

Das städtische Unfallkrankenhaus der Stadt Córdoba ist das Gesundheitszentrum schlechthin für medizinische Notfälle im Großraum Córdoba (einem Ballungsgebiet bestehend aus der Stadt Córdoba und den umliegenden Städten), in der argentinischen Provinz Córdoba.

Córdoba selbst hat drei öffentliche Spitäler, von denen das größte das Städtische Unfallkrankenhaus ist. Mit fast 700 Mitarbeitern bietet es für Notfallpatienten öffentlich zugängliche und kostenlose medizinische Versorgung (auch für Ausländer). Das Krankenhaus ist auf die Behandlung von Polytraumen spezialisiert, da in der Region eine der Hauptursachen für schwere Unfälle Verkehrsunfälle sind und diese meist mit mehreren Verletzungen einhergehen. Die Traumatologie ist die größte der 15 medizinischen Abteilungen im Krankenhaus. Darüber hinaus bietet das Krankenhaus medizinische Zusatzdienste an: Der wichtigste Dienst ist dabei der „Diagnostic Imaging Service“ der aus Radiologie, Tomographie, Angiographie und Ultraschall besteht.

Eine halbe Million digitalisierte, bildgebende Verfahren jährlich erfordert optimierte Infrastruktur

„Wöchentlich werden ca. 1.500 Notfallpatienten im Städtischen Unfallkrankenhaus behandelt. Routinemäßig werden alle Patienten zunächst einer medizinischen, bildgebenden Untersuchung unterzogen, abhängig natürlich von der Schwere ihrer Verletzungen. Die dadurch erzeugte Menge an Bildstudien ist inzwischen so riesig (fast eine halbe Million jährlich), dass wir beschlossen haben das gesamte System zu digitalisieren um es zu rationalisieren. Gleichzeitig wollten wir damit auch die Betriebskosten reduzieren.

Als die Krankenhausverwaltung sich schließlich für die Digitalisierung der diagnostischen Bildgebungsverfahren entschied, war die einzige spezifische Anforderung ein fehlertolerantes System zu implementieren, in Spanisch nennen wir so etwas "BBB" (steht für: Bueno, Bonito y Barato - übersetzt: gut, schön und billig) - nicht mehr und nicht weniger sollte es sein!

Gewachsene IT-Infrastruktur an ihren Grenzen

Zu diesem Zeitpunkt gab es in der IT-Abteilung des Krankenhauses nur einige wenige Windows-Server die direkt auf einem geklonten Bare-Metal Typ USD 200 ausgeführt wurden. Die gesamte IT-Infrastruktur war in den letzten Jahren ständig gewachsen: Immer mehr PC-Arbeitsplätze, mehr Nutzer, mehr Drucker, mehr Netzwerkgeräte. Und schließlich die vielen medizinischen Geräte die noch dazu kamen - es war schlussendlich zu viel für die bestehende Infrastruktur.

Damals mussten wir ständig panikartig Ersatz für kaputtgegangene Server-Hardware besorgen. Das verursachte uns enorme Kopfschmerzen und große Unzufriedenheit bei all unseren Mitarbeitern. Zusätzlich machte das implementierte Netzwerkfilesystem ohne Server aus den PC-Arbeitsplätze nur simple und stupide Terminals, die unfähig waren irgendetwas zu tun. Dies alles ließ schließlich bei uns die Alarmglocken klingeln: Uns war klar, dass wir dringend eine Virtualisierungslösung benötigten.

Kauf neuer Server öffnet Tür für Virtualisierung

Als wir schließlich neue Server-Hardware kaufen mussten, war uns klar, dass wir nur mithilfe von Virtualisierung eine Hardware-Unabhängigkeit erreichen und Wartungsaufgaben auf den Servern erleichtern konnten. Es war auch klar, dass diese neue Hardware ausschließlich für unsere beiden PACS-Server reserviert sein würde, die wir bereits über geklonte Ausrüstung getestet hatten. PACS (Picture Archiving and Communication System) ist eine Technologie für die digitale Bildarchivierung „DICOM“ (Digital Imaging and Communications in Medicine). Die Server-Software wäre zwar mächtig genug gewesen - wir mussten also nicht unbedingt eine Virtualisierung deswegen einführen. Aber...

Eine proprietäre Lösung ungeeignet für die öffentliche Einrichtung

Jahre zuvor hatte ich im Labor für Informationssysteme (LabSis) an der regionalen Fakultät der Technischen Universität Córdoba gearbeitet und war damals fasziniert von den frühen Implementierungen von QEMU/KVM, die das Labor im Produktivbetrieb installiert hatte. Als wir nun in der Unfallklinik die Server-Infrastruktur erweitern mussten sah ich die Möglichkeit einen Cluster auf GNU/Debian mit QEMU/KVM-Virtualisierung zu implementieren. Darauf konnten wir dann nicht nur die PACS-Server, sondern auch unsere Windows-Server, die wir bisher auf einzelnen physischen Maschinen hatten, virtualisieren.

Zu dem Zeitpunkt kannte ich Proxmox VE noch nicht, aber es war mir klar, dass ich uns nicht mit einer proprietären Lösung „verheiraten“ wollte: Weder VMware vSphere, noch Microsofts Hyper-V, noch Citrix Xen waren meiner Meinung nach geeignet (oder sind geeignet) für eine Institution der öffentlichen Hand wie unser Unfallkrankenhaus es ist.

Die Chance: der Weg zur Open Source-Lösung Proxmox VE

Zum Glück empfahl uns ein externer IT-Experte Proxmox VE, in Version 3.2. Ich war wirklich überrascht: Proxmox VE war (und ist) für mich der sprichwörtliche "sueño del pibe" was auf argentinisch soviel heißt wie „ein großer Traum" oder "etwas Unerreichtes".

Proxmox VE vereinfachte für uns viele Probleme die wir im Zusammenhang mit der Cluster-Implementierung oder dem Backup-Management hatten. Es erleichterte uns auch die Inbetriebnahme eines iSCSI-Diskspeichers. Darüber hinaus besitzt es noch ein freundliches, intuitives und ansprechend gemachtes Web-Interface, was uns erlaubte unabhängig von Client-Software zu werden. Dies hat sicher auch dabei geholfen unser Management zu überzeugen, das zunächst eher eine Lösung wie Microsoft Hyper-V präferiert hat.

Proxmox-Hardware im Krankenhaus

Als öffentliche Einrichtung versuchen wir natürlich immer alle Ausgaben zu minimieren, so auch Hardware-Kosten. Der Hardwarekauf erfolgte daher in mehreren Schritten:

• 3 x Server IBM System x3650 M4, ausgestattet mit einem 16-Core-Mikroprozessor, 64 GB RAM, 8 SAS-2 mit 1 TB, 4 Port Giga Ethernet
• 1 x Server IBM System x3250 M5, ausgestattet mit einem 8-Core-Mikroprozessor, 32 GB RAM, 4 SATA-3 mit 1TB, 4 Port Giga Ethernet
• 1 x Speicherplatte SAS-2 IBM DS3524, 4 Kanal iSCSI Giga LAN
• 1 x Bandarchiv IBM System Storage TS3200 Tape Library ausgestattet mit zwei SAS-2-Schnittstellen

Die Implementierung von Proxmox VE

Wir begannen zunächst mit einer einfachen Installation von Proxmox VE. In den ersten paar Monaten virtualisierten wir nur die zwei Windows-Server mit den PACS-Servern auf einer Standard-Installation des damals gerade neu veröffentlichten PVE 3.2. Es war genial! Unser Chef war begeistert: Alles, was wir getan hatten war Proxmox VE zu installieren und zu verwenden (Methode "install and use", ohne etwas extra zu konfigurieren). In der Tat war noch nicht einmal der Cluster konfiguriert. Die Einfachheit von Installation und Benutzung hat das Management schließlich restlos überzeugt.

Sechs Monate später konfigurierten wir dann den gesamten Cluster. Und Monat für Monat haben wir all unsere existierenden physischen Server einer nach dem anderen virtualisiert. Ein Jahr später aktualisierten wir ohne Probleme auf Proxmox VE 3.4 und haben alle Speichertanks neu konfiguriert: wir haben die VMs (mindestens 10) auf iSCSI migriert, konfiguriert als ein großes LVM-Volumen. Von den Servern haben wir die Platten benutzt um ZFS-Pools zu erstellen für Backup-Zwecke.

Im darauffolgenden Jahr (Januar 2016) haben wir unseren gesamten Cluster auf Proxmox VE 4.1 aktualisiert. Dies machten wir einfach über apt und es brauchte nur minimale Änderung an der Konfiguration. Alles lief wieder ohne Probleme (Ich dachte damals, ich träume!). Die Umstellung auf die Version 4.1 war deshalb notwendig weil wir das Bandarchiv noch konfigurieren mussten. Dieses hatte nur SAS-Ports zur Verfügung, daher war die einzige Chance es mit den VMs zu verwenden es über SAS zu einem PVE-Server zu verbinden, und dann über iSCSI zu exportieren. Wir haben SCST dafür verwendet aber es gab Probleme mit dem Kernel 2.6 (der ja Basis der 3.x-Serie von Proxmox war). Sobald wir auf die Version 4.x gewechselt hatten (Proxmox wird jetzt mit Kernel 4.x ausgeliefert), konnten wir SCST ohne große Probleme implementieren. So konnten wir die Bibliothek über iSCSI erfolgreich exportieren.

Finale Konfiguration und die Vorteile für uns

Derzeit besteht unsere Proxmox-Implementierung aus einem Cluster mit den oben erwähnten 4 Servern. Durch den Vorteil, dass jeder Server 4 Port Giga Ethernet hat, ist die Verbindung zwischen den Knoten mit LACP-Bonding (2 Ports für den LAN-Knoten im Trunk-Modus und 2 Ports für das iSCSI-LAN) mit Open vSwitch konfiguriert (aptitude install openvswitch-ipsec).

Auf jedem Computer wird die Installation auf einem RAID mit 2 Spiegel-Festplatten (RAID1) pro Hardware gespiegelt, mithilfe von LVM. Auf jedem Computer werden die restlichen Disken in RAID 5 pro Hardware konfiguriert und jeder unterhält einen eigenen ZFS-Pool, der die Sicherungen speichern soll.

Das Diskstorage ist in RAID6 (pro Hardware) konfiguriert und enthält ein einziges großes LVM-Volumen, das für alle Knoten im Cluster ist und das dazu dient die VMs zu speichern. Das Bandarchiv ist über SAS mit einem der PVE-Server verbunden und wird von iSCSI mit SCST exportiert, auf diese Weise kann es von jeder VM im Cluster verwendet werden.

Im Cluster gibt es derzeit etwa 15 VMs, jede hat eine sehr spezifische Funktion: z.B. ein drahtloser Netzwerk-Controller Ubiquiti UniFi (Debian), zwei Domänen-Controller ActiveDirectory (Win2012R2), ein LAMP-Server (Debian), ein NVR UniFi AirVision (Debian), ein PXE-Server (Debian), ein Anwendungsserver (einer mit Debian, einer mit Windows), etc.. Und natürlich die beiden PACS-Server (WIN2008R2), die zwar eine große Menge Ressourcen verbrauchen aber sich nicht auf die Gesamtleistung auswirken. Das einzige, was nicht virtualisiert ist, ist ein FreeBSD-Server (basierend auf pfSense) der als IPv4+6-Router und als Disk-Speicher fungiert für allgemeine Tests (auch mit Proxmox VE implementiert, aber nicht Teil des Clusters).

Pure Magie in Aktion

Wenn wir aus welchem Grund auch immer einen der Knoten herunterfahren müssten, würden die VMs die darauf konfiguriert sind weiter laufen und die die nicht so konfiguriert sind schalten sich aus – kein Grund mehr für uns in aller Früh ins Krankenhaus zu hetzen :-)

Wenn eine VM beschädigt ist, stellen wir einfach wieder das letzte Backup her, und sie funktioniert wieder...wir müssen jetzt nicht mehr panikartig ausschwärmen um identische oder passende Hardware zu finden.“

Pablo Alejandro Hamann
IT departement, Hospital de Urgencias, Municipalidad de Córdoba