Protecting Multi-tier Applications

Our crack Services team has written a new technical solution brief about the pitfalls of doing DR for multi-tier applications. Seeing as how most apps these days are multi-tier, and those apps are usually the most critical to a business, figuring out how to backup or failover is paramount. We’ll serialize the tech brief for a few days here.

Protecting Multi-tier Applications

Overview 

Many businesses rely on multi-tier applications in order to deliver highly available and scalable services to their enterprise. Multi-tier applications are network services that are delivered using multiple servers each running specific roles within the tiered application. Typical multi-tier applications consist of at least a database layer and an application layer. Depending upon the service, multi-tier applications can consist of many more layers and services. Enterprise class applications often have the option of running many roles on one server and subsequently scaling up to multiple tiers in order to grow with increasing use and demand within an organization.

Given the scalable nature of a typical multi-tier application, these same services tend to be critical to business continuity. Due to the inherent complexity of multi-tier applications, developing a disaster recovery strategy for these applications can seem overwhelming. Using the nScaled approach, we can deliver a solution that can be routinely tested, validated, and easy to use, making protecting these critical applications achievable.

Typical Multi-Tier Architectures 

Even with the wide array of applications that can be delivered using a multi-tier design, the overall architecture of all multi-tier applications tend to have many – if not all – of the same components in common. Applications such as document management, online learning, customer relationship management, accounting, human resource management, asset tracking, and many others use architecture similar to the one shown.

Multi-tier applications tend to take considerable time and expense to set up. The investment of time required to completely and effectively deploy this architecture is well worth the reward, however, given the inherent scalability and reliability associated with reducing single points of failure and distributing the computing workload across more than one server.

Basic Server Protection 

With the nScaled approach, servers are protected using block level mirroring technology. Each write operation on a protected server is mirrored to the nScaled Local Cloud Appliance on the customer’s network. Once the initial snapshot has been taken, subsequent changes (deltas) are captured in a consistent state called a “quiescent snapshot”. A quiescent snapshot is an exact representation of a server at a specific point in time where both the file system and underlying blocks are in a consistent state. This quiescent state allows a server to be booted from the snapshot as a virtual machine. This approach is independent of any underlying SAN technology and works with both physical and virtual machines. Once the snapshots are captured on the Local Cloud Appliance, the data is replicated to the customer’s environment in the nScaled Remote Cloud data center. Since the server snapshot is in a quiescent state, the server can then be booted in the nScaled Local Cloud Appliance or in the nScaled Remote Cloud whenever it is needed.

We’ll finish up next time.