在云计算中，启用新的实例只需要给提供者发一条简单的API调用即可，但要想知道什么时候应该启动更多的实例或撤销正在运行的实例，就会很麻烦。如果基于采集的资源使用情况来判断启用撤销的话，就会容易得多，这是测量数据用做反馈机制的一种通例。

　　为这个项目做出容量评估将是一件苦差事。尽管有一些测量数器据，用上载频度、片大小及其他因素指述了Yahoo!Photos的典型用户，但有多少用户会选择Flickr，即使选择了Flickr，用户的使用模式又会如何变化，我们心里仍然没底。我们谈论的是一项已经超过10年的照片存储服务，将会有巨量的数括，而且这么大的空同会在很短的时间内消耗掉。不用讲得太精确，我告诉你，2009年后期，Fick每天用掉大约12TB的存储客量。从Yahoo!Photos到Flickr的迁移，在2007年持续了一段不长的时间，每天消耗的存空间是这个数的两倍还多。

　　在在备迁移的过程中，基于对迁移的评估以及现有的Yahoo!Photos数器，我们对存需求做了最好的估计，并给出了一个宽松的安全系统，确保迁移结束之前，不会出现存空间不够的情况。我们能想到的每件事情，都有测量数据:

　　我直接联到有意思的部分来说吧:即使微了如此谨慎的估计，我们还是错了，错大了。虽然做了研究，对存猪容量做了精心的评估，想迁近移到Fick来的人还是超出了我们的预期。要把想迁移到Flickr来的人的Yhoo!Photos数据都近移过来的话，我们部看的存猪空间都会用完。要么增加存猪，要么Flickr停止上载片。

　　2.一旦用户的迁移任务进入队列，则则锁定该用户的Yahoo!Photos账号，防止用户进行修改。现在Yahoo!Photos和Flickr之间进行API对API的通信，以获取要迁移的照片数据。

　　迁移完成后，开放Flickr这边的账号，通知用户可以使用迁移过来的Flickr新账号了。单个用户的迁移并不需要很长时间，但用户量很大，所以还是花了不少时间。迁移过程基本上就是一个大规模的异步过程，每个异步过程包括创建Flickr新账号和批量上载照片。

　　由于知道迁移要消耗多少存储、“有机”(非迁移)增长要消耗多少存储，即使估计不足的话，也可以预测出还能够支持的天数。我们下了一个庞大的订单，来购买存储，并开始计时。确认了发货和安装日期，这样我们就知道这些存储什么时候能够在数据中心上架以及需要多久才能投入使用。

　　因为使用Ganglia采集数据，3行脚本代码就可以计算出存储的消耗率，然后将这个数字传给负责迁移的API进程。照片是存储在分布于美国各地的若干个数据中心的，要确保API进程能够远程获得这个值，并检查正在迁移数据的所有数据中心。我们修改了API的处理过程，以便观察存储消耗的速率。如果在过去的一小时存储的消耗率大于维持到新存储上线那天的消耗率，则降低对排队等待迁移的账号的处理速度，反之，则加快处理速度。前面列出的步骤中，我们在步骤2和步骤3之间插入了一个检查当前存储消耗率的步骤。

　　最终，迁移顺利完成，没有发生存储空间用光的情况。事后看来，我们的估计是有偏差的，但并没有当初想的那么大。迁移开始时的高峰使我们担心存储会用光，所以马上部署了更多的存储。但随着渐渐接近原来的存储极限，进入迁移队列的用户也慢慢减少了