Hola amigos, soy Ferran Serafini y hoy en nuestra sección de XenServer, veremos como optimizar el rendimiento de las CPUs de nuestras máquinas afinando la configuración de nuestras máquinas virtuales para que se ajusten a nuestros requerimientos.
Primeramente comentar que por defecto, XenServer divide los recursos físicos de CPU utilizando un algoritmo de equilibrio por partes iguales. Es decir que cada máquina virtual obtiene su parte de recursos de CPU de manera equitativa.
Lo que vamos hacer hoy es modificar esta configuración que viene por defecto y asignaremos a las máquinas virtuales los valores que más nos convengan.
Tenemos 3 opciones:
vCPU pinning: Esta opción otorga CPUs físicas a las vCPU de las máquinas virtuales. Podemos mapear por ejemplo las CPUs físicas 1, 2, 3 a la máquina virtual con el siguiente comando.
vCPU Priority: Ajustando este parametro modificamos el peso que tiene una máquina virtual sobre el tiempo de CPU que comparte con las otras máquinas virtuales. Por lo tanto podemos asignar más o menos tiempo de CPU en función del rendimiento que queramos asignar.
Con el comando anterior, asignamos un peso de 512 a nuestra máquina virtual. Nos va permitir que esta máquina virtual tenga el doble de tiempo de CPU de cualquier otra que tenga un peso de 256 cuando el Host XenServer tenga todos los recursos en uso. Sin duda es la forma más razonable de “tuning de CPU” ya que es la menos posesiva/agresiva.
CPU cap: Esta opción nos permite fijar la cantidad máxima de uso de CPU que puede utilizar una máquina virtual.
En este ejemplo hemos configurado nuestra máquina virtual para que solo pueda utilizar el 80% de una CPU física. Si queremos que solo pueda utilizar 4 CPUs pondríamos el valor 400.
Esta forma es útil sobre todo para máquinas de test que no queremos que nunca llegue a penalizar el rendimiento de las otras máquinas virtuales.
Con esto me despido por hoy, espero como siempre que te haya parecido interesante. Un saludo.
¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Hola soy Miguel Ángel Alonso, y aquí estoy como cada martes para contaros algo nuevo sobre el maravilloso mundo de la virtualización de sistemas.
El tema de hoy es muy cortito pero no por ello menos interesante. Hasta la versión 5 de vSphere no podíamos cambiar la dirección MAC de nuestras máquinas virtuales y siempre debían entrar en el rango de direcciones MAC que VMware nos ofrecía (00:56:XX:XX:XX).
Este simple hecho, podía llevarnos a tener más de un problema a la hora de crear, o más en particular, de convertir una máquina de físico a virtual o de virtual a virtual, la cual se viese obligada por temas de licenciamiento con MAC subyugada a dicho propósito.
Si queríamos cambiar esta dirección MAC para la tarjeta de red en cuestion de tu máquina virtual, nos encontrábamos con el problema que adjunto en la foto de presentación de este post.
No obstante, si ya has instalado la nueva version de VMware ESXi5, podrás respirar tranquilo en cuanto a que este problema ya ha desaparecido y podrás cambiar la dirección MAC de tus máquinas virtuales sin tener el problema aqui descrito.
Lo bueno de ello es que nuestra tarjeta de red cojera estos cambios sin pasos añadidos, facilitando te de sobremanera dicho trabajo.
Bueno, hasta aquí por hoy, espero haberte podido contar algo de tu interés y me despido hasta la semana que viene con un nuevo tema del mundo de la virtualización. Hasta la semana que viene!
¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Opsss… ¡¡hace más de un año que lo escribí!! Menos mal que sigue siendo válido…
Ahora ha llegado el momento de agarrar un servidor ESXi y conectarlo a un switch físico con Cisco NX-OS. Cisco NX-OS es la evolución de Cisco IOS adaptado a las necesidades del Datacenter. Concretamente, para el ejemplo, vamos a utilizar un Cisco Nexus de la familia 5000.
Pero antes, definiré el concepto BPDU para evitar que nadie se quede por el camino:
Bridge Protocol Data Units (BPDUs) son paquetes de red que contienen información del protocolo spanning tree (STP). Los switches mandan BPDUs usando la dirección MAC del switch como origen y la dirección MAC multicast 01:80:C2:00:00:00 como MAC destino.
Existen tres tipos de BPDUs: De configuración de la topología, de notificación de cambio topológico y de confirmación de notificación del cambio topológico. Por defecto se envían cada 2 segundos.
Volviendo al Cisco Nexus 5000, la configuración de cada puerto del switch físico donde se conecta una vmnic podría ser algo así:
Define las VLANs que permitimos pasar por este puerto de trunk
router(config-if)# spanning-tree port type edge trunk
Es un puerto que no emite BPDUs de spanning-tree y no participa en el cálculo de la topología de STP, ha de ser así, el servidor ESXi no sabe lo que es una BPDU de spanning tree
router(config-if)# spanning-tree bpduguard enable
Si recibimos BPDUs bloquea el puerto, de un ESXi no vendrán BPDUs, evitamos de esta manera que se conecte otro switch a este puerto
router(config-if)#
Aunque esta configuración es correcta, no es la habitual. Para evitar repetir esta configuración en cada puerto que tenga la misma configuración creamos un port-profile e incluimos en él los comandos comunes. Luego, asignamos puertos al port-profile, aplicándoles los comandos al interfaz. Facilita mucho el cambio de configuraciones.
Aplicamos los comandos del port-profile a este interface
router(config-if)# exit
router(config)# exit
¿Se pueden construir grandes infraestructuras de cloud sin switches diseñados para datacenter? ¿Qué opináis?
¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
En la tabla adjunta, se muestran los cinco tipos de almacenamiento soportados en VMware vSphere™ ESXi 5, así como las diferentes funcionalidades soportadas por cada tipo de almacenamiento.
Con relación a la conectividad iSCSI y su iniciador de software iSCSI, el máximo número de iSCSI targets es de 265. Nota que ahora es posible hacer Boot from SAN (BFS) con iniciadores de software iSCSI.
Asimismo, no es posible crear más de un NIC Teaming con el iniciador de software iSCSI con más de 8 vmnics (uplinks o tarjetas de red físicas disponibles en el servidor ESXi). Solo es posible tener un número máximo de ocho caminos por LUN para los volúmenes VMFS conectados vía software o hardware iSCSI.
En cuanto al tamaño máximo de un volumen VMFS para la versión 3 (VMFS-3) es de 2TB menos 512Bytes de espacio con un block size de 8MB. Sin embargo, en VMFS versión 5 (VMFS-5) el tamaño del block size es de tan solo 1MB, aunque es posible crear ficheros .vmdk con un tamaño máximo de 2TB. Recuerda que en VMFS versión 3 y con un block size de 1MB, el tamaño de disco de la máquina virtual (.vmdk) no podrá superar los 256GB de espacio en disco.
También, el tamaño máximo para un volumen RDM (de las siglas en inglés Raw Device Mapping) en VMFS-5 es de 64TB, siempre y cuando uses la funcionalidad de extenders a nivel VMFS y el modo de compatibilidad de este RDM sea físico. Sin embargo, para un volumen RDM VFMS-5 en modo de compatibilidad virtual, el tamaño máximo es de 2TB menos 512 bytes.
VMware vSphere™ ESXi 5 usa el protocolo NFS versión 3 para comunicarse con cabinas de tipo NAS. Nota que aunque NFS también puede usar la versión 4, esta no está soportada por VMware. En la versión VMware vSphere™ ESXi 5, ahora es posible montar hasta 256 volúmenes NFS por host.
Con relación a los ficheros swaps de las máquinas virtuales, el tamaño máximo que puede alcanzar este tipo de ficheros es de 1TB por máquina virtual, siempre y cuando, configures tu máquina virtual con 1TB de memoria RAM. Puedes ver más información sobre la configuración del block size en VMFS-5 en nuestro canal oficial de YouTube: VMware vSphere 5.0 en entornos SAN iSCSI
En cuanto al número máximo de targets que un servidor host puede ver con un adaptador Broadcom 10GB iSCSI es de 128 targets. El número máximo de tarjetas 1GB Ethernet Broadcom (bnx2) que un servidor host ESXi puede tener es 16.
Por ultimo, recuerda que es posible tener todas las funcionalidades enterprise de VMware (HA, vMoting, Storage vMotion, DRS) con un almacenamiento NAS via NFS. Interesante, ¿verdad?
¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
En el día de hoy, vamos a ver como configurar nuestros XenServer para poder enviar correos electrónicos desde ellos mismos utilizando un smarthost.
Es útil configurar un cliente de correo como mailx para poder enviarnos notificaciones de nuestros scripts como por ejemplo los scripts que se ejecuten de forma automática utilizando cron.
Citrix XenServer, tiene un corazón CentOS, por ello podemos instalar paquetes rpm compilados para CentOs 5. Desde un mirror cualquiera como:
Espero que como siempre, te haya sido de utilidad. Saludos
¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Esta semana, en el blog de virtualización y cloud computing en español, os explicare como desactivar la pestaña de Getting Started en VMware vSphere vCenter Server 5.
Ya esta disponible, en el canal de youtube del blog de virtualización y cloud computing, un nuevo video tutorial sobre la virtualización y VMware vSphere 5: ¿Cómo desactivar la pestaña de Getting Started en vCenter? Espero que te guste.
Nos vemos el próximo lunes con un próximo episodio donde te enseñare, otro video tutorial relacionado con la virtualización y la nueva versión de VMware vSphere 5.
¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Sin lugar a dudas, uno de los mayores y más sonados cambios en VMware vSphere 5 se ha dado en el modelo de licenciamiento, con la inclusión de un nuevo concepto llamado vRAM Pool.
En resumen, para lo que antes necesitábamos 2 licencias de vSphere, ahora es posible que necesitemos 4 ó mas, dependiendo del entorno y cliente. Voy a explicarlo con un ejemplo muy claro.
Con VMware vSphere™ 4.x
Dell R710 con 2 sockets y 192G de memoria = 2 Licencias de vSphere Enterprise Plus
Dell R710 con 4 sockets y 256G de memoria = 4 Licencias de vSphere Enterprise Plus
Con VMware vSphere™ 5.x
Dell R710 con 2 sockets y 192G de memoria = 4 Licencias de vSphere Enterprise Plus
Dell R710 con 4 sockets y 256G de memoria = 6 Licencias de vSphere Enterprise Plus
Adicionalmente a las licencias requeridas y necesarias para arrancar tus máquinas virtuales, también necesitarás licencias adicionales siempre que sobrepases el número de 16 cores o más por procesador o socket.
Por esta razón, VMware ha puesto a disposición de los clientes en general una herramienta gratuita llamada VMware Licensing Advisor, la cual te dará más información relativa al impacto que tendrá en tu entorno particular la actualización a la versión vSphere™ 5.
Por consiguiente, ahora si dedicas más memoria vRAM a tus máquinas virtuales de la que has licenciado, sencillamente tus máquinas virtuales no arrancarán. Para la versión Essential y Essential plus esta comprobación es obligatoria, es decir, si has licenciado un pool de vRAM de 32GB y tienes ya esta cantidad de memoria configurada y usada en tus máquinas virtuales, al arrancar una máquina virtual que necesite usar 1GB adicional no lo hará.
Sin embargo, con las licencias a partir de la Essential Plus, si sobrepasas la configuración de la memoria en tu pool vRAM, recibirás un warning avisándote de que estas usando más memoria de la que has licenciado y que requieres comprar más licencias. No obstante, tu máquina virtual arrancará.
Supongo que la buena notica es que VMware vSphere™ ESXi 5 (como todas las versiones anteriores) permite usar el producto durante 60 días (Evaluation Mode) con toda su funcionalidad incluida.
¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Hola amigos, hoy os presento Xen Cloud Plataform (XCP), ya desde la versión 1.0 la estoy utilizando y creo que ha llegado el momento de hablar un poco sobre este proyecto libre. Para los que no lo conozcáis, deciros que es una solución open-source derivada de Citrix XenServer 5.6.FP1 totalmente funcional.
XCP es una versión empaquetada de GNU/Linux CentOS (kernel 2.6.32) con Xen 3.4.2 y XenAPI (XAPI). Por lo tanto, los que ya estéis usando XenServer, vereis quela Xapi y sus comandos son los mismos y además es compatible con XenCenter.
Hay mutiltud de herramientas de administración, tanto del uso tradicional del hipervisor como frontends de gestión de clouds, compatibles con XCP: http://wiki.xen.org/wiki/XenManagementTools
También nos ofrece, al igual que Citrix XenServer, soporte para HVM (si el servidor físico lo soporta), paravirtualización de nuestros servidores GNU/Linux (PV) y soporte nativo de máquinas instaladas con Citrix XenServer.
Podéis ver una matriz de funcionalidades donde se compara Xen Cloud Plataform con las distintas versiones de licenciamento de Citrix XenServer:
La instalación es idéntica a la que tenemos con Citrix XenServer, se basa en una imagen de cd .iso auto-arrancable que en unos pocos pasos permite tener el sistema completamente operativo.
Por supuesto trae consigo soporte para bootear sobre SAN, hbas, multipath, soporte para i-scsi y un largo etc. Que podeis ver en: http://xen.org/download/xcp/index.html
La última versión oficial disponible es la XCP 1.1 que recomiendo a todos los lectores, probarla, no deja indiferente
Con esto, espero como siempre que os sea de utilidad. Saludos
¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Continuamos hoy con la segunda parte a la entrevista de nuestro amigo George Teixeira, CEO de DataCore.
JMG: ¿Por lo que se puede intuir, el mundo del Storage va a tener una gran importancia en el futuro próximo, es así?
GT: El software de virtualización y los hipervisores de storage ocuparán el centro de atención en 2012 llevando a los usuarios hacia un nuevo nivel de intercambiabilidad y comodity “buying power” a nivel de hardware.
“Más hardware al problema” sigue siendo el mantra del proveedor de storage; sin embargo, el ritmo de crecimiento y la complejidad de gestión del storage están cambiando el modelo. Las teorías “más hardware” no funcionan. La virtualización y las clouds son básicamente software. Con el alto ritmo de crecimiento en storage, virtualización y Cloud computing cada vez queda más claro que un modelo de storage basado en hardware no es práctico. Una “mentalidad hardware” restringe la eficiencia y la productividad, mientras que el software que hace posible la intercambiabilidad del hardware elimina estas características críticas.
El modelo de hardware va en cotra de las tendencias de mercantilización, apertura y pool de recursos que han dirigido la indústria de las IT a lo largo de la útima década. El software es la solución para automatizar e incrementar la gestión de la producción, al mismo tiempo que añade la flexibilidad y la inteligencia para aprovechar, agrupar e incentivar el total uso de las inversiones en hardware.
Como el mundo se mueve hacia la Cloud y entornos de IT virtualizados, los modelos de software que permiten la intercambiabilidad del hardware, las compras “open market” y mejor gestion de recursos para storage, serán los ganadores.
JMG: Y sobre el “Big Data”
GT: “Big Data” continuará acaparando la mayor parte de la atención, pero “Small Data” continuará siendo donde estará “la acción real” en 2012.
Sí, “Big Data” está acaparando la atención y sí, “Big Data” necesita “Big Storage”, así que cualquier proveedor de storage hará el “buzz” en 2012. “Big Data” tiene muchas definiciones, pero lo que es obvio es que los ritmos de crecimiento y la cantidad de datos almacenados siguen creciendo. “Big Data” requiere mejores soluciones para que sus costes sean gestionados efectivamente. La firma IDC cree que la información mundial se duplica cada dos años. Hacia finales de 2011, de acuerdo con IDC, el mundo ha creado la sorprendente cifra de 1.8 zettabytes de datos. En el 2020, el mundo habrá creado 50 veces ésta cantidad de datos, y los departamentos de IT tendrán que gestionar 75 veces el número de “containers de información” que hospedan estos datos.
Claramente, las compañías más grandes que gestionan petabytes, exabytes y más allá son el principal foco, pero las pequeñas y medianas empresas que trabajan con terabytes de información comprenden la vasta mayoría de la realidad. Y son estas pequeñas y medianas empresas las que necesitan soluciones de storage y gestión HOY. Estos negocios no pueden esperar hasta mañana, ni pueden permitirse malgastar sus inversiones en almacenamiento de datos existentes. En vez de eso, necesitan soluciones que instaladas en los dispositivos actuales, los hagan mas eficientes, más altamente disponibles, y fácilmente gestionables.
Las tecnologías de software como el thin provisioning, el auto-tiering, la virtualización de storage y los hipervisores de storage que posibilitan a los usuarios una fácil gestión de todas las bazas que requieren (estando alojadas en local, en remoto o en la Cloud) serán claves en 2012. “Big Data” será “the industry noise” y generará muchas nuevas innovaciones. “Big Data” también se beneficiará enormemente de estos habilitadores basados en software, pero la oportunidad del “Small Data” es extremadamente grande, y hacia ahí es donde va mi apuesta para 2012.
JMG: ¿Cuales son vuestras ideas en Datacore para el mercado español?
GT: DataCore ha implementado cerca de 20.000 licencias en Europa y la compañía está haciendo del mercado español un foco para expandirse en 2012. DataCore ya tiene una fuerte presencia en el mercado español con clientes como Grup Perelada y sus Casinos o el Parlamento Vasco o el Ajuntament de Terrassa, y continuará incrementando sus inversiones en personas y recursos para aumentar el negocio.
¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Esta semana, en el blog de virtualización y cloud computing en español, os explicare como activar y configurar el plugin Hardware Status en VMware vSphere vCenter Server 5.
Ya esta disponible, en el canal de youtube del blog de virtualización y cloud computing, un nuevo video tutorial sobre la virtualización y VMware vSphere 5: ¿Cómo activar y configurar el plugin Hardware Status en vCenter? Espero que te guste.
Nos vemos el próximo lunes con un próximo episodio donde te enseñare, otro video tutorial relacionado con la virtualización y la nueva versión de VMware vSphere 5.
¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Esta semana, en el blog de virtualización y cloud computing en español, os explicare como activar y desactivar todas las alarmas en VMware vSphere vCenter Server 5 con tan solo un clic de ratón.
Ya esta disponible, en el canal de youtube del blog de virtualización y cloud computing, un nuevo video tutorial sobre la virtualización y VMware vSphere 5: ¿Cómo desactivar y activar las alarmas de vCenter 5 con tan solo un clic de ratón en VMware Sphere 5. Espero que te guste.
Nos vemos el próximo lunes con un próximo episodio donde te enseñare, otro video tutorial relacionado con la virtualización y la nueva versión de VMware vSphere 5.
¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes. Antes de nada quiero desearos un feliz inicio de año 2012 y que lo acabéis mejor que lo empezáis.
Alguna vez te has preguntado: ¿Cuanto dura un vMotion en una VM de 255GB de memoria asignada? es decir el límite de memoria de una VM en un host ESX/ESXi v.4 con hardware v.7 en la placa base de la máquina virtual. Pues con vSphere 5 aparecen VMs de hasta 1GB de RAM, anunciando migraciones de larga duración para máquinas virtuales de gran formato.
vSphere 5 trae una funcionalidad que no aparece entre las mas importantes pero que es muy bien recibida en entornos con grandes máquinas virtuales. Me refiero a la posibilidad de hacer vMotion utilizando varios interfaces de red SIMULTANEAMENTE.
En EMC han realizado un análisis de carga interesante, han comparado un vMotion con diferentes escenarios, con 1 NIC, con 2NICs y con 4 NICs.
La máquina virtual de test no está nada mal, un SQL Server con 60 GB de memoria, mas de 2TB de datos y 10.000 IOPS. Es decir una máquina virtual con alta actividad y tamaño medio/alto.
Los resultados (redondeados a minutos) han sido los siguientes:
vMotion con 1 puerto de vmKernel: 23 minutos.
vMotion con 2 puertos de vmKernel: 8 minutos.
vMotion con 4 puerto de vmKernel: 3 minutos
Para evitar dudas os diré que las pruebas se han hecho con todos los interfaces a 1Gbps y con una MTU de 9000 bytes, o como la conocemos coloquialmente con Jumbo Frame activado en todos los puertos de vmKernel.
¿Cuál es la conclusión?
En todo diseño con máquinas virtuales de tamaño medio o grande, hemos de tener en cuenta el tamaño de las maquinas mas grandes para atender sus necesidades de conectividad y sus necesidades de movilidad, o sea vMotion. La eficiencia obtenida es tan alta con vMotion multi-NIC que merece la pena invertir un poco en interfaces de red.
Con máquinas de gran tamaño ¿Os podéis permitir tardar mas de una hora en poner un host en mantenimiento? o bien que DRS tarde este tiempo en mejorar el balanceo de un cluster ¿impensable verdad?
¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
VMware vSphere™ ESXi 5 incluye dos nuevas funcionalidades para aumentar la seguridad del VMkernel:
Memory Hardening: El kernel del ESXi, aplicaciones user-mode y ejecutables como drivers y librerías están localizadas en zonas de memoria aleatorias para evitar que software del tipo troyanos averigüen de una forma sencilla la localización de estas zonas de memoria.
Kernel Module Integrity: Los módulos, drivers y aplicaciones de ESXi son “firmados” digitalmente para asegurar la integridad de estos una vez que el VMkernel los carga en memoria.
Asimismo, a diferencia de las versiones VMware ESX 4.x, en VMware vSphere™ ESXi 5 es posible hacer boot de tu servidor ESXi desde un disco USB externo. También es posible instalar tus servidores ESXi con la opción de VMware Auto Deploy, sobre todo cuando tienes un número de host importante que instalar. De esta forma, acelerarás la fase de instalación del binario de ESXi y el despliegue de tus máquinas virtuales.
Si haces una actualización de la versión ESX 4.x a la versión ESXi 5 el portgroup tipo Service Console (solo disponible en versiones ESX) será borrado, ya que en los servidores ESXi no existe un Service Console. Asimismo, el portgroup de gestión en ESXi es llamado Management Port. Recuerda antes de actualizar un servidor ESXi hacer una copia de seguridad de su configuración con el comando vicfg-cfgbackup desde el vCli.
Desde el punto de vista de almacenamiento compartido SAN iSCSC, el número máximo de LUNs iSCSI que puedes conectar a un servidor ESXi es de 256. Otro de los límites que han cambiado en esta nueva versión de VMware vSphere™ ESXi 5 con respecto a las versiones anteriores, es que ahora es posible tener arrancadas hasta 2.048 máquinas virtuales por volumen VMFS.
También, ahora es posible activar – y está soportado – el modo soporte (TSM – de las siglas en inglés Tech Support Mode) de modo que podrás entrar vía SSH a tu servidor ESXi. Puedes activar el modo TSM desde la DCUI (de las siglas en inglés Direct Console User Interface) o con el vSphere Client a través del panel Security Profile localizado dentro de la pestaña de Configuration.
Una vez entres en la consola de tu servidor ESXi vía comando, podrás ver los logs de tu sistema, configurar las propiedades de los servicios de DNS, NTP, arrancar máquinas virtuales, apagar servidores ESXi y un largo etcétera. Sin embargo, una de las pocas tareas que no podrás hacer desde consola es la de poner tu host ESXi en modo mantenimiento.
Para poder ver una guía de referencia de todos los comandos disponibles por consola en la versión ESXi 5.0, te recomiendo que veas el episodio número 31 de nuestro canal de televisión web sobre la virtualización y el cloud computing en español en la siguiente dirección: http://www.virtualizacion.tv
Asimismo, con el fin de mejorar la seguridad del servidor ESXi, VMware ha añadido un firewall embebido en el VMkernel. A diferencia de las versiones anteriores, este firewall no está basado en IPtables de Linux.
Por último, y si aún tienes servidores VMware ESX en tu entorno virtual y necesitas aplicar parches en el Service Console del ESX, debes de asegúrate de aplicar dichos parches solo y únicamente cuando VMware haya hecho público las actualizaciones y siempre que sea sugerido por personal autorizado de VMware o por el equipo experto de VMware llamado VMware Security Advisories. Para poder recibir alertas de seguridad sobre vulnerabilidades del software de VMware, puedes suscribirte en esta dirección: http://www.vmware.com/security
¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Buenos dias, de nuevo estoy con vosotros. Soy Jose Mª Gris y ante todo deseo que este año sea lo mejor posible para todos nosotros. Hay que ser optimistas
Creo recordar que vengo desde la version 2 de Veeam Backup. Ya llevamos cierto tiempo con los amigos del color verde (aunque ahora veo que en la version 6 predomina el “limon”).
Ha salido la versión 6 y lo cierto es que ha traido una serie de aditamentos “Enterprise” que son muy interesantes. Iremos hablando sobre ellos.
Pero empezaremos por su actualización de 5 a 6, que es lo primero que te encuentras cuando tienes que probar un nuevo paquete. Si lo instalas de nuevo, pues mas o menos es fácil, el problema es cuando tienes una versión anterior. Aquelo de que “el pasado pesa…”. Como siempre, Veeam impecable en sus actualizaciones, pero pasemos a verlo.
Detectará que hay una versión anterior y nos preguntará si deseamos upgradar. Contestaremos afirmativamente si es lo que deseamos hacer.
Aceptamos la “EULA”
Instalaremos el fichero de licencias (aunque sea Trial debemos instalarlo, para ello, hay que pedirlo en la Web)
Nos preguntará por la opciones que deseamos instalar
Seguidamente nos preguntará por el nombre de la instancia que va a utilizar en SQL y como se llama la Database. Nos dá opciones por omisión
Y entonces tenemos el punto más crítico, nos pregunta si deseamos conectar esta instalación con la BBDD y nos notifica que si es preciso, ésta será modificada.
Indicaremos el usuario, password con el que correrá el servicio, así com el puerto que va a usar
A continuación indicaremos la ubicación del catálogo de los “Guest file System” y “VPower NFS”, así como los puertos que va a usar.
Continuará la instalación, pidiendo efectuar un reboot.
Como viene siendo habitual, el upgrade perfecto y funcionando a la primera. Seguiremos hablando de esta nueva versión. Hasta la semana que viene, take care.
¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Hola amigos, después de unos días de vacaciones… hay que volver a la carga. En el último post sobre monitorización de XenServer con Nagios, faltaba ver la monitorización de storage y otros checkeos avanzados para tener bien controlada nuestra infraestructura.
Para monitorizar los SR de nuestro pool, primeramente hay que extraer la información que nos da la Xapi:
echo “Warning: Hay procs de XAPI pero algo falla $new_test”
exit=1
fi
fi
#Salida con el codigo de error para Nagios
exit $exit
A grandes rasgos el checkeo comprueba primeramente que hay procesos de Xapi en la “GNU/Linux LAND” y si existen, ejecuta un xe-host-list. Si este falla retornará código de error ya que aunque haya procesos, la XAPI no responde.
Estado de los caminos del Multipath
Es importante tener bien monitorizados los caminos si usáis multipath para los que utilicéis una cabina de discos. Una forma de comprobar que están todos OK es filtrar por faulty en la salida de multipath –ll
Con esto, espero haberos dado herramientas para que os programéis vuestros propios monitores, ya sea medianteXAPI o mediante comandos gnu/Linux y si me permitís, me encantaría saber que monitorizáis de vuestros XenServers. Un saludo.
¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Descubre y domina la nueva versión de VMware vSphere™ 5 y aprovéchate de hasta un
20% de descuento al comprarlo online.
Regístrate y
recibe un capitulo de nuestro nuevo libro totalmente gratuito
Nuevo Site Recovery Manager 4 en español Consigue una copia gratuita del eBook
