Slide 1 - TMCnet

Document Sample
Slide 1 - TMCnet Powered By Docstoc
					Virtualizing Asterisk
Despairing Myths and Legends
    Nir Simionovich, Asterisk Guru
     Greenfield Technologies Ltd.
      A bit about myself…
• Founder of Greenfield Technologies Ltd
• Founder of the Israeli Asterisk Users
• Started using Asterisk in 2002
• Author of the AsteriskNOW book from
  Packt Publishing (Mar 08)
• Author of the Asterisk Developer’s Guide
  book from Packt Publishing (Jan 09)
 Asterisk – A SysAdmin’s POV
• When most SysAdmins look at Asterisk,
  this is what they see:
  Myth I: * is a resource hog
• Asterisk requires a fair amount of
  resources in order to run properly.
• The things that turn Asterisk into a
  resource hog are the applications
  associated with it (AGI, AMI and others).
• Call center applications usually consume
  much resources.
   Myth II: * is a slow dialer
• Traditional Asterisk based dialers utilize
  the AMI interface for generating outbound
  calls, in its most simplistic form.
• While AMI had progressed over the
  years, traditional implementations are in
  capable is surpassing the 10 calls per
  second limitation.
• Companies build large infrastructures to
  sustain their needs
 Myth III: * Can’t run in a VM
• Myth III is a result of Myth I and Myth II
• After all, if Asterisk is a hog, and,
• Asterisk is a slow dialer, thus,
• Running Asterisk in a VM based
  environments is either complicated or
Introducing PokeTalk.Com
Why is PokeTalk interesting?
• PokeTalk.Com is an ad driven, web
  callback system based upon Asterisk.
• While it utilizes an Asterisk based dialer,
  its platform is completely virtualized –
  utilizing VMWARE Server.
• It currently operates 4 different Virtual
  Asterisk servers, capable of sustaining
  up to 100 dials per second and up to 800
  concurrent channels.
How does it work?
      The Architecture
            Web Server        Web Server

            Web Server        Web Server

           Asterisk Dialer   Asterisk Dialer

           Asterisk Dialer   Asterisk Dialer
Database    VMWARE            VMWARE
 Cluster     Server            Server


                                               ISP Web
    Hardware Specification
• Each VMWARE server is based upon the
  following hardware:
  – Intel Dual Quad Core XEON Processors
  – 2 x RAID-1 SATA Drives (500GB)
  – 2 x Gigabit Ethernet
  – 16GB RAM
• In a VM environment, the more RAM you
  have the better – even if you don’t use all
  of it.
    Guest Operating System Setup
•   CentOS 5.2 64bit Release
•   All services turned off
•   Active services include SSH and xinetd
•   VMWARE Server 1.0.4
•   Each Virtual server is setup as:
     – Dual Core CPU
     – 2GB RAM
     – 40GB Hard Drive (static allocation)
     Dialer Operating System
•   CentOS 5.2 32Bit Release
•   Asterisk 1.4.22
•   MySQL 5
•   PHP 5.2
•   lighttpd web server
•   FreePBX Management Interface
•   Dialer is implemented in PHP and C++!
The Dialer Application Setup
                                      SIP Termination Partners

  Frontend Web

                     XML-RPC Status
  Quaue Manager

 A few service facts (Jan 09)
• Number of registered users > 90,000
• Max number of concurrent calls across
  the cluster: 360 calls
• Max number of concurrent requests
  served: 110 concurrent requests
• Total number of minutes served monthly
  > 2M minutes per month.
   Why virtualize Asterisk?
• Enable better utilization of your hardware
• Consolidate your services into single
  hardware infrastucture
• Utilizing Open/Free virtualization
  technologies will lower your overall TCO
• Virtualizing Asterisk installations can
  negate the need for multi-tennent
  systems and IP centrex
        Asterisk Clouding
• Currently, there are working installations
  of Asterisk utilizing Amazon EC2
• As a test, we’ve installed the dialer
  application on EC2 based instances
• The added value of running virtual dialers
  using EC2 is to get the dialer power you
  need – when you need it and not more
• Performance during the test was identical
  to that of VMWARE dedicated servers
Where to from here?
Development from the past…
• Today’s over excessive use of VM type run-
  time environments do not fit well with
• Working with virtual servers require a return to
  basics for most developers, returning to
  paradigms of high-speed optimizations and low
  memory foot prints
• The more optimal your runtime is, the more
  performance you’ll get from your virtual servers
Optimize for -

Execute like -
       Pooled Provisioning
• Handling multiple VM images (or EC2 AMIs)
  can be a hassle
• Utilizing pooled provisioning and programmatic
  API’s, your provisioning process can be
  centralized and simple
• Maintain a single VM image instance (or EC2
  AMI), and deploy your software from a central
                                      Yes We Can!

Barak H. Obama Image taken from
Rules of thumb for Asterisk Virtualization
 • Ensure proper coding techniques to
   lower platform overheads
 • Utilize central pooling provisioning for
   ease of management
 • Make use of programmatic API’s in a
   layered platform approach
 • Ensure proper caching in your
• Contact Information:
  – Nir Simionovich
  – (e)
  – (p) +972-73-2557799
  – (w)
  – (w)
  – (w)
  – (MSN)

Shared By: