In the previous chapter, I disc ussed the impact of sprawl in a SQL Server infrastructure.
Basically, my conclusion was that traditional SQL Server architectural techniques, along with a
number of business factors (suc h as political factors) seem to make SQL Server sprawl
inevitable. The result is a highly unoptimized infrastructure, where copious amounts of unused
resources exist but which cannot be easily deployed to help fill any need. That is, if you take a
look at your infrastructure as a whole, you proba bly have lots of unused storage, processor
capacity, and so forth, but you’re not necessarily free to “move” unused resources from one area
to cover a shortage in another. Your resources are inflexible, tied to individual servers, which are
often handling a very specific workload.
This chapter looks a bit harder at why things turn out this way, from a SQL Server technical
viewpoint, and explores some of the ways the industry has tried to solve the problem. Remember
that the ultimate goal is to cr eate an infrastructure that’s dynamic according to the Microsoft
Infrastructure Optimization Model (IOM)—capable of changing smoothly and quickly to meet
business needs, and in fact designed to accommodate rapid changes.
No comments:
Post a Comment