Testy wydajności 3CX Enterprise 512SC Edition

Testy wydajności 3CX Enterprise 512SC Edition
Spis treści
Wstęp ........................................................................................................................................................4
Teza .......................................................................................................................................................... 4
Procedura testów....................................................................................................................................... 4
Środowisko 3CX.................................................................................................................................. 5
Serwer............................................................................................................................................... 5
Hypervisor ........................................................................................................................................ 5
Skreowane i uruchomione VM.........................................................................................................5
Oprogramowanie na 3CX VM......................................................................................................... 5
Środowisko pomiarowe / klienckie ...................................................................................................... 6
Serwery .............................................................................................................................................6
Oprogramowanie.............................................................................................................................. 6
Scenariusze testów................................................................................................................................ 6
Scenariusze głosowe.........................................................................................................................6
Generacja rejestracji SIP .................................................................................................................. 7
Generacja zapytań http ..................................................................................................................... 7
Metoda przeprowadzania testu............................................................................................................. 7
Idle Status......................................................................................................................................... 7
8 Calls per 10s.................................................................................................................................. 8
8 Calls per second............................................................................................................................. 8
Metoda kolekcji wyników.................................................................................................................... 8
Przygotowania.......................................................................................................................................... 8
Generator SIP ....................................................................................................................................... 8
Generator RTP ...................................................................................................................................... 9
Terminator SIP/RTP ............................................................................................................................. 9
Konfiguracja 3CX ................................................................................................................................ 9
Wyniki.................................................................................................................................................... 10
Idle...................................................................................................................................................... 10
Microsoft Performance Monitor.....................................................................................................10
VMware vSphere............................................................................................................................11
8 calls per 10s..................................................................................................................................... 11
Microsoft Performance Monitor.....................................................................................................12
VMware vSphere............................................................................................................................13
8 calls per second................................................................................................................................13
Microsoft Performance Monitor.....................................................................................................14
VMware vSphere............................................................................................................................15
Podsumowanie........................................................................................................................................15
1
Wstęp
3CX to najbardziej popularny system PBX przeznaczony do pracy w środowiskach Microsoft
Windows. Charakteryzuje się prostotą i intuicyjnością konfiguracji, oraz często zaskakującą
wydajnością. Licencjonowanie systemu w głównej mierze polega na ograniczeniu ilości
jednoczesnych połączeń głosowych wykonywanych w oparciu o system. Co jednak w momencie, w
którym normalnie przyjęte 64 jednoczesne połączenia zamieniają się w 512?
Dzięki uprzejmości firmy 3CX otrzymaliśmy do testów ich najpotężniejszy system - 3CX Enterprise
512SC Edition. System miał być w stanie umożliwić wykonanie równoległych 512 połączeń
głosowych, trzeba przyznać, że jest to całkiem imponująca wartość nawet jak na rozwiązania
operatorskie. Tym większe było nasze zainteresowanie możliwością przetestowania tego produktu.
Szybko jednak euforia minęła, bowiem stanęła przed nami wizja, w której cały test będzie polegał na
wygenerowaniu 512 połączeń w Generatorze SIP, odebranie ich w Terminatorze SIP i sprawdzenie
obciążenia systemu.
Postanowiliśmy zrobić coś innego...
2
Teza
Chcieliśmy zbadać jak zachowa się ten system w emulowanym środowisku bardzo dużego PBX.
Stwierdziliśmy zatem, że musimy przygotować automatyczne środowisko symulujące pracę systemu
obsługującego około 3000 numerów wewnętrznych. Oznaczało to konieczność wprowadzenia
obszernej konfiguracji do systemu 3CX, stworzenia generatora i terminatora SIP symulującego kilka
klas i grup ruchu SIP oraz generującego media tylko w wybranych klasach, emulacji SIP Trunk do
PSTN. Od 3CX oczekiwaliśmy kierowania połączeń na zasadzie DDI, ACD, SIP Location Service,
nagrywania połączeń i odgrywania IVR.
Wisienką na torcie miał się okazać nasz ostatni pomysł. Jako wynik testu otrzymać mieliśmy zapis
obciążenia systemu Windows, ale chcąc uzyskać referencyjny pomiar, zaspokajający naszą ciekawość
w kontekście overhead nadawanego przez system operacyjny, zwróciliśmy się w stronę wirtualizacji.
Dodatkowym aspektem, który skłonił nas do wykorzystania hypervisora był fakt, że zaczyna być to
coraz częściej wykorzystywana technologia dla implementacji rozwiązań informatycznych w
środowiskach enterprise. Jednym z niepisanych zamierzeń było także udowodnienie, że transmisja
danych w czasie rzeczywistym i maszyna wirtualna nie są przeciwstawnymi terminami.
3
Procedura testów
3.1 Środowisko 3CX
3.1.1
Serwer
Platformą sprzętową dla serwera 3CX był serwer Dell PowerEdge, który hostował na sobie hypervisor
VMware
3.1.2
Model
Dell PowerEdge 1950 MKII
CPU
2x Intel Xeon E5320 @ 1,86 GHz
RAM
16 GB DDR2-667 PC2-5300
HDD
2x 300GB SAS 15k
RAID
PERC 5/i w trybie RAID1
NIC
2x Broadcom 1000 Base-T
Hypervisor
Model
3.1.3
VMware ESXi 4.1.0
Skreowane i uruchomione VM
Stwierdziliśmy, że aby najlepiej zasymulować produkcyjne wdrożenie musimy skreować i uruchomić
jeszcze dwie maszyny wirtualne poza testowaną. Maszyny były w stanie idle, poza systemami
operacyjnymi nie pracowały na nich żadne usługi
VM
3CX512test
Opis
V M u t r z y m u j ą c y Idle VM1
Idle VM2
testowany system 3CX
4 vCPU (4 rdzenie z 2 vCPU (2 rdzenie z 2 vCPU (2 rdzenie z
Xeon)
Xeon)
Xeon)
8 GB
2 GB
2 GB
CPU
RAM
HDD
VM2
RAID
83 GB SCSI (0:0) 22 GB SCSI (0:0) 22 GB SCSI (0:0)
datastore1
datastore1
datastore1
LSI Logic SAS
LSI Logic Parallel
LSI Logic SAS
NIC
1x E1000
OS
3.1.4
VM1
2 x E 1 0 0 0 ( r ó ż n e2 x E 1 0 0 0 ( r ó ż n e
vSwitch)
vSwitch)
Windows Server 2008 Debian Squeeze 6.0.2 Centos 6.0
R2 Standard
Oprogramowanie na 3CX VM
Na VM utrzymującej aplikację 3CX zainstalowano poniższy software. W celu pobierania
referencyjnych wyników wydajności w stosunku do oprogramowania Microsoft używaliśmy także
opcji Report Performance z poziomu VMware vSphere Client 4.1.0
System operacyjny
Microsoft Windows Server 2008 R2 Standard
Aplikacja PBX
Monitor wydajności OS
3CX Enterprise Edition 512SC wersja 10
Service Pack 2
Microsoft Performance Monitor
Monitor wydajności VM
VMware vSphere Client 4.1.0
3.2 Środowisko pomiarowe / klienckie
3.2.1
Serwery
W testach, po stronie generatorów i terminatorów różnych rodzajów ruchu, brały udział dwie maszyny
o zbliżonej do tej konfiguracji
3.2.2
CPU
1x Intel QC @ 2 GHz
RAM
4 GB DDR3
HDD
1x 1TB SATAII
NIC
1x Intel Pro E1000 1000 Base-T
Oprogramowanie
Obydwie maszyny generujące i terminujące ruch pracowały w oparciu o następującą konfigurację
software
System operacyjny
Centos 6.0
Emulator / generator SIP
SIPp v3.2-TLS-PCAP
Biblioteka generatora RTP
libpcap 1.0.0
Biblioteka SSL
openssl 1.0.0
Generator http
Curl-loader 0.53
3.3 Scenariusze testów
3.3.1
Scenariusze głosowe
Wyspecyfikowaliśmy podział na następujących aktorów w testach
•
Extension Voice – numer wewnętrzny generujący połączenia głosowe
•
Extension – numer wewnętrzny wykonujący jedynie rejestrację do PBX
•
SIP Trunk – symulacja usługi dostępu głosowego do sieci PSTN
Wyspecyfikowaliśmy podział na następujące klasy ruchu
•
IVR – połączenia przychodzące od SIP Trunk na DDI obsługiwane przez zapowiedzi IVR i
kierowane na grupę ACD skąd dystrybuowane są do Extension Voice
•
IN – połączenia przychodzące od SIP Trunk na DDI i kierowane bezpośrednio na Extension
Voice
•
OUT – połączenia wychodzące generowane przez Extension Voice i kierowane do SIP Trunk
•
LOCAL – połączenia generowane przez Extension Voice i kierowane do innych Extension
Voice
W poniższej tabeli wyszczególnione są poszczególne klasy ruchu wraz z ilością równoczesnych
połączeń, które zostaną maksymalnie uzyskane dla danej klasy ruchu. Dla niektórych klas ruchu
połączeń przychodzących definiowaliśmy specjalne zachowania, takie jak nagrywanie połączeń
głosowych, Active Call Distribution w oparciu o algorytm Round-Robin oraz wykorzystanie PBX w
ścieżce transmisji głosowej RTP – Media Proxy
3.3.2
Klasa ruchu Inicjator
Terminator
Nagrywanie
ACD
I V R - SIP Trunk
NOREC
IVR-REC SIP Trunk
Extension Voice
Nie
Tak
M e d i a Calls
Proxy
Tak
82
Extension Voice
Tak
Tak
Tak
20
IN-NOREC SIP Trunk
Extension Voice
Nie
Nie
Tak
189
IN-REC
SIP Trunk
Extension Voice
Nie
Nie
Tak
21
OUT
Extension Voice SIP Trunk
N/A
N/A
Nie
90
LOCAL
Extension Voice Extension Voice
N/A
N/A
Nie
110
Generacja rejestracji SIP
Każdy Extension Voice musiał zostać zarejestrowany jako SIP UA do PBX celem inicjowania /
terminowania połączenia, a także nadal istniała konieczność wygenerowania pozostałych 2378
rejestracji SIP dla numerów typu Extension, symulujących SIP UA, które w czasie testu nie
wykonywały połączeń głosowych
3.3.3
Klasa ruchu
Inicjator
Terminator
Metoda
Calls
REG-VOICE
Extension Voice
REG-IDLE
Extension
3 C X L o c a t i o n D i g e s t 622
Service
Authentication
3 C X L o c a t i o n D i g e s t 2378
Service
Authentication
Generacja zapytań http
System pracuje w oparciu o serwer WWW firmy Aprelium o nazwie Abyss i pełni rolę GUI zarówno
administracyjnego jak i dla użytkowników. Ostatnim scenariuszem testów było generowanie zapytań
HTTP GET do ww. serwera, celem sprawdzenia czy typowy dla 3000 użytkowników chcących choćby
sprawdzić nieodebrane połączenia, wpłynie na wydajność serwera.
Klasa ruchu
Inicjator
Terminator
Cel
Calls
HTTP-GET
curl-loader
Abyss Web Server MyPhone login 25/sekundę
page
3.4 Metoda przeprowadzania testu
Wyszczególniliśmy 3 metody testowania rozwiązania, z których będziemy na końcu analizować
wyniki
3.4.1
Idle Status
W tej metodzie chcieliśmy uzyskać referencyjną wartość obciążenia serwera, który nie wykonuje
żadnych czynności związanych z procesowanie połączeń SIP.
3.4.2
8 Calls per 10s
W tej metodzie chcieliśmy generować 8 połączeń co 10 sekund, gdzie każde połączenie miało 800
sekund długości. Miało to przedstawić równomiernie narastające obciążenie serwera rozłożone w
relatywnie długim czasie i zbadać odporność aplikacji na długotrwałą pracę pod wysokim
obciążeniem. Równolegle do zapytań głosowych wykonywane było 25 zapytań na sekundę do serwera
WWW wchodzącego w skład aplikacji 3CX.
3.4.3
8 Calls per second
W tej metodzie chcieliśmy generować 8 połączeń co sekundę, gdzie każde połączenie miało 80 sekund
długości. Scenariusz jest mało wykonalny przy normalnej pracy systemu, ale miał przedstawić szybko
narastające obciążenie serwera i zbadać odporność aplikacji na konieczność szybkiej alokacji dużej
ilości zasobów. Równolegle do zapytań głosowych wykonywane było 25 zapytań na sekundę do
serwera WWW wchodzącego w skład aplikacji 3CX.
3.5 Metoda kolekcji wyników
Wyniki zbieraliśmy z użyciem Microsoft Performance Monitor oraz VMware vSphere Client do
postaci plików CSV. Interesowały nas
4
CPU Load Avarage
M i c ro s o f t P e r f o r m a n c e VMware vSphere Client –
Monitor – OS Level
VM Level
Tak
Tak
Memory use Avarage
Tak
Tak
I/O Avarage
Tak
Tak
NIC BW Avarage
Tak
Tak
CPU Time dla procesów 3CX Tak
Nie
Datastore R/W Latency
Tak
Nie
Przygotowania
Podczas konfiguracji zastawu testowego natrafiliśmy na kilka elementów, które mogą być warte uwagi
dla lepszego zobrazowania otrzymanych wyników
4.1 Generator SIP
Celem wygenerowania odpowiedniej sekwencji pakietów SIP symulujących proces rejestracji,
wykonania połączenia jego autoryzacji, progresu, a później rozłączenia potrzebowaliśmy bardzo
skalowalnego generatora. Rozpatrywaliśmy kilka możliwości, m.in. FreeSwitch – bardzo skalowalny
open source softswitch zdolny do przeprowadzenia tak skomplikowanego procesu. Jednak wybór padł
na Sipp, narzędzie open source, które od lat służy do stress testów rozwiązań SIP. Zawdzięcza to
przede wszystkim swoim minimalnym wymaganiom sprzętowym.
Jedynym mankamentem, który napotkaliśmy podczas pracy z tym rozwiązaniem był fakt, że 3CX
PBX podczas dużego obciążenia potrafił wysyłać komunikaty SIP w odwrotnej niż przewidywana
kolejności, co powodowało błędy w wykonywaniu kolejnych prób aplikacji Sipp. Struktura każdego
testu, bowiem zakłada kolejność w jakiej wiadomości zostaną wysłane i odebrane. Znaleźliśmy
obejście dla tych problemów uznając niektóre SIP msg za opcjonalne.
4.2 Generator RTP
Największym problemem na jaki można natrafić podczas testowania rozwiązań VoIP jest konieczność
wygenerowania odpowiedniej ilości strumieni RTP zakodowanych z użyciem odpowiedniego kodeka.
Ze względu na bardzo wysokie zużycie procesora podczas kodowania klasycznymi kodekami,
wykorzystaliśmy możliwość odtworzenia strumienia RTP w alternatywny sposób - przy pomocy
modułu Sipp zwanego PCAP Play. Dzięki niemu byliśmy w stanie odtworzyć 8 sekundowy plik pcap
zawierający transmisję z użyciem kodeka G711A i zapętlić ją odpowiednią ilość razy, tak aby uzyskać
wymaganą długość sampla audio.
4.3 Terminator SIP/RTP
Przy konfiguracji terminatora SIP wykorzystaliśmy te same kruczki co w przypadku Generatora i
wiadomości SIP poza sekwencją. Strumień RTP zawracaliśmy do Generatora za pomocą aplikacji Sipp
RTP Echo.
4.4 Konfiguracja 3CX
Skonfigurowanie 3CX PBX polegało na wprowadzeniu konfiguracji 3000 kont dla użytkowników i
odpowiadającej im konfiguracji kierowania połączeń głosowych. W przypadku tworzenia takiej ilości
użytkowników bardzo wygodna okazała się opcja importu z pliku CSV, dzięki czemu w niecałe 15
minut cała konfiguracja kont użytkowników została zapisana do bazy PostgreSQL.
Problematyczne okazało się tworzenie DDI, bowiem 3CX nie oferuje możliwości zautomatyzowania
procesu ich nadawania. Ten element konfiguracji musieliśmy wprowadzić ręcznie dla każdego numeru
Extension Voice, co zajęło znaczną ilość czasu.
5
Wyniki
5.1 Idle
Poniższe wykresy prezentują zużycie zasobów podczas pracy systemu operacyjnego wraz z aplikacją
3CX 512SC w momencie, w którym nie wykonywano żadnych zapytań do systemu z systemów
zewnętrznych – SIP ani HTTP.
5.1.1
Microsoft Performance Monitor
Poniżej znajdują się wyniki zebrane przy pomocy Microsoft Performance Monitor prezentujące
całkowite zużycie I/O dysku twardego (zapis i odczyt) w Bajtach na sekundę, sumaryczny czas
zajętości CPU (wszystkich 4 rdzeni) w procentowej skali, dostępną (niezalokowaną) pamięć RAM w
Megabajtach oraz sumaryczne pasmo transferowane przez interfejs sieciowy (Rx i Tx) w Bajtach na
sekundę. Identycznie prezentować będziemy później wyniki pobierane z PerfMon dla innych
scenariuszy testów.
Na poniższym wykresie zaobserwować można sumaryczny czas zajętości CPU dla poszczególnych
procesów wchodzących w skład aplikacji 3CX, podczas gdy do aplikacji nie były wykonywane żadne
połączenia – SIP ani HTTP.
5.1.2
VMware vSphere
Poniżej znajdują się wyniki zebrane przy pomocy VMware vSphere Client Performance Report
prezentujące całkowite zużycie I/O fizycznego dysku twardego (zapis i odczyt) w Kilobajtach na
sekundę, sumaryczny czas zajętości CPU (wszystkich 4 rdzeni) w procentowej skali, użytą pamięć
RAM w Kilobajtacj oraz sumaryczne pasmo transferowane przez interfejs sieciowy (Rx i Tx) w
Kilobajtach na sekundę. Identycznie prezentować będziemy później wyniki pobierane z vSphere dla
innych scenariuszy testów.
5.2 8 calls per 10s
Poniższe wykresy prezentują zużycie zasobów podczas wykonywania scenariusza 8 Calls per 10s. W
prezentowanych wykresach pojawiła się pewna modyfikacja w stosunku do wyników z części Idle,
mianowicie na wykresie zaznaczona została ilość aktywnych w danym czasie połączeń głosowych
wyskalowana na prawej osi rzędnych. Test trwał prawie 25 minut, a wysoki końcowy peak w
wynikach I/O spowodowany był omyłkowym logowaniem na Windows Server z użyciem RDP .
Wyniki przedstawiane przez narzędzie vSphere i PerfMon przedstawiają bardzo zbliżone
charakterystyki wykorzystania zasobów, oznaczać to może tylko, że są one poprawnie alokowane i
zwalniane.
Przy przeprowadzaniu tego testu uzyskaliśmy 3% nieudanych połączeń, spowodowanych przede
wszystkim gubieniem się połączenia w mechanizmie ACD, lub błędną sekwencją wiadomości SIP
wysyłanych przede wszystkim do generatora SIP. Po stronie terminatora nie zauważyliśmy większych
problemów.
Zauważalne jest większe zapotrzebowanie na zasoby systemowe podczas zestawiania połączeń niż
podczas ich trwania. Nie dotyczy do oczywiście I/O HDD, które po nawiązaniu połączeń i odegraniu
prometów IVR, musiały pewną część połączeń jeszcze nagrać.
5.2.1
Microsoft Performance Monitor
Poniżej znajdują się wyniki zebrane przy pomocy Microsoft Performance Monitor prezentujące
wyniki z tego testu.
Na poniższym wykresie zaobserwować można sumaryczny czas zajętości CPU dla poszczególnych
procesów wchodzących w skład aplikacji 3CX, podczas gdy wykonywane były połączenia SIP i
HTTP wchodzące w skład scenariusza testu 8CP10S.
5.2.2
VMware vSphere
Poniżej znajdują się wyniki zebrane przy pomocy VMware vSphere Client Performance Report
prezentujące wyniki z tego testu.
5.3 8 calls per second
Poniższe wykresy prezentują zużycie zasobów podczas wykonywania scenariusza 8 Calls per second.
W prezentowanych wykresach pojawiła się pewna modyfikacja w stosunku do wyników z części Idle,
mianowicie na wykresie zaznaczona została ilość aktywnych w danym czasie połączeń głosowych
wyskalowana na prawej osi rzędnych.
Wyniki przedstawiane przez narzędzie vSphere i PerfMon przedstawiają bardzo zbliżone
charakterystyki wykorzystania zasobów, oznaczać to może tylko, że są one poprawnie alokowane i
zwalniane.
Przy przeprowadzaniu tego testu uzyskaliśmy prawie 8% nieudanych połączeń, ta całkiem spora liczba
spowodowana jest bardzo dużą ilością konkurencyjnie zestawianych połączeń rzadko występującą w
środowiskach nie operatorskich. Znów ogromna większość błędów spowodowana była gubieniem się
połączenia w mechanizmie ACD, lub błędną sekwencją wiadomości SIP wysyłanych przede
wszystkim do generatora SIP. Po stronie terminatora nie zauważyliśmy większych problemów.
Jesteśmy świadomi, że te 37 nieudanych połączeń zgodnie z wykresem zostało odrzuconych przez
brak dostępnego czasu procesora (peak w czasie 13:20), ale tak jak pisałem wcześniej scenariusz jest
słabo wykonalny w rzeczywistości, więc 3CX poradził sobie tutaj na 5.
Znów zauważalne jest większe zapotrzebowanie na zasoby systemowe podczas zestawiania połączeń
niż podczas ich trwania. Nie dotyczy do oczywiście I/O HDD, zachowało się tym razem zupełnie
odwrotnie i zanotowało największe obciążenie w końcowej fazie testu. Znów spowodowane jest to
koniecznością nagrania rozpoczętych rozmów
5.3.1
Microsoft Performance Monitor
Poniżej znajdują się wyniki zebrane przy pomocy Microsoft Performance Monitor prezentujące
wyniki z tego testu.
Na poniższym wykresie zaobserwować można sumaryczny czas zajętości CPU dla poszczególnych
procesów wchodzących w skład aplikacji 3CX, podczas gdy wykonywane były połączenia SIP i
HTTP wchodzące w skład scenariusza testu 8CPS.
5.3.2
VMware vSphere
Poniżej znajdują się wyniki zebrane przy pomocy VMware vSphere Client Performance Report
prezentujące wyniki z tego testu.
6
Podsumowanie
System oferujący możliwość obsłużenia 512 jednoczesnych połączeń głosowych swobodnie może
świadczyć usługi dla 3000 abonentów. Liczba taka niejednokrotnie definiuje ilość abonentów u
małego ISP świadczącego usługi VoIP. Oznacza to, że firma 3CX tworząc swój produkt Enterprise
512SC Edition stała przed nie lada wyzwaniem wydajnościowym. W naszych testach pomimo różnych
inicjalnych komentarzy i ogólnego niepokoju towarzyszącego faktowi powiązania terminów:
wirtualizacja, Windows Server, serwer VoIP, obsługa mediów i 512 jednoczesnych połączeń, udało
nam się udowodnić, że tak naprawdę produkt 3CX jest wyśmienity.
Cały geniusz i siła drzemiąca w nim nie zamyka się tylko i wyłącznie w świetnych wynikach
wydajnościowych i powyższych wykresach, ale też w dwóch innych faktach związanych ściśle z
finansami
•
Cena 3CX 512SC nigdy nie zbliży się nawet do poziomu tradycyjnej centrali PBX
obsługującej 3000 numerów wewnętrznych
•
Koszt utrzymania systemów IT w firmie diametralnie spada jeśli mamy do czynienia z
systemem głosowym, który pracuje tak jak inne nasze serwery w oparciu o środowisko
Windows Server.
Michał Podoski i Andrzej Pierścionek