В предыдущих версиях «1С: Предприятия 8» кластер серверов мог располагаться на нескольких физических компьютерах, но один из этих компьютеров должен был играть роль центрального сервера, координирующего работу всего кластера. Такая архитектура накладывала ряд довольно существенных ограничений на работу кластера серверов «1С: Предприятия 8».
• Выход из строя центрального сервера приводил к разрыву всех клиентских соединений и полностью парализовывал любую работу с информационными базами, обслуживаемыми кластером.
• Плановое техническое обслуживание, например установка обновлений ОС с последующей перезагрузкой, требовало остановки работы пользователей со всеми информационными базами кластера.
• Все общие данные и все сервисные функции кластера (такие, как управление транзакционными блокировками, журналирование событий, полнотекстовый поиск, нумерация объектов, и т. п.) располагались в единственном процессе, могли создавать существенную нагрузку на центральный сервер, но не могли масштабироваться.
Модель клиент-серверного взаимодействия, реализованная в предыдущих версиях «1С: Предприятия 8», также обладала рядом особенностей работы клиентских приложений с кластером.
• Обрыв связи между клиентским приложением и рабочим процессом кластера приводил к аварийному завершению клиентского приложения.
• Отказ рабочего процесса кластера приводил к аварийному завершению всех клиентских приложений, которые обслуживались рабочим процессом.
• Не было возможности перераспределять клиентские соединения между рабочими процессами кластера – обслуживающий рабочий процесс назначался клиентскому соединению «пожизненно». Соответственно нельзя было и передать часть нагрузки с одного рабочего сервера на другой.
«1С: Предприятие 8.2» содержит ряд кардинальных улучшений архитектуры кластера серверов, призванных улучшить масштабируемость и отказоустойчивость информационных систем, построенных на этой технологической платформе.
Во-первых, «горячее» резервирование кластера серверов. У администратора информационной системы появилась возможность объединить несколько кластеров в группу резервирования. Обслуживанием пользователей занимается первый кластер из группы, а остальные поддерживают у себя в актуальном состоянии все важные данные первого кластера. В случае выхода из строя первого кластера, активным становится следующий кластер из группы резервирования. Для рабочих процессов, функционирующих внутри кластера, реализована другая схема – рабочие процессы подразделяются на активные и резервные. В случае плановой или аварийной остановки активного процесса кластер запускает один из резервных процессов и переводит на него имеющуюся нагрузку.
Практически это означает, что при грамотно спроектированной структуре кластера завершение любого из серверных процессов и даже отключение любого из физических компьютеров кластера не приведет к сбою в работе пользователей. Это особенно важно для тех информационных систем, которые работают в режиме «24?7» и остановка которых даже на короткое время может привести к серьезным финансовым потерям предприятия.
Во-вторых, масштабирование управляющих процессов (менеджеров) кластера. Общие данные и сервисные функции кластера теперь могут быть распределены между несколькими процессами- менеджерами, функционирующими на разных физических компьютерах. Эта позволяет существенно разгрузить главный менеджер кластера и переложить часть «сервисной» нагрузки на другие процессы.
В-третьих, новая модель клиент-серверного взаимодействия. Теперь платформа обладает устойчивостью к обрывам каналов связи между клиентом и сервером: в случае, если клиентское приложение не было завершено штатным образом, но перестало подавать признаки жизни, пользовательский сеанс продолжает поддерживаться на стороне сервера в течение довольно длительного времени (20 мин). Если за это время связь будет восстановлена, пользователь сможет продолжить работу с того самого места, где она была прервана.
Следует отметить, что устойчивостью к обрыву связи в любом случае обладают тонкий и Web- клиент, а в случае толстого клиента «воскрешение» пользовательского сеанса зависит главным образом от того, какая именно операция выполнялась клиентским приложением в момент обрыва связи. Некоторые операции (например, работа с транзакциями), к сожалению, требуют непрерывной связи между клиентом и сервером и не могут быть временно прерваны.
В-четвертых, динамическая балансировка нагрузки между рабочими процессами кластера. Кластер постоянно отслеживает загруженность своих рабочих процессов и вычисляет интегральную доступную производительность каждого процесса. Если доступная производительность разных процессов существенно различается, происходит переключение части пользовательских сеансов с более нагруженных процессов на менее нагруженные.
В предыдущих версиях «1С: Предприятия 8» анализ загруженности рабочих процессов тоже выполнялся, но только в момент возникновения нового клиентского соединения – кластер принимал решение, какому из рабочих процессов передать это соединение для обслуживания. Но на практике разные пользователи создают непропорциональную нагрузку на кластер – например, одни просто листают список документов, а другие формируют «тяжелые» отчеты. И при неблагоприятном стечении обстоятельств (несколько «тяжелых» пользователей попали в один рабочий процесс) возникали проблемы производительности информационной системы. Конечный пользователь вовсе не обязан знать о существовании рабочих процессов и тонкостях распределения нагрузки между ними, но на ситуацию «вдруг все стало тормозить» он обязательно отреагирует, причем реакция будет строго негативной.
Механизм динамической балансировки нагрузки на рабочие процессы, появившийся в версии «1С: Предприятие 8.2», позволяет насколько это возможно равномерно распределять активность пользователей по рабочим процессам кластера и использовать аппаратные ресурсы наиболее эффективно.
В предыдущих версиях «1С: Предприятия 8» пользовательский интерфейс целиком и полностью создавался разработчиком прикладного решения. Платформа практически никогда не принимала самостоятельных решений о выводе того или иного элемента на какую-либо форму, а изменения в структуре метаданных конфигурации никоим образом не влияли на интерфейсную часть. Разработчик должен был в явной форме создать командный интерфейс (главное меню и панели инструментов) и в буквальном смысле «нарисовать» все необходимые формы. При этом разработчик получал полную свободу действий – можно было поместить любой элемент в любое место любой формы, придать любой размер, раскрасить в любые цвета и т. д. К сожалению, у полной свободы действий есть и своя оборотная сторона – при работе через Интернет или по медленным каналам связи передача информации о такой форме между клиентом и сервером стала бы очень затратным мероприятием. Более эффективный способ – передача не собственно формы, а правил ее формирования.
В «1С: Предприятии 8.2» реализована принципиально новая интерфейсная модель, называемая управляемым приложением. Управляемое приложение базируется на следующих концепциях.
• Оконная система. Каждое окно «1С: Предприятия 8» в режиме управляемого приложения – независимо и представлено отдельном элементе на панели задач ОС (или же отдельное окно браузера при работе с Web-клиентом). Основное окно предназначено для навигации по функциям конфигурации и данным информационной базы, а вспомогательные окна используются для доступа к данным (например, через формирование отчетов) и модификации объектов информационной базы.
• Декларативное описание интерфейса. Управляемое приложение позволяет разработчику перейти от конструирования интерфейса к декларированию, т. е. к явному или неявному указанию платформе, какой элемент и в какой ситуации выводить или не выводить в пользовательский интерфейс. Наиболее простой пример такого декларирования – настройка прав доступа к объектам конфигурации. Платформа
