W modelu magazynu w chmurze cała infrastruktura serwerowa systemu WMS działa u dostawcy usługi, a nie w dziale IT przedsiębiorstwa. Dostawca utrzymuje sprzęt z siecią oraz bazę danych i mechanizmy zabezpieczeń. Ten artykuł opisuje to, co dzieje się po stronie serwera: architekturę oraz kopie zapasowe. Omawia też zasady odtwarzania i skalowanie zasobów.
Sposób logowania i pracy w przeglądarce wyjaśnia osobny tekst o magazynie on-line. Ocenę korzyści operacyjnych z pomiarem zawiera artykuł o korzyściach systemu WMS online, a wybór między chmurą a serwerem własnym porządkuje materiał o programie magazynowym w chmurze i on-premise. Tutaj punkt ciężkości leży na infrastrukturze.
Magazyn w chmurze od strony infrastruktury
Od strony technicznej magazyn w chmurze oznacza, że aplikacja programu magazynowego nie jest instalowana na komputerach w firmie. Działa na serwerach dostawcy, dostępnych przez Internet. Przedsiębiorstwo nie kupuje sprzętu, nie przygotowuje sieci lokalnej pod serwer bazodanowy i nie zatrudnia administratora odpowiedzialnego za jego utrzymanie.
Fizycznie aplikacja pracuje w centrum danych z zasilaniem awaryjnym i klimatyzacją precyzyjną. Łącza internetowe są w nim redundantne. Taki poziom zabezpieczeń rzadko jest dostępny dla pojedynczej firmy z niewielką serwerownią, ponieważ koszt rozkłada się na wielu klientów korzystających ze wspólnej infrastruktury.
Architektura serwerowa systemu WMS w chmurze
Typowa architektura ma trzy warstwy. Serwer aplikacyjny wykonuje logikę biznesową, a serwer bazy danych przechowuje stany i dokumenty. Warstwa sieciowa zestawia bezpieczne połączenie użytkownika z aplikacją. Wersja chmurowa Studio WMS.net korzysta z bazy Microsoft SQL Server, co zapewnia wydajność przy dużej liczbie jednoczesnych operacji na dokumentach magazynowych.
| Warstwa | Zadanie | Co można skalować niezależnie |
|---|---|---|
| Sieciowa | Terminacja TLS i kontrola dostępu do aplikacji | Liczba jednoczesnych połączeń |
| Aplikacyjna | Logika biznesowa, dokumenty, uprawnienia | Moc obliczeniowa i pamięć maszyny |
| Bazy danych | Przechowywanie stanów i historii operacji | Pojemność dysków i wydajność zapytań |
Podział warstw na oddzielne maszyny
Warstwy mogą działać na osobnych maszynach wirtualnych, dzięki czemu moc serwera aplikacyjnego i pojemność bazy danych zmienia się niezależnie. Rozdzielenie poprawia też odporność. Problem w jednej warstwie nie musi oznaczać niedostępności całej aplikacji dla magazynierów.
Model SaaS i podział odpowiedzialności
W modelu SaaS dostawca odpowiada za cykl życia infrastruktury: wymienia sprzęt i monitoruje wydajność. Instaluje też poprawki systemu operacyjnego oraz reaguje na awarie. Przedsiębiorstwo płaci abonament za aplikację i nie musi utrzymywać działu IT dedykowanego serwerowni. Zakres obowiązków obu stron w chmurze opisuje dokument o współodpowiedzialności w Microsoft Learn.
Reguła: dostawca odpowiada za infrastrukturę, ale nie za nadawanie uprawnień w firmie. Konta i role oraz ich odbieranie po odejściu pracownika pozostają zadaniem klienta.
Kopie zapasowe i odtwarzanie danych
Bezpieczeństwo danych magazynowych zależy od kopii wykonywanych automatycznie i niezależnie od pracowników. Kopie trafiają do lokalizacji fizycznie oddzielonej od serwerów produkcyjnych, co chroni dane nawet po poważnej awarii głównego centrum danych. Harmonogram i czas przechowywania kopii oraz procedura odtwarzania wynikają z umowy z dostawcą.
Baza SQL Server umożliwia trzy rodzaje kopii, które dostawca łączy w jeden plan. Opis wszystkich typów zawiera przegląd kopii zapasowych w dokumentacji Microsoft Learn.
| Rodzaj kopii | Zawartość | Wpływ na odtwarzanie |
|---|---|---|
| Pełna | Cała baza w chwili wykonania | Punkt startowy każdego odtworzenia |
| Różnicowa | Zmiany od ostatniej kopii pełnej | Skraca liczbę plików potrzebnych do odtworzenia |
| Dziennika transakcji | Zapis operacji od poprzedniej kopii dziennika | Pozwala odtworzyć stan z wybranej chwili |
RPO i RTO jako parametry umowy
Dwa parametry opisują odporność na awarię. RPO to największa dopuszczalna utrata danych mierzona czasem, a RTO to czas, w którym system ma wrócić do pracy. W bazie z kopiami dziennika transakcji RPO wynika wprost z częstotliwości tych kopii: przy kopii co kwadrans w najgorszym przypadku traci się kwadrans zapisów. RTO zależy od rozmiaru bazy i liczby plików do odtworzenia.
-- przykład: kopie pełna i dziennika oraz kontrola poprawności pliku
BACKUP DATABASE WmsProd TO DISK = N'E:\kopie\WmsProd_full.bak'
WITH CHECKSUM, COMPRESSION, INIT;
BACKUP LOG WmsProd TO DISK = N'E:\kopie\WmsProd_log_1200.trn'
WITH CHECKSUM;
RESTORE VERIFYONLY FROM DISK = N'E:\kopie\WmsProd_full.bak'
WITH CHECKSUM;Kopia dziennika transakcji działa tylko wtedy, gdy baza pracuje w pełnym modelu odzyskiwania, co opisuje dokumentacja modeli odzyskiwania. Sama kontrola RESTORE VERIFYONLY potwierdza czytelność pliku, ale nie dowodzi, że odtworzenie się uda. Dowodem jest próbne odtworzenie na środowisku testowym, z pomiarem czasu. Nazwy bazy i ścieżek w przykładzie są ilustracyjne.
Reguła: kopia zapasowa istnieje dopiero wtedy, gdy odtworzenie zostało wykonane i zmierzone. Wynik próby należy porównać z RTO zapisanym w umowie SLA.
Zasada 3-2-1 i miejsce przechowywania kopii
Powszechnie stosowana reguła zaleca trzy kopie danych na dwóch różnych nośnikach, z których jedna leży poza główną lokalizacją. Kopia w tym samym centrum danych chroni przed błędem operatora, ale nie przed pożarem hali serwerowej. Umowa powinna więc wskazywać, gdzie fizycznie leżą kopie oraz jak długo są przechowywane.
Łącze internetowe i opóźnienia w pracy magazynu
Droga polecenia z terminala do serwera prowadzi przez sieć Wi-Fi hali i router, potem łącze operatora oraz sieć dostawcy. Każdy odcinek dodaje opóźnienie, a użytkownik widzi tylko sumę. Ekran magazyniera, który odświeża się po sekundzie zamiast po ułamku sekundy, zwykle nie świadczy o słabym serwerze, lecz o problemie z zasięgiem albo z łączem.
W pracy z aplikacją webową ważniejsza od przepustowości jest stabilność połączenia. Pojedyncza operacja przesyła niewielką ilość danych, więc łącze o skromnej prędkości wystarcza, jeśli nie gubi pakietów. Przed uruchomieniem systemu trzeba zmierzyć czas odpowiedzi z kilku punktów hali, także z miejsc oddalonych od punktów dostępowych.
Reguła: zasięg Wi-Fi mierzy się w miejscu pracy magazyniera, z terminalem w ręku, a nie przy szafie sieciowej. Zapasowe łącze od drugiego operatora jest tańsze niż godzina przestoju wydań.
Szyfrowanie transmisji i ślad audytowy
Transmisję między przeglądarką a serwerem aplikacyjnym zabezpiecza protokół TLS, a dostęp do konta może chronić uwierzytelnianie dwuskładnikowe. Dostawca odpowiada za zgodność przetwarzania danych osobowych z RODO, w tym za lokalizację centrów danych w Unii Europejskiej. Szersze omówienie tych zapisów znajduje się w artykule o bezpieczeństwie danych i RODO w programie magazynowym.
Panel administratora rejestruje historię logowań i operacji na danych, więc da się ustalić, kto i kiedy zmienił dokument albo kartotekę. Taki ślad audytowy trudno utrzymać w małej, samodzielnie prowadzonej serwerowni, gdzie brakuje zasobów na stałe przeglądanie logów.
Aktualizacje i utrzymanie po stronie dostawcy
Główna różnica względem instalacji lokalnej dotyczy aktualizacji. W wersji lokalnej trzeba ją zaplanować i przetestować, a następnie wdrożyć osobno na każdym serwerze klienta. W chmurze dostawca instaluje nową wersję centralnie dla wszystkich użytkowników danej instancji.
Aktualizacja obejmuje poprawki błędów i nowe funkcje aplikacji, a także łatki bezpieczeństwa systemu operacyjnego oraz bazy danych. Nie wymaga obecności administratora przy serwerze klienta, więc przestój ogranicza się zwykle do okna serwisowego poza godzinami pracy magazynu. Ustawienia modułów przedsiębiorstwo nadal dopasowuje w konfiguracji programu magazynowego, bez utraty wprowadzonych wcześniej parametrów.
Dostawcy prowadzą zwykle osobne środowisko testowe, na którym nowa wersja przechodzi kontrolę przed wdrożeniem produkcyjnym. Dla klienta oznacza to możliwość sprawdzenia własnych scenariuszy, na przykład wydruków i integracji, zanim zmiana trafi na hale. Przed każdym wdrożeniem powstaje kopia bazy, więc w razie błędu można wrócić do stanu sprzed aktualizacji. Zasady komunikowania okien serwisowych i wycofania zmian warto zapisać w umowie razem z parametrami SLA.
Skalowanie zasobów serwerowych
Skalowanie oznacza zwiększanie albo zmniejszanie mocy obliczeniowej i przestrzeni dyskowej oraz liczby jednoczesnych połączeń bez wymiany fizycznego sprzętu. W magazynie działającym lokalnie wzrost wydajności wymaga zakupu podzespołów i często przestoju. W chmurze zasoby przydziela się elastycznie, według bieżącego obciążenia.
W okresie wzmożonej sprzedaży liczba operacji na stanach magazynowych gwałtownie rośnie, więc dostawca może tymczasowo zwiększyć moc serwera aplikacyjnego, a po szczycie ją zredukować. Rozliczenie następuje zwykle według faktycznie zarezerwowanych zasobów. Ekonomię takiego rozwiązania opisuje artykuł o skalowalności programu magazynowego w chmurze, a ciągłość pracy przy awarii lokalnej infrastruktury - tekst o redundancji i failover.
Skalowanie pionowe i poziome
Zwiększenie mocy pojedynczej maszyny nazywa się skalowaniem pionowym: serwer dostaje więcej rdzeni i pamięci albo szybszy dysk. Skalowanie poziome polega na dodaniu kolejnych maszyn i rozłożeniu na nie ruchu. Warstwa aplikacyjna dobrze znosi ten drugi sposób, bo serwery aplikacyjne nie przechowują stanu między żądaniami. Baza danych skaluje się głównie pionowo, ponieważ wszystkie zapisy muszą trafić do jednego źródła prawdy.
Z tego powodu wąskim gardłem systemu magazynowego rzadko bywa liczba serwerów aplikacyjnych. Częściej ograniczeniem jest wydajność bazy i jakość zapytań, więc rozbudowa zasobów bez przeglądu indeksów daje ograniczony efekt. Ilość dokumentów przetwarzanych w godzinę szczytu to lepszy punkt odniesienia niż liczba zalogowanych osób.
Monitoring serwera i reagowanie na awarie
Dostawca monitoruje obciążenie procesora i pamięci oraz opóźnienia dysku. Bazy SQL Server wymagają dodatkowej obserwacji blokad, bo długa transakcja jednego użytkownika potrafi zatrzymać pracę pozostałych. Zapytanie do widoku systemowego pokazuje, które sesje czekają na zwolnienie zasobu i przez kogo są blokowane.
-- przykład: sesje czekające na zwolnienie blokady przez inną sesję
SELECT r.session_id,
r.blocking_session_id,
r.wait_type,
r.wait_time AS czas_oczekiwania_ms
FROM sys.dm_exec_requests AS r
WHERE r.blocking_session_id <> 0
ORDER BY r.wait_time DESC;Wynik jest punktem wyjścia do reakcji: administrator sprawdza, czy blokada wynika z długiej transakcji, i decyduje o jej zakończeniu. Alarmy o przekroczeniu progów uruchamia się zwykle jako zadania SQL Agent. Zestawienie pokazuje typowe sygnały i pierwszą reakcję.
| Sygnał | Możliwa przyczyna | Pierwsza reakcja |
|---|---|---|
| Wydłużony czas odpowiedzi ekranów | Blokada w bazie lub przeciążony procesor | Sprawdzenie sesji blokujących i obciążenia serwera |
| Brak połączenia z terminali | Awaria łącza operatora lub sieci hali | Przełączenie na łącze zapasowe |
| Niepowodzenie zadania kopii | Brak miejsca na dysku kopii | Zwolnienie miejsca i ponowne uruchomienie zadania |
Modele chmury i ich skutki dla firmy
Nie każda infrastruktura chmurowa wygląda tak samo. Model wpływa na koszt jednostkowy i poziom izolacji, a także na zakres kontroli klienta nad środowiskiem.
| Model | Współdzielenie zasobów | Skutek dla firmy |
|---|---|---|
| Publiczna | Fizyczne serwery wspólne dla wielu klientów dostawcy | Niższy koszt jednostkowy, mniejsza możliwość indywidualnego dopasowania |
| Prywatna | Zasoby przydzielone jednemu przedsiębiorstwu | Wyższa izolacja i kontrola, wyższy koszt utrzymania |
| Hybrydowa | Część danych w chmurze prywatnej lub lokalnie, reszta w publicznej | Kompromis wynikający z wymogów bezpieczeństwa |
Wybór zależy od wymogów bezpieczeństwa danych i przewidywanego obciążenia. Strukturę kosztów obu wariantów przedstawia strona o cenie programu WMS. Obejmuje ona licencję oraz opłaty za infrastrukturę. Firmy z rozbudowanymi wymogami, na przykład z branż regulowanych, częściej rozważają chmurę prywatną lub rozwiązanie hybrydowe.
Migracja infrastruktury magazynu do chmury
Przeniesienie systemu z serwera lokalnego do chmury przebiega w uporządkowanych etapach, niezależnie od dostawcy. Poniższa lista skupia się na tym, co dotyczy infrastruktury.
- Inwentaryzacja obecnego środowiska - spis serwerów i baz danych oraz integracji, które trzeba odtworzyć w nowym miejscu.
- Wybór modelu chmury - decyzja między chmurą publiczną, prywatną a rozwiązaniem hybrydowym, zależnie od wymogów bezpieczeństwa i budżetu.
- Migracja bazy danych - przeniesienie stanów oraz kartotek z historią dokumentów, zwykle w trybie skracającym przestój do minimum.
- Testy i przełączenie - pomiar czasu odpowiedzi pod obciążeniem, próbne odtworzenie kopii i dopiero potem wyłączenie serwera lokalnego.
Migracja trwa od kilku do kilkunastu tygodni, zależnie od wolumenu danych historycznych i liczby integracji. W okresie przejściowym dostawca utrzymuje zwykle równoległy dostęp do danych archiwalnych. Dla firm, które wolą aplikację zainstalowaną na stacji roboczej, alternatywą pozostaje wersja opisana w artykule o magazynie Framework. Przegląd rozwiązań SoftwareStudio dotyczących infrastruktury zawiera materiał System WMS w magazynie w serwisie SoftwareStudio.
