Infrastruktura serwerów Zbigniew Kulesza zjk.pl

Serdecznie witam na moich prywatnych, domowych serwerach FreeBSD/UNIX, Sieradz. Polska

Dzisiaj jest: 2026-07-10   Aktualizacja dnia: [an error occurred while processing this directive]

[English]



UWAGA - wszelkie parametry podane na tej stronie to NIE s± fikcj±, symulacj± teoretyczn±, tworzeniem idealnych scenariuszy. Jest to absolutnie REALNY stan, z którego korzystasz czytaj±c te s³owa.
Natomiast zosta³y wprowadzone elementy anonimizuj±ce ze wzglêdów bezpieczeñstwa.
Je¶li w±tpisz w prawdziwo¶æ podanych danych to zapewniam, ¿e zwykle zani¿a³em podane liczby.
Natomiast - ze wzglêdu na ci±g³e prace rozwojowe - w niektórych elementach mog± wystêpowaæ ró¿nice stopnia wdro¿enia (zwykle czekam kilka miesiêcy na sprawdzenie, czy dana technologia sprawuje siê stabilnie).
Niektóre elementy konfiguracji s± wycofywane - w razie w±tpliwo¶ci pytaj mailem o stan aktualny, poniewa¿ strona internetowa ma dla mnie tylko znaczenie ilustracyjne, nie ¶ci¶le dokumentacyjne. Jednocze¶nie konkretne parametry sprzêtu i wydarzenia opisane w historii ju¿ maj± warto¶æ dokumentacji.
Rysunki zosta³y wykonane samodzielnie b±d¼ z udzia³em ChatGPT oraz Microsoft Copilot. Teksty by³y pisane oryginalnie przez mnie z "wyg³adzeniem" przez CharGPT. T³umaczenia wykonane z u¿yciem ChatGPT.
Je¶li znajdziesz b³êdy jêzykowe czy merytoryczne - proszê zg³o¶ i wybacz mi niedopatrzenie, naprawdê i tak wiele czasu mam zajête utrzymaniem mojej serwerowni i nie tylko ;P

Spis tre¶ci: A. Filozofia projektu: B. Parametry infrastruktury: C. Architektura infrastruktury D. Infrastruktura sk³ada siê z nastêpuj±cych warstw: D.1 Warstwa brzegowa (Edge Layer) - komunikacja ze ¶wiatem D.1.1 Opis brzegowy: D.2 Warstwa sieciowa (Network Layer) - czysta infrastruktura transportowa D.2.1 Opis sieci: D.3 Warstwa us³ug i aplikacji (Service Layer) - oferowane funkcjonalno¶ci / us³ugi D.3.1 Opis poczty: D.3.2 Opis klastra WWW: D.3.3 Opis DNS: D.4 Warstwa storage i danych (Storage & Data Layer) - przechowywanie danych i backend D.4.1 Opis ZFS: D.4.2 Opis klastra Moosefs: D.4.3 Opis klastra Seaweed: D.4.4 Opis baz danych: D.4.5 Opis backupu: D.5 Warstwa u¿ytkowników i klientów (Client Layer) - kto korzysta z infrastruktury D.6 Warstwa systemów pomocniczych i operacyjnych (Operations Layer) - zwykle nie pokazuj± tego homelaby, jest w zjk.pl D.7 Warstwa zasilania i niezawodno¶ci (Power & Reliability Layer) - w zjk.pl zas³uguje na w³asn± warstwê D.7.1 Opis warstwy zasilania: D.8 Podsumowanie: wyró¿niaj±ce technologie i bezpieczeñstwo

A. Filozofia projektu:

Czy da siê zbudowaæ profesjonalne Datacenter bez korporacyjnej chmury?

W dzisiejszych czasach sieæ jest zdominowana przez wielkie korporacje, reklamy i skrypty ¶ledz±ce. Internet mo¿e jednak wygl±daæ inaczej. Od 24 lat rozwijana jest w pe³ni niezale¿na, prywatna infrastruktura serwerowa zjk.pl, która stanowi dowód na to, ¿e wolny i bezpieczny cyfrowy ¶wiat wci±¿ istnieje. To nie jest zwyk³y komputer stoj±cy w k±cie, ale zaawansowany ekosystem oparty na systemie FreeBSD.

Dla osób szukaj±cych inspiracji, studentów informatyki czy pasjonatów technologii, strona ta stanowi praktyczne studium przypadku. Przedstawia ona, jak w realnym ¶rodowisku funkcjonuj± rozwi±zania klasy Enterprise:

Fundamenty i bezpieczeñstwo: Implementacja najwy¿szych standardów bezpieczeñstwa stron (HTTP/3, rygorystyczne nag³ówki SSL/TLS), niezale¿ny i odporny na spam system pocztowy oraz aplikacje odizolowane w bezpiecznych kontenerach (Jails).
Wysoka dostêpno¶æ (HA): Architektura klastrowa oparta na protokole CARP oraz load balancerze HAProxy, eliminuj±ca przerwy w dzia³aniu us³ug w przypadku awarii sprzêtu.
Zarz±dzanie pamiêci± masow±: Skalowalna i bezpieczna przestrzeñ na dane zrealizowana za pomoc± systemu plików ZFS oraz rozproszonych systemów MooseFS i obiektowego SeaweedFS.

Poni¿szy opis to unikalny zapis drogi – od pojedynczego serwera do rozproszonej architektury. To techniczna dokumentacja tego, jak nowoczesna sztuka UNIX-owa funkcjonuje w praktyce.

B. Parametry infrastruktury:

• dostêpno¶æ us³ug 24/7/365, pe³ne zasilanie awaryjne (UPS)
  
• redundancja wybranych us³ug i komponentów infrastruktury,
• OPNsense HA (master/slave + CARP),
• dwa niezale¿ne ³±cza ISP,
• LACP/LAGG dla kluczowych po³±czeñ sieciowych,
• serwery fizyczne i wirtualne,
• storage, backup i monitoring,
• systematyczne aktualizacje sprzêtu i oprogramowania (tryb ci±g³y, restarty po istotnych aktualizacjach bez wzglêdu na uptime),
• mo¿liwo¶æ hostowania w³asnych domen i us³ug.

Powy¿szy schemat i opis poni¿ej maj± charakter pogl±dowy (ze wzglêdów bezpieczeñstwa).

C. Architektura infrastruktury

Poni¿sze schematy i opisy maj± charakter pogl±dowy ze wzglêdów bezpieczeñstwa.

Stabilna sieæ i rozproszona przestrzeñ: Architektura odporna na awarie

Prawdziwa in¿ynieria zaczyna siê tam, gdzie koñczy siê pojedynczy dysk i jeden serwer. Budowa niezawodnego ¶rodowiska wymaga skutecznego zarz±dzania rosn±cym wolumenem danych, spiêcia dwóch niezale¿nych ISP oraz zapewnienia ci±g³o¶ci dzia³ania us³ug, nawet w przypadku awarii fizycznej maszyny.

Ten rozdzia³ to szczegó³owy opis topologii i struktury zjk.pl. Przedstawia on architekturê pozbawion± pojedynczych punktów awarii (SPOF), w której warstwa sieciowa opiera siê na firewallach OPNsense HA (CARP) oraz agregacji ³±cz LACP/LAGG. Kluczowym elementem tej konfiguracji jest wysoce skalowalna pamiêæ masowa, zrealizowana w oparciu o systemy MooseFS oraz obiektowy SeaweedFS. Poni¿szy materia³ dokumentuje, jak te zaawansowane rozwi±zania magazynowania danych i replikacji funkcjonuj± w codziennej praktyce produkcyjnej klastra.


Opis ekosystemu serwerowni zjk.pl: "ekosystem", jak zjk.pl dzia³a jako ca³o¶æ z podkre¶leniem najwa¿niejszych technologii.

D. Infrastruktura sk³ada siê z nastêpuj±cych warstw:

D.1 Warstwa brzegowa (Edge Layer) - komunikacja ze ¶wiatem

• OPNsense HA (master/slave),
• CARP failover,
• dwa niezale¿ne ³±cza ISP,
• routing i automatyczne prze³±czanie awaryjne,
• firewall / NAT / filtrowanie,
• HAProxy / reverse proxy,
• TLS termination,
• HTTP/3 / QUIC.

