Sunday 10 March 2013

带你攀顶云端高级认证,有这回事?



带你攀顶云端高级认证,有这回事?

论天下大势,云计算风起云涌。作为云计算的强力引擎,掌握虚拟化技术,也就把住了云计算的脉搏。拥有VMware高级认证(VCAP-DCDVCAP-DCA)是你技术生涯的一个新的起点,因为它不仅仅是一个认证,在这个过程中的成长是实实在在的。

和你们中很多人一样,我也曾在众多的考证路上艰难跋涉过。VMware高级认证VCAP以及尖峰认证VCDX绝对是我引以自豪的一段经历。可这条路并不容易。当时我能找到的信息极为有限,基本上是摸着石头过河,对认证要求和自己能力评估都有偏差。当时如果有人能带我一程,肯定会避免很多弯路。如果你有也有同感,下面的信息可别错过了。
大中国区首场攀顶云端尖峰认证,备战VCDX专题讲座将在2013320VMware合作伙伴大会上隆重推出,地点:北京JW万豪酒店

另外还要正式发布一个好消息,vBrownbag在中国安家了! vBrownBag是一个全球虚拟化技术爱好者的非赢利独立联盟,目前已经在北美,欧洲,大洋洲和拉丁美洲有很多参与者,定期的网上互动讨论很受大家好评。作为这个联盟的一分子,我受益良多。也有幸授权在中国开始vBrownBag的网上讨论活动。目前参与组织讨论的核心成员有:
 @FrediYao  -  VMware大中华区高级技术讲师  VCAP-DCD  VCAP-DCA
范军 @frankfan -  VCDX #93  (本文作者)
很希望有更多的人能参与组织和分享虚拟化学习的经验心得!
每次Webex讨论都会预先设定一个主题,主讲人会先分享一些经验心得,并尽力回答参与者随时提出的问题。  每次讨论的内容时间会通过新浪微博和博客发布。
vBrownBag中国区的首次讨论内容:
       vBrownBag介绍
       项目流程概述
       体系结构分析
       体系结构设计
                设计方法;设计标准;设计原则
       设计案例分析

时间:314下午北京时间17:00-18:00
课程号:963 906 311
密码:vmware
点击进去后,左侧选择“不公开课程”,输入课程号,加入即可。

音频使用方法(二选一):
1、进入webex后,有音频提示对话框,或者在菜单里选择“音频”,然后点击“呼叫计算机”,可以使用耳麦进行音频接收(推荐,免电话费)。
2、使用电话拨入,拨号如下:
China - South Toll Free 10-800-140-1718
Hong Kong Toll +852 58081912 
Hong Kong Toll Free 800-933667
Taiwan Toll Free 00801-12-7316
然后输入相应课程号和访问者代码即可。(可在webex培训主界面上查到)
期待您的参与!

vBrownBag

Wednesday 6 March 2013

成功的虚拟化系统是如何炼成的?设计篇


成功的虚拟化系统是如何炼成的?设计篇
一个项目的成功归功于很多因素。可若想毁掉一个项目,一个失败的设计就足够了。
好的系统设计像一部好的小说。整体布局,细节,关联,一个都不能少!
团队中架构师的作用就显得很重要。架构师不仅需要眼观六路,耳听八方,对一些技术细节有相当程度的了解。而且要对项目进行中各个阶段的重点,以及对设计决定所产生的影响有充分的认识。你准备好了么?
咱们从传统项目过程中的不同阶段来说说吧。本文以虚拟化设计为案例。
我设计了一个图来帮助分析部署系统的几个阶段。

    需求分析阶段
客户需求
在需求分析阶段,需要挖掘出客户真正在乎的需求,最好对需求进行分优先级,不能眉毛胡子一把抓。而且需求并不是一成不变,项目过程中增减需求是平常的事,但由此造成的影响要评估并更新文档。有时项目组需要和客户协商撤销或者推后某些需求。可能的原因有:造成整个方案成本大幅上升;与其它关键需求冲突;可能造成项目延迟等等。
环境的限制
这点尤其重要,却常常容易被忽略。在分析阶段尽可能挖掘限制条件,会避免后面阶段很多的问题。比如客户已经在使用NFS,并且现有维护人员有能力维护该系统。你在推荐SAN的时候就要考虑带来的影响;若客户与某大供应商有协议,你是否可以考虑其它厂商?若客户有较严格的安全性策略,设计共享时要考虑哪些部分是不可以共享的,是否需要虚拟层的防火墙等等。
假设的条件
有时在项目执行中会因为某些需要客户或第三方完成的事情不具备,而造成项目延迟。这就需要在合同中就对这些假设特别说明/,以避免后面的责任不清。比如假设客户网络环境是可以支持你的设计的,可实施时才发现上行网络的防火墙的带宽或端口限制会大大影响你的方案的性能。 比如假设你需要使用客户已有的数据库,却发现版本和你的方案不兼容。

  设计阶段
