Designing for RAS
This is the final step in the design process. By now, you should have a fairly clear understanding of what your requirements are, as well as any possible problems with your existing system. Up until now, this book focused mainly on performance because you should make sure any solution you develop can meet your fundamental application requirements. However, properly designing for RAS is just as important, and requires some thought.
Always keep three principles in mind when designing for RAS:
The more RAS you want, the more hardware you must add to the system.
RAS is not just a function of the Sun Fire server, but of your entire site.
Maximizing RAS can decrease performance.
The first point is almost always overlooked. As an example, to effectively use DR, you should add boards in your design beyond those required for your applications. Why? Because otherwise, when the system dynamically reconfigures a board out of the system, it will not have enough resources to run your applications. The system could start paging, or the CPUs could get too busy handling I/O interrupts to do any real work. The requirements you have formed up to this point are the minimum you need for your system.
As for the second point, purchasing redundant power supplies does not benefit you if your site has only a single power grid with no UPS system. RAS is a function of your entire site, not just one server in isolation. As with performance, getting that final 10 percent of reliability out of a site gets exponentially more difficultand costly. Therefore, you should be realistic about both your requirements and expectationsand your ability to fund them.
Third, taking advantage of certain RAS features and methodologies can decrease the performance of your system. For example, if you mirror file systems, for each write the system must now perform two writes, one to each half of the mirror. Some of these effects can be mitigated, for instance by placing the two halves of the mirror on different I/O controllers.2 However, such performance hits can add up, so it is important to realize it is impossible to maximize both RAS and performance.
Uptime Requirements
You were first asked to consider your uptime requirements in Chapter 2, "What are the uptime requirements of the system?" To help answer this question, you can consider the following:
How much time do you have available for planned maintenance?
How long can you afford to be offline during an unplanned downtime?
There are two types of downtimeplanned and unplanned. Planned downtime includes hardware and software upgrades, whereas unplanned downtime includes system crashes and emergency reboots. All computer systems have some amount of downtime; the goal of a good server design is to minimize the impact this downtime has on your organization.
For some organizations, scheduled maintenance is not an issue; the systems undergo heavy usage during the day from employees, so taking the machine down after-hours is a viable solution. Other organizations, however, serve a worldwide audience and can afford little scheduled maintenance due to time zone differences. Also, it is not uncommon to have a mix of different requirements for different systems at a single site. One thing that every organization has in common, though, is the desire to minimize unplanned downtime as much as possible.
There is no reason to differentiate between the two types of downtime, other than to help you come to a conclusion regarding your overall requirements. When you have a good idea of the uptime required for this system, TABLE 1-9 will help you determine what your design should include to ensure that its RAS properties meet your requirements.
NOTE
You should always purchase redundant SCs for a system to ensure availability in the event of a System Controller board failure. Without a functioning System Controller board, none of the domains in a system will work.
TABLE 1-9 RAS Design Decision Table
Allowable downtime |
Your design should include... |
Some |
Redundant fan trays Redundant power supplies and transfer switches3 |
Little |
Redundant CPU/Memory boards DR for CPU/Memory boards Volume management software (such as Solarisª Volume Manager (SVM) or VERITAS Volume Manager (VxVM) |
Very little |
Redundant paths to I/O devices Multipathing software for I/O (such as Multipath I/0 (MPxIO) or VERITAS Dynamic Multipathing (VxDMP) Redundant network connections Multipathing software for networkssuch as Internet protocol multipathing (IPMP) DR for I/O devices and networks |
Almost none |
Multiple instances of fully redundant systems Clustering software (such as Sunª Cluster 3.0) |
NOTE
Even though you can use DR to replace failed components, a critical component failure on a running system (such as a failed CPU) will still cause the system to crash. If you cannot afford this type of downtime, you fit in the almost none category, and should use a clustering product to guard against system failures.
For most organizations, the little downtime category is a good cost/benefit tradeoff. You will have a system that is resilient to failures and, if properly configured, relatively easy to service. You can use DR to add more CPU/Memory boards for increased capacity, or to replace failed components.
Make a note of what category your system fits into, as well as the additional components you will need. You are going to use this in the next chapter to design your system. You will also use it later in the book during the discussion on configuring the system to integrate with your site.
Finally, some closing words on RAS. It is very important that you do not sacrifice parts of your required configuration for additional RAS features. For example, do not decide to buy less memory so that you can afford additional fan trays. You should ensure that your base requirements are met, or else you will not benefit from additional RAS because your system will have fundamental shortcomings.Disk Redundancy and RAID Basics
To ensure the integrity of the data, some type of disk redundancy should be used on any system with important local data storage. The different schemes for achieving such redundancy are often denoted by their RAID level. The term RAID comes from Redundant Array of Inexpensive Disks, and there are numbers from 0 all the way up through 53 denoting different ways of laying out sets of disks.
For most applications, however, only three RAID levels are useful: 0, 1, and 5. Each of these allow you to combine multiple physical disks into a single logical volume. The operating system then sees this volume just like a normal disk, and it can be mounted and used in the regular manner.
RAID 0
RAID 0, commonly called striping, provides no additional data safety. Instead, it is designed to increase the speed of file system access. With striping, disks in a volume are interleaved at a certain data interval, called the stripe unit size. This means that when reading or writing data, multiple disks are accessed in parallel, decreasing the amount of time it takes to access the data. Striping is very common on any system that needs fast data access, such as database servers.
RAID 1
RAID 1, also referred to as mirroring, is just the reverse. It provides full data redundancy, but with some performance costs. In mirroring, twice the number of disks are used for the data that needs to be stored. These disks are then arranged in pairs, and identical data is stored on both disks. On a file system write, two physical writes must be performed, one to each disk of the pair. The advantage is you now have two complete copies of your data.
This means you can lose half of your disks and still continue running without data loss. In a large volume, this is obviously an advantage.
RAID 0+1
RAID 0+1, usually called striping and mirroring, is a combination of these two techniques. In a striped/mirrored volume, a set of disks is striped together to form each half. Then, these two halves are mirrored to one another. It is possible to design a striped/mirrored volume so that the performance is better than the individual disks (due to striping), and that fully half the disks can fail without impacting the volume (due to mirroring). This technique is widely-used in production systems.
RAID 1+0
RAID 1+0 is very similar to RAID 0+1, except the volumes are assembled in the reverse order. Here, pairs of disks are mirrored to one another, and then these mirrored pairs are striped together. Volumes created in this manner are slightly more complicated to manage, but are slightly more reliable because of the ways in which disks typically fail. Generally, vendors decide to implement either RAID 0+1 or RAID 1+0, but not both, so the choice of which to use is often made for you.
RAID 5
Finally, RAID 5 is one of the most economical forms of redundancy. In this scheme, a portion of each disk in a volume is used to hold parity. On a write, data is distributed across all the disks in the volume except one, with the parity being written to the remaining disk. This process is repeated in a "round robin" fashion, so that each write places the parity for that write on a different disk. In the event of a single disk failure, the parity is used to recreate data that was on the failed disk. This allows you to lose a single disk (the most common type of failure) and continue running without interruption. RAID 5 is somewhat slow, though, since it must perform all those additional writes for the parity.
While RAID 5 is not as reliable as RAID 0+1 (striping and mirroring), it can still be a good solution, especially for NFS servers. While you can only lose one disk, it is uncommon to lose a whole enclosure barring human error or a power failure, both of which will probably affect much more than your disks. To make use of RAID 5, you should consider only those enclosures that support hardware RAID, since otherwise it is too slow for many applications.
Once you have selected what type of RAID you wish to use for each of your different volumes, you should adjust your storage purchase accordingly. For example, if you want to mirror a set of data, you must purchase double the amount of disk you calculated above. You will need to make sure to increase your controller cards as well.
With RAID 5, check the enclosure you are considering purchasing to verify that it supports hardware RAID.