Konfiguracja farmy serwerów frontend AMODIT
Komunikacja w farmie serwerów
Jeżeli AMODIT jest zainstalowany na więcej niż jednym serwerze IIS lub witrynie, to zmiana wprowadzona na jednym serwerze np. w procedurze, regule czy użytkowniku nie będzie widoczna na innych serwerach do czasu wygaśnięcia cache na tych serwerach albo do resetu puli aplikacji.
Podobna zasada dotyczy działania mechanizmu SignalR. Komunikat wysyłany z jednego serwera nie będzie docierał do użytkowników przypisanych do innego serwera.
AMODIT ma wbudowane mechanizmy komunikacji pomiędzy serwerami w farmie ale wymagają one skonfigurowania.
Poniżej przykład farmy serwerów
- Dwa serwery aplikacyjne pracujące jako farma serwerów (amoditap1, amoditap2)
- Na każdym serwerze dwie instancje AMODIT
- dla zwykłych użytkowników (amoditap1v, amoditap2v)
- dla administratorów (amoditap1vadm, amoditap2vadm)
- odrębny serwer z bazą danych (amoditdb)
Konfiguracja
Parametr systemowy LoadBalancedServers
JSON z tabelą zawierającą listę serwerów w postaci
[ {name: "amoditap1v", url: "http://amoditap1v:81"},
{name: "amoditap1vadm", url: "http://amoditap1v:82"},
{name: "amoditap2v", url: " http://amoditap1v:81"},
{name: "amoditap2vadm", url: " http://amoditap1v:82"}]
UWAGA – w tym przykładowym środowisku, na każdym z serwerów są 2 witryny – normalna i do dostępu administracyjnego. Te witryny muszą mieć oddzielne wpisy.
web.config
W każdej witrynie w web.configu należy podać odpowiednie, unikalne wartości dla klucza WebSiteName, zgodne z nazwą z parametru „name” podaną w wyżej wspomnianym JSON. To jest potrzebne po to, aby „siebie” nie synchronizować.
<add key="WebSiteName" value="amoditap1v"/>
Dostęp
Komunikacja jest poprzez endpoint api/server – powinien on być dostępny anonimowo albo do witryny musi mieć dostęp konto puli aplikacji <location path=”api/server”>…