Based on kernel version 4.16.1. Page generated on 2018-04-09 11:53 EST.
1 The cluster MD is a shared-device RAID for a cluster, it supports 2 two levels: raid1 and raid10 (limited support). 3 4 5 1. On-disk format 6 7 Separate write-intent-bitmaps are used for each cluster node. 8 The bitmaps record all writes that may have been started on that node, 9 and may not yet have finished. The on-disk layout is: 10 11 0 4k 8k 12k 12 ------------------------------------------------------------------- 13 | idle | md super | bm super [0] + bits | 14 | bm bits[0, contd] | bm super[1] + bits | bm bits[1, contd] | 15 | bm super[2] + bits | bm bits [2, contd] | bm super[3] + bits | 16 | bm bits [3, contd] | | | 17 18 During "normal" functioning we assume the filesystem ensures that only 19 one node writes to any given block at a time, so a write request will 20 21 - set the appropriate bit (if not already set) 22 - commit the write to all mirrors 23 - schedule the bit to be cleared after a timeout. 24 25 Reads are just handled normally. It is up to the filesystem to ensure 26 one node doesn't read from a location where another node (or the same 27 node) is writing. 28 29 30 2. DLM Locks for management 31 32 There are three groups of locks for managing the device: 33 34 2.1 Bitmap lock resource (bm_lockres) 35 36 The bm_lockres protects individual node bitmaps. They are named in 37 the form bitmap000 for node 1, bitmap001 for node 2 and so on. When a 38 node joins the cluster, it acquires the lock in PW mode and it stays 39 so during the lifetime the node is part of the cluster. The lock 40 resource number is based on the slot number returned by the DLM 41 subsystem. Since DLM starts node count from one and bitmap slots 42 start from zero, one is subtracted from the DLM slot number to arrive 43 at the bitmap slot number. 44 45 The LVB of the bitmap lock for a particular node records the range 46 of sectors that are being re-synced by that node. No other 47 node may write to those sectors. This is used when a new nodes 48 joins the cluster. 49 50 2.2 Message passing locks 51 52 Each node has to communicate with other nodes when starting or ending 53 resync, and for metadata superblock updates. This communication is 54 managed through three locks: "token", "message", and "ack", together 55 with the Lock Value Block (LVB) of one of the "message" lock. 56 57 2.3 new-device management 58 59 A single lock: "no-new-dev" is used to co-ordinate the addition of 60 new devices - this must be synchronized across the array. 61 Normally all nodes hold a concurrent-read lock on this device. 62 63 3. Communication 64 65 Messages can be broadcast to all nodes, and the sender waits for all 66 other nodes to acknowledge the message before proceeding. Only one 67 message can be processed at a time. 68 69 3.1 Message Types 70 71 There are six types of messages which are passed: 72 73 3.1.1 METADATA_UPDATED: informs other nodes that the metadata has 74 been updated, and the node must re-read the md superblock. This is 75 performed synchronously. It is primarily used to signal device 76 failure. 77 78 3.1.2 RESYNCING: informs other nodes that a resync is initiated or 79 ended so that each node may suspend or resume the region. Each 80 RESYNCING message identifies a range of the devices that the 81 sending node is about to resync. This overrides any previous 82 notification from that node: only one ranged can be resynced at a 83 time per-node. 84 85 3.1.3 NEWDISK: informs other nodes that a device is being added to 86 the array. Message contains an identifier for that device. See 87 below for further details. 88 89 3.1.4 REMOVE: A failed or spare device is being removed from the 90 array. The slot-number of the device is included in the message. 91 92 3.1.5 RE_ADD: A failed device is being re-activated - the assumption 93 is that it has been determined to be working again. 94 95 3.1.6 BITMAP_NEEDS_SYNC: if a node is stopped locally but the bitmap 96 isn't clean, then another node is informed to take the ownership of 97 resync. 98 99 3.2 Communication mechanism 100 101 The DLM LVB is used to communicate within nodes of the cluster. There 102 are three resources used for the purpose: 103 104 3.2.1 token: The resource which protects the entire communication 105 system. The node having the token resource is allowed to 106 communicate. 107 108 3.2.2 message: The lock resource which carries the data to 109 communicate. 110 111 3.2.3 ack: The resource, acquiring which means the message has been 112 acknowledged by all nodes in the cluster. The BAST of the resource 113 is used to inform the receiving node that a node wants to 114 communicate. 115 116 The algorithm is: 117 118 1. receive status - all nodes have concurrent-reader lock on "ack". 119 120 sender receiver receiver 121 "ack":CR "ack":CR "ack":CR 122 123 2. sender get EX on "token" 124 sender get EX on "message" 125 sender receiver receiver 126 "token":EX "ack":CR "ack":CR 127 "message":EX 128 "ack":CR 129 130 Sender checks that it still needs to send a message. Messages 131 received or other events that happened while waiting for the 132 "token" may have made this message inappropriate or redundant. 133 134 3. sender writes LVB. 135 sender down-convert "message" from EX to CW 136 sender try to get EX of "ack" 137 [ wait until all receivers have *processed* the "message" ] 138 139 [ triggered by bast of "ack" ] 140 receiver get CR on "message" 141 receiver read LVB 142 receiver processes the message 143 [ wait finish ] 144 receiver releases "ack" 145 receiver tries to get PR on "message" 146 147 sender receiver receiver 148 "token":EX "message":CR "message":CR 149 "message":CW 150 "ack":EX 151 152 4. triggered by grant of EX on "ack" (indicating all receivers 153 have processed message) 154 sender down-converts "ack" from EX to CR 155 sender releases "message" 156 sender releases "token" 157 receiver upconvert to PR on "message" 158 receiver get CR of "ack" 159 receiver release "message" 160 161 sender receiver receiver 162 "ack":CR "ack":CR "ack":CR 163 164 165 4. Handling Failures 166 167 4.1 Node Failure 168 169 When a node fails, the DLM informs the cluster with the slot 170 number. The node starts a cluster recovery thread. The cluster 171 recovery thread: 172 173 - acquires the bitmap<number> lock of the failed node 174 - opens the bitmap 175 - reads the bitmap of the failed node 176 - copies the set bitmap to local node 177 - cleans the bitmap of the failed node 178 - releases bitmap<number> lock of the failed node 179 - initiates resync of the bitmap on the current node 180 md_check_recovery is invoked within recover_bitmaps, 181 then md_check_recovery -> metadata_update_start/finish, 182 it will lock the communication by lock_comm. 183 Which means when one node is resyncing it blocks all 184 other nodes from writing anywhere on the array. 185 186 The resync process is the regular md resync. However, in a clustered 187 environment when a resync is performed, it needs to tell other nodes 188 of the areas which are suspended. Before a resync starts, the node 189 send out RESYNCING with the (lo,hi) range of the area which needs to 190 be suspended. Each node maintains a suspend_list, which contains the 191 list of ranges which are currently suspended. On receiving RESYNCING, 192 the node adds the range to the suspend_list. Similarly, when the node 193 performing resync finishes, it sends RESYNCING with an empty range to 194 other nodes and other nodes remove the corresponding entry from the 195 suspend_list. 196 197 A helper function, ->area_resyncing() can be used to check if a 198 particular I/O range should be suspended or not. 199 200 4.2 Device Failure 201 202 Device failures are handled and communicated with the metadata update 203 routine. When a node detects a device failure it does not allow 204 any further writes to that device until the failure has been 205 acknowledged by all other nodes. 206 207 5. Adding a new Device 208 209 For adding a new device, it is necessary that all nodes "see" the new 210 device to be added. For this, the following algorithm is used: 211 212 1. Node 1 issues mdadm --manage /dev/mdX --add /dev/sdYY which issues 213 ioctl(ADD_NEW_DISK with disc.state set to MD_DISK_CLUSTER_ADD) 214 2. Node 1 sends a NEWDISK message with uuid and slot number 215 3. Other nodes issue kobject_uevent_env with uuid and slot number 216 (Steps 4,5 could be a udev rule) 217 4. In userspace, the node searches for the disk, perhaps 218 using blkid -t SUB_UUID="" 219 5. Other nodes issue either of the following depending on whether 220 the disk was found: 221 ioctl(ADD_NEW_DISK with disc.state set to MD_DISK_CANDIDATE and 222 disc.number set to slot number) 223 ioctl(CLUSTERED_DISK_NACK) 224 6. Other nodes drop lock on "no-new-devs" (CR) if device is found 225 7. Node 1 attempts EX lock on "no-new-dev" 226 8. If node 1 gets the lock, it sends METADATA_UPDATED after 227 unmarking the disk as SpareLocal 228 9. If not (get "no-new-dev" lock), it fails the operation and sends 229 METADATA_UPDATED. 230 10. Other nodes get the information whether a disk is added or not 231 by the following METADATA_UPDATED. 232 233 6. Module interface. 234 235 There are 17 call-backs which the md core can make to the cluster 236 module. Understanding these can give a good overview of the whole 237 process. 238 239 6.1 join(nodes) and leave() 240 241 These are called when an array is started with a clustered bitmap, 242 and when the array is stopped. join() ensures the cluster is 243 available and initializes the various resources. 244 Only the first 'nodes' nodes in the cluster can use the array. 245 246 6.2 slot_number() 247 248 Reports the slot number advised by the cluster infrastructure. 249 Range is from 0 to nodes-1. 250 251 6.3 resync_info_update() 252 253 This updates the resync range that is stored in the bitmap lock. 254 The starting point is updated as the resync progresses. The 255 end point is always the end of the array. 256 It does *not* send a RESYNCING message. 257 258 6.4 resync_start(), resync_finish() 259 260 These are called when resync/recovery/reshape starts or stops. 261 They update the resyncing range in the bitmap lock and also 262 send a RESYNCING message. resync_start reports the whole 263 array as resyncing, resync_finish reports none of it. 264 265 resync_finish() also sends a BITMAP_NEEDS_SYNC message which 266 allows some other node to take over. 267 268 6.5 metadata_update_start(), metadata_update_finish(), 269 metadata_update_cancel(). 270 271 metadata_update_start is used to get exclusive access to 272 the metadata. If a change is still needed once that access is 273 gained, metadata_update_finish() will send a METADATA_UPDATE 274 message to all other nodes, otherwise metadata_update_cancel() 275 can be used to release the lock. 276 277 6.6 area_resyncing() 278 279 This combines two elements of functionality. 280 281 Firstly, it will check if any node is currently resyncing 282 anything in a given range of sectors. If any resync is found, 283 then the caller will avoid writing or read-balancing in that 284 range. 285 286 Secondly, while node recovery is happening it reports that 287 all areas are resyncing for READ requests. This avoids races 288 between the cluster-filesystem and the cluster-RAID handling 289 a node failure. 290 291 6.7 add_new_disk_start(), add_new_disk_finish(), new_disk_ack() 292 293 These are used to manage the new-disk protocol described above. 294 When a new device is added, add_new_disk_start() is called before 295 it is bound to the array and, if that succeeds, add_new_disk_finish() 296 is called the device is fully added. 297 298 When a device is added in acknowledgement to a previous 299 request, or when the device is declared "unavailable", 300 new_disk_ack() is called. 301 302 6.8 remove_disk() 303 304 This is called when a spare or failed device is removed from 305 the array. It causes a REMOVE message to be send to other nodes. 306 307 6.9 gather_bitmaps() 308 309 This sends a RE_ADD message to all other nodes and then 310 gathers bitmap information from all bitmaps. This combined 311 bitmap is then used to recovery the re-added device. 312 313 6.10 lock_all_bitmaps() and unlock_all_bitmaps() 314 315 These are called when change bitmap to none. If a node plans 316 to clear the cluster raid's bitmap, it need to make sure no other 317 nodes are using the raid which is achieved by lock all bitmap 318 locks within the cluster, and also those locks are unlocked 319 accordingly. 320 321 7. Unsupported features 322 323 There are somethings which are not supported by cluster MD yet. 324 325 - change array_sectors.