Before you set up workloads for protection and recovery, ensure that you configure your network with the access and communications settings described in this section.
Section 2.4.1, Open Port Requirements for the PlateSpin Server HostForge VM Web Interface
Section 2.4.2, Access and Communication Requirements for Workloads
Section 2.4.3, Access and Communication Requirements for Containers
Section 2.4.5, Protection Across Public and Private Networks Through NAT
Section 2.4.6, Overriding the Default bash Shell for Executing Commands on Linux Workloads
Section 2.4.7, Requirements for VMware DRS Clusters as Containers
Table 2-2 describes the ports that must be open for on the PlateSpin Server host to allow access to the PlateSpin Protect Web Interface.
Table 2-2 Open Port Requirements for the PlateSpin Server HostForge VM
Port (Default) |
Remarks |
---|---|
TCP 80 |
For HTTP communication |
TCP 443 |
For HTTPS communication (if SSL is enabled) |
Table 2-3 describes the software, network, and firewall requirements for workloads that you intend to protect by using PlateSpin Protect.
Table 2-3 Access and Communication Requirements for Workloads
Workload Type |
Prerequisites |
Required Ports (Defaults) |
---|---|---|
All workloads |
Ping (ICMP echo request and response) support |
|
All Windows workloads. See Supported Windows Workloads. |
For discovery, source workloads must be running Microsoft .NET Framework 2 SP2 or later. |
|
All Windows workloads. See Supported Windows Workloads. |
|
TCP 3725 NetBIOS (TCP 137 - 139) SMB (TCP 139, 445 and UDP 137, 138) RPC (TCP 135, 445) |
Windows Server 2003 (including SP1 Standard, SP2 Enterprise, and R2 SP2 Enterprise). |
NOTE:After enabling the required ports, run the following command at the server prompt to enable PlateSpin remote administration: netsh firewall set service RemoteAdmin enable For more information about netsh, see the Microsoft TechNet article, The Netsh Command Line Utility. |
TCP 3725, 135, 139, 445 UDP 137, 138, 139 |
All Linux workloads. See Supported Linux Workloads. |
Secure Shell (SSH) server |
TCP 22, 3725 |
Table 2-4 describes the software, network, and firewall requirements for the supported workload containers.
Table 2-4 Access and Communication Requirements for Containers
System |
Prerequisites |
Required Ports (Defaults) |
---|---|---|
All containers |
Ping (ICMP echo request and response) capability. |
|
All VMware containers. See Supported VM Containers. |
|
HTTPS (TCP 443) |
vCenter Server |
The user with access must be assigned the appropriate roles and permissions. Refer to the pertinent release of VMware documentation for more information. |
HTTPS (TCP 443) |
PlateSpin Protect provides the ability to use Windows Authentication for access to the Microsoft SQL Server database. You must configure Active Directory settings and open up ports in the firewall to allow authentication.
To enable Windows Authentication to the SQL database:
Ensure that you configure Microsoft SQL Server to allow both TCP/IP and Named Pipe connections.
(Conditional) If you plan to use Windows Authentication to access the Microsoft SQL Server database, you must configure the following in Active Directory:
You must add the Microsoft SQL Server database server to the domain.
You need two domain user accounts for the PlateSpin Protect installation.
A Domain user with the sysadmin role set: This user with SQL Admin rights is required to create databases, tables, and other schema objects.
PlateSpin Service user: The service user can be a low-privileged domain user in the domain. However, the service user must be a local administrator on the PlateSpin Protect Server and should be granted that permission prior to the installation.
If the Windows user’s password changes, you must update the password for the PlateSpin Service user and for the IIS App Pool. Consider using a Windows user whose password never expires to avoid the situation.
NOTE:If you use Windows Authentication, you must log in as the domain user with SQL Admin rights when you upgrade or update your PlateSpin Server.
Open the following ports on the firewall to support authentication to the SQL Server:
Ports 49152-65535/TCP: Allow traffic for RPC for LSA, SAM, Netlogon.
Port 1433/TCP: Allow traffic for Microsoft SQL Server.
Custom ports: If you configure SQL Server to use a custom TCP port, you must open that port on the firewall.
NOTE:If you do not use dynamic ports, you must specify the dedicated port in the Database Server field.
(Conditional) If you want to use dedicated ports with PlateSpin Protect, you must open the ports on the firewall:
On the database server, determine which ports need to be opened:
In the SQL Server Configuration Manager, select Protocols for SQLExpress > TCP/IP, then right-click and select Properties.
In the dialog, select the IP Addresses tab.
Under IPAll (or under the desired protocol), if TCP Port or TCP Dynamic Ports is set to any value other than 0, open the specified ports on the firewall. These are the ports you use to connect to the SQL Server.
For example, if the TCP Dynamic Ports field is set to 60664, and the TCP Port field is set to 1555, then you must enable Port 60664 and 1555 in the firewall rules on the SQL server.
Open the ports on the firewall.
NOTE:If you have a value set for dynamic ports, you may not see your server in the list of SQL servers when you click Browse. In this case, you must specify the server manually in the Database Server input field of the PlateSpin Protect installation.
For example, if your server name is MYSQLSERVER, the database instance name SQLEXPRESS, and the dedicated port set for the dynamic port is 60664, you type the following text, and then select the desired authentication type:
MYSQLSERVER\SQLEXPRESS,60664
You must open the ports on the firewall.
In some cases, a source, a target, or PlateSpin Protect itself, might be located in an internal (private) network behind a network address translator (NAT) device, unable to communicate with its counterpart during protection.
PlateSpin Protect enables you to address this issue, depending on which of the following hosts is located behind the NAT device:
PlateSpin Server: In your server’s PlateSpin Server Configuration tool, record the additional IP addresses assigned to that host. See Configuring the Application to Function through NAT.
Target Container: When you are attempting to discover a container (such as VMware ESX), specify the public (or external) IP address of that host in the discovery parameters.
Workload: When you are attempting to add a workload, specify the public (external) IP address of that workload in the discovery parameters.
Failed-over VM: During failback, you can specify an alternative IP address for the failed-over workload in Failback Details (Workload to VM).
Failback Target: During an attempt to register a failback target, when prompted to provide the IP address of the PlateSpin Server, provide either the local address of the PlateSpin Server host or one of its public (external) addresses recorded in the server’s PlateSpin Server Configuration tool (see PlateSpin Server above).
To enable the PlateSpin Server to function across NAT-enabled environments, you must record additional IP addresses of your PlateSpin Server in the PlateSpin Server Configuration tool’s database that the server reads upon startup.
For information on the update procedure, see Configuring PlateSpin Server Behavior through XML Configuration Parameters.
By default, the PlateSpin Server uses the /bin/bash shell when executing commands on a Linux source workload.
If required, you can override the default shell by modifying the corresponding registry key on the PlateSpin Server.
To be a valid protection target, your VMware DRS cluster must be added to the set of containers (inventoried) as a VMware Cluster. You should not attempt to add a DRS Cluster as a set of individual ESX servers. See Adding Containers (Protection Targets).
In addition, your VMware DRS cluster must meet the following configuration requirements:
DRS is enabled and set to either Partially Automated or Fully Automated.
At least one datastore is shared among all the ESX servers in the VMware Cluster.
At least one vSwitch and virtual port-group, or vNetwork Distributed Switch, is common to all the ESX servers in the VMware Cluster.
The failover workloads (VMs) for each protection contract is placed exclusively on datastores, vSwitches and virtual port-groups that are shared among all the ESX servers in the VMware Cluster.