... | ... | @@ -33,6 +33,8 @@ UC8: **Planning changes** - In more complex environments, larger and strategic c |
|
|
|
|
|
UC9: **Enabling HA** - This is somewhat related to UC2. The initial configuration is a stand-alone Kea server. The sysadmin now wants to enable HA and needs to come up with a configuration for the second server. Stork should allow extending stand-alone config into HA-enabled mode and then clone it (with the necessary changes) to the second server.
|
|
|
|
|
|
UC10: **Recovery from HA failure** - Suppose the Stork server monitors two HA partners. When one of the servers experiences a failure and is subsequently restarted, the HA partners should typically synchronize their lease databases. However, it may be impossible or unreliable in some cases. For example, two servers went into partner-down and leased the same addresses to different clients. There are possibly many other situations when manual operator intervention is required. In particular, we should enable mechanisms on Stork to fetch leases from the two servers, compare them, transfer leases from one server to another server etc. We must consider that leases may be stored in the lease files or databases.
|
|
|
|
|
|
## Configuration aspects
|
|
|
|
|
|
Kea configuration is incredibly complicated. It is unlikely that every knob would get a graphical representation in Stork. However, there are some configuration elements that are more important than others. The primary determining factor is frequency of changes. For example, adding or changing new host reservation is typically a frequent event, often happening many times per day. On the other hand, network interface is something that's typically set up once and then never changed. The following list is a recommended implementation order for the management capabilities:
|
... | ... | |