Windows: Чи можуть контролери домену також виконувати інші функції?


11

Це питання було дискусією щодо того, чи потрібен Active Directory для запуску термінальних служб. Але ланцюжок відповідей та зауважень (в основному я) поставила відповідне запитання щодо Контролерів доменів.

Очевидно погана практика мати лише один контролер домену в середовищі AD. Очевидно найкращою практикою є кожен контролер домену на окремому (фізичному чи віртуальному) єдиному функціональному сервері. Однак далеко не кожен може постійно дотримуватися найкращих практик.

Чи добре використовувати сервери, які заповнюють інші ролі як контролери домену?

Які речі слід враховувати при визначенні того, чи потрібно "двоцільовий" сервер?

Чи змінюється роль контролера домену в тому, як Windows працює з файловою системою або на апаратному забезпеченні?

Чи є різниця між версіями Windows Server?


Кара .. чому ви додали тег "кращі практики"? Я досить чітко зазначив, що мова йде про те, як не слідувати кращим практикам щодо контролерів домену. Крім того, набоби, що розсипають "MS не підтримує" або "це не найкраща практика", нічого не сприятимуть і захаращуватимуть те, що, сподіваюся, буде хорошими відгуками щодо вирішення проблеми за невеликий $.
tomjedrz

1
Насправді я вважаю, що Кара має рацію додавати кращі практики. Найкращі практики - це щось неправильне, це означає «проблеми на осі хорошої / поганої практики», ніколи не буде тегів поганих практик!
Крістофер Едвардс

+1 за останній тег :)
kubanczyk

Я подумав, що це відповідна посилання на AoD. :)
Avery Payne

Відповіді:


3

Можна і це працює. У мене близько 40 відділень і - з політичних причин - було прийнято управлінське рішення про надання кожному повноцінної серверної інфраструктури. З фінансових причин це було середовище з одним сервером у кожному, тому це все DC / File / Exchange (це було в Windows 2000 днів).

Однак управління ним - це кошмар, і моє улюблене правило - «постійний струм - це постійний струм, і більше нічого на ньому не йде». Це ваші найважливіші сервери, і якщо ваш AD буде смішним, у вас буде жахливий час повернути його правильно. Якщо можете, дайте собі найкращий шанс уникнути цього, виділивши присвячені ролі постійного струму. Якщо ви не можете, благайте, кричіть, хихикайте, підкупуйте, погрожуйте, пророкуйте або що завгодно, щоб поставити себе в таке становище, де можете.


Чи можете ви детальніше зупинитися на твердженні "управління - це кошмар"?
tomjedrz

1
Окрім 40 віддалених серверів, на яких немає ІТ-персоналу на місці, розподіл ролей сервера на окремі ящики робить вас в дуже приємному становищі, де ви можете робити технічне обслуговування однієї коробки, не зачіпаючи інших. Крім того, розміщення дивного та невмілого стороннього програмного забезпечення (я говорю тут драйвери принтерів) на постійному струмі не відповідає моїм чутливості. По-третє, ви хочете, щоб ваші журнали подій постійного струму були пискими чистими, ви не хочете незначного серцевого нападу будь-коли, коли ви отримуєте попередження про безпеку або систему від одного з них!
Максим Мінімус

18

Контролери домену з кількома ролями є досить поширеними. Хоча більшість ролей, які вони виконують, - це ролі мережевої інфраструктури. Хорошими прикладами є файлові сервери, DHCP та DNS. Вони є поганим вибором для таких речей, як сервери терміналів (користувачі не мають права входити в контролер домену та надавати їм зазначені права, вимагає адміністраторів домену), серверів веб-додатків, серверів ліній бізнес-серверів, серверів брандмауера / проксі / ISA тощо

У моїх умовах я вважаю за краще, щоб усі внутрішні DNS-сервери працювали на контролерах домену, а також мої служби DHCP. Це, здається, є гарним поєднанням ролей на постійних комп'ютерах, щоб знизити витрати та максимально використати обладнання.


1
Я не бачу жодної проблеми з DC, які роблять DHCP і DNS. І якщо у вас немає файлу з високим завантаженням, друк також добре. SBS є постійним клієнтом і робить все, що завгодно (крім термінальних послуг, що є поганою ідеєю на кожному рівні).
Крістофер Едвардс

4
  • Чи добре використовувати сервери, які заповнюють інші ролі як контролери домену?

"Ви навіть можете вирізати консервну банку, але цього не хотіли б!" - Пан Попель , слова Weird Al Yankovic

Я здогадуюсь питання: ти хочеш? Звичайно, ви можете перетворити контролер домену на сервер файлів і друку, або в поле SQL Server або будь-яку кількість інших функцій. Але в цьому є і мінус - ціна, яку потрібно заплатити у вигляді погіршеної функціональності на цьому полі. Якщо у вас дуже мало користувачів (скажімо, у віці до 25-50 років) або вас стикають бюджетні обмеження, і вам потрібно зробити це поле "все в одному", ви можете піти з цього. Але існують проблеми з роботою, проблеми із безпекою та навіть потенціал несумісності між службами. Робити "все в одному" поля - це функція злих бюджетів, встановлених власниками закупівлі, які не розуміють ціну, яку вони заплатять.

Якщо ви можете собі це дозволити, поставте контролер домену в окремий ящик. Чорт забирай, якщо це взагалі можливо, придбай дешевий, але серверний клас вірогідного вірогідного вікна на рівні відділу, і поклади на це послуги DC потім отримайте близнюк цього вікна і також покладіть на нього служби постійного струму. Це та модель, якою ви хотіли б мати Windows, і ви дійсно, дійсно , повинні мати принаймні два контролери домену для кожного домену.

Купуйте ящики для тих, хто використовується найбільше - бази даних, електронна пошта, файли та друк тощо. Це "повсякденні" вікна, які користувачі регулярно бачать; контролери домену найкраще залишати облікові дані користувачів з резиновим штампом у домені.

  • Які речі слід враховувати при визначенні того, чи потрібно "двоцільовий" сервер?

Чи можете ви піти з погіршеним рівнем виконання? Чи буде несумісність між службою, яку ви встановлюєте, та будь-якими іншими службами, які можуть працювати? Чи буде це заважати аутентифікації AD?

  • Чи змінюється роль контролера домену в тому, як Windows працює з файловою системою або на апаратному забезпеченні?

Ні. Але це збільшить його навантаження. І якщо ви інтегруєте інші функції, не для Windows (скажімо, використовуючи стек PAM для автентифікації вікна Linux через Kerberos як частину послуги IMAP), тоді очікуйте, що навантаження збільшиться.

  • Чи є різниця між версіями Windows Server?

Кожен випуск збільшує кількість функцій, хоча з упевненістю можна сказати, що ви хоч би хоч Windows 2000, якщо не краще. Більшість людей перебуває на Windows 2003 (і двоюрідних братів), що включає в себе вдосконалення файлових служб, тіньову копію тощо. 2008 передбачає ще більше вдосконалень.


4

Сервер для малого бізнесу Microsoft - це AD + Exchange + файловий сервер + маршрутизатор / VPN-сервер + Sharepoint + SQL Server .. і багато іншого - все це об'єднано в єдиний сервер. Тож я б не сказав, що її "найкраща практика" мати кожну функцію на іншому сервері. Для невеликих операцій не має сенсу запускати все в іншому обладнання.


1

Схоже, це зводиться до безпеки та продуктивності. Я не думаю, що ефективність не є великою проблемою в невеликих мережах, AD використовує незначну кількість найдешевшого сервера, який ви могли б скласти зараз.

У цей момент ви можете просто зважити безпеку порівняно з вартістю - ось до чого зводиться всі питання безпеки у невеликій мережі ...


1

Я думаю, що всі відповіді можна підсумувати сервером малого бізнесу.

Звичайно, MS змогла кинути майже ВСЕ (AD, Exchange, SQL тощо) на один ящик. Але він працює як лайно і корисний лише у дуже обмежених ситуаціях.


1

Словом, ти можеш це зробити? Так. Чи варто це робити? Я не рекомендую, але це може спрацювати, якщо вас чекають.

З точки зору ефективності, це залежить від завантаженості двох служб. У меншій мережі постійний струм може також без проблем працювати як DNS або DHCP-сервер. У більшій мережі це вимагає неприємностей.

Я дуже рекомендую, що ви не ставите більше одного "основного" сервера на один і той же фізичний ящик. IE, якщо це ваш головний DC, використання його як вторинного DNS-сервера або резервного сервера DHCP було б прийнятним. Причиною цього є те, що ви не хочете, щоб на одному ящику вийшов з ладу вивезти дві послуги.

Я б дуже відштовхував кого-небудь від запуску більш складних служб, таких як веб-сервер (IIS або Apache тощо) або будь-якої бази даних.

Якщо ви все-таки вирішите запустити більше одного типу сервісу в одній фізичній коробці, я б дуже рекомендував отримати якомога більше "полегшеного" вікна та використовувати його як хост для віртуалізованих серверів. Таким чином, всі ваші послуги все ще дещо не залежать один від одного на рівні ОС.


0

Не існує нічого, що по суті заперечує контролер домену від функціонування в інших можливостях.

Якщо у вас є існуюча інфраструктура AD і у вас є лише один контролер домену, я б сказав, що будь-які недоліки просування іншого сервера будуть переважені переваги отримання іншого постійного струму.

Пам’ятайте, що після запуску dcpromo вам доведеться перезавантажити, тому будь-які послуги, що надаються новоспеченою машиною, будуть перервані. Крім того, якщо у вас є якісь політики безпеки контролера домену, вони застосовуватимуться до цього сервера.


Все, на що користувач повинен увійти (він згадав про послуги терміналу), не може бути на постійному струмі, якщо всі користувачі не є членами домену адміністраторів.
Кевін Колбі

Це не зовсім так. Існує програмне забезпечення на рівні сервера (наприклад, MS Team Foundation Server), яке не може встановлюватися на контролер домену.
NotMe