概念设计
根据需求分析阶段的信息,应该尽快出一个概念设计的草图来描述以下信息。系统大概分几个运行环境,是否需要单独的开发和测试环境; 多个数据中心之间的联系,是ACTIVE-ACTIVE还是ACTIVE-PASSIVE;数据是否在数据中心之间同步;虚拟和物理网络如何共享等等。
逻辑设计
以概念设计为纲,逻辑设计描述了更多系统各部分的联系。HBA和光纤交换机,存储设备是如何联系的;集群是如何设计的;主要的管理软件等等
物理设计
依据逻辑设计,物理设计具体到使用什么设备和型号,与上行物理网络的联系,服务器在机柜位置的分配等等。
可能的影响和风险
某一个设计决定可能会影响到其它设计决定,也有可能带来一些风险。需要评估风险并提出规避风险的方案。
最佳实践(Best Practice)
盲目照搬所谓的最佳实践,可能并不适合你的环境。需要知道最佳实践背后的原因和使用的环境。
重点是不仅知道做什么,还要知道为什么这么做。为了避免人们对所谓最佳实践的误解,VMware
已经将其更改为设计指导
模块和整体
虚拟化方案大概有存储、网络、主机及集群、虚拟机和管理系统几个模块,按模块设计有助于系统的深入设计一个主题。不过一定要注意模块间的关联。比如你虚拟机的内存由2G改称4G,那么集群设计中的内存就要重新考虑,同时影响到了Swap空间增长,存储也要考虑。
在设计阶段需要完成的文档有以下:
架构设计
整个系统的概述和各个组成部分的描述。
安装手册
具体的安装步骤。当然不是说要细到怎么安装vCenter,标准安装可参照已有官方文档。关键是要突出设计中针对用户环境定制的部分。比如你网卡负载均衡采用Load based teaming;集群的Admission control policy在只有20%空余资源时生效等等
衡量一个好的安装手册很简单,如果有经验的系统管理员按照安装手册部署的系统,没有和架构设计有大的偏差,应该算是可以的。
实施计划
在真实环境中项目经理负责和架构师一起制定适当的计划。干什么,什么时候完成,谁负责等等。
有经验的架构师可以分析各项任务的倚赖性,做好统筹分派。
测试计划
很重要的一步,怎么才证明你的系统符合用户要求?怎么才让客户签字?成功执行测试计划尤其重要。
运行计划
架构师要有全局观,某些设计决定对运维环境,人员能力以及成本都有影响。比如,vCenter Linked clone会让维护人员用一个管理界面管理两个vCenter 尽可能利用脚本或者现有软件自动的功能减少重复性的人工和不必要的人为失误;考虑激活EVC 避免以后新添服务器需要重启集群中的服务器。
 本文小结:
成功的系统是怎么炼成的?
充分了解真正客户需求,并采取合适的技术方案满足需求,是关键的第一步。沟通协商能力和技术能力一样,二者不可或缺。 也要注意灵活性,有创意的解决问题。不能因为所谓技术上的完美,牺牲其它客户很在意的方面,比如成本、项目进程、人员等等。有时适当的中庸之道不失为一个可行的方案。

我的VMware认证设计专家(VCDX)之路-心得篇


作者:范军 (Frank Fan)
新浪微博:@frankfan7
Twitter:  @frankfan7 
此文是继下面两篇文章之后的几点心得体会,博您一晒。

我的VMware认证设计专家(VCDX)之路 

我的VMware认证设计专家(VCDX)之路-经历篇 


 VCDX就像马拉松,别轻易被唬住
一次通过的牛人毕竟是少数。不少VCDX申请者都是屡战屡败,屡败屡战。要是一下子问“你能跑马拉松么?”大多数人都一缩脖。再问你能跑20公里么,你还犯怵。10公里呢,要豁出才能成。5公里呢,咬咬牙应该行吧。 回首我的经历看似非常难,其实人在其中的时候,并不觉得多难,每天完成订好的计划,一步步做就是了。更重要的是,这个目标让我每天的工作都觉得很有意义,每天能为自己的点滴进步觉得欣慰。我给客户讲解方案的时候,客户的每一个问题我会当作答辩的问题认真看待。更会提前想客户会问什么问题?
转换思维定式
我们从小的教育是尊重权威,照老师教的错不了。这种观念流毒不浅。殊不知白皮书上的Best Practice是死的,用户需求和环境没有一成不变的。我们需要灵活并有创造性提出合适的设计方案。
人有多大胆,地有多大产
绝大多数人的潜力可能仅仅被开发了很少的部分。你不知道你自己可以更优秀!如果我们的目标定得太实际了,无形中就给自己头上罩上了玻璃罩。敢于梦想是很重要的第一步。有梦想还不够,还要订目标。每个月的,每周的,甚至每天的。这样就不至于到头来手忙就乱。
一个好汉三个帮
在你意志消沉的时候,没有什么比朋友的鼓励更给力的了。
 VCDX不是结果,是个新的起点