D.1.1 Opis brzegowy:

a. warstwa sk³ada siê z dwóch modemów ró¿nych dostawców Internetowych,
b. dwóch komputerów z OPNsense - z w³±czonym CARP i tryblem Master-Slave. Schemat ilustruje ten system: 2 modemy Vectra i Netia, 2 x OPNsense,
c. ale obejmuje warstwê nastêpn± - sieci: dwa switche zarz±dzalny i zwyk³y oraz punkt WiFi.

D.2 Warstwa sieciowa (Network Layer) - czysta infrastruktura transportowa

• switch zarz±dzalny,
• switch zapasowy / fallback,
• LACP / LAGG,
• VLAN / segmentacja sieci,
• trunki i agregacja,
• punkt dostêpowy WiFi,
• sieæ LAN.

D.2.1 Opis sieci:

a. LAGG/LACP ³±czy serwery ze switchem zarz±dzalnym 2x1Gb/s,
b. jednak w wybranych miejscach pojawia siê jeszcze LAGG w trybie failover oraz loadbalance.

D.3 Warstwa us³ug i aplikacji (Service Layer) - oferowane funkcjonalno¶ci / us³ugi

• rozproszone serwery WWW,
• poczta Sendmail, Dovecot,
• Nextcloud, Piwigo,
• WordPress,
• Jellyfin,
• Git / SVN / Forgejo,
• monitoring - m.in. Monitorix, Mrtg, Ganglia, Symon,
• logowanie / syslog,
• DNS,
• reverse proxy aplikacyjne,
• HA us³ug.

D.3.1 Opis poczty:

a. dwa serwery pocztowe mail.zjk.pl (mai1.zjk.pl) i mail2.zjk.pl, na obydwu pracuj± Sendmaile + wszelkie programy bezpieczeñstwa: rspamd, Mailscanner, spamassasin oraz fetchmail razem z mechanizmami: DKIM, SPF, openDMARC i kluczami LetsEncrypt.
b. na poziomie dostêpu klienckiego jest to dovecot z bardzo nowoczesnym mdbox (i ciekawostka: poczta dzia³a na montowanym z Moosefs /usr/home z oddzielnym katalogiem szybkich lokalnych indeksów).

D.3.2 Opis klastra WWW:

Podajê opis przep³ywu danych:
a. dane przychodz± na OPNsense,
b. stamt±d HAproxy kieruje je metod± Round-Robin ze sticky connections do
c. 4 serwerów www (sprawdzaj±c, który aktualnie jest dostêpny),
d. 4 serwery korzystaj± z katalogów udostêpnionych na MooseFS (1 serwer jeden katalog )
e. lub (tryb testowy/rezerwowy) 4 SeaweedFS (tam podobnie: 1 katalog 1 filler),
f. cache - lokalne przy ka¿dym serwerze: opcache i modu³ apache memory/diskcache,
g. oraz redis - redis jest skomplikowany, to jest 6 maszyn z jedn± wybran± na master przez 6 sentineli - synchronizacja dzia³ania odbywa siê przez HAproxy na OPNsense i z wybranego mastera korzystaj± serwery www,
h. OPNsense dodaje protokó³ HTTP/3 (w testach) na swoim wyj¶ciu na protokole UDP,
i. wyja¶nienie - katalogi zarówno MooseFS jak SeaweedFS - to tak naprawdê jeden katalog MooseFS montowany na ka¿dym serwerze www i podobnie SeaweedFS - katalog jest jeden, ale s± 4 oddzielne cache przechowuj±ce kopie tego katalogu na ka¿dym komputerze oddzielnie.

D.3.3 Opis DNS:

a. DNS zewnêtrzny: 3 dostawców home.pl seohost.pl porkbun.com - wpisy nie tylko standard, ale SPF, DKIM, DMARC itp - dla kilku domen obs³ugiwanych przez serwery zjk.pl,
b. DNS wewnêtrzny BIND9: 4 maszyny: jedna master + 3 slave, opisuj±ce pe³ny schemat wewnêtrznej struktury serwerowni zjk.pl.

