導⼊検討・ご相談はこちら
まずはお気軽ご相談ください
CASE STUDY導入実績
PROXMOX検討によろしければご参照ください
SUCCESS STORYアルゼンチン、コルドバの市立救急病院
コルドバ市の市立救急病院のIT部門のパブロ・ハマンは、Proxmox VEを実装して、診断前の画像検査のデジタル化を促進し、ハードウェアの独立性を実現し、サーバの管理作業を容易にしました。この実装はいくつかの段階で行われ、全スタッフから満足の声を得ることができました。
コルドバ大都市圏の医療緊急サービスの中心地
コルドバの市立緊急病院は、アルゼンチンのコルドバ州にある都市部（コルドバ市と周辺の町を含む都市圏）の医療緊急時の医療センターです。
コルドバはアルゼンチンで2番目に大きな都市であり（首都のブエノスアイレスに次ぐ）、コルドバには3つの公立病院がありますが、最大の病院は市立緊急病院です。この病院には約700人の従業員がおり、医学的緊急事態で到着するすべての人々に対して公共かつ無料の医療を提供しています（外国人も含む）。市立緊急病院は多重外傷の治療に特化しており、多重の怪我を負った重大事故の主要な原因の一つが交通事故であるためです。外傷学は、病院が提供する15の医療サービスの中で最も大きなものです。さらに、病院は医療サービスを補完するための補助サービスも提供しており、その中で最も重要なのが診断画像サービスで、これには放射線、トモグラフィー、血管造影、超音波が含まれています。
年間50万件の画像研究を
最適化するためのインフラストラクチャ
現在、市立緊急病院では週に約1,500人の緊急患者が診察されています。通常、すべての患者は、怪我の重症度に応じて、ますます多くの画像研究で最初にチェックされます。一方、生成される画像研究の量は非常に多大です（年間約50万件の研究）ので、これを効率化するためにシステム全体をデジタル化することにしました。同時に、運用コストを削減することも考えていました。
緊急病院の経営陣が診断画像研究をデジタル化することを決定した際、主要な具体的な要件は、「BBB」と呼ばれるシステム（スペイン語で「良い、美しい、安い」を意味する）を実装することでした。さらに、冗長性を持たせる必要がありました。それ以上でもそれ以下でもありません。
ITインフラストラクチャの限界
この段階では、病院のIT部門にはUSD 200のクローンされた裸のメタルで直接実行されているWindowsサーバーが数台しかありませんでした。過去数年間でITインフラストラクチャ全体が着実に成長していました。ますます多くのワークステーション、ユーザー、プリンター、ネットワークデバイスが増加しており、最終的には医療機器がその上に追加され、既存のインフラストラクチャには過度の負荷となりました。
この時点で、壊れたサーバーハードウェアの代替品を急いで購入するのに忙しかったことはもちろん、すべてのスタッフにとって大きな頭痛と不満を引き起こしました。それに加えて、ワークステーションは単純で無能な端末であることが判明し、何もできませんでした。最終的に、仮想化ソリューションが必要不可欠であることを痛感しました。
追加のサーバの購入は仮想化の扉を開きます
ある時点で、新しいサーバーを実行するためにハードウェアの購入決定をしなければならなくなりました。この時点で、ハードウェアの独立性を実現し、サーバーのメンテナンスタスクを容易にするために仮想化が唯一の方法であることは明らかでした。また、この新しいハードウェアは、すでにクローン装置でテスト済みのPACS（画像アーカイブおよび通信システム）サーバーに専用指定されることも明確でした。PACSは、DICOM（医学でのデジタル画像と通信に関する規格）のデジタルアーカイブ技術です。サーバーソフトウェアは、ハードウェアに直接インストールするほど重いものでした。
独自のソリューションは公共団体には
適切ではないと思われる
しかし、数年前には、私はコルドバ国立工科大学（National Technological University）の地域学部、コルドバ地域の情報システム研究所（LabSis）で働いており、そこでQEMU/KVMの初期の実装に感銘を受けました。したがって、緊急病院のサーバーインフラストラクチャを拡張する機会が訪れた際、GNU/DebianのクラスターをQEMU/KVM仮想化を中心に実装し、PACSサーバーだけでなく、以前にベアメタルで実行されていたWindowsサーバーも実行できる機会だと考えました。そして、Proxmox VEの存在をまだ知らなかったとしても、このタスクに対していかなるプロプライエタリソリューションとも「結婚」したくなかったことは明確でした。VMware vSphere、MicrosoftのHyper-V、Citrix Xenなど、公共環境には適していないと私の正直な意見では考えていたからです。
オープンソースのProxmox VEを知るチャンス
幸運にも、私たちは外部のIT専門家にProxmox VEを紹介されました。私は本当に驚きました。Proxmox VEは私にとって「子供の夢」（アルゼンチンの表現で「大きな夢」または「達成不可能な夢」を意味します）でした。
一方で、Proxmox VEはクラスター実装に関する多くの問題、バックアップ管理、iSCSIディスクストレージの本番稼働を簡素化してくれました。そして、非常に使いやすく、シンプルでうまく作られたWebインターフェースを提供しました。これにより、クライアントコンピュータのソフトウェアから独立できました。これは初めはMicrosoft Hyper-Vなどの他のソリューションに対して少し好意的な経営陣を説得するのに役立ちました。
使用したハードウェア
市立緊急病院は公的機関として、ハードウェアコストを含むすべてのコストを最小限に抑える努力を常にしています。ハードウェアの購入は複数の段階で実施され、最終的には次のとおりです。
- 3台のIBM System x3650 M4サーバー、16コアのマイクロプロセッサ、64GBのRAM、8台の1TB SAS-2ディスク、4ポートのギガビットイーサネットを搭載
- 1台のIBM System x3250 M5サーバー、8コアのマイクロプロセッサ、32GBのRAM、4台の1TB SATA-3ディスク、4ポートのギガビットイーサネットを搭載
- 1台のIBM DS3524 SAS-2ディスクストレージ、4チャンネルのiSCSIギガビットLAN
- 2つのSAS-2インターフェースを搭載したIBM TS3200 Tape Library Backup
Proxmox VEの実装
最初に、Proxmox VEのシンプルな実装から始めました。最初の数ヶ月は、新しくリリースされたPVE 3.2のデフォルトインストールで、PACSサーバーが2つのWindows仮想マシンを仮想化しました。それは素晴らしかったです。サービスの責任者はそれを気に入りました。私たちが行ったのはPVEをインストールして使用するだけで、何も設定していなかったのです。実際、クラスターさえまだ構成されていませんでした。インストールと使用の簡単さが管理陣を納得させました。
半年後、ついにクラスター全体を構成しました。そして、月々、以前の物理サーバーを仮想化し始めました。1年後、問題なくバージョンProxmox VE 3.4にアップデートし、すべてのストレージタンクが再構成されました。少なくとも10台の仮想マシンはiSCSI LVMディスクとして構成された大容量のストレージに移動され、各サーバーのすべてのディスクはバックアップの目的でZFSプールを作成するために使用されました。
翌年（2016年1月）には、クラスター全体をProxmox VE 4.1にアップデートしました。これは設定をほんの少し変更しただけでaptを使用して行われ、何の問題もありませんでした（この時点で私は夢を見ていると思いました）。
バージョン4.1への移行は、好奇心からだけでなく、必要性からも動機づけられました。テープライブラリはまだ構成されるのを待っており、SASポートしか利用できませんでした。VMと接続する唯一の方法は、SAS経由でPVEサーバーの1つに接続し、それをiSCSI経由でエクスポートすることでした。これにはSCSTを使用しましたが、それは確かに2.6カーネル（3.xシリーズのPVEのベース）で問題を抱えていました。4.xブランチ（Proxmox VEは現在、カーネル4.xで提供されています）に移行した後、SCSTを実装することができ、大きな問題はありませんでした。したがって、ライブラリをiSCSIで正常にエクスポートできるようになりました。
- 3台のIBM System x3650 M4サーバー、16コアのマイクロプロセッサ、64GBのRAM、8台の1TB SAS-2ディスク、4ポートのギガビットイーサネットを搭載
- 1台のIBM System x3250 M5サーバー、8コアのマイクロプロセッサ、32GBのRAM、4台の1TB SATA-3ディスク、4ポートのギガビットイーサネットを搭載
- 1台のIBM DS3524 SAS-2ディスクストレージ、4チャンネルのiSCSIギガビットLAN
- 2つのSAS-2インターフェースを搭載したIBM TS3200 Tape Library Backup
最終的な設定と利点
現在、私たちのProxmox VEの実装は、上記の4台のサーバーからなるクラスターで構成されています。各サーバーには4つのギガビットイーサネットポートがあるため、ノード間の接続はOpen vSwitchを使用してLACPボンディング（ノードLAN用の2つのポートをTRUNKモードで、iSCSI LAN用の2つのポート）で構成されています。
各コンピューターには、ハードウェアごとに2つのRAIDディスクミラーリング（RAID1）があり、LVMを使用してインストールされています。各コンピューターの残りのディスクはハードウェアごとにRAID 5で構成され、各ディスクにはバックアップ用のZFSプールがあります。
ディスクストレージはハードウェアごとにRAID 6に設定されており、すべてのノードで共通の大容量のLVMボリュームが含まれており、VMを保存するために使用されています。
テープライブラリはSAS経由でPVEサーバーの1台に接続され、SCSTを使用してiSCSI経由でエクスポートされ、クラスター内の任意のVMで使用できるようになっています。
クラスター内のVMには、それぞれ非常に特定の機能を持つ約15台のVMが稼働しており、DebianベースのUbiquiti UniFiのネットワークコントローラー、2つのActiveDirectoryドメインコントローラー（Win2012R2）、LAMPサーバー（Debian）、NVR UniFi airVision（Debian）、PXEサーバー（Debian）、アプリケーションサーバー（1つはDebian、もう1つはWindows）などが含まれています。そしてもちろん、PACS（WIN2008R2）サーバーも含まれており、大量のリソースを消費していても全体のパフォーマンスに影響を与えません。
仮想化されていない唯一のものは、IPv4 + 6ルーターとして機能するFreeBSDサーバー（pfSenseベース）と、一般的なテスト用の自家製ディスクのストレージ実装（またProxmox VEで実装されていますが、クラスターの一部ではありません）です。
- 3台のIBM System x3650 M4サーバー、16コアのマイクロプロセッサ、64GBのRAM、8台の1TB SAS-2ディスク、4ポートのギガビットイーサネットを搭載
- 1台のIBM System x3250 M5サーバー、8コアのマイクロプロセッサ、32GBのRAM、4台の1TB SATA-3ディスク、4ポートのギガビットイーサネットを搭載
- 1台のIBM DS3524 SAS-2ディスクストレージ、4チャンネルのiSCSIギガビットLAN
- 2つのSAS-2インターフェースを搭載したIBM TS3200 Tape Library Backup
魔法のような運用
何らかの理由でノードの1つをシャットダウンしなければならない場合、稼働中のVMは引き続き稼働し、停止する必要のないVMは停止します。どのVMが損傷しても、最新のバックアップを復元するだけで、それは引き続き動作します。損傷したハードウェアの同一のものを必死に探しに出かける必要はありません。ですから、生活は本当に楽になりました。
- パブロ・アレハンドロ・ハマン
- コルドバ市ウルゲンシア病院 IT 部門
CONTACT
- 都市 : コルドバ
- 所在国 : アルゼンチン
