Plus minus
Strona domowa Ireny i Zbigniewa Kuleszów
Serdecznie witamy na domowych, prywatnych serwerach
Dzisiaj jest: 2026-06-25  Aktualizacja strony dnia: [an error occurred while processing this directive]
Jezyki
Rocznica 24 lat pracy serwerów i strony zjk.pl :-) (od 2002)
24 lat nieprzerwanej pracy z systemem FreeBSD / 24 years of continuous work with FreeBSD system
UWAGA! Ten serwis, strona i podstrony mogą używać cookies i podobnych technologii (brak zmiany ustawienia przeglądarki oznacza zgodę na to)!
Powitanie Autor Irena Zbigniew Elektronika Studenci Serwer Prawo_jazdy Kolejka Pobierz Linki Palmtop Kontakt Info O Tobie Mail
FreeBSD i mikroserwery. Rocznica 18 lat pracy serwerów i strony zjk.pl :-) Nieprzerwanie od 2002 roku.
Info ogólne Infrastruktura Kogo goœcimy? Usługi Sprzęt Technologie FreeBSD Oprogramowanie Aktualizacje Historia Pobierz Linki Kontakt CMS Blog Dla_Róży Mail Zbyszek
Zdjęcia 1 Zdjęcia noc 1 Zasilanie HA-OPNsense PCI riser i9 9900T Chłodzenie Zrobię samemu 32do64 FAQ Aktualizacje 32do64 Zrobię samemu Pobierz Linki Kontakt CMS Blog Dla_Róży
Przypadki Testy odpornoœci Manifest Opinie AI Logi Poczta Mail Zbyszek



**
****
**

zjk.pl – 24 lata inżynierii i technologii - ewolucja prywatnego ekosystemu FreeBSD





I. Wstęp: 24 lata cyfrowej suwerenności.

Fakty:
    Prywatna infrastruktura serwerowa zjk.pl działa nieprzerwanie od 2002 roku i od początku oparta jest o system operacyjny FreeBSD.
Komentarz:
    Wszystko zaczęło się na przełomie wieków od prostej idei i świadomej decyzji o wyborze FreeBSD jako fundamentu pod własny, niezależny serwer. Misją projektu od ponad dwóch dekad pozostaje dostarczanie usług pro bono dla lokalnej społeczności oraz utrzymanie przestrzeni internetowej wolnej od reklam, skryptów śledzących i korporacyjnego nadzoru.
    To nie jest kolejny tymczasowy projekt zbudowany na podstawie gotowego tutoriala, lecz autorskie środowisko rozwijane konsekwentnie przez ćwierć wieku. Przez ten czas infrastruktura ewoluowała od pojedynczych usług do rozproszonego ekosystemu serwerów fizycznych, wirtualnych i storage działających w trybie 24/7/365.
    Ćwierć wieku stabilnej pracy pokazuje, że własna infrastruktura nadal może skutecznie konkurować z rozwiązaniami chmurowymi, zachowując pełną autonomię technologiczną i kontrolę nad danymi.

•    Punkt startowy: Rok 2002 i decyzja o wyborze FreeBSD.
Fakty:
    Oficjalny start infrastruktury z dostępem do Internetu nastąpił w 2002 roku. Podstawowym systemem operacyjnym od początku projektu pozostaje FreeBSD.
Komentarz:
    „25 lat” to liczba mocno przybliżona. Moje pierwsze prace z FreeBSD rozpoczęły się już około 1998/1999 roku. Największą przeszkodą nie był wtedy sprzęt ani system operacyjny, lecz brak powszechnie dostępnego Internetu. Jedyną realną opcją pozostawał ISDN, który wydawał się zbyt ograniczony dla planowanej infrastruktury.
    Mimo wielu prób i pytań u dostawców, dostęp do Internetu w moim budynku pojawił się dopiero w 2002 roku — i tę datę przyjąłem jako oficjalny start serwerów. W praktyce pierwsze maszyny działały już wcześniej, około 2000/2001 roku.
    Warto podkreślić, że wybór FreeBSD od początku był świadomą decyzją, a nie wynikiem przypadkowych testów. Wiedziałem, czego oczekuję od systemu: stabilności, przewidywalności i profesjonalnego podejścia do administracji. Miało być wymagająco — i tak pozostało do dziś.

•    Misja: Internet bez reklam, trackerów i pro bono dla społeczności.
Fakty:
    Serwery zjk.pl nie publikują reklam ani zewnętrznych mechanizmów śledzących użytkowników. Infrastruktura wykorzystywana jest również do działalności pro publico bono oraz wsparcia inicjatyw edukacyjnych i społecznych.
Komentarz:
    Serwery zjk.pl od początku były projektem rozwijanym bardziej z potrzeby tworzenia niezależnej infrastruktury niż z powodów komercyjnych. Usługi działały i nadal działają głównie na potrzeby edukacyjne, społeczne oraz prywatne.
    W czasach powstawania projektu wiele instytucji — w tym również uczelnie — nie oferowało jeszcze pracownikom własnych usług pocztowych czy przestrzeni do publikacji materiałów dla studentów. Warto dodać, że pracodawca właściciela — Politechnika Łódzka — przez wiele lat nie oferował pracownikom ani usług pocztowych, ani żadnego miejsca do publikacji materiałów dla studentów (jeszcze około 2010 roku uruchomiono jedynie pocztę PŁ). W praktyce oznaczało to konieczność budowania takich rozwiązań samodzielnie.
    Jedną z podstawowych zasad projektu pozostaje brak reklam oraz agresywnych mechanizmów śledzących użytkowników. Statystyki ruchu i monitoring usług prowadzone są wyłącznie na potrzeby administracyjne oraz utrzymania bezpieczeństwa infrastruktury. Całość utrzymywana jest prywatnie i finansowana wyłącznie przez właściciela infrastruktury — Zbigniewa Kuleszę.

•    Przekaz: To nie jest gotowiec z tutoriala – to autorski projekt rozwijany konsekwentnie przez ćwierć wieku.
Fakty:
    Projekt zjk.pl jest autorską infrastrukturą rozwijaną systematycznie od ponad 25 lat.
Komentarz:
    Jeszcze przed uruchomieniem serwerowni założeniem było jej praktyczne wykorzystanie. W czasach, gdy projekt powstawał, złożone systemy CMS dopiero zaczynały się pojawiać, a o współczesnych usługach chmurowych nikt jeszcze nie myślał. Sam Internet — mimo bardzo dynamicznego rozwoju — dopiero budował model swojej powszechnej użyteczności.
    Wiele rozwiązań trzeba było projektować samodzielnie. W początkowym okresie wykorzystywałem dziś już niemal zapomniane mechanizmy, takie jak FTP, a wiele usług przechodziło wieloletnią ewolucję. Dzisiejszy system pocztowy oparty o sendmail, miltery, MailScanner, rspamd, SpamAssassin, SPF, DKIM i DMARC niewiele przypomina prostą konfigurację pocztową z początku lat 2000.
    Przez lata kluczowe okazało się nie tyle wybieranie technologii „najmodniejszych” czy „najpopularniejszych”, ale takich, które można było realnie utrzymać i rozwijać w długim horyzoncie czasu. W praktyce oznaczało to ciągłe podejmowanie decyzji — od wyboru sprzętu i sposobu zasilania, aż po architekturę usług i konfigurację oprogramowania.
    Warunki serwowania rzeczywistych usług to jedyny moment, w którym można naprawdę sprawdzić, czy system jest poprawnie skonfigurowany i odporny na zagrożenia zewnętrzne. Żadne środowisko testowe nie jest w stanie tego w pełni zastąpić.

II. Sprzęt: Inżynieria fizyczna i trudne decyzje

Fakty: 
    Infrastruktura serwerowa oparta jest o energooszczędne platformy Mini‑ITX wyposażone w podwójne interfejsy Ethernet pracujące w agregacji LACP.
    Serwery wykorzystują procesory Intel Core serii T o obniżonym TDP oraz — w przypadku serwerów plików — wieloportowe kontrolery dyskowe obsługujące rozbudowany storage.
Komentarz: 
    Budowa domowego klastra w Sieradzu wymagała odejścia od klasycznych rozwiązań serwerowych na rzecz autorskiej architektury opartej o osiem energooszczędnych platform Mini‑ITX. Świadomy wybór procesorów Intel Core serii T pozwolił uzyskać bardzo dobry kompromis pomiędzy wydajnością obliczeniową a poborem energii, co w warunkach domowych ma kluczowe znaczenie dla pracy ciągłej 24/7. Wybór procesorów Intel Core z serii T pozwolił na uzyskanie bezkompromisowej wydajności obliczeniowej przy zachowaniu niskiego współczynnika TDP na poziomie 35 W
    Każdy węzeł wyposażony został w podwójne interfejsy 1 Gb Ethernet pracujące w agregacji LACP. Rozwiązanie to zwiększa odporność infrastruktury na awarie okablowania oraz poprawia przepustowość komunikacji pomiędzy serwerami i storage.
    Dużym wyzwaniem okazało się fizyczne rozmieszczenie tak gęstego środowiska obliczeniowego w prywatnej przestrzeni mieszkalnej. Wymusiło to zaprojektowanie układu maszyn w półce serwerowej, odpowiedniego prowadzenia okablowania oraz systemu odprowadzania ciepła.

•    Wybór platformy: Dlaczego 8x Mini-ITX.
Fakty: 
    Platforma Mini‑ITX stanowi podstawę sprzętową infrastruktury zjk.pl. Format ten zapewnia funkcjonalność porównywalną z klasycznymi płytami ATX przy znacznie mniejszych wymiarach fizycznych.
Komentarz: 
    Miniaturowe komputery kojarzą się dziś głównie z ostatnią dekadą rozwoju rynku IT, jednak zainteresowanie miniaturyzacją towarzyszyło mi znacznie wcześniej — m.in. pracy związanej z elektroniką i mikroelektroniką.
    W latach 1990–2000 najmniejsze dostępne komputery miały najczęściej charakter przemysłowy i były bardzo kosztowne. Istniały również konstrukcje jeszcze mniejsze, wielkości kart rozszerzeń czy kart kredytowych, jednak ich funkcjonalność była mocno ograniczona. Zależało mi natomiast na zachowaniu możliwie pełnej zgodności z klasyczną architekturą PC.
    Po kilku latach doświadczeń (stosowałem miniaturowe komputery przemysłowe) wybór padł na platformę Mini‑ITX. Płyty tego typu oferują praktycznie pełną funkcjonalność większych konstrukcji ATX, obsługują standardowe procesory i typowe komponenty PC, a ich głównym ograniczeniem pozostaje zwykle pojedyncze złącze PCI‑E oraz mniejsza liczba slotów pamięci.
    Dodatkową zaletą okazała się szeroka dostępność niewielkich obudów. W infrastrukturze zjk.pl wykorzystywane są m.in. obudowy przeznaczone pierwotnie do komputerów multimedialnych i samochodowych. Dzięki temu w przestrzeni zajmowanej przez jedną klasyczną obudowę ATX można zmieścić nawet kilka niezależnych komputerów. Jeśli spojrzysz na zdjęcia serwerowni, zauważysz, że w miejscu jednej obudowy ATX mieszczę pięć komputerów, a w miejscu obudowy „leżącej” ATX — cztery (lub nawet 6, jeśli zrezygnuję z obudów wielodyskowych).

•    Specyfikacja z wyczuciem: Płyty z dual 1 Gb (pod LACP), wieloportowe karty dyskowe.
Fakty:
    Serwery wykorzystują płyty Mini-ITX wyposażone w podwójne interfejsy Ethernet pracujące w agregacji LACP oraz wieloportowe kontrolery dyskowe dla rozbudowanego storage.
Komentarz:
    Mimo zalet płyt Mini-ITX jednym z ich najważniejszych ograniczeń pozostaje niewielka liczba złączy PCI-E. Jeśli chcemy uzyskać sensowną przepustowość sieciową, szybko zaczyna brakować pasma. Dlatego zdecydowałem się na płyty wyposażone w podwójne interfejsy Ethernet, które następnie pracują w agregacji LACP.
    Tutaj ważna uwaga — LACP wymaga wsparcia zarówno po stronie systemu operacyjnego (na FreeBSD jest to LAGG), jak i switcha zarządzalnego. Istnieje również możliwość agregacji statycznej, jednak w przypadku awarii okablowania trudniej znaleźć miejsce uszkodzenia.
    Jeśli jednak nabrałeś ochoty na LAGG, warto wcześniej dobrze zrozumieć zasadę działania tego mechanizmu. Agregacja najlepiej działa wtedy, gdy jednocześnie przesyłanych jest wiele strumieni danych lub aplikacja wykorzystuje wiele wątków.
    Drugim problemem okazała się obsługa dużej liczby dysków. Serwery storage wykorzystują obudowy mieszczące do ośmiu dysków jednocześnie (pomijając systemowe), co wymaga dużej liczby portów SATA. Same płyty Mini-ITX często oferują 4–6 portów, ale przy bardziej rozbudowanych konfiguracjach zaczyna to być niewystarczające — nawet dla klasycznych płyt ATX.
    Dlatego stosuję dodatkowe wieloportowe kontrolery dyskowe. Obecnie używam zarówno kart 4-portowych, jak i większych modeli 10-portowych.

• Szafa serwerowa: Logistyka upchnięcia klastra w domowych warunkach w Sieradzu.
Fakty:
    Infrastruktura została zoptymalizowana pod kątem niewielkich rozmiarów, niskiego poboru energii oraz pracy w warunkach mieszkalnych.
Komentarz:
    Tak naprawdę nie mam żadnej klasycznej szafy serwerowej. Dzięki optymalizacji wielkości i ograniczeniu ilości wydzielanego ciepła cała serwerownia mieści się w zwykłym stoliku komputerowym. Oczywiście robi się ciasno, ale większym problemem od samych komputerów okazuje się bogate okablowanie. Paradoksalnie niewielkie rozmiary infrastruktury bardzo ułatwiają chłodzenie — dostęp powietrza z każdej strony sprawdza się lepiej niż wiele „profesjonalnych” konstrukcji. O chłodzeniu piszę szerzej w oddzielnym rozdziale strony.
    Pewnie dla niektórych większym problemem byłby hałas, ale tutaj pojawia się kolejne zaskoczenie. Serwerownię oczywiście słychać, jednak z drugiego pokoju… ledwie ledwie. Nie pracują tutaj przecież klasyczne serwery pobierające po 300–500 W mocy, lecz energooszczędne platformy oparte o procesory Intel serii T. Łączny pobór mocy samych serwerów wynosi około 200–250 W przy ok. 30 fizycznych rdzeniach — czyli mniej więcej tyle, ile potrafi pobierać pojedynczy mocniejszy komputer biurkowy.
    W każdym razie nawet żona nigdy nie protestowała :)
    Jedynym większym problemem pozostaje upalne lato — temperatura w pokoju potrafi wtedy przekraczać 30–35°C. Zimą sytuacja wygląda jednak odwrotnie: kaloryfer praktycznie nie musi już pracować.

II. Energetyka: Unikalny system 12 V DC

Fakty:
    Infrastruktura zjk.pl wykorzystuje rozbudowany system dystrybucji zasilania 12 V DC, redundantne linie energetyczne dla elementów krytycznych oraz wielogodzinne podtrzymanie akumulatorowe.
Komentarz:
    Architektura zasilania serwerowni została w dużym stopniu oparta o dystrybucję napięcia 12 V DC zamiast klasycznego rozprowadzania zasilania AC wewnątrz infrastruktury. Pozwala to ograniczyć część strat energetycznych wynikających z wielokrotnej konwersji napięcia, typowej dla klasycznych układów UPS + zasilacze komputerowe.
    W infrastrukturze zastosowano redundantne linie zasilania dla elementów krytycznych, takich jak routery OPNsense czy przełączniki sieciowe. System współpracuje również z rozbudowanym buforem akumulatorowym, umożliwiającym wielogodzinną pracę serwerowni podczas awarii zasilania zewnętrznego.
    Projekt zasilania nadal jest rozwijany i testowany — szczególnie w kierunku dalszego zwiększania udziału bezpośredniego zasilania DC.

• Filozofia: Rezygnacja z AC na rzecz czystego DC.
Fakty:
    Infrastruktura zasilania zjk.pl została oparta głównie o dystrybucję napięcia 12 V DC z wykorzystaniem zasilaczy PicoPSU oraz wspólnych linii zasilających wiele komputerów.
Komentarz:
    Hasło brzmi dobrze, ale jeszcze nie zostało w pełni zrealizowane. Zacznijmy jednak od początku, czyli od problemu zasilania płyt Mini-ITX w samochodowych obudowach komputerowych. Takie obudowy zwykle nie mają miejsca na klasyczny zasilacz ATX 230 V — korzystają przecież z instalacji 12/24 V dostępnej w samochodzie :)
    No dobrze, ale skąd pozostałe napięcia wymagane przez komputer, czyli np. 5 V czy 3,3 V? W takich konstrukcjach stosuje się np. zasilacze PicoPSU. Warto poszukać ich zdjęć na stronie — są naprawdę miniaturowe. Cała elektronika zasilacza mieści się praktycznie w obudowie wielkości gniazda ATX oraz niewielkiej płytce przetwornic.
    W naturalny sposób zacząłem więc budować infrastrukturę opartą głównie o linie 12 V zamiast rozprowadzania linii 230 V. Co ciekawe, początki tego pomysłu sięgają jeszcze czasów moich wcześniejszych komputerów przemysłowych („ciasteczkowych”). Już wtedy próbowałem ograniczać liczbę różnych napięć i zastępować kilkanaście małych zasilaczy wspólnymi liniami 5 V i 12 V.
    Można więc powiedzieć, że obecna architektura zasilania została wypracowana stopniowo przez wiele lat, a platformy Mini-ITX tylko naturalnie przejęły tę filozofię. Dziś pojedyncze zasilacze 12 V obsługują wiele komputerów jednocześnie. Największą zaletą takiego rozwiązania pozostaje sprawność — jeden większy zasilacz zwykle pracuje znacznie efektywniej niż wiele małych zasilaczy wtyczkowych.
    Ale dlaczego nadal nie jest to „czyste” 12 V zasilane bezpośrednio z akumulatorów? Problemem pozostają UPS-y oraz same zasilacze PicoPSU. Obecne UPS-y (których akumulatory można by wykorzystać) wymagają napięć 24 V lub 48 V, a współczesne PicoPSU coraz częściej pracują poprawnie dopiero od okolic 12 V wejściowych. Dawniej można było znaleźć modele działające już od 8–9 V.
    Teoretycznie producenci deklarują poprawną pracę PicoPSU nawet podczas rozruchu samochodu, jednak serwer wymaga znacznie większej stabilności niż komputer samochodowy. W praktyce moje testy z mocniejszym komputerem osobistym (procesor ok. 120 W) pokazały, że przy spadku napięcia poniżej około 11,5 V mogą pojawić się resety systemu. Tymczasem napięcie rozładowującego się akumulatora 12 V potrafi spaść nawet do okolic 10 V.
    Prace nadal trwają. W międzyczasie zaprojektowałem już własny dystrybutor 12 V z pomiarem napięć, prądów i mocy oraz indywidualnym załączaniem linii zasilających poszczególne komputery — pierwsze płytki są już gotowe do testów. Być może konieczne będą dalsze eksperymenty z różnymi modelami PicoPSU, a może ostatecznie powstanie własna przetwornica stabilizująca napięcie 12 V.

• Redundancja zasilania: Niezależne linie dla OPNsense i switchy.
Fakty:
    Elementy krytyczne infrastruktury, takie jak routery OPNsense i przełączniki sieciowe, posiadają redundantne linie zasilania oparte o podwójny system UPS oraz niezależne zasilacze 12 V.
Komentarz:
    Niezależnie od samej dystrybucji 12 V problemem pozostaje dostęp do zasilania 230 V. W budynku nie ma możliwości poprowadzenia całkowicie separowanych linii energetycznych, dlatego musiałem oprzeć się na własnych rozwiązaniach.
    Serwerownia wykorzystuje podwójny system UPS, z którego zasilane są główne zasilacze infrastruktury. Awaria lub całkowite odłączenie jednego UPS-a nie powoduje przerwy w pracy — elektroniczny przełącznik aktywnej linii 230 V automatycznie przełącza zasilanie na drugi lub trzeci działający układ. Bardzo ułatwia to również konserwację i testowanie samych UPS-ów (dowolny UPS można wyłączyć w celu konserwacji).
    Na poziomie infrastruktury krytycznej, odpowiedzialnej za dostęp do sieci zewnętrznej, redundancja została dodatkowo rozszerzona. Linie 12 V są tam podwojone i trafiają do elektronicznego przełącznika opartego o diody Schottky. Dzięki temu oddzielny zasilacz jest w stanie utrzymać pracę kluczowych elementów nawet w przypadku awarii głównego zasilacza.

• Zaleta: Duży bufor akumulatorowy i przetrwanie awarii sieci energetycznej.
Fakty:
    Serwerownia posiada rozbudowany system UPS oraz dodatkowe bloki akumulatorów umożliwiające wielogodzinną pracę podczas zaniku zasilania.
Komentarz:
    UPS-y oraz dodatkowe baterie / bloki akumulatorów pozwalają utrzymać pracę serwerowni mimo braku zasilania przez kilka godzin (zwykle ok. 3–5 godzin). Na szczęście moje miasto ma całkiem stabilną sieć energetyczną i dłuższe awarie zdarzają się głównie podczas remontów infrastruktury lub poważniejszych zdarzeń, takich jak pożary w okręgu zasilania.
    Mimo obecnego systemu UPS nadal rozważam przejście w kierunku pełniejszego zasilania bezpośrednio z linii 12 V oraz dużych akumulatorów pracujących poza klasycznym układem UPS.

• Miniaturyzacja dysków: droga do dużych oszczędności energetycznych.
Fakty:
    W serwerowni zjk.pl szeroko wykorzystywane są dyski 2,5 cala. Ich główną zaletą jest niski pobór energii oraz łatwość zabudowy w obudowach mini-ITX.
Komentarz:
    Dyski 2,5 cala przez lata kojarzone były głównie ze sprzętem mobilnym — laptopami, miniaturowymi komputerami czy platformami NUC. Nie oznacza to jednak, że są nietrwałe. Wręcz przeciwnie — dzięki mniejszym rozmiarom oraz konstrukcji projektowanej z myślą o urządzeniach przenośnych często dobrze znoszą wieloletnią pracę ciągłą, wibracje i zmiany temperatury. W mojej serwerowni wiele takich dysków pracuje już ponad 10 lat.
    Największą zaletą pozostaje jednak energooszczędność. Typowy dysk 3,5 cala potrafi pobierać kilkanaście watów energii, szczególnie podczas rozruchu i intensywnej pracy. Tymczasem dysk 2,5 cala zwykle potrzebuje jedynie kilku watów zasilania 5 V. Przy większej liczbie napędów różnica staje się bardzo wyraźna — dwa duże dyski mogą pobierać niemal 40–50 W, podczas gdy dwa małe wymagają jedynie około 10 W.
    W praktyce ma to ogromne znaczenie w środowisku opartym o mini-ITX oraz samochodowe obudowy komputerowe. Zresztą — nie ma tam miejsca na ciężkie magazyny 3,5 cala, natomiast bez problemu mieszczą się dwa lub więcej dysków 2,5 cala. Dzięki temu możliwe było utrzymanie bardzo zwartej konstrukcji całej serwerowni przy jednoczesnym ograniczeniu ilości wydzielanego ciepła oraz kosztów zasilania.
    To kolejny przykład filozofii projektu zjk.pl — nie chodzi o budowę infrastruktury „enterprise za wszelką cenę”, lecz o rozsądny dobór technologii do rzeczywistych potrzeb i warunków pracy domowego klastra.

IV. Sieć i Redundancja: Walka o każdy pakiet

Fakty:
    Infrastruktura sieciowa zjk.pl wykorzystuje redundantne firewalle OPNsense z CARP i HAProxy, podwójne switche oraz agregację łączy LACP dla większości serwerów.
Komentarz:
    Dostęp do Internetu realizowany jest przez dwa firewalle OPNsense pracujące w trybie failover z wykorzystaniem protokołu CARP. Dodatkowo HAProxy odpowiada za równoważenie ruchu i kontrolę dostępności usług działających na wielu serwerach jednocześnie.
    Sieć wewnętrzna została oparta o dwa fizyczne switche. Główny przełącznik obsługuje normalny ruch infrastruktury, natomiast drugi pełni rolę awaryjnego fallbacku w przypadku uszkodzenia podstawowego urządzenia.
    Standardem dla większości serwerów stała się również agregacja łączy LACP (LAGG na FreeBSD), zwiększająca odporność infrastruktury na awarie okablowania oraz poprawiająca przepustowość komunikacji między serwerami.
    Całość była projektowana z myślą o ograniczaniu pojedynczych punktów awarii oraz możliwości prowadzenia prac konserwacyjnych bez całkowitego zatrzymywania infrastruktury.

• Brzeg sieci: Zdublowany OPNsense (CARP) i HAProxy.
Fakty:
    Dostęp do Internetu realizowany jest przez redundantne firewalle OPNsense wykorzystujące CARP, HAProxy oraz dwa niezależne łącza od różnych dostawców.
Komentarz:
    Pomysł na zdublowaną sieć dostępową pojawił się jeszcze w czasach komputerów przemysłowych pracujących w serwerowni. Największym problemem był wtedy brak oddzielnych interfejsów Ethernet, a pierwsze testy nie dawały przekonania, że całość będzie działała stabilnie.
    Po wielu latach wróciłem do pomysłu i ponownie zbudowałem środowisko testowe — dwa symulowane łącza dostawców oraz wspólna sieć wewnętrzna. Tym razem rozwiązanie zaczęło działać poprawnie :) Szybko pojawiło się jednak kolejne pytanie — cóż mi po dwóch dostawcach Internetu, skoro awarii może ulec sam komputer dostępowy?
    Odpowiedzią okazał się drugi firewall synchronizujący stany połączeń oraz przejmujący adresy IP uszkodzonej maszyny. W świecie FreeBSD rolę tę pełni CARP.
    Z czasem podobne problemy zaczęły pojawiać się również wewnątrz infrastruktury — zarówno przy awariach pojedynczych kabli, jak i całych serwerów obsługujących konkretne usługi lub storage. CARP pojawiał się więc w kolejnych miejscach sieci.
    I tutaj zaczynają się praktyczne problemy. CARP (czy linuxowy odpowiednik VRRP) świetnie działa w prostych, uporządkowanych środowiskach lub na wydzielonych segmentach sieci. W realnej infrastrukturze, gdzie jednocześnie pracują usługi WWW, poczta, użytkownicy wewnętrzni i mechanizmy HA — zaczyna pojawiać się chaos trudny do pełnego uporządkowania.
    Oczywiście idealnym rozwiązaniem byłoby dalsze wydzielanie segmentów sieci i prawdopodobnie pojawi się ono przy kolejnej przebudowie infrastruktury. Jednak w obecnym środowisku zdarzały się sytuacje, gdy CARP po prostu się „gubił”.
    Dlatego dla najbardziej krytycznych elementów infrastruktury czasem lepiej sprawdzają się własne skrypty monitorujące stan sieci i przenoszące alias IP pomiędzy interfejsami Ethernet.
    Podobna filozofia stoi za dużą rolą HAProxy w zjk.pl. Lepiej polegać na zewnętrznym mechanizmie oceny stanu usługi niż na „wewnętrznym przekonaniu” samej maszyny, że wszystko działa poprawnie. HAProxy stale testuje serwery i kieruje ruch wyłącznie do tych, które rzeczywiście odpowiadają stabilnie.
    Obecnie OPNsense stał się jednym z kluczowych elementów stabilności całego środowiska. Serwerownia korzysta z dwóch niezależnych łączy różnych operatorów i różnych technologii dostępu (kabel TV oraz światłowód). OPNsense rozdziela ruch algorytmem Round-Robin ze Sticky Connections.
    HAProxy kieruje natomiast ruchem do:
serwerów WWW (4 maszyny),
PostgreSQL Hot Redundancy (3 maszyny),
MySQL Cluster Replication (5 maszyn),
SeaweedFS (3 mastery).
    Dzięki gotowemu do przejęcia pracy drugiemu firewallowi OPNsense infrastruktura działa bardzo stabilnie. Odpowiednie wpisy DNS powodują, że oba zewnętrzne adresy IP są jednocześnie wykorzystywane zarówno przez WWW (podwójne rekordy A), jak i usługi pocztowe (mail oraz mail2).

• Topologia: Przejście na dwa fizyczne switche (zarządzalny + fallback - ten niedługo będzie zastąpiony przez drugi zarządzalny).
Fakty:
    Infrastruktura wykorzystuje główny switch zarządzalny oraz dodatkowy awaryjny switch fallback zapewniający podstawową komunikację z Internetem w przypadku uszkodzenia głównego przełącznika.
Komentarz:
    Uszkodzenie głównego switcha to dla serwerowni awaria katastrofalna — praktycznie eliminuje całą infrastrukturę z działania. Tego typu uszkodzeń trudno uniknąć lub wcześniej przewidzieć, dlatego pozostaje głównie minimalizowanie ryzyka.
    Stosuję switch 24+2 porty. Mimo zapewnień producenta o braku konieczności dodatkowego chłodzenia zdecydowałem się dodać do switcha trzy małe wentylatory 4 cm umieszczone przy bocznej kratce wentylacyjnej. Przyznam, że sam byłem zaskoczony skutecznością tego rozwiązania — zamiast bardzo gorącej obudowy switch jest teraz po prostu wyraźnie ciepły, ale już nie „parzący”.
    Pozostaje jednak pytanie: co zrobić, gdy główny switch mimo wszystko ulegnie uszkodzeniu?
    Docelowo chciałbym posiadać drugi pełny switch zarządzalny, jednak obecnie nie mam jeszcze miejsca na taką rozbudowę infrastruktury. Dlatego przyjąłem inną strategię bezpieczeństwa — skoro po awarii głównego switcha i tak większość usług przestanie działać, najważniejsze staje się zachowanie podstawowej łączności ze światem zewnętrznym.
    Tę rolę przejmuje drugi, niewielki switch awaryjny, który łączy wyłącznie kluczowe elementy infrastruktury: OPNsense, modemy oraz sieć Wi-Fi. Dzięki temu nawet przy poważniejszej awarii nadal możliwa pozostaje podstawowa komunikacja i administracja serwerownią.

• Warstwa L2: Agregacja łączy (LACP) jako standard na każdym węźle.
Fakty:
    Każdy serwer w infrastrukturze zjk.pl wykorzystuje podwójne łącza Ethernet pracujące w agregacji LACP/LAGG. Mechanizmy agregacji wykorzystywane są również w innych elementach infrastruktury sieciowej.
Komentarz:
    Opisywana wcześniej agregacja LAGG / LACP jest podstawą działania serwerów — każdy z nich posiada podwójne łącze Ethernet. W praktyce oznacza to obecnie 16 kabli sieciowych, co wynika bezpośrednio z możliwości switcha zarządzalnego, obsługującego maksymalnie 8 grup agregacji.
    Nawiasem mówiąc, wykonywałem również eksperymenty z poczwórnymi grupami LAGG. Takie rozwiązania działają poprawnie, choć w warunkach domowej serwerowni ich praktyczna użyteczność jest już znacznie mniejsza.
    Warto też zauważyć, że LAGG w mojej sieci występuje w kilku różnych odmianach, nie tylko jako klasyczne LACP. Wykorzystywany jest również tryb loadbalance pomiędzy switchem a aktywnym OPNsense, a także failover — przykładowo dla komputera osobistego, gdybym chciał korzystać z niego poza biurkiem i automatycznie przełączać go pomiędzy Ethernetem a Wi-Fi.
    Zachęcam do dokładniejszego poznania mechanizmów LAGG/LACP, ponieważ dla osób interesujących się sieciami komputerowymi kryje się tam naprawdę wiele bardzo ciekawych możliwości.

V. Dane i Storage: Klastry w praktyce

Fakty:
    Architektura przechowywania danych wykorzystuje równolegle kilka technologii storage i baz danych. Podstawowym systemem plików magazynów danych jest ZFS. Rozproszone przechowywanie plików realizuje klaster MooseFS (7 węzłów) oraz SeaweedFS dla obiektów i multimediów. Warstwa bazodanowa wykorzystuje PostgreSQL Hot Redundancy (3 maszyny), MySQL Cluster Replication (5 maszyn) oraz Redis (6 maszyn) z obsługą przez HAProxy i Sentinel.
Komentarz:
    Architektura przechowywania danych opiera się na hybrydowym podejściu wykorzystującym kilka równoległych systemów plików i baz danych o różnej charakterystyce. Tradycyjne pliki stron WWW, konfiguracje oraz operacje zgodne z POSIX obsługuje wysoko dostępny klaster MooseFS rozproszony na siedem węzłów. Do przechowywania cięższych obiektów i multimediów wdrożono niezależny klaster SeaweedFS, zoptymalizowany pod kątem dużej liczby plików i wysokiej wydajności transferu (3 mastery i 7 filerów). Warstwa bazodanowa i cache to 5 maszyn MySQL Cluster Replication, 3 PostgreSQL Hot Redundancy oraz 6 maszyn Redis współpracujących z HAProxy i Sentinel.

• ZFS: podstawowy system plików w magazynach danych
Fakty:
    Podstawowym systemem plików wykorzystywanym w magazynach danych zjk.pl jest ZFS.
Komentarz:
    UFS2 wywodzi się jeszcze z bardzo starego FFS i nadal dziedziczy wiele jego zalet oraz wad. Pamiętam przejście z UFS1 na UFS2 — kopiowanie i usuwanie plików przyśpieszyło wtedy radykalnie. Jednak jako system plików dla serwera UFS ma pewną istotną wadę: po niespodziewanym restarcie mogą pojawić się błędy uniemożliwiające poprawny start systemu. Wtedy nie zawsze pomaga automatyczne sprawdzanie dysków przy starcie i system potrafi zatrzymać się z koniecznością ręcznego fsck. Samo fsck dla terabajtowych dysków trwa niezwykle długo — jeśli zawierają wiele małych plików: do kilku godzin.
    ZFS zachowuje się inaczej — zwykle uruchamia się poprawnie nawet po awarii. Oczywiście do momentu naprawdę poważnych uszkodzeń. Co ciekawe, UFS praktycznie zawsze daje się ostatecznie naprawić, natomiast ZFS działa bardziej „zerojedynkowo” — albo wszystko działa świetnie, albo pool może nie dać się już zaimportować mimo restartów i prób odzyskiwania (importowania).
    ZFS to jednak znacznie więcej niż system plików o „zetowej” pojemności. To właściwie druga warstwa zarządzania powierzchnią dyskową: szyfrowanie, kompresja, snapshoty, RAIDZ, eksport i import całych struktur danych, a nawet przesyłanie ich przez sieć. Szczególnie wysoko oceniam RAIDZ — łączy klasyczny RAID z rozproszonymi sumami kontrolnymi i mechanizmami odbudowy danych (stosuję RAIDZ2). Majstersztyk.

• MooseFS: 7 węzłów dla plików WWW i POSIX (/usr/home)
Fakty:
    Rozproszone przechowywanie danych POSIX oraz katalogów współdzielonych realizuje klaster MooseFS działający na 7 węzłach.
Komentarz:
    Przechowywanie, udostępnianie i archiwizacja danych to podstawowe zadania każdego mini-DataCenter. Klasyczny NFS rodzi jednak wiele problemów — od ograniczeń pojedynczych dysków, po problemy z montowaniem udziałów podczas startu systemu. Nawet RAID pozostaje pojedynczym punktem awarii, a jego rebuild lub przywracanie danych z backupu zawsze wymaga czasu.
    Po dłuższym namyśle zdecydowałem się na polskie rozwiązanie — MooseFS. System ten łączy przestrzeń dyskową wielu komputerów w jeden wspólny zasób, z możliwością zabezpieczenia danych przez multiplikację lub EC (Erasure Coding). Szczególnie ważna jest odporność na awarie dysków.
    Miałem sytuacje uszkodzenia dysków i przyznam, że ogromny spokój daje obserwowanie, jak MooseFS sam odbudowuje brakujące dane i przywraca właściwy poziom replikacji — bez nerwowego odtwarzania backupów czy oczekiwania, czy RAID przeżyje rebuild.
    MooseFS jest przy tym wyjątkowo stabilny. Problemy mogą pojawić się przy przeciążeniu sieci i chunkserverów, ale mastery i metaloggery w mojej infrastrukturze nigdy nie zawiesiły się ani nie resetowały.
    Dodatkową zaletą jest wygodne współdzielenie zasobów pomiędzy wieloma komputerami — np. katalogów /usr/home czy wspólnej przestrzeni roboczej dla kilku serwerów WWW korzystających z tych samych danych.

