Exercise Summary

Exercise Summary

As you can tell, designing a technology solution to meet all of your requirements optimally is by no means straightforward or easy. You will win some battles and lose others. In the end, there is no absolutely correct architecture because trade-offs will have to be made for one reason or another. In this case, you sacrificed a whole testing environment and disaster recovery site, but you got basically the architecture you needed from a production standpoint. Not having a proper test system could introduce risk into your production system because you will not know how it will behave under load, meaning you do not know what to monitor (among other things). Not having the disaster recovery system leaves you greatly exposed from an availability standpoint. Throughout this book, the ability to test for load is highlighted as a crucial factor.

In terms of your disk subsystem, you did not really sacrifice disk performance in going from the larger disks to the smaller ones. Most people prefer smaller, faster disks. The problem you now face is that you intended to use some combination of mirroring and striping but only did so on your OLTP data, exposing your system databases to a potential availability problem or tempdb performance problem. Not having the testing environment hardware is starting to come into play. Because of the sheer number of disks (97) now involved in your solution, you need to stock spare drives to be used at a moments notice. Your risk exposure on the OLTP disks is less than, say, your system databases, but if enough drives fail, an entire LUN could fail. You could experience the impact of making trade-offs.

Unfortunately, cost always has to be addressed in the trade-off mix of cost, performance, growth, and availability. It is not easy to achieve all of those while staying at or under budget. In fact, most people do not have a $500,000 budget for just the database portion of the hardware; the budget might be for all servers or ( worse ) the budget might be even smaller! This example was designed to show you how difficult it is with a lot of money, let alone a smaller budget. People tend to suggest ideal architectures, start to design maintenance plans and applications, and then find that the business cannot afford their awesome solution, so they have to go back to the beginning and plan everythingagain. Not only did you waste the days, weeks, or months already put into the project, but your project end date probably did not change. That means that you will have less time to deliver. In this example, you saw very quickly that the desire for performance, growth, availability, and scalability did not fit your budget.

Remember to do checks, both real and in your head, during the entire process. Some questions you can ask are listed below; there will be more that are project specific. Hold regular meetings to make sure everyone is in agreement that the solution is right.

• Does the architecture seem sound? What are the potential flaws?

• Is the solution you designed supportable or is it too complex? Is it flexible and scalable? Or is it too rigid, and will it be outdated within the proposed life span of the hardware?

• {% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

  Does the solution meet the availability requirement? Are there any risks or points of exposure?

• Does the solution fit the budget, or does there need to be some compromise? If so, where would you make trade-offs? Consider questions like these:

  • Where would you place the most memory or processors?

  • Are you valuing performance over availability?

• Do you design a base level of hardware first and build from there?

• Did you consider special requirements such as the quorum disk or domain connectivity if you are using a cluster?

Similar products