В нашей компании начинается новый проект внедрения 1С:ERP в одной торговой организации. Заказчик попросил дать некоторые рекомендации по оборудованию и требованию к инфраструктуре для комфортной работы 100+ пользователей в системе 1С:ERP. Ниже мои выкладки на эту тему.
Но прежде всего, хотел бы сказать, что я не являюсь опытным системным администратором и тем более специалистом по серверному оборудованию. Но за моими плечами есть один завершенный проект внедрения 1С:ERP на производственном предприятии (со схожим объемом операций и количеством пользователей) в роли ведущего разработчика. И данная статья появилась здесь больше для того, чтобы услышать критику / рекомендации / замечания от людей, хорошо разбирающихся в железе и имеющих реальный опыт эксплуатации системы 1С:ERP. Ну и надеюсь, может еще кому статья пригодится. Итак:
Входные данные:
- Учетная система — 1С:ERP 2.4 + интеграция с 1С:Документооборот 2.1.
- Количество одновременно работающих пользователей:
- С учетной системой: 80-100
- С документооборотом: 100-200
- Среднемесячное количество основных операций:
- Поступление товаров и услуг: ~2000 (~50000 строк)
- Реализация товаров и услуг: ~13000 (~2000000 строк)
- Перемещение товаров: ~8000 (~800000 строк)
- Прочие связанные операции с на порядок меньшим объемом.
- Большинство пользователей находятся в одной локальной сети.
- Разработка ведется на мощностях клиента в отдельном тестовом контуре (~4 разработчика и ~5 консультантов + ключевые пользователи)
- В качестве серверного ПО – продукция компании Microsoft.
Сервер для продакшена:
- Мои рекомендации — совместить роли сервера баз данных (SQL) и сервера 1С. Деньги, которые будут затрачены на покупку отдельного сервера, мне кажется, разумнее вложить в сервер баз данных. Причины следующие:
- Сервер 1С практически не использует диски (только временные файлы и журнал регистрации), а на отдельный физический сервер их покупать все равно придется.
- Также придется покупать и остальные составляющие сервера (корпус, материнская плата и т. д.)
- Соответственно придется покупать серверное ПО (Microsoft Windows Server, Windows CAL-лицензии на каждого пользователя и т. д.)
- Намного продуктивнее вложить все эти средства в бОльший объем оперативной памяти, более быстрые диски (в 90% случаев узкое место — это диски) и более производительные процессоры для сервера баз данных.
- Получаем до 10% прирост производительности за счет Shared Memory (и исключаются проблемы, которые могли бы возникнуть с сетью).
- Рекомендации по серверу баз данных:
- Диски: Это самый главный фактор. К выбору дисков и контроллера следует подойти с особой тщательностью. Минимальные требования следующие:
- Система: RAID 1 или выше на быстрых SAS дисках, с оборотами >10000, объем ~500 Гб.
- Отдельный диск для временных файлов (файл подкачки, TEMP, база TempDB): SSD-диск объемом ~256 Гб (или 2 по ~128 Гб), плановая замена через 3-5 лет.
- Диски для баз данных: RAID 10 или выше на быстрых SAS дисках, с оборотами >10000, объем ~1 Тб. Возможны также варианты с промышленными SSD-дисками (например, с интерфейсом PCI-Express) и СХД. Также, в зависимости от бюджета, есть смысл рассмотреть отдельные массивы дисков для файлов баз данных и файлов журналов транзакций.
- Дешёвые диски для служебных файлов и бэкапов «copy only»: RAID 1 (в условиях ограниченного бюджета, без RAID), объем ~3 Тб.
- Учесть пропускные возможности материнской платы / контроллера / шины / дисков. Бывало в моей практике так, что покупали дорогие диски и экономили на контроллере. В результате, контроллер выступая «узким горлышком», не давал дискам работать на полную производительность.
- Оперативная память: 256 Гб и выше.
- Процессор: Два или четыре серверных процессора, по 8 ядер (суммарное количество ядер >16) с тактовой частотой >2.7 GHz.
- Сетевой адаптер: пропускная способность 1 Гбит и выше. Обратить внимание на сетевое оборудование до сервера (пропускная способность должна соответствовать).
- Диски: Это самый главный фактор. К выбору дисков и контроллера следует подойти с особой тщательностью. Минимальные требования следующие:
Надежность:
Надежность сервера баз данных может достигается за счет:
- Регулярного резервного копирования (система, базы данных и т. д.)
- Использования RAID 1 и выше для всех дисковых накопителей.
- Использования комплектующих с гарантией замены. В удаленных регионах, использование запасных комплектующих.
- Наиболее безопасный и дорогой вариант — использование связки из двух серверов, работающих в режиме кластера.
В случае использования выделенных серверов в дата-центрах, за надежность отвечает дата-центр.
Разработочный / тестовый сервер:
Совмещение роли сервера баз данных, сервера 1С и сервера терминалов. Системные требования — 1/4 от мощностей производственного сервера:
- Диски:
- Система: RAID 1 или выше, объем ~500 Гб.
- Базы данных: RAID 1 или выше, объем: 1-3 Тб.
- Оперативная память: >64 Гб.
Организация работы пользователей:
Тут возможны 2 схемы: терминальный сервер и работа в тонком клиенте со своих рабочих машин. Рассмотрим плюсы / минусы:
- Терминальный сервер:
- Плюсы:
- Возможность безопасного подключения из любой точки мира.
- Если пользователи работают в различных информационных базах, можно сэкономить на лицензиях 1С, установив лицензии на сервер терминалов (как однопользовательские), а не на сервер 1С.
- Удобство администрирования. Намного легче выполнять такие операции как обновление платформы, очистка кэша пользователей, подключение к сессии пользователя (с демонстрацией экрана), администрирования списка баз и т. д.
- Контроль производительности системы, проще искать «узкие места».
- Минусы:
- Необходим довольно производительный сервер. Дополнительные затраты на обслуживание.
- Необходимо дорогостоящее серверное ПО (Microsoft Windows Server, Windows CAL-лицензии, лицензии на терминальные сессии).
- В случае выхода сервера из строя, работа «встанет» на неопределенное время.
- Возможны проблемы с подключением торгового оборудования, смарт-карт, проблемы с печатью.
- Затрудняется или становится совсем невозможна интеграция с другими программами пользователя (почтовый клиент, мессенджеры, переход по навигационной ссылке в документ из письма и т. д.).
- У малоподготовленных пользователей возникают проблемы с доступом к файловой системе своего компьютера.
- Плюсы:
- Работа со своих рабочих мест:
- Плюсы:
- Нет затрат на дополнительный терминальный сервер.
- Надежность. Выход из строя компьютера пользователя, влечет к простою только этого пользователя.
- Нет проблем с подключением оборудования, смарт-карт, печатью.
- Система 1С:ERP адаптирована для работы в тонком клиенте. В этом случае нагрузка на клиентскую часть минимальна, что позволяет работать на малопроизводительных компьютерах (в рамках минимальных системных требований).
- На компьютер пользователя дополнительно устанавливается только то ПО, которое необходимо ему в работе (например, Microsoft Office).
- Минусы:
- Рабочие компьютеры пользователей должны соответствовать минимальным системным требованиям.
- Дополнительный трафик внутри сети.
- В общем случае, лицензии 1С выдаются на каждое подключение к информационной базе.
- Нет возможности подключаться к информационным базам вне локальной сети (вариант решения – организация WEB-доступа к информационным базам).
- Есть некоторые трудности с администрированием, затрудняются такие операции как обновление платформы, очистка кэша пользователей, администрирование списка баз и т. д.
- Затрудняется поддержка пользователей. Для доступа к сессии пользователя нужны специальные средства (TeamViewer, RAdmin, LiteManager и т. д.)
- Плюсы:
- Возможен комбинированный случай, когда часть пользователей работают с сервера терминалов, часть со своих рабочих мест.
Итог:
Минимальная конфигурация для работы пользователей в системе 1С:ERP для данного количества пользователей / операций следующая:
- Совмещенная роль сервера СУБД и сервера 1С. Технические требования указаны выше.
- Основная часть пользователей работает через тонкий клиент со своих рабочих мест.
- Сервер терминалов для ограниченного количества пользователей, которым необходим постоянный удаленный доступ.
P.S.
Если не трудно, поделитесь в комментариях характеристиками своих серверов и объемом операций / пользователей, если вы используете конфигурацию 1С:ERP. Продукт относительно новый, и по моим субъективным ощущениям невероятно прожорливый. Все интересуются минимальными системным требованиями, а опыта реальной эксплуатации системы пока не очень много. Вместе мы сможем собрать более-менее реалистичную статистику. Если комментариев будет достаточно, обещаю опубликовать отдельную статью со сводными данными.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
тактовая частота 3+ GHz. Для комфорта.
На 2.7 не получить высоких гилевских попугаев никак.
3+ это как раз барьер между удовлетворительно и хорошо.
Чтобы бы ты не делал с винтами сетью и тд на 2.7 в уровень комфортной работы не перейти.
у нас есть замечательные курсы для администраторов, попадают в ваше тему на 146% ))
— чтобы положить высоконагруженную систему, вам и sqlite ЖР хватит за глаза, а если кто заковногодит массивы и блоб-данные в сеансвоые данные….
это актуально было в каменном веке…
50% всей производительности приходится на процессоры
застрелите высоконагруженную систему легко, вы еще туда 3пар поставьте и законсолидируйте не 1С виртуалки, чтобы железки использовать по максимому и … увольняйтесь )))
а не судьба резервный сервера кластера использовать?
приходите к нам на курсы лучше
Есть подозрение, что 128 может не хватить
Есть опыт эксплуатации ERP 1.5 года с ~400 одновременно работающих пользователей. Все настройки сервера и его мощность нивелируются перед такими факторами как:
1. Явные ошибки сервера 1С как такого начиная с версии 8.3.7.2027. Это косяки с планами запросов, с управлением рабочими процессами, с подвисшими управляемыми блокировками (до перезапуска сервера 1С), разрушение кэша пользователей, несуразные ошибки при динамическом (а иногда и при нормальном) обновлении и даже потеря SQL таблиц при реструктуризации через ТИИ. Дедлоки при одновременном проведении документов. Я заколебался по звонку убивать сессии пользователей у которых платформа намертво зависла или рухнула при открытых документах.
2. Журнал SQLITE — этот хлам вырубать нужно сразу же (переводя на старый формат) иначе нормальной жизни не будет никогда и ни у кого.
3. Планы обменов — не приведи господь вам столкнутся с необходимость обмена данными в реальном времени (чаще 3-х раз в день). Висеть будут все, в том числе с ошибками типа «превышение ожидания времени блокировки».
4. Регламентные задания — тоже самое что и с планами обменов, обновление индекса полнотекстового поиска и слияние индексов просто не позволяет пользователям работать вообще, пока он не закончится.
5. Постоянные утечки памяти рабочих процессов. Не выделишь память — рухнет и рабочий процесс и пользователь отвалится. Выделишь всю доступную — рухнет сервер, но дня через 2-3.
6. Закрытие месяца идет около недели. На разных этапах приходится перезапускать расчет, т.к. он отваливается по разным причинам. Запускать расчет приходится более 6 раз на разных этапах. Просто попытка открыть форму закрытия месяца подвешивает всех пользователей на несколько минут, ровно как и переключение на другие месяцы, чтобы понять вскрылись они или нет.
При всех этих проблемах хочу отметить тот факт, что все это время сервер не нагружен и на 10%. Говоря «сервер» я имею ввиду: CPU, очередь ожидания дисков, сеть и т.д. по всем счетчикам, которые когда либо запускали для тестирования производительности.
1С сама по себе очень плохо распараллеливается. Судя по SQL профайлеру просто «спамит» кучей мелких однотипных запросов. Ну очень не оптимально и туго работает с RLS. Фрагментация индексов постоянно в районе 80%, хоть обреструктуризируйся и обдефрагментируйся.
Многомесячные наблюдения за сервером 1С меня заставили сделать неутешительный вывод — 1С тормозит сама по себе, хоть поставь её на Sunway TaihuLight — она будет работать с производительностью вашего домашнего ПК.
Извиняюсь за эмоциональный пост. Но многочисленные жалобы пользователей и нулевые результаты фирм-оптимизаторов серверов 1С просто констатируют безвыходную ситуацию.
(2)
Вячеслав, большое спасибо за комментарий. Добавлю исправления в статью.
С удовольствием пришел бы, правда. Только курсы у вас очные в Москве. Организуйте онлайн обучение. Мне кажется, спрос будет.
Действительно, почему бы и нет.
Бесплатным советом не поделитесь?
А по другим пунктам статьи замечаний нет?
(3)
Думаю вы правы. Я тоже здесь сомневался. Исправил в статье на 256 Гб.
(5) замечания есть по всему целиком, поэтому Вам проще сначала пройти курс, здесь три дня материала даже конспектом я излагать не буду
все что бесплатно — у нас опубликовано на сайте
(4) универсальный код всегда будет работать универсально «никак»
старое видео ,которое не потеряет своей актуальности в ближайшей перспективе
типовой код это заготовка, которую надо дошлифовывать напильником под конкретную ситуацию
если работа 24/7 и есть возможность лучше купить 2 сервера не стоит экономить, может выйти боком.
вопрос спорный во первых не надо пользоваться почтовыми клиентами на сервере, да и документами не желательно. Во вторых интеграция почты с 1С УПП у нас прошла легко и без всяких проблем, все зависит от квалификации программиста.
не совсем понятно, что имеется в виду, если пользователь не может свернуть терминальную сессию то стоит задуматься нужен ли такой пользователь,а если админ не может расшарить папку, то нужен ли такой админ.
Проблему с печатью в RDP решил с помощью ScrewDrivers и сетевых МФУ.
Это справедливо для 1 и 2 вариантов. поэтому лучше иметь 2 сервера, расшарить временно RDP или поднять скуль для основных пользователей займет от силы пару тройку часов.
+ RDP — возможность использования на рабочих местах бездисковых тонких клиентов,(даже б/у, минимальной стоимостью) и меньшей вероятности «исчезновения железных компонентов». Бездисковые — больше безопасность.
(3)
У нас обменов много и работают в интервале от 10-15 минут, ничего не висит. Используем только план обмена для регистрации и КД 2.1.
(4)
Перезагружайте службы 1с каждый день в регламентное техническое окно.
Приведите пожалуйста конфигурацию вашей системы.
Чем замеряли тормознутость? Использовали APDEX? Какие критерии брали?
Также помогает подключение (распараллеливание) дополнительных Рабочих серверов к базе.
Перенос выполнение кода «тугих и долгих» фоновых процессов и регламентных задний на отдельный Рабочий сервер.
Жаль, что такое распределение нельзя сделать на уровне SQL (с поддержкой на стороне 1С).
Типа вот есть подсистема обмена — и она (ее код) работают на таком-то Рабочем сервере + ее данные и все таблицы хранятся на «таком-то» сервере SQL. И все что касается обменов — обрабатывается отельным SQL сервером, но тем не менее, со стороны прикладного решения — это одна и та же база (собственно, это инкапсулируется на стороне 1С)
(10)
В том то и дело, что если почтовый клиент и мессенджер на компьютере клиента, а 1С в терминале то и затрудняется интеграция. Например, как-то была задача по ссылке из письма переходить в документ в 1С. Но проблема в том, что 1С в терминале а почта на компьютере пользователя. Как такое сделать — сходу не понятно.
Админ папку расшарил, даже диски клиента подключены в терминале, но пользователи все равно путаются, особенно при работе в RempteApp.
Поднять на терминальном сервере? Ну если только для самых-самых ключевых пользователей то да, может и сработать. Но держать сервер терминалов как резервный для сервера баз данных, мне кажется, не самая хорошая идея. Лучше иметь кластер из 2-х серверов, а пользователи пусть работают со своих рабочих мест.
(7)
А есть у вас пример, насколько реально увеличивается производительность в информационной базе 1С после перехода на рам диск?
Хочется понять, насколько игра стоит свеч? И на каких конфигурациях / объемах / оборудовании проверяли?
(4)
Большое спасибо, что поделились опытом.
Да, тоже, к сожалению сталкивался с подобным. Пользователи жалуются, что «все тормозит». Идешь на сервер, смотришь в монитор производительности, а сервер не загружен, все показатели в норме. Что делать, с ходу совсем не понятно.
(15)
У меня только файловая, можно положить на сервак по тимвьюеру SQL и испытать, рамдиск на 64 гига могу сделать,если что — в лс
(14)
вот в этом проблема не надо все подряд подключать одна единственная папка + наклейка на монитор для склеротиков.
1С на сервере, а как вы к ней подключаетесь совсем другое, никто не мешает подключить часть пользователей по RDP а часть напрямую, там где нужно, у нас так например касса подключена.
(2) и (8) Очень много пафоса, а по делу НОЛЬ! Зачем постить что-то и понтовать курсы? Что спрос уже закончился? или как?
А я категорически не соглашусь. что это актуально было в каменом веке. Система офигенно умеет писать СВОП и ничего с этим не поделать!!! Так что если бюджет позволяет то систему следует и желательно разделать на отдельный носитель.
(0)У вас есть опыт конфигурирования и поддержки высоко нагруженных серверных систем?
(4) В аналогичной ситуации ))
1. Полностью согласен почти по всем перечисленным пунктам, через все эти вещи прошли. В итоге пришли к регламенту про обновление 1 раз в день в обед, запуск почти всех фоновых заданий ночью, а переде этим перегрузка сервера. При таких условиях работать стало полегче.
2. Рекомендую написать свой или воспользоватся разработками представленными на инфостарте, но это сугубо ИМХО.
3. А вот такой проблемы у нас нет, обмен идет либо по требованию либо 1 раз в день вечером когда нагрузка меньше, и влияния на общую производительность особой не имеет (возможно из-за того что новых объектов для обмена немного или нет вообще).
4. Тут и как и раньше писал запускайте ночью, также есть настройки фоновых заданий, вплоть до указания количества потоков, в общем тут точно нужно применять напильник.
5. Аналогичная проблема, но тут может быть недостаточная или неверная настройка серверов, так как есть наглядный пример где похожие организации с близкими по конфигурациями серверов, имеют разную статистику «багов» включая утечку памяти рабочих процессов, но возможно делаю не верный вывод.
6. Вот тут не понятно, так как сам процесс закрытия идет максимум 1 час на организацию, и ошибки он достаточно адекватно представляет (правда что бы докопаться зачастую много кликов приходится делать). Мне кажется лучше принять меры по недопущения ошибок в процессе, чем мучится при закрытии.
Надеюсь что вы в erp не используете RLS, очень замедляет работу, вызывает неадекватное поведение форм.
(20) Смею предположить, что имелось в виду нерациональным на сегодняшний день ставить в сервера что-то отличное от SSD. И под системный диск в том числе! Поставьте интеловский консьюмерскую 5хх серию, раздел под систему сделать процнтов на 20 меньше объёма диска и будет вам долговременное счастье.
Из своего опыта:
1. Процессор максимальной частоты на сколько позволяет бюджет. Однозначно больше 3ГГц! А вот количество ядер уже относительно вторично и зависит от количества одновременно активных действий пользователей. А то может у вас 100 человек генерируют в среднем пару одновременных действий.
2. В качестве дисков SSD
3. Объем памяти сами смотрите статистику использования конкретно на вашей системе. Ограничить MSSQL иначе он использует всю доступную память и у кластера 1С тоже прописать лимиты по отстреливанию процессов сжирающих память (и отслеживать источник)
3. Выносить каталоги временных файлов системы (&TMP%, %TEMP%) и 1С (каталог кластера или отдельные его папки используя связанные папки) в отдельный раздел. Это поможет с сортировками на сервере 1С
4. Выносить ТемпДБ. Это уже отдельная пестня
Не скупитесь на процессор. Чем дольше выполняется операция, тем дольше будут висеть блокировки.
Сугубо своё имхо основанное на жизненных обстоятельствах.
(19) вы я смотрю по делу фантастически написали )))
мне плевать что там у вас понты, автору не хватает знаний, но он спешит учить других
(15) еще как стоит, это значительно сглаживает говнокод, когда сотни тысяч строк и больше швыряют во временные таблицы tempdb, да и sqllite журнал регистрации с сеансовыми данными туда не лишним положить
(13)
Перенос выполнение кода «тугих и долгих» фоновых процессов и регламентных задний на отдельный Рабочий сервер.
гораздо лучше помогает более мощный, но один сервер 1С — 100%
в кластер добавляют от «нищеты» )))
(23) хотя бы s3710
Конечно SAS диски рекомендовать в конце 2017 года, это еще тот совет.
(21)
То что я описал в пункте «Входные данные:» попадает под ваше определение высоко нагруженной системы?
(30)Нет.
(30)Сделайте еще раз анализ вашей архитектуры и проведите прогнозные расчеты производительности с учетом слабых мест приложений который собираетесь разворачивать на вашем сервере.
(31)
Ну значит, к сожалению, нет.
(33) Вы в конфигурации своего сервера одновременно уменьшаете производительность и делаете ее попытку установки SSD ради увеличения производительности, На вскидку: судя по объему вам понадобится корзина из 8 дисков с соответствующим контроллером RAID, RAID 10 из 8 SAS дисков будет обладать пропускной способностью на запись ~400-500Мб/с, на чтение ~800-1000Мб/с, что гораздо выше чем пропускная способность чем у 1 SSD, при установке всех SSD пропускная способность возрасте в 3-4 раза, про надежность даже не говорю. Примерно такие же расчеты делаются и для процессоров, сетевых контроллеров. Резервное копирование серверов делается на другие сервера (дисковые полки, схд).
(27)Вы имеете ввиду, что при распределении, допустим, выполнение кода модулей на разных рабочих серверах (пусть даже их общая вычислительная мощь= мощи 1 отдельного сервера (центрального)) — есть все же лаг обеспечения контекста выполнения для каждого из доп. рабочих серверов?
Сомневаюсь, что цель реализации 1С функционала «Рабочих серверов для базы» — сводится к борьбе с «нищетой» ))
(35)
это называется штраф за синхронизацию, плюс дедлоки на коде (не путать с данными) и много чего еще слабопубликуемого и диагностируемого метриками
сомневаться вы можете в чем угодно и в ком угодно, благодаря этому у нас всегда будет хлеб )))
(36)
очень слабая взаимосвязь.
плюс дедлоки на коде (не путать с данными)
Имеется ввиду, что «дедлок кода» настаёт в случае каких-то событий (при использовании нескольких Рабочих серверов), не связанных с данными? Т.е. где-то в одном месте читают, а на другом Раб.сервере пытаются записать данные? Если так — то это все же суть блокировка данных БД. Если нет (данные — не связаны с БД, например ХранилищеЗначений в памяти) — то можете привести пример такого «дедлока кода», который связан именно с распределение выполнения кода на разных Рабочих серверах? Действительно интересно
2687w v2 3.6 8 core 4.0 single core будет идеальным вариантом)
(29) сейчас уже SSD SAS парочку в продаже видел. вот только нужны ли они?
Реализую третий проект ERP на нагруженных системах. Из опыта…
1. SQL физический поставил забыл, только SSD на современном контролере (для экономных можно подключать диски на прямую и бить базу по группам , RAID в данном случае зло). По процессорам влияет только скорость шины. Если процессоры (для ERP) нагружены значит проблемы в файловой системе или плохом состояние таблиц. Рассматриваю типовую конфигурацию ERP, рекомендую к ней стремиться много проблем от непонимания этого. Обновление статистики не реже раза в сутки, индексы в идеале каждый час если это возможно.
2. 1С главное частота процессора 3.6 + для комфорта , памяти x2 без обновления x3 если планирует динамически обновляться относительно памяти SQL. Гилев тут в чем-то прав , лучше один сервер с ним меньше проблем, но не всегда его хватает. Журнал на ОТДЕЛЬНЫЙ физический диск , очереди на него быть не должно, если с этим проблемы лучше выключить, как частично решение проблемы перейти на старый формат.
(9) Видео давно потеряло актуальность.
Конфигурации стали сложнее, специалисты в разы дороже. Пилить ERP напильников признак низкой квалификации и недальновидности.
(40)
Уточните, пожалуйста, что надо делать с индексами каждый час?
(39) Пишут, что такие устройства могут быть востребованы, как ни странно(не каменный век, все же) —
Правда, предполагается, что такие диски надо подключать к контроллеру RAID 12 ГБ/с(кэш 1-4 ГБ, «батарейка») стоимостью от 50-60 т.р. и выше. Что сводит целесообразность их применения почти к нулю(учитывая стоимость их самих), даже на «высоконагруженных системах». Вот если бы можно было прямиком к дешевой десктопной матплате, тысяч за пять, то им бы цены не было…
(42)
Статистику нужно обновлять, а индексы дефрагментировать. Логично же.
(41) да вы даже видео не посмотрели, сложность конфигурации к теме видео ни как не относится
еще скажите что ERP учитывают особенности железа заказчика и особенности ведения учета
В статье абсолютно проигнорировано «почему»:
Почему указаны именно такие минимальные требования для дисковой системы?
Почему именно столько оперативной памяти?
Почему именно столько процессоров и с такой частотой?
Понравился подраздел «надёжность». Это о чем? Знаю об отказоустойчивости, знаю о допустимом времени простоя, знаю о уровнях сохранности данных, а о надёжности не слышал.
Но больше всего убило про плюсы и минусы различных видов подключения к серверу 1С. Вот самые яркие моменты:
«Терминальный сервер, Плюсы: Возможность безопасного подключения из любой точки мира.» В первый раз слышу чтобы терминальный сервер обеспечивал возможность подключиться из любой точки мира, а к тому же ещё и безопасно. В общем случае сервер терминалов дает меньше безопасность чем трёхзвенная архитектура.
«Работа со своих рабочих мест. Минусы: Дополнительный трафик внутри сети.» А подключение к серверу терминалов не даёт дополнительный трафик внутри сети?
«Работа со своих рабочих мест. Минусы: Нет возможности подключаться к информационным базам вне локальной сети (вариант решения – организация WEB-доступа к информационным базам).» А к серверу терминалов вы подключаетесь магическим способом из любой точки мира с повышенной безопасностью?
Автору стоит подтянуть свои знания о администрировании сетей и 1С в организации.
(46)
Исходя из опыта предыдущих внедрений. Я написал об этом.
А я в первый раз слышу, чтобы НЕ обеспечивал. При использовании, например, сертификатов или VPN вполне себе будет безопасное соединение из любой точки мира.
А как по вашему еще можно удаленно работать с 1С, если это не сервер терминалов, VPN или web-доступ к информационной базе?
В разы меньший трафик, нежели при использовании тонкого клиента.
Да, именно так.
Критиковать может каждый. Расскажите как вы видите идеальный вариант работы с 1С, выполняющий все реальные задачи бизнеса.
(46) Чапаев и пустота.
Пришёл, всех шашкой порубил и вот… Не хочет увеличивать энтропию форума… 🙂
(46) Давненько не читал такого бреда. Либо тролль.
поднял на микротике опенвпн. но 1с из вне локальной сети не подключается, может кто знает почему? из-за того, что он udp не поддерживает?
Примерные конфигурации можно посмотреть здесь