So you need to design highly available MySQL powered system… how do you approach that ?
Too often I see the question is approached by focusing on expensive hardware which in theory should be reliable. And this really can work quite well for small systems. It is my experience - with quality commodity hardware (Dell,HP,IBM etc) you would see box failing once per couple of years of uptime which is enough to maintain level of availability needed by many small systems. In fact they typically would have order of magnitude more availability issues caused by their own software bugs, DOS attacks and other issues.

However as your system growths the reliability goes down. If you have 100 servers with each failing every 2 years this is about a server a week which is bad and if you’re into thousands and tens of thousands of servers server failures are becoming common place so it is important to make sure failing server does not affect your system and also what you can recover from server failure easily

So you should assume every component in the system can fail (if it is Server,Switch,Router,Cable, SAN) etc and you’re ready to deal with this. It does not mean you always have to ensure you stay fully operational after any failure but at least you should understand the risks. For example you may want to choose to keep single Cisco router because it has its own internal high availability on the component level which makes it extremely unlikely to fail, because you have 4 hour onsite repair agreement and because it is just freaking expensive. Though may be redundant less expensive systems could be better choice.

I would highlight again every component can fail it does not matter how redundant it is inside. The SAN is very good example - I’ve seen Firmware glitches causing failure in the SAN which was fully redundant on the component level. It is not every hardware component but also any code may fail as well. This is actually what makes your own code often the weakest link in availability.

Depending on failure rate you also should be thinking about automation - for frequent failures you want to recovery (like getting spare Web server and putting it online) to be automatic or done with simple manual command. For complex and rare failures you may have less automation - if certain type of failure happens once per couple of years for many evolving systems there is very high chance the old automation tools may not work well (this is of course unless you always test all automated failure scenarios regularly).

So if we’re designing the system so it can tolerate hardware failures should we bother about hardware quality at all ? The answer is yes in particular for classic database/storage systems. Few systems are design with so much error detection and automated handling in mind as Google File System.

In particular you want to make sure Error Detection is on the good level. For example if you’re running the system without ECC memory chances are your data will melt down and you will not notice it for long time (in particular if you’re using MyISAM tables) which can cause the error to propagate further in the system and make recovery much more complicated than simply swapping the server. This is exactly one of the reasons many high scale installations prefer Innodb - it is paranoid and this is how you want your data storage to be. This is also why Sun is so proud about checksums on the file system level in ZFS.

What is about RAID when ? As strange as it may sound but you should not relay on RAID for your data safety. There are many ways to loose data on RAID system even if you’re running RAID6 with couple of hot spare. The RAID is just dramatically reduces chance of data loss in case of hard drive failure and this is good because recovering database servers is not fully automated in most cases. Plus there may be system performance impact and (in particular if you use MySQL Replication for HA) the switch to the new server may not be 100% clean with few updates lost. RAID, especially with BBU also makes a good sense to get extra performance out of the box.

Some installations are using RAID0 for slaves - in these cases there are typically many slaves and recovery of the slave is very easy and causes no business impact. This is fine assuming you do the math and the performance gains or cost savings are worth it.

Another good RAID question is if Hot Spare should be used. I normally do not use it because it a large waste, especially as most of systems have even number of drives, so if you’re looking for RAID10 setting up hot spare costs you 2 drives. Having hot spare does not add a lot to high availability - if you have proper RAID monitoring in place and keep couple of spare hard drives on the shelf in the data center we’re speaking about couple of extra hours running in degraded mode. Even if you do not have spare hard drive you can often pool the one from the spare server and have the “warranty man” to replace it instead.

It is also a good question if you need redundant power supplies. In my experience they rarely fail so having redundant power supplies does not increase availability when it comes to hardware failures that much and so if you just look from this angle it may be justified only for the most critical servers. Do not forget redundant power supplies also increase server power usage a bit. Redundant power supplies however are helpful if you have multiple power feeds, so server can stay up if one of the phases has a power loss. Another benefit is - in redundant power supply will often allow to do some power work (like moving server to different circuit) without downtime which may be or may not be something important for you.

Finally I should mention about spare component. These are paramount if you’re designing highly available system. Having spare drives on the shelf, spare switches, spare servers (which are same as better as servers which are in production) is paramount. It is important promotion happens easily and there are no performance gotchas (ie 8 core server can be slower than 4 core with MySQL). It is best if you just put couple of spare servers in each purchase batch so they are absolutely same configuration but I know it is not always possible. Dealing with spares is yet another reasons to avoid the “server zoo” and have limited set of purchased configurations which are reviewed yearly (on other regular interval) rather than finding different best configuration each week.

