CUCM 11.5.1 обновление до 14.1SU3 preUpgrade Неудачная проверка 1.6

[Jason@Logicalis]

У меня есть клиент, которому необходимо обновить версию с 11.5(1) SU11 до v15, но нет пути обновления/L2, чтобы это сделать. Поэтому единственным поддерживаемым методом является миграция данных или экспорт/импорт данных. Я был как вы, я думал, что если диск имеет объем 110 ГБ, то все должно быть в порядке. Но все чаще я убеждаюсь, что экспорт данных — это действительно надежный способ обновления, позволяющий убедиться, что все построено/перестроено правильно. Предварительная проверка по-прежнему важна, чтобы убедиться, что все остальное готово для экспорта данных.

[Roger Kallberg]

Если вы не хотите видеть предупреждения, связанные с этим, вам нужно вернуться к версии предварительной проверки, предшествующей любой проверке v15. Тем не менее, как я уже писал, вы можете безопасно игнорировать предупреждение, поскольку вы обновляетесь до v14. Однако в какой-то момент вам нужно будет перестроить систему, чтобы она соответствовала требованиям версии 15, и вы могли перейти на эту версию. Сейчас мы находимся в процессе перехода, хотя в настоящее время используем версию 14. Мы планируем создать новые виртуальные машины на основе OVA v15, изменить гостевую ОС на созданной виртуальной машине на CentOS 7 (64-битную), затем установить версию CM 14, которую мы используем в настоящее время, на созданной виртуальной машине и, в качестве последнего шага, выполнить восстановление DRS этого одного узла и повторить процесс для всех остальных узлов. Мы знаем, что есть и другие варианты, но мы их ранее не использовали и поэтому не чувствуем себя с ними комфортно. ![Response Signature]

[Hermanus Janse van Vuuren]

К вашему сведению, я успешно выполнил обновление CUCM 11.5SU7 --> 14.0SU3 в своей лаборатории, несмотря на то, что получил вышеуказанное сообщение об ошибке в файле cop перед обновлением. Затем я продолжил и вчера вечером успешно обновил тот же CUCM до последней версии CM15SU, без каких-либо проблем и ошибок, только пришлось изменить объем ОЗУ с 8192 Мб до 10 Гб и сменить ОС виртуальной машины с CentOS7 64-разрядной на Linux other 4.x 64-разрядную. Обновление заняло некоторое время, но переключение версии заняло около 5-8 минут, учитывая, что база данных практически пустая, в ней зарегистрировано только несколько телефонов. С уважением

[thomas-buchholz]

@Hermanus Janse van Vuuren Тема уже немного устарела, но я надеюсь, что кто-нибудь сможет на нее ответить: При прямом обновлении неактивного раздела с 14 до 15, когда мне следует внести изменения в виртуальную машину (RAM, смена ОС Linux, совместимость виртуальной машины)? Выключить серверы перед началом обновления и изменить виртуальную машину, запустить серверы снова и запустить обновление? Спасибо, Томас

[Roger Kallberg]

RAM и все, что связано с аппаратным обеспечением, до этого, а гостевая ОС — после. ![Response Signature]

[Michael.Heimann]

Привет, я попытался сделать то же самое (обновить 14SU3 до 15SU1), но обновление не удалось — в журнале обновления указаны ext3 и swap.
Поскольку резервное копирование и восстановление всего кластера занимает довольно много времени, я пошел другим путем. Я обновил ext3 до ext4 и увеличил swap на 2031 МБ с помощью live-cd Ubuntu Desktop.
Чтобы увеличить swap: измените размер общего раздела (который находится после раздела swap) с помощью gparted и освободите 2031 МБ, затем увеличьте swap на эту величину.
Чтобы обновить ext3 до ext4, просто запустите терминал и выполните sudo tune2fs -O extents,uninit_bg,dir_index /dev/sdXY где sdXY — это sda6, если это раздел, который вы хотите обновить. Не забудьте также изменить запись /etc/fstab с ext3 на ext4 для этого раздела.
Мне нужно было обновить общий и неактивный раздел до ext4, поскольку при обновлении общий раздел проверяется, а неактивный раздел переформатируется и монтируется как ext4. Если один из них не работает, обновление останавливается.
Если вы не знаете, является ли /partB или / вашим текущим активным разделом, вы можете просто оставить его как ext3, и тогда в журнале обновления будет явно указано, какой раздел не удалось смонтировать. Кроме того: если версия вашего коммутатора не работает, он, вероятно, загрузится в состоянии, когда будет отображаться сообщение о том, что раздел Xy не может быть смонтирован — в этом случае вам также необходимо обновить раздел с ext3 на ext4.
В целом, это гораздо быстрее, чем переустановка, но я бы порекомендовал сделать снимок перед этим.
![:winking_face:]

[Roger Kallberg]

Все это сделает вашу систему непригодной для поддержки TAC. Поэтому я бы не рекомендовал использовать этот подход. Да, переустановка и восстановление занимают много времени, но, честно говоря, это не занимает более 3, может быть 4 часов на каждый узел кластера. Мы только что завершили эту работу для двух кластеров из 5 узлов и смогли выполнить ее за полторы недели, выполняя поочередно на каждом узле в разные дни. ![Response Signature]

[Michael.Heimann]

Эта процедура не поддерживается TAC, так как она не описана ни в одном руководстве Cisco, это точно. Создание загрузочного ISO-образа для обновления также не поддерживается.
Но я не вижу причин, по которым это должно лишить систему права на поддержку TAC. Если все сделано правильно, система остается в точно таком же состоянии, как и после переустановки (если она тоже была выполнена правильно).
Я бы пошел дальше и сказал, что средний сотрудник TAC не обучен даже распознавать, что было сделано что-то подобное. Кроме того, TAC рассматривает конкретную проблему, а не то, была ли система каким-либо образом изменена не в соответствии с официальной документацией.
Технически это упрощение, которое позволяет сэкономить как минимум десятки часов, чтобы получить тот же результат, что и при переустановке. Конечно, для этого нужны некоторые навыки работы с Linux (gparted, fstab и mount не должны быть вам незнакомы), но если у вас есть эти навыки, почему бы не сэкономить деньги для клиента?
Кроме того, переустановка — это то, что не всем нравится делать по разным причинам.
Я просто хотел поделиться способом, который сэкономил мне кучу времени и который я был бы рад найти сам.
Мне все же интересно, почему Cisco не делает это в рамках своих скриптов обновления. Думаю, это, к сожалению, часть менталитета «тратить минимум усилий на локальные ресурсы», который я заметил в последнее время.

[Roger Kallberg]

Возможно, и вы имеете право на свое мнение по этому поводу, ведь мы живем в свободном мире. Но я хотел, чтобы другие читатели вашего поста поняли, что то, что вы предлагаете, приведет к тому, что система окажется в нерабочем состоянии
, если
это когда-нибудь обнаружит представитель Cisco. Правда, большинство инженеров TAC,
возможно
, этого не заметят, но это не делает систему более поддерживаемой, просто в данный момент времени это не обнаружено, но это не значит, что позже кто-то другой не обнаружит это. В конечном итоге, это предложение не поддерживается Cisco, и я бы не советовал никому его использовать. ![Response Signature]

[iverson.justin]

Интересно, Роджер, можно ли выполнять экспорт и импорт данных по одному узлу за раз? У нас 5 узлов, и если придется делать это за один день, то это приведет к значительному перерыву в работе. Кластер будет заблокирован до тех пор, пока все узлы не будут переведены на версию 15?

[Nithin Eluvathingal]

Кластер будет заблокирован до тех пор, пока все узлы не будут перенесены. При новой установке с экспортом данных сначала установите Publisher, а затем Subscribers. После установки Publisher вы можете установить все Subscribers одновременно, что является моим обычным подходом, импортируя экспортированные данные во время процесса установки. Если ваша главная задача — минимизировать время простоя, рассмотрите возможность создания лабораторной среды для построения нового кластера. Во время окна обслуживания отключите старый кластер от сети и подключите новый, чтобы сократить время простоя. ![Response Signature]