Saltar al contenido

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.

 

 

Big Switch’s llega a un acuerdo con HPE

Big Switch’s comercializa tecnología de software-defined networking (SDN) y recientemente a llegado a un acuerdo con HPE para equipar algunos de los switches SDN con su tecnología, en un acuerdo similar al que ya tiene con DELL.

Switch HPE Altoline

<Switch HPE Altoline cortesía de HPE>

 

Es un movimiento muy interesante, porque poco a poco están ganando cuota de mercado.

Python on Windows (multi versión)

Tener un entorno de Python funcional, es una de esas cosas indispensables si trabajamos habitualmente con sistemas y queremos automatizar algún tipo de tarea.

Logo Python

En un equipo Linux o Unix es relativamente normal contar de base con una instalación del mismo (o es sumamente sencillo instalarlo), en Windows aunque no lo encontraremos instalado de base no es mucho más complicado tenerlo.

 

Lo primero es ir a la página de descarga del proyecto Python (aquí) y elegir la versión a instalar.

 

Versiones de Python

 

como podemos ver, tenemos dos opciones la 2.7.x y la 3.6.x

¿Que versión instalar?

La mayoría de los scripts antiguos estarán desarrollados para la 2.7, si el script es moderno o queremos desarrollar uno nuevo, quizás nos interese más la 3.6. En este post os enseñare a instalar y tener disponibles ambas versiones, así que debéis descargar las dos.

 

Descarga_Python

 

 

Instalando la 2.7

Lanzamos el ejecutable

 

Instalación Python

 

seleccionamos el path de instalación

 

Instalación Python

 

 

seleccionamos las personalizaciones que queramos

 

Instalación Python

 

en nuestro caso añadiremos el path

 

Instalación Python

 

 

y finalizamos la instalación

 

 

Instalación Python

 

en este punto podemos abrir una linea de comando y verificar la instalación

 

Verificamos instalación

 

ya tenemos la versión 2.7.x de Python operativa.

 

Instalando la 3.6

Instalamos la 3.6.x (proceso de instalación muy parecido), unicamente deberemos quitar el “path length limit”, por si tenemos un path relativamente largo

 

Instalación Python

 

hacemos una copia del ejecutable de python y lo llamamos python3

 

instalando Python

 

aquí podemos ver el nombre de fichero modificado

 

Instalacion Python

 

el siguiente paso sería incluir el path a python3 en nuestras variables de entorno

 

Instalación Python

 

lo que nos interesa es la variable path

 

Instalación python3

 

donde añadiremos nuevas las rutas de python3

 

Instalación Python3

 

y con esto ya tendríamos operativos los 2 entornos de Python

 

verificando instalación python

 

 

 

 

 

 

 

Virtualizar Oracle, mini guía de licenciamiento (2/2)

Continuando con el artículo anterior  “Virtualizar Oracle, mini guía de licenciamiento (1/2)“, que la verdad ha despertado bastante interés (o al menos generado feedback por vuestra parte), voy a intentar aclarar algunos aspectos alrededor del licenciamiento de este popular motor de RDBM.

Logo Oracle

Antes que nada recordar que este post no pretende ser una guía de licenciamiento o Best Practices de Oracle (para ello podéis dirigiros a www.oracle.com o a vuestro AM/Partner de confianza, que os podrá ayudar), pero sí aclarar desde mi experiencia, alguna de las preguntas que siempre se plantean.

Entornos de Desarrollo, Test, Pre-Producción…. ¿tengo que licenciarlos?

 

Toda instalación de Oracle debe estar licenciada adecuadamente, ahora bien, existen diversos modelos de licenciamiento (OTN, OMA, OSA, ULA,…). Cuando descargamos software de la OTN ( Oracle Technology Network (OTN) ), aceptamos el modelo de licenciamiento OTN que dice algo así como :

..this limited license allows the user to develop applications using the licensed products as long as such applications have not been used for any data processing, business, commercial, or production purposes….

es decir, podremos usar esta licencia “gratuita” para desarrollar, siempre y cuando no hagamos un uso comercial de la misma, o ejecutemos sobre ella ningún tipo de acción ajeno al desarrollo.

Cualquier entorno de Pre, validación, test, etc., necesitaría por tanto ser licenciado, salvo que lo tratemos como un entorno de desarrollo y ojo!!, no hagamos sobre ellos ninguna labor distinta a los tests propios asociados al desarrollo.

 

Procesadores y factor de corrección

Oracle puede desplegarse sobre distintas arquitecturas (X86, Power, UltraSparc, etc.) y el licenciamiento cambia de un procesador a otro en un factor multiplicador o de corrección. Esto significa que una vez tengamos nuestro número de procesadores, deberemos multiplicarlo por el factor de corrección asociado a esa CPU y tendremos el nº final de licencias necesarias.

 

Podéis consultar la tabla (Oracle la actualiza periódicamente), aquí.

 

VMWare certificado / Soportado para Oracle

Este es otro de los temas que genera bastante confusión.  VMWare NO esta certificado oficialmente para Oracle, pero si soportado, lo que significa que si tenemos un problema podremos acudir al soporte de Oracle y ellos nos ayudaran, pero al no ser un entorno certificado, pueden pedirnos que movamos nuestra BBDD a un entorno certificado para continuar dándonos soporte.

VMWare DRS, afinidad de Hosts  y Oracle

Desde la versión 5.1, Oracle considera necesaria licenciar todos los hosts pertenecientes a un vCenter que vaya a ejecutar una RDBM Oracle, independientemente de que establezcamos DRS con afinidad de Hosts.

Podéis encontrar más información al respecto aquí.

 

Disclaimer: este artículo se basa en mi experiencia y conocimiento del modelo de licenciamiento de Oracle a Agosto de 2017. Es importante remarcar que el modelo de licenciamiento puede cambiar o lo aquí indicado puede contener alguna errata involuntaria, es por ello que el lector se hace responsable del uso que haga de la misma.

 

Información adicional:

http://www.oracle.com/us/corporate/pricing/sig-070616.pdf

http://www.oracle.com/us/corporate/pricing/databaselicensing-070584.pdf

http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf

http://www.oracle.com/us/products/database/enterprise-edition/comparisons/index.html

https://blog.dbi-services.com/all-you-need-to-know-about-oracle-database-licensing-with-vmware/

Virtualizar Oracle, mini guía de licenciamiento (1/2)

En lo muchos proyectos de diseño de arquitecturas y virtualización de CPDs que he podido realizar a lo largo de mi carrera profesional (y seguramente en muchos de los que vendrán), hay siempre un tema recurrente, virtualizar o no virtualizar las BBDD Oracle. Bien, este post no pretende ser una guía de licenciamiento o Best Practices de Oracle (para ello podéis dirigiros a www.oracle.com o a vuestro AM/Partner de confianza, que os podrá ayudar), pero sí aclarar desde mi experiencia, alguna de las preguntas que siempre se plantean.

 

Logo Oracle

¿Cual es el modelo de licenciamiento?

Oracle BBDD se licencia por procesador, lo que quiere decir que en una máquina física que vaya a correr una BBDD Oracle se debe licenciar todos los procesadores que esa máquina tenga.

 

¿Qué pasa con los entornos virtuales?

Esta es la madre del cordero. La respuesta es que deberemos licenciar todos los procesadores físicos susceptibles de ejecutar la BBDD, ¿qué significa esto?, que si tenemos por ejemplo 3 hosts con 2 sockets de 10 cores cada host, integrantes de un cluster por ejemplo de vSphere, deberemos adquirir 6 licencias, independientemente del nº de cores virtuales que tenga la máquina virtual creada para alojar la BBDD Oracle.

La explicación a la situación anterior es que Oracle interpreta que la máquina virtual que corre la BBDD puede ejecutarse sobre todos los procesadores disponibles en el cluster (por ejemplo al hacer vMotion, estaríamos moviendo la máquina a otro host, que por tanto debe ser licenciado).

¿Que ocurre si establezco reglas de afinidad a procesador o alguna técnica similar?

Oracle no considera que reglas de afinidad a procesador o tecnologías similares, sean garantía de que se va a limitar de manera real lo cores involucrados, por lo tanto deberemos licenciar todos nuestros cores.

El fabricante X (diferente de Oracle) tiene una formula mágica para consumir menos licencias, ¿lo creo?

Cantos de sirena al margen, el único fabricante que establece el modelo de licenciamiento de Oracle es Oracle, por lo que todo lo que sea apartarnos de ese modelo podrá acarrearnos problemas a futuro con el soporte o con el licenciamiento.

 

¿De verdad Oracle me obliga a licenciar todos los cores de mi infraestructura?

No, Oracle contempla dos tipos de particionamiento de una máquina:

  • Físico o Hard Partitioning: lo que hacen las máquinas particionables tipo M6, M7, P-series, etc.
  • Lógica o Soft: VMWare y el resto de Hypervisores caen en esta categoría

pues bien si establecemos particiones fisicas solo tendremos que licenciar los cores en las particiones que corran Oracle, es decir si establecemos una partición de 10 procesadores, solo adquiriremos 10 licencias, aunque nuestra máquina tenga 200 procesadores.

 

¿Hay diferencia entre Hypervisores?,

La respuesta es que todos los Hypervisores se tratan de igual manera, salvo el propio de Oracle que en este caso tiene un trato que resulta claramente ventajoso frente a otras opciones como VMWare, AHV, KVM, etc.

 

El motivo de que OVM salga beneficiado es que pueden ser configurados como Oracle Trusted Partition, lo que les permite licenciarse como si de una partición física se tratase.

 

Disclaimer: este artículo se basa en mi experiencia y conocimiento del modelo de licenciamiento de Oracle a Agosto de 2017. Es importante remarcar que el modelo de licenciamiento puede cambiar o lo aquí indicado puede contener alguna errata involuntaria, es por ello que el lector se hace responsable del uso que haga de la misma.

 

Información adicional:

http://www.oracle.com/us/corporate/pricing/sig-070616.pdf

http://www.oracle.com/us/corporate/pricing/databaselicensing-070584.pdf

http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf

http://www.oracle.com/us/products/database/enterprise-edition/comparisons/index.html

VMWorld Europe 2017, razones para asistir

Del 11 al 14 de septiembre de 2017, se celebrará en Barcelona un año más el VMWorld edición Europa.

Para los que no lo conozcan decirles que es uno de los principales eventos IT a nivel mundial y por supuesto una fecha clave en lo referente a VMWare.

vmworld2017_Europe

 

Particularmente es uno de los eventos que más me gusta y al que intento asistir siempre que mi trabajo me lo permite y es que hay muchas razones para hacerlo, aunque VMWare lo limite solo a 7.

 

para mí y esto es una opinión personal, mis razones para asistir son:

  • Reencuentro con amigos: en un mundo donde todos tenemos muchos viajes y agendas complejas, a veces este tipo de eventos son las excusa ideal para reencontrarse con compañeros/amigos que llevemos tiempo sin vernos.
  • Networking personal: Es una oportunidad única para conocer gente del sector, de partners, de integradores y por supuesto de fabricantes
  • Actualización tecnológica: si buscas un sitio donde poder tener acceso y conocer de primera mano el estado del arte en tecnologías de virtualización y cloud, este es tu evento
  • + Networking personal:  en serio, si asistes a este evento, tienes que aprovechar y conocer a tanta gente como puedas, intercambiar opiniones, debatir….
  • Divertirse: por supuesto también hay diversión y no solo de las numerosas fiestas, que también las tienen. Los mejores momentos los compartidos con amigos y compañeros.

 

Si tenéis oportunidad de asistir, no lo dudéis.

 

Configurar DSM Synology para dar NFS a VMWare 6.5

Para aquell@s que queráis usar un dispositivo Synology como almacenamiento compartido de una instalación VMWare y os plantéis usar NFS en lugar de iSCSI (altamente recomendable en el caso de Synology), a continuación podréis encontrar los pasos para exportar un Datastore por NFS desde nuestros dispositivo DSM 6.x a nuestros hosts ESXi.

<imagen ilustrativa Synology DS 414>

Comenzaremos lógicamente accediendo a nuestro dispositivo Synology y visualizando el escritorio:

Synology Desktop

 

 

chacemos click en Panel de control  y posteriormente en “Servicios de archivos”

Panel de control Synology

a continuación marcamos “Habilitar NFS” (si queréis usar NFSv4 podéis marcar también el check box y configurar el Dominio NFS correspondiente

Habilitar NFS

 

Aceptamos pulanso ok y regresamos al Panel de control, donde en esta ocasión “pincharemos” en “Carpeta Compartida”, para configurar los permisos (dejaremos unicamente el usuario administrador con permisos de lectura/escritura).

Permisos NFS

 

continuamos cambiando a la pestaña “Permisos avanzados”

 

Permisos avanazdos NFS

y finalmente en la pestaña “Permisos NFS”, deberemos crear una regla que permita la conexión de los Hosts ESXi (podemos crear una por Host, o una que cubra la red en la que se encuentran los Host ESXi).

Permisos de conexion a los hosts ESXi

en mi caso he creado una regla por cada Host ESXi

Permiso de Host ESXi para conectar a NFS

con esto finalizamos la configuración en el lado de Synology y deberemos pasarnos a nuestro Host ESXi o vSphere.  La imagen siguiente muestra mi entorno de homelab con los Datastores disponibles en ese momento:

Datastores previos

con el botón derecho sobre el Datacenter (o uno de los Hosts), seleccionamos Almacenamiento/Nuevo almacén de datos

 

Añadir_Datastore

seleccionamos NFS

Seleccionamos NFS

 

y la versión de NFS

Seleccionamos versión de NFS

introducimos configuración

Configuración NFS

si estamos realizando la operación sobre un Datacenter, seleccionaremos los Hosts que montaran el Datastore

Selección de Hosts

y finalizamos:

Finalizamos configuración

 

ahora si podemos visualizar y usar nuestro nuevo Datastore compartido por NFS

NUevos Datastores

 

¿Por qué usar NFS en lugar de iSCSI?

Normalmente yo suelo preferir iSCSI, pero en el caso de Synology, los recursos compartidos por NFS tienen un rendimiento bastante mejor en NFS que en iSCSI (y no es el único dispositivo en el que he observado este comportamiento), además Synology provee un plugin VAAI para NFS (en otra entrada, explicaré como configurarlo).

Xeon Scalable, el nuevo procesador de Intel ya está aquí

Hace unos días hemos podido asistir al lanzamiento de la nueva familia de procesadores Xeon de Intel, denominada Xeon Scalable. Según Intel esta nueva familia de procesadores supondrá un importante avance en materia de rendimiento y eficiencia energética, contando además con variantes especificas para determinados tipos de cargas de trabajo, tales como HPC, IoT, etc.

 

Imagen_procesadores_Xeon

 

¿Qué podemos esperar de ellos?

 

Para empezar el número de cores crece hasta los 28 y (siempre según Intel), se pueden experimentar mejoras de rendimiento de hasta:

  • 70% menos de latencia en acceso a datos
  • 4.2 veces más máquinas virtuales que la familia anterior
  • Entre 40% y 100% de rendimiento más, usando plataformas como Google Compute Platform
  • Etc.

 

Silver, Bronce, Platinum….

Si este no fuese un blog tecnológico, parecería que estamos en una joyería :-), en realidad esta nueva clasificación de los procesadores se basa en:

 

