Best-Practice - OverOps Components Follow

 

What is it?

Each component within the OverOps architecture requires tried and tested configurations to have an optimal environment for scale, stability, security and maintainability.

Why use it?

If best practices are not followed, or minimum configurations are not met, then the OverOps applications will not function optimally, and may become unstable.

How to spec each component

Agents

Minimum of 100MB of disk space available on vm or container available on ${TAKIPI_HOME}/resources for snapshot cache (default TAKIPI_HOME is /opt/takipi)

Collectors

  • Virtual Machine, Container, or Physical Hardware with 8GB RAM and 4 CPU
  • 50G of disk available to ${TAKIPI_HOME}/work (storage for snapshot cache if backend cannot be reached)
  • Plan for scale. Consider the number of Agents/JVMs connected per Collector
    • for Microservices application - up to 500 Agents/JVMs Per collector
    • for Monolithic application - up to 100 Agents/JVMS Per Collector
  • If a High availability or multiple collectors are needed, OverOps supports commercial or open source load balancers like F5 BigIP, Amazon ELB, Google ILB, nginx (recommended configuration).
    As alternative OverOps also supports a simple round robin collector pool

On-Premise Backend

  • Virtual Machine or Physical Hardware with 32GB RAM, 8 CPU
  • 1 TB disk
  • Options for MySQL, Postgres or Oracle for Backend SQL.
    If High Availability/Failover are needed for the backend, discussions about DB failover, as well as ARC store failover with OverOps Professional Services are needed

On-Premises SQL Server Recommended Approach

  • Virtual Machine or Physical Hardware with 8GB RAM, 4 CPU
  • 250 GB disk
  • for MySQ, Postgres or Oracle for Backend SQL.
  • For DB failover discussion please contact OverOps Professional Services

 

Storage Server (SaaS backend)

Pros

  • A scalable, reliable, and future-proof setup of all OverOps components

Cons

  • None

Comments

0 comments