MOSIP deployment is split into two distinct parts:
Pre-registration
Registration
The server-side hardware estimates for the above are specified at a high level in terms of compute (Virtual CPU, RAM) and storage requirements. We provide estimates for MOSIP core modules only. External components are not in the scope. See Exclusions.
The variables that largely determine the hardware requirements are:
The population of the country
Rate of enrolment
Usage of foundation ID by various services
Refer to Pre-registration Resource Calculator XLS
Allow for 20% additional compute and storage for monitoring and any overheads.
The registration compute resources are related to the max rate of enrolment desired. The processing throughput must match the enrolment rate to avoid a pile-up of pending registration packets.
The data here is based on actual field data of a MOSIP deployment.
Assumptions:
Rate of enrolment: 216000 per day
Average packet size: 2MB
Biometric modalities: Finger, iris, face
Pod replication as given here. (TBD)
Configuration of compute node: 12 VCPU, 64GB RAM, 64GB disk store.
Number of nodes: 21
Storage is dependent on the population of a country (i.e. the number of UINs to be issued). Storage requirements for various types of data are listed below.
Allow for 20% additional compute and storage for monitoring and any overheads.
Refer to IDA Resource Calculator XLS
Allow for 20% additional compute and storage for monitoring and any overheads.
The compute and storage estimates for the following components are not included:
DR would significantly increase compute and storage requirements. It is expected that System Integrator works out the appropriate DR strategy and arrives at an estimate.
In V3 installation cluster can be administered by logging into organisation wide Rancher setup. Rancher is integrated with Keycloak for authentication. To provide cluster access to a user perform the following steps as administrator:
Login into organisation wide Keycloak e.g https://iam.xyz.net. It is assumed that you have admin role in Keycloak.
Create a new user.
Make sure a strong password is set for the same under Credentials tab.
On Details tab you should see Update Password flag under Required User Actions. This will prompt a user to change the password during first login. Disable the same only if you are sure you don't want user to change password.
Login to Rancher as administrator, e.g. https://rancher.xyz.net.
Select a cluster for which you would like to enable access to the user.
Add the user as member of the cluster.
Assign a role, e.g Cluster Owner, Cluster Viewer.
| Resource | Per node | Nodes | Total |
|---|---|---|---|
| Data | Storage | Comments |
|---|---|---|
| Component | Comments |
|---|---|
VCPU
12
21
252
RAM (GB)
64
21
1344
Node disk (GB)
64
21
1344
Object Store (S3/Minio)
3200 GB/million packets/replication
Replication factor to be applied based on replication strategy
Postgres storage
30 GB/million packets
Includes all databases
Unprocessed packets X avg packet size
The size of landing zone depends on the estimated lag in packet processing and packet uploads. Once UINs are issued, the packets may be removed from the landing zone as a copy is already saved in Object Store
Logs (Elasticsearch)
80 GB/day
Logs maybe archived after, say, 2 weeks
Monitoring (Prometheus)
1.2 GB/day
Kafka
NA
Resource allocation is part of cluster node
ActiveMQ
NA
Resource allocation depends on the deployment - standalone or part of cluster
Redis
Single VM with, RAM = Cache size * 1.5 VCPU = 4 to 16 depending on number of packets getting processed per min Hardware: Minimum
Cache size = Avg. packet size * No. of packets processed in a min * Packet to be stored in cache for X mins
Postgres
Only storage estimated above.
Object store
Only storage estimated above.
Bio SDK
Antvirus (AV)
Default scanner (ClamAV) in included, however, if you integrate your AV, the same needs to be estimated.
Load balancers
External IAM (for Rancher)
Disaster recovery(DR)
Below table lists various checks that must be performed before actual roll out of a deployment. This list is not exhaustive and it is expected that SIs use this as a reference and augment their own hardening procedures.
| Topic | Tasks |
|---|
|
Backup |
|
Cluster hardening |
|
Archival |
|
Keycloak |
|
Postgres |
|
Access control |
|
Cluster setup |
|
Persistence |
|