March 6, ProductScope. everrun MX. commissioned by

Transcription

1 March 6, 2011 everrun MX commissioned by

2 Microsoft SQL Server continues to take on an increasingly mission-critical role within nearly every Microsoft-centric organization. SQL Server is not often recognized as being as mission-critical as it is; because it typically sits in the back-end and isn t directly seen or touched by end users, it s easy to forget about SQL Server. But it is being used to power SharePoint installations, Customer Relationship Management (CRM) solutions, Enterprise Resource Planning (ERP) applications, Business Intelligence (BI) solutions, and much more. These are the applications that companies usually can t live without, and that means they can t live without SQL Server. SQL Server s supporting role for these core solutions means that companies are looking for more and better ways to increase the availability of their SQL Server computers. Downtime due to both planned maintenance and unexpected failures is simply unacceptable, although many smaller- and medium-sized businesses sometimes believe that such downtime is simply unavoidable. SQL Server natively provides some high-availability capabilities, and offers additional options in combination with the Microsoft Windows Server operating system. Third party software vendors also offer a range of high-availability options. Marathon Technologies everrun MX is one such third-party product that is positioned as a high-availability software-based fault tolerance platform that is well-suited for SQL Server. Contents Native Options: Log Shipping and Database Mirroring 3 SQL Server + Windows: Clustering 4 Third-Party Higher Availability: Fast Recovery 5 Third-Party High-Availability Through Virtualization 6 everrun MX s Approach to High Availability 7 Summary 9 2

3 Native Options: Log Shipping and Database Mirroring SQL Server s native log shipping is an asynchronous replication technology. A replication pair consists of an active server and a hot spare. The active server periodically transmits ( ships ) its transaction log to the spare, which re-runs those transactions, bringing its copy of the database up-to-date. In the event of a failure, at-risk data includes any unwritten pages in SQL Server s memory, as well as any transactions that have not yet been shipped to the spare. Recovering from a failure is a highly-manual process: An administrator must manually remove the failed server, bring the spare online, and so forth. This potentially involves making DNS changes so that clients will see the spare when accessing SQL Server. Negative impact to client applications, in the form of downtime, is inevitable, and some amount of data loss is almost unavoidable. Log shipping is not usually considered suitable for true high availability, since performing the failover process for something like routine maintenance isn t practical. Database mirroring is a somewhat more synchronous form of replication, sending individual transactions more or less in real-time, rather than sending batches in a log file. With a third instance of SQL Server available to act as a witness, failover from mirror to mirror can be automated, minimizing client impact and downtime. Database mirroring can be resource-intensive for large, busy databases, and must be considered when planning server capacity. Database mirroring protects against data loss, but that is not guaranteed. It is still possible for un-replicated transactions to be lost in the event of a failure. Mirroring on SQL Server Standard Edition is single-threaded; for large databases or multiple databases, the full mirroring capability found in Enterprise Edition is necessary. Retail licensing for Enterprise Edition, however, is more than $20,000 additional per processor socket, making it financially impractical for many businesses. 3

