文章来源：企业网

       没有哪一个云平台是完美无缺的；任何云供应商都总存在着发生中断事件或数据丢失这样的风险。可以考虑采用一个多云模式来确保系统的冗余和备用。

        虽然供应商和分析人士对于多重云的定义各有不同，但是多云计算在一般意义上是指使用多家云供应商的公共云基础设施，例如使用谷歌计算引擎与亚马逊网络服务，或采用微软与IBM。

        使用多重云模式的理由各有不同，但其中大部分都与平台需求有关。例如，企业用户可能会使用谷歌公司的云服务来满足他们的大数据需求，但又对亚马逊网络服务(AWS)的计算与存储服务选项衷情不已。

        目前，对于多重云的最新讨论焦点集中在“主动/主动云计算冗余”话题。这就意味着企业用户会把他们的主系统部署在一个云平台上(例如AWS)，而把 他们的备用或辅助系统托管到另一个云平台(例如微软的Azure)上。之后，他们的IT团队就要持续不断地使用在两个云实例中的相同数据来更新这些冗余系统。一旦部署主系统的云平台出现中断事件，那么用户的相关工作负载就可以在备用云供应商的平台上继续运行。 当制定使用一家以上云供应商的云计算冗余计划时，有三个关键步骤需要注意。

        首先，用户必须非常了解他们自己的应用与数据的需求。必须时刻记得，他们的应用程序与数据需要同时在两个云平台上正常运行。它们应当以相同的方式运行，而且应当具有相同的运行计划，但是这些计划应当各自特别针对每一个平台。例如，企业有可能拥有一个他们认为是关键任务的库存控制系统。他们可以在 AWS上运行一个应用程序和数据的实例作为主云平台，而在Azure上运行另一个作为辅助平台。

        虽然每一个云和应用实例的功能都是保持一致的，但还是有不同的操作流程需要予以考虑。例如，每一家云供应商之间的安全机制是各不相同的，这是由于基于使用的计费模式以及其他因素造成的。IT团队必须了解不同的流程，并接受过与不同云平台之间差异性相关的针对性培训;其中就包括了如何确保不同平台之间的数据同步。

        其次，应在每一个云平台上测试每一个应用与数据。主要测试的是应用的运行性能，数据的准确性与可用性。其中，即便辅助(或备用)云平台的运行性能略低于主云平台，这也是可以接受的，因为前者是仅供临时使用的，但是在数据准确性方面则是不能有任何偏差的。

        当我们在开发一个云冗余策略时，应确保在不同云计切换过程中不会出现任何数据丢失的情况。为了做到这一点，应全面设计数据同步操作以确保万无一失。 每一个同时在主要和辅助云计算平台上运行的应用与数据实例必须在需要使用到辅助应用程序时能够拥有同步的数据。IT团队应当以尽可能小的延迟及时对云平台之间的数据库进行更新包更新，从而确保在不同云之间切换过程中不会出现数据丢失的情况。

        最后，应制订一个策略可在主云平台不可用时自动实现从主平台到辅助平台的切换。做到这一点可以有几种方法。例如，用户可以重新定向网络连接以实现不同云计算平台之间的用户切换。当主平台不可用时，建立可重新连接至辅助服务器的策略。IT团队还可以使用独立于云平台的软件来安排云应用，从而在发生停用事件时实现从主平台至辅助平台的自动切换。

         此外，还需在用户的云冗余计划中定义好实施平台切换操作的触发条件，例如，主云平台发生停用事件且持续20分钟是无法触发平台切换的，但如果停用时间持续一个小时以上则应启动平台切换。 事实上，主云平台发生故障从而迫使用户切换至辅助冗余系统的概率是比较低的。大多数供应商在他们系统内部就考虑了这个问题并设置了冗余量，所以他们并不会建议用户使用其他的云平台作为备用。

        但是，世事无常，我们有可能会在未来几年内看到一次重大的云中断。停用时间可能长达一到两天，在这种情况下基于多家供应商的云冗余计划将是至关重要的。同时，这样一个计划的成本也较低;用户只需支付一小笔费用就可以在辅助云平台上托管他们的运行代码与数据。

        然后，随着在发生停用事件时用户工作负载切换至备用系统，相关的账单也会相应变厚。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。