Having spare servers also means you often do not need most expensive support agreements and Business Hours Monday-Friday is good enough for you - you’re not waiting for support for production anyway just fall back to another server and use it. Of course you can imagine cases when problem could affect all servers of the same type but it is not that frequently seen in practice.

To avoid multiple servers failing at the same time it is of course important to QA/Stress test servers before you put the load on them. I’ve seen multiple cases when something would go wrong and all servers of same configuration will experience the same problem. Proper QA/Stress test reduces the chance of this but you better to be testing with load similar to what you expect in production.

Requirement to have Spare hardware is also the reason why commodity inexpensive hardware is often better choice. If you have couple of $1M in production you need another $1M server as a spare and this is expensive. If instead you have 10 pairs $10K boxes having couple of spares would cost you only $20K plus I found it in many cases much easier to convince “finance” people to buy something cheap which is not used most of the time when to spend a lot of money on the server which will be where sitting doing idle.

How many spare servers you need - you would see it in practice. As I mentioned at least one for any hardware class you have. If you have many failures you need more of course. You may also decide to keep more spare systems when you can use them to help capacity management, especially if you have multiple applications which do not share hardware but share the data center. You may have “spares” to provide extra on demand capacity for web servers or memcached quite easily, or say increase number of slaves if you have unexpectedly high number of reports launched by users etc.

Entry posted by peter | 4 comments

Add to: | | | |

打小家里就穷，别说现在小孩们玩的林林种种、花样翻新、光怪陆离的新鲜玩具，就是那些看起来挺寒碜的铁皮蛤蟆、塑料小手枪，当时的绝大多数孩子都只有眼巴巴看着流口水的份。童贞的世界里怎么能没有玩具！所以，刚刚告别饿肚皮日子不久的大人孩子们一起发挥diy精神，创造出无数好玩的东西来——铁丝拧的灯笼、火柴枪、肥皂盒做的小车、泥巴捏的娃娃、车胎做的弹弓等等粉墨登场，虽然简陋，一样给童年带来无数快乐——70后们就是这样度过的。

除去做玩具、养红茶菌，养宠物也是老少咸宜的节目——养兔子之类的，不能算养宠物，养肥后要宰了吃掉或者卖掉换钱的，留给孩子的只有眼泪和难过。当时养鸟最常见。村子里常有悦耳的鸽哨从天空掠过，余音袅袅，鸽子舒展华美惬意的身姿，轻盈的像在水面上轻轻滑过，丝丝云彩仿佛轻轻荡漾的波浪。我往往一直仰望到鸽子完全在视野里消失。饲养鸽子和拥有一架天文望远镜，是当时最持久、最甜美的梦想。可当时饲养鸽子是有点小奢侈的玩意，别说优良品种，就是最普通的鸽子也不容易搞到，何况经常有人偷盗。所以，连哥哥姐姐都不能饲养，别说我这样的小屁孩了。鸽子梦就此破灭。

当时很流行逮鸟，比较残忍的用夹子，就是铁丝+钢丝拧的玩意，用一截树枝做机关，玉米秸里剥出的虫子做诱饵。无数贪吃的小鸟殒命其上，除去常见的麻雀，还有歌声嘹亮、不大多见的土百灵。被夹到的鸟儿几无生还可能，不是当时命丧黄泉就是筋断骨折、口吐鲜血，罪过罪过……大哥当时常干这个，家里至少有二十个以上的打鸟夹子，神气活现的拿将出去，设好夹子、用沙土伪装好后，再折根树枝插在一边加强效果，然后拉着我趴在土坑里耐心等待。陷阱发作的术语叫“夹子犯了”，立刻欢呼雀跃的跑过去查看战果，如果打到鸟，兴高采烈，没打死的话从头再来。至于鸟的结局，不是当时立刻找柴火烧熟就是回家放在灶膛里烤熟。总之，一个字，吃。是啊，吃是那个时候所有人最强大、最诱人、超越一切的需求，一分钱两颗的虎皮花生、二分钱的雪糕、还有供销社里让人淌口水的糖果，过年时才宰的肥猪，哪个都不如眼前的（或者说夹子上的）鸟儿来的最实在，最踏实，最诚恳，最香甜！妈妈说，每次院子里有小鸟飞过，我的直接反应就是：戟指+高喊“烧着吃了”……

饱暖思淫欲，诚然。太祖时代为啥没妓 女、毒品，一则有文工团和特供，再则吃饱的没几个，哪有心思惦记那奢侈事，能把自己家的皇粮缴齐就不错咧……

