kCura has placed a hard cap on the amount of threads that each Worker server is allowed to spawn, the hard cap is 16 threads. Worker The ‘Worker’ role is responsible for handling enhanced native imaging, processing, and viewer conversion jobs. This server is also used for native imaging and viewer conversion request management across the queue and instance settings tables. Total memory and processor requirements for this role are not as demanding as the SQL Servers that house workspace databases. SQL Server (Invariant/Worker Manager Server) Relativity processing has individual store databases that correspond to each Relativity workspace database with processing enabled. In addition to workspace databases there are Relativity system databases present on each server that contain tables for system configurations, agent job queues, user/groups, etc. Environments may have one or more SQL Servers. Each Relativity workspace is represented by its own SQL Server database. SQL Server (Workspaces) This SQL server is where the structured text and metadata resides for the documents. Therefore, each Relativity agent server that is designated to be a dtSearch search agent server should only have one dtSearch search agent and nothing else. One dtSearch search agent may be able to utilize all available processor cores on a server. The agents can be scaled vertically and horizontally to accommodate organizational needs.Īgent Server (dtSearch) In Relativity 8 and above, the searches are multi-threaded and spawn as many threads as there are sub-indexes or cores - whichever number is lowest will be the constraint.
The agents run under a Windows Service and often require various levels of CPU, RAM and I/O, depending on the job type. When a user submits a job, such as a Production or OCR job, the associated agent(s) will pick up the job and complete the work. Agent Server (Core) Agents in Relativity are responsible for running all background processing tasks. User sessions can be load balanced with the included Relativity User Load Balancer or via available hardware load balancing solutions. There are different methods of authentication into the system including forms, active directory, and RSA support. It authenticates the user with the system, contains APIs for searching and third-party applications, transfers documents to the end user in the Relativity Viewer, and is responsible for communications during imports and exports in workspaces. Web Server The Web Server is the gateway for all users to access Relativity. Note: Beginning in Relativity Version, you have the option of maintaining multiple master nodes for Relativity Data Grid. As illustrated in the following diagram, all areas of the platform are scalable providing support for any hardware vendor, hypervisor, and storage protocol.
NET framework with a Microsoft SQL Server back-end. These requirements also provide various recommendations for configuring a new deployment of Relativity, as well as scaling your environment as the number of users and the amount of data continue to grow.Ģ Infrastructure overview Relativity is designed with a scalable infrastructure that you can tailor to the requirements of your environment.
For the most recent version of this document, visit our documentation website.ģ.1 Tier level definitions 4 Recommended configurations for new deploymentsĤ.1 Tier 1 - Hardware requirements (25-50 named users)Ĥ.2 Tier 1 - Hardware requirements (100 or more named users)Ĥ.3 Tier 2 - Hardware requirements (300 or more named users)ĥ Infrastructure configuration 5.1 Guides for infrastructure management 6 Software requirementsħ.1 Relativity system requirements matrixħ.2 Internet Explorer with Compatibility Viewħ.5 Invariant (worker manager server) release matrixĨ.2 Data Grid cluster system requirementsĨ.4 Elasticsearch version and supported JVMĩ.1 Processing worker hardware specificationsġ System requirements These system requirements contain detailed information about the software and hardware you use to host Relativity in your environment and in the cloud.