Saltar al contenido

arquitectura

Web Scale conceptos de arquitectura

Web-Scale es uno de esos conceptos que utilizamos habitualmente en Arquitectura de Sistemas y que de un tiempo a esta parte escuchamos con más asiduidad, pero ¿qué es exactamente?.

Web Scale nube de palabras

Definición de Web Scale:

 

Utilizamos este termino para indicar que un determinado servicio o arquitectura debe poder escalar con facilidad y rapidez para atender a un gran número de usuarios.

El termino “web” se usa ya que es en está tecnología o ámbito donde con más frecuencia los sistemas deben ser Web-Scale, pensemos por ejemplo en servicios como Facebook, Gmail, etc. que no paran de crecer o en páginas web que deben poder aumentar su capacidad para atender picos de usuarios.

 

Se trata por tanto de una nueva forma de diseñar nuestros sistemas, teniendo en cuenta no solo los aspectos tradicionales como:

  • Diseño modular
  • Seguridad
  • Interoperatividad
  • etc.

a partir de ahora nuestros sistemas deben estar preparados para afrontar el reto de convertirse en un Facebook, Twitter o similar sin morir de éxito 🙂

 

Los problemas de escalado:

En realidad no es nada fácil diseñar sistemas que soporten el reto del Web-Scale, implica conocimientos avanzados de múltiples tecnologías y engloba no solo a la arquitectura de sistemas, también al propio diseño de las aplicaciones (fase de desarrollo). Diseñar una aplicación determinada que soporte 10 usuarios concurrentes es muy sencillo, si subimos a 100 empezaremos a encontrar algún problemilla, si pasamos 1000, 10.000……… solventar esa problemática es el origen del Web Scale.

 

 

SDN & NFV, ¿quién es quién?

SDN y NFV son dos de las palabras que surgen en toda discusión (actual) sobre arquitecturas de red. Están de moda y por tanto parece que abordar una nueva arquitectura de red (independientemente del tamaño o necesidades) sin tan si quiera plantearlo es poco menos que un pecado mortal, pero realmente ¿tenemos claro que es SDN y que NFV?, ¿que ventajas e inconvenientes podemos obtener de la adopción de estos modelos?.

Mi intención con esta entrada es dar una pequeña introducción de que es SDN y NFV, si eres un arquitecto de sistemas/redes acostumbrado a grandes despliegues, posiblemente este post no es para ti ;-).

 

SDN:

En las redes tradicionales, la inteligencia o capacidad de configuración y control se aplicaba a nivel de cada dispositivo, es decir, la configuración de un switch se hacía en el propio switch y esta era más o menos aislada de la del resto de dispositivos que le rodeaban.

Con SDN se pretende desacoplar/separar el plano de control de los dispositivos del propio dispositivo, de tal manera que este puede ser transferido a un elemento “controlador”.

 

sdn

<original de la imagen, aquí>

Algunas preguntas interesantes sobre SDN

 

¿Se pueden definir redes SDN multi-vendor? => Sí, siempre que nos basemos en estándares abiertos. El más popular es OpenFlow.

¿Se pueden controlar múltiples dispositivos desde una misma controladora? => Sí, es una de las cosas más interesantes que aporta SDN, la simplificación de redes complejas y la posibilidad de gestionar todos los dispositivos desde un único punto.

¿Permite configuraciones multi-tenant?=> Of course

¿Es apta para despliegues cloud?=> Nació entre otras cosas para solucionar los problemas derivados de los grandes despliegues cloud.

 

NFV:

NFV es una iniciativa para virtualizar las funciones de red, de tal manera que se reduzca la cantidad de HW necesaria, pero…¿qué es exactamente una función de red?.

Entendemos por funciones de red aquellas tales como Routing, switching, balanceo de carga, Firewall, etc., etc.

Algunas preguntas interesantes sobre NFV

¿Es SDN lo mismo que NFV? => No,SDN se puede apoyar sobre dispositivos físicos o virtuales y su principal objetivo es optimizar el funcionamiento de la red y de su gestión. NFV, tiene entre sus objetivos, reducir la cantidad de HW necesario.

¿Pueden trabajar juntas SDN y NFV? Sí, en arquitecturas modernas y de un cierto tamaño es habitual cierto grado de integración entre ambas.

¿Qué es mejor SDN o NFV?=> Son complementarias, pueden usarse de manera individual o conjunta dependiendo de nuestras necesidades

 

Espero os resulte de interés y utilidad esta entrada, que intentare completar con una individual que trate con más detalles tanto SDN, como NFV.

Rack Scale Design, el rival de Open Compute

Rack Scale Design – anteriormente conocido como  Rack Scale Architecture (probablemente lo hayan cambiado porque RSA ya tiene registrada esa marca) – se puede describir como la respuesta de  Intel al proyecto Open Compute. Se trata por tanto de una arquitectura estandarizada que permita a los fabricantes tradicionales de servidores vender equipamiento a operadores de Datacenter tipo hyperscale (Google, Facebook, operadores de cloud, etc.).

Logo_intel

¿En que consiste?

Pues básicamente en establecer los requerimientos (a cumplir con HW Intel, logicamente) para diseñar componentes de Datacenter compatibles con el diseño Rack Scale y que permitirán a cualquier fabricante, tener productos aptos para el gran Datacenter

rack_scale_architecture

Podéis consultar la Web del proyecto aquí.

Nutanix – Hyperconvergencia ¿quién es quién? (I)

La primera de las soluciones que analizaremos es la del fabricante Nutanix, que a día de hoy (Junio de 2016) es uno de los lideres del mercado.

Logo_Nutanix

Nutanix es una compañía Norte Americana, fundada en 2009 y con presencia en más de 70 paisaes. Actualmente tiene una plantilla aproximada de 1.300 empleados a nivel mundial y cuenta con presencia en España a nivel comercial y preventa.

 

¿Qué es Hyperconvergencia para Nutanix?

 

De las múltiples definiciones de Hyperconvergencia existentes, no en vano, cada fabricante tiene la suya en función de las características, fortalezas y debilidades de su producto, la de Nutanix es posiblemente una de las más extensas y completas. Nutanix extiende o aplica la convergencia a nivel de almacenamiento y Fabric SAN, llegando incluso a la capa de virtualización a través de su solución de Hypervisor basada en KVM (Acrópolis).

Nutanix-Def_Hyperconvergencia

<correspondencia entre las distintas capas de arquitectura y fabricante que la cubre>

El Hardware:

 

Nutanix se define como una solución software, por tanto es agnostica (dentro del HW certificado) en cuanto a fabricante. Actualmente (Junio de 2016) es posible adquirir appliance Nutanix de los fabricantes SuperMicro, Dell y Lenovo e instalarlo (como HW certificado) en Cisco UCS.

Un bloque Nutanix, vendrá equipado en el frontal con los discos para el almacenamiento de los nodos , cubiertos por un frontal

Nutanix_Sin_Frontal

<imagen ilustrativa de un Bloque 3060-G4 del fabricante SuperMicro>

El frontal tiene el siguiente aspecto:

nutanix-box

<Frontal Nutanix>

en la parte posterior podremos encontrar las “cuchillas”, cada una de las cuales se corresponderá con un nodo

Trasera_Nutanix

<Imagen ilustrativa de un bloque de 4 nodos>

Los nodos se equipan con procesadores Intel Xeon de la familia Haswell de hasta 24 cores (Junio de 2016) y memoria de hasta 512GB de RAM DDR4. La conectividad principal de cada nodo descansa sobre interfaces SFP+ a 10Gbe que se complementan con puertos a 1Gbe y un puerto IPMI (puerto de gestión equivalente a la iLO, IPMI, etc. de otros fabricantes). Un nodo tipico contaría con 2 interfaces 10Gbe + 2 interfaces 1Gbe + 1 puerto de gestión (IPMI).

La tecnología:

Nutanix se sustenta en dos pilares tecnológicos para hacer su magia:

  • NDFS (Nutanix Distributed Filesystems) : se trata de un sistema de ficheros distribuido, que se construye con el almacenamiento local del que dispone cada bloque
  • Hadoop: gran parte de la inteligencia del sistema, la que se encarga de la optimización, reconfiguración, etc. etc. (casi todo), se basa en tecnología de Hadoop, es por tanto un “cerebro” distribuido y de crecimiento ilimitado…bueno, en realidad estará limitado por nuestro bolsillo 😉

Sobre cada nodo se instalará un Hypervisor (puede ser KVM, HyperV y VMware) que correrá además de las máquinas virtuales cliente una controladora virtual llamada CVM. Estas controladores virtuales son las responsables de construir el NDFS y de ofrecer todos los servicios basados en Hadoop.

Nutanix-NDFS

<ilustración de la relación entre nodos, CVM y sistema de ficheros distribuido>

en la siguientes entradas profundizaremos en como se gestiona el almacenamiento, características avanzadas como deduplicación, compresión, etc. y factores diferenciadores frente a la competencia.

El Tiering en arquitectuas de sistemas:

Hace poco se publico en DatacenterDynamics, una noticia sobre el nuevo CPD que Facebook  (puedes leerla aquí )construirá para alojar las fotos antiguas (menos vistas de los perfiles). En esencia se trataría de un Datacenter donde se primaría el espacio de almacenamiento y el coste reducido por MB frente al rendimiento.

