Наверное, каждому сисадмину хоть раз в жизни приходилось решать задачи внедрения продуктов 1С, развёртывания SQL-баз и создания терминальных серверов. К нам регулярно обращаются заказчики с просьбой подобрать сервер под какую-нибудь из этих задач, а то и под все сразу. Здесь есть три возможных подхода, и мы хотим поделиться своим опытом в подборе оборудования, возможно, кому-то он сильно облегчит жизнь.
Основным критерием при выборе серверов для организации является набор сервисов, которые будут использоваться, и количество пользователей.
Сегодня мы рассмотрим выбор серверного «железа» для небольшой организации на 25-30 пользователей, с распределенной инфраструктурой (торговые точки, склад), которой требуются терминальный сервер и программа «1С: Предприятие». Этими сервисами будут пользоваться все сотрудники.
Большинство малых компаний, для удешевления стоимости оборудования, предпочитают минимизировать количество приобретаемой техники и просят администраторов «впихнуть» все запрошенные ими сервисы в один физический сервер. Желание понятное и простительное, но тут «есть нюансы».
Можно организовать терминальный сервер и использовать там файловую версию 1С, но при таком количестве пользователей компания-разработчик рекомендует переходить на клиент-серверный вариант. Поэтому нам потребуется еще сервер под «1С: Предприятие» и сервер баз данных. Уточним сразу, что организовать терминальный сервер, сервер SQL и сервер 1С на одной операционной системе возможно, но, с точки зрения безопасности и стабильности работы сервисов, это крайне не рекомендуется. А если всё-таки очень хочется использовать один физический сервер для всех трёх ролей, то рекомендуем использовать виртуализацию, например, VMWare ESXi или Hyper-V.
Таким образом, вырисовывается три варианта:
- Один сервер с файловой 1С. Плохой вариант, далее мы его рассматривать не будем.
- Один сервер с двумя виртуальными машинами.
- Два физических сервера, один терминальный, второй с БД и 1С.
Для решения этих задач можно предложить следующую конфигурацию серверов:
В случае с одним физическим сервером мы остановили выбор на Dell R710, с двумя шестиядерными процессорами Xeon X5650, 64 Гб оперативной памяти и шестью дисками: два SSD в RAID 1 и четыре SAS-диска в RAID 10.
В случае с двумя физическими серверами мы остановили выбор на таких конфигурациях:
- Терминальный сервер: IBM x3550 M3 с одним процессором Xeon E5620, 32 Гб оперативной памяти и двумя SSD в RAID 1, с дополнительной сетевой картой на два гигабитных интерфейса. У этого сервера также есть богатые возможности для апгрейда, так как он двухпроцессорный, имеет 18 слотов под модули памяти и поддерживает до 288 Гб ОЗУ.
- Сервер баз данных: IBM x3250 M5 с одним процессором Xeon E3-1220v3, 16 Гб ОЗУ, дополнительным RAID-контроллером SAS/SATA, четырьмя SAS-дисками в RAID 10, с дополнительной сетевой картой на 2 гигабитных интерфейса.
Почему мы выбрали именно такие конфигурации? Для ответа на этот вопрос давайте подсчитаем, что нам нужно для обеспечения комфортной работы пользователей в нашей небольшой организации на 25-30 сотрудников. Чтобы не было недопонимания: это лишь один из примеров недорогого внедрения 1С, и во многих случаях целесообразнее выбрать другие конфигурации.
Процессор
С точки зрения процессорного времени терминальные сессии занимают не очень большую долю. По опыту внедрения терминальных решений в различных организациях, для поддержания комфортной работы 30-ти пользователей достаточно будет 4-6 физических ядер процессора, по одному ядру на 6-8 сессий. Для небольшой базы SQL-серверу понадобится одно ядро. Но мы будем ориентироваться на расширение базы в будущем (или увеличение количества баз) и возьмем два ядра на SQL.
Для сервера «1С: Предприятие» важно не столько количество ядер, сколько их тактовая частота и частота шины. Поэтому заложим еще два ядра на сервер 1С.
И не забудем, что в случае использовании виртуализации одно или два ядра нам пригодится для обеспечения работы хостовой операционной системы.
Итого у нас получается:
- для сервера с двумя виртуальными машинами нужно 12 физических ядер. Можно и меньше, но всегда должен оставаться запас по мощности. Сервер с двумя шестиядерными процессорами подходит для этого идеально.
- для терминального сервера достаточно одного процессора Xeon E5620 с шестью ядрами, для сервера баз данных — процессора Xeon E3-1220v3 с четырьмя ядрами.
Оперативная память
Сначала посмотрим, сколько нужно оперативной памяти под сервисы:- Операционная система Windows Server только под себя требует 2 Гб ОЗУ.
- Для SQL и небольшой базы 1С достаточно будет 4-6 Гб ОЗУ.
- Сервер «1С: Предприятие» требует еще 2-3 Гб ОЗУ.
- Рассчитываем, что каждому пользователю потребуется 700 Мб ОЗУ в терминальной сессии, тогда на 30 пользователей потребуется 21 Гб.
Теперь применим это к нашим вариантам.
- Для одного сервера с двумя виртуальными машинами нужно около 40 Гб ОЗУ.
- Для терминального сервера достаточно будет 24 Гб или 32 Гб ОЗУ (возьмем с запасом, предполагая будущее расширение). Для сервера с базами данных нужно не менее 8 Гб, но это «впритык», поэтому 16 Гб с запасом. Память сейчас — один из самых дешевых компонентов сервера.
Дисковая подсистема
Это традиционное бутылочное горлышко многих систем. Правильный выбор жестких дисков очень важен для обеспечения быстродействия серверов. При работе 1С с базой SQL происходит множество операций чтения/записи в секунду (IOPS). Если пользователи работают на терминальном сервере с тонких клиентов (т.е. полноценно используют терминальный сервер как рабочую среду), это сильно нагружает дисковую систему сервера. Например, 30 пользователей терминального сервера на RAID 1, SATA 3 Гбит/с, с дисками WD Velociraptor чувствуют себя некомфортно при работе с почтой и активном сёрфинге в интернете. Для терминальных серверов мы рекомендуем использовать SSD-накопители. Для серверов баз данных — SAS-диски, собранные в отказоустойчивые массивы.Помимо накопителей, следует уделить внимание и дисковому контроллеру. Современные серверы имеют на борту довольно хорошие контроллеры, например, HP SmartArray и DELL PERC. Однако некорректно будет использовать «набортные» решения при серьёзной нагрузке, когда требуется максимальная производительность. Немного сэкономив, вы легко можете получить мощный сервер, который совершенно не тянет нагрузку. Поэтому контроллер должен быть аппаратным, а не программным, со своей энергонезависимой памятью.
Рассмотрим варианты решения этой задачи.
- Для одного сервера с двумя виртуальными машинами желательно использовать два RAID-массива: на одном будут располагаться файлы виртуальной машины терминального сервера, на втором — файлы виртуальной машины сервера баз данных и «1C: Предприятия». Для создания первого массива лучше всего использовать два SSD-накопителя в RAID 1 (зеркало).
Второй массив лучше создать из четырёх SAS-диска в RAID 10 (зеркало + страйп), но можно и из двух SSD-накопителей в RAID 1. Выбор зависит только от стоимости дисков и модели сервера. - Для двух серверов всё то же самое, только массивы будут разнесены по серверам. На терминальном — RAID 1 из двух SSD, на сервере баз данных — RAID 10.
Один или несколько серверов
Как сказано выше, у небольших организаций довольно велико желание разместить все сервисы на одном сервере. К преимуществам использования одного сервера и виртуализации можно считать более низкое энергопотребление и более гибкое распределение ресурсов между виртуальными машинами. Ну и перенос виртуальных машин, в случае чего, гораздо удобнее, чем перенос физических ОС.
Однако два сервера имеют более широкие возможности по апгрейду. Например, в нашем варианте недорогой IBM x3550 M3 с добавлением еще одного процессора и ОЗУ превращается в
Еще одно «узкое место» в нашем случае, которое необходимо учитывать при выборе двух физических серверов, это обмен данными между ними по сети. У виртуальных серверов обмен данными идёт через виртуальный коммутатор. Здесь же, для увеличения пропускной способности сети, можно установить в каждый сервер по сетевой карте с двумя гигабитными интерфейсами, которые можно агрегировать между собой и напрямую соединить оба сервера агрегированными 2-х гигабитными линками. Или же использовать сетевые карты с SPF+ 10GBASE, но это дорогое удовольствие.
Запас по мощности
При расчетах и выборе сервера необходимо принимать во внимание пиковые нагрузки. Также обязательно нужно помнить, что база данных будет только «пухнуть», объёмы данных на терминальном сервере будут расти, а количество пользователей может увеличиться. Многие предприятия экономят на запасе мощности и через полгода-год сталкиваются с перебоями в работе и жалобами пользователей. Это тот случай, когда чрезмерная экономия приводит к новым затратам в будущем — скупой платит дважды. Выбранные нами варианты рассчитаны с запасом мощности и возможностью апгрейда. Учтено, что в DELL R710 можно будет добавить еще два жестких диска и ОЗУ, а также заменить процессоры на более производительные.
Так что, если вам потребуется расширение, или количество сервисов увеличится, то тут есть большие перспективы, а существующие серверы еще долгое время будут эффективно выполнять свои задачи. Возможно, через год нам неожиданно потребуется увеличить количество пользователей в два раза, до 60 человек? Пожалуйста.
Если вы использовали один сервер DELL R710, то можно докупить недорогой IBM x3550 M3, поднять на нём гипервизор, перенести туда виртуальную машину с БД и 1С-сервером, а на DELL-е все ресурсы отдать виртуальной машине с терминалом. Это будет быстро, и не потребуется «всё выкинуть и купить новое».
Если же вы использовали два сервера IBM, то x3550 M3 с добавлением второго процессора и небольшого количества ОЗУ превращается из середнячка в довольно мощную машину. А в x3250 M5 можно обновить процессор с E3-1220v3 до E3-1285v3.
Заключение
Конечно, предложенные конфигурации — далеко не единственные варианты оборудования, например, для внедрения того же 1С. Тут очень многое зависит от текущей инфраструктуры, уровня нагрузки и её увеличения в будущем, а также бюджета. Поэтому всегда можно подобрать либо похожие модели серверов, либо более мощные и дорогие.
Комментарии (50)
hamnsk
19.07.2016 10:51+1Эм считаю что терминальный сервер это лишняя трата денег, если в качестве конечного сервиса это только 1С предприятие, гораздо дешевле и разумней поступить иначе:
1. Все на одном сервере, для доступа клиентов используем Apache под Windows
2. Два сервера, 1с ОС Linux для доступа клиентов к бд, второй это наш SQL + 1C Предприятие.
Конкретизировать конфигурации я не буду, для доступа 50 человек в базу нам хватит сервера с 2 ГБ ОЗУ, самым медленным диском и тд, для этих целей можно вообще арендовать сервер в облаке за 500 рублей в среднем в месяц. При этом для масштабирования системы в будущем, фронтэдом вешаем Nginx настраивая его как балансировщик по 443 порту, а бакэндом апач на этом же сервере, в случае роста компании добавляем еще один сервер с апачем и строчку в конфигурацию Nginx.
Если же все вешаем на 1 сервер то там просто виндовый апач, с опубликованной БД. И вот именно для БД я бы позаботился не только процессором а именно SSD причем желательно разнести данные логи и tempdb на разные диски.
И не тратил бы деньги на сервер терминалов и терминальные лицензии и по 700 метров ОЗУ на каждого пользователя, мне кажется это в современных реалиях просто расточительство ресурсов и не достаточная глубина знаний предмета.dmitry_ch
19.07.2016 11:08Это при условии, что ваша конфигурация через веб работает как надо. Что, вообще говоря, не всегда правда (банально, сканер ШК подключить не получится, как и запустить конфигурацию, которая с «вебом» не другит).
hamnsk
19.07.2016 13:10Современные конфигурации типовые уже поддерживают все из коробки. Ведь у нас идет речь о внедрении продукта, а не переноса существующей инфраструктуры.
dmitry_ch
19.07.2016 13:12«Современные типовые конфигурации» — да, может и так (но надо тестировать), но только если вы под словом «внедрение» подразумеваете просто установить и отдать людям. Если в планах модификации — надо уже внимательно все планировать, чтобы веб работал.
EgorLyutov
20.07.2016 07:22Разве есть уже драйвера для фискальных регистраторов, например ШТРИХ, для печати из веба? Просто тоже думали отказаться от терминальных серверов в пользу веб
speaktr
19.07.2016 15:21Это возможно, как вариант. Однако надо понимать, что описывается задача создания именно терминального сервера. Когда у пользователей тонкие клиенты, а не случаи если публикуется база в WEB или настраивается RemoteApp. Например мы часто сталкивались с требованием клиентов — вынести всю работу в датацентр, чтобы в офисе был шлюз, и тонкие клиенты. Или есть клиенты, которые хотят контролировать все действия пользователей, чтобы они на локальных машинах ничего делать не могли. Таких задач много и в одной статье их не охватить. Были и гибридные варианты, когда офис работает в RemoteApp а филиалы с тонких клиентов.
ArthurLeighAllen
19.07.2016 11:06Абсолютно верно, в том случае, если конечный сервис только 1С.
Еще очень важный момент в нормальной работе 1С — это частота процессора на сервере 1С.
LoadRunner
19.07.2016 11:11А с количеством ядер не промахнулись? Насколько я знаю, при выполнении ресурсоёмких операций, клиент 1С будет всё ядро вешать.
Да и другие приложения при различных сбоях могут поступать аналогично.ArthurLeighAllen
19.07.2016 11:15По практике для данной задачи достаточно с запасом. И конечно, есть различные «но»
AMaxKaluga
19.07.2016 12:37>Абсолютно верно, в том случае, если конечный сервис только 1С.
Это то с чего и надо было начинать статью. Т.е. терминальный сервер вам нужен НЕ ДЛЯ 1С.
* Для именно 1С теминальный сервер бесполезен (в случае использования тонкого клиента конечно), только лишние траты на лицензии MS
* В случае экономии и размещения сервера 1С и MSSQL на одной машине появляется очень приятный бонус в виде подключения через SharedMemory с заметным ускорением.
* Для 1С критична к частоте процессора (это действительно важно), т.к. не параллелит один процесс. Но многоядерность нужна в случае значительного числа активных пользователей. Так что для небольших групп очень выгодно выглядит серия Е3.
* А вот MSSQL гораздо чаще может параллелить один запрос на несколько процессоров. Как итог не забываем про существование cpu affinity.
* Не стоит забывать что в случае сложных отчётов на СКД идёт обработка локально во временных файлах на стороне сервера 1С. Поэтому желательно выносить данные кластера 1С на отдельный дисковый том (по умолчанию он на системном разделе).
* Про оптимизацию самого mssql отдельные трактаты и очень важно их не игнорировать.
*!*! Самое главное в производительности 1С — это сам код конфигураций. Никакие танцы вокруг потимизации «железа» не заменят голову программисту, который ВНЕЗАПНО решит выбрать по сотне тысяч записей из десятка таблиц потом их объединить (в экстремальных случаях без джойна даже) и только после этого наложить фильтры.
PS: Советовать смотреть на серию 56** как-то очень странно в 2016 годуArthurLeighAllen
19.07.2016 12:47Спасибо, за комментарий и важные уточнения.
Конечно, можно использовать более новое оборудование. А в некоторых компаниях это обязательное требование.
Сейчас достаточно много сторонников refurbished решений. И данное оборудование вполне справится с задачами.
xtelekom
19.07.2016 13:36Делал подобный проект на двух серверах dell r420 для отказоустойчивости, это было основное требование. Дополнительно там же работала IP АТС на базе elastix. Итого на 2х серверах 2*2640v2/32Гб/2*ssd 240Гб: домен, терминальный сервер, сервер 1С с базой mssql, ip атс. В случае отказа любого сервера работа останавливается максимум на минуту. Бекап на внешнее сетевое хранилище.
LoadRunner
19.07.2016 15:02А Вам не страшно виртуалить DC и размещать на той же хостовой машине?
xtelekom
19.07.2016 15:35Какие вы видите риски?
LoadRunner
19.07.2016 16:03Невозможность решить проблему удалённо, если что не так с машиной DC. Да и по производительности — виртуализация медленнее.
Да и принцип «не класть все яйца в одну корзину» — увеличивать количество точек отказа, чтобы не накрылось сразу всё (хотя репликация на уровне виртуальных машин спасает, да).xtelekom
19.07.2016 16:22удаленное управление сервером есть, можно под локальной учеткой зайти если что. И серверов 2, контроллеров тоже 2 (не 1 на 2 виртуалках)
LoadRunner
19.07.2016 16:30А с точки зрения безопасности это не кажется плохим решением — удалённый доступ к серверу под локальной учётной записью?
P. S. Если что, я не оспариваю решение, а просто любопытствую.xtelekom
20.07.2016 08:26Он же в отдельной management сети, физически выделена. А уж как вы доступ настроите от вас зависит :)
navion
19.07.2016 15:42А что такого в КД на виртуалке? Виндовый кластер научился работать при их недоступности в 2012.
yosemity
19.07.2016 16:58Нежелание КД в виртуалке — пережиток прошлого. Ну а если забыл отключить синхронизацию времени гостя с хостом через VM-tools, то ССЗО.
navion
19.07.2016 17:06Там ещё пачка продвинутых настроек, но с 2012 жить стало намного проще.
yosemity
19.07.2016 17:13Я живу с vSphere и в ус не дую :)
navion
19.07.2016 17:38+1Как раз в vSphere настроек синхронизации больше одной и без их отключения при определённом везении можно развалить аутентификацию в домене.
yosemity
19.07.2016 17:47Да я собственно не к выбору гипервизора, а вообще о том, что смысла выделять под КД отдельную железку нет и опасения по поводу заморочек со временем идут от неверной настройки.
LoadRunner
20.07.2016 08:49А не поделитесь информацией об этих настройках?
navion
20.07.2016 14:13Выше ссылка и где-то на Хабре был пост про это.
Ещё можно почитать талмуд про синхронизацию и бест практисы для гостевых ОС:
Timekeeping in VMware Virtual Machines
Timekeeping best practices for Windows, including NTP
Timekeeping best practices for Linux guests
navion
21.07.2016 13:25Ещё в Windows Server 2012 появился VM-Generation-ID (нужна поддержка со стороны гипервизора), который меняется при восстановлении из снепшота и КД сваливается в DSRM чтобы избежать потери данных.
LoadRunner
21.07.2016 13:51Я так и не понял, это довод «за» КД на виртуалке или «против»?
Или это просто предупреждение — не использовать снэпшоты для КД?navion
21.07.2016 14:03Наверное «за», так как стало чуть сложнее выстрелись себе в ногу.
LoadRunner
21.07.2016 14:16Но ведь и возможность выстрела появляется лишь на виртуалке, разве нет?
То есть, с одной стороны — добавляется возможность налажать, а с другой — защита от такого чудачества с остановкой роли КД. Да, целостность данных остаётся, но и работа простаивает в итоге.
Понятное дело, что правильным выходом будет использование правильных средств бэкапирования КД и АД, но в данном примере виртуалка выглядит проигрышнее, на мой взгляд.
guglez
19.07.2016 18:57+2Сначала автор пишет, что хочет по-дешевле все сделать, но потом пошло про MSSQL и винду? Тут постгрес и линукс, а не мсскл и винда…
Melex
19.07.2016 19:32Та ну блин, и не надоело вечно про это вспоминать?
Лицензия скуля+винды будет значительно дешевле, чем нанять адекватного спеца, который шарит в линуксе и постгри.
1с под виндой — работает быстрее чем под линуксом, и на скуле — из коробки, тоже работает быстрее.
Те уровни изменений, которые требуется сделать в постгри, что бы он начал работать на уровне с sql — очень высоки. Т.е. необходим спец, не дешевый, и вы постгри никогда не настроите за 10 минут, та даже за 1 день. Так как с ним необходимо воевать постоянно, вы должны его подстраивать под реальные процессы компании (количество документов, масштабы отчетов и проче-прочее-прочее).
Т.е. минимум на пол года. Это раз.
Два — спецам необходимого уровня — ваще не в кайф сидеть и ковырять 1С, получая гневные отзывы от бабушек из бухгатерии, за то, что медленно что-то работает и вообще — почини и заправь ей принтер.
Отсюда вывод — мс скуль + винда, это единственное что имеет смысл ставить компанием со штатом до 100 человек.
А вот если у вас 200 человек, несколько баз и т.д., вот тогда да, тогда другая песня.
И если вы сейчас скажите, что вы постгри настроили за 10 минут и все летает, я, и не только я — просто не поверю.VVizard
21.07.2016 10:46+1На самом деле все проще.
Для небольших баз в общем то нет особой разницы 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 очень перспективное.Melex
21.07.2016 17:19+1Никто не говорит, что у SQL громадное приимущество, хотя у него таки есть ряд приимуществ, который в большей мере накоплен благодаря тому, что 1С таки долго только на нем и была.
Я в своей практике не встречал чистых юникс андминов, у которых история не запятнана виндой, т.е. обычно человек вначале становится хоть каким то спецом в винде, и потом осознано переходит на никсы.
Т.е. намного проще и быстрее найти спецов именно на винде.
Отсюда следуюет комментарий для этой фразы:
*по поводу того что спецам «ваще не в кайф сидеть и ковырять 1С», на мой взгляд это очень спорное утверждение. Если 1С это сердце бизнеса (а так часто бывает) то что там «в кайф спецам» владельцев бизнеса мало волнует.
Все верно, только когда админа никсов задалбывает чинить принтеры и прочее, он сваливает, и вот тут уже может дойти до того, что бизнес просто встанет, так как другого никс андмина — найти уже достаточно сложно, и уж точно не быстро.
Та и франчи тут не помошники, так как чаще всего от них такие сразу и сбегают.
Буквально недавно звонили и просили помочь поднять бекап с постгри, так как админ уволился, пол года никто не следил за сервером, ибо тупо даже не знали как зайти туда и что смотреть. И все. Бизнес встал. Тут можно долго спорить, что сами олени и не нашли, но признаются честно — искали, но когда слышали цены никс админов — решили послать все нафиг и купить винду и скуль, так как за 3 года оно просто окупается. Ибо вин админом может быть тот же 1Сник, за те же деньги, по сути.
Areso
21.07.2016 13:29Скажем так, все в мире относительно.
К примеру, наша база (~17 ГБ, 25 пользователей) в MS SQL работает довольно сносно на машине E5620x2, 16 GB RAM (будет 24 осенью). Сервер 1С: Предприятия на этой же машине. Второй процессор для наших нужд никуда не упирается, а вот SAS HDD хотим поменять на SSD.
Ради интереса мы поднимали нашу базу на машине с Потстгрю, первоначальная настройка делалась одним автоматическим скриптом, работало медленнее скульного и даже немного медленнее файл-серверного варианта, но если хочется сэкономить на лицензии, то потерпеть можно.
А вообще 1С просто медленная. Нет, она нереально медленная. И тут уже ничем не помочь. То, что делают другие ЯПы в разы быстрее, а компилируемые вообще за секунды, 1С-ка делает секундами и даже минутами.
Хотя сделать еще хуже — запросто: слабое железо, кривые запросы/отчеты (как правило доработки), неадекватная настройка MS SQL/другой СУБД.
yosemity
21.07.2016 13:31+1Вы во многом правы, но да, постгря настраивается за 10 минут, если знаешь. Для начала просто берем pgtune + правка некоторых настроек, конечно нужно знать каких. По собственной инструкции сервер на дебиане 8 х64 + 1с х32 + ПГ 64 9.4.8 от ПостгресПро я подниму за полчаса с нуля, включая установку ОС. При чем уже с настройками. Не уверен нужна ли такая небольшая инструкция на хабре.
LESHIY_ODESSA
19.07.2016 20:57\\ «для небольшой организации на 25-30 пользователей»
Только мне кажется что предлагаемое железо выходит за рамки небольшой организации.
\\ это лишь один из примеров недорогого внедрения 1С
Недорогого? Видимо я совсем отстал от жизни.Areso
21.07.2016 13:38На самом деле, ценник железа и лицензий просто меркнет по сравнению с отраслевым решением+доработкой (тем самым «внедрением») — такому бизнесу пытаются продать внедрение вместо коробки — под потребности бизнеса. Из-за курса сейчас это не так сильно бросается в глаза, но раньше это было именно так. Это выливается в проекты, которые тянутся от нескольких месяцев до нескольких лет, а суммы поражают шестью нулями. Причем, вместо 1С: Предприятия с доработками можно вписать MS Dynamics AX (ERP), Sharepoint, SAP или любого другого монстра, внедренцы которого, если не разорят, то изрядно облегчат кошельки предприятия-заказчика.
kondrash055
21.07.2016 10:46Планирую делать ферму виртуалок. Пользовательские виртуалки будут на linux и windows для использования 1с, офисного пакета и браузера.
Писать статью?
LoadRunner
А бэкапы? Или предполагается, что уже есть, куда их делать?
Чем плох вариант с сервером на Xeon 2600 серии для двух виртуалок?
В идеале, отдельные диски надо под систему и отдельно диски под профили терминальных пользователей, базы 1С и прочее добро. С нормальной политикой хранения документов где-нибудь на файловом сервере. Даже в относительно дешёвых вариантах такое доступно (при условии, что файловый сервер уже есть). А если файлового сервера нет — нет и бэкапов?
А ещё, хотелось бы узнать у тех, кто это использует: RAID 1 на SSD стоит этого? Диски не умирают одновременно?
ArthurLeighAllen
Конечно вариантов реализации сервиса 1С очень много. Мы рекомендуем делать бэкапы на отдельную железку, для удобства.
Вариант на Xeon 2600 не плох, но он значительно дороже, а для данной задачи достаточно и Xeon 5600 серии.
Про SSD диски наблюдали практику в дата центрах, когда диски ставили в Raid 1 из разных партий, но возможно это излишние предосторожности.
В практике не встречали чтобы SSD умирали одновременно.
LoadRunner
А в случае выхода из строя отдельных компонентов — не будет потом проблем с поиском замены при использовании устаревающего железа?
Xeon 5600 уже лет 5 не производят же.
ArthurLeighAllen
Данное железо очень ходовое и проблем с ним не будет еще лет 10.
xexex
В основном используем Raid10, ещё не разу не умирали одновременно диски. Хотя стараемся ставить разных производителей (в основном samsung и intel) или разные модели одного производителя.
dronmaxman
Диск в таких масивах (Raid 5,10) чаще всего умирают при ребилде. Проверено практикой.
speaktr
Рассматривается выбор сервера. Для бэкапов можно использовать недорогой NAS, в данном частном случае. На небольшую компанию хватит Synology DS213j с двумя дисками WD RE или RED.
mgis
Год назад сделал RAID0 из 2-х SSD, сервер нормально крутится до сих пор. Насчет RAID1 из SSD ничего сказать не могу.
yosemity
А вы замеряли скорость по сравнению с одним ССД? Какие диски и контроллер используете?