No te acostarás sin saber una cosa más, si Señor.

Estaba yo tan contento, preparando mi post de este jueves (éste, si, éste) y pensaba que versaría sobre una herramienta que me ha dado muchos alegrías. Hablo de Mremote, una herramienta que hace de cónsola / Shell para RDP, VNC, SSH, HHTP y alguno más.

En un proyecto me han pedido especial hincapié en tener una herramienta de este tipo, y buscando por esas webs de Dios, me encuentro con esta maravilla, Remote Desktop Manager by Devolutions, que encima es Freeware.

Integra los siguientes clientes: RDP and TS, MS Remote Assistance, Real VNC, TightVNC, UltraVNC, Citrix,LogMeIn, Team Viewer, Dameware, VMware Player, Workstation, vSphere, Hyper-V, Virtual PC, Virtual Server…. Add-ons para HP graphics, y SQL studio …. me dejo alguno que te interese? pues seguro que me lo he olvidado y seguramente está disponible. Increíble

Se puede hacer download aquí , bajas el .msi y lo instalas como un “my wife”, Al arrancar no te asustes, no te pide licencia, tan sólo te pide si lo quieres arrancar en modo Standard (Freeware) o Enterprise (de pago, básicamente con gestion de usuarios y soporte para SQL Server, Amazon S3, Multiusuario, etc). Obtendréis una vista como ésta.

