FTS Configuration Options for Recovery Environments This document sets forth four potential options for configuring a remote index for use by Full Text Search in a recovery environment. The scope of this document is limited to considerations which effect FTS. This document assumes BMC Remedy AR System Server version 7.6.04 or later and that FTS in the production environment configured for High Availability. |
Overview This document sets forth four potential options for configuring a remote index for use by Full Text Search in a recovery environment. The scope of this document is limited to considerations which effect FTS. This document assumes BMC Remedy AR System Server version 7.6.04 or later and that FTS in the production environment configured for High Availability. Some of the options discussed here require BMC Remedy AR System Server 8.1 SP2 as they rely upon the multiple indexer capability of that release. This document does not address server grouping options of BMC Remedy System Server. Refer to this docs page for details. Background Global Search is made possible by the full text search (FTS) subsystem of BMC Remedy System Server. This system provides searching for terms across multiple forms and record types. Data in knowledge articles and other transaction records is scanned and indexed. The index is stored in a set of index files in the collection directory on the server (not in the remedy database). Any character field can be configured to be indexed and so become searchable. BMS Remedy ITSM has certain fields pre-configured to be indexed, but the fields which are indexed may be adjusted; field level indexing can be added or removed. NOTE: Even though the FTS components are updated in Version 9.0 and the index is stored differently, the configuration options mentioned below remain unchanged. FTS High Availability configuration The FTS subsystem is able to be configured for high availability (HA). There are two important aspects to HA configuration: - Multiple search servlets search the index and return hits. o This provides for resilience for search functionality.
This document does not cover HA configuration of FTS. Refer to this docs page for details. Recovery Scenarios Virtually every company has their own corporate policies which stipulate recovery objectives (RTO and RPO), methods of recovery, and entry criteria for recovery. In addition, corporate policies govern data retention (including legal hold), system security, system backup, general infrastructure management, IT operations governance, service management governance, to name a few. The decision to fail over to a recovery site is typically authorized by impacted business units, operations, and executive leadership. Recovery objectives and target recovery goals are established and agreed to by all affected parties. Some of the more common scenarios in which a system must be recovered in a remote system: Catastrophic loss of primary data center The original data center is not accessible in any way. The data that you have in the form of backups or in a recovery datacenter is all there is. Other systems may or may not be accessible including, but not limited to, source data feeds, integrations with other applications, integrations to vendors (both inbound and outbound). Risk Avoidance fail-over Sufficient immanent risk to system stability exists either in the primary system or in the data center where the primary system is hosted. Bi-directional capability needed:
Decisive fail-over Due to complex criteria and calculated risk, failover to recovery infrastructure is warranted.
Regardless of the reason for recovery, the FTS collection data must be recovered (or rebuilt, as you will see later) in order to support global search operations. Infrastructure configuration based on needs of business Because every company has specific guidelines for recovery, and specific requirements to enable global search capability within the BMC Remedy product, the options below represent potential solutions which MAY be implemented. This document assumes that you have capability to recover the BMC Remedy AR System (mainly the database) in a remote location. MAJOR ASSUMPTION: the database is replicated in near real-time manner such that the copy in the recovery site is as close to 100% accurate and up to date. This is usually accomplished via database replication schemes. This document does not address database replication. It is up to the database administration team to develop, configure, and operate whatever database replication scheme is required for your company. Configuration Options OPTION 1 – Isolated index
When recovery has been initiated, the BMC Remedy AR System in the Recovery Environment is started up in the usual manner. After the system is up and ready, the Remedy administrator will follow documented steps to cause a full FTS re-index. This includes:
OPTION 2 –REMOTE COLLECTION directory Set up an AR System Server as an index server for FTS. Configure this machine as an Indexer but NOT as a searcher. This server will index things, but no-one would go to it for searching. Configure this indexer server to refer to a remote mounted file system that is located actually in the recovery environment. Your indexer is actually indexing to files in the recovery environment. In the recovery environment, set up a machine as the indexer who indexes to that same directory. This server will be used for indexing and searching only when the Recovery Environment site is in use. Set up the machine names so the auxiliary indexer in PRODUCTION and the indexer machine in the Recovery Environment are considered to be the same machine. This option requires AR System Server 8.1 SP2 or later. Figure 2
When recovery is required, anything that has not been indexed by the auxiliary AR DR indexing server will still be in FT_PENDING. When the indexing server in the recovery environment is started up, it will pick up indexing where the auxiliary server left off.
OPTION 3 – REMOTE FTS INDEX server Adding a server to the server group but locate it remotely. This server will be in the Recovery Environment site but is a production server; make it part of the PRODUCTION server group. This is solely an FTS INDEXING server for the purpose of building the Recovery index. Set it up to not have any other traffic. In this case, you now have a remote DB connection – but your server is focused on FTS Indexing. The added DB latency will not impact production operations as the server is not used for anything interactive. Set up the auxiliary server in Recovery Environment so it is ALSO in the recovery environment Server Group. In the case of recovery, this server would continue the role of maintaining the index in Recovery and can actually be used as a Recovery server instance for other purposes too. This option requires AR System Server 8.1 SP2 or later.
Note: If we can assume that the network connection for Option 2 is the same as that for Option 3, including all pieces of infrastructure, then the performance, Option 2 performance should be better than Option 3. This is due to the amount of traffic that must be read from the database through a slower connection OPTION 4 – SAN STORAGE replication NOTE: this option relies upon your having enterprise grade storage options and sufficient business justification to utilize same. In this scenario the PRODUCTION system and the recovery system are configured separately. The collection directory is physically located on a SAN device. In the same way, the FTS indexer server in the Recovery Environment is configured to have its collection directory on a SAN device. The SAN devices are configured such that the production filespace is replicated by SAN replication to the SAN device in the recovery environment. For this to work, the recovery indexing server must not write to its collection directory. When recovery mode is required, the SAN replication link is disabled and the recovery indexer picks up where the PRODUCTION server left off. Figure 4
Some Legal Stuff The configuration options discussed herein are offered as potential scenarios. BMS Software, Inc. cannot guarantee the viability of your implementation of these configuration options. Simply put, there are just too many variables not in our control to allow us to do so. |