Не можна змінити політику безпеки контролера домену, щоб дозволити це? (не те, що я припускаю, що це гарна ідея, але, здається, батьки знають, що це не найкраща ідея)
Метт Сіммонс,

0

Ви могли б, але чому б ви хотіли? Теоретично ви можете мати цілий куточок служб на одному боксі (Small Business Server). Однак те, що МОЖЕТЕ щось зробити, не означає, що слід. Контролер домену зберігає базу даних AD, тому якщо ви хочете ризикувати замикання з друком (і не дай бог) спільного використання файлів, то це ризик, який вам доведеться оцінити самостійно. Якщо ви хочете відіграти його в безпечному режимі, створіть Linux-сервер безкоштовно і використовуйте це як мережевий файл спільного доступу або сервер друку і намагайтеся зберегти вікна вашого доменного сервера саме таким.


Як щодо абсолютної нездатності витрачати гроші з причин, які мають бути на сьогодні кристально зрозумілими в нашій історії.
tomjedrz

1
Коли люди дізнаються, що програмне забезпечення - це інвестиція для підвищення продуктивності. Не купувати програмне забезпечення, щоб заощадити на витратах на ліцензування, але це означає, що ви повинні виконати на 10 разів більше роботи - це божевільно. Якщо тільки ви щасливі працювати безкоштовно
Нік Кавадіас

@ Nick - чому б файловий сервер також діяв як контролер домену, викликає багато зайвої роботи? Цікаво просто ... ми дуже обмежені в грошах (<50 співробітників) і думаємо просто кинути обох на одну коробку, щоб заощадити 700 доларів.
Звуковий сигнал

0

Так, вони можуть, але з точки зору безпеки звичайна відповідь - ні. Причина проста: чим більше працює на контролері домену, тим більша площа поверхні, яку можна використати, щоб взяти коробку. Візьміть вікно і у вас є домен. Зазвичай не дивно бачити DNS, що працює з інтегрованими зонами Active Directory. Однак, нічого іншого, я б сказав, що ні, якщо ви невеликий магазин і просто не можете дозволити собі вирвати послуги.


0

(не сприймайте мене занадто серйозно, але ви знаєте, що у мене є пункт)

Звичайно, просто встановіть VMware, а на ньому Debian і у вас чудовий багатоцільовий сервер. Тобто, якщо навантаження на хост досить мала.


У вас є пункт, цікавий насправді. Можливо, постійний струм може бути у вітрині комп'ютера на термінальному або веб-сервері, або навпаки.
tomjedrz

Це я ... але я думаю: встановіть Debian, на ньому встановіть VmWare і на ньому "сервери". Використовуйте повні резервні копії на хості / debian, а при необхідності просто перемістіть "сервер" на новий хост. Хмарні обчислення найкраще.
elcuco

0

Якби у мене був вибір мати лише один контролер домену або інший заголовок постійного струму у вікні SQL, я б взяв цей варіант.

Насправді я б, швидше за все, запустив віртуальний сервер, ніж насправді перетворив будь-який інший робочий сервер на контролер домену - навіть якщо він просто працює на робочій станції.

Моя особиста думка полягає в тому, що для стабільності вам потрібно як мінімум три контролери домену, що дозволяє розділити головні ролі операцій, і у вас завжди має бути принаймні два глобальних каталоги - але враховуючи, що майстер інфраструктури не повинен бути GC .


0

Як правило, я запускаю DNS і DHCP на контролерах доменів і маю щонайменше два постійних постійного струму. Особисто у мене є віртуальний постійний постійний струм, який працює на двох моїх віртуальних хостах (працює VMware ESXi, три віртуальних хости) і на одному фізичному. Всі постійні джерела харчування є серверами DNS, і два з них - DHCP-сервери (що обслуговують половину діапазону кожен). Віртуалізація дозволяє легко (і залежно від того, як ви платите за ліцензування Windows, доступне за ціною) мати спеціальні віртуальні комп'ютери, залежні від завдання, і я дуже вважаю за краще розділяти речі, оскільки перезавантаження одного сервера не вплине на інші.

Однак я запускаю SBS 2003 в іншому (меншому) офісі, і він добре працює на надійному сервері, хоча проблема планування перезавантаження іноді дратує. SBS є фізичним, але у мене є другий сервер під управлінням VMware ESXi, який має VM для Windows, який також є постійним струмом, тому у мене є секонарний (другий DC дозволений для SBS, поки SBS виконує ролі FSMO). Я ненавиджу наявність одного постійного струму, це ускладнить відновлення і будь-який простой довший!

Я б спробував і додати лише щось на зразок друку та / або подачі файлів до постійного струму, якщо можливо, крім DNS та DHCP. Іншим доведеться зважувати ретельно ... і, якщо можливо, вставте навіть настільний / низький сервер у як вторинний блок DC / DNS, якщо вам потрібно змішати основне обладнання. Навіть не надлишкові апаратні засоби, ймовірно, будуть спрацьовувати, якщо ваш основний не працює і навпаки (будь то перезавантаження чи збій).

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.