Обновление и миграция до SP 2014

Вот и вышла наконец-то версия WSP2014. Сейчас она доступна для заказа, а в январе 2014 обещают выложить для скачивания на WDN. В ноябре-начале декабря я уже успел протестировать release candidate WPS2014, а до этого beta версию. Много появилось интересного и полезного, но интересности я расскажу в вебинаре 17-го января (записаться на вебинар по System Platform 2014 можно здесь), а в этой статье подробно разберу пример обновления и миграции с предыдущей версии SP2012R2 path 1.

Содержание

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

Рассмотрим процесс обновления System Platform до версии 2014

Архитектура Галактики:

  • PC_A — роли: IDE, GR, Application server, Historian, Lisense Server для Historian Client
  • PC_B — роли: Application Server, Historian
  • PC_IT_1 — InTouch Runtime with Historian Client с серверной лицензией на Historian Client (Per Server Conc)
  • PC_IT_2 — InTouch Runtime with Historian Client с локальной лицензией на Historian Client (Per Device)
  • ПЛК — симулятор ПЛК

Исходные данные:

Программное обеспечение:

  • MS Windows 2008 Server R2 SP1 64 bit (на узлах PC_A, PC_B)
  • MS Windows 7 SP1 64 bit (на узлах PC_IT_1, PC_IT_2)
  • MS SQL 2012 (на узлах PC_IT_1, PC_IT_2)
  • MS Office 2010 32 bit (на узлах PC_IT_1, PC_IT_2)
  • System Platform 2012 R2 path 1 (на узлах PC_A, PC_B, PC_IT_1, PC_IT_2)

Доступно резервирование:

  • Application Server: на PC_A и PC_B задеплоин резервированный движок AppEngine1
  • Historian: настроен Historian redundant (Historian на узле PC_A и Historian на узле PC_B)
  • InTouch: просто две рабочие станции с одним и тем же проектом (PC_IT_1 и PC_IT_2)

Задача:

Обновить программное обеспечение Wonderware до версии System Platform 2014 без прерывания контроля процесса и архивирования данных.

Описание процедуры обновления

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

MS SQL Server желательно обновить до версий MS SQL 2012 SP1

Общий план обновления:

  1. Обновить узел PC_A — роли: IDE, GR, Application Server, Historian
    1. Выполнить полный бэкап Галактики
    2. Раздеплоить платформу только на узле PC_A
    3. Обновить MS SQL сервер до версии MS SQL 2012 SP1
    4. Обновить IDE, GR, Application Server, Historian до версии 2014
    5. Обновить БД Runtime сервера Historian на узле PC_A
    6. Открыть обновленную IDE и произвести миграцию Галактики в версию SP2014
    7. Мигрировать все InTouch проекты в данной Галактике в версию InTouch 2014
    8. Задеплоить платформу на узел PC_A (GR)
  2. Обновить узел PC_B — роли: Application Server, Historian
    1. Обновить MS SQL сервер до версии MS SQL 2012 SP1
    2. Обновить Application Server, Historian до версии 2014
    3. Обновить БД Runtime сервера Historian на узле PC_B
    4. Задеплоить платформу на узел PC_B
  3. Обновить узел PC_IT_1 — роли: InTouch Runtime with Historian Client
    1. Обновить InTouch Runtime и Historian Client до версии 2014
    2. Задеплоить платформу на узел PC_IT_1
  4. Обновить узел PC_IT_2 — роли: InTouch Runtime with Historian Client
    1. Обновить InTouch Runtime и Historian Client до версии 2014
    2. Задеплоить платформу на узел PC_IT_2

Описание процесса обновления

Итак. Время 7:40, поехали.

Обновить узел PC_A — роли: IDE, GR, Application Server, Historian

Выполнить полный бэкап Галактики

7:40. Открываем SMC, выбираем Galaxy Database Manager, правая клавиша на имени Галактики -> backup. Выбираем место сохранения файла.

Проект у меня небольшой, вся процедура бэкапа заняла около 8-х минут. Файл бэкапа получился размером 140 МБ

Раздеплоить платформу только на узле PC_A

7:48. Открываем IDE и раздеплаиваем платформу узла PC_A. Он же у меня и узел GR. И на нем же крутится резервируемый AppEngine1.

Смотрим на архивные данные, был перерыв на 10 сек. Но этот перерыв произошел из-за того, что перед операцией undeploy я не переключил active AppEngine на другой узел.

7:51. Пробуем еще раз: deploy обратно, проверка сохранения архивных данных, переключение активного AppEngine на узел PC_B и undeploy платформы с узла PC_A

7:56. Так теперь в архивных данных потерь не заметно.

