Con la llegada masiva de los servicios en las nubes, muchos han desplazado los servicios de VoIP hacia servidores remotos para aprovechar mejores prestaciones y ahorrar en los costos de la infraestructura. Otros utilizan servidores locales creando maquinas virtuales según necesidad. Los primeros no tienen/conocen algunos datos que ayudarían a mejorar la configuración, los segundos tienen o pueden obtener este tipo de datos. El primer parámetro importante son las CPU o mejor dicho las CPU virtuales asociadas a cada servidor virtual. Este es un dato que todos los proveedores siempre facilitan al momento de alquilar un servidor y el precio del servidor es directamente proporcional al numero de vCPU escogidas. Un ejemplo:

Un servidor remoto con 1 vCPU, en el caso de Vultr, tiene un costo de 10 dólares, con 2 vCPU 20 dólares, con 4 vCPU 40 dólares; como pueden ver la diferencia de precio es considerable. El segundo parámetro son los ciclos de CPU asignados a cada vCPU del servidor virtual. En los proveedores tipo Vultr, me imagino, que los ciclos son distribuidos de manera igual entre todos los servidores virtuales alojados en el mismo servidor físico. Si no fuera así, al utilizar el servidor virtual con menos ciclos asignados podríamos experimentar, sobre todo, problemas en la calidad del audio de la llamada.

La segunda configuración que puede afectar las prestaciones de la centralita es asociar al proceso de Asterisk PBX mayor prioridad o modificar su valor de nice. Esto, aunque pueda parecer una buena idea, se resuelve en un completo desastre ya que en el momento en que Asteriks tenga que ejecutar operaciones que dependan de una respuesta recibida de otras aplicaciones, servidores, si estas respuestas tardan en llegar pueden saturar los hilos utilizados por la centralita telefónica.

Una opción que puede mejorar las prestaciones de Asterisk es priorizar los paquetes entrantes/salientes a nivel de router/cortafuegos. La configuración de COS/TOS en Asterisk normalmente no ayuda mucho.

Otro parámetro importantes es el tipo y el uso del sistema de almacenamiento de los datos de funcionamientos de Asterisk, es decir tipo y ubicación del disco duro, tipo y ubicación de la base de datos, tipo de configuración y uso de la base de datos, si se graban o no las llamadas, etc. Al momento de configurar/escoger el tipo de almacenamiento, hay que tener en cuenta:

• un acceso lento al sistema de archivos, consultas en la base de datos, pueden ralentizar todo el funcionamiento de Asterisk

• la grabación de llamadas y el funcionamiento del correo de voz causan muchas escrituras en el sistema de archivos

• si se utiliza asterisk Realtime, es decir se configura buena parte de la centralita en una base de datos, hay que calibrar la configuración de la cache de memoria de sorcery (esto para el canal PJSIP)

• Si se utiliza ODBC, el numero de conexiones predefinidas es 1. Aumentar este valor no siempre es una buena idea

• Si el sistema de archivos y/o la base de datos son remotos, revisar siempre el tipo y la calidad de la conexión disponible con estos servicios

• Las utilidades Linux, iotop e iostat, arrojan muchos datos útiles relacionados con las prestaciones del INPUT/OUTPUT del sistema de archivos.

Ahora algunas consideraciones finales basadas en mi experiencia personal:

• Con la mayoría de los proveedores de servidores virtuales remotos que utilizo diariamente, nunca he tenido problemas; estos son VULTR y LINODE. Con DigitalOcean a veces si

• Aumentar el numero de vCPU no aumenta proporcionalmente las prestaciones de la PBX

• El servidor más económico de VULTR y LINODE puede manejar alrededor de 40 llamadas simultaneas sin problemas.

• Si quieren utilizar una base de datos compartida por distintos servidores, utilicen un servidor presente en el mismo centro de datos y trabajen con la IP local en lugar de la IP publica

• Si necesitan cursar más de 40 llamadas simultaneas pongan delante de los servidores Asterisk un Proxy SIP tipo OpenSIPs o Kamailio. En el próximo curso de Kamailio justamente se hablará de este tema.

Vía Asterisk BLOG