Chinaunix首页 | 论坛 | 博客
  • 博客访问: 581369
  • 博文数量: 165
  • 博客积分: 3897
  • 博客等级: 中校
  • 技术积分: 1799
  • 用 户 组: 普通用户
  • 注册时间: 2005-07-19 14:09
个人简介

英文名Coroel,读音类似“珊瑚”coral,你懂的!不懂的查海词,还有个类似读音的,CorelDraw画图软件。。。

文章分类

全部博文(165)

文章存档

2014年(1)

2012年(7)

2011年(12)

2010年(33)

2009年(19)

2008年(10)

2007年(51)

2005年(32)

分类: 服务器与存储

2011-01-20 22:19:37

 

鱼缸的启示:Scale-out和Scale-up架构

提到Scale-out和Scale-up,初看到可能会有点晕。其实我认为Scale-out和Scale-up的概念可以通过鱼缸的例子来解释。

  提到Scalout和Scale-up,初看到可能会有点晕。其实我认为Scale-out和Scale-up的概念可以用一个简单的例子来解释。

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

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

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

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

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

阅读(848) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~