容灾系统

(IDC彭帅) 什么是？备份异地容灾的内容是什么？异地容灾对企业应用及数据库起到了安全性、业务连续性等方面的作用，因此他与私有云或者公共云起到的容灾结果是完全不同的。 大数据时代，的异地容灾变得非常重要。备份的数据往往会因为各种因素而遭到毁坏，如地震、火灾、丢失等。异地容灾解决方案的出现则可通过在不同地点建立备份系统，从而进一步提高数据抵抗各种可能安全因素的容灾能力。 随着信息技术的发展，特别是信息化程度的深入发展，企业的数据以指数方式增长，大量的数据在带给企业财富的同时，数据丢失带来的损失也越来越大，在信息化程度较高的地区，部份公司内部的数据备份方案得到实施，然而这只是解决了公司数据安全的一部分，并没有解决公司数据在本地的一些威胁，异地备份都是解决数据安全的重要部分。 UCACHE企业级灾备云服务是面向企业和组织机构团体的，利用云的特性来解决信息化异地备份/恢复、灾备、灾难恢复的云端服务，可提供面向云端、虚拟和物理环境下的数据、平台、应用备份/恢复的云服务平台，满足企业当前和未来的数据管理需要。在我们的未来，互联网、移动互联网、物联网、工业互联网行业将迎来迅猛发展，作为数据安全最后一道防线，灾备技术具有巨大的应用前景。当前，企业的每一个业务系统所关心的最主要问题就是业务如何连续运转的问题，这其中，既有业务模式方面的，也有系统支撑方面的，每一个用户或服务商都需要考虑数据的重要级别

构建高可用ZooKeeper集群 2017/01/23 | 分类： 技术架构 | 0 条评论 | 标签： ZOOKEEPER 分享到： 9 原文出处： cyfonly ZooKeeper 是 Apache 的一个顶级项目，为分布式应用提供高效、高可用的分布式协调服务，提供了诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知和分布式锁等分布式基础服务。由于 ZooKeeper 便捷的使用方式、卓越的性能和良好的稳定性，被广泛地应用于诸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系统中。 本文的目标读者是对 ZooKeeper 有一定了解的技术人员，将从 ZooKeeper 运行模式、集群组成、容灾和水平扩容四方面逐步深入，最终构建出高可用的 ZooKeeper 集群。 一、运行模式 Zookeeper 有三种运行模式：单机模式、伪集群模式和集群模式。 1.1 单机模式 这种模式一般适用于开发测试环境，一方面我们没有那么多机器资源，另外就是平时的开发调试并不需要极好的稳定性。 在 Linux 环境下运行单机模式需要执行以下步骤： 1. 准备 Java 运行环境 安装 Java 1.6 或更高版本的 JDK，并配置好 Java 相关的环境变量 $JAVA_HOME 。 2. 下载 ZooKeeper 安装包 下载地址： http://zookeeper

ZooKeeper 是 Apache 的一个顶级项目，为分布式应用提供高效、高可用的分布式协调服务，提供了诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知和分布式锁等分布式基 础服务。由于 ZooKeeper 便捷的使用方式、卓越的性能和良好的稳定性，被广泛地应用于诸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系统中。 　　 本文的目标读者是对 ZooKeeper 有一定了解的技术人员，将从 ZooKeeper 运行模式、集群组成、容灾和水平扩容四方面逐步深入，最终构建出高可用的 ZooKeeper 集群。 运行模式 　　Zookeeper 有三种运行模式：单机模式、伪集群模式和集群模式。 单机模式 　　这种模式一般适用于开发测试环境，一方面我们没有那么多机器资源，另外就是平时的开发调试并不需要极好的稳定性。 　　在 Linux 环境下运行单机模式需要执行以下步骤： 　　 1. 准备 Java 运行环境 　　　　安装 Java 1.6 或更高版本的 JDK，并配置好 Java 相关的环境变量 $JAVA_HOME 。 　　 2. 下载 ZooKeeper 安装包 　　　　下载地址： http://zookeeper.apache.org/releases.html 。选择最新的 stable 版本并解压到指定目录，我们用 $ZK_HOME

一、 概述 混合云容灾服务 （HDR）是阿里云提供的低成本高性能业务连续性保障的服务，可以为企业内部关键应用，互联网应用，乃至Hadoop大数据集群提供容灾服务。 其中的连续复制型（CDR）基于磁盘数据连续复制技术，可以为企业关键业务提供低至秒级RPO，分钟级RTO的容灾服务，极大缩短业务宕机时间，减少数据丢失损失。其一键演练，全链路监控，自动化运维等功能更是解决了传统容灾服务操作难，验证难，维护难的问题，极大提高了容灾系统的可用性，释放了容灾系统的价值。 CDR近期推出了针对阿里云上环境的跨地域和跨可用区容灾方案，可以为云上应用的业务连续性，等保合规要求等提供保障。本操作指南介绍的是一个典型的阿里云上应用跨地域整站异地容灾场景的操作方法。 二、 场景介绍 某客户已经在阿里云上杭州地域通过双AZ部署应用，做到了多可用区双活，因为业务连续指标以及合规要求，需要在异地做应用容灾。核心要求是 生产在杭州地域，要求容灾地域物理距离大，选择北京地域 5分钟以内RPO，15分钟以内RTO。 整站容灾，所有服务器在异地拉起后IP不变，避免应用配置过多修改，影响RTO 一键演练，运维人员需要每3个月在不影响生产环境的情况下，做一次操作演练 容灾架构概略图如下 全站的ECS服务器通过HDR-CDR实现秒级RPO的容灾复制 RDS数据库基于RDS跨地域复制实现数据库异地容灾

容灾通信链路设计是保障用户在合理的通信成本下成功实现容灾系统建设的重要步骤。不同的通信链路有不同的属性，如距离支持、带宽能力等，而不同的容灾技术和容灾应用对通信链路的要求并不相同。 容灾通信链路的选择 对于容灾方案，无论采用哪种容灾通信链路，都需要从信息系统灾备的实际需求出发，确定风险的类型，分析各业务系统不同的容灾要求，明确灾备系统的RTO和RPO的目标。用户还需要根据应用数据特点、可以承受的成本来选择合适的数据传输方式。容灾通信链路的选择需要解答以下问题: 容灾通信链路距离(即生产中心到容灾中心的距离)，需要根据抵御的风险类型确定，如区域性灾难需要选择异地灾备，站点灾难可选择同城灾备，系统或设备故障可选择同机房灾备。 容灾通信链路带宽，需要根据业务应用分析，明确RTO和RPO需求，从而确定需要哪种带宽链路和需要多少条。 容灾通信链路选择后，还需要根据应用系统的数据变化量、数据传输的可靠性，进行验证确认设计的链路是否满足预期的目标。目前数据远程传输的主要方式、优缺点、适合的传输距离如表所示。 容灾链路连接方式 当前业界容灾方案的通信链路基本采用“裸光 来源： CSDN 作者： Hardy晗狄 链接： https://blog.csdn.net/swingwang/article/details/103755710

容灾恢复是绝大多数企业级应用的基本要求 在没有Kubernetes也没有容器的时候，备份和恢复解决方案通常在虚拟机（VM）级别上实现。当应用程序在单个VM上运行时，容灾系统适用于这样的传统应用程序。但是，当使用Kubernetes对应用程序进行容器化管理时，这样的容灾系统就无法使用了。有效的Kubernetes容灾恢复方案必须针对容器化架构进行重新设计，并按Kubernetes的原生方式来运行。 传统的基于VM的备份和恢复解决方案，使用快照来收集数据，但这些数据对于某个具体容器化应用并不足够。因为任何一个特定的VM都将包含来自多个应用的数据。如果您尝试通过VM快照来备份APP 1，将会同时获取其他应用的多余数据。但这些数据从容器角度来看又不够：APP 1可能还会将数据存储在其他VM上。因此通过对某个单独VM的快照无法捕获所有APP1的数据。 基于分布式体系结构的现代应用需要的容灾方案，需要能够找到特定应用的所有相关数据和配置信息，并能够以零RPO（Recovery Point Objective，复原点目标）和接近零RTO（Recovery Time Object，复原时间目标）的方式进行恢复。 一个有效的Kubernetes容灾解决方案需要具备： 容器粒度的控制 能够备份数据和配置 Kubernetes命名空间感知 针对多云和混合云架构的优化 保持应用的一致性

容灾恢复是绝大多数企业级应用的基本要求 在没有Kubernetes也没有容器的时候，备份和恢复解决方案通常在虚拟机（VM）级别上实现。当应用程序在单个VM上运行时，容灾系统适用于这样的传统应用程序。但是，当使用Kubernetes对应用程序进行容器化管理时，这样的容灾系统就无法使用了。有效的Kubernetes容灾恢复方案必须针对容器化架构进行重新设计，并按Kubernetes的原生方式来运行。 传统的基于VM的备份和恢复解决方案，使用快照来收集数据，但这些数据对于某个具体容器化应用并不足够。因为任何一个特定的VM都将包含来自多个应用的数据。如果您尝试通过VM快照来备份APP 1，将会同时获取其他应用的多余数据。但这些数据从容器角度来看又不够：APP 1可能还会将数据存储在其他VM上。因此通过对某个单独VM的快照无法捕获所有APP1的数据。 基于分布式体系结构的现代应用需要的容灾方案，需要能够找到特定应用的所有相关数据和配置信息，并能够以零RPO（Recovery Point Objective，复原点目标）和接近零RTO（Recovery Time Object，复原时间目标）的方式进行恢复。 一个有效的Kubernetes容灾解决方案需要具备： 容器粒度的控制 能够备份数据和配置 Kubernetes命名空间感知 针对多云和混合云架构的优化 保持应用的一致性

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Redis也用了一段时间了，记录一下相关集群搭建及配置详解，方便后续使用查阅。 提纲 Redis安装 整体架构 Redis主从结构搭建 Redis容灾部署（哨兵sentinel） Redis常见问题 Redis安装 发行版： CentOS -6.6 64bit 内核：2.6.32-504.el6.x86_64 CPU：intel-i7 3.6G 内存：2G 下载redis，选择合适的版本 [root @rocket software]# wget http://download.redis.io/releases/redis-2.8.17.tar.gz [root @rocket software]# cd redis-2.8.17 [root @rocket redis-2.8.17]# make [root @rocket redis-2.8.17]# make test cd src && make test make[1]: Entering directory `/home/software/redis-2.8.17/src' You need tcl 8.5 or newer in order to run the Redis test make[1]: *** [test] Error 1

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Redis也用了一段时间了，记录一下相关集群搭建及配置详解，方便后续使用查阅。 提纲 Redis安装 整体架构 Redis主从结构搭建 Redis容灾部署（哨兵sentinel） Redis常见问题 Redis安装 发行版： CentOS -6.6 64bit 内核：2.6.32-504.el6.x86_64 CPU：intel-i7 3.6G 内存：2G 下载redis，选择合适的版本 [root @rocket software]# wget http://download.redis.io/releases/redis-2.8.17.tar.gz [root @rocket software]# cd redis-2.8.17 [root @rocket redis-2.8.17]# make [root @rocket redis-2.8.17]# make test cd src && make test make[1]: Entering directory `/home/software/redis-2.8.17/src' You need tcl 8.5 or newer in order to run the Redis test make[1]: *** [test] Error 1

FreeNas使用ZFS文件系统，支持一些存储虚拟化功能，如快照功能。为了保证数据可靠性，不会丢失，利用快照功能对数据进行定时自动快照保存，同时将快照同时复制同步到另一台同样的FreeNas存储上，实现主备容灾。两台FreeNas都是虚拟机，所有配置一样，主端为名称为F1,备端名称为F2 参考： http://doc.freenas.org/11/storage.html#examples-common-configuration 定期快照 定期快照任务允许在给定时间点安排创建ZFS卷和数据集的只读版本。可以快速创建快照，如果数据变化很小，则新快照占用的空间非常小。例如，没有文件更改的快照占用0 MB的存储空间，但随着对文件的更改，快照大小会更改以反映更改的大小。 快照提供了一种保存文件历史记录的巧妙方法，提供了恢复旧版本甚至已删除文件的方法。出于这个原因，许多管理员经常拍摄快照（可能每十五分钟一次），将它们存储一段时间（可能是一个月），然后将它们存储在另一个系统上（通常使用 复制任务）。这种策略允许管理员将系统回滚到特定时间点。如果发生灾难性丢失，可以使用异地快照将系统还原到上次快照的时间。 在F1上，配置定期快照 配置定期快照的时间段，保存时间等信息，本次为了测试，将定期快照设定为周一到周五，每10分钟执行一次，保存2周 创建完成后如下图所示： 在快照里面