虽然是值得自豪的一段经历,欣喜过后觉得压力也无形中增加了。对自己的标准高了,
别人对你的期望值高了。总不能吃老本吧,做出的东西不能太离谱吧。
同时对迎接其他挑战的信心也强了很多,这是我最大的收获。
 新年礼包
刚过新年,就收到了VMware从美国寄来的一个大箱子。虽然很早就知道有这么回事,还是按耐不住好奇急忙打开它。宝贝还真不少呢。这是VMware为庆祝全球超过百人拥有VMware设计专家认证(VCDX)的一次庆祝活动。每位专家都获得一份礼物。最喜欢的是印有自己名字的奖杯和VCDX牌啤酒了。







我的VMware认证设计专家(VCDX)之路-经历篇


作者:范军 (Frank Fan)
新浪微博:@frankfan7
Twitter:  @frankfan7 


感谢网友们的留言鼓励我的VMware认证设计专家(VCDX)之路。我一激动就话多,于是就有了下文。除了自吹自擂外,还想结交各路豪杰,也为有兴趣攀登科学高峰的同学提供些经验教训。若有您看不惯的地方,就当个乐子吧。

引子
是什么让我决定挑战VCDX?
借机会拽一把。 请问你为什么登山?因为山在那里。
事实上我是逼上梁山的。
 上篇   初试锋芒
IT这么些年了,考证的情结始终不灭。当年从RHCE(Redhat Certified Engineer)的认证过程中还是有些收获的。不过在2010年初对传说中的VCDX还是高山仰止,可望不可及。因为当时全球也就20名左右VCDX而已。我当时已是VCP,可还有两门考试和文档设计和申请要做。一位当时的同事问我,咱俩弄个兴趣小组,一帮一,一对红,如何?这才有了后来的慢慢长征路。
我于是在一个月之内通过了Advanced Administrator Advanced Design 考试。因为该考试在我所在城市墨尔本没考点,我自费飞去悉尼几次考试。可是我的文档设计没能在申请日截止前提交。错过了20107月在墨尔本的答辩机会。而我的同事在经历美国答辩失利之后,成功把握住这次机会,成为全球第37VCDX.  我那个羡慕嫉妒恨啊,同时口水留了一地。
这一误不要紧,随着vSphere的推出,VCDX3也升级到了VCDX4。还得再考一门Advanced Data Centre Design vSphere 4.0.   开始和另外一位同事成立学习小组开练。猜猜我考了几次。不怕丢人,咱考了三次才过。第一次是受邀参加Beta版,题比正式版多。第二次时间没掌握好。第三次才过。虽然说也是经历数次雅思水火洗礼的,可在考试中英语阅读大量案例,在时间上还是比英语为母语的人有点吃亏。虽说经历有点曲折,但有机会系统的把很多官方White Pager PDF文档都看了几遍,也在工作中有意识的点滴积累,不仅想着把活干了,还要想为什么这么做,有其他方法没?
这一晃就20115月了,这时候得知在新加坡11月有答辩机会。决定冲一把。白天带项目,晚上闭门造车搞设计文档往往夜深。第二天还得照常上班。当时仓促的拼凑了一个假想客户需求,套上一个我自认为四平八稳的方案。没经过真实客户环境验证,漏洞自然不少。在答辩中没有能充分表现出自己的经验和能力。也没有充分的自信说服考官为什么该方案可行。
另外一个小插曲是由于预订班机的取消,我抵达新加坡也是答辩当天的凌晨2点,胡乱睡眠后状态不是最佳。在答辩没结束的时候我个人就预料到了失利的结果。

