Yujuuu!
Pues sí, un título un poco «hollywood movie«, pero creemos que la ocasión se lo merece jijiji Al menos, nos lo estamos creyendo por aquí 😉
Seguramente, si estáis leyendo este post, habréis vivido esta misma situación:
- Al iniciar un nuevo proyecto, bien sea grande, o al contrario tipocirugía de precisión, o un hack especial o incluso un desafío en general, lo más más más importante es el nombre ! De alguna forma es lo que nos motiva en el viaje, darle un nombre que evoque un sentimiento del equipo, un feeling, un target, un libro o una película que ilustre de alguna manera nuestro brain status actual 😉
Así que en: Beyond Thunderdome! En alusión a Mad Max, no tanto por estar asilvestrados y cowboy way of life (que ya dijimos que todavía no hemos llegado a ese punto), sino mas bien por ese punto de salir del loop / anti-loop split horizon hacia un nuevo continente 😉 A parte de que porque el nombre mola y punto jijiji
El viaje que iniciamos
El caso es que este otoño-invierno, ha sido bastante movido, vivimos un VoIP2Day2016 realmente intenso, a todos los niveles. Nos vinimos un poco arriba con una demo in realtime de un escalado de IVOZ Provider llegando a unos 12 AS’s y un volumen alto de CPS y llamadas concurrentes.
Y, acto seguido, la LibreCon 2016 asistiendo a una charla de los «Cloud Architects» de ACKSTORM (un abrazo desde aquí), nos contagiaron esa energía que transmiten y ese «dale dale !» que iba manteniendo en vilo a a la audiencia mientras ilustraban su forma de trabajar con la infraestructura definida por software y como un GIT PUSH acababa desplegando una infraestructura grande.
Todo eso nos ha impregnado de mucha energía y ganas de escalar, y sobre todo, de compartir con toda la comunidad nuestros resultados, no sólo de hacer demos sin detalles del escenario. Para llegar a esos valores hay cierto tuning que realizar o cuellos de botella que a priori no lo parecen.
Así que este viaje que queremos iniciar con vosotros es, esto mismo, hacer el camino del escalado de IVOZ Provider al andar, juntos 😉
Nuestros compañeros
Hace ya cierto tiempo que iniciamos por aquí las anduras con containers / micro-servicios, y la verdad que la distribución vía Docker, tanto para pruebas como para producción, es algo que tenemos en mente y en el road-map, pero, no tan inmediato como las ganas que teníamos de compartir esto, a parte de que tenemos varios clientes que no están pidiendo con relativa urgencia si podemos llegar o no a cifras superiores.
En cuanto a la perspectiva de alto nivel:
- Cloud Engine: Dicho esto, hemos optado por OpenStack, que hoy por hoy nos permite cierta flexibilidad, como cloud engine.
- Cloud Provider: Como proveedor de Cloud, ya que somos partners oficiales de OVH 🙂
Aterrizando a lo que es real y «se puede compilar» 😉 lo iremos comentando en este mismo post, poco a poco, para no revelar todos los personajes con early media 😉
Sobre este punto:
Nuestros más sinceros agradecimientos a OVH y en concreto a Fernando Ramos por hacernos el rise to the max en el servicio OVH Cloud.
El destino
El destino, con total sinceridad, no lo sabemos, de mientras que vamos escribiendo este post, nos vamos haciendo push entre nosotros para llegás más allá. Lo que si sabemos es que para el caso de éxito del voip2day2014 (hace ya 3 años!) presentamos una solución testada y documentada (muy muy en detalle) para 100 000 end users.
Nos hemos marcado 250K como cifra redonda, porque al menos doble o nada, siendo de Bilbao, es algo a lo que tenemos que jugar 😉
Etapa inicial: Análisis de comportamiento
Seguramente no seremos los primeros que hablamos en alguna reunión de un 15-20% de cálculo de ocupación para sector empresarial, y datos similares.
Pero para este viaje, hemos querido ser bastante fieles al uso que se le da actualmente a las soluciones de Hosted PBX / Virtual PBX / Cloud PBX:
- Hemos cogido los datos de uso de un proveedor cercano, de tamaño medio (< 10 000 subscribers).
- Y con ello, nuestros calculitos, lo más reales posibles.
Los datos que hemos obtenido, que serán los que simularemos:
Tipología general de llamadas
| Tipo de llamada | Reparto |
| Llamadas internas | 23% |
| Llamadas externas entrantes | 32% |
| Llamadas externas salientes | 45% |
Tipología de llamadas entrantes
De todas las llamadas que entran de forma externa, el reparto sería:
| Tipo de encaminamiento en entrada externa | Reparto |
|---|---|
| Directas a usuario | 16% |
| Grupo de salto, cola | 71% |
| IVR | 13% |
CPM’s, CPS’s
| Usuarios | CPM |
|---|---|
| 1 usuario (media real) | 0,025265285 |
| 250 000 usuarios (extrapolado) | 6316,32 |
| 500 000 usuarios (extrapolado) | 12632,6 |
Haciendo la división fácil por segundo, emulando un comportamiento empresarial esperado, estamos hablando de 105 CPS a meterle a la granja de SIPP’s, hablando en claro.
Empresas, Usuarios
Hasta aquí, datos de uso de la plataforma, en cuanto a cantidades, la media que hemos sacado de este tipo de plataformas es de unos 15 usuarios (así sale un número redondo) por empresa. Por tanto, en nuestro target tendremos 17000 empresas creadas de 15 usuarios cada una.
Next step: La terraformación!
Al igual que en Alien los colonos tenían como misión la terraformación, por aquí nos hemos marcado tb el mismo target 😉
Fuera bromas, dentro de todas las opciones y nombres techies con mucho hype que pueblan la nueva cultura cloud, la gente de HashiCorp se lo ha currado mucho con Terraform.
Su tagline: WRITE, PLAN, AND CREATE INFRASTRUCTURE AS CODE
De alguna forma, en la misma línea que lo que vamos sintiendo en estos lares profesionales, tan bien definido por Javier Domingo en la LibreCon 2016:
«Si, es así, la guerra entre la gente de sistemas y los desarrolladores ha acabado ya por fín, y han ganado los desarrolladores. Es así.»
Terraform va a ser el agente director en el área de cloud deployment, ya que soporta perfectamente OpenStack, tanto vía NOVA como NEUTRON, así que nos encaja perfectamente: Definir el escenario en un fichero .tf y hacer que se cree mágicamente 😉
En líneas generales, ilustrando lo que queremos montar con Terraform:
Continuemos … Discovering Services!
Si, somos conscientes, hemos comentado que este no era el post ni la prueba final con todo dockerizado, y estamos utilizando muchas de las techies de dicho mundo 😉 Vamos, que ni de lejos están pensadas sólo para containering, es mas bien algo planteado hacia el universo cloud y lo que aparece o muere como efímero, bien sean instancias o contenedores.
Para la ocasión, dentro de lo más o menos conocido:
Lo que más nos encaja por aquí es Zookeeper, pero de cada a este target de Beyond Thunderdome, queremos ir con algo mas planteable y más «it just works» de cara a ilustrar todo el path, así que dicho esto, es lo que hemos seleccionado 😉
No se trata de nada en producción de alto rendimiento y Alta Disponibilidad, así que basta con arrancarlo en un único server.
Previamente, hemos definido los servicios que queremos que se haga discovery, definición para nosotros mismos, porque con Consul no es necesario pre-definirlos:
root@routerthunderdome:~/consul# cat consul.d.sample/*
{"service": {"name": "applicationserver"}}
{"service": {"name": "data"}}
{"service": {"name": "proxytrunks"}}
{"service": {"name": "proxyusers"}}
Nos olvidamos de la parte web, por el momento, ya que es mas bien «consumidora» y no «productora» ni necesaria en el call flow standard, se podría hablar en otro post de HAPROXY’s, WAF’s como bien describía Koldo Aingeru de Sarenet.
Y el arranque, lo dicho, nos olvidamos de clusterizar, recordemos que vamos por el páramo a todo velocidad con el Interceptor 😉 Así que un arranque rápido:
./consul agent -server -data-dir /tmp/consul -bootstrap-expect 1 -bind 10.60.120.1 -dns-port 53 -domain ivozprovider -recursor 8.8.8.8 -config-dir=consul.d/
En cuanto a los paráms:
- Arrancamos un agente de tipo server
- Con bootstrap (iniciando la arch del DC), y con un 1 server.
- El tema de recursor es para permitir de paso que resuelva DNS externos, así es más easy2go, y en el 53 udp 😉
Para arrancar un agente, por ejemplo en la instancia de tipo Application Server:
./consul agent -bind 10.60.120.37 -join 10.60.120.1 -data-dir /tmp/ -config-dir consul.d/
Y en cuanto a config.d, tenemos ahí definido que somos un AS:
cat consul.d/applicationserver.json
{"service": {"name": "applicationserver"}}
A modo de pruebas, arrancamos un AS y tenemos:
root@routerthunderdome:~# dig @127.0.0.1 applicationserver.service.ivozprovider ; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> @127.0.0.1 applicationserver.service.ivozprovider ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42730 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;applicationserver.service.ivozprovider. IN A ;; ANSWER SECTION: applicationserver.service.ivozprovider. 0 IN A 10.60.120.37 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Dec 10 22:17:50 CET 2016 ;; MSG SIZE rcvd: 72
Así que ya estamos, arrancamos una decenita para ir probando, le damos terraformación 😉 tal que:
$ cat thunderdome-miniasgroup.tf
resource "openstack_compute_instance_v2" "applicationserver" {
count = 10
name = "applicationserver"
image_id = "83ed5335-268a-463f-9c73-e6a7bf743664"
flavor_id = "98c1e679-5f2c-4069-b4da-4a4f7179b758"
network {
name = "IVOZPROVIDER_THUNDERDOME_PRIVATE"
}
}
y basta con un terraform apply para que se construyan esos 10 AS iniciales, que se registraran vía Consul
Tras spawnearlos (con nova se puede ir viendo como van en otra consola, Terraform tb se queda en hook hasta que se crea todo), comprobamos el status via consul (atacando por DNS o por API, lo que queramos):
;; ANSWER SECTION: applicationserver.service.ivozprovider. 0 IN A 10.60.120.38 applicationserver.service.ivozprovider. 0 IN A 10.60.120.39 applicationserver.service.ivozprovider. 0 IN A 10.60.120.40 applicationserver.service.ivozprovider. 0 IN A 10.60.120.41 applicationserver.service.ivozprovider. 0 IN A 10.60.120.42 applicationserver.service.ivozprovider. 0 IN A 10.60.120.43 applicationserver.service.ivozprovider. 0 IN A 10.60.120.44 applicationserver.service.ivozprovider. 0 IN A 10.60.120.45 applicationserver.service.ivozprovider. 0 IN A 10.60.120.46 applicationserver.service.ivozprovider. 0 IN A 10.60.120.47
Si matamos aleatoriamente alguna de las instancias, al momento vemos que ya no están en el pool 😉
Se suman compañeros al viaje: Los reporteros STATSD, Graphite, Grafana !
El caso es que hacer este viaje sin tener una bitácora que analizar luego, no tendría mucho sentido 😉 Así que sumamos a nuestro viaje el stack completo habitual para la obtención de métricas, ya que por supuesto:
Su aporte
La verdad es que buscando referencias por términos tan de moda como DEVOPS y similares, aparecen muchos esquemas de arquitecturas, el que más nos ha convencido para ilustrarlo aquí y continuar la aventura es este de Igor Cicimov , cogido de su página de GITHUB:
La idea principal y el tema de de enviar y olvidarse de statsd nos encaja muy bien en arquitecturas en la que puedes o no estar vivo y si no hay conexión mejor que mejor, así no hay que preocuparse de nada. De la misma forma, añadir métricas sin tener que modelar ningún data schema es algo realmente apeticible 😉
Sea como fuere, es algo que en Asterisk ya está soportado, así como en Kamailio desde hace casi 3 años.
De la misma forma, hacerse un probe de cualquier métrica es algo tan trivial como:
echo "foo:1|c" | nc -u -w1 127.0.0.1 8125
Y listo, ya está, ya podremos usar dicha métrica. Un poco de aterrizar los average time value y tal y listo.
Los soldados de asalto: SIPP
Todos los que estamos por estos lares, hemos buceado una y otra vez con SIPP, utilizando los built-in scenarios y construido a mano los escenarios, con los asuntos de Asterisk, como los ReInvites de liberación de media path y de fin de de diálogo de la pataba de su mundo B2BUA, para conectarlo consigo mismo 😉 Vamos, que unas cuantas sesiones de SNGREP bastan para ver que los flujos no son Request Invite, 100 trying, Ringing, 200 OK / ACK, BYE/200 OK, sino con algo mas de mesh 😉 jiji.
Continuando con el concepto de dangerous demos, o, evitando lo que bien ilustraba en su magistral charla del Voip2Day 2016 nuestro gran amigo Saghul («Si, he preparado una demo con un video, algo de derechas, conservadora«), hay que añadirle media, es decir: RTP! Si, porque no sólo de SIP va el tema, por mucho ICE para aquí y para allá, La realidad es que es en el mundo de los SIP Hardphones y arquitecturas de Provider, todavía no ha llegado y a saber si llegará o si directamente dejarán de existir y será todo WebRTC y fin de la cita.
Sea como fuere, para poder gestionar bien la prueba con media, en SIPP lo que hace falta es un PCAP con el rtp, disponibles varios por acá si no queremos estar con el bisturí de PCAP’s.
Photobook final 😉
La verdad es que este post hemos tardado mucho tiempo en cerrarlo, con tanto frente por aquí no lo estábamos priorizando nada de nada 😉 Hemos llegado a la cumbre de la montaña hace tiempo, pero todo la escenografía/atrezo y descripciones que queríamos ir comentando en el viaje no la tenemos tan bonita como quisiéramos. Así que, para al menos cerrarlo y no alargarlo más os planteamos por aquí directamente los resultados obtenidos.
En cualquier caso, y sabéis que estaremos por el Voip2Day 2017, así que o por el stand o en el networking o en las cervezas podemos comentar cualquier tema de escalado y tb asuntos que todavía no hemos indagado en exceso como behind nat y políticas de auto-escalado de Google Cloud Platform o AWS o similares, vamos, que hay mucho de lo que se puede hablar 🙂
Photofinish
[[ No Filter 😉 ]]]
- 250K subscribers
- XXX cps
Nos vemos pronto
Lo dicho, estamos realmente con mucho trabajo pero avanzando tb varios frentes, que esperemos podamos compartir pronto por acá 😉
Gracias !
Queremos tu opinión :)