Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes. La semana pasada empezamos a construir la lista Top 10 de las cuestiones clave respecto mi proveedor cloud, esta semana toca completar la lista:

6. ¿Qué posibilidades de recuperación tengo con el almacenamiento en la nube?

He de revisar el diseño de mis estrategias de respaldo y recuperación, averiguar si son aplicables en los servidores virtuales ubicados en el cloud. Si extraigo de la nube los respaldos, he de analizar el impacto económico que puede tener la transferencia de datos, ya que probablemente nos cobren el ancho de banda por transferencia.

7. ¿Qué posibilidades tengo de exportación de mi información alojada en una solución SaaS?

Antes de añadir el primer dato en una base de datos en la nube, he de saber las posibilidades que tengo de exportación (y recuperación) de esta información. Esto puede hacernos huir de algunas aplicaciones SaaS.

8. ¿Puedo auditar el entorno donde se ejecutan mis datos, aplicaciones o VMs en la nube?

Auditar infraestructuras en la nube suele ser mas caro que en nuestro Data Center, hemos de adaptar nuestros procesos de operaciones al nuevo entorno, la logística es mas compleja por tener que coordinar a ms personas y seguramente hay gastos extra en desplazamientos y estancias.

9. ¿En que idiomas da soporte el proveedor cloud?

Aunque el ingles es un idioma “casi” global, cuando tenemos un problema, el idioma local del cliente hace acortar por tiempos de resolución de la incidencia, o sea, menor impacto económico sobre el negocio, es un elemento a considerar.

10. ¿Quién hay detrás del proveedor?

Es difícil saber si un proveedor vivirá mucho tiempo, ahora estamos en época emergente pero cuando el negocio se estabilice, por un céntimo/hora un proveedor puede perder clientes y entrar en crisis.

Conocer las empresas que hay detrás del proveedor es un elemento de posible confianza. No tendremos nunca la certeza absoluta de tener un riesgo cero al escoger, pero la confianza es clave en esta elección, recordar que no buscamos un proveedor, buscamos un socio para nuestro negocio. Las capacidades del proveedor pueden hacer que nuestro negocio tenga nuevas capacidades o limitaciones.

Me haréis muy feliz si entre todos mejoramos esta lista con otras importantes preguntas que queráis incluir. Gracias adelantadas.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo. Gracias.

Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes, para aportar mi granito de arena a la montaña de las TIC actuales.

Estamos en un momento de efervescencia creativa en lo que a servicios cloud se refiere, existen grandes multinacionales con servicios consolidados (o no tanto), empresas locales buscando su hueco, empresas creativas “inventando” soluciones y grandes operadoras reclamando su lugar en la historia.

Esto genera grandes dudas a los clientes ¿Son todos los proveedores iguales? ¿Qué he de buscar en los proveedores? ¿Cómo distinguir los que mejoran mi negocio?

No son preguntas triviales ni existe la formula mágica y general, pero hay preguntas que no podemos dejar de hacer y analizar, por eso propongo un Top10 de las preguntas fundamentales:

1. ¿Cual es el SLA y las indemnizaciones por la perdida de servicio?

Esta es importante y de sorprendente respuesta, nos podemos encontrar un 99,9% mensual de SLA para Amazon S3, o sea 45 minutos de caída “legal”.

Mas curioso es el servicio Amazon EC2, con un SLA de 99,95% anual, es decir más de 4h de caída “legal”.

Lo más divertido es Salesforce.com, no tiene SLA en su precio base, se ha de negociar!!!!, es muy curioso porque cuando tiene perdidas de servicio aparece en todos los periódicos.

Las indemnizaciones son de risa, no nos engañemos, no resuelven económicamente los problemas que generan ¿es una pista de la inversión realizada y los procedimientos existentes del proveedor cloud?.

2. ¿Bajo qué cumplimiento normativo está cubierta mi instancia de VM?

Es muy importante porque cada proveedor de servicio tiene, como vimos en anteriores post, diferentes cumplimientos normativos, hemos de tener proveedores alineados con nuestro negocio, por estrategia de negocio y por necesidades normativas.

3. ¿En que localización estarán mis servidores virtuales y que legislación cumple?

Es necesario conocer la dirección de nuestros datos, sobretodo si tenemos datos de carácter personal, en este caso es obligatorio.

