Środowisko systemu i transportu Comarch ERP Enterprise składa się z kilku zainstalowanych systemów Comarch ERP Enterprise, które pełnią różne funkcje. Poszczególne systemy mogą być od siebie zależne. W ramach środowiska systemowego mogą zostać uruchomione systemy do zapewniania jakości, rozwoju, testowania opracowanych dostosowań oraz systemy wykorzystywane produkcyjnie.
Systemy te mogą tworzyć ściśle powiązane rodziny systemów za pośrednictwem zdefiniowanych ścieżek transportowych albo komunikować się ze sobą i udostępniać sobie wzajemnie usługi.
W obrębie jednego systemu usługi takie jak zarządzanie wydrukami, zarządzanie magazynem, dostęp ODBC oraz usługi integracji biznesowej powinny zostać rozdzielone w sposób zapewniający płynne działanie.
Termin środowisko systemowe jest zatem używany z jednej strony do opisu wielu systemów Comarch ERP Enterprise oraz relacji pomiędzy nimi, a z drugiej strony do opisu komponentów pojedynczego systemu Comarch ERP Enterprise i zależności między tymi komponentami.
Niniejszy artykuł przedstawia możliwe warianty środowiska systemowego oraz komponenty powiązane. Skupiono się na projektowaniu środowiska systemowego pojedynczego systemu Comarch ERP Enterprise. Specyfikę środowiska obejmującego wiele systemów Comarch ERP Enterprise opisano w artykule Środowisko systemowe.
Grupa docelowa
- Administratorzy systemu
- Konsultanci techniczni
Wymagania wstępne
- Pomyślnie zainstalowano system Comarch ERP Enterprise
- Wymagania dotyczące środowiska systemu są znane
Środowisko systemu Comarch ERP Enterprise
Poniższe sekcje opisują środowisko systemowe dla systemu Comarch ERP Enterprise oraz jego komponentów. W niniejszym artykule przedstawiono typowe systemy instalowane w ramach środowiska systemowego Comarch ERP Enterprise. Następnie wymieniono komponenty, które logicznie należą do pojedynczego systemu. Na końcu opisano możliwości łączenia komponentów i usług oferowanych przez Comarch ERP Enterprise oraz rozmieszczenia wymaganych elementów na komputerach.
Systemy Comarch ERP Enterprise
W tej sekcji przedstawiono typowe systemy Comarch ERP Enterprise występujące w środowisku systemowym oraz relacje pomiędzy nimi.
System zapewnienia jakości
Zanim aktualizacje oprogramowania zostaną dostarczone do klienta lub zanim aktualizacje oprogramowania od partnera deweloperskiego zostaną zaimportowane do własnych systemów, zaleca się ich wcześniejsze zaimportowanie do systemu zapewnienia jakości (QAS).
Jednym z powodów jest możliwość centralnego zaopatrywania kolejnych systemów poprzez QAS, z wykorzystaniem funkcji Aktualizuj system docelowy. Dodatkowo, w systemie niewykorzystywanym produkcyjnie można zweryfikować, czy importowane aktualizacje nie powodują niepożądanych skutków, a następnie centralnie zdecydować, czy powinny zostać zaimportowane do innych systemów.
Aktualizacje oprogramowania mogły wcześniej zostać zaimportowane do systemu nadrzędnego w innej kolejności i w innym rozkładzie czasowym (np. rozłożonym na tygodnie). Aby przetestować spójność oraz możliwość instalacji aktualizacji przeznaczonych do dostarczenia, zalecane jest ich zainstalowanie w QAS przed przekazaniem do systemu produkcyjnego.
Systemy wywoływane funkcją Aktualizuj system docelowy muszą być zarejestrowane w tej samej bazie danych konfiguracji oraz udostępnione QAS jako systemy docelowe aktualizacji oprogramowania.
Pomiędzy systemami docelowymi a QAS istnieje jedynie luźna zależność, ponieważ system QAS nie musi być niezbędny do działania pozostałych systemów.
Systemy prezentacyjne
Systemy prezentacyjne są instalowane głównie do celów prezentacyjnych, szkoleniowych i edukacyjnych. W środowisku systemowym stanowią one niezależne systemy bez dodatkowych powiązań z pozostałymi systemami.
Systemy deweloperskie
W oparciu o standard Comarch ERP Enterprise partnerzy tworzą rozszerzenia specyficzne dla branży w systemie deweloperskim. Dla każdego klienta, dla którego mają zostać wykonane indywidualne adaptacje, tworzony jest osobny system deweloperski.
Systemy deweloperskie charakteryzują się tym, że każdy deweloper uruchamia własny SAS oraz środowisko programistyczne na komputerze lokalnym. System adaptacji może opierać się bezpośrednio na standardzie Comarch ERP Enterprise albo na systemie branżowym partnera.
Aktualizacje oprogramowania utworzone w systemie deweloperskim są importowane do innych systemów Comarch ERP Enterprise. W momencie zaimportowania aktualizacji wyeksportowanej z systemu deweloperskiego do systemu następczego system następczy staje się zależny od systemu deweloperskiego.
Testowe systemy rozwojowe
W testowym systemie rozwojowym importowane i testowane są adaptacje utworzone w systemie deweloperskim. Importowane aktualizacje oprogramowania mogą być również łączone w większe pakiety przed ich importem do kolejnych systemów.
Jeżeli w testowym systemie rozwojowym aktualizacje oprogramowania są łączone, a następnie jedna z tak przygotowanych aktualizacji zostaje zaimportowana do systemu niższego szczebla, system niższego szczebla staje się zależny od testowego systemu rozwojowego. Testowy system rozwojowy pozostaje zależny od systemu deweloperskiego, z którego pobiera aktualizacje oprogramowania.
System wewnętrzny – usługa zleceń deweloperskich
Usługa zleceń deweloperskich może wspierać proces rozwoju niezależnie od systemu i wydania. Usługa, realizowana jako zadanie w tle, powinna być stale dostępna dla systemów deweloperskich, które z niej korzystają.
Pomiędzy systemami zaangażowanymi w rozwój a systemem wewnętrznym występuje silne powiązanie, ponieważ dane są wymieniane pomiędzy systemami deweloperskimi a systemem wewnętrznym poprzez usługę zleceń deweloperskich. Jeżeli w testowym systemie rozwojowym aktualizacje oprogramowania są łączone w dostawy wsparcia, zarządzanie dostawami wsparcia odbywa się w systemie wewnętrznym, a system wewnętrzny oraz testowe systemy rozwojowe wymieniają dane.
System testów produkcyjnych
System testów produkcyjnych służy do testowania planowanych ustawień procesów oraz rozszerzeń oprogramowania przed przeniesieniem ich do systemu produkcyjnego. W szczególności krytyczne czasowo przetwarzania masowe są testowane na kopii danych rzeczywistych pochodzących z systemu produkcyjnego.
Ponadto system testów produkcyjnych pełni zwykle rolę systemu szkoleniowego. System testów produkcyjnych jest zależny od systemu deweloperskiego lub testowego systemu deweloperskiego, z którego pobiera aktualizacje oprogramowania do importu.
System produkcyjny
System produkcyjny zarządza wszystkimi danymi istotnymi dla działalności przedsiębiorstwa, wynikającymi z codziennych transakcji biznesowych. System produkcyjny jest zależny od systemu deweloperskiego, testowego systemu deweloperskiego lub systemu testów produkcyjnych, z których bezpośrednio pobiera aktualizacje oprogramowania do importu.
Zależności między systemami
Wymienione systemy Comarch ERP Enterprise są zwykle powiązane ustalonymi trasami transportowymi, a więc są od siebie zależne. W przypadku instalacji systemu wewnętrznego systemy są dodatkowo powiązane z systemem wewnętrznym poprzez wykorzystanie usługi zleceń deweloperskich.
Logiczny podział systemu Comarch ERP Enterprise
Pojedynczy system Comarch ERP Enterprise składa się z kilku komponentów, takich jak bazy danych OLTP, Comarch ERP Enterprise Output Manager (SOM) oraz Comarch ERP Enterprise Application Server (SAS). Komponenty te udostępniają różne usługi, z których część może być realizowana również pomiędzy systemami.
Bazy danych Comarch ERP Enterprise
System Comarch ERP Enterprise obejmuje kilka baz danych, takich jak baza danych repozytorium, baza danych konfiguracji systemu, jeden lub więcej OLTP, jedna lub więcej baz danych OLAP. Baza danych konfiguracji systemu jest współdzielona między systemami, natomiast pozostałe bazy danych należą do konkretnego systemu.
Status klasy Comarch ERP Enterprise
Każdy system Comarch ERP Enterprise posiada w danym czasie zdefiniowany status klasy, przechowywany w systemie plików, który w czasie wykonywania udostępnia klasy dla wirtualnej maszyny Java (JVM).
Wersje klas w systemie plików muszą być zgodne z wersjami odpowiednich obiektów programistycznych w repozytorium systemu. Dodatkowo wersje klas mapowania DBU przechowywanych w systemie plików muszą odpowiadać fizycznemu schematowi bazy danych w bazach danych systemu Comarch ERP Enterprise.
Jedynie pełna spójność wersji zapewnia płynne działanie systemu Comarch ERP Enterprise. Z tego względu bazy danych Comarch ERP Enterprise wraz z systemem plików tworzą logiczną całość i muszą pozostawać na tym samym poziomie.
Serwer aplikacji Comarch ERP Enterprise
Każdy Comarch ERP Enterprise Application Server (SAS) uzyskuje dostęp do baz danych systemu. W czasie wykonywania dostępny jest status klasy przypisany do tego systemu. System Comarch ERP Enterprise może wykorzystywać jeden lub kilka SAS, przeznaczonych do różnych zastosowań.
Serwer komunikatów
Każdy system Comarch ERP Enterprise posiada dokładnie jeden wyróżniony SAS, który działa jako serwer komunikatów i realizuje komunikację pomiędzy kilkoma SAS tego samego systemu. Serwer komunikatów odpowiada m.in. za zarządzanie blokadami oraz wykonywanie silnika przepływu pracy w obrębie różnych SAS. Ponadto komunikacja z innymi systemami Comarch ERP Enterprise jest realizowana za pośrednictwem serwera komunikatów danego systemu.
SAS dla dostępu interaktywnego
Głównym zadaniem Comarch ERP Enterprise Application Server jest odbieranie i przetwarzanie interaktywnych poleceń użytkowników. SAS przeznaczony do dostępu interaktywnego powinien być wykorzystywany wyłącznie do tego celu.
Na dane SAS nie powinien być wykonywany dostęp ODBC i nie powinny być konfigurowane dla nich kolejki zleceń przetwarzania.
Ustawienia JVM są optymalizowane pod możliwie krótki czas cyklu Garbage Collection.
SAS te mogą również przejmować zadania przetwarzania w tle, jednak powinny być planowane poza godzinami, w których odbywa się dostęp interaktywny.
SAS dla zadań w tle
Oprócz zapytań interaktywnych w systemie realizowane są również zadania w tle, takie jak transfer danych do modułu księgowego lub przenoszenie danych do statystyk OLAP. Zadania te charakteryzują się długim czasem wykonywania oraz inną charakterystyką obciążenia niż zapytania interaktywne.
Z tego względu zasadne jest przewidzenie odrębnych serwerów SAS przeznaczonych do realizacji zadań w tle, które są obsługiwane w ramach kolejek przetwarzania.
Ustawienia JVM dla tych serwerów SAS są optymalizowane pod kątem możliwie wysokiej przepustowości.
Zadania w tle
Comarch ERP Enterprise udostępnia szereg usług realizowanych jako specjalne zadania w tle. W kolejnych sekcjach opisano wybrane usługi oraz ich specyfikę w ramach środowiska systemowego.
Środowisko planowania
Środowisko planowania realizuje swoje zadania w całości w pamięci operacyjnej, dlatego, w zależności od poziomu obciążenia, wymaga wykorzystania znacznej części dostępnej sterty pamięci JVM.
Środowisko planowania pracuje zawsze na dokładnie jednej bazie danych OLTP. Na jednym serwerze SAS może zostać uruchomione tylko jedno zadanie w tle środowiska planowania.
Dla środowiska planowania należy stosować dedykowany serwer SAS. Dla każdej bazy danych OLTP wymagane jest uruchomienie osobnego środowiska planowania, a tym samym osobnego serwera SAS.
Serwer logistyki magazynowej
Serwer logistyki magazynowej jest uruchamiany jako zlecenie przetwarzania dla miejsc składowania.
Dla jednej bazy danych OLTP możliwe jest uruchomienie kilku serwerów logistyki magazynowej. Na jednym serwerze SAS może jednocześnie działać kilka serwerów logistyki magazynowej.
Serwer logistyki magazynowej odwzorowuje magazyny w całości w pamięci operacyjnej i – w zależności od liczby zarządzanych magazynów – wymaga znacznych zasobów pamięci JVM.
Usługa zleceń deweloperskich
Usługa zleceń deweloperskich udostępnia międzysystemowe zarządzanie procesem rozwoju – od momentu zgłoszenia aż do utworzenia dostarczenia wsparcia.
Business Integration Service
Do wymiany danych z innymi systemami wykorzystywany jest Business Integration Service (BIS). Komponent ten obejmuje cały proces wymiany danych – od ich ekstrakcji, poprzez konwersję, aż po komunikację z innymi systemami.
Za pośrednictwem tego interfejsu możliwa jest również wymiana danych pomiędzy różnymi systemami Comarch ERP Enterprise.
SAS dla dostępu ODBC
Dostęp ODBC jest realizowany przez programy zewnętrzne, takie jak Crystal Reports, Cognos i Excel, a także przez Comarch ERP Enterprise Output Manager, w celu przygotowania danych do wydruku artykułu lub raportu.
Do obsługi zapytań wynikających z dostępu ODBC można przeznaczyć jeden lub kilka serwerów SAS dedykowanych wyłącznie do tego celu.
Administrator może skonfigurować dla użytkowników wpisy DSN na stacjach klienckich, tak aby zapytania były kierowane do wybranego serwera SAS, a nie do serwerów SAS zdefiniowanych do obsługi zapytań interaktywnych.
Dla SOM każdorazowo zapisywana jest informacja, z którego serwera SAS ma on korzystać podczas wykonywania zapytania ODBC.
SAS dla dostępu partnerów biznesowych
Dostęp partnerów biznesowych do własnego systemu jest zazwyczaj realizowany za pośrednictwem publicznej infrastruktury internetu. Aby umożliwić dostęp do systemu Comarch ERP Enterprise, a jednocześnie nie dopuszczać użytkowników do sieci wewnętrznej, zasadne jest uruchomienie serwera SAS w strefie DMZ.
SAS systemu deweloperskiego
W systemie deweloperskim każdy programista uruchamia lokalnie własny serwer SAS w celu testowania i debugowania wprowadzonych rozszerzeń. Dodatkowo zasadne jest uruchomienie centralnego serwera SAS, wykorzystywanego do centralnego check-in oraz zapewniającego osobom niebędącym programistami możliwość zapoznania się z aktualnym stanem rozwoju.
Comarch ERP Enterprise Output Manager
Comarch ERP Enterprise Output Manager (SOM) udostępnia usługi wydruku międzysystemowo. Nie uzyskuje bezpośredniego dostępu do baz danych systemu ani nie korzysta ze stanu klas systemu.
Do każdego systemu Comarch ERP Enterprise należą systemowe wpisy dotyczące Comarch ERP Enterprise Output Manager oraz urządzeń wydruku. Wpisy w różnych systemach Comarch ERP Enterprise mogą wskazywać na tę samą instalację SOM oraz na te same urządzenia wydruku.
Comarch ERP Enterprise Accounting
Comarch ERP Enterprise Accounting to system księgowy odpowiedzialny za sprawy finansowe firmy.
Dla każdej bazy danych OLTP, dla której ma być wykorzystywany moduł finansowy, wymagana jest osobna instancja lub instalacja.
Komponenty innych producentów
System Comarch ERP Enterprise opiera się na szerokiej gamie sprzętu i oprogramowania innych producentów, z których wszystkie są częścią środowiska systemu Comarch ERP Enterprise i muszą być uwzględnione we wszystkich rozważaniach związanych z planowaniem środowiska systemu lub optymalizacją wydajności.
Niekompletna lista możliwych komponentów innych producentów obejmuje na przykład:
- Systemy zarządzania bazami danych (DBMS)
- Systemy operacyjne (OS)
- Serwery poczty e-mail
- Oprogramowanie i sprzęt faksowy
- Drukarki i sterowniki drukarek
- Rozwiązania równoważenia obciążenia
- Przełączniki i inne komponenty sieciowe, takie jak karty sieciowe klientów
- Zapory sieciowe
- Programy antywirusowe
- Rozwiązania do tworzenia kopii zapasowych
- Rozwiązania wirtualnej sieci prywatnej (VPN)
- Serwer terminali (Citrix)
- Rozwiązania SAN
- Komputery klienckie
- Sprzęt serwerowy
Komponenty te mogą być łączone na różne sposoby. Na jednym komputerze może działać kilka z wymienionych rozwiązań, a niektóre elementy mogą występować zarówno jako rozwiązania programowe, jak i sprzętowe.
Ponadto istnieją kolejne produkty firm trzecich wspierane przez Comarch ERP Enterprise:
- D.3
- Format
- Infostore
- QS1
- Varial
- Xpert.ivy
W przypadku aplikacji Format, QS1, Varial i Xpert.ivy wymagana jest jedna instancja lub instalacja dla każdej bazy danych OLTP, dla której mają być używane. Należy zapoznać się z dokumentacją producenta i artykułami dotyczącymi integracji z Comarch ERP Enterprise, aby uzyskać dokumentację dotyczącą instalacji oraz wymagań.
Dzielenie usług
W środowisku systemowym kilka z wymienionych komponentów i usług może działać w czasie rzeczywistym na jednym lub wielu komputerach.
W zakresie podziału komponentów możliwe są liczne warianty: od skrajnego przypadku, w którym wszystkie komponenty są zainstalowane na jednym komputerze, po wariant, w którym dla każdego komponentu przewidziany jest osobny sprzęt.
Dla konkretnego środowiska systemowego zazwyczaj wybierana jest forma mieszana, której wyposażenie zależy m.in. od następujących wymagań:
- Przeznaczenie (systemy deweloperskie lub produkcyjne)
- Profil obciążenia (liczba użytkowników, ilość obsługiwanych danych)
- Wymagania dotyczące wysokiej dostępności
- Geograficzne rozmieszczenie oddziałów
- Zaangażowane komponenty zewnętrzne (serwer pocztowy, serwer faksu, starsze aplikacje).
Przykłady możliwych kombinacji wymieniono w poniższych sekcjach.
Serwer bazy danych
Baza danych może być realizowana za pomocą rozwiązania klastrowego i przechowywać pliki danych w sieci SAN lub może działać na samodzielnym serwerze.
Serwery baz danych korzystają w szczególności z tak zwanej zasady skalowania, w której wydajność komputera jest zwiększana poprzez dodanie większej liczby procesorów i pamięci głównej.
W Comarch ERP Enterprise, dzięki różnym typom baz danych, możliwe jest stosunkowo proste rozdzielenie ich na różne instancje baz danych. Przykładowo produkcyjna baza danych OLTP może działać na jednym komputerze w instancji DBMS, podczas gdy bardziej intensywnie odczytywane bazy danych OLAP oraz baza danych repozytorium mogą działać na drugim komputerze w osobnej instancji DBMS.
Posiadając dwie instancje DBMS na jednym komputerze, można m.in. oddzielić produkcyjny system testowy od systemu produkcyjnego. W ten sposób na przykład początkowe raporty testowe nie mogą zastąpić ważnych danych produkcyjnych z pamięci podręcznej bufora, ponieważ jest ona zarządzana przez inną instancję systemu DBMS.
W planowaniu wyposażenia serwerów DBMS należy przewidywać możliwie dużą ilość pamięci operacyjnej. Zwłaszcza w przypadku implementacji 64-bitowej nie należy planować mniej niż 8 GB pamięci operacyjnej.
Na serwerze bazy danych powinno działać jak najmniej innych usług. Zaleca się uruchomienie serwera komunikatów na jednym z serwerów baz danych, ponieważ są one zwykle wyposażone w sprzęt, który jest lepiej chroniony przed awarią lub redundantny sprzęt, z którego korzysta serwer komunikatów.
Serwer plików
Wszystkie serwery SAS danego systemu powinny korzystać z centralnej struktury katalogów systemu Comarch ERP Enterprise na centralnym serwerze plików. Serwery SAS mogą jednak korzystać również z lokalnego stanu klas. W takim przypadku katalogi muszą być utrzymywane w synchronizacji, w szczególności po wgraniu aktualizacji oprogramowania.
Zalecane jest centralne przechowywanie klas dla wszystkich serwerów SAS danego systemu.
Każdy system Comarch ERP Enterprise wymaga własnego stanu klas oraz własnego katalogu Comarch ERP Enterprise Home. Na jednym serwerze plików mogą być przechowywane katalogi Comarch ERP Enterprise Home wraz z wymaganymi stanami klas dla wielu systemów Comarch ERP Enterprise. System plików zazwyczaj nie musi (i zwykle nie powinien) znajdować się na serwerze bazy danych, ponieważ generowałoby to dodatkowe, głównie odczytowe obciążenie podsystemu I/O.
Przy wykorzystaniu NFS w Unix lub DFS w Windows zasoby z wielu źródeł mogą być udostępniane pod jedną ścieżką. Przykładowo w ramach /opt/cisag/V4R1M0 mogą być montowane różne katalogi systemów Comarch ERP Enterprise z wielu źródeł, co umożliwia jednolite podejście do obsługi.
W przypadku pracy mieszanej z kilkoma systemami operacyjnymi należy zwrócić uwagę między innymi na następujące punkty:
- W przypadku pracy mieszanej z i5 i Linuksem lub Windows i SAS uruchomionym na i5, znacznie wydajniej jest przechowywać system plików na i5 niż pozwolić SAS na dostęp do innego systemu plików z i5
- W przypadku pracy mieszanej z systemami Windows DFS i Linux należy pamiętać, że różna obsługa uchwytów plików może na przykład prowadzić do problemów z blokowaniem
Należy zapoznać się również z odpowiednią dokumentacją systemu operacyjnego lub usług, za pośrednictwem których zintegrowane są systemy plików.
Serwer aplikacji Comarch ERP Enterprise
Środowisko systemu i wykorzystanie serwerów aplikacji (SAS) są ograniczone przez dostępny sprzęt i ograniczenia maszyny wirtualnej Java.
Na systemie operacyjnym 32-bit serwer SAS nie może adresować dowolnie dużej ilości RAM. Ze względu na garbage collection JVM oraz współdziałanie z systemem operacyjnym istnieją ograniczenia skalowania dotyczące liczby jednocześnie aktywnych instancji JVM.
Na systemie 8-procesorowym niekoniecznie osiem serwerów SAS będzie działać jednocześnie wydajnie, ponieważ m.in. duża liczba context switch może zwiększać narzut zarządzania systemu operacyjnego do tego stopnia, że CPU nie będą wykorzystywane optymalnie.
Serwery SAS korzystają zatem z tzw. skalowalności, w której wyższą wydajność uzyskuje się dzięki wykorzystaniu kilku komputerów poprzez dystrybucję SAS na te komputery.
Serwer komunikatów
Serwer komunikatów jest centralnym punktem przełączania między SAS. Jeśli serwer komunikatów jest zajęty i nie może odpowiedzieć na żądanie SAS, SAS uruchamia się ponownie i próbuje ponownie połączyć się z serwerem komunikatów. Zapobiega to między innymi pracy SAS z nieaktualnymi informacjami blokującymi i zagraża spójności danych.
Należy unikać sytuacji, w których serwer komunikatów nie może zostać osiągnięty, np. z powodu nadmiernego wykorzystania procesora serwera, na którym jest uruchomiony lub z powodu długich faz GC.
Serwer komunikatów powinien działać na jednym z serwerów baz danych. Wymaga on bardzo mało procesora i tylko umiarkowanego rozmiaru sterty dla swoich zadań jako serwer komunikatów.
Silnik przepływu pracy zwykle działa również na serwerze komunikatów, co prowadzi do podstawowego obciążenia serwera. Jest to zwiększone przez dużą liczbę złożonych definicji aktywności, które regularnie prowadzą do generowania dużej liczby zadań, a tym samym do generowania wielu wiadomości e-mail.
SAS dla operacji interaktywnych
Każdy użytkownik tworzy nowe obiekty Java, które wymagają pamięci głównej poprzez interakcje z SAS. Jeśli nie są już potrzebne, obiekty te mogą zostać usunięte po pewnym czasie przez przez mechanizm Garbage Collection JVM albo pozostać przywoływane w sesji użytkownika, co uniemożliwia ich usunięcie.
Ograniczenia rozmiaru sterty w systemach 32-bitowych, implementacje algorytmów GC i wymóg, aby czasy GC nie wpływały na interaktywną pracę nawet przy dużych stertach w systemach 64-bitowych oznaczają, że tylko ograniczona liczba użytkowników może pracować nad SAS w tym samym czasie.
Liczba ta w dużym stopniu zależy od profilu obciążenia generowanego przez użytkowników i musi być indywidualnie zaplanowana, zmierzona i dostosowana do każdego środowiska systemowego.
W zależności od przeznaczenia systemów, na jednym komputerze może działać różna liczba SAS.
- W przypadku systemu produkcyjnego wymagania dotyczące pamięci uruchomionego SAS nie mogą przekraczać fizycznie dostępnej pamięci. W przeciwnym razie pod obciążeniem wystąpią efekty zamiany i wydajność spadnie.
- W środowisku produkcyjnym liczba interaktywnych SAS nie powinna przekraczać liczby procesorów na komputerze
- W środowisku systemu deweloperskiego kilka SAS może działać na jednym komputerze, a zapotrzebowanie na pamięć może również przekraczać fizycznie dostępną pamięć główną. Zazwyczaj rozmiary sterty w trybie deweloperskim są mniejsze, ponieważ mniej użytkowników stale pracuje na SAS. Ponadto w trybie deweloperskim można zaakceptować dłuższe czasy odpowiedzi spowodowane na przykład wymianą.
- Na interaktywnym serwerze SAS mogą być planowane zadania w tle realizowane w okresach niskiej aktywności użytkowników, np. w godzinach nocnych
Dostęp do SAS-ów przeznaczonych do pracy interaktywnej powinien być przejrzysty dla użytkowników za pomocą mechanizmów równoważenia obciążenia, jeśli używanych jest kilka interaktywnych SAS-ów. Mechanizmy równoważenia obciążenia mogą być również wykorzystywane do kierowania grup użytkowników do tego samego SAS przez cały czas.
SAS dla dostępu partnerów biznesowych
Oddzielne SAS dla dostępu partnerów biznesowych są przydatne wszędzie tam, gdzie wykorzystywani są partnerzy biznesowi.
Ze względu na ograniczony zakres uprawnień partnerów biznesowych, na jednym interaktywnym serwerze SAS możliwe jest zazwyczaj obsłużenie większej liczby partnerów biznesowych niż użytkowników posiadających pełny dostęp do systemu.
SAS dla zleceń w tle
Do realizacji zadań w tle, takich jak transfer danych finansowych czy obsługa serwera logistyki magazynowej, w zależności od profilu obciążenia można stosować kilka serwerów SAS w ramach jednego systemu. Serwery te mogą być uruchamiane na tych samych komputerach co serwery SAS przeznaczone do pracy interaktywnej.
Przykładowo, na typowym komputerze wyposażonym w dwa procesory i 4 GB pamięci operacyjnej możliwe jest uruchomienie dwóch interaktywnych serwerów SAS oraz jednego serwera SAS do zadań w tle. Możliwe jest również uruchomienie trzech serwerów SAS obsługujących różne zadania w tle na takim komputerze.
Zasadniczo zadania w tle mogą być dowolnie łączone, dzięki czemu np. wszystkie zadania w tle w systemie demonstracyjnym mogą być realizowane przez jeden serwer SAS.
Najważniejsze usługi realizowane w Comarch ERP Enterprise jako zadania w tle są opisane osobno w kolejnych sekcjach, jednak ogólne zasady przedstawione w tym rozdziale mają do nich również zastosowanie.
Przy planowaniu serwerów SAS do zadań w tle należy uwzględnić następujące aspekty:
-
każde aktywne zadanie w tle wymaga co najmniej jednego dedykowanego wątku
-
każde aktywne zadanie w tle zużywa dodatkowe zasoby systemowe, takie jak CPU, oraz generuje obciążenie serwera bazy danych poprzez zapytania kierowane do warstwy DBMS
Zalecane jest ograniczanie liczby wątków w celu kontrolowania generowanego obciążenia. Dodatkowo możliwe jest nadawanie zadaniom w tle różnych priorytetów wykonania, np. poprzez ustawienia w szablonach artykułów końcowych oraz w ustawieniach użytkowników.
Zadania w tle powinny być dzielone na zadania długotrwałe oraz krótkotrwałe. W połączeniu z priorytetami oraz różnymi kolejkami przetwarzania, oferującymi różną liczbę wątków, możliwe jest np. realizowanie długotrwałych i zasobożernych zadań w kolejce z dwoma wątkami, natomiast krótkich zadań, takich jak generowanie artykułów, w kolejce z pięcioma wątkami.
Podział na różne kolejki przetwarzania zapobiega sytuacji, w której długotrwałe zadania zajmują wszystkie dostępne wątki i blokują realizację pozostałych zadań. Zadanie w tle, które zostało już uruchomione, nie jest przerywane przez zadanie o wyższym priorytecie. Zróżnicowane priorytety umożliwiają natomiast uprzywilejowanie zadań o wyższym priorytecie w momencie zwolnienia wątku.
Często spotykane ustawienia dopuszczające do 100 jednoczesnych wątków są zazwyczaj kontrproduktywne, ponieważ obciążenie generowane przez taką liczbę równolegle wykonywanych zadań nie może zostać obsłużone przez warstwę DBMS. W rezultacie przepustowość systemu spada zamiast wzrastać.
W środowiskach deweloperskich oraz w systemach demonstracyjnych zadania w tle mogą być uruchamiane również na serwerze komunikatów, ponieważ liczba jednocześnie pracujących użytkowników jest tam niewielka.
SAS dla usługi integracji biznesowej
Jeżeli dane są intensywnie wymieniane z innymi systemami oraz w dużym wolumenie, konieczne może być zastosowanie kilku serwerów SAS wyspecjalizowanych w obsłudze tych usług.
Należy określić, ile scenariuszy wymiany danych system ma obsłużyć w danej jednostce czasu. Jeżeli na przykład w ciągu jednej godziny realizowanych jest kilka rozbudowanych i długotrwałych scenariuszy wymiany danych, zasadne jest rozważenie wykorzystania wielu serwerów SAS dedykowanych do tych zadań.
Dla takich serwerów SAS należy w szczególności zwiększyć partycję pamięci podręcznej danych podstawowych, aby uzyskać wyższy współczynnik trafień i poprawić wydajność przetwarzania.
SAS dla środowiska planowania
Planowanie odbywa się w pamięci głównej. Z tego powodu SAS, na którym działa środowisko planowania, nie powinien przetwarzać żadnych innych zadań oprócz środowiska planowania.
Przydział zależy od obciążenia, którym należy zarządzać i liczby scenariuszy planowania, które mają być dostarczane jednocześnie.
SAS dla serwera logistyki magazynowej
Magazyny są mapowane w całości w pamięci głównej. Dlatego na serwerze SAS, na którym działa serwer logistyki magazynowej, powinno być wykonywane możliwie niewiele innych zadań.
Dla każdego magazynu wysokiego składowania należy zaplanować osobny serwer logistyki magazynowej, a tym samym osobny serwer SAS. Inne typy magazynów mogą być zazwyczaj obsługiwane przez jeden serwer logistyki magazynowej.
SAS dla dostępu ODBC
Dedykowane serwery SAS do dostępu ODBC są zasadne w środowisku produkcyjnym oraz w środowiskach, w których produkty firm trzecich intensywnie korzystają z dostępu ODBC do danych.
Jeżeli wykorzystywanych jest kilka instalacji Comarch ERP Enterprise Output Manager, dla każdej z nich można zdefiniować dokładnie jeden serwer SAS przeznaczony do obsługi zapytań ODBC.
W aplikacji Źródła danych ODBC jako domyślny serwer SAS do dostępu ODBC wyświetlany jest serwer, na którym użytkownik jest aktualnie zalogowany. Ten interaktywny serwer SAS zazwyczaj nie dopuszcza dostępu ODBC.
Możliwe jest na przykład zastosowanie dwóch serwerów ODBC-SAS: jednego do zapytań wykonywanych przez SOM oraz drugiego do zapytań realizowanych przez użytkowników w narzędziach takich jak Cognos lub Excel.
Dla użytkowników należy utworzyć odpowiednie wpisy DSN, co pozwala jednoznacznie określić, z którego serwera ODBC-SAS mają być wykonywane zapytania.
SAS systemu deweloperskiego
Każdy programista wymaga własnego serwera SAS uruchamianego lokalnie w ramach środowiska Java IDE. Centralnie musi być uruchomiony Message Server, który odpowiada za synchronizację pamięci podręcznej, na przykład w zakresie blokowania obiektów deweloperskich pomiędzy poszczególnymi serwerami SAS.
Zadania w tle w środowisku deweloperskim mogą być w razie potrzeby uruchamiane przez programistów na ich własnych serwerach SAS.
Comarch ERP Enterprise Output Manager
Comarch ERP Enterprise Output Manager (SOM) powinien być uruchamiany na osobnym komputerze. Serwery SAS przeznaczone do dostępu ODBC mogą być zasadnie uruchamiane na tym samym komputerze.
Instalacja wielu instancji SOM ma uzasadnienie przede wszystkim w środowiskach produkcyjnych, jeżeli wolumen przetwarzanych danych jest zbyt duży dla jednego komputera. W takim przypadku czynnikiem ograniczającym skalowalność SOM na jednym komputerze jest najczęściej wydajność procesora.
W przypadku realizacji wydruków do oddziałów podłączonych na przykład za pomocą łączy stałych zalecane jest umieszczenie SOM w centrum danych. Opóźnienia sieciowe mają wówczas mniejszy wpływ na przesyłanie wygenerowanych plików bufora wydruku do drukarek w oddziałach niż na komunikację pomiędzy SOM a serwerami ODBC-SAS podczas wykonywania zapytań ODBC.
W zależności od zastosowanego rozwiązania wydruku, na przykład z wykorzystaniem serwera wydruku w oddziale, obciążenie komunikacyjne może się odwrócić i korzystniejsze może być umieszczenie SOM bezpośrednio w oddziale.
Ponieważ zachowanie systemu zależy od dostosowanych artykułów oraz raportów, a także od zastosowanego rozwiązania wydruku, zalecane jest zaplanowanie pomiarów dla obu wariantów.
Należy również zaplanować zarządzanie pasmem z wykorzystaniem mechanizmów Quality of Service dla oddziałów, aby na przykład rozbudowane wydruki były przesyłane z niższym priorytetem niż dostęp użytkowników do interaktywnych serwerów SAS.
Przykłady krajobrazów systemowych
Spośród przedstawionych możliwych kombinacji należy wybrać taką konfigurację, która najlepiej odpowiada określonym wymaganiom. W tym celu w pierwszej kolejności konieczne jest zdefiniowanie wymagań dla środowiska systemowego.
Poniższe wyjaśnienia przedstawiają przybliżone profile wymagań. Wymagania muszą zostać zdefiniowane znacznie dokładniej w projekcie, a następnie wdrożone. Środowiska systemowe muszą być dostosowane do konkretnych okoliczności i wymagań.
Systemy demonstracyjne
Kilka systemów z różnymi wersjami kodu może być zainstalowanych na przykład na notebooku, które współdzielą DBMS i instalację SOM. Zazwyczaj w danym momencie działa dokładnie jeden SAS pojedynczego systemu Comarch ERP Enterprise. Zainstalowane systemy mają własne systemowe bazy danych i poziomy klas, dzięki czemu mogą być obsługiwane niezależnie.
Jeśli system demonstracyjny jest zarejestrowany w centralnej bazie danych konfiguracji w całej firmie z adresem URL (nie localhost) i jeśli serwer pomiarowy QAS może komunikować się z serwerem komunikatów systemu demonstracyjnego, wówczas system demonstracyjny może być również dostarczany z aktualizacjami oprogramowania bezpośrednio z systemu QAS za pomocą funkcji Aktualizuj system docelowy.
Systemy deweloperskie
W środowisku programistycznym wiele usług jest używanych bardzo rzadko lub tylko przy niewielkiej ilości danych:
- Serwer bazy danych dla obsługiwanego systemu DBMS
- Centralny serwer plików lub sieć SAN
- Systemy demonstracyjne na notebookach
- System QAS, serwer komunikatów jest uruchamiany na żądanie
- System rozwoju lub korekty partnera ze stale dostępnym centralnym serwerem komunikatów
- System testowy rozwoju partnera ze stale dostępnym centralnym serwerem pomiarowym
- System wewnętrzny ze stale dostępnym serwerem komunikatów
- Systemy adaptacyjne i systemy testów adaptacyjnych dla bieżących projektów
- Instalacja SOM
Serwery komunikatów mogą na przykład razem z SOM działać na jednym serwerze lub kilka serwerów komunikatów systemów Comarch ERP Enterprise może być uruchamianych na jednym komputerze.
Zazwyczaj tylko niewielka liczba systemów adaptacyjnych pracuje w tym samym czasie. Ich serwery komunikatów muszą być dostępne dla programistów, natomiast pozostałe systemy są uruchamiane ponownie dopiero w razie potrzeby.
Całe systemy, takie jak system adaptacji i system testowania adaptacji, mogą być nawet archiwizowane jako obraz vmware i przywracane tylko w razie potrzeby, np. gdy wymagana jest korekta.
System wewnętrzny – usługa zleceń rozwojowych
W przypadku systemu wewnętrznego należy uruchomić tylko serwer komunikatów, na którym usługa zleceń rozwojowych jest skonfigurowana jako zadanie w tle.
Ten serwer komunikatów powinien być stale dostępny w środowisku deweloperskim, aby w dowolnym momencie możliwe było tworzenie nowych Zleceń deweloperskich w systemach deweloperskich korzystających z tej usługi.
System zapewniania jakości
Tylko jeden serwer komunikatów musi być uruchomiony dla Systemu Zapewnienia Jakości (QAS). I tylko wtedy, gdy jest to wymagane.
Środowiska produkcyjne
Wymagania stawiane środowiskom produkcyjnym różnią się od wymagań stawianych np. środowisku programistycznemu. Podczas gdy SAS są często ponownie uruchamiane w środowisku programistycznym, należy unikać tak zwanego czasu przestoju systemu produkcyjnego. Objętość danych przetwarzanych przez systemy i liczba użytkowników będą wielokrotnie wyższe niż w środowisku programistycznym.
Poniższe sekcje przedstawiają przykłady sposobów dystrybucji usług świadczonych przez system.
Środowisko produkcyjne – przykład 1
W tym przykładzie przetwarzana jest niewielka liczba użytkowników i umiarkowana ilość danych.
W środowisku produkcyjnym znajdują się co najmniej dwa systemy: system testowy i system produkcyjny. System testowy jest uruchamiany tylko w razie potrzeby i jest przeznaczony tylko dla niewielkiej liczby użytkowników:
- Centralny serwer bazy danych
- System plików systemów znajduje się również na serwerze bazy danych
- Produktywny system testowy:
- Serwer komunikatów jest uruchamiany na żądanie
- Ten system może być skonfigurowany w tej samej instalacji DBMS
- W razie potrzeby serwer komunikatów jest uruchamiany na serwerze bazy danych
- System produkcyjny:
- Serwer komunikatów działa stale na serwerze bazy danych i przetwarza niezbędne zadania w tle
- SOM i ODBC SAS działają na oddzielnym serwerze
- SAS dla dostępu interaktywnego na oddzielnym komputerze
- SAS dla zadań w tle działa razem z interaktywnym SAS na tym samym komputerze
Środowisko produkcyjne – przykład 2
W tym przykładzie należy spełnić wyższe wymagania dotyczące dostępności, zwłaszcza w przypadku baz danych. Na przykład ze względu na intensywne korzystanie ze środowiska planowania i większą liczbę użytkowników konieczne jest użycie kilku wyspecjalizowanych SAS na oddzielnych serwerach:
- Serwer bazy danych z bazą danych standby/failover lub klastrem
- Serwer systemu plików i plików bazy danych
- Produkcyjny system testowy:
- System można skonfigurować w ramach tej samej instalacji DBMS
- W razie potrzeby serwer komunikatów jest uruchamiany na komputerze testowym
- w razie potrzeby uruchamiany jest dodatkowy serwer SAS do testów środowiska planowania, działający razem z serwerem komunikatów
- Na komputerze testowym uruchamiany jest również SAS ODBC
- System produkcyjny:
- Serwer komunikatów działa nieprzerwanie na jednym z serwerów baz danych i przetwarza niezbędne zadania w tle
- SOM i ODBC SAS działają na oddzielnym serwerze
- Kilka SAS-ów do interaktywnego dostępu działa na oddzielnych komputerach
- SAS do planowania działa na komputerze razem z interaktywnymi SAS
- Jeden SAS dla partnerów biznesowych
Środowisko produkcyjne – przykład 3
W tym przykładzie wymagania wysokiej dostępności dotyczą w szczególności bazy danych. Intensywne wykorzystanie wszystkich obszarów udostępnianych przez Comarch ERP Enterprise, w tym środowiska planowania, oraz duża liczba jednocześnie aktywnych użytkowników powodują konieczność zastosowania wielu wyspecjalizowanych serwerów SAS na osobnych komputerach.
System testowy produkcyjny przechowuje dane systemu produkcyjnego jako jego lustrzane odwzorowanie.
- Serwer bazy danych z rezerwową/awaryjną bazą danych lub klastrem
- SAN dla systemu plików i plików bazy danych
- Testowy system produkcyjny :
- Serwer komunikatów działa stale na jednym z serwerów baz danych
- Ten system jest skonfigurowany w oddzielnej instancji DBMS
- Kilka SAS do ciągłego testowania środowiska planowania i serwera logiki magazynu, a także przetwarzania w tle
- Jedna instalacja SOM z ODBC-SAS i jeden SAS do przetwarzania w tle na jednym komputerze
- System produkcyjny:
- Serwer komunikatów działa stale na jednym z serwerów baz danych
- Kilka SAS dla wymaganych zadań w tle
- Kilka SAS dla serwera logistyki magazynowej
- Kilka SAS dla środowiska planowania na własnych komputerach
- Kilka SOM i kilka ODBC SAS działa na własnych serwerach
- Jeden SAS do łączenia się z innymi systemami za pośrednictwem Corba i usług sieciowych
- Kilka SAS do interaktywnego dostępu działa na własnych komputerach, np. Blade Center
- Load balancer do dystrybucji dostępu do SAS
- Jeden lub więcej SAS dla partnerów biznesowych
Zmiany w środowisku systemu
Zmiany w obrębie środowiska systemu Comarch ERP Enterprise
Środowisko systemowe pojedynczego systemu Comarch ERP Enterprise nie stanowi konfiguracji stałej w czasie. Zmiany warunków brzegowych, takie jak wzrost wolumenu zleceń, przejęcia i fuzje przedsiębiorstw czy zmiana platformy całej infrastruktury IT, powodują konieczność dostosowania środowiska systemowego.
Dzięki elastycznej architekturze Comarch ERP Enterprise tego typu dostosowania mogą być realizowane w krótkim czasie.
Zmiany środowiska systemowego wielu systemów Comarch ERP Enterprise
Zmiany środowiska systemowego obejmujące wiele systemów Comarch ERP Enterprise oraz ich wzajemne relacje wymagają szczególnie ostrożnego podejścia. Tego typu zmiany mogą prowadzić do istotnych modyfikacji ścieżek transportowych pomiędzy systemami i dlatego muszą być dokładnie zaplanowane.
Dodatkowe informacje na ten temat przedstawiono w artykule Środowiska systemowe.
