Author Archive

En esta Nota, enumeramos los puertos que se necesitan disponibles para la infraestructura de VMWare View y la virtualización de Estaciones de Trabajo.

Para permitir la conexión de clientes Externos a un Security Server que se encuentra dentro de una DMZ, el Firewall Front-End debe permitir el tráfico entrante de los siguientes puertos TCP:

También, como es de imaginarse, se necesitan habilitar los puertos para la comunicación entre los Servidores View Connection que están en la red interna.

Los puertos necesarios para habilitar el tráfico de entrada son:

En caso de utilizar las políticas de USB Redirection y MMR, habilitar tambien los siguientes puertos para RDP:

USB Redirection: TCP:32111

MMR: TCP:9427

Cortito y conciso! Justo lo que buscás, los puertos para habilitar y que tu infraestructura de Desktops virtualizadas funcione.

Saludos!

Bueno, esta idea de explicar qué es un Virtual Appliance (VA a partir de ahora), surgió luego de la nota emitida por Nicolás Solop: Qué es una Máquina Virtual?.

Un VA es muy similar y sencillo de entender:

Se trata de una Máquina Virtual (VM a partir de ahora) que se encuentra alojada en algún sitio de internet, con un formato comprimido llamado OVF (Open Virtualization Format).

En general se trata de VMs creadas con un Sistema Operativo (SO), una ó varias Aplicaciones, y configuradas para cumplir determinado fin, por ejemplo:

- NAS Servers virtuales.

- Routers y Firewalls.

- Monitoreo de Infraestructura tecnológica.

Dónde están?

Estos VA son muy fáciles de encontrar y de elegir, ya que están muy bien organizados en el Virtual Appliance Marketplace de VMWare.

En el VA Marketplace se puede ver las VA ordenadas por categorías, vendor, etc.

Cómo se ponen en Producción?

Bueno, según cada Fabricante…

Los pasos comunes para obtenerla son:

	Encontrar la VA deseada y revisar release note para comprobar la compatibilidad con nuestra infraestructura y Hardware si es necesario.
	Descargar el archivo ZIP ó RAR (según vendor), el cual contiene los archivos OVF y VMDK.
	Una vez descargado, descomprimirlo, conectarse con vSphere Client al Virtual Center. Click en File, y luego en “Deploy OVF Template”.  Buscar el ZIP descargado, ó colocar URL donde se encuentre el VA.
	En el caso de Browse, buscar el archivo OVF, y clikc en Deploy. Los archivos que se verán son VMDK y OVF. OVF sólo 1, y VMDK según la cantidad de discos que tenga el VA. Luego seguir los pasos de Importación tal como pide.

Luego de finalizado el Deploy del VA, ya tendremos una VM en funcionamiento.

Al encenderla, en general, deberíamos seguir los pasos de Configuración final tales como Networking, Sincronización de fecha y hora, etc.

Recuerden que cada VA puede variar en cuanto a la forma de descarga, y la forma de Configuración final.  Leer atentamente Release note e Installation Guide.

Saludos!

Hoy les muestro una configuración muy importante, que a la vez puede pasar desapercibida, trayendo confusiones, mal entendidos, y hasta algún dolor de cabeza.  La doy a conocer para que ese potencial dolor de cabeza, pase a ser un alivio y una posibilidad más de controlar las conexiones a través de VMWare View.

VMWare View, más puntualmente la Consola de Administración, tiene una configuración de Time Out, que por defecto, viene configurada en 600 minutos (10 horas).  Esta característica sirve para dar un límite de tiempo de conexión a un equipo.

Puede utilizarse para liberar conexiones disponibles, para limitar el tiempo de uso de los recursos de la compañia, y cualquier otro tipo de fin.

Esa configuración puede ser modificada sin necesidad de reiniciar ningún tipo de servicio.

Dónde está esa configuración?

1- Ingresar a la consola del View Manager, y click en el Botón CONFIGURATION:

2- Luego Click en Global Settings, prestar atención a la línea de “Session TimeOut”

3- Click en el link “Edit” y modificar el valor en minutos.

Una vez que estos cambios fueron aplicados, las terminales deberán reconectarse para que tomen la política. 

Espero les sirva!

Saludos…

Patricio

Sabemos que ESXi es la versión Gratuita de vSphere que permite a empresas de pequeña infraestructura incursionar en la Virtualización, también muy útil para Laboratorios, Pruebas de Performance, etc.

En este caso, voy a tratar un tema simple pero importante:

¿Qué puedo hacer con ESXi gratis y qué me habilita comprar Licencias?.

