Supporting high availability for Tacker

Asked by Yimeng


Right now Tacker still runs in single instance, hence it still has potential single-point failure.
Is there any plan to support distributed Tacker services in future releases?

Best Regards

Question information

English Edit question
tacker Edit question
Sridhar Ramaswamy Edit question
Solved by:
Sridhar Ramaswamy
Last query:
Last reply:
Revision history for this message
Best Sridhar Ramaswamy (srics-r) said :

This was discussed few times in previous summits and midcycle meetups to take up. The end goal is to decompose the monolithic tacker-server into,

1) tacker-api-server
2) tacker-engine
3) tacker-monitor

A blueprint for #3 is written here,

Looking for contributors to work in this area.

Until then, to achieve HA you can run multiple copies of tacker-server running behind a LB. Note, one catch is these tacker-servers need to run in the same server due to a vim-credential storage.

Revision history for this message
Yimeng (yimeng) said :

When running multiple tacker-servers behind a LB, instead of running them on the same server, it is possible for them to share a fully replicated database. This may solve the issue of vim-credential storage.

The main problem is still the monitoring process. If two or more tacker-servers are monitoring the same vnfd, there will be conflicts in checking/changing the status of vnfd. So it is better that one vnfd is monitored/controlled by only one tacker-server.

One potential solution is to add an “UUID" for each tacker-server and store this ID in DB. When creating a VNFD, we should record the owner(which tacker-server) of this operation. The monitoring service on each tacker-server should only handle the vnfd that created by itself.

Revision history for this message
Yimeng (yimeng) said :

Thanks Sridhar Ramaswamy, that solved my question.