Frequently Asked Questions 

Does RackWare support physical servers?

Yes, RackWare supports physical servers as both an Origin and a Target, and the servers do not need to be from the same vendor nor identically setup as long as there are enough resources to run the workload on the Target.  This includes physical to physical (P -> P) as well as physical to virtual (P -> V).  This feature is particularly useful when replicating to a datacenter or a cloud that supports physical servers. 

 Interestingly the RMM also supports virtual to physical (V -> P).  This latter case may be counterintuitive, but is useful in the DR use case when falling back to a datacenter from a cloud environment.  It would be common for a physical server, perhaps running a database in an Origin datacenter to failover to a virtual server running in the cloud.  For a DR test, or a real DR event, being able to seamlessly fallback to a physical server from the cloud is required for a complete DR solution. 

Does RackWare support replication across disparate hypervisors? 

Yes, RackWare supports replication across disparate hypervisors.  For the supported hypervisors, any confluence is supported.  For example, one can replicate from VMware to Xen, or KVM to VMware, or any other combination.  The reason is that the RMM does not access the hypervisor in any nor have any hypervisor awareness.  The VMDK is not touched in any way.  The replication mechanism is Operating System based.

The RMM also supports physical to virtual for any hypervisor.

What applications does RackWare support?

RackWare's replication and sync technology transparently supports virtually all applications.  The RMM does not attempt to recreate the Image on the Target, but rather copies the Image bits at the file level (not sectors) and then configures the Image to the new hardware in the Target environment.  This preserves applications, configurations, application data, users, and the exact version of the OS.

Some applications such as extremely large and high IO databases may require some additional setup and configuration.  The RackWare discover process identifies such servers for consideration.  Consult RackWare for details.

Does RackWare support SAP HANA?

Yes, RackWare supports SAP HANA for both migration and DR and Backup.  The reason some products have an issue with SAP HANA is the in-memory nature of some aspects of storage.  Replication and sync methods that track storage writes at the sector level ignores the important data consistency that happens when in-memory storage or databases are used.  In contrast, the RackWare process is not a sector (or VMDK) replication/sync process and avoids this problem.  Rather, the RMM takes Logical Volume snapshots via LVM/VSS which instructs applications to flush outstanding IOs to disk.  Once that is done the OS places a bookmark in the FileSystem so IOs continue on to of that bookmark, hence the replication/sync is non-disruptive.  Importantly, the RMM replicates and delta syncs from the static snapshot where the IOs have been flushed properly to disk, so when the target server boots that data is consistent.  No special workflow, settings, or application interfaces are necessary as the RMMs standard process handles SAP HANA.

Does RackWare modify applications in the Target environment?

By design, as part of the default process, the RMM does not modify any application settings.  Only OS and infrastructure configuration changes are made to enable the Image to run on the new hardware in the new environment.  Many applications work immediately after a replication.  Some applications require modification of some settings that may be sensitive to network IP addresses or other infrastructure that may be different in the Target environment. 

For larger projects, these can easily be automated via pre and post API calls as part of replication and sync.

Does RackWare support clusters?

Yes, RackWare supports clusters.  For simple clusters, the servers are replicated as is to a Target environment and only requires adjustment of IP addresses.  Adjustment of the IP addresses can be automated as needed.  But often clusters can be complex and thus require additional attention.

Some conditions that may require additional attention:

  • In cases where drives change ownership frequently, a mechanism may need to be put in place to hold the drive in place during replication and sync operations.

  • It's common to replicate/sync from a multi-node cluster to a single node cluster for economic reasons.  When doing so a post API script can be used to adjust the configuration on the Target side after sync operations.

Does RackWare support network storage? 

Yes, RackWare supports network storage. For iSCSI and Fibre Channel replication and sync are seamless and transparent. The RMM also has the ability to replicate and sync remote mounts for iSCSI and Fibre Channel to local volumes.

