Podążaj za instrukcjami w poniższym filmie, aby zobaczyć, jak zainstalować naszą stronę jako aplikację internetową na ekranie głównym swojego urządzenia.
Informacja: Ta funkcja może nie być dostępna w niektórych przeglądarkach.
Używasz przestarzałej przeglądarki. Może ona nie wyświetlać poprawnie tej lub innych stron internetowych. Powinieneś zaktualizować swoją przeglądarkę lub użyć alternatywnej przeglądarki.
Jak wykonać test iperf3 lub bandwidth test na klastrze HA manager? Lub czy podczas tworzenia klastra jest opcja weryfikacji prędkości? Ponadto rozwiej wątpliwość.. bo ja gdybym robił ten mechanizm to zastosowałbym zupełnie inne sysctl wytyczne działania buforów sieciowych i cache pakietów. Uzasadniłbym to potrzeba tunningu sieciówek pod kątem środowiska High Availability które IMHO rządzi się swoimi prawami a surowy test prędkości to tylko powierzchowny test. Racja czy nie?
Krótko: High Availability Manager nie robi automatycznej weryfikacji przepustowości podczas tworzenia klastra — testy wydajności musisz wykonać samodzielnie. Najpewniejszy sposób to testy iperf3 między rzeczywistymi interfejsami węzłów (albo między klastrowym VIP a węzłem aktywnym), plus testy symulujące przełączenia (switch over / failover) żeby sprawdzić zachowanie ruchu. Poniżej kompletna, samodzielna instrukcja, wskazówki i uwagi o tuningu buforów sieciowych.
UWAGA bezpieczeństwo przed testami
Zawsze wykonaj pełną kopię zapasową danych przed testami HA (podają to fragmenty dokumentacji).
Testy wydajności i wymuszanie awarii rób poza środowiskiem produkcyjnym lub w oknie serwisowym.
Monitoruj High Availability Manager > Cluster i logi podczas testów.
1. Co i gdzie testować — warianty
Test między dwoma fizycznymi węzłami (najbardziej „surowy"): uruchom iperf3 server na węźle A, client na węźle B, testuje bezpośrednio łącze między nimi (przydatne dla linku synchronizacji / replikacji).
Test między klientem zewnętrznym a klastrowym VIP: uruchom iperf3 server na klastrowym VIP (lub na węźle aktywnym, kierując ruch na VIP) i client na zdalnym hoście — sprawdzisz przepustowość usług na IP klastra.
Test wydajności usług po przełączeniu: połącz client do VIP, wymuś Switch Over lub zasymuluj awarię i powtórz testy, aby zobaczyć przerwy/zmiany throughput/RTT.
Testy wielostrumieniowe / równoległe: iperf3 z wieloma równoległymi wątkami (parametr -P) dla obciążenia i oceny skalowania TCP.
2. Przygotowanie sieci i interfejsów (zgodnie z wymogami HA)
Upewnij się, które interfejsy używa klaster (połączenie klastra, heartbeat). Z dokumentacji: konfiguracja interfejsów klastra przy tworzeniu HA jest istotna — notuj adresy IP interfejsów klastra i heartbeat.
Preferuj testy na tych samych interfejsach, które służą synchronizacji i ruchowi usług (np. interfejs klastra/VIP i dedykowane łącze danych).
Wyłącz/odseparuj wirtualne agregacje (LACP) tylko jeśli chcesz testować poszczególne porty; w przeciwnym razie testuj na produkcyjnej konfiguracji agregacji.
3. Jak uruchomić iperf3 — przykłady (uruchomienia na urządzeniach z powłoką)
(Uwaga: QNAP ma BusyBox / Linux — jeśli nie masz iperf3 w systemie, użyj zewnętrznego klienta/serwera lub kontenera/VM z iperf3.)
Uruchom serwer na węźle A:
Bash:
iperf3 -s
# lub dla TCP z zapisem wyników:
iperf3 -s > /tmp/iperf3_server.log 2>&1 &
Uruchom klienta na węźle B (jednostrumieniowy test 10 s):
Bash:
iperf3 -c <IP_serwera> -t 10
Test przy wielu strumieniach (np. 8 równoległych):
Bash:
iperf3 -c <IP_serwera> -t 30 -P 8
Test UDP (jeśli chcesz sprawdzić przepustowość liniową, ale pamiętaj o stratkach i jitterze):
Bash:
iperf3 -c <IP_serwera> -u -b 1G -t 10
Jeżeli nie możesz uruchomić iperf3 na NAS: uruchom kontener (Container Station) lub VM z iperf3 i testuj z/na interfejsy NAS.
4. Testy specyficzne dla klastra HA
Test przełączenia ręcznego: High Availability Manager > Cluster > Manage > Switch Over. Podczas i po przełączeniu powtórz iperf3 testy na VIP i porównaj wyniki, zmierzone przerwy i ewentualne spadki throughput.
Test automatycznego failover: zasymuluj odłączenie sieci lub wymuszone wyłączenie aktywnego węzła (zgodnie z dokumentacją), obserwuj czy pasywny staje się aktywny i jak szybko ruch się odtwarza. Mierz czasy przerwy aplikacji i ponownego zestawienia połączeń.
Testy synchronizacji puli/replic: obciążenie, które generuje ruch replikacji między węzłami — zmierz, czy link synchronizacji (jeśli to krytyczne) nie jest wąskim gardłem.
5. O tuningu sysctl i buforach — ogólne zalecenia (oznaczone jako ogólna wiedza)
Uwagi: Nie podaję tu QNAP-owych ścieżek/opcji, bo dokumentacja producenta określa ten obszar. Poniższe to standardowe dobre praktyki dla Linux/TCP w środowiskach HA:
Skaluj bufory TCP (net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, net.ipv4.tcp_wmem) gdy masz wysoką przepustowość x wysokie opóźnienie (BDP).
Dostosuj tcp_congestion_control (np. cubic/bbr) zależnie od środowiska; BBR może dać lepszy throughput przy dużym BDP.
Jeśli używasz sprzętowych offloadów (TSO/GSO/GRO), sprawdź kompatybilność z kartami i sterownikami — czasem wyłączenie GRO na testerze ujawnia rzeczywisty problem.
Uważaj na aggressive TCP autotuning — może wpływać na stabilność w krótkich failoverach (reset połączeń).
Dla UDP ustaw limit przepustowości (-b w iperf3) a także monitoruj paket loss/jitter.
Testuj zmiany w labie — przy HA zmianą parametrów sieciowych można wpłynąć na czas odbudowy po failover.
Ważne: powyższe to ogólne wskazówki. Na QNAP modyfikacje sysctl i trwałe ustawienia trzeba robić ostrożnie i najlepiej testować w środowisku nieprodukcyjnym.
6. Co mierzyć i jak interpretować wyniki
Throughput (Mb/s, Gb/s) – porównaj z przepustowością linku i oczekiwaniami.
Straty pakietów i retransmisje — wskazują problemy z linkiem lub przeciążeniem buforów.
Latencja i jitter (np. ping, iperf3 UDP) — krytyczne dla usług aplikacyjnych.
Czas przełączenia (time to failover) i przestoju aplikacji — kluczowe KPI dla HA.
Spadki throughput przy równoległych połączeniach — może wskazywać ograniczenia CPU, offloadów lub enkapsulacji.
7. Przydatne narzędzia dodatkowe
tcpdump / tshark — do analizy ruchu podczas failover.
ethtool — sprawdzenie offload/standby linków.
netstat / ss — stan połączeń TCP podczas przełączeń.
Monitoring QNAP i logi High Availability Manager.
8. Przykładowy sekwencyjny plan testu (konkretny checklist)
1) Wykonaj backup danych.
2) Zanotuj konfigurację interfejsów i VIP (Network & Virtual Switch > Network > Interfaces).
3) Uruchom serwer iperf3 na węźle A i klienta na węźle B; wykonaj testy single i multi-thread, zapisz wyniki.
4) Test z zewnętrznego hosta do VIP (przed failover).
5) Wykonaj Switch Over (High Availability Manager > Cluster > Manage > Switch Over). Powtórz test do VIP i porównaj.
6) Zasymuluj awarię (odłącz kabel) i zmierz czas failover i wpływ na throughput.
7) Zbadaj logi i tcpdumpy, jeśli wystąpiły anomalie.
8) Wprowadź ewentualny tuning (bufory, offload) w środowisku testowym i powtórz testy.
Ostatnie uwagi i podsumowanie
Dokumentacja QNAP (High Availability Manager) nie zawiera wbudowanego „speed testu” podczas tworzenia klastra — testy wydajności wykonujesz niezależnie.
Surowy test iperf3 jest przydatny, ale słusznie zauważyłeś: tuning dla HA to więcej niż bandwith — ważne są latencja, czasy failover, zachowanie połączeń i stabilność offloadów. Testuj oba aspekty: surowy throughput i scenariusze przełączeń.
Zawsze testuj najpierw w środowisku nieprodukcyjnym i miej backup.
Krótkie zakończenie z działaniami do wykonania teraz
1) Zrób backup. 2) Wybierz topologię testu (między węzłami vs. VIP). 3) Uruchom iperf3 zgodnie z przykładami powyżej i zapisz wyniki. 4) Przeprowadź Switch Over/failover i powtórz testy. 5) Analizuj logi i dostosuj tuning w labie przed wdrożeniem w produkcji.
Ta wiadomość pochodzi od asystenta AI — może zawierać błędy, zweryfikuj przed zastosowaniem. Oceń ją, głosując pod postem: ▲ pomocna lub ▼ nieprzydatna.
Na tym forum nie ma złych ocen — wszyscy wciąż się uczymy i wszyscy jesteśmy adminami, a +1 czy −1 to zawsze tylko 1 punkt. Każde Twoje kolejne pytanie to wspólna pomoc, która zostaje nie tylko na forum, ale i w internecie. Społeczność forum QNAP działa od 2008 roku i po niemal dwóch dekadach nieprzerwanie dostarcza rzetelne treści, z których korzystają kolejni admini — a ostatnio uczy się na nich także AI.
