我的云计算之路

云计算,是在14年6月中旬接触的。由于自己是学渣,实在无技能傍身,就决定寻找一个培训机构。当初组织过去北京,在哪里呆了接近两周,因为专业学的java,到哪里先学的网页制作,在哪里一天的感觉那可真是碉堡了,在那里一天瞬间觉得把学校学的一年知识学了一遍,瞬间觉的信心那个满满啊。第二天学的还是网页,深入了一些,那学的一吃力,各种代码各种错,尽管有提示,从那以后信心就是无限下降,下降....学了两周之后,就凯旋回到郑州放弃了呆在北京的奢侈愿望。回到郑州后又去几个培训机构,偶然了解到了云计算,瞬间觉的哪么高大上的一个技能,代码不仅少,还赚钱多!决定学习这个技能。

在开始学习了活动目录,觉得各种绕啊绕的,偶尔晕了一次,立马恢复快照,没有看错误在哪里。(新手切记,错误也是一个积累)学了快两周,为了锻炼,让我们学习做项目,错的那个叫惨不忍睹,几度想放弃,后来项目勉勉强强做完了。

后来学习系统,首先安装了一次windows server 2008 那感觉好神奇(因为实在渣,没有装过!)然后linux,centos什么的一堆系统,瞬间满血复活,各种嗨皮,当然由于出错次数之多,快照必不可少。

系统不同还要安装相同的功能什么apache,nfs,samba等等,我觉得我学的里面最棒的也就是克隆后修改ip冲突和主机名sid冲突的问题了吧,项目也就不说了,曲曲折折坎坎坷坷的做完。

现在是最后一期学了vmware和hyper-v两种虚拟化,vmware用着还好,hyper必须吐槽,实在是太麻烦了,在vmware中装了windows server2012在里面运行了hyper,那机器怎么一个卡了得,我的还是4G机器,虚拟机不能开小,开小带的起来运行慢,开的大物理机直接卡屏卡的死!那个做的一个纠结,最后和一个8G机器搭档,勉强把曾经在vmware上面运行的故障转移群集做成功。说起来,vmware上面要用cdp,项目经理给了一个飞康的,要用2.5G运行起来,还要运行exsi那卡的也真是一个惨不忍睹。

磕磕绊绊过去了,现在终于接触到了云计算虚拟化。细的来说还真无法解释云计算到低是什么的东西,大概也就是通过网络便利,按照自己的需要付费获取一些继续计算机资源(服务器,存储应用,服务什么的,)是一堆共享的,可以配置的资源池。最省力和无人干预。最生动的例子也就是抢购小米手机了,平时没人去官网,到了抢购时间瞬间爆发那么多人进去购买,想想若果真有存储那可想想都是醉了(撑爆的感觉),小米就运用的云计算,成功的解决的当时人多的问题,花费仅仅1W左右。真是赞,尽管小米老总不差那点钱,不过也是个成功的例子。ps:项目经理解释加个人理解

现在仍然在接触云计算,我觉得前途有些许迷茫,实在是太难了!!现在学的微软云,项目经理讲的各种happy,自己在下面听的用力,可是...跟不上啊。错误各种不一样。服务各种少,(微渣)不过看了51cto各种大神的各种经历,觉得自己也可以克服下去!!写这篇文章的目的就是总结一下这接近三个月的学的一些内容和经历。IT真心不好走啊,与菜鸟们互勉。大神,站住不要走!等我们90后超越你们!!

时间: 2024-10-07 16:12:23

我的云计算之路的相关文章

云计算之路-阿里云上:Wireshark抓包分析一个耗时20秒的请求

这篇博文分享的是我们针对一个耗时20秒的请求,用Wireshark进行抓包分析的过程. 请求的流程是这样的:客户端浏览器 -> SLB(负载均衡) -> ECS(云服务器) -> SLB -> 客户端浏览器. 下面是分析的过程: 1. 启动Wireshark,针对内网网卡进行抓包. 2. 在IIS日志中找出要分析的请求(借助Log Parser Studio) 通过c-ip(Client IP Address)可以获知SLB的内网IP,在分析Wireshar抓包时需要依据这个IP进

云计算之路-阿里云上:超过70秒的请求抓包分析

超过70秒的请求是通过分析IIS日志发现的: 10.159.63.104是SLB的内网IP. 通过Wireshark抓包分析请求是9:22:21收到的(tcp.stream eq 23080): 09:22:21.299838000 10.159.63.104 10.161.241.208 HTTP 291 GET /eastsea/p/3764040.html HTTP/1.0 这个请求响应内容的长度是:Content-Length 1154110(1.1MB) 云服务器(ECS)在收到请求后

云计算之路-阿里云上:对“黑色n秒”问题的最终猜想——CPU C-states引起的