D.4 Warstwa storage i danych (Storage & Data Layer) - przechowywanie danych i backend

• ZFS + RAID ZFS,
• MooseFS,
• SeaweedFS,
• PostgreSQL cluster,
• MySQL cluster,
• backup,
• repliki danych,
• object storage,
• snapshoty i backup,

D.4.1 Opis ZFS:

System plików obecny g³ównie na dyskach magazynach danych (czyli MooseFS korzysta z dysków ZFS, tak¿e wszystkie dyski archiwów, backupu), w jeden pool typu raidz2-0 – odpowiednik RAID 6 (toleruje awariê 2 dysków).
Dyski systemowe z drobnymi wyj±tkami (na ZFS) to UFS2.

D.4.2 Opis klastra Moosefs:

a. 1 master - to wersja Community Edition,
b. ale 2 serwery mog± przej±c skryptem rolê mastera,
c. 12 chunkserwerów,
d. ok. 30 punktów montowania, w tym warto zaznaczyæ - montowanie dla serwerów katalogu /usr/home (co jest dosyæ trudn± spraw± do utrzymania), a punkty montowania to FreeBSD i Windows,
e. warto podkre¶liæ, ¿e istniej± klasy dysków HDD i SDD (potrójne) oraz specjalna klasa dla 4 dysków, które s³u¿± jako lokalne maszyny dostarczaj±ce pliki dla 4 serwerów www (do¶æ unikatowe).

D.4.3 Opis klastra Seaweed:

a. 3 mastery,
b. 7 fillerów,
c. synchronizowane na 4 ró¿nych portach oddzielnie w HAproxy w OPNsense,
d. 4 filery pracuj± na katalogi www, pozosta³e to punkty montowania z 2 i 3 krotno¶ci±, ale oddzielnie dla szybkich SSD i zwyk³ych HDD - uwaga - 3 g³ówne fillery maja po dwa dyski HDD i SSD, filery www maja dyski SSD, w sumie jest zatem 10 dysków,
e. SeaweedFS trzyma metadane w PostgreSQL - 3 oddzielne serwery, które pracuj± w trybie Hot Redundancy, jeden wybrany na mastera - wybór oraz transmisja danych bazy metadane odbywa siê przez HAproxy, które pracuje na OPNsense.

D.4.4 Opis baz danych:

a. PostgreSQL w trybie Hot Redundancy: 3 serwery z czego jeden wybrany na master, jego wybór odbywa siê poprzez HAproxy na OPNsense - z dostêpem do bazy danych przez wspólny port na OPNsense - ta baza danych przechowuje metadane SeaweedFS i m.in. dane z backupu Bareosa,
b. MySQL - 5 serwerów w trybie Cluster Replication, komunikuj± siê z OPNsense do wyboru jednego mastera i jednocze¶nie na OPNsense jest udostêpniony wspólny port dostêpu do danych. MySQL to g³ównie bazy danych dla www,
c. uwaga - bazy danych s± backupowane z pomoc± systemowych narzêdzi jako zrzuty z retencj± min. 15 dni.

D.4.5 Opis backupu:

a. ka¿dy z 8 serwerów ma dwa dyski: SSD g³ówny i HDD z lokalnymi dumpami (robione moim w³asnym skryptem - miesiêczne),
b. dane trafiaj± na wspólny dysk sieciowy (NFS nie MooseFS),
c. a z niego na dysk zewnêtrzny archiwum,
d. backupy Bareosa (klasyka codzienne, tydzieñ i miesi±c) na oddzielnych dyskach NFS,
e. Urbackup - oddzielny dysk nfs
e. dyski MooseFS i SeaweedFS trafiaj± na wspomniany zewnêtrzny dysk archiwum,
f. backupy /etc /usr/local/etc konfiguracji - etckeep (testowo).

D.5 Warstwa u¿ytkowników i klientów (Client Layer) - kto korzysta z infrastruktury

• komputery domowe,
• laptopy,
• urz±dzenia mobilne,
• urz±dzenia IoT,
• systemy testowe,
• urz±dzenia sieciowe u¿ytkowników,
• stacje robocze.

