NetIQ Documentation: Guía del usuario de PlateSpin Protect 11.0.1 - Requisitos de acceso y comunicación en la red de protección

2.3.1 Requisitos de acceso y comunicación para las cargas de trabajo

Los requisitos de software, redes y cortafuegos siguientes se aplican a las cargas de trabajo que pretende proteger mediante PlateSpin Protect.

Tabla 2-2 Requisitos de acceso y comunicación para las cargas de trabajo

Tipo de carga de trabajo	Requisitos previos	Puertos necesarios (por defecto)
Todas las cargas de trabajo	Compatible con ping (petición y respuesta de eco ICMP)
Todas las cargas de trabajo Windows	Microsoft .NET Framework versión 2.0 o 3.5 SP1
Windows 7; Windows Server 2008; Windows Vista	Credenciales de cuenta de administrador o de administrador del dominio incorporadas (no es suficiente solo ser miembro del grupo de administradores). En Vista, la cuenta debe estar habilitada (está inhabilitada por defecto). El Firewall de Windows debe estar configurado para permitir la opción Compartir archivos e impresoras. Use una de estas opciones: Opción 1, uso del Firewall de Windows: use el elemento básico del Panel de control Firewall de Windows (firewall.cpl) y seleccione Compartir archivos e impresoras en la lista de excepciones. - O bien - Opción 2, uso del Firewall con seguridad avanzada: use la utilidad Firewall de Windows con seguridad avanzada (wf.msc) con la opción Reglas de entrada habilitada y definida como Permitir: Compartir archivos e impresoras (solicitud eco: ICMPv4In) Compartir archivos e impresoras (solicitud eco: ICMPv6In) Compartir archivos e impresoras (datagrama NB de entrada) Compartir archivos e impresoras (nombre NB de entrada) Compartir archivos e impresoras (sesión NB de entrada) Compartir archivos e impresoras (SMB de entrada) Compartir archivos e impresoras (administrador de trabajos de impresión: RPC) Compartir archivos e impresoras (administrador de trabajos de impresión: RPC-EPMAP)	TCP 3725 NetBIOS 137 - 139 SMB (TCP 139, 445 y UDP 137, 138) TCP 135/445
Windows Server 2003 (incluidos SP1 Standard, SP2 Enterprise y R2 SP2 Enterprise)	NOTA:después de habilitar los puertos necesarios, ejecute el comando siguiente en el indicador del servidor para habilitar la administración remota de PlateSpin: netsh firewall set service RemoteAdmin enable Para obtener más información sobre netsh, consulte el artículo de Microsoft TechNet: http://technet.microsoft.com/en-us/library/cc785383%28v=ws.10%29.aspx.	TCP: 3725, 135, 139, 445 UDP: 137, 138, 139
Windows Server 2000; Windows XP	Instrumental de administración de Windows (WMI) instalado WMI (RPC/DCOM) puede usar los puertos TCP 135 y 445, así como puertos aleatorios o asignados de forma dinámica por encima del 1024. Si se producen problemas al añadir la carga de trabajo, puede colocar de forma temporal la carga de trabajo en una zona desmilitarizada o abrir temporalmente los puertos bloqueados por el cortafuegos mientras se añade la carga de trabajo en PlateSpin Protect. Para obtener información adicional, como instrucciones para limitar el rango de puertos para DCOM y RPC, consulte los siguientes artículos técnicos de Microsoft. Uso de DCOM con servidores de seguridad Cómo configurar la asignación dinámica de puertos RPC para trabajar con servidores de seguridad Cómo configurar DCOM para que funcione en un Firewall basado en NAT	TCP 3725 NetBIOS 137 - 139 SMB (TCP 139, 445 y UDP 137, 138) RPC (TCP 135)
Todas las cargas de trabajo Linux	Servidor de shell segura (SSH)	TCP 22, 3725

2.3.2 Requisitos de acceso y comunicación para los contenedores

Los requisitos de software, redes y cortafuegos siguientes se aplican a los contenedores de carga de trabajo admitidos.

Tabla 2-3 Requisitos de acceso y comunicación para los contenedores

Sistema	Requisitos previos	Puertos necesarios (por defecto)
Todos los contenedores	Compatible con ping (petición y respuesta de eco ICMP)
VMware ESX/ESXi 4.1 VMware ESXi 5.0	Cuenta de VMware con función de administrador API de servicios Web de VMware y API de gestión de archivos	HTTPS (TCP 443)
vCenter Server	El usuario con acceso debe tener asignados los permisos y las funciones correspondientes. Consulte la documentación de la versión específica de VMware para obtener más información.	HTTPS (TCP 443)

Sistema

Requisitos previos

Puertos necesarios (por defecto)

Todos los contenedores

Compatible con ping (petición y respuesta de eco ICMP)

VMware ESX/ESXi 4.1

VMware ESXi 5.0

Cuenta de VMware con función de administrador
API de servicios Web de VMware y API de gestión de archivos

HTTPS (TCP 443)

vCenter Server

El usuario con acceso debe tener asignados los permisos y las funciones correspondientes. Consulte la documentación de la versión específica de VMware para obtener más información.

HTTPS (TCP 443)

2.3.3 Requisitos de apertura de puertos para los hosts de servidores de PlateSpin

Los requisitos de apertura de puertos siguientes se aplican a los hosts de servidores de PlateSpin.

Tabla 2-4 Requisitos de apertura de puertos para los hosts de servidores de PlateSpin

Puerto (por defecto)	Observaciones
TCP 80	Para comunicaciones HTTP
TCP 443	Para comunicaciones HTTPS (si SSL está habilitado)

2.3.4 Protección en redes públicas y privadas mediante NAT

En ciertos casos, un origen, un destino o el propio PlateSpin Protect pueden estar situados en una red (privada) interna protegida por un dispositivo de traducción de direcciones de red (NAT) que no puede comunicarse con su equivalente durante la protección.

PlateSpin Protect permite resolver este problema, según cuál de los hosts siguientes esté ubicado tras el dispositivo NAT:

Servidor de PlateSpin: en la herramienta PlateSpin Server Configuration, registre las direcciones IP adicionales asignadas al host. Consulte Configuración de la aplicación para que funcione con NAT.
Contenedor de destino: cuando intente descubrir un contenedor (por ejemplo, VMware ESX), especifique la dirección IP pública (o externa) del host en los parámetros de descubrimiento.
Carga de trabajo: si intenta añadir una carga de trabajo, especifique la dirección IP pública (externa) de la carga de trabajo en los parámetros de descubrimiento.
Máquina virtual en failover: durante el failback, puede especificar una dirección IP alternativa para la carga de trabajo en failover en Detalles de failback (carga de trabajo en máquina virtual).
Destino de failback: durante un intento para registrar un destino de failback, cuando se le pida que proporcione la dirección IP del servidor de PlateSpin, proporcione la dirección local del host del servidor de protección o una de sus direcciones públicas (externas) registradas en la herramienta PlateSpin Server Configuration del servidor (consulte Servidor de PlateSpin más arriba).

Configuración de la aplicación para que funcione con NAT

Para habilitar el servidor de PlateSpin a fin de que funcione en entornos con NAT habilitada, debe registrar direcciones IP adicionales del servidor de PlateSpin en la base de datos de la herramienta PlateSpin Server Configuration que el servidor lee durante el inicio.

Para obtener información sobre el procedimiento de actualización, consulte Configuración del comportamiento del servidor de PlateSpin mediante parámetros de configuración XML.

2.3.5 Anulación de la shell bash por defecto para ejecutar comandos en cargas de trabajo Linux

El servidor de PlateSpin usa por defecto la shell /bin/bash para ejecutar comandos en una carga de trabajo de origen Linux.

Si se requiere, puede anular la shell por defecto modificando la clave de registro correspondiente en el servidor de PlateSpin.

Consulte el artículo 7010676 de la KB.

2.3.6 Requisitos de clústeres DRS VMware como contenedores

Para ser un destino de protección válido, el clúster DRS VMware debe añadirse al conjunto de contenedores (inventariarse) como clúster VMware. No debe intentar añadir un clúster DRS como conjunto de servidores ESX individuales. Consulte Adición de contenedores (destinos de protección).

Además, el clúster DRS VMware debe cumplir los siguientes requisitos de configuración:

DRS debe estar habilitado y establecido como Partially Automated (Parcialmente automatizado) o Fully Automated (Totalmente automatizado).
Debe existir al menos un almacén de datos compartido entre todos los servidores ESX del clúster VMware.
Debe existir al menos un vSwitch y un grupo virtual de puertos, o bien un conmutador distribuido de vNetwork, compartido entre todos los servidores ESX del clúster VMware.
Las cargas de trabajo de failover (máquinas virtuales) de cada contrato de protección se sitúan exclusivamente en los almacenes de datos, vSwitch y grupos virtuales de puertos compartidos entre todos los servidores ESX del clúster VMware.