等到吃的问题解决的差不多了，才有饲养鸟儿的想法。饲养鸟也不像现在这么简单，花鸟市场一溜达，看上哪个，讨价还价，拎家去就是了。当时还没有自由市场，封资修的大帽子还阴森森飘摇在每个人的脑袋上，犯不着为拇指大的玩意扛个“投机倒把”的罪名游街，于是，只剩下捕捉这条最安全的路了。捕鸟不能采取夹子这种野蛮的直接方式，要动点脑筋。简单点的，在打鸟的夹子上编个小网子，夹子“犯了”只是把小鸟扣在里面，顶多伤几根羽毛，不会死翘翘；勤快的就编个复合式鸟笼子，模样有点像三居室，最上面编两个小空间，用木棍做翻板，插根谷穗做诱饵，鸟站到木棍上吃谷穗就会被扣在小居室里。如果扣到麻雀，不好意思，摔死吃肉；如果是土百灵、锡嘴、腊嘴，就欢欢喜喜的拿回家养起来。养鸟是个麻烦活计，刚逮回来的鸟不大温顺，整天吵吵着要自 由，时刻想砸碎牢 笼跑将出去，广阔天地大有作 为。这样的生猛货色，得放在黑暗里捂上两天，饿的眼冒金星，让它们意识到填饱肚皮是最大的鸟权，意识谁是真正的主人，然后就乖的多了。这个有点像组织上搞的思想教育、岗前培训等等。

不过这个和思想教育还是有区别的——鸟爷爷既然屈尊蹲在笼子里任凭你摆弄、炫耀、溜达，自然得好口粮伺候，比较快当的方法是去劈玉米秫秸找虫子，或者挑上好的谷穗饲喂，还得冒鸟爷爷一气之下不跟你玩了的危险——失去了自由自在飞翔、迁徙、恋爱权利的鸟儿还要办理户 籍、暂 住证、鸟人证、良 民证，搞不好早晨醒来，鸟笼里就是一具僵硬的尸体。

那时候，村头有棵大杨树，高的吓人，晃晃悠悠的枝头，经常有个古怪的鸟 巢，形状，这个，很像男性生殖器……  

参看这位鸟类学工作者的博客：http://blog.sina.com.cn/s/blog_491fe51001000d12.html据说，老乡们用这种鸟 巢来治疗疝气。  

筑巢的小鸟，真的是“小”鸟，体型娇小，估计去掉了毛，也就拇指大一团。这种巢是用杨柳科植物的种子、或者说主要用种子基部的柔毛编织而成，小鸟要耗费几天的时间，反复寻觅建筑材料、在枝头上多次盘旋才筑成，编织技术之高超、筑巢之辛苦，让我等小破孩叹为观止，而且几乎高不可及，除非活的不耐烦了，或者极度想炫耀、或者求药，才卯足劲爬上去，把整个树枝折下来，还要顶住树下孩子们不断扔上来的石块、口水和咒骂。折下来的巢，像一杆胜利的旗帜，至少要在村子里飘扬几天才算告一段落，而且几年都舍不得扔。我就有这样一个巢，是邻居刘瘸子的儿子爬上树梢摘下来的。我用四个玻璃球才换回来，巢里还有一枚粉白色、小手指一半那么大的蛋。巢插在屋檐下不到一天，一只小鸟破壳而出，是个更小的小不点，没到一天，雏鸟死了……

大哭一场之后，再也不养鸟。

那个巢，一直保留到92年，期间跟随我们三次搬家，十年之久。去年，专门向研究鸟类的王老师求教这种鸟的名字，原来叫做“攀雀（中华攀雀）”，学名Remiz consobrinus ，“consobrinus”，拉丁里“相关”的意思。抱歉，我毁了你的家，间接或直接的杀死了你的孩子。

老家的邻居有只聪明的八哥，总是喜欢隔着阳台教它说话：“吃了吗？”“来个酱肘子”。后来，老爷子把八哥挪屋里去了……

我饲养的宠物，都是安安静静的小家伙，比如，绳子栓着的蜻蜓、蝴蝶、水塘里捞来的蝌蚪、小鱼苗、泥鳅，还有河蚌啥的。最牛的一回，用空罐头瓶子养了一只屎壳郎，地里挖出来的——屎壳郎的巢很好找，地上有一小堆碎土渣，洞穴很浅，一铁锹下去，屎壳郎的老巢尽在掌握。这只屎壳郎可与众不同，头上有一只大角，很是让我炫耀了一阵子。可惜，没几天它就死翘翘了。屎壳郎虽然在我的强行帮助下过上了不吃屎的体面生活，却失去了赖以为生的口粮，自然撒手归西。现在想想，真是脏的要命，希望当时每次玩完屎壳郎后都洗手了……    

