jueves, 26 de febrero de 2015

Las disponibilidad de un sistema o el cómo esto se caiga ¡¡¡¡ es el apocalipsis !!!

Continuo con mis rollos de informática. Para el que no le guste le pondría aquí un enlace al Playboy, a la prensa o una recomendación de libros interesantes pero como en España hay una ley infame que dice que por enlazar hay que pagar a una organización con comportamientos poco edificantes que van a cobrar sean o no socios de ella, pues mira, te vas al buscador que más te guste y buscas algo más ameno.

Rollo al canto ... que no me vea.
Pues nada, vamos a meternos en harina. Para cualquiera que hayas desarrollado o trabajado con un sistema de información le sonará el término disponibilidad o lo que es lo mismo, cuantas horas al día tiene que estar funcionando un sistema y en caso de parada cuánto tiempo puede estar parado sin impactar al negocio de manera significativa. Por lo general la respuesta del usuario es la misma: 

¡¡¡ MI SISTEMA ES LO MÁS IMPORTANTE DEL MUNDO
Y NO SE PUEDE PARAR JAMAS !!!

Lo gracioso es que eso te lo puede decir por ejemplo el encargado del sistema o parte del mismo encargado de pagar los recibos en ventanilla en el banco. Si, ese señor tan joputa simpático que ha decidido que sólo se pueden pagar recibos en ventanilla los martes cuyo día del mes sea par de las semanas bisiestas entre las 08:00AM y las 08:15AM, eso siempre que el día siguiente no sea miércoles e impar. Por supuesto que necesita su sistema arrancado 7x24 y con un SLA (acuerdo de nivel de servicio) de 30 segundos (o menos) Y claro, como el que gestionaba los costes de contabilidad hacía trampas y lo metía todo en el mismo saco, este señor tenía su 7x24 funcionando por todo el morro y sin costarle un euro directamente.

Es curioso que sistemas tan críticos que no se pueden parar nunca resulta que hasta su mecanización o hasta que se modificaron solo iban de 8 a 3 y de lunes a viernes. Y si la cosa se estropeaba, se tiraba de libreta y ya se pasaría cuando se arreglara. Y lo curioso es que no se moría nadie por hacerlo así.
¿Todavía sigue aquí el cansino éste?
Durante mucho tiempo se han gastado ingentes cantidades de dinero en hacer robustos hasta la paranoia sistemas que no lo han necesitado o han tenido alternativas muchísimo más baratas. Se ha abusado de clusters, bases de datos replicadas (la opciones "enterprise" de las bases de datos son sorprendentemente caras) granjas de servidores que estaban al 5% o menos de ocupación de CPU, ...

No voy a decir que se monte un sistema de manera que se pueda caer sin posibilidad de recuperación o que sea sensible a un fallo hardware pero durante mucho tiempo ES QUE SE HA HECHO ASÍ. He visto muchos sistemas que se montaban en discos únicos o servidores únicos con montones SPOF (Single Point of Failure) Lo cierto es que una solución a la que se recurría era el tener un segundo equipo al lado (por ejemplo el viejo) con las mismas aplicaciones y en el que de una manera u otra se hacían volcado de los datos. Esta sistema podía ser de lo más diverso: desde copias de seguridad se recuperaban, volcados de datos, bases de datos replicadas .... todo variaba según el nivel de paranioa y el nivel técnico y económico disponible. No es lo mismo dar HA con software y sistemas de hace 15 años que con una aplicación virtualizada en un cluster, por ejemplo. Para dar alta disponibilidad hoy en día hay infinidad de soluciones pero lo cierto antes de elegir una de ellas hay que hacerse una serie de preguntas:
  • Qué disponibilidad necesito en mi aplicación. Esta es la primera pregunta y hay que evitar pensar siempre en "lo más grande que haiga" Si tienes una aplicación de nóminas las lanzarás a final de mes en una determinadas fechas y horas, no te hace falta estar operativo los 30 días de mes (o no toda la aplicación) Si tienes una tienda en Internet estilo Amazon o Aliexpres necesitas estar disponible las 24 horas del día. No conozco las distribuciones horarias de las ventas de estos sitios, pero aparte de servir a todo el mundo (lo que cubre todas las franjas horarias) apostaría un euro a que su actividad principal es los fines de semana y fuera de horas de trabajo. Hablando de fines de semana, no en todo el mundo el fin de semana es el sábado y el domingo.
  • Cuánto tiempo puedo estar parado. Time is money como dicen los pérfidos. Si mi aplicación es algo de banca estoy perjudicando a los usuarios si se cae, si es una tienda como las anteriores, dejo de ingresar dinero. Aquí me interesa invertir en tenerla arriba el mayor tiempo posible. Si lo que tengo es la aplicación para pedir las vacaciones, pues si hoy no funciona, ya las pedirán mañana. Esto no es decir que lleno mi sistema de SPOFs (discos, máquinas, comunicaciones) pero tampoco necesito protegerme como si fuera Fort Knox.
  • Puedo perder datos o no. Si soy un banco la respuesta es rotunda: No puedo perder ni una sola operación (otra cosa es que si la pierdo me callo como una puta y asumo el coste no sea que de mala imagen) pero si soy Facebook y pierdo las fotos de la última media hora ... pues que las vuelvan a subir.
  • Soy o no de verdad crítico. Porque si de verdad soy criticoa lo mejor tengo que irme a un datacenter que me garantice que no voy a tener ningún imponderable (Telefónica se acaba de gastar más de 100 millones en hacerse un TIER IV Gold) o duplicar (mejor triplicar) y distribuir instancias entre diversos sites. Vamos, que será por dinero. Curiosamente según me han contado hay en España algunos sistemas críticos de verdad con menos protecciones ante imprevistos (eso no quiere decir que estén desprotegidos que pueda entrar cualquier hacker) que otros sistemas mucho menos importante.
