Как стать автором
Обновить

Бюджетный вариант перехода от рабочей группы к домену

Время на прочтение 4 мин
Количество просмотров 15K
Всего голосов 6: ↑4 и ↓2 +2
Комментарии 49

Комментарии 49

Статья опоздала лет на пять?
В каком смысле? Придумали что-то новое взамен сети с доменом?
Может я чего не понимаю, но зачем брать для контроллера домена 500 Гб? Хватает и SSD на 60 Гб. И затраты на такой сервер — 25-30 тысяч рублей, без учёта лицензий, разумеется.
От RAID можно вообще отказаться, имея второй дублирующий сервер.
Тем более, если есть файловый сервер, куда будут литься бэкапы — вот на этом уже точно не стоит экономить и уж под бэкапы обязательно нужен RAID, а не «один терабайтник».
Брать 2 SSD на 60ГБ или 2 500 ГБ SATA (возможно, бу) — тут все упирается в деньги, какое решение более подходит под бюджет, такое лучше и выбрать.

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

по поводу зеркала на бэкапы — тут смотря какие бэкапы. Если там только бэкапы самого контроллера, то нет особого смысла их зеркалить, а если что-то еще будет туда бэкапится, тогда да, нужно зеркало. В рассматриваемом случае имелось ввиду, что на этот диск бэкапится только сам DC, а остальное (виртуальные машины, файловые шары и БД) бэкапятся на другой массив, и вот там уже да, зеркало.

В описанном случае необходимость в Raid обусловлена тем, что диски у нас тоже б/у, причем он интегрированный, так что кроме стоимости 2-го диска и небольшой доп.нагрузки на CPU этот рейд ничего не стоит в плане затрат
Вы же понимаете, что в случае критичных данных вариант «один SATA» — не вариант, потому что надёжность и корректность таких данных под вопросом?
Конечно, при переходе от рабочих групп к домену хочется сэкономить. Но экономить на дисках, у которых стоимость в разы отличается от стоимости лицензий — это экономия на спичках, причём совершенно ненужная и опасная.

Да и максимум проблем, которые можно поиметь с выходом основного DC из строя — то, что второй контроллер из slave надо переводить в master, а потом уже думать, что делать с первым.
Не вполне понятно, о чем вы — о бу-дисках? Но использование новых дисков никак не гарантирует их безупречность и отказоустойчивость, гарантируется лишь их бесплатная замена. Примеров, когда новые диски сыплются хоть отбавляй. Для этого Raid и нужен. А какие диски туда поставить, это уже вопрос возможностей бюджета.

С выходом из строя основного контроллера домена при наличии второго инфраструктура продолжит работать и пользователи ничего не заметят. В этом и есть весь смысл иметь 2-ой КД. А вот использовать на КД один сата без зеркала — это и есть экономия на спичках.
Ну б\у диски тоже не гарантируют качества и надёжности. Им-то как раз меньше доверия. А брак в партии новых дисков — вполне обычная вещь. Мои основные претензии к выбору дисков под бэкапы, пусть даже если туда бэкапится только КД (и вопрос ещё — чем бэкапится. Если Windows Archive, то терабайтник тут перебор, а уж если диск под бэкапы на той же машине — тем более сомнительно всё это выглядит).
А ещё, как правило, у малых организаций под бэкапы уже есть NAS какой-нибудь и его вполне достаточно будет.
Поэтому смысла пичкать КД дисками нет, соответственно, нет смысла покупать полноразмерный сервер. Потому что про стоимость владения забывать тоже не стоит.
1. В т.ч. поэтому нужен Raid.

2. По размеру — может и перебор, но больше — не меньше. Если есть желание поставить диск поменьше или утилизировать побольше — ради бога.

3. Про NAS — если есть, то да. Но если нет — диск в сервере будет дешевле, чем NAS, да и умрет NAS быстрее, чем выделенный только под бэкапы DC диск. Мухи отдельно, котлеты отдельно. Но это уже вопрос выбора в каждой конкретной ситуации.
Мухи отдельно, котлеты отдельно.
Не стоит складывать все яйца в одну корзину. Откажет сервер и толку нам от диска с бэкапами, который внутри вышедшей из строя машины?

Вообще, в каком сценарии Ваш вариант с одним диском на той же машине позволяет без проблем восстановить нужные данные из бэкапа и это выгоднее, чем бэкапы на сетевое расположение?

