Configuración estándar de SIP Proxy en Alta Disponibilidad para soportar altos volúmenes de tráfico
David Viamonte
Me gustaría plantear una pregunta que espero que sea adecuada para el foro. Si no lo es, por favor, corregidme.
Estamos planteándonos la instalación y configuración de un conjunto de Proxys SIP (en este caso, Kamailio) en modo Alta Disponibilidad para cursar un volumen de tráfico elevado. Nos estábamos preguntando cuál es la configuración más habitualmente utilizada para este propósito. Se nos ocurren las siguientes posibilidades:
- Configurar un cluster activo-pasivo en que el nodo pasivo asume la carga si se cae el activo. No tenemos claro cómo generalizar esta arquitectura a N nodos si el volumen de tráfico a cursar no puede ser gestionado por un solo nodo activo.
- Configurar un cluster Kamailio con una IP virtual compartida con 2 (o N) nodos en modo activo-activo, de manera que puedan gestionar un volumen de tráfico mayor. No tenemos claro que la configuración estándar de Kamailio esté pensada para funcionar en modo activo-activo, puesto que no hemos encontrado demasiada documentación ni scripts de configuración que tengan en cuenta este caso.
- Configuración de N clusters Kamailio, cada uno de ellos puede contener uno o dos nodos (en este último caso, en modo activo-pasivo), en que el reparto de carga y la protección contra caídas de los nodos se gestiona a través del descubrimiento de servicios SIP vía DNS y donde, por tanto, no es necesario que los nodos compartan una única dirección IP virtual.
Muchas gracias por adelantado y saludos,
David
Iñaki Baz Castillo
<david.v...@genaker.net> escribió:
> Se nos ocurren las siguientes posibilidades:
>
> se cae el activo. No tenemos claro cómo generalizar esta arquitectura a N
> nodos si el volumen de tráfico a cursar no puede ser gestionado por un solo
> nodo activo.
Correcto, esto sólo sería una solución de failover/redundancia, nada
de balanceo de carga.
> 2. Configurar un cluster Kamailio con una IP virtual compartida con 2 (o N)
> nodos en modo activo-activo, de manera que puedan gestionar un volumen de
> tráfico mayor. No tenemos claro que la configuración estándar de Kamailio
> esté pensada para funcionar en modo activo-activo, puesto que no hemos
> encontrado demasiada documentación ni scripts de configuración que tengan en
> cuenta este caso.
¿Te refieres a ambos kamailios escuchando en la misma IP? Si fuese
tráfico HTTP seguro que hay mil inventos para que eso funcione, pero
con tráfico SIP (supongo que habrá UDP) eso es muy problemático
(imagina que un usuario envía el INVITE a un Kamailio, recibe un 486 y
el ACK le llega al otro Kamailio, que obviamente no sabía nada de esa
transacción).
> 3. Configuración de N clusters Kamailio, cada uno de ellos puede contener uno o
> dos nodos (en este último caso, en modo activo-pasivo), en que el reparto de
> carga y la protección contra caídas de los nodos se gestiona a través del
> descubrimiento de servicios SIP vía DNS y donde, por tanto, no es necesario
> que los nodos compartan una única dirección IP virtual.
Ésta es, en mi opinión, la solución más académica, y debería ser la
mejor siempre y cuando tus clientes sepan usar DNS SRV correctamente
(espero que no sean Asterisk o teléfonos con SRV desactivado por
defecto).
Una 4ª solución sería poner un único proxy delante de un cluster de
proxies, y que dicho proxy trabaje stateless. Si trabaja transaction
stateful es todo más fácil, pero consume más memoria. En cualquier
caso nada que no pueda arreglarse aañdiendo RAM. Lo importante es que
dicho proxy sea muy eficiente (que no haga queries DNS, SQL, etc), y
dejar la complejidad y el procesado completo de mensajes al cluster de
proxies tras él.
Saludos.
--
Iñaki Baz Castillo
<i...@aliax.net>
Jose M Recio
Qu� tal si en la 4� alternativa se utiliza un equipo especializado, tipo
F5, Cisco, etc. (supongo que habr� alternativas m�s baratas)?
Supuestamente ofrecen en SIP funcionalidades similares a las de
balanceadores HTTP. Ten�is experiencia al respecto?
On 22/12/11 09:39, I�aki Baz Castillo wrote:
> El d�a 22 de diciembre de 2011 00:50, David Viamonte
> <david.v...@genaker.net> escribi�:
>> Se nos ocurren las siguientes posibilidades:
>>
>> 1. Configurar un cluster activo-pasivo en que el nodo pasivo asume la carga si
>> se cae el activo. No tenemos claro c�mo generalizar esta arquitectura a N
>> nodos si el volumen de tr�fico a cursar no puede ser gestionado por un solo
>> nodo activo.
> Correcto, esto s�lo ser�a una soluci�n de failover/redundancia, nada
> de balanceo de carga.
>
>
>> 2. Configurar un cluster Kamailio con una IP virtual compartida con 2 (o N)
>> nodos en modo activo-activo, de manera que puedan gestionar un volumen de
>> tr�fico mayor. No tenemos claro que la configuraci�n est�ndar de Kamailio
>> est� pensada para funcionar en modo activo-activo, puesto que no hemos
>> encontrado demasiada documentaci�n ni scripts de configuraci�n que tengan en
>> cuenta este caso.
> �Te refieres a ambos kamailios escuchando en la misma IP? Si fuese
> tr�fico HTTP seguro que hay mil inventos para que eso funcione, pero
> con tr�fico SIP (supongo que habr� UDP) eso es muy problem�tico
> (imagina que un usuario env�a el INVITE a un Kamailio, recibe un 486 y
> el ACK le llega al otro Kamailio, que obviamente no sab�a nada de esa
> transacci�n).
>
>
>
>> 3. Configuraci�n de N clusters Kamailio, cada uno de ellos puede contener uno o
>> dos nodos (en este �ltimo caso, en modo activo-pasivo), en que el reparto de
>> carga y la protecci�n contra ca�das de los nodos se gestiona a trav�s del
>> descubrimiento de servicios SIP v�a DNS y donde, por tanto, no es necesario
>> que los nodos compartan una �nica direcci�n IP virtual.
> �sta es, en mi opini�n, la soluci�n m�s acad�mica, y deber�a ser la
> mejor siempre y cuando tus clientes sepan usar DNS SRV correctamente
> (espero que no sean Asterisk o tel�fonos con SRV desactivado por
> defecto).
>
>
> Una 4� soluci�n ser�a poner un �nico proxy delante de un cluster de
> proxies, y que dicho proxy trabaje stateless. Si trabaja transaction
> stateful es todo m�s f�cil, pero consume m�s memoria. En cualquier
> caso nada que no pueda arreglarse aa�diendo RAM. Lo importante es que
> dicho proxy sea muy eficiente (que no haga queries DNS, SQL, etc), y
> dejar la complejidad y el procesado completo de mensajes al cluster de
> proxies tras �l.
>
>
> Saludos.
>
>
--
Jos� M Recio
Co-Founder - http://blog.solaiemes.com
re...@solaiemes.com
Iñaki Baz Castillo
<re...@solaiemes.com> escribió:
> Qué tal si en la 4ª alternativa se utiliza un equipo especializado, tipo F5,
> Cisco, etc. (supongo que habrá alternativas más baratas)? Supuestamente
> ofrecen en SIP funcionalidades similares a las de balanceadores HTTP. Tenéis
> experiencia al respecto?
Es que, como decía antes, HTTP es muy fácil de balancear: pones un
balanceador a nivel IP, TCP o HTTP (un proxy) y a correr. El cliente
hace su conexión TCP/HTTP, pide algo y lo recibe, y opcionalmente
mantiene la conexión permanentemente.
En SIP eso no es así. Si usas UDP a ver cómo haces para garantizar que
el INVITE de un cliente llega al mismo nodo SIP que su ACK (en caso de
que la respuesta final haya sido [3456]XX).
David Viamonte
muchas gracias por la respuesta. Estoy de acuerdo contigo. S�lo una
aclaraci�n adicional sobre el punto 2 (inline).
Saludos,
David
El 22/12/2011 9:39, I�aki Baz Castillo escribi�:
> El d�a 22 de diciembre de 2011 00:50, David Viamonte
> <david.v...@genaker.net> escribi�:
>> Se nos ocurren las siguientes posibilidades:
>>
>> 1. Configurar un cluster activo-pasivo en que el nodo pasivo asume la carga si
>> se cae el activo. No tenemos claro c�mo generalizar esta arquitectura a N
>> nodos si el volumen de tr�fico a cursar no puede ser gestionado por un solo
>> nodo activo.
> Correcto, esto s�lo ser�a una soluci�n de failover/redundancia, nada
> de balanceo de carga.
>
>
>> 2. Configurar un cluster Kamailio con una IP virtual compartida con 2 (o N)
>> nodos en modo activo-activo, de manera que puedan gestionar un volumen de
>> tr�fico mayor. No tenemos claro que la configuraci�n est�ndar de Kamailio
>> est� pensada para funcionar en modo activo-activo, puesto que no hemos
>> encontrado demasiada documentaci�n ni scripts de configuraci�n que tengan en
>> cuenta este caso.
> �Te refieres a ambos kamailios escuchando en la misma IP? Si fuese
> tr�fico HTTP seguro que hay mil inventos para que eso funcione, pero
> con tr�fico SIP (supongo que habr� UDP) eso es muy problem�tico
> (imagina que un usuario env�a el INVITE a un Kamailio, recibe un 486 y
> el ACK le llega al otro Kamailio, que obviamente no sab�a nada de esa
> transacci�n).
�Si Kamailio est� configurado en modo stateless, el ACK no lo trata como
una nueva transacci�n -aunque no conozca el di�logo- y lo enruta como
corresponda? �O al tratarse de un ACK justamente hay alguna implicaci�n
adicional que se me escapa, por ser una transacci�n "especial"? S�lo por
aclarar: en nuestro caso el procesado final de los mensajes lo realiza
un B2BUA, por lo que s�lo estamos hablando de Kamailio como Proxy puro y
duro.
>
>
>> 3. Configuraci�n de N clusters Kamailio, cada uno de ellos puede contener uno o
>> dos nodos (en este �ltimo caso, en modo activo-pasivo), en que el reparto de
>> carga y la protecci�n contra ca�das de los nodos se gestiona a trav�s del
>> descubrimiento de servicios SIP v�a DNS y donde, por tanto, no es necesario
>> que los nodos compartan una �nica direcci�n IP virtual.
> �sta es, en mi opini�n, la soluci�n m�s acad�mica, y deber�a ser la
> mejor siempre y cuando tus clientes sepan usar DNS SRV correctamente
> (espero que no sean Asterisk o tel�fonos con SRV desactivado por
> defecto).
>
>
> Una 4� soluci�n ser�a poner un �nico proxy delante de un cluster de
> proxies, y que dicho proxy trabaje stateless. Si trabaja transaction
> stateful es todo m�s f�cil, pero consume m�s memoria. En cualquier
> caso nada que no pueda arreglarse aa�diendo RAM. Lo importante es que
> dicho proxy sea muy eficiente (que no haga queries DNS, SQL, etc), y
> dejar la complejidad y el procesado completo de mensajes al cluster de
> proxies tras �l.
>
>
> Saludos.
>
>
David Viamonte
de los timers.
El 22/12/2011 10:17, David Viamonte escribi�:
Iñaki Baz Castillo
<david.v...@genaker.net> escribió:
>> ¿Te refieres a ambos kamailios escuchando en la misma IP? Si fuese
>> tráfico HTTP seguro que hay mil inventos para que eso funcione, pero
>> con tráfico SIP (supongo que habrá UDP) eso es muy problemático
>> (imagina que un usuario envía el INVITE a un Kamailio, recibe un 486 y
>> el ACK le llega al otro Kamailio, que obviamente no sabía nada de esa
>> transacción).
>
> nueva transacción -aunque no conozca el diálogo- y lo enruta como
> corresponda? ¿O al tratarse de un ACK justamente hay alguna implicación
> adicional que se me escapa, por ser una transacción "especial"? Sólo por
> aclarar: en nuestro caso el procesado final de los mensajes lo realiza un
Si te refieres a un ACK para un 2XX dicho ACK es siempre una nueva
transacción, pero si es un ACK para un [3456]XX es parte de la misma
transacción (mismo Via branch).
En el segundo caso, el Request-URI del ACK debe ser el mismo que el
del INVITE, y el proxy stateless debe estar configurado de tal forma
que siempre lo rute al mismo sitio (ya que él no sabe de
transacciones, ni hablar ya de diálogos que ni los menciono).
Para esto hay módulos en Kamailio (como el Dispatcher) que distribuyen
los requests entre varios nodos detrás del proxy de forma stateless, y
para asegurarse de que requests pertenecientes a la misma transacción
llegan al mismo server, rutan en base a ciertos parámetros constantes
(como el Call-ID, From-tag, etc).
David Viamonte
Kamailio para que el algoritmo de routing haga que la transacci�n ACK
acabe llegando al mismo nodo del backend que el resto de transacciones
del di�logo (que entiendo que es lo que estamos haciendo ya) no deber�a
haber problema en que un ACK en particular pueda circular por un
Kamailio del front-end diferente de por donde han circulado INVITE y
[3456]xx. �Estoy endendiendo correctamente?
El 22/12/2011 10:22, I�aki Baz Castillo escribi�:
> El d�a 22 de diciembre de 2011 10:17, David Viamonte
> <david.v...@genaker.net> escribi�:
>>> �Te refieres a ambos kamailios escuchando en la misma IP? Si fuese
>>> tr�fico HTTP seguro que hay mil inventos para que eso funcione, pero
>>> con tr�fico SIP (supongo que habr� UDP) eso es muy problem�tico
>>> (imagina que un usuario env�a el INVITE a un Kamailio, recibe un 486 y
>>> el ACK le llega al otro Kamailio, que obviamente no sab�a nada de esa
>>> transacci�n).
>> �Si Kamailio est� configurado en modo stateless, el ACK no lo trata como una
>> nueva transacci�n -aunque no conozca el di�logo- y lo enruta como
>> corresponda? �O al tratarse de un ACK justamente hay alguna implicaci�n
>> adicional que se me escapa, por ser una transacci�n "especial"? S�lo por
>> aclarar: en nuestro caso el procesado final de los mensajes lo realiza un
>> B2BUA, por lo que s�lo estamos hablando de Kamailio como Proxy puro y duro.
> Si te refieres a un ACK para un 2XX dicho ACK es siempre una nueva
> transacci�n, pero si es un ACK para un [3456]XX es parte de la misma
> transacci�n (mismo Via branch).
>
> En el segundo caso, el Request-URI del ACK debe ser el mismo que el
> del INVITE, y el proxy stateless debe estar configurado de tal forma
> que siempre lo rute al mismo sitio (ya que �l no sabe de
> transacciones, ni hablar ya de di�logos que ni los menciono).
>
> Para esto hay m�dulos en Kamailio (como el Dispatcher) que distribuyen
> los requests entre varios nodos detr�s del proxy de forma stateless, y
> para asegurarse de que requests pertenecientes a la misma transacci�n
> llegan al mismo server, rutan en base a ciertos par�metros constantes
Iñaki Baz Castillo
<david.v...@genaker.net> escribió:
> Mmm. Vale, entonces entiendo que, si configuramos el Dispatcher de Kamailio
> al mismo nodo del backend que el resto de transacciones del diálogo (que
> entiendo que es lo que estamos haciendo ya) no debería haber problema en que
> un ACK en particular pueda circular por un Kamailio del front-end diferente
> de por donde han circulado INVITE y [3456]xx. ¿Estoy endendiendo
> correctamente?
Eso es.
Por otra parte, el resto de requests (los in-dialog, incluyendo el ACK
a un 200) ya llevan en su Request-URI el destino concreto del
server/nodo que le haya respondido por lo que no hay ya problemas de
routing.
Jon Bonilla
Iñaki Baz Castillo <i...@aliax.net> escribió:
> El día 22 de diciembre de 2011 10:28, David Viamonte
> <david.v...@genaker.net> escribió:
> > Mmm. Vale, entonces entiendo que, si configuramos el Dispatcher de Kamailio
> > para que el algoritmo de routing haga que la transacción ACK acabe llegando
> > al mismo nodo del backend que el resto de transacciones del diálogo (que
> > entiendo que es lo que estamos haciendo ya) no debería haber problema en que
> > un ACK en particular pueda circular por un Kamailio del front-end diferente
> > de por donde han circulado INVITE y [3456]xx. ¿Estoy endendiendo
> > correctamente?
>
Si no tenéis backend de db, un kamailio con suficiente RAM y procesadores en
modo statefull es más sencillo y puede manjear un gran cantidad de tráfico.
Aquí es donde entramos en la definición e "gran".
Saúl Ibarra Corretgé
>> 3. Configuración de N clusters Kamailio, cada uno de ellos puede contener uno o
>> dos nodos (en este último caso, en modo activo-pasivo), en que el reparto de
>> carga y la protección contra caídas de los nodos se gestiona a través del
>> descubrimiento de servicios SIP vía DNS y donde, por tanto, no es necesario
>> que los nodos compartan una única dirección IP virtual.
>
> Ésta es, en mi opinión, la solución más académica, y debería ser la
> mejor siempre y cuando tus clientes sepan usar DNS SRV correctamente
> (espero que no sean Asterisk o teléfonos con SRV desactivado por
> defecto).
>
+1.
>
> Una 4ª solución sería poner un único proxy delante de un cluster de
> proxies, y que dicho proxy trabaje stateless. Si trabaja transaction
> stateful es todo más fácil, pero consume más memoria. En cualquier
> caso nada que no pueda arreglarse aañdiendo RAM. Lo importante es que
> dicho proxy sea muy eficiente (que no haga queries DNS, SQL, etc), y
> dejar la complejidad y el procesado completo de mensajes al cluster de
> proxies tras él.
>
Pero asi tienes un unico punto de fallo. Quien balancea el balanceador? ;-)
--
/Saúl
http://saghul.net | http://sipdoc.net
Iñaki Baz Castillo
<sag...@gmail.com> escribió:
>> Una 4ª solución sería poner un único proxy delante de un cluster de
>> proxies, y que dicho proxy trabaje stateless. Si trabaja transaction
>> stateful es todo más fácil, pero consume más memoria. En cualquier
>> caso nada que no pueda arreglarse aañdiendo RAM. Lo importante es que
>> dicho proxy sea muy eficiente (que no haga queries DNS, SQL, etc), y
>> dejar la complejidad y el procesado completo de mensajes al cluster de
>> proxies tras él.
>>
>
> Pero asi tienes un unico punto de fallo. Quien balancea el balanceador? ;-)
Ahí ya es tema de poner el proxy balanceador en cluster activo/pasivo y tal.
Saúl Ibarra Corretgé
Jose M Recio
On 22/12/11 10:16, I�aki Baz Castillo wrote:
> El d�a 22 de diciembre de 2011 10:12, Jose M Recio
> <re...@solaiemes.com> escribi�:
>> Qu� tal si en la 4� alternativa se utiliza un equipo especializado, tipo F5,
>> Cisco, etc. (supongo que habr� alternativas m�s baratas)? Supuestamente
>> ofrecen en SIP funcionalidades similares a las de balanceadores HTTP. Ten�is
>> experiencia al respecto?
> Es que, como dec�a antes, HTTP es muy f�cil de balancear: pones un
> balanceador a nivel IP, TCP o HTTP (un proxy) y a correr. El cliente
> hace su conexi�n TCP/HTTP, pide algo y lo recibe, y opcionalmente
> mantiene la conexi�n permanentemente.
>
> En SIP eso no es as�. Si usas UDP a ver c�mo haces para garantizar que
> el INVITE de un cliente llega al mismo nodo SIP que su ACK (en caso de
> que la respuesta final haya sido [3456]XX).
>
Supuestamente los balanceadores de carga SIP se encargan de eso y
soportan configuraciones clusterizables, etc.
Supuestamente, claro. �Nadie los ha probado?
David Viamonte
Chema, gracias por el apunte de los load balancers "carrier grade".
Aunque no lo habr� aclarado demasiado, impl�citamente estaba planteando
un entorno basado en productos COTS HW y SW OpenSource, pero estoy de
acuerdo en que en ciertos entornos tambi�n tiene sentido lo que comentas.
Gracias de nuevo por todas las contribuciones y dejadme la oportunidad
para desaros unas Felices Fiestas ;-)
Saludos,
David
El 22/12/2011 12:23, Jose M Recio escribi�: