如何评估固态存储需求?存储与灾备

2014-11-14    来源:TechTarget中国    编辑:Eric Slack
在IT环境中部署闪存技术往往从存储的性能瓶颈着手,成本、容量、风险以及采用缓存还是分层也应加以考虑。闪存部署中的容量问题需要在现实环境中测试后得出。

  固态存储所展现出的高性能对于用户的应用程序来说无疑是很有吸引力的,不过你仍然得判断将其部署在何处、所需要的具体容量以及其使用模式。

  闪存存储可以被视为是解决应用程序性能问题的一条捷径,不过决定购买何种类型的闪存,以及用何种方式在哪里部署,这些都不是简单的问题。

  你不能靠着照搬某一套理论或数据统计表来判断选择什么类型的固态存储,部署位置以及所需的具体容量。这关系到对实际环境的具体分析,明确你所希望藉由闪存存储解决的问题。尤其是,你必须判断哪里才是性能瓶颈,实际工作负载如何,以及需要多大的性能改进空间。此外,你同时还得兼顾到现实环境中的各项限制因素。

  选择闪存存储的理由并不总是显而易见的

  想象一下你拥有一张矩阵图,在一个坐标轴上显示出具体的应用个案,比如虚拟桌面基础架构(VDI)、服务器虚拟化、大数据分析等等,并在另一个上面标识出理想的闪存选项,这实在非常美妙。不过这却是近乎不可能的事情,因为即便在同一应用环境下也有太多的变量,并且这些变量之间又会互相影响。

  举例来看,存储瓶颈的具体位置通常决定了在什么地方部署闪存技术(例如在主机端或是磁盘阵列端),但存储瓶颈和具体的使用案例关系并不大,但却和现有的存储基础架构戚戚相关。不管怎样,部署位置的判断可以影响到所使用的闪存类型(固态存储驱动器或是闪存插卡,如PCIe的插卡),以及将其部署为缓存或单独的存储层。闪存的部署类型又决定了所需的容量(分层模式会比闪存模式需要更多容量),而成本和预算又会对容量产生限制。

  而诸如使用哪一种闪存存储技术的问题在当前已经不再像几年前那样重要了。不过其它的因素,比如数据风险,需要高可用性或快速的数据增长量或许会影响到所有的使用场合。因此除了关注于使用场合和数据参数表,判断闪存存储更好的选择方式是着眼于当前的实际环境,这是首先必须清晰明确的问题。

  从存储瓶颈入手

  固态存储通常通过提升服务器的数据处理速度来解决应用程序的性能问题。从本质上看,在存储基础架构的某一环节必定会存在着瓶颈,而分析找到瓶颈所在就是确定解决方案的第一步。

  如果闪存能够成为一种准确解决方案,下述各项资源的一项或者数项通常不会显示出很高的使用率:主机处理器、主机内存、存储系统的处理器或网络带宽。要找出哪一项资源较为紧张需要在一段时间内监控其使用率,并将其和应用程序的性能进行比较。假如主机处理器近乎满负荷运作,那么存储通常不是瓶颈,应当着力解决计算资源和应用程序体系架构方面的问题。但是假如在应用程序运行很慢的一段时间内主机处理器利用率很低(假设说低于40%),这就很好地反映出存储基础架构的某处存在着瓶颈。

  基于阵列的闪存

  如果一台存储阵列的控制器一直处于“游手好闲”的状态,这就表明存储系统正在等待磁盘驱动器(存储介质固有的问题),因此这时在存储阵列中增加固态存储便是一种有用的方案。不过,假如阵列并没有设计支持闪存,那么增加固态存储或许没什么效果,因为这时装满固态存储的驱动器托架可能会将存储控制器变为新的瓶颈。

  同样地,如果控制器利用率已近饱和,将固态存储盘放入存储系统也没有什么用处。假如网络并不是问题,那么更好的解决方案应当是投资购买另一台支持固态存储盘的存储系统,比如混合阵列或全闪存阵列。但假如网络带宽有局限性,或者你无法购买另一台存储系统,那么另一种可供选择的方案是在主机服务器上安装闪存存储。

  服务器端的闪存

  主机服务器端的闪存可以是驱动器形式的固态存储盘(SATA或SAS接口)、PCIe的闪存卡或者甚至是通过双列直插式存储模块(DIMM)和存储总线相连的闪存。这些方式都使得闪存的性能更接近应用程序的处理器而非网络附加的存储阵列,从而通过降低延迟提供了更好的存储性能。照以往经验看,固态存储盘是这三种形式中最为经济的,PCIe卡提供比固态存储更好的性能,不过通常来讲每GB的开销也更大。不过现在将闪存放置于DIMM中的新形式提供了另一种低延迟的方式,这或许会开启一些全新的应用模式。

  假如一款应用程序可以从闪存缓存或服务器的闪存层中获取数据,就不必再通过网络来索取数据。

  第一款DIMM形式的闪存驱动器逻辑上并没有连接到内存总线,而是连入主板上的闲置SATA端口。这些产品的主要卖点在于其容量,由于许多小型的刀片服务器只有为数极少的SATA驱动器槽位,但却会有未经使用的内存插槽。而近来,开始出现闪存模块逻辑和内存总线相连,提供相比PCIe闪存更低的延迟,但仍然利用空闲的DIMM插槽。这种“内存通道”技术刚刚起步,不过配以非易失性DIMM(NVDIMM)技术,代表着另一种令人振奋的服务器端闪存应用。

  网络传输

  将固态存储部署在服务器端而非网络附加存储系统端还有一些好处,即降低SAN网络传输。假如一款应用程序可以从闪存缓存或服务器的闪存层中获取数据,就不必再通过网络来索取数据。从而降低共享存储阵列的工作负载并将更多资源释放支持其他的服务器。因此网络传输量的降低使得服务器端闪存相比购买另一台共享存储系统成为一种更佳选择。

  是否分层

  一旦决定了部署的位置,存储类型的选择(固态存储实际使用方式)也需要被确定下来。除了全闪存阵列,闪存的实现方式关键体现在将最适合的数据在其被使用之前放入闪存中,并在后台持续保持这种状态。从本质上看,分层技术为最关键的数据集和数据子集创建了一块高速存储区域,比如数据库索引或变更日志,并基于业已选定策略填满闪存。分层通常比缓存需要更大的闪存容量,因此如果你的预算或物理空间有限时这往往不是最佳选择。缓存技术或许是这种场景下更好的选择,不过仍需个案分析。

  闪存缓存

  缓存软件通常包含在存储系统的特性之中,这种部署方式可以最大化传统存储阵列中的闪存容量。如果这种功能可用的话,其可以发挥很大的作用,因为对于使用者而言它完全透明,而且通常只需很少的配置工作。缓存技术同时还适用于安装在主机服务器端的PCIe闪存卡。

  闪存技术的另一种使用场景还可以是一款独立的软件,运用于加速某一台特定服务器上的应用。这样的解决方案提供了更大的灵活性,可以使用任何供应商的闪存产品,并支持不同的闪存形式(PCIe、固态存储盘或DIMM)。有一些甚至能够支持连接在一起的闪存卷,从而使得新加入的固态存储盘透明无缝地整合到现有部署环境之中。

  当然这其中也有一些潜在的风险。相比分层技术而言,缓存的性能可能更难以预计,而且缓存中数据的高流动性可能也会影响到固态存储的使用寿命。写缓存同样会有一些风险。

  缓存解决方案同样可以适用于服务器虚拟化、VDI或数据库等解决方案,利用应用程序特定数据类型和处理流程的知识库亦可以提升缓存的性能。不过所需要的闪存容量或许是一项重要的决定性因素,即便在类似的使用环境下也可能产生很大的差别。

  MLC和SLC之争:还那么重要么

  当闪存第一次登上舞台时,一项关键的采购指标是打算采用哪种闪存技术。单层式存储(SLC)更为可靠而快速,但同时也更为昂贵;多层式存储(MLC)的使用寿命较短,性能也较慢,但每GB单价则低廉很多;企业级多层式存储(eMLC)则介于两者之间。

  然而随着技术,尤其是闪存控制器技术的发展,使用哪一类闪存技术的问题变得不再重要。

  故障纠正和其它处理流程提升了可靠性,甚至使得低成本的MLC现在也能够用于企业级存储产品了。有一些则设计使用SLC甚至DRAM作为写缓存,来降低对MLC介质的影响。最主要的是现在许多有关采取何种技术的决定已经留给了厂商来决定,由他们来判断在产品中选择何种类型的闪存技术。

  多大的闪存才够用

  分层技术要求要有足够的闪存来保持完整的应用程序,或者至少是最关键的数据集合,因而决定这种方式要求的容量较为简单。不过缓存技术所使用的容量则难以估量。以经验法则开始也不错,不过实际环境测试更有助于判断闪存容量是否足够,又不会被浪费。一家闪存和缓存软件的供应商举过一个十分有意思的例子,客户是一家大型的电信企业,他们运行着几个超大型数据中心,支持多个VMware集群和成百上千的虚拟机。即便是在这种定义清晰的虚拟机环境中,这家企业仍然不断尝试测试新的缓存部署,先是将5%的主要数据迁移到缓存,然后是10%,最后则高达20%。从中我们可以看出:先从经验主义出发推测缓存容量,而后再根据实际环境中的监控进行不断调整。

  数据增长量、风险和高可用性

  在闪存部署决定过程中,还有另外一些和性能无关的限制因素。其中一项就是现有基础架构所产生的瓶颈需要应用闪存加以解决。另一项是风险,部分写缓存模式可能在数据安全写入主存储区域之前产生风险。在考虑具体的闪存方案之前,可以运用“分散写闪存”之类的技术来解决这些风险。

  如果需要高可用性,那么就意味着闪存上的数据必需被共享,可以考虑使用SAN阵列或闪存缓存设备。当然,部分服务器端的闪存解决方案也可以利用虚拟化软件来支持故障转移,或者支持本地闪存资源的共享。

  数据增长预期也是一项限制因素,可能会排除掉服务器端的解决方案。在这种情况下,系统必须能够有足够的容量并在扩展升级的过程中不会影响到系统的在线时间。

  打破系统瓶颈

  在IT环境中部署闪存技术往往受存储的性能瓶颈所驱动。找出瓶颈所在便能够回答第一个问题——闪存的应用从何着手?当确定了这一点之后,成本、容量、风险以及采用缓存还是分层也应加以考虑。不过,这些因素常是相互关联的,应当通盘考虑。闪存部署中的容量问题则往往需要在现实环境中测试后得出。

1
3