TackerDB 和 KubernetesDB 之间的数据库同步¶
https://blueprints.launchpad.net/tacker/+spec/database-synchronization
问题描述¶
在当前实现中，TackerDB 和 VIM DB（Kubernetes 中的 etcd 等 KubernetesDB）仅在执行 SOL002 修复时同步。但是，当 Kubernetes 自动修复或自动扩展并且 pod 重启时，信息仅反映在 KubernetesDB 中，而不会反映在 TackerDB 中。因此，会出现以下问题：
当用户使用命令或 API 获取 Pod 资源的信息时，他们会看到存储在 TackerDB 中的信息，并获得过时的输出。
如果用户尝试在数据库不一致时进行扩展，Pod 将以用户不希望的数量进行扩展，因为它会查看和处理旧信息。
注意
现有的修复过程已经支持同步 Pod 信息的能力。
本规范假定以下更改
添加 TackerDB 和 KubernetesDB 之间 Pod 信息的定期同步
提议的变更¶
以下功能包含在本规范中：
定期检索 TackerDB 和 KubernetesDB 持有的 pod 信息，比较数据，如果存在差异，则从 KubernetesDB 更新 TackerDB。
注意
当通过同步处理更新 TackerDB 时，信息将显示在日志中。日志包含旧 pod 和新 pod 的名称。
启用配置以指定同步频率。
TackerDB 中要更新的属性如下
vnf_instantiated_info.scaleStatus.scaleLevel：根据从 KubernetesDB 检索到的 Pod 数量计算 scaleLevel，如果与 TackerDB 不同，则进行更新。
vnf_instantiated_info.vnfc_resource_info：如果正在运行的 Pod 数量发生变化，则增加或减少 vnfcResourceInfo 中的数据数量，以匹配正在运行的 Pod 数量。
vnf_instantiated_info.vnfc_resource_info.computeResource.resourceId：使用新的资源 ID（Pod 名称）更新 resourceId。
VnfInstanceV2.instantiatedVnfInfo.scaleStatus.scaleLevel：根据从 KubernetesDB 检索到的 Pod 数量计算 scaleLevel，如果与 TackerDB 不同，则进行更新。
VnfInstanceV2.instantiatedVnfInfo.vnfcResourceInfo：如果正在运行的 Pod 数量发生变化，则增加或减少 vnfcResourceInfo 和 VnfInstanceV2.instantiatedVnfInfo.vnfcInfo 中的数据数量，以匹配正在运行的 Pod 数量。
VnfInstanceV2.instantiatedVnfInfo.vnfcResourceInfo. computeResource.resourceId：使用新的资源 ID（Pod 名称）更新 resourceId。
注意
从 KubernetesDB 获取以下资源信息
Pod
Deployment
Replicaset
Daemonset
StatefulSet
受 StatefulSet 控制的 Pod 具有静态名称，因此即使 Kubernetes 重建它们，resourceId 也不会更改。但是，Tacker 必须获取当前 Pod 数量才能在 DB 同步期间更新 ScaleStatus。
TackerDB 和 KubernetesDB 之间的同步¶
定期数据库同步¶
此功能定期同步 Pod 资源相关的 TackerDB 和 KubernetesDB 之间的信息。
下图显示了数据库同步。
+----------------------------------------------------------+
| VNFM |
| +-----------------------+ |
+-------------------------------+ | | Tacker-conductor | |
| Kubernetes | | | +--------------+ | |
| | | | | VnflcmDriver | | |
| +--------------------------+ | | | | (v1/v2) | | |
| | Master | | | | +---+----------+ | |
| | | | | | | 1. Start periodic database synchronization |
| | | | | | | | |
| | | | | | | | |
| | +------+ +---------+ | | | | +---v----------+ | |
| | | etcd | | | | | | | | Kubernetes | | +-----------+ |
| | | |<-->|kube- |<---------------------------+ InfraDriver +------------------->| TackerDB | |
| | +------+ |apiserver| | | 3. Get pod | | | | | | | |
| | | | | | information | | +--------------+ | +-----------+ |
| | | | | | | | 4. Check difference | 2. Get pod information |
| | | | | | | | | |
| | | | | | | | | 5. If there are difference, |
| | +---------+ | | | | | update pod information |
| | | | | | | |
| +--------------------------+ | | +-----------------------+ |
| | | |
+-------------------------------+ +----------------------------------------------------------+
定期数据库同步序列
在 Config 中指定的间隔内，定期启动数据库同步过程
KubernetesInfraDriver 检索存储在 TackerDB 中的 Pod 信息
KubernetesInfraDriver 检索 KubernetesDB 中当前正在运行的 Pod 名称和 Pod 数量
KubernetesInfraDriver 比较这两部分信息
比较包括
Pod 名称
正在运行的 Pod 数量
如果存在差异，KubernetesInfraDriver 会将 Pod 信息和 scaleLevel 更新到 TackerDB。
任何目标实例的 LCM 请求都将被 HTTP 409（冲突）拒绝。
步骤 1’ 到 5’ 描述了 LCM 过程期间 DB 同步冲突的详细信息。如果 DB 同步需要影响正在进行的 LCM 程序实例，则将跳过该实例的 DB 同步。
间隔计时器的配置¶
Config 可以设置一个计时器，以同步 TackerDB 和 KubernetesDB 之间的 pod 信息。
此配置适用于 v1 和 v2 API。
默认值为 300 秒。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
当同时执行数据库同步和 LCM 操作时，可能会发生争用。
如果在正在对 VNF 实例进行定期数据库同步的同时，对同一 VNF 实例执行 LCM 操作，Tacker 将响应“409 冲突”，并且不会执行 LCM 操作。
如果在 VNF 实例的 LCM 操作期间对 VNF 实例执行数据库同步，则跳过数据库同步。
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
Masaki Ueno <masaki.ueno.up@hco.ntt.co.jp>
- 其他贡献者
Hideki Matsuda <matsuda.hideki1@fujitsu.com>
Ayumu Ueha <ueha.ayumu@fujitsu.com>
Yoshiyuki Katada <katada.yoshiyuk@fujitsu.com>
新見雄介 <niimi.yusuke@fujitsu.com>
工作项¶
支持定期数据库同步
添加有关检查数据库同步间隔的新配置
添加新的单元和功能测试
依赖项¶
无
测试¶
将添加单元和功能测试，以涵盖规范中所需的情况。
文档影响¶
将添加完整的配置指南，以解释有关指定同步间隔之间的配置。
参考资料¶
无