Haciendo un poco de historia en este blog, hace casi un año Nicolás Solop anunció el lanzamiento de un Kit de Management para ESXi en forma centralizada.  Con respecto a esta nota, menciono un detalle, ESXi sin Licencia tiene 2 limitaciones Claves:

1- El Host ESXi no puede ser manejado por un vCenter Server.  Los comandos API tienen acceso de sólo lectura al Host

2- No se puede modificar la configuración del Hypervisor automáticamente por medio de scripts.

De este modo, sabemos que al Licenciar ESXi, se activa la posibilidad de operar el Host con:

- vCenter Server

- vCLI

- vMA

- PERL Took Kit

- Powershell Tool Kit

(Próximamente postearé info técnica sobre vCLI y vMA)

Bueno, otra duda que brota a partir de acá, es qué features habilita cada Licencia.  Este cuadro les será de mucha utilidad:

Como se ve en el cuadro, ESXi stand alone es bastante limitado con respecto al resto.

Las herramientas de VMWare que marcan la diferencia se van sumando a medida que la licencia contratada es más alta (más que obvio), de todos modos, se ve claro que con la licencia más básica (Essentials), ya hay una notable diferencia, y su valor en $ no es elevado.  VC Agent, permite conectar el Host a un vCenter Server y poder administrar en forma centralizada los ESXi, además de Update Manager (update automático por medio de vCenter), VMSafe (Seguridad máxima para sus vms sin requerir recursos de la misma) y vStorage APIs para Protección de Datos.

Para conocer más acerca de licencias de vmware, visite:

Licencias Parte 1

Licencias Parte 2

Para mayor información acerca de Licenciamiento y Herramientas de VMWare, contáctenos!.

Saludos!!

Patricio Limeres

Es probable que al intentar virtualizar un Windows 2000 con VMWARE Converter, aparezca la petición de un archvio llamado SCSIPORT.SYS, donde Converter nos pide la ruta para encontrar ese archivo.
Bueno, esto no es difícil de resolver:
Windows 2000 Server requiere para poder ser virtualizado el SP4 Rollup 1.
Por lo general, quienes tienen Windows 2000 Server en Producción con su SP4, suponen que ya están totalmente cubiertos.  Pero existe el Rollup 1, que salió posteriormente al SP4, quien tiene actualizados algunos drivers, por ejemplo el mencionado SCSIPORT.SYS.

Una vez instalado el Rollup 1, el servidor físico necesita ser reiniciado para poder convertirlo.
Les dejo acá el link de Ms para bajar el Rollup 1.
http://www.microsoft.com/downloads/details.aspx?FamilyId=B54730CF-8850-4531-B52B-BF28B324C662&displaylang=en

Éxitos con la Virtualización!
Saludos…
Patricio Limeres

Con unos pasos muy cortos y sencillos, se puede dejar
automatizado el encendido y apagado de las Máquinas virtuales de un Servidor
ESX/ESXi.

Esto acelerará el trámite de apagado de equipos ESX de
Laboratorio en el momento en que no estén en uso, ó el apagado y encendido de
Equipos ESX en producción en caso de Mantenimiento, ó por políticas de
Green-IT.

Esto se refiere, a que cuando se Apaga un Equipo ESX, se
puede ordenar el apagado automático de las Virtual Machines que éste
contenga. De la misma forma, se puede
ordenar y automatizar el encendido de las VMs cuando se vuela a encender el
Equipo ESX.

Los pasos a seguir son los Siguientes:

- Conectarse al ESX utilizando VIClient (ó al Virtual Center si lo tienen Implementado)

- Seleccionar el servidor ESX que deseen configurar.

- Ir a la Solapa “Configuración”

- En la sección de Software sobre la izquierda de la pantalla, seleccionar “Virtual Machine Startup-Shutdown” Luego click en “Properties” a la derecha y arriba.

- Seleccionar la VM elegida, El Orden de Encendido/Apagado se modifica con los botones “Move Up” y “Move Down” sobre la derecha del cuadro que lista las VMs.

- Click en el Botón Edit.

- Configurar los tiempos de Retraso y el tipo de acción en Shutdown Settings.

- Una vez configurado, click en Ok en ambas ventanas y revisar si la configuración es la deseada.

Espero les sea de utilidad!

Saludos…

Patricio Limeres

Entendiendo la arquitectura de Unicenter DSM, sabemos que un Scalability Server es el nexo entre el DSM Manager y los Agentes.

Las Mejores prácticas dictan que un Scalability Server reduce el tráfico entre el Manager y Agentes.  Esto aplica perfecto cuando entre Agentes y Manager hay un enlace WAN.

