Топология AOS'ов

[Sequel]

Доброго времени суток.
Мы работаем с трехзвенной архитектурой, топология системы такова: 1 база данных, 4 AOS'а (по 2 на 2-х компьютерах), AOS'ы не объединены в кластер, каждому пользователю в зависимости от географического расположения (разные магазины в разных городах) назначен свой AOS.
При этом все AOS'ы используют общее приложение.
Вопрос 1: отличается ли такая схема работы от той, когда все AOS'ы объединены в кластер? Например кэширование данных из базы в некластерной системе работает не совсем корректно: закэшированные данные в одном AOS'е не видят изменений в других какое то время, пока не обновятся. Как работает кэширование данных в кластерной системе?
Вопрос 2: при внесении изменений в программный код какие действия надо сделать чтобы он обновился сразу во всех Аосах. В некластерной системе, я так понимаю, для этого нужно чтобы эти изменения записались не только в кэш, но и на диск в файлы приложения, после чего остальные аосы должны обновить у себя в кэше эти объекты. Как происходит обновление кода в кластерной системе?

[zemlyn]

вопросов там не два а 4
попробую ответить на те, что про кластер
1)кэширование данных в кластерной системе (для entire table cache - вроде тоже у нас не сразу изменения происходят - но в нормативную минуту вроде укладываемся

The entire table cache is flushed automatically at midnight on an AOS. This type of cache is synchronized every minute within an installation, so that even with mixed clients and multiple AOS’s, the cache is reasonably synchronous.

2)для того, чтобы новый код виделся на обоих AOS, стопорим AOS, в 2звенке импортируем проекты, запускаем AOS

[Sequel]

т.е. обновлять код можно только в 2-х звенке? а почему нельзя обновить его на одном из АОСов, потом остановить и этот АОС и все остальные? Разве после перезапуска код не обновится? А еще интересно можно ли вносить изменения без остановки АОСов. Скажем принудительно заставлять АОС сбрасывать кэш объектов в файлы приложения, а затем заставлять другие АОСы заново читать все свои объекты из файлов приложения

[zemlyn]

1)както повелось, сказали из MBS делать "так", иначе не проверяли.
2)с терминологией не совсем понятно - в вашем понимании (я думал в первом посте опечатка) обновление сначала попадает в кэш и только потом в файлы приложения. Разумеется все наоборот - весь вопрос в том, чтобы кэш приложения потом раздать серверу и клиентам. У нас не 24*7, поэтому такой вопрос не вставал, может ктото поделится как решали проблему.

[Sequel]

Т.е. я просто неправильно представлял себе процесс внесения изменений в программный код? Любые изменения СРАЗУ ЖЕ записываются на диск в файлы приложения? Никакой отложенной записи из кэша потом?

[savel]

У себя мы делаем так:
в 3х звенке заливается необходимые модифиикации, компилируется. Далее входишь на другой AOS, там говоришь "востановить" и компилируешь там (у нас только 2 AOS'а. Вам похоже нужно проделать такую операцию на всех). После для пользователей которым важны внесённые модификации говориться, что нужно выйти из Аксапты и удалить *.aoc файлы.
Необходимо отметить, что без остановки AOS'ов переносить модификации нужно, если не в крайних случаях, то по крайней мере осторожно. Добавление полей в общеиспользуемых таблицах, в них же изменение состава индексов - только через остановку.

[Sequel]

2savel
ну собственно мы так и делаем.
а АОСы у вас в кластере или нет?

[savel]

Да в кластере.
Но даже если бы они были не в кластере - (но обращаются к одному приложению) алгоритм обновления не изменился бы.

[Sequel]

Мне просто интересно - есть ли какие нибудь противопоказания против работы нескольких АОСов, не объединенных в кластер с одним приложением

[savel]

Не думаю, что есть противопоказания,(хотя твёрдого знания нет). Но Вы же должны иметь возможность распределения пользователей по AOS'ам через кластеры или иным способом.