[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OT proxy reverso con apache con multiples ip de destino



German Cardozo Chirinos
~ carpe diem ~
On May 2, 2015 3:15 PM, "Camaleón" <noelamac@gmail.com> wrote:
>
> El Sat, 02 May 2015 13:31:32 -0430, German Cardozo escribió:
>
> > 2015-05-02 13:08 GMT-04:30 Camaleón <noelamac@gmail.com>:
> >> El Sat, 02 May 2015 12:43:36 -0430, German Cardozo escribió:
> >>
> >>> 2015-05-02 12:24 GMT-04:30 Camaleón <noelamac@gmail.com>:
> >>
> >> (...)
> >>
> >>>> Otra cosa, mejor reinicia el servidor apache tras los cambios
> >>>> ("service apache2 restart").
> >>>>
> >>>>
> >>> En general, y para este tipo de cambios, no te recomendaría que en
> >>> ambientes de producción se ejecute un "service apache2 restart".
> >>
> >> (...)
> >>
> >> Cierto, pero recargando la configuración no siempre se obtiene el
> >> efecto deseado así que te curas en salud con un reinicio del servicio y
> >> si hay algún error más gordo cuanto lo veas, mejor.
> >>
> >>
> > Debe leerse bien la documentación de Apache httpd. En ambientes de
> > producción, en especial aquellos con mucho tráfico, y a pesar de tener
> > balanceadores (ejemplo haproxy), nunca es recomendable efectuar un
> > reinicio, ya que los navegadores pueden experimentar fallas en sus
> > request, lo que dependiendo del sitio, puede causar molestias
> > innecesarias a sus usuarios.
>
> (...)
>
> Disiento.
>
> Si estás haciendo pruebas y cambios en la configuración de los archivos
> de Apache te expones a que algo deje de funcionar recargues la
> configuración o reinicies así que se supone que lo estás haciendo cuando
> el servidor tiene poca carga de trabajo o en un día de poco tráfico para
> molestar lo menos posible. Siempre será preferible una parada del
> servicico para asegurarse de que todo funciona correctamente.
>

Disiento doblemente... ;)

En ambientes en producción, donde el (o los proxy reversos) deben atender 20 o mas VirtualHost, con diferentes niveles de uso de las aplicaciones, hace díficil abrir ventanas de mantenimiento que incluyan cese del servicio "prolongado" (5, 10, 15 minutos pueden ser largos para ciertos proveedores). Para pruebas, siempre es recomendable tener ambientes de test homologados al de producción, para saber a que nivel los cambios afectan este servicio.

Así mismo, la activación de nuevos servicios "al vuelo", es una gran ventaja en sistemas muy dinámicos, escalables y a gran escala. Apache httpd soporta desde hace tiempo estos cambios, y su mecanismo para hacerlo es bastante seguro y confiable.

Respecto a nginx, lo estoy probando aún, pero hay requerimientos de ciertos componentes que manejo, que lo hacen de dificil implementación en la actualidad.

> Saludos,
>
> --
> Camaleón
>
>
> --
> To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive:[🔎] pan.2015.05.02.19.45.11@gmail.com"> https://lists.debian.org/[🔎] pan.2015.05.02.19.45.11@gmail.com
>


Reply to: