混合云和多云基础设施在企业的IT环境中越来越普遍，因为它提供了一套比从单一云中获得的更好的能力。具体来说，它允许我们在单一环境中为不同的使用场景使用不同的云服务，有助于避免厂商锁定。同时使用内部环境和云环境使我们有可能使用两个世界的最好的东西，让用户按照自己的节奏过渡到云；如今，对于具有相当规模的企业来说，只存在于其中一个环境是非常罕见的。
对混合基础设施的新需求，以及随之而来的向云的迁移，加速了自动化在整个企业中的应用，企业采用了相关技术，包括微服务架构和容器的使用。现代混合基础设施需要一个统一的平台来管理多个环境中的容器，这就是Kubernetes出现的地方。它可以自动部署、管理和扩展企业内的容器化应用。
Banzai Cloud Pipeline平台允许企业在单云、多云或混合云环境中运行其工作负载，提供一个统一的平台。
在混合基础设施中，服务抽象化成为一种必要，因为与工作负载一样，服务可以根据其需求、速度、成本和合规性要求而到处存在。因此，需要一个统一的基础设施层来提供服务之间的无缝、安全和可靠的连接，无论这些服务在混合基础设施中存在于何处。
服务网是基础设施中的一个新层，处理服务之间的所有通信。它独立于每个服务的代码，因此它可以与多个服务管理系统一起工作，并跨越网络边界，没有问题。它的功能在服务之间创建和管理连接，安全而毫不费力。
混合基础设施中的服务故障转移 🔗︎
混合云基础设施的用途之一是通过将工作负载和服务部署到多个环境中来提供高可用性，可以是内部环境和公共云，也可以是两个公共云。下面的例子说明了如何用Backyards建立这样一个环境。
本例将使用三个集群。一个用于Backyards控制平面和面向客户的入口网关，两个用于不同云提供商的工作负载集群。Backyards带有一个内置的演示应用程序，它将被安装到两个工作负载集群上，以演示自动的多供应商故障转移。
Backyards支持基于位置的负载平衡，这项功能用于为传入的请求提供自动故障转移。你可以在我们之前关于该主题的博文中阅读关于基于位置的负载均衡的内容。
创建三个Kubernetes集群 🔗︎
如果你需要帮助，你可以用我们的Banzai Cloud的Pipeline平台的免费版本创建集群。
实际例子中使用的集群是。
waynz0r-1009-02-aws- 控制平面和入口集群，运行在AWS上，位于eu-west-3区域。waynz0r-1009-01-aws- 工作负载集群在EW-2地区的AWS上运行waynz0r-1009-01-gke- 在欧洲-西2区的GKE上运行的工作负载集群
将KUBECONFIG 在其中一个集群 🔗︎
正如你可能知道的，思科最近收购了Banzai Cloud。目前我们正处于过渡期，正在转移我们的基础设施。请联系我们，以便我们可以讨论你的需求和要求，并组织一次现场演示。
将另外两个集群附加到服务网状结构上 🔗︎
创建一个多集群的单一网状结构就像派一样简单。用一个简单的CLI命令就可以连接集群。
~ waynz0r-1009-02-aws ❯ backyards istio cluster attach
? Are you sure to use the following context? waynz0r-1009-01-aws (API Server: https://52.56.114.116:6443) Yes
✓ creating service account and rbac permissions
✓ retrieving service account token
✓ attaching cluster started successfully name=waynz0r-1009-01-aws
✓ backyards ❯ configured successfully
✓ backyards ❯ reconciling
✓ backyards ❯ deployed successfully
✓ node-exporter ❯ configured successfully
✓ node-exporter ❯ reconciling
✓ node-exporter ❯ deployed successfully
~ waynz0r-1009-02-aws ❯ backyards istio cluster attach
? Are you sure to use the following context? waynz0r-1009-01-gke (API Server: https://35.246.99.134:6443) Yes
✓ creating service account and rbac permissions
✓ retrieving service account token
✓ attaching cluster started successfully name=waynz0r-1009-01-gke
✓ backyards ❯ configured successfully
✓ backyards ❯ reconciling
✓ backyards ❯ deployed successfully
✓ node-exporter ❯ configured successfully
✓ node-exporter ❯ reconciling
✓ node-exporter ❯ deployed successfully
检查网格状态 🔗︎
~ waynz0r-1009-02-aws ❯ backyards istio cluster status
Clusters in the mesh
Name Type Status Gateway Address Istio Control Plane Message
waynz0r-1009-02-aws Host Available [15.236.163.90] -
waynz0r-1009-01-aws Peer Available [3.11.47.43] cp-v17x.istio-system
waynz0r-1009-01-gke Peer Available [35.197.239.240] cp-v17x.istio-system
~ waynz0r-1009-02-aws ❯ backyards demoapp install -s bombardier
✓ demoapp ❯ deploying application
✓ demoapp/reconciling ❯ done name=backyards-demo, namespace=backyards-demo
✓ demoapp ❯ deployed successfully
~ waynz0r-1009-02-aws ❯ backyards -c demoapp install -s frontpage,bookings,catalog --peer
✓ demoapp ❯ deploying application
✓ demoapp/reconciling ❯ done name=backyards-demo, namespace=backyards-demo
✓ demoapp ❯ deployed successfully
~ waynz0r-1009-02-aws ❯ backyards -c demoapp install -s frontpage,bookings,catalog --peer
✓ demoapp ❯ deploying application
✓ demoapp/reconciling ❯ done name=backyards-demo, namespace=backyards-demo
✓ demoapp ❯ deployed successfully
为了使基于位置的故障转移发挥作用，需要在所有相关服务上定义OutlierDetection ，这样Envoy就可以确定实例是否不健康。下面的YAML片段必须应用在控制集群上。
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: frontpage-outlier
namespace: backyards-demo
spec:
host: "frontpage.backyards-demo.svc.cluster.local"
trafficPolicy:
loadBalancer:
localityLbSetting:
enabled: true
failover:
- from: eu-west-3
to: eu-west-2
outlierDetection:
consecutiveErrors: 7
interval: 5m
baseEjectionTime: 15m
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: bydemo-outlier
namespace: backyards-demo
spec:
host: "*.backyards-demo.svc.cluster.local"
trafficPolicy:
outlierDetection:
consecutiveErrors: 7
interval: 5m
baseEjectionTime: 15m
这个配置使得如果eu-west-3 区域的frontpage 服务中没有健康的工作负载（这是我们的入口所在），流量应该故障转移到eu-west-2 区域，这是我们的主要AWS工作负载集群所在。
让我们在ingress上公开演示应用程序的frontpage 服务，以模拟外部流量到演示应用程序。这里有一篇关于如何用Backyards做到这一点的详细帖子。
该服务的内部地址是frontpage.backyards-demo.svc.cluster.local:8080 。曝光后，外部可用的URL是http://frontpage.1pj1gx.backyards.banzaicloud.io 。
打开Backyards仪表板并测试故障转移 🔗︎
可以通过以下命令轻松访问Backyards仪表板。
~ waynz0r-1009-02-aws ❯ backyards dashboard
同时，让我们向外部URL发送一个负载，并降低AWS工作负载集群上的frontpage服务的规模，以模拟工作负载中断。我们应该看到流量模式与以下动画中的模式相似。
由于Backyards在我们的混合基础设施中提供了服务抽象和无缝、安全的通信，所以流量应该自动故障切换到GKE工作负载集群，而不会出现任何中断或打嗝。
该演示应用程序是无状态的，但是，通常情况下，情况并非如此，本文章的第二部分将介绍我们对有状态应用程序的选择。
如果企业使用的所有应用程序都是无状态的，生活就会更简单。这些应用程序的灾难恢复解决方案将很简单，就像在未受影响的区域启动新的应用程序实例并将流量导向它们。现实情况是，由于各种原因，大多数应用程序不是，或不能是无状态的。这些应用程序将它们的状态存储在数据存储中，因此灾难恢复解决方案必须将状态复制到不同的辅助位置，以便在主数据存储可能中断的情况下，不受损失。所使用的数据存储本身可能会提供开箱即用的复制功能。然而，这些往往需要一个相同类型的二级数据存储。当企业在一个云提供商上运行他们的工作流程，同时使用不同的云提供商作为恢复地点时，可能会遇到一个绊脚石，因为这两个地点的RDBMS不是100%兼容的，从而使开箱即用的复制功能失效。Kafka通过在异质环境之间复制数据来拯救这里。
通过Supertubes，我们的用户可以轻松地在Kubernetes上建立Kafka集群，然后使用MirrorMaker2实现它们之间的双向复制。
已经使用Kafka交换/存储数据的应用程序可以利用Kafka主题的双向镜像，无需任何额外的组件。在灾难恢复的情况下，这些应用可以切换到驻扎在第二地点的Kafka集群。由于使用MirrorMaker2的Supertubes设置了双向镜像，确保Kafka主题保持同步，因此辅助位置的状态已经可用。当故障地点重新上线时，MirrorMaker2确保来自镜像主题的数据被更新。这种双向镜像使得热-热设置成为可能，其中应用程序的一个实例在每个地点连续运行，都有相同的数据，因为两者都保持同步（当然，我们需要考虑到地点之间的距离可能造成的滞后）。
例如，那些不使用Kafka，而是使用RDBMS作为数据存储的应用呢？
如果应用程序不使用Kafka来存储他们的数据，可以使用额外的组件，将数据从这些数据存储中提取/发布到Kafka中，然后使用我们一直在讨论的基于MirrorMaker2的机制进行复制。这些额外的组件可以是生产者/消费者Kafka客户端应用程序，或运行在Kafka Connect框架上的CDC（变化数据捕获）连接器。
Kafka主题的双向复制与网状功能相结合，不仅限于无缝处理灾难恢复场景，还可以实现其他有用的功能，如位置感知和流量转移，等等。
启示 🔗︎
从全球基础设施的角度考虑，跨越地区、云供应商、内部数据中心的工作负载不再是一些几乎无法完成的复杂任务，需要各个领域的专业知识，因为Backyards提供了所有必要的凝聚力，在引擎罩下。Backyards与Supertubes实现的双向数据复制相辅相成，使在全球基础设施上运行工作负载成为一种无缝体验。
