• Solutions
  • By Industry
    • Distribution
    • Security
    • Gaming
    • Government
    • Healthcare
    • Manufacturing
    • Media & Entertainment
    • Travel, Transportation & Logistics
  • By IT Need
    • Proactively Prevent Downtime
    • Protect Data for Compliance
    • Achieve Disaster Resilience
    • Reduce CAPEX & OPEX
    • Provide HA in Remote Locations
  • Small & Medium Business Solutions
  • Windows Business Application Availability
    • BlackBerry HA
    • Exchange HA
    • SharePoint HA
    • SQL HA
    • XenApp HA
    • BlackBerry DR
    • Exchange DR
    • SharePoint DR
    • SQL DR
    • Virtual Server DR
• Products
  • Overview
  • everRun MX
  • everRun MX Express
  • everRun MX Extend FT+DR
  • everRun SplitSite
  • everRun HA & FT
  • everRun Advantage
  • Product FAQs
• Services
  • everRun Services Overview
  • Consulting Services
  • Training Services
    • Authorized Training Centers
  • Assurance Program
  • Customer Portal
  • Requesting Technical Support
  • Technical Community Login
  • everRun Assist Web Support
• Partners
  • Partners Overview
  • Citrix Alliance
  • Microsoft Alliance
  • ISV Partners
  • Why Resell Marathon
  • Partner Program FAQs
  • Find A Reseller
  • Partner Login
• Resources
  • Resource Center
  • White Papers
  • Webinar Recordings
  • ROI Calculator
  • Collateral
  • Flash Demos
  • Glossary
    • Symmetric Multi-Processing
    • Continuous Application Availability
    • Application Availability
    • Disaster Recovery
    • Failover
    • Fault Tolerance
    • High Availability
    • High Availability Cluster
    • Server Redundancy
  • Customer Endorsements
  • Success Stories
  • Product Reviews
  • Analyst Opinions
  • Exporting everRun Products
• News & Events
  • Latest News
  • Press Releases
  • In The News
  • Events & Webinars
• About Us
  • Overview
  • Announcement
  • Why Marathon
  • Executive Team
  • Board of Directors
  • Awards
  • Careers
    • Current Openings
    • Benefits
  • Corporate Offices
  • Contact Us

Blog

Thanks again to everyone who joined us for last week’s webinar “Top 5 Low Cost Tips for Preventing Exchange Downtime” where Marathon’s availability experts reviewed their key tips for the prevention of downtime, including:

1. Reduce human error with process
2. Document your infrastructure
3. Remove single points of failure
4. Don’t forget to test
5. Understand your requirements

There’s a lot of great information in this 40-minute webinar, so be sure to check it out. We’ve summarized the Q&A portion for the webinar below.
 

Q: What type of storage does everRun support?
everRun supports any type of storage that you have. The most common storage configuration we see is local disk drives for the servers themselves. That would have the same amount of data protection as even a SAN would, and in some cases would be even better protection, because you have total redundancy from both servers and everRun is protecting that as if it’s a single storage device. You could also have iSCSI connected storage, or any kind of SAN storage that you wanted to have. Again, everRun supports any type of storage.

Q: Which versions of Exchange do you support?
The beauty of the everRun architecture is that is can support pretty much any Windows-based application. Exchange 2003, Exchange 2007 or Exchange 2010 – everRun supports them all. Some other high availability solutions require specialized scripting to support applications, but everRun does not require this. Also, with solutions like clusters, sometimes you have to buy the higher-end more expensive “enterprise” versions of the application software to support that configuration, but with everRun, we can provide complete protection for the standard versions of Windows and Exchange Server or any other application.

Q: What is the load on the systems when using everRun?
The good news here is that there is very little overhead associated with everRun – about 5% to make things run redundantly. That’s a very small performance price to pay to get such a high level of protection for Exchange.

Q: How does everRun handle the mirroring of data that’s loaded in memory?
There are a couple of ways that is done. Since the application is actually running both severs simultaneously, that means the memory is being replicated on both servers simultaneously as well. Keep in mind that as the applications execute, they are storing to storage, and because of the redundancy built into the everRun solution, that data is being written from memory down under the storage element redundantly as well.

Q: Is it possible to run servers in two different locations?
Absolutely. In the slide where I showed the everRun architecture with the two servers, you can take those two servers and separate them geographically. They could be in different rooms in the same building, different buildings on the same campus, or even separated further, by about 100 miles, depending on the bandwidth and latency of your connection. We call this our SplitSite configuration.

Q: How is this different from a cluster solution?
The major difference of everRun vs. a cluster solution is that we are doing operations on two servers simultaneously. The application is actually running in tandem on both of these servers. With a cluster solution, you’re running your application on one server, while the other server stands by and waits for a failure to occur. That means that with a cluster solution, when the first server fails, the cluster then has to do something to start up the application on the second server and then continue from that point. But that means downtime, data loss, and loss of connectivity. With everRun, that doesn’t happen. Because the other server is already doing the same thing, there is no downtime and no data loss, because there is no “recovery” – even when there is a failure.

Q: So are both servers “hot” in an everRun configuration?
Yes – that’s exactly right. Both servers are active and run simultaneously, unlike a cluster. So with everRun, you could have a failure of a component on one server and then another type of failure on the second server and still be operational. With a cluster, this scenario is not possible. If you have failures on both systems at the same time with a cluster, then you are down.

Q: Does everRun require dedicated servers just for Exchange?
No – everRun protected servers do not need to be dedicated to one specific application. You can run multiple applications on this pair of servers, and even chose which ones you do or don’t want to protect with everRun. This is good for small businesses, who want or need to consolidate several applications on to fewer servers.

For more information about protecting Exchange from downtime, be sure to check out our white paper "Six Secrets to 24x7 Exchange Availability."
 

It’s always interesting at this time of year to take a look back at what was top of mind for our newsletter readers. It’s also a great opportunity for you to discover a key topic that you might have missed the first time around. Here are our top 5 most downloaded articles and white papers of 2009:

1. Configuring High Availability for Windows Server 2008 Environments
2. Optimizing Exchange High Availability - A New Approach
3. Increasing Reliability and Availability in a Virtualized SQL Server Environment
4. Reduce Downtime by 70% - Without Spending a Dime
5. iX Magazine product review: vSphere 4 FT vs. Citrix XenServer with everRun VM
 

If you would like to stay current with latest trends, developments and tools in the world of high availability and disaster reocvery, be sure to sign up for our monthly newsletter by sending an email to mstec@marathontechnologies.com or click on the Resource Center and look for the sign-up box in the right column.

How many times do you check your email each hour? Recent studies have shown that the average worker checks email once every 15 minutes, with some users checking email as often as 40 times per hour. In addition, growing use of iPhones, BlackBerrys and similar email-enabled mobile devices means that employees have become attached to their email at all times, with some checking their device as soon as each email arrives. Now that email has evolved into a must-have business communications tool, employees have come to expect access to their email 24x7, with very little tolerance for downtime.

Meeting the “always on” expectations of employees creates challenges for the IT administrator. Service-level agreements (SLAs) are increasingly stringent and demanding as users require non-stop access to email and other collaborative features of Microsoft Exchange. Availability of Exchange is paramount, as well as protecting the integrity of your Exchange data. In order to maintain Exchange availability, every component of the Exchange infrastructure needs to be considered. You can protect your mailbox server to the highest degree, but if your DNS server fails, the Exchange server may not be accessible.

To help your company protect its Exchange environment, Marathon has developed a series of steps for achieving optimal Exchange availability. The tips are designed to help identify what availability levels should be designated in order to achieve Exchange SLA commitments with fewer resources and lower costs.

Define Availability Objectives
Creating availability objectives is an important first step in formulating Exchange protection strategies. This is typically done by establishing Recovery Time Objectives (RTO), the time it takes for an application to be running again, and Recovery Point Objective (RPO), the point in time to which the IT professional can recover data in case of a failure, for your Exchange environment.

RTO and RPO baselines establish the SLAs you commit to for the overall company, business units, or specific internal groups. You may even have different Exchange SLAs for different users within your company. For example, you may have an executive group that requires 24x7 email access, while the rest of the company can withstand Exchange downtime of up to one hour. In addition, consideration should be given to what level of protection is needed for the other components of your Exchange infrastructure, such as Active Directory and DNS servers.

Understanding the Levels of Availability
There are multiple levels of availability to consider for different applications and their support infrastructures, starting with basic failover and recovery, moving up to high availability, and all the way to continuous availability for extremely transaction-sensitive applications.

1. The Recovery level is for those applications for which recovery time (RTO) of a day or more is often acceptable. Some downtime is acceptable, and even significant downtime won’t have a detrimental effect on the business. Assurances that recovery will happen is not a requirement.

2. The High Availability level is the home of the majority of applications that run the business, such as email, CRM, financial systems, and databases. These are systems with high downtime costs, and therefore short RTO requirements. These applications require assurances that they will not be down for extended periods should failures occur.

3. The highest level of availability is Continuous Availability in which even brief moments of downtime or a single lost transaction can be extremely detrimental and/or costly to the client or business.

As you establish availability objectives for different groups of Exchange users, you need to consider the protection requirements for your entire Exchange infrastructure, beyond just the mailbox server. You will need to protect all of the components of the Exchange environment, in addition to the different workloads deployed on the mailbox server. Also, don’t forget that the way your company uses Exchange today might change in the future. You may use Exchange today for general correspondence, but within the next year you may plan to use email to process orders. This adds to the need to have multiple levels of availability to assign to the components of the Exchange infrastructure and Exchange user groups. Additionally you’ll need flexibility to change those levels as your business changes.

Assigning Levels of Availability to Exchange Environments
A meaningful exercise to undertake is to apply various levels of protection to your Exchange infrastructure based on your SLA commitments. First look at the users and their requirements for Exchange access. Do you have a single SLA in place for all users, or do you have multiple user groups with different SLAs? If you have a single SLA in place company-wide, you can deploy those users in workloads based on email usage and assign them a single level of protection. However if you have different SLAs for different business groups, you can divide those into multiple workgroups on the mailbox server based on their SLA requirements.

For example, if you have an executive group that needs a 24x7 uptime, then you should consolidate those executives in a dedicated Exchange workload and assign a level of protection that will provide continuous availability. Sales people can often fall into this category as well, requiring non-stop access to email and Exchange collaboration features. Other employees may have less stringent SLAs in place and would require a lower level of protection.

It is also important to keep the components of Exchange, including the DHCP server, DNS server and Active Directory server, up and running. If one or more of these components goes down, requiring the IT administrator to manually intervene could cause excessive downtime for Exchange and exceed your SLAs. Automatic recovery from failures enables you to keep the Exchange environment operating to meet your SLA commitments. Assigning a level of protection to the supporting systems, including the DNS, DHCP, and Active Directory servers, equivalent to that necessary to meet your Exchange SLAs is as important as protecting the actual Exchange servers. Any single point of failure could bring down a well protected Exchange server.

For remote employees and “road warriors”, your company may also have a BlackBerry Enterprise Server (BES) and/or Client Access Server (CAS) implementation, to serve as a secondary or backup method for remote email access. The BES and CAS implementations should be protected to the level you require based on your remote email access strategy and user SLAs.

Establishing RTO and RPO for SLA commitments, determining the right level of availability protection to meet these commitments, and protecting all components necessary to support an Exchange environment will help create n robust and reliable messaging system.

For an even more detailed look at Marathon’s approach to Exchange high availability, download our “Optimizing Exchange High Availability - A New Approach” white paper or our complete Exchange 2007 High Availability Toolkit.
 

Getting ready to deploy Exchange 2007? If so, we’ve put together a comprehensive set of tools to help you select the optimal availability levels for your Exchange 2007 environment:

• Optimizing Exchange High Availability—A New Approach explains how to use a new strategy for Exchange high availability that enables you to protect all aspects of your Exchange environment with the right amount of resources.

• Exchange 2007 Performance White Paper to help you understand and characterize the performance implications for running Exchange 2007 with everRun.

• Exchange 2007 Deployment Blueprint that includes hardware recommendations, workload planning, shared storage design, networking best practices and other practical tips for your Exchange 2007 deployment with everRun.

• Webinar/Q&A: download our “Optimizing Exchange High Availability” webinar and also check out our blog post that recaps the Q&A covered during the webinar.
 

I recently blogged about how to apply the three levels of availability to Exchange 2007 mailbox servers. By splitting the amount of users across multiple VM’s you can provide a level of availability to each set of users based upon your SLA with each business unit in your company. 

Since Exchange is more than just a mailbox server, we thought it would make sense to provide you with a deeper look at how to protect all of the components of your Exchange environment. I’ll be co-hosting a webinar on this topic on May 20th. You can register for this webinar here. We'll provide an in-depth look at a new approach that allows you to tailor the levels of availability by user groups and Exchange components.

We’ve also published a new whitepaper on this topic, “Optimizing Exchange High Availability—A New Approach,” which is available for download in our Resource Center.

When planning your VM workloads, you should be aware of what level of availability each server will need. By splitting the amount of users across multiple VM’s you can provide a level of availability to each set of users based upon your SLA with each business unit in your company. Looking back to the availability pyramid you can choose which level of availability for each mailbox server is needed. For example if you have an executive group that needs to be up with a 24/7 uptime and only limited downtime then level 3 should be your selection on a separate mailbox server. If all of your business units require the same level of availability and have the same SLA in place then you will split your mailbox servers according to usage. Using the chart from section one we can split the users based upon the type of user. For example if you have 1,000 heavy users we would assign 2 vCPU’s to the virtual machine. Always follow Microsoft best practices when deploying the amount of users per core or vCPU.

