PC Magazine/RE - Журнал PC Magazine/RE №12/2009

Практически это означает, что при грамотно спроектированной структуре кластера завершение любого из серверных процессов и даже отключение любого из физических компьютеров кластера не приведет к сбою в работе пользователей. Это особенно важно для тех информационных систем, которые работают в режиме «24×7» и остановка которых даже на короткое время может привести к серьезным финансовым потерям предприятия.

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

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

Следует отметить, что устойчивостью к обрыву связи в любом случае обладают тонкий и Web-клиент, а в случае толстого клиента «воскрешение» пользовательского сеанса зависит главным образом от того, какая именно операция выполнялась клиентским приложением в момент обрыва связи. Некоторые операции (например, работа с транзакциями), к сожалению, требуют непрерывной связи между клиентом и сервером и не могут быть временно прерваны.

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

В предыдущих версиях «1С: Предприятия 8» анализ загруженности рабочих процессов тоже выполнялся, но только в момент возникновения нового клиентского соединения – кластер принимал решение, какому из рабочих процессов передать это соединение для обслуживания. Но на практике разные пользователи создают непропорциональную нагрузку на кластер – например, одни просто листают список документов, а другие формируют «тяжелые» отчеты. И при неблагоприятном стечении обстоятельств (несколько «тяжелых» пользователей попали в один рабочий процесс) возникали проблемы производительности информационной системы. Конечный пользователь вовсе не обязан знать о существовании рабочих процессов и тонкостях распределения нагрузки между ними, но на ситуацию «вдруг все стало тормозить» он обязательно отреагирует, причем реакция будет строго негативной.

Механизм динамической балансировки нагрузки на рабочие процессы, появившийся в версии «1С: Предприятие 8.2», позволяет насколько это возможно равномерно распределять активность пользователей по рабочим процессам кластера и использовать аппаратные ресурсы наиболее эффективно.

В предыдущих версиях «1С: Предприятия 8» пользовательский интерфейс целиком и полностью создавался разработчиком прикладного решения. Платформа практически никогда не принимала самостоятельных решений о выводе того или иного элемента на какую-либо форму, а изменения в структуре метаданных конфигурации никоим образом не влияли на интерфейсную часть. Разработчик должен был в явной форме создать командный интерфейс (главное меню и панели инструментов) и в буквальном смысле «нарисовать» все необходимые формы. При этом разработчик получал полную свободу действий – можно было поместить любой элемент в любое место любой формы, придать любой размер, раскрасить в любые цвета и т. д. К сожалению, у полной свободы действий есть и своя оборотная сторона – при работе через Интернет или по медленным каналам связи передача информации о такой форме между клиентом и сервером стала бы очень затратным мероприятием. Более эффективный способ – передача не собственно формы, а правил ее формирования.