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 amigos, como veis continuamos con la monitorización de sistemas. Al igual que lo hice con Hyperic esta vez voy a mostraros como instalar el agente de Zabbix en Xenserver 5.5. Otro día lo haremos con Nagios que es el que nos falta.

1.- Descargamos de la web de Citrix el “SDK Virtual Machine” y lo importamos en nuestro XenServer. Esto nos servirá para poder compilar el agente de Zabbix para nuestra versión de XenServer.

http://www.citrix.com/lang/English/lp/lp_1688621.asp

2.- Una vez tenemos la máquina virtual creada, nos traemos el paquete que contiene el agente zabbix y lo descomprimimos.

3.- Compilamos:

./configure –enable-agent –enable-static

make install

4.- Localizaremos los ficheros del agente de zabbix en la siguiente ruta:

/usr/local/sbin/zabbix_agent

/usr/local/sbin/zabbix_agentd

5.- Copiamos el directorio tal cual sobre nuestro XenServer 5.5. Yo suelo hacerlo con scp por medio de comandos pero hay clientes como WinSCP que también son muy cómodos.

6.- Creamos el usuario zabbix en XenServer

useradd zabbix

7.- Le damos permisos de este usuario sobre los directorios antes creados

chmod 755 zabbix_agent*

chown zabbix zabbix_agent*

8.- Creamos el directorio donde estarán los ficheros de configuración:

mkdir /etc/zabbix

9.- Le damos permisos al usuario zabbix sobre el directorio

chown zabbix /etc/zabbix

10.- LLevamos el fichero zabbix_agentd.conf al directorio anterior creado y le damos permisos para el mismo usuario

chown zabbix /etc/zabbix/zabbix_agentd.conf

11.- Creamos el directorio para logs

mkdir /var/log/zabbix

12.- Le damos permios para el usuario zabbix

chown zabbix /var/log/zabbix

13.- Copiamos el script de inicio en /etc/init.d y lo añadiremos a los niveles de ejecución

chkconfig –level 2345 zabbix-agend on

14.- Modificamos la linea donde aparece:

ZABBIX_AGENTD_BIN=/usr/sbin/zabbix-agentd

por

ZABBIX_AGENTD_BIN=/usr/local/sbin/zabbix-agentd

15.- Editamos la configuración del IPTables, añadiendo la siguiente linea

-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 10050 -j ACCEPT

16.- Reiniciamos IPTables

service iptables restart

17.- Arrancamos el agente y comprobamos su funcionamiento

/etc/init.d/zabbix_agentd start

/tail -f /var/log/zabbix/zabbix_agentd.log

Con esto tendremos el agente funcionando en nuestro XenServer. Espero que os sea de utilidad.

Saludos y 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.

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?

Os acordáis de Andrew Kutz y su plug-in SVMotion para VI 3.5?. Ese plug-in nos facilitó mucho el trabajo.

Os acordáis de Xtravirt? Muchos instalamos nuestros primeros ESX de prueba en entornos Workstation con su “How to”.

No es que esté sentimental ni añoro otros tiempos, si unimos los dos temas nos encontramos frente al nuevo plug-in que ha desarrollado Xtravirt para vCenter.

Cuantas veces nos hemos quejado de que la consola de la VM en el vCenter va lenta?

Os presento vSpher Client RDP Plug-in. A partir de ahora cuando queramos conectarnos a una VM desde vCenter lo podremos hacer directamente desde el vCenter, botón derecho, “Connect via RDP”.

Podéis obtener el plug-in aquí. Una vez efectuado el download, lo instalaremos con un sencillo setup “mi wife”… y podremos verlo mediante Plug-ins, Manage Plug-ins.

Cerramos vCenter y lo volvemos a arrancar (esa informática….) y a partir de ese momento, click sobre la VM, botón derecho, ahí tenemos al final la opción “Connect via RDP”

Más aún, queréis definir passwords y resolución?. Vamos a Home de nuestro vCenter. Bajo “Solutions and Applications” vemos un icono “Xtravirt RDP Plugin”

