Home

Dotychczasowo zaprojektowaliśmy infrasturukturę składającą się z 3 instancji.

• VM -> DB - instancja z bazą danych
• VM -> Master WP - backend dla CopyWriterów i developerów
• VM -> Frontend - dla wszystkich publicznych użytkowników

Obecnie zadaniem będzie zaprojektowanie systemu, który stworzy replikę Frontendu zapopiegającą przeciążeniu serwera. Jeśli nagle Twój ruch na WWW zwiększy się a Twój administrator będzie na urlopie ... Zautomatyzujmy proces.

Wykorzystany w tym celu narzędzie Azure Virtual Machine scale set.

Proponuje dla testów najpierw zainstalować 2 pakiety:

sudo apt-get install -y stress stress-ng htop

Wykonaj polecenia na instancji Frontend, ma to na celu usunięcia danych "osobistych" maszyny (wiecej):

sudo waagent -deprovision

Następnie robimy Capture VMki Frontendu. Przypominam, instancja zostanie zawieszona i zablokowana bez możliwości jej uruchomienia po utworzonym Capture.

Nastepnie do wszystkich kolejnych kroków będziemy korzystać z tego obrazu.

Test #1a - Standard B1s

Za pomocą loadimpact.com testuje stronę z podstawowymi URLami.

Maszyna: Standard B1s (1 vcpus, 1 GB memory), Disk Premium SSD (IOPS limit 120)

Dla 100 virtual usersów w ciągu 10 minut.

Już przy tej instancji widać granicę ~75 userów których możemy obsłużyć jednocześnie.

Test #1b - Standard DS1 v2

Za pomocą loadimpact.com testuje stronę z podstawowymi URLami.

Maszyna: Standard DS1 v2 (1 vcpus, 3.5 GB memory), Disk Premium SSD (IOPS limit 120)

Dla 100 virtual usersów w ciągu 10 minut.

Ta sama sytuacja. Więcej RAMu nie pomaga. Sytuacja podobna wytrzymuje około ~75 userów.

Test #1c - Standard D2s v3

Za pomocą loadimpact.com testuje stronę z podstawowymi URLami.

Maszyna: Standard D2s v2 (2 vcpus, 8 GB memory), Disk Premium SSD (IOPS limit 120)

Dla 100 virtual usersów w ciągu 10 minut.

Wynik minimalnie lepszy. Około ~80 userów granica końca działania płynnego.

Podsumowanie testów 1:

Niezależnie od maszyny VM i jej parametrów nagłe obiążenie nie miało dużego wpływu na ilość obsługiwanych jednoczesnych połaczeń. Różnicę widać w średnim czasie Response:

• Standard B1s (1 vcpus, 1 GB memory) #1 -> 1.19s
• Standard DS1 v2 (1 vcpus, 3.5 GB memory) -> 1.04s
• Standard D2s v2 (2 vcpus, 8 GB memory) -> 0.99s
• ScaleSets - 1VM x Standard DS1 v2 (1 vcpus, 3.5 GB memory) -> 0.96s

Create virtual machine scale set

Po utworzeniu obrazu (image) systemu, tworzymy pierwszy Scale Set. Tworzymy według poniższego schematu. Moim rodzajem maszyny będzie do testów: Standard DS1 v2 (2 vcpus, 8 GB memory), Disk Premium SSD (IOPS limit 120)

W moim przypadku Load balancing dzieli się według typu:

Wybór to: Load balancer

Przypominam, jeżeli używałeś domen, zmień domenę aby kierowała od tej pory na Scale Set.

Po utworzeniu - skalujemy manualnie według schematu:

Test #2a - 1 instancja

Uruchamiamy set z 1 instancją. Wynik:

Test #2a - 2 instancje

Uruchamiamy set składający się z 2 instancji. Wynik:

Podsumowanie testów 2:

Ustawienie maszyn w setach pozwala na przyśpieszenie i zwiększenie ruchu:

• NO ScaleSet -Standard DS1 v2 (1 vcpus, 3.5 GB memory) -> 1.04s
• ScaleSets - 1VM x Standard DS1 v2 (1 vcpus, 3.5 GB memory) -> 1.06s
• ScaleSets - 2VM x Standard DS1 v2 (1 vcpus, 3.5 GB memory) -> 0.32s
• ScaleSets - 4VM x Standard DS1 v2 (1 vcpus, 3.5 GB memory) -> 0.26s

Widać znaczącą różnicę w przyśpieszeniu.

Przypominam o możliwościach stresowaniu usług:

Zalogujmy siędo SSH Frontendu serwera i wykonajmu pierwszy test:

stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 1G --timeout 5m --metrics-brief

Stres dla 4 CPU, 2 IO i 1 VM z użyciem 1G RAMU.