Вот сценарии, где этот вариант проигрывает:
Пропадает электропитание — головка HDD паркуется неправильно и приплыли.
Пошли невосстановимые ошибки системы и надо либо переустановить всё (если бэкапим только базу КД), либо восстановить из образа системы — так Windows Archive не делает полный бэкап системы на диск, принадлежащий этой же системе. Да и инкрементный не делает.
Использовать не Windows Archive, а контрольные точки — это опять же привязка к текущей системе, а вне её будет очень проблематично восстанавливать нужную информацию, что сводит на нет такой способ.
Насчет расположения диска с бэкапами на том же сервере — никто и не настаивает именно на таком решении, это лишь один из вариантов.

Есть принципиально 3 наиболее вероятных точки отказа на КД — это HDD, БП и MB. CPU — маловероятно. HDD у нас в рэйде. БП крайне желательно иметь в зипе. Ну, а если MB умрет, какая разница где бэкап лежит? Лишь бы он был. Какие бэкапы и каким софтом делать — это отдельная тема. Мы делаем штатными средствами, через Windows Server Backup по сценарию Full server.
Если КД один и умирает MB (или любое другое железо) — то стоит иметь запасную в холодном резерве. Не такие уж и большие расходы (тем более, их можно растянуть во времени) для бесперебойной работы и малого времени простоя.
Да и второй КД тоже можно докупить со временем. Расходы не обязательно могут быть единомоментны.
Чем отличается второй КД в инфраструктуре от зипа для КД? Минусом корпус, плюсом — время на ремонт и восстановление. Стоит оно того?
В идеале холодный резерв должен быть в дополнение к двум КД.
Потому что второй, третий, четвёртый и так далее КД — это не главный КД в инфраструктуре, главный всегда в единственном экземпляре, и при выходе его из строя лучше его и восстанавливать как можно быстрее, чем перенастраивать дублирующие.
Понятие главного КД — преданья седины глубокой. Мы говорим о первом и единственном домене в первом и единственном лесу. Роль GC MS рекомендует поднимать на каждом КД в домене. В данном случае у нас не будет ГЛАВНЫХ и НЕглавных контроллеров, в этом вся прелесть. Остальные роли могут быть просто захвачены любым контроллером по желанию Администратора, лишь бы этот КД был GC.
Главную ТО забыли — пользователь.

Бекапы должны быть 3-х уровневыми:

1. Диск на сервере который бекапим — допустимо при ГАРАНТИИ полного восстановления из Архива;
2. Архив на Отдельном сервере — максимально удаленном ФИЗИЧЕСКИЙ от первого сервера;
3. Внешний диск в машине админа/ДИТ/ДСБ — таких дисков должно быть 3 один в сейфе в банке, второй в сейфе в конторе третий в работе и ротаци не реже ОДНОГО раза в месяц.

И самое главное — раз в Квартал(лучше раз в месяц) генерал/дит/дсб — должны Видеть и проверять как Админ восстанавливает с ПОСЛЕДНЕГО бекапа хотя бы по одному ключевому компоненту системы(ДБ, КД, Архив Документов пользователей).

и то есть шансы просрать все… опыт…
Схема резервного копирования должна обеспечивать восстановление работоспособности критических сервисов и данных. Чем глубже паранойя, тем больше шансов))
Немого ошиблись с определением «критической массы». Меньше 100 пользователей это все еще малый бизнес — с соответствующим бюджетом на IT.
Ставить 2 сервера (пусть и один виртуальный) только для удобства управления доступами или любознательности админа никто в здравом уме не будет. А еще и лицензии покупать.

Обычно все ограничивается самосборным файловым/почтовым/прокси сервером.
Исключительно по экономическим причинам, или после проверки ПО на легальность.
Малый с какой точки зрения? Существуют предприятия с численностью 40 человек и оборотами на сотни миллионов в месяц. С точки зрения налогообложения это уже ни разу не малый бизнес.

Второй сервер ведь нужен не для удобства или экспериментов, а для отказоустойчивости инфраструктуры, дабы не остановились бизнес-процессы из-за какого-нибудь сбоя на мат.плате или в БП например.
Да вы правы, не сразу заметил что это платный блог.

Зная я несколько подобных компаний с большими оборотами (8 человек, AD, Exchange, Docvision) там реальная работа — по старинке, в смысле бумажными документами.

Но сегодня есть куда более интересный вариант — полностью работать в облаках, что и выбирают начинающие стартаперы

И как только начинающие стартаперы через год осознают себя окрепшим малым бизнесом, начинается миграция либо в приватное облако, либо в локальную инфраструктуру.
Б/у железо дешевле нового. Спасибо, кэп!
И тут от внезапной необходимости капитальных затрат впору схватится за голову: ведь одного контроллера домена будет недостаточно, его падение будет означать остановку работы всех пользователей.