7:57. Закрываем IDE, останавливаем и делаем shotdown (disable) сервера Historian на узле PC_A

Обновить MS SQL сервер до версии MS SQL 2012 SP1

8:00. Копируем SP 1 для SQL сервера на PC_A. Так начались первые проблемы, при копировании SP1 для SQL зависла виртуальная машина. Пришлось сделать reset PC_A

8:16. Запуск установщика SP 1 для MS SQL 2012. Сервис пак распаковывается и установка обновления запускается.

Сервис пак 1 для SQL 2012 можно скачать с сайта Microsoft. У меня скачан файлик с именем SQLServer2012SP1-KB2674319-x64-ENU.exe

8:21. Начало установки.

  • Проверка требований для установки прошла успешно. NEXT
  • С лицензией соглашаемся. NEXT
  • Для обновления выбираем все доступные опции. NEXT
  • UPDATE

Пока идет обновление проверяем как идут RealTime даные от нашего процесса автоматизации и проверяем как сохраняются архивные данные.

AppEngine1 PC_B для сервера Historian на узле PC_A сохраняет store&forward данные. Это можно увидеть по увеличению объема каталога для сохранения store&forward данных ДЛЯ СЕРВЕРА Historian на узле PC_A. Архивация данных для Historian на узле PC_B идет в обычном режиме.

Historian client на PC_IT_1 автоматически переключился на Historian на узле PC_B

8:36. Обновление MS SQL закончено, хоть перезагрузку сервер и не попросил, все равно сделаем restart Windows.

Обновить IDE, GR, Application Server, Historian до версии 2014

8:38. Копируем дистрибутив SP2014 на узел PC_A. Дистрибутив весит около 3,5 Гб

Дистрибутив у меня в виде zip архива, поэтому архив распаковываем и запускаем файлик setup.exe из корня дистрибутива.

9:05 Запуск установщика SP2014

  • На первом же шаге, просят обновить Microsoft .NET Framework до версии 4.5. Обновления есть в составе дистрибутива SP2014 и запускается оно нажатием кнопки «Install Prerequisites». MS .NET Framework 4.5 устанавливался около 25 минут.
  • На следующем шаге появилось предупреждение, что компоненты SP будут обновлены до версии SP 2014. Выбрать только некоторые компоненты для обновления нельзя, обновляются все ранее установленные. В процессе обновления добавить или удалить компоненты тоже нельзя. Если требуется изменить состав установленного на узел ПО, тогда после обновления необходимо запустить установщик еще раз и выбрать «modify»
  • В процессе установки исталятор сругался на работающий процесс Wonderware Vendor Daemon (это aaLicServer.exe), пришлось его принудительно завершить. Просто убить его из диспетчера задач не получилось, пришлось сначала открыть менеджер лицензий и удалить сервер лицензий. Потом только убивать процесс aaLicServer.exe из диспетчера задач. После удаления сервера лицензий Historian Client на узле PC_IT_1 поработал 5 минут и перешел в дело режим (на втором узле у меня установлена локальная, а не серверная лицензия на Historian Client, поэтому так все нормально) Таймер демо режима пошел. Отчет с 15 минут. Будем наедятся, что установка за это время закончится и я смогу опять поднять сервер лицензий. Последний этап установки — конфигурирование, инсталятор его запускает после нажатия кнопки «Configure» и через пару минут установка закончена. Инсталятор запросил перезагрузку сервера.

10:15 — запуск перезагрузки системы.

10:20. После перезагрузки сервера, первым делом поднимает сервер лицензий. Лицензии конечно же уже ставим новые на SP2014!!!. Менеджер лицензий теперь абсолютно новый: «Invensys License Manager» (хотя никто не мешает воспользоваться и старым менеджером лицензий, только он переехал с папку: Пуск->Invensys->License Manager->ArchestrA License Manager)

10:25. После установки новых лицензий Historian client на узле PC_IT_1 автоматически подцепил лицензию и самостоятельно вышел из демо режима.

Открыть обновленную IDE и произвести миграцию Галактики в версию SP2014

10:32. Открываем обновленную среду разработки — IDE, выбираем нашу Галактику и подключаемся к ней. При первом подключении система запрашивает миграцию Галактики в новую версию… соглашаемся и ждем окончания миграции. У меня Галактика небольшая (бэкап 140 МБ, и менее 100 своих шаблонов и объектов) , поэтому миграция заняла всего 15 минут. Но в случае БОЛЬШИХ галактик — сотни мегабайт, сотни объектов и пр — есть рекомендации по оптимизации SQL сервера для произведения миграции (см. Оптимизация работы SQL или TN 921 Optimizing SQL Server for Large Galaxy Migration). И кроме этого есть еще возможность миграции и переноса объектов из старой версии в новую с помощью экспорта-импорта.

