gilev.ru экспертиза 1С оптимизация производительности тех.поддержка обучение
 
   
 

Выбор серверного оборудования

для платформы 1С:Предприятие 8

 

Начало

 

Многие мои коллеги задаются постоянно одним и тем же вопросом - какой купить сервер для работы "1С"?
Очень рекомендую сначало посмотреть на этот пример выбора серверного оборудования для 250 пользователей 1С:Предприятие 8.1.

 

Подбор любого сервера (в том числе для сервера 1С версии 8.2) мной - 5000 руб.

 

  

Есть ли готовые примеры для конкретного количества пользователей

 

Ну конечно, ориентироваться только на количество пользователей недостаточно для "идеального" выбора, но очень часто этот критерий достаточно удачно применяется.

Поэтому я предлагаю Вам посмотреть другие конфигурации (тех кто уже купил) и написать туда же Вашу конфигурацию, чтобы коллеги смогли учесть Ваш опыт.

Конфигурация до 10 пользователей

Конфигурация до 25 пользователей

Конфигурация до 50 пользователей

Конфигурация до 100 пользователей

Конфигурация до 200 пользователей



SSD диски

Тесты производительности SSD.

Инструкция по изменению содержимого таблиц. Пишете с Вашей почтовой записи на gmail.com мне письмо со ссылкой на интересную Вам конфигурацию (сслыка в наименовании кофигурации с этой страницы, например "Конфигурация на 10 пользователей"). В заголовке письма пишите "Гилеву - Предоставить доступ для редактирования таблицы Гугля". Моя почта : gilev.ru собачка gmail.com .

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

Просьба писать только сервера, РЕАЛЬНО РАБОТАЮЩИЕ У ВАС!

 

  

Проблема выбора

 

Однажды я пошел покупать автомобиль. Не, не компьютер, именно автомобиль.

Проблемы начались еще за месяц до покупки, когда появились деньги. Главные мучившие меня вопросы - где и какую машину купить?

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

К чему это все расказываю? 

Сервер для 1С:Предприятие 8.1 (как и автомобиль) можно выбрать. Но не надо хвататься за все подряд!

Определите для себя приоритеты, по которым будете выбирать и действуйте!

Для себя выделил критерии, показанные на рисунке 1

 

Критерии выбора

Кстати, не так давно на одном из сайтов я провел миниопрос среди коллег.

Тема опроса: "кто как выбирает и аргументирует выбор сервера". Почти половина ответила -  руководство мне просто доверяет. Еще некоторая часть аудитории сказала, что делегирует ответственность выбора поставщику услуг или просто повторяет "как у соседа" (например, читая сайт фирмы 1С). Остальные ответы составили незначительную долю.

  

Расчет потребности в мощностях

 

Мне нужно понять, какими техническими характеристиками должен обладать сервер, чтобы прежде всего обеспечить работоспособность 1С:Предприятие 8.1 без возникновения проблем с нехваткой серверных ресурсов. Пользователи не должны ожидать, пока "проведется документ", из-за того, что например процессоры кластера сервером загруженны под 100%.

Расчет мощностей

Такой расчет может быть приблизительным или достаточно точным. На рисунке 2 показал некоторые подходы к решению этой задачи.

  

Приблизительный вариант

 

Приблизительный вариант обычно использую для новых задач. Тут можно опереться на опубликованный в интернете опыт коллег (не возьмусь утверждать, что это не рисковано, но если "посты определяются автора человеком здравомыслящим", то этот способ мне помогал не раз).
Другими словами, тут нужен опыт и знание обобщенных (примерных) зависимостей загруженности серверов. Чуть дальше раскажу некоторые такие мои наблюдения загруженности.

  

Точный вариант

 

Точный вариант расчета основан на выполнении нагрузочных тестов. Этот способ часто бывает достаточно дорогой. Если использовать бесплатные тесты из интернета, которые чаще всего не учтут моих конкретных особенностей. Платные тесты должны воспроизвести реальную рабочую нагрузку на сервера. Такими возможностями обладает например продукт 1С:ТестЦентр. Но учтите, что в тесте участвуют не только сервера для кластера 1С:Предприятие 8.1 и СУБД, но и оборудование для клиентских рабочих мест. Например, для 100 пользователей скажем это не всегда просто бывает сделать.
Тест не дешев, возникает желание не тратить деньги на тест, а на дополнительную мощность сервера.
Вы должны знать о выборе сервер нагрузочным тестированием обязательно. Причина проста - он дает Знание реальной нагрузки, воспроизведенной на предполагаем к использованию сервере. Остальные варианты выбора сервера основаны на прогнозируемом поведении, а не реальном. В моей практике сложилось так: когда масштабы проекта имеют такие показатели как 400 пользоватлей, объем базы данных в 500 Gb, то без нагрузочного тестирования уже обойтись сложно. Цена ошибки при таких масштабах высока!
Зная требования к серверу можно переходить к оценке его стоимости.

  

Вариант обоснования по текущей загруженности серверов

 

1 Что и как загружает сервера

Чтобы "не открывать Америку", предлагаю Вам проверить, что раскажу далее. Выполните самостоятельное наблюдение за сервером приложений и сервером субд. Рекомендую воспользоваться бесплатной утилитой Process Explorer.

1.1 Загрузка кластера серверов 1С:Предприятие

Кластер может состоять из одного или неско

льких узлов. Один из узлов является центральным, где функционирует "Менеджер кластера".

Схема кластера

Рисунок 3.

При планировании нескольких серверов учтите, что нагрузка на центральный сервер больше чем на остальные рабочие узлы кластера. Это связано с дополнительным фукнционалом, который выполняется в рамках менеджера кластера rmgr.exe. Особенно это надо учитывать при использовании механизмов платформы 1С:Предприятие:
- полнотекстовый поиск (загружает оперативную память и дисковую подсистему - файлы *.elf, *.dat)

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

- обработка "Параметров сеанса" (пример тут)

На каждом рабочем сервере стартом службы сервера приложений 1С:Предприятие 8.1 руководит ragent.exe (Агент кластера), именно он запускает подчиненные потоки rmngr.exe (Менеджер кластера)и rphost.exe (Рабочий процесс). Все они стартуют из подкаталога /bin.

Process Explorer

Рисунок 4.

Агент кластера нагрузки на сервер не оказывает.
А вот сам исполняемый код конфигураций 1С:Предприятие выполняется в рабочем процессе rphost.exe. Именно rphost требователен к объему оперативной памяти. Ему чем больше доступно памяти, тем лучше. В 32х разрядном варианте он съедает до 1,5-2 Gb RAM. Такой объем ограничен адресацией операционной системой и разрядностью сервера приложений 1С:Предприятие. Чтобы использовать больший объем, используйте 64х разрядные версии операционной системы и серверной части 1С:Предприятие 8.1. Особенно это актуально, если конфигурация обрабатывает объемы данных гигабайтами - сотни тысяч строк в возвращаемом результате выборки например. Один рабочий процесс загружает одно ядро процессора. Т.е. для большей эффективности использования процессорных ресурсов создайте больше рабочих процессов.

Создание рабочего процесса

Думаю, Вы догадались, что частота процессора - одна из основных характеристик, определяющих скорость обработки сервером приложений 1С:Предприятие 8.1.
Влияние дисковой подсистемы сильно связано с функционалом информационной базы.
Загрузку дисков (в подкаталоги /server) создают файлы журнала регистрации конфигурации *.log. На интенсивность оказывают влияние:
- детализация журнала: чем больше детализация, тем больше действий пишутся в журнал;
- период: если долго не обрезать журнал, замедлится чтение журнала;
- интенсивность работы пользователей: чем больше действий, тем больше записи в журнал.
Еще сильнее загрузить диски в некоторой ситуции может технологический журнал, который по умолчанию отключен.
Если не аккуратно включить детальный лог вообще всех записей (не наложить фильтры), то в каталог логов будет очень высокая загрузка операций на запись диска. Каталог опеределяется в файле настройки технологического журнала logcfg.xml.
Еще один источник умеренной загрузки дисковой подсистемы - временные файлы рабочих процессов 1С:Предприятие 8.1. Они расположены во временном каталоге учетной записи, из под которой работает служба сервера приложений. Что вроде C:\Documents and Settings\USR1CV81\Local Settings\Temp, файлы *.tmp и *.dat. Еще один временный каталог - временный каталог операционной системы. Например, C:\WINDOWS\Temp.
Вот некоторые события 1С, способные спровоцировать обращения к диску:
- Большой объем результата выполнения запроса (если объем памяти, занимаемой приложением, превышает 512 Mb и объем выборки превышает 64 Mb, то выборка вместо оперативной памяти размещается во временном файле на диске);
- Переменная типа ХранилищеЗначения большого размера;
- Большой объем значений параметров, передаваемых с клиента на сервер;
- Выгрузка конфигураций.

1.2 Загрузка сервера СУБД

Сервер MS SQL Server 2005 достаточно подробно описан на сайте производителя. Есть опубликованные рекомендации по выбору оборудования.
Тем неменее хочу поделится личными ощущениями применительно к базам данных с "содержимым 1С:Предприятие 8".
Чаще всего недооценивается влияние дисковой подсистемы сервера. Желание съэкономить понятно на количестве и стоимости жестких дисков. Однако при большом количестве пользователей 1С:Предприятие 8 можно даже сразу начинать мониторинг с обращений к диску.
Причин (это мое личное мнение) здесь несколько:

1) Активно используется tempdb. Сложные запросы 1С, транслируясь сервером приложений 1С:Предприятие 8 в sql-запрос, разбиваются на части и их результаты записываются во временные таблицы служебной базы данных tempdb. В последние годы в конфигурациях 1С:Предприятие 8 стали часто использоваться конструкции с использование объекта "Менеджер временных таблиц". Если такие конструкции в явном виде присутствуют в запросе, то еще до странсляцией запроса в sql-запрос к базе данных понятно, что это гарантированная временная таблица в tempdb.
Вообще, такое использование данных само по себе не является чем-то плохим. Я сам раньше уделял tempdb внимания меньше, чем нужно было.
По умолчанию tempdb создается на системном диске, куда устанавливается экземпляр MS SQL Server 2005. Советую озаботиться этим моментом (и с точки зрения произвоидтельности, и с точки зрения контроля свободного места на диске). Перенесите файл базы данных на "быстрые" диски. Есть такая практика создавать дополнительные файлы tempdb, чтобы их общее количество соответствовал количеству ядер. СУБД лучше распораллеливает обращения к I/O чем RAID. Журнал транзакций желательно вынести в отдельный диск/массив.

2) Запросы без отборов провоцируют интенсивное чтение диска. И не только это могут быть отчеты, но ошибки в любых запросах, которые читают избыточные данные вместо только необходимых. Количество баз 1С на сервере влияет на выбор дисковой подсистемы - размещать активное используемые базы на разных дисках/массивах, не допуская избыточных очередей к дискам. Нужно помнить, что лучший способ повысить производительность обращений к дисковой подсистеме - это "развести" дисковые операции по объектам обращений.
Так померив счетчиками Performance Monitor процент времени на чтение и процент времени на запись (и выяснив что их соотношение не 99% к 1%, а например 70% на 30%), мы прежде всего должны обратить внимание на файл журнала транзакций (операции записи) и вынести на отдельный диск/массив.
Примечание. Это действие эффективно, когда в свойствах базы данных Recovery Model в значении Full (такое значение обычно задается по умолчанию при создании базы, еще точнее "наследуется" из свойств системной базы model).

3) Недостаток памяти заставляет СУБД выполнять "подкачку" с диска. Один из основных способов ускорения запросов - это размещение данных в кэше, т.е. в оперативной памяти. Но кэш не исключают польностью чтение с диска. Во-первых, первое обращение к данным все равно вызывает подкачку, "подымая" их в кэш. Во-вторых, наступает момент, когда в кэше "одновременно всем тесно", и остаются "более нужные", а "неугодные" снова потом могут быть считаны с диска.
Мне нравиться мониторить картину происходящего в кэше СУБД такими счетчиками Performance Monitor как "Частота попаданий в кэш" (SQLServer Buffer Manager \ Buffer Cash Hit Ratio) и "Время жизни страницы" (SQLServer Buffer Manager \ Page life expectancy). Значение первого примерно >=92%, второго > 300 секунд.
Тоесть, если вижу проблему с кэшем, то возникает три варианта:
- добавить память (обычно дешевле всего бывает);
- улучшить дисковую подсистему (кстати, например используя "новороченный" RAID-контроллер, который тоже способен часть операций кэшировать в своей памяти);
- улучшить код.
На последнем способе хочется остановится подробней. Это сфера деятельности программистов. Это часто самый дорогой вариант. Но  самый лучший способ решения проблемы.

Реальный пример. Один из моих Заказчиков испытовал проблемы со 100% загруженным сервером. Были загруженны полностью процессоры, что довольно нехарактерно для 1С:Предприятие (4 ядра обслуживало 50 пользователей). Чтобы понять, что происходит был использован продукт фирмы 1С - Центр Управления Производительностью. Хотя в данном случаи с помощью какой программы решать задачу не принципиально. Вы можете воспользоваться любым продуктом, который может Вам разобраться, "кто грузит" MS SQL Server. Сделал запись логов и затем подверг их автоматической обработке. Выяснилось, что на сервере выполняется не очень долгий по времени запрос (несколько десятков секунд), но его частота вызова каждым использователей очень большая (тысячами). Каково же было удивление, когда стал анализировать структуру кода - обыкновенное "левое соединение" и пара "отборов" - ничего особенного.  Запрос был "переформулирован". Теперь он возвращал тот же результат, но уже за одну секунду. На следующий день произошло "маленькое чудо", сервер СУБД имел загрузку менее 15%.
Мораль этой истории. Задачу производительности можно решать различными способами, но учитывайте стоимость решения и прогнозируемый результат. Оптимизация кода не всегда бывает возможна, но не исключайте этот вариант, оставляя только покупку более мощного железа. Для анализа кода чаще всего требуется дополнительные инструменты. Скорее всего они не бесплатные.

1.3 Одновременное использование кластера 1С:Предприятие 8.1 и СУБД на одном сервере

На сайте 1С есть рекомендация: разносить где то от 70 пользователей. Давайте порасуждаем вместе.

Размещение на одном сервере может быть оправдано по двум причинам:
- экономия средств
- высокая скорость обмена между кластером 1С:Предприятие 8.1 и сервером СУБД по причине отсутствия передачи данных по сети.

Личная практика тоже подтверждает, совмещение ролей на одном сервере часто бывает оправданным.
Возьму частный случай, не надо его воспринимать как правильный или не правильный. Он будет просто точкой отсчета. Актуальные цены вы сможете перепроверить, путем использования указанных в расчетах мной позиций.
Итак, предполагается работа 50 пользователей, 45 из них в 1С:Управление Торговлей и остальные 5 в 1С:Бухгалтерия.
Железо подбираем зная, что других задач на серверах не выполняется, клиентские компьюетры покупать не требуется и они удовлетворяют нашим задачам. На таких аспектах, как пропускная способность сети и т.п. мы не акцентируемся, только на выборе серверов.
В обоих случаях стоимость на ПО 1С (сервер приложений x86-64) одна и таже, у меня примерно получилась 254 тыс. руб.
Также постоянна стоимость на ПО СУБД (буду считать для MS SQL Server 2008 Std), примерно 327 тыс.руб.
Будет разница в стоимости лицензий на Windows Server 2003, для стандартной редакции каждый сервер примерно 30 тыс.руб.
Количество клиентов останется тем же, стоиомость одного клиента где-то 5,5 тыс.руб.
Получается, что основная разница возникнет при разнесении ролей сервера приложений и субд по разным серверам за счет стоимость серверного оборудования.
Если брать доступные компоненты на момент на писания статьи, до у меня получилась вот такая конфигурация:
CPU    2xIntel Xeon 5450 3 GHz
(по 2 ядра (одно ядро серверу приложений, одно субд)  на каждые 15 пользователей:   (50/15)*2 ~ 6.7 , ближайшее реально существуеще - это 8 ядер)
RAM    4x4GB DDRII-667
(1 GB дарю ОС, для рабочих процессов выделю 4 рабочих процесса, которые как минимум способны освоить 1.5 Gb каждый и около 9 Gb будет зарезервировано за СУБД, на практике это обычно выдерживает базы данных объемом где то до 20 Gb без потерь в производтельности)
HDD    8x 73GB 15K rpm в RAID10
(размещение дисков в один 10й рейд имеет как сторонников, так и противников, однако 8 дисков позволят Вам как минимум выделить отдельный массив для записи логов, не забывайте, что именно дисковая подсистема чаще всего бывает узким местом из-за недооценки ее влияния)

Попросил российских поставщиков предоставить мне конфигурации, удовлетворяющие данным требованиям, получил
от 240 тыс. рублей российской сборки
и до 325 тыч. рублей за иностранной сборки под заказ.
Рекламировать не хочу, но один из российских поставщиков мне понравился больше остальных - он предоставил на выбор 3 решения: в стойку, башню и еще один в стойку 3U с возможностью увеличения памяти до 64 GB, наращивания до 16 дисков, резервным блоком питания при увеличении стоимости текущей конфигурации по отношению к первым двум вариантам на 20 тыс. руб.

Данная ситуация нам не позволяет оценить текущую загруженность железа. Если нам бюджет не позволяет взять сервера с запасом, то в данном случаи я возьму один сервер и начну его эксплуатировать. Сравню практическую загруженность с предполагаемыми расчетами.
При возникновении очень высокой загруженности ресурсов сервера у меня будет возможность либо наращивать мощность сервера, либо взять второй сервер и перенести на него роль сервера приложений.
Наращивание мощностей сервера дает и другой плюс. В ситуации, когда количество пользователей достигнет некой отметки пользователей и будет сложно ответить на вопрос "не сказывается ли отрицательно совмещение ролей", можно виртуализировать ресурсы.
То есть сервера будут выполняться на разных, но только "виртуальных" серверах, а физически расположены на одном.

1.4 Как отследить активность с помощью Performance Monitor

Для чего мы отслеживаем загрузку сервера? Есть следующий подход при выборе серверного оборудования - опросить параметры информационной системы и железки, которые используются "соседом". Это могут быть опубликованные внедрения на сайте 1С или опыт коллег в форумах. Тут существует опасность "не выяснить значение параметра", который оказывает существенное влияние на производительность. Даже из пункта 2.1.1 уже видно, что различная настройка сервера приложений и использование его функций различными конфигурациями на одном и том же железо может создавать существенно разную нагрузку на ресурсы сервера. Более того, даже просто спрашивая характеристики желаза, мы можем "прозевать" какой то ключевой параметр вроде частоты шины или кэша рейд-контроллера. Это потенциально означает возможность купить "вроде похожий" по характеристикам сервер, а на практике, даже поставив его к соседу выясниться, что это не одно и тоже. Например слышал от коллег фразы: "какая разница, сервер от IBM или Dell". Возможно для бюджетных вариантов разница не существена в плане производительности, а вот для "топовых" моделей разница существует.
Опираться от текущей загруженности, а не от праметров сервера.
Я отследживаю нагрузку сервера для того, чтобы работать не с абсолютными цифрами параметров, а для оценки загруженности компонентов. Чем сильнее компонент загружен, тем больше внимания ему будет уделено, и именно он прежде всего будет усилен в новой конфигурации. Почувствуйте - не надо знать количество пользователей, не надо знать объем базы, не надо знать кучи других параметров - вполне достаточно посмотреть на загрузку сервера.

Снять нагрузку достаточно легко и недорого, если сравнивать с затратами на нагрузочное тестирование. Этот способ обоснования выбора достаточно легко может быть применен любым системным администратором. Оснастка "Performance" входит в состав операционной системы.
Без предварительного мониторинга производительности системы любой выбор серверного оборудования будет не обоснован.
Хочется обратить внимание, что некоторые применяют счетчики  не осозновая их суть. Смотрят на некую рекомендованную (например на сайте 1С) таблицу счетчиков и граничных значений. Замеряют и сравнивают с предложенными цифрами.
Наверно перечислить некотрые из них можно:

  • Memory \ Pages/sec
  • Pocessor [_Total] \ %Processor Time
  • System \ Processor Queue Length
  • Phisical Disk \ Avg. Disk Queue Length
  • Network Interface \ Bytes Total/sec.

