Комментарии 50
А бэкапы? Или предполагается, что уже есть, куда их делать?
Чем плох вариант с сервером на Xeon 2600 серии для двух виртуалок?
В идеале, отдельные диски надо под систему и отдельно диски под профили терминальных пользователей, базы 1С и прочее добро. С нормальной политикой хранения документов где-нибудь на файловом сервере. Даже в относительно дешёвых вариантах такое доступно (при условии, что файловый сервер уже есть). А если файлового сервера нет — нет и бэкапов?
А ещё, хотелось бы узнать у тех, кто это использует: RAID 1 на SSD стоит этого? Диски не умирают одновременно?
Чем плох вариант с сервером на Xeon 2600 серии для двух виртуалок?
В идеале, отдельные диски надо под систему и отдельно диски под профили терминальных пользователей, базы 1С и прочее добро. С нормальной политикой хранения документов где-нибудь на файловом сервере. Даже в относительно дешёвых вариантах такое доступно (при условии, что файловый сервер уже есть). А если файлового сервера нет — нет и бэкапов?
А ещё, хотелось бы узнать у тех, кто это использует: RAID 1 на SSD стоит этого? Диски не умирают одновременно?
Конечно вариантов реализации сервиса 1С очень много. Мы рекомендуем делать бэкапы на отдельную железку, для удобства.
Вариант на Xeon 2600 не плох, но он значительно дороже, а для данной задачи достаточно и Xeon 5600 серии.
Про SSD диски наблюдали практику в дата центрах, когда диски ставили в Raid 1 из разных партий, но возможно это излишние предосторожности.
В практике не встречали чтобы SSD умирали одновременно.
Вариант на Xeon 2600 не плох, но он значительно дороже, а для данной задачи достаточно и Xeon 5600 серии.
Про SSD диски наблюдали практику в дата центрах, когда диски ставили в Raid 1 из разных партий, но возможно это излишние предосторожности.
В практике не встречали чтобы SSD умирали одновременно.
В основном используем Raid10, ещё не разу не умирали одновременно диски. Хотя стараемся ставить разных производителей (в основном samsung и intel) или разные модели одного производителя.
Рассматривается выбор сервера. Для бэкапов можно использовать недорогой NAS, в данном частном случае. На небольшую компанию хватит Synology DS213j с двумя дисками WD RE или RED.
Год назад сделал RAID0 из 2-х SSD, сервер нормально крутится до сих пор. Насчет RAID1 из SSD ничего сказать не могу.
Эм считаю что терминальный сервер это лишняя трата денег, если в качестве конечного сервиса это только 1С предприятие, гораздо дешевле и разумней поступить иначе:
1. Все на одном сервере, для доступа клиентов используем Apache под Windows
2. Два сервера, 1с ОС Linux для доступа клиентов к бд, второй это наш SQL + 1C Предприятие.
Конкретизировать конфигурации я не буду, для доступа 50 человек в базу нам хватит сервера с 2 ГБ ОЗУ, самым медленным диском и тд, для этих целей можно вообще арендовать сервер в облаке за 500 рублей в среднем в месяц. При этом для масштабирования системы в будущем, фронтэдом вешаем Nginx настраивая его как балансировщик по 443 порту, а бакэндом апач на этом же сервере, в случае роста компании добавляем еще один сервер с апачем и строчку в конфигурацию Nginx.
Если же все вешаем на 1 сервер то там просто виндовый апач, с опубликованной БД. И вот именно для БД я бы позаботился не только процессором а именно SSD причем желательно разнести данные логи и tempdb на разные диски.
И не тратил бы деньги на сервер терминалов и терминальные лицензии и по 700 метров ОЗУ на каждого пользователя, мне кажется это в современных реалиях просто расточительство ресурсов и не достаточная глубина знаний предмета.
1. Все на одном сервере, для доступа клиентов используем Apache под Windows
2. Два сервера, 1с ОС Linux для доступа клиентов к бд, второй это наш SQL + 1C Предприятие.
Конкретизировать конфигурации я не буду, для доступа 50 человек в базу нам хватит сервера с 2 ГБ ОЗУ, самым медленным диском и тд, для этих целей можно вообще арендовать сервер в облаке за 500 рублей в среднем в месяц. При этом для масштабирования системы в будущем, фронтэдом вешаем Nginx настраивая его как балансировщик по 443 порту, а бакэндом апач на этом же сервере, в случае роста компании добавляем еще один сервер с апачем и строчку в конфигурацию Nginx.
Если же все вешаем на 1 сервер то там просто виндовый апач, с опубликованной БД. И вот именно для БД я бы позаботился не только процессором а именно SSD причем желательно разнести данные логи и tempdb на разные диски.
И не тратил бы деньги на сервер терминалов и терминальные лицензии и по 700 метров ОЗУ на каждого пользователя, мне кажется это в современных реалиях просто расточительство ресурсов и не достаточная глубина знаний предмета.
Это при условии, что ваша конфигурация через веб работает как надо. Что, вообще говоря, не всегда правда (банально, сканер ШК подключить не получится, как и запустить конфигурацию, которая с «вебом» не другит).
Современные конфигурации типовые уже поддерживают все из коробки. Ведь у нас идет речь о внедрении продукта, а не переноса существующей инфраструктуры.
«Современные типовые конфигурации» — да, может и так (но надо тестировать), но только если вы под словом «внедрение» подразумеваете просто установить и отдать людям. Если в планах модификации — надо уже внимательно все планировать, чтобы веб работал.
Разве есть уже драйвера для фискальных регистраторов, например ШТРИХ, для печати из веба? Просто тоже думали отказаться от терминальных серверов в пользу веб
Это возможно, как вариант. Однако надо понимать, что описывается задача создания именно терминального сервера. Когда у пользователей тонкие клиенты, а не случаи если публикуется база в WEB или настраивается RemoteApp. Например мы часто сталкивались с требованием клиентов — вынести всю работу в датацентр, чтобы в офисе был шлюз, и тонкие клиенты. Или есть клиенты, которые хотят контролировать все действия пользователей, чтобы они на локальных машинах ничего делать не могли. Таких задач много и в одной статье их не охватить. Были и гибридные варианты, когда офис работает в RemoteApp а филиалы с тонких клиентов.
Абсолютно верно, в том случае, если конечный сервис только 1С.
Еще очень важный момент в нормальной работе 1С — это частота процессора на сервере 1С.
Еще очень важный момент в нормальной работе 1С — это частота процессора на сервере 1С.
А с количеством ядер не промахнулись? Насколько я знаю, при выполнении ресурсоёмких операций, клиент 1С будет всё ядро вешать.
Да и другие приложения при различных сбоях могут поступать аналогично.
Да и другие приложения при различных сбоях могут поступать аналогично.
>Абсолютно верно, в том случае, если конечный сервис только 1С.
Это то с чего и надо было начинать статью. Т.е. терминальный сервер вам нужен НЕ ДЛЯ 1С.
* Для именно 1С теминальный сервер бесполезен (в случае использования тонкого клиента конечно), только лишние траты на лицензии MS
* В случае экономии и размещения сервера 1С и MSSQL на одной машине появляется очень приятный бонус в виде подключения через SharedMemory с заметным ускорением.
* Для 1С критична к частоте процессора (это действительно важно), т.к. не параллелит один процесс. Но многоядерность нужна в случае значительного числа активных пользователей. Так что для небольших групп очень выгодно выглядит серия Е3.
* А вот MSSQL гораздо чаще может параллелить один запрос на несколько процессоров. Как итог не забываем про существование cpu affinity.
* Не стоит забывать что в случае сложных отчётов на СКД идёт обработка локально во временных файлах на стороне сервера 1С. Поэтому желательно выносить данные кластера 1С на отдельный дисковый том (по умолчанию он на системном разделе).
* Про оптимизацию самого mssql отдельные трактаты и очень важно их не игнорировать.
*!*! Самое главное в производительности 1С — это сам код конфигураций. Никакие танцы вокруг потимизации «железа» не заменят голову программисту, который ВНЕЗАПНО решит выбрать по сотне тысяч записей из десятка таблиц потом их объединить (в экстремальных случаях без джойна даже) и только после этого наложить фильтры.
PS: Советовать смотреть на серию 56** как-то очень странно в 2016 году
Это то с чего и надо было начинать статью. Т.е. терминальный сервер вам нужен НЕ ДЛЯ 1С.
* Для именно 1С теминальный сервер бесполезен (в случае использования тонкого клиента конечно), только лишние траты на лицензии MS
* В случае экономии и размещения сервера 1С и MSSQL на одной машине появляется очень приятный бонус в виде подключения через SharedMemory с заметным ускорением.
* Для 1С критична к частоте процессора (это действительно важно), т.к. не параллелит один процесс. Но многоядерность нужна в случае значительного числа активных пользователей. Так что для небольших групп очень выгодно выглядит серия Е3.
* А вот MSSQL гораздо чаще может параллелить один запрос на несколько процессоров. Как итог не забываем про существование cpu affinity.
* Не стоит забывать что в случае сложных отчётов на СКД идёт обработка локально во временных файлах на стороне сервера 1С. Поэтому желательно выносить данные кластера 1С на отдельный дисковый том (по умолчанию он на системном разделе).
* Про оптимизацию самого mssql отдельные трактаты и очень важно их не игнорировать.
*!*! Самое главное в производительности 1С — это сам код конфигураций. Никакие танцы вокруг потимизации «железа» не заменят голову программисту, который ВНЕЗАПНО решит выбрать по сотне тысяч записей из десятка таблиц потом их объединить (в экстремальных случаях без джойна даже) и только после этого наложить фильтры.
PS: Советовать смотреть на серию 56** как-то очень странно в 2016 году
Делал подобный проект на двух серверах dell r420 для отказоустойчивости, это было основное требование. Дополнительно там же работала IP АТС на базе elastix. Итого на 2х серверах 2*2640v2/32Гб/2*ssd 240Гб: домен, терминальный сервер, сервер 1С с базой mssql, ip атс. В случае отказа любого сервера работа останавливается максимум на минуту. Бекап на внешнее сетевое хранилище.
А Вам не страшно виртуалить DC и размещать на той же хостовой машине?
Какие вы видите риски?
Невозможность решить проблему удалённо, если что не так с машиной DC. Да и по производительности — виртуализация медленнее.
Да и принцип «не класть все яйца в одну корзину» — увеличивать количество точек отказа, чтобы не накрылось сразу всё (хотя репликация на уровне виртуальных машин спасает, да).
Да и принцип «не класть все яйца в одну корзину» — увеличивать количество точек отказа, чтобы не накрылось сразу всё (хотя репликация на уровне виртуальных машин спасает, да).
А что такого в КД на виртуалке? Виндовый кластер научился работать при их недоступности в 2012.
Нежелание КД в виртуалке — пережиток прошлого. Ну а если забыл отключить синхронизацию времени гостя с хостом через VM-tools, то ССЗО.
Там ещё пачка продвинутых настроек, но с 2012 жить стало намного проще.
Я живу с vSphere и в ус не дую :)
Как раз в vSphere настроек синхронизации больше одной и без их отключения при определённом везении можно развалить аутентификацию в домене.
А не поделитесь информацией об этих настройках?
Выше ссылка и где-то на Хабре был пост про это.
Ещё можно почитать талмуд про синхронизацию и бест практисы для гостевых ОС:
Timekeeping in VMware Virtual Machines
Timekeeping best practices for Windows, including NTP
Timekeeping best practices for Linux guests
Ещё можно почитать талмуд про синхронизацию и бест практисы для гостевых ОС:
Timekeeping in VMware Virtual Machines
Timekeeping best practices for Windows, including NTP
Timekeeping best practices for Linux guests
Ещё в Windows Server 2012 появился VM-Generation-ID (нужна поддержка со стороны гипервизора), который меняется при восстановлении из снепшота и КД сваливается в DSRM чтобы избежать потери данных.
Я так и не понял, это довод «за» КД на виртуалке или «против»?
Или это просто предупреждение — не использовать снэпшоты для КД?
Или это просто предупреждение — не использовать снэпшоты для КД?
Наверное «за», так как стало чуть сложнее выстрелись себе в ногу.
Но ведь и возможность выстрела появляется лишь на виртуалке, разве нет?
То есть, с одной стороны — добавляется возможность налажать, а с другой — защита от такого чудачества с остановкой роли КД. Да, целостность данных остаётся, но и работа простаивает в итоге.
Понятное дело, что правильным выходом будет использование правильных средств бэкапирования КД и АД, но в данном примере виртуалка выглядит проигрышнее, на мой взгляд.
То есть, с одной стороны — добавляется возможность налажать, а с другой — защита от такого чудачества с остановкой роли КД. Да, целостность данных остаётся, но и работа простаивает в итоге.
Понятное дело, что правильным выходом будет использование правильных средств бэкапирования КД и АД, но в данном примере виртуалка выглядит проигрышнее, на мой взгляд.
Сначала автор пишет, что хочет по-дешевле все сделать, но потом пошло про MSSQL и винду? Тут постгрес и линукс, а не мсскл и винда…
Та ну блин, и не надоело вечно про это вспоминать?
Лицензия скуля+винды будет значительно дешевле, чем нанять адекватного спеца, который шарит в линуксе и постгри.
1с под виндой — работает быстрее чем под линуксом, и на скуле — из коробки, тоже работает быстрее.
Те уровни изменений, которые требуется сделать в постгри, что бы он начал работать на уровне с sql — очень высоки. Т.е. необходим спец, не дешевый, и вы постгри никогда не настроите за 10 минут, та даже за 1 день. Так как с ним необходимо воевать постоянно, вы должны его подстраивать под реальные процессы компании (количество документов, масштабы отчетов и проче-прочее-прочее).
Т.е. минимум на пол года. Это раз.
Два — спецам необходимого уровня — ваще не в кайф сидеть и ковырять 1С, получая гневные отзывы от бабушек из бухгатерии, за то, что медленно что-то работает и вообще — почини и заправь ей принтер.
Отсюда вывод — мс скуль + винда, это единственное что имеет смысл ставить компанием со штатом до 100 человек.
А вот если у вас 200 человек, несколько баз и т.д., вот тогда да, тогда другая песня.
И если вы сейчас скажите, что вы постгри настроили за 10 минут и все летает, я, и не только я — просто не поверю.
Лицензия скуля+винды будет значительно дешевле, чем нанять адекватного спеца, который шарит в линуксе и постгри.
1с под виндой — работает быстрее чем под линуксом, и на скуле — из коробки, тоже работает быстрее.
Те уровни изменений, которые требуется сделать в постгри, что бы он начал работать на уровне с sql — очень высоки. Т.е. необходим спец, не дешевый, и вы постгри никогда не настроите за 10 минут, та даже за 1 день. Так как с ним необходимо воевать постоянно, вы должны его подстраивать под реальные процессы компании (количество документов, масштабы отчетов и проче-прочее-прочее).
Т.е. минимум на пол года. Это раз.
Два — спецам необходимого уровня — ваще не в кайф сидеть и ковырять 1С, получая гневные отзывы от бабушек из бухгатерии, за то, что медленно что-то работает и вообще — почини и заправь ей принтер.
Отсюда вывод — мс скуль + винда, это единственное что имеет смысл ставить компанием со штатом до 100 человек.
А вот если у вас 200 человек, несколько баз и т.д., вот тогда да, тогда другая песня.
И если вы сейчас скажите, что вы постгри настроили за 10 минут и все летает, я, и не только я — просто не поверю.
На самом деле все проще.
Для небольших баз в общем то нет особой разницы Postgres или SQL.
Для больших и нагруженных все равно нужно уметь настраивать и Postgres и SQL и специалисты нужны с соответствующими уровнями.
Установка Postgres (https://postgrespro.ru/products/1c_build) в общем то простая не сложней SQL (само собой для Linux администратора).
Насчет спецов, если это решение для бизнеса то в и для Win и для Nix нужны толковые админы, то что в Win порог входа ниже я бы записал в недостатки.
В том виде в котором описано в статье использовать Win платформу есть смысл только если админить всю эту систему будет тот же самый человек который будет сопровождать и дорабатывать 1С (для небольших компаний и/или филиалов это нормально).
Большинство 1С ников (включая и меня) «win only» так как 1С долгие годы была так же «win only» и только последнее время развернулась в сторону *NIX, в итоге специалистов по 1С умеющих работать с чем то кроме MSSQL+WIN довольно мало.
*по поводу того что спецам «ваще не в кайф сидеть и ковырять 1С», на мой взгляд это очень спорное утверждение. Если 1С это сердце бизнеса (а так часто бывает) то что там «в кайф спецам» владельцев бизнеса мало волнует. По мне так направление Linux + 1C очень перспективное.
Для небольших баз в общем то нет особой разницы Postgres или SQL.
Для больших и нагруженных все равно нужно уметь настраивать и Postgres и SQL и специалисты нужны с соответствующими уровнями.
Установка Postgres (https://postgrespro.ru/products/1c_build) в общем то простая не сложней SQL (само собой для Linux администратора).
Насчет спецов, если это решение для бизнеса то в и для Win и для Nix нужны толковые админы, то что в Win порог входа ниже я бы записал в недостатки.
В том виде в котором описано в статье использовать Win платформу есть смысл только если админить всю эту систему будет тот же самый человек который будет сопровождать и дорабатывать 1С (для небольших компаний и/или филиалов это нормально).
Большинство 1С ников (включая и меня) «win only» так как 1С долгие годы была так же «win only» и только последнее время развернулась в сторону *NIX, в итоге специалистов по 1С умеющих работать с чем то кроме MSSQL+WIN довольно мало.
*по поводу того что спецам «ваще не в кайф сидеть и ковырять 1С», на мой взгляд это очень спорное утверждение. Если 1С это сердце бизнеса (а так часто бывает) то что там «в кайф спецам» владельцев бизнеса мало волнует. По мне так направление Linux + 1C очень перспективное.
Никто не говорит, что у SQL громадное приимущество, хотя у него таки есть ряд приимуществ, который в большей мере накоплен благодаря тому, что 1С таки долго только на нем и была.
Я в своей практике не встречал чистых юникс андминов, у которых история не запятнана виндой, т.е. обычно человек вначале становится хоть каким то спецом в винде, и потом осознано переходит на никсы.
Т.е. намного проще и быстрее найти спецов именно на винде.
Отсюда следуюет комментарий для этой фразы:
Все верно, только когда админа никсов задалбывает чинить принтеры и прочее, он сваливает, и вот тут уже может дойти до того, что бизнес просто встанет, так как другого никс андмина — найти уже достаточно сложно, и уж точно не быстро.
Та и франчи тут не помошники, так как чаще всего от них такие сразу и сбегают.
Буквально недавно звонили и просили помочь поднять бекап с постгри, так как админ уволился, пол года никто не следил за сервером, ибо тупо даже не знали как зайти туда и что смотреть. И все. Бизнес встал. Тут можно долго спорить, что сами олени и не нашли, но признаются честно — искали, но когда слышали цены никс админов — решили послать все нафиг и купить винду и скуль, так как за 3 года оно просто окупается. Ибо вин админом может быть тот же 1Сник, за те же деньги, по сути.
Я в своей практике не встречал чистых юникс андминов, у которых история не запятнана виндой, т.е. обычно человек вначале становится хоть каким то спецом в винде, и потом осознано переходит на никсы.
Т.е. намного проще и быстрее найти спецов именно на винде.
Отсюда следуюет комментарий для этой фразы:
*по поводу того что спецам «ваще не в кайф сидеть и ковырять 1С», на мой взгляд это очень спорное утверждение. Если 1С это сердце бизнеса (а так часто бывает) то что там «в кайф спецам» владельцев бизнеса мало волнует.
Все верно, только когда админа никсов задалбывает чинить принтеры и прочее, он сваливает, и вот тут уже может дойти до того, что бизнес просто встанет, так как другого никс андмина — найти уже достаточно сложно, и уж точно не быстро.
Та и франчи тут не помошники, так как чаще всего от них такие сразу и сбегают.
Буквально недавно звонили и просили помочь поднять бекап с постгри, так как админ уволился, пол года никто не следил за сервером, ибо тупо даже не знали как зайти туда и что смотреть. И все. Бизнес встал. Тут можно долго спорить, что сами олени и не нашли, но признаются честно — искали, но когда слышали цены никс админов — решили послать все нафиг и купить винду и скуль, так как за 3 года оно просто окупается. Ибо вин админом может быть тот же 1Сник, за те же деньги, по сути.
Скажем так, все в мире относительно.
К примеру, наша база (~17 ГБ, 25 пользователей) в MS SQL работает довольно сносно на машине E5620x2, 16 GB RAM (будет 24 осенью). Сервер 1С: Предприятия на этой же машине. Второй процессор для наших нужд никуда не упирается, а вот SAS HDD хотим поменять на SSD.
Ради интереса мы поднимали нашу базу на машине с Потстгрю, первоначальная настройка делалась одним автоматическим скриптом, работало медленнее скульного и даже немного медленнее файл-серверного варианта, но если хочется сэкономить на лицензии, то потерпеть можно.
А вообще 1С просто медленная. Нет, она нереально медленная. И тут уже ничем не помочь. То, что делают другие ЯПы в разы быстрее, а компилируемые вообще за секунды, 1С-ка делает секундами и даже минутами.
Хотя сделать еще хуже — запросто: слабое железо, кривые запросы/отчеты (как правило доработки), неадекватная настройка MS SQL/другой СУБД.
К примеру, наша база (~17 ГБ, 25 пользователей) в MS SQL работает довольно сносно на машине E5620x2, 16 GB RAM (будет 24 осенью). Сервер 1С: Предприятия на этой же машине. Второй процессор для наших нужд никуда не упирается, а вот SAS HDD хотим поменять на SSD.
Ради интереса мы поднимали нашу базу на машине с Потстгрю, первоначальная настройка делалась одним автоматическим скриптом, работало медленнее скульного и даже немного медленнее файл-серверного варианта, но если хочется сэкономить на лицензии, то потерпеть можно.
А вообще 1С просто медленная. Нет, она нереально медленная. И тут уже ничем не помочь. То, что делают другие ЯПы в разы быстрее, а компилируемые вообще за секунды, 1С-ка делает секундами и даже минутами.
Хотя сделать еще хуже — запросто: слабое железо, кривые запросы/отчеты (как правило доработки), неадекватная настройка MS SQL/другой СУБД.
Вы во многом правы, но да, постгря настраивается за 10 минут, если знаешь. Для начала просто берем pgtune + правка некоторых настроек, конечно нужно знать каких. По собственной инструкции сервер на дебиане 8 х64 + 1с х32 + ПГ 64 9.4.8 от ПостгресПро я подниму за полчаса с нуля, включая установку ОС. При чем уже с настройками. Не уверен нужна ли такая небольшая инструкция на хабре.
\\ «для небольшой организации на 25-30 пользователей»
Только мне кажется что предлагаемое железо выходит за рамки небольшой организации.
\\ это лишь один из примеров недорогого внедрения 1С
Недорогого? Видимо я совсем отстал от жизни.
Только мне кажется что предлагаемое железо выходит за рамки небольшой организации.
\\ это лишь один из примеров недорогого внедрения 1С
Недорогого? Видимо я совсем отстал от жизни.
На самом деле, ценник железа и лицензий просто меркнет по сравнению с отраслевым решением+доработкой (тем самым «внедрением») — такому бизнесу пытаются продать внедрение вместо коробки — под потребности бизнеса. Из-за курса сейчас это не так сильно бросается в глаза, но раньше это было именно так. Это выливается в проекты, которые тянутся от нескольких месяцев до нескольких лет, а суммы поражают шестью нулями. Причем, вместо 1С: Предприятия с доработками можно вписать MS Dynamics AX (ERP), Sharepoint, SAP или любого другого монстра, внедренцы которого, если не разорят, то изрядно облегчат кошельки предприятия-заказчика.
Планирую делать ферму виртуалок. Пользовательские виртуалки будут на linux и windows для использования 1с, офисного пакета и браузера.
Писать статью?
Писать статью?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как выбрать сервер для 1С, SQL и терминалов