Мультисерверная архитектура КМИС

Одна из основных задач при разработке КМИС - возможность свободного масштабирования системы от уровня небольшого фельдшерского пункта до крупного регионального лечебного учреждения.
Мы выделяем два основных направления:
  • Масштабирование внутри ЛПУ (уровневое). С ростом нагрузки на сервер КМИС система должна позволять увеличивать производительность сервера или сохранять его на заданном уровне без удаления информации из БД путем простого увеличения мощности сервера или добавлением новых серверов в общий вычислительный центр.
  • Территориальное масштабирование. Т.е. возможность использования системы в распределенных по территории лечебных учреждениях. При этом каждое лечебное учреждение имеет свою базу данных, однако все они соединены между собой и могут либо обмениваться любой информацией, либо работать как единая база данных, т.е. в прозрачном для пользователя режиме. Эта возможность специально предусмотрена в архитектуре ядра системы для региональных проектов автоматизации.

Основные технологии, используемые для масштабирования КМИС
  • Репликация баз данных по расписанию позволяет обмениваться изменениями в любых базах данных системы между серверами ЛПУ. Так, центральная база данных регионального уровня может автоматически собирать в себя всю информацию о пациенте, находящемся на лечении в районной больнице. При перемещении пациента из местного ЛПУ в республиканское ему нет необходимости везти с собой амбулаторную карту, рентгеновские снимки или другие медицинские данные – вся информация доступна врачам соединенных между собой медицинских учреждений
  • Поддерджка кластеров позволяет масштабировать производительность КМИС путем простого добавления новых узлов в кластер и распределения (в том числе балансирования) нагрузки.
  • Автоматическое обновление приложений позволяет избежать серьезной проблемы обновления ПО на территориально-распределенной системе. Все начальные изменения могут производиться на любом узле (сервере), но автоматически будут унаследованы другими серверами. При этом строго ограничивается возможность злонамеренных исправлений в программном обеспечении, т.к. подсистема безопасности распространяется не только на информацию, но и на программы.

Использование данных технологий, кроме решения задач масштабирования, позволяет добиться следующих существенных преимуществ:
  • повышение отказоустойчивости системы за счет того, что в случае выхода одного из серверов из строя, кластер продолжает работу за счет других своих членов
  • автоматическое резервное копирование информации за счет синхронизации информационных потоков между всеми членами кластера
  • выполнение обслуживания без остановки КМИС. Эта возможность позволяет проводить плановые работы по обслуживанию сервера без прекращения работы пользователей системы.

Поддержка распределенной базы данных

Важнейшим способом увеличения доступности и производительности системы является принцип распределенной БД. КМИС - уникальная в этом плане система, т.к. поддержка распределенных БД является не просто опцией системы, а основой все ее архитектуры.

Мы поддерживаем 2 основных подхода для реализации распределенной БД:
  • Программная поддержка работы с распределенными БД, когда ядро системы (БД историй болезни, амбулаторных карт и т.д.) могут быть физически разделены на несколько автономных частей, расположенных на одном или нескольких выделенных серверах. При этом могут быть выделены архивные БД и БД для текущей (оперативной) работы с медицинской документацией. КМИС автоматически определяет распределенную инсталляцию и сама осуществляет обмена данными между серверами в режиме реального времени или с помощью репликации. В любом случае - для пользователя наличие распределенной БД никак не заметно - ни с точки зрения производительности, но с точки зрения функциональных возможностей.
  • Поддержка аппаратно распределеных БД. Аппаратное распределение БД состоит в том, что часть системы, наиболее требовательная к производительности работы (например, БД текущих историй болезни стационара), помещаются на максимально мощные (основные) серверы. Остальная часть (архивы, дистрибутивы ПО и т. д.) помещается на менее производительные (резервные) серверы, не расходуя, таким образом, ресурсы основных. При этом происходит разграничение задач для серверов (балансировка нагрузки).

Поддержка территориального распределения серверов

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

Экономичный вариант. В случае, когда имеется один мощный компьютер, а второй менее мощный, можно выполнить распределение по схеме экономичного варианта. При этом строится «псевдокластер». Резервное копирование осуществляется за счет репликации по расписанию между серверами. При штатном режиме работы пользователи обращаются непосредственно к Serv. 1. В случае выхода из строя происходит автоматическое (на стороне клиента) переключение на сервер Serv. 2. При этом допускаются снижение производительности работы системы, и, возможно, потеря определенной части данных, которые находились в оперативной памяти основного сервера и не были реплицированы на резервный сервер. Однако, сохраняется возможность продолжения работы с системой. У службы технического обеспечения имеется время на восстановление основного сервера и переключение пользователей обратно на работу с ним после восстановления информации с резервного сервера.

Экономичный вариант аппаратно распределенной базы данных медицинской информационной системы

Экономичный вариант аппаратно распределенной базы данных медицинской информационной системы

Работа в кластерах серверов. Одинаковые по мощности серверы целесообразно объединять в настоящий кластер. Состав БД на обоих серверах одинаков. Пользователи подключаются к кластеру. Все они первоначально пытаются подключиться к серверу Serv. 1, либо они делятся пополам и каждая часть пользователей подключается к своему серверу. Операции записи в БД синхронизированы. используется механизм балансировки нагрузки. Как и в первом варианте, в случае выхода одного из серверов из строя происходит переключение на резервный сервер.

Необходимо отметить возможность размещения серверов кластера в различных помещениях, а при наличии сегментированной сети – в различных сегментах (корпусах или зданиях ЛПУ). Во-первых, за счет этого повышается надежность хранения данных и доступность системы за счет исключения влияния таких факторов, как пожар, наводнение, разрушение помещения серверной и т.д. Во-вторых, с использованием соответствующего коммуникационного оборудования и размещения серверов в разных сегментах уменьшается нагрузка на сеть.

Оптимальный вариант аппаратно распределенной базы данных медицинской информационной системы

Оптимальный вариант аппаратно распределенной базы данных медицинской информационной системы

Поддержка высокопроизводительных инсталляций. При прогнозировании максимально высокой нагрузки на систему (тысячи пользователей и гигабайты обрабатываемой информации в сутки) и возможности закупки дорогостоящего оборудования имеется возможность построение системы по высокопроизводительной схеме.

Высоко устойчивое аппаратное распределение базы данных медицинской информационной системы
Высоко устойчивое аппаратное распределение базы данных медицинской информационной системы

Основная часть системы, наиболее требовательная к производительности, размещается на максимально мощных серверах кластера А. Остальная размещается на серверах кластера Б.

Кластер Б содержит полную реплику всех данных кластера А. При штатном режиме работы происходит обращение к кластеру А, при этом подключается наименее загруженный сервер кластера. При необходимости доступа к архивам происходит автоматическое подключение к кластеру Б. Внутри кластеров работают службы синхронизации и балансировки нагрузок.

Между кластерами репликация проходит по расписанию, при этом оно составлено так, чтобы минимизировать затраты ресурсов серверов кластера А.