Viendo la noticia anterior, quizás alguien se pregunte ¿no tiene dinero Facebook para almacenamiento de alto rendimiento?, la respuesta es lógicamente sí, entonces ¿alguien no sabe lo que esta haciendo?, claro que lo saben, es más un servicio como el de Facebook con los problemas de escala y volumen a los que se tiene que enfrentar a diario, no se mantiene sin gente muy buena detrás.

Hay una frase que suelo usar como recurso habitualmente en charlas y formaciones,

“si tienes como única herramienta un martillo veras todos los problemas como clavos”

la realidad es así de demoledora en muchos aspectos y es habitual que el ser humano use habitualmente aquellas herramientas con las que más cómodo y seguro se siente, aunque a menudo puedan no ser las mejores herramientas para resolver el problema dado.

El Tiering es un concepto que esta de moda en el mundo IT y que básicamente consiste en disponer de recursos de distintas prestaciones para prestar el servicio. Aunque este concepto se puede utilizar en varias ámbitos quizás donde más claro se vea es el con el almacenamiento.

Imaginad que tenemos una cabina de almacenamiento que soporta 3 tipos de discos (SSD, FC y SATA) cada uno de ellos con las siguientes características:

  • Los SSD son pequeño,  rápidos y caros.
  • Los FC son rápidos y caros y con menor tasa de fallos que los sata.
  • Los SATA son baratos, grandes y lentos.

western digital hard disk

En esta cabina repartiríamos los datos entre los tres tipos de discos, poniendo los más frecuentemente accedidos en los HD SSD y los menos accedidos en los SATA, de esta manera podemos tener mucho almacenamiento y barato (discos SATA) para la inmensa mayoría de los datos y menos cantidad de almacenamiento de más rendimiento, para los datos que más veces se acceden.

rendimiento_precio_hdspacio_rendimiento_HD

Ese mismo concepto es el que ha aplicado Facebook, pero cambiando los tipos de disco  Datacenters distintos, donde cada Datacenter tiene un coste y rendimiento distintos Lógicamente el Datacenter que albergara el contenido menos accedido tendrá un tipo de almacenamiento de bajo coste por GB.

El Tiering se puede aplicar prácticamente a todo, por lo que es una herramienta muy importante para dejar de ver todas las arquitecturas como clavos ;-).

Data-Link Switching (DLSw)

Data-link Switching esta documentado en la RFC 1434 (puedes consultarla aquí) y en la RFC 2166 para la versión 2 (puedes consultarla aquí) y es un protocolo para la encapsulación y transmisión de protocolos no enrutables como el SNA de IBM o el Netbios de Microsoft.

¿Se trata entonces de una especie de Bridge?

No, DLSW esta orientado a conexión y el Data Link Control se queda en cada uno de los extremos del tunel, esto se ve mejor en los siguientes gráficos:

Bridge

Bridge

DLSW

DSLw

¿Qué aporta con respecto a un Bridge?

  • DLC time-outs
  • DLC ACK sobre la WAN
  • Control de flujo y de congestión
  • Control de broadcast
  • Límite de Conteo de saltos de SRB (Source Route Bridging) (7 hops)

Referencias:

http://en.wikipedia.org/wiki/Data-Link_Switching

http://en.wikipedia.org/wiki/Systems_Network_Architecture

http://en.wikipedia.org/wiki/NetBIOS_Frames_protocol

http://tools.ietf.org/html/rfc2166

http://tools.ietf.org/html/rfc1434

http://www.fiuba6662.com.ar/6648/presentaciones/tordillo/Informe-htm-Tordillo/dlsw.htm

¿Qué es la arquitectura HP ProActive Insight?

Hoy os traigo otro nuevo término de justificación más comercial que técnica, se trata de la arquitectura HP ProActive Insight de HP.

 

 

Esta “nueva” arquitectura se inaugura con la familia Gen8 de servidores y básicamente se compone de hardware y software cuya función es automatizar lo máximo posible el ciclo de vida del servidor. Al mismo tiempo que automatiza el ciclo de vida también permite incorporar cierta inteligencia para supervisar el estado del servidor (utilización, estado y otros checklist).

 

<nuevo servidor SL4500 Gen8 de HP>

 

Las mejoras de esta nueva arquitectura se agrupan en 4 bloques:

Integrated Lifecycle Automation: aseguran que se pueden automatizar muchas de las tareas manuales que se realizan sobre un servidor, permitiendo ahorrar hasta 30 días de tiempo administrativo al año por persona en un centro de datos de 1000 m2.

Dynamic Workload Acceleration: afirman  mejorar el almacenamiento intensivo de datos (hasta 7 veces) gracias a un mejor uso de balanceo de carga y discos de estado solido y optimizaciones en el manejo y creaciones de raid, redundando esto en mejoras de seguridad para los datos. Hasta 1.000 veces más seguros gracias a HP Advanced Data Mirroring, (le pones la palabra Advanced a cualquier cosa y mejora un montón 😉 ).

