Scribd
Upload
47 views4 pages

RackWare FAQ 2023

Uploaded by

MWANAHAWA BAKARI
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
47 views4 pages

RackWare FAQ 2023

Uploaded by

MWANAHAWA BAKARI
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

RackWare Frequently Asked Questions (FAQ)

Question: 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.

Question: 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.

Question: 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.

Question: 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

1|Page RackWare Proprietary and Confidential


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.

Question: 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.

Question: 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.

Question: 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.

2|Page RackWare Proprietary and Confidential


Question: 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.

Question: 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.

3|Page RackWare Proprietary and Confidential


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.

4|Page RackWare Proprietary and Confidential

You might also like