腾讯云容灾（容灾服务器）
本文目录一览：
腾讯云是什么?有什么作用?
腾讯云有着深厚的基础架构，并且有着多年对海量互联网服务的经验，不管是社交、游戏还是其他领域，都有多年的成熟产品来提供产品服务。腾讯在云端完成重要部署，为开发者及企业提供云服务、云数据、云运营等整体一站式服务方案。
1、放置公司网站和电子商务平台
随着越来越多的公司开始通过互联网开发业务渠道，许多公司将选择将其网站放置在云服务器上，并允许用户直接通过云服务器访问它们。不仅是企业网站，还有博客，电子商务平台等。不仅安全稳定，数据安全，而且具有成本效益。
2、APP和其他应用程序
它不仅仅是一个可以放置在云服务器上的网站，诸如APP之类的应用程序以及任何希望用户访问网络的应用程序都可以放置在云服务器上。但是，应该注意的是，一般APP等应用对云服务器配置要求较高，所以尽量选择配置较高的云服务器。
3、使用云服务器来存储和共享数据
许多公司，由于数据量大，或需要实时共享。它将专门购买云服务器来存储数据。它不仅高度安全，而且提供在线下载和数据共享，非常方便。
4、云服务器放置游戏
许多小型游戏都放在云服务器或服务器上，然后才能访问它们。很多时候游戏链接不稳定或闪回，这可能是由于云服务器过载。还有一些用户专门购买云服务器与其他人进行在线玩。
Elasticsearch数据迁移与集群容灾
本文讨论如何跨集群迁移ES数据以及如何实现ES的同城跨机房容灾和异地容灾。
在ES的生产实践中，往往会遇到以下问题：
根据业务需求，存在以下场景：
如果是第一种场景，数据迁移过程中可以停止写入，可以采用诸如elasticsearch-dump、logstash、reindex、snapshot等方式进行数据迁移。实际上这几种工具大体上可以分为两类：
如果是第二种场景，数据迁移过程中旧集群不能停止写入，需要根据实际的业务场景解决数据一致性的问题：
下面介绍一下在旧集群可以停止写入的情况下进行数据迁移的几种工具的用法。
elasticsearch-dump是一款开源的ES数据迁移工具，github地址:
以下操作通过elasticdump命令将集群x.x.x.1中的companydatabase索引迁移至集群x.x.x.2。注意第一条命令先将索引的settings先迁移，如果直接迁移mapping或者data将失去原有集群中索引的配置信息如分片数量和副本数量等，当然也可以直接在目标集群中将索引创建完毕后再同步mapping与data
logstash支持从一个ES集群中读取数据然后写入到另一个ES集群，因此可以使用logstash进行数据迁移，具体的配置文件如下：
上述配置文件将源ES集群的所有索引同步到目标集群中，当然可以设置只同步指定的索引，logstash的更多功能可查阅logstash官方文档 logstash 官方文档 .
reindex是Elasticsearch提供的一个api接口，可以把数据从一个集群迁移到另外一个集群。
snapshot api是Elasticsearch用于对数据进行备份和恢复的一组api接口，可以通过snapshot api进行跨集群的数据迁移，原理就是从源ES集群创建数据快照，然后在目标ES集群中进行恢复。需要注意ES的版本问题：
如果旧集群不能停止写入，此时进行在线数据迁移，需要保证新旧集群的数据一致性。目前看来，除了官方提供的CCR功能，没有成熟的可以严格保证数据一致性的在线数据迁移方法。此时可以从业务场景出发，根据业务写入数据的特点选择合适的数据迁移方案。
一般来说，业务写入数据的特点有以下几种：
下面来具体分析不同的写入数据的特点下，该如何选择合适的数据迁移方式。
在日志或者APM的场景中，数据都是时序数据，一般索引也都是按天创建的，当天的数据只会写入当前的索引中。此时，可以先把存量的不再写入的索引数据一次性同步到新集群中，然后使用logstash或者其它工具增量同步当天的索引，待数据追平后，把业务对ES的访问切换到新集群中。
具体的实现方案为：
add only的数据写入方式，可以按照数据写入的顺序(根据_doc进行排序，如果有时间戳字段也可以根据时间戳排序)批量从旧集群中拉取数据，然后再批量写入新集群中；可以通过写程序，使用用scroll api 或者search_after参数批量拉取增量数据，再使用bulk api批量写入。
使用scroll拉取增量数据：
上述操作可以每分钟执行一次，拉起前一分钟新产生的数据，所以数据在旧集群和新集群的同步延迟为一分钟。
使用search_after批量拉取增量数据：
上述操作可以根据需要自定义事件间隔执行，每次执行时修改search_after参数的值，获取指定值之后的多条数据；search_after实际上相当于一个游标，每执行一次向前推进，从而获取到最新的数据。
使用scroll和search_after的区别是：
另外，如果不想通过写程序迁移旧集群的增量数据到新集群的话，可以使用logstash结合scroll进行增量数据的迁移，可参考的配置文件如下：
使用过程中可以根据实际业务的需求调整定时任务参数schedule以及scroll相关的参数。
业务场景如果是写入ES时既有追加，又有存量数据的更新，此时比较重要的是怎么解决update操作的数据同步问题。对于新增的数据，可以采用上述介绍的增量迁移热索引的方式同步到新集群中。对于更新的数据，此时如果索引有类似于updateTime的字段用于标记数据更新的时间，则可以通过写程序或者logstash，使用scroll api根据updateTime字段批量拉取更新的增量数据，然后再写入到新的集群中。
可参考的logstash配置文件如下：
实际应用各种，同步新增(add)的数据和更新(update)的数据可以同时进行。但是如果索引中没有类似updateTime之类的字段可以标识出哪些数据是更新过的，目前看来并没有较好的同步方式，可以采用CCR来保证旧集群和新集群的数据一致性。
如果业务写入ES时既有新增(add)数据,又有更新(update)和删除(delete)数据，可以采用6.5之后商业版X-pack插件中的CCR功能进行数据迁移。但是使用CCR有一些限制，必须要注意：
具体的使用方式如下：
如果业务是通过中间件如kafka把数据写入到ES， 则可以使用如下图中的方式，使用logstash消费kafka的数据到新集群中，在旧集群和新集群数据完全追平之后，可以切换到新集群进行业务的查询，之后再对旧的集群下线处理。
使用中间件进行同步双写的优点是：
当然，双写也可以使用其他的方式解决，比如自建proxy，业务写入时向proxy写入，proxy把请求转发到一个或者多个集群中，但是这种方式存在以下问题：
随着业务规模的增长，业务侧对使用的ES集群的数据可靠性、集群稳定性等方面的要求越来越高，所以要比较好的集群容灾方案支持业务侧的需求。
如果是公司在自建IDC机房内，通过物理机自己搭建的ES集群，在解决跨机房容灾的时候，往往会在两个机房 部署两个ES集群，一主一备，然后解决解决数据同步的问题；数据同步一般有两种方式，一种方式双写，由业务侧实现双写保证数据一致性，但是双写对业务侧是一个挑战，需要保证数据在两个集群都写成功才能算成功。另外一种方式是异步复制，业务侧只写主集群，后台再把数据同步到备集群中去，但是比较难以保证数据一致性。第三种方式是通过专线打通两个机房，实现跨机房部署，但是成本较高。
因为数据同步的复杂性，云厂商在实现ES集群跨机房容灾的时候，往往都是通过只部署一个集群解决，利用ES自身的能力同步数据。国外某云厂商实现跨机房部署ES集群的特点1是不强制使用专用主节点，如上图中的一个集群，只有两个节点，既作为数据节点也作为候选主节点；主分片和副本分片分布在两个可用区中，因为有副本分片的存在，可用区1挂掉之后集群仍然可用，但是如果两个可用区之间网络中断时，会出现脑裂的问题。如下图中使用三个专用主节点，就不会存在脑裂的问题了。
但是如果一个地域没有三个可用区怎么办呢，那就只能在其中一个可用区中放置两个专用主节点了，如国内某云厂商的解决方案：
但是重建节点的过程还是存在问题的，如上图中，集群本身的quorum应该为2，可用区1挂掉后，集群中只剩一个专用主节点，需要把quorum参数(discovery.zen.minimum_master_nodes)调整为1后集群才能够正常进行选主，等挂掉的两个专用主节点恢复之后，需要再把quorum参数(discovery.zen.minimum_master_nodes)调整为2，以避免脑裂的发生。
当然还是有可以把无法选主和脑裂这两个可能发生的问题规避掉的解决方案，如下图中国内某云厂商的解决思路：
创建双可用区集群时，必须选择3个或者5个专用主节点，后台会在一个隐藏的可用区中只部署专用主节点；方案的优点1是如果一个可用区挂掉，集群仍然能够正常选主，避免了因为不满足quorum法定票数而无法选主的情况；2是因为必须要选择三个或5个专用主节点，也避免了脑裂。
想比较一主一备两个集群进行跨机房容灾的方式，云厂商通过跨机房部署集群把原本比较复杂的主备数据同步问题解决了，但是，比较让人担心的是，机房或者可用区之间的网络延迟是否会造成集群性能下降。这里针对腾讯云的双可用区集群，使用标准的benchmark工具对两个同规格的单可用区和双可用区集群进行了压测，压测结果如下图所示：
从压测结果的查询延时和写入延时指标来看，两种类型的集群并没有明显的差异，这主要得益与云上底层网络基础设施的完善，可用区之间的网络延迟很低。
类似于同城跨机房容灾，异地容灾一般的解决思路是在异地两个机房部署一主一备两个集群。业务写入时只写主集群，再异步地把数据同步到备集群中，但是实现起来会比较复杂，因为要解决主备集群数据一致性的问题，并且跨地域的话，网络延迟会比较高；还有就是，当主集群挂掉之后，这时候切换到备集群，可能两边数据还没有追平，出现不一致，导致业务受损。当然，可以借助于kafka等中间件实现双写，但是数据链路增加了，写入延迟也增加了，并且kafka出现问题，故障可能就是灾难性的了。
一种比较常见的异步复制方法是，使用snapshot备份功能，定期比如每个小时在主集群中执行一次备份，然后在备集群中进行恢复，但是主备集群会有一个小时的数据延迟。以腾讯云为例，腾讯云的ES集群支持把数据备份到对象存储COS中，因为可以用来实现主备集群的数据同步，具体的操作步骤可以参考 。
在6.5版本官方推出了CCR功能之后，集群间数据同步的难题就迎刃而解了。可以利用CCR来实现ES集群的异地容灾：
CCR是类似于数据订阅的方式，主集群为Leader, 备集群为Follower, 备集群以pull的方式从主集群拉取数据和写请求；在定义好Follwer Index时，Follwer Index会进行初始化，从Leader中以snapshot的方式把底层的segment文件全量同步过来，初始化完成之后，再拉取写请求，拉取完写请求后，Follwer侧进行重放，完成数据的同步。CCR的优点当然是因为可以同步UPDATE/DELETE操作，数据一致性问题解决了，同步延时也减小了。
另外，基于CCR可以和前面提到的跨机房容灾的集群结合，实现两地多中心的ES集群。在上海地域，部署有多可用区集群实现跨机房的高可用，同时在北京地域部署备集群作为Follwer利用CCR同步数据，从而在集群可用性上又向前走了一步，既实现了同城跨机房容灾，又实现了跨地域容灾。
但是在出现故障时需要把集群的访问从上海切换到北京时，会有一些限制，因为CCR中的Follwer Index是只读的，不能写入，需要切换为正常的索引才能进行写入，过程也是不可逆的。不过在业务侧进行规避，比如写入时使用新的正常的索引，业务使用别名进行查询，当上海地域恢复时，再反向的把数据同步回去。
现在问题就是保证上海地域集群数据的完整性，在上海地域恢复后，可以在上海地域新建一个Follower Index，以北京地域正在进行写的索引为Leader同步数据，待数据完全追平后，再切换到上海地域进行读写，注意切换到需要新建Leader索引写入数据。
数据同步过程如下所示：
1.上海主集群正常提供服务，北京备集群从主集群Follow数据
2.上海主集群故障，业务切换到北京备集群进行读写，上海主集群恢复后从北京集群Follow数据
上线两年用户破两亿，腾讯会议还能做什么？
腾讯会议诞生于2019年12月底，上线不久便遭遇疫情突袭，赶上了在线会议的发展大势。
它是腾讯内部用户量破亿最快的产品，两年过去，腾讯会议的用户数更是再悄然间突破2亿。而腾讯云副总裁吴祖榕和腾讯会议产品总经理钱敏对此毫无感知，他们已经在高速奔跑间将用户数据抛在了脑后。
腾讯会议的成功，不但是腾讯在B端（企业端）市场的惊喜，也证明了腾讯云的可靠性。
吴祖榕告诉界面新闻等媒体，腾讯会议作为一款云原生产品，从诞生的第一天起就是基于腾讯云做开发，基础架构基于云的，腾讯云也将手上的服务器、带宽和IP资源无条件提供给腾讯会议，帮助其在疫情高发期经受住考验。
从另一方面来说，腾讯云也有了一款使用它所有基础组建开发的产品，并且经受住了两亿用户的使用考验。腾讯云也更有信息将这些服务推广给B端更多用户，这是一个互相迭代合作的链条。
IDC数据显示，中国视频会议市场规模在2024年将超过100亿元，云会议市场占比将近40%。而在中国的5000万间会议室中，使用视频会议的会议室不到1%，所有巨头都在疯狂推进企业办公产品抢占市场。
在不久前的腾讯员工大会上，公司创始人马化腾骄傲的向全体员工介绍新的“一门三杰”：企业微信、腾讯会议和腾讯文档。它们正在紧锣密鼓的部署相互打通的工作。
在新的外部竞争态势下，腾讯高层非常关心这三款产品如何形成新的合力，这也是现在和未来一段时间内，腾讯会议手头最重要的任务。
吴祖榕认为，企业微信、腾讯会议和腾讯文档的打通从某种意义上说是众望所归，从国内外趋势来看，不管是分散套件还是“all in one”的办公协同产品，最终一定要实现同一个账号的互相访问，在用户许可范围内授权。
“SaaS产品之间的联动，无论是API还是SDK形式，都是必然的趋势。”吴祖榕表示。
企业微信的会议模块本身就是由腾讯会议团队负责开发和运营的，产品设计也由两边团队共同完成。
为了推动腾讯会议和企业微信更好融合，几十名腾讯会议员工在成都与企业微信团队共同工作超过5个月时间，未来企业微信团队也会安排人到深圳进行联合开发。
下个月即将发布的新版企业微信，目前已经在腾讯内部广泛试用过，从反馈来看效果很好。
对于腾讯会议未来的演进方向预测，吴祖榕表示，SaaS类产品最重要的是开放，通过开放更多API和能力，让用户能在更多场景中使用产品。
腾讯会议的开放，包括API、SDK和文档开放等多种模式。与腾讯会议接触的合作伙伴，需求场景遍及面试场景、招聘场景、围绕CRM的场景、互动场景、咨询场景甚至是远程问诊场景。
在每个典型使用场景之下，腾讯会议都打造了一批标杆客户案例，根据用户需求不同，推出针对性的功能。
以招聘场景为例，普通人使用腾讯会议，界面上显示的是参会者的头像，而招聘场景之下使用腾讯会议，面试官看到的是候选人简历，候选人看到的可能是他接下来应该知道的信息、注意事项、在线答题的页面等等。
“软件不像硬件，有很多差异化场景。”钱敏表示，“腾讯会议需要去逐个沟通，同时兼顾好双方的商业模式”，这是一个长期过程。
做硬件生态开放，实际交付的流程已经被大大简化。
以腾讯和贝壳的交付案子举例，在不到两天的周末时间里，双方就完成了超过300间会议室的腾讯会议Rooms改造，并对贝壳的原有设备进行充分利用，整个过程非常平滑。贝壳的员工在周一上班时完全无感知，可以流畅使用腾讯会议Rooms。
“无须教育，几乎没任何门槛。”吴祖榕表示，“我对这个交付感触很大。”
而放在过去，如果是传统入驻式的视频会议，300间会议室的改造没有半年时间无法完成交付。
腾讯会议坚持不做硬件的策略，让产品在今年取得更多突破式进展。目前全球音视频硬件行业最大的厂商有两个，分别是罗技和poly，而这两家公司官网上的全球三大合作伙伴之一就是腾讯会议，另外两家合作伙伴分别是微软和Zoom。
从传统的SIP/H.323设备，到USB设备再到进一步的大屏幕，腾讯会议的硬件形态已经完整覆盖大、中和小型会议室。
腾讯会议在过去两年时间里，花费大量时间和精力保障音视频的稳定性，腾讯云的全球部署和多机房容灾能力，作用很关键。
从事后走访反馈来看，客户对腾讯会议稳定和清晰的音视频服务很认可。
“今年的infoComm展（国内最大的音视频会展）上，几乎所有展位都希望能上腾讯会议的认证，或者合作logo。”吴祖榕对此感到非常骄傲。
吴祖榕告诉界面新闻等媒体，在腾讯大厦25楼的认证实验室里，每天排队等待认证的硬件产品非常多，单靠腾讯会议自己已经很难保持认证速度，腾讯不得不委托第三方公正机构来帮忙完成认证初筛，来提升工作效率。
目前已经向腾讯会议提交认证的品牌有大约70家，通过认证的有20多家，提交测试设备的型号超过80个，通过认证的型号超过40个。
腾讯云的归档存储异地容灾能力强吗？如何购买？
找腾讯云蓝色航线购买的归档存储具有异地容灾解决方案，可将主站数据保存在多个核心存储节点上，同时将主站数据复制一份保留在归档存储CAS中，CAS 最快支持1-5分钟的数据读取，可以迅速恢复容灾数据。
发表评论
暂时没有评论，来抢沙发吧~