If we look at Figure 1 we can see that that we have 4 active VM’s spread across two servers with 2 vCPU’s assigned to each. Looking at the example chart above and using figure one we can see that this design example would support 4,000 “Heavy users”. We achieve this by allowing our storage groups on each mailbox VM to support 1,000 “Heavy” users.

Let’s take a look at a basic design with 3 separate types of users spread across 4 servers. We have an executive mailbox store, a mid-management store, and a general user store. In looking over what each teams HA requirement is we have come to the following, the executive team needs 24/7 up time with no downtime except for a maintenance window once a month. The mid-management team can handle some downtime, but only a few minutes each week. The general users have no HA requirement they can be down for an hour a week if needed. So how do we decided what level of availability we would like to use, it’s easy we simply look at the application availability pyramid and we put the appropriate mailbox store at each level:

By using this simple plan you can simplify you’re HA strategy for Exchange. By distributing the mailbox stores across multiple servers on the same hardware you can save rack space as well as provide individual levels of availability based upon different business unit needs.

We had a lot of great questions during the Q & A session of our January webinar with one of our customers. We’ve posted the questions and responses here on our blog for everyone’s benefit.

Questions for The Sullivan Group:

Q: Which everRun product are they running? everRun HA or FT?
A: everRun VM

Q: How did you migrate your VMware VMs to XenServer?
A: We used a V2V software migration tool from Visioncore that worked really well.

Q: What was the procedure when bringing back up one of the servers when the RAID card failed. How easy was it?
A: It couldn’t have been easier. Once we repaired the failed component, everRun identified it and put it back into use. everRun used a mirror copy to bring the two systems back in complete synchronization. This all happened without our intervention and without impacting our users.

Q: Was a short implementation time a demand from The Sullivan Group, and what was the expectations before the implementation?
A: Short implementation time wasn’t a hard requirement. We expected the implementation to take a couple of weeks and were pleasantly surprised when we had it all up and running in a little less than a week.

Questions for Marathon:

Q: Is there a special license for SQL? Or any other special considerations?
A: Special licensing for the applications you protect is not required. You should refer to the SQL license agreement or the agreement for the application on the VM that you are protecting. With everRun, only one instance of the application is running at any one time.

Q: Is this active active or active passive?
A: We refer to it as ‘active/ready’. The secondary VM is in a paused state, however disk and network I/O are being processed. This allows everRun to deliver fault tolerance at the component level, while immediately starting the paused VM fully in the event of a full host failure on the primary side.

Q: Do you have to install everRun prior to your application, so if I already have an application installed would I need to rebuild the production server? IF so does this change the install time and impact?
A: Assuming you have a VM set up on a host, the application can be installed before or after the VM is protected with everRun. The protection process does require the VM to be shutdown prior to beginning the protect process, however the process takes about 2 minutes to complete after which time the VM can be restarted.

Q: How does everRun handle Software or OS hangs?
A: everRun does not monitor applications.

Q: In your opinion what is the strongest difference between this and MS Clustering?
A: MS Clustering can be a nice fit, especially with applications such as SQL Server. One of the requirements for MSCS is shared storage, or a SAN. This requirement can push the cost out of reach for many small and midsized businesses. everRun does not require shared storage and can utilize any type of storage the customer may have or intend to purchase. In addition, everRun provides fault tolerance and not just failover restart. This helps to minimize interruptions typically caused by failed devices.

Q: Does everRun VM support Windows x64 architecture on VM?
A: Yes, everRun and XenServer support 64-bit hardware and software.

Q: Can VM run Windows 2008 x64? Or Windows 2003 x64?
A: Citrix XenServer supports VMs running Windows 2008 64-bit and Windows 2003 64-bit. Currently everRun VM can protect VM’s running Windows Server 2003, 32-bit and 64-bit. Our next release planned for calendar Q2 09 will support Windows Server 2008 32-bit and 64-bit VM’s.

Q: How much overhead do you have when you protect a VM?
A: When protecting a VM you are able to define how much of a particular resource is to be utilized and reserved. This helps to reduce the amount of resources required for protecting VM’s. Performance overhead can vary depending on if it is I/O heavy, CPU heavy, what the application is, etc. Typically however performance overhead is not impactful.

