Na tej stronie (9)
- Platforma: .NET 10, MongoDB i Blazor Server
- Serwer własny czy chmura: dwa modele wdrożenia
- Kopie zapasowe, retencja i praca dwuserwerowa
- Uprawnienia użytkowników i zakres widoczności danych
- Wymagania po stronie sieci
- Czego architektura nie obejmuje
- Wyjście z usługi i przekazanie bazy danych
- Pytania działu IT o architekturę
- Powiązane
Platforma: .NET 10, MongoDB i Blazor Server
Serwer aplikacji działa na .NET 10, na Windowsie lub na Linuksie, więc wpasowuje się w serwerownię, która już istnieje, zamiast wymuszać drugą platformę.
Bazą danych jest MongoDB: jedna baza, około dziewięćdziesięciu kolekcji. Daje to jeden punkt kopii zapasowej i jeden punkt utrzymania, bez rozproszenia danych między instancje.
Interfejs działa w technologii Blazor Server, czyli jako aplikacja w przeglądarce, więc na stanowiskach niczego się nie instaluje ani nie aktualizuje.
TraxSystem jest modularnym monolitem: 75 modułów, jedno wdrożenie, jedna baza i zakres funkcji włączany licencją. Nie ma tu mikrousług do orkiestracji, kolejek do utrzymania ani synchronizacji między bazami.
Stany bram, alerty i zdarzenia przychodzą na żywo przez SignalR, bez odświeżania strony.
Rozpoznawanie tablic działa lokalnie: silnik odczytu pracuje na serwerze albo na urządzeniu brzegowym przy bramie. Detekcja obiektów działa na środowisku uruchomieniowym ONNX, również lokalnie. Obraz z kamer idzie strumieniowo przez konwersję do przeglądarki i nie jest zapisywany na dysk.
Serwer własny czy chmura: dwa modele wdrożenia
Oba modele wdrożenia TraxSystem mają tę samą aplikację i tę samą listę funkcji w licencji. Różnią się tym, gdzie stoi serwer, kto go utrzymuje i kto odpowiada prawnie za dane.
| Na Twoim serwerze | W naszej chmurze | |
|---|---|---|
| Gdzie stoi serwer | w Twojej serwerowni | w Polsce |
| Czyja infrastruktura | Twoja | nasza albo zewnętrznego dostawcy, do wyboru |
| Kto utrzymuje | Twój dział IT | my |
| Aktualizacje, kopie, monitoring | po Twojej stronie | w abonamencie |
| Deklarowana dostępność | nie dotyczy | 99% |
| Kopie zapasowe | po Twojej stronie | co 8 godzin, przy pracy dwuserwerowej ciągłe |
| Rola wobec danych osobowych | jesteś jedynym administratorem, podmiot przetwarzający nie występuje | jesteśmy podmiotem przetwarzającym, potrzebna umowa powierzenia |
| Praca przy awarii łącza | obiekt pracuje dalej | zależna od konfiguracji, ustalana w analizie |
| Dostęp do urządzeń | bezpośrednio w sieci lokalnej | wymaga łącza i konfiguracji dostępu |
| Ścieżka zakupu | jednorazowa albo abonament | tylko abonament |
Oba warianty są równorzędne i wybiera się je z konkretnych powodów. Własny serwer ma sens, gdy polityka firmy nie dopuszcza wynoszenia danych albo gdy obiekt musi pracować przy padzie łącza. Chmura ma sens, gdy nie ma działu IT, serwerowni albo chęci utrzymywania kolejnej maszyny.
Kopie zapasowe, retencja i praca dwuserwerowa
Kopia zapasowa bazy TraxSystem to archiwum z plikami zrzutu, konfigurowalne co do zakresu i częstotliwości. Przy wdrożeniu w chmurze wykonujemy ją co osiem godzin.
Retencja i anonimizacja działają jako osobny mechanizm: reguły z terminami, uruchamiane raz dziennie. Anonimizacja jest nieodwracalna; więcej o tym na stronie bezpieczeństwo danych.
Monitoring urządzeń i diagnostyka zgłaszają brak odpowiedzi z kamery, czytnika, wagi albo kontrolera, zanim zauważy to obsługa.
Praca dwuserwerowa działa w układzie aktywny–pasywny: zestaw replikacyjny bazy, pływający adres, usługa strażnika na Windowsie i na Linuksie, kreator konfiguracji w interfejsie aplikacji, przełączanie planowe i powiadomienia. Całość konfiguruje się z poziomu aplikacji.
Uprawnienia użytkowników i zakres widoczności danych
TraxSystem oddziela uprawnienia, czyli to, co użytkownik może zrobić, od zakresu widoczności, czyli tego, jakie dane widzi. Jedno i drugie ustala się osobno, najlepiej już na etapie oferty.
Uprawnień jest 217, w 24 grupach, a nadaje się je wyłącznie przez role. Są drobne celowo: rejestrowanie wjazdu, otwieranie szlabanu i dostęp do wszystkich bram to trzy osobne prawa.
Zakres widoczności ma dwa wymiary: obiekty docelowe oraz typy wjazdu. Reguła jest zaporowa: brak roli oznacza brak dostępu do danych, a nie dostęp do wszystkiego. Zakres obowiązuje także w raportach i eksporcie, więc nie da się go obejść pobraniem pliku.
Wymagania po stronie sieci
Serwer TraxSystem komunikuje się z urządzeniami na obiekcie: kontrolerami dostępu, kamerami, szlabanami, miernikami wagi, kioskami i terminalami. Adresację i reguły na zaporze ustala się w analizie przedwdrożeniowej.
Czego architektura nie obejmuje
Nie konfigurujemy sieci zakładowej. TraxSystem monitoruje urządzenia i łącza, ale nie zarządza przełącznikami ani zaporami.
Wyjście z usługi i przekazanie bazy danych
Przy wdrożeniu na Twoim serwerze baza danych jest u Ciebie, więc nie ma czego przekazywać.
Przy wdrożeniu w chmurze przekazujemy przy rezygnacji kopię bazy danych Twojej instancji. To pełna baza w formacie, który da się przywrócić, a nie eksport wybranych danych do arkusza.
Pytania działu IT o architekturę
Czy potrzebujemy serwera z kartą graficzną?
Dla samej aplikacji nie, bo silnik odczytu tablic działa na procesorze. Przy większej liczbie kamer i rozpoznawaniu tablic na serwerze karta graficzna przyspiesza przetwarzanie obrazu, więc uwzględnia się ją w analizie przedwdrożeniowej. Decyduje liczba kamer i to, czy rozpoznawanie ma działać na serwerze, czy na urządzeniu brzegowym.
Ile zasobów potrzebuje serwer?
Zależy od liczby bram, kamer i stanowisk. Wymagania podajemy dla konkretnej konfiguracji przy ofercie.
Czy da się to postawić na maszynie wirtualnej?
Tak, i tak wygląda większość wdrożeń na własnym serwerze.
Jak wygląda aktualizacja?
Aktualizacja to krótkie okno serwisowe na serwerze. Stanowiska nie wymagają żadnych działań, bo aplikacja działa w przeglądarce.
Czy udostępniacie API?
Tak, i budujemy na nim integracje opisane na stronie integracji.
Powiązane
Bezpieczeństwo danychIntegracje i APIObsługiwany sprzętLicencja i wsparcie
Do poczytania: Serwer własny czy chmura · ANPR brzegowy a chmurowy · Integracja z ERP: czego wymagać