FreeBSD i ZFS dla WordPressa – wydajność, bezpieczeństwo i praktyczne korzyści

Praktyczne porównanie FreeBSD z ZFS i Linuksa jako platformy hostingowej dla WordPressa. Analizujemy różnice w stosie sieciowym (kqueue vs epoll), optymalizację MySQL/MariaDB na ZFS, mechanizmy migawek i rollbacku, izolację usług w Jails z VNET i RCTL oraz realne ograniczenia ekosystemu FreeBSD.

WordPress napędza ogromną część internetu, od małych blogów po rozbudowane sklepy i serwisy korporacyjne. Niemal wszystkie działają na Linuksie: stos LAMP (Linux, Apache, MySQL, PHP) albo LEMP (z Nginxem), coraz częściej z Dockerem na pokładzie. Działa to dobrze i jest sprawdzonym standardem. Warto jednak wiedzieć, że nie jedynym.

FreeBSD z systemem plików ZFS to alternatywa, o której rzadko się mówi. Inne jądro, inny model izolacji, inny system plików, a przy odpowiedniej konfiguracji konkretne przewagi w wydajności i bezpieczeństwie. Benchmarki CIS (Center for Internet Security) dla FreeBSD 14 potwierdzają, że prawidłowo utwardzony system zapewnia znakomitą wydajność sieciową i silne mechanizmy obronne. Pytanie brzmi: czy to się opłaca i dla kogo?

Stos sieciowy: kqueue kontra epoll

Dla CMSa takiego jak WordPress szybkość serwowania treści ma kluczowe znaczenie. WordPress generuje HTML dynamicznie przez PHP, ale jednocześnie serwer musi obsłużyć mnóstwo żądań statycznych: obrazy, CSS, JavaScript. Tu liczy się to, jak jądro systemu radzi sobie z obsługą wejścia/wyjścia przy dużej liczbie jednoczesnych połączeń.

Linux używa do tego mechanizmu epoll. FreeBSD ma kqueue, i w tym obszarze różnica jest wyraźna.

Oba mechanizmy działają w czasie O(1), więc samo skalowanie zdarzeń jest porównywalne. Przewaga kqueue polega na czymś innym: oferuje ujednolicony interfejs API do obsługi zdarzeń z różnych źródeł, takich jak deskryptory plików, sygnały czy zmiany w systemie plików. Można też zgłosić wiele aktualizacji w ramach jednego wywołania systemowego. Epoll tego nie potrafi, bo tam każda zmiana to osobne wywołanie epoll_ctl(). W praktyce, przy dziesiątkach tysięcy jednoczesnych połączeń (klasyczny problem C10K), kqueue generuje mniejszy narzut na procesor.

Warto wspomnieć jeszcze o jednym: epoll nie radzi sobie z powiadamianiem o zmianach w zwykłych plikach dyskowych i wymaga, żeby dane były już w pamięci podręcznej. kqueue nie ma tego ograniczenia.

Porównanie serwerów WWW na FreeBSD

Wybór serwera WWW decyduje o tym, czy w ogóle uda się wykorzystać potencjał sieciowy FreeBSD.

Szczególnie ciekawa jest współpraca Nginxa z FreeBSD w kontekście tzw. zero-copy. Dzięki wywołaniu sendfile z flagą SF_NODISKIO serwer potrafi strumieniować dane z pamięci podręcznej ZFS (ARC) bezpośrednio do gniazda sieciowego, z pominięciem przestrzeni użytkownika. To drastycznie zmniejsza obciążenie procesora i ma duże znaczenie np. dla sklepów WooCommerce, które muszą przetrwać nagłe szczyty ruchu.

FreeBSD oferuje też filtry akceptacji jądra (np. accf_http). Pozwalają one wstrzymać budzenie procesu serwera WWW do momentu, aż klient prześle kompletne żądanie HTTP. Mniej zbędnych przełączeń kontekstu, większa stabilność pod obciążeniem.

PHP na FreeBSD: bez rewolucji

Jeśli chodzi o surową wydajność PHP, różnice między FreeBSD a dobrze zoptymalizowanym Linuksem są niewielkie, rzędu 1–3% w testach syntetycznych. Rewolucji tu nie ma.