Обновить БД Runtime сервера Historian на узле PC_A

10:50. При попытке открытия из SMC сервера Historian выдается ошибка: «Fatal initialization error — unable to start. (Older version of Runtime database found. Run the Wonderware Historian database configurator utility to mirgate/create the Runtime database)». Запускаем конфигуратор сервера Historain (Пуск->Wonderware->Common->Configurator->Historain Server) и нажимаем Configure (галочку «drop and create new database» я не ставил)

10:55 После окончания конфигурирования БД Runtime открываем SMC и убеждаемся что все службы сервера Histrian «зелененькие» (количество служб по сравнению с предыдущей версией увеличилось). У меня дольше всего стартовал OLE-DB Provider

После старта сервера Historian на узле PC_A с узла PC_B пошли текущие и store&forward данные (это можно заметить: по появлению MDAS с AppEngine узла PC_B в списке «Data Acquisition» сервера Historian на узле PC_A и по уменьшению объема каталога store&forward данных для узле PC_B).

Задеплоить платформу на узел PC_A (GR)

11:10. Возвращаемся к IDE и начинаем разворачивать Галактику на узел GR (у меня это PC_A).

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

Затем разворачиваем AppEngine. При попытке задеплоить AppEngine выпала ошибка: «Failed to deploy AppEngine1: Cannot deploy failover enabled engine as partner is not included». Придется немного «поплясать с бубном». И так. Конечно же среда разработки не желает выполнять разворачивание системы, в «Wonderware System Platform Installation Guide» указано, что при обновлении резервной пары необходимо остановить основной и резервный Engine, по очереди их обновить, а затем только разворачивать на них объекты. Но т.к. перед собой я ставлю задачу по-максимуму сохранить архивные данные и по возможно не лишать оператора доступа к процессу управления. Поэтому я делаю следующее:

  • Разъединяю сетевое соединения «RMC»
  • Изолирую узел PC_A от основной сети «ArchestrA»
  • В IDE выполняю undeploy платформы с резервной копией AppEngine1, обязательно с галочкой «On Failure Mark as Undeployed». Пускай система считает ee раздеплоинной
  • Выполняем deploy AppEngine1 (конечно же без партнера, хотя галочка не доступна, т.к. не система считает вторую платформу незадеплоиной). Галочку «Cascade deploy» можно поставить.
  • Отключаем PC_B от сети ArchestrA и RMC
  • Возвращаем узел PC_A в сеть «ArchestrA» и сеть «RMC»
  • Узлы InTouch успешно подхватывают работу с узлом PC_A.
  • Данные Historian на узле PC_A — есть частично (какие-то теги есть, какие-то отсутствуют). Ищем причину: …Реалтайм данные идут без проблем … смотрим лог событий и видим кучу сообщений типа: «AppEngine1.PC_A: Tag M300.LT.PV failed to add to Historian after 3 attempts [HistTag.cpp, 2492]». Да, исторические данные все таки теряем. Попробуем решить проблему. Перезагрузка сервера не помогла. Пробуем удалить теги с сервера Historian, в итоге получаем ошибку «The statement has been terminated. The DELETE statement conflicted with the REFERENCE constraint «FK_SnapshotTag_Tag». The conflict in database «Runtime», table «dbo.SnapshotTag», column ‘TagName'». Так все ясно. У меня на сервере Historian были заведены Event Tags и в качестве Action->Snapshot для некоторых из них были задействованы теги с Application Server. Вот именно эти теги у меня и не шли :). Отлично. Делаем экспорт event tags и их настроек с Historian на узле PC_A (Пуск ->Wonderware->Historian->Database configuration export and import ->Export и выбираем галочку «include event tags»). Удаляем event теги с сервера Historian. Делаем Commit… Так, архивные данные теперь идут нормально. На всех выше описанных манипуляциях потеряли около 20 минут архивных данных. Время 13:00, продолжим после обеда.

Обновить узел PC_B — роли: Application Server и Historian

Все дистрибутивы на узел PC_B я скопировал за ранее, поэтому процесс установки ПО должен быть быстрее.

Удалить платформу с узла PC_B при помощи утилиты «Plaftorm Remover»

13:25. Запускаем «A_ Plaftorm Remover» на узле PC_B и удаляем платформу

Наученные горьким опытом сразу удаляем event теги с сервера Historian на узле PC_B (на нем они тоже настроены, перед удалением, конечно же делаем экспорт их настроек в текстовый файлик Пуск ->Wonderware->Historian->Database configuration export and import ->Export и выбираем галочку «include event tags»)

Восстанавливаем сети «ArchestrA» и «RMC».

