Перейти к содержанию

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


Рекомендуемые сообщения

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

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

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

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

Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

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

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

 

Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

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

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

 

Ссылка на сообщение
Поделиться на другие сайты

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

Ссылка на сообщение
Поделиться на другие сайты
07.11.2020 в 01:22, andrew75 сказал:

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

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

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

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

Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Изменено пользователем andrew75
Ссылка на сообщение
Поделиться на другие сайты

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

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

Это в идеале.

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

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

 

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

Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

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

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

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

 

1234.jpg

Ссылка на сообщение
Поделиться на другие сайты

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

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

Ссылка на сообщение
Поделиться на другие сайты
9 часов назад, oit сказал:

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

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

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

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

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

 

Ссылка на сообщение
Поделиться на другие сайты
4 часа назад, oit сказал:

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

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

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

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

 

 

 

 

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

 

Аннотация 2020-11-10 094741.jpg

Ссылка на сообщение
Поделиться на другие сайты

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

PORT      STATE         SERVICE
15000/udp open|filtered hydap

 

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

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

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

3.jpg

Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Похожий контент

    • SnakeEyes
      От SnakeEyes
      Не нашёл грамотной информации о добавлении исключений в политику KES (контроль приложений). Рекомендуется добавлять метаданные, хэши, маски. Не ясно как работают правила, если выбрано правило разрешённых - работает ли правило запрещённых приложений, если работает правило разрешённых, исключения используются как запрет или нет? (в таком случае они не имеют смысла, т.к. все кроме доверенных будут автоматически запрещены).
      Меня интересует где мне посмотреть конкретные данные файла чтобы KES его не трогал и не ругался.


    • 8Aleksej8
      От 8Aleksej8
      Всем доброго дня! 
      Подскажите кто, пожалуйста, как можно восстановить окно (панель) на фото выделенное красным. В общих задачах случайно закрыл, теперь не могу назад вернуть. Если открыть по дереву в управляемых устройствах панелька есть. Просто очень не привычно без нее.

    • Medvedev
      От Medvedev
      Добрый день! Подскажите каким способом можно мониторить подключение и отключение смарт карт. Настроил отчёт о контроле устройств. Информация о подключении и отключении съёмных носителей и MTP-устройств отображается в отчёте, а про смарт карты выводится только информация о подключении - об отключении нет. Скрины настройки и вывода отчёта приложены.


    • Gunslinger42
      От Gunslinger42
      Добрый день.
      Возникла необходимость перевода существующей установки KSC 14 на свободную СУБД (Maria, MySQL или другие) с сохранением всех настроек, политик, задач и тд. Объем базы KSC около 24 гигабайт.
      Существует ли автоматический инструмент для такого перехода? Или Пошаговый алгоритм действий?
      Спасибо.
    • Nesser
      От Nesser
      Добрый день!
       
      С чем связано данное решение?
       
       
      Подробнее https://www.ixbt.com/news/2022/11/08/vpn-kaspersky-secure-connection.html
×
×
  • Создать...