4 SQL Server + Windows: Clustering Microsoft s flagship solution for SQL Server high availability is clustering, which requires the Windows Cluster Service of the Windows Server operating system. With Standard Editions of Windows Server and SQL Server, 2-node clusters are available. These clusters typically require somewhat specialized hardware, and require the use of a shared storage component, such as a Storage Area Network (SAN). Cluster configurations are often expensive, although active-active configurations are possible. In such a configuration, each cluster node runs one or more instances of SQL Server. In the event of a failure, the instances running on the failed node are transferred to a surviving node. Capacity planning must consider these scenarios, since each node must essentially have some spare capacity in the event that it needs to take over workload for a failed node. Windows Clustering has often been considered an extremely complex, difficult-to-deploy set of technologies. SQL Server rides atop that clustering capability, adding its own layers of complexity. Managing and maintaining these clusters can be challenging as well. The hardware needed to create these clusters can be expensive, particularly with the class of hardware commonly used for SQL Server computers. Moving to clusters with more than two nodes requires the Enterprise Editions of both Windows Server and SQL Server on each cluster node. At retail pricing, this imposes a combined $23,000 licensing surcharge for each processor socket in each cluster node. Clustering does not provide any protection for the required shared storage systems. Clusters today are usually built with external SANs for storage, and smart businesses typically invest in fairly comprehensive SAN systems that provide their own levels of fault tolerance. It is important to note that if a node s storage system experiences a failure, then everything running on that node is effectively down. No other node can assume that workload, since the shared storage necessary to making that workload function is offline. For example, in a SQL Server scenario, the actual databases are located on that shared storage. If the storage system fails, it doesn t matter how many nodes are available to run the workload, because the databases themselves are unavailable. Microsoft does offer and support geoclusters, or multi-site clusters, where storage is replicated between sites. That replication requires additional software and is not a native part of the Windows Cluster Service. Multi-site clusters require three components: A complete cluster in each site, and a third witness which determines which of the two clusters is active at any given time. Multi-site clustering is more complex than traditional single-site clustering and requires significantly more expertise, monitoring, and of course expense. Cluster failover is an all or nothing proposition. If a node experiences a failure in its public network adapter, for example, then that entire node is offline even though the rest of the node may function properly. For this reason, companies often configure the nodes themselves with significant hardware redundancy: Spare power supplies, redundant network adapters, and so forth. Doing so increases the odds of a node surviving a component failure, but significantly increases the cost of the node hardware. Use of these hardware redundancy features must be carefully planned: Swapping out a power supply, for example, can make Windows think that a failure has occurred on the node, forcing a cluster failover which can then create a short period of downtime. 4

5 Third-Party Higher Availability: Fast Recovery With the high cost of many high-availability solutions, many companies opt for higher availability, often in the form of backup and recovery solutions that are capable of rapidly restoring an entire server commonly in just a few minutes. There are an enormous number of vendors in this space, including traditional backup software ISVs as well as newcomers to the space. A typical approach leverages technologies that are more-commonly associated with backup and restore technologies, but have been expanded to support additional failover features. These technologies back up individual disk blocks as they change, sending them to a central backup solution and disk-based storage device. With the right network infrastructure in place, that central backup server can write a complete copy of a server s disks to a new server (of similar or different hardware composition) or to a virtual machine, very quickly. These systems often focus on getting the core server back online and operating, while restoring data in the background. Data remains accessible while being restored, although at a much lower level of performance. A complete restore to full performance can still take a day or more, depending on the amount of data being restored. With prices in the hundreds, not thousands of dollars, some businesses, particularly smaller companies with price-sensitive executives, often see this as an acceptable tradeoff between cost and downtime. What companies often miss, however, is the need for manual intervention. These solutions can t automatically detect a failed server and automatically bring up a backup copy on a spare server or on a virtual machine. An administrator is needed to put the process into motion, supervise it, and complete it. If a failure occurs during the workday, then that s no problem. Organizations often fail to consider, however, scenarios where an administrator isn t immediately available. If someone has to be paged, downtime may exceed an hour or more while the administrator gets into the office and performs the recovery. In some cases, such as in inclement weather, getting someone to the datacenter may be impossible. There s also still the need to have a spare server or virtual machine capacity within the organization, so that it can be utilized in the event of a failure. This additional capacity is often a hidden cost of this kind of solution, unless the organization already has sufficient spare capacity that can be reserved for this use. Using virtualization for spare capacity can be dangerous when the real server is not virtualized. For example, taking an extremely busy physical server and moving it to a virtual machine, on a host that runs other virtual machines, can create significant performance problems to the point, in some instances, of being little better than outright downtime. Fast-recovery solutions are rarely seen by businesses as a means of eliminating or reducing planned downtime. There are risks involved in restoring a server, using it for a time, and then restoring the current server state back to the original hardware. 5

