云存储供应商几乎都是使用了冗余的硬件, 从而能够以服务水平协议 (SLA) 为客户提供服务, 而采用这样的冗余策略来规避有可能导致停机事件或者甚至数据丢失的现有保护漏洞也是较为常见的做法.
正如高可用性和灵活性是本地存储应用的重要性能要素一样, 这两个性能指标对于使用云存储服务的组织也是同等重要的. 云存储供应商几乎都是使用了冗余的硬件, 从而能够以服务水平协议 (SLA) 为客户提供服务, 而采用这样的冗余策略来规避有可能导致停机事件或者甚至数据丢失的现有保护漏洞也是较为常见的做法.
虽然云供应商通常都会在他们的各级基础设施中增加冗余, 但是单独使用冗余策略并不足以防止停机事件的发生. 本地组件故障, WAN 故障或者云供应商中断都会导致数据变得不可用. 至少, 使用云存储服务的组织应当部署冗余的云存储网关和冗余的 WAN 链路. 另外, 如果预算允许, 应通过采用冗余独立云 (BRIC) 集合架构以实施更高级别的冗余措施.
确定云存储服务的高可用性的第一步就是验证你从你的云算储服务供应商那里得到的保护等级. 确定你的云存储服务供应商针对你的业务需求而提供的冗余等级是非常重要的工作. 例如, 如果你的企业的数据存储策略要求所有数据都有三个副本, 那么仅仅把用户数据复制至二级数据中心的云存储供应商可能就无法满足你的数据存储策略需求了. 你可能会发现你需要更高层次的服务才能实现你所需的冗余等级.
正如云存储冗余是非常重要的一样, 还有必须予以考虑的其它注意事项. 为了实现云存储的真正高可用性, 你还需要把冗余策略应用于你与云存储的连接方式上. 云计算供应商们是以一种 "首先失败" 的心理在建设他们自己的基础设施的, 但是供应商们对于在你的本地基础设施中所使用架构是没有控制权的.
需要考虑应用冗余策略的关键所在: WAN 连接, 网关
通常, 我们会使用两种组件来提供云存储的连接性: 一个 WAN 连接和一个云存储网关, 也就是所谓的云存储控制器. 这是两个为实现高可用性而必须被解决的问题.
WAN 冗余的一个通用解决方案就是从不同的 WAN 供应商那里租用冗余的网络连接. 从理论上来说, 如果其中有一家供应商发生了中断事件, 那么你应当能够通过另一个供应商的链路来保持云的连接性.
大多数的云存储服务都是基于一个对象存储平台的. 因为大部分的本地存储都是基于块存储的, 所有我们需要有一个机制来执行块存储和对象存储之间的转换. 通常, 这样的一个任务是由云存储网关设施来完成的, 它可以为本地和云存储提供一个全局的命名空间.
有鉴于云存储网关的重要性, 防止云存储网关因出现单点故障而造成整体系统停机是至关重要的. 如果云网关是一个物理设施, 那么显而易见的解决方案就是根据你企业的具体冗余需求来部署一个或多个附加的设施. 但是物理设施的价格是相当昂贵的. 如果附加设施并不在你的预算中, 那么你还可以与你的供应商沟通以确定是否可能有其它选择方案存在. 如果高可用性是你的唯一目标, 那么你可能会发现你可以使用一个较低端的设施或者甚至一个虚拟设施来达到目的.
在使用虚拟云存储网关设施的情况下, 你将不得不考虑所需的冗余等级. 因为, 一个虚拟云网关设施真的只不过就是一个虚拟机(VM), 通过在你的服务器虚拟化基础设施中的冗余措施, 你就可以保护该设施. 值得一提的是, 虽然诸如 Hyper-V 故障转移这样的高可用性功能可以保护虚拟设施出现物理硬件故障, 但是硬件集群对于防止发生在虚拟机中的故障并没有发挥任何作用. 因此, 你应考虑是否可能需要通过部署并行虚拟设施来提供附加的保护, 这是有必要的.
当谈及云存储的高可用性时, 从过去的经历中获得经验是比较重要的. 例如, 在 2011 年, 亚马逊网络服务就由于单一可用区域中的弹性块存储资源发生故障而遭遇了一次重大的中断事件, 进而无法对读写操作请求作出响应. 虽然这种类型的大问题并没有再次出现, 但这也说明了, 即便云供应商拥有他们内置的高可用性机制, 他们还是有可能发生问题的. 所以, 制定一个针对云存储供应商遭遇数据丢失事件的到位的应急预案是一个好主意.
BRIC 架构保护数据和访问
传统观点一直认为, 当谈及确保存储可用性时, 客户往往会听任云存储供应商的摆布. 毕竟, 如果一个供应商出现了一次亚马逊曾遭遇过的中断事件, 这终究还是会影响到他们客户的. 但是, BRIC 的架构是大有裨益的.
BRIC 的工作方式类似于一个 RAID 存储阵列, 所以用户不必担忧单个磁盘出现问题, BRIC 可跨多个云运行. 通过使用这种方法, 如果云供应商发生了故障或数据丢失事件, 数据也将可以得到保护, 同时在其它云中保持了数据的可访问性.
使用 BRIC 架构的最大缺点就是成本. 虽然也有诸如 Tahoe Least-Authority 文件系统 (Tahoe-LAFS) 这样免费的开源 BRIC 实施, 但是云计算存储供应商通常会根据用户所消费的存储资源数量来计费. 如果某家组织使用 BRIC 在单独的几个云中存储数据的多个副本, 那么他们的云存储成本将成倍增加. 情况就是如此, 如果某家组织想要考虑实施一个 BRIC 架构, 那么他们应准确地预测他们未来的存储量需求并选择一个能够以最小化成本实现最大限度保护的存储方法, 这是非常重要的. 否则, 客户的云存储成本很快就会失控.
来源: http://stor.51cto.com/art/201806/576678.htm