KSC - миграция на новый физический сервер

[gurlov]

Уважаемые форумчане, здравствуйте.

Имеется одни сервер KSC11 на старом железе. Требуется мигрировать на новое железо. Подскажите стратегию наиболее корректного и удобного перехода. 

Можно для этого использовать такую функцию, как иерархия серверов?

Попробовал просто создать параллельно второй KSC, импортировать политики со старого, и переводить постепенно клиентов со старого на новый. Но не понравилось, что при переводе клиента не сохраняются его теги. Да и в принципе все его статистические данные.

[andrew75]

@gurlov, как-то так - https://support.kaspersky.com/KSC/11/ru-RU/3675.htm

[gurlov]

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

... или поможет? ...

 

9 часов назад, andrew75 сказал:

@gurlov, как-то так - https://support.kaspersky.com/KSC/11/ru-RU/3675.htm

 

А с учётом того, что сервера будут иметь разные адреса?

Перенос, указанный в статье можно выполнить с KSC11 на KSC12? или лучше не рисковать  и мигрировать на ту же версию KSC, и только потом обновить его?

 

[andrew75]

@gurlov, разные IP адреса или разные имена? И как у вас агенты подключаются к серверу, по имени, или по IP?

Если будут разные имена, то нужно создавать на старом сервере задачу смены сервера администрирования.

 

Думаю лучше сначала мигрировать, а потом обновить.

 

Но я рассуждаю чисто теоретически, исходя из документации.

Подождите пока подойдут люди, которые работают с корпоративными продуктами.

 

[gurlov]

@andrew75 И имена и IP разные. Клиенты конектятся по ip. Про задачу миграции знаю. Но вот переживаю, а как себя поведут точки распространения, при одновременной работе 2х серверов KSC. Как будут работать клиентские ПК с точками распространения. Нужно ли на новом KSC на время миграции клиентов назначить другие точки распространения (отличные от тех, что назначены на старом). Да и вообще чувствую, что я ещё много факторов не учёл и встречу при миграции не один подводный камешек. 

[gurlov]

07.11.2020 в 01:22, andrew75 сказал:

создавать на старом сервере задачу смены сервера администрирования.

А нужно ли создавать такую задачу, если есть точки распространения (они же шлюзы соединения)?

Я перевёл эти точки под управление новым сервером и KSC всех  клиентов, на которых влияли эти точки, спокойно увидел у себя и мог управлять.

При этом, выполнение задачи по смене сервера администрирования привело к тому, что все эти клиенты хоть и остались под управлением сервера, но явно перестали взаимодействовать через точки распространения (шлюз соединения)

[andrew75]

@gurlov, лучше напишите в техподдержку через https://companyaccount.kaspersky.com/

Или попробуйте спросить на Community.

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

Изменено 9 ноября, 2020 пользователем andrew75

[oit]

Делается бэкап. Тушится старый сервер.

Настраивается новый сервер с теми же ip и именем, разворачивается бэкап.

Это в идеале.

Если ip разные, то тут все зависит от того как подключались агенты к ксц. Если по имени, то все тоже самое

Если по ip, то только через миграцию.

 

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

[gurlov]

Я вынужден переезжать на новы сервер с новым именем и новым ip. Все клиенты соединяются по ip

3 часа назад, oit сказал:

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

Вот тут у меня зародилось сомнение. Поясню ещё раз.

После запуска нового сервера я мигрировал на него все точки распространения (они же шлюзы доступа). После этого из консоли управления новым KSC мне стали доступны к управлению все клиенты, которые находились под действием этих точек. Т.е. по хорошему, дело сделано, всё работает. Я даже как обычно мог оперативно запускать и останавливать задачи и программы в свойствах конкретного клиента (см. скрин)

Но далее я, как мне кажется, рассудил логично: клиенты общаются с KSC через  точки, и клиенты просто не в курсе, что точкой теперь управляет новый KSC. Но в свойствах самих клиентов стоит же IP старого KSC. Значит, если когда-нибудь точка станет недоступна, то клиенты будут стараться обращаться на старый KSC. Значит задачу "смена сервера" всё таки выполнить надо. Что я и сделал. Видимо зря, потому что:

При выполнении этой задачи точки распространения потеряли связи с сервером. После восстановления связи все клиентские ПК доступны и числятся в консоли KSC, но вот оперативно запускать и останавливать задачи я уже не могу (см. выделенное на скрине). Т.е. точки перестали работать полноценно, так как они работали до этого.

Что это? почему? 

Мне с таким вопросом лучше в  Community. или даже в техподдержку или можно пока тут остаться и не плодить параллельных веток?

 

[oit]

Точки распространения со шлюзом подключения не путаете?

Точка распространения - это просто компьютер, который забирает часть фич КСЦ на себя в своем окружении, но он никак адреса сервера не раздает

[gurlov]

9 часов назад, oit сказал:

Точки распространения со шлюзом подключения не путаете?

Точка распространения - это просто компьютер, который забирает часть фич КСЦ на себя в своем окружении, но он никак адреса сервера не раздает

Я же в начале своего сообщения указал 

9 часов назад, gurlov сказал:

После запуска нового сервера я мигрировал на него все точки распространения (они же шлюзы доступа).

 

[oit]

Не можете управлять, значит udp15000 не доступен, в т.ч. через точку распространения

[gurlov]

4 часа назад, oit сказал:

Не можете управлять, значит udp15000 не доступен, в т.ч. через точку распространения

Порт udp15000 точки распространения недоступен для KSC, но для точки стоит "не разрывать соединение". Так что тут всё должно работать и работает. Точками я могу "управлять"

Порт udp15000 клиента действительно недоступен для точки распространения (проверил nmap-ом). Но почему так могло произойти от выполнения задачи "смена сервера администрирования"??

Политики для клиентов не изменялись. В сетевом экране что клиентские сети (сети, где находятся клиенты и их точки), что сеть самого KSC указаны как "локальная сеть". На всякий случай поместил сделал сеть KSC доверенной, но это тоже не помогло.

 

 

 

 

да и здесь вроде тоже всё в порядке (политика агента):

 

[oit]

А у вас агенты ставились с указанием шлюза изначально? Или профиль подключения имеется?

[gurlov]

прошу прощения. Что-то намудрил я с nmap-ом. Открыт на самом деле порт udp15000 на клиенте для точки распространения:

PORT      STATE         SERVICE
15000/udp open|filtered hydap

 

4 минуты назад, oit сказал:

А у вас агенты ставились с указанием шлюза изначально? Или профиль подключения имеется?

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