Ciekawiej robi się głębiej. Testy na procesorach AMD Threadripper pokazały, że FreeBSD znacznie lepiej radzi sobie z wielowątkowością na poziomie jądra. Operacje na semaforach wykonuje nawet dwukrotnie szybciej, a przełączanie kontekstu bywa do 15 razy szybsze niż na Linuksie. Tyle że w typowym środowisku WordPress ta przewaga jest w dużej mierze maskowana przez sam charakter przetwarzania PHP.

Dlatego kluczowe staje się dobre dostrojenie PHP-FPM. Ustawienie profilu pm = ondemand zamiast domyślnego dynamic pozwala uniknąć alokowania niepotrzebnych procesów i ograniczyć marnowanie pamięci RAM.

Optymalizacja MySQL/MariaDB na ZFS

Baza danych to najczęstsze wąskie gardło każdej instalacji WordPressa. Na Linuksie, przy tradycyjnych systemach plików (ext4, XFS) na sprzętowym RAID-zie, administrator musi pilnować synchronizacji rozmiarów bloków, żeby uniknąć amplifikacji zapisu. To dodatkowa warstwa złożoności.

ZFS podchodzi do tego zupełnie inaczej dzięki mechanizmowi Copy-on-Write (CoW). Aktualizacja rekordu nie nadpisuje starych danych. System zapisuje nowe informacje w wolnych sektorach i atomowo aktualizuje wskaźniki. Zapis jest kompletny albo wcale się nie odbywa. Nie ma stanów pośrednich, nie ma uszkodzonych stron.

Żeby jednak w pełni to wykorzystać, trzeba wyłączyć w MySQL/MariaDB kilka funkcji, które ZFS realizuje lepiej na własnym poziomie:

Co to daje w praktyce? Testy na infrastrukturze AWS EBS (prezentowane m.in. przez Percona) wykazały, że tak dostrojony MySQL na ZFS skraca łączny czas wykonywania zapytań o ok. 22% w porównaniu z ext4 na RAID10. Największy zysk widać przy operacjach DELETE (ok. 40% szybciej) i INSERT (ok. 15%).

Warto dodać kwestię kompresji. Zamiast używać wbudowanej kompresji MySQL, lepiej włączyć natywny algorytm LZ4 na poziomie ZFS (compression=lz4). Współczesne procesory dekompresują strumień LZ4 praktycznie bez narzutu, a efekt to podwojenie prędkości odczytów i redukcja zajmowanego miejsca na dysku nawet o 50%. Przy cenach za storage w chmurze to realna oszczędność.

Trzeba uczciwie powiedzieć, że nowsze testy Percona z 2021 r. pokazują, iż gap wydajnościowy między ZFS a ext4 się zmniejszył. Przy dobrym strojeniu obu stron wyniki bywają porównywalne. Przewaga ZFS leży dziś bardziej w dodatkowych funkcjach (kompresja, snapshoty, integralność danych) niż w surowej prędkości.

Migawki, klony i zakładki: zarządzanie danymi na ZFS

Tradycyjne tworzenie kopii zapasowych WordPressa – nawet z narzędziami typu Duplicator czy WP Staging – opiera się na eksporcie bazy danych i plików, który trwa minuty lub dłużej. W tym czasie użytkownicy mogą modyfikować dane, co grozi niespójną kopią. ZFS rozwiązuje ten problem na poziomie systemu plików.

Migawki (Snapshots)

Polecenie zfs snapshot przechwytuje dokładny stan całego systemu plików. Trwa to ułamek sekundy i w momencie utworzenia nie zajmuje żadnego dodatkowego miejsca na dysku. Dopiero gdy dane zaczną się zmieniać, migawka zaczyna „rosnąć", zachowując stare bloki.

Co ważne, migawka jest niemutowalna (immutable). Nie da się jej zmodyfikować ani zaszyfrować, co czyni ją skuteczną obroną przed ransomware. Jeśli aktualizacja WordPressa pójdzie źle, jedno polecenie zfs rollback przywraca serwer do stanu sprzed awarii.

Klony

Testowanie zmian w środowisku preprodukcyjnym (staging) zwykle wymaga skopiowania całej bazy, często wielu gigabajtów danych. To trwa i marnuje dysk.

