Disk array controller: Difference between revisions
Citation bot (talk | contribs) Add: date, title. Changed bare reference to CS1/2. | Use this bot. Report bugs. | Suggested by BrownHairedGirl | Linked from User:BrownHairedGirl/Articles_with_bare_links | #UCB_webform_linked 881/2185 |
m Added non-breaking space to non-template file size, bitrate, and bandwidth values (via WP:JWB) |
||
(16 intermediate revisions by 12 users not shown) | |||
Line 1: | Line 1: | ||
{{Short description|Device that manages disk drives}} |
|||
A '''disk array controller''' is a device that manages the physical [[disk drives]] and presents them to the computer as [[Logical Unit Number|logical units]]. It almost always implements [[RAID#Hardware-based|hardware]] [[RAID]], thus it is sometimes referred to as '''RAID controller'''. It also often provides additional disk [[cache (computing)|cache]]. |
A '''disk array controller''' is a device that manages the physical [[disk drives]] and presents them to the computer as [[Logical Unit Number|logical units]]. It almost always implements [[RAID#Hardware-based|hardware]] [[RAID]], thus it is sometimes referred to as '''RAID controller'''. It also often provides additional disk [[cache (computing)|cache]]. |
||
''Disk array controller'' is often |
''Disk array controller'' is often ambiguously shortened to ''[[disk controller]]'' which can also refer to the circuitry responsible for managing internal disk drive operations. |
||
== Front-end and back-end side == |
== Front-end and back-end side == |
||
A disk array controller provides front-end interfaces and back-end interfaces. |
A disk array controller provides front-end interfaces and back-end interfaces. |
||
* |
* The back-end interface communicates with the controlled disks. Hence, its protocol is usually [[Advanced Technology Attachment|ATA]] (a.k.a. PATA), [[Serial ATA|SATA]], [[SCSI]], [[Fibre Channel|FC]] or [[Serial Attached SCSI|SAS]]. |
||
* |
* The front-end interface communicates with a computer's [[host adapter]] (HBA, Host Bus Adapter) and uses: |
||
** one of ATA, SATA, SCSI, FC; these are popular protocols used by disks, so by using one of them a controller may transparently [[emulator|emulate]] a disk for a computer |
** one of ATA, SATA, SCSI, FC; these are popular protocols used by disks, so by using one of them a controller may transparently [[emulator|emulate]] a disk for a computer. |
||
** somewhat less popular |
** somewhat less popular dedicated protocols for specific solutions: [[FICON]]/[[ESCON]], [[iSCSI]], [[HyperSCSI]], [[ATA over Ethernet]] or [[InfiniBand]]. |
||
A single controller ''may'' use different protocols for back-end and for front-end communication. Many enterprise controllers use FC on front-end and SATA on back-end. |
A single controller ''may'' use different protocols for back-end and for front-end communication. Many enterprise controllers use FC on front-end and SATA on back-end. |
||
Line 29: | Line 31: | ||
== Simple controllers == |
== Simple controllers == |
||
[[Image:Promise Ultra33.jpg|thumb|250px| |
[[Image:Promise Ultra33.jpg|thumb|250px|Promise Technology ATA RAID controller]] |
||
A simple disk array controller may fit inside a computer, either as a [[Peripheral Component Interconnect|PCI]] [[expansion card]] or just built onto a [[motherboard]]. Such a controller usually provides [[Host adapter|host bus adapter]] (HBA) functionality itself to save physical space. Hence it is sometimes called a '''RAID adapter'''. |
A simple disk array controller may fit inside a computer, either as a [[Peripheral Component Interconnect|PCI]] [[expansion card]] or just built onto a [[motherboard]]. Such a controller usually provides [[Host adapter|host bus adapter]] (HBA) functionality itself to save physical space. Hence it is sometimes called a '''RAID adapter'''. |
||
{{As of | 2007 | February }} [[Intel]] started integrating their own [[Intel Matrix RAID|Matrix RAID controller]] in their more upmarket motherboards, giving control over 4 devices and an additional 2 SATA connectors, and totalling 6 SATA connections ( |
{{As of | 2007 | February }} [[Intel]] started integrating their own [[Intel Matrix RAID|Matrix RAID controller]] in their more upmarket motherboards, giving control over 4 devices and an additional 2 SATA connectors, and totalling 6 SATA connections (3 Gbit/s each). For backward compatibility one IDE connector able to connect 2 ATA devices (100 Mbit/s) is also present. |
||
=== History === |
=== History === |
||
Line 40: | Line 42: | ||
Around 1997, with the introduction of [[Atapi|ATAPI-4]] (and thus the [[Direct memory access|Ultra-DMA-Mode 0]], which enabled fast data-transfers with less [[CPU]] utilization) the first ATA RAID controllers were introduced as PCI expansion cards. Those RAID systems made their way to the consumer market, where the users wanted the fault-tolerance of RAID without investing in expensive SCSI drives. |
Around 1997, with the introduction of [[Atapi|ATAPI-4]] (and thus the [[Direct memory access|Ultra-DMA-Mode 0]], which enabled fast data-transfers with less [[CPU]] utilization) the first ATA RAID controllers were introduced as PCI expansion cards. Those RAID systems made their way to the consumer market, where the users wanted the fault-tolerance of RAID without investing in expensive SCSI drives. |
||
ATA drives make it possible to build RAID systems at lower cost than with SCSI, but most ATA RAID controllers lack a dedicated buffer or high-performance XOR hardware for parity calculation. |
ATA drives make it possible to build RAID systems at lower cost than with SCSI, but most ATA RAID controllers lack a dedicated buffer or high-performance XOR hardware for parity calculation. As a result, ATA RAID performs relatively poorly compared to most SCSI RAID controllers. Additionally, data safety suffers if there is no [[Battery (electricity)|battery]] backup to finish writes interrupted by a power outage. |
||
==OS support== |
==OS support== |
||
Because the hardware RAID controllers present assembled [[RAID]] volumes, [[operating system]]s aren't strictly required to implement the complete configuration and assembly for each controller. |
Because the hardware RAID controllers present assembled [[RAID]] volumes, [[operating system]]s aren't strictly required to implement the complete configuration and assembly for each controller. Very often only the basic features are implemented in the [[open-source software]] driver, with extended features being provided through [[binary blob]]s directly by the hardware manufacturer. |
||
Normally, RAID controllers can be fully configured through card [[BIOS]] before an [[operating system]] is booted, and after the operating system is booted, [[proprietary software|proprietary]] configuration utilities are available from the manufacturer of each controller, because the exact feature set of each controller may be specific to each manufacturer and product. |
Normally, RAID controllers can be fully configured through card [[BIOS]] before an [[operating system]] is booted, and after the operating system is booted, [[proprietary software|proprietary]] configuration utilities are available from the manufacturer of each controller, because the exact feature set of each controller may be specific to each manufacturer and product. |
||
Unlike the [[network interface controller]]s for [[Ethernet]], which can be usually be configured and serviced entirely through the common operating system paradigms like [[ifconfig]] in [[Unix]], without a need for any third-party tools, each manufacturer of each RAID controller usually provides their own proprietary software tooling for each operating system that they deem to support, ensuring a [[vendor lock-in]], and contributing to reliability issues.{{r|lyrics-38}} |
Unlike the [[network interface controller]]s for [[Ethernet]], which can be usually be configured and serviced entirely through the common operating system paradigms like [[ifconfig]] in [[Unix]], without a need for any third-party tools, each manufacturer of each RAID controller usually provides their own proprietary software tooling for each operating system that they deem to support, ensuring a [[vendor lock-in]], and contributing to reliability issues.{{r|lyrics-38}} |
||
For example, in [[FreeBSD]], in order to access the configuration of [[Adaptec]] RAID controllers, users are required to enable [[FreeBSD#OS compatibility layers|Linux compatibility layer]], and use the Linux tooling from Adaptec,{{r|f-aac}} potentially compromising the stability, reliability and security of their setup, especially when taking the |
For example, in [[FreeBSD]], in order to access the configuration of [[Adaptec]] RAID controllers, users are required to enable [[FreeBSD#OS compatibility layers|Linux compatibility layer]], and use the Linux tooling from Adaptec,{{r|f-aac}} potentially compromising the stability, reliability and security of their setup, especially when taking the long term view in mind.{{r|lyrics-38}} However, this greatly depends on the controller, and whether appropriate hardware documentation is available in order to write a driver, and some controllers do have open-source versions of their configuration utilities, for example, <code>mfiutil</code> and <code>mptutil</code> is available for FreeBSD since FreeBSD 8.0 (2009),{{r|mfiutil|mptutil}} as well as <code>mpsutil</code>/<code>mprutil</code> since 2015,{{r|mpsutil}} each supporting only their respective device drivers, this latter fact contributing to [[code bloat]]. |
||
Some other operating systems have implemented their own generic frameworks for interfacing with any RAID controller, and provide tools for monitoring RAID volume status, as well as facilitation of drive identification through LED blinking, alarm management, [[hot spare disk]] designations and {{section link|data scrubbing#RAID}} from within the operating system without having to reboot into card BIOS. |
Some other operating systems have implemented their own generic frameworks for interfacing with any RAID controller, and provide tools for monitoring RAID volume status, as well as facilitation of drive identification through LED blinking, alarm management, [[hot spare disk]] designations and {{section link|data scrubbing#RAID}} from within the operating system without having to reboot into card BIOS. For example, this was the approach taken by [[OpenBSD]] in 2005 with its [[bio(4)]] [[pseudo-device]] driver and the [[bioctl]] utility, which provide volume status, and allow LED/alarm/hotspare control, as well as the sensors (including the [[hw.sensors#drive|drive sensor]]) for health monitoring;<ref name=theo-misc-38/> this approach has subsequently been adopted and extended by [[NetBSD]] in 2007 as well.{{r|sensors-mmath}} |
||
With [[bioctl]], the feature set is intentionally kept to a minimum, so that each controller can be supported by the tool in the same way; the initial configuration of the controller is meant to be performed through card BIOS,{{r|theo-misc-38}} but after the initial configuration, all day-to-day monitoring and repair should be possible with unified and generic tools, which is what |
With [[bioctl]], the feature set is intentionally kept to a minimum, so that each controller can be supported by the tool in the same way; the initial configuration of the controller is meant to be performed through card BIOS,{{r|theo-misc-38}} but after the initial configuration, all day-to-day monitoring and repair should be possible with unified and generic tools, which is what bioctl is set to accomplish. |
||
==References== |
==References== |
||
Line 63: | Line 65: | ||
|website= BSD Cross Reference |publisher= [[FreeBSD]] |
|website= BSD Cross Reference |publisher= [[FreeBSD]] |
||
|author1= Scott Long |author2= Adaptec, Inc |author2-link= Adaptec |date= 2000 |
|author1= Scott Long |author2= Adaptec, Inc |author2-link= Adaptec |date= 2000 |
||
}} |
|||
|lay-url= http://mdoc.su/f/aac.4 |
|||
*{{cite book |section=aac -- Adaptec AdvancedRAID Controller driver |title=FreeBSD Manual Pages |url=http://mdoc.su/f/aac.4}}</ref> |
|||
}}</ref> |
|||
<ref name=mfiutil>{{cite web |
<ref name=mfiutil>{{cite web |
||
Line 71: | Line 73: | ||
|website= BSD Cross Reference |
|website= BSD Cross Reference |
||
|publisher= [[FreeBSD]] |
|publisher= [[FreeBSD]] |
||
}} |
|||
|lay-url= http://mdoc.su/f,d/mfiutil.8 |
|||
*{{cite book |section=mfiutil -- Utility for managing LSI MegaRAID SAS controllers |title=FreeBSD Manual Pages |url=https://www.freebsd.org/cgi/man.cgi?query=mfiutil&sektion=8}}</ref> |
|||
}}</ref> |
|||
<ref name=mpsutil>{{cite web |
<ref name=mpsutil>{{cite web |
||
Line 78: | Line 80: | ||
|title= mpsutil — Utility for managing LSI Fusion-MPT 2/3 controllers |
|title= mpsutil — Utility for managing LSI Fusion-MPT 2/3 controllers |
||
|website= BSD Cross Reference |
|website= BSD Cross Reference |
||
|publisher= |
|publisher= FreeBSD |
||
}} |
|||
|lay-url= http://mdoc.su/f,d/mpsutil.8 |
|||
*{{cite book |section=mpsutil, mprutil -- Utility for managing LSI Fusion-MPT 2/3 controllers |title=FreeBSD Manual Pages |url=https://www.freebsd.org/cgi/man.cgi?query=mpsutil&sektion=8}}</ref> |
|||
}}</ref> |
|||
<ref name=mptutil>{{cite web |
<ref name=mptutil>{{cite web |
||
Line 86: | Line 88: | ||
|title= mptutil — Utility for managing LSI Fusion-MPT controllers |
|title= mptutil — Utility for managing LSI Fusion-MPT controllers |
||
|website= BSD Cross Reference |
|website= BSD Cross Reference |
||
|publisher= |
|publisher= FreeBSD |
||
}} |
|||
|lay-url= http://mdoc.su/f,d/mptutil.8 |
|||
*{{cite book |section=mptutil -- Utility for managing LSI Fusion-MPT controllers |title=FreeBSD Manual Pages |url=https://www.freebsd.org/cgi/man.cgi?query=mptutil&sektion=8}}</ref> |
|||
}}</ref> |
|||
<ref name=lyrics-38>{{cite web |
<ref name=lyrics-38>{{cite web |
||
Line 105: | Line 107: | ||
|date= 2005-09-09 |
|date= 2005-09-09 |
||
|mailing-list= misc@ |
|mailing-list= misc@ |
||
|publisher = |
|publisher = OpenBSD |
||
}}</ref> |
}}</ref> |
||
Line 119: | Line 121: | ||
}} |
}} |
||
{{refbegin}} |
|||
⚫ | |||
{{refend}} |
|||
⚫ | |||
{{FOLDOC}} |
|||
{{RAID}} |
{{RAID}} |
||
Latest revision as of 15:33, 23 April 2024
A disk array controller is a device that manages the physical disk drives and presents them to the computer as logical units. It almost always implements hardware RAID, thus it is sometimes referred to as RAID controller. It also often provides additional disk cache.
Disk array controller is often ambiguously shortened to disk controller which can also refer to the circuitry responsible for managing internal disk drive operations.
Front-end and back-end side
[edit]A disk array controller provides front-end interfaces and back-end interfaces.
- The back-end interface communicates with the controlled disks. Hence, its protocol is usually ATA (a.k.a. PATA), SATA, SCSI, FC or SAS.
- The front-end interface communicates with a computer's host adapter (HBA, Host Bus Adapter) and uses:
- one of ATA, SATA, SCSI, FC; these are popular protocols used by disks, so by using one of them a controller may transparently emulate a disk for a computer.
- somewhat less popular dedicated protocols for specific solutions: FICON/ESCON, iSCSI, HyperSCSI, ATA over Ethernet or InfiniBand.
A single controller may use different protocols for back-end and for front-end communication. Many enterprise controllers use FC on front-end and SATA on back-end.
Enterprise controllers
[edit]In a modern enterprise architecture disk array controllers (sometimes also called storage processors, or SPs[1]) are parts of physically independent enclosures, such as disk arrays placed in a storage area network (SAN) or network-attached storage (NAS) servers.
Those external disk arrays are usually purchased as an integrated subsystem of RAID controllers, disk drives, power supplies, and management software. It is up to controllers to provide advanced functionality (various vendors name these differently):
- Automatic failover to another controller (transparent to computers transmitting data)
- Long-running operations performed without downtime
- Forming a new RAID set
- Reconstructing degraded RAID set (after a disk failure)
- Adding a disk to online RAID set
- Removing a disk from a RAID set (rare functionality)
- Partitioning a RAID set to separate volumes/LUNs
- Snapshots
- Business continuance volumes (BCV)
- Replication with a remote controller....
Simple controllers
[edit]A simple disk array controller may fit inside a computer, either as a PCI expansion card or just built onto a motherboard. Such a controller usually provides host bus adapter (HBA) functionality itself to save physical space. Hence it is sometimes called a RAID adapter.
As of February 2007[update] Intel started integrating their own Matrix RAID controller in their more upmarket motherboards, giving control over 4 devices and an additional 2 SATA connectors, and totalling 6 SATA connections (3 Gbit/s each). For backward compatibility one IDE connector able to connect 2 ATA devices (100 Mbit/s) is also present.
History
[edit]While hardware RAID controllers were available for a long time, they always required expensive SCSI hard drives and aimed at the server and high-end computing market. SCSI technology advantages include allowing up to 15 devices on one bus, independent data transfers, hot-swapping, much higher MTBF.
Around 1997, with the introduction of ATAPI-4 (and thus the Ultra-DMA-Mode 0, which enabled fast data-transfers with less CPU utilization) the first ATA RAID controllers were introduced as PCI expansion cards. Those RAID systems made their way to the consumer market, where the users wanted the fault-tolerance of RAID without investing in expensive SCSI drives.
ATA drives make it possible to build RAID systems at lower cost than with SCSI, but most ATA RAID controllers lack a dedicated buffer or high-performance XOR hardware for parity calculation. As a result, ATA RAID performs relatively poorly compared to most SCSI RAID controllers. Additionally, data safety suffers if there is no battery backup to finish writes interrupted by a power outage.
OS support
[edit]Because the hardware RAID controllers present assembled RAID volumes, operating systems aren't strictly required to implement the complete configuration and assembly for each controller. Very often only the basic features are implemented in the open-source software driver, with extended features being provided through binary blobs directly by the hardware manufacturer.
Normally, RAID controllers can be fully configured through card BIOS before an operating system is booted, and after the operating system is booted, proprietary configuration utilities are available from the manufacturer of each controller, because the exact feature set of each controller may be specific to each manufacturer and product. Unlike the network interface controllers for Ethernet, which can be usually be configured and serviced entirely through the common operating system paradigms like ifconfig in Unix, without a need for any third-party tools, each manufacturer of each RAID controller usually provides their own proprietary software tooling for each operating system that they deem to support, ensuring a vendor lock-in, and contributing to reliability issues.[2]
For example, in FreeBSD, in order to access the configuration of Adaptec RAID controllers, users are required to enable Linux compatibility layer, and use the Linux tooling from Adaptec,[3] potentially compromising the stability, reliability and security of their setup, especially when taking the long term view in mind.[2] However, this greatly depends on the controller, and whether appropriate hardware documentation is available in order to write a driver, and some controllers do have open-source versions of their configuration utilities, for example, mfiutil
and mptutil
is available for FreeBSD since FreeBSD 8.0 (2009),[4][5] as well as mpsutil
/mprutil
since 2015,[6] each supporting only their respective device drivers, this latter fact contributing to code bloat.
Some other operating systems have implemented their own generic frameworks for interfacing with any RAID controller, and provide tools for monitoring RAID volume status, as well as facilitation of drive identification through LED blinking, alarm management, hot spare disk designations and data scrubbing § RAID from within the operating system without having to reboot into card BIOS. For example, this was the approach taken by OpenBSD in 2005 with its bio(4) pseudo-device driver and the bioctl utility, which provide volume status, and allow LED/alarm/hotspare control, as well as the sensors (including the drive sensor) for health monitoring;[7] this approach has subsequently been adopted and extended by NetBSD in 2007 as well.[8]
With bioctl, the feature set is intentionally kept to a minimum, so that each controller can be supported by the tool in the same way; the initial configuration of the controller is meant to be performed through card BIOS,[7] but after the initial configuration, all day-to-day monitoring and repair should be possible with unified and generic tools, which is what bioctl is set to accomplish.
References
[edit]- ^ "Storage Basics - Part V: Controllers, Cache and Coalescing". 23 March 2010.
- ^ a b "3.8: "Hackers of the Lost RAID"". OpenBSD Release Songs. OpenBSD. 2005-11-01. Retrieved 2019-03-23.
- ^ Scott Long; Adaptec, Inc (2000). "aac(4) — Adaptec AdvancedRAID Controller driver". BSD Cross Reference. FreeBSD.
- "aac -- Adaptec AdvancedRAID Controller driver". FreeBSD Manual Pages.
- ^ "mfiutil — Utility for managing LSI MegaRAID SAS controllers". BSD Cross Reference. FreeBSD.
- "mfiutil -- Utility for managing LSI MegaRAID SAS controllers". FreeBSD Manual Pages.
- ^ "mptutil — Utility for managing LSI Fusion-MPT controllers". BSD Cross Reference. FreeBSD.
- "mptutil -- Utility for managing LSI Fusion-MPT controllers". FreeBSD Manual Pages.
- ^ "mpsutil — Utility for managing LSI Fusion-MPT 2/3 controllers". BSD Cross Reference. FreeBSD.
- "mpsutil, mprutil -- Utility for managing LSI Fusion-MPT 2/3 controllers". FreeBSD Manual Pages.
- ^ a b Theo de Raadt (2005-09-09). "RAID management support coming in OpenBSD 3.8". misc@ (Mailing list). OpenBSD.
- ^ Constantine A. Murenin (2010-05-21). "1.1. Motivation; 4. Sensor Drivers; 7.1. NetBSD envsys / sysmon". OpenBSD Hardware Sensors — Environmental Monitoring and Fan Control (MMath thesis). University of Waterloo: UWSpace. hdl:10012/5234. Document ID: ab71498b6b1a60ff817b29d56997a418.
- Storage Basics: Choosing a RAID Controller, May 7, 2004, By Ben Freeman