论文部分内容阅读
对于磁盘的备份和恢复，是选择简单、熟悉的纵向扩展还是技术和成本更具优势的横向扩展，企业需认真权衡。
存储行业中许多人在讨论用于备份和恢复操作的“纵向扩展”（scale-up）架构与“横向扩展”（scale-out）架构。近些年，越来越多的企业在部署使用重复数据删除技术的基于磁盘的设备，以此减少磁带的使用或者不用磁带。但设备厂商们采用的架构方法对所选择解决方案的性能、可扩展性和总体成本有着很大的关系。
在讨论纵向扩展方法和横向扩展方法的优缺点之前，不妨先界定两个术语。
纵向扩展架构通常指使用单一、固定的资源控制器来处理所有任务的架构。想添加容量，可以附加磁盘柜；最多能附加多少磁盘柜，控制器已有规定。
横向扩展架构通常指可以单独扩展或步调一致地扩展性能和容量的架构，不是依赖单一的控制器，而是为每个磁盘单位提供了处理能力。
满足备份的经济意义
不管采用哪种方法，基于磁盘的备份重要的一点是，如果没有重复数据删除技术，使用磁带就缺乏经济意义。由于许多企业保留几个星期、几个月，甚至几年的备份数据，实际的备份数据量通常是企业环境中活动数据量的好多倍，这就导致纯粹使用磁盘成本过高。因此，结合磁盘和重复数据删除技术是厂商向备份和恢复市场推出实际产品的第一步。
从表面上看，纵向扩展架构有一个简单的前提：磁盘加上重复数据删除技术形成了一种备份和恢复设备，能够满足备份的经济意义。但是备份和恢复绝不仅仅是个存储问题。实际上，备份和恢复还是：数据移动问题——在预先确定的备份窗口内转移大量数据；数据处理问题——数据需要进行处理，才能以经过重复数据删除处理的形式加以存储；以及存储问题——重复数据删除技术让更多的备份数据得以存储在少得多的磁盘空间。
话虽如此，但纵向扩展方法也有几大优势：具有明显的简单性，因为这种方法通常只有一个计算单元——你在此进行配置和管理；在一些情况下，纵向扩展架构可能只需较少的电源与冷却资源；纵向扩展方法的历史比较久，对管理员来说比较熟悉，它一般提供了良好的功能特性，适合管理员所需的用途。
但数据迅猛增长导致纵向扩展架构出现了性能问题，原因很简单，由于这种架构只有一个计算单元放置所有的网络端口、处理器和内存，所以其性能受到该部件能力的限制。由于数据不可避免地增长，只好添加容量（意味着更多的工作负载），直至达到该控制器的最大容量。
这就导致了两个重大问题：在数据增长期间，所有过程也都随之变长，这包括备份时间、重复数据删除时间、复制时间和恢复时间。很显然，如果你将更多的工作负载扔给某一固定的资源，又不提供额外的处理能力，完成该工作就要花更长的时间；达到最大容量时，你只好进行叉车式升级（fork-lift upgrade），升级到功能更强大的控制器，这可能需要高昂成本。
而横向扩展架构以不同的方式来应对数据增长。在横向扩展架构中，架构的每个基本模块确实含有或可以添加额外的性能单元，包括网络端口、处理器、内存和磁盘。因而，随着数据不断增长、容量不断添加，处理能力也可以随之添加。这意味着数据增长并不导致备份、重复数据删除、复制和恢复所用的时间更长。如果工作负载增至4倍，架构的处理能力也增至4倍。也不存在所谓的“最大容量”。虽然厂商们可能限制了多少设备可以共存于一个单独管理的系统，但从来不需要叉车式升级，因为可以继续单独添加设备，哪怕这意味着开始使用一个“新系统”。
选择合身的系统
纵向扩展方法存在的另一个难题与选择大小合适的系统有关。许多纵向扩展技术厂商提供了大小不一的控制器，这意味着控制器可以处理不同的最大磁盘数量。你可能也料到了，功能更强的、允许添加更多容量的控制器自然成本更高。所以，如果顾客选购这种方案，就要确定是购买能够应对比目前所需环境更大的控制器，还是购买会更早达到最大容量的更小控制器。
横向扩展方法避免了选择大小合适的系统这个问题，因为这种架构具有模块性。客户可以根据目前环境，再加上预计的合理增长，购置大小合适的系统。然后，随着数据不断增长，可以根据需要添加更多的基本模块，不用担心叉车式升级。这使得前期购买可能更具成本效益，同时又避免了以后进行成本高昂的升级。
不利于纵向扩展方法的最后一个理由是技术容易过时。IT专业人员对这一幕再熟悉不过了：购买一个新产品，却发现买来不久就过时了。如果你决定买一只更大的控制器，以便适应更大的扩展需求，这个问题显然尤为突出。控制器把你死死绑在了买来时还算先进的技术上。如果厂商此后发布了基于更新技术的控制器，你想使用这种控制器，唯一的办法就是进行另一次叉车式升级。
横向扩展方法也许可以避免这个问题（取决于厂商），因为它让用户可以在同一个系统中混合搭配好几代的基本模块。假设厂商保证硬件可以升级到最新最好的软件，你就不需要丢弃并更换成本高昂的部件，以便充分利用厂商提供的最新产品。
存储行业中许多人在讨论用于备份和恢复操作的“纵向扩展”（scale-up）架构与“横向扩展”（scale-out）架构。近些年，越来越多的企业在部署使用重复数据删除技术的基于磁盘的设备，以此减少磁带的使用或者不用磁带。但设备厂商们采用的架构方法对所选择解决方案的性能、可扩展性和总体成本有着很大的关系。
在讨论纵向扩展方法和横向扩展方法的优缺点之前，不妨先界定两个术语。
纵向扩展架构通常指使用单一、固定的资源控制器来处理所有任务的架构。想添加容量，可以附加磁盘柜；最多能附加多少磁盘柜，控制器已有规定。
横向扩展架构通常指可以单独扩展或步调一致地扩展性能和容量的架构，不是依赖单一的控制器，而是为每个磁盘单位提供了处理能力。
满足备份的经济意义
不管采用哪种方法，基于磁盘的备份重要的一点是，如果没有重复数据删除技术，使用磁带就缺乏经济意义。由于许多企业保留几个星期、几个月，甚至几年的备份数据，实际的备份数据量通常是企业环境中活动数据量的好多倍，这就导致纯粹使用磁盘成本过高。因此，结合磁盘和重复数据删除技术是厂商向备份和恢复市场推出实际产品的第一步。
从表面上看，纵向扩展架构有一个简单的前提：磁盘加上重复数据删除技术形成了一种备份和恢复设备，能够满足备份的经济意义。但是备份和恢复绝不仅仅是个存储问题。实际上，备份和恢复还是：数据移动问题——在预先确定的备份窗口内转移大量数据；数据处理问题——数据需要进行处理，才能以经过重复数据删除处理的形式加以存储；以及存储问题——重复数据删除技术让更多的备份数据得以存储在少得多的磁盘空间。
话虽如此，但纵向扩展方法也有几大优势：具有明显的简单性，因为这种方法通常只有一个计算单元——你在此进行配置和管理；在一些情况下，纵向扩展架构可能只需较少的电源与冷却资源；纵向扩展方法的历史比较久，对管理员来说比较熟悉，它一般提供了良好的功能特性，适合管理员所需的用途。
但数据迅猛增长导致纵向扩展架构出现了性能问题，原因很简单，由于这种架构只有一个计算单元放置所有的网络端口、处理器和内存，所以其性能受到该部件能力的限制。由于数据不可避免地增长，只好添加容量（意味着更多的工作负载），直至达到该控制器的最大容量。
这就导致了两个重大问题：在数据增长期间，所有过程也都随之变长，这包括备份时间、重复数据删除时间、复制时间和恢复时间。很显然，如果你将更多的工作负载扔给某一固定的资源，又不提供额外的处理能力，完成该工作就要花更长的时间；达到最大容量时，你只好进行叉车式升级（fork-lift upgrade），升级到功能更强大的控制器，这可能需要高昂成本。
而横向扩展架构以不同的方式来应对数据增长。在横向扩展架构中，架构的每个基本模块确实含有或可以添加额外的性能单元，包括网络端口、处理器、内存和磁盘。因而，随着数据不断增长、容量不断添加，处理能力也可以随之添加。这意味着数据增长并不导致备份、重复数据删除、复制和恢复所用的时间更长。如果工作负载增至4倍，架构的处理能力也增至4倍。也不存在所谓的“最大容量”。虽然厂商们可能限制了多少设备可以共存于一个单独管理的系统，但从来不需要叉车式升级，因为可以继续单独添加设备，哪怕这意味着开始使用一个“新系统”。
选择合身的系统
纵向扩展方法存在的另一个难题与选择大小合适的系统有关。许多纵向扩展技术厂商提供了大小不一的控制器，这意味着控制器可以处理不同的最大磁盘数量。你可能也料到了，功能更强的、允许添加更多容量的控制器自然成本更高。所以，如果顾客选购这种方案，就要确定是购买能够应对比目前所需环境更大的控制器，还是购买会更早达到最大容量的更小控制器。
横向扩展方法避免了选择大小合适的系统这个问题，因为这种架构具有模块性。客户可以根据目前环境，再加上预计的合理增长，购置大小合适的系统。然后，随着数据不断增长，可以根据需要添加更多的基本模块，不用担心叉车式升级。这使得前期购买可能更具成本效益，同时又避免了以后进行成本高昂的升级。
不利于纵向扩展方法的最后一个理由是技术容易过时。IT专业人员对这一幕再熟悉不过了：购买一个新产品，却发现买来不久就过时了。如果你决定买一只更大的控制器，以便适应更大的扩展需求，这个问题显然尤为突出。控制器把你死死绑在了买来时还算先进的技术上。如果厂商此后发布了基于更新技术的控制器，你想使用这种控制器，唯一的办法就是进行另一次叉车式升级。
横向扩展方法也许可以避免这个问题（取决于厂商），因为它让用户可以在同一个系统中混合搭配好几代的基本模块。假设厂商保证硬件可以升级到最新最好的软件，你就不需要丢弃并更换成本高昂的部件，以便充分利用厂商提供的最新产品。