某天，哥哥兴高采烈的揣回一只刺猬，小小的一团，粉红的鼻子，很是好玩，只是总缩成一团，或者很愤怒的竖起满身的刺，发出“嘶嘶”的警告声。刺猬属杂食动物，菜叶啥的都能养活，用只柳条筐扣起来，它就在里面焦躁不安的爬来爬去，啃柳条。把杂草扔的到处都是，很快开始不吃不喝，最后的结局我记不得了，好像是被邻居大孩子用泥巴裹起来烧熟吃掉了——又是个悲哀的残忍结局。

搬家到城里后，从叔叔家里要来一只黑白花大狗，温顺调皮，没多久被前院邻居逮去吃肉了；四年级的时候养了条黄狗，被后院的流氓家吃掉了。六年级时，右腿出了大问题，在家养了整个学期的病，每天打发日子的，除去无聊的课本，就是一条神气活现的小黑狗，是大姐带专门回来陪我玩的。小黑狗特别听话，围着瘸腿的我跑前跑后，跳来跳去，蹲在脚边和我一起晒太阳。入冬的时候，县城爱卫会给狗狗们打疫苗，也不知道啥疫苗，说是狗打了以后咬人也不会得狂犬病。疫苗三块钱，“打狗队”们随身带着逮狗的钳子和铁棍，不交钱就一棍子打死，交钱打针的话给发一个印着狗头的铝牌牌。交了三块钱，我的小黑狗挨了一针，没多久就在一个雪天死掉了。从此，爱卫会之流的畜生们，留给我的印象就是尸位素餐扰民为乐的东西。

再后来，学业越来越重，哪有心思养宠物，一直到上大学。

刚入学，发现95级专科的爷们在寝室养兔子、养鸟，而且基本是散养，我靠，简直没法进门。

97年上半年，三将军从系里那个放农具的狗窝里扛回个干燥器，大伙热火朝天的商量是腌咸鸡蛋还是做咸菜，最后我拿来刷干净，去岳阳街早市买来几条鹤顶红金鱼放养，放在宽大的桌子上，金鱼悠哉游哉的很舒服。某天回寝室，发现王七X这孙子往鱼缸里倒方便面汤，这厮还振振有辞的说这样可以提高鱼的抵抗力、考验其生存能力，靠！没多久，这几条倒霉的鱼自己就吓死了。这个三将军扛回来的宝贝器物一直没舍得扔，历经几次转手又回到我手里，至今仍恭恭敬敬供在窗台上，准备一代代留传下去。自从去年一不小心打碎了盖子后，谁敢摸一下，我的脸色都非常难看。

98年去左家实习，大伙逮回一大堆很牛的宠物：540养了两只猫头鹰幼雏、一条铅笔大小的白条锦蛇，刘唇养了条红红绿绿的虎斑游蛇。这几位新成员一下子成了避邪圣物，学生处那些罚钱的龟孙子们再也不敢登门找碴了。不过，刘唇的虎斑游蛇没几天就出溜到544郑X的床下，找了双拖鞋温暖的蜷在里面睡觉。大清早，郑X被尿憋醒，随后一声惨叫蓬头垢面的跑来砸门，刘唇很不好意思的去把蛇拿回来。540的小蛇被陈老幺的同学拿去玩，就此无影无踪，陈老幺伤心了很多天。至于那两只猫头鹰幼雏，唉，简直是倒了八辈子霉，落到了这群厮的手里——武大郎养夜猫子，啥人玩啥鸟。刚逮到的时候，两个小家伙吃的不多，大伙还能用癞蛤蟆、打来的耗子啥的对付，后来食量大增，每天能吃五到七块钱牛肉，每天还要安排一个人早起去早市卖肉。两只猫头鹰羽毛渐丰，在桌子、晾衣绳、床铺上蹿下跳、踱步，畅快的上厕所，而且，熄灯后饿的受不了，就会不停敲打喙，“嗒嗒嗒”之声不绝于耳，四只闪着绿油油贼光的圆眼盯着床上酣睡的八条肉虫，虎视眈眈。大伙心虚了，竟然拿榨菜对付这两位夜猫子爷爷。没多久，两只猫头鹰的毛色黯淡，某次我去玩，想帮它俩练习飞翔，手动展翅后从空中落下，竟然摔断了腿骨，没多久两只猫头鹰都死掉了，搞得我非常难受和内疚。去请教鸟类学老师，说是因为全面缺乏营养，尤其是钙质，必然会死掉，并且谴责我们不该拿两只雏鸟从巢里拿回来。ps：罗先生02年英年早逝，叹息。

每次从化学系和物理系中间走过，看到樟子松上蹲着的二十几只猫头鹰，总是很不好意思。

99年夏天，兆森捡回来一只未完全成年的红隼，国家二级保护动物，大伙纷纷拍照留念。宝贝一样端回548，放在纸箱里养了两天，喂了五块钱牛肉，这厮竟然死活不飞走了。再次请教宋先生，先生大笑，说吃的太饱，舍不得走了，饿一下就好。果然，某天清早，展翅飞到中文系门口的树上，至今杳无音讯，也不知道有没有携妻带子去548探望？

以后多年不饲养宠物，除了小强之外。前一阵子手痒，搞了一条红点锦蛇、一只丽纹攀蜥Japalura splendida镇宅。锦蛇挺安静的，除了数次试图越狱外，一直安安静静。倒是那只丽纹攀蜥不怎么安静，在玻璃缸里兴高采烈的跳来跳去，一直打算逃出去。食量挺大，每顿要吃掉几条面包虫或者甲虫。给它起名字Durius，也叫“跳跳”。没多久，悲剧继续上演，红点锦蛇得病死掉了，还好宝贝跳跳安好，长了将近两厘米，而且蜕皮，换了一身非常神气的新衣服，黑绿色的条纹，长长的尾巴，每天晒晒太阳、练练跳高，在我的胳膊、肚皮上爬来跳去，日子过的不亦乐乎。可是，跳跳前几天成功越狱，翻箱倒柜猛找了几次，无影无踪，估计是爬出玻璃缸后，跳到了阳台里，从阳台再次逃脱到别的屋子里，或者掉到了楼下的草坪上。估计是策划很久了，温习Prison break的时候不带它就好了。贴了寻物启事，无果。跳跳在东北是没法过冬的，唉，又是一幕延时悲剧！

我的宠物，从来没有善终的，以后绝对不养任何宠物。

其实，我们都是生活在更大笼子里的宠物而已，何必把那些小可怜关在更小的牢笼里满足私欲。

这周的内部技术交流会，是一个同事介绍 screen 的使用。俺一时嘴痒，就从怀旧开始，给大家从终端开始发散：

十年前，刚接触 UNIX 主机的时候，机房里的终端已经基本不再使用了。但调试维护路由器交换机总偶尔会碰上忘带串口线或者针头不匹配，前辈就从一堆老终端里翻出台合用的代替。第一次看见别人用终端印象非常深刻——总算知道windows那个“超级终端”，或者 telnet.exe 里的 vt100 对应的实物是什么了。

从形态上，terminal 和 console 是一致的，就是输入设备和输出设备的组合。它自己没有计算能力，任务在主机上执行。

在终端键盘上敲一个字符，比如 'a'，首先把 'a' 送到主机上，主机再把这个 'a' 回显(echo)，然后我们才能在终端屏幕上看到这个 'a'。和在编辑器里输入并看到一个 'a' 相比，是完全不一样的概念。

最近几年入行的新人是不太可能有机会亲手摸一下终端了(可在 google 上图片搜索 vt100 或 vt220 过过眼瘾)。但如果安装过 Linux 操作系统，它的文本控制台(console)可以很好的帮助理解 screen。

A. Linux 控制台，缺省有 6 个虚拟终端，我们可用 Alt-F1/F6 来依次切换；在 screen 里就可以这么干。

B. Linux 控制台的某虚拟终端上，登录进去，然后拔掉键盘，拔掉显示器，再把它们插上，你会发现刚才登录的状态还保持在；screen 也是这样的——在不可靠的网络环境下想长时间的在终端前台执行某程序，screen 就是必须的工具了。

C. 最后，刚才拔掉键盘显示器，再插回去的动作，用英文怎么说？不就是 detach 和 attach 么

在该同事演示的过程中，screen -x 命令效果是最让人震撼的。我开玩笑说，以后大家都必须在 screen 里工作，这样我就可以做一个真正的监工了。昨晚回家骑车的路上想，这就是远程 PP 啊！如果不得不在不同地点办公，同时又想执行结对编程的团队，是可以考虑利用这个功能来结对的。 只是不知道 X Terminal或远程桌面是否也能实现这样完整共享设备的特性