Automated Energy Optimization: Mejoras en eficiencia energética e integración con sistemas de gestión de CPD’s y Racks inteligentes. Esto si me ha gustado mucho.

Proactive Service and Support: Mejoras en el soporte gracias al HP Insight Online, que no es otra cosa que un portal de soporte, eso sí aseguran alcanzar tasas del 95% de resolución de incidencias en el primer intento.

¿Qué me parece?

Como suele ser habitual en el mundillo del marketing, un montón de palabras y términos nuevos para transformar un avance (no disruptivo) de un producto ya existente en algo innovador.  Desde el punto de vista estrictamente técnico me han gustado las mejoras en eficiencia energética y las optimizaciones en las operaciones intensivas de disco. Habrá que verlos en acción, pero esta nueva generación de servidores (Gen8), parece claramente enfocada al BigData.

Referencias:

http://convergenciahp.com/que-es-la-arquitectura-hp-proactive-insight/

Dog Pile y Facebook

En la entrada del día 20 (aquí) trate el efecto Dog Pile y la verdad que dio pie a algunas preguntas interesantes, tanto en los comentarios, como en personas que me conocen y prefieren charlar con un café por delante.

 

Hay que tener claro que este tipo de efectos los vamos a ver en sitios de mucha carga, por lo que la mayoría de los profesionales de IT se retirarán sin haberse enfrentado a ellos, o tan siquiera  conocerlos.

Para que os hagáis una idea voy a poner el ejemplo de Facebook, que por escala pondrá en contexto muy bien la explicación del artículo anterior, imaginada pues:

  • Más de 10.000 servidores web
  • Más de 800 servidores cache
  • Más de 1.800 servidores MySql
  • Un ratio del 99% en aciertos cache

ahora imaginad que esos 800 servidores cache, de golpe pasan todas las conexiones hacía los webs y voila, ya tenéis vuestro Dog Pile.

Efecto Dog Pile

El Dog Pile, es un efecto de sobra conocido en sistemas de gran entidad y un total desconocido en el resto, para los que no forméis parte del selecto grupo de personas que se enfrentan de manera más o menos habitual a el, voy a intentar explicar que es y como enfrentarse a el la primera vez que os lo encontréis.

 

 

Puesta en situación, con un ejemplo:

Centrándonos en el mundo de las aplicaciones web (por acotar un poco), si estas obtienen éxito (pensad por ejemplo en facebook), empiezan a recibir gran número de visitas y a menudo con un crecimiento exponencial de las mismas en poco intervalo de tiempo. El escenario anterior nos enfrenta al problema de la escalabilidad de nuestra arquitectura, que por supuesto no será tal porque somos unos ti@s maj@s, con un gran número de trucos en la chistera y rápidamente presentamos nuestro plan de acción al CIO:

  • Vamos a desplegar una serie de caches que:
    • Reducirán la latencia.
    • Reducirán el tráfico sobre nuestros servidores web.
    • Ahorraran ancho de banda.
    • Nos convertirán en empresa guay, ya que todo el mundo sabe que la complejidad hace chula nuestra infraestructura :-).

Durante un tiempo la solución funcionan, el tráfico no deja de crecer y la arquitectura aguanta sin mayor problema hasta que….

El fatídico día:

El día que alcanzamos tropecientos mil visitantes simultáneos, con los jefes descorchando las botellas de champagne a nuestro alrededor…algo ocurre, la monitorización avisa de que la carga en los servidores web se ha disparado en un instante hasta el infinito y no pueden atenderla……pero….

 

¿Qué ha pasado?

Hemos sufrido lo que se conoce como Dog Pile, efecto que se produce cuando uno o varios contenidos muy populares (con gran número de descargas) expiran en las caches y de golpe, todas esas peticiones se pasan a los servidores web, para que os hagáis una idea, básicamente el efecto de las caches (recordad que están allí porque las necesitamos) desaparece de golpe y las peticiones pasan en avalancha a los pobres servidores web, que por supuesto no pueden atender tal demanda.

 

 

¿Tiene solución?

El problema se puede abordar de diferentes manera y aunque podríamos estar tentados a recomendar la adquisición de más servidores y de mayor capacidad, puede que la solución sea tan fácil como revisar el comportamiento de las caches ante la expiración de objetos, que básicamente será:

  • Pasar todas las peticiones recibidas al los servidores origen (Provocando el Dog Pile)
  • Retener encoladas las peticiones y pasar unicamente una al servidor origen,  de esta manera no provocamos el Dog Pile y una vez renovado el objeto en las caches, podemos atender el resto de peticiones.

Aunque la solución pasa de manera clara por encolar las peticiones, nos encontraremos con que no todos los caches soportan esta feature, con lo cual nuevamente habrá sido vital la experiencia de nuestro arquitecto de sistemas a la hora de prever este y  otros efectos derivados de un alto tráfico.