Не будет если настроить кеширование входа в домен. Поэтому если уже есть сервер (почтовый, файловый или приложений) можно смело поднимать контроллер на нем. Затраты 0р при условии, что этот сервер у вас на windows.
Так мы теряем не только контроллер, но и те сервисы, которые жили рядом + получаем периодическую деградацию производительности, на таком сервере она гарантирована. Кэширование — это костыль, имеющий очевидную проблему с безопасностью и управлением.

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

Кеширование это не костыль а функция имеющая очевидную пользу при отсутствии резервирования контроллера домена.

Расскажите про очевидные проблемы с безопасностью и управлением. Мне они не очевидны.
Деградация производительности случится от трафика репликации, если есть другие КД, от трафика инфраструктурных сервисов и нагрузки от них на CPU, RAM и HDD.

Кэширование предназначено для входа в ОС при отсутствии доступа к КД. При этом у пользователя нет доступа к Active Directory, следовательно, нет доступа к сетевым ресурсам и сервисам. Что толку в корпоративной среде от того, что пользователь вошёл в ОС локально с использованием кэша?

Он максимум будет иметь только доступ к локально сохраненным файлам и папкам. А что делать с DNS и DHCP в случае падения единственного КД? Кэширование входа в домен подходит только для использования на мобильных устройств за пределами домена, но никак не в качестве замены упавшему КД.

Совмещать инфраструктурные роли с прочими ролями технически возможно, но крайне не рекомендуется MS и best practice.
Деградация производительности случится от трафика репликации, если есть другие КД, от трафика инфраструктурных сервисов и нагрузки от них на CPU, RAM и HDD.

Стоп, стоп, стоп. Откуда у нас взялись другие КД? У нас же был один сервер с почтой файлами и приложениями.

Кэширование предназначено для входа в ОС при отсутствии доступа к КД. При этом у пользователя нет доступа к Active Directory, следовательно, нет доступа к сетевым ресурсам и сервисам. Что толку в корпоративной среде от того, что пользователь вошёл в ОС локально с использованием кэша?

У него есть интернет (если мы его раздаем через роутер, а не через этот же сервер), есть Word, есть Excel. Уже можно жить)

Он максимум будет иметь только доступ к локально сохраненным файлам и папкам. А что делать с DNS и DHCP в случае падения единственного КД? Кэширование входа в домен подходит только для использования на мобильных устройств за пределами домена, но никак не в качестве замены упавшему КД.

А что мы до этого делали с DNS и DHCP, когда у нас не было КД, но так же был один сервер?

Роль КД добавленная на единственный сервер не сильно повлияет на надежность. У нас по прежнему будет большая точка отказа в виде сервера.
Ну вот и мы и пришли к общему знаменателю!))) Должно быть 2 КД — или оставаться в рабочей группе.

Сеть с доменом на одном КД — это бомба с часовым механизмом.
Нет, я не согласен))) КД имеет смысл поднимать даже на одном сервере. Плюсы появятся, а минусы останутся теже.
Плюсы то появятся, но и риски простоев из-за отказа в узком месте тоже появятся. Если не планировать второй КД — это выстрел в ногу раньше или позже. А если планировать, так почему не сразу? Не такой уж большой будет бюджет по сценарию из данной статьи, не?
Риски новые не появятся. Если исходить из того, что уже был сервер для файлов, почты и 1с, то поднятие КД незначительно увеличит риски (сервер не работает — все лежит, независимо от того есть КД или нет).
Если есть бюджет, то вопросов нет. Я бы тоже зарезервировался по железу. Просто я не согласен с тем что КД можно поднимать только в паре. Я считаю, что даже если нет бюджета на второй сервер, КД на одном сервере принесет пользу.
Тут я думаю будет сильно от нагрузки зависеть. Если сервер сильно нагружен, то польза может выйти боком. Про траблшутинг такого кентавра лучше к ночи не упоминать. )))
При наличии физического доступа к компьютеру у злоумышленника есть возможность
сделать с компьютером всё, что угодно.
Тоже при обсуждении конфигурации сервера настаивал на SSD.
Просто зачем брать диск на 500 когда будет использоваться 40-50 Гб?
Жаль что пока флеш дороговат для больших объёмов.
Думаю через пару лет даже на 1ТБ HDD уже будут редкостью.
Уже давно железо может стоит гораздо дешевле софта.
Ведь в качестве варианта можно взять само железо БУ а диски поставить новые.
Зачем SSD на DC? Там нет требований по быстродействию дисковой подсистемы. В цене — выйдет дороже. 2x500Gb б/у = 5400руб, SSD бу не встречал, новые на 40-60Gb тоже не нахожу доступных к поставке. 80Gb SSD Intel стоит от 6000 руб/шт.
А вы в DC пихаете Enterprise диски, или сойдут и обычные?
Например, те же интеловские SSD, даже для десктопа, имеют гарантию на 5 лет. И версия на 56 гигабайт стоит дешевле, чем 500 Гб HDD.
Во первых, хоть 25 лет — гарантия не гарантирует безотказность, выше кажется уже об этом упоминали. Во вторых, где вы их нашли? Дайте пруф-линк, плиз.
Спасибо, не надо, уже сам нашел. 3400 в стоке за штуку или 3100 по предзаказу, срок поставки 2 недели. Ну ок, это ваше право, ставьте SSD. )) А я вот о другом задумался — куда б использовать бесхозные 450Gb на КД с пользой для дела ))) Может выделить в отдельный том под репозиторий WDS, например?
А для безотказности есть RAID. Тем более, если цена одинакова, то почему бы не взять SSD, который будет быстрее и потреблять меньше электроэнергии? А это экономия на охлаждении и оплате счетов. То есть SSD выгоднее, даже если будет чуть дороже.
Слушайте, я, может, отстал, и CIFS опять новой версии, но раньше SAMBA рулила доменом легко… И все дела через openldap настраивались…
Тынц Может я тоже отстал? Было 2 больших проблемы: 1 — найти и не потерять того, кто это грамотно поднимет, 2 — потенциальные проблемы с масштабируемостью в перспективе. Что то изменилось с тех пор?
Б/У Dell C6100 — при цене в пределах 300к (сервак+второй БП + пачка SSD + HDD на 3ТБ резервированного хранения) — ПОЛНОСТЬЮ закрывает потребности предприятия до 200 пользователей. Причем это все реализуется на бесплатном ESXi + Ubuntu server — включая терминалы для пользователей, бекапы(хотя тут всетаки нужна внешняя машина для архива), офис, маршрутизацию, 1с, сайт + магазин и тп… и все в пределах 2-х юнитов и это со 100% резервом по всем критичным компонентам…
Во-первых, это в 2 раза дороже. Во-вторых, хотелось бы увидеть очередь из желающих, а главное — способных — все это дело поднять, сопровождать и обслуживать. В-третьих, входит ли в эти деньги резервирование по MB, контроллеру? Сколько памяти у кентавра? Какие процы и сколько их в эти деньги? Какую нагрузку генерят эти 200 пользователей? Сколько в пачке SSDшек и каких?
4 ноды — по 1 маме по 2 проца по 24GB памяти

настривается по инструкции из интеренета и реально не требует ничего сложного кроме навыка чтения и базовых знаний по системному администрированию.
не «в два раза» дороже, а полнофункциональное решение закарывающее ВСЕ нужды Небольшой компании.
Ачётакдорага-та, а? На наге ценник 90 645.24 P / шт. И чует моя опа что что-то тут не так )))
второй бп + пачка дисков(hdd+ssd), и за 90к там камни квады а не 6 ядерные
Я все пытаюсь представить, как обслуживать и ремонтировать такой комбайн. Там хотсвап дисков есть? А если вдруг умрет мамка на средней ноде, её заменить без останова соседних возможно?
Хотсвапа на ICH10 в базе вроде нет, но можно отдельно купить и поставить raid контроллер как специальный так и обычный. Hot Add есть и в базе, так что делал программную реализацию показавшую за 2 года достаточную стабильность.

В случае специального контроллера правда теряется возможность установки 10G, но это обычно не критично.

можно — image
За что люблю хабр, так это за экспертные комментарии.

«Периодически будет происходить трафик репликации, что будет нагружать сеть – но такова плата за экономию.»

«Такая схема (с двумя КД) теоретически способна выдерживать 100-200 пользователей в сети»

«От RAID можно вообще отказаться, имея второй дублирующий сервер»

«максимум проблем, которые можно поиметь с выходом основного DC из строя — то, что второй контроллер из slave надо переводить в master, а потом уже думать, что делать с первым.»

«Поэтому если уже есть сервер (почтовый, файловый или приложений) можно смело поднимать контроллер на нем. Затраты 0р при условии, что этот сервер у вас на windows.»

«Слушайте, я, может, отстал, и CIFS опять новой версии, но раньше SAMBA рулила доменом легко… И все дела через openldap настраивались…»
«Слушайте, я, может, отстал, и CIFS опять новой версии, но раньше SAMBA рулила доменом легко… И все дела через openldap настраивались…»

Настраивал так zentyal в качестве PDC. Машинки в сети разношерстные были, у кого-то linux, у бухов и кадровиков windows, у шефа MacOS. Windows машинки подключались к домену на ура. Политики тоже работали через windows remote administration tools. Несколько внутренних сервисов: jenkins, icinga, redmine — использовали общую с PDC LDAP базу.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий