灾难恢复
明确灾难恢复模式等进行数据分析平台是至关重要的砖。bob体育客户端下载对一些公司来说,这是至关重要的,你的团队可以使用砖平台数据即使在罕见的情况下区域service-wide云服务提供者中断,是否引起的地区灾难就像一个飓风或地bob体育客户端下载震或其他来源。
砖通常是一个生态系统整体数据的核心部分,包括许多服务,包括上游数据摄入服务(批/流),谷歌云存储等云本地存储等下游工具和服务商业智能应用程序,和编制工具。你的一些用例可能特别敏感地区service-wide停机。
本文描述的概念和一个成功的灾难恢复解决方案的最佳实践的砖统一的分析平台。bob体育亚洲版bob体育客户端下载每个组织都是不同的,所以如果你有当部署自己的解决方案的问题,请联系您的砖的代表。
灾难恢复的概述
灾难恢复是一套策略、工具和程序,使重要的技术基础设施和系统的恢复或延续自然或人为灾难。像Google这样的大云服务云服务许多客户和内置的守卫一个失败。例如,区域是一组建筑物连接到不同的电源保证单个功率损耗不会关闭。然而,云地区的失败可能发生,破坏的程度及其对组织的影响也各不相同。
在实施灾难恢复计划之前,重要的是要理解之间的差异灾难恢复(博士),高可用性(公顷)。
高可用性是一个系统的弹性特征。高可用性保证最低级别的操作性能通常定义的一致的正常运行时间或正常运行时间的百分比。高可用性实现到位(在同一地区作为你的主系统)设计主系统的一个特征。例如,谷歌云等云服务高可用性服务,如谷歌云存储。高可用性不需要从砖客户重要的明确的准备。
相比之下,一个灾难恢复计划需要决策和解决方案,为您的特定组织工作为关键系统处理一个更大的地区停电。本文讨论了常见的灾难恢复的术语,常见的解决方案,和一些最佳实践与砖的灾难恢复计划。
术语
地区的术语
本文使用以下定义区域:
主要地区:用户运行一个典型的日常互动的地理区域和自动数据分析工作负载。
二级区域:IT团队的地理区域数据分析工作负载暂时停机期间的主要地区。
Geo-redundant存储:谷歌的云geo-redundant存储各地区为坚持GCS桶使用异步存储复制过程。
重要的
灾难恢复过程,砖建议你_not依靠geo-redundant存储区域的重复数据,如两个GCS桶在你的谷歌云账户,砖创建为每个工作区。一般来说,使用深克隆表和数据转换为δ格式使用深克隆如果可能对其他数据格式。
部署状态的术语
本文使用以下定义的部署状态:
积极部署:用户可以连接到一个积极部署砖工作区和运行的工作负载。工作计划定期使用砖调度器或其他机制。数据流可以在此部署执行。一些文件可能引用作为一个活跃的部署热部署。
被动的部署:过程不运行在一个被动的部署。IT团队可以设置自动程序部署代码,配置,和其他砖的被动对象的部署。部署变得活跃只有如果当前活动的部署。一些文件可能指的是作为一个被动的部署寒冷的部署。
重要的
一个项目可以包含多个被动部署在不同地区提供额外的选项来解决地区断电。
一般来说,一个团队只有一个积极部署,所谓的一个主被动灾难恢复策略。有一个不太常见的灾难恢复解决方案策略active - active中,有两个同时积极部署。
灾难恢复行业术语
有两个重要的行业术语,你必须为你的团队理解和定义:
恢复点目标:一个恢复点目标(RPO)最大的目标是在数据(事务)可能会失去从IT服务由于重大事件。你的砖部署不存储你的主要客户数据。存储在单独的系统,如谷歌云存储或其他数据源在你的控制之下的。砖控制飞机在部分或全部存储一些对象,如就业和笔记本。砖,RPO是定义为对象,如工作的最大目标段和笔记本变化可能会丢失。另外,你对自己的客户负责定义RPO谷歌云存储或其他数据源中的数据在你的控制之下的。
恢复时间目标:恢复时间目标(RTO)是有针对性的持续时间和服务水平在一个业务流程必须灾后恢复。
灾难恢复和数据腐败
一个灾难恢复解决方案不减少数据丢失。破损的数据复制的主要地区的主要地区二级区域,这两个地区的损坏。还有其他方法来缓解这种失败,例如三角洲时间旅行。
典型的复苏工作流
砖灾难恢复场景通常在以下方式:
故障发生在一个关键服务使用在您的主要地区。这可能是一个影响砖的数据源服务或网络部署。
你与云提供商调查情况。
如果你认为你的公司不能等待要矫正的问题在主要地区,你可能会决定你需要故障转移到次要的地区。
确认同样的问题也不影响你的二级地区。
故障转移到次要的地区。
在工作区中停止一切活动。用户停止工作负载。用户或管理员要求最近的变化如果可能的话进行备份。工作是关闭,如果他们还没有失败由于停机。
在二级地区启动恢复过程。恢复过程更新路由和重命名的二级地区的连接和网络流量。
测试后,申报二级地区运营。现在可以恢复生产工作负载。用户可以登录到现在积极部署。你可以再触发器或延误工作。
在砖上下文中详细步骤,请参阅测试故障转移。
在某种程度上,问题的主要地区是减轻和你确认这个事实。
恢复(失败)你的主要地区。
停止所有工作在二级地区。
启动恢复过程的主要地区。恢复过程处理路由和重命名的连接和网络流量的主要地区。
复制数据所需的主要地区。降低复杂性,也许减少多少数据需要被复制。例如,如果有些工作是只读的运行时部署在二级,你可能不需要复制数据回到你的主要部署在主要地区。然而,你可能有一个生产工作,需要运行,可能需要数据复制回的主要地区。
测试部署的主要地区。
声明你的主要地区作战,积极部署。恢复生产工作负载。
对恢复您的主要地区的更多信息,见测试恢复(退回)。
重要的
在这些步骤中,一些数据可能发生的损失。您的组织必须定义数据丢失多少是可以接受的,你能做什么来减轻这种损失。
第一步:了解您的业务需求
你的第一步是定义和理解您的业务需求。定义哪些数据服务是至关重要的,什么是他们的预期RPO, RTO。
研究每个系统的实际公差,请记住,灾难恢复故障转移和退回可以是昂贵和有其他风险。其他风险可能包括数据丢失、数据复制如果你写错误的存储位置,和用户登录并修改错误的地方。
地图上所有的砖集成点,影响您的业务:
你的灾难恢复解决方案需要适应互动流程,自动化流程,或都有?
你使用哪个数据服务?一些可能是内部。
输入数据到云中如何?
谁使用这些数据?什么流程下游消费吗?
有第三方集成需要意识到灾难恢复变化?
确定工具或传播策略能够支持灾难恢复计划:
你们将使用什么工具来修改网络配置快?
你能预先确定您的配置,使其模块化,以适应灾难恢复解决方案在自然和可维护的方式?
通讯工具和渠道将通知内部团队和第三方(集成,下游消费者)灾难恢复故障转移和退回变化?和你将如何确认确认?
需要什么工具或特殊支持吗?
如果有哪些服务将被关闭,直到完全恢复?
步骤2:选择一个过程,满足您的业务需求
你的解决方案必须复制正确的数据在两种控制平面,数据平面和数据来源。冗余的工作区灾难恢复必须映射到不同的控制飞机在不同地区。你必须保持数据同步定期使用基于脚本解决方案,一个同步工具或CI / CD工作流。不需要同步数据从内部数据平面网络本身,如砖运行时的工人。
此外,您需要确保您的数据来源是根据需要复制的跨区域。
一般的最佳实践
一般成功的灾难恢复计划的最佳实践包括:
理解哪些流程关键业务,必须在灾难恢复运行。
清楚地识别哪些服务,数据处理,数据流是什么和在哪里存储
隔离和数据尽可能的服务。例如,创建一个特殊的云存储容器的数据灾难恢复或移动砖对象需要在灾难的一个单独的空间。
是你的责任来维护完整性中小学部署其他对象之间不存储在砖控制飞机。
警告
这是一个最佳实践不将任何数据元素存储在根GCS桶用于根DBFS访问工作区。根DBFS存储客户数据不支持生产。但是,你可以存储其他对象(如图书馆、配置文件、init脚本,和类似的数据。开发一个自动化过程复制这些对象,或者记住流程更新二次部署为手动部署。
为数据来源,在可能的情况下,建议您使用本机谷歌云工具复制和冗余复制数据到灾难恢复的地区。
选择一个恢复解决方案策略
典型的灾难恢复解决方案包含两个(或更多)工作区。你可以选择有几种策略。考虑潜在的破坏长度(小时甚至一天),努力确保工作区是全面运行,并努力恢复(失败)的主要地区。
主被动解决方案策略
一个被动的解决方案是最常见和最简单的解决方案,和这种类型的解决方案是本文的重点。解决方案的一个主动-被动同步数据和对象变化从你积极部署你的被动部署。如果你喜欢,你可以有多个被动部署在不同的地区,但本文主要关注单一被动的部署方法。在事件中,灾难恢复的被动部署在二级地区成为你积极部署。
有两种主要的变异的策略:
统一(enterprise-wise)解决方案:一个主动和被动的部署,支持整个组织。
解决方案由部门或项目:每个部门或项目领域维护一个单独的灾难恢复解决方案。一些组织想解耦灾难恢复细节部门之间和使用不同的主要和次要区域为每个团队根据每个团队的独特需求。
还有其他的变种,如使用被动部署为只读的用例。如果你有工作负载是只读的,例如用户查询,他们可以在任何时候运行在一个被动的解决方案如果不修改数据或砖对象如笔记本或工作。
active - active解决方案策略
在一个active - active的解决方案,您运行所有数据进程并行在这两个地区。运营团队必须确保数据流程等工作仅标记为完成当它完成成功地在这两个地区。对象不能更改在生产中,必须遵循严格的CI / CD从开发/分段生产推广。
一个active - active的解决方案是最复杂的策略,因为这两个地区的工作运行,有额外的财务成本。
正如主被动策略,可以实现这个解决方案或由部门统一组织。
你可能不需要一个等价的工作区中所有工作区辅助系统,根据您的工作流程。例如,也许开发或分期工作区可能不需要一个副本。用精心设计的开发过程,你可以重建这些工作区容易如果需要。
选择你的工具
主要有两种方法工具保持数据尽可能相似的工作区之间在你的主要和次要区域:
同步客户端复制从主要到次要的:同步客户端将生产数据和资产的主要地区二级地区。这通常运行在一个预定的基础。
CI / CD为并行部署工具:对于生产代码和资产,使用CI / CD的工具同时推动改变生产系统这两个地区。例如,当把代码和资产分期/从开发到生产,CI / CD系统使得它可以在这两个地区在同一时间。的核心思想是将所有工件在砖infrastructure-as-code工作区。大多数工件可以重新部署到初级和二级工作区,虽然有些工件可能只需要部署灾后复苏的事件。工具,请参阅自动化脚本、样品和原型。
下图对比这两种方法。
根据您的需要,您可以结合的方法。例如,使用CI / CD笔记本源代码,但使用同步配置池和访问控制等。
下表描述了如何处理不同类型的数据,每个工具的选择。
描述 |
如何处理与CI / CD工具吗 |
如何处理与同步工具 |
|---|---|---|
源代码:笔记本源包装出口和源代码库 |
Co-deploy主要和次要的。 |
同步源代码从主要到次要的。 |
用户和组 |
在Git管理元数据配置。另外,使用相同的身份提供商(IdP)为工作区。Co-deploy用户和组数据主要和次要的部署。 |
使用SCIM对这两个地区或其他自动化。手动创建不使用推荐的,但是如果必须同时完成。如果使用手动设置,创建一个调度自动化流程比较两国部署的用户和组列表。 |
池配置 |
可以在Git模板。Co-deploy中小学。然而, |
池创建任何 |
工作配置 |
可以在Git模板。主要部署,部署工作定义。二次部署,部署工作,将并发设置为零。这禁用的工作部署和防止额外的运行。改变后并发值二次部署变得活跃。 |
如果工作在现有运行 |
访问控制列表(acl) |
可以在Git模板。Co-deploy中小学部署笔记本,文件夹,和集群。然而,持有的数据工作,直到灾难恢复活动。 |
的权限API 2.0可以为集群设置访问控制、工作、池,笔记本,文件夹。同步客户端需要为每一个对象映射到相应的对象id在二级工作区。砖建议创建一个地图对象的id从初级到中级工作区而同步这些对象之前复制的访问控制。 |
库 |
包括源代码和集群/工作模板。 |
从集中式存储库同步自定义库、DBFS或云存储(可以安装)。 |
如果你喜欢包含在源代码。 |
对于简单的同步,init脚本存储在主工作区在公共文件夹或在一个小的文件夹,如果可能的话。 |
|
挂载点 |
包含在源代码中如果只有通过notebook-based或创造就业机会命令API。 |
使用工作。注意,存储端点可能会改变,因为工作区将会在不同地区。这在很大程度上取决于你的数据灾难恢复策略。 |
表元数据 |
包括源代码如果只有通过notebook-based或创造就业机会命令API。这适用于内部砖metastore metastore或外部配置。 |
比较metastores之间的元数据定义使用火花目录API或显示创建表通过笔记本或脚本。注意,表底层存储可以提出,将不同metastore实例。 |
秘密 |
如果只有通过创建包含在源代码命令API。注意,一些机密内容可能需要中小学之间的变化。 |
秘密是两个工作区中创建通过API。注意,一些机密内容可能需要中小学之间的变化。 |
集群配置 |
可以在Git模板。Co-deploy中小学部署,尽管次要的部署应该终止,直到灾难恢复活动。 |
创建集群后同步到二级工作区使用API或CLI。这些可以明确如果你想终止,根据auto-termination设置。 |
笔记本,工作,和文件夹权限 |
可以在Git模板。Co-deploy中小学部署。 |
复制使用权限API 2.0。 |
选择区域和多个二级工作区
你需要完全控制你的灾难恢复触发。你可以决定触发这个在任何时间或任何理由。你必须负责灾难恢复稳定才能重新启动操作退回(正常生产)模式。通常这意味着您需要创建多个砖工作区来满足您的生产和灾难恢复的需求,并选择你的二次故障转移。
在谷歌的云,你可以选择中等地区的完全控制。确保你所有的可用资源和产品。只在一些一些砖服务是可用的谷歌云区域。
第三步:准备工作区和做一次性复制
如果一个工作区已经在生产中,它是典型的运行一次性复制操作同步你的被动部署积极部署。这一次复制处理如下:
数据复制:复制使用云复制解决方案或δ深克隆操作。
令牌生成:使用令牌生成自动复制和未来的工作负载。
工作区复制使用描述的方法:使用工作区复制第四步:准备数据源。
工作区验证:测试确保工作区和流程可以执行成功,并提供预期的结果。
初始一次性复制操作之后,随后的复制和同步行动更快,任何日志记录从你的工具也是一个日志的改变,当它改变。
第四步:准备数据源
砖可以处理多种数据源使用批处理或数据流。
在你实现一个系统数据源,重要的是要理解GCS和BigQuery复制的区别:
BigQuery,数据复制。破损的数据可以恢复为7天(假设没有备份)。
gc使用三角洲湖、复制取决于水桶型,如单、双或多。损坏的数据可以恢复取决于真空保留。
批处理数据来源
在批处理数据时,它通常驻留在一个数据源,很容易被复制或传递到另一个地区。
例如,数据可能会被上传到云存储位置。在灾难恢复模式下对你的二级地区,您必须确保文件将上传到您的二级地区存储。工作负载必须阅读二级区域存储和写入二级区域存储。
数据流
处理数据流是一个更大的挑战。流数据可以从各种来源摄取、处理和发送到流媒体解决方案:
消息队列,如卡夫卡或PubSub Lite
数据库变化数据捕获流
基于文件的连续处理
基于文件的安排处理,也称为触发一次
在所有这些情况下,您必须配置您的数据源处理灾难恢复模式和使用你的二级地区二级部署。
流作家存储检查点与被处理的数据信息。该检查点可以包含一个数据位置(通常是云存储),已被修改成一个新位置,以确保一个成功重启的流。例如,源子文件夹下检查点可能云存储文件的文件夹。
必须及时复制该检查点。考虑同步检查点间隔的任何新的云复制解决方案。
作家的检查点更新是一个函数,因此适用于数据流摄入或处理和存储在另一个流源。
对于流媒体工作负载,确保配置在customer-managed存储检查点,这样他们就可以被复制到二级地区工作负载恢复从去年的失败。你也可以选择在并行运行二次流过程的主要过程。
第五步:实现和测试您的解决方案
定期测试灾难恢复设置,以确保其功能正常。没有价值在维护一个灾难恢复解决方案如果你不能使用它,当你需要它。一些公司之间切换地区每隔几个月。定期切换区域测试假设和流程,确保他们满足你的恢复的需求。这也确保您的组织的政策和程序熟悉紧急情况。
重要的
在现实条件下定期测试灾难恢复解决方案。
如果你发现你失踪一个对象或模板和仍然需要依靠信息存储在主工作区,修改你的计划来消除这些障碍,复制这个信息在二级系统,或在其他方式使其可用。
测试所需的组织变更流程和配置。灾难恢复计划影响您的部署管道,重要的是,你的团队知道需要保持同步。建立灾难恢复工作后,您必须确保您的基础设施(手动或代码),工作,笔记本,图书馆,和其他工作区对象在你的二级地区。
与您的团队讨论如何扩大标准工作流程和配置管道将更改部署到所有工作区。在所有工作区管理用户身份。记得要配置工具,如工作自动化和监测新工作区。
计划和测试修改配置工具:
摄入:了解你的数据来源是哪里,那些得到他们的数据来源。在可能的情况下,参数化源和确保你有一个单独的配置模板来处理你的二级和二级地区部署。准备一份计划,故障转移和测试所有的假设。
执行变更:如果你有一个调度器触发工作或其他操作,您可能需要配置一个独立的调度程序,适用于二级部署或其数据源。准备一份计划,故障转移和测试所有的假设。
交互式连接:考虑如何配置、验证和网络连接可能会影响区域中断任何使用REST api, CLI工具,或其他服务,如JDBC / ODBC。准备一份计划,故障转移和测试所有的假设。
自动化的变化:自动化工具,准备一个计划为故障转移和测试所有的假设。
输出:对于任何工具,生成输出数据或日志,准备一个计划为故障转移和测试所有的假设。
测试故障转移
灾难恢复可以由许多不同的场景。它可以由一个意想不到的休息。一些核心功能可能发生故障,包括云计算网络,云存储,或者另一个核心服务。您没有访问关闭系统优雅和必须努力恢复。然而,这个过程可以由关机或停机计划,甚至通过周期性切换两个地区之间的积极部署。
当你测试故障转移时,连接到系统并运行一个关闭的过程。确保所有工作完成和集群被终止。
同步客户端(或CI / CD工具)可以复制相关数据砖二级工作区对象和资源。激活你的二级工作区,过程可能包括下列部分或全部:
平台运行测试确认是最新的。bob体育客户端下载
在主节点上禁用池和集群地区,如果没有在线服务返回,不开始处理新的数据的主要区域。
恢复过程:
检查最新的同步数据的日期。看到灾难恢复行业术语。这一步的细节变化基于如何同步数据和您的独特的业务需求。
稳定你的数据源,并确保他们都是可用的。包括所有的外部数据源,例如谷歌云SQL, BigQuery,或PubSub,以及三角洲湖,拼花,或其他文件。
找到你的流恢复点。设置过程从那里重新开始,有一个准备过程识别和消除潜在的重复(三角洲湖湖使这更容易)。
完成数据流过程和通知用户。
开始相关池(或增加
min_idle_instances相关数字)。启动相关的集群(如果不是终止)。
改变工作和运行的并发运行的相关工作。这可能是一次性或定期运行运行。
任何外部工具,它使用一个URL或域名砖工作区,更新配置占新的控制飞机。例如,更新url REST api和JDBC / ODBC连接。砖的web应用程序的面向客户的URL更改控制平面的变化,所以通知您组织的用户的新URL。
测试恢复(退回)
退回可以做更容易控制和维护窗口。这个计划可以包括下列部分或全部:
得到确认的主要地区是恢复。
禁用池和集群在二级地区所以它不会开始处理新的数据。
同步任何新的或修改资产在二级工作区主要部署。根据您的故障转移脚本的设计,您可以运行相同的脚本,以同步对象从二级(灾难恢复)地区主要的(生产)区域。
任何新的数据更新同步回主部署。您可以使用日志和三角洲表的审计跟踪保证不丢失数据。注意,一些管理数据源有限的时间窗口使用自动快照进行恢复。例如,谷歌BigQuery七天的限制数据恢复。
在灾难恢复地区关闭所有工作负载。
改变工作和用户的URL的主要地区。
平台运行测试确认是最新的。bob体育客户端下载
开始相关池(或增加
min_idle_instances数量有关)。启动相关的集群(如果不是终止)。
改变工作的并发运行,运行相关工作。这可能是一次性或定期运行运行。
再根据需要,设置二级地区未来的灾难恢复。
自动化脚本、样品和原型
自动化脚本考虑为您的灾难恢复项目:
砖建议您使用砖起程拓殖的提供者帮助开发自己的同步过程。
另请参阅砖工作区迁移工具示例脚本自动化和原型。
的砖同步(DBSync)项目是一个对象同步工具,备份,恢复和同步数据砖工作区。