The shared block-device methodology described at the beginning of this chapter is the recommended method for storing CCS data (Section 7.1 Creating a CCS Archive and Section 7.2 Starting CCS in the Cluster). The advantages are that there is no server point-of-failure and that updates to the CCS archive happen atomically.
However, not every cluster has every node connected to the shared storage. For example, a cluster may be built with external lock servers that do not have access to the shared storage. In that case, the client/server methodology (Section 7.5.1 CCA File and Server) could be employed, but that approach introduces a server point-of-failure. Also, local file archives could be used on each node (Section 7.5.2 Local CCA Files), but that approach makes updating the CCS archives difficult.
The best approach for storing CCS data may be a combination of the shared-device method and the local-files method. For example, the cluster nodes attached to shared storage could use the shared-device method, and the other nodes in the cluster could use the local-files approach. Combining those two methods eliminates the possible point-of-failure and reduces the effort required to update a CCS archive.
Note | |
---|---|
When you update a CCS archive, update the shared-device archive first, then update the local archives. Be sure to keep the archives synchronized. |