Вопросы Теги

Мертвое обнаружение шлюза на Windows 2008 Server

Инструмент: Шеф-повар является довольно новым инструментом, выпущенным в январе Opscode. Это записано в Ruby, и его языком конфигурации является чистый Ruby DSL. Это - молодой инструмент при активной разработке, но это привыкает в производстве несколькими компаниями.

Шеф-повар может управлять Вашей всей инфраструктурой, от установки PXE загружают и запускают сервисы, к развертывающимся приложениям и руководящим пользователям. Это очень гибко, расширяемо и мощно.

Определенными преимуществами является чистый Ruby DSL, УСПОКОИТЕЛЬНЫЙ API, доступные для поиска данные узла и богатство поваренных книг, готовых использовать. Из-за DSL Ruby сложные структуры данных и логика могут использоваться в рамках рецептов, и наряду с УСПОКОИТЕЛЬНЫМ API, сделать Шеф-повара мощным инструментом для программирования инфраструктуры.

9
задан 13 September 2009 в 09:05
4 ответа

Мы не смогли прибыть в окончательный результат относительно того, почему мы не могли управлять поведением Мертвого Обнаружения Шлюза.

Вместо того, чтобы тратить тонну времени, диагностируя эту проблему, мы решили сделать наш трафик маршрута экземпляра HAProxy к шлюзу исходящим и установить оба шлюза значения по умолчанию веб-серверов на IP haproxy и удалили внутренний адрес шлюза. 

  [ soweb1 ] 69.59.196.220, GW=69.59.196.211 [haproxy]
       |
       +---- [haproxy] 69.59.196.211, GW 69.59.196.209
       |
    [ gw ] 69.59.196.209

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

5
ответ дан 2 December 2019 в 22:29

Те Мертвые Обнаружение Шлюза DWORDs бесполезны на Windows Server 2008. Единственная причина они существуют, по причинам совместимости. Драйвер TCP/IP и компоненты маршрутизатора Windows больше не ищут эти значения.

Я подозреваю, что эта функция включилась в Автоматическую настройку, которая дебютировала в Windows Vista. Попытайтесь выполнить следующее в поднятой командной строке (и перезагрузка):

netsh int tcp set global autotuninglevel=disabled


Обновление (добавленный 13 сентября 2009 @7:58PM EST)

Если это не будет работать, то нам будет нужно больше диагностического вывода. Запустите (круговую) трассировку или с NetConnection или со сценариев LAN и позвольте ему продолжить работать, пока проблема не произойдет.

netsh trace start scenario=NetConnection maxSize=512

(Пример: Запускает NetConnection, прослеживающий сценарий, с максимальным размером журнала трассировки 512 МБ),

Можно открыть получающуюся трассировку в Мониторе сети 3.3, просто удостоверьтесь, что Вы устанавливаете последние синтаксические анализаторы.

5
ответ дан 2 December 2019 в 22:29
  • 1
    хорошая идея, но didn' t, кажется, работают также.. просто опытный 5-минутное отключение электричества исходящего трафика - который загадочно зафиксировал себя. –  Jeff Atwood 14 September 2009 в 01:24
  • 2
    @Jeff: Хм, нам нужно больше Капитана данных! Посмотрите редактирование выше. –  Rafael Rivera 14 September 2009 в 03:00

Я подверг бы сомнению, почему даже необходимо изменить шлюз по умолчанию, чтобы быть HAproxy вообще. Обычно Вы не должны изменять свой шлюз по умолчанию вообще, если Вы не указываете, что он в высоконадежном N+1 устанавливает, где IP шлюза может обработка отказа к другому маршрутизатору/машине в случае чего-то плохо случай. Если бы что-то произошло с Вашей машиной HAproxy, и у Вас не было внеполосного доступа, то веб-серверы просто привезли бы Интернет.

Поскольку я верю причине, которую можно делать, это вызвано тем, что Вы используете Tproxy в своей установке, чтобы заставить клиентский IP-адрес появиться в Ваших журналах а не IP прокси-сервера, мог я предлагать, чтобы Вы сделали это вместо этого

  1. Добавьте "опцию forwardfor..." к Вашей конфигурации HAproxy
  2. Установите x-forwarded-for ISAPI фильтр
  3. Удалите tproxy из своей установки
  4. Возвратите шлюз по умолчанию к тому же шлюзу, который Вы использовали прежде с прямым подключением Интернет

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

4
ответ дан 2 December 2019 в 22:29
  • 1
    Я только что определил Ваш комментарий к исходному вопросу относительно этой установки. Однако я сомневался бы относительно " это работает удивительно на us" если Ваши серверы освобождают интернет-соединение :) –  davidsmalley 13 September 2009 в 11:49
  • 2
    С другой стороны, Вы могли посмотреть на намного большее надежное решение, такое как ldirectord+heartbeat, который просто перенаправляет трафик на уровне ядра, как таковом нет никакого проксирования, включенного вообще. Я использую эту установку экстенсивно, и она работает отлично. linuxvirtualserver.org/docs/ha/heartbeat_ldirectord.html –  davidsmalley 13 September 2009 в 11:57
  • 3
    We' ve посмотрел на использование того x-forwarded-for заголовок и фильтры IIS для изменения журналов, но нас don' t знают, как (или если) наши другие дополнительные модули IIS также используют заголовок в своей операции. –  Jarrod Dixon♦ 13 September 2009 в 22:14
  • 4
    Спасибо за тот linuxvirtualserver.org/HighAvailability.html ссылка - информация там удивительна! I' m вне неосведомленного об этих предметах (который является почему I' m не тот, настраивающий все это!), но I' m пытающийся учиться максимально быстро. Возможно, мы можем использовать heartbeat+ldirectord подобный тому, как linuxvirtualserver.org/docs/ha/ultramonkey.html делает это с нашим фаворитом HAProxy. –  Jarrod Dixon♦ 13 September 2009 в 22:18

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

-1
ответ дан 2 December 2019 в 22:29

Теги

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