Al final no hay que obsesionarse con que si mi sistema es la leche o no. Hay que analizar los factores anteriores y conseguir un balance entre coste y disponibilidad. No obstante hay una serie de factores con los que no se debe jugar (otra cosa es que se haga):
  • Energía: tus sistemas deben tener algo que les proteja ante fallos eléctricos. Deben estar protegidos ante picos de tensión y disponer de un SAI (sistema de alimentación ininterrumpida) que permita bien el tiempo suficiente para apagar los equipos de manera segura o mejor todavía, aguantar mientras entran equipos auxiliares para producir energía (Ojo, que deben alimentar los ordenadores y la refrigeración) Luego ya te puedes ir a virguerías como equipos duplicados N+1, 2N o incluso, 2N+1, refrigeración redundada, ....  por lo general, casi todos podemos sobrevivir con algo más modesto. Eso sí en invierno, procurad NO CONECTAR RADIADORES Y CALEFACTORES a las tomas alimentadas desde el SAI (no me invento nada)
  • Comunicaciones: si lo anterior es importante las comunicaciones son la razón de ser de tu sistema y de tu centro de datos. Hoy en día no creo que nadie trabaje ya con terminales conectados al servidor (aunque de todo hay en la viña del Señor) Mínimo equipos duplicados funcionando en cluster a ser posibles, líneas principales y de backup, 
  • Almacenamiento: El perder datos por daño de discos en pleno siglo XXI debería estar penado en el Código Penal con dos años escuchando música de dulzaina y acordeón. Con el precio de los discos y los sistemas existentes para evitar las pérdidas de información (RAID, triple-mirror, hot spare) esto es casi tan importante como lo anterior. Y ya puestos, esto no se mantiene solo. Si se jode un disco y entra el hot-spare, luego hay que cambiarlo (que nos conocemos)
Por supuesto que hay un montón de cosas más que añadir y que se pueden duplicar que van desde servidores, robots de backup, firewalls, .... Pero un fallo en estos elementos se puede intentar paliar pero un fallo en estos sistemas es catastrófico.

Bueno, dentro de unos días más. Seguramente vaya de nubes.

Desde luego, cada vez que habla me entra un sueño más ricooooo

jueves, 19 de febrero de 2015

El futuro de la nube y la madre que la parió.

He de reconocer que no me he matado escribiendo estos últimos tiempos así que he hecho propósito de enmienda y a lo mejor ... escribo algo más (no prometo nada) Dado que como no me lee ni el tato, tampoco me están agobiando por escribir. En estas entradas me va dar por la informática y dado que llevo más de 25 años metido en el cotarro se supone que algo he de saber.

Como introducción al tema antes habría puesto un enlace al blog de Wardog sobre un experto en nube, pero gracias a cierta ley que no puede ser nombrado no puedo ponerlo con lo que si alguien quiere saber de que hablo que busque en cierto buscador que tampoco puede ser nombrado superstar palito y que se eche unas risas que la cosa merece la pena (son tres capítulos)

¡la nube! Fuente: propia

El tema es que sobre la nube hay muchos conceptos etéreos (aquí vendría un enlace a la RAE para rematar el chiste, pero me lo han jodido) y sobre todo erróneos. A ver si aclaro alguno de ellos.

Uno de los primeros conceptos que mal se interpretan de la nube es que ahorra dinero. Este concepto se interpreta mal porque se hace en términos de economistas, gente que por lo general se caracteriza por oír lo que les interesa, interpretar lo que quieren y cuando las cosas no salen, echarles la culpa a los otros ¿acaso la nube no ahorra dinero? Sí, ahorra mucho dinero ... el tema es saber respecto a qué cosa que no les suele interesar. Por mi experiencia, según se miren las cuentas en un sitio u otro, la nube es un ahorro o no y lo voy a poner con dos ejemplos (y cualquiera que me conozca le aviso que voy a negar SEAN LAS EMPRESAS QUE ELLOS PIENSAN)
- Empresa A: los equipos se compran y se colocan en una sala (ahora mola decir Datacenter, antes era Centro de Cálculo y previamente fue "mételos ahí que no estorben") La electricidad la paga el edificio, al igual que el alquiler o la refrigeración (que para eso sale del margen) A éste una ves comprada la máquina le dan lo mismo las eficiencias y puede decirte con toda su alegría que él deja una aplicación crítica corriendo en una SUN SPARC 5 (en el año 2015) porque él lo vale (la máquina ya no)

