Databases Reference
In-Depth Information
be much better utilized in a SAN, that can come at the cost of many other systems
being underutilized (the database server spends a lot of time waiting for I/O, the
application server spends a lot of time waiting for the database, and so on). We've
seen many real-world opportunities to consolidate servers and cut costs by
decen-
tralizing
storage.
High availability
Sometimes people think of a SAN as a high-availability solution. We'll suggest in
Chapter 12
that this could be due to disagreement over what high availability really
means.
In our experience, SANs are pretty frequently implicated in failures and downtime.
This is not because they are unreliable—which they aren't—but because people
are reluctant to believe such a miracle of engineering can actually fail. In addition,
a SAN is sometimes a complex, mystifying black box that nobody knows how to
troubleshoot when something goes wrong, and it can be expensive and difficult to
build the expertise needed to manage a SAN well. The lack of visibility into most
SANs is why you should never simply trust the SAN administrator, support staff,
or management console. We've seen cases where all three are wrong, and the SAN
turned out to have a problem such as a failed hard drive that was causing degraded
performance.
10
This is another reason to get comfortable with
sysbench
: so you
can dash off an I/O benchmark to prove or disprove the SAN's culpability.
Interaction between servers
Shared storage can cause seemingly independent systems to affect each other,
sometimes very badly. For example, one SAN user we know had a rather rude
awakening when an I/O-intensive operation on a development server caused his
database server to grind nearly to a halt. Batch jobs,
ALTER TABLE
, backups—
anything that causes a lot of I/O on one system can cause starvation on other
systems. Sometimes the impact is much worse than your intuition would suggest;
a seemingly trivial workload can cause a surprisingly severe degradation of
performance.
Cost
Cost of what? Cost of management and administration? Cost per I/O operation
per second (IOPS)? Sticker price?
There are good reasons to use SANs, but regardless of what the salespeople say,
performance—at least, performance of the type that MySQL needs—just isn't a
valid reason. (Pick a SAN vendor and call a salesperson, and you're likely to
hear them agree in general, but then tell you that their product is an exception to
the rule.) If you consider performance and price together, it becomes even clearer,
because if it's a good price-to-performance ratio you want, flash storage or
10. The web-based SAN management console insisted that all hard drives were healthy—until we asked the
administrator to press Shift-F5 to disable his browser cache and force the console to refresh!
