<div dir="ltr">Missed you all at DevCon this year! Happy to chime in on this one, having had some experience with relatively large fleets of Asterisk servers for various purposes. Certainly seen a few themes...<div><br></div><div>* Dialplan versioning and deployment. I have relied on static dialplans with HTTP or func_odbc calls for a majority of larger deployments. Most of this is managed via git, and tagged for release via one of a few pipeline processes. The process of actually releasing it and ensuring the proper version is running can be tricky. We often want to test new dialplan on a small subset of servers in a fleet and so managing multiple versions in production is important. We've build companion apps, made Asterisk servers git deployment targets with post-deployment hooks for reloads, used rsync, etc... to work around this, but all of it feels a little inelegant.</div><div><br></div><div>* Docker/k8s official support. Most of our Asterisk builds are customized in one fashion or another. In the past, that meant building our own packages and deploying with Puppet/Terraform/ugly bash scripts, but increasingly, we've been relying on Docker to deploy, tag, and release, even if that has just meant running Docker daemon on top of a "standard" Linux install. This is vastly easier to orchestrate and manage than building and deploying custom packages or distributing source around and recompiling. It'd be nice to have this available out of the box a little more easily, and targeting a base Docker image that is much, much smaller than CentOS or Debian would be ideal. Our Docker image is several gigabytes to get a base Asterisk build. Something that we could build on Alpine that would dramatically shrink the footprint would be desirable. Kubernetes is a bit newer to most stacks, but it's increasingly being asked for. The temporal nature of networking and IP addressing, at least without additional orchestration tooling, is a barrier to running effectively in k8s.</div><div><br></div><div>* Cluster awareness of peer instances/endpoints. In cases where there is no external SIP registrar, it is desirable to be able to round-robin registrations or otherwise distribute endpoints between cluster nodes. Finding these elements for anything beyond basic call features can be quite difficult and usually requires external application code. Using a shared realtime database with ps_contacts, for instance, doesn't work the way one might expect in this use case, so we end up writing lots of fairly ugly dialplan to account for intra-cluster communications. Similar considerations around dynamic insertion/removal of peer Asterisk instances.</div><div><br></div><div>* AMI/ARI aggregation. We've spent a lot of dev cycles providing a unified view to our application layers that doesn't require app code to have knowledge of node placement inside Asterisk clusters. Often, this has required recreating and aggregating things like device state, notification for call events, and mechanisms for invoking 3rd party call control. The firehose for AMI coming off of 100 busy instances can overwhelm almost any application without some quite impressive-looking gyrations of EventFilters, even if you're scoped to minimum classes.</div><div><br></div><div>* Database dependencies/performance. We've more or less had to acknowledge that direct ODBC links from things like CEL/CDR to Asterisk don't scale well at all. Having dozens to hundreds of nodes writing to databases directly, even when DBs are properly sized, tends to just cause unexpected issues. Clustered databases add another layer of complexity for Asterisk, especially when you want to do maintenance or switch active write nodes. Asterisk lockups due to failures in DB instances are also still a problem. Early solutions tended to be to use haproxy locally on Asterisk instances and control database connectivity from there but more recent solutions have been to use AMI and a messaging pipeline to push CDR, CEL, etc... to ZMQ/Kafka/Kinesis for upstream processing.</div><div><br></div><div>Well.. that's probably enough for one email. :) Certainly not complaining about the state of things nor implying these are Asterisk issues or bugs. These are just major areas of development effort that we expected to and ended up undertaking to make systems work in the hundreds of millions of minutes a month scale.</div><div><br></div><div>J.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 21, 2020 at 2:44 AM Jaco Kroon <<a href="mailto:jaco@uls.co.za">jaco@uls.co.za</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
* in asterisk cli, display instance name to which is attached, in other<br>
words, if the being controlled instance has "systemname => bar" on a<br>
host with hostname "foo", then instead of the prompt being:<br>
<br>
foo*CLI><br>
<br>
Either:<br>
<br>
foo*bar*CLI><br>
<br>
or simply:<br>
<br>
bar*CLI><br>
<br>
Would be great.  This is actually something I should be able to attend to.<br>
<br>
Kind Regards,<br>
Jaco<br>
<br>
On 2020/10/21 10:35, Jaco Kroon wrote:<br>
<br>
> Hi,<br>
><br>
> On 2020/10/20 23:32, Michael Cargile wrote:<br>
><br>
>> Towards the end of DevCon, Matt asked if there were any pain points<br>
>> for provisioning large numbers of Asterisk instances and I mentioned I<br>
>> would talk to my colleague who handles such things. He provided this<br>
>> list:<br>
>><br>
>> * Sanity checks within Asterisk at start up and module reload. this<br>
>> include:<br>
>>      -- Asterisk making sure it has the proper file permission for all<br>
>> directories that it is configured to write / read to<br>
> If this is implemented, this would need to be configurable.  We had a<br>
> check in our init script on Gentoo.  This was switched off.  Most<br>
> deploys was not an issue ... but I think the record we clocked was ~6<br>
> hours startup time just checking /var/spool/asterisk and sub paths. <br>
> Yes, the script could have been improved to not check recursively and<br>
> not descend into sub folders for recordings ...<br>
><br>
> Still, very good and valid suggestion.<br>
><br>
>>      -- verification that things like audio files called from<br>
>> Background / Playback are actually there<br>
>>   If these checks fail throw an error at start up / reload rather than<br>
>> when something is attempted to be accessed so these problems can be<br>
>> addressed sooner<br>
> Some of these names are determined dynamically, especially when multiple<br>
> formats are involved.  One thing that would be nice is at least a syntax<br>
> validation, eg, missing or extraneous brackets and the like.  For<br>
> example ... Set(foo=${bar) <-- obviously invalid, missing }.  Nice to<br>
> have in my opinion though.<br>
><br>
>> * asterisk.conf directory variables for things like audio files are<br>
>> not always honored requiring symlinks as a work around (though this<br>
>> might be the OpenSuSE build of Asterisk causing issues)<br>
> Never encountered this.  And we make heavy use of this (eg, running<br>
> multiple, generally < 100, instances on the same physical and using<br>
> astspooldir => /var/spool/asterisk.uls).  If this was not being honoured<br>
> we'd have issues that we'd only be able to describe as insane critical.<br>
><br>
>> * Reliable module reloading without core restarts<br>
>>      Example: Client lets their SSL certificate lapse on an Asterisk<br>
>> server and they only figure this out when their<br>
>>      agents attempting to log in using WebRTC clients. They have<br>
>> dozens or even hundreds of customer calls in queue,<br>
>>      but their agents cannot login. On Asterisk 13 we cannot fix the<br>
>> SSL certs without a full restart of Asterisk<br>
>>      which drops these calls. A reload of the http module does not fix<br>
>> this.<br>
> Sean mentioned this fixed, looking at the diff, http module reload will<br>
> now be adequate.  And PJSIP from what I can tell don't suffer this<br>
> issue.  chan_sip loads certificates at accept() time.<br>
><br>
> Trying to confirm chan_sip I did find that the setting of sip_reloading<br>
> = FALSE happens in an odd place ... will check that out a bit later.<br>
><br>
> And then I'd like to also add:<br>
><br>
> * reduction of idle-instance CPU usage (which seems to be running @<br>
> ~0.7% of a core generally when asterisk is doing "nothing" - obviously<br>
> variable based on CPU clock speed).  Not a major problem when running<br>
> one or two instances, but does create an artificial upper limit, and<br>
> there are measurable power implications when running hundreds of<br>
> instances in the same rack.<br>
><br>
> Kind Regards,<br>
> Jaco<br>
><br>
><br>
>><br>
<br>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div>