Ahora bien, hasta cuánto de pequeño puede ser el enlace entre Manager y Scalability?

NOTA: Estos tips están destinados a Consultores que ya conocen la herramienta, su funcionamiento y Arquitectura.

He tenido experiencias en enlaces de hasta 64 kbps.  El deploy del Scalability funcionó bien utilizando “Deploy Infrastructure” en el Explorer del Manager, y el Stage de paquetes lo tuve que hacer manualmente.  Aquí los pasos a seguir:

1- Desde el Explorer del Manager, modificar las siguientes políticas Default:

. DSM/Manager/Infrastructure Deployment/Job Failure Timeout Inteval.   Esta política tiene un valor de 120 minutos por default.  Se expande para que el job de deploy de un Scalability finalice correctamente.  De lo contrario, el job fallará debido al pobre enlace.

. DSM/Manager/Infrastructure Deployment/Message Delivery Timeout interval. Setearlo en 10 minutos es suficiente.

. DSM/Manager/Infrastructure Deployment/Primer timeout Interval.  30 Minutos es suficiente.

NOTA: los valores mencionados no garantizan el funcionamiento, se debe modificar de acuerdo a cada situación particular.

2- Ejecutar el job de Deploy de Scalability Server.  Esta tarea, en mi caso, con 64kbps demoró 7 horas y media.  Puede variar considerablemente.  Aquí se ve reflejado el cambio de las políticas, sin modificarlas nunca hubiese funcionado ya que  a las 2 horas daría Time Out.

3- Realizar un Job de “Stage” en el mismo Manager, esto creará una nueva carpeta: Program Files\CA\DSM\DMPrimer

4- Copiar la nueva carpeta DMPrimer con todo su contenido a la misma ubicación pero en el Scalability Server.  Esto puede ser vía Copy/Paste, ó enviando algún medio (CD, Pendrive, etc.).

5- Una vez copiado, realizar pruebas: Crear una tarea desde el Manager, para instalar un Agente en la Subred de Destino, utilizando el Scalability Server recién instalado, y verán resultados positivos y con buena performance.

Espero les haya sido de utilidad!

Saludos…

Patricio Limeres

Trabajando sobre soluciones ya implementadas, me encuentro con problemas serios de base, causados al momento de la Instalación y muy difíciles ó Imposibles de Reparar.

A continuación detallo algunos Tips a tener en cuenta para evitar estos problemas a futuro:

MDB – Dominio de AD para los Managers – CCS

- MDB: Dónde se instalará la Base de datos?

Hay que tener en cuenta tanto el Acceso a la base como el tamaño a futuro de la misma.

1 – Dónde residirá la base de Datos? Qué tan buena ó grande es la conexión de red entre el Domain Manager y la MDB? No es lo mismo un tráfico de 500 estaciones de trabajo a un tráfico de 2000 estaciones de trabajo.  La lecutra y escritura en la MDB irá creciendo a medida que se agreguen Estaciones de trabajo ó Servidores, y un enlace pequeño causa pérdida de paquetes durante la escritura originando daños severos a la base.

2 – Habrá espacio suficiente para la MDB de acá a X años?  Según el nivel de crecimiento estimado por la empresa, se debe seleccionar un Storage, ó un Disco Local con suficiente tamaño para soportar ese crecimiento, aunque en el momento de tomar la decisión suene exagerado, es preferible estar tranquilos y no colapsar la base de datos en un futuro.  Si la MDB queda con poco espacio, la performance de TODAS las tareas decrecerá y mucho!.  También corre riesgo de corromperse la base de datos.

3 – Es estable la base de datos? Siempre y cuando utilice SQL u Oracle, SI!, pero no hay que dejar de lado las tareas de mantenimiento propias de cada motor.  Puede pasar que dichas tareas sean creadas al momento de instalar el motor de DB, pero nunca más fueron chequeadas, ya que no es una Base de Datos de interés “Comercial” para la empresa.

- Dominio: Dónde se instalarán los Managers?

Sabemos que para que un Enterprise Manager ó un Domain Manager puedan trabajar sobre TODO un Bosque de Active Directory, debe estar instalado en el Dominio Más Alto en jerarquía.

NUNCA mover un manager (Enterprise ó Domain) de un dominio Child a su superior, ni entre Dominios paralelos.  Esto genera el cambio del FQDN del servidor y por consigueinte, entradas duplicadas en la MDB.  Ej: servidordsm1.child.domain  es el nombre original al instalarlo, si se mueve hacia su superior, quedaría como servidordsm1.domain.  Esto genera entradas erróneas en el comstor y en la MDB, genera errores en el Reporter y horrible performance navegando en el Explorer y en el deploy de paquetes entre Manager y Scalability Servers.  La única solución a este problema es la Reinstalación del producto con una MDB vacía.  No se podrá recuperar la base de datos anterior ya que el contenido es inconsistente y erróneo.

- CCS: Esta herramienta que aparece en la versión 11.1, por lo general es ignorada por los que implementan esta versión pero su experiencia es sobre versiones anteriores.

CCS integra el DTS (Data Transport Service) y el Continuous Discovery.  Dos herramientas fundamentales para obtener la mejor performance posible.

He visto instalaciones de versión 11.2 SIN CCS instalado, por lo tanto no se puede hacer uso de las herramientas mencionadas.

Aclaro que esta herramienta no requiere conocimientos extraordinarios ni ningún tipo de licencia extra.  No hay motivo para evadir la instalación de CCS.

Espero les sea de utilidad y que haya sido amigable la explicación.

Saludos…

Patricio Limeres

La base de Datos de Brightstor ARCServe Backup (VLDB) reside en el directorio \CA\Brightstor ARCServe Backup\DATABASE

Allí se encuentran una serie de archivos con diversos tamaños (algunos 0kb y otros varios megas ó gigas) según la cantidad de datos respaldada, cantidad de Tapes, cantidad de Restores, etc.

Esta base VLDB tiene ciertas desventajas con respecto a la instalación de BAB sobre una base de MS SQL.

Entre las desventajas, está la limitación de tamaño, VLDB sólo soporta hasta 36 gb como máximo.

Otra desventaja, es que requiere un mantenimiento periódico con más frecuencia que SQL.

Para correr el mantenimiento, existen los siguientes comandos:

dbcheck: Chequea la base de datos

dbfix: Intenta reparar corrupciones en la base

dbdefrag: Defragmentación de la base de datos luego de ejecutado el job Prune Database.

keybuild: Regeneración de índices.

Contenido de la Base de Datos:

Antes de entrar en Detalle, les muestro una tabla que bajé y traduje de un doc de CA, donde nos presentan a los archivos de la VLDB:

COMANDOS:

Abajo vemos los comandos seguidos por los parámetros convencionales para trabajar con la base entera:

El órden correcto es como está citado abajo:

- Esto revisará TODA la VLDB.

dbcheck -a -L casdb;admin;secret asjob

dbcheck -a -L casdb;admin;secret asmedia

dbcheck -a -L casdb;admin;secret asobject

dbcheck -a -L casdb;admin;secret asrhost

dbcheck -a -L casdb;admin;secret astape

dbcheck -a -L casdb;admin;secret astpdrv

dbcheck -a -L casdb;admin;secret astpsdat

dbcheck -a -L casdb;admin;secret asmmo

- Esto intentará reparar los errores en las bases (si existen).

dbfix -a -L casdb;admin;secret asjob

dbfix -a -L casdb;admin;secret asmedia

dbfix -a -L casdb;admin;secret asobject

dbfix -a -L casdb;admin;secret asrhost

dbfix -a -L casdb;admin;secret astape

dbfix -a -L casdb;admin;secret astpdrv

dbfix -a -L casdb;admin;secret astpsdat

dbfix -a -L casdb;admin;secret asmmo

- Esto removerá objetos eliminados en la VLDB con la tarea Prune liberando el espacio en disco.

dbdefrag -a -L casdb;admin;secret asjob

dbdefrag -a -L casdb;admin;secret asmedia

dbdefrag -a -L casdb;admin;secret asobject

dbdefrag -a -L casdb;admin;secret asrhost

dbdefrag -a -L casdb;admin;secret astape

dbdefrag -a -L casdb;admin;secret astpdrv

dbdefrag -a -L casdb;admin;secret astpsdat

dbdefrag -a -L casdb;admin;secret asmmo

- Esto intentará reparar errores de Alto nivel (índices). Sólo se ejecuta en conjunto con DBDEFRAG.

keybuild -k -L casdb;admin;secret asjob

keybuild -k -L casdb;admin;secret asmedia

keybuild -k -L casdb;admin;secret asobject

keybuild -k -L casdb;admin;secret asrhost

keybuild -k -L casdb;admin;secret astape

keybuild -k -L casdb;admin;secret astpdrv

keybuild -k -L casdb;admin;secret astpsdat

keybuild -k -L casdb;admin;secret asmmo

NOTA:

casdb;admin;secret debe escribirse tal cual, no se refiere a ningún tipo de usuario ni de Windows ni de Brightstor.