Q: Is everRun tied to a VM on a particular physical XenServer, what would happen if you used XenServer technology to move to another physical server?
A: Once a VM is protected with everRun, it is hard-configured to two physical hosts. everRun allows online migration of the active VM between these two hosts without interruption. To move one or both VM’s in the protected pair to a different host would require it to be unprotected, migrated if necessary, and protected again with the new host.

Q: Please speak about XenServer integration, process for failover to DR site?
A: everRun has a tight integration with XenServer. everRun is installed on top of XenServer and is completely compatible and able to protect Windows VMs created in XenCenter. During the protection process, everRun takes the chosen VM and clones it to the designate secondary host. This creates a complete and identical VM on the secondary host. everRun maintains these two VM synchronously so that they are always identical. everRun’s unique architecture exposes these two mirrored VM’s as a single VM; there is no need to install, manage, or update both sides, only the one single instance of the OS/application. Should the entire ‘primary’ host fail, the ‘secondary’ host will immediately start the cloned VM. It comes up with the same IP address, hostname, and MAC address of the primary so that there are no client-side, DNS, Active Directory, or other infrastructure changes required.

Q: Will everRun run on x64?
A: Yes, it requires 64-bit servers.

Q: I assume the servers must match i.e. memory, HD space and memory as well as other array controllers and type of arrays?
A: The only requirement for similarities within the servers is same family of processors. everRun can mirror storage between dissimilar storage types and vendors, allowing lower-cost storage to be deployed on the ‘secondary’ host.

Q: Is everRun for virtual servers XenServer specific, or does it work with Hyper-V, Virtual Iron, etc.?
A: Today everRun is developed for XenServer. In January we announced a development and marketing agreement with Microsoft, we will be developing an everRun product for Hyper-V as well.

Q: What if the server is up but a single app on the server fails? Also, how do you detect the app failed?
A: everRun does not monitor applications. However if by ‘single app’ you mean a single VM, everRun does protect at the individual VM level. If a VM fails yet the host and other VM’s remain alive, everRun can restart the VM on the secondary host.

Q: Do you have to purchase redundant licenses for the applications that you have replication as Virtual Machines across two physical servers? For example, do you have to purchase double the Exchange licenses to do it or just the licenses as if you had a single server?
A: You would need to refer to the license agreement for each application. With everRun, the application is running as a single instance and many vendors don’t require two licenses, but this varies between vendors.

Q: Can you have full fault tolerance on XenApp servers between 2 datacenters, where users would not be disconnected from their session if a failover occurred?
A: everRun can certainly protect XenApp as it can protect any Windows application. A number of customers are using everRun to protect XenApp today. The ability to separate between data centers (there are latency requirements due the synchronous nature of everRun) will be available in Q2. To prevent session disconnects will require Level 3 protection, or full System-Level Fault Tolerance, which will also be available for everRun VM in Q2.

Q: Can the VM servers be in different data centers across a WAN behind firewalls?
A: The ability to separate servers geographically will be available in Q2.

Q: Are there general guidelines on the number of VM's that can be protected between two host machines? I'm thinking of SQL Server systems hosting highly transactional databases.
A: The answer to this is dependent on the applications running within the VM’s, hardware, and activity within them, so providing a set number of VM’s would not be practical. Please contact Marathon if you would like to discuss your environment to better understand what VM limits may be suitable.

Q: How can you use the USB interface, for example when software requires a dongle?
A: everRun does not redirect the USB interface to a protected VM.

While most companies using Microsoft Exchange still use Exchange 2003, Exchange 2007 provides a new, more flexible architecture that provides real benefits worth looking at. This new architecture is based on server roles. All services and features are organized around five distinct server roles: Mailbox, Client Access, Hub Transport, Unified Messaging and Edge Transport. The big advantage to this approach is that you only have to deploy the roles that are needed and multiple copies of a role can be deployed for enhanced availability, DR and performance.

When Exchange 2007 is run in a virtual server environment each role can be implemented as a separate virtual machine. Individual services can be easily matched to resource requirements by selecting the number and location of the virtual machines implementing each service to be started. The number, location and configuration of these virtual machines can be dynamically adjusted as usage requirements change over time. Infrastructure components that support the Exchange environment, including Active Directory, DNS and DHCP that have traditionally required separate servers and distinct availability solutions, can now be implemented as virtual machines in a common resource pool and leverage the common availability solution that is used to address the entire virtualization environment.

