Вопросы Теги

DHCP для дата-центра

Путем Microsoft хочет, чтобы Вы осмотрели процесс начальной загрузки в полных деталях:
http://helpdeskgeek.com/how-to/speed-up-boot-time-in-windows-vista/

Можно получить те инструменты из Windows SDK или в нижнем правом в:
http://msdn.microsoft.com/en-us/performance/default.aspx

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

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

Надо надеяться, эти инструменты помогут Вам выяснить, почему Ваш компьютер загружается медленно, закрываясь медленно, или имея проблемы с Резервным устройством, и Быть в спящем режиме.Приятного отдыха!

7
задан 4 January 2010 в 20:11
6 ответов

Я голосую нет. Позвольте мне перечислять свои причины.

1: Надежность.
Наличие каждой машины сервера полагается на dhcp, чтобы иметь его сетевой стек, подошедший, правильно добавляет другой потенциальный отказ. В серверной среде, где Вы пытаетесь максимально трудно достигнуть максимальной доступности, добавляя другую подвижную часть, не хорошая идея

2: Безопасность
DHCP по существу вручает любому включающему переключатель действительный арендный договор. Да, можно указать, что только известные MAC получают арендные договоры, и всем остальным отказывают, но лучшим местом для этого являются динамические VLAN.

3: Документация
Наличие центрального пула DHCP, который присваивает адреса волей-неволей, безумно для блока сервера. Присвоение сервера, определенный IP через DHCP менее безумен, в том смысле, что наличие 3 мнимых розовых слонов, преследующих Вас, менее безумно, чем 5.

4: Управление
Не только Вам должны указать в сервере DHCP, чему присвоена каждая машина, необходимо сохранить документацию его. И необходимо обновить ВСЮ документацию любое время, которое что-либо изменяет. Новая сетевая плата? Документация обновления и сервер DHCP и DNS, и т.д.

Простой лучше.

16
ответ дан 2 December 2019 в 23:12
  • 1
    +1 Розовый Elephans сделали меня lol –  Zypher 4 January 2010 в 20:07
  • 2
    Спасибо за подробное обоснование. Просто вопрос - резервирование DHCP обеспечивает какое-либо значение? Или это по существу то же как статическое присвоение IP, с добавленной нагрузкой управления MAC-адресами? –  SyRenity 4 January 2010 в 20:10
  • 3
    Если Ваш сервер DHCP настроен нормально И функционирует, то it' s эффективно то же как статический дюйм/с..., но почему добавляют другую сервисную зависимость? Высокая доступность DHCP isn' t что-то Вы слышите много... –  Matt Simmons 4 January 2010 в 20:23
  • 4
    Я думаю it' s стоящий упоминания, что Вашими причинами того, что не использовался DHCP является not' t всегда столь сильный, как они появляются. 1) Относительно надежности DHCP является одним из наиболее надежного протокола / реализации сервера вокруг. Проблемы с DHCP имеют тенденцию быть сетевыми проблемами, которые имеют тенденцию выводить серверы из эксплуатации так или иначе. 2) Можно настроить DHCP, чтобы быть совершенно безопасными, это - соломенный человек. 3) Конфигурация DHCP замечательная документация. 4) То же, конфигурация документация. –  Travis Bradshaw 4 January 2010 в 23:13
  • 5
    Кроме того, в отношении (4) управление. Вы могли заменить " DHCP server" с " локально на каждом server" без изменения в значении. –  Travis Bradshaw 4 January 2010 в 23:14

Единственное исключение к не рабочий DHCP в центре обработки данных является этим:

DHCP на СПЕЦИАЛИЗИРОВАННОМ VLAN сборки, таким образом, Вы можете PXE загружать новые серверы после установки в стойку их для обработки изображений их.

Нет никакого другого серьезного основания иметь DHCP, работающий в центре обработки данных как уже говорилось так хорошо всеми остальными.

2
ответ дан 2 December 2019 в 23:12

Я лично полагаю, что DHCP прекрасен в дата-центре, если использование совместно использовало адресное пространство. DHCP действительно не означает, что это должны быть динамические адреса; они могут быть зафиксированы.

Пока Вы обеспечиваете избыточные серверы DHCP (обработка отказа DHCP), таким образом, DHCP всегда доступен, вещи должны быть прекрасными.

Люди раньше думали, оставляя порты коммутатора для выбирания скоростей автоматически, и дуплекс был плохой идеей, и теперь я не знаю ни о ком, кто проводит время, настраивая переключатель такой.

1
ответ дан 2 December 2019 в 23:12

Erm... это хорошо для клиента ПК в офисе рядом с дата-центром...

... принтеры также, если Вы должны...

... но не, все еще плохая идея для серверов, производственные, по крайней мере - возможно, в dev/test среде, которую я предполагаю, или для VPSs, если у Вас не было никакого другого выбора.

0
ответ дан 2 December 2019 в 23:12

Вообще говоря, DHCP с резервированием является "лучшим среди аналогов" для управления IP в центре обработки данных, завися (конечно), от конкретных потребностей Вашего дата-центра.

Профессионалы:

  • DHCP с резервированием позволяет централизованное управление Вашим адресным пространством. Единственное место для администраторов, чтобы сослаться и отредактировать Ваше адресное пространство, обязательно не имея необходимость сослаться на пространство имен (DNS). Это - особое великое, если Ваши администраторы естественно "разделяли" в обязанностях на сетевом уровне.
  • DHCP может обеспечить способность динамично присвоить ресурсы с корректным IP в адресном пространстве. Переустановленный сервер сразу придумывает корректный IP без консультации.
  • Динамическое выделение является особенно большим для быстрого развертывания серверов, где автоматизация обрабатывает большинство установки системы.

Недостатки:

  • Поставщики DHCP точка отказа, который может предотвратить доступ к сети. (Это особенно противно, если Вы забываете понижать время для клиента DHCP.)
  • Проектирование сети должно рассмотреть широковещательный трафик DHCP. Это может усложнить маршрутизацию и обеспечить другой уровень потенциального отказа для доступа к сети.
  • Руководящий DNS и DHCP отдельно считают обременительными некоторые.
  • Неудавшееся присвоение DHCP может привести к 169 создаваемым сетям, брандмауэры и маршрутизаторы должны быть соответственно подготовлены.

Очень редко это мудрый для выполнения DHCP в дата-центре без резервирования, хотя некоторое смешение является соответствующим. Во многих настройках "Недостатки" для DHCP с резервированием заканчивают тем, что были надуманными вопросами (если маршрутизатор может вынуть DHCP, ну, в общем, серверы не доступны так или иначе, и т.д.). Это - также обычно решение относительно размера. Центр обработки данных с сотнями или тысячи серверов с частым развертыванием и переустановкой будут, конечно, использовать некоторый DHCP, даже если это будет только для тестирования/развертывания. Центр обработки данных с несколькими серверами, вероятно, согласится со всем статически присвоенным.

13
ответ дан 2 December 2019 в 23:12
  • 1
    Что относительно того, чтобы управлять MAC-адресами, doesn' t это представляют другой уровень нагрузки? –  SyRenity 4 January 2010 в 20:15
  • 2
    Ну, это зависит от того, что Вы рассматриваете нагрузкой. Для многого развертывания MAC-адреса и IP-адреса должны быть зарегистрированы так или иначе. Хорошо обработанный файл конфигурации DHCP делает замечательную документацию для обоих. Каждый слой сетевого стека важен для дизайна центра обработки данных, таким образом, " ignoring" MAC-адреса действительно isn' t опция так или иначе. Большинство администраторов, которых я знаю, предпочитает ссылаться на файл конфигурации DHCP, вместо того, чтобы иметь необходимость пробраться через маршрутизатор/конфигурацию коммутатора (или ожидать на сетевом администраторе, чтобы иметь время для ответа). –  Travis Bradshaw 4 January 2010 в 20:17
  • 3
    Привет Travis. Спасибо за точные замечания я действительно размышлял трудно, какой способ будет лучшим для меня и в настоящее время меня все еще думающий, что среда DHCP меньше более привлекательна, пока мне удается выполнить машины IP' s использующий некоторую удаленную систему конфигурации. –  SyRenity 5 January 2010 в 19:06
  • 4
    Нет проблем. Довольный я мог помочь. Удачи. :) –  Travis Bradshaw 7 January 2010 в 05:07

Почему люди так беспокоятся о DHCP в центре обработки данных?

  • DHCP упрощает управление
  • По крайней мере, в мире MS DHCP очень надежен
  • Если вы беспокоитесь, сделайте уверен, что это единственная рабочая нагрузка на DHCP-сервере
  • Разберитесь, как работает аренда. Отказ DHCP-сервера - это далеко не катастрофа, клиенты (включая серверы) будут продолжать работать
  • Существует ряд способов сделать MS DHCP высокодоступным, которые задокументированы и поддерживаются MS.
  • Используйте резервирование, соглашайтесь с тем, что в общем, вы не хотите, чтобы рабочие нагрузки сервера имели динамически назначаемые адреса
  • DHCP, DDNS и Active Directory - все вместе прекрасно сочетаются
  • Эти темы в основном освещаются в других сообщениях здесь
  • Кажется, много эмоций об этой дискуссии здесь и на других форумах. Почему? Ни "правильно", ни "неправильно" и даже можно использовать гибридное решение. Размер вашей инфраструктуры, количество изменений, операционная зрелость вашей организации, ваш аппетит или нежелание рисковать, ваш уровень обслуживания, уровень вашего персонала и т. Д. И т. Д. - все это влияет на эти факторы

Отказ от ответственности - я реализовал DHCP в центре обработки данных, и у меня не было проблем, когда я был менеджером инфраструктуры, но теперь, как консультант для многих клиентов, я бы не стал этим заниматься. Все зависит от ....

Следующее скопировано из MS. Подумайте об этом и подумайте, почему вы так беспокоитесь о DHCP в центре обработки данных:

Если клиенты получают адреса от DHCP-сервера, важно иметь возможность предсказать, как на них повлияет любой простой DHCP-сервера. В целом, чем дольше период аренды, тем меньше будет эффект, если время простоя DHCP останется коротким. Например, если для клиентских периодов аренды установлено значение по умолчанию 8 дней, клиенты не будут пытаться продлить аренду до тех пор, пока не истечет 50 процентов этого периода (4 дня). Если исходный DHCP-сервер недоступен в это время, клиент продолжает использовать этот арендованный адрес до 87,5% срока аренды (7 дней), а затем пытается продлить с помощью любого DHCP-сервера. Когда клиенты пытаются продлить подписку через 4 дня, даже если DHCP-сервер останется недоступным в течение 2 дней, клиенты не достигнут 87,5-процентного состояния повторного связывания. Таким образом, обычно не нужно беспокоиться о сбоях в работе, которые не превышают 25% срока аренды. Точно так же, чем короче время аренды, тем короче время, доступное для восстановления DHCP-сервера.

клиенты не пытаются продлить договор аренды, пока не истечет 50 процентов этого периода (4 дня). Если исходный DHCP-сервер недоступен в это время, клиент продолжает использовать этот арендованный адрес до 87,5% срока аренды (7 дней), а затем пытается продлить с помощью любого DHCP-сервера. Если клиенты пытаются продлить подписку через 4 дня, даже если DHCP-сервер останется недоступным в течение 2 дней, клиенты не достигнут 87,5-процентного состояния повторного связывания. Таким образом, обычно не нужно беспокоиться о сбоях в работе, которые не превышают 25% срока аренды. Точно так же, чем короче время аренды, тем короче время, доступное для восстановления DHCP-сервера.

клиенты не пытаются продлить договор аренды, пока не истечет 50 процентов этого периода (4 дня). Если исходный DHCP-сервер недоступен в это время, клиент продолжает использовать этот арендованный адрес до 87,5% срока аренды (7 дней), а затем пытается продлить с помощью любого DHCP-сервера. Когда клиенты пытаются продлить подписку через 4 дня, даже если DHCP-сервер останется недоступным в течение 2 дней, клиенты не достигнут 87,5-процентного состояния повторного связывания. Таким образом, обычно не нужно беспокоиться о сбоях в работе, которые не превышают 25% срока аренды. Точно так же, чем короче время аренды, тем короче время, доступное для восстановления DHCP-сервера.

5 процентов срока аренды (7 дней), а затем попытки продления с любого DHCP-сервера. Когда клиенты пытаются продлить подписку через 4 дня, даже если DHCP-сервер останется недоступным в течение 2 дней, клиенты не достигнут 87,5-процентного состояния повторного связывания. Таким образом, обычно не нужно беспокоиться о сбоях в работе, которые не превышают 25% срока аренды. Точно так же, чем короче время аренды, тем короче время, доступное для восстановления DHCP-сервера.

5 процентов срока аренды (7 дней), а затем попытки продления с любого DHCP-сервера. Когда клиенты пытаются продлить подписку через 4 дня, даже если DHCP-сервер останется недоступным в течение 2 дней, клиенты не достигнут 87,5-процентного состояния повторного связывания. Поэтому обычно не нужно беспокоиться о сбоях, которые не превышают 25 процентов срока аренды. Точно так же, чем короче время аренды, тем короче время, доступное для восстановления DHCP-сервера.

1
ответ дан 2 December 2019 в 23:12

Теги

Похожие вопросы