También es importante para poder analizar las reglamentaciones que han de cumplir nuestros datos, recuerda que son las del país donde se alojan, NO las del nuestro.

4. ¿Qué tecnología de hipervisor utiliza?

¿Necesito mover una VM en caliente de mi datacenter a la nube pública? Si esto es así he de asegurar la compatibilidad de la tecnología de hipervisor que proporciona el proveedor a mis máquinas virtuales.

5. ¿Qué posibilidades tengo para integrar mi DC con la nube?

Para que mi nube privada tenga la elasticidad que proporciona la nube pública, necesito integrar la nube pública en mi red, para ello es importante conocer las capacidades de extensión de VLANs y aislamiento con VPN que la nube pública proporciona para ayudar a mejorar mi negocio.

La semana próxima continuaremos con la segunda parte de la lista…

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo. Gracias.

 

Buenos días, soy Jose Maria Gris de nuevo con todos vosotros. Hoy vamos a hablar de una nueva iniciativa de Veeam, esta empresa tan innovadora que no está quieta en hacer y mostrar nuevas cosas. Hoy vamos a hablar de V-Index.

www.v-index.com es a partir de ahora un lugar que debemos tener presente entre nuestros favoritos para ver “como andamos de virtualización”.  De la mano de la empresa Varson Bourne y con el auspicio de Veeam nace este site donde podremos ver 3 indicadores (La penetración de la Virtualización, el Ratio de consolidación y el Hypervisor usado) en cuatro países (Francia, USA, Alemania y UK) más la media.

He estado mirando por encima “a vuela pluma” los ratios y hay cosas interesantes:

• El ratio de penetracion medio es 39.4%
• Curiosamente no es USA, sino Alemania y Francia quien están a la cabeza con 45.x%
• USA queda con un 37,2% y UK con 39,4%
• El ratio de consolidación medio es de 6.3 “Come on, you can doe it much better… ”   bajito señores, bajito.
• Es UK quien se lleva la primera posición con 7.3, seguido de Alemania con 6.4, USA con 6 y Francia con 5.8
• Por ultimo, VMware se lleva el 58.2% de share, Hyper-V el 18.6 y Xen con el 20.2 en términos medios.
• UK es VMware en un 72 quedando lejos los otros fabricantes, muy lejos
• Francia con un VMware al 56 con un MSFT al 27 (se nota lo que tira MSFT en Francia). Xen la nota más baja en todos los países
• Alemania sigue el patrón con la primera plaza con un 46 pero Xen! un 30, cerca estamos. MSFT queda con un 22.
• Por último USA con un 58 para VMware, 22 para Xen y 16 para MSFT.

Muy interesante. Los resultados se publicarán de modo trimestral.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Una de las preguntas que uno se plantea cuando que se encuentra ante un diseño de una plataforma de virtualización es la del diseño del almacenamiento en general y la del tamaño de las particiones o datastores donde se van a almacenar las máquinas virtuales en particular.

En particular esta última cuestión, el tamaño de los datastores, fue la que me planteó el otro día un cliente. Además me planteaba que plataforma, Microsoft Hyper-V o VMWare Hypervisor, tenía mayores límites, en lo que a almacenamiento se refiere.

En este sentido me gustaría presentaros esta semana una pequeña comparativa entre ambas plataformas en lo que a máximos de almacenamiento se refiere.

Antes de entrar en la comparativa en si misma creo importante hacer una pequeña diferenciación entre:

• Almacenamiento físico, es decir aquel almacenamiento que es gestionado o “visto” directamente por el hypervisor.
• Almacenamiento virtual, que para el caso que nos ocupa es el almacenamiento que es usado o “visto” directamente por la máquina virtual.

En el caso del almacenamiento físico antes de poder hacer uso del espacio disponible e independientemente de si se trata de almacenamiento DAS (Direct Attached Storage) o SAN (Storage Area Network) debemos particionar el almacenamiento para después formatearlo.

En este punto es donde llega la primera cuestión que debemos tener en cuenta, ¿de qué tamaño creo la partición? Estrictamente hablando y de forma absolutamente teórica el límite para particiones GUID estaría en 9.4 ZB (ZettaBytes ). El problema real es que una partición no deja de ser como un armario sin cajones, es decir, un espacio vacío donde no hay ni orden ni concierto. En este punto es donde entra en juego el sistema de ficheros. Volviendo al ejemplo anterior, un sistema de fichero sería el equivalente a los cajones, barras, perchas, etc que encontramos dentro del armario, es decir las estructuras que usamos para organizar la ropa, o los datos si hablamos de particiones.