Klon ZFS to edytowalna kopia migawki, która na starcie nie zajmuje dodatkowego miejsca. Współdzieli bloki z oryginałem, a nowe miejsce jest alokowane tylko dla zmienionych danych. Można więc błyskawicznie postawić pełnowymiarowe środowisko testowe, przetestować destrukcyjną migrację albo nową wersję wtyczki, a potem po prostu usunąć klon.

Zakładki (Bookmarks)

Przy replikacji migawek do zewnętrznej serwerowni pojawia się problem: na serwerze głównym gromadzą się stare migawki, których nie można usunąć, bo zależą od nich łańcuchy replikacyjne.

Zakładki ZFS rozwiązują to sprytnie. Nie rezerwują miejsca na dane, a jedynie zapisują wskaźniki (identyfikatory GUID i numery logów transakcji). Dzięki temu można usunąć ciężkie, przestarzałe migawki na serwerze głównym, jednocześnie kontynuując przyrostową replikację do zapasowej lokalizacji.

FreeBSD Jails: izolacja zamiast konteneryzacji

WordPress pada ofiarą ataków najczęściej przez dziurawe wtyczki, nie przez luki w rdzeniu. Typowy scenariusz: napastnik uzyskuje zdalne wykonanie kodu (RCE) przez zaniedbany plugin. W tym momencie liczy się to, czy infrastruktura potrafi skutecznie odizolować intruza.

Na Linuksie standardem jest Docker albo Podman, opcjonalnie z orkiestracją Kubernetes. Te narzędzia działają w przestrzeni użytkownika i wprowadzają własną warstwę złożoności, a czasem i własne podatności.

FreeBSD podchodzi do tego inaczej. Jails to wirtualizacja na poziomie jądra systemu (OS-level virtualization), koncepcyjnie bliższa chroot na sterydach niż kontenerom w dockerowym sensie. Jail zachowuje się jak zamknięty, autonomiczny system, ale jest izolowany bezpośrednio przez jądro hosta.

Jak działa izolacja w Jails

Nawet jeśli napastnik przejmie uprawnienia root wewnątrz Jaila, jądro FreeBSD automatycznie blokuje mu m.in.:

• Dynamiczne ładowanie modułów systemowych.
• Bezpośredni dostęp do sprzętu i surowych gniazd komunikacyjnych.
• Wywołania systemowe modyfikujące ustawienia globalne maszyny.

To nie jest kwestia konfiguracji. Te ograniczenia są wpisane w jądro. Administrator Jaila to po prostu nie jest ten sam root co na hoście.

Zarządzanie Jailami można zautomatyzować frameworkami takimi jak BastilleBSD, co eliminuje potrzebę stosowania ciężkich narzędzi w stylu Kubernetes. Jails natywnie współpracują z ZFS, więc tworzenie nowego Jaila ze snapshota to kwestia sekund.

Segmentacja sieci: VNET

Każdy Jail może mieć przydzielony własny, w pełni odizolowany stos sieciowy dzięki mechanizmowi VNET. Oznacza to osobne tablice routingu, osobny interfejs pętli zwrotnej, osobna zapora ogniowa (pf lub ipfw). Nawet gdyby atakujący przełamał izolację samego Jaila, musiałby jeszcze sforsować wirtualną topologię sieciową, żeby dotrzeć do hosta.

Zarządzanie zasobami: RCTL i RACCT

W hostingu współdzielonym regularnie pojawia się problem „głośnego sąsiada". Jeden sklep WooCommerce z niewydajnymi zapytaniami SQL potrafi sparaliżować działanie wszystkich pozostałych stron na serwerze.

FreeBSD ma na to framework RACCT/RCTL. Po włączeniu w konfiguracji jądra (kern.racct.enable=1) administrator może nakładać precyzyjne limity zasobów na poszczególne Jaile w czasie rzeczywistym, bez restartowania usług:

• Ograniczenie CPU do 80%: rctl -a jail:NAZWA:pcpu:deny=80
• Limit pamięci RAM na 1 GB: rctl -a jail:NAZWA:memoryuse:deny=1G

Plik konfiguracyjny /etc/rctl.conf można zabezpieczyć (chmod 600), żeby współdzieleni klienci nie mogli podejrzeć ustawionych limitów.

