Saltar al contenido

analisis

Servicio CloudFare en aodbc.es

Durante esta semana (y quizás la próxima) es posible que experimentéis o hayáis sufrido algún tipo de lentitud o fallo a la hora visitar este blog. El motivo es que estoy evaluando la posibilidad de usar CloudFare para gestionar los dominios aodbc.es y aodbc.com.

Logo CloudFare

¿Qué es CloudFare?

Es una compañía que nos ofrece varios servicios, en distintas modalidades (una de ellas Free) que puede ser muy interesante para usuarios particulares e incluso empresas.

Las funcionalidades que nos ofrece CloudFare (dependerá del plan contratado, así que por favor chequea en su web que incluye cada plan y su coste) son:

  • Gestión DNS
  • Cacheo y uso de su red CDN para mejorar accesos por distribución geográfica
  • Protección frente ataques (incluso en la versión Free ofrece una protección básica)
  • Optimización de htmls, imagenes, javascript, etc. para reducir tiempos de carga

¿Por qué te metes en estos líos?, ¿lo necesitas?

Afortunadamente el servicio que tengo contratado es suficiente par manejar el tráfico actual de aodbc.es y aodbc.com sin necesidad de aditivos o ayudas, pero que lo voy a hacer, lo llevo en el ADN, tengo que probar cosas y ver que pueden aportar.

La experimentación junto con la observación, es una de las mejores maneras de aprender 😉

¿Y funciona?

En clientes importantes (con planes comerciales contratados) el resultado ha sido francamente bueno, así que quería ver que podría hacer CloudFare por mí.

La respuesta es sí, funciona bastante bien y puede ahorraros una gran cantidad de ancho de banda, a continuación os dejo algunos ejemplos para el dominio aodbc.es:

CloudFare_Cache

 

CloudFare Performance

 

Un consejo:

 

Si os animáis a probar el servicio, no os pongáis a activar todas las funcionalidades de optimización que os ofrece como locos, ya que seguramente tendréis algún efecto no previsto (normalmente algún tipo de ralentización) y no sabréis acotar que opción lo ha provocado. Activarlas de una en una y dejad un tiempo prudencial para observar el comportamiento, hasta que tengáis vuestra configuración optima.

En mi caso he sufrido ralentización durante algunos periodos y he notado que he perdido tráfico (debido a la carga lenta de la página) en algunos periodos tras activar alguna optimización que provocaba problemas con mi wordpress.

 

Espero os haya resultado de interés y os animo a explorar las posibilidades que este y otro tipo de servicios pueden ofreceros.

Os veo en el siguiente post.

 

Nutanix NX-3060-G4 análisis for dummies del Datasheet

Hoy os traigo un pequeño análisis de las especificaciones del appliance 3060-G4 de Nutanix.

Este appliance es posiblemente el más equilibrado del portfolio de Nutanix y será sin duda el que más se venda en España.

Su aspecto (lo que veo y toco)

Nos encontramos ante un bloque (recordemos que Nutanix llama a los chasis bloque) formato 19″ para racks standard, con 2Us de altura.

El aspecto físico, disipación y consumo pueden variar ligeramente dependiendo de la plataforma HW que elijamos (recordemos que en la actualidad podemos elegir entre SuperMicro, Dell y Lenovo), siendo los incluidos en los Datasheets los correspondientes a la plataforma SuperMicro.

El aspecto exterior de nuestro nodo será el siguiente visto desde delante:

Nutanix Box

sin retiramos el frontal veremos algo tal que así:

Nutanix_Sin_Frontalla parte posterior de nuestro bloque (equipado con 4 nodos)

Trasera_Nutanix

las fotos muy bonitas y ya se que es formato 19″, pero dime algo más

Dimensiones: 88mm de alto, 438mm de ancho y una profundidad de 724mm

Peso: 40.8Kg del chasis (con discos) + 3.2Kg por nodo

 

Aunque esto no lo dice el Datasheet, o recomiendo una profundidad mínima del rackde 1000mm) y puertas tanto delanteras como traseras perforadas para favorecer la refrigeración.

Lo que necesita para estar encendido y funcionando

Este es uno de los aspectos que más me gusta de la plataforma Nutanix y es que con los requisitos del HW y la funcionalidad que ofrece el SW (compresión, deduplicación, auto-tiering, caches, etc. ), con este bloque podremos obtener factores de consolidación muy altos en nuestro Datacenter

 

NX-3060-g4-2

como podemos ver en la tabla adjunta tenemos una disipación media de 3412 BTU/hr (podéis leer aquí a que equivale una BTU) y permite rangos de operación de hasta 35º, lo cual es muy interesante porque implica dos cosas:

  • Disipa muy poco calor (para el tipo de equipamiento IT que puede llevar)
  • Podemos operar nuestro Datacenter a temperaturas más elevadas de a las que estamos acostumbrados en España. Por ejemplo, los 27º los soportará sin ningún tipo de problemas y la diferencia entre operar nuestro Datacenter a 22º o 27º en términos de consumo, os aseguro es bastante grande.

¿y que lleva esto dentro?

Las especificaciones de este nodo son las siguientes:

 

NX-3060-g4

es decir por nodo (en un bloque de este tipo entran 4 nodos), podremos llegar a tener 48 cores, 512GB de RAM y 4 puertos 10GbE , lo que nos daría la siguiente capacidad por bloque:

  • 192 cores a 2.5GHz
  • 2TB RAM
  • 160Gbps de conectividad
  • 32TB HDD + 12.8TB en SSD

 

en el laboratorio de la empresa uno de estos estupendos equipos, al que estamos sometiendo a pruebas que espero compartir con vosotros a lo largo de este año.

Espero que os resulten de utilidad y si tenéis interés por conocer datos de alguna prueba concreta (y razonable ;-)), planteadme el escenario e intentaremos realizarla.

 

Nota: tenéis el Datasheet completo accesible aquí.

El universo digital se expande exponencialmente (IDC)

Según un reciente informe de IDC que puedes consultar aquí. El universo digital que en 2013 tenía un tamaño apróximado de 4.4ZB alcanzará los 44ZB en 2020.

 

UniversoDigital

doblando prácticamente su tamaño cada dos años. De esos datos según IDC se analizan una mínima parte (22%):

 

opportunity-for-big-data

 

También se anuncia un balance o crecimiento del universo hacía los países emergentes:

 

emerging-mature-markets-total-du

 

The Social Recruiting Pocket Guide

Aunque no es la temática habitual del blog, la siguiente infografía me ha resultado muy interesante, e ilustra perfectamente el cambio de tendencia en la selección de personal a la que debemos adaptarnos:

info_social_recruiting1

 

la moraleja de todo esto, es que nuestra huella en la red cada vez tiene más repercusión en nuestra futura empleabilidad, así que ya sabéis es el momento de empezar cuidar también este aspecto.

 

La infografía origina puedes consultarla aquí.

 

Big Data, un ejemplo de aplicación al metro de Nueva York

El Big Data es uno de los nuevos paradigmas que tendremos que afrontar como responsables de TI. Aquellos que lean el blog de forma asidua, recordaran un artículo introductorio (podéis verlo aquí), donde planteaba algunas claves de este fenómeno.

 

La necesidad de analizar grandes volúmenes de datos siempre existió, lo que si ha cambiado es el concepto de “grande”, que ha crecido de manera exponencial a la par que la sociedad de la información y sobre todo, la necesidad de analizar esos grandes volúmenes de datos. Antes eran pocos las entidades y organismos que realizaban estas tareas y ahora casi cualquier empresa puede beneficiarse de esas técnicas, siendo lo complicado recolectar o tener acceso a los datos.

 

