为了解决这个问题,Openshift上的容灾需要的解决方案应是:
- 容器颗粒度的
- Kubernetes命名空间可感知的
- 应用一致的
- 能够备份数据和应用配置
- 能够为数据中心提供同步和异步备份的不同方式
Portworx企业版数据平台的PX-DR就是按照以上的原则设计的。
apiVersion: stork.libopenstorage.org/v1alpha1
kind: Rule
metadata:
name: cassandra-presnap-rule
spec:
– podSelector:
app: cassandra
actions:
– type: command
value: nodetool flush
例如,一个银行有本地部署的数据中心,并且通过专线连接到了一个AWS数据中心,可能会需要为一个重要商业应用选择零RPO的DR策略,同时要求RTO<1分钟。在这种情况下,我们倾向于推荐同步备份的PX-DR,由于两个环境的延时极低,因此可以提供零数据损失的恢复。
另一个例子,如果一个制造业的公司在较远的两地有两个数据中心,应用要求较低的RTO,但按每小时的备份频率对于RPO的目标来说已经足够了,在这种情况下,异步备份的PX-DR,使用连续增量式的备份就已经足够。
下面是不同情况下OpenShift DR策略的选择
较远网络的OpenShift容灾策略(两个站点之间的往返延迟 >10毫秒的情况)
通过集群域,Portworx数据管理层来区分主站点和容灾站点。集群域在Portworx集群被安装的时候就会配置完成。在每一个OpenShift集群上(主集群或DR集群)配置Portworx来包括同一个Key-value的存储端点和集群名称,但使用不同的集群域来区分主站点和DR站点,看下面的例子。
Primary DR Site args: [“-k”, “etcd:http://etcd:2379”, “-c”, “px-cluster-synchronous”, “-s”, “type=gp2,size=250”, “-secret_type”, “k8s”, “-cluster_domain”, “primary” “-x”, “kubernetes”] “` args: [“-k”, “etcd:http://etcd:2379”, “-c”, “px-cluster-synchronous”, “-s”, “type=gp2,size=250”, “-secret_type”, “k8s”, “-cluster_domain”, “dr-site” “-x”, “kubernetes”]
低延时要求
$ ping ip-10-0-131-167 PING (10.0.131.167) 56(84) bytes of data. 64 bytes from (10.0.131.167): icmp_seq=1 ttl=255 time=0.019 ms 64 bytes from (10.0.131.167): icmp_seq=2 ttl=255 time=0.028 ms 64 bytes from (10.0.131.167): icmp_seq=3 ttl=255 time=0.035 ms 64 bytes from (10.0.131.167): icmp_seq=4 ttl=255 time=0.029 ms 64 bytes from (10.0.131.167): icmp_seq=5 ttl=255 time=0.028 ms ^C — ip-10-0-131-167.us-west-2.compute.internal ping statistics — 5 packets transmitted, 5 received, 0% packet loss, time 4080ms rtt min/avg/max/mdev = 0.019/0.027/0.035/0.008 ms
Setup Openshift集群配对
一旦完成两个站点都在运行Portworx,在正确的集群域设定基础上,它们就可以正常的来Sync了。我们可以通过Portworx命令 “` $ pxctl cluster domains show “` 来进行验证。验证完成后,并且两个集群域都是正常的情况下,就可以创建集群配对对象。这样两个站点就可以共享一个OpenShift应用YAML文件。这些YAML文件代表了应用的配置,对于在出问题时保证低RTO有着重要的作用。首先为目标命名空间产生集群配对,然后把YAML文件应用到主站点上。
$ storkctl generate clusterpair -n appns dr-site > dr-site.yaml
$ oc create -f dr-site.yaml
可以通过下面的命令来验证集群配对。
$ storkctl get clusterdomainsstatus
创建一个调度和迁移
取决于你的组织的RTO要求,你可以选择应用的sync频率。通过创建一个策略来定义调度,然后把调度和应用的迁移关联起来。
首先,创建一个调度,下面的例子中在每一分钟迁移应用配置。把它保存成一个Yaml文件,然后使用`oc create -f` 来创建策略。
apiVersion: stork.libopenstorage.org/v1alpha1
kind: SchedulePolicy
metadata:
name: sched-policy
namespace: appns
policy:
interval:
intervalMinutes: 1
daily:
time: “10:14PM”
weekly:
day: “Thursday”
time: “10:13PM”
monthly:
date: 14
time: “8:05PM”
接下来,创建一个迁移:针对 “appns”命名空间、“dr-site”集群配对、和使用这个调度。注意文件最下方的“schedulePolicyName”。存成一个yaml文件,然后通过` oc create -f` 来应用它。
apiVersion: stork.libopenstorage.org/v1alpha1
kind: MigrationSchedule
metadata:
name: migrationschedule
namespace: appns
spec:
template:
spec:
clusterPair: dr-site
includeResources: true
startApplications: false
includeVolumes: false
namespaces:
– demo
schedulePolicyName: sched-policy
注意以上仅仅设定includeResources是true,而设定其他的都是false,因为同步DR集群已经在两个集群上都配置了数据,因此我们不再需要include卷,并且直到有系统错误发生前,我们也不想启动这个应用。如果我们使用异步PX-DR方式,我们需要把`includeVolumes` 改为true。
你可以通过运行下面的命令来验证迁移是否已经完成。
$ storkctl get migration
通过OpenShift DR站点来恢复
现在OpenShift集群都已经sync完成,应用也sync完成。我们准备好来恢复应用了。当一个主站点的灾难发生后,下面的步骤即可在DR站点上恢复,并且是零RPO。
首先,关闭主站点,等待域变成 (NotInSync)
$ storkctl deactivate clusterdomain ocs-primary
$ storkctl get clusterdomainsstatus
接下来,如果你有权限访问主站点,把复制集变成0。如果你没有权限访问主站点,直接走到下一步,在容灾站点上恢复应用。
$ oc scale deploy -n demo –replicas=0 –all
通过向迁移调度增加 `suspend:true` ,并且更新spec,可以暂停迁移
apiVersion: stork.libopenstorage.org/v1alpha1
kind: MigrationSchedule
metadata:
name: migrationschedule
namespace: appns
spec:
template:
spec:
clusterPair: dr-site
includeResources: true
startApplications: false
includeVolumes: false
namespaces:
– demo
schedulePolicyName: sched-policy
suspend: true
$oc apply -f migration-schedule.yaml
最后,在DR站点上,启动迁移,打开DR站点上的Pods。
$ storkctl activate migration -n appns
你的“appns”命名空间里的应用现在已经在OpenShift DR站点上重启了,并且是0数据损失。
PX-DR包括一个API可以自动化的实现上面的步骤,另外,当主站点又重新启动后,应用的配置和数据会重新被sync,这样就可以重新在主站点上启动应用。
登录后评论
立即登录 注册