In the Municipal Emergency Hospital of Cordoba (Argentina), Pablo Hamann of the hospital's IT department implemented Proxmox VE to help facilitate the digitization of pre-medical imaging studies, as well as to achieve independence of hardware, and to facilitate management tasks of servers. The implementation was executed in various phases and results satisfactory to the whole staff.
The Municipal Emergency Hospital in the city of Cordoba, is the health care center for medical emergencies in Greater Cordoba (a metropolitan area including the city of Cordoba and surrounding towns), in the province of Cordoba, Argentina.
Cordoba is the second largest city in Argentina (just behind the capital of the Republic Buenos Aires). There are three public hospitals in Cordoba, of which the largest one is the Municipal Emergency Hospital. With nearly 700 employees it provides public and free health care to all people arriving with a medical emergency (even foreigners). The Municipal Emergency Hospital is specialized on the treatment of polytraumas, since one of the main causes of serious accidents with multiple injuries are road accidents. The Traumatology is the largest of the 15 medical services the hospital offers. Additionally, the hospital offers auxiliary services to complement the medical services: the most important one of which is the Diagnostic Imaging Service and consists of radiology, tomography, angiography and ultrasound.
To date, approximately 1.500 emergency patients per week are attended at the Municipal Emergency Hospital. As a routine, all patients are first of all checked with a pre-medical imaging study, for sure depending on the severity of their injuries. Meanwhile, the amount of imaging studies generated is so huge (almost half a million studies annually) that we decided to digitalize the entire system to help streamline it. On the same time we also had an eye to reducing operating costs.
When the management of the Emergency Hospital decided to digitalize the diagnostic imaging studies, the main specific requirement was to implement a system called in Spanish "BBB” (Bueno, Bonito y Barato - translates to: good, beautiful and cheap)" with fault tolerant...nothing more and nothing less.
At this point there were only a few Windows servers running directly on a cloned bare-metal, USD 200 in the hospital's IT department. The whole IT infrastructure had been growing steadily in the last years: More and more workstations, more users, more printers, more network devices. And finally adding the medical appliances on top, it was way to much for the existing infrastructure.
At this time we were busy with rushing out in panic and bying replacements for some broken server hardware. Of course, all this caused enormous headaches and huge dissatisfaction to all of our staff. Apart from that, the workstations turned out to be simple and dumb terminals, unable to do anything. This finally lead to the wake-up call that we badly needed a virtualization solution.
At some point, to run new servers, we had to make a purchase decision for the hardware. At this time it was clear to us that virtualization was the only way to go if we wanted to achieve hardware independence, and facilitate maintenance tasks on the server. It was also clear that this new hardware would be designated exclusively to our two PACS (Picture Archiving and Communication System) servers, that we already had tested on cloned equipment. PACS is a technology for digital archiving DICOM (Digital Imaging and Communications in Medicine). The server software would have been heavy enough to justify the non-virtualization and run them directly on the metal.
But years before I had been working at the Laboratory of Information Systems at the Regional Faculty Córdoba, National Technological University (LabSis), and there I had been amazed with the early implementations of QEMU/KVM which the lab had been using in production. So when the time came to expand the infrastructure of servers in the Emergency Hospital, I saw the opportunity to implement a cluster on GNU/Debian with QEMU/KVM virtualization as a core, and thus run on them not only PACS servers, but also Windows servers that existed previously running on the bare metal. And even though I was still unaware of the existence of Proxmox VE, it was clear to me that I did not want to "marry" with any proprietary solution for such a task: Neither VMware vSphere, nor Microsoft's Hyper-V, nor Citrix Xen proved or are appropriate, in my honest opinion, for a public environment with the characteristics of our Municipal Emergency Hospital.
Luckily we got introduced to Proxmox VE by an external IT professional we contracted. I was really surprised: Proxmox VE was (and is) for me the proverbial "kid's dream" (argentinian expression meaning a "big dream" or "unachievable").
On the one hand, Proxmox VE facilitated for us many problems concerning the cluster implementation, also the backup management, and the production start of iSCSI disk storage. On the other hand, it provided a friendly, simple and well made web interface, which of course, allowed us to get independent from the software from the clients computer. This definitely helped to convince the management, initially a bit more inclined to some other solution like Microsoft Hyper-V.
As a public entity, the Municipal Emergency Hospital always tries hard to minimize all costs, including the hardware costs. The purchase of hardware was therefore realized in several steps and finally consisting in the following:
We first started with a simple implementation of Proxmox VE. For the first couple of months we virtualized only two Windows with the PACS servers on a default installation of a newly released PVE 3.2. It was fabulous. The boss of services loved it: all we had done was to install and use PVE (style "install and use", without configuring anything). In fact, not even the cluster had been configured yet. The simplicity of installation and use convinced the management.
Six months later, we finally configured the entire cluster. And month by month we started virtualizing all our previously existing physical servers. A year later we updated to version Proxmox VE 3.4 without any problems, and all storage tanks were reconfigured: the VMs (which were at least 10) were moved to the storage of a large volume configured as iSCSI LVM disks; and all disks of each server were used to create ZFS pools, with backup purposes.
The following year (January 2016) we updated our entire cluster to Proxmox VE 4.1. This was done via apt with only minimal change to the configuration, and without any problem (at this point I thought I was dreaming).
The move to version 4.1 was motivated by curiosity but also by necessity: the tape library still was waiting to be configured, and only had SAS ports available. The only chance to use it with the VMs was to connect via SAS to one of the PVE servers, and then export it via iSCSI. We used SCST for this, but it certainly had problems with the 2.6 kernel (base of the 3.x series of PVE). Once we moved to the 4.x branch (Proxmox VE now shipped with kernel 4.x), we could implement SCST without any major problem. So we successfully could export the library iSCSI.
Currently, our implementation of Proxmox VE consists of a cluster of the 4 servers mentioned above. Taking advantage that each server has 4 ports giga Ethernet, the connection between nodes is configured using LACP bonding (2 ports for the nodes LAN in TRUNK mode and 2 ports for iSCSI LAN) with Open vSwitch, (aptitude install openvswitch-ipsec).
On each computer, the installation is performed on a 2-RAID disk mirroring (RAID1) per hardware, using LVM. On each computer, the remaining disks are configured in RAID 5 per hardware, and each disk maintains it's own ZFS pool, intended to keep the backups.
The disk storage is set to RAID 6 (for hardware), and contains a single large LVM volume, which is common to all nodes in the cluster and whose purpose is storing the VMs.
The tape library is connected via SAS to one of the PVE servers, and is exported by iSCSI using SCST, this way, it can be used by any VM in the cluster.
In the cluster VM, there are currently about 15 VMs running each of them with a very specific function: we have a network controller wireless Ubiquiti UniFi (Debian), two domain controllers ActiveDirectory (Win2012R2), a LAMP (Debian) server, NVR UniFi airVision (Debian), a PXE server (Debian), an application server (one Debian, another Windows), etc.. And of course, the PACS (WIN2008R2) servers which, although consuming a huge amount of resources, do not affect the overall performance.
The only thing not virtualized, is a FreeBSD server (based on pfSense) acting as IPv4 + 6 router, as well as a storage implementation of homemade discs (craft rather...) for general tests (also implemented with Proxmox VE, but not part of the cluster).
If for some reason we would have to shut down one of the nodes, the VMs configured to keep running, still will run, and those not will go down... no rushing in at dawn :-) If any VM is damaged, we simply restore the latest backup available, and it will continue working... we do not have to go out looking desperately for an identical hardware to the damaged one. So live really became easier :-)
Pablo Alejandro Hamann
IT departement, Hospital de Urgencias, Municipalidad de Córdoba
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。