Nosql avanza
Digg cambia MySQL por NoSQL
http://www.vivalinux.com.ar/eventos/digg-cambia-mysql-por-nosql
Otro gran consumidor de servicios de bases de datos - Twitter lo hizo este mes también - está abandonando MySQL y en profundidad, dejando las DB relacionales como base de sus procesos de negocios más importantes. Digg ya está usando una arquitectura NoSql basada en Cassandra, y la migración desde MySQL/DBs relacionales a Cassandra/NoSql habría comenzado hace 6 meses atrás y hoy ya tienen Cassandra/NoSql corriendo en producción.
Según comentan en el blog de la empresa, abandonan las DBs relacionales por las limitaciones que tienen cuando se escala a grandes volúmenes de datos y al tener que particionar - horizontal y verticalmente - la información, pierden las ventajas de lo "relacional" de las DBs, a la vez que mantienen todas las desventajas (sobrecarga derivada del mismo particionamiento).
También comentan que les resulta muy importante que a medida que se expanden a lo largo de múltiples datacenters para obtener redundancia, mejor performance de red, poder añadir capacidad o reemplazar nodos caídos sin ningun downtime (sin tener que apagar el hardware/servers/datacenters, ni el software/DBs). A la vez planean seguir usando hardware commodity y por lo tanto asumiendo que fallará regularmente; todo ello se vuelve constantemente más difícil de manejar usando MySQL.
Más aquí:
Saying Yes to NoSQL; Going Steady with Cassandra
http://about.digg.com/node/564
En este otro post, tenemos lo que fue la previa de la migración a Cassandra, con una intro a unas pruebas de factibilidad que corrieron los ingenieros de Digg en una feature del sistema, evaluando muy positivamente la performance de Cassandra.
Lo más importante de este post, tal vez sea que llegaron al mismo razonamiento que Google, Amazon, Yahoo, Facebook, Linkedin, Twitter y otros: es mucho más barato incorporar nuevos discos (y hard commodity ultrabarato), que lidiar con las complejidades de escalar una DB relacional típica a cientos/miles de nodos.
Más aquí:
Looking to the future with Cassandra
http://about.digg.com/blog/looking-future-cassandra
El futuro cercano del software
El software libre de DBMS de avanzada (MySQL, Postgresql, y ahora las NoSQL), y sistemas operativos (Linux, BSDs), cambiaron completamente el juego de los negocios IT altamente rentables tradicionales (sistemas operativos, bases de datos y equipamiento de datacenters). cuando los jugadores más importantes de la industria mundial (en cantidad de datos de procesamiento y por velocidad de procesamiento), migraron hacia soluciones completamente libres.
El primer salto hacia el datacenter del futuro cercano es que las organizaciones que implementan sistemas con gran consumo de recursos rápidamente necesitan implementar redundancia y replicación masivamente, lo que llevaría en el caso de estar usando software propietario, a necesitar muchas - cientos por ejemplo - licencias de sistemas operativos, y de ellas, las más caras, que son las que habilitan el uso - legal - de funcionalidades de clustering e interoperatividad que se requiere en ambientes de decenas a centenares de nodos - servers - corriendo teams de procesamiento.
La misma idea se aplica a las licencias de bases de datos propietarias, si necesitamos implementar 200 servidores de bases de datos trabajando en modo avanzado - replicación, clustering, interoperatividad avanzada - los costos se vuelven prohibitivos.
Si saltamos de 200 a 2000, los costos se vuelven imposibles de cubrir para la mayoría de las organizaciones públicas y privadas que no tengan un presupuesto de adquisición y otro presupuesto de mantenimiento similares a los de una corporación multinacional que tiene decenas de miles de millones de dolares de ganancias anuales.
De vuelta, de 200 sistemas operativos con licencia de datacenter a 2000 licencias, los costos también se vuelven prohibitivos. ¿Que tal si saltamos de 2000 a 200.000?
El futuro cercano del hardware
En este punto tocamos el hardware, si necesitamos 20 servidores, luego 200 y despues 2000 servidores, los costos de adquisición y mantenimiento se vuelven imposibles para muchos. A esto hay que sumar que la necesidad de mayor capacidad de procesamiento lenta pero progresivamente se vuelve un factor constante y presente en las infraestructuras IT de muchas organizaciones. ¿O sea que un día podría necesitar 200.000 servidores?
Este problema trae aparejado otras cuestiones profundas a analizar y que - básicamente - derivaron en que la planificación, construcción e implementación de nuevos datacenters masivos para grandes empresas como Google, Amazon, y otros se realizan utilizando grandes inmuebles en zonas extremadamente baratas que tengan el abastecimiento de energía necesario (y el más barato posible en el caso de países con mercado de energía desregulado, como es el caso de EE.UU.).
Volviendo al hardware, comprar 2000 servidores, mantenerlos (agregarles ram, reparar placas madres), se vuelve un juego en que cada 3 años aprox., cuando vencen las garantías del fabricante, se vuelve imperativo volver a comprar servidores, sin opción más que seguir usando un hardware imposible de reemplazar de inmediato - si fuera necesario - por hardware de menor costo, y en muchos casos ni siquiera disponiendo del presupuesto apropiado, se puede disponer de inmediato o en plazos razonables - horas - de reemplazos completos.
Un plazo razonable de provisión de hardware tan crítico está medido en horas porque organizaciones como por ej. bancos, no pueden asumir downtimes mayores sin sufrir un gran impacto a nivel organizativo (regulativo, económico, financiero, legal, laboral, social, etc.).
En una extensión del razonamiento de los tiempos de provisión, debemos recordar que aunque los proveedores de servers de alto nivel disponen de equipamiento en stand-by en países con un mercado de infraestructura IT fuerte, y ello se materializa en grandes cantidades de servers y equipamiento para datacenters a corta distancia geográfica y administrativa (se pueden comprar por Internet y llegan al otro día a las pocas horas y de madrugada si hace falta), de las organizaciones; todo esto no se repite en la misma magnitud en muchos países (en Latinoamérica en general los tiempos de respuesta y existencias son bajos, y los costos por "apuro" son considerablemente altos), por lo que muchas organizaciones en el mundo se ven considerablemente expuestas a riesgos mayúsculos al atarse inseparablemente de infraestructuras - servidores principalmente - que no se pueden reemplazar rápidamente.
Aunque el escenario de falla de un server cuando se usan 20, y se tienen 5 de reserva tiene un impacto relativamente menor (se activan planes de disaster recovery y/o esto se produce automáticamente, gracias a clustering, replicación o infraestructura virtualizada). Cuando se tienen 200 o 2000, las cosas cambian.
Software libre y hardware commodity
Meditando sobre el escenario anterior, vemos que es presente para organizaciones como Google, Amazon, Yahoo, Facebook, Linkedin, Twitter, Digg y muchas otras organizaciones avanzan rápidamente hacia escenarios similares a mediano plazo (un par de años), a medida que incorporan sistemas que almacenan gigabytes de datos por mes y terabytes por año (o peor, TBs por mes y EBs por año). Estos datos almacenados requieren ser accedidos cada vez a mayor velocidad gracias a la constante adición de minería de datos y en mayor medida incluso, a que los sistemas en producción simplemente acceden el pleno de datos almacenados, sin posibilidad de "retirar" conjuntos de datos como "históricos" y mejorar con ello la performance de los sistemas y bajar los requerimientos de hardware.
En este escenario es que se presenta la necesidad de mantener cientos a miles de nodos de servidores, cada uno corriendo un sistema operativo y una base de datos, con el requerimiento inevitable de que el hardware sea muy, muy barato, fácil de reemplazar y fácil - rápido - de conseguir localmente.
A este tipo de infraestructuras migraron los grandes ya mencionados, reemplazando centenares de servidores individuales (que fue el típico modelo de infraestructura "barata" de finales de los 90), de "marca", con garantía del fabricante, por cientos o miles de máquinas commodity, PCs de escritorio montadas como servidores clusterizados por software, con mínima resiliencia y máximas probabilidades de fallo por baja calidad del hardware. Pero cada nodo es extremadamente barato, fácil de conseguir y se puede mantener literalmente miles de nodos en cold-standby (apagados), listos para reemplazar a cualquier PC/Nodo/server que falle, inmediatamente.
Adicionalmente el software libre brinda costo de licencia cero (0) para cada sistema operativo y base de datos corriendo en cada uno de los miles de nodos del datacenter.
Otras infraestructuras muy simples, brindan servicios de automatización completa, por ejemplo permitiendo que la falla total de una PC/nodo/server sea insignificante a nivel de prestación de servicios del datacenter. Incluso implementar un nuevo servidor de reemplazo es decir, conectar y encender e instalar una nueva PC/Nodo/server, se automatiza al punto de que el software (sistema operativo, base de datos y configuraciones), se instala y despliega automáticamente, simplemente conectando la nueva Pc/nodo/server a la red (por ejemplo vía PXE y Kickstar). Tal como esto es el funcionamiento actual de las infraestructuras de Google, Yahoo, Twitter, Facebook, Digg y otros.
En este punto vemos que hacer un deployment con miles de sistemas operativos Ubuntu LTS Server - por ejemplo - cada uno exactamente igual al otro (excepto algunos pocos gigas de datos variables), vuelve posible adquirir un par de decenas de contratos de soporte 24x7x365 para Ubuntu LTS Server, y disponer así de soporte especializado de alto nivel que se puede maximizar dando soporte - por inferencia - a los miles de nodos que seguirán usando el mismo Ubuntu LTS Server gracias a que es de licencia libre.
De hecho, este modelo anterior de soporte "oficial" es usado por muchas organizaciones en el mundo, incluso realizando inferencias como de RHEL a CentOS, siempre con una adecuada planificación de personal especializado e inhouse (Google, Yahoo, etc.), aunque muchos tambien tercerizan tareas de este tipo sin mayores inconvenientes (Linkedin, etc.).
El futuro de las SANs, Storages e infraestructuras virtualizadas
El tema del storage, las SAN y las infraestructuras virtuales posiblemente viva un escenario parecido cuando se vuelvan masivas, básicamente es cuestión de que los administradores de hipervisores libres actuales (ya hay varios en pleno desarrollo), adquieran suficiente nivel para que sean comparativamente capaces a sus equivalentes pagos y/o propietarios (hay administradores libres con versiones pagas con más features).
Aunque el costo de infraestructuras FC (Fibre Channel), puede parecer un inconveniente de momento, con la masificación de tecnologías de networking de 10 Gigabit Ethernet (GeB), el uso de PC/nodos/servers commodity baratos con placas de red 10GeB y con iSCSI (o incluso ATA over Ethernet, mucho más barato), va a llevar las SAN, los Storage y las infraestructuras virtuales al mismo escenario que hoy previsualiza en servidores tradicionales vs. hardware commodity. Aunque de momento, los dispostivos storage de alta capacidad no tienen rivales posibles si se los implementa en conjunto con infraestructura virtual (hipervisores, administradores de hipervisores, y administradores de administradores, no no es una repetición, Vmware vSphere soporta esta funcionalidad hace más de un año).
Conclusiones
Tarde o temprano el mercado de hardware va a evolucionar hacia servidores/nodos muy baratos, más que los servidores más baratos disponibles hoy (hojas Blade con dos placas de red y un par de discos en RAID como máximo). Los sistemas operativos pagos y bases de datos pagas van a abaratarse para compras grandes, o al menos van a ofrecer algun tipo de competencia a las bases de datos de licencia gratuita (como por ejemplo, grandes descuentos en compras por volumen y/o features a pedido en compras por volumen).
Links
No hay comentarios:
Publicar un comentario