Сервер для PACS: расчет емкости, IOPS и сети для DICOM

Что влияет на скорость открытия снимков в PACS

Фраза «PACS быстро открывается» на практике означает несколько разных ожиданий. Сначала пользователь ждет список исследований, затем открытие серии, а потом прокрутку срезов. На каждом шаге узкое место может быть другим, поэтому важно разделять симптомы.

Чаще всего «тормозит» один из участков:

• загрузка списка исследований: поиск, фильтры, сортировка, работа базы данных и индексов;
• открытие серии: передача DICOM по сети и чтение файлов с дисков;
• прокрутка срезов: кэш просмотрщика, скорость чтения мелких блоков, задержки хранилища;
• переход к прошлым исследованиям: доступ к «холодному» архиву на более медленных дисках;
• одновременная работа многих пользователей: очереди на дисках, ограничения сети, нагрузка на сервер приложения.

Пиковые часы почти всегда важнее «средней» нагрузки. Если одновременно смотрят 5 врачей, это один уровень требований. Если 25 рабочих мест открывают КТ-серии параллельно, требования к IOPS, сети и кэшам резко растут, даже если общий объем архива пока небольшой.

Рост базы влияет не только на терабайты. Со временем увеличиваются таблицы метаданных, индексы и журналы, кэш чаще «промахивается», а запросы к истории пациента становятся тяжелее. В итоге PACS может упереться в задержки базы и хранения, хотя дискового места еще достаточно.

Скорость складывается из работы четырех частей: хранилища, сети, сервера приложения (PACS/БД) и просмотрщика. Хороший расчет начинается с понимания того, где именно появляется задержка в ваших сценариях.

Исходные данные, без которых расчеты будут неточными

Перед тем как подбирать сервер под PACS, соберите исходные цифры. Без них легко ошибиться в 2-3 раза: либо переплатить за оборудование, либо получить долгие открытия снимков в часы приема.

Сначала зафиксируйте список модальностей. КТ и МРТ обычно дают самый большой рост архива, но рентген, маммография, УЗИ и эндоскопия тоже важны: они добавляют много «мелких» исследований и создают нагрузку за счет одновременных просмотров.

Дальше нужны реальные размеры исследований по каждой модальности (в МБ или ГБ). Не берите «среднюю по больнице»: у КТ головы и КТ грудной клетки будут разные объемы, как и у МРТ с разными протоколами. Проще всего выгрузить статистику из текущей PACS/модальностей за 2-4 недели и взять медиану.

Отдельно зафиксируйте три группы требований:

• сколько исследований в день по каждой модальности и как меняется поток в пиковые дни;
• сколько дней (или месяцев) нужно хранить «онлайн», то есть на быстром хранилище для мгновенного открытия;
• сколько копий данных требуется: рабочая, резервная, плюс реплика для отказоустойчивости.

Проверьте требования регулятора и внутренние правила: срок хранения, необходимость неизменяемого архива, регламенты по резервному копированию и восстановлению. На практике часто просят держать последние 6-12 месяцев «горячими», а более старые исследования переносить в более дешевый слой хранения без потери доступа.

Небольшой пример: клиника добавляет КТ, поток вырастает на 15 исследований в день. При среднем размере 1,2 ГБ это около 18 ГБ в сутки только по одной модальности. С учетом копий и «онлайн»-срока итоговая емкость меняется резко, и это лучше посчитать до закупки.

Как рассчитать емкость архива DICOM на 1-3 года

Емкость PACS обычно считают в двух слоях: быстрый онлайн-архив (то, что врачи чаще открывают в рабочие часы) и более дешевое долгосрочное хранение (то, к чему обращаются редко, но хранить нужно по регламенту). Такое разделение помогает держать скорость стабильной и не переплачивать за «дорогие» терабайты.

Базовая формула простая:

Емкость = дневной объем исследований x срок хранения (в днях) x коэффициент роста + служебный запас.

Дневной объем лучше брать не «средний по году», а «типичный загруженный день», иначе вы недооцените пики.

К служебному запасу относите не только сами DICOM-файлы, но и то, что часто забывают при подборе сервера под PACS: базу данных, индексы, превью, метаданные, журналы, временные файлы, место под обслуживание и обновления. Практичное правило для старта - добавить 15-30% сверху (точнее скажет ваш PACS-вендор и политика резервного копирования).

Рост лучше считать не одной цифрой, а планом. На емкость сильнее всего влияют новые модальности и изменения протоколов (например, переход на тонкие срезы КТ).

Удобный способ задать коэффициент роста:

• +10-20% в год на общий рост потока пациентов;
• отдельной строкой: запуск КТ/МРТ, скринингов, новых отделений;
• изменения качества: больше кадров, выше разрешение.

Пример оценки (упрощенно). Сейчас вы пишете 200 ГБ в день, служебный запас 20%.

• Сейчас (онлайн 90 дней): 200 x 90 = 18 ТБ, с запасом примерно 22 ТБ.
• Через 1 год (рост 15%): дневной объем 230 ГБ, онлайн примерно 25 ТБ.
• Через 3 года (15% ежегодно): дневной объем примерно 305 ГБ, онлайн примерно 33 ТБ.

Долгосрочное хранение считайте так же, но на срок 1-3 года (или больше по вашим требованиям) и с учетом того, что туда уйдет почти весь поток.

IOPS и задержки: что критично для PACS, а что вторично

В PACS скорость ощущается не тогда, когда «быстро копируются гигабайты», а когда врач кликает и ждет. Почти все такие действия упираются в мелкие операции чтения и время отклика дисков, поэтому важны и IOPS, и задержка (latency) в миллисекундах.

Нагрузку создают не только DICOM-файлы, но и «обвязка» просмотра: поиск пациента, открытие исследования, выбор серии, перелистывание кадров, подгрузка миниатюр и предзагрузка соседних срезов. Это часто похоже на множество коротких запросов к базе и чтений небольших блоков с диска.

Случайное чтение против последовательного

Последовательное чтение - это когда рабочая станция тянет большой файл или длинный кусок серии подряд. Здесь важна пропускная способность (MB/s). Случайное чтение - это когда система дергает много мелких фрагментов из разных мест. В PACS именно оно чаще «убивает» скорость в часы пик.

Ключевой показатель здесь - задержка. Даже при «высоких IOPS на бумаге» latency 15-25 мс на HDD дает паузы в интерфейсе. Для интерактивной работы комфортнее, когда чтение укладывается в единицы миллисекунд, поэтому SSD (или хотя бы SSD-кэш) часто дает эффект сильнее, чем просто добавление HDD.

Как снизить задержки без переплаты

Рабочая схема обычно выглядит так: базу данных и журналы держат на отдельном быстром SSD-пуле, а DICOM-файлы - на другом пуле. Дополнительно помогает SSD-кэш под «горячие» данные и разделение потоков, чтобы просмотр (чтение) не страдал из-за фоновой архивации и резервного копирования.

Для грубой прикидки можно закладывать 50-150 случайных IOPS на одного активного врача в пиковые часы (сильно зависит от модальности, толщины среза и поведения просмотрщика). Проверка на практике простая: в тестовый день имитируйте 5-10 одновременных открытий типовых исследований и смотрите не только загрузку дисков, но и среднюю задержку чтения. Если latency начинает «прыгать» вверх, пользователи это почувствуют сразу.

Пошаговый расчет производительности хранения (простая методика)

Чтобы снимки открывались быстро, полезно считать не абстрактные IOPS, а понятный пик: сколько исследований одновременно читают врачи и как именно они их смотрят.

1) Считаем пик одновременных открытий

Возьмите самый загруженный час и оцените, сколько рабочих мест реально открывают исследования параллельно. Не путайте это с количеством учетных записей в системе: одновременно читают обычно меньше.

Дальше зафиксируйте сценарии просмотра. Например: обычный просмотр одного исследования, сравнение с прошлым (два исследования), или мультисерийное КТ с активной прокруткой.

2) Переводим сценарии в МБ/с и IOPS

Практически всегда важны две величины: скорость чтения (МБ/с) и число операций чтения (IOPS). Для грубой оценки достаточно такого подхода:

• определите типичный размер исследования (например, КТ 800 МБ, МРТ 400 МБ, рентген 20 МБ);
• оцените, какой объем нужно прочитать, чтобы врач начал работать (часто 5-20% от исследования, остальное догружается);
• задайте целевое время первого открытия (например, 2-5 секунд);
• посчитайте требуемую скорость: (объем для старта) / (время);
• оцените IOPS от среднего размера блока чтения. Если блок 256 КБ, то 100 МБ/с примерно равны 400 IOPS (100 / 0,256).

Мини-пример: 10 врачей в пике открывают КТ, для старта нужно 100 МБ за 3 секунды. На одного врача это около 33 МБ/с, на десять - около 330 МБ/с только на первичное открытие.

3) Учитываем фон и добавляем запас

К пиковому чтению добавьте фоновые задачи: импорт новых исследований, сжатие, пересборку индексов, репликацию, бэкап. Они могут съедать заметную долю диска именно днем.

Заложите запас 20-40% и заранее пропишите критерии приемки: например, «первое отображение КТ до 3 секунд в часы пик» и «сравнение с прошлым исследованием без ощутимых пауз».

Требования к сети для DICOM: скорость, задержка и пиковые нагрузки

В PACS сеть чувствуется сразу: снимок может «весить» много, а врач ждет не «когда-нибудь», а сейчас. При этом нагрузка разная. DICOM C-STORE (загрузка с модальностей) чаще идет ровным потоком, а C-FIND и особенно C-MOVE (выдача на рабочие станции) дают резкие пики, когда несколько врачей одновременно открывают серии.

По скорости ориентируйтесь не на среднюю, а на пик в рабочие часы. 1 Гбит/с часто хватает для небольшого отделения и умеренного потока КТ/МРТ, но 10 Гбит/с становится нужным, когда много рабочих мест, активно поднимается архив, есть 3D-постобработка или растет число КТ. Простой признак: если при одновременной выдаче нескольких исследований «проседает» отклик у всех, апгрейд сети даст эффект быстрее, чем замена дисков.

Качество канала важнее «скорости по тарифу». Для DICOM критичны задержка и потери пакетов: при потерях TCP начинает переотправки, и фактическая скорость падает в разы. Даже мощный сервер не поможет, если между PACS и рабочими станциями нестабильные коммутаторы, перегруженный Wi-Fi или длинные цепочки без контроля ошибок.

Чтобы сеть вела себя предсказуемо, обычно отделяют медицинский трафик от офисного (VLAN), задают приоритет для DICOM и просмотра (QoS), ограничивают «шумные» задачи (резервные копии, обновления) в рабочие часы и измеряют реальную пропускную способность, задержку и потери, а не только факт «линк поднят».

Для филиалов и телерадиологии чаще упираются не в LAN, а в WAN. VPN добавляет накладные расходы, а канал может быть «широкий», но с высокой задержкой. Практичный вариант - держать локальный кэш ближе к рабочему месту (на шлюзе или станции просмотра) и переносить большие выгрузки из архива на ночь, оставляя днем только то, что нужно для текущих пациентов.

Выбор дисковой подсистемы: SSD, HDD, RAID и уровни хранения

Дисковая подсистема в PACS решает две разные задачи: быстро находить нужное исследование и быстро отдавать сами DICOM-файлы. Поэтому часто выгодно разделять хранение: SSD для базы данных, индексов и журналов, и отдельный пул для DICOM-архива. Так поиск остается быстрым, а массовые записи меньше влияют на выдачу снимков.

SSD и HDD: как распределить роли

Практичный вариант: «горячее» держим на SSD, «холодное» на HDD. На SSD обычно кладут базу PACS (метаданные), кэш просмотра и последние месяцы исследований, которые открывают чаще всего. На HDD уходит основной архив на годы.

Если бюджет ограничен, «все на SSD» не всегда лучший план. Объемы КТ и МРТ растут быстро, и переплата за терабайты может быть заметнее, чем выигрыш. Чаще всего больше дает правильно настроенный кэш: популярные исследования открываются с SSD, а старые спокойно лежат на HDD.

RAID без лишних терминов

RAID нужен, чтобы отказ диска не остановил работу. Для PACS важно и чтение, и запись, поэтому выбирайте схему, где системе проще переживать поломки и восстановление.

Ориентиры:

• RAID 10 выбирают, когда важны быстрые записи и предсказуемая скорость (например, активный пул и база).
• RAID 6 экономит емкость и переносит отказ двух дисков, но восстановление может идти дольше и сильнее «просаживать» скорость на больших HDD.
• Hot spare помогает быстрее начать восстановление без участия инженера.

Tiering (уровни хранения) и кэш полезны, когда нужно уложиться в бюджет: небольшой слой SSD «подхватывает» частые чтения, а основной объем дает HDD.

Локальные диски или SAN/NAS

Если у вас один PACS и умеренная нагрузка, локальные диски в сервере часто проще и дешевле. SAN/NAS обычно выбирают, когда нескольким системам нужно совместно работать с хранилищем, требуется масштабирование без остановок, или есть строгие требования к отказоустойчивости на уровне всего хранилища.

Не забывайте про эксплуатацию: удобную замену дисков, мониторинг состояния, запас слотов под расширение, понятную схему обновления.