Respecto a los números que nos interesan vemos que el tamaño máximo que puede tener una partición es de:

• VMFSv3 (VMware) 2 TB por partición única
• NTFSv6 (Microsoft) 2 TB por partición única

Pero es posible que un datastore (vmware) o un volumen (Microsoft) ocupe más de una partición, con lo que el tamaño máximo para un datastore o volumen crezca por encima de esos 2TB que acabamos de ver, en particular:

• VMFSv3 hasta 64TB para un único datastore, haciendo uso 32 particiones o “extends” de 2 TB cada una.
• NTFSv6 hasta 16 EB (ExaBytes) para un único volumen lógico.

Una vez que tenemos el armario organizado, es decir que hemos creado la partición y la hemos formateado con un sistema de ficheros, tenemos que meter la ropa dentro, las máquinas virtuales.

Las máquinas virtuales, como ya sabemos, hacen uso de discos virtuales que son, dicho de forma general, ficheros almacenados en un disco físico, los cuales tienen un formato bien definido que es interpretado por Virtual Machine Monitor (Hypervisor) como un disco duro.

Dicho esto, vemos que un disco virtual no deja de ser un fichero dentro de un disco físco, y como tal está sujeto a las limitaciones del sistema de ficheros. Para el caso que nos ocupa, el límite que nos debe preocupar es el de tamaño máximo de fichero, que para ambas plataformas es de 2 TB por fichero.

Por supuesto, en esta comparativa no entran el mapeo directo del almacenamiento a las máquinas virtuales, bien usando RDM o iSCSI.

Un último apunte que me gustaría hacer es que “simplemente por que podamos hacer algo no significa que debamos hacerlo”, por lo que os animaría a consultar las best practices antes de realizar configuraciones que se acerquen “peligrosamente” a los limites, ya que existen otras implicaciones además del tamaño del almacenamiento.

A continuación os pongo algunos enlaces de referencia para ampliar algo de información:

• VMware Configuration Maximums, Storage Maximums on ESX Host Maximums section
• How NTFS Works
• Practical limits to number of files in NTFS filesystem
• VMware Virtual Machine File System: Technical Overview and Best Practices
• Virtual Hard Disk Performance

¡Hola de nuevo! Soy Miguel Ángel Alonso y hoy estoy de nuevo con vosotros para contaros algo nuevo sobre el hypervisor de Red Hat Enterprise Virtualization (RHEV-H).

En el tema de hoy trataremos sobre el Hypervisor RHEV-H para la consolidación de las VMs en sus HOSTS.

Os recordaré que el esquema de funcionamiento es igual que en VMware y XenServer, necesitando de un centro/s de almacenamiento compartido (NFS, ISCSI ó FC) para el alojamiento de nuestras VMs y la necesidad de 2 o más NODOS para poder hacer migraciones, DRS, HA ó Power Saver (Power Managemet en VMware) y no olvidarnos de que nuestras tarjetas de RED soporten WOL (Wake on Lan) para esta última característica.

Tampoco debemos olvidar que para la creación de las VMs, necesitaremos obligatoriamente un Almacenamiento NFS para que albergue nuestras ISOs.

Y por último la necesidad imperiosa de habilitar en nuestra BIOS la tecnología VT , ya que sin esta, RHEV –H no podría funcionar nunca. (Requisito imprescindible). Bueno una vez dicha esta pequeña introducción, pasaremos a la instalación de RHEV-H y sus prolegómenos:

En este caso lo instalaré desde mi CD pero quiero resaltar que lo podemos hacer desde un USB o vía RED (PXE).

Nos aparecerá un pantalla como esta y presionaremos “enter” para que continue la instalación, la cual no tiene ningún misterio.

Una vez se han instalado los componentes necesarios nos saldrá un menú como este y desde el cual realizaremos las configuraciones necesarias

1. Dejaremos por defecto la configuración de las particiones y en la partición DATA pondremos: -1 para que se asocie el resto del disco a dicha partición. Luego daremos en Commit y saldremos de la configuración.