Como muestra de lo que se puede hacer os dejo un ejemplo de la ciudad de Nueva York, donde se pueden ver los tiempos de transito (clasificados por colores) entre estaciones de metro….. un ejemplo sencillo y útil, para entender las cosas que pueden llegar a hacerse.

big-data-NY

La imagen original, puedes verla aquí.

 

Y vosotros, ¿estáis listos para el Big Data?

Zen Load Balancer (Toma de contacto) (I)

Desde que escribí un  artículo sobre balanceadores de carga (podéis leerlo aquí), analizando algunas de las opciones que había en el mercado actual, tenía pendiente escribir una pequeña reseña tras la toma de contacto con Zen Load Balancer.

Instalación:

Zen Load Balancer, esta basado en Debian y tiene la instalación clásica de esta distribución, así que si estas familiarizado con Linux en general y Debian en particular, no debe suponer mayor problema.

ZenLB1

Configuración:

La configuración se realiza a través de un entorno web muy cuidado, tanto en lo estético como en lo funcional. Sigue la lógica tradicional de este tipo de dispositivos, organizando los servidores entorno a grupos (farms en este caso) y permite configurar las opciones típicas, protocolos, puertos, ips virtuales, etc.

En una instalación por defecto accederemos en la url: https://ip_configurada:444

ZenLB25

y tras aceptar las clásicas advertencias sobre los certificados e identificarnos con las credenciales por defecto (un maravilloso admin / admin) veremos el dashboard de nuestro nuevo balanceador:

 

ZenLB27

 

El movimiento se demuestra andando, así que vamos a configurar una granja de balanceo (farm), que como veremos es realmente fácil:

 

ZLB_granja1

 

seleccionamos el nombre y el protocolo a balancear

 

ZLB_granja2

 

seleccionamos la ip virtual de la granja y el puerto a balancear

 

ZLB_granja4

y ya tendríamos creada nuestra granja a falta de incluir los servidores miembros y configurar las opciones de balanceo:

 

ZLB_granja5

 

estas son algunas de las opciones de balanceo ofrecidas

 

ZLB_granja6

 

y la configuración de un servidor miembro de la granja:

 

ZLB_granja6

 

la opción de añadir un servidor a la granja, esta debajo de las de balanceo:

 

ZLB_granja7

y la definición sería algo como esto:

 

ZLB_granja8

 

Comclusiones:

Se trata de una primera toma de contacto, así que me quedan cosas muy importantes que probar, como la estabilidad y el comportamiento con las distintas opciones de balanceo que ofrece, también la alta disponibilidad.

Al margen de lo anterior, se trata de software libre (punto positivo), con una interfaz de configuración razonablemente bien cuidada (punto positivo) y con una lógica de funcionamiento similar a la de muchos productos comerciales de balanceo (punto positivo para los familiarizados con estos dispositivos).

 

En lo referente a la configuración, por lo que he podido ver, es muy sencillo de configurar (al menos las configuraciones básicas), siendo un punto negativo el tener los iconos para añadir o editar objetos (entre  otros) muy pequeños y cercanos entre si.

En lineas generales parece un software prometedor, con opciones básicas de configuración de balanceo que pueden ser validas para muchos entornos (no demasiado exigentes).

 

Conforme lo prueba en más profundidad, os comentare mis impresiones.

¿Cual es el mejor software servidor web?

 

Este artículo surge a raíz de una consulta recibida vía email, en forma de …¿ Cual es el mejor servidor web para un sitio de alto tráfico?.

Nunca me cansaré de repetir que no existe la solución perfecta y óptima para todos los casos, sobre todo si hablamos de entornos de misión crítica o altos requerimientos.

Si vuestro caso no es el de un sitio web con mucho tráfico, os diría que uséis el que os conozcáis mejor ya que no notaréis diferencias significativas entre uno u otro que justifiquen usar el servidor X.

Hay que tener en cuenta que a veces la tecnología empleada en el desarrollo de la aplicación alojada puede condicionar la elección del servidor, para este artículo supondremos que no tenemos ningún tipo de condicionante.

Los aspirantes:

 

 

 

 

 

Apache: Es el servidor web por antonomasia, ¿que decir de el?, es rápido, configurable, seguro y muy muy flexible. Sinceramente, si estáis en un sitio donde Apache no cubre vuestras necesidades, o estáis en un sitio muy grande o debéis volver a la mesa de dibujo con la arquitectura 😉 (usad caches, etc.)

Puntos fuertes:

  • Documentación.
  • Flexibilidad

Puntos débiles:

  • Consumo de recursos.
  • No es el más ágil a la hora de servir contenido estático.

 

 

 

 

NGINX: Es el gran aspirante al trono de Apache, más rápido por término medio a la hora de servir contenido (estático sobre todo), tiene una comunidad bastante activa.

Puntos fuertes:

  • Documentación del proyecto de buen nivel
  • Rapidez (sobre todo con contenido estático)
  • Flexibilidad (sin llegar al nivel de Apache, pero soporta las configuraciones más habituales)

Puntos débiles:

  • Fundamentalmente falta de knowHow  (expertos)

 

 

 

 

 

 

Cherokee: La promesa. Es un servidor que tiene como puntos fuertes la rapidez y sencillez de configuración, tuvo bastante tirón al principio pero desde finales del 2011 su desarrollo esta estancado. Esperemos que se recupere, porque sin duda tenía unas bases muy interesantes.

Puntos fuertes:

  • Facilidad de configuración.
  • Rapidez

Puntos débiles:

  • Desarrollo ¿estancado?.
  • Fundamentalmente falta de knowHow  (expertos)

 

 

 

 

 

 

 

Lighttpd: Otro servidor que aspira al trono de Billy el rápido :-). En su momento fue adoptado por bastante sitios grandes (youtube, wikipedia, etc.), pero muchos de esos sitios han migrado (o están en proceso de ello) a otras opciones (fundamentalmente nginx), por presentar este problemas realmente graves y tardar en solucionarlos (memory leaks).

Puntos fuertes:

  • Rapidez

Puntos débiles:

  • Estabilidad y madurez del proyecto.
  • Fundamentalmente falta de knowHow  (expertos)

 

 

 

 

IIS: El servidor web de Microsoft tiene su público y si usas tecnología .Net puede que no tengas otra alternativa. Nos es muy común verlo en sitios grandes y muchos menos como frontal o sirviendo contenido estático.

Puntos fuertes:

  • Fácil de configurar e instalar.
  • Integrable con toda la familia de productos Microsoft.

Puntos débiles:

  • Todo los demás.

Conclusiones:

Con cualquiera de los servidores anteriores se pueden soportar grandes cantidades de tráfico, usar uno u otro dependerá de nuestros skills, de la tecnología usada y de la arquitectura empleada. En sitios de alto tráfico es habitual usar soluciones mixtas, donde se emplean distintos software para diferentes funciones (proxy inverso, servir contenido estático, etc.).

En el sitio web de Netcraft podéis consultar las estadísticas de uso de varios servidores web (os dejo una captura extraída de allí):

 

 

Mis preferencias:

Como os digo depende del caso, pero en mi caja de herramientas nunca falta Apache, Nginx o Lighttpd, mezclado con otras soluciones como ATS, Varnish o Squid

Referencias:

http://httpd.apache.org/

http://www.lighttpd.net/

http://www.cherokee-project.com/

http://nginx.org/

https://www.varnish-cache.org/

http://trafficserver.apache.org/

http://www.squid-cache.org/

http://news.netcraft.com/

http://www.cherokee-project.com/

Análisis de riesgos, ese gran desconcido:

A raíz de una conversación típica de café después de comer, acerca de qué pasa con algunos proyectos y como inexplicablemente se tuercen, no he podido evitar recordar mi primeros años en este mundillo.

