Но написанное вряд ли покажется интересной и актуальной опытным сисадминам, так как она затрагивает достаточно простую задачу. Впрочем, поднимаемые в ней проблемы могут быть актуальны и для состоявшихся профессионалов, а комментарии к озвученным в этой статье рецептам от специалистов со стажем будут очень ценны.
После набора определенной «критической массы» (обычно это 15-20 пользователей) развитие сети в рамках рабочей группы увеличивает затраты человеческих ресурсов на управление инфраструктурой. При этом с ростом количества пользователей и количества используемых ими приложений, растут трудности администрирования, повышается необходимость в безопасности, стандартизации программного обеспечения, централизованном управлении политиками, которые обеспечить может только серьезная собственная инфраструктура и собственный контроллер домена.
И тут от внезапной необходимости капитальных затрат впору схватится за голову: ведь одного контроллера домена будет недостаточно, его падение будет означать остановку работы всех пользователей. Поэтому для обеспечения отказоустойчивости всей системы понадобится еще один. Ну а третий сервер, почтовый, файловый или для приложений, скорее всего и без того у вас будет.
Таким образом, в определенный момент развития компании возникает необходимость построения серьезной собственной инфраструктуры – и не с одного, а скорее сразу с трех серверов. Ее можно игнорировать, осуществляя работу в рабочих группах, но чем дольше это будет продолжаться, тем тяжелее будет перейти к доменной инфраструктуре.
Неужели нельзя как-то сгладить этот рывок? Можно! Но для этого придется прибегнуть к нескольким хитростям.
Хитрость первая: виртуализация
Затраты на три сервера (означающие также затраты на лицензии программного обеспечения для них — но об этом ниже) можно сильно уменьшить, если использовать виртуализацию для совмещения серверных ролей почтового, файлового или сервера приложений со вторым доменом контроллера.
То есть вам уже понадобится не три сервера, а один полноценный контроллер домена на физическом сервере и еще один сервер с виртуализацией контроллера домена плюс те функции, которые должен был исправлять третий сервер.
Стоит иметь в виду репликацию между двумя контроллерами. DNS и DHCP нужно будет устанавливать на обоих контроллерах домена, при этом DNS работает в дублирующем режиме, а DHCP можно разделить: часть адресов можно выдавать в аренду с одного сервера, другую с другого. Периодически будет происходить репликация, которая будет порождать трафик и нагружать сеть – но такова плата за экономию.
Такая схема теоретически способна выдерживать 100-200 пользователей в сети – тут все, конечно, будет зависеть от нагрузки каждого, но расширять такую инфраструктуру рано или поздно все равно придется, так что это неплохое решение проблемы.
Оптимальная конфигурация
Что касается подходящего для поставленной задачи железа, то для контроллера домена будет достаточно сервера со слабеньким процессором (в случае параноидальной перестраховки можно взять и с двумя, но в нашей практике был только один случай, когда и Intel отказал), 4 Гб памяти, двух дисков по 500 Гб в RAID 1 под операционную систему, еще одного диска для горячей замены и терабайтника под бэкапы. Для отказоустойчивости обязательны две сетевые карты!
А вот на втором сервере, который будет осуществлять виртуализацию, лучше не экономить! Такая же конфигурация точно не подойдет, необходима более сильная и серьезная машина: два хороших процессора, солидный объем RAM – минимум 32ГБ; два диска по 500 Гб в RAID1 под операционную систему, три терабайтника, один из которых бэкапы, а также две сетевых карты. Капитальные затраты в данном случае неизбежны, но переплаты можно избежать.
На рынке есть достаточно предложений новых серверов, которые подойдут для такой задачи: сервер домена RH1288/8-2 V3 1X2609V4/16GB/2x500&1x1TB HUAWEI HU будет стоить 172 400 рублей, а сервер приложений 2XE5-2620V4 64GB 2x500GB 2x1TB 240 000 рублей.
Можно, впрочем, взять наши бывшие в употреблении серверы: для домена подойдет ASUS RS500-E6/PS4 2xXeon E5530 16GB RAM, 2x500Gb & 1x1TB HDDs за 34 890 рублей, а под приложения SUPERMICRO SYS-6017R-NTF 2xXeon E5-2665, 64Gb RAM, 2x500Gb & 2x1TB HDDs за 124 800 рублей.
Сумма различается, как видите, значительно: 159 690 за б/у против 412 400 за новые. Очевидно, что три новых сервера были бы еще дороже.
Хитрость вторая: лицензии
Еще одна головная боль для небольшого предприятия, которое только начинает строить собственную инфраструктуру — лицензии программного обеспечения для серверов. Microsoft Windows Server 2016 Essentials Open License (поддерживает до 25 пользователей), программа, рассчитанная для первых серверов небольшого предприятия, стоит около 25 тысяч рублей. Но и тут есть возможность если не избавиться от трат вовсе, то хотя бы отложить их ни много ни мало на полгода – если использовать пробную версию, работающую 180 дней.
Только вот «Пробное использование» не подразумевает применения программного обеспечения в производственной среде. Никаких рабочих задач! Ну, по крайней мере, формально. Но ясно ведь, что никаким иным образом как следует обкатать такой софт нельзя.
Ну и, конечно, понятно, что пользователь, строивший инфраструктуру на каком-то программном обеспечении целых полгода будет гораздо сильнее привязан к вендору и просто вынужден купить у нее лицензию. И в Microsoft о такой возможности точно подумали, когда давали «на попробовать» не три дня, не неделю или две, а целых полгода! )
Выводы
Первые шаги и решения, предпринимаемые при построении инфраструктуры очень важны и могут серьезно повлиять на дальнейшее функционирование предприятия, поэтому делать их нужно осознанно. Но при этом если не решать задачу в лоб, а подойти к решению творчески, то можно серьезно сэкономить.
Вот как можно оптимизировать траты:
Таким образом, затраты получается сократить в несколько раз, а сэкономленные ресурсы лучше не перебрасывать на другие нужды, а подумать, как подготовить только зародившуюся ИТ-инфраструктуру к дальнейшему росту и расширению.
А с чего строить свою инфраструктуру начинали вы? Какие у вас рецепты?
Комментарии (49)
LoadRunner
15.02.2017 11:37+2Может я чего не понимаю, но зачем брать для контроллера домена 500 Гб? Хватает и SSD на 60 Гб. И затраты на такой сервер — 25-30 тысяч рублей, без учёта лицензий, разумеется.
От RAID можно вообще отказаться, имея второй дублирующий сервер.
Тем более, если есть файловый сервер, куда будут литься бэкапы — вот на этом уже точно не стоит экономить и уж под бэкапы обязательно нужен RAID, а не «один терабайтник».
Valeriy_Squadra
15.02.2017 12:00Брать 2 SSD на 60ГБ или 2 500 ГБ SATA (возможно, бу) — тут все упирается в деньги, какое решение более подходит под бюджет, такое лучше и выбрать.
Что зеркалить — вопрос дискуссионный. При выходе из строя одного из дисков многие предпочтут иметь живой DC, чем восстанавливать его из бэкапов.
по поводу зеркала на бэкапы — тут смотря какие бэкапы. Если там только бэкапы самого контроллера, то нет особого смысла их зеркалить, а если что-то еще будет туда бэкапится, тогда да, нужно зеркало. В рассматриваемом случае имелось ввиду, что на этот диск бэкапится только сам DC, а остальное (виртуальные машины, файловые шары и БД) бэкапятся на другой массив, и вот там уже да, зеркало.
В описанном случае необходимость в Raid обусловлена тем, что диски у нас тоже б/у, причем он интегрированный, так что кроме стоимости 2-го диска и небольшой доп.нагрузки на CPU этот рейд ничего не стоит в плане затратLoadRunner
15.02.2017 12:43Вы же понимаете, что в случае критичных данных вариант «один SATA» — не вариант, потому что надёжность и корректность таких данных под вопросом?
Конечно, при переходе от рабочих групп к домену хочется сэкономить. Но экономить на дисках, у которых стоимость в разы отличается от стоимости лицензий — это экономия на спичках, причём совершенно ненужная и опасная.
Да и максимум проблем, которые можно поиметь с выходом основного DC из строя — то, что второй контроллер из slave надо переводить в master, а потом уже думать, что делать с первым.Valeriy_Squadra
15.02.2017 13:00Не вполне понятно, о чем вы — о бу-дисках? Но использование новых дисков никак не гарантирует их безупречность и отказоустойчивость, гарантируется лишь их бесплатная замена. Примеров, когда новые диски сыплются хоть отбавляй. Для этого Raid и нужен. А какие диски туда поставить, это уже вопрос возможностей бюджета.
С выходом из строя основного контроллера домена при наличии второго инфраструктура продолжит работать и пользователи ничего не заметят. В этом и есть весь смысл иметь 2-ой КД. А вот использовать на КД один сата без зеркала — это и есть экономия на спичках.LoadRunner
15.02.2017 13:15Ну б\у диски тоже не гарантируют качества и надёжности. Им-то как раз меньше доверия. А брак в партии новых дисков — вполне обычная вещь. Мои основные претензии к выбору дисков под бэкапы, пусть даже если туда бэкапится только КД (и вопрос ещё — чем бэкапится. Если Windows Archive, то терабайтник тут перебор, а уж если диск под бэкапы на той же машине — тем более сомнительно всё это выглядит).
А ещё, как правило, у малых организаций под бэкапы уже есть NAS какой-нибудь и его вполне достаточно будет.
Поэтому смысла пичкать КД дисками нет, соответственно, нет смысла покупать полноразмерный сервер. Потому что про стоимость владения забывать тоже не стоит.Valeriy_Squadra
15.02.2017 13:371. В т.ч. поэтому нужен Raid.
2. По размеру — может и перебор, но больше — не меньше. Если есть желание поставить диск поменьше или утилизировать побольше — ради бога.
3. Про NAS — если есть, то да. Но если нет — диск в сервере будет дешевле, чем NAS, да и умрет NAS быстрее, чем выделенный только под бэкапы DC диск. Мухи отдельно, котлеты отдельно. Но это уже вопрос выбора в каждой конкретной ситуации.LoadRunner
15.02.2017 14:43Мухи отдельно, котлеты отдельно.
Не стоит складывать все яйца в одну корзину. Откажет сервер и толку нам от диска с бэкапами, который внутри вышедшей из строя машины?
Вообще, в каком сценарии Ваш вариант с одним диском на той же машине позволяет без проблем восстановить нужные данные из бэкапа и это выгоднее, чем бэкапы на сетевое расположение?
Вот сценарии, где этот вариант проигрывает:
Пропадает электропитание — головка HDD паркуется неправильно и приплыли.
Пошли невосстановимые ошибки системы и надо либо переустановить всё (если бэкапим только базу КД), либо восстановить из образа системы — так Windows Archive не делает полный бэкап системы на диск, принадлежащий этой же системе. Да и инкрементный не делает.
Использовать не Windows Archive, а контрольные точки — это опять же привязка к текущей системе, а вне её будет очень проблематично восстанавливать нужную информацию, что сводит на нет такой способ.Valeriy_Squadra
15.02.2017 15:25Насчет расположения диска с бэкапами на том же сервере — никто и не настаивает именно на таком решении, это лишь один из вариантов.
Есть принципиально 3 наиболее вероятных точки отказа на КД — это HDD, БП и MB. CPU — маловероятно. HDD у нас в рэйде. БП крайне желательно иметь в зипе. Ну, а если MB умрет, какая разница где бэкап лежит? Лишь бы он был. Какие бэкапы и каким софтом делать — это отдельная тема. Мы делаем штатными средствами, через Windows Server Backup по сценарию Full server.LoadRunner
15.02.2017 15:44Если КД один и умирает MB (или любое другое железо) — то стоит иметь запасную в холодном резерве. Не такие уж и большие расходы (тем более, их можно растянуть во времени) для бесперебойной работы и малого времени простоя.
Да и второй КД тоже можно докупить со временем. Расходы не обязательно могут быть единомоментны.Valeriy_Squadra
15.02.2017 15:54Чем отличается второй КД в инфраструктуре от зипа для КД? Минусом корпус, плюсом — время на ремонт и восстановление. Стоит оно того?
LoadRunner
15.02.2017 16:18В идеале холодный резерв должен быть в дополнение к двум КД.
Потому что второй, третий, четвёртый и так далее КД — это не главный КД в инфраструктуре, главный всегда в единственном экземпляре, и при выходе его из строя лучше его и восстанавливать как можно быстрее, чем перенастраивать дублирующие.Valeriy_Squadra
15.02.2017 16:38Понятие главного КД — преданья седины глубокой. Мы говорим о первом и единственном домене в первом и единственном лесу. Роль GC MS рекомендует поднимать на каждом КД в домене. В данном случае у нас не будет ГЛАВНЫХ и НЕглавных контроллеров, в этом вся прелесть. Остальные роли могут быть просто захвачены любым контроллером по желанию Администратора, лишь бы этот КД был GC.
Nordicx86
16.02.2017 09:03Главную ТО забыли — пользователь.
Бекапы должны быть 3-х уровневыми:
1. Диск на сервере который бекапим — допустимо при ГАРАНТИИ полного восстановления из Архива;
2. Архив на Отдельном сервере — максимально удаленном ФИЗИЧЕСКИЙ от первого сервера;
3. Внешний диск в машине админа/ДИТ/ДСБ — таких дисков должно быть 3 один в сейфе в банке, второй в сейфе в конторе третий в работе и ротаци не реже ОДНОГО раза в месяц.
И самое главное — раз в Квартал(лучше раз в месяц) генерал/дит/дсб — должны Видеть и проверять как Админ восстанавливает с ПОСЛЕДНЕГО бекапа хотя бы по одному ключевому компоненту системы(ДБ, КД, Архив Документов пользователей).
и то есть шансы просрать все… опыт…Valeriy_Squadra
16.02.2017 14:49Схема резервного копирования должна обеспечивать восстановление работоспособности критических сервисов и данных. Чем глубже паранойя, тем больше шансов))
badmilkman
15.02.2017 12:11Немого ошиблись с определением «критической массы». Меньше 100 пользователей это все еще малый бизнес — с соответствующим бюджетом на IT.
Ставить 2 сервера (пусть и один виртуальный) только для удобства управления доступами или любознательности админа никто в здравом уме не будет. А еще и лицензии покупать.
Обычно все ограничивается самосборным файловым/почтовым/прокси сервером.
Исключительно по экономическим причинам, или после проверки ПО на легальность.Valeriy_Squadra
15.02.2017 12:11Малый с какой точки зрения? Существуют предприятия с численностью 40 человек и оборотами на сотни миллионов в месяц. С точки зрения налогообложения это уже ни разу не малый бизнес.
Второй сервер ведь нужен не для удобства или экспериментов, а для отказоустойчивости инфраструктуры, дабы не остановились бизнес-процессы из-за какого-нибудь сбоя на мат.плате или в БП например.badmilkman
15.02.2017 16:33Да вы правы, не сразу заметил что это платный блог.
Зная я несколько подобных компаний с большими оборотами (8 человек, AD, Exchange, Docvision) там реальная работа — по старинке, в смысле бумажными документами.
Но сегодня есть куда более интересный вариант — полностью работать в облаках, что и выбирают начинающие стартаперы
Valeriy_Squadra
16.02.2017 14:51И как только начинающие стартаперы через год осознают себя окрепшим малым бизнесом, начинается миграция либо в приватное облако, либо в локальную инфраструктуру.
pu5her
15.02.2017 12:43И тут от внезапной необходимости капитальных затрат впору схватится за голову: ведь одного контроллера домена будет недостаточно, его падение будет означать остановку работы всех пользователей.
Не будет если настроить кеширование входа в домен. Поэтому если уже есть сервер (почтовый, файловый или приложений) можно смело поднимать контроллер на нем. Затраты 0р при условии, что этот сервер у вас на windows.Valeriy_Squadra
15.02.2017 12:43Так мы теряем не только контроллер, но и те сервисы, которые жили рядом + получаем периодическую деградацию производительности, на таком сервере она гарантирована. Кэширование — это костыль, имеющий очевидную проблему с безопасностью и управлением.
При наличии физического доступа к компьютеру у злоумышленника есть возможность воспользоваться сохраненными учетными данными, то для повышения безопасности рекомендуется отключать локальное кэширование.pu5her
15.02.2017 12:50Откуда взялась деградация производительности? От того что на сервер добавили роль контроллера домена?
Кеширование это не костыль а функция имеющая очевидную пользу при отсутствии резервирования контроллера домена.
Расскажите про очевидные проблемы с безопасностью и управлением. Мне они не очевидны.Valeriy_Squadra
15.02.2017 13:19Деградация производительности случится от трафика репликации, если есть другие КД, от трафика инфраструктурных сервисов и нагрузки от них на CPU, RAM и HDD.
Кэширование предназначено для входа в ОС при отсутствии доступа к КД. При этом у пользователя нет доступа к Active Directory, следовательно, нет доступа к сетевым ресурсам и сервисам. Что толку в корпоративной среде от того, что пользователь вошёл в ОС локально с использованием кэша?
Он максимум будет иметь только доступ к локально сохраненным файлам и папкам. А что делать с DNS и DHCP в случае падения единственного КД? Кэширование входа в домен подходит только для использования на мобильных устройств за пределами домена, но никак не в качестве замены упавшему КД.
Совмещать инфраструктурные роли с прочими ролями технически возможно, но крайне не рекомендуется MS и best practice.pu5her
15.02.2017 13:31Деградация производительности случится от трафика репликации, если есть другие КД, от трафика инфраструктурных сервисов и нагрузки от них на CPU, RAM и HDD.
Стоп, стоп, стоп. Откуда у нас взялись другие КД? У нас же был один сервер с почтой файлами и приложениями.
Кэширование предназначено для входа в ОС при отсутствии доступа к КД. При этом у пользователя нет доступа к Active Directory, следовательно, нет доступа к сетевым ресурсам и сервисам. Что толку в корпоративной среде от того, что пользователь вошёл в ОС локально с использованием кэша?
У него есть интернет (если мы его раздаем через роутер, а не через этот же сервер), есть Word, есть Excel. Уже можно жить)
Он максимум будет иметь только доступ к локально сохраненным файлам и папкам. А что делать с DNS и DHCP в случае падения единственного КД? Кэширование входа в домен подходит только для использования на мобильных устройств за пределами домена, но никак не в качестве замены упавшему КД.
А что мы до этого делали с DNS и DHCP, когда у нас не было КД, но так же был один сервер?
Роль КД добавленная на единственный сервер не сильно повлияет на надежность. У нас по прежнему будет большая точка отказа в виде сервера.Valeriy_Squadra
15.02.2017 13:43Ну вот и мы и пришли к общему знаменателю!))) Должно быть 2 КД — или оставаться в рабочей группе.
Сеть с доменом на одном КД — это бомба с часовым механизмом.pu5her
15.02.2017 13:49Нет, я не согласен))) КД имеет смысл поднимать даже на одном сервере. Плюсы появятся, а минусы останутся теже.
asv909
15.02.2017 15:57Плюсы то появятся, но и риски простоев из-за отказа в узком месте тоже появятся. Если не планировать второй КД — это выстрел в ногу раньше или позже. А если планировать, так почему не сразу? Не такой уж большой будет бюджет по сценарию из данной статьи, не?
pu5her
15.02.2017 16:12Риски новые не появятся. Если исходить из того, что уже был сервер для файлов, почты и 1с, то поднятие КД незначительно увеличит риски (сервер не работает — все лежит, независимо от того есть КД или нет).
Если есть бюджет, то вопросов нет. Я бы тоже зарезервировался по железу. Просто я не согласен с тем что КД можно поднимать только в паре. Я считаю, что даже если нет бюджета на второй сервер, КД на одном сервере принесет пользу.asv909
15.02.2017 18:41Тут я думаю будет сильно от нагрузки зависеть. Если сервер сильно нагружен, то польза может выйти боком. Про траблшутинг такого кентавра лучше к ночи не упоминать. )))
LoadRunner
15.02.2017 13:16При наличии физического доступа к компьютеру у злоумышленника есть возможность
сделать с компьютером всё, что угодно.
Arxitektor
15.02.2017 14:09Тоже при обсуждении конфигурации сервера настаивал на SSD.
Просто зачем брать диск на 500 когда будет использоваться 40-50 Гб?
Жаль что пока флеш дороговат для больших объёмов.
Думаю через пару лет даже на 1ТБ HDD уже будут редкостью.
Уже давно железо может стоит гораздо дешевле софта.
Ведь в качестве варианта можно взять само железо БУ а диски поставить новые.asv909
15.02.2017 15:46Зачем SSD на DC? Там нет требований по быстродействию дисковой подсистемы. В цене — выйдет дороже. 2x500Gb б/у = 5400руб, SSD бу не встречал, новые на 40-60Gb тоже не нахожу доступных к поставке. 80Gb SSD Intel стоит от 6000 руб/шт.
LoadRunner
15.02.2017 16:23А вы в DC пихаете Enterprise диски, или сойдут и обычные?
Например, те же интеловские SSD, даже для десктопа, имеют гарантию на 5 лет. И версия на 56 гигабайт стоит дешевле, чем 500 Гб HDD.asv909
15.02.2017 17:34Во первых, хоть 25 лет — гарантия не гарантирует безотказность, выше кажется уже об этом упоминали. Во вторых, где вы их нашли? Дайте пруф-линк, плиз.
asv909
15.02.2017 18:34Спасибо, не надо, уже сам нашел. 3400 в стоке за штуку или 3100 по предзаказу, срок поставки 2 недели. Ну ок, это ваше право, ставьте SSD. )) А я вот о другом задумался — куда б использовать бесхозные 450Gb на КД с пользой для дела ))) Может выделить в отдельный том под репозиторий WDS, например?
LoadRunner
16.02.2017 08:29А для безотказности есть RAID. Тем более, если цена одинакова, то почему бы не взять SSD, который будет быстрее и потреблять меньше электроэнергии? А это экономия на охлаждении и оплате счетов. То есть SSD выгоднее, даже если будет чуть дороже.
Spiritschaser
15.02.2017 18:47Слушайте, я, может, отстал, и CIFS опять новой версии, но раньше SAMBA рулила доменом легко… И все дела через openldap настраивались…
Nordicx86
16.02.2017 09:11Б/У Dell C6100 — при цене в пределах 300к (сервак+второй БП + пачка SSD + HDD на 3ТБ резервированного хранения) — ПОЛНОСТЬЮ закрывает потребности предприятия до 200 пользователей. Причем это все реализуется на бесплатном ESXi + Ubuntu server — включая терминалы для пользователей, бекапы(хотя тут всетаки нужна внешняя машина для архива), офис, маршрутизацию, 1с, сайт + магазин и тп… и все в пределах 2-х юнитов и это со 100% резервом по всем критичным компонентам…
Valeriy_Squadra
16.02.2017 15:10Во-первых, это в 2 раза дороже. Во-вторых, хотелось бы увидеть очередь из желающих, а главное — способных — все это дело поднять, сопровождать и обслуживать. В-третьих, входит ли в эти деньги резервирование по MB, контроллеру? Сколько памяти у кентавра? Какие процы и сколько их в эти деньги? Какую нагрузку генерят эти 200 пользователей? Сколько в пачке SSDшек и каких?
Nordicx86
16.02.2017 15:184 ноды — по 1 маме по 2 проца по 24GB памяти
настривается по инструкции из интеренета и реально не требует ничего сложного кроме навыка чтения и базовых знаний по системному администрированию.
не «в два раза» дороже, а полнофункциональное решение закарывающее ВСЕ нужды Небольшой компании.asv909
16.02.2017 15:53Ачётакдорага-та, а? На наге ценник 90 645.24 P / шт. И чует моя опа что что-то тут не так )))
Nordicx86
16.02.2017 16:04второй бп + пачка дисков(hdd+ssd), и за 90к там камни квады а не 6 ядерные
asv909
18.02.2017 01:34Я все пытаюсь представить, как обслуживать и ремонтировать такой комбайн. Там хотсвап дисков есть? А если вдруг умрет мамка на средней ноде, её заменить без останова соседних возможно?
Nordicx86
18.02.2017 09:35Хотсвапа на ICH10 в базе вроде нет, но можно отдельно купить и поставить raid контроллер как специальный так и обычный. Hot Add есть и в базе, так что делал программную реализацию показавшую за 2 года достаточную стабильность.
В случае специального контроллера правда теряется возможность установки 10G, но это обычно не критично.
можно —
whiplash
16.02.2017 13:15+1За что люблю хабр, так это за экспертные комментарии.
«Периодически будет происходить трафик репликации, что будет нагружать сеть – но такова плата за экономию.»
«Такая схема (с двумя КД) теоретически способна выдерживать 100-200 пользователей в сети»
«От RAID можно вообще отказаться, имея второй дублирующий сервер»
«максимум проблем, которые можно поиметь с выходом основного DC из строя — то, что второй контроллер из slave надо переводить в master, а потом уже думать, что делать с первым.»
«Поэтому если уже есть сервер (почтовый, файловый или приложений) можно смело поднимать контроллер на нем. Затраты 0р при условии, что этот сервер у вас на windows.»
«Слушайте, я, может, отстал, и CIFS опять новой версии, но раньше SAMBA рулила доменом легко… И все дела через openldap настраивались…»SchmeL
16.02.2017 15:15«Слушайте, я, может, отстал, и CIFS опять новой версии, но раньше SAMBA рулила доменом легко… И все дела через openldap настраивались…»
Настраивал так zentyal в качестве PDC. Машинки в сети разношерстные были, у кого-то linux, у бухов и кадровиков windows, у шефа MacOS. Windows машинки подключались к домену на ура. Политики тоже работали через windows remote administration tools. Несколько внутренних сервисов: jenkins, icinga, redmine — использовали общую с PDC LDAP базу.
diger
Статья опоздала лет на пять?
asv909
В каком смысле? Придумали что-то новое взамен сети с доменом?