D.6 Warstwa systemów pomocniczych i operacyjnych (Operations Layer) - zwykle nie pokazuj± tego homelaby, jest w zjk.pl

• monitoring,
• alerting,
• log aggregation,
• backup orchestration,
• automatyzacja,
• skrypty HA,
• synchronizacja konfiguracji,
• dokumentacja infrastruktury.

D.7 Warstwa zasilania i niezawodno¶ci (Power & Reliability Layer) - w zjk.pl zas³uguje na w³asn± warstwê

• UPS #1,
• UPS #2,
• dystrybucja DC 12 V,
• bufor akumulatorowy,
• redundancja PSU,
• monitoring zasilania,
• OR-ing / Schottky,
• failover energetyczny,

D.7.1 Opis warstwy zasilania:

a. dwa UPS Fideltronik KI PRO 2000,
b. ich wyj¶ciu jest jeszcze podwójny prze³±cznik wykrywaj±cy zanik zasilania - czyli wybór linii zasilania jest kaskadowy, je¶li jeden UPS wy³±czy siê, przejmuje zasilanie drugi,
c. zasilanie trafia do dwóch linii - jedna jest g³ówna do zasilacza 660 W 80Platinum - daj±cego g³ówn± liniê zasilania 12 V do wszystkich serwerów,
d. serwery (wszystkie) maj± na pok³adzie zasilacze Picopsu (znajd¼ opis w Internecie),
e. drugi zasilacz mini-ITX 80Platinum generuje drug± liniê zasilania 12 V ,
f. obie linie 12 V za po¶rednictwem diod Schottkiego ³±cz± siê na linii zasilania serwerów i innych zasobów wra¿liwych, jak OPNsense, switch, WiFi itp - ¿eby zasilanie do nich zawsze by³o dostêpne,
g. trzeci zasilacz du¿ej mocy generuje 12 V, ale ju¿ tylko do komputerów u¿ytkowych - aby by³y odseparowane.

D.8 Podsumowanie: wyró¿niaj±ce technologie i bezpieczeñstwo

• FreeBSD,
• OPNsense,
• HAProxy,
• MooseFS,
• SeaweedFS,
• PostgreSQL HA,
• Mysql Cluster,
  
• Redis,
• HTTP/2 oraz HTTP/3,
• SPF / DKIM / DMARC,
• monitoring bezpieczeñstwa,
• systematyczne aktualizacje.

Nazwa historyczna:

Dawna nazwa "ciasteczkowy serwer" (nie myliæ ze wspó³czesnymi obudowami mini-ITX). Angielska nazwa subminiaturowych komputerów to "biscuit computer". Biscuit to po polsku herbatnik, sucharek (tak¿e ang. "rusk"). Jednocze¶nie mo¿na zauwa¿yæ, ¿e "ciasteczko" to raczej angielskie "cookie". Jednak po polsku "herbatnikowy serwer" albo "sucharkowy serwer" brzmi tak sobie... Dlatego ostatecznie zostawi³em "ciasteczkowy serwer". Wiêcej o tych niezwykle ma³ych. pobieraj±cych ma³o energii komputerkach w dziale "sprzêt". Zapraszam... UWAGA - dawne "ciasteczka" zosta³y zast±pione nowocze¶niejszymi konstrukcjami, ale równie¿ o bardzo niskim poborze mocy - opis tak¿e w dziale sprzêt.


£±cza internetowe

Infrastruktura wykorzystuje dwa niezale¿ne ³±cza operatorów dla zwiêkszenia dostêpno¶ci us³ug.

1. Aktualny dostawca Internetu - Vectra oddzia³ Sieradz - ³±cze Vectra biznes
(od 18.VI.2021r.): 600/60 Mb/s (czyli 75 MB/s i 7,5 MB/s)
IP: 88.156.77.167 dawniej 232
2. Drugie ³±cze: Netia na BSA Orange, ¶wiat³owód
(od 11.V.2021): 1000/300 Mb/s (czyli 125 MB/s i 37,5 MB/s) - promocja Netia
IP: 83.238.166.222

Serwer posiada rejestracjê nazwy w NASK, aktualnie home.pl - oficjalnie: zjk.pl

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