将分析数据复制到 2DCDR 暖备用数据中心

如果有两个数据中心的热备部署，可以配置活动数据中心的分析子系统，将传入的 API 事件记录卸载到热备数据中心的分析子系统。

关于此任务

如果您有两个数据中心的灾难恢复部署，并且每个数据中心都部署了分析子系统，那么您就可以在数据中心之间复制 API 事件数据。

offload 功能用于 API 事件数据复制。 在2DCDR部署中，由于两个数据中心的管理子系统数据库内容相同，因此可从任一数据中心的管理用户界面查看所有数据中心的分析数据。

分析两个数据中心复制关键点：
  • 只能复制由 API 网关生成的 API 事件数据。 无法复制来自 V5 兼容网关的数据。
  • 该功能需要额外的 CPU、内存和存储空间。 使用 专用存储和横向扩展来满足资源需求。
  • 这种配置仍然存在门户网站没有分析数据的限制。

本任务中的步骤将您的两个数据中心分别称为 DC1（活动数据中心）和 DC2（备用数据中心）。

注：
  • 对于 OpenShift 用户 - 本文档中的示例步骤使用 命令 Kuberneteskubectl 。 在 OpenShift, 使用等效的 oc 命令代替它。
  • 若您使用的是顶级CR，则必须编辑 APIConnectCluster 该CR（即顶级CR），而非直接编辑子系统CR。
  • 若使用顶级CR(APIConnectCluster)，请确保包含部分 spec.gateway 。 如果尚未包含，则必须在添加所需属性之前先添加 部分 spec.gateway 。

过程

  1. 在DC1中，通过在管理子系统命名空间中运行此命令来识别分析摄取客户机秘密：
    kubectl -n <management namespace> get secrets | grep "\-client"

    秘密名称为 analytics-ingestion-client 或 a7s-ing-client，前缀可能为其他文本。

  2. 在 DC1中，查看分析摄取客户端秘密的内容：
    kubectl -n <management namespace> get secret -o yaml <analytics ingestion secret>
    输出应该类似于以下内容：
    apiVersion: v1
data:
  ca.crt: <ca.crt encoded certificate string>
  tls.crt: <tls.crt ncoded certificate string>
  tls.key: <tls.key encoded certificate string>
...
  3. 在 DC1 中，将 tls.key 值转换为 PKCS #8 格式。
    1. Base64 解码 tls.key 并复制到名为 tls.key 的文件：
      echo <tls.key encoded certificate string> | base64 --decode > tls.key
    2. 将 tls.key 文件内容转换为 PKCS #8，并将 Base64 编码到名为 converted_tls.key 的文件中：
      openssl pkcs8 -topk8 -in tls.key -nocrypt | base64 -w 0 > converted_tls.key
  4. 在 DC2 中，使用在步骤 2 和 3 中获得的 DC1 证书字符串和 TLS 密钥，创建或更新 analytics_offload_certificates.yaml 文件。
    如果之前没有配置分析卸载目标，则创建一个名为 analytics_offload_certificates.yaml 的新文件，并粘贴以下内容：
    apiVersion: v1
kind: Secret
metadata:
  name: offload-certificates
data:
  replication_ca.crt: <ca.crt string from ingestion secret>
  replication_tls.crt: <tls.crt string from ingestion secret>
  replication_tls.key: <converted_tls.key file contents>
    如果已经配置了其他卸载目标，请编辑现有的 analytics_offload_certificates.yaml 文件，并在数据部分添加上一步中的证书字符串：
    apiVersion: v1
kind: Secret
metadata:
  name: offload-certificates
data:
  replication_ca.crt: <ca.crt string from ingestion secret>
  replication_tls.crt: <tls.crt string from ingestion secret>
  replication_tls.key: <converted_tls.key file contents>
  existing_offload_target1_ca.crt: hGywkdWE...
  existing_offload_target1_tls.crt: kY7fW..
  ...
...
  5. 在 DC2 中，应用 analytics_offload_certificates.yaml 文件创建 offload-certificates 秘密：
    kubectl -n <analytics namespace> apply -f analytics_offload_certificates.yaml
    创建一个名为 offload-certificates 的新秘密。 通过运行验证该秘密是否存在：
    kubectl -n <analytics namespace> get secrets

    如果您之前创建了卸载目标，则会更新此秘密。

  6. 在 DC2 中，通过在管理子系统命名空间中运行此命令，识别分析摄取客户端秘密：
    kubectl -n <management namespace> get secrets | grep "\-client"

    秘密名称为 analytics-ingestion-client 或 a7s-ing-client，前缀可能为其他文本。

  7. 在DC2中，查看分析摄取客户端秘密的内容：
    kubectl -n <management namespace> get secret -o yaml <analytics ingestion secret>
    输出应该类似于以下内容：
    apiVersion: v1
data:
  ca.crt: <ca.crt encoded certificate string>
  tls.crt: <tls.crt ncoded certificate string>
  tls.key: <tls.key encoded certificate string>
...
  8. 在 DC2 中，将 tls.key 值转换为 PKCS #8 格式。
    1. Base64 解码 tls.key 并复制到名为 tls.key 的文件：
      echo <tls.key encoded certificate string> | base64 --decode > tls.key
    2. 将 tls.key 文件内容转换为 PKCS #8，并将 Base64 编码到名为 converted_tls.key 的文件中：
      openssl pkcs8 -topk8 -in tls.key -nocrypt | base64 -w 0 > converted_tls.key
  9. 在 DC1 中，使用在步骤 7 和 8 中获得的 DC2 证书字符串和 TLS 密钥，创建或更新 analytics_offload_certificates.yaml 文件。
    如果之前没有配置分析卸载目标，则创建一个名为 analytics_offload_certificates.yaml 的新文件，并粘贴以下内容：
    apiVersion: v1
kind: Secret
metadata:
  name: offload-certificates
data:
  replication_ca.crt: <ca.crt string from ingestion secret>
  replication_tls.crt: <tls.crt string from ingestion secret>
  replication_tls.key: <converted_tls.key file contents>
    如果已经配置了其他卸载目标，请编辑现有的 analytics_offload_certificates.yaml 文件，并在数据部分添加上一步中的证书字符串：
    apiVersion: v1
kind: Secret
metadata:
  name: offload-certificates
data:
  replication_ca.crt: <ca.crt string from ingestion secret>
  replication_tls.crt: <tls.crt string from ingestion secret>
  replication_tls.key: <converted_tls.key file contents>
  existing_offload_target1_ca.crt: hGywkdWE...
  existing_offload_target1_tls.crt: kY7fW..
  ...
...
  10. 在 DC1 中，应用 analytics_offload_certificates.yaml 文件创建 offload-certificates 秘密：
    kubectl -n <analytics namespace> apply -f analytics_offload_certificates.yaml
    创建一个名为 offload-certificates 的新秘密。 通过运行验证该秘密是否存在：
    kubectl -n <analytics namespace> get secrets

    如果您之前创建了卸载目标，则会更新此秘密。

  11. 在 DC1 中，编辑分析 CR，并设置 spec.external.offload 部分，如图所示：
    kubectl edit a7s
    external:
    offload:
      enabled: true
      output: |
        if  [gateway_service_name] == "<DC1 gateway service name>" {
          http {
            url => "https://<DC2 analytics ingestion endpoint>/ingestion"
            http_method => "post"
            codec => "json"
            content_type => "application/json"
            id => "offload1_http"
            ssl_certificate_authorities => "/etc/velox/external_certs/offload/replication_ca.crt"
            ssl_certificate => "/etc/velox/external_certs/offload/replication_tls.crt"
            ssl_key => "/etc/velox/external_certs/offload/replication_tls.key"
          }
        }
      secretName: offload-certificates
    其中，
    • <DC1 网关服务名称>是 DC1 中网关服务的名称。
    • <DC2 分析摄取端点>是 DC2 中分析服务的分析摄取端点。

    如果有多个卸载目标，请参阅多个卸载目标。

    保存更新的 CR 后，分析摄取 pod 将重新启动，新的 API 事件将发送到 DC2 中。
    注意： 如果您随后返回到 external.offload.output 部分编辑属性，您可能需要手动重新启动摄取 pod：
    kubectl delete pod <analytics ingestion pod>
  12. 在 DC2 中，编辑分析 CR，并设置 spec.external.offload 部分，如图所示：
    kubectl edit a7s
    external:
    offload:
      enabled: true
      output: |
        if  [gateway_service_name] == "<DC2 gateway service name>" {
          http {
            url => "https://<DC1 analytics ingestion endpoint>/ingestion"
            http_method => "post"
            codec => "json"
            content_type => "application/json"
            id => "offload1_http"
            ssl_certificate_authorities => "/etc/velox/external_certs/offload/replication_ca.crt"
            ssl_certificate => "/etc/velox/external_certs/offload/replication_tls.crt"
            ssl_key => "/etc/velox/external_certs/offload/replication_tls.key"
          }
        }
      secretName: offload-certificates
    其中，
    • <DC2 网关服务名称>是 DC2 中网关服务的名称。
    • <DC1 分析摄取端点>是 DC1 中分析服务的分析摄取端点。

    保存更新的 CR 后，分析摄取 pod 将重新启动，新的 API 事件将发送到 DC1 中。

  13. 通过对 DC2 网关服务进行测试 API 调用，并确认在 应用程序接口管理器 UI 的 探索视图 中看到 DC1 事件，来确认复制是否正常。

    要验证从 DC1 到 DC2 的复制、您必须完成管理子系统的 failover 操作，这样才能访问 DC2 中的 API Manager UI，并查看 DC2 中分析子系统的数据。

如果 API 事件没有在数据中心之间复制，那么请检查摄取 pod 日志，查看 API 调用时是否有错误信息：
kubectl logs <analytics ingestion pod>