Доброго времени!
Время от времени выносы (подключены по туннелю через cisco) уходят в состояние Out of service. В инцидентах причины покуда не нашел. Возможно, уходят в аут при пропадании туннелей и не желают подниматься. Лечится тем, что по телнету захожу на GD и делаю ей рестарт.
Delivery software version : g1.503
Patch version : 17 ;
Dynamic patch version : b

В основном такая штука происходит с выносами, где качество интернета не очень хорошее, но бывает и на точках с хорошим интернет-каналом.
Где поковырять можно?

Не хотите попробовать g1.503.27?

К сожалению - совершенно неприемлимый вариант. Потребуется абгрейдить все GD, иначе они по полчаса-минут сорок подниматься будут при перезагрузке, новые бинарники скачивая.
А их 72 штуки по разным странам мира. Для посольств делали. А GD удаленно я чегой-то не знаю как апдейтивать....

вариант pcs не хотите расмотреть

так по сути если мозги поднять до g1.503.27 gd должны сами подхватить новый патч, которые не подхватят тут уж придется в рукопашную пинать на апгрейд

Стоят там PCS.
GD сами новый патч подхватывают, только процесс его загрузки на GD длится, как я уже сказал, порядка получаса и дольше.
А так как частенько сеть колбасит - на PCS переходит моментом, а обратно долго - льет бинарники новые каждый раз.

А чего, PCS с основным процом на разных версиях?
1 - нафиг это надо
2 - чего бы вам в /DHS3bin/downbin не положить одинаковые бинарники (чего надо - смотрим лог загрузки GD).

нет, сорри, запутал я наверное )))
во фразе: "на PCS переходит моментом, а обратно долго - льет бинарники новые каждый раз" я отписал что получается, ежели на центре версию поднять.
В этом случае, GD находит новую версию софта на центре и долго грузится.

по поводу пункта 2 - я правильно понял: поднять до 27 релиза, а бинарники в него засунуть от 17 b?

хорошая идея - поднять до 27 релиза, а бинарники в него засунуть от 17 b
потом засунуть бинарики от 27 и поочередно ребутать gd чтоб накладно небыло т.е. чтоб все выносы разом не отвалились

to error: бинарники не сохраняются в памяти GD сами, они там живут, при заливе с центра только до перезагруза.
Чтоб они туда записались, надо пешком их переливать через PCInstaller.
В этом и проблема.

хм... в релизе 9 GD-2 сама подхватила новые бинарики после поднятия патча на проце

попробуйте, ради интереса, прицепиться к GD через консоль , перегрузить gd и понаблюдать выйдет ли сообщение, что найдена новая версия софта, которая, собственно грузится и будет с центра.
Как я уже говорил, бинарники подхватываются, но в память GD не пишутся и после перезагруза их ему приходится заново подхватывать.
А у меня на сети есть точки с проблемным инетом им и так не сладко, а если еще и станция по 40 минут поднимаеться будет....



Редактировано 1 раз. Последний раз 19.08.2009 14:55 пользователем Vsjakov.

startmg и т.п. грузятся всегда. Собственно биос и прочее - один раз.
Если регулярно падают (и надолго) - смотрим в сторону PCS (если в центре CS или AS, если CPU - не канает).

> startmg и т.п. грузятся всегда.
вот оно самое долго и грузится. PCS стоят на всех выносах, в центре AS .
падают на некоторых точках довольно часто, но ненадолго. Потому народ и возмущает, что долго поднимается потом.
Как резюме всему вышесказанному: таки порекомендуете поднять центр до 27 релиза?
И пусть разводят в проблемных точках с провайдером, дабы каналы не падали....?

Поднял релиз до 31. Не цеплялся софт на GD потому как не успевал залиться и GD перегружалась по тайм-ауту со старым софтом. Поднял timout на GD до максимально возможного (3600) 80 процентов выносов залилось (где инет хреновый - так и неуспевает до перегруза залиться).
Какая картина была - такая и осталась. Причина, как мне кажется, в том, что PCS не желают выходить из активного режима. Вот только не разобрался еще почему.... Может кому что в голову придет?