Но выделю, что если я не понимаю, ЧТО счетчик и КАК замеряет, то его не использую. Часто можно "схалявить", потому что многие поставщики оборудования сами помогут Вам и попросят предоставить интересующие их счетчики и значения.
Замер показателей счетчиков выполняется для выявления узких мест в серверном оборудовании.
В идеале все компоненты сервера должны быть сбалансированы. В реальности узкое место есть практически всегда.
Новый сервер прежде всего должен устранять проблему выявленного текущего узкого места. Именно решая эту задачу мы обосновываем причину применения более мощного нового сервера, а не просто потому что нам доверяют.

 

  

Сумма, в которую надо уложиться (бюджет)

 

Вопрос бюджета и сложный, и одновременно простой (если математически). Другими словами, за сумму Х всегда какой-то сервер купить можно. А вот чтобы он удовлетворял расчитанным требованиям, тут надо иногда подумать.

  

Выбор между поставщиками

 

Цена одного и того же сервера у разных поставщиков может отличатся существенно.
Часто цену серверов увеличивают компонеты от производителей-брэндов.
Делаю запрос к нескольким поставщикам сразу на сервера нескольких, а не одного производителя.
Озвучиваю бюджет и решаемые задачи сервером. Свое видение, какими характеристиками должен обладать сервер также доношу до продавца. Продают сервера обычные люди. Телепатическими способностями они не обладают. Если они присылают "какое-то недоразумение" или например неоптимальную на мой взгляд дисковую подсистему, то "не исчезаю", а уточняю, какими соображениями они руководствовались. Бывает так, что это я недостаточно ясно сформулировал критерии, а не поставщик "глупый".
Получив конфигурации от нескольких продавцов за одну и туже сумму гораздо легче сравнить их производительность, нежели брать "одну и туже производительность" и смотреть на разницу в стоимости. При примерно равных условиях по озвученным критериям не забывайте про сервисное обслуживание и время восстановления в случаи сбоя.

  

Способы снижения стоимости

 

Если денег нехватает, можно ли оптимизировать процесс покупки?

В качестве экономии можно использовать:

1 Сервера без громких имен производителей. Однако могут возрасти риски:

- заплатить в будущем за более частый ремонт комплектующих;

- не найти комплектующие или сервисный центр в вашем регионе;

- производитель вообще может уйти с рынка.

2 Покупать сервер "размазывая" оплату на несколько кварталов в бюджете компании. 

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

Например, в момент покупки сервера купить объем RAM скажем X GB, а в следующем квартале (заранее учтя это в возможностях сервера) доустановить объем Y Gb.

При этом помнить, что найти в будущем комплектующие для брэндов легче, но стоимость компонент в сравнении с конкурентами выше.

3 Для кластера 1С:Предприяте добавление рабочих узлов по мере потребностей. Кластер 1С:Предприятие изначально решает задачу балансировки нагрузки клиентских соединений между рабочими серверами 1С:Предприятие. По мере появления новых пользователей в компании (количество которых то и спрогнозировать заранее бывает сложно) вы будете добавлять новые сервера в кластер.
4 Снижение стоимости ПО.
Обычно мои системы в клиент серверном-варианте используют в качестве
ОС - Windows Server 2003 x86-64,
СУБД - MS SQL Server 2005 x86-64,
и кластер серверов 1С:Предприятие x86-64.
Говоря о постепенном росте нагрузки на информационную систему, изначально можно купить лицензию на сервер приложений 1С - 32х разрядный. Если на практике не хватит  - выполнить апгрейд до 64х разрядного. Не обязательно сразу покупать и Enterprise версию операционной системы и MS SQL Server 2005, очень часто достаточно версии Standart. Только обязательно уточните у продавца возможность апгрейда каждого из продуктов.
Теперь о поддержке бесплтаных версий СУБД. Таковыми являются MS SQL Server Express, IBM DB2 Express-C, PostgreSQL. В моей практике таких клиентов не много, советовать что то конкретное сложно. Однако общаясь с коллегами, сформировал убеждение. На начальном этапе многих проектов такие варианты жизнеспособны, но требуют интузиазма обслуживающих администраторов и программистов. Но как только возникают вопросы, которые "повисают воздухе" без быстрого ответа (а работать то надо), то коллеги переходят к платным вариантам СУБД.
5 Вертикальное масштабирование является удобным приемом для мощных серверов, когда сразу не ясна необходимая мощность или очень дорог нагрузочный тест. Мне например известно, что IBM в своих топовых моделях предоставляет возможность "сборки нескольких сервер в один". Эта компания устанавливает в материнских платах свои чипсеты, называют такую архитектуру "как в мейнфремах IBM". Тоесть вы покупаете один сервер, который должен справиться с задачей на начальном этапе. А затем, когда со временем нагрузка на сервер вырастет, вы не заменяете его на более мощный, а докупаете еще такой же сервер. Соединив "коннектором" два таких сервера, их мощности складываются и для операционной системы это ОДИН сервер, обадающей "двойной" мощностью.

 

  

Влияние на стоимость задачи, которую решает сервер

 
Защита от выхода из строя "по учебнику" - это резервирование наиболее вероятных к поломках компонет. Стоимость решений по резервированию при этом не должна превышать стоимость самого выхода из строя серверов (фактически остановки нашей компании).
А выходях из строя и "брэндовые железки", и "безымянные".Наличие сервисного центра и времени доставки запасных комплектующих определяет мое предпочтение.
Если компания работает по схеме 12 часов х 5 дней в неделю, то требования к восстановлению надо уточнить у бизнеса, но все же это обычно потратить сутки на доставку запасной компоненты взамен вышедшей из строя приемлемо. Плюс наиболее часто выходящие из строя детали (имеющие двигающиеся части) вроде блоков питания (вентиляторы) и жестких дисков недорого резервировать/дублировать.
В компаниях с режимом работы 24 часа х 7 дней в неделю логично спрогнозировать даже задачи бизнеса так - всегда должен быть доступен горячий резерв. Бюджет решаемой задачи часто больше не двое, а в три и более раз. Причиной служит избыточное резервирование "питания", дублирование интерфейсов к внешним дисковым системам, используемое ПО.
1 Отказоусточивость. Когда прикупать  запасные компоненты или резервировать сервера?
Чаще всего отвечают на этот вопрос не технические специалисты, а люди, финансирующие бюджет на закупку и обслуживание серверов. Наша задача прежде всего заключается в том, чтобы правильно донести до заинтересованных в стабильной работе 1С:Предприятие 8, что при выходе из строя материнской платы, хоть и с небольшой вероятностью, но все же предприятию грозит остановка. Существуют технические способы компенсации этих рисков, и тут вы их доводите эти способы и стоимость до руководства.
2 Быстродействие сервера лучше всего понимать как именно возможность работы сервера обеспечить программному обеспечению нужные ресурсы. Это вовсе не означает, что если сервер будет не загружен, до однозначно будет "все летать". Существуют различные механизмы (вроде механизма блокировок), которые куда больше оказывают влияние на общую производительность системы. Нам нужно разделять факторы, снижающие быстродействия. Но и думать, что оптимизировав код до совершенства можно заставить его работать на любом компьютере тоже опасная затея.
3 Качество сервера определяется вроде кажущимися на первый взгляд второстепенными факторами как гарантия, возможность замены в будущем вышедших из строя компонет, энергопотреблением, сроками доставки и место расположением поставщика.

Для своих проектов заполняю такую анкету:

 

1. Сколько времени должен будет проработать новый сервер (реалистично) _________

2. Предположительно какой максимальный объем базы данных будет на конец срока эксплуатации ____

3. Точно также сколько максимум активных пользователей _____

4. Готовы ли ждать сервер "под заказ" до 8 недель или надо быстро ______

5. Есть ли религиозные убеждения против брэнд-серверов _____

6. Сервер в стойку (особенно, если нет серверной) или отдельно (башня) _______

7. Сколько времени (максимум) может быть потрачено на восстановление данных ______

8. Требуется ли скидки как корпоративному заказчику (нужно будет указать юр. лицо) ______

9. Ограничения по бюджету ____

10. Ограничения по времени (если есть) _____

  

Ссылки

 

Материал также обсуждается здесь >>

Вы также можете пообщаться со мной на курсах >>>

 

Похожий материал по теме:

Пример выбора серверного оборудования для 250 пользователей 1С:Предприятие 8.1

Перейти к другим материалам сайта

  

Платное

 

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

  
 
 

gilev.ruэкспертиза 1С оптимизация производительности тех.поддержка обучение