Skip to main content

Converting ServiceOps from Standalone to Distributed Mode

Scale your ServiceOps environment for higher performance and resilience by converting your single-server deployment into a distributed architecture.

This guide provides a comprehensive walkthrough for converting an existing ServiceOps standalone deployment into a distributed architecture. This conversion enhances scalability, performance, and resilience by separating core components onto dedicated servers.

Overview of Deployment Modes​

  • Standalone Deployment: All ServiceOps components (Application, Database, Analytics) are consolidated onto a single server. This model is simple to manage and is ideal for smaller environments, evaluations, or proof-of-concept setups.
  • Distributed Deployment: ServiceOps components are separated across multiple servers. Typically, this involves dedicating separate servers for the Application and the Database. This model is designed for medium to large organizations with higher workloads, providing better performance, fault isolation, and the ability to scale components independently.

Why Convert to a Distributed Architecture?​

Converting from standalone to distributed is recommended when your organization needs to:

  • Improve Performance: Isolate database and application workloads to prevent resource contention.
  • Enhance Scalability: Scale the application and database tiers independently as your usage grows.
  • Increase Reliability: Reduce the impact of a single point of failure.
  • Meet Compliance Requirements: Adhere to security policies that mandate the separation of application and database servers.

Prerequisites​

Before you begin the conversion process, ensure you have the following:

  1. Existing Standalone Instance: A fully functional ServiceOps application running in standalone mode.
  2. New Dedicated Servers: At least one new server prepared to host the PostgreSQL database. If you also plan to separate the file server, you will need another dedicated server.
  3. System Requirements: The new server(s) must meet the System Requirements for ServiceOps.
  4. Network Connectivity:
    • Stable network connectivity between the application server and the new database server.
    • Ensure necessary firewall ports are open. For a distributed deployment, the following ports are essential:
      • 80/443 (TCP): For standard web access to the ServiceOps portal.
      • 5432 (TCP): For communication between the application server and the PostgreSQL database server.
  5. Full Backup: This is a critical step. Before making any changes, perform a complete backup of your standalone ServiceOps instance. For detailed instructions, refer to the ServiceOps Application and Database Backup Procedure.
danger

This procedure involves modifying core configuration files and migrating data. It is strongly recommended to perform and validate these steps in a staging or test environment before applying them to a production instance.

Part 1: Migrating the Database to a Dedicated Server​

The process of migrating the database to a dedicated server is the core of converting your standalone instance to a distributed architecture. At a high level, the process involves these key stages:

  1. Stop all services on your current standalone server to ensure data consistency.
  2. Perform a full backup of your serviceops database.
  3. Prepare the new database server by installing PostgreSQL using the provided utility.
  4. Restore your database backup onto the new server.
  5. Reconfigure the application server to point to the new remote database IP address and restart the services.

The complete, step-by-step procedure with all necessary commands and validation checks is documented in the primary installation guide.

For detailed instructions, please follow the Installation Guide for Distributed Deployment.

Part 2: (Optional) Migrating the FileDB to a Dedicated File Server​

The FileDB contains attachments, patches, and other essential files. You can also move this to a dedicated file server or a network mount point (NFS) for better scalability and management.

Step 1: Prepare the New File Server Location​

  1. Create the new directory on your file server or mount point.
  2. Stop the ServiceOps services on the application server if they are running.
    systemctl stop ft-main-server
    systemctl stop ft-analytics-server
  3. Copy the entire filedb directory from your application server to the new location. The default location is /opt/flotomate/main-server/filedb.
    rsync -avz /opt/flotomate/main-server/filedb/ user@your-file-server:/path/to/new/filedb/
  4. Ensure the fmtuser has the correct permissions on the new directory.

Step 2: Reconfigure the FileDB Path​

On the application server, edit the following configuration files to update the DfileDb property to the new path.

  1. Main Server:

    • File: /opt/flotomate/main-server/lib/boot-hosted-exec.conf
    • Change -DfileDb=../filedb to -DfileDb=/path/to/new/filedb/main-server

  2. Analytics Server:

    • File: /opt/flotomate/cm-analytics/lib/analytics-hosted-exec.conf
    • Change -DfileDb=../filedb to -DfileDb=/path/to/new/filedb/analytics-server

Step 3: Start and Verify​

  1. Start the ServiceOps services on the application server.
    systemctl start ft-main-server
    systemctl start ft-analytics-server
  2. Log in to the application and test functionality that uses the FileDB, such as opening a ticket with an attachment or viewing software packages.

Your ServiceOps instance is now running in a distributed mode with a separated database and/or file server.