由于IO的请求不是每次等待完成指令后再发送下一个请求，而是存在于队列中，且遵循FIFO。因此如果遇到存储掉电的情况，就可能会出现数据的不一致。虽然这种情况出现的可能性不大，因为存储中有电池，能保证cache中的信息写到存储中。但是在这里还是提一下数据丢失的风险。

由于我们的异步IO的队列中是针对使用裸设备的IO请求，即redo log、datafile和controlfile，这边分2种情况讨论存储掉电时候，数据的丢失情况（注：以下情况考虑的是cache中的IO请求丢失，但是文件未损坏的情况）：

（1）当记录A insert到表中，已经commit，记录B insert到表中，未commit，此时checkpoint未发生时。此时的IO队列中有insert A的redo请求，insert B的redo请求，但未有buffer向dbfile写的请求。此时掉电，oracle端的情况是oracle认为redo的IO请求已经写到redo log，os端的情况redo的IO请求还没写到redo log中。重启数据库时候之前的oracle端认为redo和dbfiles的scn不一致，需要介质恢复，但是在启动的时候，读取redo log，由于在os级上尚未写入，redo log和dbfiles的scn一致，因此正常启动，但是丢失AB记录。

（2）当记录A insert到表中，已经commit，记录B insert到表中，未commit，此时发生了checkpoint。此时的IO队列中有insert A的redo请求，insert B的redo请求，A记录从db buffer向dbfile写的请求，还有控制文件被更新的请求。当都未写到裸设备时掉电，oracle端的情况是oracle认为redo的IO请求已经写到redo log中，db buffer的请求已经写入了数据文件，控制文件已经被更新，os端的情况是redo的IO请求和写dbfiles的IO请求均未完成，控制文件未更新。重启数据库时，由于scn还是一致的，因此能正常打开，但丢失cache中的A、B记录。

（3）当记录A insert到表中，已经commit，记录B insert到表中，未commit，此时发生了checkpoint。此时的IO队列中有insert A的redo请求，insert B的redo请求，A记录从db buffer向dbfile写的请求，还有控制文件被更新的请求。当redo的请求已经被写入redo log，但是A记录从db buffer向dbfiles写的请求和更新控制文件的请求还没写的时候掉电。Oracle端的情况是oracle认为redo的IO请求已经写到redo log中，db buffer的请求已经写入了数据文件，控制文件已经被更新，os端的情况是redo完成写入redo log，但是dbfiles未写，控制文件未更新。重启数据库，oracle读取了redolog、控制文件、dbfile，发现redo log、dbfile不一样，需要介质恢复。AB数据不丢失。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

The System p Support site has migrated to a new subscription service tool for support notifications named My notifications

You‘ll need an IBM Developerwork‘s ID. (It‘s free and painless to register a new ID)

Subscriptions for IBM Systems provides the following new features:

- Ability to create multiple subscriptions with different topics and notification options
– Ability to create and name multiple folders to organize your subscriptions
– Ability to specify weekly or daily notifications when a topic is updated
– Ability to access the PTF Cover Letters directly from links in the email
– Ability to choose notification delivery methods, viewing a concise list online and/or email

For more information see the following URL. The "My notification" link is at the bottom of the page.

http://www14.software.ibm.com/webapp/set2/sas/f/enews/2008/08/newsubscribetool.html

众所周知，乔布斯是让苹果的产品滋滋作响的人，而在他身后，二把手并非体型如鼓风机的 Phil Schiller，或者橄榄球运动员般壮硕的设计明星 Jonathan Ive，而是鲜为人知的 Tim Cook。在他的管理下，苹果被 AMR Research 评为全球最佳供应链管理第二名，甚至高于以此闻名的戴尔电脑。是 Tim Cook 让苹果的运营能力与乔布斯的创造力相匹配。他被认为是“乔布斯被卡车压扁时”接班的第一人选。

但对于多数外界人士，Tim Cook 是怎样的一个人，大家并不清楚。而我们这次翻译的这篇《华尔街日报》2006年发表的这篇文章，也长期被忽视了。

这次，我们依然采用了“时间租赁”，一位叫做木遥的朋友迅速完成了这篇文章，可以说，这是我们能从外界获得的最充足的信息了。

苹果二号人物

作者：Nick Wingfield；翻译：木遥；原文链接

1998年年初，苹果公司的首席执行官 Steve Jobs 把默默无闻的 Timothy D. Cook 招入公司，职责是整顿这家衰落中的硅谷巨头一团糟的运营。

现在，八年多后，苹果复苏，而 Cook 是这家公司的首席运营官和二把手。但是公众仍然对他所知甚少——和著名到连"周六夜现场"也要拿来开涮的 Jobs 形成了鲜明的反差。当 Jobs 因为给苹果产品线重新带来了灵气而得到普遍赞扬的时候，Cook 只是一个低调的运营官，在幕后确保公司顺利地运转。

"他是那些故事背后的故事。"硅谷老将，前苹果高管 Mike Homer 说。

两年前，Jobs 在胰腺癌的术后康复期间把公司的日常运营交给 Cook 负责。苹果和了解 Jobs 的人说这位 CEO 现在健康状况良好，并且直到可预见的将来都会继续给公司掌舵。

尽管 Cook 在公众中形象低调，他在苹果的贡献仍然为他在技术圈里赢得了足够的注意，他不断的接到 CEO 职位的邀请，但了解他的人说现年 45 岁的他近期没有离开苹果的打算。他被认为没在苹果的期权回溯事件中扮演什么角色，在那起事件里，苹果给它的雇员按照在真实授予日期之前 1997 至 2002 年间的 15 个行使价格较低的日期发售了期权。

苹果本月初声称公司关于股票期权的调查表明有证据显示两位苹果前官员行为不当，并且目前正在纠正不法管理行为。然而公司并没有给出在那段时间里接受有问题的股票的人员名单，从而不能排除 Cook 接受过回溯期权的可能性。

一位苹果发言人拒绝就此进行评论或安排 Cook 接受专访。

Cook 在苹果的地位一直稳步上升。这个阿拉巴马州人在 Auburn 大学主修工业工程，在杜克大学拿到了商业管理硕士，此前曾经为 Compaq，IBM和一家叫做 Intelligent Electronics 的电脑经销商工作。他以资深副总裁的身份加入苹果，掌管电脑制造业务。Jobs 后来又把苹果全球销售和 Macintosh 部门交由他负责。去年十月 Cook 成为公司的 COO，从而身为 Jobs 的主要副手。

在 Jobs 和 Cook 来到公司之前，苹果一团混乱。1997财年它损失超过10亿美元，制造部门出了名的低效，库存臃肿，迫使它对未售出的电脑和部件进行大笔的帐面减记。这种低效的一个例子是苹果当时把亚洲运来的部件在一家爱尔兰工厂里组装成笔记本，然后其中的很大一部分又被运回亚洲市场销售。

Cook 帮助解决这些问题。他推动苹果的部件供应商在地理上贴近产品组装厂。这使得供应商把部件保留在自己的库存里而不用算在苹果头上。1998 年 9 月 25 日财政年度结束时，苹果只维持着 6 天的库存量，相当于 7800 万美元的商品价值，这比上年的 31 天库存量和 4.37 亿美元大幅降低。到了 1999 年年底，Cook 进一步把该数字挤压为 2 天和 2000 万美元。

熟悉 Cook 和 Jobs 的人们说，他们个性上的差异确保了他们形成稳健的工作关系。Jobs 以脾气无常和牙尖嘴利著称，而Cook则是一派南方绅士的温良风度。和他共事的人说，他沉静的姿态和从容的作风对苹果这家充斥着爱敲桌子的家伙的步履匆匆的公司来说是一种缓和的力量。

Cook 看起来很乐于避开舞台，那是 Jobs 天然的地盘。"我觉得他极端聪明又不以自我为中心，这在苹果很管用。"一家电脑连锁店的前经理 John Landforce 说，他在苹果顾问委员会里的时候和 Cook 当打过几年交道。

关于 Cook 的职责也有一些批评，特别是关于领导销售方面。苹果的 iPod 音乐随身听在美国大受欢迎，在亚洲却非如此。苹果说过它需要付出更多努力来在中国和韩国之类的地方鼓动 iPod 的流行。

Cook重于分析和细部，良好的记忆里让他可以很少借助笔记就能回忆起从前的会议细节。耐克公司的董事成员（Cook 也是董事之一）John Connors 回忆说，Cook 曾经在一次董事会上评论他在阿拉巴马访问过的一家耐克直销店缺乏他认为耐克店所应当具有的活力。

他"过于专注和谨慎，从客户的角度来看简直有些可恶"，微软公司前首席财务官 Connors 说，他目前是西雅图地区的一个风险投资者。

一家苹果合作伙伴的认识 Cook 很多年的高管说，在谈判中的某些场合，换了别人或许会提高音量，Cook 令人不安的习惯则是沉默而专注的盯着他的对手。他回忆起他曾和 Cook 一起离席，事后才意识到Cook 已经巧妙地修理了对方。那个人"拱手投降，但是 Tim 是用一种职业化的，手术般的方式做到这一点的"，他说。