6 Third-Party High-Availability Through Virtualization The widespread adoption of virtualization has created new options for high availability. For example, VMware Fault Tolerance, an additional feature of the company s vsphere product line, creates multiple copies of a virtual machine on redundant virtualization hosts. These virtual machines are constantly running, and are synchronized across a private network with the active virtual machine. Processor and memory are all synchronized, so that if the active host fails, or requires maintenance, one of the other instances can immediately take over. Such a failover is usually imperceptible to client applications and users, and can happen automatically in the event of a failure, or on-demand for scheduled node maintenance. This would seem to be the ideal high-availability solution, but VMware s current implementation is rife with limitations. Virtual machines can, for example, only be assigned a single virtual processor. That is a killing disadvantage with applications like SQL Server that are specifically tuned for high levels of multi-processing. In a consolidation scenario, when several SQL Server instances are migrated to a single, powerful machine, the singleprocessor limit is entirely impractical. VMware s Fault Tolerance technology has other meaningful limitations, including: Shared storage such as a SAN is required. Like Windows Clustering, this makes the storage a potential point of failure, unless it is also built with high levels of fault tolerance. Thin-provisioned disks are not supported, meaning one of VMware s more popular disk-management features is not available in fault tolerance scenarios. Certain non-replayable devices, such as USB, physical CD-ROMs, and so forth are not supported. This is typically not burdensome for most SQL Server virtualization scenarios. 6

7 everrun MX s Approach to High Availability Marathon Technologies everrun MX starts with the basic virtualization approach discussed above: Using virtualization, Marathon has created a packaged high availability product. Essentially, you install everrun MX, create virtual machines, and then deploy Windows Server and SQL Server inside those virtual machines. Marathon s innovation is in supporting the synchronization of up to eight processors between a large number of nodes, in addition to synchronizing memory and disk storage. This permits the creation of virtual machines with multiple processors, suitable for high-volume SQL Server installations or for SQL Server consolidation. Marathon has kept the installation and configuration of everrun MX extremely simple. A decently-experienced server administrator should be able to have an availability pair up and running in a few hours much of that time given over to operating system, application, and SQL Server installation processes. No specialized hardware is required. This simplicity is a welcome improvement over the more-complex hardware requirements and setup steps under Windows Clustering. everrun MX supports simultaneous cross-node component failure. For example, suppose you create an availability pair with Node A and Node B. Node A experiences a disk failure, but can continue running because it is synchronizing its disk storage with Node B. At the same time, Node B experiences a public network adapter card failure, but can continue providing disk synchronization to Node A, keeping that node active. There is no failover time: Nodes are accessed through a shared, managed IP address so that network traffic is always capable of reaching a surviving network adapter within the availability set. In demonstrations, Marathon runs a series of benchmarks against SQL Server, and pulls the utility power plug from a server in the availability set. The benchmark application continues to run without exhibiting a timeout or interruption its traffic is simply directed to a surviving node. The cutover time between nodes is barely measurable so little, in fact, that Marathon prefers the term Always-On over high availability when describing the product s market space. The system supports planned maintenance, as well. Maintenance such as patch installation is performed on inactive virtual machines within the availability set. Once complete, the inactive virtual machines are made active, which takes place instantly. The formerlyactive virtual machine can now be patched. everrun MX supports installation on commodity server hardware, which offers businesses the opportunity to create availability sets for a lower price than the more-specialized, certified hardware often required for Windows Clustering. everrun MX does have specific network requirements: Each node in the availability set needs a high-speed private connection to the other nodes (typically Gigabit Ethernet or 10Gb EtherNet), as well as connectivity for use by clients. Marathon has announced flat pricing for the solution, offering a fixed price for a two-node availability set. Unlike pricing models that focus on users, seats, processors, or other components, this more-transparent pricing model will likely make the solution more attractive 7