Linux ma oczywiście swój odpowiednik: cgroups (w wersji v2 ujednolicone i dojrzałe). Docker i systemd korzystają z nich automatycznie, co w praktyce oznacza, że na Linuksie limitowanie zasobów jest wbudowane w codzienne narzędzia i nie wymaga dodatkowej konfiguracji jądra. RCTL robi to samo, ale na niższym poziomie abstrakcji. Przewaga FreeBSD nie polega tu na samym mechanizmie limitowania, lecz na tym, że RCTL współpracuje bezpośrednio z Jailami i ZFS jako spójny, zintegrowany stos, bez potrzeby nakładania na siebie osobnych warstw (Docker + cgroups + overlay filesystem).

Dostawcy VPS z obsługą FreeBSD

FreeBSD to nisza wśród dostawców chmurowych i hostingu. Poniżej krótkie zestawienie sprawdzonych dostawców, u których konfigurujemy serwery FreeBSD pod WordPress i WooCommerce. Pomijamy popularnego Contabo – nasze testy wykazały niestabilność stosu sieciowego FreeBSD na ich platformie.

Wyzwania i ograniczenia

Artykuł byłby nieuczciwy bez omówienia tego, co sprawia, że FreeBSD mimo swoich zalet nie dominuje na rynku hostingowym.

Brak paneli zarządzania. cPanel, DirectAdmin i inne popularne panele hostingowe są projektowane pod Linuksa. Ich odpowiedniki dla FreeBSD albo nie istnieją, albo są słabo utrzymywane (np. Plesk zrezygnował z rozwijania swojego narzędzia dla FreeBSD). Obsługa FreeBSD opiera się głównie na terminalu i skryptach powłoki. Nie ma GUI do konfiguracji VNET czy zapory pf, wszystko robi się z konsoli.

Niedobór specjalistów. Rynek pracy jest zdominowany przez inżynierów znających Linuksa, Dockera i Kubernetes. Ludzi, którzy potrafią administrować FreeBSD na poziomie produkcyjnym, jest znacznie mniej. Dla agencji i korporacji budujących zespoły to poważna bariera.

Mniejszy ekosystem oprogramowania. Wiele popularnych narzędzi DevOps i monitoringu (Prometheus exporters, Ansible modules, Terraform providers) jest rozwijanych z myślą o Linuksie. Na FreeBSD część z nich wymaga dodatkowej konfiguracji, a niektóre po prostu nie działają. To samo dotyczy sterowników sprzętowych, szczególnie dla nowszych kart sieciowych i kontrolerów NVMe. Przed wyborem FreeBSD warto sprawdzić, czy cały planowany stos narzędziowy jest kompatybilny.

Podsumowanie

FreeBSD z ZFS to rozwiązanie, które w konkretnych scenariuszach oferuje realne przewagi nad standardowym stosem linuksowym.

Po pierwsze, wydajność bazy danych. ZFS z odpowiednio dostrojonym InnoDB skraca czas wykonywania zapytań, a natywna kompresja LZ4 pozwala zaoszczędzić do 50% miejsca na dysku bez uszczerbku na prędkości odczytu.

Po drugie, bezpieczeństwo. FreeBSD Jails z VNET tworzą izolację na poziomie jądra, znacznie głębszą niż standardowe kontenery. Nawet po przejęciu WordPressa atakujący pozostaje skutecznie odizolowany.

Po trzecie, zarządzanie danymi. Migawki ZFS, klony i zakładki przenoszą kopie zapasowe i środowiska stagingowe na zupełnie inny poziom: są błyskawiczne, spójne i odporne na ransomware.

Na rynku taniego hostingu współdzielonego FreeBSD nie znajdzie zastosowania – Linux z cPanelem i wyspecjalizowanymi dystrybucjami jak CloudLinux (z CageFS, LVE i MySQL Governor) jest tam po prostu łatwiejszy i tańszy w utrzymaniu. Natomiast dla wymagających środowisk biznesowych, takich jak duże sklepy WooCommerce, serwisy instytucji finansowych czy platformy obsługujące setki tysięcy zapytań SQL, infrastruktura oparta na FreeBSD oferuje poziom bezpieczeństwa i stabilności, który trudno osiągnąć na standardowym stosie.

Gdyby nie dominacja Linuksa w ekosystemie hostingowym i chmurowym, FreeBSD zdecydowanie byłby naszym systemem pierwszego wyboru!