- Need Help? Request A Callback
- Working Hours: 8:00 AM – 7:45 PM
Konfiguracja sieciowa programu księgowo-magazynowego dla kilku stanowisk wymaga przemyślanej architektury sieci lokalnej, wyboru odpowiedniego komputera pełniącego rolę serwera oraz zabezpieczenia transmisji danych. Poniżej opisujemy, jak podchodzimy do takich wdrożeń.
Program księgowo-magazynowy pracujący na kilku komputerach korzysta ze wspólnej bazy danych. Oznacza to, że wszystkie stanowiska muszą mieć stabilny dostęp do komputera, na którym znajduje się baza oraz usługi odpowiedzialne za jej obsługę. Sama instalacja programu na poszczególnych komputerach nie wystarczy. Konieczne jest prawidłowe zaplanowanie adresacji sieciowej, uprawnień, zapory systemowej, kopii zapasowych i sposobu obsługi sytuacji awaryjnych.
Podstawą pracy wielostanowiskowej jest wyznaczenie komputera lub serwera, na którym zainstalowana będzie baza danych — może to być dedykowany serwer, komputer pełniący dodatkowo tę rolę, lub w mniejszych firmach jedna z bardziej wydajnych stacji roboczych. Niezależnie od wyboru, konfigurujemy dla niego stały adres IP, co zapobiega problemom z łącznością po restarcie routera przydzielającego adresy dynamicznie.
Komputer pełniący funkcję serwera powinien być dostępny dla pozostałych stanowisk w czasie pracy firmy. Warto więc zwrócić uwagę nie tylko na procesor i ilość pamięci RAM, ale również na stan dysku, chłodzenie, zasilanie oraz sposób przechowywania danych. Uszkodzony dysk lub przypadkowe wyłączenie serwera może przerwać pracę wszystkich użytkowników, dlatego konfiguracja musi uwzględniać również niezawodność sprzętu.
W małej firmie funkcję serwera może pełnić jeden z używanych komputerów, jednak nie każda stacja robocza będzie się do tego nadawała. Nie zalecamy wykorzystywania komputera, który jest regularnie wyłączany, przenoszony albo obciążany wymagającymi zadaniami niezwiązanymi z programem księgowo-magazynowym. Serwer powinien mieć stabilne połączenie sieciowe i znajdować się w miejscu, w którym nie będzie narażony na przypadkowe odłączenie przewodów.
Przed rozpoczęciem konfiguracji sprawdzamy, czy system operacyjny, sterowniki karty sieciowej oraz silnik bazy danych są zgodne z wymaganiami używanego programu. Weryfikujemy także wolne miejsce na dysku oraz ustawienia automatycznych aktualizacji. Aktualizacje są ważne dla bezpieczeństwa, ale ich niekontrolowane instalowanie i restarty w godzinach pracy mogą zakłócić dostęp do bazy.
Serwer powinien mieć stały adres IP w sieci lokalnej. Można ustawić go bezpośrednio w systemie albo skonfigurować rezerwację adresu w routerze. Istotne jest, aby wybrane rozwiązanie było opisane i spójne z konfiguracją pozostałych komputerów. Jeśli adres serwera zmieni się po restarcie routera, stanowiska mogą stracić połączenie z bazą, mimo że sam program i sieć będą działały poprawnie.
W praktyce przydatna jest również jednoznaczna nazwa komputera. Ułatwia ona identyfikację urządzenia w dokumentacji i podczas późniejszej diagnostyki. Nie powinna jednak zastępować prawidłowej konfiguracji adresu IP, jeśli program lub silnik bazy danych korzysta z konkretnego adresu albo określonej instancji serwera.
Dla stabilnej pracy programów księgowych z bazą SQL zalecamy sieć przewodową (Ethernet) zamiast Wi-Fi, szczególnie dla komputera pełniącego rolę serwera — połączenie bezprzewodowe wprowadza opóźnienia i niestabilność, które przy pracy na bazie danych objawiają się zawieszeniami programu i błędami zapisu. Dobieramy przełączniki sieciowe o odpowiedniej przepustowości (minimum 1 Gb/s) proporcjonalnie do liczby stanowisk.
Przewód sieciowy prowadzony do serwera powinien być podłączony bezpośrednio do przełącznika, a nie do przypadkowego wzmacniacza sygnału lub dodatkowego urządzenia o nieznanych parametrach. Sprawdzamy również stan gniazd, wtyczek i patch paneli, ponieważ uszkodzenie pojedynczego przewodu może powodować krótkotrwałe rozłączenia trudne do zauważenia podczas zwykłego korzystania z internetu.
Wi-Fi może być wystarczające dla urządzeń służących do przeglądania dokumentów lub komunikacji, ale przy bazie danych liczy się powtarzalność połączenia. Jeżeli stanowisko musi korzystać z sieci bezprzewodowej, analizujemy zasięg, zakłócenia oraz obciążenie punktu dostępowego. W miarę możliwości komputer serwerowy i stanowiska intensywnie korzystające z programu pozostawiamy w sieci przewodowej.
Przed instalacją programu sprawdzamy, jak działa lokalna sieć firmy. Ustalamy zakres adresów przydzielanych automatycznie przez router, adres serwera, adresy urządzeń sieciowych oraz sposób rozwiązywania nazw. Dzięki temu można uniknąć konfliktu, w którym dwa urządzenia otrzymają ten sam adres IP albo serwer znajdzie się poza zakresem używanym przez pozostałe stanowiska.
Ważne jest także odseparowanie sieci firmowej od sieci dla gości, jeżeli router lub punkty dostępowe obsługują taką funkcję. Komputery pracowników powinny widzieć serwer bazy danych, natomiast urządzenia przypadkowych użytkowników nie powinny mieć dostępu do zasobów firmy. Zmiana ustawień sieciowych wymaga ostrożności, ponieważ błędna izolacja może zablokować komunikację między programem a bazą.
Konfigurujemy zaporę systemu Windows na serwerze tak, by zezwalała na ruch przychodzący na portach wymaganych przez silnik bazy danych (dla SQL Server: port 1433 TCP oraz 1434 UDP dla SQL Browser), jednocześnie ograniczając dostęp wyłącznie do adresów z sieci lokalnej firmy dla zachowania bezpieczeństwa.
Nie otwieramy większej liczby portów niż jest to konieczne. Najpierw ustalamy, z jakiego silnika bazy danych korzysta program, czy używana jest instancja domyślna, czy nazwana, oraz czy aplikacja wymaga dodatkowych usług. Następnie tworzymy reguły zapory obejmujące wyłącznie odpowiedni profil sieci i właściwy zakres adresów.
Po zapisaniu ustawień sprawdzamy połączenie z każdego stanowiska. Sam fakt, że komputer odpowiada na polecenie ping, nie oznacza jeszcze, że działa komunikacja z bazą SQL. Testujemy więc dostęp do konkretnej usługi, logowanie użytkownika oraz wykonanie podstawowej operacji w programie. Pozwala to odróżnić problem z siecią od problemu z konfiguracją aplikacji.
Na komputerach użytkowników instalujemy odpowiedni komponent programu i wskazujemy lokalizację bazy danych znajdującą się na serwerze. Wszystkie stanowiska powinny korzystać z tej samej wersji aplikacji oraz zgodnego komponentu dostępowego. Różnice wersji mogą powodować błędy przy logowaniu, problemy z otwieraniem dokumentów albo niezgodność struktury bazy.
Konfigurację wykonujemy według jednego, ustalonego schematu. Sprawdzamy nazwę serwera, adres IP, nazwę instancji, sposób uwierzytelniania oraz uprawnienia użytkownika. Jeżeli program zapisuje dodatkowe pliki konfiguracyjne na komputerze lokalnym, uwzględniamy je w dokumentacji, aby późniejsza wymiana komputera nie wymagała odtwarzania ustawień metodą prób i błędów.
Uprawnienia do programu i bazy danych powinny odpowiadać zakresowi obowiązków pracowników. Nie każdy użytkownik musi mieć możliwość zmiany konfiguracji, usuwania dokumentów czy wykonywania operacji administracyjnych. Ograniczenie uprawnień zmniejsza ryzyko przypadkowej modyfikacji danych i ułatwia ustalenie, z którego stanowiska wykonano daną operację.
Nie zalecamy korzystania ze wspólnego konta administracyjnego przez wszystkie osoby. Oddzielne konta pozwalają lepiej kontrolować dostęp oraz szybciej zareagować w przypadku odejścia pracownika, zmiany zakresu obowiązków lub podejrzenia nieuprawnionego użycia programu.
Konfiguracja sieci nie zabezpiecza danych przed awarią dysku, błędnym usunięciem dokumentów, uszkodzeniem bazy lub działaniem złośliwego oprogramowania. Dlatego już na etapie wdrożenia ustalamy sposób wykonywania kopii zapasowych. Kopia powinna obejmować bazę danych oraz inne istotne pliki wymagane do odtworzenia pracy programu.
Nie wystarczy zapisanie kopii na tym samym dysku, na którym znajduje się baza. Awaria tego nośnika może wtedy zniszczyć zarówno dane robocze, jak i kopię. Sprawdzamy również, czy kopie są faktycznie wykonywane i czy można je odczytać. Okresowy test odtworzenia jest ważniejszy niż sama obecność plików w katalogu kopii.
Procedura powinna określać, kto odpowiada za kontrolę kopii, gdzie są przechowywane oraz jak postępować po awarii serwera. Dokumentujemy także kolejność czynności: zabezpieczenie aktualnych plików, przygotowanie systemu, instalację wymaganych usług, odtworzenie bazy i test logowania ze stanowisk.
Jeśli firma ma oddziały w innych lokalizacjach lub pracowników pracujących zdalnie, konfigurujemy bezpieczny dostęp poprzez VPN lub serwer terminali (RDS), zamiast bezpośredniego udostępniania portu bazy danych do internetu, co byłoby poważnym zagrożeniem bezpieczeństwa. Takie rozwiązanie pozwala na pracę zdalną z zachowaniem pełnego bezpieczeństwa danych firmowych.
Przy połączeniu między lokalizacjami analizujemy jakość łączy, opóźnienia i sposób uwierzytelniania. Baza danych wymaga stabilnej komunikacji, dlatego samo szybkie łącze internetowe nie gwarantuje prawidłowej pracy programu. W niektórych przypadkach lepszym rozwiązaniem jest uruchomienie aplikacji na serwerze i udostępnienie użytkownikom sesji terminalowej, zamiast przesyłania dużej liczby operacji bezpośrednio przez internet.
Dostęp zdalny powinien być ograniczony do określonych użytkowników i urządzeń. Stosujemy silne hasła, dodatkowe zabezpieczenia dostępne w używanym rozwiązaniu oraz rejestrujemy podstawowe informacje o połączeniach. Po zakończeniu pracy użytkownik powinien wylogować się z sesji, a nie tylko zamknąć okno programu.
Po skonfigurowaniu sieci przeprowadzamy testy obciążeniowe — jednoczesną pracę wszystkich stanowisk na programie — oraz sporządzamy dokumentację konfiguracji sieciowej, co znacząco ułatwia przyszłą rozbudowę firmy o kolejne stanowiska lub lokalizacje.
W trakcie testów sprawdzamy logowanie kilku użytkowników, otwieranie kartotek, wystawianie dokumentów, zapis zmian, wydruki oraz operacje wykonywane równocześnie przez różne stanowiska. Obserwujemy, czy program reaguje prawidłowo i czy nie pojawiają się komunikaty o utracie połączenia. Testujemy także ponowne uruchomienie aplikacji po chwilowym rozłączeniu sieci.
Dokumentacja nie powinna zawierać haseł zapisanych w zwykłym pliku. Informacje dostępowe przechowujemy w sposób ograniczający możliwość ich przypadkowego ujawnienia. W dokumencie można natomiast wskazać, kto jest uprawniony do zarządzania kontami i gdzie znajduje się bezpieczna procedura ich zmiany.
Jednym z częstych problemów jest działanie programu tylko na serwerze, przy jednoczesnym braku połączenia ze stanowisk roboczych. Zwykle przyczyną jest blokada zapory, błędna nazwa instancji, nieprawidłowy adres serwera albo wyłączona usługa bazy danych. Innym przypadkiem jest okresowe rozłączanie, które może wynikać z uszkodzonego przewodu, niestabilnego Wi-Fi, wadliwego przełącznika lub usypiania karty sieciowej.
Jeśli problem pojawia się wyłącznie przy większej liczbie użytkowników, sprawdzamy wydajność serwera, obciążenie dysku, ilość dostępnej pamięci oraz jakość połączeń. Nie należy od razu zmieniać przypadkowych ustawień w programie. Najpierw trzeba ustalić, czy opóźnienie występuje podczas komunikacji z bazą, zapisu plików, generowania wydruków czy wykonywania konkretnej operacji.
Prawidłowo przygotowana sieć lokalna powinna być nie tylko działająca w dniu instalacji, ale również możliwa do utrzymania i rozbudowy. Jasny podział ról między serwerem, urządzeniami sieciowymi i stanowiskami użytkowników ułatwia diagnozowanie problemów. Dzięki temu awaria pojedynczego komputera nie musi oznaczać utraty dostępu do bazy przez całą firmę, a dodanie kolejnego stanowiska może odbyć się według wcześniej sprawdzonej procedury.
Zgłoszenie naprawy: 22 390 56 49 — telefon czynny całą dobę, siedem dni w tygodniu. Sprzęt odbieramy spod wskazanego adresu w Grodzisku Mazowieckim i okolicy.