8 to smaller- and medium-sized businesses, who are typically very cautious with their IT budgets. An optional extension to everrun MX permits split-site availability sets. In this model, the nodes in the set are separated by some geographic distance, and connected by highbandwidth network links. Suitable for office park and other campus scenarios, the splitsite model provides additional tolerance for site-based disasters, such as a loss of utility power, flood or other natural disaster, and so on. Marathon cites a distance limitation of approximately a mile, based primarily on the latency in the inter-site network connection. An additional product, everrun MX Extend, provides additional capabilities for off-site disaster recovery across more distantly-separated sites, but is not included in this review. We should note that a key selling point of everrun MX is its ease of installation. Highavailability solutions aren t generally known for straightforward or easy installation. Windows Cluster Service, for example, had traditionally involved specialized hardware (which is less true in current releases) and very complex hardware and software configurations. everrun MX, by contrast, installs much more like a typical software application. You install the product, create virtual machines, get the virtual machines up and running (meaning installing Windows, SQL Server, and so forth inside), and you re pretty much done. There s no complex cluster configurations, no everrun MX-required hardware configuration to speak of, and very little complexity. A decent administrator can have the system up and running in a few hours, and most of that time will be spent installing Windows and SQL Server, not on Marathon s product. 8

9 Summary With everrun MX, Marathon appears to have created an availability solution that is easy to deploy, works automatically, and is ideally-suited for SQL Server. Its multi-processor support is particularly well-suited for high-volume SQL Server deployments as well as SQL Server consolidations. Its ability to handle multiple, simultaneous component failures on different nodes suggests that availability sets could be constructed from less-expensive, less-redundant hardware, while still enjoying the component-level fault-tolerance that more expensive hardware provides. Because everrun MX provides automatic fault tolerance for any application installed within one of its virtual machines, we suspect that it will be seen as a simpler solution for highavailability for a large number of complex solutions. Microsoft SharePoint, for example, has a very complex high-availability model that requires different techniques at multiple, different application layers. Simply installing SharePoint into an everrun MX availability set, however, would provide instant and automatic high availability with much less architecture, planning, design, deployment, and configuration. everrun MX could also be a way to provide always-on availability for Exchange Server and other mission-critical applications, in lieu of more complex, clustering-based solutions. Product Facts Marathon Technologies everrun MX Review based on shipping product as of January

10 About Concentrated Technology Concentrated Technology, LLC is a technology education and analysis consulting firm founded by industry luminaries Don Jones and Greg Shields. The company provides strategic consulting services to companies around the world, and performs market research and analysis for technology vendors and customers. The company distinguishes itself through its motto, Maximum Knowledge - Minimum Time, focusing on producing concise, accurate materials that help modern businesses accomplish more, with less effort. About Marathon Technologies At Marathon Technologies, we focus on one thing: application availability. With this single-minded focus, we have developed innovative and unique fault tolerance, disaster recovery, and high availability solutions that proactively prevent application downtime with unmatched reliability and simplicity even in environments where IT resources are limited. Our innovative everrun technology proves that always on IT doesn t have to be expensive or require teams of experts. Our more than 3000 customers worldwide include innovators and leaders in their respective industries who turn to Marathon to prevent application downtime, eliminate data loss, reduce operational costs and gain a little peace of mind. We re the availability standard for leading ISVs in a range of vertical industries whose users can t afford downtime. And we have strategic partnerships with Microsoft and Citrix to bring always on computing to a much broader audience. By working with closely with our partners and customers, we continue to expand the frontiers of application availability, delivering fault tolerance, disaster recovery, and high availability software solutions that are so simple, reliable and resilient that no Windows application ever needs to experience downtime or data loss. About this Paper Although often commissioned by a third party, Concentrated Technology analysis papers are 100% independent and objective. The commissioning company typically participates in our analysis by answering questions, demonstrating their products or services, and by providing Concentrated Technology with software to test and evaluate. However, neither the commisioning company nor any other entity exercised any editorial control over the content of this paper. The commissioning company has the option to discontinue and block publication of this paper in its entirety. Various external experts may have provided technical proofreading and technical reviews, but their input was limited solely to improving the technical accuracy of this paper. The opinions and views expressed herein are solely those of Concentrated Technology, and may not reflect the opinions or views of the commissioning company nor any other company or entity described or mentioned herein. This paper is copyrighted 2011 by Concentrated Technology, LLC. No portion of this paper may be reproduced in any form without prior written consent. 10