Перед остановкой Historian на узле PC_B посмотрим как работает redundant Historian в случае разных версий сервера:

  • Данные Store&forward c AppEngine1 для Historian на узле PC_B — передались. Кстати в них тот же перерыв в 20 минут есть и здесь (см. выше)
  • Historian client без проблем распознает redundant пару (переключается при обрыве связи на доступный сервер)
  • Application Server 2014 тоже без проблем распознает такую пару
Обновить MS SQL сервер до версии MS SQL 2012 SP1

13:50. Выполняем shotdown (disable) сервера Historian на узле PC_B

13:55. Запускаем установку SP1 для MS SQL server на узле PC_B

14:10 Обновление MS SQL закончено, на всякий случай перезапускам узел PC_B

Обновить Application Server, Historian до версии 2014

14:15. Запускаем обновление SP

15:10. Обновление завершено, в конце кнопка «Configure», а после конфигурации «Restart»

15:15. Сразу после старта системы обновляем БД Runtime сервера Historian на узле PC_B, действия те же что и для узла PC_A, поэтому особо не расписываю.

15:20. Устанавливаем лицензии на Historian 2014

Задеплоить платформу на узел PC_B

15:25. Открываем IDE на узле PC_A, подключаемся к Галактике и выполняем deploy узла PC_B, можно сразу каскадный для всех объектов платформы узла PC_B. Так в момент разворачивания пропало еще около 2-х минут архивных данных.

Обновить узел PC_IT_1 — роли: InTouch Runtime with Historian Client

Осталась самая легкая часть — обновить узлы с InTouch. Обновлять узлы с HMI я буду по очереди. Чтобы в любой момент времени был доступен хотя бы один интерфейс оператора. Начнем с первого узла.

15:40. Закрываем WindowViewer и Historian Client. Платформу я не удаляю, она удалиться при установке обновления автоматически.

Запускаем setup.exe из дистрибутива SP2014 на узле PC_IT_1

На шаге «Prerequisites» требуется обновить Microsoft .NET framework до версии 4.5 и Microsoft Visual C++ 10.0 SP1 x64 Runtime Redistributable. Это занимает около 5 минут. Гораздо быстрее чем на серверных узлах (там это требовало около 20-25 минут).

15:50. Установщик завершил работу. Перезагружаем Windows

15:55. Выполняем deploy платформы и InTouch проекта на узел PC_IT_1. Разворачивание прошло на первый взгляд прошло без проблем.

Пробую открыть WindowViewer — не дает, говорит что требуется миграция проекта.

Открываю InTouch Application Manager, версия InTouch в которой был создан проект 10.6. Ну конечно, кто же будет InTouch проект мигрировать-то.

Возвращаюсь к IDE, открываю проект в WindowMaker соглашаюсь с миграцией и с созданием backup. Проект открылся, но я его сразу же закрываю. Провожу Check-IN и передиплаиваю экземпляр InTouch проекта на узле PC_IT_1. После, особо не мудрствуя, на станции оператора сразу пробую запустить WIndowViewer. При открытии он предупреждает что проект был обновлен и спрашивает применить или нет изменения. Конечно же «ДА».

16:15. Обновления узла PC_IT_1 завершено. Повторяем те же действия и для узла PC_IT_2

16:25. Обновление ПО на узле PC_IT_2, выполняем deploy платформы и экземпляра InTouch проекта.

16:30. Обновление всех четырех станций в Галактике до SP2014 закончено.

Выводы по процессу обновления до SP2014

Общее затраченное время.

Приведенные ниже данные никак не приукрашены. Общее время включает в себя время копирования дистрибутивов, время установки, затраты времени на решение возникших проблем и пр.  Так что при надлежащей подготовке можно было бы и быстрее.

Узел Установленное на узле ПО Общее время обновления
PC_A IDE, GR, Application server, Historian, Lisense Server для Historian Client 5 часов 20 минут
PC_B Application Server, Historian 2 часа
PC_IT_1 InTouch Runtime with Historian Client с серверной лицензией на Historian Client (Per Server Conc) 45 минут
PC_IT_2 InTouch Runtime with Historian Client с локальной лицензией на Historian Client (Per Device)  15 минут
Общее время обновления 8 часов 20 минут

Анализ архивных данных

Анализируя тренды архивных параметров я нашел два окна:

  • первое около 20 минут — это когда возникли проблемы с event tags. В документации я пока не нашел информации по этой проблеме.
  • второе около 2 минут — это когда я вместо того, что бы деплоить резервные engine по очереди, решил сократить время и развернуть их одновременно. При этом у меня сначала выполнился undeploy, а затем deploy. Этого можно было вполне избежать.

Добавить комментарий