Ahí podremos configurar nuestros valores por defecto.

Espero que os ayude en vuestro trabajo diario.

Hasta la semana que viene.

¡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.

La licencia Enterprise Plus de vSphere incluye un nuevo tipo de switch, el Distributed Switch que aporta mejoras en calidad de servicio, seguridad, escalabilidad y explotación respecto al clásico Standard Switch de siempre.

Sin embargo esta licencia permite, también, utilizar (comprándolo adicionalmente) el primer switch virtual de Cisco, el Cisco Nexus 1000V, pero ¿Que ventajas aporta este switch respecto al Distributed Switch para que merezca la pena pagar un dinero extra?.

Como todo en la vida, para algunos será necesario y para otros no, pero hablemos brevemente de algunas de las características que lo diferencian del vDS :

En VI3 v3.5 se incorporaba NetFlow en modo experimental (y funcionaba muy bien), pero en vSphere ha desaparecido, si queremos registrar los flujos de información que pasan por nuestros switches virtuales, fundamental para análisis de comportamiento de las aplicaciones y para detectar flujos sospechosos, hemos de utilizar Cisco Nexus1000V.

Si necesitas enviar los logs de los switches virtuales para correlacionarlos con los del resto de los switches físicos, Cisco Nexus 1000V te lo proporciona.

Cisco Nexus 1000V soporta ACLs utilizando direcciones MAC o IP y se aplican a nivel de puerto, dicho de forma rápida tenemos un firewall en cada puerto y se mueve con la VM al cambiar de ESX, es una buena ayuda en lo que a seguridad se refiere.

Otras medidas de seguridad son DHCP snooping y IP Source Guard que mitigan ataques man-in-the-middle o Dynamic ARP Inspection que nos protege de ataques ARP spoofing.

Además puede trabajar en combinación con VMware vShield Zones, blindando nuestra infraestructura y facilitando la administración de la seguridad con herramientas gráficas.

Nos aporta diversos mecanismos de QoS : Mecanismos de clasificación de tráfico por diversos criterios, técnicas de marcado de tráfico y políticas de QoS. Todo ello utilizando los comandos Cisco IOS y llegando a garantizar un ancho de banda a un tráficos determinado !!!!

Y los entusiastas de Cisco están de suerte, se configura mediante Cisco CLI y con los comandos que ya conoce y muchos mas.

Como vemos la seguridad, las redes y los sistemas, ya no son especialidades diferentes, están naciendo los especialistas en DataCenter … ¿te apuntas?

Hola, que tal, como estáis?

Aquí estamos como cada semana hablando sobre temas del ecosistema de la virtualización, específicamente en entorno VMware.

Hoy vamos a ver una pequeña herramienta que nos puede facilitar mucho el trabajo. En un entorno donde hay proliferación de VMs y tenemos definidos “Resource Pools” si deseamos que éstos estén bien configurados y al día deberemos ir revisándolos de forma periódica calculando las reservas de los recursos.

Eric Sloof ha desarrollado un script llamado DRPC (Dynamic Resource Pool Calculator) que nos permite hacer esta tarea administrativa de forma fácil.

Podemos obtener el script aquí, deberemos instalar en la maquina que vamos a usar VMware vSphere PowerCLI y los que no nos gusta trabajar con powershell, nos instalamos PowerGUI y todos contentos, que con la que cae, no es poco.

Cargamos el script en el PowerGUI y tenemos una pantalla como esta

Ejecutamos con F5 o bien con el “Play”. La siguiente ventana nos preguntará por nombre o ip de nuestro vCenter o ESX

Browse, incluimos la ip y le decimos “OK”

Nos pedirá credenciales para acceder al vCenter o al ESX, logico…

Y aquí nos enseña los Resource Pool que tenemos establecidos en nuestro entorno….

Si efectuamos click sobre el Resource Pool que queremos revisar, tras funcionar la barra de trabajo nos indicará los valores que tenemos establecidos en estos momentos para reservas de memoria y cpu para este elemento (Old) y los valores que nos plantea que modifiquemos. En este caso, dado que he movido máquinas la diferencia es importante

No hay más secreto, si hacemos click, nos actualizará directamente el Resource Pool sin que tengamos que tocar para nada el vCenter. Si no deseamos actualizar, pues pulsamos Exit y listos.

Espero que os sea de provecho.

Hasta la semana que viene.

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.

Hola que tal? Como estáis?

Estáis buscando como mantener una Base de Datos de vuestra infraestructura con atributos definidos por vosotros mismos? . Atributos como que antivirus tenemos instalado o a que hora tenemos establecido el backup? vScout puede ser la solución.

Además de inventariar vuestra infraestructura dinámicamente y “on line” (importante) vScout permite que definas tus propios atributos.

Para ello nos vamos al menú “Configuration” y “Custom Attributes”

Botón Add y nos aparece la ventana para configurar el atributo y su descripción

Y aquí podemos ver los atributos definidos, a que hora tenemos programado el backup de esta VM, si tenemos instalado un Antivirus, cual, cual es el propósito de la VM y en que Resource Pool lo vamos a tener ubicado.

Una vez definido, tan sólo tendremos que ir a la vm y hacer click sobre “Apply Custom Attributes”

Y podemos introducir nuestra información o editarla.

Para hacer listados nada más facil, usamos los establecidos o hacemos una exportación a Excel y desde ahí imprimimos.

Como veis, un programa “free” al que se le puede sacar mucho partido.

Hasta la semana que viene.

Update1: Si tienes problemas en bajarte el documento haz clic en este enlace.

Hola amigos. Tal y como podemos ver en este artículo, Citrix ha publicado un test para escalar a 5000 sesiones concurrentes VDI y lo más notable que encuentro de todo esto es que para el test utilizan VMWare ESX como plataforma de virtualización.

A continuación os paso a listar la plataforma utilizada:

1.- Desktop delivering controler para la administración de los escritorios remotos.
2.- Citrix provisioning services para el aprovisionamiento.
3.- Netapp como sistema de almacenamiento.
4.- Blades de HP para el alojamiento de las máquinas virtuales.
5.- VMWare ESX como sistema de virtualización.
6.- Switches cisco para la red.

Os recomiendo su lectura, de la que, además de una plataforma de XenDesktop 4 sobre VMWare ESX, cabe destacar la sinceridad en los problemas encontrados.

Saludos y hasta la próxima semana.

Muchos son los emails y llamadas que he recibido durante años sobre si Oracle está soportado en VMware. Pues bien, puesto clara y llanamente, si Oracle está soportado o no, dependerá del departamento en Oracle con el que hables. Me explico:

El equipo de preventa en Oracle es posible que te diga que Oracle no está ni certificado ni soportado en VMware pero si miras el articulo creado por el equipo de soporte en Oracle (metalink número 249212.1) dice lo contrario, o al menos, viene a decir que esta soportado aunque no certificado.

Oracle soporta sus productos en VMware. Esta política ha estado presente por más de dos años y no ha cambiado. Mientras que Oracle no está certificado en VMware, el articulo en el meta link claramente especifica las condiciones bajo las que Oracle ofrecerá soporte a clientes con VMware.

Si la capa de virtualización de VMware es el responsable del problema, entonces el departamento de soporte de VMware asistirá al cliente a solventar dicho problema.

Asimismo, Oracle VM es la única solución&plataforma de virtualización certificada y soportada para los productos de Oracle – Good for them.

Tip: La experiencia con el departamento de soporte de Oracle y con mis clientes corriendo Oracle bajo VMware es, ciertamente, muy positiva. Nunca he tenido ningún problema con Oracle cuando hemos necesitado (en muy contadas ocasiones) su soporte.

Y ciertamente, dependerá del departamento con el que hables: soporte, sales o marketing, – Oracle estará o no soportado sobre VMware. Triste pero cierto.

Ahora cuando te digan que no está soportado, primero, pregúntales para que departamento trabajan y, segundo, podrás enseñarle el metalink número 249212.1

Es un placer para el Blog de la Virtualización en Español dar la bienvenida a VizionCore nuestro último sponsor y empresa con reconozidas soluciones innovadoras para la plataforma VMware desde el año 2005.

Vizioncore es una empresa líder de la virtualización y cuenta con más de 18.000 clientes (desde PYMES a grandes empresas). VizionCore fue fundada en 2002, y es un proveedor líder de soluciones de administración de virtualización de servidores.

Vizioncore es el único proveedor de la actualidad que comercializa un completo conjunto de soluciones para gestionar, controlar y proteger de forma completa los entornos virtuales durante todo su ciclo de vida.

Las soluciones de Vizioncore permiten a los usuarios analizar, convertir, proteger, supervisar, optimizar y automatizar la infraestructura virtual para obtener el máximo rendimiento y tiempo de funcionamiento de sus sistemas. Hoy por hoy, miles de clientes de todo el mundo (desde PYMES a organizaciones empresariales) utilizan las soluciones de Vizioncore porque son fiables, efectivas, fáciles de usar y asequibles.

Vizioncore es una empresa subsidiaria independiente de Quest Software, proveedor líder en la administración de sistemas empresariales. Actualmente, Vizioncore distribuye sus productos a través de una red de asociados extendida de 2.200 revendedores de valor agregado en todo el mundo.

Para obtener más información, visita www.vizioncore.com o www.vizioncorum.com, el sitio oficial del blog de Vizioncore Inc., o pónte en contacto a través de la dirección sales @ vizioncore.com.

Vamos a ver la instalación y configuración de Datacore SANmelody. Los requerimientos mínimos son servidor con Windows 2008 (x86 o x64) con una CPU de 2 cores (1 lo usa Windows y el otro Datacore) y memoria RAM (entendiendo que el ratio es de 20% de la memoria la usa Windows mientras que el 80% restante la usa Datacore como Caché). Microsofot .NET Framework 3.5. Lista total de requerimientos, aquí.

Vamos a usar para este laboratorio un viejo conocido, dos HP ML110 con 1 Xeon 2 nucleos y 8 Gb de RAM, uno como ESX y el otro comoDatacore. La topología a implementar es ésta. Simplificamos la red de storage con un simple cable cruzado para iSCSI entre los servidores.

Instalamos Windows 2008 en el servidor que tenemos preparado a tal efecto y le aplicamos todos los updates disponibles. A continuación le asignamos 2 ip fijas, una para administración y la otra para el Target de iSCSI. Como recomendación, deshabilitamos las actualizaciones (así evitamos reinicios no esperados). Se desaconseja que el servidor sea parte de nuestro Directorio Activo, así como se aconseja que se instale windows 2008  en su versión inglesa para un mejor soporte a la hora de compartir los posibles mensajes. Como es un “labo” y tan sólo tengo un 2008 español, “pues eso….”

En este caso tenemos 2 discos de 250 no usados, los inicializamos con GPT y los dejaremos Básicos y sin formatear.

Instalamos el software de SANmelody por defecto, incluyendo la licencia evaluación, trial o adquirida que tenemos cuando nos los indique, poco más que “siguiente, siguiente”. Reiniciamos.

Antes de nada, vamos a hablar de los términos en que “habla” Datacore. Un nodo Datacore como es éste SANmelody que estamos instalando es denominado Storage Server, mientras que nuestros ESX o Windows o máquinas que accedan a los recursos serán denominados Application Server y los recursos mostrados por el Storage Server son Virtual Volumes.

Otra característica de Datacore es que mientras otros sistemas presentan el target y el initiator los decubre y asigna, aquí, después de que el Initiator haya inicializado el canal, Datacore asigna un Virtual Volume a un Application Server mediante un Channel. Para mí es un método seguro para que no te levanten las LUN por error en una instalación, por ejemplo.

Continuamos, en la barra de estado vemos un icono de Datacore, botón derecho y seleccionamos Open computer Management, con elloaccedemos a la cónsola donde vemos un Snap-in de Datacore. Lo abrimos y accedemos sobre el Storage Server

Nos indica que el Storage Server está parado y que debemos ponerlo en marcha.

Aceptamos el mensaje y vamos a la barra de tareas y buscamos el botón de arrancar el servicio, lo arrancamos y podemos ver abajo una característica que debemos tener en cuenta. Cuando iniciemos el servicio nos dirá “Running – Not applied”. Casi todos los cambios que hagamos van a quedar “sin aplicar” hasta que no hagamos un “Apply configuration”

Con esto tenemos nuestro Storage Server preparado para crear recursos a compartir, o Virtual Volumes.

Accedemos en la misma cónsola al snap-in de administración de discos, seleccionando los discos que hemos dejado sin usar antes e inicializados. Botón derecho sobre el disco que deseamos convertir en Virtual Volume, Nuevo volumen simple, el tamaño que deseamos (todo el disco en este caso) y muy importante! “No asignar una letra o ruta de acceso de unidad” y “No formatear este volumen”. De esta forma nos queda un disco con una particion “Raw”, sin letra asignada ni formateado.

El siguiente paso es “Proteger” esta partición. De esta forma es Datacore quien gestiona la partición y prevenimos usos accidentales desde Windows. Para ello vamos al Snap-in Datacore y sobre Storage Server, botón derecho “Protect all volumes”, el sistema nos contestará OK.

Pero el Volume1 nos aparecerá en rojo como indica el grafico. Que ocurre? Volvamos atrás y recordemos que casi todos los cambio precisan de un “Apply” y el sistema nos está diciendo “Tengo el cambio en buffer, pero no lo he aplicado, los aplicaré todos cuando hagas el Apply”.  Lo hacemos.

Con un volumen creado, vamos a hacer un Virtual Volumen que vamos a  llamar VVproduction1. Nos posicionamos sobre Virtual Volumes, botón derecho, New Virtual Volume y nos aparece la siguiente ventana. En Name indicamos VVproduction1, seleccionamos el volumen disponible y con la flecha verde y OK obtenemos un Virtual Volume pendiente de hacer Apply. Aplicamos.

Nos trasladamos ahora a nuestro ESX.  Siempre será mejor si desde nuestro service console hacemos un vmkping a la ip del target de Datacore. Configuration, Storage Adaptors y nos posicionamos sobre nuestro adaptador de iSCSI por software (doy por sentado que hemos configurado el firewall y el initiator). En Properties, Tab Dynamic Discovery, Add, podremos incluir la dirección de la ip del target del STorage Server, 10.10.10.xx. Verificamos en Static Discovery y vemos el iqn de nuestro Datacore. Al salir, hacemos rescan.

Para comprobar que tenemos establecido el enlace, desde Datacore, en iSCSI Manager, sobre el NIC que enlaza con el ESX y podremos ver el iqn de nuestro ESX1. Tenemos el enlaze correcto. Tan sólo nos queda mapear el Virtual Volume con el ESX1 a través del Channel establecido. Nos posicionamos sobre Datacore Snap-in, sobre Application Servers, botón derecho, New Application Server. Damos nombre al Application Server, ESX1 e indicamos que el tipo es VMware ESX.

Sobre el Application Server ESX1, botón derecho, propiedades, Channels, señalamos el Channel del iqn del ESX y con la flecha verde lo pasamos a Assigned channels. Aceptamos y hacemos “Apply”.

Mapeamos el Virtual Volume con el Application Server mediante el channel establecido. Para ello nos posicionamos sobre Application Server, Map New Virtual Volume, obteniendo la siguiente imagen. Seleccionamos el Virtual Volume VVproduction1 con el Channel ESX1_! del Application Server ESX1. Ok y hacemos “Apply” y con eso hemos concluido.

Nos vamos a nuestro ESX, Storage, Add Storage, Disk/LUN, y ahí vemos el identificador de la LUN disponible de Datacore. Creamos la partición, lo formateamos y le damos nombre.

Tras un breve espacio de tiempo tendremos un Datastore disponible para nuestras VM.

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.

Podéis ver una demo interactiva en este link