Сервер для 10 пользователей и 100+ ИБ
Добрый день, уважаемые коллеги. Вопрос нетривиальный.
Имеется организация, которая оказывает услуги по бухучету Предпринимателям и маленьким организациям (бухучет на аутсорсинге).
Живут сейчас на сервере с виртуализацией (esxi):
- Intel Xeon E3-1220v6 (3.00Ghz/8Mb)
- 16Гб оперативной памяти 2666MHz DDR4
- 2Тб в RAID 10 (довольно быстрый массив на контроллере Adaptec RAID 8405E V2).
Используется 1С:Предприятие 8.3 (8.3.14.1779), сервер х32бит (программная лицензия).
СУБД MS SQL Server 2014.
Постоянных пользователей - 11. В пике работает 7 пользователей, каждый максимум с 3 ИБ.
Размеры ИБ варьируются от 1Гб до 3Гб. Используется две конфигурации: БП 3.0 и ЗУП 3.1.
Чтобы было понятно, как работает организация:
- заключает договор на платные услуги по ведению учета (Бухучет, зарплата, кадры);
- берется ИБ от клиента, размещается на своих мощностях (ведется учет за него).
- чем больше клиентов, тем больше количество ИБ.
Описанного оборудования хватало, пока организация работала с 20-30 базами.
Проблемы начались когда число ИБ выросло за 50+. Сейчас вот такая картина (100ИБ)
Понятно, что жить на 16Гб совсем невозможно.
Основной затык в оперативной памяти. Ее не хватает, чтобы обслуживать такое количество ИБ.
Как рассчитываю память для этого сервера:
6 ИБ на 1 процесс = 2048 Мб (сервер 32-х битный, процесс не может потреблять больше 2Гб)
100 ИБ / 6 ИБ = 17 процессов rphost
17 * 2048 = 34816 Мб памяти.
16Гб установлено, докупаем 32Гб и получаем 32 + 16 = 48Гб.
По расчетам, этого должно хватить с запасом на год+.
Прошу вас, коллеги, поделиться опытом в подобных вопросах.
1) Правильно ли рассчитываю требуемый объем оперативной памяти? Может есть проверенные методики для "моего случая"?
2) У кого из вас есть опыт управления таким огромным числом ИБ?
Думаю, здесь требуются особенные подходы в администрировании, управлении ресурсами. На ИТС, в разделе Крупных внедрений, не говорится о случаях 100+ ИБ. Рассказывают о большом числе пользователей и больших базах. Что посоветуете, может есть рекомендации?
Имеется организация, которая оказывает услуги по бухучету Предпринимателям и маленьким организациям (бухучет на аутсорсинге).
Живут сейчас на сервере с виртуализацией (esxi):
- Intel Xeon E3-1220v6 (3.00Ghz/8Mb)
- 16Гб оперативной памяти 2666MHz DDR4
- 2Тб в RAID 10 (довольно быстрый массив на контроллере Adaptec RAID 8405E V2).
Используется 1С:Предприятие 8.3 (8.3.14.1779), сервер х32бит (программная лицензия).
СУБД MS SQL Server 2014.
Постоянных пользователей - 11. В пике работает 7 пользователей, каждый максимум с 3 ИБ.
Размеры ИБ варьируются от 1Гб до 3Гб. Используется две конфигурации: БП 3.0 и ЗУП 3.1.
Чтобы было понятно, как работает организация:
- заключает договор на платные услуги по ведению учета (Бухучет, зарплата, кадры);
- берется ИБ от клиента, размещается на своих мощностях (ведется учет за него).
- чем больше клиентов, тем больше количество ИБ.
Описанного оборудования хватало, пока организация работала с 20-30 базами.
Проблемы начались когда число ИБ выросло за 50+. Сейчас вот такая картина (100ИБ)
Понятно, что жить на 16Гб совсем невозможно.
Основной затык в оперативной памяти. Ее не хватает, чтобы обслуживать такое количество ИБ.
Как рассчитываю память для этого сервера:
6 ИБ на 1 процесс = 2048 Мб (сервер 32-х битный, процесс не может потреблять больше 2Гб)
100 ИБ / 6 ИБ = 17 процессов rphost
17 * 2048 = 34816 Мб памяти.
16Гб установлено, докупаем 32Гб и получаем 32 + 16 = 48Гб.
По расчетам, этого должно хватить с запасом на год+.
Прошу вас, коллеги, поделиться опытом в подобных вопросах.
1) Правильно ли рассчитываю требуемый объем оперативной памяти? Может есть проверенные методики для "моего случая"?
2) У кого из вас есть опыт управления таким огромным числом ИБ?
Думаю, здесь требуются особенные подходы в администрировании, управлении ресурсами. На ИТС, в разделе Крупных внедрений, не говорится о случаях 100+ ИБ. Рассказывают о большом числе пользователей и больших базах. Что посоветуете, может есть рекомендации?
По теме из базы знаний
- Кластер серверов 1С
- Таблицы серверов (как просто выбрать сервер)
- Распространенные ошибки разработчиков, приводящие к проблемам производительности
- Эффективное управление фоновыми заданиями и коммуникация сеансов сервера с Фоном с помощью Структуры обмена (ноу-хау) + Бонус: Альтернативный вариант через Хранилище настроек
- Запускаем 120 000 одновременных пользователей мобильного приложения на платформе 1С
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Вы забыли прикинуть память под процедурный кэш MSSQL. Его чем больше, тем лучше. Это единственное, что можно ответить по делу.
А вообще, в данном конкретном случае сервер 1С - это лишнее. Тем более, х32.
Сервер 1С и отдельная СУБД берутся главным образом для обеспечения параллельного доступа к конкурентным ресурсам.
Например, 10 кассиров шквально пробивают чеки. Они все обращаются к одним и тем же таблицам. Это требует управления.
Другое дело - ваш случай. Всё наоборот. Пользователи крайне редко пользуются одними и теми же таблицами одновременно. Здесь не требуется оптимальное управление блокировками.
Короче говоря, у вас сервер 1с - это лишняя прослойка, которая не даёт ничего. Ну разве что, более удобное обслуживание баз в MSSQL.
Ну и виртуализация. Зачем она здесь? Только бесполезное замедление.
А вообще, в данном конкретном случае сервер 1С - это лишнее. Тем более, х32.
Сервер 1С и отдельная СУБД берутся главным образом для обеспечения параллельного доступа к конкурентным ресурсам.
Например, 10 кассиров шквально пробивают чеки. Они все обращаются к одним и тем же таблицам. Это требует управления.
Другое дело - ваш случай. Всё наоборот. Пользователи крайне редко пользуются одними и теми же таблицами одновременно. Здесь не требуется оптимальное управление блокировками.
Короче говоря, у вас сервер 1с - это лишняя прослойка, которая не даёт ничего. Ну разве что, более удобное обслуживание баз в MSSQL.
Ну и виртуализация. Зачем она здесь? Только бесполезное замедление.
(2)
Посоветуйте методику расчета, которая в моем случае подойдет.
Признаюсь, что экономим на всем, т.к. бизнес не слишком прибыльный. Хватает на самое необходимое.
Пробовали работать без сервера 1С, использовали только файловый вариант. Вариант не устроил по быстродействию, нагрузке на сеть.
Вы не представляете сколько времени экономит сервер 1С. Конфигурации все современные, используется ТонкийКлиент. После развертывания сервера 1С, скорость работы с базами существенно улучшилось. Появилась единая точка администрирования.
Нормальные средства для резервного копирования (SQL), которые можно выполнять даже в течении рабочего дня (возникают ситуации, когда нужно откатить состояние на определенный момент дня).
Соглашусь, что нет шквальной записи. Но работать и управлять 100 ИБ без сервера - это не просто и не надежно.
В случае замены "железа", переехать на новый сервер не составит никаких проблем. В моем случае, замедление, которое дает esxi, равно статистической погрешности измерения. Виртуальный сервер проходит "Нагрузочный тест TPC-1C" на 23 балла (между удовлетворительно и хорошо). Для маленькой фирмы - вполне приемлемый результат. Понимаю, что можно поднять результат выше. На него еще предстоит заработать. :-)
А виртуализация - хорошее и удобное средство для администрирования и управления системами. Добавим массив с дисками - легко его применить на сервере. Никакой привязки к "железу".
Напишите рекомендации по расчету памяти под SQL, пожалуйста. Может есть ссылки, которые попробовали?
* кроме статей на ИТС. Изучил подробно и выполнил все рекомендации.
Вы забыли прикинуть память под процедурный кэш MSSQL
Посоветуйте методику расчета, которая в моем случае подойдет.
Признаюсь, что экономим на всем, т.к. бизнес не слишком прибыльный. Хватает на самое необходимое.
в данном конкретном случае сервер 1С - это лишнее
.
Пробовали работать без сервера 1С, использовали только файловый вариант. Вариант не устроил по быстродействию, нагрузке на сеть.
Вы не представляете сколько времени экономит сервер 1С. Конфигурации все современные, используется ТонкийКлиент. После развертывания сервера 1С, скорость работы с базами существенно улучшилось. Появилась единая точка администрирования.
Нормальные средства для резервного копирования (SQL), которые можно выполнять даже в течении рабочего дня (возникают ситуации, когда нужно откатить состояние на определенный момент дня).
Здесь не требуется оптимальное управление блокировками
Соглашусь, что нет шквальной записи. Но работать и управлять 100 ИБ без сервера - это не просто и не надежно.
Ну и виртуализация. Зачем она здесь?
Для удобного администрирования и управления сетью и сервером.
В случае замены "железа", переехать на новый сервер не составит никаких проблем. В моем случае, замедление, которое дает esxi, равно статистической погрешности измерения. Виртуальный сервер проходит "Нагрузочный тест TPC-1C" на 23 балла (между удовлетворительно и хорошо). Для маленькой фирмы - вполне приемлемый результат. Понимаю, что можно поднять результат выше. На него еще предстоит заработать. :-)
А виртуализация - хорошее и удобное средство для администрирования и управления системами. Добавим массив с дисками - легко его применить на сервере. Никакой привязки к "железу".
Напишите рекомендации по расчету памяти под SQL, пожалуйста. Может есть ссылки, которые попробовали?
* кроме статей на ИТС. Изучил подробно и выполнил все рекомендации.
(7)
Есть внутренние задачи, которые существенно упрощаются с сервером 1С:Предприятия. Сбор различной статистики, разбор ЖР и т.п.
Кроме того, работа в трехзвенной архитектуре улучшает безопасность (это важно для этого предприятия).
Чем именно вы собираетесь управлять? Копированием?
Есть внутренние задачи, которые существенно упрощаются с сервером 1С:Предприятия. Сбор различной статистики, разбор ЖР и т.п.
Кроме того, работа в трехзвенной архитектуре улучшает безопасность (это важно для этого предприятия).
(10)
Как разбор ЖР упрощается трёхзвенкой если ЖР хранится либо в отдельной базе SQLite либо в текстовых файлах?
Статистику можно и из файловой собирать. А какая нужна статистика при 10 пользователях?
Тут да... по сравнению с файловой по надёжней будет.
Потому что 100+ баз это не "крупные внедрения", "Крупные" это когда от 500 пользователей одновременно в одной базе.
А так единственная проблема тут только с обновлением всех этих баз. У меня знакомый работает в какой то компании, у него там штук 200 или 300 баз. Обновляет скриптами, админит всё это дело скриптами. Вот единственная проблема это писать скрипты администрирования всего этого обновления, добавление/отключение пользователей и тд.
разбор ЖР
Как разбор ЖР упрощается трёхзвенкой если ЖР хранится либо в отдельной базе SQLite либо в текстовых файлах?
Сбор различной статистики
Статистику можно и из файловой собирать. А какая нужна статистика при 10 пользователях?
Кроме того, работа в трехзвенной архитектуре улучшает безопасность (это важно для этого предприятия).
Тут да... по сравнению с файловой по надёжней будет.
На ИТС, в разделе Крупных внедрений, не говорится о случаях 100+ ИБ.
Потому что 100+ баз это не "крупные внедрения", "Крупные" это когда от 500 пользователей одновременно в одной базе.
А так единственная проблема тут только с обновлением всех этих баз. У меня знакомый работает в какой то компании, у него там штук 200 или 300 баз. Обновляет скриптами, админит всё это дело скриптами. Вот единственная проблема это писать скрипты администрирования всего этого обновления, добавление/отключение пользователей и тд.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот