El Uptime, o tiempo sin caída de un servicio o un servidor, puede llevar a la gente a hacer cosas rarísimas, pero… ¿hasta dónde tiene sentido el uptime? ¿Qué se debe realizar en pro de tener el mejor uptime? ¿Es necesario tener el servicio siempre arriba a toda costa?
Si os hablo de pasta y os pregunto hasta cuanto debe gastar una empresa en pro de mantener el uptime de sus servidores, rápidamente, al ser fácil entender que la pasta es limitada, todos llegaréis a la conclusión que depende de la criticidad del servicio. Para saber esto, la ecuación que hay que realizar es justo la inversa, ¿cuánta pasta perdemos por cada unidad de tiempo que nuestro servicio o servidor no esté funcionando? La respuesta a esta pregunta marcará el límite superior del gasto.
Otra de las cosas raras que he visto es la de sacrificar las actualizaciones de seguridad. Hace poco nuestro amigo “Pajarraco” de los Santos, sacaba pecho de que su servidor de VoIP llevaba más de 700 días de uptime. ¡¡Eso es todo un record!!
Eso quiere decir que lleva más de 700 días sin parchear el kernel de su Linux, es decir, se ha saltado todas las mejoras y/o actualizaciones de seguridad para su negrita que obligasen reiniciar la máquina.
La pregunta es, ¿realmente es tan crítica la “Negrita” que cuesta más reiniciar que asumir el riesgo? El debate telefónico que tuvimos giró en torno a que si estaba en un entorno controlado o no, donde pudieran ser explotadas o no las vulnerabilidades conocidas o, si merecía aumentar el riesgo de reinicio.
Riesgo de reinicio
Éste es un factor que sí que aumenta el riesgo de que algo no vaya bien, el tiempo de reinicio. Una de las leyes de la disponibilidad es no introducir cosas nuevas que no necesitas pues, cuanto más software, más riesgo de fallo, y no sólo de seguridad. Así, cuando se introducen cambios en el software del sistema operativo, lo más saludable es comprobar que todo arranca bien. Para ello, dentro de los planes de contingencia y de disponibilidad se planifican reinicios programados para comprobar que el software se ejecuta correctamente tras un nuevo reinicio.
¿Y si el servicio es tan crítico que no puede pararse? Supongamos en un determinado momento que la “Negrita” de “Pajarraco” oferta un servicio tan crítico que necesita estar activo el 100% del tiempo. Eso significaría que el tiempo de caída del servicio implica un coste cuantificable en la organización lo que nos llevaría a presupuesto para implementar alguno de los servicios de redundancia y disponibilidad de los que tanto se conoce hoy en día. Un par de negritas clusterizadas o un buen sistema de replica off-line o un servidor en stand-by que tome el control cuando la negrita se reinicie.
¿Debemos volvernos locos por el uptime? ¿reiniciaríais vosotros la negrita para comprobar que todo va a ir bien en caso de necesidad o dejaríais que la Negrita siguiera hasta que “pase algo” y ver que pasa entonces?
Saludos Malignos!
PD: Sergio, por favor, cuando reinicies… cuéntanos cómo te fue.
Si os hablo de pasta y os pregunto hasta cuanto debe gastar una empresa en pro de mantener el uptime de sus servidores, rápidamente, al ser fácil entender que la pasta es limitada, todos llegaréis a la conclusión que depende de la criticidad del servicio. Para saber esto, la ecuación que hay que realizar es justo la inversa, ¿cuánta pasta perdemos por cada unidad de tiempo que nuestro servicio o servidor no esté funcionando? La respuesta a esta pregunta marcará el límite superior del gasto.
Otra de las cosas raras que he visto es la de sacrificar las actualizaciones de seguridad. Hace poco nuestro amigo “Pajarraco” de los Santos, sacaba pecho de que su servidor de VoIP llevaba más de 700 días de uptime. ¡¡Eso es todo un record!!
Eso quiere decir que lleva más de 700 días sin parchear el kernel de su Linux, es decir, se ha saltado todas las mejoras y/o actualizaciones de seguridad para su negrita que obligasen reiniciar la máquina.
La pregunta es, ¿realmente es tan crítica la “Negrita” que cuesta más reiniciar que asumir el riesgo? El debate telefónico que tuvimos giró en torno a que si estaba en un entorno controlado o no, donde pudieran ser explotadas o no las vulnerabilidades conocidas o, si merecía aumentar el riesgo de reinicio.
Riesgo de reinicio
Éste es un factor que sí que aumenta el riesgo de que algo no vaya bien, el tiempo de reinicio. Una de las leyes de la disponibilidad es no introducir cosas nuevas que no necesitas pues, cuanto más software, más riesgo de fallo, y no sólo de seguridad. Así, cuando se introducen cambios en el software del sistema operativo, lo más saludable es comprobar que todo arranca bien. Para ello, dentro de los planes de contingencia y de disponibilidad se planifican reinicios programados para comprobar que el software se ejecuta correctamente tras un nuevo reinicio.
¿Y si el servicio es tan crítico que no puede pararse? Supongamos en un determinado momento que la “Negrita” de “Pajarraco” oferta un servicio tan crítico que necesita estar activo el 100% del tiempo. Eso significaría que el tiempo de caída del servicio implica un coste cuantificable en la organización lo que nos llevaría a presupuesto para implementar alguno de los servicios de redundancia y disponibilidad de los que tanto se conoce hoy en día. Un par de negritas clusterizadas o un buen sistema de replica off-line o un servidor en stand-by que tome el control cuando la negrita se reinicie.
¿Debemos volvernos locos por el uptime? ¿reiniciaríais vosotros la negrita para comprobar que todo va a ir bien en caso de necesidad o dejaríais que la Negrita siguiera hasta que “pase algo” y ver que pasa entonces?
Saludos Malignos!
PD: Sergio, por favor, cuando reinicies… cuéntanos cómo te fue.
Hoy en día, sobre todo con la guerra abierta de la virtualización entre unos y otros, yo creo que se da más importancia al uptime de la que realmente tiene.
ResponderEliminarUna cosa es que un servicio tremendamente crítico deba estar operativo constantemente (que digo yo que para eso se crearon los entornos de alta disponibilidad) y otra que nos ceguemos en que la maquina que alberga los servicios no pueda reiniciarse nunca para aplicar actualizaciones de seguridad.
Personalmente creo que una buena administración pasa por equilibrar la necesidad de disponibilidad del servicio con la necesidad de mantener el entorno actualizado.
De todas formas no siempre se pueden poner las maquinas con redundancia (sobre todo por un tema presupuestario) y hay que apretarse los machos y esperar a que no se caiga nada ni haya un problema de seguridad que se hubiese solucionado con una actualización y un reinicio.
De todas formas, al final, la planificación de un reinicio de un servidor es algo que entreaña tantos problemas burocraticos que casi es mejor esperar a que la maquina se caiga y aguantar el chaparrón :P
Un gran Blog Chema!!!
Chema: en el caso que contaba Sergio está muy claro. Un servidor VoIP que use hardware de telefonía analógica y/o digital y no necesite de conexión a Internet no precisa de actualizaciones. ¿Para que instalarlas? La única posible intrusión sería local. Si que me quedé con la duda cuando leí el articulo de Sergio es de si permitían conectarse a la centralita desde casa para teletrabajar. En ese caso si podría existir un riesgo potencial que te obligara a introducir actualizaciones en SIP e IAXY (los protocolos comunes que usa Asterisk) que no precisen de reinicio pero que te obliguen a vigilar los cambios introducidos.
ResponderEliminarEso si, si un día la máquina se escacharra y no arranca, basta con haber sido lo suficientemente precavido como para haber hecho una copia de seguridad en bruto en un momento estable. Mucho mejor si ya se tiene directamente sobre un disco duro convencional: un Linux sin entorno gráfico se "pincha" en otro hardware cualquiera y arranca a funcionar sin problemas. Yo he "rearrancado" servicios críticos que estaban funcionando en un IBM Netfinity de gama alta pinchando directamente el disco en un clónico de mala muerte mediante este sistema y sin ningún problema.
Por cierto, tocando este tema: ¿recuerdas esa promesa de Spectra de sacar un servidor sin entorno gráfico?¿para el 2015 tal vez? :-)
Hay que mirar el uptime con reservas... yo estoy contigo que no vale de nada tener un exchange 4.5 funcionando desde los tiempos de Dinio y Marujita y un uptime de narices por no decir de cojones.
ResponderEliminarLos "usuarios" están muy bien acostumbrados, "todo funciona bien y ese es el estado natural de las cosas", no amigos, precisamente el estado natural de las cosas es que fallen: a la Nasa le explotan transbordadores, a Ferrari se le rompen motores y la mayoría de nosotros contamos con una infraestructura - perdón, presupuesto - que no llega ni al nivel del que pone cafés en algún sitio de esos... Pero como informáticos que somos, nuestro orgullo nos hace instalar,configurar,optimizar,rentabilizar lo último de lo último, lo más de lo más... y todo eso con presupuesto limitado y sin caídas?? Al final nos toca lo de siempre, 3 de la mañana, café en vena, desde casa realizar las actualizaciones y mantenimientos que no se pueden hacer en horas normales y rezar para que ningún usuario necesite la cosa más rara del mundo en el mismo momento que se produce el reinicio.
Si acritud...:o) Feliz 2009
Christian Hdez.
"Josemaria: Por cierto, tocando este tema: ¿recuerdas esa promesa de Spectra de sacar un servidor sin entorno gráfico?¿para el 2015 tal vez? :-)"
ResponderEliminarNo, el año pasado :)
Server core
Fernando: ¿en serio?¿el server 2008 puede funcionar ya sin entorno gráfico? Pues no ha recibido nada de publicidad ¿tan mala ha sido la acogida? Yo pensaba que iba a tener mucho éxito...
ResponderEliminarcualquier dia de estos los amantes de las consolas y aborrecedores del entorno gráfico os dareis cuenta de que al final, el tiempo que ahorra el entorno gráfico, bien merece el consumo de dicho entorno...
ResponderEliminarPara todo lo demas, 2008 Server Core, a ver si leemos un poquito (aunque lo de sin entorno grafico...)
PD: Feliz año :D
Josemaría, que tienes el Server 2008 core xDDD, aunque realmente filemaster tiene razón, el entorno gráfico te ahorra una cantidad de tiempo y de comandos que no te imaginas, para hacer algunas cosas en el 2008 Core es una odisea, eso si...la herramientas mas preciada de los Windows (Notepad) no la han quitado :P
ResponderEliminarFilemaster: no seas sectario. Yo no aborrezco nada, sólo quiero tener la libertad de elegir y, para mi, un entorno gráfico en un servidor web o de bases de datos es absolutamente superfluo. Si tú lo necesitas yo jamás me meteré con ello.
ResponderEliminarEn cuanto al 2008 core, he estado leyendo el enlace que ha mandado fernando y veo que la funcionalidad es limitada y que realmente el entorno no "desaparece" del todo... Tal vez por eso no ha tenido la repercusión que debiera. ¿Lo habéis probado "en serio" alguno?¿La funcionalidad que proporciona el nuevo shell es buena o hace falta usar terminal server y/o MSC para todo?
Eso quiere decir que lleva más de 700 días sin parchear el kernel de su Linux
ResponderEliminarNo necesariamente: ksplice
Un saludo,
Pedro
¿quien ha dicho que en linux hay que reiniciar despues de parchear el kernel?...
ResponderEliminarUn par de aclaraciones: todo está absolutamente parcheado, programas y kernel (en especial el Asterisk, lógicamente). No se ha reiniciado por tanto supongo que algunos parches del kernel no se han aplicado realmente.
ResponderEliminarEn este entorno concreto el riesgo tiende a cero. Los únicos fallos documentados por ahora de mi kernel son elevación de privilegios local, pero no tengo usuarios locales ni servicios al exterior. Los fallos remotos que hayan existido en el kernel, no tienen tampoco efecto porque se han aplicado las contramedidas necesarias, algunos directamente no me afectan, y además, como dice josemari, he creado copias de seguridad estables.
Y como el riesgo entonces tiene a cero, me gusta simplemente evaluar la estabilidad a través del uptime. ¡Chema sensacionalista!
@amperis, puedes parchear el kernel en caliente, pero los cambios rularán cuando se arranque con ese kernel. Funcionan igual los parcheos en Windows.
ResponderEliminarXavales,yo con mi server de andar por casa con XP,he llegado a tener un uptime de mas de 60 dias, a ver si lo repito y pongo una foto.
ResponderEliminar@maligno
ResponderEliminarMirate el enlace que he puesto antes. Se puede parchear un kernel de linux (2.6.x ) sin reiniciar.
Un saludo,
Pedro
Tengo mis dudas sobre qué es peor, si los muggles obsesionados con el uptime a toda costa, o los informáticos que se hacen los héroes del día/empleado de la semana y paran un servicio para aplicar un parche sin pensarlo.
ResponderEliminar@Pedro, lo primero agradecerte el link al paper, es SUPERCHULO. En segundo lugar, cómo has visto, es una tecnología bastante peculiar y bastante lejos de como actualizar un servidor.
ResponderEliminarLo que hacen los amigos es parchear el kernel en caliente utilizando una técnica basada en lo que realizan los rootkits para parchear los kernels y hacer "otras cosas", pero como ellos dicen en el paper, en muchas de las actualizaciones se ven obligados a escribir código para hacerlo rular.
Esto mismo se puede realizar con Windows (no hace falta que te cuente que la tecnología rootkit se migró con éxito a Windows) pero dista bastante lejos de ser un plan de actuliación abordable hoy en día.
Repito, un paper superchulo, Gracias!
Precisamente Raymond Chen, en su columna de la edición de noviembre de 2008 de TechNet Magazine, expuso motivos por los que, con respecto a Windows, es preferible forzar un reinicio para reemplazar un archivo en uso. La otra opción, la "cohabitación" de la versión antigua (cargada en memoria, en procesos que se están ejecutando) y la "parcheada" durante un tiempo determinado, no está exenta de problemas a pesar del cuidado que se pueda haber tenido para mantener la compatibilidad.
ResponderEliminarWindows Confidential: Windows Can but Won't
Verificación: glalioli. ¿Gladiolos con all-i-oli? :-P
Estimado Chema. Tener un servicio (que reside en un servidor) con una vulnerabilidad crítica no es tenerlo Uptime, si no vulnerable.
ResponderEliminarSin parcheo ni reinicio ya puedes tener el servidor todas las horas que quieras (y el servicio activo) que no debería estar orgulloso nadie de ello, si no avergonzado de tener tanto tiempo a su empresa con el culo al aire
Saludos
@Ramon Sola
ResponderEliminarEstamos de acuerdo que si es una
actualización del Kernel (Windows o Linux) lo más fácil es hacer un reinicio y a seguir. Pero no me digas que si hay una actualización del IIS, IE, mediaplayer tengo que reiniciar el ordenador. Eso es una chorrada que debería mejorarse ya.
Por ejemplo sabes que si tengo un Apache (en Linux, claro) y tengo una actualización del Apache o del PHP o lo que sea no tengo que reiniciar el ordenador, reinicio el servicio y "fieshta".
Realmente me parece chorrada tener que reiniciar cada vez que actualiza cualqueir mariconada , y sino lo haces te jode todo el día.
Feliz año
http://blogs.zdnet.com/open-source/?p=2333
ResponderEliminarLa verdad es que no he llegado a probarlo, pero siempre lo he visto útil para parcheos de urgencia de máquinas críticas... claro que si no lo usáis ni los superpartners no creo que me anime ;-).
ResponderEliminarhttp://technet.microsoft.com/en-us/library/cc781109.aspx
@Josep, te digo lo mismo que le he dicho a Pedro y también te aplica el comentario de Ramón Sola.
ResponderEliminar@ramandi, cuando llegue el entorno concreto que te fuerce usar algo así lo usarás, mientras tanto un reinicio garantiza muchas cosas. ;)
Saludos!
@Sergio: si no quieres reiniciar a cada actualización de kernel hazlo de forma periódica pero no lo tengas 2 años "olvidado". Tu ansiada disponibilidad te puede llevar a lo contrario, si se te cae la máquina cuando menos te lo esperasm, en el peor momento (leyes de Murphy), y luego resulta que por cualquier cosa no arranca. Por ejemplo, imagina que se te va la luz y vuelve, ¿arranca tu server? ¿Seguro? :)
ResponderEliminarLo menos que te pasará es que te tardará bastante en arrancar porque te saltará el chequeo del filesystem por llevar no se cuantos días sin chequear ;-) Lo más, como he dicho, es que ni arranque (y si te pilla fuera de la ofi, en horas que no hay nadie, etc...).
Yo casi siempre hago este tipo de verificaciones en los servers que instalo; a la larga, ahorras tiempo y problemas :-)
-r