Что такое масштабируемость по функционалу 1с
Это статья написана как ответ на дискуссию на открытом форуме по вопросу дальнейшего развития программы 1С. Оппоненты попросили обосновать свою точку зрения и мне ничего не оставалось делать как написать эту небольшую заметку. Все изложенные в ней материалы являются частным взглядом технического специалиста и не претендуют на полноту и правильность. Также они могут не совпадать со взглядами Б. Нуралиева или мнением технических специалистов занимающихся 1С.
1С завоевала основную долю рынка за счет 1С 6.0 . В ней был ряд отличных идей:
В июле 2003 года был анонсирован новый продукт 1С 8.0. Была задекларирована полноценная клиент-серверная архитектура (производительность и масштабируемость), эргономичный интерфейс и новая, более гибкая среда разработки.
Проследите динамику. Продукт присутствует на рынке уже 3 (Три!!) года. У фирмы огромная клиентская база, огромный пакет решений. И что?
Написан хотя бы элементарный конвертор, облегчающий перенос разработок с версии 7.7 на 8.0? Нет, но развитие 7.7 уже приостановлено ((
Повышена производительность системы?
Тогда зачем через 3 года опять проводить тесты демонстрирующие что производительность повышена? Самих себя успокаиваем: 1С:УПП: проверка на масштабируемость пройдена
Увеличена масштабируемость?
Даааа, в пресс-релизах регулярно проходит информация о 400 рабочих местах. Только если даже просто дочитать пресс- релиз до конца - удивительные вещи открываются: Единая платформа, на которой базируются созданные для «Иркутскэнерго» системы, еще не означает наличия единого информационного пространства — его только предстоит создать.
Эргономичный интерфейс?
Да, по сравнению с монстрообразной 7.7 интерфейс основного меню значительно упрощен, но если копнуть глубже.. То выясняется что монстроузность просто переехала в другие места. Если раньше нагромождение панелей гнездилось в главном окне, то теперь оно скромненько поселилось в каждой форме. Каждая форма отличается интерфейсом. Юзабилити на нуле. В программе сложно разобраться и работать!
Интерфейс громоздкий, потому что функционал возрос??
Ха. Например, в карточке принятия ОС я насчитал более 40 полей ввода на 4 закладках! Это же опухнуть можно, притом что основного - НЕТ. Я хочу при заведении нового основного средства определить возможный срок полезного использования по классификатору ОКОФ в привязке к возможным нормам амортизации по классификатору ЕНАО. А справочники – пустые! Зачем мне программа учета, которая не помогает автоматизировать учет? Записная книжка?
Среда разработки..
Это отдельная песня.. Начнем с того что я пока просто не видел ни одной более неудобной среды. Для просмотра результатов надо запустить приложение. Более громоздкий цикл разработки сложно даже придумать. Притом что я не говорю о таких профессиональных инструментах как Дельфи или Эклипс. Нет. Я сравниваю с средами разработки бизнес-приложений: Axapta, Navision, Инфо-предприятие. Это надо просто сравнить..
Может быть есть какие-то технологические отличия от конкурентов которые не видны на поверхности?? Давайте посмотрим что у неё внутри..
Основные отличия решений на платформе 1С 8.0:
- Файл-сервер. Программа не использует преимущества клиент-серверной архитектуры. Ни ссылочная целостность, ни триггеры, ни хранимые процедуры – не используются. Программа построена на файл-серверной архитектуре с СУБД в качестве хранилища данных. Единственное используемое преимущество клиент- серверной архитектуры – надежность.
- Низкое быстродействие решений на базе 1С.
- Архитектура данных. Непродуманные связи между сущностями приводят к длинным транзакциям и блокировкам записей.
- Методологические ошибки. Например, совмещенные процессы расчета себестоимости и формирования бухгалтерских проводок.
- Отчужденность от конкретной СУБД. 1С не привязан к возможностям какой-либо СУБД. Ни к MS SQL сейчас ни к Postgree в будущем. Зачем использовать Postgree если не использовать возможности версионности данной СУБД?? С тем же успехом можно хранить данные в бинарных файлах (что по сути и происходит).
- Ресурсоемкость. Высокие аппаратные требования.
Успешные продукты, такие например как Аксапта или Навижн смогли выйти на международный рынок только за счет непрерывной конкуренции между собой в рамках одной страны. 1С потеряет значительную долю рынка, потому что она потеряла темп, утратив конкурентов. Она стала монстром не успев им стать.
Сейчас неизбежна ситуация когда конкуренты начнут давить 1С причем сразу со всех сторон. Со стороны малого бизнеса будут идти более простые и удобные решения такие, как:
Ну, до них не доросла пока 1С ни по функционалу, ни по причинам изложенным выше.
Это только относительно новые продукты, разрабатываемые сейчас и только выходящие на рынок в России. А ведь есть ещё западные производители, такие как sage, myob и ряд других. Да и старые, отечественные могут проснуться.
Рынок разработки бизнес-приложений один из самых динамичных. Много ли среди Вас например тех, кто знает фирму hackers design?
Это только кажется что такое сложное приложение как 1С может разработать только крупная корпорация и на это нужны долгие годы. Все известные мне программы были написаны одним - двумя одиночками-хакерами за менее чем 1-2 года. Наоборот - большие компании не могут разработать успешных продуктов в силу своей инерции. Они скупают маленькие компании или одиночек, когда те совершают очередной прорыв.
Масштабируемость — это способность системы адаптироваться к расширению предъявляемых требований и возрастанию объемов решаемых задач.
Работа одного прикладного решения в разных условиях
Система «1С:Предприятие 8» имеет хорошие возможности масштабирования. Она позволяет работать как в файловом варианте, так и с использованием технологии «клиент-сервер».
При работе в файловом варианте платформа может работать с локальной информационной базой, расположенной на том же компьютере, на котором работает пользователь. Такой вариант работы может использоваться в домашних условиях или при работе на ноутбуке.
Файловый вариант также обеспечивает возможность работы по локальной сети нескольких пользователей с одной информационной базой. Такой способ работы может использоваться в небольших рабочих группах, он прост в установке и эксплуатации.
Для больших рабочих групп и в масштабах предприятия может применяться клиент-серверный вариант работы, основанный на трехуровневой архитектуре с использованием кластера серверов «1С:Предприятия 8» и отдельной системы управления базами данных. Он обеспечивает надежное хранение данных и их эффективную обработку при одновременной работе большого количества пользователей.
Крупные холдинговые компании могут использовать работу в распределенной информационной базе, сочетающуюся с применением как файлового, так и клиент-серверного вариантов работы. Распределенная информационная база позволяет объединить удаленные друг от друга подразделения холдинга, а каждое из этих подразделений может использовать, в свою очередь, файловый или клиент-серверный варианты работы. Механизм распределенной информационной базы будет обеспечивать идентичность конфигураций, используемых в каждом из подразделений холдинга, и осуществлять обмен данными между отдельными информационными базами, входящими с состав распределенной системы.
Важно отметить, что одни и те же прикладные решения (конфигурации) могут использоваться как в файловом, так и в клиент-серверном варианте работы. При переходе от файлового варианта к технологии «клиент-сервер» не требуется вносить изменения в прикладное решение. Поэтому выбор варианта работы целиком зависит от потребностей заказчика и его финансовых возможностей. На начальной стадии можно работать в файловом варианте, а затем с увеличением количества пользователей и объема базы данных можно легко перейти на клиент-серверный вариант работы со своей информационной базы.
Многопользовательская работа
Одним из основных показателей масштабируемости системы является возможность эффективной работы при увеличении количества решаемых задач, объема обрабатываемых данных и количества интенсивно работающих пользователей.
В варианте клиент-сервер обеспечивается возможность параллельной работы большого количества пользователей. Как показывают тесты, с ростом числа пользователей скорость ввода документов уменьшается очень медленно. Это означает, что при увеличении количества интенсивно работающих пользователей скорость реакции автоматизированной системы остается на приемлемом уровне.
В модели данных, поддерживаемой системой «1С:Предприятие 8», не существует таблиц базы данных, однозначно приводящих к конкурентному доступу со стороны нескольких пользователей. Конкурентный доступ возникает только при обращении к логически связанным данным и не затрагивает данные, не связанные между собой с точки зрения предметной области.
При выполнении регламентных операций исключены ситуации, когда для начала работы в некотором отчетном периоде требуется установка монопольного режима. Регламентные операции могут выполняться в удобные для пользователей и организации моменты времени. Монопольный режим устанавливается не при запуске системы, а в тот момент, когда необходимо выполнение операции, требующей его включения. После выполнения таких операций монопольный режим может быть отключен.
Механизмы оптимизации
Технологическая платформа «1С:Предприятия 8» содержит ряд механизмов, оптимизирующих скорость работы прикладных решений.
Управление блокировками в транзакции
Режим управляемых блокировок в транзакции позволяет управлять блокировками данных в терминах предметной области и повышает параллельность работы пользователей. Подробнее…
Выполнение на сервере
В варианте клиент-сервер использование сервера «1С:Предприятия 8» позволяет сосредоточить на нем выполнение наиболее объемных операций по обработке данных. Например, при выполнении даже весьма сложных запросов программа, работающая у пользователя, будет получать только необходимую ей выборку, а вся промежуточная обработка будет выполняться на сервере. Обычно увеличить мощность сервера гораздо проще, чем обновить весь парк клиентских машин.
Кэширование данных
Система «1С:Предприятие 8» использует механизм кэширования данных, считанных из базы данных при использовании объектной техники. При обращении к реквизиту объекта выполняется чтение всех данных объекта в кэш, расположенный в оперативной памяти. Последующие обращения к реквизитам того же объекта будут направляться уже в кэш, а не в базу данных, что значительно сокращает время, затрачиваемое на получение нужных данных.
Работа встроенного языка на сервере
При работе в клиент-серверном варианте вся работа прикладных объектов выполняется только на сервере. Функциональность форм и командного интерфейса также реализована на сервере.
На сервере выполняется подготовка данных формы, расположение элементов, запись данных формы после изменения. На клиенте отображается уже подготовленная на сервере форма, выполняется ввод данных и вызовы сервера для записи введенных данных и других необходимых действий.
Аналогично командный интерфейс формируется на сервере и отображается на клиенте. Также и отчеты формируются полностью на сервере и отображаются на клиенте.
Примеры технологических параметров внедрений решения «Управление производственным предприятием»
В этом разделе публикуется развернутая информация о технологических параметрах внедрений «1C:Предприятие 8. Управление производственным предприятием» на предприятиях различного масштаба и профиля деятельности.
Цель раздела — ознакомить ИТ- специалистов с данными о реально используемом оборудовании и с примерами нагрузки реальных внедрений «1С:Предприятия 8».
Также эта информация может быть полезна и для пользователей всех программ системы «1С:Предприятие 8».
1С:Центр управления производительностью — инструмент мониторинга и анализа производительности
1С:Центр управления производительностью (1С:ЦУП) — инструмент мониторинга и анализа производительности информационных систем на платформе «1С:Предприятие 8». 1С:ЦУП предназначен для оценки производительности системы, сбора подробной технической информации об имеющихся проблемах производительности и анализа этой информации с целью дальнейшей оптимизации. Подробнее…
1С:ТестЦентр — инструмент автоматизации нагрузочных испытаний
1С:ТестЦентр — инструмент автоматизации многопользовательских нагрузочных испытаний информационных систем на платформе «1С:Предприятие 8». С его помощью можно моделировать работу предприятия без участия реальных пользователей, что позволяет оценивать применимость, производительность и масштабируемость информационной системы в реальных условиях. Подробнее…
Внедрение корпоративных информационных систем на платформе «1С:Предприятие 8»
Опыт внедрения прикладных решений на платформе «1С:Предприятие 8» показывает, что система позволяет решать задачи различной степени сложности — от автоматизации одного рабочего места до создания информационных систем масштаба предприятия.
В то же время, внедрение большой информационной системы предъявляет повышенные требования по сравнению с небольшим или средним внедрением. Информационная система масштаба предприятия должна обеспечивать приемлемую производительность в условиях одновременной и интенсивной работы большого количества пользователей, которые используют одни и те же информационные и аппаратные ресурсы в конкурентном режиме. Подробнее…
База знаний по технологическим вопросам крупных внедрений
Фирма «1С», совместно с сертифицированными «1С:Экспертами по технологическим вопросам» и другими техническими специалистами, ведет и регулярно обновляет базу знаний по технологическим вопросам крупных внедрений.
База знаний — это постоянно пополняемый информационный ресурс, который является основным источником информации по технологическим вопросам крупных внедрений:
Платформа «1С: Предприятие 8» отличается способностью расширяться, подстраиваясь под рост бизнеса пользователя, новые требования и новые задачи. Одно и то же прикладное решение от «1С» легко масштабируется, предоставляя возможность работать как в варианте файловом, так и в режиме «клиент-сервер».
Файловый вариант или «клиент-сервер»?
Если необходимо персональное решение, то предпочтительнее файловый вариант работы, когда локальная ИБ расположена на рабочей машине пользователя. Удобно для работы в домашних и «полевых» условиях (достаточно установить ИБ на ноутбук). При расширении объемов задач для небольшой рабочей группы файловый вариант также оптимален, поскольку несколько пользователей могут работать с одной ИБ, при этом не возникает сложностей с инсталляцией и эксплуатацией.
Для решения масштабных задач в рамках крупных предприятий и разветвленных рабочих групп предпочтительнее вариант «клиент-сервер» на основе трех уровней, с использованием сервера «1С:Предприятие 8» и системы управления БД, что гарантирует:
- более стабильную работу;
- сохранность данных;
- эффективную обработку в т.ч. при работе одновременно множества пользователей.
Сочетание файлового режима и варианта «клиент-сервер» – это решение для крупных корпораций и холдингов. Распределенная ИБ объединяет обособленных подразделения, гарантирует безопасную передачу информации и эффективный обмен данными и информацией, при этом сохраняется возможность использовать как файловую схему, так и режим «клиент-сервер».
Система «1С: Предприятие 8» выгодно отличается тем, что смена варианта работы – с файловой системы на схему «клиент-сервер» и наоборот, - не требует внесения изменений в конфигурацию. На первоначальном этапе можно предпочесть файловый вариант, по мере роста сети пользователей и БД можно легко перейти на схему «клиент-сервер».
Поддержка многопользовательской работы
Платформа «1С: Предприятие 8» поддерживает эффективную многопользовательскую работу, сохраняя функционал и скорость работы независимо от увеличения числа решаемых задач, объема данных и количества пользователей. Для многопользовательской работы предпочтительнее схема «клиент-сервер». Тесты показали, что скорость ввода документов при увеличении числа пользователей практически не сокращается, даже при интенсивной работе пользователей скорость ответа системы остается на высоком уровне, тем более что модель данных системы не подразумевает использования таблиц БД, приводящих к конкуренции при доступе нескольких пользователей. (Конкуренция возникает лишь при обращении пользователей к данным, имеющим логические связи, но не предмет).
Регламентные операции не требуют для начала работы в отчетном периоде монопольного режима, они могут выполняться в удобные для пользователя моменты времени. Монопольный режим стартует не вместе с системой, а лишь тогда, когда это требуется исходя из характера операции. По окончании такой операции монопольный режим отключается.
Оптимизация быстродействия
Система «1С:Предприятие 8» содержит следующие механизмы для оптимизации быстродействия:
- режим управления блокировками в транзакции упрощает блокировку данных в предметной области, повышая производительность одновременной работы;
- выполнение операций на сервере. При режиме «клиент-сервер» сервер «1С» берет на себя самые объемные операции по обработке данных, а пользователь получает лишь необходимую ему выборку. Сменить сервер на более мощный проще, нежели обновить парк ПК;
- кэширование данных, считываемых из БД, также позволяет увеличить скорость работы, ведь данные загружаются в кэш оперативной памяти, и последующие обращения обрабатываются именно оперативной памятью, а не базой данных, что позволяет получать необходимые сведения гораздо быстрее;
- встроенный язык на сервере при работе «клиент-сервер» позволяет пользователю получить уже готовую форму, сгенерированную на сервере, ему надо лишь ввести данные и вызвать сервер для их записи.
На официальном сайте «1С» можно ознакомиться с:
- примерами технологических параметров внедрений решения «Управление производственным предприятием»;
- рекомендациями по выбору оборудования
а также имеется инструменты для исследования производительности «1С:Центр управления производительностью» и автоматизации нагрузочных испытаний «1С:ТестЦентр».
Решение для крупномасштабной автоматизации
Решения на основе «1С:Предприятие 8» могут быть внедрены как на уровне одного рабочего места, так и на общефедеральном уровне. Для технических специалистов, перед которыми стоят задачи крупного внедрения, на сайте «1С» создана регулярно обновляемая база знаний по технологическим вопросам крупных внедрений, содержащая методики и технологии, применение которых помогает повышать качество крупного внедрения, а также способы решения технологических проблем, их сопровождающих.
Кластер — это разновидность параллельной
или распределённой системы, которая:
1. состоит из нескольких связанных
между собой компьютеров;
2. используется как единый,
унифицированный компьютерный ресурс
Дано: есть бизнес-приложение (например, ERP-система), с которым работают одновременно тысячи (возможно, десятки тысяч) пользователей.
- Сделать приложение масштабируемым, чтобы при увеличении количества пользователей можно было за счёт наращивания аппаратных ресурсов обеспечить необходимую производительность приложения.
- Сделать приложение устойчивым к выходу из строя компонентов системы (как программных, так и аппаратных), потере связи между компонентами и другим возможным проблемам.
- Максимально эффективно задействовать системные ресурсы и обеспечить нужную производительность приложения.
- Сделать систему простой в развертывании и администрировании.
К желаемому результату мы пришли не сразу.
В этой статье расскажем о том, какие бывают кластеры, как мы выбирали подходящий нам вид кластера и о том, как эволюционировал наш кластер от версии к версии, и какие подходы позволили нам в итоге создать систему, обслуживающую десятки тысяч одновременных пользователей.
Как писал автор эпиграфа к этой статье Грегори Пфистер в своей книге «In search of clusters», кластер был придуман не каким-либо конкретным производителем железа или софта, а клиентами, которым не хватало для работы мощностей одного компьютера или требовалось резервирование. Случилось это, по мнению Пфистера, ещё в 60-х годах прошлого века.
Традиционно различают следующие основные виды кластеров:
- Отказоустойчивые кластеры (High-availability clusters, HA, кластеры высокой доступности)
- Кластеры с балансировкой нагрузки (Load balancing clusters, LBC)
- Вычислительные кластеры (High performance computing clusters, HPC)
- Системы распределенных вычислений (grid) иногда относят к отдельному типу кластеров, который может состоять из территориально разнесенных серверов с отличающимися операционными системами и аппаратной конфигурацией. В случае grid-вычислений взаимодействия между узлами происходят значительно реже, чем в вычислительных кластерах. В grid-системах могут быть объединены HPC-кластеры, обычные рабочие станции и другие устройства.
Для тех, кто не в курсе, коротко расскажу, как устроены бизнес-приложения 1С. Это приложения, написанные на предметно-ориентированном языке, «заточенном» под автоматизацию учётных бизнес-задач. Для выполнения приложений, написанных на этом языке, на компьютере должен быть установлен рантайм платформы 1С:Предприятия.
1С:Предприятие 8.0
Первая версия сервера приложений 1С (еще не кластер) появилась в версии платформы 8.0. До этого 1С работала в клиент-серверном варианте, данные хранились в файловой СУБД или MS SQL, а бизнес-логика работала исключительно на клиенте. В версии же 8.0 был сделан переход на трехзвенную архитектуру «клиент – сервер приложений – СУБД».
Сервер 1С в платформе 8.0 представлял собой СОМ+ сервер, умеющий исполнять прикладной код на языке 1С. Использование СОМ+ обеспечивало нам готовый транспорт, позволяющий клиентским приложениям общаться с сервером по сети. Очень многое в архитектуре и клиент-серверного взаимодействия, и прикладных объектов, доступных разработчику 1С, проектировалось с учетом использования СОМ+. В то время в архитектуру не было заложено отказоустойчивости, и падение сервера вызывало отключение всех клиентов. При падении серверного приложения СОМ+ поднимал его при обращении к нему первого клиента, и клиенты начинали свою работу с начала – с коннекта к серверу. В то время всех клиентов обслуживал один процесс.
1С:Предприятие 8.1
В следующей версии мы захотели:
- Обеспечить нашим клиентам отказоустойчивость, чтобы аварии и ошибки у одних пользователей не приводили авариям и ошибкам у других пользователей.
- Избавиться от технологии СОМ+. СОМ+ работала только на Windows, а в то время уже начала становиться актуальной возможность работы под Linux.
Так в версии 8.1 появился первый кластер. Мы реализовали свой протокол удаленного вызова процедур (поверх ТСР), который по внешнему виду выглядел для конечного потребителя-клиента практически как СОМ+ (т.е. нам практически не пришлось переписывать код, отвечающий за клиент-серверные вызовы). При этом сервер, реализованный нами на С++, мы сделали платформенно-независимым, способным работать и на Windows, и на Linux.
На смену монолитному серверу версии 8.0 пришло 3 вида процессов – рабочий процесс, обслуживающий клиентов, и 2 служебных процесса, поддерживающих работу кластера:
- rphost – рабочий процесс, обслуживающий клиентов и исполняющий прикладной код. В составе кластера может быть больше одного рабочего процесса, разные рабочие процессы могут исполняться на разных физических серверах – за счёт этого достигается масштабируемость.
- ragent – процесс агента сервера, запускающий все другие виды процессов, а также ведущий список кластеров, расположенных на данном сервере.
- rmngr – менеджер кластера, управляющий функционированием всего кластера (но при этом на нем не работает прикладной код).
Клиент на протяжении сессии работал с одним рабочим процессом, падение рабочего процесса означало для всех клиентов, которых этот процесс обслуживал, аварийное завершение сессии. Остальные клиенты продолжали работу.
1С:Предприятие 8.2
В версии 8.2 мы захотели, чтобы приложения 1С могли запускаться не только в нативном (исполняемом) клиенте, а ещё и в браузере (без модификации кода приложения). В связи с этим, в частности, встала задача отвязать текущее состояние приложения от текущего соединения с рабочим процессом rphost, сделать его stateless. Как следствие возникло понятие сеанса и сеансовых данных, которые нужно было хранить вне рабочего процесса (потому что stateless). Был разработан сервис сеансовых данных, хранящий и кэширующий сеансовую информацию. Появились и другие сервисы — сервис управляемых транзакционных блокировок, сервис полнотекстового поиска и т.д.
В этой версии также появились несколько важных нововведений – улучшенная отказоустойчивость, балансировка нагрузки и механизм резервирования кластеров.
Отказоустойчивость
Поскольку процесс работы стал stateless и все необходимые для работы данные хранились вне текущего соединения «клиент – рабочий процесс», в случае падения рабочего процесса клиент при следующем обращении к серверу переключался на другой, «живой» рабочий процесс. В большинстве случаев такое переключение происходило незаметно для клиента.
Балансировка нагрузки
Это стандартная задача для кластера с балансировкой нагрузки. Есть несколько типовых алгоритмов её решения, например:
-
– серверам присваиваются порядковые номера, первый запрос отправляется на первый сервер, второй запрос – на второй и т. д. до достижения последнего сервера. Следующий запрос направляется на первый сервер и всё начинается с начала. Алгоритм прост в реализации, не требует связи между серверами и неплохо подходит для «легковесных» запросов. Но при балансировке по этому алгоритму не учитывается производительность серверов (которая может быть разной) и текущая загруженность серверов. – усовершенствованный Round-Robin: каждому серверу присваивается весовой коэффициент в соответствии с его производительностью, и сервера с бо́льшим весом обрабатывают больше запросов.
- Least Connections: новый запрос передается на сервер, обрабатывающий в данный момент наименьшее количество запросов.
- Least Response Time: сервер выбирается на основе времени его ответа: новый запрос отдаётся серверу, ответившему быстрее других серверов.
Запрос от нового клиента адресуется на наиболее производительный на данный момент сервер.
Запрос от существующего клиента в большинстве случаев адресуется на тот сервер и в тот рабочий процесс, в который адресовался его предыдущий запрос. С работающим клиентом связан обширный набор данных на сервере, передавать его между процессами (а тем более между серверами) – довольно накладно (хотя мы умеем делать и это).
Запрос от существующего клиента передается в другой рабочий процесс в двух случаях:
- Процесса больше нет: рабочий процесс, с которым ранее взаимодействовал клиент, более недоступен (упал процесс, стал недоступен сервер и т.п.).
- Есть более производительный сервер: если в кластере есть сервер, отличающийся по производительности в два и более раза по сравнению с сервером, где запушен текущий рабочий процесс, то платформа считает, что даже ценой миграции клиентского контекста нам выгоднее выполнять запросы на более производительном сервере. Переноситься клиенты с одного сервера на другой будут постепенно, по одному, с периодической оценкой результата – что в плане производительности стало с серверами после переноса каждого из клиентских процессов. Цель этой процедуры – выравнивание производительности серверов в кластере (т.е. равномерная загрузка серверов).
Резервирование кластеров
Мы решили повысить отказоустойчивость кластера, прибегнув к схеме Active / passive. Появилась возможность конфигурировать два кластера – рабочий и резервный. В случае недоступности основного кластера (сетевые неполадки или, например, плановое техобслуживание) клиентские вызовы перенаправлялись на резервный кластер.
Однако эта конструкция была довольно сложна в настройке. Администратору приходилось вручную собирать две группы серверов в кластеры и конфигурировать их. Иногда администраторы допускали ошибки, устанавливая противоречащие друг другу настройки, т.к. не было централизованного механизма проверки настроек. Но, тем не менее, этот подход повышал отказоустойчивость системы.
1С:Предприятие 8.3
В версии 8.3 мы существенно переписали код серверной части, отвечающий за отказоустойчивость. Мы решили отказаться от схемы Active / passive кластеров ввиду сложности её конфигурирования. В системе остался только один отказоустойчивый кластер, состоящий из любого количества серверов – это ближе к схеме на Active / active, в которой запросы на отказавший узел распределяются между оставшимися рабочими узлами. За счет этого кластер стал проще в настройке. Ряд операций, повышающих отказоустойчивость и улучшающих балансировку нагрузки, стали автоматизированными. Из важных нововведений:
- Новая настройка кластера «Уровень отказоустойчивости»: число, указывающее, сколько серверов может выйти из строя без последствий в виде аварийного завершения сеансов подключенных пользователей. Исходя из этой настройки кластер будет тратить определённый объём ресурсов на синхронизацию данных между рабочими серверами, чтобы иметь всю необходимую для продолжения работы клиентов информацию на «живых» серверах в случае выхода из строя одного или нескольких серверов.
- Количество рабочих процессов не задается вручную, как раньше, а автоматически рассчитывается исходя из описаний требований задач по отказоустойчивости и надежности.
- Появился ряд настроек, связанных с максимальными объемами памяти, которые разрешается потреблять рабочим процессам, а также настройки, определяющие что делать, если эти объемы превышены:
Главная идея этих наработок – упростить работу администратора, позволяя ему настраивать кластер в привычных ему терминах, на уровне оперирования серверами, не опускаясь ниже, а также минимизировать уровень «ручного управления» работой кластера, дав кластеру механизмы для решения большинства рабочих задач и возможных проблем «на автопилоте».
Три звена отказоустойчивости
Как известно, даже если компоненты системы по отдельности надёжны, проблемы могут возникнуть там, где компоненты системы вызывают друг друга. Мы хотели свести количество мест, критичных для работоспособности системы, к минимуму. Важным дополнительным соображением была минимизация переделок прикладных механизмов в платформе и исключение изменений в прикладных решениях. В версии 8.3 появилось 3 звена обеспечения отказоустойчивости «на стыках»:
В заключение
Благодаря механизму отказоустойчивости приложения, созданные на платформе 1С:Предприятие, благополучно переживают разные виды отказов рабочих серверов в кластере, при этом бо́льшая часть клиентов продолжают работать без перезапуска.
Бывают ситуации, когда мы не можем повторить вызов, или падение сервера застает платформу в очень неудачный момент времени, например, в середине транзакции и не очень понятно, что с ними делать. Мы стараемся обеспечить статистически хорошую выживаемость клиентов при падении серверов в кластере. Как правило, средние потери клиентов за отказ сервера – единицы процентов. При этом все «потерянные» клиенты могут продолжить работу в кластере после перезапуска клиентского приложения.
Надежность кластера серверов 1С в версии 8.3 существенно повысилась. Уже давно не редкость внедрения продуктов 1С, где количество одновременно работающих пользователей достигает нескольких тысяч. Есть и внедрения, где одновременно работают и 5 000, и 10 000 пользователей — например, внедрение в «Билайне», где приложение «1С: Управление Торговлей» обслуживает все салоны продаж «Билайн» в России, или внедрение в грузоперевозчике «Деловые Линии», где приложение, самостоятельно созданное разработчиками ИТ-отдела «Деловых Линий» на платформе 1С:Предприятие, обслуживает полный цикл грузоперевозок. Наши внутренние нагрузочные тесты кластера эмулируют одновременную работу до 20 000 пользователей.
В заключение хочется кратко перечислить что ещё полезного есть в нашем кластере (список неполный):
Собственные наработки и набитые шишки в моей практике по программированию в 1С.
вторник, 8 декабря 2015 г.
Выдержки из ИТС по настройке кластера сервера 1С
В текущем разделе, посвещается основные выдержки по настройке кластера. Естественно они не являются полными, поскольку все это зависит от тонкости настройки каждой платформы. Но все-же хотчеться не искать в торопях, а где-же я это искал, или как я это когда-то делал?
Масштабируемость кластера серверов
Отказоустойчивый кластер
Уровень отказоустойчивости
Уровень отказоустойчивости определяет максимальное количество рабочих серверов, входящих в состав кластера, одновременный выход из строя которых не приведет к аварийному завершению сеансов подключенных пользователей. Надо понимать, что «выход из строя» подразумевает ситуации, подобные следующим: отключение питания компьютера, разрыв сетевого кабеля, проблемы с операционной системой, не позволяющие запустить процесс и т. д.
Таким образом, если в кластер серверов входит только один рабочий сервер, то максимальный уровень отказоустойчивости будет 0,т. к. выход из строя единственного рабочего сервера приведет к аварийному завершению всех подключенных пользователей. Если в кластер входит 4 рабочих сервера, то уровень отказоустойчивости может изменяться от 0 до 3. При этом 0 означает, что фатальным считается выход из строя любого рабочего сервера, а значение 3 означает, что кластер сохранит работоспособность даже в том случае, если выдут из строя 3 из 4 рабочих серверов.
Следует понимать, что увеличение уровня отказоустойчивости выполняется ценой некоторого падения производительности кластера, т. к. кластер будет тратить некоторые ресурсы на синхронизацию данных между рабочими серверами.
Уровень отказоустойчивости связан с количеством центральных серверов в кластере. Количество центральных серверов определяет возможность создания новых соединений. Если, например, в кластер входит два центральных сервера при общем количестве 3 рабочих сервера, то пользователи смогу подключаться к информационным базам в случае аварийного завершения одного центрального сервера. При этом остается два работающих рабочих сервера: один центральный и один рабочий. Если в кластере будет только один центральный сервер, то аварийное завершение этого сервера приведет к тому, что кластер станет недоступен пользователям, несмотря на то, что в нем сохранили работоспособность еще 2 рабочих сервера.
Если в кластере присутствует 3 рабочих сервера (из них один центральный) и установлен уровень отказоустойчивости равный 1, то могут наблюдаться различные ситуации. Рассмотрим их.
2.1.6. Масштабируемость кластера серверов
● Наращиванием вычислительных мощностей компьютера, на котором развернут единственный рабочий сервер кластера.
Все необходимые действия по обеспечению масштабируемости кластер серверов выполняет автоматически. Администратор кластер может влиять на действия кластера серверов с помощью изменения свойств рабочего сервера.
В список рабочих серверов кластера можно добавлять новые сервера и менять свойства существующих (см. здесь). Измененные значения свойств действуют только на новые соединения и сеансы. Удаление рабочего сервера следует проводить особым образом, чтобы не допустить аварийного отключения пользователей, которых обслуживает удаляемый сервер. Подробнее порядок удаления рабочего сервера см. здесь. Невозможно удаление последнего рабочего сервера в кластере с установленным признаком Центральный сервер . При создании кластера по умолчанию, рабочий сервер того компьютера, на котором создается кластер серверов, автоматически включается в список рабочих серверов и для этого рабочего сервера устанавливается флажок Центральный сервер .
Во время работы кластер серверов автоматически распределяет нагрузку между рабочими серверами таким образом, чтобы обеспечить минимальное время обслуживания клиентских приложений. Сервисы кластера (см. здесь) равномерно распределяются по рабочим серверам по типам сервисов, информационным базам и сеансам.
Во время установки соединения с информационной базой, кластер серверов выбирает рабочие сервера с максимальной доступной производительностью (на момент выбора рабочего сервера). Существующие соединения могут быть перемещены на другой рабочий сервер. Более подробное описание этого механизма см. здесь.
2.1.7. Балансировка нагрузки в кластере
2.1.7.1. Доступная производительность рабочего процесса
Каждый рабочий процесс имеет свойство Доступная производительность . Оно определяет, насколько быстро данный рабочий процесс способен выполнить эталонный вызов сервера по сравнению с другими рабочими процессами. Эталонный вызов включает в себя следующие операции:
● Выполняется определение степени загрузки процессоров компьютера, на котором работает рабочий процесс и количество потоков, ожидающих исполнения. Это значение корректирует время выполнения эталонного вызова в сторону увеличения. Если пользователь, от имени которого работает сервер, не входит в группу Пользователи журналов производительности ( Performance Log Users ), то определение степени загрузки процессора не выполняется.
Значение свойства Доступная производительность вычисляется делением числа 10 000 на среднее (за 5 минут) время выполнения эталонного вызова текущим рабочим процессом. Эталонный вызов выполняется каждые 2 секунды в том случае, если в кластере присутствует несколько рабочих серверов. Если кластер серверов состоит из одного рабочего сервера – все рабочие процессы считаются равноправными.
Клиенты распределяются между рабочими процессами так, чтобы сделать доступную производительность всех рабочих процессов примерно одинаковой. Существенным считается отличие доступной производительности более чем на 25%.
При изменении соотношения между доступной производительностью рабочих процессов клиенты динамически в течение не более 10 минут перераспределяются между рабочими процессами.
При выключении рабочего процесса его клиенты динамически перераспределяются между оставшимися включенными рабочими процессами.
2.1.7.3. Требования назначения функциональности
2.1.7.3.1. Общая информация
Кластер серверов предоставляет некоторый набор функциональных возможностей (называемые объекты требований ), распределением которых между рабочими серверами внутри кластера можно управлять. Например, можно указать, что все фоновые задания в кластере будут выполняться на выбранном рабочем сервере.
Для того чтобы поместить соединение или сервис кластера на какой-либо рабочий сервер, необходимо для выбранного рабочего сервера создать требование назначения функциональности. Это требование определяет возможность или невозможность конкретного сервера выполнять ту или иную работу. Рассмотрим более подробно, что собой представляет требование назначения функциональности.
● Для какого объекта требования создается требование. В качестве объекта требования могут выступать некоторые сервисы кластера (см. здесь), клиентские соединения (см.здесь) и произвольный объект требования. В качестве объекта требования могут выступать следующие сервисы кластера:
Читайте также: