|
To ensure that storage-area network (SAN) corruption doesn't occur, both hosts need to be aware of all data changes. This arbitration takes place at the application layer and has nothing to do with the underlying SAN hardware. A disk array merely allows hosts to access logical devices through logical unit number (LUN) masking; once this is achieved, the array's job is finished. Similarly, the operating system carries out a discovery cycle when it boots up and, if the shared LUN is available, will assume it has exclusive access to the LUN.
The intelligent layer that allows multiple hosts to access the same data set without corruption is the application that the Web servers are running. If the data set is read-only, then many hosts are allowed to access the data at once, as there's no possibility of them attempting to change the data while more than one host has the data open. If the data set is read/write, then the access control is different and there are alternative ways to ensure data consistency:
Alternative ways to ensure data consistency
- Locking records after access, denying requests from other hosts. This guarantees that only the first host is allowed to access the data. This is fairly simple but can cause issues with records being open for extended periods of time (for example, somebody closes a browser without releasing the application, etc.). To a certain extent, timeouts can mitigate these issues, but an explicit lock isn't an ideal solution.
- Using a timestamp on the record. Any host is allowed to access any record but must save the timestamp of the record when it's accessed. If a host wants to update a record, it must read the timestamp of the record again and compare it against the copy of the timestamp it saved earlier. If they match, the record hasn't been updated since it was opened and the update can be applied in the safe knowledge that the data is consistent. If the timestamp is different, then the record has been updated by somebody else. In this scenario, the updated record must be read and fed back into the calculation before another write is attempted. This must go on until the timestamps match and the update can be written safely.
- Raising a flag when an access attempt is made. This states that the record is being updated and read-only access is currently allowed. This also leaves the host to make a decision on whether read-only access is acceptable or if it would prefer to wait until exclusive access is granted.
When deciding on which access method to implement, you will need to consider the needs of the application being built.
|
