Это взгляд со стороны директора компании, а не ИТ специалиста, без углубления в технические вопросы практической реализации.
Особенностью нашего бизнеса, предопределившей принятые решения, было и остается недопустимость потери данных. Т.е. если небольшие перерывы в работе из-за сбоев ИТ системы нежелательны, но не смертельны, то любая потеря данных – это прекращение бизнеса.
Задача создания своей ИТ системы была нами поставлена и решена в 2011 году. Прошедшее время полностью подтвердило правильность принятых тогда решений.
Основным требованием, как уже отмечено, было: достижение максимально высокой надежности хранения данных компании. Т.е. требовалось, чтобы информация не потерялась никогда (никогда – это конечно только цель).
Основной используемый в компании софт – обычный офисный пакет, 1С бухгалтерия. Что тогда не требовалось, так это: собственный почтовый сервер, IP телефония.
Естественно выбранное решение сравнивалось прежде всего с обычной одноранговой сетью.
В итоге была выбрана структура с терминальным сервером (на ОС WINDOWS), организованного на простом специализированном сервере (не самосборка).
Дополнительные условия:
1. Дисковое хранилище данных с аппаратной реализацией RAID 1 массива.
2. Отдельное сетевое хранилище для резервных копий основных данных, включая слепок ОС на сервере, с автоматическим (по расписанию) архивированием.
3. Для выхода во внешний мир использовался отдельный роутер-коммутатор.
4. Сервер был размещен локально, в том же здании, где располагаются рабочие места сотрудников.
Запуск системы и последующее обслуживание терминального сервера сразу был поручен специализированной ИТ компании. От «своего системного администратора» отказались изначально.
До сотрудников было доведено следующее условие: за сохранность данных на терминальном сервере полностью отвечает компания, а вот за сохранность данных, хранящихся на локальных машинах, компании как раз и не отвечает (за отдельными исключениями).
Это позволило сразу правильно сориентировать людей, где можно и нужно хранить свои данные. И соответственно практически вся работа сотрудников компании проходила и проходит сейчас в терминальном режиме.
За прошедшее время (уже 5 лет) был только один серьезный сбой, когда после смены физического канала выхода на Интернет из-за рассогласования скоростей работы оборудования провайдера и нашего роутера пропал Интернет. Вылечилось обновлением прошивки в роутере.
Подтвержденные опытом эксплуатации плюсы данного решения сейчас могут быть сформулированы следующим образом:
1. Фактически действительно обеспечивается при разумных стартовых затратах высокая надежность хранения данных.
2. Система пригодна для профессиональной удаленной поддержки.
3. При необходимости сравнительно легко можно переехать в другой офис – требуется только перевезти сервер и локальные машины и включить все это в транспортную сеть нового офиса (конечно с облаком это еще проще, но все познается в сравнении).
4. Локальные машины могут быть любого типа и дешевыми, никаких специальных требований к ним не предъявляется.
В то же время со временем стали проявляться и относительные недостатки такого решения:
1. Защита данных не является максимально высокой, такой которая уже вполне достижима в современных условиях. В частности система не защищена от серьезных физических повреждений сервера (условно – пожар в серверной).
2. Терминальный сервер не очень хорошо приспособлен для работы с тяжелыми или многочисленными WEB приложениями.
3. В связи с начальным отказом от виртуализации на сервере (исключительно по мотивам экономии) мы были вынуждены мириться с потенциальной возможностью перерыва в работе (конечно без потери данных!!!) на срок до 2-3 дней при серьезных проблемах на сервере.
4. Появились за прошедшее время и более дешевые решения с теми же примерно характеристиками на основе «облачных» решений (PaaS, SaaS, IaaS).
В этой связи структура нашей ИТ системы была дополнена следующим образом:
1. Был принципиально ограничен выход в Интернет непосредственно с терминального сервера. В случае работы, например, по системе Банк-Клиент – на сервере хранились только данные, а сама программа Банк-Клиент запускалась с какой-либо локальной машины, которая по одноранговой сети обращалась к данным на сервере, который в этом случае играл роль файл-сервера.
2. Для решения проблемы физической защиты данных было организовано дополнительное хранение текущих и архивных копий данных в облаке.
Это наш опыт. Далее пойдут рассуждения.
Почему и когда все же не стоит полностью отказываться от своего сервера и переходить на работу только с облаком, несмотря на привлекательность соответствующих предложений.
В теории при работе в облаке все просто замечательно. Но.
Ваша компания при этом попадает в полную зависимость от ИТ компании, предоставляющей соответствующий облачный сервис. И даже если Вы вначале выбрали супер надежную компанию со временем она может (увы, это жизнь) потихоньку деградировать, а Ваши то данные все у нее. И даже перейти в другое облако без поддержки специалистов первой ИТ компании, вы не сможете.
Критически важен оказывается Интернет канал. А по закону подлости, как раз тогда когда он Вам позарез нужен, проблемы с ним и случаются.
Если для Вас важным является обеспечения конфиденциальности (секретности) данных, то надо либо проводить какой-то независимый технический аудит предполагаемого к использованию облачного сервиса, либо все же ориентироваться на собственный локальный сервер. Дело в том, что некоторые технические реализации облачных технологий допускают смешивание прав пользователей из разных компаний, вследствие чего сотрудники одной компании, работающей в облаке, могут получить доступ к данным другой компании, работающей в этом же облаке.
В целом по нашему мнению можно считать относительно безопасным такой вариант ИТ системы (с учетом оговорок относительно соблюдения конфиденциальности данных):
Терминальный сервер в облаке с одновременной организацией собственного дополнительного сетевого хранилища данных (локальный файл-сервер) для хранения актуальных текущих копий всех Ваших данных.
На этом же своем локальном сервере можно хранить текущий кэш данных, что снизит трафик по внешней сети и повысит скорость работы.
А следующий шаг в развитии ИТ системы компании логически выглядит так – переход на систему виртуальных рабочих столов, расположенных на собственном сервере или в облаке (технология DaaS). При этом у Вас должно быть независимое хранилище данных (расположенное физически в другом месте и обслуживаемое желательно другой сервисной ИТ компанией).
Плюс, если работаете с облаком, желателен сервер для локального кэширования текущих данных.
Комментарии (33)
dklm
23.06.2016 08:44-1— зря отказались от виртуализации, Можно использовать Free версии VMware ESXi или MS Hyper-V.
— c браузерами на терминале у меня никаких проблем, если у вас ws2012R2 все должно работать отлично (без бубна), если ws2008R2 нужно руками включать RemoteFX.
— с клиент банками тоже проблем нету.
— самому делать виртуальные десктопы не имеет смысла на количестве 10 юзеров, нужно мнооого юзеров для экономического эффекта.
— если вам кто-то из «администраторов» говорит что нужно использовать классические ПК, не слушайте такого человека и сотрите его контакт.
ПК не нужны «офисным» работникам!
На данный момент ПК нужны только для работы с 3д графикой, или для подключения всяких разных аппаратиков типа кассового или плотера… и т.д и т.п.
— у меня юзеры работают на терминале с Autocad LT и все ок!
— Считаю что на терминале и не только на терминале, обязательно нужно внедрять MS Applocker или software restriction policy. Чтобы у пользователей не было и шанса подхватить «вирус».
— в случаи 10-20 юзеров нет смысла покупать новые сервера. можно легко купить HP G6 или другие, на хабре по поводу бу серверов уже куча статей. такие сервера легко отработают еще лет 7, а стоимость за 2х процессорный сервер до 1000 уе.
— аналогично с ПК, можно купить бу брендовые (HP,DELL) компактные ПК с ОЕМ лицензиями на винду, и использовать эти ПК в качестве тонких клиентов. предложений море…
П.С.
Возможно для 10-20 юзеров лучше полностью уйти в облоко и отказаться от физических серверов.
Знаю одну контору которая работает аналогично тому как описано в статье, но они использовали ESXi (затем сменили вроде на KVM).
И все у них хорошо. Покупали БУ сервер HP ML150 G6.DaemonGloom
23.06.2016 09:13Простите, а какое вы используете железо и какой софт на терминалах?
dklm
23.06.2016 09:23если вкратце:
Xeon 5620 2шт на сервер, HP ML350 G6.
ESXi 5.5
ws2008R2 для виртуалок
П.С.
посмотрите мои публикации.DaemonGloom
23.06.2016 09:39Как я понял из публикаций, вы используете тонкие клиенты HP.
На первом попавшемся сайте, продающем такие устройства, цены начинаются от 30 тысяч за устройство.
Купить обычный офисный компьютер c профессиональной версией Windows — дешевле.dklm
23.06.2016 09:45не внимательно читали ;) или плохо написана статья (я старался) =)
1 — чтобы получить нормальную стоимость на тонкие(новые) нужен «проект».
2 — я(мы) покупали бу тонкие (зачем платить больше?).
таки да, стоимость тонкого и пк, сравнима, даже если техника бу…
но, габариты + енергопотребление, лицензирование…
сейчас мне удобно эксплуатировать парк тонких, и менять ПК которым по 10 и больше лет на тонкие.
Landgraph
23.06.2016 09:16Автор, Вами представлен один из многих подходов для реализации офисной инфраструктуры. Хорошо, конечно, что Вы имеете представление о том, какое время Вы допускаете на восстановление и, что именно для Вас важнее.
Но подавляющее большинство директоров в принципе этого не представляют. И системные администраторы плодят железки не потому, что они такие плохие. А, чаще всего потому, что директор сам в этом не разбирается, а все пинки и зуботычины из-за того, что накрылся один единственный собранный на коленке за три копейки из б/у оборудования сервер, достаются именно администратору.
По закону подлости оборудование выходит из строя именно тогда, когда «плановый» простой в 2-3 дня будет недопустим. И та же Ваша сопровождающая организация пожмёт плечами и скажет: «Вы выбрали такую инфраструктуру». И предъявить им будет нечего. На сисадмина хоть поорать можно, почему он не предусмотрел, что именно в этот момент накроется мать и не купил запасную.
Вы описали просто один из подходов к реализации инфраструктуры в определённых условиях. Он не хорош, он не плох — он один из. Его главный плюс в том, что для Вашей организации он достаточен.
Подходит ли он для всего малого бизнеса? Не думаю.
Только не дай бог Вашу статью прочитать другим директорам, которые возомнят себя ИТ-гуру после этого и будут требовать именно такую инфраструктуру, несмотря ни на что =)
LoadRunner
23.06.2016 09:36Лучше напишу отдельным комментарием, чем ответом в одной из веток.
Мнение начинающего системного администратора.
В самом начале Вы сразу сказали, что Директор, а не Айтишник. В этом вся проблема. Ещё проблема — узость мышления. Вы зациклились на «у меня это уже 5 лет работает, значит верное решение». Возможно, верное в плане экономии денег, но оно не оптимальное в плане надёжности данных. Вам требуется сверхнадёжность при минимальных затратах. По своему опыту знаю, что когда стоит задача «не терять данные вообще никогда, иначе конец света» — думать о бюджете стоит в последнюю очередь.
Если у Вас только 1С и офисные программы на 10 сотрудников, то я бы тоже предложил терминальный сервер. Если набор программ для всех сотрудников одинаковый, то хватит и RDP. Если же разный софт, то лучше использовать виртуализацию рабочих столов. При любом раскладе для подключения к серверу достаточно тонкого клиента, а не полноценного компьютера.
Сервер 1С должен быть отдельным сервером. Бэкап-сервер — тоже отдельный сервер.
Разумеется, сервер может быть как виртуальным, так и физическим. Тут важнее разделение ролей по разным серверам, чтобы при корректировке работы одной из ролей не возникало проблем с другими.
Кстати, Вам не говорили, что профили пользователей (даже на локальных компьютерах) можно сделать перемещаемыми и хранить на сервере (тогда повышаются требования к сети)? А можно только папку «Мои документы» разместить на сервере. И бить по пальцам за сохранение на рабочем столе. А ещё я не встречал вирус-шифровальщик, который умеет шифровать по UNC-путям.
Ещё бочка дёгтя в ложке мёда: лицензии. Вы в курсе, что Вам надо: лицензия на физический сервер, лицензия на каждое устройство\пользователя, которое подключается к этому серверу (даже если просто расшареные папки на сервере используются), лицензия на каждое терминальное подключение, при использовании офиса в терминале — лицензия офиса на каждое устройство (даже тонкий клиент), с которого идёт подключение к терминальному серверу (даже через интернет с домашнего компьютера). И не абы какая любая от любого офиса, к слову.
А Вы говорите — «минимальные затраты». У Вас есть шанс влететь на штраф при проверке. Спасает лишь то, что их почти не устраивают мелким компаниям. А маски-шоу Вам тоже не угрожают? Шанс такого — нулевой?
Итог. Никогда не экономьте на IT. В фанатизм ударяться не стоит — никакой экономии, но и сверхзатрат не нужно. Нужно просто вырабатывать адекватное решение, учитывая не только критерий «сверхнадёжность данных», но и «комфортная работа». Не забывайте, что работу делают сотрудники и компьютеры\серверы — лишь инструмент. От того, как Ваши сотрудники управляют инструментом, зависит качество сделанной работы. И как результат — прибыль компании.
Кратко Ваше решение характеризуется так: «Raid 1 + бэкапы + бэкап бэкапов».
ashum2015
23.06.2016 10:36После первоначальных небольших шараханий — пошла интересная и полезная дискуссия.
Есть общее замечание на тему приличности и необходимости директору компании самому вникать в некоторые общие вопросы ИТ системы.
Полагаю, что сейчас уже очевидно идет переход даже в не очень больших компаниях от системы директор+системный администратор+плюс сторонняя сервисная обслуживающая ИТ компания к системе директор + директор по ИТ + много сервисных обслуживающих компаний.
И здесь диретору надо или самому быть ИТ директором или нанимать на стороне не услуги системного администратора, а услуги ИТ директора.
А пока вынужденно совмещая в одном лице и директора и ИТ директора вижу, что прошедшая дискуссия позволяет сформулировать некоторые общие принципы построения структуры ИТ системы, ориентированной на высокую надежность хранения данных компании. Так надо строить распределенную отказоустойчивую систему хранения данных, в которой:
1. будет минимум две физически разнесенные точки хранения данных, обслуживаемые при этом разными организациямими (людьми);
2. одна из таких точек должна находиться под полным контролем компании как физически (находится в ее офисе), так и логически (полностью контролироваться или иметь возможность контролироваться сотрудниками компании).
3. важная частность: в точке хранения с своем офисе крайне желательны аппаратно поддерживаемые RAID массивы.
4. Резервные копии — это само — собой тоже.
А дальше начинаются варианты.
Можно взять (как у меня) один профессиональный сервер и сделать на нем систему виртуальных серверов (чего я не сделал, а зря).
Можно поставить несколько простых «серверов», объединив их технологией Ceph (к слову 5 лет назад ее вроде как еще не было).
Что лучше и надежнее (при ограниченном бюджете) для меня пока не очевидно.
Вопрос о терминальном сервере решается в зависимости от конкретных потребностей бизнеса. Для примера:
Если как у меня новая компания, ничего нет, будет одинаковый софт — то лучше терминальный сервер.
Если идет модернизация сложившейся стрруктуры с большим количеством локальных машин с разным софтом на разных рабочих местах, то терминальный сервер не нужен.
И разумеется, если есть такая возможность (по бюджету и по квалификации исполнителей), то надо иметь минимум два физических сервера (один из них может быть в облаке) и делать систему миграции виртуальных машин между серверами.
Ivan_83
23.06.2016 20:54У меня не профессиональные десктопы по 5-10 лет непрерывно пашут и ничего. При должном то уходе.
Начнём с простого: бэкапы есть а вы хоть раз пробовали развернуть с них что то на новый/другой сервер?
Мне оч сильно сдаётся что когда ваш чудо сервер накроется вы неделю будете воротать всё обратно до рабочего состояния, из которых 5 дней будете безуспешно пытатся развернуть бэкап ОС со всеми настройками и оставшиеся два дня будете ставить ОС с нуля и настраивать, заливать данные.
Виртуализация в вашем случае нужна ровно для одного: чтобы бэкапить венду с 1с целиком и потом чтобы это можно было развернуть на другом железе.
Но я бы искал как уйти с:
— терминала
— венды на сервере
— венды на клиентах
— может быть веб версию 1с.
Есть конечно нюансы со считывателями штрих кодов, банк клиентами и прочим дерьмовым софтом, но в худьшем случае осталась бы 1-2 машины с виндой.
Виртуализация для не венды не шибко актуальна, при прямых руках.
Аппаратный рейд — нафик не впёрся, если ОС не винда, даже без него намного лучше, в плане сохранности данных — переткнул диски в другую железку и понеслось, не надо искать такой же контроллер.ashum2015
23.06.2016 23:28Нисколько не сомневаюсь, что у Вас будет работать все и без проблем.
Только вот моя задача была и остается сделать такую структуру, которая не требует постоянного наличия возле себя золотых рук.
Про бэкапы. Описанная Вами опасность есть. Однако бэкапы — это прежде всего последняя линия обороны в хранении совсем даже не системы, а данных компании. Систему можно и восстановить, даже еще раз купить в крайнем случае, а вот утерянные собственные данные купить негде.
Хотя и систему тоже бэкаппируют. До кучи. Вдруг получится ее быстро восстановить.
А основная линия обороны по защите данных — это горячее резервирование (RAID массивы, кластеры).
Совершенно не согласен с Вашим негативным восприятием виртуализации. Каюсь здесь у меня исключительно теоретические знания, так что пусть практики меня если что поправят.
Но насколько я понимаю виртуализация (на основе любой ОС) полезна в следующих целях:
— облегчается удаленное администрирование, виртуальный сервер можно перезапустит программно, а не щелкать клавишей сброса или питания.
— на отдельном сервере полезно поставить 1С, чтобы глюки, временами происходящие при обновлении 1С, не влияли на остальной софт.
— можно на отдельных виртуальных серверах поднять такие полезные штуки как VPN сервер, сервер IP телефонии, почтовый сервер.
— Наконец на виртуальных серверах можно организовать отказоустойчивый кластер.
Про аппаратный рейд — где то выше была небольшая дискуссия. Повторяться не буду.
Ivan_83
24.06.2016 00:13У вас и первой линии нет.
Того и гляди кто нибудь работая в терминале запустит очередной шифровальщик. (оставим в стороне рассуждения что у вас там антивирус)
Если очень «повезёт» он ещё и через дырку в системе права подымет до админских и дотянется до вообще всех файлов.
Аппаратный рейд — вещь в себе.
В целом его ниша это:
1. оффлоад операций, это было оч актуально раньше сейчас обвязка проца сама прекрасно с этим правляется
2. дать возможность юзать рейд пользователям десктопной венды
Я по неопытности его использовал с 2005 по 2008 года. К счастью у меня железо не дохло во время этого, но пару неприятных моментов было, когда до потери было совсем рядом:
— один раз шлейф пришёл в негодность, а там был какой то экзотический SCSI контроллер и 4 диска как раз с базой и я все выходные бегал по городу искал такой же. Город был не большой и нашлось оно в одном магазине.
— другой раз сдох вентилятор на чипсете матери и интенсивная дисковая активность стала приводить к отвалу и ребутам, тут просто вовремя переехали на др железо.
С программным рейдом под не виндой пробем не было. Под виндой как то буква на системном разделе слетела, но данным ничего не грозило.
Засовывание отдельных приложений в виртуалку это усложнение администрирования, тк помимо администрирования приложения нужно ещё и за ОС следить. Но это в мире бсд/линух.
Венду проще сунуть в виртуалку, чем переставлять каждый раз когда она помрёт или когда нужно железо менять.
Для удалённого админства в вашем мегасервере должен быть KVM/iLO или ещё какой то встроенный механизм. Для десктопных серверов продаются ip-KVM, которые подключаются к сети и к компу вместо монитора+клавы+мышки.
Для отказустойчивого кластера одного сервера набитого виртуалками мало.dklm
24.06.2016 08:22для того чтобы не ловить шифровальщика достаточно развернуть Applocker и разрешить запуск приложений только из системных папок, вот и все.
у меня так один пользователь работая на ПК зашифровал сетевую папку, после чего очень быстро начал работать на терминальном сервере ;-).
П.С.
честно говоря мне не понятны советы где рекомендуют избавится от терминального сервера.
П.П.С.
кстати Shadow Copy отличная штука для файловых шар на ws, юзеры смогут сами получать доступ к предыдущим «версиям» файлов.
легко настраивается и администрируется.Ivan_83
24.06.2016 10:56Это явно не под силу автору.
И лазейки всё равно остаются, вон на джаве есть локеры.
Терминальный сервер это дорогое удовольствие от единственного вендора, по крайней мере для подавляющего большинства.
Это ещё и единая точка отказа.
Я уже перешёл в другой мир технологий, тут и примерно такое можно найти/соорудить, при желании.
Лёгкость администрирования на винде — видимая. Всё легко пока всё идёт хорошо, когда что то переастаёт работать то последний аргумент — дебагер (видимо WinDBG + символы ядра), предпоследний процессмонитор.
И обычно решающий все проблемы — переустановка с нуля… Ну да, бэкапы тоже иногда помогают.
Логов можно считать что нет — понять из них без грепанья по исходникам ничего не возможно а исходников нет.
DaemonGloom
Мнение со стороны системного администратора, видевшего аналогичное решение:
Нет, не надо так делать. Даже если всем вашим десяти пользователям нужен одинаковый софт — не надо так делать. Браузер с кучей анимированных картинок может запросто подвесить всю сессию, если используется, например, Thinstation в качестве бесплатного тонкого клиента.
«Локальные машины могут быть любого типа и дешевыми» означает, что будет использоваться старый хлам. Он будет гореть, умирать, но заменяться на такой же хлам.
Лицензий на windows на машинах при этом явно нет.
Десяток человек, одновременно активно работающих с дисками — и винчестерам уже печально.
Никакой надежности запрет на выход в интернет с данного сервера вам не даст, если пользователи могут перемещать документы с локальных машин на сервер и обратно.
Насмерть зависший процесс у одного из пользователей запросто приведёт к тому, что перезапускать необходимо будет весь сервер.
Как вам, вероятно, стоило сделать:
Нормальные компьютеры.
Сетевая версия 1С.
Регулярное резервное копирование компьютеров целиком. Сейчас это можно сделать через Veeam Endpoint Backup, например.
Виртуализация сервера, либо кластеризация сервисов.
Что это даст:
Если у вас умер компьютер — вы просто покупаете аналогичный или меняете умершую часть, после чего прекрасно восстанавливается бэкап.
Если у вас умер сервер — вы не потеряли возможность работать. Софт прекрасно работает на компьютерах, а в силу того, что это не простейшие дешевые калькуляторы — пользователи не ругаются на тормоза и невозможность открыть пару документов.
И всем этим хозяйством можно будет нормально раздельно управлять. Необходимость обновить банк-клиент для бухгалтера не приводит к необходимости перезапуска сервера. Обновление очередного ПО для очередных закупок не приводит к необходимости перезапуска сервера.
Более того, у вас исчезает единая точка отказа.
Если вы купите второй физический сервер — вы сможете настроить их работу либо так, чтобы пользователи даже не заметили, что что-то случилось (при использовании кластера 1С), либо с коротким перерывом на подъем реплики на резервном сервере(при использовании виртуализации).
ashum2015
Вы пишете правильные вещи. Но. На основании своих знаний и того, что один раз видели подобную систему.
Я же во-первых не теоретизирую, а всего лишь описываю реальный опыт реальной компании. И полученный опыт — за мое решение. Оно уже 5 лет без сбоев работает.
Во вторых, Вы почти не уделили внимания главному требованию — обеспечить при минимальных затратах самую большую как только можно надежность хранения данных.
В Вашем варианте такой же надежности можно достичь только поставив RAID массивы на каждое рабочее место (что дорого) или же путем скрупулезного выполнения обслуживающим персоналом (своим айтишником или сторонней компанией — без разницы) всех алгоритмов бэкапирования. Теоретически в этом ничего сложного нет. Практически вмешивается человеческий фактор и от надежности создания резервных копий (если вся надежность только на них) остаются только воспоминания.
Ну и безусловно такое решение, как я описал, подойдет не для всех. И об этом я прямо написал: предполагается одинаковый софт у всех сотрудников и минимум работы через web интерфейсы. Но всем у кого подобные же условия и требуется высокая надежность хранения данных — категорически рекомендую сделать что то подобное.
Да, эту систему легко отдать на централизованное обслуживание в компанию где работают грамотные специалисты. Возьмут (хотя сейчас и будут навязывать облачные решения). А куча «продвинутых» локальных рабочих станций — для централизованного обслуживания гораздо менее пригодна.
И частные замечания: в отношении хлама, который может использоваться на рабочих местах. Да может. И это для меня как директора большой плюс. 5 лет назад сервер со всеми хранилищами и даже с лицензией обошелся мне менее чем в 200 тысяч рублей. Рабочие места «из хлама» я получил даром. А сколько будет стоить (точнее стоила бы 5 лет назад) Ваша структура? Да насчет «гореть». Проблемы которые реально были — это перестал работать СД привод, стал чрезмерно сильно шуметь вентилятор. Думаю это не те проблемы, о которых вообще стоит говорить.
В отношении зависших процессов. Практически не было. Но «последователям» я бы рекомендовал ставить виртуализацию на сервер. Тогда никакие зависания процессов в принципе не страшны.
Ну а поскольку, повторюсь, я описываю реальный опыт, хотелось бы обратиться ко всем, желающим поставить минус — обоснуйте пожалуйста свою негативную реакцию.
Спасибо
pred8or
Сделанное вами представляется настолько удивительно неоптимальным, что даже сложно всерьёз аргументировать. Пока могу придумать единственное оправдание такой вашей архитектуры — бюджет. Об этом вы не сказали ни слова, а было бы очень интересно узнать. Раскроете? Хотя бы порядок затрат. Capex, Opex
ashum2015
Про бюджет я написал. Фактически новые вложения были менее 200 тысяч рублей.
Не надо ничего аргументировать. Приведите пример не придуманной, а работающей системы, стоящей примерно столько же и гарантирующей ту же степень надежности хранения данных, что и описанная мною.
На сегодня, с учетом нового резервного копирования в облако, она почти совершенна. Более высокая надежность может быть достигнута только при затратах на порядок больше.
onegreyonewhite
Вот поэтому (я про статью в целом) директор компании и ИТ-специалист должны быть разные люди.
Раз уж делимся опытом, то поделюсь своим.
1. Mikrotik RB951G-2HnD + 2 х D-Link DGS-1016
2. Три небольших сервера Ceph на любом недорогом железе (мы использовали восстановленные Fujitsu)
3. Ещё один сервер так же малой мощности под 1С-сервер в web-файловом исполнении и под Calculate Directory Server
(такой же Fujitsu, но с большей ОЗУ)
4. Все машины на относительно недорогом железе, но с достаточно большим количеством ОЗУ.
Система разворачивается по PXE на клиентских машинах. Ввод новой машины занимает время загрузки оной на компьютере.
Ко всему snapshot`ы всего хранилища дублируются на Dropbox каждый день в 00:00. База резервируется раз в час.
Всё работает уже почти 3 года без нареканий и ввод нового кабинета занимал время вставки двух коннекторов в разъём и протяжки кабеля. Windows только у бухгалтера на ноутбуке, но с бухгалтерией у ИТ всегда особые отношения.
В своё время очень хотелось реализовать VLAN структуру, но мне на ту компанию стало совсем не хватать времени и мы расстались.
Оглядываясь назад понимаю, что сейчас при помощи OpenStack можно было бы всё реализовать ещё более красиво.
Цена такого решения сейчас (специально решил посмотреть):
Микротик — 6 299
DGS-1016A 3 999x2=7 998
Fujitsu RX100S6 Core i3-540/8GB/500 GB SATA/2xGlan/PSU 350W — 19 200x4=76 800
1С Бухгалтерия 8.3 ПРОФ 10 800
1С лицензия на 10 рабочих мест 34 500
ИБП DEXP Rely Power 3000VA (2600Вт) 26 999
Шкаф б/у 10 000
Итого: 173 396 рублей без учёта стоимости рабочих мест и со всеми лицензиями
Когда я собирал всю эту систему, обошлось в 140к рублей (правда мы собирали на Xeon-процессорах).
Данная система не то что такая же по надёжности, что и описанная Вами, но и гораздо более надёжная.
В итоге мы получаем сервисы: DNS, DHCP, AD, Mail, NAS, Proxy, 1C. Узким местом является сервер 1С и CDS, но сами данные потерять невозможно (хотя дуракам всё возможно).
ashum2015
Итак, я директор (это не модельная игра, я действительно директор), Вы системный администратор, который предлагает мне сделать несколько (3-4, сколько нужно) дешевых серверов. Я знаю, что есть такие понятия как виртуальные сервера и терминальный сервер.
И тогда я Вас попрошу ответить на такие вопросы:
1. На основании чего Вы считаете, что много простых и дешевых серверов надежнее одного профессионального сервера, на котором можно поднять систему виртуальных серверов?
2. Где физически будет храниться база знаний (ну упростим — база документов и данных) компании и как Вы обеспечите надежность их основного места хранения (дублирование данных в облако — это уже дополнительная защита от потери данных).
3. Если у меня сейчас 5 сотрудников и 5 локальных машин и все, а вскоре я планирую увеличить количество сотрудников в 2 раза — не правильнее все же будет организовать сразу терминальный сервер?
4. Что удобнее и дешевле в обслуживании — один физический сервер с системой виртуальных серверов или несколько отдельных простых серверов?
DaemonGloom
1,2) Ceph — распределенное отказоустойчивое хранилище. Смерть отдельного сервера не означает ничего, кроме необходимости покупки/замены железа. Сервисы даже не заметят, что один сервер умер.
3) Терминальный сервер не масштабируется нормально, если он не является виртуальной машиной на мощном железе. Удвоение людей — удвоение нагрузки. А придет ещё 5 сотрудников — и старый терминальный сервер станет бесполезным, придется брать новый.
4) Гораздо удобнее обслуживать несколько отдельных серверов при условии наличия кластера для сервисов. Нет ограничения «вот надо добавить памяти/диск, но для этого нужно ждать, когда все уйдут».
pred8or
1. Один сервер — это единая точка отказа. Отсутствие дублирования — это простой и перебои в работе бизнеса. Так что ответ здесь — несколько серверов в рамках бюджета, на которых развернуть систему виртуализации с возможностями прозрачной миграции ВМ между серверами. В большинстве случаев для этого понадобится специализированная система хранения с высокоскоростными интерфейсами типа Fibre Channel и хорошими аппаратными контроллерами RAID. Поскольку сервера оказываются зарезервированными, это могут быть «сервера». Главное — насовать в них побольше памяти
2. Как раз на этой самой системе хранения. Надёжности можно отсюда добавлять например путём создания или использования географически удалённого хранилища, собственного или арендованного
3. Размазав нагрузку по нескольким серверам вы внезапно увеличиваете общую пропускную способность и получаете систему на вырост. Терминальные сервера — довольно странная вещь. Зачем, если даже 5-7 летний компьютер имеет достаточно мощности для нормальной офисной деятельности (я не имею в виду понты и тяжёлые специализированные приложения. Но и там терминальный сервер не спасёт).
dklm
вы предлагаете Fibre Channel для офиса из 10-20 человек и географически удаленные площадки? я предлагаю еще запустить собственный спутник связи )))
П.С.
для «смол бизнеса» есть беджетные хранилки QNAP и Synology ;-)
про фабрику улыбнуло…
pred8or
Да ладно. Авито + кризис = можно купить FC за копейки. Надо только задаться целью и мониторить. Ну и 4Гб в такой конфигурации хватит за глаза. Есть опыт создания на коленке системы хранения в обычном ATX-корпусе с RAID-контроллером и FC, работающем на специализированной сборке Linux (запамятовал, как называется, а искать лень)
Landgraph
Коллеги, мне кажется, что вы обсуждаете два подхода к обеспечению надёжности системы.
Первый подход заключается в уменьшении количества точек отказа (представлен автором, но не стоит забывать, что и один сервер в себе таит с десяток точек отказа), второй — резервирование узлов (которое увеличивает вероятность отказов, но снижает их влияние на систему).
Но, простите, это не взаимоисключающие, а взаимодополняющие подходы!
Обратите внимание, автор допускает перерыв в работе бизнеса 2-3 дня. За это время можно, даже находясь в регионе, слетать в Мск и привезти новый сервер!
Соответственно для некоторого бизнеса и такой вариант является достаточным. Для другого, возможно, будет даже избыточен, для третьего — недостаточен и т.д.
onegreyonewhite
Думаю коллеги DaemonGloom и pred8or более чем достаточно привели доводов на ваши вопросы.
От себя добавлю:
1. Что в Вашем понимании «профессиональный сервер»? А есть непрофессиональный? Fujitsu RX100S6 весьма хороший 1U сервер, с хорошим встроенным RAID контроллером.
2. А где в Вашей конфигурации база знаний будет храниться? Я думаю Ceph вполне себе подойдёт. Хотя ещё круче будет развернуть на тех же 3х серверах LAMP и MediaWiki.
3. Причём здесь вообще терминальный сервер? Вас как будто загипнотизировали…
4. Когда кластер, тогда лучше много серверов. Обновляться гораздо легче без остановки работы.
ashum2015
Спасибо за пояснения. Собственно в новом комментарии, которое я уже написал в конце обсуждения, я уже отметил, что терминальный сервер — это важная, но частная особенность конкретной реализации.
Кластер на технологии Ceph (или нечто аналогичное по функционалу) — это конечно здорово, если его можно сделать по имеющемуся бюджету и есть исполнители, которые это умеют.
В то же время и один сервер, как показывает наш опыт, надежное решение, если там есть аппаратный RAID и это не обычный офисный компьютер, в который добавили память (это к тому, что можно называть профессиональным сервером).
DaemonGloom
Ваш опыт — это то, что называется «ошибка выжившего». Аппаратный рейд не даст вам уровень защиты данных лучше, чем даст ОС или софт-рейд. Вы всего лишь исключаете ошибку драйвера софт-рейда и добавляете вероятность сбоя контроллера, помноженную на проблемы с переносом массива на другие устройства.
Рекомендую статью: https://habrahabr.ru/company/advanserv/blog/163451/
В вашем случае, это ещё и сервер с минимальной отказоустойчивостью при сбоях железа. Память не registered, один блок питания.
ashum2015
Спасибо за ссылку по сравнению аппаратного и программного рейдов. Прочитал. С трудом, но прочитал и комментарии. Однако все не так очевидно.
Да есть много ситуаций, когда программный рейд лучше (быстрее, дешевле и т.п.), особенно, если вы работаете с Линаксом.
А вот с Виндоуз уже не всегда программный рейд выигрывает.
Именно такие выводы получаются от чтения того, что Вы порекомендовали.
От себя добавлю. Если серьезный производитель (HP в моем случае) интегрирует в свой сервер аппаратный рейд, то наверно он это делает вполне обдуманно, а не для того, чтобы развести нас на деньги.
Вот в чем Вы безусловно правы — так это в том, что на качестве сервера, особенно единственного, экономить надо осторожно.
Я тут у себя пожалуй палку экономии перегнул.
dklm
HP/HPE заявляют что можно вынуть диски которые собраны в рейд (из сервера любого класса) и переставить их в другой сервер HP (любого класса), и массив поднимится.
собственно нужно использовать рейд на материнке или другой который предлагает HP.
HP/HPE не производит диски и не производит рейды, но они пишут под них свои прошивки.
основной плус аппаратных рейдов это наличие «большого» энергонезависимого кеша.
ashum2015
Чисто для иллюстрации: наш сервер это HP ProLiant ML110 G6…
asgard88
Можно подробнее про «1С-сервер в web-файловом исполнении и под Calculate Directory Server»? Я так понимаю вы предлагаете развернуть linux сервер 1C в файловом варианте, где базы будут лежать в кластере Ceph, а юзеры будут сидеть через браузер в 1С? Но тогда мы дважды упираемся в ограничение по скорости сети и проблемы с репликацией и восстановлением файловых баз. Да у 1С в файловом варианте базы живут гораздо хуже SQl-ных
onegreyonewhite
В нашем случае база не планировала расти до 100Гб и файлового режима на 10 (максимум) одновременно работающих пользователей хватало. База находится на сервере, но снапшоты базы лежат на Ceph.
Сидеть в 1С через браузер уже давно не нужно ибо клиент 1С умеет подключаться к web-серверу. В принципе 1С клиент на Linux работает вполне сносно. Особой разницы в «глюках» с форточной версией не увидел.
Впрочем, насколько я знаю та компания скоро перейдёт на SQL, так как их становится всё больше.
pavelpromin
del