Al principio como correspondía a mi nivel de experiencia, participaba en proyectos pequeños, con presupuestos y alcance limitados. En ese contexto, nadie se planteaba la necesidad de hacer un análisis de riesgos y seguramente muchas de las personas que participaban  no conocían o no veían necesidad de dedicar recursos a esta tarea.

Ahora con unos cuantos años de recorrido y alguna que otra lección aprendida, de esas que solo se pueden aprender en la propia carne y el calor de la trinchera, sencillamente no concibo la posibilidad de no realizar esta labor. Sin duda no tiene sentido en un proyecto sencillo y con poco presupuesto realizar un análisis complejo o excesivamente formal, que nos consuma gran cantidad de tiempo, eso lo reservaremos para proyectos complejos, con presupuestos que lo permitan y lo requieran.

¿entonces en que quedamos?…. ¿lo hacemos o no lo hacemos?

Para proyectos complejos o de importancia ya sabemos que deberíamos, pero para proyectos sencillos que no lo permitan hacer formalmente, también deberíamos hacer el ejercicio (aunque sea mental) de parar a  reconocer y evaluar los posibles riesgos, así como cual va a ser nuestro comportamiento ante ellos.

Un poco de teoría:

El concepto de riesgo tienen gran importancia en todas las metodologías de gestión de proyecto, también en buenas prácticas como ITIL, pero ¿qué es un riesgo?, ¿sabríamos reconocerlo?.

Sino me falla la memoria, ITIL define riesgo como incertidumbre en el resultado, que bien puede ser positiva (oportunidad) o negativa (amenaza). Por tanto riesgo sería cualquier situación que pueda producirse y que afecte a los activos, personas, procesos, etc, etc, dando como resultado un final incierto.

Un ejemplo siempre deja las cosas más claras, imaginad que tenemos un flamante Datacenter sobre el que nuestra compañía quiere desplegar su estrategia Cloud, la fecha de fin prevista para que el contratista nos entregue el nuevo Datacenter es el 21 de Diciembre de 2012 (si, los mayas ya lo sabían) y como vamos justos de tiempo pedimos al proveedor de los servidores que nos los entregue el día 22, coincidiendo con el sorteo de navidad, ahora paramos y reflexionamos:

Futuro CPD Oracle en West JOrdan

  • ¿Qué ocurre si el Datacenter no esta entregado en la fecha prevista?, porque el camión con los servidores llega el día 22.
  • ¿Que ocurre si el 22 toca la lotería a nuestro personal y abandonan el proyecto?.
  • …..

Como podéis ver se trata de reconocer aquellas situaciones que pueden poner en peligro en nuestro proyecto a fin de anticiparnos y decidir que hacer, que básicamente puede ser:

  • Tomamos las medidas para eliminar el riesgo (prohíbo comprar lotería a mis empleados)
  • Mitigo (convenzo  a varias personas del equipo para que no compren lotería)
  • No hago nada y que dios nos pille confesados si toca :-).

El riesgo de precipitarse

Una de las cosas por las que será recordado el lanzamiento del iphone 5 de Apple, es por el fiasco de Apple Maps como sustituto del Google Maps y es que ya lo decía Amado Nervo, “La mayor parte de los fracasos nos vienen por querer adelantar la hora de los éxitos”.

Por supuesto la competencia no ha perdido la oportunidad de hacer leña del árbol caído, alguna graciosa como la siguiente de Motorola:

La moraleja que todos deberíamos aprender, es que no deberían lanzarse productos, sistemas, etc. sin estar suficientemente maduros y probados, porque “La mayor parte de los fracasos nos vienen por querer adelantar la hora de los éxitos” y nos puede costar a nosotros y a nuestros clientes un buen disgusto.

Espero que esta entrada la lean muchos compañeros managers y jefes / directores de proyecto 😉 y que cale especialmente en aquellos que tienen dificultades para cuantificar el peligro de la precipitación en sus análisis de riesgo.