Below is the theory of operation for XtremIO. I'll try to cover as much ground as i can and while keeping things simple.
As we know XtremIO is an all flash array, based on scale-out architecture. The system's building block is X-Brick, which can be clustered together to grow the array.
Each X-Brick consist of:
a) 1 DAE (disk array enclosure); containing 25 SSDs, 2 PSUs, 2 SAS redundant module interconnect.
b) 1 Battery backup unit (BBU)
c) 2 Storage controllers. Each controller has 2 PSUs, 2 Eight Gb/s FC ports, Two 10GbE isci ports, Two 40 Gb/s Infiniband ports, One 1 Gb/s management port.
Note: If its a single brick cluster then you may need a additional BBU for redundancy.
The system operation is controlled via stand-alone dedicated Linux-based server called XtremIO Management Server (XMS). One XMS can manage only one cluster. Array continues operating if XMS is disconnected but can't be monitored or configured. XMS can be either be a virtual or physical server. It communicates with each storage controller in X-Brick via management LAN. XMS enables array administrator to manage array via GUI or CLI.
XIOS handles all activities in storage controller. There are 6 software modules that are responsible for all system functions.
1) I/O modules R, C & D that are used for routing, control and data placement throughout the array.
Routing Module: It translate all SCSI commands into internal XtremIO commands. It is also responsible for breaking incoming I/O into 4K chunk and calculate data hash value.
Control Module: This module contains the address to hash mapping table (A2H).
Data Module: This module contains Hash to Physical (H2P) SSD address mapping. It is also responsible for maintaining data protection (XDP).
2) Platform Module: Each storage controller has PM to manage the hardware and system process; it also restart system process if required. PM also clustering agent that manages the entire cluster.
3) Management Module: Each Storage Controller has one management module running on it; in a active/passive way. If one SC fails then MM starts on the other SC of X-Brick. If both SC fails then the system will halt.
Below picture depicts the module communication flow-chart:
As we know XtremIO is an all flash array, based on scale-out architecture. The system's building block is X-Brick, which can be clustered together to grow the array.
Each X-Brick consist of:
a) 1 DAE (disk array enclosure); containing 25 SSDs, 2 PSUs, 2 SAS redundant module interconnect.
b) 1 Battery backup unit (BBU)
c) 2 Storage controllers. Each controller has 2 PSUs, 2 Eight Gb/s FC ports, Two 10GbE isci ports, Two 40 Gb/s Infiniband ports, One 1 Gb/s management port.
Note: If its a single brick cluster then you may need a additional BBU for redundancy.
The system operation is controlled via stand-alone dedicated Linux-based server called XtremIO Management Server (XMS). One XMS can manage only one cluster. Array continues operating if XMS is disconnected but can't be monitored or configured. XMS can be either be a virtual or physical server. It communicates with each storage controller in X-Brick via management LAN. XMS enables array administrator to manage array via GUI or CLI.
XtremIO Operating System:
XtremIO runs on a Open Source Linux distribution as a base platform and on top which runs XIOS. OS manages the functional modules, RDMA functions over InfiniBand (IB) between all storage controllers in the cluster.
XIOS handles all activities in storage controller. There are 6 software modules that are responsible for all system functions.
1) I/O modules R, C & D that are used for routing, control and data placement throughout the array.
Routing Module: It translate all SCSI commands into internal XtremIO commands. It is also responsible for breaking incoming I/O into 4K chunk and calculate data hash value.
Control Module: This module contains the address to hash mapping table (A2H).
Data Module: This module contains Hash to Physical (H2P) SSD address mapping. It is also responsible for maintaining data protection (XDP).
2) Platform Module: Each storage controller has PM to manage the hardware and system process; it also restart system process if required. PM also clustering agent that manages the entire cluster.
3) Management Module: Each Storage Controller has one management module running on it; in a active/passive way. If one SC fails then MM starts on the other SC of X-Brick. If both SC fails then the system will halt.
Below picture depicts the module communication flow-chart:
Write Operation:
When host writes a I/O to array.
1) It is picked up by R Module, which breaks it into 4K chunks and calculate the corresponding hash value.
2) C Module stores the hash value
3) D module updates the physical address information in its mapping table before storing it at physical SSD.
4) System sends the acknowledgement back to host.
Below picture depicts the normal Write I/O operation.
Write operation of duplicated I/O:
Read Operation:
Whenever a read I/O is issued to array:
1) System analyse each request to determine the LBA (logical block address) for each data block. This logical block address is stored C Module.
2) C module do a look up for Hash value stored in D module.
3) D module returns the relevant Physical SSD address to the Host.
Below picture depict the read operation:
Also read array-administration and xtremio-architecture
Happy Learning!
No comments:
Post a Comment