什么是Scale Up和Scale Out？

导读:Scale Out（也就是Scale horizontally）横向扩展，向外扩展 Scale Up（也就是Scale vertically）纵向扩展，向上扩展 无论是Scale Out，Scale Up，Scale In，实际上就是一种架构的概念，这些概念用在存储上可以，用在数据库上，网络上一样可以。 简单比喻下Sc

Scale Up（也就是Scale vertically）纵向扩展，向上扩展

Scale Out（也就是Scale horizontally）横向扩展，向外扩展

 
 

无论是Scale Out，Scale Up，Scale In，实际上就是一种架构的概念，这些概念用在存储上可以，用在数据库上，网络上一样可以。

 

简单比喻下Scale out和Scale up，帮助我们理解：

Scale UP，比如：我们向原有的机器添加CPU、内存。

Scale Out，比如：我们向原有的web、邮件系统添加一个新机器。

 
 

Scale Up 和  Scale out 

来自  https://www.cnblogs.com/zhwl/p/3640649.html

什么是scale up和scale out?

　　许多存储系统开始很简单，但当需要进行系统扩展时就会变得复杂。升级存储系统最常见的原因是需要更多的容量，以支持更多的用户，文件，应用程序或连接的服务器。

　　但是通常，存储系统的升级不只是需要容量，系统还对其他存储资源有额外需求，即带宽和计算能力。如果没有足够的I/O带宽，将出现用户或服务器的访问瓶颈;没有足够的计算能力，常用的存储软件如快照、复制和卷管理等服务都将受到限制。

　　常见的系统扩展方式有scale up和scale out两种。

　　Scale Up(纵向扩展) 主要是利用现有的存储系统，通过不断增加存储容量来满足数据增长的需求。

　　但是这种方式只增加了容量，而带宽和计算能力并没有相应的增加。所以，整个存储系统很快就会达到性能瓶颈，需要继续扩展。

　　这个时候有两种方法，一是采用更强性能的存储引擎(EMC 的Clarion系统和NetApp 的FAS系列，采用增加控制器CPU或内存的方式来提供更强的性能)，但是这种方式问题在于价格昂贵;

　　另外一种方法是额外购买的独立的存储系统，这样又会增加管理的复杂度。

　　Scale-out横向扩展架构的升级通常是以节点为单位，每个节点往往将包含容量、处理能力和I / O带宽。一个节点被添加到存储系统，系统中的三种资源将同时升级。

　　从上面的图例可见，容量增长和性能扩展(即增加额外的控制器)是同时进行。

　　而且，Scale-out架构的存储系统在扩展之后，从用户的视角看起来仍然是一个单一的系统，这一点与我们将多个相互独立的存储系统简单的叠加在一个机柜中是完全不同的。

　　所以scale out方式使得存储系统升级工作大大简化，用户能够真正实现按需购买，降低TCO。

　　以下是常见的两个比喻:

　　一是传统火车和动车。传统的存储Scale-up架构的存储就好像传统的火车一样，当后面的磁盘越挂越多的时候，控制器性能以及背板带宽却不能相应提升，因此传统存储在磁盘容量扩容到一定程度时候，往往性能下降。

　　集群存储就好像新一代的“动车组”火车一样，当火车车厢增加的时候，前面的火车头动力也随之增加，因此不会发生性能瓶颈。

　　所谓动车组的设计理念和传统火车设计理念的最大区别在于传统火车主要动力来自于火车头(就像传统模块化阵列的两个控制器)，而动车组则不一样，除了车头配有动力装置外，每一节车厢都配有动力推动装置。集群存储大多都是由一个个节点(X86 服务器)组成，每一个节点添加进去后，不仅能够添加容量，还能够添加整个存储器的整体处理能力。

　　另外一个鱼缸的比喻：

　　当你只有六七条鱼的时候， 一个小型鱼缸就够了;可是过一段时间新生了三十多条小鱼，这个小缸显然不够大了。

　　如果用Scale up解决方案，那么你就需要去买一个大缸，把所有沙、水草、布景、加热棒、温度计都从小缸里拿出来，重新布置到大缸。这个工程可不简单哦，不是十分钟八分钟能搞得定的，尤其水草，纠在一起很难分开(不过这跟迁移数据的工程复杂度比起来实在是毛毛雨啦，不值一提)。

　　那么现在换个思路，用Scale out方案，就相当于是你在这个小缸旁边接了一个同样的小缸，两个缸联通。鱼可以自动分散到两个缸，你也就省掉了上面提到的那一系列挪沙、水草、布景等的折腾了。

来自 https://blog.csdn.net/kepa520/article/details/82791470