Доп. сервера управления

[Flickerlight 0]

Доброе всем утро/день/ночь.

Переодически возникает проблема с обновлением дополнительных серверов управления SEP.

Для начала о структуре устновленного SEP.

Есть сайт SEP, где соответсвенно крутится база SQL и работет основной сервер.

К основному серверу подключается ряд дополнительных серверов SEP (географически расположенных в других городах). Такова политика партии компании.

При обновлении базы на основном сервере (с помощью файла *.jdb) начинают обновлятся доп. сервера (здесь все вроде как надо), но вот что происходит потом:

1. При обновлении основного сервера файлом размером порядка 85 Mb на доп. сервера уходит траффик в разы больше (приходится ограничивать скорость во избежании полной загрузки каналов)

2. По истечении неопределенного времени, которое затрачено на обновление сервера, клиенты, подключенные к доп. серверу остаются необновленными. Помагает только перезапуск сервиса SEPM на доп. сервере или его железная перезагрузка.

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

[Олег Шабуров 56]

у меня больше вопросов чем ответов)

К основному серверу подключается ряд дополнительных серверов SEP

это реализовано дополнительными сайтами? или SEPM сервера из регионов обращаются к удаленной базе данных, расположенной в основном филиале?

В зависимости от этого будут дальнейшие ответы...

[Flickerlight 0]

у меня больше вопросов чем ответов)

это реализовано дополнительными сайтами? или SEPM сервера из регионов обращаются к удаленной базе данных, расположенной в основном филиале?

В зависимости от этого будут дальнейшие ответы...

Почему-то я догадывался, что вопросов будет много )

Нет, сайт как уже упоминалось один. Допики обращаются к основной БД, которая удалена (анализ траффика показал постоянные sql-запросы, как я понял, это нормально)

[Олег Шабуров 56]

анализ траффика показал постоянные sql-запросы, как я понял, это нормально

правильно.

Именно поэтому существует рекомендация иметь SEPM и SQL как можно ближе (в идеале на одном свитче). При малом кол-ве клиентов это не так важно, но при большом - может быть очень критично, т.к. постоянные запросы по узким каналам могут положить канал связи и серьезно "тормозить" SEPM.

Можете более детально описать инфраструктуру:

- сколько филиалов? + сколько там клиентов?

- есть ли "подфилиалы"? + сколько в них клиентов?

- ширина каналов?

- есть ли в филиалах прямой доступ в интернет или все идет через центр?

Может будет больше вопросов, но пока хватит.

Если не хотите делиться этой инфомацией публично, то можем пообщаться лично.

[Flickerlight 0]

Можете более детально описать инфраструктуру:

- сколько филиалов? + сколько там клиентов?

- есть ли "подфилиалы"? + сколько в них клиентов?

- ширина каналов?

- есть ли в филиалах прямой доступ в интернет или все идет через центр?

Может будет больше вопросов, но пока хватит.

Если не хотите делиться этой инфомацией публично, то можем пообщаться лично.

Информация такова:

1. Есть один головной офис, к которому в идеале должно подключится порядка 15 филиалов. У последних сеть тоже разветвленная (подфилиалы), но там планировалось обновления забирать с выделенных станции обновления (при необходимости), что б не "рожать" еще больше серверов.

2. По количеству клиентов - цифры будут разные, от величины филиала зависит. Где-то 500, где-то 300.

3. Ширина каналов различная, от 2 Мб до 512 Кб (есть предпосылки к увеличению), поэтому вынуждены ограничивать траффик.

4. Обновление только через центр-офис, как говорится - централизация. В филиалах люди вообще обновлением заниматься не должны.

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

6. Прямого доступа в Интернет для серверов SEP - нет.

7. Возможно использовать Live Update, конечно, ставить расписание в ночь и прочее, но у последнего обновления занимают от 1.5 Gb, а это "пипец" (с).

[Олег Шабуров 56]

Есть причины по которым не хотите полностью избавиться от серверов SEPM в регионах?

Мое предложение следующее:

1. Центральный офис: 2 SEPM (один из которых для отказоустойчивости и балансировки нагрузки).

2. Филиалы: в каждом филиале по 2 GUP (один из которых для отказоустойчивости).

3. Подфилиалы: в них тоже GUP, если есть возможность сделать пару - хорошо.

Теперь детали.

1. На SEPM-серверах храните большое кол-во обновлений. Если обновления качаются 3 раза в день, то желательно хранить около 45 обновлений (это необходимо для генерации дельт в тех случаях, когда машины пользователей не будут включаться по две недели). Это, конечно, займет довольном много дискового пространства (среднее обновление около 220МБ на диске + 70МБ в базе данных), но существенно облегчит нагрузку на каналы связи.

2. GUP-ами назначаете машины, которые постоянно в онлайне, желательно какой-нибудь файловый или другой сервер. На нем тоже устанавливаете срок хранения обновления подольше (недели достаточно, если понадобится дельта за больший срок - SEPM ее сгенерирует).

Если нагрузка на канал очень критична, то настраиваете GUP таким образом, что клиенты никогда не будут обращаться за обновлениями напрямую к SEPM.

3. В подфилиалах то же самое, что и в филиалах, но срок хранения обновленй можно сделать поменьше.

4. Дальше мониторите состояние GUP-ов и остальных клиентов. Например для этого можно использовать GUP Monitor.

Если что-то из предложенного мной не может быть реализовано по каким-то причинам - пишите, будем думать.

но у последнего обновления занимают от 1.5 Gb

LUA - штука, не особо экономящая трафик.

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

Поэтому настоятельно рекомендую использовать GUPы.

[Flickerlight 0]

Тут вот какое дело.

GUP-ами да, можно назначить те же самые доп. сервера. Дело в том, что машинки в филиалах напрямую не пингуют SEPM в центр офисе. И методом научного тыка выяснили, что таким образом они не будут обновляться с GUP-а и передавать свое состояние в БД SEPM. Поэтому и было принято решение об организации доп SEPM в филиалах.

Хотя возможно что-то делали не так, может буквари по SEP не дочитали.

P.S. Олег, может есть возможность как-то более он-лайн пообщаться?

P.P.S С уважением, Александр.

[Олег Шабуров 56]

может есть возможность как-то более он-лайн пообщаться

конечно, пишите на почту: oleg подчеркивание shaburov собака symantec.com

[radamol 18]

Ребята, выкладывайте пожалуйста хотя бы результаты личного общения. Здесь же можно гораздо больше почерпнуть чем из доки. Я из вопрос-ответ понял гораздо больше чем читая мануалы как все работает.

[Олег Шабуров 56]

Ребята, выкладывайте пожалуйста хотя бы результаты личного общения

обязательно, как только пообщаемся получше.

а если есть какое-то недопонимание - пишите, подскажем.