/
ModelOp Center Sizing Considerations

ModelOp Center Sizing Considerations

Owned by Dave Trier
Last updated: Apr 22, 2024 by Mark LeMonnier
3 min read

Introduction

Appropriately sizing the Kubernetes cluster and nodes that will support the ModelOp Center software is an important step to take when deploying. The values presented below represent defaults that can be used to size the pod requirements and the cluster nodes. Note that these values are not absolute and simply serve as a starting point for your deployment of ModelOp Center.

Considerations

Actual needs will depend on a number of factors, such as the number and complexity of models, the number and complexity of model lifecycles, number of users etc. The ModelOp team can assist with tuning of resources based on your individual needs. Another factor to consider is what environment ModelOp Center is being configured for. You may find that a development or sandbox environment will require less resources than a production environment.

Environment Requirements

ModelOp Center consists of a set of “Core services” that provide overall management and a configurable set of ModelOp “Runtimes” that scale up with the number of models. The following table lists the minimum supported resources for each service along with the recommended base configuration. While the minimum may be sufficient for a non-prod environment, the recommended values would be a good starting point for a production environment that can then be scaled up as needed. The items listed below with (core) next to them are required for the proper functioning of ModelOp Center. The items listed with (optional) next to them can be included as part of the instantiation of the environment, but are not strictly ModelOp software. The three data stores required for operation are MongoDB, PostgreSQL or SQL Server, and an S3-compliant data store. With these three in place ModelOp will be functional. The three containers below, mongodb, postgres, and minio, are provided as-is from their respective repositories as options in the case where external databases and S3-compliant stores are not available.

 

CPU

Memory (GB)

Disk Space (GB)

Service

Minimum

Recommended

Minimum

Recommended

Minimum

Recommended

document-service (core)

1

2

2

8

2

32

gateway (core)

2

4

2

8

0.5

1

mlc-manager (core)

2

4

4

8

0.5

1

model-manager (core)

2

4

8

16

8

16

registry (core)

1

2

2

4

0.5

1

reporting-service (core)

1

2

2

4

0.5

1

sccs (core)

1

2

2

2

0.5

1

MongoDB or DocumentDB

2

4

8

16

20

80

Postgres or MS SQL

1

2

2

4

4

8

CORE TOTALS

13

26

32

70

36.5

141

 

 

 

 

 

 

 

**runtimes (core) See notes below (3 runtimes assumed)

1 per runtime

2 per runtime

2 per runtime

4 per runtime

2 per runtime

4 per runtime

RUNTIME TOTALS 

3

6

6

12

6

12

 

 

 

 

 

 

 

minio (optional)

1

2

2

4

16

32

Jira (optional)

1

2

2

4

4

8

jenkins (optional)

1

2

2

4

2

4

OPTIONAL TOTALS

3

6

6

12

22

44

 

** Runtimes are horizontally scalable out of the box. Strictly speaking, the minimum number of runtimes is 0 (though certain features will be non functional with no runtimes) and a recommended starting point is 3. Without runtimes, monitoring, scoring, retraining and model tests cannot be performed. Data set sizes must also be considered when calculating memory for runtimes, as all datasets are read in-memory.

 

Related content