geereyeхм. ну в Киев тоже можно.
Ок, надо будет только как-то связаться.
И, хотелось бы, чтобы хотя бы два человека, а не один, выразили желание :)
Ну, так сказать, на троих сообразить :)
....
"SLA"....
.....


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


мыло в профиле.

geereyeдак фишка в том, что я больше по старостям, а не по новостям.
вот, к примеру, по софту, древний способ первый. генерируется две подсистемы IMS на одной z/OS. А поскольку базы отчуждены от СУБД чуть более, чем полностью, понятие системного каталога отсутствует как класс, то пока одна подсистема обслуживается (ptf накатываются), вторая работает с транзакциями и базами, потом меняются местами.
способ второй - одна машина бьётся на три сущности, coupling facility (меньшая, то есть совсем мелкая), и два LPAR в сисплексе, всё в пределах одной машины, напоминаю. Итого, на две z/OS в двух ЛПАР, допустим, 4 ЦПУ, по 2 ЦПУ в каждом. Останавливаем один ЛПАР с отдачей всей памяти и ЦПУ во второй ЛПАР - он теперь имеет все 4 ЦПУ, и начинаем обслуживать выведенную из эксплуатации ОСь со всеми подсистемами, в то время как общая мощность системы не снизилась - как обслуживалось всё на 4 ЦПУ, так и обслуживается. Потом меняем местами - подымаем обслуженную, выключаем необслуженную. Это, как бы, самая очевидная классика. В зависимости от эксплуатируемых подсистем может быть много чего ещё.
Это так, навскидку, наверняка эксплуатанты ещё способов накидают - сильно будет зависеть, все z/OS разные, каждый сисадмин генерит ОСь под себя, поэтому нету двух похожих ОСей (если только вам не российский офис наклонировал своей багливой нерабочей копии). Потому приёмы и способы будут отличаться в каждом случае.
Ок, письмецо брошу, контакт будет.

Я знаю что такое эксплуатация процессинга, что такое ЛПАР, не первый год с аиксом дружу,
как бросаться ресурсами, как переключаться на стендбай в оракле.
Даже что такое лив партишин мигрейшин знаю.
Но все это не то, когда нужно переключиться без остановки или накатить патч
на несколько терабайтную БД. Не в текстовых ;t файлах движения и остатки хранятся.
Пусть даже ночью, когда пару тройку, до десятка транзакций в секунду пролетает.

SLA однако.



geereyeТема накатки патчей идёт бок-о-бок с темой восстановления после сбоя, так что можно сразу обе.

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

geereyeДохтаР - так именно что без остановки обслуживания.
а бок-о-бок - потому что технологии одни используются.
Я тым выше менеджер очередей упоминал - немалая доля на него в этой ситуации ложится.
Когда одна система выводится, то запросы к ней не должны "пропасть" - вот они в нём и не пропадают, пока их другая система не извлечёт. И тут уже сам размер баз на дисках мало рояля играет, в такой ситуации, а вот глубина очередей и их надёжность много.
Так что по регламенту вещи - разные, а технологии используют схожие.
ну это теоритезирование - надо на практике смотреть и замерять - на сколько просело время отклика. И вписывается ли оно в заданный SLA.
Тут только смотреть.

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

И сам менеджер очередей где работает и как его апгрейдить?

geereyeя письмо кинул, может, что и сделаем, чему и научимся.

Ок , я вечером гляну.

geereyeО!
Харроший вапрос!
В нон-стопе он вообще в ОСь встроен.
И есть такой изречени - каждая субд мечтает стать ОСью, но не всем это удалось.
Я к тому, что, к примеру, ИМС это удалось, это фактически ОСь, и менеджер очередей встроен в неё.
вообще транзакционная обработка без менеджера очередей это ересь (ой!). но, наверное, действительно хватит офф-топить :)
пока не применили карательную медицину в виде принудительной психиатрической помощи :)

Транзакционная обработка нормально.
А теория массового обслуживания без манеджера очередей буксует.
:)

geereye на проектировании, на документировании, на правильно выстроенных процессах обеспечения жизненного цикла.


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