如果说2013年云计算之路的主题是"踩坑",那么2014年我们希望云计算之路的主题变成"填坑"--当然填坑是阿里云来完成的,我们只是见证曾经的坑坑洼洼变成平坦大道. 15号(周四)晚上我们发现了SLB会话保持的坑,16号晚上阿里云成功定位并进行修复,这两天正式发布后会填平这个坑.这次从踩坑到填坑的过程是最痛快的一次. 接下来我们的目标锁定在"黑色n秒"(刚发现一个英文说法:stuck for x seconds)这个坑我们最多.最神秘.最诡异的坑

云计算之路-阿里云上:CPU 100%引发的状况

今天下午17:00-17:05之间,在请求量没有明显变化的情况下,SLB中的1台云服务器的CPU突然串到100%(当时SLB中一共有3台云服务器),见下图: 造成的直接后果是请求执行时间变得超长,最长竟然达到了53秒(下图中的紫色线条). 另外伴随的表现是大量请求排队. 再看看这个时间段其它2台服务器的表现: 从这些现象分析,我们猜测CPU 100%这台云服务器出现了CPU资源争抢问题,将之从SLB中摘除后恢复正常. 云计算之路-阿里云上:CPU 100%引发的状况,布布扣,bubuko.com

云计算之路-阿里云上:什么是“黑色1秒”?

为了更好地分享我们解决"黑色1秒"问题的过程,在这篇博文中我们将专门描述一下"黑色1秒"问题的表现. "黑色1秒"是我们使用阿里云以来继"黑色10秒"之后遭遇的最奇特.最诡异.最难以捉摸.最富有戏剧性的问题. 它有2个最显著的特征: 第一个是最直观的表现,在Windows性能监视器(Performace Monitor)中会出现1秒的ASP.NET Applications -> Requests/Sec(简称QPS)为

云计算之路-阿里云上:消灭“黑色n秒”第一招——不让CPU空闲

昨天对"黑色n秒"问题的最终猜想以失败而告终,从而让我们结束了被动猜想阶段,进入了主动进攻阶段--出招. 今天出第一招--用C#写个小程序,让其在每个CPU核上运行一个线程,不让任何一个CPU核进入空闲(idle)状态,以进一步排除CPU idle引起的"黑色n秒". 在这一招中,借助的最重要的武器是System.Diagnostics.ProcessThread.ProcessorAffinity.通过给ProcessorAffinity设置一个掩码,就可以指定当

云计算之路-阿里云上:消灭“黑色n秒”第二招——给w3wp进程指定CPU核

虽然昨天的第一招失败了,但是从失败中我们学到了与多核CPU相关的Processor Affinity(处理器关联)的知识. 既然我们可以让.NET程序的不同线程运行于指定的CPU核,那是不是也可以让IIS应用程序池的进程w3wp运行于指定的CPU核? 虽然看起来"黑色n秒"似乎与w3wp运行于哪些CPU核没有什么关系,但是我们既然把怀疑对象锁定在CPU,那么任何与CPU相关的线索都不能放过.即使失败,也会满载而归,因为如果没有"黑色n秒"这个问题的驱动,我们根本不会

云计算之路-阿里云上:“黑色1秒”问题与2009年Xen一个补丁的故事

在之前对"黑色1秒"问题的分析博文中,我们将最大嫌疑对象锁定在了Xen,在这篇博文我们将从Xen的角度进行分析.也许有人会问,为什么不知道天多高地多厚地去研究不属于自己范围的问题?只因我们对一个问题的强烈好奇心--究竟是不是我们用Windows的错? 2009年3月20日,来自Intel的Yu Ke通过Xen-dev Mailing List给来自Citrix的Keir Fraser(负责的Xen开发者之一)发了一封邮件,提交了Xen的一个patch--cpuidle: suspend

云计算之路-阿里云上:负载均衡从七层换成四层后的意外发现

阿里云的负载均衡产品叫SLB,七层负载均衡用的是LVS+Tengine,四层负载均衡用的是LVS. 昨天七层SLB出现了波动,我们后来改用了四层SLB. 使用后意外地发现,用户请求的响应内容TCP出包走的是云服务器的公网网卡. 之前用七层SLB时流量走的都是内网网卡,再加上RDS.Memcached也走的是内网网卡,于是网络负载都集中在一块内网网卡,内网网卡IO成为了瓶颈.而公网网卡却闲置着,我们之前也曾想过要是将一部分网络负载让公网网卡分担该多好啊. 我们用物理服务器的时候,会把Web服务器上

云计算之路-阿里云上:“黑色1秒”最新线索——w3tp与w3dt

向大家分享一下最近排查"黑色1秒"问题的进展,"黑色1秒"的问题表现详见什么是黑色1秒. 1. 发生在w3wp进程内 判断依据:"黑色1秒"期间,http.sys的HTTP Service Request Queues\ArriveRate正常,W3SVC_W3WP\Requests/Sec正常. 2. 请求未进入.NET线程池 判断依据:"黑色1秒"期间静态文件的请求也不能被处理,如果"黑色1秒"发生在.