Multiple Server Setup

[chrisdbarnett]

Hello, I need some advice please.

We have a goautodial server that runs in our office.

GoAutoDial CE 2.1 | VICI DIal Build: 2.4-309a | Asterisk 1.4.39.1 | No Digium/Songoma Hardware

We are fairly happy it with it and it's really to be used with a low number of agents (Always less than 10).

That system will only ever be for people physically in the office. We want that system to see the internet, but we don't want to open up any ports so that any of the internet can see into that office.

We now wish to start a small cluster with another possible goautodial server on the internet with agents outside of the office, who work from home, connecting to that server.

Knowing that there can only be one MySQL in the cluster and that it must be accessible to all the systems, we have migrated the MySQL to a cloud based server and have firewall-ed it off so that only the right IP addresses from the right servers can connect to it....and yes...the MySQL connection is encrypted.

Now here is where I *might* have some options:

A) Simply provision a leased server in a datacentre (Dual core, 1 GB RAM) - Install goautodial, disable mysql server, update astguiclient.conf with connection details to central MySQL server.

B) Provision a cloud server, rip out MySQL server, leave apache + agent components then provision the hardware server as an Asterisk 1.6 box and declaring it in goautodial

2 Questions

1) Is option B possible?
2) Is option B better than A?

Thanks!

[chrisdbarnett]

Never mind, I have the server so I'm going to play it safe by making it a goautodial server!

[williamconley]

Change to Vicibox. It clusters automatically.

No, you cannot "cloud" vicidial unless your cloud server is a dedicated server (which is not really cloud, per se, it's just a hosted server).

We use Vicibox and Dynamic Good Guys to secure it. No problems at all with security since we built DGG.

http://www.viciwiki.com/index.php/DGG

[gardo]

@williamconley it's possible to "cloud" Vicidial. A complete Vicidial based system can be put in the cloud. It can run on virtual machines (or a cluster of them) handling hundreds of agents.

No, you cannot "cloud" vicidial unless your cloud server is a dedicated server (which is not really cloud, per se, it's just a hosted server).

@chrisdbarnett both are possible. For option A, the latency between the "cloud" mysql and the applications server (Vicidial + Asterisk) ideally should be less than 50 ms.

A) Simply provision a leased server in a datacentre (Dual core, 1 GB RAM) - Install goautodial, disable mysql server, update astguiclient.conf with connection details to central MySQL server.

B) Provision a cloud server, rip out MySQL server, leave apache + agent components then provision the hardware server as an Asterisk 1.6 box and declaring it in goautodial

2 Questions

1) Is option B possible?
2) Is option B better than A?

[williamconley]

@williamconley it's possible to "cloud" Vicidial. A complete Vicidial based system can be put in the cloud. It can run on virtual machines (or a cluster of them) handling hundreds of agents.

No, you cannot "cloud" vicidial unless your cloud server is a dedicated server (which is not really cloud, per se, it's just a hosted server).

We'll have to disagree on that. To date I have not seen an example of a virtual server functioning with more than a few calls (except as a wasted massive server reduced to a single instance of a virtual server at half of the larger server's capacity) nor have I seen an example of a reliable setup that would go past more than a few calls (few being 3 or so) when fully virtual with more than one virtual instance on a single box. I've heard many descriptions of "cloud" and "virtual" vicidial, but they always end up with vague references to where the servers really are and what services are running where and then disappear.

To date I have not heard a single instance of "Yes, I have a GoAuto/Vicibox server running in a Virtualbox/vmWare/vSphere/Xen with 10 agents successfully.for several weeks now" unless it turned out that this virtual server was the only instance in a server that would otherwise be able to handle 25 agents, but has been reduced to 10 agents by virtue of being "virtual". Fitting 10 agents in an 8 core 2.5Ghz machine with 16G RAM is not a "feat", it's a waste. LOL But getting TWO such boxes in the same virtual server would be grand. I'd love to hear that happen.

Dedicated servers in "the cloud" are certainly viable, because they are dedicated servers. But then really they aren't in "the cloud", they are merely servers hosted somewhere other than your office. Or (in some cases), the claim that they are in "the cloud" denotes that they are in a colocation facility that the owner likes to call "the cloud". But that is merely a modification of the definition of the word "cloud". A dedicated server is required to run Vicidial at this point, although some web and other functions can be offloaded for certain configurations. But that's a bit more complex than the average user wants to get into, and not cost-effective in the end since the main component that cannot be virtualized is the one that must be for it to be cost-effective. That would be the Dialer with the Agents and Trunks on it.

So when you say it is "in the cloud", do you refer to a server in your colocation facility, or dedicated server in another colocation facility ... or an Amazon Cloud Instance (not a dedicated server, of course, just a virtual instance on another server ...)?

Details!

[gardo]

Our cloud platform http://justgocloud.com runs on a combination of VMware, OpenVZ and KVM. One of the largest clients (400+ seats) we have runs on our private cloud platform. Op3r can actually confirm this.

The reason you haven't heard of "Yes, I have a GoAuto/Vicibox server running in a Virtualbox/vmWare/vSphere/Xen with 10 agents successfully.for several weeks now" is that noone has ever done it yet but us.

[mflorell]

One of our partners has been running a hosted OpenVZ Vicidial setup for years now in Europe. This has been mentioned a few times here on the forums over the last 3 years. It is stable, but there are complications in how things run that make setup, configuration and maintenance more complex, and its use means that a machine will not have as much capacity as if it were running regular Linux without OpenVZ. Also, if you use the same disk sub-system all of the OpenVZ instances are vulnerable to locking up if one of them locks up the drive sub-system. It is also important to mention that OpenVZ is not a true virtualization environment(like VMware, Xen, etc...), it is a segmented chroot containers environment that has a lot more restrictions in how it can be set up and run. But you do get direct hardware access unlike true virtualization platforms, meaning a proper hardware timer, which is why it can be used for Vicidial agents successfully.

[gardo]

OpenVZ has it's advantages and disadvantages. As you mentioned it can lock up the drive sub-system. We've encountered this too. However, the advantages outweighs the disadvantages. Depending on your configuration, optimization and hardware, you can run multiple instances of Vicidial efficiently. This is actually one of the workarounds where you can run more channels and have more capacity than running Vicidial on a dedicated hardware without virtualization. And you're not bound to the the limits imposed by Asterisk - namely the number of simultaneous channels you can run without succumbing to massive deadlocks.

OpenVZ is just one virtualization platform. It can be combined with VMWare and/or KVM to bring a cloud based Vicidial platform. Redundant, scalable and flexible.

[williamconley]

Our cloud platform http://justgocloud.com runs on a combination of VMware, OpenVZ and KVM. One of the largest clients (400+ seats) we have runs on our private cloud platform. Op3r can actually confirm this.

The reason you haven't heard of "Yes, I have a GoAuto/Vicibox server running in a Virtualbox/vmWare/vSphere/Xen with 10 agents successfully.for several weeks now" is that noone has ever done it yet but us.

This is not "it's running in a virtualbox". This is a vague reference to a complex built system with some components not actually virtual.

And it's not "in the cloud" by any stretch of the imagination.

What you have is a well-thought-out enterprise level group of Vicidial clusters with a proprietary (ie: You have not told anyone ...) group applications run on various portions of cloud-type servers.

When someone thinks of virtual, they are thinking of a vSphere (or other platform) VPS that can be copied to create a new machine easily. If the restriction of a timing card were the only challenge, that may be acceptable. But if it is necessary to have different pieces running on different systems ... well, it is well suited for your operation (and I can see why you don't share easily as it would probably take all your time just answering questions about how complex the system is! LOL).

When someone thinks of "in the cloud", they think shared application resources running across multiple servers. In a way, yours is BOTH but running in your physical location. But I'm not sure running a combination of Virtual Servers and Semi-Virtual servers while using some application sharing technologies but limited to physical machines for some of it ... can be summarized as "it's in the cloud" honestly. Purely my opinion, of course.

Which brings me back to ... at this point, it can't Just be run in a VM or the Cloud. Certainly not easier than just buying or leasing a physical server. And by the time the description is done, it's hard to say which one it is.

I think that's one of the requirements for it to work out. I will say, however, that if you were to share your method (which pieces run on which server types ... etc), you would gain a whole new following. Just like PoundTeam Incorporated would if we were hired to build a system out in that way. Segregating the pieces for "semi-virtualization" and advertising which piece goes where could make the virtualization of Vicidial a reality if it were truly shared. And open up some interesting possibilities, at that.