Determining Your Need for Additional Resources

 < Day Day Up > 



The Great Divide

As with most of the backup products on the market, you can add additional backup servers to offset the workload of an overly burdened server. The question is, when and what advantage or disadvantage is there when implementing a solution like this? In this section, we will be using VERITAS NetBackup as the backup tool for the illustrations, but practically speaking, the concepts you discover within this chapter can be applied to most other solutions on the market as well. A word of advice before we jump into this section of the chapter: Unless there is a compelling reason for additional server resources, maintain the existing environment for as long as you can to minimize its complexity.

For example, one of our clients who was using VERITAS NetBackup had a decision to make with regard to their expanding environment. They had two buildings-for the sake of this illustration, let's call them building A and building B-6 miles apart, with a fairly equal amount of data in each data center. Both buildings had a large-capacity tape silo and dark fibre between the buildings-although the dark fibre was yet to be implemented-as well as a 2-GB network pipe currently in use for connectivity. They knew they wanted to expand into building B; the decision before them was whether to add another primary backup server or a secondary server within the current primary domain. The other challenge presenting itself was a request from the business to readdress the architecture to meet their new data requirements.

The business unit managers made it known that they wanted their data secured off-site as close to the completion of the backup jobs as possible. This seemed like an unrealistic expectation given that most off-site vendors typically operate during normal business hours for pickup and delivery, unless you pay a premium. We did some personal research to see what an off-site vendor would charge for that type of service, just in case the client asked for any input on the matter. If memory serves correctly, the expense outweighed the benefit. They decided to look at other options, such as using the two buildings 6 miles apart to move data during backup to an 'off-site' staging facility.

One of the options would consist of placing a media server in building B within the domain of the NetBackup master server in building A. The media server in building B would back up the data in the same building, then a copy would be created to be taken off-site.

Note 

A NetBackup master server manages the who, what, where, when, and why of the backup polices. A backup server under the control of a NetBackup master server is called a media server, which is any NetBackup server having management control over physical storage devices, such as tapes, tape drives, optical drives, robotic control, and robotic management. The media server will respond to requests from the NetBackup master server for tape mounts and optical mounts, and it tracks the physical condition and location of all the media.

The architecture of this expansion takes on a new perspective, since this client was using VERITAS NetBackup Version 3.4, which does not support the pooling of the logical storage or storage units (called storage unit groups in Version 4.5).

Note 

Had the client deployed NetBackup Version 4.5, they could have used storage unit groups to contain the data to a geographic location. For example, if all the data in building B had to be backed up to building A, a storage unit group could have been created containing all of building A's storage units. Then all they would have had to do is modify the backup policies to use the storage unit group versus the single storage unit. If you find yourself running into this situation, you should consider an upgrade to Version 4.5.

So this would mean that all backup policies for building B would have to specifically request the storage unit in building B. If building B never grows beyond its current size, this would work out beautifully, but as we know, data grows, so eventually they would have had to expand with yet another media server in building B. Then the complexity of this solution under NetBackup Version 3.4 increases and becomes much more difficult to manage.

In this scenario, the administrator would basically be required to 'balance' the backup policies between the storage units. However, this didn't meet the original expectations of the business unit managers, who wanted to have their data off-site as soon after the backup as possible. The idea of a cross-building backup was introduced; again, this would have worked well with NetBackup Version 4.5, using the storage unit groups.

Now we were starting to see the complexity of having to manage 40 or more backup policies and balance them properly among the storage units between buildings, as a result of the limited functionality of pre-4.5 NetBackup. If ever there were a compelling reason to upgrade to the latest version of software, this is one of them. If you choose 'Any Available Storage Unit' in your backup policy, NetBackup will, in a round-robin fashion, select any available storage unit not defined as demand only (meaning only backup policies that specifically demand this storage unit may use it). If all of the storage units are available for use by the Any Available Storage Unit attribute, it very well means that data we want backed up to the other building might end up locally backed up.

You can start to see more complexity building up now. This is all a part of being a storage architect: planning based on customer expectations and working through all of the possible scenarios to come to a reasonable solution. This particular scenario proved to be the wrong solution for this environment, given the customer's desire to remain at the current version.

The second option explored was creating a completely separate NetBackup master server domain in building B. This would allow cross-building backup and effectively meet the expectations of the business unit managers. The storage units could be created to be used by any backup policy, so no 'over-administration' would be required for the backup policies; the backup from building A to building B could happen without issue.

All of the issues that were uncovered when reviewing the additional Media Server would have been addressed by either upgrading to NetBackup Version 4.5 or by continuing with NetBackup 3.4 and deploying the second master server. A higher priority was given to bringing building B online without an upgrade, but an upgrade was planned for some time next year during phase III of the architecture plan.

If you go this route, you have two catalogs to back up and ensure are working properly, two separate client configuration files to maintain, two separate global configuration policies to maintain, two separate backup policies, media databases, and the list goes on. However, this was the best solution given what the customer was interested in doing.

The question of when to divide into multiple backup servers is clearly answered by two words: It depends. It depends on what your environment, the customers, and your business are willing to tolerate. Remember, change for the sake of change only adds potentially unnecessary complexity to our already busy schedules as storage administrators.

Tip 

Identify those compelling reasons for change, decide if the benefit outweighs the pains of change, then plan your work and work your plan.

Advantages and Disadvantages of the Great Divide

There are advantages and disadvantages in any choices we make. For instance, consider the purchase of a new vehicle. You want more seating capacity-the advantage-but find that a larger vehicle requires more fuel to operate-the disadvantage. Further, the advantage may even become a disadvantage. For instance, now that you have more seating capacity, you find that you have become the de facto chauffeur whenever you have those large group lunch outings.

You can come up with many reasons why or why not to divide your configuration into multiple server domains. In the following, we outline some advantages and disadvantages of using a single backup server or master and multiple backup servers or masters:

Lone-Server Advantages

The benefits of keeping a single master include having a single point of control, configuration, and backup image catalog repository. This doesn't sound like much when you are only talking about two servers, one master and one media. However, if you have one master and 22 media servers, it clearly minimizes the complexity of the environment.

Single Point of Administration

There is one location to manage all of the servers within the domain. This includes all of the policy control, job control, device control, and media control. While additional server resources will add some complexity to your environment, having a single point of administrative control will minimize the management effort.

Central Catalog Repository

The image catalog for VERITAS NetBackup typically will be the largest of all the catalogs that it manages, and it is a very critical piece of the puzzle when recovering client data. Having only one master means there is only one location for the image catalog which means there is only one catalog to back up.

Central Configuration Control

Backup policy changes or global configuration changes are made at one server for all of the backup servers within the domain. Again, if we are speaking of two or three servers, this might not sound that terrible, but when the number reaches 22, you then start to see the benefit of a single primary or master server.

Storage Access

With the additional device servers or media servers, there exist more storage devices to be used during the backup process and a sharing of the backup workload across all backup servers. If the reason for the expansion was performance related, this might help to increase the aggregate throughput of the backup jobs.

Minimize Complexity

Simpler is better. You are less likely to have a misunderstanding with some of the more junior members of the administration staff, or even the more senior members. A single-master approach also minimizes the site documentation that needs to be developed and maintained, which we know can be tedious work.

Scalability

At least with NetBackup, its strength is in its scalability; it can transition from a small to medium-size site with one server acting as both master and media server to an environment with multiple media servers protecting the enterprise and all being controlled by one master server.

Lone-Server Disadvantages

The disadvantage of having a single master server is also one of the advantages we listed previously: central repository of the image catalog and central configuration control. Some people find this to be a disadvantage because it means a single point of failure. If you are running 22 servers and lose the master server, you have lost the control center for all scheduling of backups, whether or not you are using NetBackup's scheduler. Plus you have lost all possibility of restoring any data until you recover this failed resource. Yes, you do have the option of recovering data from the NetBackup tapes independent of having a NetBackup server, since NetBackup writes in a TAR-compatible format, but in reality, we know of very few people who choose this method of recovery. Therefore, if this backup server is considered critical and must be highly available, perhaps installing clustering software like VERITAS Cluster Server, IBM HACMP, or similar tools would be a benefit.

Single Point of Failure

Once we lose the master server, all backup, restore, and duplication possibilities are lost until this server is recovered and returned to an online status. This adds cost to the total cost of ownership, since we would have to purchase some clustering software to eliminate this disadvantage. Note that if you do elect to use VERITAS Cluster Server (VCS) or some other High Availability (HA) tool, you must not only failover the application if it is a master server, but you must failover the device control if it is also a media server. Figure 9.5 depicts a master server only, with no robotic or physical device control whatsoever, with VCS configured in an active-passive role. This, in our opinion, is the best approach when attempting to make NetBackup a highly available service, but also adds a higher cost of ownership.

click to expand
Figure 9.5: Active-passive master server solution.

Central Catalog Repository

Depending on the environment, this may look like a disadvantage. If the intention of the architecture was to protect against facility loss, then having this centrally located for all client backups may be a disadvantage if you do not have the additional software necessary to protect you from this facility loss. However, if you are backing up data from building A to building B and lose building A, you still have a master server in building B. If you further set up building A to write its catalog backup to building B, you could restore data for building A clients with some minor configuration changes. It is a bit confusing, but on a white board, it becomes very impressive and shows the power and flexibility of the solution. Figure 9.6 illustrates the architecture. Each building is performing its own local catalog backup to disk; then by design, each server is backing up the opposite building's, A to B and B to A. Therefore, when the backup of master A is done to building B, master A's local catalog backup is protected in the process.

