15 Oct 09 Astricon 2009 – Glendale, AZ – Part II

Ok, it’s day 1 (or actually day 2) for AstriCon 2009 – and here’s my report for the day.

Yesterday was kind’a of a hectic day for me, as I was teaching a full day track of Asterisk and Cloud Computing, specifically, implementing Asterisk systems with Amazon EC2. I started the day with a class filled with 20+ people, and ended the day with a similar number – so in general I’m very happy. Not many people tend to attend the pre-conference days, so having that number of people and their positive reactions through out the day were very reassuring to me.

If there is one thing I’ve learned from this experience, it is the following: If you give a full day track, don’t arrive at the hotel 24 hours prior to it – you need at least 48 hours! People didn’t really notice (I hope), but through out the day I was suffering from a splitting headache – one that would usually send me right into bed with a couple of Advil’s. But hey, that didn’t stop me and I powered through it, I’m fairly proud of myself for doing so – as at the end of the day I regained back my strength and was livelier.

Today was the first official day of the conference – I gave the opening talk for the Cloud Computing track of the day. My talk was about how to build “IP Centrex” like services, without building an “IP Centrex”. I guess that I didn’t really introduce a brand new concept, but actually talked about something that many are thinking about, but are not inclined to try it on their own and burn some cash on. I guess my talk helped them out saying: “Hey, we’re not talking out of our asses here, this guy makes some sense and what we thought of isn’t that far fetched”.

Previous to that, Digium announced the 2009 Digium innovation award winners, where my company won an award in the pioneer category. This is the second year in a row my company had won the award, and I’m really happy with being acknowledged for this specific work. Having being a part of the community for over 7 years now, this award, at least to me personally, says a lot – it’s basically saying: “Look, you’ve done good, you’ve done some work that really helps out the project and the community in general – here’s a beer and a toast to you – hip hip” – well, that’s kind’a of a mouth full, but you get what I mean. I think that this is actually the place to mention that the award was for developing a high-powered Dialer/IVR platform, used in the Israeli elections and the work was contracted for a company called Shtrudel.

The all conference party is tonight – so I better rest up and be ready for it – should be fun. I guess beer and food are always a good mix when a bunch geeks are getting together

Tags: Amazon, Amazon EC2, Asterisk, Business, Cloud computing, digium, EC2, GreenfieldTech, Innovation Award, Virtualization, VMWARE

14 May 09 Asterisk and Amazon EC2 – Amoocon Presentation

I recently gave a presentation at the Amoocon convention, held in Rostock, Germany – about Asterisk and Amazon EC2. Below is a medium quality video of that presentation:

or you may download it here:
Amazon EC2 and Asterisk video files

Tags: AGI, Amazon, Amazon EC2, Asterisk, Cloud computing, Dialers, economy, GreenfieldTech, php, PHPAGI, Virtualization, VMWARE

07 Feb 09 Virtualizing Asterisk – Digium Asterisk World, Feb 2008

Well, I just got back from the ITExpo show in Miami, Florida. I have to admit that I really enjoyed the venue, although I didn’t really have time to walk the floor. The main reason that I was unable to walk the floor was due to the fact that I gave a talk, as part of the Digium Asterisk World venue, which was co-located with TMCnet’s ITExpo.

My talk was about the possibilities and incentives for Virtualizing Asterisk using VMWARE and Amazon EC2. Following below is the presentation that I gave.

Virtualizing Asterisk – Presented at Digium Asterisk World, Feb 2008, Miami, Florida

Tags: Amazon EC2, Asterisk, Dialers, digium, Greenfield Technologies, GreenfieldTech, openVZ, PokeTalk.Com, VMWARE, XEN

21 Jan 09 Thoughts of virtualization – Part III

Ok, it’s been almost 24 hours since I started my serious playing around with Amazon EC2, and I can honestly say that I’m tired – however, I’m very pleased with my results. Like any other experiment, this one started with a requirement. The requirement was to install and operate one of the dialer frameworks I’ve written in the past year on an EC2 based instance. In order to evaluate the process, let’s start with our baseline installation, meaning, what am I using in the real-world:

Hardware and Software Specification

The original machine answered to the following specification: Quad Core CPU, 2GB of RAM, 250GB of Hard Drive. My original machine was running CentOS 5.2 with an x86_64 kernel installed. In terms of software installed, we had Asterisk 1.4.22.1, MySQL 5.X, PHP, FreePBX, Apache and my dialer framework.

Introducing Amazon EC2 AMI

An EC2 AMI is basically an image of a computer, contained with a single installation manifest on the Amazon cloud computing system. AMI’s provide for the simplest manner to start using EC2, as these usually include a pre-defined server installation, that usually has some stuff already installed.

Choosing your AMI

Amazon provides a multitude of AMI’s to work with, unfortunately, most of these are either out-dated and the sheer number of these makes the choice somewhat overwhelming. I decided to start working with a working AMI image of Fedora Core 8, that already had the LAMP stack installed – the one I used was:

The YUM Repository issue

For some strange reason, the AMI images contained in the Amazon repository are all unable to perform any updates to their installed RPM packages. It took me a while to understand what’s wrong, but in general, the fedora project had simply removed the old releases from their repository, so I had to go in and manually modify the /etc/yum.repos.d/ configuration files. For you convenience, here is the repos list that I’m using at this point:

