Federated Config Servers

Federated Config Servers

Federated Config Servers describes an environment where two or more Audrey Config Servers are able to share instance configurations between each other to facilitate the configuration of guests in disparate back ends.

{{toc}}

Glossary

• Federation: allow interoperability and information sharing between decentralized components in an architecture
• Federated deployment: a deployment of virtual machines across multiple unique back end cloud providers that must share configuration information
• Federated Config Server: one or more Audrey Config Servers deployed to otherwise disconnected environments that must cooperate in the configuration of federated deployments
• Topic: an artifact of a message driven architecture over which participants can publish and subscribe to messages

Purpose

The purpose of federated config servers is to provide a mechanism for instances launched as part of the same deployment but in separate back ends to still share deployment configuration information through their respective config servers. The assumption is that the Config Servers in disparate back ends would be connected to a shared network via a VPN or something similar (see LINK_ME((Assumptions))LINK_ME below).

Implementation

The implementation is summarized as two parts:

1. Changes to Config Server to broadcast configuration changes received from guests in a particular deployment
2. The addition of Qpid as a messaging service to transmit the configuration changes that Config Server broadcasts

Changes to Config Server

• additional logic to broadcast “PUT /params/$version/$uuid”
• additional logic for Config Server to register with Qpid broker
• additional logic for Config Server to register as publisher/subscriber to each topic

Qpid as a messaging service

Introducing Qpid as a messaging service provides three key pieces of functionality:

• message broadcast from sender to multiple receivers
• reliable delivery of durable messages
• federation through dynamic exchange routes

Topic management

• new topic would be created for each deployment

Route management

• dynamic exchange routes are established between brokers to provide federation of messages from config servers

Security

• Data transmission encryption
• Config Server authentication with Qpid broker

Assumptions

Assumption: Network connectivity

This proposal assumes two key factors about network connectivity:

1. Federated Config Servers are connected to a shared network
   • this document does not propose a specific solution to the shared networking problem
2. The deployed instances are not connected to a shared network
   • if all deployed instances are connected to a shared network (e.g., VPN), then there is no need for Federated Config Servers since all guests could reach a single shared Config Server

Assumption: Deploying to multiple back ends

This proposal assumes that Conductor will provide a way to separate out the instances in a single deployment to launch in multiple back ends. And example of such a deployment could be a multi-tiered application where the application servers and database servers should be launched on RHEV running internally, while the proxy web servers should be launched in EC2 externally.

Questions

Q: What changes are expected to the setup of new Config Server?

Q: What changes are expected to the launch process in Conductor?

• How does conductor launch a single deployment across multiple back ends?