Complexity

The following may add much more complexity to your environment:

  • Multiple catalog backups

  • Client configuration files

  • Backup policies to create and maintain

  • Multiple points of monitoring, reporting, troubleshooting, and so on

  • Necessity to create and maintain a balance in the distribution of data because of the limitations of the existing product (i.e., NetBackup Version 3.4)

Multiple-Server Advantages

No doubt the format for the information in the next two sections is becoming very evident. Once again, where there are disadvantages in one environment, there are advantages to another. So let's take some time to briefly outline the advantages of having multiple master servers.

click to expand
Figure 9.6: Two-master server configuration.

Multiple Points of Recovery

As in the example given, if the master domains are backing up one another's data, as well as backing up the NetBackup Catalog information across buildings, then you potentially have built a much more resilient backup architecture, because you now have multiple points of recovery within your enterprise. If you are in a similar situation as described in this chapter-two buildings roughly 6 miles apart on separate power grids, with one of the buildings being used for an off-site staging area-in the event of a full facility disaster, either of the buildings could be used for a recovery site. For instance, if you lose building A for a considerable amount of time, but building B is still online, what you have lost in the midst of this disaster is the backup service for building B; however, you have all of building A's data at the ready to be restored to any server the administration team requires in order to restore the business. If building B has the necessary hardware, a quick configuration change could be made to the client files in order to successfully back up and protect its own data.

Independent Scalability

As in the previous examples, NetBackup can scale as needed with additional device servers or media servers. Having two masters allows that to happen based on the environments independent of one another. An argument could be made saying that if you had one master, you would still be able to scale the environments independent of one another. That is true, but independent scaling goes beyond just adding more device servers; it also speaks to the ability to globally configure each of the buildings differently as it is required by an SLA or other service-level mechanism that your company may have enacted.

Secured Segregation

What does secured segregation mean? Well, simply put, the two buildings are completely and totally separated, each having its own set of security rights managed by perhaps two completely different management groups. In the examples that have been given thus far, it would not make sense to segregate the rights of the administrators between buildings, but there might be a compelling reason to do so. For instance, you might have two administration teams within your company, a corporate team and a regional team. In some companies that we have consulted with, this definite division exists, so having multiple master servers fulfills the requirement nicely here, since the two groups have completely different data protection strategies, security policies, schedules, and so on.

Multiple-Master Disadvantages

Finally, in this section, we cover the last point of when to divide backup servers. We have read about the advantages and disadvantages of single backup servers and the advantage of multiple backup servers. We have simply listed bullets of the disadvantages of having multiple backup servers here, since most of the advantages and disadvantages are similar whether you are using multiple or single backup servers.

  • Twice as much administration

  • Multiple points of administration

  • Configuration management

  • Catalog management

  • Much more complexity

Most people design their backup environment with one goal in mind: to back up the data as efficiently and quickly as possible. Others, however, design their backup environments to include the newest technology toys. We're not against the fancy toys, but we are against unnecessary complexity and wasteful resources that eventually lead to an environment that is struggling to meet the service level agreements that your group has made with the business. Backup is a critical service, probably the most important role in the company next to that of the visionaries who create the future for the company. After all, backup protects these visionaries' intellectual property, and without it, we risk losing all of that precious data. Minimize your exposure by architecting a solid backup solution, but do it in a way that makes the management of that environment feasible for everyone who will have any responsibility within the environment.

Note 

Service-level agreements are typically used to define performance expectations for a given service between the customer and the provider. Some companies use this for internal purposes to track performance of the various computing solutions offered to the business units. In this respect, the SLA would be between the IT group or the provider and the business unit or customers. For this reason, it is very important that you properly manage the expectations for backup and recovery from the very beginning.

The bottom line for the customer in the two building illustration: it was best to deploy two masters because of the WAN in the middle. When the WAN goes down, you essentially have lost all communication to the other facility, so if all you had was a media server in building B, you would be effectively down until the WAN was fixed. They too would be in dire straits if the WAN went down, based on their desire to back up between facilities, but it was a risk they were willing to take since they had redundant network links by different providers between buildings.



 < Day Day Up > 



Implementing Backup and Recovery(c) The Readiness Guide for the Enterprise
Implementing Backup and Recovery: The Readiness Guide for the Enterprise
ISBN: 0471227145
EAN: 2147483647
Year: 2005
Pages: 176

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net