sipfoundry colab 2013 - sipxecs cloud architecture (uccs)
DESCRIPTION
At the SIPfoundry CoLab users conference members of the sipXecs team present an architecture overview and explain why sipXecs is optimized for cloud production.TRANSCRIPT
moderator: michael picher
March 10, 2013 / Bentley University / Boston MA
sipXecs Architecture & Direction
1
>Load Testing & Build Team:>Douglas Hubler
>Ciprian Hacman
>SIP Core Team:>Joegen Baclor
>Daniel Tacalau
2Intro of Presenters Team
>sipXecs 4.6 Architecture Overview
>Testing Procedure
>Test Automation
>Status of 4.6
>Roadmap Near-Term / Long-Term
Agenda3
Typical sipXecs Cluster
Multi-master (Before… 4.4 and earlier)
Single Master - Now
>Needed better interprocess communications>Lightweight
>Robust
>Evaluated several>Build?
>RabbitMQ
>ZeroMQ
Message Queuing Introduced7
Publisher / Subscriber
Message Queuing8
Dealer / Worker
Message Queuing9
SQA
sipXecs 4.6 Architecture10
>Manual smoke test
>Basic tests that catch major issues
>Manual sanity test
>Detailed tests for each feature
>Manual regression tests
>Complex tests for features that are added/changed
>Automated Load Tests
>Deployment for a week on our Production System
>Dog fooding…
11Testing Procedure
>Placing and receiving calls is the core feature and we want this to be stable
>Basic testing cannot predict
>How a server behaves over time
>How a server behaves under stress
>Call Load tests helps address both problems
>Allows determination the performance of a Certain Server
>All servers are different (physical, virtual)
>Allows for determining how well sipXecs scales
12sipxtestAutomated Load Tests
>Simple install ‘yum install sipxtest’
>Pink – Files or Commands that test user can interact with.
>Yellow – Generated files (you can edit these files, but know that sipxtest changes overwrite edits)
sipxtest - Architecture13
>3 days of load testing for all major builds
>15 calls per second
>4 million calls total
14What do we do as part of build testing?Load Test Numbers
>Running in house on production system since end of July 2012
>Controlled release since August 2012
>GA December 1, 2013
>Update 1, February 5>Polycom Firmware Updates, New iptables capabilities, bug fixes.
>Update 2, February 6 (small revert)
>Update 3, March 13>fail2ban, bug fixes.
sipXecs 4.6 Status15
>openACD w/Supervisor & Agent Portals
>Multiple Level Administrator
>Multiple Time Zone
>Polycom VVX 300/400 Support
>sipXsbc
>Session State Services – SSS (clean up RLS / XMPP link)
>Improvements to HA (get rid of odd # of server requirement)
>Call Queuing
>Unite 2.0
End of Q1 to End of Q2
Roadmap – Near Term16
>openACD Reporting
>Branch Office Solution>Will likely involve looking at User & System management differenly (i.e., more like a
directory structure).
>User Portal re-write>Browser based client, WebRTC. Zero Install Communications Solution.
>New Admin GUI>Time to modernize a bit. The old interface is efficient but dated.
Roadmap – Longer Term17
End18
>What is different as compared to traditional architectures?
>What makes sipXecs an IT application?
>High-level intro to sipXecs architecture (diagram)
>Hardware independence: What does this mean?
>Resulting deployment options: Focus on flexibility, global scale, redundancy
>Redundancy, branch redundancy
>Focus on our ‘secret sauce’. What makes this architecture better than all the others?
19
>What is new?
>Experience with 4.6 in the field
>Test results and test methodology
20Status of the 4.6 Release
>Pick 2 to 3 examples. E.g. Axcess Finacial
21Deployment Examples
>Discuss near term and longer term roadmap
>What is our goal?
22Roadmap
23
24
3:00-4:00 sipXecs Architecture Moderator: Mike
Participants: Douglas, Daniel, Joegen, CiprianEngineering provided content:•Architecture overview (Mongo, SIP, XMPP, CFEngine high-level arch diagram). •Features and improvements delivered with 4.6•Test automation (how do we test?)•Status of 4.6 •Deployment examples (distributed, virtualized, redundancy)•Roadmap – what to come next?