En Ultreia somos conscientes de que los proyectos de virtualización se dejan buena parte de su presupuesto en la solución de almacenamiento compartido.
Nuestra idea es que, con la virtualización, el almacenamiento tiene que ser una commodity, como ya son los servidores, el procesador y la memoria. Entendemos que la era de las soluciones de almacenamiento cerradas y monolíticas, tal y como se concebían en los mainframes, ha dejado de tener sentido. Por estas razones, creemos que Coraid es la mejor solución de almacenamiento.
Coraid basa su éxito en cuatro factores:
Rápido: > 500 MB/s sostenidos
Sencillo: Usa el cableado ethernet estándard
Escalable: desde unos pocos TB hasta Petabytes, sin perder velocidad
Económico: 1/5 del precio de la competencia.
Las soluciones ethernet-SAN de Coraid permiten alcanzar velocidades sostenidas de 500 MB/s en acceso a datos, sin sacrificar en escalabilidad ni en economía. Con un coste/TB desde inferior a 500 € (mantenimiento incluido), es posible montar soluciones sin punto de fallo único al coste que tienen las cabinas simples de la competencia (NetApp, EMC, HP EVA, etc).
Además, gracias a que utilizan cableado ethernet normal, y no precisan de redes de fibra, estas cabinas se pueden instalar y poner en marcha en minutos: lleva más tiempo meterlas en el rack que configurarlas y darle acceso a los servidores.
Las soluciones SAN de Coraid están soportadas tanto en VMWare como en Xenserver, siendo ideales para los entornos de virtualización, ya que no solapan características con el hypervisor. En Ultreia, como distribuidores en España de Coraid, podemos aconsejar modelos y apoyar la implantación de estas soluciones.
Imaginaros que disponemos de una Lun en una san iSCSI del fabricante X y por necesidades de espacio desde la interfaz de administración de la san incrementamos el tamaño de la partición gestionada por LVM.
Posteriormente tendremos que realizar los siguientes pasos en XenServer para que podamos disfrutar de ese espacio adicional en la Lun.
1.- Apagamos las máquinas virtuales.
2.- Buscamos el uuid del SR
# xe sr-list
3.- Sacamos más información del SR localizado anteriomente
# xe sr-param-list uuid=”uuid” |grep PBD
4.- desadjuntamos el PBD
# xe pbd-unplug uuid=”uuid del PBD”
5.- Adjuntamos el PBD
# xe pbd-plug uuid=”uuid del PBD”
6.- Arrancamos las máquinas virtuales.
Con esto tendremos el SR redimensionado y funcionando. Como siempre espero que esta breve lectura os sea de utilidad.
Aprovecho la ocasión para desearos unas felices vacaciones a todos.
En el post de hoy trataré de explicar como añadir un repositorio local en XenServer.
Imaginad, por ejemplo, que la instalación inicial del servidor se hizo sobre un raid 1 con dos discos. Ahora disponemos de 4 más y hemos montado un raid 5 con ellos.
Con estos dos pequeños pasos podremos hacerlo.
1.- Localizamos como ha llamado el servidor a la unidad compuesta por el raid 5.
# fdisk -l
otra opción:
# ls /dev/sd*
2.- Añadimos el repositorio:
# xe sr-create content-type=”Almacenamiento_local” host-uuid=”uuid del servidor” type=lvm ó ext device-config-device=/dev/sdb shared=false name-label=”Almacenamiento en raid 5″
Como podéis ver hay posibilidad de escoger entre partición lvm o ext. Esto queda a vuestra elección.
Decir que una partición ext se tomará más tiempo en crearse que lvm. Además, en mi opinión, lvm tiene muchas más ventajas.
Una vez terminado, podremos ir a XenServer y veremos el repositorio creado.
Normalmente en los centros de datos o incluso en nuestras oficinas deberíamos tener algún SAI para en el caso de cualquier fallo o corte en el suministro eléctrico.
Estos SAI independientemente del fabricante deben tener un software que instalado en un equipo al cual esté conectado poder configurarlo.
Este software nos permitirá apagar las máquinas antes de que se acabe la autonomía de las baterías e incluso nos permitira ejecutar secuencias de comandos o scrips para que nos realice alguna tarea en concreto.
Si a esa aplicación le decimos que nos ejecute el siguiente script nos apagará nuestro XenServer 5.5 junto con todas sus máquinas virtuales de forma correcta antes que el sistema se quede sin corriente.
VMware vSphere ESX y ESXi, a día de hoy, solo soporta un tipo de multipathig, ya sea via iniciador software iSCSI o iniciador hardware iSCSI.
Debido a que el iniciador software iSCSI solo puede ser activado una vez, debemos crear una red IP con múltiples caminos hacia nuestra LUNs iSCSI para dotar de balanceo de carga dichas LUNs.
Recuerda: configurar los dos iniciadores iSCSI a la vez no está soportado.
En este episodio #27 te enseñare a crear una configuración multipathing para las conexiones de las LUNs iSCSI en tus cabinas iSCSI:
En el primer capítulo explique los beneficios de la virtualización y porque hay que optimizar y consolidar primero para luego virtualizar nuestro centro de datos con la idea de crear un plan de contingencias.
En este capítulo hablare del porque tu negocio quizás no pueda permitirse que tus aplicativos críticos estén caídos y como te puede ayudar la tecnología de Virtualización para crear un plan de contingencias.
Brevemente expondré primero lo que deberías considerar para aumentar la disponibilidad de tus datos y los métodos que existen para prepararnos antes posibles fallos.
Actualmente existen multitudes de necesidades tecnológicas dentro de una organización, cada uno con un coste asociado e impacto en el negocio. Asimismo, hay diferentes métodos y niveles de inversión que son requeridos para resolver cada necesidad en particular.
También existen, por ejemplo, diferentes razones por las que los sistemas pueden fallar, desde apagados controlados para actualizar el hardware hasta desastres naturales como huracanes, incendios o inundaciones. Las paradas de servido mas comunes son los que llamamos apagados controlados, y fallos de los componentes de un servidor, es decir, fallos de componentes electrónicos, como memoria, procesadores, placas, como vemos el la imagen.
Para proteger tus datos ante fallos, pensemos como una cebolla protege su núcleo, por capas. Un aplicativo en cluster nos protegería ante fallos en algunos de los componentes técnicos del servidor (disco duro, memoria, etc). Este también nos protegería ante fallos humanos (alguien podría borrar un fichero critico del sistema operativo y dejar inestable la aplicación en uno de los nodos del cluster).
¿Pero nos protegería ante desastres naturales como una inundación en nuestro centro de datos o un incendio o incluso peor un ataque terrorista?
Como vemos en el grafico anterior, la implantación de este tipo de sistemas tolerante a fallos, empieza desde arriba y cada capa (cebolla) ofrece un nivel adicional de protección para las necesidades de cada centro de datos. La clave es encontrar el nivel de disponibilidad que mas se ajuste a nuestras necesidades y para cada aplicativo en particular.
No obstante no cabe duda de que cuando un fallo ocurre este tendrá un impacto en nuestro negocio y este impacto será mayor o menor dependiendo de cómo estén tus datos protegidos ante fallos. Pero como consigues mantener tu centro de datos altamente disponible ante cualquier fallo ya sea mecánico, humano, o desastre natural?
La respuesta a esta pregunta debe basarse por supuesto en la siguiente pregunta: “si esa persona, proceso o tecnología deja de funcionar “, cuál sería el impacto que tendría en cuanto a la continuidad de nuestro negocio?”
Así pues la respuesta correcta, por ejemplo para un servidor de archivos caído poco utilizado y que no sea imprescindible, seria que este tendría un impacto muy “pequeño” – si servir archivos no es el core de tu negocio -, así pues poco o nada necesitamos hacer o planear para la continuidad de este servicio o aplicación. Sin embargo una aplicación critica como puede ser el correo electrónico (herramienta que utilizamos diariamente con proveedores, clientes, partners, etc) tendría obviamente un impacto mas alto para tu negocio ante el hipotético caso de que este servicio fuese interrumpido, con lo cual necesitaríamos protegernos mucho mas ante una caída o fallo de esta aplicación.
Y es aquí en este punto donde la tecnología de virtualización entra de lleno para ayudarte a proteger de una forma más dinámica tus aplicativos ante fallos catastróficos o no tan catastróficos.
Aumenta la disponibilidad de las aplicaciones críticas sobre una plataforma virtual
Cada año centenares de centros de datos experimentan caídas significativas de servicio debido a alguno de los problemas que he mencionado anteriormente (errores humanos, fallos en el hardware, virus, etc. En el año 2000 Gartner realizo un estudio a gerentes de IT en Estados Unidos el cual sugería que el 60% de los negocios administrados por estos gerentes analizados, no poseían un plan básico para mitigar los efectos de un posible desastre natural.
Incluso después de los trágicos eventos del atentado terrorista en Estados Unidos, muchas de las organizaciones todavía no han implementado un plan de contingencia. Dicho de otro modo, el 60 % de las organizaciones analizadas por este analista independiente serian afectados gravemente en caso de desastre y cerrarían sus negocios debido al alto coste que esto supondría tener que restaurar operaciones (sin contar el coste indirecto de la reputación).
Sin embargo mediante el uso de una infraestructura virtual, los gerentes de IT podrían mejorar muchos de los aspectos de su plan de contingencias pues este seria:
Entorno mas flexible y consistente (VM son independientes del hardware físico en el que residen) con un menor coste que un entorno físico. No es necesario tener recursos hardware duplicados en el centro remoto (DR site)
Reducciones significativas en apagados controlados y no controlados (mediante la encapsulación la VM puede ser copiada a otro servidor físico para ser lanzada en el caso de un fallo en el equipo). Esta tecnología nos permite migrar un VM “online” a un servidor físico diferente sin interrupción en el servido. Esto nos permite reconfigurar y optimizar recursos sin impactar a los usuarios. También así organizaciones podrán reaprovisionar dinámicamente estos recursos (VM) online para cubrir picos en la demanda (el data center del futuro)
Reducción en los proceso en la implementación de nuestro plan de contingencias (trabajar con maquinas virtuales (VM) resulta mas fácil y mas “barato” que trabajar con servidores físicos, al menos para mí).
El movimiento se demuestra andando: Un caso práctico con infraestructura virtual
Para ayudarte a entender esta tecnología de replicación por cabina para aquellos que estéis interesados en este tipo de soluciones, he creado una solución típica de replicación de cabinas.
Básicamente se trata de conectar a través de fibra óptica el centro de datos primario con el centro de datos secundaria.
En el vídeo estoy simulando un fallo natural en nuestro centro de datos de producción mientras nuestro aplicativo esta ejecutándose a pleno ritmo, pero no te alarmes, no simulo ningún incendio o algo parecido.
Trascurridos unos minutos levantamos una copia exacta de nuestro entorno de producción en el centro de datos remoto sin ninguna pérdida de datos y con los datos consistentes.
Un dato muy importante es el hecho de que la LUN(logical unit number) en la SAN (storage area network) donde residen mis VMs se esta replicando en modo síncrono mediante el software mirrorview ( mecanismo de replicación basado en array para las cabinas de EMC) lo cual nos permite “levantar” el centro de datos en el emplazamiento remoto sin ninguna pérdida de información o datos.
Resumen
El centro de datos del futuro será aquel que este consolidado, sea escalabre, y utilicé tecnología estándar en la industria de los servidores para así ayudar a:
Simplificar la gestión del centro de datos
Mejorar la utilización de los servidores en el centro de datos
Obtener un escalado más económico (scale out) de este
Asimismo la importancia de proteger nuestros datos han aumentando considerablemente debido a nuevas leyes que obligan a tener implementado un plan de contingencias (Reglamento de Seguridad Real Decreto 994/1999 de 11 de junio) para organizaciones como bancos, hospitales, instituciones financieras, etc.
La consolidación de servidores nos ofrece una reducción importante en el coste del hardware y la virtualización nos facilita y nos ayuda a tener un plan de contingencias mas robusto, mas flexible y mas seguro.
Por favor, si te ha gustado este post dame tu puntuacion: [ratings]
Hola, que tal, como estais? Soy Jose Mª Gris y como cada jueves estoy aquí con vosotros para hablar de tema relacionados con el ecosistema de VMware.
Hoy vamos a ver una de esas historias que no sabes porque, pero al final acabas haciendo funcionar.
Situación: Tenemos una máquina VM con SO Guest XP. Esta máquina fue creada en su momento de forma un tanto “ a la ligera” y no se configuró el HD como SCSI, sino como IDE.
De acuerdo con la KB de VMware, editas el .vmx y cambias ddb.adapterType = “ide” por ddb.adapterType = “lsilogic” o en su caso ddb.adapterType = “buslogic”. Nada más queda que quitar este disco con “edit settings” de la VM (teniendo en cuenta de no hacer “Remove from disk” y seguidamente volvemos a añadirlo con Add, Hard Disk, Use existing Disk, seleccionando el mismo disco. El scsi ID debe leer SCSI 0:0. Sin más.
Pues bien, alguna veces me funciona y algunas veces no, dándome unos bsod de las narices.
Como lo solvento? Pues cuando tengo la VM antes de empezar me voy a la web de LSI e instalo en el SO Guest la WHQL 1.20.18.00 e instalo el driver sobre el HD IDE. Cuando este IDE “resucita” como LSIlogic encuentra el driver perfectamente y no me asusta con la bsod.
Si alguien conoce porque a veces va y a veces no, adelante. Cuidaros.
Por favor, si te ha gustado este post dame tu puntuacion: [ratings]
Hola amigos, soy Florián Murillo y vuelvo al ataque con temas de networking, hoy hablaré de como mejorar el rendimiento de nuestros interfaces de red de 10Gb utilizando Virtual Machine Device Queues (VMDq) de Intel.
El ratio de consolidación en los sistemas actuales, me refiero al número de VM que “corren” en un servidor físico, está aumentando considerablemente, según mis estimaciones, se ha multiplicado por 4 en los últimos 4 años, esto lleva parejo una consolidación del tráfico de red y tenemos la tentación de pensar que con ampliar los interfaces de red lo arreglamos, pasando de 1Gb a 10Gb, pero hemos de pensar que la mejora de rendimiento no es lineal con el aumento de ancho de banda, ya que el vmkernel ha de procesar y clasificar mucho mas tráfico, consumiendo CPU, convirtiendose en un cuello de botella y esto ocurre para el tráfico saliente y el tráfico entrante.
VMDq es una tecnología que permite realizar la clasificación del tráfico en el interfaz de red, creando colas de entrada/salida y especializando estas colas en VM especificas, descargando al VMkernel, evitando cuellos de botella y aumentando la velocidad de transmisión.
En pruebas de laboratorio con controladoras de red Intel 82598 de 10Gb, Intel midió, en un escenario concreto, velocidades de transmisión de 4.0Gbps sin VMDq y 9.2Gbps con VMDq, o sea a mas del doble, y todavía mejoro un poco (9.5Gbps) utilizando jumbo frames en el escenario final.
He visto pruebas parecidas con controladoras de red de Neterion.
La implementación de VMDq en VMware se llama NetQueue, y está disponible desde VI 3.5 U1. En vSphere v4 está activada por defecto, por lo que solo hemos de configurar el interfaz de red para soportar NetQueue y a disfrutar de sus beneficios.
¿Como verifico que NetQueue está activado en mi ESX?
Comprueba que en Configuration > Software > Advanced > VMkernel tengas VMkernel.Boot.netNetQueueEnabled activo, si no es así lo activas y reinicias el ESX.
Lo que estamos haciendo, en realidad, es cambiar el archivo /etc/vmware/esx.conf añadiendo la linea /vmkernel/netNetqueueEnabled = “TRUE”
¿Como configuro mi interfaz de red para soportar NetQueue?
El comando siguiente es para una Intel 82598 de un solo puerto, los parámetros pueden cambiar de nombre de un interfaz de red a otro.
esxcfg-module -s “InterruptType=2 VMDQ=16″ ixgbe
Donde InterruptType activa MSI-X, es una exigencia de NetQueue, permite a la controladora ethernet enviar datos a multiples cores aprovechando las interrupciones.
El parámetro VMDQ especifica el número de pares de colas de entrada y salida que tendremos, estas colas se asignaran automáticamente a las VM para aumentar la eficiencia. El número de colas depende de la interfaz ethernet, cuantas mas tenga, mejor.
Tras el comando esxcfg-module, hemos de reiniciar el ESX y ya está configurado NetQueue.
Santiago Gonzalez Ayçaguer , ingeniero superior de sistemas, y que en la actualidad reside en Uruguay trabajando para GEOCOM como consultor senior de Virtualizacion Vmware, me ha mandado un documento que no tiene ningún desperdicio.
El documento explica muy bien y en gran detalle la instalación y configuración del agente de UPS APC para VMware ESX. Es un documento bastante interesante, sobre todo si necesitas saber cómo se instala el software de agente de una UPS en VMware ESX.
Muchas gracias Santiago por compartir desinteresadamente tu documento y enhorabuena por un trabajo bien hecho. Podéis leer el documento de Santiago Gonzalez Ayçaguer sobre la instalación y configuración del agente UPS APC para VMware ESX en este enlace.
Y a ti, mi querido lector, si tienes algún documento o how-to similar, el cual quieras compartir con esta gran comunidad de virtualización, no dudes en ponerte en contacto directamente conmigo.
Hola a todos, soy Florián Murillo y hoy quiero hablar del impacto que está empezando a tener el Ethernet Unified Fabric en el mundo de las redes de datos y las redes de almacenamiento.
Bajo el aparatoso nombre de Ethernet Unified Fabric, nos encontramos la fusión entre las redes de almacenamiento, dominadas por Fiber Channel (FC) y las redes de datos dominadas por Ethernet.
En definitiva, consiste en encapsular Fiber Channel sobre Ethernet en una trama jumbo frame de 2500 bytes.
Esto, que se explica rápido, conlleva unas implicaciones fascinantes, para empezar la fiesta, acabamos de llevar la consolidación al mundo del I/O, ya que hemos consolidado la red de datos y de almacenamiento en una sola y para ello utilizaremos en nuestros queridos servidores ESX unas tarjetas Converged Network Adapter (CNA), que son tarjetas que cara al switch son interfaces Ethernet de 10GB y que cara al host ESX presentan interfaces vNIC e interfaces vHBA, con lo que la encapsulación de FC a FCoE se realiza transparentemente en la tarjeta CNA y llega al switch en una VLAN.
¿Y como sigue la fiesta? pues con switches Ethernet Unified Fabric, como los Cisco Nexus 5000, que son capaces de tener puertos Ethernet a 10GB y puertos FC a 8GB, por lo que el tráfico FCoE que llega del host ESX se desencapsula en el switch y envía las tramas FC a la cabina de discos.
¿Y como acaba la fiesta? pues para acabar llegará Data Center Bridge, con extensiones al Ethernet para adecuarlo a las necesidades del Data Center:
Priority based Flow Control (PFC) IEEE 802.1Qbb proporciona mecanismos de control de flujo utilizando la función PAUSE definida en el IEEE 802.3
Enhanced Transmission Selection (ETS) IEEE 802.1Qaz con el que podemos crear flujos prioritarios, asignar anchos de banda por flujo y tratar las diferentes “sensibilidades” que tienen tráficos tan distintos con los tráficos IPC, LAN y SAN conviviendo en un enlace.
Data Center Bridging Capabilities Exchange Protocol (DCBX) IEEE 802.1AE proporciona a DCB la capacidad de descubrir las características del otro extremo del enlace (por ejemplo, si soporta PFC), también ayuda en la sincronización de extremos y la autoconfiguración de capacidades, esto abarca la conexión entre switches o la conexión entre host y switch.
Y como la fiesta acaba de empezar, pronto llegarán nuevas funcionalidades para el DCB, como Energy Efficient Ethernet, Quantized Congestion Notification, Shortest Path Bridging y mas …
Y si no se retrasan los amigos del IEEE 802.3ba tendremos en unos meses Ethernet a 40GB y a 100GB.
El wizard de la migración en caliente, VMware VMotion, valida los requerimientos del servidor origen y servidor destino así como los requerimientos de la maquina virtual que quieres migrar.
Una máquina virtual no puede ser migrada en caliente cuando:
La MV tiene una conexión activa a un virtual switch de uso interno.
La MV tiene una conexión activa a un CD o disquete.
La MV tiene configurada una afinidad a una CPU.
La MV forma parte de un clúster Microsoft.
El wizard de migración en caliente, VMware VMotion, produce un warning cuando:
La MV tiene una conexión a un virtual switch de uso interno pero no está conectado.
La MV tiene una conexión a un CD o disquete pero no está conectado.
La MV tiene uno o más snapshots.
El servidor VMware vSphere ESX/ESXi no ha recibido un guest OS heartbeat (probablemente las VMware tools no han sido instaladas o configuradas adecuadamente).
El wizard de migración en caliente, VMware VMotion, muestra un mensaje de error si la máquina virtual no puede ser migrada desde el servidor origen al servidor destino. Sin embargo, con un mensaje de error de tipo warning, la máquina virtual puede ser migrada con VMotion sin problemas.
Asimismo, los servidores involucrados en la migración, servidor origen y servidor destino, deben cumplir los siguientes requerimientos:
Visibilidad de todas las LUNs (FC, iSCSI, NAS) usadas por la MV.
Una red Gigabyte Ethernet dedicada al tráfico VMotion. (En una red 10/100 también funciona pero va muchoooo mas lento. No ostante, VMware solo soporta una red Gigabyte para el trafico VMotion.
Acceso a la misma red Ethernet física.
El nombre de los virtual switch debe ser igual en ambos Servidores ESX (incluyendo mayúsculas y minúsculas). En VMware vSphere ESX/ESXi versión 4 update1, si los virtual switches no son nombrados iguales, el wizard de migración en caliente VMotion produce un warning pero la migración puede continuar.
CPUs compatibles o similares (misma familia CPU). VMotion también funciona, si el servidor origen tiene Hyperthreading activado pero no el servidor destino
Seguro que se me escapan algunos requerimientos de VMotion, con lo que si no ves aquí todos, o crees que falta alguno, por favor déjame tu comentario.
Me acaban de llegar a las manos las hojas técnicas de los nuevos servidores de Cisco.
Mucho hemos oído hablar de que Cisco quería entrar en el tema de Servidores de la mano de su coalición con VMware. Y aquí están.
Os presento al UCS C200 M1 High Density Rack-mount server. Servidor de 1U con 2 sockets y con 12 slots de memoria, llegando a poder instalar 96 Gb con alta densidad o bien llegar a tasas altas con precios asequibles.
Incorpora 2 Nics de 10 Gb y un nuevo chipset que es capaz de gestionar la memoria para ofrecer más memoria de la que realmente tiene (me han dicho un número de veces que quiero antes validar.)
A ver si me cae uno en demo y os cuento cosas bonitas sobre ellos….. también hemos de ver los precios.
Hola amigos, si recordaís hace ya algunos post os comentaba que Citrix lanzó NetScaler VPX, appliance que podemos descargar desde la web de Citrix e importarla sobre nuestro XenServer y que es muy interesante según que entornos pero que viene limitada según los recursos hardware de nuestro hypervisor.
Os recuerdo alguna de sus características:
Maximum HTTP throughput – 1Gbps
Maximum compression – 750 Mbps
Maximum Application Firewall – 500 Mbps
Maximum SSL transactions/second – 500 Mbps
Maximum SSL through put – 1Gbps
Hoy os explicaré las diferencias que tiene con la versión hardware y recomendaré cuando hay que usar uno u otro.
La principal diferencia entre ambos es el rendimiento. La versión virtual de NetScaler no incluye hardware especifico para la aceleración SSL. NetScaler VPX soporta etiquetado de tráfico pero este es limitado a lo que soporte nuestro hypervisor. En cambio NetScaler MPX tiene soporte nativo para 802.1q.
NetScaler VPX no soporta 802.3ad, es decir link aggregation, puesto que no es soportado por XenServer. NetScaler MPX sí que tiene soporte nativo para 802.3ad.
¿Cuando debemos usar uno u otro?
Utilizaremos la versión hardware cuando:
- Necesitemos grán ancho de banda y rendimiento.
- Necesitemos gran volumen de tráfico SSL
- Mas de 100 sesiones VPN concurrentes.
- Sea requerido FIPS
Utilizaremos la versión virtual cuando:
- Estemos en entornos de pruebas o de desarrollos.
- Datacenters virtualizados y con hypervisores con gran capacidad de proceso.
Nada mas, espero que si os veis en situación de elegir uno u otro os sirva de ayuda.
La semana pasada Microsoft y HP anunciaron un acuerdo de colaboración millonario – $250 millones de dólares – para ofrecer directamente en partnership, un nuevo modelo de infrastructure-to-application y soluciones avanzadas de cloud computing para reducir los costes y la complejidad de TI.
La virtualización es, por supuesto, el centro de atención del partnership entre Microsoft y HP. Las nuevas soluciones basadas en infraestructura HP y software de virtualización de Microsoft, Hyper-V, en teoría, permitirán a los clientes acelerar el tiempo de despliegue de las aplicaciones, reducir el tiempo de caída no planificada, y reducir los costes de infraestructura.
Este es, sin lugar a dudas, un gran compromiso por parte de ambas empresas. El acuerdo, establece tres componentes principales:
Una hoja de ruta común de ingeniería para garantizar una integración sólida entre el hardware y software de las dos compañías, Microsoft y HP.
Soluciones conjuntas para optimizar y simplificar el despliegue, gestión y “salud” del centro de datos.
Una inversión inicial en el departamento de ventas, de servicios y para los programas del canal.
Puedes ver el comunicado de prensa en este enlace, y los videos ejecutivos y más información adicional en este otro enlace.
Habrá que ver, que clientes se decantan por utilizan HP + Microsoft Hyper-V en la nube y cuales se deciden por usar Hp + VMware vSphere …. y lo mas importante, cual es el factor de elección de una solución vs la otra por parte del cliente?. El tiempo nos dirá.
VMware vSphere tiene una manera muy “peculiar” de balancear el uso de ciclos de CPU física en un servidor VMware ESX/ESXi y pensé, a raíz de una discusión muy interesante iniciada por un usuario en los foros de VMware, que también te interesaría saber, mi querido lector, lo siguiente:
El VMware VMkernel dinámicamente “migra” las máquinas virtuales de CPU cada 20 milisegundos.
Para máquinas virtuales con múltiples CPU virtuales (vCPUs), el VMkernel intentara por todos los medios no poner más de un ciclo de ejecución de una misma máquina virtual en un mismo core. Sin embargo, con la tecnología hyperthreading habilitada, el scheduler del VMkernel tiene más CPUs que verificar.
El uso de la tecnología hyperthreading, permite convertir un core físico en dos – uno físico y otro lógico -, aunque esta tecnología no garantiza el doble de potencia para las máquinas virtuales, es decir, el escaldo no es lineal. Intel estima una mejora en el rendimiento de un 20%, aunque hay excepciones.
Hyperthreading suele estar deshabilitado en la BIOS del servidor físico. Mas cosas, las tareas del Service Console siempre son ejecutadas en la CPU con el ID número 0. El VMkernel nunca migrara ninguna tarea relacionada con el Service Console a otro core diferente.
Recuerda que en vSphere, una máquina virtual puede tener hasta un máximo de 8 vCPUs y ahora, el número de vCPUs puede ser impar. Aunque la máquina virtual puede usar tanto los cores físicos como los lógicos, el scheduler en VMkernel siempre intentara usar los cores físicos versus los lógicos, y siempre que hyperthreading este activado, obviamente.
Moraleja: un servidor vSphere con hyperthrering activado tendrá la capacidad de ejecutar mas threads simultáneos en paralelo (cpu fisica y cpu logica), por consiguiente, la teoría dice que el rendimiento de la infraestructura virtual seria mayor.
Descubre todos los secretos de VMware vSphere 4 y aprueba el examen de
certificación oficial VMware VCP-410 GARANTIZADO.
Regístrate y
recibe un capitulo del libro totalmente gratuito