Virtualization also makes disaster recovery easier to implement, more effective and less costly. Virtual machines separate the software configuration from the underlying hardware. This provides total flexibility in the hardware required for the disaster site. One set of hardware can provide disaster backup for multiple applications and cost effective configurations can be chosen strictly based on their disaster recovery role. Software configurations change over time and changes must be duplicated at the disaster site to ensure proper operation. This can be extremely time consuming and error prone in a physical environment. In a virtual environment, the configuration is contained within the virtual machine definition file. Simply copying this file to the disaster site is all that is needed to maintain configuration compatibility.

So how many of you have made the important step to moving to Exchange 2007? If you haven’t deployed 2007 yet, are you planning to? We would love to hear from you. If you have a minute, please take the poll to the left and tell us your plans. If you deployed it, are you taking advantage of the virtualization benefits? Leave us a comment and share your thoughts.

Every day, companies around the world rely on the features of Microsoft Exchange for their business-critical applications like email, calendaring, contacts, mobile support, web-based information accessing and data storage support. While we’ve discussed the importance of maintaining Microsoft Exchange high availability and steps to simpler Exchange HA, we thought this would be a good opportunity to share a case study from one of our customers.

Connecting Employees, Vendors and Customers Without Interruption

A large U.S. furniture retailer was becoming increasingly dependent on Microsoft Exchange 2003 for internal communication and collaboration, and for communication with both vendors and customers. Since the retailers primary revenue-generating activities relied on e-mail, downtime would have resulted in serious consequences. As a result, Exchange protection became a requirement and top priority for senior leaders.

everRun –An Alternative to Clustering

The IT staff had previous experience with traditional clustering and was looking for an easier, more robust solution. They selected everRun and implemented a solution using a pair of IBM servers with local boot disks and a fibre channel SAN for the datastore. Currently, the system supports close to 1200 users.

No Exchange Failures = Increased Competitive Advantage

In over a year of operation, they have not experienced a single unplanned disruption of their Exchange system. In turn, this has allowed them to keep their revenue-generating activities operating at full speed. As a result, they are currently looking at adding the everRun SplitSite option to allow geographical separation of their systems for additional protection.

Do you have a story when protecting Exchange would have been a better option than what resulted? How did it affect you or your company?

Yesterday, Matt Fairbanks, VP Product Marketing, Citrix, and Jerry Melnick, CTO, Marathon, presented the webinar “Virtualizing Exchange – The Cold, Hard Numbers on Why Citrix XenServer + everRun VM is the Best Platform.” Below are a few of the questions asked from participants with Jerry’s response to each:

Q: What happens in a case of a split brain scenario?

Jerry: In our SplitSite products, we have what we call a quorum services capability – it’s actually an additional component that’s added on to manage split brain and arbitrate when you lose all connections between the two machines.

Q: How long does it generally take to set up XenServer with everRun VM to create this kind of a solution?

Jerry: Citrix people have always mentioned “Ten minutes to Xen” which is a pretty good rule of thumb. We say it’s another ten minutes to add the Marathon software. It’s a simple script that gets run on each host, and then you’re off and ready to protect the machines. The actual protection process itself is really a matter of a minute. The simplicity and ease have never been seen before in this industry with this class of availability solution.

Q: In field of limitations and customers that have deployed this kind of technology, are there any things you would council people to consider to set up XenServer and everRun in the most highly available and robust way?

Jerry: With our system, we provide best practice guidelines for configuring networks availability, etc. One of the beauties of our technology – working in conjunction with XenServer – is that once everything is installed and running, we put everything into an active validation mode so that we know components are configured properly. If something is misconfigured or isn’t running redundantly, you’re going to see the status and receive a warning. A key benefit of this system is you will know how to fix it before there are any problems.

There are many cases in availability systems where you have simple failover technologies: you take an error, you failover, you get to that resource, and then you find out the network or disk isn’t working because it wasn’t configured properly. By having this active validation capability and the report out, the status is being monitored in a simple and reliable fashion – you know when you’re redundant and how you’re going to manage failures.

Thanks to everyone that attended. For those that didn’t have the chance to attend or ask questions, please feel free to leave them in the comments section and we will do our best to answer them.

For those of you that may have forgot to put it on your calendars, Marathon and Citrix are holding a webinar today to showcase the benefits of virtualizing Microsoft Exchange servers. Event attendees will learn:

The webinar will begin promptly at 11:30 a.m. EDT, so if you haven’t yet registered you can do so here.

For those that can’t attend, we will be posting the Q&A following the event.

As we noted in our last post, Exchange High Availability has become increasingly important to businesses of all sizes. To help you get started, we’ve put together these five tips, which are easily-digestible pieces from our “Protecting Microsoft Exchange in Physical and Virtual Environments” white paper.

