Kontakt

Salzdahlumer Str. 46-48
D-38302 Wolfenbüttel

Fon +49 5331 6794-0
Fax: +49 5331 6794-499

E-Mail: info(at)iant.de

Sie möchten mehr Wissen?

Kontaktieren Sie uns jetzt!

SipXecs 4.4 / 4.6 Virtualisierung im Test

Testbeschreibung

Als System under Test (SUT) kommen zwei verschiedene SSOA-Implementationen zum Einsatz, SipXecs 4.4 und 4.6. Beide Systeme werden zunächst direkt auf der Hardware und anschließend als virtuelle Maschine (VM) mit einem ESXi 5.1 Hypervisor ausgeführt. Beim Test der SSOA als VM ist diese die einzige ausgeführte VM auf der Virtualisierungslösung. Die Klärung der grundsätzliche Effekte von Virtualisierung auf Unified Communications-(UC)- Umgebungen wird nur durch einen direkte Vergleich zwischen einem physisch und einem virtuell laufenden System mit den selben Hardwareressourcen möglich.

Getestet wird mit jedem der SUTs zum Einen die Skalierbarkeit der Zeichengabe- Dienste und zum Anderen die generellen Qualitätsparameter (Jitter, Packet- loss, ...) bei der Erbringung der Nutzdatendienste. Der Aufbau der SSOA erlaubt die Trennung von Signalisierung und Nutzdaten, wodurch auch die Testfälle unabhängige betrachtet werden können. 

Testrahmen für die Durchführung von Test Szenarien bei SSOAs
Tabellarische Übersicht zu den Details der für die Untersuchung verwendeten Rechner

 

Ziel der Entwicklung war die Implementation eines Testrahmens für ein IP Multimedia Subsystems (IMS). Ein entsprechender Testrahmen ist im ETSI-Standard Nummer TS 186 008-x (siehe [186 008-1 V1.2.2], [186 008-2 V2.1.1] und [186 008-3 V1.1.1]) beschriebenen. Dieser Standard diente bei der Implementation von IMS-Benchmark (SIPp) als Ausgangspunkt. Beim IMS handelt es sich um eine Architektur die Netzbetreibern den Aufbau von rein Paket-basierten Netzen ermöglichen soll. Dabei werden an IMS die gleichen Anforderungen an Qualität und Skalierbarkeit gestellt wie an herkömmliche Leitungsorientierte-Systeme.  

Hierbei werden folgende Punkte getestet: 

  • Registrierungen (SIP-REGISTER)
  • De-Registrierungen (SIP-REGISTER mit Expire-Time: 0)• Re-Registrierungen (SIP-REGISTER mit Expire-Time >0)
  • UAC/UAS (SIP-INVITE, SIP-BYE zwischen zwei Test-Nodes; Simulation eines Voice-Calls (Signalisierung))
  • MessageC/MessageS (SIP-MESSAGE zwischen zwei Test-Nodes) 

Die Test Szenarien sind in folgendem Diagramm zu sehen. 

In der Abbildung sind verschiedene Phasen zu sehen. In den Phasen werden die SAPS immer weiter erhöht. Im Bereich zwischen t0 und t1 ist eine Vor- bereitungsphase zu sehen (prepare), in der ein Grundstamm von Testnutzern registriert wird. Dies ist notwendig, um einen Pool an Nutzern zu haben an den INVITEs gesendet werden können.

Der Bereich von t1 bis t4 bildet eine Aufwärmphase (heatup) für das SUT. Diese Aufwärmphase dient der langsamen Erhöhung der Last auf das System um dieses zunächst auf Betriebstemperatur zu bringen. Diese Zeitraum ist selbst in drei Phasen unterteilt, bei der die Last schrittweise erhöht wird.

Ab t4 beginnt der eigentliche Testlauf. Die Phasen sind länger und die Last wird weiter erhöht. Am Ende jedes Testschrittes wird geprüft ob die Fehlerrate über dem zulässigen Wert liegt. Ist dies nicht der Fall, werden die SAPS erhöht und der nächste Testschritt bis zum Ende durchlaufen. Erst dann wird erneut geprüft. Die Fehlerrate ist als prozentualer Wert vom betrachteten Zeitraum abhängig. Eine zu Beginn als 100% gemessene Fehlerrate kann sich über die Laufzeit einer Testphase noch in den Promille Bereich verschieben. Dies wäre beispielsweise der Fall, wenn nur das erste Szenario fehlschlägt und anschlie- ßend kein weiteres. 

Testergebnisse von den Zeichengabe-Dienste

Testergebnisse bei einem Testlauf mit einem virtuell laufenden SipXecs 4.4 als SUT. SAPS (Scenario Attempts Per Second).

 

Testergebnisse bei einem Testlauf mit einem virtuell laufenden SipXecs 4.6 als SUT. SAPS (Scenario Attempts Per Second).

Gesamtauswertung

Im Kontext der Zeichengabe-Dienste kann daher in Fällen bei denen ein hohes Aufkommen von Requests zu erwarten ist (große Nutzerzahlen) nur vom Ein- satz eines SipXecs 4.4 abgeraten werden. Der Einsatz eines SipXecs 4.6 kann unter diesen Gesichtspunkte vorbehaltlos empfohlen werden. Es ist besonders hervorzuheben, dass die gemessenen Fehler währen der SipXecs 4.6 Testfälle immer erst bei erreichen der Lastgrenze der Systeme auftraten.