下篇     水到渠成
失利后心灰意冷,决定金盘洗手,退出江湖。无奈在2012年初的悉尼vForum大会上遇到一位原来的同事,哭诉我的经历之后,哥们以三寸不烂之舌让我重燃希望。于是在他及其朋友的激励下,重头再来。我们组成了VCDX预备队锵锵三人行。有几个周末和晚上就是在小组讨论和模拟答辩中度过的。后来的事实证明,学习小组是成功的关键因素之一。我们互相挑战对方的观点,完善自己的方案和补充自己的短板。VCDX要求的不仅仅是VMware知识和经验,还要求对网络,存储,安全以及你设计中的方方面面的透彻掌握。优秀架构师的素养和思维方式,在设计文档和答辩中要充分展现。考官考量的不是你的设计方案多么完美无缺,而是你为什么这么做,是否在考虑了客户环境的限制,风险,执行等各方面后还能自圆其说。这就要求你有足够的现实案例来支撑你的方案。基于假想的客户环境的设计是允许的,但你答辩的难度之大会可想而知。
吸取了上次的经验教训,我提前一周抵达多伦多准备五月的答辩。一边倒时差,一边调整自己的状态和温习设计方案。不知道是时差还是紧张,一周中我基本上在凌晨3点之前根本睡不着,好在答辩是周五下午。
演出开始了,面对三位VCDX考官,我自信的陈述了设计方案,与上次不同的是,因为有充分的准备,我很好的回答了提出的问题。第一关45分钟的方案陈述及答辩我觉得完成的不错。短暂10分钟休息后开始30分钟的现场设计。考官扮演的客户提出需求,你需要一步步推演出大概的设计草案。看官会问了:“有没有搞错,30分钟设计完整方案?这在现实中做第一次需求分析的时间都不够。”
这个环节考量的是你是否有清晰的思路,在关键点上问合适的问题,一步步设计大致框架。我认为这种能力是需要在日常工作中有意识培养的,VCDX认证答辩阶段不是说你学了很多书本知识,到时候碰个运气,努力一哆嗦就有戏的。其实这是你多年第一手经验和能力浓缩在半天里的自然体现。坐在你面前的三位VCDX考官也是这么一步步磕过来的,你说他们会轻易降低要求放你一马侥幸过关么?
这个环节给我给自己及格分,大概覆盖了计算,存储和网络的关键设计决定。可由于时间关系,没能应对所有的设计需求。
紧接着第三关就是30分钟现场排错了。考官提出一个客户存在的问题,你分析什么地方可能有问题。我分析了方方面面后还是没能最终找出症结所在。其实结果也不是最重要的。考量的是你思路是否清晰,能否有条理的一步步用排除法缩小包围圈。
所有环节结束后我有机会对考官说考证感言。我声音哽塞无限深情地表达了我对虚拟化技术的热爱,以及在认证过程中的收获。当然还有感谢考官们的辛勤耕耘及表达仰慕之情等等。
接下来就是漫长的两周的等待,终于有一天收到一封关于VCDX结果的邮件,忐忑不安的打开后,跃入眼帘的是“It gives me great pleasure to welcome you to the VMware Certified Design Expert community. Your VCDX number is 93. "  这让我不太敢相信,掐了自己几把后,才反复确认不是做梦。
 更值得欣慰的是,我们并肩作战的三剑客获得100%成功,另外两位分别是VCDX #83  VCDX #90
后记
几年的努力,总算是对自己,家人还有支持我考证的公司有个圆满的答案。
回首看来时路正如登山。不必怕山高路远,只走好眼前的一两步即可。不经意间,你已经登顶。
回首向来萧瑟处,也无风雨也无晴。


更多心得请看:

我的VMware认证设计专家(VCDX)之路-心得篇




Monday 4 March 2013

实战虚拟化之设计模板



作者:       范军 (Frank Fan)  
新浪微博:   @frankfan7
Twitter:   @frankfan7
博客:                 b.GetToCloud.com

原创作品,随意转载,转载时如果您能注明原始出处、作者信息和本声明就能帮助他人看到最近更新。谢谢!


   如果把一个项目比作战役的话,项目经理是三军统帅,架构师就是羽扇纶巾运筹帷幄的那位.仗怎么打,就看你的你的战术和战略了。

未战而庙算胜者,得算多也;未战而庙算不胜者,得算少也。多算胜少算,而况于无算乎!-孙子兵法

   挑战
