Так мы не писали — только перевели; статья же не про протокол, а про программный продукт, приглашение обсудить, достаточно ли ее будет для удовлетворения всех сегодняшних нужд или еще нет.
Во-первых, это в 2 раза дороже. Во-вторых, хотелось бы увидеть очередь из желающих, а главное — способных — все это дело поднять, сопровождать и обслуживать. В-третьих, входит ли в эти деньги резервирование по MB, контроллеру? Сколько памяти у кентавра? Какие процы и сколько их в эти деньги? Какую нагрузку генерят эти 200 пользователей? Сколько в пачке SSDшек и каких?
И как только начинающие стартаперы через год осознают себя окрепшим малым бизнесом, начинается миграция либо в приватное облако, либо в локальную инфраструктуру.
Схема резервного копирования должна обеспечивать восстановление работоспособности критических сервисов и данных. Чем глубже паранойя, тем больше шансов))
Понятие главного КД — преданья седины глубокой. Мы говорим о первом и единственном домене в первом и единственном лесу. Роль GC MS рекомендует поднимать на каждом КД в домене. В данном случае у нас не будет ГЛАВНЫХ и НЕглавных контроллеров, в этом вся прелесть. Остальные роли могут быть просто захвачены любым контроллером по желанию Администратора, лишь бы этот КД был GC.
Насчет расположения диска с бэкапами на том же сервере — никто и не настаивает именно на таком решении, это лишь один из вариантов.
Есть принципиально 3 наиболее вероятных точки отказа на КД — это HDD, БП и MB. CPU — маловероятно. HDD у нас в рэйде. БП крайне желательно иметь в зипе. Ну, а если MB умрет, какая разница где бэкап лежит? Лишь бы он был. Какие бэкапы и каким софтом делать — это отдельная тема. Мы делаем штатными средствами, через Windows Server Backup по сценарию Full server.
2. По размеру — может и перебор, но больше — не меньше. Если есть желание поставить диск поменьше или утилизировать побольше — ради бога.
3. Про NAS — если есть, то да. Но если нет — диск в сервере будет дешевле, чем NAS, да и умрет NAS быстрее, чем выделенный только под бэкапы DC диск. Мухи отдельно, котлеты отдельно. Но это уже вопрос выбора в каждой конкретной ситуации.
Деградация производительности случится от трафика репликации, если есть другие КД, от трафика инфраструктурных сервисов и нагрузки от них на CPU, RAM и HDD.
Кэширование предназначено для входа в ОС при отсутствии доступа к КД. При этом у пользователя нет доступа к Active Directory, следовательно, нет доступа к сетевым ресурсам и сервисам. Что толку в корпоративной среде от того, что пользователь вошёл в ОС локально с использованием кэша?
Он максимум будет иметь только доступ к локально сохраненным файлам и папкам. А что делать с DNS и DHCP в случае падения единственного КД? Кэширование входа в домен подходит только для использования на мобильных устройств за пределами домена, но никак не в качестве замены упавшему КД.
Совмещать инфраструктурные роли с прочими ролями технически возможно, но крайне не рекомендуется MS и best practice.
Не вполне понятно, о чем вы — о бу-дисках? Но использование новых дисков никак не гарантирует их безупречность и отказоустойчивость, гарантируется лишь их бесплатная замена. Примеров, когда новые диски сыплются хоть отбавляй. Для этого Raid и нужен. А какие диски туда поставить, это уже вопрос возможностей бюджета.
С выходом из строя основного контроллера домена при наличии второго инфраструктура продолжит работать и пользователи ничего не заметят. В этом и есть весь смысл иметь 2-ой КД. А вот использовать на КД один сата без зеркала — это и есть экономия на спичках.
Так мы теряем не только контроллер, но и те сервисы, которые жили рядом + получаем периодическую деградацию производительности, на таком сервере она гарантирована. Кэширование — это костыль, имеющий очевидную проблему с безопасностью и управлением.
При наличии физического доступа к компьютеру у злоумышленника есть возможность воспользоваться сохраненными учетными данными, то для повышения безопасности рекомендуется отключать локальное кэширование.
Малый с какой точки зрения? Существуют предприятия с численностью 40 человек и оборотами на сотни миллионов в месяц. С точки зрения налогообложения это уже ни разу не малый бизнес.
Второй сервер ведь нужен не для удобства или экспериментов, а для отказоустойчивости инфраструктуры, дабы не остановились бизнес-процессы из-за какого-нибудь сбоя на мат.плате или в БП например.
Брать 2 SSD на 60ГБ или 2 500 ГБ SATA (возможно, бу) — тут все упирается в деньги, какое решение более подходит под бюджет, такое лучше и выбрать.
Что зеркалить — вопрос дискуссионный. При выходе из строя одного из дисков многие предпочтут иметь живой DC, чем восстанавливать его из бэкапов.
по поводу зеркала на бэкапы — тут смотря какие бэкапы. Если там только бэкапы самого контроллера, то нет особого смысла их зеркалить, а если что-то еще будет туда бэкапится, тогда да, нужно зеркало. В рассматриваемом случае имелось ввиду, что на этот диск бэкапится только сам DC, а остальное (виртуальные машины, файловые шары и БД) бэкапятся на другой массив, и вот там уже да, зеркало.
В описанном случае необходимость в Raid обусловлена тем, что диски у нас тоже б/у, причем он интегрированный, так что кроме стоимости 2-го диска и небольшой доп.нагрузки на CPU этот рейд ничего не стоит в плане затрат
Мы говорим о принципиально разном уровне резервирования: требования к оборудованию будут сильно отличаться, и стоимость решений, соответственно, тоже. В разы, если не в десятки раз. А так, да, справедливое замечание))
Резервирование в предложенном вами случае желательно, в случае с серверным оборудованием — строго обязательно.
Ну и да, Google-то его не продает никому, сам использует, и всю эту информацию вряд ли обнародовать захочет.
Есть принципиально 3 наиболее вероятных точки отказа на КД — это HDD, БП и MB. CPU — маловероятно. HDD у нас в рэйде. БП крайне желательно иметь в зипе. Ну, а если MB умрет, какая разница где бэкап лежит? Лишь бы он был. Какие бэкапы и каким софтом делать — это отдельная тема. Мы делаем штатными средствами, через Windows Server Backup по сценарию Full server.
Сеть с доменом на одном КД — это бомба с часовым механизмом.
2. По размеру — может и перебор, но больше — не меньше. Если есть желание поставить диск поменьше или утилизировать побольше — ради бога.
3. Про NAS — если есть, то да. Но если нет — диск в сервере будет дешевле, чем NAS, да и умрет NAS быстрее, чем выделенный только под бэкапы DC диск. Мухи отдельно, котлеты отдельно. Но это уже вопрос выбора в каждой конкретной ситуации.
Кэширование предназначено для входа в ОС при отсутствии доступа к КД. При этом у пользователя нет доступа к Active Directory, следовательно, нет доступа к сетевым ресурсам и сервисам. Что толку в корпоративной среде от того, что пользователь вошёл в ОС локально с использованием кэша?
Он максимум будет иметь только доступ к локально сохраненным файлам и папкам. А что делать с DNS и DHCP в случае падения единственного КД? Кэширование входа в домен подходит только для использования на мобильных устройств за пределами домена, но никак не в качестве замены упавшему КД.
Совмещать инфраструктурные роли с прочими ролями технически возможно, но крайне не рекомендуется MS и best practice.
С выходом из строя основного контроллера домена при наличии второго инфраструктура продолжит работать и пользователи ничего не заметят. В этом и есть весь смысл иметь 2-ой КД. А вот использовать на КД один сата без зеркала — это и есть экономия на спичках.
При наличии физического доступа к компьютеру у злоумышленника есть возможность воспользоваться сохраненными учетными данными, то для повышения безопасности рекомендуется отключать локальное кэширование.
Второй сервер ведь нужен не для удобства или экспериментов, а для отказоустойчивости инфраструктуры, дабы не остановились бизнес-процессы из-за какого-нибудь сбоя на мат.плате или в БП например.
Что зеркалить — вопрос дискуссионный. При выходе из строя одного из дисков многие предпочтут иметь живой DC, чем восстанавливать его из бэкапов.
по поводу зеркала на бэкапы — тут смотря какие бэкапы. Если там только бэкапы самого контроллера, то нет особого смысла их зеркалить, а если что-то еще будет туда бэкапится, тогда да, нужно зеркало. В рассматриваемом случае имелось ввиду, что на этот диск бэкапится только сам DC, а остальное (виртуальные машины, файловые шары и БД) бэкапятся на другой массив, и вот там уже да, зеркало.
В описанном случае необходимость в Raid обусловлена тем, что диски у нас тоже б/у, причем он интегрированный, так что кроме стоимости 2-го диска и небольшой доп.нагрузки на CPU этот рейд ничего не стоит в плане затрат
Резервирование в предложенном вами случае желательно, в случае с серверным оборудованием — строго обязательно.