• SeaweedFS: równoległy klaster dla obiektów i multimediów
Fakty:
    Do przechowywania obiektów i dużej liczby małych plików wykorzystywany jest niezależny klaster SeaweedFS.
Komentarz:
    MooseFS ma jedną charakterystyczną cechę wynikającą z jego architektury — każdy plik przechowywany jest w osobnym chunku. Przy bardzo dużej liczbie niewielkich plików czas dostępu zaczyna mieć znaczenie.
    SeaweedFS działa podobnie, ale przechowuje wiele plików wewnątrz większych bloków danych. Dzięki temu znacznie lepiej radzi sobie z ogromną liczbą małych plików.
    Aktualnie testuję, na ile SeaweedFS może częściowo zastąpić MooseFS przy obsłudze setek tysięcy niewielkich plików wykorzystywanych przez Apache. W zależności od sposobu liczenia moje strony WWW to obecnie od 400 do 800 tysięcy plików o łącznym rozmiarze od około 15 do 80 GB.

• Bazy danych PostgreSQL Hot Redundancy (3 maszyny) oraz MySQL Cluster Replication (5 maszyn)
Fakty:
    Infrastruktura wykorzystuje klaster PostgreSQL Hot Redundancy oraz MySQL Cluster Replication synchronizowane i nadzorowane przez HAProxy.
Komentarz:
    Każde data-center wcześniej czy później sprowadza się do baz danych. Wybór odpowiedniego rozwiązania nie może być przypadkowy.
    SQLite jest niezwykle szybka i prosta, ale przy dużych bazach stosunkowo łatwo ją uszkodzić podczas awarii lub restartu systemu. Naprawa bywa możliwa, ale nie zawsze kończy się pełnym sukcesem.
    W przypadku bardziej krytycznych zastosowań stosuję PostgreSQL. Dobrym przykładem jest Bareos, który musi przechowywać informacje o milionach zarchiwizowanych plików. Tutaj pomyłki są niedopuszczalne.
    SeaweedFS również preferuje PostgreSQL, szczególnie w bardziej rozbudowanych konfiguracjach. Dodatkowo dochodzi problem split-brain w środowiskach multimaster. Dlatego zastosowałem klaster PostgreSQL Hot Redundancy składający się z trzech maszyn — jednego mastera i dwóch replik. Nad całością czuwa HAProxy, zapewniający wspólny punkt dostępu dla zapisów i odczytów.
    Klaster MySQL powstał z nieco innej potrzeby. To klasyczny „wół roboczy” dla aplikacji WWW — szybki, względnie prosty i dobrze sprawdzający się pod dużym obciążeniem. Dane z mastera replikowane są na cztery pozostałe maszyny, a mechanizmy klastra umożliwiają weryfikację poprawności danych przy rozbieżnościach pomiędzy węzłami. Także tutaj całość nadzoruje HAProxy.

• Cache Redis (6 maszyn) tunelowany przez Stunnel
Fakty:
    System cache oparty jest o Redis działający w konfiguracji 1 master + 5 replik z nadzorem Sentinel i HAProxy.
Komentarz:
    Udostępnianie stron WWW jest procesem znacznie bardziej złożonym niż samo wysłanie pliku do przeglądarki użytkownika. Kluczowe znaczenie ma szybkość dostępu do danych i mechanizmy cache.
    Apache posiada własne systemy przyśpieszania pracy, jednak dodatkowo wykorzystuję Redis jako bardzo szybki cache pamięciowy. System działa w konfiguracji jednego mastera oraz pięciu serwerów replikujących.
    Nad spójnością całości czuwa Sentinel monitorujący stan klastra, natomiast HAProxy automatycznie kieruje ruch do aktualnie aktywnego serwera Redis. Tunelowanie ruchu przez Stunnel pozostaje obecnie w fazie testów.

VI. Bezpieczeństwo potwierdzone danymi

Fakty:
    Infrastruktura zjk.pl utrzymuje wysokie wyniki w niezależnych audytach bezpieczeństwa, m.in. SSL Labs A+ oraz Security Headers A. Systemy są stale monitorowane, regularnie aktualizowane i rozwijane bez konieczności pełnych reinstalacji.
Komentarz:
    Miarą skuteczności zabezpieczeń nie są deklaracje administratora, ale niezależne testy i praktyczna stabilność działania. Serwery zjk.pl od lat utrzymują wysokie wyniki w audytach SSL Labs oraz Security Headers. Infrastruktura jest stale monitorowana, a wszelkie anomalie lub problemy zwykle wychwytywane są bardzo szybko.
    O stabilności FreeBSD najlepiej świadczy fakt, że przez ponad 20 lat działania serwerowni system przeszedł tylko jedną pełną reinstalację — jeszcze w czasach wersji 5.3. Wszystkie późniejsze aktualizacje systemu i aplikacji wykonywane były „w locie”, bez budowania środowiska od zera. W praktyce upgrade sprzętu zwykle polegał na przeniesieniu danych na nowe dyski lub dysków do nowego sprzętu niż na reinstalacji całych systemów.

• Audyty: SSL Labs A+ i Security Headers A na własnym sprzęcie
Fakty:
    Serwery regularnie osiągają wysokie wyniki w zewnętrznych audytach bezpieczeństwa i konfiguracji usług.
Komentarz:
    Nie ma w tym żadnej tajemnicy — podstawą jest systematyczna praca i brak założenia, że skoro „jakoś działa”, to wszystko jest już dobrze skonfigurowane.
    Bardzo ważne są zewnętrzne audyty. Nawet jeśli to tylko strona testowa lub opinia użytkownika, pozwalają spojrzeć na własną infrastrukturę z zewnątrz. Pokazują nie tylko błędy, ale także kierunek dalszej poprawy i poziom, do którego można dążyć.
    Czasami najprostsze testy okazują się najcenniejsze. Zwykły ping, próba pobrania strony WWW czy połączenia z pocztą potrafią ujawnić problemy, których od środka infrastruktury w ogóle nie widać.
    Mogę podsumować to jednym słowem — polecam.

• Monitoring: Jak pilnowany jest stan serwerowni
Fakty:
    Infrastruktura wykorzystuje wielowarstwowy monitoring oparty o raporty systemowe, własne skrypty, narzędzia analityczne oraz obserwację pracy serwerów.
Komentarz:
    Każda metoda monitoringu jest dobra — pod warunkiem, że jest ich wiele i wzajemnie się uzupełniają.
    Podstawą są codzienne raporty mailowe z serwerów. Nawet pobieżne ich przeglądanie pozwala szybko zauważyć anomalie. Dla bardziej krytycznych usług polecam własne skrypty kontrolujące stan aplikacji i wysyłające alerty — u mnie dotyczy to m.in. SeaweedFS czy PostgreSQL.
    Na serwerach praktycznie stale uruchomiony jest top, htop lub atop. Z czasem administrator zaczyna intuicyjnie rozpoznawać normalny stan pracy systemów.
    Najchętniej stosuję mój 16 portowy przełącznik KVM - szybkie przełączanie od razu z dostępem do kilku przełączanych konsol na każdym komputerze.
    Cenne są również raporty historyczne generowane przez narzędzia takie jak Monitorix, MRTG czy Symon. Szczególnie lubię codzienne wykresy Monitorixa — pozwalają szybko zauważyć zmiany obciążenia lub nietypowe zachowanie serwerów.
    Testowałem także cięższe systemy monitoringu, np. Zabbixa. Nadal go polecam, ale w moim przypadku generował zbyt dużą ilość danych i alarmów, które z czasem bardziej przeszkadzały niż pomagały.
    Po wielu latach pracy pojawia się też inny rodzaj monitoringu — administrator zaczyna słyszeć serwerownię. Czasem wystarczy minimalnie głośniejszy wentylator albo lekko zmieniony szum powietrza, żeby wiedzieć, że któryś komputer jest bardziej obciążony niż zwykle.
    A jeśli zwykły użytkowy komputer któregoś z domowników zaczyna „przycinać” pocztę, transfer plików lub strony WWW — to także sygnał, że warto sprawdzić stan całej infrastruktury.

• Backup
Fakty:
    System backupu wykorzystuje równolegle kilka mechanizmów: dump, Bareos, UrBackup oraz narzędzia do tworzenia obrazów systemów.
Komentarz:
    Trzeba mieć backup. Trzeba mieć kopię zapasową. Trzeba mieć archiwum. Jeszcze ważniejsze jest jednak to, żeby dało się z nich łatwo i szybko skorzystać.
    Struktura backupów w zjk.pl jest wielowarstwowa.
    Podstawą pozostaje klasyczny dump — niedoceniany, ale nadal bardzo skuteczny i prosty mechanizm. Wiele moich własnych skryptów opiera się właśnie na nim.
    Do backupów codziennych i tygodniowych świetnie sprawdza się Bareos, szczególnie przy odzyskiwaniu pojedynczych plików. UrBackup bardzo dobrze nadaje się natomiast do tworzenia obrazów całych systemów.
    W przypadku Windows nawet podstawowe mechanizmy systemowe są już sensownym zabezpieczeniem, choć dodatkowo dla komputerów osobistych korzystam z SyncBackPro oraz EaseUS Todo Backup, który bardzo dobrze radzi sobie z wykonywaniem obrazów systemu.

• Ciągłość: Jedna reinstalacja i 20 lat aktualizacji „w locie”
Fakty:
    Przez ponad 20 lat działania infrastruktura przeszła tylko jedną pełną reinstalację systemu. Aktualizacje systemów i aplikacji wykonywane są regularnie bez zatrzymywania całego środowiska.
Komentarz:
    To prawda — pełna reinstalacja była tylko jedna (dla v 5.3). Miałem wtedy backup, ale równocześnie pojawił się problem z odczytem dysku ratunkowego i ostatecznie system trzeba było odtworzyć od początku.
    Znacznie ciekawsze są jednak same początki aktualizacji FreeBSD. W tamtych latach praktycznie wszystko kompilowało się ręcznie. Dostępnych źródeł wiedzy było niewiele, a aktualizacja większej liczby programów mogła zajmować nawet tydzień lub dwa.
    Później przez wiele lat korzystałem z Poudriere do budowy własnych pakietów dla różnych konfiguracji serwerów. Dziś sytuacja jest znacznie wygodniejsza — system pkg w FreeBSD jest naprawdę świetny.
    Najważniejsze pozostaje jednak regularne aktualizowanie aplikacji. To kwestia zarówno bezpieczeństwa, jak i stabilności działania.
    Co tydzień wykonuję pełny upgrade aplikacji. Dzięki temu łatwo kontrolować, które usługi wymagają restartu, bez konieczności restartowania całych serwerów. Unika się też problemów z zależnościami i nagromadzeniem zmian.
    Aktualizacja wykonywana raz w roku staje się bardzo trudna — jednocześnie pojawiają się nowe wersje wielu programów, zmiany konfiguracji i problemy kompatybilności. Nawet jeśli sam upgrade się powiedzie, często kończy się kilkoma dniami naprawiania usług.
    Znacznie łatwiej robić to systematycznie. W jednym tygodniu aktualizowany jest Perl, w kolejnym PostgreSQL, a kilka tygodni później trzeba sprawdzić nową konfigurację Dovecota. Takie podejście jest po prostu spokojniejsze i bezpieczniejsze.

VII. Pokora: Ciemna strona złożoności

Fakty:
    Rozbudowane mechanizmy redundancji i wysokiej dostępności zwiększają odporność infrastruktury, ale jednocześnie podnoszą poziom jej złożoności. W zjk.pl regularnie wykonywane są zarówno aktualizacje oprogramowania, jak i fizyczna konserwacja całego klastra.
Komentarz:
    Budowa zaawansowanej serwerowni bardzo łatwo prowadzi do pułapki „Complexity Penalty” — sytuacji, w której kolejne warstwy zabezpieczeń i redundancji same zaczynają generować nowe problemy. Mechanizmy wysokiej dostępności potrafią znacząco zwiększyć odporność systemu, ale jednocześnie komplikują diagnostykę, utrudniają przewidywanie zachowań sieci i mogą prowadzić do zjawisk takich jak split-brain. W praktyce często okazuje się, że rozwiązanie prostsze bywa stabilniejsze od teoretycznie bardziej „idealnego”.
    Dlatego równie ważna jak sama wiedza techniczna staje się umiejętność zachowania rozsądku i prostoty tam, gdzie jest ona możliwa. Każdy dodatkowy element infrastruktury to potencjalne nowe źródło awarii, dodatkowe zależności i większa odpowiedzialność administratora.
    Nad całym środowiskiem zawsze stoi człowiek — administrator odpowiedzialny nie tylko za konfigurację, ale również za aktualizacje, monitoring, konserwację sprzętu i reagowanie na sytuacje awaryjne. Nawet najlepiej zaprojektowana architektura wymaga regularnej kontroli fizycznej.
    Stąd w zjk.pl istnieje coroczny „Dzień Odkurzacza” — kontrolowane wyłączenie całego klastra połączone z fizycznym przeglądem infrastruktury. To moment sprawdzenia wentylatorów, radiatorów, okablowania, pamięci, baterii podtrzymania BIOS-u czy stanu złączy zasilania. Przy okazji usuwany jest kurz, który pozostaje jednym z głównych wrogów elektroniki pracującej całodobowo.
    Dodatkowe planowane wyłączenia wynikają również z większych aktualizacji systemów operacyjnych oraz modernizacji oprogramowania. Regularna konserwacja okazuje się znacznie bezpieczniejsza niż oczekiwanie na pierwszą poważną awarię.

• Complexity Penalty: Świadomość, że nagromadzenie zabezpieczeń tworzy nowe ryzyka (Split-brain).
Fakty:
    Wysoka dostępność i tryby multimaster zwiększają odporność infrastruktury, ale jednocześnie mogą prowadzić do trudnych do wykrycia błędów synchronizacji, takich jak split-brain.
Komentarz:
    Duży zachwyt zwykle towarzyszy informacjom, że dane oprogramowanie potrafi pracować w trybie multimaster – czyli sytuacji, gdy kilka maszyn jednocześnie zarządza tym samym zasobem. W teorii brzmi to idealnie. W praktyce jednak pojawia się problem split-brain – rozdwojenia stanu systemu, gdy dwa węzły zaczynają uważać się równocześnie za nadrzędne.
    Moje doświadczenia pokazują, że problem ten wcale nie jest mityczny. Próbowałem wdrożyć dziś już wycofany system HAST (High Available Storage). Wystarczyły przeciążenia sieci lub problemy ze sterownikami kart Ethernet, aby regularnie zrywać komunikację między węzłem master i slave. Efekt był bardzo nieprzyjemny – split-brain i konieczność odbudowy całego środowiska od początku.
    To jedna z najważniejszych lekcji budowy własnej serwerowni: rozwiązanie bardziej skomplikowane nie zawsze jest rozwiązaniem lepszym. Czasem prostsza architektura okazuje się stabilniejsza, łatwiejsza do utrzymania i po prostu bezpieczniejsza.

• Czynnik ludzki: Odpowiedzialność administratora za tak złożony organizm.
Fakty:
    Stabilność infrastruktury zależy nie tylko od sprzętu i oprogramowania, ale również od regularnej konserwacji, monitoringu i świadomego zarządzania całością środowiska.
Komentarz:
    Przede wszystkim nie wolno lekceważyć serwera. Zaniedbany komputer podłączony do Internetu bardzo szybko staje się źródłem problemów – od awarii usług po rozsyłanie spamu czy pogarszanie reputacji całej podsieci.
    Odpowiedzialność administratora jest podobna do odpowiedzialności właściciela samochodu. Czasem słyszy się: „tylko jeżdżę i leję paliwo”. W praktyce każdy samochód wymaga przeglądów, wymiany części i kontroli stanu technicznego. Z serwerami jest dokładnie tak samo. Dobrze utrzymana maszyna potrafi działać latami bardzo stabilnie, ale wymaga systematycznej opieki.
    W korporacjach podejrzany sprzęt często wymienia się natychmiast na nowy. W domowej serwerowni częściej działa zasada „chuchać i dmuchać” – obserwować temperatury, dźwięki wentylatorów, napięcia, zachowanie dysków i reagować zanim pojawi się realna awaria.
    Największym pojedynczym punktem zawodności pozostaje jednak jednoosobowa administracja. W praktyce wszystko zależy od jednej osoby. Chociaż czasem zdarzają się zabawne sytuacje – zdarzało mi się prosić żonę, humanistkę, aby w razie długiej awarii prądu po określonym czasie bezpiecznie wyłączyła serwery. I działało. Może więc redundancja istnieje nawet tam, gdzie człowiek się jej nie spodziewa.

• Dzień Odkurzacza: Coroczna konserwacja i kontrolowane wyłączenie klastra.
Fakty:
    Raz w roku cała serwerownia jest planowo wyłączana w celu przeprowadzenia pełnej konserwacji fizycznej sprzętu.
Komentarz:
    Raz w roku serwery milkną na kilka godzin. Obowiązkowe odkurzanie.
    Nie jest to wyłącznie kwestia estetyki. Czyszczenie radiatorów, wentylatorów i obudów ma bezpośredni wpływ na temperatury pracy, a temperatura pozostaje jednym z głównych czynników wpływających na trwałość elektroniki.
    Przy okazji wykonywany jest pełny przegląd techniczny:
sprawdzanie oporów wentylatorów,
kontrola napięcia baterii BIOS-u,
przepięcie pamięci RAM,
kontrola radiatorów procesorów,
sprawdzenie okablowania wewnętrznego i zewnętrznego,
wymiana elementów budzących wątpliwości zanim ulegną awarii.
    To także dobry moment, by zwyczajnie posłuchać sprzętu. Po latach pracy administrator zaczyna rozpoznawać problemy nawet po delikatnej zmianie charakterystyki szumu wentylatorów czy temperatur obudów.
    Dodatkową korzyścią jest fakt, że wyczyszczony sprzęt pracuje ciszej, chłodniej i stabilniej przez kolejne miesiące.


VIII. Sprzęt podstawą spokoju w serwerowni – jaki sprzęt i oprogramowanie wybierać?

Fakty:
    Infrastruktura zjk.pl budowana jest w oparciu o stabilne i dobrze wspierane podzespoły komputerowe. Przy wyborze sprzętu kluczowe znaczenie mają niezawodność, kompatybilność z FreeBSD oraz stabilna praca ciągła 24/7.
