谁是王道？互联网环境下Scale out和Scale up模式大PK！（获奖名单已公布-2014-7-31）

hxksd

用户在采购之初很难准确预测未来数据增长的速度和总量。用户往往不得不采购比自己目前实际需求容量更大的存储，这就导致两个问题，一是预算的浪费，很多存储空间都是为未来数据增长采购的，花了10TB的钱，但是可能只利用上了5TB，另5TB的资金都白白放在那里。另一个问题是，随着时间推移，数据增长，数据量超过了10TB。

      按照过去Scale-up的理念，解决方案就是购买更大容量的存储，那么难免面临数据迁移的问题，用户必须停机迁移数据，意味着服务的中断。而Scale-out架构解决了这个矛盾。用户按需采购存储，一旦容量不够了，再购置一台接到原有存储上就可以了。

billicon

send_linux 发表于 2014-07-05 10:32
兄弟有点落伍了吧，自大互联网开始爆发的时候，就有这个scale out 和scale up这两个之争了

传统银行 ...

电信不是这样的了，可能核心的结算系统是吧，但是大量的外围的IT设施都是x86来做的，而且hadoop和云计算的集群很多了，华为和他们合作的比较多，江苏电信，杭州电信都有这样的成功案例

billicon

zclhard 发表于 2014-07-10 11:31
并不是所有企业都需要云计算。但是如果企业内部各个部门，各自有一套 “小而全” 的 IT 系统，各自为政 ...

旁观者清，当局者迷，领导都要像你这么想，每年的IT bugdet花不出去，那他还混个P啊，会花钱才是好同志

billicon

zclhard 发表于 2014-07-10 11:31
并不是所有企业都需要云计算。但是如果企业内部各个部门，各自有一套 “小而全” 的 IT 系统，各自为政 ...

所以，Iaas必须的上，管它有没有用，是否可以带来效益，但是起码有个东西在我们的机房里，看的见，摸的着，这就是国内为啥这么多Iaas的，没有几个paas的原因

billicon

q1208c 发表于 2014-07-10 18:55
回复 42# send_linux

不完全是.

做互联网的还有垂直扩展的？不会吧，除了数据库硬件啥的，上个SSD啥的，不会有其他的垂直扩展吧？

大部分的都是做垂直削减，比如做CDN的，节点功能都在削减，只为减低功耗和成本，从而满足更好的效率

互联网行业水平扩展是王道

q1208c

回复 49# billicon

就说CDN吧. 当CDN节点的数量多到一定程度的时候, 你会发现, CDN节点的数据一致性是个大问题, 解决的办法很简单, 增加单个节点的容量, 减少节点的数量.

除非CDN算法有了新的突破, 可以保证数据一致性.
   

may0505

zhaopingzi 发表于 2014-06-30 13:16
所谓scale-out即横向扩展，scale-up即纵向扩展

在选择scale-up还是scale-out的时候，

记得N年前，初次接触网络规划的题目时接触过这个词，同时出现的还有"Scale Up"。Scale Out 按字面意思是超过尺寸范围，而Scale Up则是按比例增高。即使用靠增加处理器来提升运算能力和增加独立服务器来增加运算能力。
    对于服务器体系来说必须要考虑的一点就是可扩展性（Scalability）。除非业务永不增长，否则随着使用人数不断增多，服务器就一定会很快达到性能和并发极限。解决这个问题，通常只有两个办法：即代表分布式计算的Scale out和以主机或机箱式为主的Scale up。
    Scale Out(向外扩展)：就是指企业可以根据需求增加不同的服务器应用，依靠多部服务器协同运算，借负载平衡及容错等功能来提高运算能力及可靠度。
    Scale Up(向上扩展)：指企业后端大型服务器以增加处理器等运算资源进行升级以获得对应用性能的要求。
    在现今这两种技术已经没有明显的区别，各个提供商不仅提供用于分布式计算的Unix和Windows平台，还提供用于集中式计算的Unix和Windows平台。甚至传统的集中式计算大型机也正具有分布式计算的性质——如在IBM zSeries服务器上使用Linux和z/VM的虚拟性能，就是其中的证明。

may0505

但是更大更强的服务器同时也是更昂贵的，往往成本会大于部署大量相对便宜的服务器来实现性能的提升。而且服务器性能所能提高的程度也有一定的上限（分布式的部署相对来说性能提高的上限更高些）。所以一种呼声是应该使用向外扩展（Scale Out）来实现可扩展性，同时可以让使用者得以保留通过增加服务器以提升系统能力的后路。

may0505

但是在实现中也有很多困难需要解决：
    首先，要想成功地实现向外扩展架构必须解决复杂的分布式计算问题（相对来说Scale Up方案不需要考虑这个问题），而这个问题的解决往往需要很复杂的技术和相对多的资金（Scale  Out  与  Scale Up比如说我就没有这个技术和这些钱......）。大型站点如Google、Yahoo和Amazon.com，都自行研发大量相关技术。
    其次，Scale Out方案还需要对原先是用的软件进行大量的重写工作，以保证系统能在分布式服务器上运行（Scale Up方案则对现有软件几乎没有改动要求）。这一步往往是每个公司的开发人员的噩梦。一个不好会使开发人员的所有工作白费。
    再者，Scale Out方案始终面临着数据集中的问题，即拆分过的数据在服务器逻辑体系中仍然是各自相对集中的而非无限随意拆分。如果大量的逻辑放在数据库服务器一端，数据库服务器将会使得系统失去Scale out的能力和可能。因此，要保证Scale out的能力就必须保证数据库只处理实质性的数据提交和不可避免的数据查询，对于能够避免的数据查询和非实质性数据提交都应该想办法予以避免。而具体的策略和方案相对没有最优的方法。
    现在的大多数平台都提供了系统扩展方面的支持，但没有任何一种平台技术能够解决所有的问题。
所以总的来说，Scale  Out  与  Scale Up是会并存的，特定的场景下，特定的模式是最好使的。

may0505

q1208c 发表于 2014-07-14 06:46
回复 49# billicon

就说CDN吧. 当CDN节点的数量多到一定程度的时候, 你会发现, CDN节点的数据一致性是个 ...

单纯的硬盘容量扩展，可不可以理解为scale out呢，这个虽然是节点上的系统升级，但是模式上还是scale out