|
Hmmm, I guess I'm wondering a little bit by what you mean by external RAID controller. External to what? I'll try to answer as best I can with what I have to go on and you can ask again if you want.
For starters, virtualization can be done almost anywhere along the I/O path from the volume manager, through the device driver, in adapter firmware in a SAN appliance and down into the subsystem controller. There's a lot of hype behind doing it in a SAN appliance right now, but I have concerns about the recoverability of such installations and the complexity of layering virtualization translations.
An appliance is a stand-alone unit that is external to hosts and subsystems. In fact, it is functionally between them. It can take the total available logical block address spaces available to it and present it in almost any fashion to "upstream" hosts. This can be as multiple LUNs or as a single LUN or, even as multiple targets - depending on the number of SAN ports in the appliance. Appliances can work with individual drives (in a JBOD cabinet for instance) or with exported storage from a subsystem. However, it cannot manage the individual disk drives within a storage subsystem because the appliance only sees what the subsystem exports.
The block address translation and RAID functions are performed in the virtualization appliance as opposed to the host. This means the appliance has to be able to read in transmitted frames, interpret them and resend them to downstream storage. There can be a lot of communications to keep track of that are outside of the normal way of working. All this reading, writing and accounting for I/O activities is a potential performance bottleneck and certainly adds latency to I/O processing. Generally not a problem except with database access. Appliances can provide cache, but it needs to be pointed out that this is not file system cache and results and mileage of an appliance cache will vary by application. Care needs to be taken that writes into the cache will not be lost during a system failure. That's harder to do than just saying it.
Host systems can be completely faked out by virtualization in a way that could potentially make it difficult to recover following a disaster. It is essential that the virtualization data in the appliance be stored in non-volatile storage as well as being able to be backed up and restored. In general, backup and recovery of appliances is a little dicier than it is for systems.
A device driver/RAID controller in a host can do all the same things - except that it is limited to providing it to the host system where it is installed. Such adapters are often used to provide RAID functionality with JBOD disk subsystems. The block address translation is performed by the host CPU, which can potentially impact a CPU-bound system. Host memory caching is usually the most efficient way to cache, but again -writes need to be accounted for.
Configuration information in the RAID controller must also be stored persistently and with backup protection. This might be done through driver config files that are backed up along with all the other stuff in the file system. But no assumptions should be made and full functionality needs to be checked.
Finally a RAID controller can be in a storage subsystem. All virtual storage can be theoretically accessed by multiple servers. In a disk subsystem, the controller can access individual drives for whatever management purposes. This approach has some advantages for write caching, although the effectiveness of storing level cache is variable, the same as it is for the appliance version.
Persistent config info and backup are still an issue same as the others.
Hope this helps, I'm out of space and time.
|