Komentarz:
    Najważniejsza zasada jest bardzo prosta: sprzęt ma być dobry i stabilny.
       
• Dobry sprzęt: stabilność ważniejsza niż maksymalna wydajność.
Fakty:
    W serwerowni kluczowe znaczenie mają stabilność, jakość wykonania oraz zgodność sprzętu z systemem operacyjnym, a nie maksymalna wydajność podzespołów.
Komentarz:
    Dobry sprzęt nie musi być najdroższy. Powinien być przede wszystkim przewidywalny i stabilny. Nie „gamingowy”, nie ekstremalnie wydajny i nie najtańszy. Każdy słaby element wcześniej czy później się mści i staje się źródłem awarii całego środowiska. W praktyce problemem częściej okazuje się drobny detal — kiepska wtyczka zasilania, słaby przewód albo niestabilny zasilacz — niż brak dodatkowych megaherców procesora. W serwerze nie ma potrzeby agresywnego podkręcania czy pracy na granicy możliwości sprzętu. Komputer ma działać stabilnie przez całą dobę, często przez wiele lat bez restartu. Dodatkowe megaherce zwykle nie mają większego znaczenia, natomiast ogromne znaczenie ma jakość chłodzenia, niezawodne połączenia sieciowe, stabilne zasilanie, kompatybilność sterowników oraz przewidywalność pracy całego zestawu.
    W mojej serwerowni zdarzały się sytuacje, gdy problemem okazywała się zwykła wtyczka zasilania za kilka złotych. Potrafiła nagrzewać się przy niewielkim prądzie, topić od środka, a w skrajnym przypadku doprowadzić do zwarcia linii zasilających. Takie doświadczenia bardzo szybko uczą szacunku do jakości wykonania nawet najdrobniejszych elementów infrastruktury. Każdy słaby element potrafi po latach stać się przyczyną trudnej do wykrycia awarii.
    Jednocześnie bardzo drogi sprzęt serwerowy często nie ma większego sensu w domowym data-center. Serwer nie jest komputerem do benchmarków czy overclockingu. Nie musi osiągać rekordowych wyników wydajności – ma pracować spokojnie, cicho i stabilnie przez całą dobę.
    Przy wyborze sprzętu dla FreeBSD bardzo ważna jest zgodność sterowników oraz wsparcie systemowe. Linux posiada zwykle szerszą bazę obsługiwanych urządzeń, dlatego niektóre nowe lub egzotyczne konstrukcje mogą działać tam łatwiej. W praktyce oznacza to konieczność spokojnego sprawdzenia kompatybilności przed zakupem sprzętu do serwera.W przypadku FreeBSD zawsze warto najpierw przed zakupem sprawdzić listę wspieranego sprzętu. Linux ma zwykle lepsze wsparcie sterowników, dlatego nie każdy nowoczesny układ będzie działał równie dobrze na obu systemach.
    Paradoksalnie problemem potrafi być też sprzęt „zbyt energooszczędny”. Mechanizmy agresywnego oszczędzania energii mogą usypiać urządzenia, powodować zrywanie transmisji lub destabilizować pracę usług sieciowych. Problemy potrafią sprawiać także urządzenia fabrycznie projektowane z przesadnym naciskiem na oszczędność energii. Zbyt agresywne mechanizmy usypiania interfejsów, procesorów czy kontrolerów potrafią powodować zrywanie transmisji, opóźnienia lub niestabilność usług sieciowych. Dlatego energooszczędność jest ważna, ale tylko wtedy, gdy nie odbywa się kosztem stabilności pracy całego środowiska. Jak zwykle – przesada w żadną stronę nie jest dobra.

• Analizy i gotowe recepty.
Fakty:
    Nie istnieje jedna uniwersalna konfiguracja sprzętowa lub programowa odpowiednia dla każdej serwerowni.
Komentarz:
    Nie przedstawię tutaj gotowych analiz ani jednej „idealnej” konfiguracji. Pewne wskazówki znajdują się w opisach całej infrastruktury, ale szczegóły każdy administrator musi dopracować samodzielnie.
    Każda serwerownia działa w innych warunkach:
inne są potrzeby użytkowników,
inne obciążenia,
inne budżety,
inne wymagania dotyczące bezpieczeństwa,
inne ograniczenia energetyczne i lokalowe.
    To, co świetnie sprawdzi się w jednym środowisku, w innym może okazać się kompletnie niepraktyczne.

• FAQ i poradniki budowy własnej serwerowni.
Fakty:
    Dodatkowe informacje techniczne oraz praktyczne przykłady znajdują się w działach FAQ i poradnikach dotyczących budowy własnej serwerowni.
Komentarz:
    Osoby bardziej zainteresowane tematyką zachęcam do przejrzenia działu FAQ oraz materiałów opisujących budowę własnej serwerowni. Znajdują się tam bardziej praktyczne informacje dotyczące:
wyboru sprzętu,
zasilania,
chłodzenia,
konfiguracji sieci,
magazynów danych,
redundancji i backupów.

• Wybór oprogramowania: test kompetencji i doświadczenia.
Fakty:
    Dobór oprogramowania serwerowego zależy od doświadczenia administratora, charakteru usług oraz kompromisu między prostotą i elastycznością konfiguracji.
Komentarz:
    Nie ma jednej poprawnej odpowiedzi na pytanie: „jakie oprogramowanie wybrać?”. To jeden z najtrudniejszych elementów budowy własnego środowiska.
    Dobrym przykładem jest odwieczna dyskusja Apache kontra Nginx. Oba rozwiązania realizują dokładnie to samo zadanie – obsługę stron WWW – ale robią to w zupełnie inny sposób.
    Jedni administratorzy uwielbiają Apache za ogromną elastyczność konfiguracji. Inni wskazują wydajność i prostotę Nginxa. Jeszcze inni proponują rozwiązanie kompromisowe: Nginx jako szybkie proxy na pierwszej linii, a Apache jako backend obsługujący właściwe aplikacje. I każda z tych grup ma rację – wszystko zależy od konkretnego zastosowania.
    Jeśli miałbym dać jedną praktyczną radę, byłaby ona bardzo prosta: nie wybieraj oprogramowania ani zbyt prostego, ani przesadnie skomplikowanego.
    Zbyt proste rozwiązania często wykonują wiele operacji poza kontrolą administratora albo ograniczają możliwości konfiguracji. Zbyt skomplikowane tworzą natomiast sztuczne bariery i wymagają ogromnego nakładu pracy administracyjnej.
    Pamiętam sytuację sprzed ponad 20 lat, gdy przez kilka lat próbowałem skonfigurować DNS i DHCP przy użyciu pewnego programu. Próby były regularnie ponawiane i problem nie wynikał z braku wiedzy. Po prostu konfiguracja była nieintuicyjna i bardzo trudna. W końcu przesiadłem się na inne rozwiązanie – i wszystko uruchomiło się dosłownie w kilka minut. To doświadczenie nauczyło mnie, że czasem warto zmienić narzędzie zamiast bez końca walczyć z jego ograniczeniami.

• Dlaczego nie wirtualizacja?
Fakty:
    Zastosowanie jednego komputera z 32–128 rdzeniami jest pozornie prostsze. Uruchamiamy pakiet wirtualizujący, kilka maszyn na tej platformie, całość wygląda i działa zachęcająco. Rozwiązanie zajmuje mniej miejsca, wymaga mniejszej liczby kabli, a zarządzanie jest wygodne i scentralizowane.
    W takim modelu wiele maszyn wirtualnych współdzieli te same zasoby sprzętowe: pamięć operacyjną, dyski oraz interfejsy sieciowe. W dużych serwerowniach problem ten rozwiązuje się między innymi poprzez stosowanie szybkich kart sieciowych (10 Gb/s i więcej), wydajnych macierzy dyskowych oraz serwerów wyposażonych w dużą liczbę rdzeni procesora.
    Istotną cechą takiej architektury jest również to, że awaria pojedynczego serwera fizycznego wpływa jednocześnie na wszystkie maszyny wirtualne uruchomione na tym hoście.
Komentarz autora:
    Moim zdaniem przy projektowaniu infrastruktury warto zwracać uwagę nie tylko na parametry widoczne na pierwszy rzut oka, ale również na elementy brzegowe i współdzielone zasoby. Jedna pamięć, jeden zestaw dysków czy jedna pula interfejsów sieciowych może stać się ograniczeniem, jeśli wiele usług pracuje intensywnie jednocześnie.
    Dla przykładu: nawet podwójne łącze 10 Gb/s zapewnia łącznie 20 Gb/s przepustowości. W przypadku serwera wyposażonego w 32 rdzenie oznacza to średnio około 0,625 Gb/s przepustowości przypadającej na rdzeń. Nie jest to oczywiście rzeczywisty podział ruchu sieciowego, ale dobrze pokazuje skalę współdzielenia zasobów przez wiele usług działających jednocześnie.
    Jeszcze ciekawiej wygląda sytuacja w przypadku storage. Nie chodzi wyłącznie o przepustowość dysków czy liczbę nośników, ale również o liczbę równoczesnych operacji zapisu wykonywanych przez wiele maszyn wirtualnych. W praktyce oznacza to konieczność analizowania nie tylko wydajności nominalnej, ale także rzeczywistych obciążeń oraz potencjalnych wąskich gardeł.
    W mojej ocenie właśnie takie elementy należy liczyć i analizować podczas projektowania infrastruktury. Parametry procesora, ilość pamięci czy szybkość interfejsów są ważne, jednak równie istotne jest zrozumienie, co stanie się w przypadku awarii lub przeciążenia pojedynczego współdzielonego elementu.
    Dla mnie i mojej serwerowni decydującym argumentem była niezawodność. „Wypadnięcie” jednego komputera ma niewielki wpływ na działanie całego systemu. Z tego powodu świadomie wybrałem architekturę opartą na wielu niezależnych serwerach fizycznych zamiast maksymalnej koncentracji usług na pojedynczej platformie wirtualizacyjnej.