有些时候，Cook 会更公开的表达批评，但是伴随着幽默感。比方说在一次苹果销售人员的年会上，他据说给最未能完成预期目标的销售团队颁发了一个马桶塞。

Cook 在苹果以长时间工作著称，他单身，把大多数业余时间用在体育锻炼上。了解他的人说他是个活跃的脚踏车骑手，常常在苹果会议中引述 Lance Armstrong （编注：著名自行车手）的话，并且通常早上五点就呆在健身房里。Cook 的办公室和家里都张贴着 Auburn 老虎队的大事记，这是他母校的橄榄球队。

他在加入苹果的时候冒了些风险，但是有了回报。根据 Thomson Financial 的资料，从他加入公司以后他已经出售了价值 1130 万美元的苹果股票。苹果的报表显示按今年四月份算，他持有的股票目前价值2300 万美元，并且去年收到工资和分红总计 120 万美元，这使得他成为 2005 年最高收入的苹果管理层人员。

在其他决策上他表现得就要小气一点——也倒霉一点。自从他加入苹果移居加州以来，他一直在 Palo Alto 城租房居住，只因为硅谷的房价很高，而且越来越高。Cook 的一个朋友和从前的同事，网络公司Avaya的资深管理人员 Susan Bailey 说："一年前我和他在 Palo Alto 吃过一顿晚饭，他说，'我真不能相信我没把这房子买下来。'"

Shared by Fenng
推荐，那是必须滴！

Today marks the launch of Amazon EBS (Elastic Block Store), the long awaited persistent storage service for EC2. Details can be found on the EC2 detail page, the press release and Jeff Barr's posting over on the AWS evangelists blog. Also the folks at Rightscale have two detailed postings: why Amazon EBS matters and Amazon EBS explained.

With the launch of the Elastic Block Store we complete an important milestone in offering a complete suite of storage solutions as part of the Amazon Infrastructure Services. Back in the days when we made the architectural decision to virtualize the internal Amazon infrastructure one of the first steps we took was a deep analysis of the way that storage was used by the internal Amazon services. We had to make sure that the infrastructure storage solutions we were going to develop would be highly effective for developers by addressing the most common patterns first. That analysis led us to three top patterns:

1. Key-Value storage. The majority of the Amazon storage patterns were based on primary key access leading to single value or object. This pattern led to the development of Amazon S3.
2. Simple Structured Data storage. A second large category of storage patterns were satisfied by access to simple query interface into structured datasets. Fast indexing allows high-speed lookups over large dataset. This pattern led to the development of Amazon SimpleDB. A common pattern we see is that secondary keys to objects stored in Amazon S3 are stored in SimpleDB, where lookups result in sets of S3 (primary) keys.
3. Block storage. The remaining bucket holds a variety of storage patterns ranging special file systems such as ZFS to applications managing their own block storage (e.g. cache servers) to relational databases. This category is served by Amazon EBS which provides the fundamental building block for implementing a variety of storage patterns.

I have written before about the basic features of Amazon EBS:

• Amazon EBS will be offered in the form of storage volumes which you can mount into your EC2 instance as a raw block storage device. It basically looks like an unformatted hard disk. Once you have the volume mounted for the first time you can format it with any file system you want or if you have advanced applications such as high-end database engines, you could use it directly.
• Developers can create multiple volumes, in size ranging from 1 GB to 1TB. This volume will be created within a specified Availability Zone and will be accessible by your EC2 instances running in that Availability Zone. As to be expected with a volume abstraction only one instance can have the volume mounted at any given time. Volumes can migrate and be reattached to other instances if necessary for failure handling or application migration reasons.
• The consistency of data written to this device is similar to that of other local and network-attached devices; it is under control of the developer when and how to force flush data to disk if you want to bypass the traditional lazy-writer functionality in the operating systems file-cache. Because of the session oriented model for access to the volume you do not need to worry about eventual consistency issues.

However Amazon EBS isn't just a massive volume storage array within an Availability Zone, it provides a unique feature that allows for the creation of novel storage management scenarios: the ability to create snapshots and store those snapshots into Amazon S3. These snapshots can then be used as the starting point for creating new volumes within any availability zone.

We see developers use this feature for long term backup purposes, for use in rollback strategies, for (world-wide) volume re-creation purposes. Snapshots also play an important role in building fault-tolerance scenarios when combined with managing applications using Elastic IP addresses and Availability Zones.

Congratulations to the EBS team for delivering a great service that will help a lot of EC2 customers managing their storage efficiently.