Сбой сервера
Sppa t3000. Также там установлено 2 сервера, 10 рабочих станций, контроллеры и еще много чего.
Так вот где то 2 недели назад начались проблемы с видеограммами на клиентских компьютерах.
Начали зависать мнемосхемы и видеограммы, управление оборудованием (задвижки, регуляторы)
стало невозможным. Теперь постоянно около 3х часов пропадают графики по датчикам давления,
расходу и др.
Причина скорее всего в сервере. Ниже представлены скриншоты лога событий по серверу.
Не подскажете как можно исправить эту проблему? Заранее благодарю.
Проблема с графиками была, но по всем параметрам. В Siemens мне уточнили, что она может быть связана со слишком большим количеством запросов на сервер (открыто много трендов). Помогал перезапуск контейнера tds.
Кстати, на клиентах вылетают какие-нибудь ошибки?
Я попробую завтра посмотреть по Вашей проблеме на самом оборудовании.
А у Вас есть возможность полностью перезапустить сервера? Или оборудование в работе?
Судя по картинкам, у Вас все-таки сервера Primergy. А CoServer1 и CoServer2 - сервер приложений и архивный сервер соответственно.
При работающем оборудовании, перегружать сервера лучше не стоит. Отключение CoServer1 приведет к полной потере управления верхнего уровня и контроля за процессами. А перегружаются они довольно не быстро.
А как и где именно перезагружать контейнер tds - на инженерной станции (отдельный компьютер для инженера АСУТП) или на сервере?
На сервере в консоли SPPA можно посмотреть установленный размер, а в диспетчере задач - текущее использование (процессы с имнами _t3k....)
Не подскажете где эта консоль SPPA - просто мы (инженеры) побаиваемся лишний раз что-нибудь не то запустить))
ТАК вроде бы получше
На инженерной станции необходимо в SPPA-T3000 открыть Приложения->Вид диагностики. В открывшемся окне раскрыть узел CoServer2 (или CoServer1, если там тоько он). В иерархии появится строчка "tds". Выделив ее, справа отобразятся элементы управления. Надо будет нажать Стоп. Дождаться состояния "Остановлен" и нажать на Старт. Когда состояние будет "Работает" - контейнер полностью запустился. Можно перезапустить и через сервер. Зайти на CoServer2, запустить диспетчер задач и завершить процесс _t3k_tds (имя примерно такое). Запуститься он автоматически, просто проследите, что он снова появится в Процессах. Через сервер лучше перегружать, когда на инженерной станции он не перегружается (зависает).
Заходите на сервер. И ищете ярлык на рабочем столе или в Пуске Admin Console и запускаете. Причем, консоль есть на обоих серверах. И если их у Вас два, то контейнер tds будет в консоле CoServer2.
Еще хотел спросить, не вносилось ли в последнее время изменений в сетевое оборудование (маршрутизаторы) или программное обеспечение? И не происходит ли отказов в каком-нибудь из маршрутизаторов в это же время. Посмотрите логи.
Если никаких изменений не было, а ошибка носит спонтанный характер, то дело скорее всего в операционной системе. Читал про Вашу ошибку на сайте Microsoft. они советуют ставить дополнительные патчи. Хотя я бы не очень советовал это делать. Если только после консультации с поставщиком и наладчиком оборудования. На сколько мне известно, права на поставку продуктов компании Siemens в России были только у Siemens и ИнтерАвтоматики.
Получается нужно завершить процесс и ничего не делая он сам восстановится?
Изменений вроде бы не было. А как узнать что есть ошибки в маршрутизаторах. Какого содержания лог должен быть?
У нас как раз интеравтоматика устанавливала сервера и SPPA t3000
Если использовать этот метод, то да - контейнер запуститься автоматически. Есть специальные службы, которые отслеживают состояние процессов и автоматически их запускают при их пропадании.
Нужно отталкиваться от модели маршрутизаторов. Практически везде точно должны писаться пропадания линков (связи) на портах. Возможно какая-либо общая ошибка мрашрутизатора или связи.
Я посмотрел у себя, и ошибки с кодом 8032 и 8021 также периодически возникают. Но на работу не влияют. Мне кажется что работа SPPA-T3000 не зависит так от технологии DCOM, чтобы отваливать станции. По поводу предупреждений с кодами 166, 167, 169, 58 нужно поразбираться. И это системный журнал. А есть какие-нибудь события в журнале Application?
Если данная проблема больше не возникает или возникает редко, лучше дождаться момента когда остановится оборудование и полностью перезагрузить сервера согласно инструкции. И отследить работу после перезагрузки. Иначе необходимо просмотреть логи всех элементов сети, которые могут повлиять на работу и поточнее узнать о возможно проводимых в недавнее время работах.
Если есть какие-то сервесные договора с поставщиками - обратиться к ним.
Если будут вопросы - спрашивайте. Большинство информации, которая может понадобиться для выяснения причин, может быть квалифицирована как корпоративная тайна. Поэтому выкладывать ее здесь следует осторожно.
И это системный журнал. А есть какие-нибудь события в журнале Application?
Ниже я еще прикрепил скриншоты. Только не помню из какого они журнала
Согласно четвертой картинке железные и виртуальные сервера работают и синхронизированы.
А пропадание связи еще продолжаются?
И каким устройствам принадлежат ip 192.168.20.1(2)?
А пропадание связи еще продолжаются?
И каким устройствам принадлежат ip 192.168.20.1(2)?
Да время от времени висят сигналы "B" на всех мнемосхемах. Например на одной из видеограмм висит сигнал "В" уже 2-ое суток. Вроде бы это плохой сигнал качества...
Устройство с ip 192.168.20.2 это компьютер на другом объекте, удаленном от основного оборудования. У нас там все время выскакивает ошибка Синхронизации. Кстати еще у нас изменилось время с MSK на GMT, а потом на GMT+3 на SPPA T3000 - а на сколько мне известно GMT+4 это московское время
Сервер от GPS-часов, клиенты от сервера?
У нас были проблемы с графиками из-за того, что когда вводилась поправочная секунда одни из GPS часов ее подловили, а вторые - нет. Из-за рассинхронизации могут быть проблемы. Но не уверен, что со всеми данными.
Сервер от GPS-часов, клиенты от сервера?
Точно сказать не могу, а как это проверить?
у вас как в анекдоте :
экскурсия по заводу -
в этом цеху у нас ДОС... в этом ЮНИКС... а перед входом в цех где виндовс попрошу надет скафандры высшей защиты .
Заглянуть в проектную документацию))
Через интернет не должно быть синхронизации, по-идее. Требования промышленной безопасности запрещают внешние подключения к системам управления. По крайней мере, постоянные.
Посмотрите в шкафу с серверами или сетевым оборудованием. Чаще ставят именно туда.
К сожалению, большинство современных промышленных систем управления заточены под винду еще на этапе создания программных продуктов и SCADA-систем.
Так что выбирать не приходится.
И всегда в этот период?
А восстанавливаются сами?
Да с 3-х до 4-х пропадают а потом восстанавливаются. Это наверное связано с тем что у нас раньше показывалось время GMT+4, а теперь GMT+3. Также в обычном состоянии время на sppa допустим 14:00, а график (реальный) отображается до 13:00, а еще один час "дорисовывается" последним значением графика прямой линией. Например по давлению идут какие то скачки, а последнее значение допустим 22 кпа, вот им дорисовывается по прямой график с 13:00 до 14:00 как бы в будущее.
Это плохо. Необходимо обязательно привести синхронизацию времени впорядок.
А как это сделать не подскажешь?
Зависит от схемы самой синхранизации.
Допустим, эта схема: GPS-часы -> сервера -> клиенты.
Проверь сперва через консоль управления GPS-часами корректность получаемого ими времени. Если оно некорректно - проверь настройки часов через ту же консоль в плане часового пояса, задержек, доступности источника времени, расхождение между часми (резервированная схема).
Если оно корректно, переходим на сервера.
Здесь тоже необходимо знать схему получения времени (от часов или нет). Если используется NTP-клиент - проверить его настройки. Посмотреть часовой пояс, выставленный на сервере. Должен быть +4. Если не так, то либо вручную выставить +4 (например Баку), либо установить обновление с сайта Microsoft касательно времени России.
Теперь клиенты. Посмотреть настройки получения времени от серверов. Скорее всего это будет NTP-клиент. Проверить также часовой пояс. Он обязательно должен совпадать с асовым поясом на серверах.
Sppa t3000!!!
Меня зовут Михаил Арзуманьянц, и я работаю в подразделении «АСУ ТП для электростанций» Департамента «Производство энергии на ископаемом топливе» компании «Сименс». Я увидел Ваше сообщение на форуме и хотел бы помочь с решением возникшей проблемы.
Ниже Вы найдете некоторые рекомендации, которые помогут Вам разрешить вопросы, озвученные на форуме.
Я увидел у Вас на данный момент 4 явные проблемы:
1) Превышение подписки.
Признак – появление множественных сигналов качества B или U на мнемокадрах, чаще всего на динамических элементах, относящихся к одному контроллеру.
Причиной является то, что АРМы через Сервер Приложений опрашивают контроллеры о состоянии сигналов. Когда число одновременных опросов (подписок) достигает 1900, в ПСО появляется ошибка Subscription_Size_UL или Верхний предел количества по подписке, при достижении значения 2000, все динамические элементы на мнемокадрах, открытых далее, получат код качества B или U и перестанут обновляться.
Обходное решение – перезапуск (остановить/запустить) контейнера PDS через Вид диагностики. Занимает не более 2 минут, но в процессе перезапуска будут недоступны все динамические значения, и будет невозможно управление технологическим процессом. Данную процедуру не рекомендуется производить без консультации с проектировщиком и поставщиком ПТК.
Проверка текущего значения подписки – значение Current Subscription Size или Текущий размер подписки в меню <Вид диагностики – рантайм контейнер S7 или AS3000, в зоне которого замечены параметры с недостоверностью>. С помощью этого параметра можно отслеживать увеличение размера подписки при открытии видеокадров.
Решение:
• не открывать видеокадры в масштабе, меньше 100%. Т.е. не открывать несколько видеокадров на одном экране или ЭКП.
• пересмотреть состав «насыщенных» видеокадров и разбить их на несколько, с меньшим количеством динамических элементов.
2) Превышение нагрузки на контейнер TDS (контейнер для создания графиков) слишком большим количеством запросов.
Признак – отсутствие любых значений на графиках (пустые видеокадры с графиками).
Причиной является большое количество графиков, одновременно выведенных на экран.
Обходное решение – перезапуск контейнера TDS через Вид диагностики. Занимает до 2 минут, не влияет на управление. Во время перезапуска будет невозможно запустить график.
Решение (наблюдения желательно выполнять во время нормальной нагрузки на оборудование, а изменения во время останова основного оборудования):
• Проконтролировать, при каком количестве графиков, выведенных на АРМах, возникает данный сбой, сколько сигналов всего было выведено на графики, и сообщить цифру поставщику ПТК.
• Провести перераспределение ресурсов Сервера приложений. Для этого необходимо обратиться к поставщику ПТК.
3) Превышение нагрузки на архивный контейнер слишком большим количеством запросов.
Признак – отсутствие любых значений на графиках (пустые видеокадры с графиками) и невозможность создавать отчеты.
Причиной является большое количество запросов в архивный контейнер через отчеты (более 300 страниц единовременно) или графики.
Обходное решение – перезапуск контейнеров TDS, RC и ARC через Вид диагностики. Последовательность следующая: остановить контейнеры TDS, потом RC, потом ARC, запустить ARC, потом RC, потом TDS. Занимает, в зависимости от нагрузки на архив, до 10 минут, не влияет на управление. Во время перезапуска будет невозможно сформировать отчет или запустить график, а также значения любых сигналов не будут поступать в архив.
Решение (наблюдения желательно выполнять во время нормальной нагрузки на оборудование, а изменения, с помощью табличного проектирования, во время останова основного оборудования):
• пересмотреть апертуры аналоговых сигналов и увеличить их для сигналов с высокой частотой изменения величин. Это позволит избежать т.н. эффекта «дребезжания», который возникает, если колебания сигнала с датчика, возникающие без изменения технологического параметра, превышают апертуру, выставленную на блоках ASMON и ASEL.
• пересмотреть состав архивируемых параметров и исключить из архива вторичные и промежуточные значения.
• Провести перераспределение ресурсов Сервера приложений. Для этого необходимо обратиться к поставщику ПТК.
4) Неправильная настройка синхронизации времени.
Признак – ежедневное отсутствие или неверные значения на графиках в определенные промежутки времени, и превышение нагрузки на архивный контейнер (см. п.1) ввиду большого количества повторяющихся запросов сигналов с неправильной меткой времени (запрос параметров из будущего).
Причиной является неправильная конфигурация синхронизации времени на АРМ или Сервере приложений, т.к. именно клиент, на котором запущен workbench, формирует запрос в архив со своей меткой времени.
Обходное решение – не существует.
Решение (изменения на АРМ можно вносить в любой момент времени, предварительно выведя его из работы, изменения на Сервер приложений необходимо вносить только во время останова основного оборудования):
• на АРМ и Сервере приложений должна быть отключена служба «Windows time» и включены службы «Network Time Protocol Daemon» и «NTP Prepare».
• на АРМ и Сервере приложений проверить файл c:\Program files\ntp\etc\ntp.conf, он должен содержать следующие строчки на Сервере:
# Use specific NTP servers
server tmesrv01 minpoll 5 maxpoll 5 iburst
server tmesrv02 minpoll 5 maxpoll 5 iburst
и на АРМ:
# Use specific NTP servers
server <имя-сервера-приложений> minpoll 5 maxpoll 5 iburst
• на Сервере приложений проверить файл c:\Windows\system32\drivers\etc\hosts, он должен содержать следующие строчки:
tmesrv01 xxx.xxx.xxx.xxx
tmesrv02 xxx.xxx.xxx.xxx
где xxx.xxx.xxx.xxx – это IP-адреса Серверов точного времени (GPS-часов). Согласно стандартам «Сименс», поставщик ПТК вместе с Серверами приложений должен передать папку с документацией, содержащей настройки Сервера приложений, АРМ, их резервные копии, пароли и список сетевых компонентов. В этой документации Вы можете найти IP-адреса Серверов приложений и Серверов времени. Также эту информацию можно найти в документах «Структурная схема сетевого обмена» и «Перечень сетевых компонентов».
• на АРМ и Сервере приложений проверить временные зоны в настройках Windows. Она должна быть выставлена как UTC +Ваша временная зона. Переход на летнее время должен быть отключен. Внимание: смена временной зоны влечет за собой перезагрузку сервера.
Если у Вас возникнут дополнительные вопросы, пожалуйста, присылайте через личные сообщения свои контакты, и мы сможем в рамках поддержки продукта дополнительно Вас проконсультировать.