IX. Podsumowanie: Miejsce w świecie

Fakty:
    Projekt zjk.pl rozwijany jest niezależnie od korporacyjnych platform społecznościowych, usług chmurowych oraz systemów telemetrycznych. Infrastrukturę od ponad dwóch dekad stanowią własne rozwiązania sprzętowe i programowe oparte głównie o FreeBSD.
Komentarz:
    Wycofanie się z globalnych projektów telemetrycznych czy zamkniętych społeczności internetowych było w przypadku zjk.pl decyzją całkowicie świadomą. Serwerownia nie powstała dla statystyk, internetowych rankingów czy popularności w mediach społecznościowych. Jej celem od początku była przede wszystkim praktyczna inżynieria, niezależność technologiczna oraz budowa własnego środowiska działającego według własnych zasad.
    W praktyce oznacza to między innymi rezygnację z uzależniania infrastruktury od zewnętrznych usług chmurowych, reklam, mechanizmów śledzących czy gotowych platform narzucających sposób działania całego systemu. Zamiast tego rozwijane są własne rozwiązania sieciowe, storage, backupu i monitoringu, utrzymywane lokalnie oraz dostosowywane do rzeczywistych potrzeb serwerowni.
    W świecie coraz silniej zdominowanym przez korporacyjne chmury i scentralizowane usługi, zjk.pl pozostaje niezależną wyspą techniczną — rozwijaną konsekwentnie od ponad dwóch dekad, opartą o własne rozwiązania sprzętowe, własne podejście do bezpieczeństwa oraz sprawdzone przez lata FreeBSD.

• Kontekst: Odcięcie się od „dziwnych” statystyk i zamkniętych społeczności.
Fakty:
    Projekt zjk.pl nie jest rozwijany dla statystyk popularności ani zamkniętych społeczności internetowych. Priorytetem pozostaje praktyczna użyteczność i niezależność infrastruktury.
Komentarz:
    Moje serwery nie pracują dla statystyk. Próbowałem kiedyś raportować systemy do projektu bsdstats, jednak liczba widocznych maszyn nigdy nawet w przybliżeniu nie odpowiadała rzeczywistości. A przecież już sam opis tej serwerowni pokazuje, że środowisko obejmuje znacznie więcej niż kilka komputerów. W pewnym momencie człowiek zaczyna więc zadawać sobie pytanie, jaki faktycznie sens mają takie zestawienia.
    Podobnie patrzę na zamknięte społeczności budowane wokół konkretnych technologii czy marek. Typu: „mam Forda – robimy własną grupę i wpuszczamy tylko wybranych”. Oczywiście – jeśli ktoś lubi, nie ma w tym nic złego. Jednak dla mnie serwery są przede wszystkim narzędziem. System ma działać dobrze, stabilnie i niezależnie od tego, kto aktualnie tworzy modną grupę dyskusyjną.
    Znacznie większą wartość mają ogólnodostępne fora i otwarta wymiana wiedzy. Jeśli zaczynamy zamykać wiedzę wyłącznie wewnątrz prywatnych społeczności, to coś przestaje działać tak, jak powinno.

• Czy całość nie jest zbyt złożona?
Fakty:
    Środowisko zjk.pl posiada wysoki poziom złożoności logicznej, jednak dzięki lekkiej architekturze bare-metal utrzymuje bardzo niskie obciążenie zasobów sprzętowych.
Komentarz:
    I tak, i nie.
    Poszczególne konfiguracje rzeczywiście są złożone. Jednak większość usług działa praktycznie bez ciężkiej warstwy pośredniej – bez rozbudowanej wirtualizacji czy ogromnych platform orkiestracyjnych. To w dużej mierze środowisko bare-metal, dzięki czemu obciążenie maszyn pozostaje bardzo niskie.
    Kilka procent użycia procesora, niewielka kolejka systemowa czy praktycznie pusty swap – to nie są parametry budzące niepokój. Najbardziej obciążona pozostaje sieć i to właśnie ona będzie prawdopodobnie jednym z pierwszych kierunków dalszej modernizacji.
    Jednocześnie podział ról pomiędzy serwerami jest bardzo świadomy. Nie ma przypadkowości:
serwer plików pełni rolę magazynu danych,
serwer WWW obsługuje strony,
klastry bazodanowe realizują zadania baz danych,
systemy cache odpowiadają za przyspieszanie usług,
ale serwer plików nie jest jednocześnie serwerem www, ani serwerem pocztowym.
    Oczywiście pewnie przydałoby się więcej maszyn. Ale sztuką nie jest budowanie infrastruktury przy nieograniczonych zasobach. Sztuką jest sensowne wykorzystanie tego, co się posiada.

X. Wniosek: zjk.pl jako niezależna wyspa techniczna.

Fakty:
    Projekt zjk.pl pozostaje niezależną, autorską infrastrukturą rozwijaną poza dominującym modelem pełnej wirtualizacji i usług chmurowych.
Komentarz:
    zjk.pl pozostanie niezależnym portalem i serwerownią. Zarówno koncepcja sprzętowa, jak i filozofia oprogramowania będą dalej rozwijane w obecnym kierunku.
    Doskonale wiem, że jest to podejście odmienne od współczesnych trendów opartych niemal wyłącznie o wirtualizację i publiczne chmury. Jednocześnie właśnie dlatego projekt ten ma dla mnie dużą wartość – pokazuje, że podobne cele można osiągnąć również innymi metodami.
    Niektóre technologie po prostu dobrze się starzeją. Z biegiem lat nie tracą wartości, lecz nabierają dojrzałości i stabilności. Trzeba jedynie umieć wykorzystać ich mocne strony i świadomie zaakceptować ich ograniczenia.
    zjk.pl pozostaje więc alternatywą, punktem odniesienia i praktycznym dowodem, że klasyczne podejście do budowy infrastruktury nadal może być skuteczne.

• Zakończenie: Gotowość na 25-lecie.
Fakty:
    Projekt zjk.pl wchodzi w 25. rok publicznej obecności infrastruktury w Internecie.
Komentarz:
    Pomysł na opis 25-lecia pojawił się dość niespodziewanie. Poprosiłem kiedyś AI o analizę zawartości strony. Po zakończeniu odpowiedzi pojawiło się krótkie zdanie: „gratuluję rocznicy – jak na serwery to wyjątkowy wiek”.
    „Skąd wiesz?” – zapytałem.
    Odpowiedź była prosta: „informacja znajduje się w nagłówku strony”.
    I właściwie od tego wszystko się zaczęło.
    Co ciekawe – same serwery faktycznie przekroczyły już ćwierć wieku pracy. Rok 2027 będzie raczej symbolicznym świętowaniem 25 lat pełnego wyjścia „na świat” z fizycznym dostępem do Internetu.
    Nie będzie wielkich obchodów. Wystarczy, jeśli śladem po tych latach pozostanie strona, którą właśnie czytasz.

• Plany.
Fakty:
    Infrastruktura zjk.pl jest stale rozwijana i modernizowana.
Komentarz:
    Planów nadal jest bardzo dużo:
wymiana serwerów OPNsense na nowsze jednostki,
modernizacja sieci do 2,5 Gb/s lub 10 Gb/s,
dalszy rozwój infrastruktury zasilania 12 V,
wdrożenie elektronicznych dystrybutorów zasilania z pomiarem napięć, prądów i mocy,
dalsze eksperymenty z pełnym zasilaniem DC,
szybsze łącza dostępowe do Internetu,
porządkowanie usług i podziału zasobów,
rozbudowa archiwów dyskowych,
możliwy powrót do poudriere,
dalsze rozwijanie własnych skryptów administracyjnych.
    Bo w praktyce każda dobrze działająca serwerownia zawsze znajduje się „w trakcie następnej modernizacji”.
Powrót na stronę główną - Informacje o stronie, prawa autorskie, legalność itd. tutaj
Informacje o przetwarzaniu i ochronie danych osobowych, kontakt i zapytania itd. tutaj
Prywatne serwery Zbigniewa Kuleszy zjk.pl. Aktualny dostawca Internetu - Vectra.pl, Wszelkie prawa zastrzeżone. Zespół redakcyjny zjk.pl: zjk7@wp.pl
W sprawie treści i działania strony oraz w sprawie funkcjonowania i udostępniania treści na serwerach zjk.pl - kontakt z administratorem: webmaster@zjk.pl lub zjk7@wp.pl

Valid HTML 4.01 Transitional Valid XHTML 1.0 Transitional Poprawny CSS! Poprawny CSS!

Copyright (c): Zbigniew Kulesza, Sieradz 2002-2026