2. Aquí pondremos nuestro Password y habilitaremos SSH.
3. Pondremos el nombre a nuestro HOST RHEV-H
4. Configuraremos nuestra RED introduciendo una IP estática o por DHCP,DNS,etc….
5. Aquí deberemos introducir el FQDN ó IP de nuestro Server RHEV-Manager para así realizar la total asociación de ambos.
6. Finalmente una vez configurados dichos parámetros se instalarán y se reiniciará.

Finalmente iremos a la Consola de nuestro RHEV-Manager y nos aparecerán en mi caso 2 Hypervisores RHEV-H, les daremos con botón derecho en cada uno de los server y seleccionaremos la opción Approve. De esta manera se registraran los servidores RHEV-H en la consola.

Bueno hasta aquí el tema de hoy. Me despido de vosotros hasta la semana que viene esperando contaros algo que os pueda interesar siempre y cuando desde mi humilde opinión.

Como cada martes, gracias por estar ahí y hasta la semana que viene.

Por favor, si te ha gustado este post dame tu puntuacion: [ratings]

Antes de empezar a describir que es una máquina virtual, permíteme comenzar diciendo que la consolidación de servidores es una tecnología clave para mejorar la utilización de los servidores físicos y por lo tanto de nuestro centro de datos.

Mediante el uso de la tecnología de virtualización de servidores, las organizaciones mejoran enormemente la utilización de sus servidores actuales pasando de utilizar un 10% a un 60-80% de su capacidad total de cálculo haciendo así un uso más completo de los servidores que adquieren.

Por consiguiente, el software de virtualización de servidores (VMware, Xen, HyperV, RedHat Virtualization por poner un ejemplo) es un software de máquina virtual, en ingles, Virtual Machine (VM), que se instada directamente en el servidor físico para consolidarlo y “particionarlo”.

La VM es el equivalente en el mundo físico a la unidad unidad c: ,d:, etc, junto con sus aplicaciones y sistema operativo, en este caso Windows, o /root, /home, /tmp, … para GNU/Linux.

En otras palabras, este software nos permite crear múltiples instancias de máquinas virtuales en un mismo servidor físico, cada una de las cuales corre independientemente un sistema operativo y aplicativo diferente.

Así por ejemplo en esta imagen adjunta, podemos observar con mayor detalle la tecnología de virtualización de la solución de VMware vSphere.

La fina “capa de virtualización” que se muestra en azul oscuro en la imagen anterior separa la capa física (arquitectura x86) del sistema operativo en sí.

Cada máquina virtual posee sus propios recursos virtuales hardware como memoria RAM, CPU, NIC, etc, los cuales son usados por la máquina virtual. El sistema operativo en la máquina virtual (sistema operativo Guest) cree que este hardware es en todo momento físico y no entiende nada de recursos virtuales.

Esto permite, como vemos en la imagen anterior, ejecutar múltiples sistemas operativos, mejor dicho, máquinas virtuales heterogéneas (Windows, Linux, Novel, etc) a la vez y en un mismo servidor físico, maximizando así todos los recursos del servidor físico.

Beneficios de las máquinas virtuales

Uno de los grandes beneficios es la encapsulación. Las máquinas virtuales son encapsuladas en varios ficheros lo cual hace posible que estas sean copiadas, movidas y implementadas más rápidamente. Así pues y, gracias a la encapsulación un sistema completo (VM) con aplicaciones, sistema operativo, BIOS y hardware virtual puede ser movido ininterrumpidamente (migración en caliente) de un servidor fisco a otro en cuestión de segundos.

El segundo benéfico es el particionamiento lógico del servidor físico, lo cual nos permite ejecutar múltiples aplicaciones y sistemas operativos en un único servidor físico como se puede apreciar en la imagen anterior.

El tercer benéfico es la tecnología de aislamiento, el cual asila completamente una VM de las otras. Así ante el hipotético caso de que una VM se “cállese” debido a un fallo del sistema operativo en la maquina virtual (BSOD, blue screen of death) este fallo no afectaría a ninguna de las otras VM que estuvieran corriendo en el mismo sistema.

Y por último, una máquina virtual es independiente al hardware físico. Este beneficio representa un avance tecnológico gigantesco con respeto a los planes de contingencias basados en servidores físicos.

La máquina virtual al ser independiente del hardware físico puede ser movida, copiada o replicada de un centro de datos a otro y con independencia de los servidores físicos que estos centros de datos tengan (migración en frio).

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba. Gracias por el apoyo.