CPU, RAM и архитектура: один сервер или разделение ролей

Для PACS чаще всего «упираются» не в процессор, а в хранение и сеть. Но CPU и RAM напрямую влияют на стабильность в часы пик, когда одновременно идут записи, выдача исследований и построение превью.

По CPU ориентир простой: лучше больше «обычных» ядер, чем несколько самых быстрых. Процессор нужен для фоновых задач (компрессия, пересборка индексов, генерация превью, шифрование, антивирусный контроль, веб-сервисы). Если CPU постоянно держится выше 70-80% в рабочие часы, задержки начинают расползаться по всей системе.

RAM часто дает самый заметный эффект, потому что помогает кэшем. Чем больше памяти, тем больше шансов, что часто открываемые серии, метаданные и индексы будут читаться без лишних обращений к дискам. Типичный симптом нехватки RAM - активный swap и резкие «ступеньки» времени открытия исследований.

Архитектурно есть два пути: все на одном сервере (проще и быстрее внедрить) или разделить роли, чтобы пики одной части не «душили» другую. Обычно отдельно выносят базу данных, сервисы store/retrieve и веб-просмотр, а при высокой нагрузке добавляют отдельный узел для 3D/постобработки.

Виртуализация удобна для эксплуатации и резервирования, но есть риск, что задержки вырастут из-за «соседей» и неправильных лимитов. Правило простое: фиксируйте ресурсы (CPU/RAM), не экономьте на контроллерах и сетевых очередях, и заранее тестируйте сценарий «час пик».

GPU нужен не для хранения DICOM, а для тяжелой визуализации (3D MPR/VR, ИИ-обработка, рендеринг). Для обычного просмотра и архива GPU на сервере часто не дает заметной выгоды.

С первого дня полезно снимать метрики, чтобы рост базы не стал сюрпризом:

• CPU: загрузка и очередь;
• RAM: кэш и swap;
• диск: IOPS, latency, очередь;
• сеть: пропускная способность и потери;
• приложение: время retrieve и открытия серии.

Частые ошибки при подборе сервера под PACS

Самая частая ошибка - смотреть только на общий объем архива. В реальности место съедают не только DICOM-файлы, но и база данных, индексы, журналы, временные файлы, а также хранение резервных копий (или место под их выгрузку). Если заложить объем «впритык», система начинает тормозить раньше, чем заканчиваются диски: из-за переполнения журналов, нехватки свободного пространства для служебных операций и ухудшения работы кэшей.

Вторая ловушка - планирование по «среднему дню». PACS живет пиками: утром массово приходят исследования, днем идет активная выдача врачам, а под вечер закрывают отчеты и повторно открывают сложные случаи. Если считать IOPS и сеть по средним значениям, в часы нагрузки снимки будут открываться заметно дольше.

Еще одна типичная ошибка - складывать на один и тот же массив сразу все: DICOM-архив, базу данных PACS и бэкапы. В такой схеме фоновые задачи (например, резервное копирование или проверка целостности) легко «съедают» дисковые операции у врачей. Лучше разделять роли хотя бы на уровне разных пулов/томов, а при серьезной нагрузке - и по отдельным узлам.

Про сеть часто вспоминают в последнюю очередь, особенно если есть филиалы. Даже если серверная часть мощная, узкий канал или высокая задержка между сервером и рабочими станциями превращают просмотр КТ в ожидание загрузки каждого среза.

Чтобы сервер под PACS не стал проблемой через полгода, заранее зафиксируйте: ожидаемый пик одновременных просмотров, где лежат БД, DICOM и резервные копии (раздельно), какой запас нужен на рост в 2-3 раза, когда выполняется бэкап, и какие каналы связи есть до филиалов.

Простой пример: клиника добавила второй КТ и открыла филиал. Объем архива вырос быстро, но сильнее ударило то, что бэкапы начали идти в 18:00, ровно когда врачи массово пересматривают исследования. Без плана масштабирования и разнесения нагрузок даже хороший конфиг начинает «проседать».

Если вы привлекаете интегратора, просите не только «список железа», а расчет с допущениями, нагрузочным профилем и запасом.

Быстрый чек-лист перед закупкой и внедрением

Перед покупкой сервера под PACS зафиксируйте несколько чисел и правил. Это занимает час, но потом экономит недели споров и переделок.

Сначала договоритесь с врачами о цели по скорости. «Быстро» у всех разное: для рентгена это одно, для КТ с сотнями срезов - другое. Запишите целевое время открытия исследования в часы пик в секундах (и отдельно - время первой картинки).

Дальше проверьте ключевые точки, которые чаще всего ломают ожидания:

• цель по отклику в пике: сколько одновременно врачей и постов, и какая задержка считается нормой;
• онлайн-архив: сколько месяцев или лет храните «горячие» исследования на быстром хранилище, и какой запас берете на рост базы;
• разделение ресурсов: база данных и DICOM-хранилище не должны бороться за одни и те же диски;
• сеть по факту, а не «по паспорту»: измерьте скорость, задержку, потери и загрузку в пике;
• бэкап и восстановление простыми словами: сколько данных можно потерять (RPO) и за сколько обязаны поднять сервис (RTO).

В конце определите план масштабирования: что добавляете первым при росте (пул хранения, апгрейд сети, второй узел/сервер) и какие ограничения могут упереться раньше всего (контроллеры, сеть, лицензии, окна бэкапа).

Пример сценария: клиника растет, а снимки должны открываться быстро

Представим многопрофильный центр: 120 исследований в день. Из них 60 рентгенов (в среднем 30 МБ на исследование), 40 КТ (350 МБ), 20 МРТ (250 МБ). В сумме выходит около 22-25 ГБ новых данных в сутки, то есть примерно 8-9 ТБ в год без учета служебных файлов и резервов.

Первые полгода все довольны: 10 рабочих мест, снимки открываются за 2-4 секунды. Потом ставят еще один КТ, а число врачебных рабочих мест растет до 20. Суточный прирост данных увеличивается примерно на треть, а главное - растет одновременная нагрузка в рабочие часы: несколько врачей листают серии, лаборанты отправляют исследования, идут печать и выгрузки.

Когда сервер под PACS начинает «не успевать», это обычно видно по симптомам:

• долго открывается список исследований и поиск пациента - чаще упираетесь в БД и задержки диска;
• первые кадры появляются быстро, а прокрутка и подгрузка серии «затыкается» - часто не хватает IOPS у хранилища;
• ночью все нормально, а с 10:00 до 16:00 «тормозит» - признак пиков по сети или по дискам;
• передача между модальностью и PACS идет рывками - может быть узкое место по сети или по приемному диску.

Быстрый эффект обычно дают шаги, которые отделяют «интерактивное» от фонового:

• перенести БД и журналирование на SSD (отдельный том), чтобы поиск и карточки не зависели от архива;
• добавить SSD-кэш для «горячих» данных (последние 30-90 дней), а старое держать на HDD;
• перейти на 10 Гбит/с на магистрали PACS, если в пике идет много параллельных просмотров;
• разнести роли (хранилище, БД, сервисы), чтобы обновления и бэкап не забирали отклик.

Чтобы клиника росла без полной замены, обычно закладывают резерв по емкости 30-50% на 1-2 года, возможность добавить дисковые полки или второй узел хранения, и понятный план очередности апгрейдов (SSD-кэш и сеть, затем емкость архива).

Следующие шаги: как оформить требования и выбрать поставку

Начните с измеримых целей. Зафиксируйте, за сколько секунд снимок должен открываться в рабочие часы (например, первые кадры КТ - до 3-5 секунд на рабочем месте) и что будет считаться деградацией в пик.

Соберите исходные цифры и сведите их в один документ, который можно согласовать между ИТ, рентген-службой и руководством. Часто хватает короткого ТЗ на 1-2 страницы с приложением расчетов.

Полезно включить:

• профиль нагрузки: сколько исследований в день, сколько одновременных врачей, какие модальности и когда пик;
• целевые времена: открытие исследования, прокрутка серии, сравнение с прошлым;
• расчет: емкость (с учетом роста и ретеншн), IOPS и пропускная способность сети, плюс запас 20-30%;
• план проверки: сверка по логам PACS и короткий пилот на реальных рабочих местах;
• надежность и обслуживание: что должно переживаться без простоя, мониторинг, регламенты замены компонентов.

После этого уже проще выбирать конкретную поставку и проверять, как система расширяется через 12-24 месяца.

Если нужен партнер, который закрывает и «железо», и интеграцию, уместно обсудить проект с GSE.kz (gse.kz): это производитель и системный интегратор из Казахстана, у которого есть серверная линейка S200 и опыт построения инфраструктуры, включая поддержку 24/7. В таком разговоре удобно сразу увязать хранение, сеть и резервирование под ваши пиковые сценарии, а не под «средний день».