STEP ONE – PROTECT AGAINST SERVER FAILURES WITH QUALITY HARDWARE AND COMPONENT REDUNDANCY

Server core components include power supplies, fans, memory, CPUs and main logic boards. Purchasing robust, name brand servers, performing recommended preventative maintenance, and monitoring server errors for signs of future problems can all help reduce the chances of Exchange downtime due to catastrophic server failure.

Downtime caused by server component failures can be significantly reduced by adding redundancy at the component level. Examples are: redundant power and cooling, ECC memory, with the ability to correct single-bit memory errors, and combining Ethernet cards with RAID.

STEP TWO – GET RID OF STORAGE FAILURES WITH STORAGE DEVICE REDUNDANCY AND RAID

Storage protection relies on device redundancy combined with RAID storage algorithms to protect data access and data integrity from hardware failures. There are distinct issues for both local disk storage and for shared, network storage.

For local storage, it is quite easy to add extra disks configured with RAID protection. A second disk controller is also required if you want to protect against controller failures.

Access to shared storage relies on either a fibre channel or Ethernet storage network. To assure uninterrupted access to shared storage, these networks must be designed to eliminate all single points of failure. This requires redundancy of network paths, network switches, and network connections to each storage array.

STEP THREE – PREVENT NETWORK FAILURES WITH REDUNDANT NETWORK PATHS, SWITCHES AND ROUTERS

The network infrastructure itself must be fault-tolerant, consisting of redundant network paths, switches, routers and other network elements. Server connections can also be duplicated to eliminate failovers caused by the failure of a single server or network component. Take care to ensure that the physical network hardware does not share common components. For example, dual-ported network cards share common hardware logic, and a single card failure can disable both ports. Full redundancy requires either two separate adapters or the combination of a built-in network port along with a separate network adapter.

STEP FOUR – FORGET SITE FAILURES WITH DATA REPLICATION TO ANOTHER SITE

Site failures can range from an air conditioning failure or a leaking roof that affects a single building, a power failure that affects a limited local area, or a major hurricane that affects a large geographic area. Site disruptions can last anywhere from a few hours to days or even weeks.

There are two methods for dealing with Site Disasters. One method is to tightly couple redundant servers across high speed/low latency links, to provide zero data-loss and zero downtime. The other method is to loosely couple redundant servers over medium speed/higher latency/greater distance lines, to provide a disaster recovery (DR) capability where a remote server can be restarted with a copy of the application database, which only misses the last few updates. In the latter case, asynchronous data replication is used to keep a backup copy of the data.

Data replication is combined with error detection and failover tools to help get a disaster recovery site up and running in minutes or hours, rather than days.

STEP FIVE – CONSIDER VIRTUALIZING EXCHANGE FOR BETTER HIGH AVILABILITY

The latest server virtualization technologies, while not required for protecting Exchange, do offer some unique benefits that can make Exchange protection both easier and more effective. Virtualization makes it very easy to set up evaluation test and development environments without the need for additional, dedicated hardware. Virtualization also allows resources to be adjusted dynamically to accommodate growth or peak loads.

To help you make the business case for virtualization Exchange, we’re producing a live webinar with Citrix on November 11th: Virtualizing Exchange - The Cold, Hard Numbers on Why Citrix XenServer + everRun VM is the Best Platform. Register for the webinar here.

For most organizations, email is single-handedly the most important tool for accomplishing business objectives. Without access to email, companies are at an immediate disadvantage in today’s “I want it now” marketplace. For example, let’s look at the impact email downtime has on productivity: Assuming that your employees are 25% less productive when email is unavailable, and their annual salary is $60,000, then every hour of downtime for an organization of 500 people results in more than $7,200 in lost employee productivity. Can your organization bare a $7,200/hour loss? In today’s economy? Probably Definitely not.

Avoiding the aforementioned consequence is an option, but in order to do so you need to guarantee continuous availability for your organizations email server. According to Paul Rubens at ServerWatch, 2007 forecasts from Gartner revealed that Microsoft Exchange 2007 will own 70% of the email market share by 2010. Now, whether Microsoft will actually return those results, it’s still too early to tell. However, as more and more companies rely on Exchange servers to run business functions, all potential causes of unplanned downtime need to be identified and eliminated.