Pero no terminan aquí las sorpresas. “File, Import, Import from another application, mremote” . Pues sí, te vas a tu Mremote que tienes funcionando, exportas un XML de la configuración de las conexiones y te lo importas a tu nuevo entorno (algún cambio tendrás que hacer, no todo es tan “directo”.

Aquí podéis ver el impresionante “pop up” de configuración con las herramientas que podemos integrar

Pero fijaros la lista que tiene especificamente para virtualización

Recordad que hay que instalar los clientes en la máquina donde vais a ejecutar la cónsola, y si no sabéis donde encontrarlos, en la pagina de download de la aplicación están los links necesarios, mas fácil imposible.

Le ha llegado la hora a mi fiel Mremote veo. Hasta la semana que viene.

Hola soy Miguel Angel Alonso y como cada Martes vuelvo al Blog de la Virtualización en español de José María Gonzalez para volver a contaros algo nuevo y siempre desde mi humilde opinión.

En este caso continuaremos con el capítulo 3 de VMware View que no es otro que el de Security Server; servidor que nos ayudará a encapsular nuestro tráfico mediante SSL por nuestro más que conocido puerto 443 y así de esta manera proteger todas nuestras sesiones de nuestros clientes con nuestro Broker de View a través de nuestras conexiones de INTERNET.

Además debemos saber que luego de nuestro Server security a nuestro Connection Server este se comunicará utilizando los puertos tcp : 8009 (AJAP139) y 4001 (JMS).

Todas estas comunicaciones mediante SSL servirán exclusivamente para nuestras conexiones mediante RDP ya que en caso de utilizar PCoIP deberíamos mapear el puerto tcp 50002 en nuestro querido Router para cada uno de nuestros Desktops Virtualizados .
Y por último pero no más importante deberíamos colocar nuestro Server Security en la DMZ de nuestra organización y no pertenecer o ser miembro del Dominio de nuestra organización.

Bueno explicado todo esto comenzaremos con la instalación de nuestro Servidor de Seguridad:

Habremos de empezar con el asistente de instalación de VMware View Connection Server, “Next” para comenzar…

Aceptamos el acuerdo de licencia y continuamos con el botón de NEXT

Indicaremos cual es la ruta de instalación por defecto que nos indica en este Snapshot y por supuesto; NEXT

Ahora elegimos el servidor que queremos instalar, que no es otro que nuestro Security Server

Ahora seleccionaremos la dirección en este caso FQDN de nuestro servidor Broker, aunque podríamos introducir perfectamente nuestra IP correspondiente; y NEXT

Comienza nuestra instalación …

Finalizaremos nuestra instalación y nos iremos a nuestro servidor Broker (Connection Server) para desde allí añadir y parametrizar nuestro nuevo Security Server

Seleccionamos la pestaña Configuration y en la sección Security Server en el enlace Add añadiremos nuestro Servidor de Seguridad

Introducimos el nombre de nuestro Servidor de Seguridad y le adjuntamos debajo la dirección HTTPS con su correspondiente puerto para nuestras conexiones externas. Después pulsamos OK.

Seguidamente seleccionaremos la opción Create Configuration File para generar un fichero de seguridad con el cual trabajará nuestro SS (Security Server)

Y seleccionamos guardar. Al fichero le llamamos config.propierties. Este fichero debe ser guardado en la carpeta “C:\Archivos de programa\VMware\VMware View\Server\sslgateway\conf\” del Security Server.

Lo siguiente que haremos será ir a nuestro Server Security de la DMZ y reiniciar el servicio VMware View Security Server y ya tendremos configurado nuestro Servidor de Seguridad.

Aquí os muestro un ejemplo de conexión mediante WEB por HTTPS a mi servidor Broker protegido por nuestro Security Server antes configurado

Bueno aquí me despido de vosotros por el momento hasta el próximo Martes en un nuevo capítulo que será el 4º y en el que veremos cómo instalar y configurar de Vmware View 4 Composer. Gracias como siempre a José María González y a todos nuestros lectores sin los cuales nada de esto sería posible.

El cliente vSphere es la principal interfaz para administrar todos los aspectos de tu entorno vSphere.

Es el interfaz para el servidor de vCenter Server y el servidor ESX/ESXi. También proporciona acceso a la consola de las máquinas virtuales.

Una vez que has instalado el servidor ESX o ESXi, una página de bienvenida es mostrada, a la cual es donde te debes conectar y desde donde te puedes descargar el cliente de vSphere

Para ver la lista de versiones de ESX y ESXi con el que el cliente de vSphere es compatible, consulte la guía de instalación en http://www.vmware.com/guides.html

En este episodio te mostrare como bajarte el cliente de vSphere para poder gestionar tu entorno una vez instalado el servidor ESX o ESXi:

Hola a todos, soy Florián Murillo y como en mi anterior post, continuo hablando de seguridad y networking, con una breve introducción de VMware vShield Zones y su aportación a la seguridad.

El origen de este producto hay que buscarlo en Blue Lane, empresa adquirida por VMware hace año y medio, y el producto actual tiene sus orígenes en VirtualShield, un buen IPS para entornos virtuales que, en manos de VMware, tras integrarse con VMsafe (API de seguridad) y evolucionar, renace como vShield Zones.

vShield Zones nace como una pieza clave en la arquitectura cloud de VMware, conjuntamente con vCloud y otros productos que poco a poco se van orientando a gestionar clouds y no dataCenters.

Otros productos y funciones aportan seguridad a nivel de host y a nivel de red, vShield Zones añade, además, seguridad entre las máquinas virtuales y el hipervisor.

Las funciones de vShield Zones son tres :

1. Nos proporciona un firewall virtual con persistencia de sesiones y que maneja reglas L2, L3 y L4.
2. Registro y análisis de tráfico, para análisis forense o detección de tráficos anómalos.
3. Descubre y construye un inventario de sistemas operativos, aplicaciones y puertos abiertos.

El producto tiene 2 partes, el vShield Manager y el vShield Agent, ambos son Virtual Appliances que se instalan como archivos OVF.

El vShield Manager monitoriza, configura y actualiza los vShield Agent que desplegamos sobre la infraestructura virtual, y como ya habéis intuido, los agentes se encargan de aplicar las reglas de firewall, de “capturar” el tráfico entrante y saliente, así como detectar S.O. y aplicaciones para construir el inventario en el vShield Manager (ver imagen siguiente).

VMware vShield

La arquitectura de distribución de los agentes de vShield Zones nos recordará a la disposición de los firewalls físicos que protegen DMZs, y la finalidad es la misma, en la imagen siguiente podemos ver el antes y el después de la instalación de un agente para securizar un Port Group llamado Servers.

Desde el vShield Manager le aplicaremos las políticas al agente y quizás os preocupe el hecho de que el port group Servers está conectado a un switch interno, imposibilitando el funcionamiento de vMotion, pero esto lo arreglaremos añadiendo en parámetro VMOnVirtualIntranet con el valor “false” en el archivo vpxd.cfg, este archivo lo encontrareis en la instalación del vCenter.

Me reservo para otro post la integración de los agentes de vShield Zones con los Virtual Service Domain de Cisco Nexus 1000V, nos elevará la seguridad de vShield Zones al siguiente nivel (opss, parece un juego).

No es el único producto para llevar la seguridad hasta el port group, existen otros productos interesantes como VMC de Reflex Systems o Virtual Network Firewall de Altor Networks, ¿estamos entrando en la era de los Virtual UTM Appliances?

Por todo lo comentado llegamos a hacernos preguntas en la línea de mi último post, ¿puede un experto en seguridad aplicar este nivel de seguridad sin conocimientos de vSphere y de networking?

¡Hola a todos de nuevo! soy Miguel angel Alonso y como cada martes estoy aquí para contaros algo nuevo que en este caso seguiré con el orden de los dos POSTS anteriores.

Hoy veremos la instalación, que es muy sencilla de un servidor Réplica para nuestro Connection Server, ya que de esta manera nos aseguraremos el mantenimiento del servicio en caso de caída y el balanceo de carga de nuestro Connection Server en función de nuestro número de conexiones a nuestros escritorios virtualizados.

Se debe instalar por lo menos un segundo servidor VMware View Connection Server para disponer de alta disponibilidad o balanceo de carga, a esto se le llama disponer de un servidor de réplica.

Al instalar en modo réplica Connection Server, se crea una instancia ADAM (Active Directory Application Mode) y se inciará el View LDAP data que permitirá mantener todos los servidores Connection Server con la misma información, ya que usará la misma tecnología de replicación del Directorio Activo para replicar los datos entre los Connection Server.

Lógicamente antes de realizar esta instalación, tendremos que tener un servidor Connection Server instalado.

La instalación de este componente no tiene nada, basta con ejecutar el asistente de instalación de Connection Server de nuevo en otro servidor, “Next”

Aceptamos el acuerdo de licencia “I accept the terms in the license agreement” & “Next”,

Seleccionamos la ruta de instalación, por defecto “%ProgramFiles%\VMware\VMware View\Server”, “Next”,

Debemos seleccionar la opción “Replica” para unirnos a otro servidor de nuestra instalación, “Next”,

Aceptamos la licencia de ADAM (Microsoft Active Directory Application Mode), “I accept the terms in the license agreement” & “Next”,

Debemos introducir un servidor VMware View Connection Server cualquiera de nuestra organización para poder replicarnos con él la configuración y los datos de nuestra instancia, “Next”,

Pulsamos “Install” para comenzar inmediatamente con la instalación del servidor de réplica,

Una vez terminada la instalación, si abrimos un navegador, contra cualquiera de nuestros Connection Server (https://ConnectionServer/admin), y vamos a la parte de “Configuración”, a “Servers”, podremos observar cómo ya tenemos un segundo servidor VMware View!

Bueno aquí me despido de vosotros por el momento hasta el próximo martes en un nuevo capítulo que será el 3º y en el que veremos cómo instalar y configurar de VMWare View 4 VMware View 4 Security Server.

Gracias como siempre a Jose María Gonzalez, mis compañeros del BLOG, a Xavisan y Cristiansan de CTXDOM y a todos nuestros lectores sin los cuales nada de esto sería posible.

También querría hacer una mención especial a nuestro nuevo compañero del Blog y que cada Viernes estará con nosotros para enseñarnos cosas nuevas y al que yo al menos espero con los ojos bien abiertos. Un fuerte abrazo y cálida bienvenida para Florián Murillo especialista del mundo de la Virtualización de Servidores, seguridad y Cloud Computing.

Hasta el próximo martes.

El role “Administrator” es el role con mas privilegios en vCenter Server. Este role permiete al usuario ejecutar cualquier accion disponible en vCenter Server y por consiguiente deberías otorgar este role al menor número posible de usuarios.

Por defecto, el grupo local “Administrators” de Windows, es añadido al role “Administrator” del servidor de vCenter.

Para limitar el alcance de acceso, es una buena practica evitar el uso de la cuenta de usuario Administrator de Windows para ejecutar vCenter Server. En su lugar, asigna el role Administrator a una cuenta o grupo normal sin privilegios administrativos.

En este episodio te enseñare como crear en el servicor vCenter un usuario mas restringido – en cuanto a privilegios – para sustituir así el grupo “administrators” del role Administrator:

La semana pasada te mostre como activar y configurar Jumbo Frames en un switch virtual.

En este otro episodio te mostrare a configurar Jumbo Frames en una máquina virtual Windows 2003 con el driver virtual vmxnet para una tarjeta a un Gigabit.

De esta forma tendrás Jumbo Frames configurado en todos los compoenens de tu entorno Virtual. No olvides de asegurarte que el switch físico en el que conectamos la tarjeta de red física de tu red iSCSI tiene también activado el soporte Jumbo Frames.

En caso de que tu switch físico no tenga soporte Jumbo Frames, es aconsejable no configurar Jumbo Frames en nuestro servidor VMware ni máquina virtual por razones obvias.

Por defecto, Jumbo Frames esta desactivado en VMware vSphere. La otra mala noticia es que tienes que “bajarte” de nivel (al Service Console) para poder activar Jumbo Frames en VMware vSphere.

Si recuerdas, hace una par de semanas, te mostré como activar Jumbo Frames en los nuevos vswtiches distribuidos en VMware vSphere. Para los vswitch distribuidos – solo incluidos en la versión Enterprise Plus de VMware vSphere -, activar Jumbo Frames es una tarea de un solo clic ya que existe la opción de activar Jumbo Frames desde la GUI – vCenter Client.

Desafortunadamente o afortunadamente, si te gusta bajarte de nivel y “trastear” en el Service Console, tendrás que saber cuál es el comando para activar Jumbo Frames en tu entorno VMware vSphere.

En este video te mostrare como activar la opción de Jumbo Frames en un vswitch virtual estandar:

Hola de nuevo, soy Miguel Angel Alonso y aquí estoy afortunadamente una vez más con vosotros para mostraros un nuevo artículo que espero que os guste y os pueda ayudar en vuestras inquietudes diarias de nuestro mundo de la virtualización.

Hoy le ha tocado el turno a cómo crear Multipathing desde la consola ESXCLI.

En el artículo de Chad Sakac y otros como(Netapp, EMC, Dell, HP, VMware) podremos tener acceso al nuevo método de Multipathing iSCSI para la nueva versión de ESX(vSphere).

Por fin en esta versión el iniciador ISCSI estará habilitado para múltiples conexiones  ISCSI. (Multipathing mediante múltiples conexiones TCP)

Estoy encantado realmente con dicha función y lo fácil de configurarala que es. Necesitarás varias pautas a seguir para su correcto funcionamiento. Necesitaremos asignar 2 NICs a un VMkernel (o más) y sólo una NIC áctiva. Las demás NICs las moveremos hacia abajo (DOWN) en la sección “Unused Adapters”.

Después de haber creado tus VMkernels y unirlos (Bound) a una NIC específica, necesitarás añadirlos a tu Software iniciador ISCSI:

1. esxcli swiscsi nic add -n vmk0 -d vmhba35
2. esxcli swiscsi nic add -n vmk1 -d vmhba35
3. esxcli swiscsi nic list -d vmhba35

Si chequeas tu cliente vSphere te darás cuenta que habremos conseguido 2 PATHS en tu ISCSI Target, aquí os dejo un ejemplo:

Y en el ESXTOP, puedes ver los 2 VMKernel Ports con su tráfico:

Esta es una de las muchas cosas que se pueden conseguir mediante la consola de comandos ESXCLI.

Por supuesto en el Screenshot de arriba podemos ver que nuestra opción de Multipathing está en FIXED, pero como ya sabemos podremos elegir también entre MOST RECENT USED (MRU) o ROUND ROBIN (RR).

Bueno por fin un artículo un poquito más corto de lo que es habitual en mí pero creo que no por ello menos interesante. Aprovecho de nuevo para saludaros y daros siempre las gracias por estar ahí y como no, una y cuantas veces hagan falta a Jose María Gonzalez y todos mis compañeros del Blog que son increíbles.

Hasta la próxima semana.

Es posible definir resource pools a nivel de servidor VMware ESX/ESXi o a nivel de clúster VMware DRS. Sin embargo, si a la hora de crear un clúster no seleccionas la opción Enable VMware DRS, la opción de New Resource Pool estará deshabilitada.

Para poder crear un New Resource Pool en un Clúster VMware DRS, asegúrate de habilitar la opción Enable VMware DRS durante la creación de tu clúster VMware o, en su defecto, puedes habilitar dicha opción después de la creación del clúster, seleccionando el clúster con el botón derecho del ratón y seleccionando Edit Settings. Después, haz clic en Enable VMware DRS.

Los resource pools creados a nivel VMware ESX/ESXi pueden ser heredados ( grafted ) e incluidos en un clúster vSphere VMware DRS, cuando incluyes un servidor ESX/ESXi con resource pools ya creados a nivel de host, a un clúster VMware DRS.

Sin embargo, la opción por defecto cuando añades un servidor ESX/ESXi a un cluster DRS es “Put all of this host´s virtual machines in the cluster´s root resource pool. Resource pools currently present on the host will be deleted”.

Para heredar los resources de tu servidor host ESX/ESXi a tu clúster DRS, asegúrate de seleccionar “Create a new resource pool for this host’s virtual machines and resource pools. This preserves the host’s current resource pool hierarchy”.

Los resource pools heredaros serán nombrados Grafted from + nombre del servidor VMware ESX/ESXi. Si posteriormente eliminas el servidor host ESX/ESXi de tu cluster DRS, los resource pools serán “retenidos”.

No obstante, si decides desactivar la opción DRS de tu cluster, perderás todos los resource pools de dicho cluster, previo aviso eso si, y tendrias que re-crearlos de nuevo.

Esto ha sido todo, hasta la próxima semana con un nuevo tip.

Después de 11 años haciendo exámenes de certificación en VMWare y más de 19 años en la industria de IT, hoy puedo confirmar con total rotundidez, que este es el examen más difícil que jamás he hecho.

Es tan difícil que, los 11 años de experiencia con productos VMware, cientos de proyectos de virtualización a mis espaldas – algunos de los proyectos en los que estuve involucrado hasta la “ceja” son dos de las granjas de VMWare mas grandes en EMEA ( Dell y BP ) , y todos los cursos oficiales de VMware Fast Track y VMware ICM que imparto y los ciento de estudiantes que formo mensualmente, no han sido suficientes para superar el examen.

Ciertamente estuve muy cerca, con un scoring de 268 – necesitas mínimo un score de 300 – de aprobar el examen pero el cansancio – mas de 2 horas y media de examen – y el que el día anterior no pude dormir mas que dos horas – el avión que me trajo desde Dublín a Madrid salió con mas de 5 horas de retraso -, hicieron mella en las mas que ya agotadas baterías humanas, aparte de que este examen no lo ha aprobado mucha gente.

Este es el primer examen oficial de VMware que suspendo, ciertamente me alegra saber que ha sido con el VMware Desing Exam VCP310 para conseguir la certificación VCDX.

El examen, en tres palabras: no me gusto. La primera parte, tuve que responder a 51 preguntas – algunas muy largas y con conceptos enrevesados y envenenados – y en otras el enunciado estaba mal – se nota que este examen esta aun en beta!.

En algunas de las preguntas tipo drag & drop, las respuestas podían ser arrastradas en múltiples casillas – según el enunciado – pero cuando arrastrabas un mismo icono dos veces en diferentes casillas no funcionaba, está seguro que la falle – como esperan que uno acierte semejante sinvergonzonería?

Con la segunda parte del examen, la cual es dibujar un diseño – nada del otro mundo -, tuve mas problemas intentando averiguar como funcionaba la GUI que con el diseño propio.

Moraleja, no me extraña que solo 20 personas en el mundo tenga esta certificación y que, según mis últimas informaciones, todos menos uno trabajan para VMWare. Creo que sería necesario saber las mejores prácticas internas de VMware si quieres tener, al menos, una remota posibilidad de aprobar este examen. Yo lo volveré a intentar próximamente……

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.

¿Hola que tal de nuevo?. Pido mis disculpas a José María y todos nuestros lectores por el retraso en mis POSTS ya que he tenido un ligero contratiempo a lo largo de este mes que me ha hecho ir más lento con vosotros de lo que yo quisiera.

Una vez explicado esto, quería haceros llegar algo que ya he probado y que me ha sorprendido por su funcionamiento con un programa de almacenamiento SAN como es Openfiler (Código Abierto). Como realizar un Cluster entre SAN con Openfiler para la redundancia de nuestras VMs?.

Mirando en varios Blogs y otros donde ponían como realizarlo (HOW to) os transmito paso a paso como realizarlo. Aunque cabe reseñar antes de empezar, que todo se basa en el protocolo DRDB, el cual es básicamente una replicación continua vía TCP/IP mediante nuestra red Ethernet.

Lo primero es descargar e instalar openfiler en las dos máquinas. Hay una imagen para x86 o para x86_64 según las máquinas de que dispongáis. Durante la instalación, haced las particiones idénticas en los dos servidores, y cuando reiniciéis, os tendréis que asegurar que no se montan las particiones que se van a replicar entre los dos servidores. En mi caso, hice el siguiente particionado:

• /dev/hda1 — /boot – 150MB
• /dev/hda2 — / — 10GB
• /dev/hda3 – swap – 1024MB
• /dev/hda5 – 512MB – Será donde guardemos los ficheros de config para el cluster.
• /dev/hda6 – 12,9 GB – Haremos un share SMB
• /dev/hda7 – 12,9 GB – La usaremos como target iSCSI para VMWare

Para que nos quede un poco mas claro, las particiones que replicaremos serán las de datos y la de configuración del cluster. Las de sistema no será necesario replicarlas ya que el sistema está instalado en ambos nodos. Aseguraos también de que los dos nodos resuelven correctamente el nombre del otro y opcionalmente, montad la autentificación por claves de ssh, para no tener que escribir el password cada vez que hagáis un scp.

DRBD

Montar drbd es bastante sencillo. Lo primero que tenéis que hacer es aseguraros de que las particiones estén vacías, ya que es muy probable que durante la instalación hayáis creado un sistema de ficheros sobre ellas. Si fuese así:

dd if=/dev/zero of=/dev/hdaX bs=1M count=1

Con esto borráis las particiones y las dejáis impolutas para que podáis empezar a replicar. Lo siguiente, editamos el fichero /etc/drbd.conf en el nodo 1. Ahí tendremos que especificar un par de opciones generales y los arrays que váis a crear:

Ejemplo del fichero de configuración.

Luego lo copiamos al nodo 2. Una vez tenemos el fichero de configuración podemos crear los arrays (esto hay que hacerlo en ambos nodos):

• drbdadm create-md cluster_metadata
• drbdadm create-md vg0drbd
• drbdadm create-md vg1drbd

Y arrancamos el servicio drbd en los dos nodos. Si miráis el fichero /proc/drbd, veréis que el estado de los discos es inconsistente y que ambos nodos estan como secundarios. Así que en el nodo 1 hacéis:

• drbdsetup /dev/drbd0 primary -o
• drbdsetup /dev/drbd1 primary -o
• drbdsetup /dev/drbd2 primary –o

Con esto hemos puesto al nodo 1 como primario en todas las particiones que gestiona drbd. Ahora si miráis el /proc/drbd, veréis como está replicando los datos. Ahora hay que añadir drbd al inicio del sistema y ya de paso, creamos el sistema de ficheros en la partición que nos guardará los ficheros de configuración del cluster.

• chkconfig –level 2345 drbd on (en ambos nodos)
• mkfs.ext3 /dev/drbd0 (en el nodo 1)

En este punto, con los arrays creados, nos referiremos siempre al los dispositivos drbd para I/O para cualquier operación con discos.
Siguiente, editamos el fichero /etc/lvm/lvm.conf y cambiamos el filtro de esto:

• filter = [ "a/.*/" ]

a esto:

• filter = [ "r|/dev/hda*|" ]

y procedemos a crear el physical volume sobre drbd1 (el otro sera sobre drbd2, ya que el 0 no será gestionado por lvm).

• pvcreate /dev/drbd1

En la siguiente parte, te contare la parte del heartbeat y de como terminar la configuración de drdb.

Hasta la próxima semana.

VMware proporciona una utilidad llamada VMware CPU bootable Utility, la cual puedes descargar desde la propia web de VMware.

Una vez que arranques tu servidor ESX/ESXi desde CDROM con dicha utilidad, podrás comprobar si tu servidor VMware ESX/ESXI soporta las funcionalidades SSE, SSE2, NX/ED, Hyperthreading, Intel VT (Virtual Technology), AMD-V

VMware VMotion no tiene en cuenta la diferencia en la velocidad del reloj de la CPU de tus servidores ESX/ESXi, ni la diferencia en la memoria de la cache L1, L2, ni la diferencia en el numero de cores o sockets.

Asimismo VMware VMotion no tiene en cuenta las diferencias de memoria RAM entre los servidores ESX/ESXI involucrados en la migración en caliente.

La única pega que le veo a esta utilidad es que has de apagar tu servidor ESX/ESXi para comprobar que opciones y funcionalidades tiene soportado tu servidor VMware ESX/ESXi.

Hola que tal?

Parece que nos hemos puesto de acuerdo en hablar del tema “Backup”. Pues vamos a ello.

Veeam Backup usa la técnica de Backup sintético, permitiendo tras efectuar un backup completo, efectuar backup tan sólo de los cambios incrementalmente. La técnica habitual que usan los productos similares es crear un fichero “grande” con el “full backup” para posteriormente ir creando ficheros “delta” con los cambios incrementales una vez vamos ejecutando el job.

Una vez alguien dijo “El problema no es el Backup, es el Restore”. Cuanta razón tenía, recuerdo cuando trabajaba con Mainframes y teníamos que “tirar” de cinta (si, aquellos armarios increíbles con cintas más grandes que los magnetófonos) y oía al técnico de sistemas “no lee, no restaura”. Un sudor frío pasaba por nuestra espalda hasta que al fin el milagro se producía y restauraba.

La premisa es la siguiente. Si vas a restaurar, estadísticamente lo que vas a buscar en primera instancia para cubrir el RTO es la última copia que hemos hecho. Si ésta es completa en lugar de sintética, siempre nos dará más facilidades (rapidez, consistencia, etc.)

Es por ello que Veeam usa la particularidad de copia “reverse” o decremental, por la cual, el primer backup completo nos creará el fichero principal pero cuando ejecute la primera incremental nos encontraremos con que el fichero perteneciente a la primera ejecución tiene sólo las diferencias, mientras que el último que hemos efectuado está “completo”.

Como trabaja Veeam? Curiosamente de una forma muy parecida a como gestiona los snapshots Datacore.

Tras la generación del fichero .vbk en la primera ejecución, cuando se ejecuta la primera copia incremental, Veeam actualiza los cambios que han habido en el sistema en explotación en el fichero .vbk, guardando todos los datos antiguos que han sido actualizados en un fichero .vrb para esta ocasión.

El fichero .vbk tendra como nombre de fichero el que le hemos asignado al hacer el job, mientras que el .vrb, además del nombre llevará concatenado el “timestamp” del dia y la hora en que se inició el job.

De esta forma podremos identificar los ficheros que tenemos en nuestros directorios ya que tendremos un fichero copia.vbk y tantos .vrb como rollbacks hayamos parametrizado, que se denominarán copiayyyy-mm-ddThhmmss.vrb.

Mecanismo parecido pasa con las réplicas, pero con diferencias, ya que una réplica en el fondo es una vm preparada para ponerse en marcha asap, entonces el fichero .vbk es substituido por el .vmdk de la VM, trabajando los vrb de igual forma que el Backup. Podéis obtener un resumen y más información en www.veammeup.com, blog que mantienen los chicos de ingeniería de Veeam de San Petersburgo, desde aquí un saludo.

Especial cuidado si estáis corto de espacio en el espacio smb que contiene estos ficheros y los movéis. A partir de la versión 4.0, Veeam Backup cuando editas el job, y en la ejecución del mismo hace ciertas verificaciones de la existencia de los ficheros destino. Hablaremos otro día de este tema y de como cumplir con las normas de seguridad y auditoría haciendo servir discos intercambiables y jobs alternados de copia.

Como anécdota, en orden interno VBK ha quedado como una acepción de “Hacer un Veeam Backup”, de esta forma, en slang podemos oír “el cliente VBKs tres servidores”

La próxima semana hablaremos de como efectuar un fine tuning de nuestro sistema detectando cuellos de botella y dimensionamientos no adecuados.