Platinum

Son los más potentes de la familia y lógicamente podemos usarlos para todo, pero es en HPC y análisis de datos donde puede tener más sentido pagar el coste. Por hacer una analogía, serán los sustitutos de los E7

 

 

Gold y Silver

Son los procesadores que más vamos a ver en Servidores en el Datacenter, ideales para Virtualización, Cloud, etc, etc.

Xeon Scalable Gold

Xeon Scalable Silver

Bronze

 

Serán los Xeon de bajo coste, enfocados sobre todo al SMB y a equipos de almacenamiento Entry Level

Xeon Scalable Bronze

 

Reconocimiento de créditos:

Todas las imágenes son propiedad y cortesía de Intel. Puede consultarse las originales, así como información adicional sobre los procesadores aquí.

VAAI y VASA de VMWare

Hace ya algún tiempo que VMWare se decidió a desarrollar y mejorar las APIs de conexión con terceros y algunas de estas APIS son VAAI y VASA. Aunque no estamos hablando de un nuevo lanzamiento de la 6.5 (por ejemplo VAAI lleva entre nosotros desde la 4.1), no deja de sorprenderme que aún son desconocidas por gran número de personas.

¿Qué es VAAI?

VAAI (VMware vSphere API for Array Integration) es una API ofrecida por vSphere para integración con fabricantes de almacenamiento. Por decirlo de una manera sencilla (por favor, los puristas, no sigan leyendo 😉 ), esta API permite que vSphere sea consciente del almacenamiento que tiene por detrás y hable con el, no solo a través de los protocolos estándar como iSCSI, FC o FCoE.

En realidad VAAI es una parte de la API vStorage que engloba entre otras cosas:

  • vStorage API for Site Recovery Manager
  • vStorage API for Data Protection
  • vStorage API for Multipathing
  • vStorage API for Array Integration

 

<original de la imagen aquí>

¿Para que sirve VAAI?

Pues básicamente nos permite que operaciones que son muy costosas para el host, como por ejemplo hacer un snapshot de una VM, pedírselo directamente a nuestra cabina y que lo haga ella.

En operaciones de snapshot por ejemplo, se pueden obtener reducciones de un 20% en consumo de CPU (según VMWare).

Si acudimos a la página oficial de VMWare podemos leer:

The goal of VAAI is to help storage vendors provide hardware assistance to speed up VMware I/O operations that are more efficiently accomplished in the storage hardware.

Generalmente el fabricante del Storage suele suministrar un plugin para nuestro vCenter que nos permite implementar esta funcionalidad.

Podéis comprobar si vuestro almacenamiento soporta VAAI aquí.

¿Qué es VASA?

 

VASA es otra API, (en este caso VMware vSphere API for Storage Awareness) cuya finalidad es la de permitir integrar nuestro storage con el vCenter para funcionalidades de management. Es algo más nueva que VAAI, ya que se libero con la versión 5.

<imagen cortesía de VMWare>

¿Para que sirve VASA?

Se trata de ofrecer funcionalidades de management en el vCenter y las funcionalidades dependerán del fabricante. Por ejemplo una muestra podría ser:

  • Disk Type (SSD, SATA, SAS, FC)
  • Snap space reserved
  • Dedupe –
  • VV Type

Por tanto el vCenter accederá las funcionalidades VASA ofrecidas por nuestro storage, a través del “VASA Provider”.

Espero haber podido aclarar un poco mejor estos conceptos.