Nexenta had some "issue" reports relating to
the mpt driver. In almost all cases, the results are related to situations
where people are using SATA drives, and hooking them into SAS configurations.
Although the technology is supposed to work, and
sometimes it works well, its a bad idea.
- SAS
drives are generally subjected to more rigorous quality controls. This is
the main reason why they cost more. (That and the market will pay more.)
- SAS to
SATA conversion technologies involve a significant level of protocol
conversion. While the electricals may be the same, the protocols are quite
different.
- Such
conversion technology is generally done in hardware, where only the
hardware manufacturer has a chance of debugging problems when they occur.
- Some of
these hardware implementations remove debugging information that would be
present in the SATA packet, and just supply "generic"
undebuggable data in the SCSI (SAS) error return.
- The
conversion technology creates another potential point of failure.
- SATA is single
ported and SAS is dual ported, so if you want to use SATA drives in a High
Available, multipathed system, you need something to translate between a
single port and dual port, a so called "interposer". Interposers
are very sensitive to errors and interference
- Nexenta has verified that SAS/SATA expanders
combined with high loads of ZFS activity have proven conclusively to be
highly toxic.
- Some of
these hardware implementations won't be upgradeable, or at least not
easily upgradeable, with software.
- SATA
drives won't have a SCSI GUID (ATA specs don't require it), and so the
fabricated GUID (created by the SAS converter) may be different when you
move the drive to a different chassis, potentially breaking things that
rely on having a stable GUID for the drive.
SATA drives are great when you need low cost storage,
and when you are connecting to a system that is purely SATA (such as to an AHCI
controller), there is no reason to be concerned. But if you're designing an enterprise storage solution, please consider
using SAS all the way to the disk drives, and just skip those cheaper SATA
options. You may think SATA looks like a bargain, but when your array goes
offline during ZFS scrub or resilver operations because the expander is choking
on cache sync commands, you'll really wish you had spent the extra cash up
front.
Building a system that relies upon complex protocol
conversion in hardware, just adds another level of complexity. And complexity
is evil. (KISS). Nexenta advises strongly to spring for the extra cost of
drives that are natively SAS. Goofing around with the hybrid SAS/SATA options
is just penny wise, and pound foolish. Everything is standardized on SAS. So would you rather
have SAS all the way to the disk or SAS all the way and then a have a translation
on the SATA disk?
And effectively SATA and SAS have the same price because if you use SATA
on an enterprise storage system, you need interposers which have a cost price
as well
SATA$ + Interposer$
= SAS$
Niciun comentariu:
Trimiteți un comentariu