大型虚拟化项目涉及面广,模块关联多,架构设计师经常面临的挑战有以下几个方面:
满足客户关键需求
和关键客户的会谈的机会是很宝贵的,能否有效的挖掘商业和技术需求,直接关系到项目成败。架构师要有清晰的思路来掌控会议的话题和进程。哪些方面需要深入发掘,哪些方面大概覆盖,哪些方面暂时搁置,都要心中有个大概计划并灵活应对。
需求有了之后,设计并实施的过程中是否全面考虑满足那些需求呢?
掌控全局和深入局部
技术专家常常容易犯的一个毛病就是只见树木,不见森林。有时容易沉浸在技术细节中,而没能多着眼大布局。有时候对一个设计决定的风险和影响估计不足。
设计实施计划
技术蓝图之外,还要靠缜密的实施计划,才能有效利用资源,规避风险和保证质量及进度。
我设计了下面的架构设计图来说明了虚拟化项目的成功要素。屋顶代表客户需求,这是我们的终极目的,一切的努力都是要把这个屋顶撑起来。五棵柱子代表虚拟化项目中的关键模块。每棵柱子的技术决定都会对紧接下面一层的风险有影响。再下面的三层分别是假设条件、环境限制,客户环境。最下面的一层基础是实施计划,直接决定了项目执行的成败。

 案例
光练不说是傻把式,光说不练是假把式,咱还是实战演习一把练练真把式。
下面的客户需求摘自VMware VCDX训练营提供的一个案例。

 谢谢看官耐着性子看到这儿,是不是觉得有点晕,有点乱,不知道从哪儿着手?这就对了。不只你晕,我也晕。


VCDX最后一关面试的时候是要求30分钟内对以上客户需求出个设计草案的,打仗没章法,那怎么成?我第一次VCDX面试的失利,原因之一就是因为折在这儿了。说着说着没词了,不知道下一步问考官扮演的客户什么问题,也不知道是不是满足客户需求了。
别急,咱有招儿,翠花,上模板!

  模板
我又发明了个图(您是不是嘀咕了,我好像别的不会,就会画图凑字数,糊弄个推荐文章?)个人觉得还是有拨云见日的功效的(吹吧,接着吹~


下载该图的最新的Excel模板。您要还有兴趣往下读,需要结合模板,要不肯定一头雾水。
咱们把上面零碎地信息往这模板里一填,是不是清晰多了?
解释一下,ID是该条目的标识,而OIDOutcome ID)是与此条目有关联的其他条目ID。好处就是标出了条目直接的关联,很容易查证是否满足的需求,并且掌握了设计决定之间的关联。
我仅仅列出了设计中较为重要的一些考虑因素,细节部分还需具体问题来具体研究。
在客户需求会议之中着重于模板的蓝色部分,会议中就有章可循。当然不指望一次会议就全弄清楚。
在设计过程中根据蓝色部分的信息,一步步勾勒出绿色部分的大致信息,然后再具体细化。
咱们就拿其中一个具体的需求来说事儿吧。
R1  客户需要把200台物理服务器虚拟化。下一步直接要考虑的就是 H1
1  H1-目标ESXi服务器选用什么硬件?大概多少台?
环境限制中的 C3C4以及条件假设A1 就大概决定了H1
C3:尽可能继续使用原来的服务器并说明了其配置
C4:新购买了五台服务器并说明了其配置
A1:假设15物理服务器的工作量将在1ESXi主机上运行,那么一共200台服务器
200/15=13.3  取整后是14,再考虑额外2台主机作为Failover Capacity, 14+2=16
2 具体ESXi服务器的配置  
H1有关联的条目(OID)是H2H3
H2:需要按照C3来计算所需要的ESXi主机的CPURAM需求
Number of vCPU socket number * core number * 物理主机数(2 * 2  * 200 = 400
在第一步中我们预计需14ESXi主机
400/14=29   一台主机需要满足29 vCPU
RAMRAM * 物理主机数 4 *  200= 800 G
同理:800G/14= 58G   一台主机需要有58G可用内存

新购服务器的配置是:
CPU physical cores:   2-cpu * quad core( 2*4) = 8
Ratio of physical core: vCPU =  8:29 = 1:4  , 还算是稳妥。
RAM:  不清楚
至少RAM要有20%的空余吧
58G / 80%  = 73G 
这就看内存的价格了,可能上128G比较合适
可是我们只有5台新服务器啊,16-5=11 还有11台没着落呢。
别忘了条件限制中的C3:尽可能使用已有服务器
已有服务器只有4G RAM,这就肯定需要扩容到最大支持的内存了。

还有一个案例中透露的细节是,200台主机是分3个阶段来虚拟化的。为什么?第一是 根据需求R2来制定执行计划P1:  把关键应用的服务器放在最后一个阶段。 第二:我们可以利用虚拟化完成后的服务器,作为ESXi主机来补充新购服务器的不足
经过以上分析,是不是主机和集群的框架就出来了?
还没完呢,存储网络的事儿还没说呢,很多看官耐着性子听我罗嗦到这儿,谢谢了。咱还是下回分解吧。