CUCM 12.5 до 15.x — миграция с экспортом/импортом данных

[TONY SMITH]

Здравствуйте, У нас есть кластер, работающий под управлением версии 12.5, с одним издателем и двумя подписчиками. Его необходимо обновить, и в настоящее время мы планируем пропустить версию 14.x и перейти сразу к версии 15.x. Изучив доступные пути обновления, мы пришли к выводу, что миграция с экспортом/импортом данных выглядит привлекательной: мы можем перейти на новую инфраструктуру VMware за один шаг, установить новую виртуальную машину, построенную с использованием последней версии OVA, и оставить позади все потенциальные проблемы, связанные с предыдущими обновлениями, изменением размера диска и т. д. Но информация об этом процессе скудна, в руководствах по установке или обновлению практически ничего нет. Я прочитал... https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/222244-install-cucm-cluster-using-data-export-a.html И у меня возникло несколько вопросов. (1) Приводит ли запуск экспорта данных с исходных серверов к каким-либо изменениям? Я, конечно, надеюсь, что нет, но в документации говорится о немедленном отключении серверов после экспорта. Очевидно, я думаю о плане отката, вы бы хотели, чтобы старые серверы могли быть запущены снова, если дело дойдет до худшего, то есть если мы столкнемся с препятствием при миграции Publisher. Есть упоминание об откате, что подразумевает, что были внесены некоторые изменения... «Если вы хотите вернуться к предыдущей версии, установите файл COP
ciscocm.DataExport_rollback_v1.0.cop.sgn
». (2) Можно ли организовать это так, чтобы кластер не был выведен из строя на весь период? Опять же, я бы хотел, чтобы это было возможно, но в документации указано, что все исходные серверы должны быть выключены еще до начала установки 15.x. На скриншотах показано, что установка Publisher занимает около двух с половиной часов. Предположительно, нам также необходимо установить файлы Locale и, возможно, обновить часовой пояс, прежде чем новый Publisher начнет нормально работать. Так можно ли это организовать? Сначала запустите экспорт данных на всех исходных серверах. Затем выключите только Publisher и оставьте старые Subscribers работать, пока новый Publisher не заработает. То же самое с резервным Sub. Это означает, что кластер по-прежнему работает на старой версии, пока мы окончательно не выключим активные Subscriber(ы), после чего телефоны смогут повторно зарегистрироваться с резервным. Или нам нужно запланировать полное отключение на три часа или около того? (3) Последний вопрос на данный момент, опять же, я надеюсь, что это не проблема, но все ли сертификаты реплицированы на новые серверы, чтобы телефоны доверяли им и регистрировались правильно без этапов экспорта/объединения/импорта сертификатов? Мы сохраним те же IP-адреса, если это имеет значение. Спасибо,

[Nithin Eluvathingal]

Когда вы экспортируете данные с помощью Data Export, насколько я знаю, это вносит изменения в некоторые функции исходных узлов, с которых экспортируются данные. Эти изменения на исходных узлах можно отменить с помощью файла COP ciscocm.DataExport_rollback_v2.0.cop. Я никогда не выполнял откат на исходном кластере, но, насколько я понимаю, это необходимо, когда вы снова остаетесь на исходном кластере. Всегда настоятельно рекомендуется создавать резервную копию перед обновлением. Вы должны выполнить это с помощью PCD или новой установки с экспортом данных, чтобы в худшем случае вы могли восстановить приложения до их прежнего рабочего состояния. При установке необходимо выключить узел, если он переносится на тот же IP-адрес. В противном случае выключать его не нужно, и необходимо выполнить массовый обмен сертификатами, чтобы телефоны доверяли новому кластеру. Вы можете выполнять миграцию по одному. Экспортируйте данные из всех кластеров и сохраните их на SFTP-сервере, к которому могут подключиться как новый, так и старый кластеры. Если вы используете тот же IP-адрес, отключите издателя, установите нового издателя, импортировав экспортированные данные. После завершения продолжите тот же процесс с узлами подписчиков. Те же старые сертификаты будут импортированы в новый кластер. Если используются разные IP-адреса, требуется массовый обмен сертификатами, как упомянуто выше. ![Response Signature]

[Roger Kallberg]

Вы, вероятно, найдете несколько ответов на свои вопросы в этом посте в блоге, который
@Nithin Eluvathingal
написал несколько дней назад. [) ![Response Signature]

[TONY SMITH]

Спасибо. На самом деле я понял, что нет никакой необходимости беспокоиться о откате. С тех пор как CUCM перешел на Vmware, мы всегда делаем полную копию виртуальной машины Publisher перед началом любого обновления. Поэтому в данном случае мы могли бы запустить экспорт из копии, оставив прежнюю Publisher выключенной, но в остальном нетронутой. Или наоборот, сохранив резервную копию в качестве отката. При необходимости это гораздо быстрее, чем выполнять новую установку и восстановление DRS.

[TONY SMITH]

Только что пометив это как «решено», у меня возник другой вопрос. Во время выполнения экспорта на издателе или после него, влияет ли это на нормальную работу издателя или на работу всего кластера? Как и раньше, я думаю о планировании и времени простоя. В идеале я бы хотел обновить Publisher, прежде чем нарушать работу кластера. Возможно, мы могли бы (виртуально) переместить его в изолированную сеть. Но это связано с необходимостью перемещения SFTP-сервера и сопутствующими сложностями по управлению обоими серверами в их изолированном состоянии. То же самое касается новой установки/импорта. Если это будет сделано в рабочей сети, повлияет ли это на подписчиков? Или функционально это будет практически то же самое, что и в случае обновления?

[Nithin Eluvathingal]

Насколько я знаю, рекомендуется запустить COP отката, если вы планируете сохранить исходный кластер CUCM на некоторое время. При недавнем переходе на версию 15 все телефоны были на абоненте. Я экспортировал издателя, создал издателя, отключил абонента, а затем создал абонента. Во время создания абонента телефоны зарегистрировались у издателя. Как только абонент был запущен, телефоны вернулись к абоненту. Несмотря на то, что он был запущен, я выполнил эту задачу в выходные дни, чтобы у нас было дополнительное время для устранения любых проблем, которые могли возникнуть. Я не тестировал все операции CUCM, но, поскольку телефоны вернулись к издателю и звонки работали, я ожидаю, что все будет работать как обычно. На данный момент после миграции никаких проблем не наблюдалось. ![Response Signature]

[TONY SMITH]

Спасибо, описанная вами последовательность действий вполне соответствует тому, что мы хотели бы сделать. Мы просто раздумываем, можно ли выполнить экспорт/установку/импорт Publisher до начала периода изменений и простоя, как мы делали при предыдущих обновлениях этого кластера.

[jaheshkhan]

Итак, я понимаю это следующим образом:
сценарий заключается в том, что мы не меняем никаких сетевых настроек, таких как IP-адрес, DNS, домен и т. д.
Пожалуйста, подтвердите последовательность действий, о которой я говорю:
давайте предположим, что мы переходим с версии 11.5 на 15 с одним издателем кластера и двумя подписчиками
. Экспорт ДАННЫХ Экспорт старого издателя, затем экспорт старого подписчика 1, затем экспорт старого подписчика 2.
Затем выключение старого издателя. Запуск старого подписчика 1 и старого подписчика 2, не выключая их в течение этого времени. Телефоны будут регистрироваться у подписчика 1 и подписчика 2.
Установите нового издателя, импортировав данные старого издателя. Затем выключите старого подписчика 1. Если какие-либо телефоны, зарегистрированные у подписчика 1, будут регистрироваться у нового подписчика 2 cucm11.5 или нового издателя с 15.0, или мне нужно выключить обоих подписчиков одновременно?
Установите нового подписчика 1, импортировав старого подписчика 1 с данными.
Выключите старого подписчика 2, а затем импортируйте нового подписчика 2 с данными.
Какая последовательность действий требуется в данном случае?