For distributed enterprise, which is sometimes referred to as remote office/branch office (ROBO), Scale wanted to address the need for very small infrastructure requirements at locations supporting a small number of users. These remote sites, away from the central IT hub, most likely do not have any dedicated IT staff which makes management problematic. Still, these sites often need a number of services from Active Directory, DNS, messaging and communications, file and print services, among others.
You may be thinking that a low-cost traditional server or two would suffice for these sites and that is how these sites have traditionally been architected. However, HC3 offers so much more than traditional server architecture for distributed enterprise. With HC3 running at both the central IT hub and the remote sites, the distributed enterprise infrastructure is not only easier to manage, but more resilient and able to be recovered from disaster much more quickly.
• Right Sizing - HC3 single node appliance can be deployed to support the smallest sites with multiple VMs as needed. Different node configuration and models from the HC1000/2000/4000 series can provide the right amount of resources for each site, or clusters if necessary.
• Rapid Deployment - HC3 can be racked, cabled, powered on, configured in a matter of minutes, and VMs can be deployed and running in under an hour.
• Self Healing Storage - The block access, direct attached storage system in HC3 can automatically recover from individual drive failure to keep VMs running while the drive is replaced.
• Web-Based Management - Administrators can quickly connect their web browsers to remote HC3 systems and manage storage and virtual machines from a single management interface.
• Replication and Failover - VMs can be replicated between two HC3 systems with native, built-in replication. Replication can be local or remote across any distance and can be configured to replicate changes as often as every 5 minutes. Replicated VMs can be failed over between clusters in minutes.
• Remote Support Access - HC3 offers a remote access point exclusive to ScaleCare support to help diagnose support issues and take corrective actions if necessary.
Disaster Recovery (DR) is definitely not a one-size fits all solution. That’s why Scale built it into HC3 to allow you to protect your workloads down to the individual VM level. Depending on your business, you may need to protect only a few critical workloads or you may need to protect most or all of your workloads. Just because you have a multi-node HC3 cluster in production does not necessarily mean you need a duplicate cluster for DR.
The single node appliance configuration provides budget-friendly options for protecting critical workloads with replication and failover. If you can identify a handful of critical workloads that will keep your business operation in the event of disaster, you may be able to use a single node appliance to recover those workloads until you can reinstate your full HC3 production cluster. For some organizations, a single node appliance as a local replication target can provide an effective backup solution.
• No Agents or DR Licensing - HC3 replication is built in for both clusters and single node appliances so there is no extra cost or licensing.
• Right-Sized Recovery - With the single node appliance configuration, you can choose the right amount of capacity you need for recovery even when it is much less than your production capacity.
• Continuous Per-VM Replication - HC3 makes use of its space efficient snapshot technology to replicate to a secondary site, tracking and sending only the changed blocks.
• Low RPO/RTO and Flexible Scheduling - Continuously replicate as often as every 5 minutes and failover within minutes while tailoring replication schedules per VM.
• Simple Disaster Recovery Testing - Testing a DR infrastructure plan is now as simple as cloning a snapshot on the target appliance and starting a VM. No disruption to ongoing replication.
• Easy Failback after Disaster Recovery - After running a VM at the DR site, simply replicate the changed data back to the primary site for simple failback.