在BBCS和VM移动赌注

上周，我的一位同事跟我打赌，我写不出一篇关于英国广播公司(BBCs)的易懂的博客。像往常一样，我不假思索地接受了这个赌注。那么BBC——英国广播公司?不，很难写客户，你不想违反任何人的保密协议或安全态势。那么，纽约阿马甘塞特(Amagansett)的西里尔鱼屋(Cyril’s Fish House)的“贝利香蕉奶油鸡尾酒”(Bailey’s Banana Creme Colada)又如何呢?管他呢，为什么不……西里尔是路边的一家鱼屋，有很好吃的食物，有趣的鸡尾酒，还有很多。但有趣的是西里尔与他的鱼屋、员工以及汉普顿的夏季结束时所做的事情。从夏末开始，西里尔·帕克(Cyril pack)带着他的员工和物资，前往英属维尔京群岛，特别是安圭拉，并在游艇季期间重新开放。游艇季从10月底开始，一直持续到阵亡将士纪念日(Memorial Day)周末之前，这个迁徙周期将再次出现。现在，这可能有点夸张，但我已经有几个人问我，他们如何能在虚拟机上做同样的事情。具体来说，“我怎样才能追随太阳，追随千瓦时的价格，追随客户”? Follow the Sun- think call centers. You want the servers to be in closest proximity to the workers who will be awake and at highest productivity when answering live calls in their time zones. This will ensure maximum responsiveness. Follow the kWh- affordable power. Many utilities offer discounts for off-peak loads, if the virtualization platform understood power pricing and power draw in real-time, and also understood the 'cost' associated with a given workload move (bandwidth costing against size of VM for instance) then you could move the workload to the location with the most affordable energy costs at a given time and reduce the OPEX associated with power. (Note: this would be pretty network intensive, but would be a heck of a demo.) Follow the Customers- not dissimilar to Follow the Sun, but if your customer base is migratory then move the workloads to the location that is best able to service their transactions at any given time. Some services will certainly continue to be centralized but other, more real-time, applications can benefit from proximity. I can imagine some of today's CDNs evolving to limited and then more full-featured VM hosting and tying in to multiple customers virtualization platforms to provide for them the analytics and capacity needed to co-locate workload near demand. Of course, these models, while quite interesting on the surface expose significant network limitations - most significantly the lack of an ESI in the IP structure. Global and Cross-AS workload portability is not pragmatic with today's protocols and host stacks. (Someone will invariably post the comment- "Can't you just use DNS to solve this... in short, "No." DNS A-records are cached both by clients and proxies and TTL is not always adhered to. Your browser will cache an IP address for a given FQDN and then open a socket up, that socket itself needs to remain intact through the move for it to be seamless to the end-user. This is not possible with DNS tweaks.) What ways are you seeing people design around these limitations? (I have seen: really large flat Layer-2 networks that remind me of the Vitalink days, BGP setup VPLS tunnels, emerging standards such as TRILL and LISP, and some more proprietary implementations...) any others? dg