Over the next month, we will be providing you with some recommendations on how to improve Exchange high availability through planned and unplanned downtime – starting with a webinar on November 11 titled “Virtualizing Exchange – The Cold, Hard Numbers on Why Citrix XenServer and everRun VM is the Best Platform.” For this webinar, Jerry Melnick, Marathon CTO, and Matt Fairbanks, VP of Product Marketing for Citrix Virtualization and Management Division, will team up to discuss how the latest server virtualization technologies keep users continuously connected to Microsoft Exchange servers in the easiest and most effective manner. We encourage you to register online for the webinar if you haven’t already.

Is there anything in particular related to protecting your Exchange severs you would like us to address in the next few weeks? Leave us a comment below and we will be sure to put it on our radar.

Everyone is well aware of the recent market turbulence and the pressure this will put on corporate spending. The economic situation is going to have an effect on every aspect of business action. However, despite budget cuts, I think that the increase in virtualization adoption will continue unabated. Here are a few things I expect:

• Since the beginning of 2008, the virtualization industry has seen changes in its landscape. Microsoft’s Hyper-V introduction has made a lot of noise, as more and more customers are seeing and trying it for themselves. One of the big draws for Hyper-V is its price point. In this market, its price will continue to make it an attractive solution. In fact, I believe the price will dip even further by year’s end, keeping it in consideration for enterprises as other solutions are ditched to shore up costs. As additional vendors support Hyper-V it will only become easier for companies to evaluate, justify, and acquire the solution.

• I believe that not only will Hyper-V demand continue, but people will also begin to adopt more than one hypervisor. Almost all companies have more than one operating system or hardware platform. Since IT departments are adapt at integrating heterogeneous technologies, it is only natural for companies to mix and match hypervisors to solve the specific challenges they have while meeting budget requirements.

• In general, many of the companies that made initial virtualization-related purchases capitalized on its “low-hanging fruit.” Most Fortune 1000 companies have already completed relatively low risk actions and virtualized applications like dev and test systems and file and print. Moving forward, I think that customers will now want to implement virtualization on more of their mission-critical applications. Applications like Exchange and SQL, which both have growing needs for high availability solutions.

• Expect the interest level and the actual deployment of both higher-end availability technology and sophisticated management tools, and the infrastructure that surrounds that, to quickly ratchet up. This will allow people to complete the first phase of adoption and will begin a speedier move towards mainstream inclusion of virtual technology in data centers.

How do you think the rest of the year will play out in the virtualization industry? Feel free to leave a comment with your thoughts; I’m interested to hear the insights of others.

We all like to think that we will be prepared in the event of an emergency, or a disaster. Hospitals exist if we fall sick; fire stations surround us if flames break loose; we are constantly preparing so if a catastrophe strikes, we are ready.

Preparing for a system’s disaster is no different. However, how to go about preparing for an event like this can be confusing. There are many options out there when it comes to protecting your system, each best suited for specific requirement. Unfortunately, many vendors use terms like disaster recovery and high availability interchangeably to describe their solutions when in fact they are usually designed for one or the other.

Disaster Recovery (DR) is the way to recover applications and from a system failure. DR is a reactive solution where if a failure occurs, IT relocates the data, builds the system over, and brings everything back up to working order. This takes time, a precious commodity that typically businesses relying on critical applications don’t have. In addition, recovering applications could bring about a number of side effects which you really don’t want to endure every time some minor failure happens.

But what if I could tell you that instead of worrying about how to recover from a computer system failing, you could simply prevent it from occurring at all?

Disaster tolerance (DT) is a proactive way to prevent system failure from impacting application and data availability. A disaster tolerant solution isn’t going to recover the data if there’s a disaster. Instead it will tolerate the fault if a disaster occurs – keeping an organization’s critical applications up and running at all times. It is not recovery, but rather prevention. And with solutions like our everRun SplitSite, separate servers don’t even need to be in the same building – they can be up to 100 miles apart with fault-tolerant protection between the two locations.

DR solutions are good for applications that can afford some downtime while you recover them. But for essential applications like Microsoft Exchange, SQL, and SharePoint, which need to be available all the time, disaster tolerance is often the best way to go.

So what combination of DT and DR protection would work best for your company’s applications?

Can virtualization move beyond test and developmental in most companies and become a key component of the core enterprise IT infrastructure? Jerry Melnick discusses the necessity of high availability in a virtual environment and how it can be achieved with Mike Vizard of eWeek.

If you’re interested in using virtualization for essential applications like Exchange but haven’t yet because you’re worried about keeping them available, we encourage you to listen to this podcast and learn about the proliferation of different virtual machines, why there are different types available, and how Marathon’s HA solution can make virtualization of applications like Exchange and SharePoint a reality.