How everrun Works. An overview of the everrun Architecture

Transcription

1 An overview of the everrun Architecture everrun Architecture Overview The everrun family of availability solutions from Marathon Technologies represents a breakthrough virtualization technology that delivers increased overall availability, fault tolerance, and complete disaster protection for Windows applications in a simple, affordable, software-based solution. The everrun FT and everrun HA software solutions protect any Windows application from costly downtime and data loss, providing mirrored data and uninterrupted network access through hardware faults and network failures for continuous computing. These benefits are realized without requiring application modification or custom scripts. Simply load your application into the everrun virtual Windows environment and it is immediately protected. This virtual environment is derived using our own patented technologies and is designed to provide the highest levels of availability. everrun uses virtualization for availability, unlike server virtualization solutions which use virtualization for consolidation. At the highest level, everrun creates a single virtual Windows environment on top of two standard servers. This single Windows environment is all that needs to be managed by the administrator. There is only one IP address, one hostname, and one MAC address, so users, clients, and applications need only connect to one system and never have to make changes to this, even when failures occur. With only one Windows environment to manage, applications are installed and licensed only once and system and application changes are made only once. everrun creates a completely protected environment using an architecture that appears as a single Windows system. It s basically the same as if you were to install Windows on a single standalone server, however everrun ensures redundancy of the hardware, data, and networks, and provides automated fault management.

2 everrun can support and protect any Windows application with no requirements for cluster-aware, custom coding, or scripting of any kind. This is enabled by masking the hardware layer from the virtual Windows environment and the application. To the Windows environment and everything running within it, the hardware layer appears as a single system. everrun handles all the mirroring, fault management, error handling, and policy management without any awareness by the OS or applications as to the redundancy, and without any configuration. This is how everrun delivers comprehensive protection with such simplicity and flexibility. Figure 1 - everrun Logical View Building everrun Environments To create an everrun environment, we start with the following: 1) Two physical servers, either Intel- or AMD-based - 2 -

3 For everrun FT, the 2 servers must be identical with respect to CPU and memory. For everrun HA, the 2 servers need not be identical, but must be from the processor architecture (Intel or AMD) Each server must have at least 1 physical storage device locally attached Each server must have at least 3 Ethernet ports 2) Three Windows licenses if using Standard edition. With Windows Server 2003 Enterprise Edition R2, only two licenses are required. 3) One everrun license 4) One application license Starting from bare metal, the everrun environment is built by first installing Windows on each of the 2 physical servers. Each Windows installation on the physical servers requires a Windows license. We refer to these servers as CoServer 1 and CoServer 2. Similar to server virtualization technologies, the CoServer runs the host OS, which in our case is Windows. The everrun software is then installed. This process will partition the physical CoServers to create a guest operating environment, resulting in two Windows OS running on each physical server. Although each CoServer has its own guest environment, everrun synchronizes them into a single operating environment, treating them as one, thusly requiring only one additional Windows installation and license. From this point forward, anything done to one guest OS is done to the other; automatically and without any duplication of effort on the part of the administrator. They appear as a single system. Within the Virtual Server, a third copy of Windows is installed. This installation is performed once and because of our mirrored disks (see Building Redundancy below), the installation actually occurs on the guest OS on each CoServer. The virtual system disk, C:, is a mirrored disk, comprised of a disk from each CoServer. The installation to C:\Windows is actually being done to two separate drives, transparently. Once completed, there is a single Windows operating environment that is protected from faults and failures. Simply install any application and it will become inherently protected as well without any modifications. Since there is only a single Windows operating environment, the application is only installed - 3 -

4 and licensed once, and all configuration and maintenance to the application are performed only once. Both everrun HA and everrun FT employ the same core architecture. The slight differences between them are in their operation, which we will review next. everrun FT everrun FT provides complete fault tolerance to critical applications that require zero downtime. These are applications that need continuous availability, as even brief interruptions in processing are costly and damaging to the business. everrun FT keeps applications running even in the event of a complete server failure. In the everrun FT environment, when the CoServers are booted, the guest OS on each are started and synchronized together to create a single Windows environment. Everything within these two guest OS are synchronized, including CPU, memory, and storage. This synchronized, virtual environment is exposed as the single Windows environment. everrun ensures that these systems remain completely synchronized at all times. Each instruction that is executed on one CoServer is executed at the same exact time on the other CoServer, always remaining completely synchronized. We refer to this as instructional lockstepping. This is all completely transparent to the virtual Windows environment and the applications that are running in it. Figure 2 - everrun FT Virtualization Architecture The lockstep synchronization is what enables the fault tolerance capabilities, even in the event that one of the CoServers is rendered completely inoperable

5 From the application standpoint, it processes a single transaction, but everrun executes that transaction on both CoServers simultaneously. Not until each CoServer acknowledges completion of the transaction is the application given acknowledgement. This guarantees that each transaction is executed and committed on each CoServer. Should one CoServer fail at any time, even midtransaction, everrun immediately identifies that failure but continues processing the transaction on the remaining CoServer. There is absolutely no interruption to the application, the in-flight transactions, the data, or the end-users. everrun HA everrun HA is designed for those applications that require a rapid and automated recovery from failed servers. The business can afford a brief interruption to the application without costly ramifications. Figure 3 - everrun HA Virtualization Architecture Whereas in an everrun FT environment where the guest OS is running on both systems simultaneously in complete lockstep, in an everrun HA environment only one guest OS is running at a time. CPU and memory operations are not synchronized and a complete system failure results in an immediate restart of the guest OS and application on the other CoServer. The guest OS on each CoServer is an exact mirror of the other, so when a restart occurs, all changes and updates that were made to the virtual OS and the applications are applied to both systems. When a CoServer fails and the virtual environment restarts on the other CoServer, it is basically the same as rebooting the system, with the benefit of restarting on a different server. Unlike clusters and failover solutions, the only time there is a restart is when the entire server fails. Device failures such as - 5 -

6 disks and networks do not cause a restart and as a result do not affect the application state. Should a disk or network connection fail on either CoServer, everrun will immediately and transparently redirect I/O to the other CoServer without any interruption to the application (see ComputeThru Technology below). Building Redundancy To protect against device and hardware failures and to remove any single-pointsof-failure, everrun creates redundancy for each device that is made available to the virtual environment. For example, drive C: in the virtual environment appears and is managed as just a single disk/partition, however everrun has paired two separate physical disks (one from each CoServer) together to provide redundancy. Applications need only write the data once as everrun ensures that it is written to both disks simultaneously. The same is done with network interfaces. We refer to this as redirection, as we redirect two like physical devices to create a single device in the virtual environment. If one should fail, we immediately and automatically use the other without interruption to the application. As stated earlier, the hardware is transparent to the application, so the application isn t even aware a failure has occurred. Storage Redundancy everrun maintains a completely synchronous copy of the data to guarantee data integrity trough faults and failures. Since the hardware layer is completely transparent to the application environment, data redundancy is masked from the application. To achieve this, when everrun creates the virtual environment, it builds redundant devices through its redirection process. In the case of disks, everrun will redirect a disk from each CoServer to create a single disk in the virtual environment. For example, logical Disk1 from CoServer 1 and logical Disk1 from CoServer 2 may be paired and redirected to the virtual environment to create Disk0. Disk0 looks like any other disk you would see in any Figure 4 - Building Storage and Data Redundancy - 6 -

7 other Windows system; it can be formatted and partitioned as needed. When a write occurs to this disk, everrun performs that write to the two logical disks on the CoServers without any awareness by the application or even by the virtual Windows environment. To maintain performance levels, these writes are performed simultaneously, not serially. Network Redundancy To provide redundancy for the network, everrun performs redirection similar to how disk redundancy is accomplished. A network adaptor is selected from each CoServer to create a single network interface in the virtual environment. This virtual adaptor can then be treated and configured as any other physical adaptor. It presents a single IP address, a single MAC address, and single hostname to the network. Figure 5 - Building Network Redundancy To accomplish this, everrun replaces the physical MAC address from each physical adaptor with a single MAC address and controls the I/O to transmit out of only one at any given time

