**
****
**

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óworaz 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”.