NFS and CIFS may have a more complex decision tree. If NFS/CIFS are implemented via a standard Linux or Windows server the RMM standard mechanism can be used on those servers with full integrity. In this case the RMM connects to the NFS/CIFS server itself as it would any other server. From this context the RMM is replicating the block storage mounted on that server. Replicating the NFS/CIFS data from the client side is not supported.

If the NFS/CIFS storage is implemented on a hardware appliance there are other considerations such as whether or not multiple writers are configured. Consult RackWare for more information.

Does RackWare have an agent? 

By default RackWare does not deploy an agent.  In about 1 to 3 percent of servers that are extremely large with high IO rates, deployment of an agent can be used for aggressive RPO settings and continuous sync.

Does RackWare require root or administrative permissions? 

RackWare does not require access to any hypervisor or storage array, the Image replication is performed via the Operating System.  This requires that the RMM have access to the disk, and thus commensurate permissions. 

For Linux, the RMM uses passwordless SSH and can be configured with a non-root user with a sudo configuration. 

Passwordless SSH is also used for Windows.  RackWare has a small MSI that can be used to configure SSH on the Windows servers.  Administrator privileges are required. 

What is required on the Target and Source side for replication and sync?

RackWare performs replication and sync via the Operating System which translates into a few requirements.  First, the RMM uses the highly secure SSH communications protocol between itself and the client servers.  This requires IP level network connectivity and the use of TCP port 22. 

Additionally, the RMM utilizes a small number of standard OS packages and utilities.  For example, on Windows VSS Shadow Copy is required.  In the majority of cases, on production servers, all the necessary packages are already available.  The RMM can automatically install these packages if desired.

Origin servers also require sufficient storage as working area to perform the replication and sync operations.  The RMM by default does not access a live filesystem, but takes a snapshot of the Image and performs all operations on the snapshot.  It is recommended that each partition has about 15% of free space for this function.  High IO rate servers may require more.

Consult the RMM Prerequisites and Operational Requirements document for details.

Does RackWare support encryption? If yes, please describe.

Yes, the RMM supports encryption, and by default all data flows are encrypted. 

Normally the RMM Server is deployed in the Target environment and connects to the Origin environment over a WAN connection.  That WAN connection can be over a private network or a public interface.  In this topology, all information exchanged with the Origin server is fully protected by highly secure protocols.   This can run over the public Internet, any private network, or any VPN or tunnel. The only requirement is that the RMM can connect to the Origin server at the IP level. 

SSH is used for all data transfer for both Windows and Linux.  All data exchanges with the Target server are likewise protected via SSH.

The RMM configures SSH to use ciphers in the following preferred order:

  • aes128-ctr

  • aes192-ctr

  • aes256-ctr

  • arcfour256

  • arcfour128

  • aes128-cbc

  • 3des-cbc

  • blowfish-cbc

  • cast128-cbc

  • aes192-cbc

  • aes256-cbc

  • arcfour

The preferred order as well as the available ciphers can be customized.  Contact RackWare for more information.

How are Domains handled?  GPOs?  What type of user needs to be set up?

Replication and sync semantics preserve all Domain settings, including GPOs on the Target side.  Applications, when booted, will attempt to login via the same Domain users as on the Origin.  So, the Target environment requires a Domain Controller with the same or similar settings as the Origin. 

It's important to remember that while the Image bits are preserved from Origin to Target, the Target boots on different hardware.  When initially booting the server in the Target, a best practice is to reset the Domain account for that server.  RackWare does not recommend changing the SID.

Does the RMM support Data Guard?

The RMM does not directly configure or monitor Data Guard.  However, the RMM is very effective at facilitating DataGuard setup.  The RMM can replicate the origin server to the target environment minus the ASM disks.  There are specific features in the RMM that allows this to happen.  The Target server boots with the exact same OS and Oracle configuration.  This can save days of work setting up the target server prior to the DG setup.  Once the server is replicated the ASM disks can be added DG can commence.  The RMM does not integrate DG alerts or status in its dashboard or policy alerts.  However, often DG failover is initiated from a pre/post script that is executed as part of the policy, but this is a customer preference.

>