8 ComputeThru Technology Protecting the application when something breaks Complete System Failure everrun FT In the case of a complete system failure (loss of power, system crash, hardware failure, etc.) within an everrun FT configuration, the failed CoServer will simply be removed from the environment while the application continues to run completely uninterrupted on the other CoServer. everrun identifies the failure and takes immediate action automatically. Because all transactions were being processed on both systems at the same time, there is no loss of state, no restarts, no re-computes, and no retransmits. The failure is completely transparent to the application environment allowing continuous computing without interruption. Figure 6 shows a failed server scenario. Figure 6 - everrun FT ComputeThru Server Failure everrun HA In an everrun HA environment, when the active CoServer fails, the virtual OS and applications will automatically restart on the Ready CoServer with no user or administrator intervention required. The restart is essentially the same as rebooting a server, however in this case the Windows environment is rebooting on a different server. Remember that they entire virtual environment is mirrored between the CoServers, including the OS and applications. Everything that is done to the virtual Windows environment will be completely in tact when it restarts on the other CoServer. See figure

9 Figure 7 - everrun HA Failed Server Restart Storage Failure In the event of a failure within the storage subsystem, the everrun software recognizes the failure and takes immediate action to reflect the state change and redirect I/O away from the failed disk. For example, if the disk on CoServer 2 fails, CoServer 2 will continue to process transactions using that disks paired counterpart on CoServer 1. This happens without interruption to the application or to the transactions being processed. This process is the same within both everrun FT and everrun HA. Figure 8 - Redirecting Disk I/O After a Failure - 9 -

10 Network Failure In the case of a failure to one of the physical network connections, such as a disconnected or severed cable, or a failed card, everrun automatically recognizes the failure and immediately redirects network I/O to its paired adaptor in the other CoServer. This process is completely transparent to the Windows environment and the application, having no impact or visibility to the clients and users; no lost transactions or connections, and no retransmits. Figure 9 - Redirecting Network I/O After a Failure

11 Achieving Disaster Tolerance Both everrun FT and HA offer the capability to provide Disaster Tolerance by separating the two CoServers between different locations. The separation can be via a direct connection from one building in a campus to another or via a dedicated connection spanning many miles. With the increased risk of the potential for split-brain (both servers running independently with the same application and same IP address) with the separation of the CoServers, everrun utilizes its SplitSite capabilities to prevent this. SplitSite monitors the health of the CoServers and network connections and will take appropriate action to ensure only one instance of the application is available on the network at any given time. everrun SplitSite implements a Quorum service that can run on any server within the network and will force the shutdown of one of the CoServers in the event that network communications become impaired. Once connections are restored, SplitSite will restart the stopped CoServer to regain complete redundancy. Revision 1.1 WORLDWIDE HEADQUARTERS Marathon Technologies Corporation 295 Foster Street, Littleton, MA Tel / Fax info@marathontechnologies.com web: EMEA HEADQUARTERS Marathon Technologies UK Ltd Regus House, Trinity Court Wokingham Road, Bracknell Berkshire, RG42 1PL Tel +44 (0) Fax +44 (0) The Marathon logo, SplitSite and Marathon everrun are trademarks or registered trademarks of Marathon Technologies Corporation. Microsoft and Windows are registered trademarks of Microsoft Corporation. All other trademarks and registered trademarks are the property of their respective owners. Copyright 2006 Marathon Technologies Corporation. All rights reserved. Marathon Technologies Corporation reserves the right to make improvements to this document at any time and without further notice. Marathon Technologies Corporation assumes no responsibility for any errors that may appear in this document