![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |
If your stores are file-based, there are several options available for implementing shared storage, using a combination of hardware and software. EMS requires that your storage solution guarantees all four criteria in Table 88.
Always consult your shared storage vendor and your operating system vendor to ascertain that the storage solution you select satisfies all four criteria.
(Solutions that write data blocks in any other order (for example, to enhance disk efficiency) do not satisfy this requirement.) The EMS servers must be able to request and obtain an exclusive lock on the shared storage. The storage solution must not assign the locks to two servers simultaneously. (See Software Options.) Dual-port SCSI and SAN solutions generally satisfy the Write Order and Synchronous Write Persistence criteria. (The clustering software must satisfy the remaining two criteria.) As always, you must confirm all four requirements with your vendors.NAS solutions require a CS (rather than a CFS) to satisfy the Distributed File Locking criterion (see below).
• NFS v2 and NFS v3 definitely do not satisfy the criteria.
• NFS v4 with TCP might satisfy the criteria. Consult with the NAS vendor to verify that the NFS server (in the NAS) satisfies the criteria. Consult with the operating system vendor to verify that the NFS client (in the OS on the server host computer) satisfies the criteria. When both vendors certify that their components cooperate to guarantee the criteria, then the shared storage solution supports EMS.For more information on how the EMS locks shared store files, see How EMS Manages Access to Shared Store Files.With dual-port SCSI or SAN hardware, either a CS or a CFS might satisfy the Distributed File Locking criterion. With NAS hardware, only a CS can satisfy this criterion (CFS software generally does not). Of course, you must confirm all four requirements with your vendors.Messages with PERSISTENT delivery mode are stored, and are available in the event of active server failure. Messages with NON_PERSISTENT delivery mode are not available if the active server fails.By default, the tibemsd server creates three file-based stores to store shared state:
• $sys.failsafe—This store holds persistent messages using synchronous I/O calls.
• $sys.nonfailsafe—This file stores messages using asynchronous I/O calls.
• $sys.meta—This store holds state information about durable subscribers, fault-tolerant connections, and other metadata.These stores are fully customizable through parameters in the stores configuration file. More information about these files and the default configuration settings are fully described in stores.conf on page 261.To prevent two servers from using the same store file, each server restricts access to its store file for the duration of the server process. For more information on how the EMS manages shared store files, see How EMS Manages Access to Shared Store Files.
These default files can be changed or modified. See Default Store Files for more information.
![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |