Ten artykuł to czwarty z cyklu materiałów, w których szczegółowo przyglądamy się funkcjonalnościom i możliwościom rozwiązania VMware Cloud Director oferowanego przez GigaCloud. Moim celem jest przeanalizowanie poszczególnych komponentów tej platformy oraz pokazanie, jak można je wykorzystać w wybranych aspektach codziennej pracy z chmurą opartej na tej technologii. Każdy artykuł będzie się koncentrował na innym aspekcie VMware Cloud Director – od tworzenia maszyny wirtualnej, testy wydajnościowe, przez backup, migrację aż po awaryjne odtwarzanie (DR).
Zapraszam do śledzenia kolejnych wpisów z tej serii, które będą pojawiać się w najbliższym czasie:
- Przegląd środowiska VMware Cloud Director w Gigacloud
- Przykładowa konfiguracja środowiska przez GUI (pierwsza maszyna)
- Przykładowa konfiguracja środowiska przez IaC (Terraform i wiele maszyn)
- Testy wydajnościowe łącza internetowego oferowanego przez providera
- Testy wydajnościowe wdrożonych maszyn dostępnych dysków
- Weryfikacja i konfiguracja funkcji kopii zapasowych od Veeam udostępnionych na platformie
- Migracja do VMware Cloud Provider przy pomocy VMware Cloud Director Availability
- Awaryjne odtwarzanie do centrum danych przez VMware Cloud Director Availability
Wprowadzenie do zakresu bieżącego artykułu
W poprzednich artykułach omówiliśmy ogólny przegląd środowiska VMware Cloud Director oraz proces tworzenia pierwszej maszyny wirtualnej za pomocą interfejsu graficznego (GUI) jak i dalsze wdrożenie na większą skalę poprzez terraform. Kontynuując tę serię, skupimy się na testach połączenia internetowego z wewnątrz infrastruktury oraz na próbie wydajnościowej dysków w zależności od używanego “storage policy”.
1. Wstęp
Testy wydajnościowe są kluczowym elementem weryfikacji infrastruktury IT po wdrożeniu maszyn wirtualnych. Sprawdzenie wydajności połączenia sieciowego oraz systemu storage pozwala uniknąć problemów związanych z opóźnieniami, niską przepustowością i nieefektywnym zarządzaniem zasobami. W niniejszym artykule zostaną przedstawione testy, które pozwolą ocenić jakość połączenia internetowego oraz wydajność dysków w środowisku wirtualnym.
2. Testy połączenia internetowego
Połączenie sieciowe jest jednym z kluczowych elementów wpływających na wydajność maszyn wirtualnych. Stabilność, przepustowość oraz niskie opóźnienia mają bezpośredni wpływ na jakość pracy aplikacji i użytkowników końcowych.
2.1 Narzędzia do testowania sieci
Do testowania połączenia internetowego zostaną wykorzystane narzędzia:
- nPerf – testowanie rzeczywistej prędkości połączenia, latencji oraz jakości połączenia.
- Fast.com – prosty test prędkości pobierania i wysyłania.
- Speedtest.net – szeroko stosowane narzędzie do testowania sieci, dostępne także w wersji CLI.
2.2 Sposób przeprowadzenia testów
Do oceny jakości połączenia internetowego można wykorzystać popularne narzędzia online, takie jak nPerf, Fast.com oraz Speedtest.net, które pozwalają na szybkie sprawdzenie kluczowych parametrów sieci. nPerf oferuje kompleksowy test mierzący prędkość pobierania, wysyłania, opóźnienia (ping) oraz jakość połączenia w czasie rzeczywistym. Fast.com, narzędzie od Netflixa, koncentruje się głównie na pomiarze przepustowości pobierania i wysyłania, co jest przydatne do analizy wydajności streamingu. Speedtest.net, zarówno w wersji przeglądarkowej, jak i CLI, umożliwia szczegółową analizę prędkości łącza, latencji oraz stabilności połączenia, pozwalając na wybór serwera testowego
Architektura testowa:

Wszelkie pomiary wykonywane były z maszyny testowej “mgt-win-01”
2.3 Pomiary dla łącza 50 MBps
Średnie wyniki pomimo czasami róznych lokalizacji są dość zbliżone. Pierwszą serie pomiarów wykonałem na domyślnym łączu 50 MBps (obecnie domyślna otrzymywaną prędkością jest 100 Mbps). Po kontakcie ze wsparciem technicznym w sprawny sposób łącze zostało podniesione do przepustowości 1 GBps i wyniki mierzone w lustrzany sposób zostały zaprezentowane poniżej w osobnej tabeli.
| Narzędzie | Download [Mb/s] | Upload [Mb/s] | Latency [ms] | Test Server |
| nperf.com | 46.9 | 53.55 | 2.244 | ovh.com Warszawa |
| nperf.com | 46.44 | 45.38 | 8.45 | Systel, Katowice |
| nperf.com | 42.58 | 28.69 | 242.7 | Brasil Banda Larga ,Ilha Solteira, São Paulo |
| nperf.com | 46.53 | 45.99 | 19.41 | Kyiv, Eurotranstelecom |
| nperf.com | 46.65 | 45.29 | 24.98 | Kvant2, Kolomyia, Ivano-Frankivsk Oblast |
| nperf.com | 45.03 | 43.56 | 68.2 | VTS, Paris, Île-de-France |
| nperf.com | 30.71 | 32.95 | 96.46 | DataPacket, New York, New York |
| nperf.com | 47.44 | 46.28 | 9.96 | Opole, Multiplay |
| nperf.com | 47.61 | 45.36 | 24.76 | Kamienna Gora, Ignum |
| fast.com | 43 | 37 | 2 | n/a |
| speedtest.net | 50.09 | 47.28 | 1 | Warszawa, PLAY |
| speedtest.net | 50.08 | 47.42 | 1 | Warszawa, Atman |
| speedtest.net CLI | 53.16 | 48.49 | 1.01 | Warszawa, PLAY |
| speedtest.net CLI | 49.03 | 48.15 | 1.23 | Warszawa, Atman |
2.4 Pomiary dla łącza 1 GBps
| Narzędzie | Download [Mb/s] | Upload [Mb/s] | Latency [ms] | Test Server |
| nperf.com | 927.5 | 920.8 | 1.881 | DataPacket, Warszawa |
| nperf.com | 987,9 | 822,8 | 7,357 | Systel, Katowice |
| nperf.com | 336.9 | 62.86 | 242.9 | Brasil Banda Larga ,Ilha Solteira, São Paulo |
| nperf.com | 991 | 804.7 | 15.35 | Kyiv, Eurotranstelecom |
| nperf.com | 1008 | 422 | 24.89 | Kvant2, Kolomyia, Ivano-Frankivsk Oblast |
| nperf.com | 888.7 | 214.7 | 69.2 | VTS, Paris, Île-de-France |
| nperf.com | 431.8 | 55.99 | 96.09 | DataPacket, New York, New York |
| nperf.com | 985.4 | 828 | 9.869 | Opole, Multiplay |
| nperf.com | 946 | 614.9 | 24.57 | Kamienna Gora, Ignum |
| fast.com | 1000.1 | 960 | 1 | n/a |
| speedtest.net | 1005.24 | 958.54 | 1 | Warszawa, PLAY |
| speedtest.net | 997.57 | 958.84 | 1 | Warszawa, Atman |
| speedtest.net CLI | 972.63 | 961.45 | 0.83 | Warszawa, PLAY |
| speedtest.net CLI | 975.15 | 962.1 | 0.99 | Warszawa, Atman |

2.5 Wnioski
Porównując wyniki testów z początkową przepustowością 50 Mbps (jaką dostaje się domyślnie w GigaCloud), można zauważyć:
- Speedtest.net (CLI i przeglądarka) pokazują wartości bliskie maksymalnej dostępnej prędkości (50.1–51.1 Mb/s dla pobierania, 47.3–48.3 Mb/s dla wysyłania), co oznacza, że łącze działa zgodnie z deklarowaną specyfikacją.
- Fast.com oraz nPerf wykazały nieco niższe wartości (43–44 Mb/s dla pobierania, 37–43 Mb/s dla wysyłania), co może wynikać z:
- różnic w metodologii testowania (np. Fast.com priorytetyzuje testy streamingu),
- obciążenia sieci w momencie testu,
- lokalizacji serwera testowego, które było słabsze przy lokalizacjach za oceanem.
Zasadniczo jednak wszystkie narzędzia pokazują, że łącze wykorzystywało niemal pełną deklarowaną przepustowość 50 Mbps, co świadczy o stabilnym i dobrze skonfigurowanym połączeniu. Podobne wyniki widzimy przy łączu 1 GBps. Na wykresie widać jak widoczna jest rózna pomiędzy poszczególnymi prędkościami. Taka duża ilość pomiarów przy pomocy narzędzia nperf.com pokazała mi jak istotne są testy konkretnego dostawcy chmury aby zweryfikowac jak odległość ale i też lokalizacja różnych komponentów naszej aplikacji ma wpływ na jej wydajność i róznego rodzaju opóźnienia.
Jeśli chciałbyś być na bieżąco i budować swoją wiedzę razem zemną w tematach IT dodaj się do listy mailowej TUTAJ . Co jakiś czas będę podsyłał Tobie informacje co się dzieje na blogu i w świecie cloud computingu, którym także się zajmuję.
Masz jakieś pytania lub myślisz, że moglibyśmy zrobić wspólny projekt razem ? daj znać!
Informacje o nowych artykułach, świecie wirtualizacji i "cloud computingu" prosto na Twojego maila:
Dodam Cię do listy mailowej, z której możesz wypisać się w dowolnym momencie (jeden klik.) | Polityka Prywatności
