Así de claras les gustan las cuentas a algunos. Fuente: propia.

- Empresa B: Voy a dedicar XXX metros a alojar la informática (esto no quiere decir que B previamente no se hubiera comportado como A) y ese coste lo repercuto en los equipos alojados (tanto dinero por metro ocupado, tantos rack, tantas rack units, .... una simple división con un resultado muuuuuuy alto para el que viene de A) por supuesto que la corriente de la repecuto, al igual que el cooling. Por ejemplo, un Datacenter muuuuuuy eficaz es capaz de utilizar en cooling de los equipos un 20% de la energía empleada en computación (PUE: Power Ussage Efectiveness) uno normalito por cada Vatio gastado por el ordenador precisa otro en refrigeración y los malos (por ejemplo ESA SALA DE ORDENADORES IMPROVISADA EN UNA OFICINA puede consumir 3 o más) Si tenemos en cuenta que 1 kW de energía consumida de continuo (o lo que es lo mismo, tres servidores no excesivamente antiguos arrancados de continuo) equivale a precio industrial (la cosa puede varias, pero seguramente hacia arriba) son unos 1.000 € al año hay que contar con otros 1.000 € (fácilmente) en refrigeración de esos equipos. Ahora empecemos a multiplicar por equipos y el recibo de la luz se dispara a muchos miles/decenas de miles de euros al mes. Aparte de eso, hay que contar con gastos de administradores, operaciones sobres las máquinas, etc. A este usuario le interesa ser eficiente ... por la cuenta que le tiene.


Al usuario de sistemas en la empresa A el precio de cada sistema le sale regalado ... al final ha enviado los costes a otro sitio y no le importa (a él no le miden por eso) con lo que lo de la nube se la deja floja. Al usuario de la empresa B no sólo le cobran todo lo que usa (margen aparte) sino que es consciente de lo que gasta por lo que a éste SI le interesa seguir leyendo.
Esto ayuda mucho para la lectura de éste rollo. Y no te digo a la escritura. Fuente: propia
Si eres del caso B (en el caso A te da lo mismo, puedes pasarte a leer el Marca o las 50 sombras esas) lo que voy a escribir te interesará. Te habrás dado cuenta que un servidor no sólo cuesta la compra que puede andar fácilmente de 2.000 a 10.000 € o más (lo que vende cierta tienda de logo rojo y que presume no tontería no son servidores ... lo que venden otros que dicen que sí los venden ... tampoco) con lo que cada máquina que necesites cuesta un dinero tanto en OPEX como en CAPEX con lo que lo de reutilizar recursos no suena tan mal, habida cuenta, salvo que el que te venda la moto sea un mainfranero de IBM, las CPU suelen estar bastante descansadas ...

¿quiere decir esto que la nube (privada o pública) sea barata? NOOOOOOOOR, La nube cuesta dinero y cuando miras el monto total, un datacenter bien completito cuesta dinero ... mucho y a medida que pidas poyaques (Po ya que lo tengo me vas a hacer ....) más todavía,

Me da a mí que aquí va a haber gato encerado ....  Fuente: propia.

¡un momento! Pero si me has dicho al principio que me iba a ahorrar dinero .... pues claro que sí. Mira esta foto:



Eso de la foto cuesta .... muchos euros (más de lo que te piensas) y tiene unas 700 máquinas virtuales sin estar muy apretadas precisamente. El equivalente en físico en máquinas de 1 RU son más de 47 racks. Eso gasta unos 6 Kw de continuo ... el equivalente en máquinas antiguas podrían ser fácilmente 150 kW más la refrigeración (otro tanto) eso sin tener en cuenta que ocuparían unos 17 racks (siendo muy optimistas ... el doble fácilmente) Vamos que en un año lo amortizas más que de sobra.

Para los neófitos de la nube ¿qué leches llevo contando todo este rato? Pues para resumir:
- Los gastos de electricidad, alojamiento y refrigeración de los sistemas clásicos no son precisamente despreciables, por mucho que el economista de turno diga que se cuentan en otro lado.
- La virtualización/nube no es barata, pero su coste es menor que su equivalente físico. De licencias hablamos otro día, pero aunque no son baratas, compensan.
- Cambiar por cambiar no merece la pena ... hay que echar cuentas antes. Eso si, el seguir evolucionando en físico (salvo casos muy puntuales, no merece la pena)
- No vais a poder echar al BOFH ... los sistemas se siguen teniendo que administrar.

Hay que ver lo bien que van estos rollos para el insomnio .... Fuente: propia.

Amenazo con volver con más rollos de estos ...
Pues ... no me he enterado de nada. Fuente: propia

Armaduras.

He de reconocer que últimamente no me estiro demasiado en el tema bloguero este. Tampoco voy a molestarme en hacer propósito de enmienda so...