Wirtualizacja serwerów Szczecin

Skąd bierze się szafa pełna serwerów w firmie transportowej?

Z historii, nie z projektu. Najpierw był serwer do programu handlowego. Potem doszedł system spedycyjny i dostawca poprosił o osobną maszynę. Później skanowanie dokumentów, wydruk etykiet, telefonia, jeszcze później integracja z platformą kontrahenta. Za każdym razem najprościej było dołożyć kolejny komputer do szafy.

Po kilku latach w szafie stoi sześć albo osiem maszyn, z których jedna pracuje ciężko, a reszta zużywa kilkanaście procent tego, co ma. Firma płaci za sprzęt, prąd, chłodzenie i miejsce ośmiokrotnie, a odporność na awarię ma zerową, bo każdy system stoi na dokładnie jednym urządzeniu.

Konsolidacja odwraca ten rachunek. Osiem systemów przenosi się na dwa hosty, maszyna staje się plikiem, który da się skopiować i uruchomić gdzie indziej, a serwis sprzętu przestaje wymagać wyłączania czegokolwiek, bo działające maszyny przechodzą wtedy na sąsiedni węzeł.

Co się dzieje przy awarii hosta, zależnie od tego, co stoi w szafie?

Poniżej trzy warianty, które spotykamy najczęściej, i różnica między nimi w chwili, gdy sprzęt przestaje odpowiadać o drugiej w nocy.

Stan środowiska	Co dzieje się przy awarii	Kiedy firma pracuje dalej
Serwery fizyczne, po jednym na system	stoi ten jeden system, reszta działa	po naprawie sprzętu albo odtworzeniu z kopii
Jeden host, wszystkie maszyny na nim	stoi wszystko naraz	po odtworzeniu na sprzęcie zastępczym
Dwa hosty z zapasem	maszyny startują na drugim węźle	w kilka minut, bez udziału człowieka
Dwa hosty i replika poza szafą	działa nawet przy utracie całej lokalizacji	po przełączeniu, w ustalonym czasie

Drugi wiersz jest częstszy, niż powinien. Wirtualizacja postawiona na jednym hoście porządkuje środowisko, ale nie daje odporności, a bywa sprzedawana tak, jakby dawała. Drugi węzeł zmienia rachunek ryzyka, pierwszy zmienia tylko sposób zarządzania.

Gdzie w tej branży postawić drugą kopię środowiska?

Firmy transportowe i magazynowe mają jedną przewagę nad biurem w jednym budynku: prawie zawsze dysponują drugim adresem. Magazyn, biuro na placu, punkt przy terminalu. To wystarczy, żeby postawić tam replikę maszyn krytycznych, o ile jest łącze i miejsce w szafie.

Replika nie jest tym samym co kopia zapasowa i nie zastępuje jej. Kopia służy do odtworzenia danych sprzed dowolnego dnia, replika do uruchomienia systemu w innym miejscu bez czekania na odtwarzanie. Środowisko odporne ma jedno i drugie, a firma, która ma tylko replikę, nie odzyska pliku skasowanego w zeszłym tygodniu, bo skasował się też po drugiej stronie.

Czego nie warto wirtualizować i dlaczego mówimy to na starcie?

Maszyn, których producent nie wspiera w środowisku wirtualnym i od których wsparcia realnie potrzebujecie. Systemów przywiązanych do sprzętu, na przykład do klucza licencyjnego albo do karty wpiętej w konkretny serwer, choć część z nich da się przenieść po uzgodnieniu z dostawcą. Pojedynczego serwera, który pracuje spokojnie i ma sprawdzoną kopię: sam hypervisor niczego tam nie poprawi, a doda warstwę do utrzymania.

Mówimy o tym przed kosztorysem, także wtedy, gdy oznacza to mniejszy projekt. Środowisko zbudowane wbrew wymaganiom producenta oprogramowania wraca do nas przy pierwszym zgłoszeniu, które ten producent odrzuci.

Skąd znamy czas powrotu po awarii?

Z pomiaru, nie z dokumentacji. Raz w miesiącu odtwarzamy losową maszynę do środowiska testowego i zapisujemy, ile to zajęło. Ta jedna liczba jest jedyną uczciwą odpowiedzią na pytanie, ile potrwa powrót, i to ją podajemy zamiast deklaracji o wysokiej dostępności.

Przy replice mierzymy osobno czas przełączenia, bo to inna operacja i inne minuty. Obie liczby trafiają do raportu miesięcznego i obie zmieniają się wraz z rozrostem środowiska, więc mierzymy je stale, a nie raz przy odbiorze.

Wybór platformy opisaliśmy przy porównaniu Proxmoksa i VMware, przebieg zmiany platformy przy migracji z VMware na Proxmox, a systemy stojące na maszynach prowadzimy w ramach administracji serwerami.

Treść sprawdzona i zaktualizowana: 31 lipca 2026