| Table of Contents |
|---|
...
This document aims at giving an understanding of what a multi-node installation entails. For detailed step by step procedures, consult the documentation under Multi-Server Environments.
This document assumes that one are familier with all the components of a single node ayfie Locator installation. If not, then first read ayfie Locator Architectural Overview..
Single Node Installation
...
All incoming documents are indexed by the Index Builder and handed over to the SOLR instance on the Primary nodeprimary server. The SOLR node consult consults with ZooKeeper about which shard and replica to use for what and then passes the document between the SOLR node based on this and then place the documents . Based on this information the SOLR nodes distribute the documents between them and have them inserted into the right shards and/or replicas. On the query side it is almost the same with the one difference that , the Rest Service , unlike the Index Builder, always interact direcely with the SOLR instance on the same nodepasses the queries on to the local SOLR instance which then upon the direction of ZooKeeper, distributes the query to the right shards/replicas and merge the return search results.
Large Multi-Node Setups
Below we see the standard node layout for a Locator deployment with more than 40 million documents to be indexed.
...
- Index Builder - The Index Builder is stateless, hence the worse case scenario is an temporary interruption in indexing of new and updated documents.
- Linguistic service - The Linguistic Services (a.k.a the Lingo Services) is not part of the out of the box installation. If installed later, it will be called by the Index Builder to perform entity extraction upon data extracted from the database. Failure by this component will slow the Index Builder down and it will take it longer to produce the index as it will be waiting for a timeout for each document, and no entities will be extracted.
- License Service - A License Service failure will be fatal. Without the license server, connectors will stop to operate and no user will be allowed to pass in queries.
- Primary Search Node - If one operates with a search matrix to provide failover, then that will will work as long as the failing search node is not the primary server. The reason for this is that the license server resides on the primary node and if that node goes down, no Rest Service will be able to authenticate the user.
- Zookeeper - A Zookeeper failure will render the search nonoperational as ZooKeeper is responsible for directing searches to the correct shards within the collection for the search node in question.
- IIS - If the Windows IIS Web Server were to go down then it will no longer be possible to post queries. However, as that service is stateless, as soon as it is up again, it would be back to business as usual as no data would be lost beyond the failed queries posted while the service was down. Using a load balancer and two or more IIS node as shown in the next section, would not eliminate this single point of failure as both/all of them would be depending on the license server which would continue to be a single point of failure.
- Database.- If the database were to go down all searches would stop working as the required user authentication depends on the database. However, it is possible to set up an external standalone PostgreSQL or Microsoft MySQL database with its own failover solution independent of the ayfie Locator.
- Connector services - The connectors have two phases, discovery and fetch. Unlike fetch that can by done from any number of servers, discovery can only be done from a single server. For collections served by a connector performing discovery from a particular server, the failure of that server / that connector will result in failure to do any further updates to the index. The server assigned to perform discovery can be changed, however only 1 server can be assigned to perform discovery.
...