Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Sobre cómo gestionamos centenares de despliegues de VoIP

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Cargando en…3
×

Eche un vistazo a continuación

1 de 53 Anuncio

Sobre cómo gestionamos centenares de despliegues de VoIP

Descargar para leer sin conexión

Ponencia presentada por Héctor Prieto (Coordinador de Soporte) y Gorka Gorrotxategi (CTO de VoIP) de Irontec durante la edición de 2019 de VOIP2DAY celebrada en Málaga.

Una charla que repasa la dilatada experiencia de Irontec en el ámbito de la VoIP. Una empresa en constante crecimiento y con cientos de despliegues a sus espaldas desde 2006. Se centra fundamentalmente en los aspectos más técnicos, detallando los diferentes retos que hemos ido teniendo que superar. En ella, hablamos de monitorización avanzada específica o de automatismos multi entorno desde el plano de las devOps.

En este sentido y, entre otros desafíos a los que nos hemos enfrentado a lo largo de nuestra trayectoria, explicamos algunas de las decisiones técnicas que hemos tenido que tomar para asegurar un crecimiento importante de plataformas.

La conferencia fue impartida en conjunto por el responsable de soporte de nuestro equipo de comunicaciones, a cargo de un amplio equipo humano especialista en los diferentes componentes VoIP open source, tales como Asterisk, Kamailio, SEMS, IVOZProvider, SNGREP y derivados, acompañado por el responsable técnico del área.

Ponencia presentada por Héctor Prieto (Coordinador de Soporte) y Gorka Gorrotxategi (CTO de VoIP) de Irontec durante la edición de 2019 de VOIP2DAY celebrada en Málaga.

Una charla que repasa la dilatada experiencia de Irontec en el ámbito de la VoIP. Una empresa en constante crecimiento y con cientos de despliegues a sus espaldas desde 2006. Se centra fundamentalmente en los aspectos más técnicos, detallando los diferentes retos que hemos ido teniendo que superar. En ella, hablamos de monitorización avanzada específica o de automatismos multi entorno desde el plano de las devOps.

En este sentido y, entre otros desafíos a los que nos hemos enfrentado a lo largo de nuestra trayectoria, explicamos algunas de las decisiones técnicas que hemos tenido que tomar para asegurar un crecimiento importante de plataformas.

La conferencia fue impartida en conjunto por el responsable de soporte de nuestro equipo de comunicaciones, a cargo de un amplio equipo humano especialista en los diferentes componentes VoIP open source, tales como Asterisk, Kamailio, SEMS, IVOZProvider, SNGREP y derivados, acompañado por el responsable técnico del área.

Anuncio
Anuncio

Más Contenido Relacionado

Similares a Sobre cómo gestionamos centenares de despliegues de VoIP (20)

Más de Irontec (20)

Anuncio

Más reciente (20)

Sobre cómo gestionamos centenares de despliegues de VoIP

  1. 1. Gestionando cent/milesGestionando cent/miles de soluciones VoIPde soluciones VoIP Héctor Prieto Gorka Gorrotxategi
  2. 2. Somos IrontecSomos Irontec   16 años 60 personas en el equipo   Cientos de proyectos producidos con éxito Miles de líneas de código escritas   Desde 2005 con el focus en VoIP   Varios productos importantes liberados: IVOZProvider, SNGREP, IVOZBusiness ...
  3. 3. ... y nosotros... y nosotros Gorka Gorrotxategi CTO Héctor Prieto Coordinador Soporte
  4. 4. Quizás nos conozcáis deQuizás nos conozcáis de otras charlas por aquí ;)otras charlas por aquí ;) 2009 Presentamos el MSCTL en primicia ;) 2016 Horizontal Escaling Anycall2AnyAsterisk 2017 Automated Testing en aplicaciones VoIP/RTC 2018 Crónica de un viaje de Alta Disponibilidad
  5. 5. ¿Por qué esta charla?¿Por qué esta charla?
  6. 6. ¿Por qué esta charla?¿Por qué esta charla? Como en otras ocasiones, queríamos plantear algo técnico, pero sin alejarnos demasiado de la órbita terrestre ;) El año pasado, hablando con muchos de vosotros era el tipo de charla que nos pedíais, cómo gestionar las situaciones habituales, sin entrar en grandes escenarios avanzados ni nada especial. En 2019 los conceptos de los que hablaremos (automatismos, DevOps, escalado ...) están ya más que asentados. Y con ello, damos visibilidad a nuestro gran equipo de soporte, liderado por mi compañero Héctor Prieto, ¡gracias equipo!
  7. 7. Antes de empezar algunasAntes de empezar algunas de nuestras cifras...de nuestras cifras... ¡Estas cifras no paran de crecer día a día gracias a nuestros clientes!
  8. 8. Antes de empezar algunasAntes de empezar algunas de nuestras cifras...de nuestras cifras... 5.000 Proyectos desplegados en total desde 2003. Anualmente 1.800 clientes iteran con nosotros . 15.000 casos gestionados. Infraestructuras 1.200 sistemas monitorizados. 36.000 servicios supervisados. Infra propia (AS BGP propio) y ajena, muchísimo networking. ¡Estas cifras no paran de crecer día a día gracias a nuestros clientes!
  9. 9. Nuestro equipo :)Nuestro equipo :) Técnic@s multidisciplinares Gente con ganas de hacerlo realmente bien Somos técnicos y pensamos como tal (nada de 1,2,3) Cada problema puede resolverse de diferentes formas, hay que buscar la más eficiente o adecuada para cada cliente. Valor de equipo, mente colmena, la información reside en el organismo general Objetivos basados en resultados de calidad Funcionando no significa resuelto. Apoyar la formación continua y certificaciones
  10. 10. Mostrar flujos de trabajo habituales. Metodologias usadas y validadas por el equipo durante la resolución de problemas. Diferentes técnologias que explotamos para realizar diferentes tareas. Si quiere llevar a cabo cualquier tarea aqui mencionada consúltelo previamente con su equipo de técnico. Consideraciones previas al consumo de VOIPConsideraciones previas al consumo de VOIP
  11. 11. Los 3 Big Bosses a los que nos enfrentamosLos 3 Big Bosses a los que nos enfrentamos
  12. 12. Cantidad Criticidad Diversidad
  13. 13. [I]Nuestras armas[I][I]Nuestras armas[I]
  14. 14. Gestionando la cantidad...Gestionando la cantidad...
  15. 15. Se notifican decenas de situaciones constantemente: Alarmas generadas Intervenciones/nuevas solicitudes Consultas VoIP specifics Con todo lo que ello conlleva El gran problema: la simultaneidad y variedad Nuestro día a díaNuestro día a día Entonces... ¿qué proponemos?
  16. 16. "El plan""El plan" Apostar por soluciones sostenibles SIEMPRE El problema de un cliente puede llegar a ser el de muchos Apostar por adelantarse: e.g. la calidad global de voz (MoS) es medible y debe hacerse Las claves: Procedimientos claros: Flujos que sigue la información Protocolos perfectamente definidos Desde Ingeniería debe hacerse llegar toda la información relativa a los despliegues, así como toda la documentación junto con la formación al equipo de soporte La cantidad sólo se puede derrotar con: ORDEN ORDEN y ORDEN.
  17. 17. Distinguimos dos fasesDistinguimos dos fases Fase Preventiva Fase Correctiva Dentro de estos dos marcos de trabajo es dónde pondremos en práctica nuestro plan
  18. 18. Fase preventivaFase preventiva Tareas desde el orden y  la tranquilidad Actualizaciónes de software Repositorios propios / externos Todo está paquetizado/dockerizado Mantenimientos de hardware Checks propios basados en datos SMART/lifetime esperada Gestión Documental Documentación actualizada Flujo continuo con ingeniería Propuestas de mejora/updates Nada es para siempre
  19. 19. FaseFase combativacombativa correctivacorrectiva Suenan las alarmas! We are working on it! Informar al cliente Análisis del problema Gráficos de estado/rendimiento Logs y capturas de los sistemas Diagnostico diferencial Comprensión real del problema ¿Reinicia y listo? NO, NO, NO, NO JAMÁS! Bajo pena de prisión permanente revisable. Call GDB Ninjas!
  20. 20. Vale, lo tengo... ¿Ahora qué?Vale, lo tengo... ¿Ahora qué? Evaluación del impacto de la solución Aplicación definitiva de la solución ¿Puede desplegarse ahora en el cliente? Una vez aplicada la solución: Tests funcionales Informar al cliente ¿Ya lo había dicho ? :) Documentar Si varios proveedores gestionan la solución, mantener informado al cliente es clave
  21. 21. Reflexiones post apocalípticasReflexiones post apocalípticas Está solucionado y funcionando. Pero JAMÁS se acaba ahí el proceso, hay que plantearse: Problema NO detectado ¿Podría haberse detectado? ¡Seguro que sí! Opciones de control Generar marcadores o indicadores, entender si es algo tipo "abismo instantáneo" o "bañera que desborda" ;) Documentar, documentar y documentar Problema detectado ¿Esto puede llegar a suceder en otro cliente? Propagar la solución al resto de clientes   El trabajo NUNCA acaba aquí.
  22. 22. Conviviendo con la diversidadConviviendo con la diversidad
  23. 23. Evolución de las infraestructuras VOIPEvolución de las infraestructuras VOIP En Irontec hemos seguido el mismo path que much@s de vosotr@s: En los inicios pequeñas empresas, entornos con menos integraciones, menos networking. Evolucionando paulatinamente: Decenas de sedes, networking propio (MPLS, VPNs, L2's, ...) Integraciones complejas Arquitecturas HA, híbridas... Soluciones de operador, wholesale... alto tráfico en definitiva Cada cliente requiere de un tipo de sistema de telefonía que puede acabar evolucionando y los tiempos cambian.
  24. 24. Diferentes conceptos de arquitectura que evolucionan con el tiempo y específicos de cada criterio: Cloud propio, Cloud ajeno, híbrido, full in-House. Diferentes usos: Multitenancy, dedicado Diferentes enfoques Virtualizado, dockerizado ... Diferentes tecnologías VMWare, Citrix, Hyper-V, Proxmox(KVM) Diferentes proveedores (empresas partícipes) Cloud Storage, BBDD, Networking ... En definitiva, mucha ingenieria social :d Arqui/Infra VoIP: Evolución continuaArqui/Infra VoIP: Evolución continua
  25. 25. En búsqueda del Santo GrialEn búsqueda del Santo Grial Carta a los reyes magos Multi-entorno Fácil gestión Fácil uso Sin agentes Libre Flexible Algo actual, vivo, sin EOL
  26. 26. Algunos de nuestros pasos para gestionar la diversidad Puppet Requiere agente en todos los nodos Compleja programación de escenarios / no tan flexible Lo seguimos usando: Integrar Foreman como inventariado de fácil acceso Chef Poca flexibilidad, requiere de tareas programadas Uso complejo SaltStack Requiere agente en todos los nodo ... por dónde hemos ido pasando... por dónde hemos ido pasando
  27. 27. ANSIBLE, tu nuevo mejor amigoANSIBLE, tu nuevo mejor amigo ¿Por qué ansible? No requiere de agentes, ssh y fin Flexible y programable, hooks por todos los lados Fácil de mantener Pocos Requerimientos de mantenimiento Gestionar listados de máquinas Integración con datos de negocio (ERP's) / herramientas de inventariado (Foreman) Gestionar Playbooks Definición de tareas/automatismos
  28. 28. PlaybooksPlaybooks ¿Qué nos permite hacer? Básicamente: alcanzar la simultaneidad desde la centralización Despliegue de software Si lo queremos exclusivamente para esto quizás Puppet sea mejor camino Activación de automatismos (cambios config) Obtención de información que escapa al concepto de inventariado Todo ello de forma scripteable, con hooks, control de errores
  29. 29. Entendiendo la criticidadEntendiendo la criticidad
  30. 30. ... criticidad es monitorización... criticidad es monitorización Es el corazón del equipo de soporte Aporta una visibilidad TOTAL de la salud de los sistemas Herramienta vital para: Medir SLA's y actuar en consecuencia Ver evolución. Podemos adelantarnos a los problemas Esto aporta un valor añadido increíble Como todo, los excesos... Es mandatory tener bien controlado el bosque, evitar que  la niebla nos nuble la vista ;) Lo admitimos, estamos OBSESIONADOS. Y creemos que así debe ser :)
  31. 31. Monitorización/actuación local Monitorización remota Diferenciamos dos tipos ¿Qué nos aporta cada una de ellas?
  32. 32. Monitorización local descentralizadaMonitorización local descentralizada   Nuestra visión: Nos permite obtener información del host de forma rápida Nos permiten actuar de forma local sin depender del entorno remoto (tipo watchdog) Inconvenientes: Los entornos están tendiendo a containerización , donde todo es efímero y todo está orquestado "por alguien" En caso de desastre, pierdes el acceso a esa información [Forensic IT] Las alertas las genera el propio host donde esta instalado, en caso de  fallo...                                       
  33. 33. NetdataNetdata Standalone option Low footprint Tons of metrics Zeroconf ;) Very pluggable One-line install
  34. 34. ObserviumObservium SNMP Network oriented Tons of metrics Auto discovery https://www.observium.org/
  35. 35. ¿Los descartamos entonces no?¿Los descartamos entonces no? Definitivamente no Pueden convivir perfectamente con otros sistemas centralizados mas avanzados Aportan información extra Bajo (ínfimo) consumo de recursos. En caso de total aislamiento [OON] seguimos recopilando información
  36. 36. Monitorización remota centralizadaMonitorización remota centralizada Es el modelo de monitorización por excelencia. Toda la información agrupada en un único sistema lista para ser explotada. - "Escalabilidad" - En caso de desastre tenemos toda la información. Existen multitud de opciones, todas ellas con sus pros y contras: Pandora FMS Icinga Zabbix Monit DataDog SpiceWorks Centreon   Pero antes....Pero antes....
  37. 37. El enfoque habitual es monitorizar los recursos/procesos del host/instancia sin tener en cuenta la finalidad de la misma: ESTO NO GARANTIZA NADA CPU Load Memoria FS usage iface's status Process status Monitorización sí, pero conMonitorización sí, pero con SENTIDOSENTIDO
  38. 38. Una instancia es más que una máquina,Una instancia es más que una máquina, es un servicio, es una funcionalidad y eses un servicio, es una funcionalidad y es precisamente así como lo tenemos queprecisamente así como lo tenemos que tratartratar "Estar vivo no significa vivir" Un host que actúa como una PBX, tiene que ser capaz de llamar. Un host que actúa como GW tiene que ser capaz de encaminar.
  39. 39. Monitorización avanzadaMonitorización avanzada Monitorización de tráfico por tipo Menos tráfico SIP|RTP del esperado puede ser un problema, más trafico lo mismo Soluciones de storage remotas: NFS / CIFS / XXX en estado R/W correcto El talón de Aquiles de muchas plataformas es el I/O Media de calidad de llamadas! Control de llamadas de alta tarificación Actividad real de procesos Ocupación de canales en integraciones con PSTN via TDM-SIP CPU Idle Time BBDD accesible y con buena salud (CPS, Slow Queries ...9 Llamadas reales BlackBox SIP (BBS! It's free!) [!] A pesar de todo, Alice tiene que ser capaz de llamar a Bob
  40. 40. Obtener la visión gráficaObtener la visión gráfica El ser humano es muy visual en general y sobre todo ante situaciones de stress Una tabla de 20 líneas y X columnas no aporta jerarquía ni concepto de arquitectura Un esquema siempre aporta información geográfica, datos de dependencias e información contextual vital Si esto lo unimos con la diversidad de entornos, arquitecturas, integraciones con empresas, verlo gráficamente es vital Un esquema vale más que mil tablas
  41. 41. Obtener la foto del pasadoObtener la foto del pasado Es muy habitual que un problema sea reportado a tiempo pasado: Casos que no suceden constantemente No son reproducibles Gracias a toda la información que hemos recopilado durante todo este tiempo podemos analizar el caso concreto sin molestar al cliente ¿Puedes repetir la secuencia que ha provocado el error mientras el resto del mundo se comporta exactamente igual que cuando ha sucedido, por favor?
  42. 42. Métricas, métricas y métricas sobre las métricasMétricas, métricas y métricas sobre las métricas La diferencia entre... "Esto no va muy fino..." "El proceso principal está atorado" "No se qué pasa, pero algo pasa"   ... y...   El proceso XXX tiene un memory leak y está consumiendo más y más memoria El cliente X tiene un pico de llamadas anormal
  43. 43. Señalización SIP Homer Sip Capture Resumen de flujos RTP Jittter Packet Loss Crash debug GNU Debugger (GDB)   Logs de actividad ELK Stack! Métricas TICK stack (y variantes ;)
  44. 44. ArquitecturaArquitectura 4 componentes: Collectors Telegraf, Netdata, custom... Time series databases InfluxDB, Prometheus Frontales web Chronograf, Grafana Alert systems Prometheus Alertmanager, Kapacitor, Grafana Cada punto es un mundo Las alternativas son compatibles entre sí TICK stack example architecture
  45. 45. Ejemplo 1 - Registros SIP
  46. 46. Ejemplo 2 - Alertar ante caídas abruptas del número de registros SIP
  47. 47. Ejemplo 3 - Uso de canales
  48. 48. En conclusión...En conclusión... Claramente marca la diferencia: Podemos dar una explicación sólida, técnica y racional de QUÉ y POR QUÉ ha sucedido Los datos nos avalan: Un respuesta sólida acompañada de toda esta información aporta al cliente SEGURIDAD Trasladar con todo lujo de detalles el tratamiento del caso. El análisis detallado del problema siempre aporta (+), nunca resta (-). NO es una pérdida de tiempo Podemos descubrir la punta del Iceberg Nos hace crecer como profesionales y como proveedores Siempre tenemos que valorar peso del servicio vs debug control No podemos parar un callcenter de 500 personas para debuggear tranquilamente ;)
  49. 49. ¡¡¡ DEMO TIME !!!¡¡¡ DEMO TIME !!!
  50. 50. ¡¡¡ DEMO TIME !!!¡¡¡ DEMO TIME !!! Queremos ilustrar/enseñar: Monitorización externa automática tipo "blackbox" SIP End to End Y todo con contextualización de la información de soporte, de forma integrada Facilidad de obtener gráficas de rendimiento con todas las herramientas basadas en bbdd time series (InfluxDB)
  51. 51. CONCLUSIONES FINALESCONCLUSIONES FINALES Bajo nuestra experiencia: Las plataformas VoIP no difieren de otros sistemas "tics" en cuanto a diversidad y cantidad se refieren. Su gestión diaria se resuelve con el mismo enfoque que aplicaríamos en los casos generales. Los problemas habituales de las plataformas de voz son muchas efímeros: Es fundamental tener knowhow y herramientas que aporten: Visión en tiempo real de forma gráfica y aplicada de forma concisa a todo lo relacionado con la calidad de voz. Foto en el pasado enriquecida.
  52. 52. ¡Muchas gracias!¡Muchas gracias!

×