YUM Repositories for Amazon EC2 Fedora images <- click this to download the file

[development]
name=Fedora Core $releasever - Development Tree
baseurl=http://archives.fedoraproject.org/pub/archive/fedora/linux/core/development/$basearch/
enabled=1
gpgcheck=0

[extras-development]
name=Fedora Extras $releasever - Development Tree
baseurl=http://archives.fedoraproject.org/pub/archive/fedora/linux/extras/development/$basearch/
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras
gpgcheck=0

[extras]
name=Fedora Extras $releasever - $basearch
baseurl=http://archives.fedoraproject.org/pub/archive/fedora/linux/extras/$releasever/$basearch/
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras
gpgcheck=1

[updates-testing]
name=Fedora Core $releasever - $basearch - Test Updates
baseurl=http://archives.fedoraproject.org/pub/archive/fedora/linux/core/updates/testing/$releasever/$basearch/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-test

[updates-released]
name=Fedora Core $releasever - $basearch - Released Updates
baseurl=http://archives.fedoraproject.org/pub/archive/fedora/linux/core/updates/$releasever/$basearch/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora

[base]
name=Fedora Core $releasever - $basearch - Base
baseurl=http://archives.fedoraproject.org/pub/archive/fedora/linux/core/$releasever/$basearch/os/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora

If you are trying to install an instance, you may use the above for any Fedora based AMI on EC2.

Creating my own AMI

While going about and building a single server is fun, I needed a way to create my own installation AMI once I’ve completed my modifications. The Amazon EC2 resources website gives out a whole lot of information, which can be somewhat confusing for the first time reader. So, I searched for a better way to construct my own AMI image. I found the following web page, which was really really helpful: Azeez’s Notes.

Azeez’s blog gives a very concise and to the point, step by step, guide to building your own AMI image – it got me up and running in less than 10 minute – WAY TO GO AZEEZ.

So far, so good …

So far my installed instances are working just fine and I’m currently operating a cluster of a few of these dialer systems. I’m in the process of checking what kind of mileage I’ll get from the EC2 instances, in comparison to a real hardware server – which is really interesting.

My main objective here is to be able to build a dialer-on-demand framework, which will enable my customers to increase their capacity utilizing a simple web interface to initiate my AMI instances. I’ll report back with additional information once I have it.

Tags: Amazon, Asterisk, Cloud computing, dialer, EC2, Virtualization, VMWARE

15 Dec 08 Thoughts of Virtualization – Part III – Multiple Asterisk Gateways

While this post is titled “Thoughts of Virtualizaiton”, the applications described can be easily applied to non-VM type installations.

Virtualization is a wonderful tool, it enables rapid growth and rapid deployment of new servers and services. However, just like any other platform that tends to grow across the time line, it poses the same annoying issue of managing a large system, especially when dealing with Asterisk based installations.

Let us imagine the following scenario: A Calling Card company while utilizes 8 different Asterisk application servers, are utilizing a single Database servers cluster and are receiving inbound calls from various sources and load balanced across all Asterisk application servers. What I’ve described above is more or less the practice most (if not) all calling card operators deploy. No matter if the usage is A2Billing, MOR, ASTBILL – the methodology is more or less the same.

One of the bigger issues with such an installation is debugging of a running session, more over, the ability to debug a session after it is finished. This situation is caused by a simple, yet annoying issue, we are operating within a “zero-knowledge” system, where we have no precognition of where a specific call will be handled utilizing our cluster. Now, if you are an experienced sysadmin, you would most probably do the following:

1. SSH to all your Asterisk servers.
2. Tile all consoles on your desktop.
3. Start the test – and hope your eyes are fast enough to capture the right gateway.

Well, this is the normal practice with most people – but I have to admit it’s kind of annoying. Now, let’s imagine that we are now building our system from scratch, we’re not using A2Billing or any of the other Open Source products, we simply build our own application framework. So, what do we need to do in order to keep track of our system correctly?

Step 1: Consolidate

Consolidate the messages coming from each of your gateways to a single logging facility. The best track would be to utilize some form of Syslog facility. For example, all the scripts and network services that I develop utilize a clear and concise interface to syslog. I usually re-direct the syslog facility that I use to an external server, thus, I get all the logs on a single syslog file system.

If you are worried about I/O issues on the syslog server, you can always create a “syslog-proxy” using tools such as memcached or others.

Step 2: Identify

Your syslog write function should always include a prefix indicating the name of the generating Asterisk server. For example, have something like the following prefix your syslog entry:

Dec 14 21:51:32 pbx [PBX01/6d6d6423a2244aa71980e5a5b437919e/check_pincode[22537]: agiParameters: check_pincode

While the syslog facility will include your generating hostname, when duplication VM’s, this would be a really good practice.

Step 3: Analyse

Once your logs are consolidated to a single environment, it should be fairly simple for you to go about and analyse these in a pre-defined routine. There is little to gain from analysing the logs on-the-fly, but analysing it every 5/10/15 minutes will prove worthwhile.

Step 4: Audit

Auditing is good – as long as you keep a clear view of what you audit and what you don’t. Audit key points in your application to a database can save you a whole lot of time of debugging – just make sure your audit is clear.

Keep the above in mind and you should be just fine creating any scale of platform.

Tags: AGI, Asterisk, scaling, syslog, Virtual Server, VM, VMWARE