虚拟化就是云计算吗,两者之间有哪些不同之处?

虚拟化就是云计算,这个说法很早就有,尤其商业厂商, vmware,微软,都是把以前叫虚拟化的产品,改名为云计算。

其实某种意义上,也对,虚拟化是云计算的初级阶段。对于企业来说,虚拟化,其实就已经能完全满足需求,那其实这就是云计算。相信云计算也是有不同的阶段,不同的层次。

API接口,没有api接口的,就是虚拟化。有api接口的,就是云计算。其实也挺有道理的。因为有api接口,你才可能和第三方调用。没有api接口,你就只能通过管理界面,一个一个虚拟机创建。

不过现在很多虚拟化厂商也开始提供api接口,不过这只是部分功能的api接口。

如果说IaaS,云计算,必须提供全部功能的API接口,这个定义我还是很赞同的。

节点规模,有人说,10台的规模,就是虚拟化,1000台,就是云计算。其实也是有道理的。你管理机器的规模和你的管理方式有很大的联系。一个简单的例子,你10台机器的时候,创建虚拟机,制定物理节点,就是一个刚需。当你的设备超过1k,那么你更多的是考虑放到哪个zone里。

分布式技术,有人认为采用分布式的技术,就是云计算,例如如果你的存储是用本地存储,那么还是虚拟化,用了分布式,那么就是云计算,网络也是类似。

这个观点,还是很深入人心,符合中国人很多观念。虚拟机都是分布式的,肯定不会有所谓的单点故障。

弹性扩展

这个就更加深入人心。有弹性扩展的功能,就是云计算,没有就是虚拟化。不过大家对弹性扩展的理解,其实差异很大。对于虚拟机来说,是横向还是纵向扩展呢?

横向是指自动增加和减少机器的数量。

纵向是指自动增加和减少cpu和内存

在这个行业混了那么久,坦白说,见到和我的理解的横向弹性扩展,就是fit2cloud,真的是基于青云的上实现了自动扩展。纵向的就是刻通云给我演示过。不过这个都是局限在linux下,windows下,目前还是很难做一个demo。
其实外面的很多demo演示。在真实场景下,其实根本是无法使用的。增加虚拟机容易,减少呢?

云存储和云计算之间相比较,主要是什么关系?

现在的IT业界对于云集计算的钟爱超过了以往的任何时候,云计算产业被认为是继大型计算机、个人计算机、互联网之后的 第四次IT产业革命,IT行业进入云时代,对IT界的大小企业来说云计算就是一次炼狱。其实在某种的意义上云计算并不是一项全新的技术,是在信息化积累到一定的程度需要对于IT资源进行有效整合的客观需求催生的,因此在云计算整个的发展过程我们会看到过去很多看见过的技术跟应用模式。

云计算的概念现在已经很明晰,云计算之所以能够在*近几年快速兴起,是因为用户渴望能够充分利用IT资源来给业务提供即时按需的高效服务。云计算具体指的是:狭义云计算指IT基础设施的交付和使用模式,指通过网络以按需、易扩展的方式获得所需资源;广义云计算指服务的交付和使用模式,指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是IT和软件、互联网相关,也可是其他服务。

这是云计算的一个核心的概念,其实简单的理解就是将大量用网络连接的计算资源统一管理和调度,构成一个计算资源池向用户按需服务。提供资源的网络被称为“云”。这种“云”服务,我们可以随时的享用,只是这种服务有偿的。

说了这么多的云计算究竟什么是云存储?究竟目前云存储发展到什么程度了?云存储是在云计算(cloud computing)概念上延伸和发展出来的一个新的概念,是指通过集群应用、网格技术或分布式文件系统等功能,将网络中大量各种不同类型的存储设备通过应用软件集合起来协同工作,共同对外提供数据存储和业务访问功能的一个系统。当云计算系统运算和处理的核心是大量数据的存储和管理时,云计算系统中就需要配置大量的存储设备,那么云计算系统就转变成为一个云存储系统,所以云存储是一个以数据存储和管理为核心的云计算系统。

就如同云状的广域网和互联网一样,云存储对使用者来讲,不是指某一个具体的设备,而是指一个由许许多多个存储设备和服务器所构成的集合体。使用者使用云存储,并不是使用某一个存储设备,而是使用整个云存储系统带来的一种数据访问服务。所以严格来讲,云存储不是存储,而是一种服务。

从两者的关系来看,云存储和云计算之间的关系还是很好理解的,云存储和云计算相比较,可以认为是云存储配置了大容量存储空间的一个云计算系统。

未来云计算的应用会更加细致的深入到我们日常的生活中去,未来基于云计算的云存储会更加的深入到目前的移动互联行业,而我们现在的智能有手机在未来将有一个具有大容量云端存储,正如前面所说的,云存储不是实物,是服务,未来市场潜力巨大。

云计算、雾计算、霾计算、边缘计算是什么意思,我们应该怎么理解?

未来的世界将是一个万物互联的时代,随着物联网行业技术标准的完善以及关键技术上的不断突破,数据大爆炸时代将越走越近。

我们都知道,每台服务器都有自己的CPU、内存,但分配到这些服务器的应用往往不能充分地利用这些资源。再者,为了确保服务的可靠性往往还要预留冗余的服务器、存储器、网络设备等,而很多时候,这些硬件资源往往处于空置状态,并没有得到充分的利用。*后,正确预测不同应用对服务器的计算能力和存储器的存储能力的需求又是困难的。因此,2006年Google的CEO埃里克·施密特首次提出了云计算的概念,以及后来业界衍生出来雾计算、霾计算、边缘计算等等一系列的计算方式,接下来,让我们一起去辨析一下它们到底指的是什么。

云计算

云计算是一种利用互联网实现随时随地、按需、便捷地使用共享计算设施、存储设备、应用程序等资源的计算模式。

云计算系统由云平台、云存储、云终端、云安全四个基本部分组成。云平台作为提供云计算服务的基础,管理着数量巨大的CPU、存储器、交换机等大量硬件资源,以虚拟化的技术来来整合一个数据中心或多个数据中心的资源,屏蔽不同底层设备的差异性,以一种透明的方式向用户提供计算环境、开发平台、软件应用等在内的多种服务。

通常情况下,云平台从用户的角度可分为公有云、私有云、混合云等。

公有云:第三方提供商为用户提供服务的云平台,用户可通过互联网访问公有云。

私有云:为一个用户单独使用而组建的,对数据存储量、处理量、安全性要求高。

混合云:是结合了公有云和私有云的优点而组建的。

再者,通过从提供服务的层次可分为基础设施即服务(Iaas)、平台即服务(Paas)和软件即服务(Saas)。

雾计算

相比于云计算的高高在上和遥不可及,雾计算更为贴近地面,就在你我身边。我们知道,将数据从云端导入和导出实际上比人们想象的要更为复杂,由于接入设备越来越多,在传输数据、获取信息时,带宽就显得不够用了,这就为雾计算的产生提供了空间。

雾计算的概念在2011年被人提出,并非是些性能强大的服务器,而是由性能较弱、更为分散的各种功能计算机组成,渗入电器、工厂、汽车、街灯及人们生活中的各种物品。雾计算是介于云计算和个人计算之间的,是半虚拟化的服务计算架构模型,强调数量,不管单个计算节点能力多么弱都要发挥作用。

雾计算有几个明显特征:低延时、位置感知、广泛的地理分布、适应移动性的应用,支持更多的边缘节点。这些特征使得移动业务部署更加方便,满足更广泛的节点接入。

与云计算相比,雾计算所采用的架构更呈分布式,更接近网络边缘。雾计算将数据、数据处理和应用程序集中在网络边缘的设备中,而不像云计算那样将它们几乎全部保存在云中。数据的存储及处理更依赖本地设备,而非服务器。所以,云计算是新一代的集中式计算,而雾计算是新一代的分布式计算,符合互联网的“去中心化”特征。

霾计算

当然,无论是“云”还是“雾”,都不想成为“霾”,但是这个问题却事实存在着,如果得不到慎重的预防以及妥善的解决,那么“霾计算”就来了。

霾计算指的是什么呢?这里你可以理解为比较差劲的云计算或雾计算,因为这两者虽然概念先进,但也不是没有缺点。*,隐私与安全。现在的互联网世界,遭黑客攻击简直就是家常便饭的事,因此客户的隐私数据很容易泄漏。第二,网络延迟或者中断。云计算都是通过互联网远程访问的,虽然现在网速提高很快,但和局域网相比,速度还是有所延迟的,虽然在延时方面雾计算稍微好点,但如果网络中断,无论云计算或者是雾计算,服务都无法访问。第三,带宽会耗费预算,厂商按流量收费有时会超出预算、应用软件性能不够稳定,数据可能不值得放在云上,规模过大难以扩展,缺乏人力资本等都是造成霾计算的根源所在。

边缘计算

边缘计算指在靠近物或数据源头的网络边缘侧,融合网络、计算、存储、应用核心能力的开放平台,就近提供边缘智能服务,满足行业数字化在敏捷连接、实时业务、数据优化、应用智能、安全与隐私保护等方面的关键需求。到这里,您是否觉得边缘计算和雾计算有些相似呢?

一般而言,雾计算和边缘计算的区别在于,雾计算更具有层次性和平坦的架构,其中几个层次形成网络,而边缘计算依赖于不构成网络的单独节点。雾计算在节点之间具有广泛的对等互连能力,边缘计算在孤岛中运行其节点,需要通过云实现对等流量传输。

那么,边缘计算和云计算又有何区别?这两者都是处理大数据的计算运行方式。但不同的是,这一次,数据不用再传到遥远的云端,在边缘侧就能解决,更适合实时的数据分析和智能化处理,也更加高效而且安全。

如果说物联网的核心是让每个物体智能连接、运行,那么边缘计算就是通过数据分析处理,实现物与物之间传感、交互和控制。“边缘计算”作为一种将计算、网络、存储能力从云延伸到物联网网络边缘的架构,遵循“业务应用在边缘,管理在云端”的模式。

认知计算

认知计算包含了信息分析、自然语言处理和机器学习领域的大量技术创新,能够助力决策者从大量非结构化数据中揭示非凡的洞察。认知系统能够以对人类而言更加自然的方式与人类交互,专门获取海量的不同类型的数据,根据信息进行推论。

认知计算的一个目标是让计算机系统能够像人的大脑一样学习、思考,并做出正确的决策。人脑与电脑各有所长,认知计算系统可以成为一个很好的辅助性工具,配合人类进行工作,解决人脑所不擅长解决的一些问题。

传统的计算技术是定量的,并着重于精度和序列等级,而认知计算则试图解决生物系统中的不精确、不确定和部分真实的问题,以实现不同程度的感知、记忆、学习、语言、思维和问题解决等过程。

目前随着科学技术的发展以及大数据时代的到来,如何实现类似人脑的认知与判断,发现新的关联和模式,从而做出正确的决策,显得尤为重要,这给认知计算技术的发展带来了新的机遇和挑战。

就像“云”“雾”和“霾”的关系,物联网和大数据也是如影随形,相信通过业界人士的共同努力,定能找到更为先进的计算方式。在物联网时代来临时,我们定能合理、安全地让大数据技术为我们服务,因此不必太过恐慌,也不必杞人忧天。

容器云测试、UAT、生产环境应该采用什么样的部署架构和方式

一、全容器化部署
目前应该是几乎所有的容器云厂商在容器云交流和PoC时都强调所有组件都容器化。这样实施安装部署相对容易,一键部署、半小时搭建容器云平台。但我们在PoC测试中也发现了一些问题,比如容器资源分配的问题,Kubernetes多集群部署问题,控制节点高可用部署问题,镜像仓库定位和部署问题,中间件和不同的环境部署和定位问题等;也发现容器云平台容器异常,新的容器创建,旧的依然在,导致很多无用的容器占用资源,也带来一些理解上的困难。虽然是平台自身实现的问题,但明显是在设计时一些问题没考虑到。

二、环境管理

全容器化部署的好处是可以快速的构建一致性的环境,这也是实现DevOps的一个重要方面。所以在开发测试环境全容器化部署是没有问题的。因为这些环境需求变化快,传统维护开发测试环境需要花费大量的时间和人力,如果采用容器化方式,可以快速构建一个开发测试环境域,用于完成服务的测试。主要完成功能性方面的测试,对于可能涉及到性能测试,我们建议放到UAT环境来做。UAT和生产环境保持软硬件和部署架构一致。UAT和生产环境容器云基础组件建议部署到虚拟机或物理机上,比如集中日志、监控、服务注册发现、服务网关等组件。这样部署的目的一方面是为了更好的利用容器云的轻量化特性,另一方面也是基于安全、运维管理等考虑。

我们也一直说要用简单的方式解决复杂的问题,基于容器云基础设施,我们希望建设企业级服务中台,一家企业只需要维护一套日志系统,一套监控系统,没必要每次都重复建设。这些组件相对固定,并不需要经常改变,而且数据需要保证的安全。通常集中日志系统、监控系统等都需要集群化部署,不是一台机器一个实例能满足需求的。所以在开发测试环境是为了利用容器的快速构建特性,在UAT、生产环境则要保持稳定、安全。采用容器云在环境管理环境部署方面可以有所差别。

各个环境保持独立而又通过镜像仓库联系起来,镜像是联系各个环境的标准交付物。

三、镜像仓库

镜像仓库在容器云平台如何定位?在DevOps中起什么样的价值?这是我们考虑采用容器云平台过程中也一直考虑的问题。以前的讨论中我们提到过,考虑把镜像仓库作为开发测试和生产之间的媒介,开发测试都止于镜像仓库,生产起于镜像仓库。镜像作为标准交付物,在各个环境间传递,镜像仓库通过镜像的安全检查等机制保证镜像安全。也就是DevOps持续集成止于镜像仓库,镜像仓库是部署运营的起点。

镜像仓库要不要部署于容器?其实这个在我们看来不是很重要。首先镜像仓库是基础组件,不会经常需要更改变化,所以其实更适合稳定的部署。另外公共镜像和私有镜像会需要很多的磁盘空间,IO能力会成为一个因素。镜像仓库可以作为镜像的分发中心,也就是我们所说的各环境之间的媒介,或者不同集群之间的媒介。从这个角度来说,镜像仓库可以作为一个独立的部分,只是为容器云平台提供镜像分发服务和镜像管理服务。它可以独立部署,不依赖于容器云平台。物理机或虚拟机部署或许更合适一点,当然,部署于容器也不是不可以。

镜像仓库高可用部署是需要考虑的,这也是很多容器云厂商宣传的一个重要的功能点。如果有充足的资源,我们还是建议镜像仓库部署高可用,毕竟这样可以多一份保障,减少一些意外,但高可用节点不是越多越好,通常主备节点就可以了。不部署高可用通常也不会有太大问题,只要数据不丢失,很快的恢复,没有大的影响。

四、集群部署

Kubernetes理论上可以管理成千上万的节点,但现实总会有不小的差距。有测试显示Kubernetes集群节点数超过500就会出现超时,增加Kube Master节点并不能真的解决问题,所以每个Kubernetes集群节点数有一定的限制,在达到500左右时就需要考虑优化措施,或者按业务条线分集群部署。

通常我们这样的传统企业,节点数也不会很快达到500以上,单一集群一定时间内也可以满足需求。随着节点数的增加,Kube Master节点数也需要增加。其实*初我们考虑只要Kubernetes能保证在Master节点宕机时不影响到业务应用的正常运行,Kubernetes集群的管理工作我们可以忍受一段时间的中断,所以我们没考虑Master节点高可用,但节点数的增加可能必须部署Master节点的高可用,否则可能无法支持kubectl的正常操作。随着节点数的增加master节点数也需要增加。但master节点数超过10就也会带来一些问题,所以通常master节点数是3、5或7比较合适,支持几百个节点。

所以初始情况下,可以用简单的方式,化繁为简,化大为小,采用按业务条线多集群部署方式。这样每个集群确保不会有超过500以上的节点。超过的话考虑新建集群进行拆分。但有些情况下可能需要很大的集群,这个目前采用Mesos可能是更好的方案,从《scaling kubernetes to 2500 nodes》一文中我们了解到Kubernetes可能需要采取不少的优化措施。我们还远未达到这样的集群数量,也没有条件进行测试,所以目前还不能确切知道是否可行。也不知道是否有什么潜在的问题,厂商似乎在这方面也没有太多经验。所以如果可能的话,把大集群拆分为多个小集群,按业务条线、或者按区域等划分,应该是一个可行的方案。

五、控制节点

控制节点就是我们说的master节点,是集群中的大脑和中枢神经,控制和指挥着整个集群的运转。控制节点不可用,整个集群就会陷入瘫痪。*初我们考虑,是否有必要占用那么多的资源来部署控制节点高可用,对我们来说我们可以忍受一段时间内控制节点不可用,只要能及时恢复。部署并不是每时每刻发生,只要部署的业务服务能正常运行,业务不受影响,控制节点暂时的不可用是不会有太大的影响。所以*初我们只考虑部署一个控制节点,不考虑高可用部署。这也是基于我们ESB运维的经验。ESB的控制监控节点故障,不影响业务服务,所以我们有充足的时间来调试恢复ESB控制监控节点。不过Kubernetes跟ESB不同的是,随着节点数的增加,可能需要部署更多控制节点,实现控制节点高可用部署。

Kubernetes控制节点有多个组件,包括kube-apiserver、kube-controller、kube-scheduler和etcd等,这些组件是分开部署还是一个节点上部署?随着集群节点数的增加,可能也是一个不得不考虑的问题。Etcd应该需要单独部署,不同的场景选择合适的磁盘,以及是否使用不同的etcd集群,比如配置中心如果使用etcd,是否和平台合用同一个etcd还是新建一个,需要根据具体节点数量等情况来确定。从《scaling kubernetes to 2500 nodes》文中我们知道,etcd使用了串行 I/O, 导致 I/O 之间的延迟叠加,在节点数超过500的时候延迟就增加很多,导致Kubectl操作超时,所以etcd在改用本地SSD磁盘后,etcd终于正常了。另外Kubernetes Events 也可以存储在一个单独的 etcd 集群里,这样对 Events 的操作就不会影响到主 etcd 集群的正常工作。但这也带来了更多的资源投入,以及管理的复杂度。

六、基础组件部署

我们讨论过多次,要建设容器云平台,仅有Kubernetes是远远不够,还需要很多的基础组件来支撑整个业务应用。比如日志、监控、配置、注册发现、服务网关等组件。这些组件是容器化部署好还是虚拟机/物理机上部署好,都是绕不开的问题。

初始节点数量和服务数量少的情况下,可能基础组件容器化部署是个不错的选择。其实就像我们所说的开发测试环境,目的是为了快、敏捷,所以量不会很大。随着节点数增加,服务量增加,不只是Kubernetes自身组件会遇到瓶颈,服务治理服务管理等平台基础组件也会遇到同样的问题。

七、中间件部署

我们建设容器云,很重要的原因是希望利用云上中间件的能力。如果没有中间件服务,那将需要很多的工作来构建这些服务,不过幸运的是,已经有很多中间件可以在容器云上部署。不过同样面临一个“量”的问题,量大的情况下,是否能支撑,是否比非容器化需要成倍的资源来支撑,是否给运维带来一些困难。比如某证券的Kafka集群有20多台,内存配置一般选择64G,采用SSD硬盘,并做了raid5冗余,这样的配置在容器云平台肯定是不合适的,所以需要部署于虚拟机或者物理机上。

在开发测试环境我们还是建议使用容器化环境。在生产根据实际的情况和业务场景选择合适的部署方式。数据库什么的可能就不是很合适,虽然也支持,可以部署,但从运维、安全、组件稳定性等方面考虑,非容器化部署可能更合适。

八、微服务/业务服务部署

微服务肯定是要部署到容器上。目的就是为了利用容器的轻量、隔离、标准化、弹性伸缩等特性。微服务/业务服务往往是需要不断的改进、更新,所以服务整个生命周期要足够敏捷,不只是开发敏捷。其实从这点我们也可以看到,容器化部署比较适合经常变化的、轻量的,那些笨重的、基本没有太大变化的组件如果容器化部署可能无法展现容器的优点。把容器当虚拟机用,有点画蛇添足。其实很多公司选择互联网应用场景部署于容器云作为采用实施容器云的开端,也是因为这些原因吧。看来是英雄所见略同。

我们还讨论过容器化部署时,每个镜像可能会不小,几百兆、甚至上G,跟我们传统ESB服务部署对资源需求就有很大不同。容器化隔离更好,但是每个容器都会重复占用资源。比如Java应用,通常一台机器安装一个JDK就可以了,可以运行很多个Java应用。但对于容器来说,每个容器都需要一个JDK,所以每个镜像都需要打包JDK,在网络传输、存储、运行时资源占用,似乎都没有节约。

备份数据迁移到云端的七种方式

人们可能对云备份的方式有一个普遍的认识,即很少有人希望保留昂贵和过时的遗留系统。下面,让我们来看看云端数据备份可以为组织做些什么。
1.确保合规性
如果组织在全球拥有自己的数据中心或云计算设施,就必须遵守当地的数据法。公共云让始终遵守地理数据规则的组织能够在特定地区存储数据,并无需担心数据安全。此外,使用公共云提供的所有必需安全和认证,包括当地政府机构的安全和认证。由于能够创建为联邦,州和地方政府机构设计的独立云端区域,政府机构可以保护有价值的数据,并始终遵守这些法规。
2.打破孤立的工作流程
为什么不需要单独的备份/恢复,灾难恢复,归档和分析系统?巩固云计算中的基础架构可以集中数据管理,并消除单独的传统系统和工作流程。云计算可以更轻松地处理每个端点,服务器和云应用程序的所有数据,这意味着更高的效率,更少的人为错误和开销。此外,所有数据的中央存储库,允许进行简单的电子发现(eDiscovery)和合规监控。
3.更换过时的流程
云原生技术的出现,解决了历史上依赖内部部署解决方案的过时流程。例如,eDiscovery以前是一个繁琐、昂贵和耗时的过程。通过将其移动到云端,组织可以轻松地简化电子发现流程,完成整个流程所需的时间减少了近50%。
4.始终保持更新及可靠性
云计算没有停机时间,并始终访问*新软件。一旦组织的业务转移到云端,他们可以采用自动软件更新和安全修补程序,而不像传统系统必须等待计划更新。此外,与内部部署解决方案不同,使用云计算可以确保可接受的数据保护和可恢复性水平,价格不昂贵,并满足AWS99.99999%的耐用性保证和99.5%的可用性承诺。
5.降低整体拥有成本(TCO)
组织通过合并云备份和灾难恢复来降低资本支出。除了存储效率低以外,传统解决方案通常具有复杂的定价模式。相比之下,云存储可以扩展或缩小规模,以满足用户需求,使供应商能够提供与实际相符的“即付即用”的定价。基于使用的支付模式,降低软件许可成本以及对专用数据恢复基础设施的需求减少,来进一步缩小整体拥有成本。此外,云计算的全球重复数据删除,节省了网络带宽,并提高了千兆位有效备份速度。*终,云计算的弹性和规模可以适应数据变异性,并让组织有能力在需要时缩小储存空间。
6.整体存储节省资金
公共云架构提供较大的存储容量。在此基础上,本地云存储解决方案可实现集中数据管理,无需采用昂贵的内部设施。通过将活跃数据提供到即时恢复,并将不经常访问的数据自动移动到较低成本的冷存储库中,这时,云计算中数据的自动分层就会*大降低整体成本。此外,分层备份架构还让企业能够更轻松地满足恢复时间目标(RTO)和恢复点目标(RPO)的要求。
7.规范可用性,服务水平和成本
将二级存储工作负载转移到云端,通过共同的地理位置共享平台为企业提供全球数据备份,可用性和治理方法。通过在全球基础设施中采用单一管理点,企业还可以更好地预测成本,有效管理数据,实现服务水平合规性和其它流程的一致性。
这些是将备份数据迁移到云端的七种方式,都能够降低组织的总体存储空间和成本,同时也获得了云原生解决方案可提供的独特优势。

数据中心行业的工程师和架构师,面临的主要网络挑战是什么?

  1. 网络容量

对于参与提供网络解决方案的各方而言,网络容量是一个重要问题。如今的公司正在处理数据源产生的越来越多的数据。视频内容的扩散是一个重要因素,因为部署的物联网设备数量不断增加,产生的数据也越来越多。企业还需要处理数据的货币化问题。许多新的商业模式并不是围绕产品销售,而是将信息实现货币化和产品化。

因此,对网络容量的需求将继续增长。并且行业专家给出了很多的网络预测。而且,这并不是因为网络工程师们正在寻找更多的投资方式,而是由于人们总是需要找到一种方法来使用可用的连接和通信资源。

大数据和视频等行业趋势不断发展,但总是会有其他事情发生。例如,智能汽车共享和通信或供应链物流采用传感器,以及制造工厂采用的现场或工业控制传感器。在可预见的未来,将不会出现推动网络容量需求的用例。

除了不断变化的容量需求之外,网络还必须扩展以响应不断变化的安全威胁。随着人们越来越依赖数据和在线服务,对停机或表现不佳的网络的容忍度急剧下降。数据复制和保护策略对企业来说至关重要。

许多公司已经发现,通过将其IT基础设施转移到第三方托管数据中心,可以更经济高效地进行扩展,从而提高效率。

  1. 可扩展性

幸运的是,对于*终用户来说,随着需求激增,带宽的成本越来越低。企业面临的挑战是如何按需扩展基础设施以保持*于需求,同时*大限度地提高财务效率。例如,在企业办公室中部署IT资产的组织面临与本地环路电信服务相关的成本效率低下的挑战。这需要快速增加规模。

许多公司已经发现,通过将其IT基础设施转移到第三方托管数据中心,可以更经济高效地进行扩展,从而提高效率。尽管对网络容量、可扩展性、冗余和数据复制的需求不断增长,但这些组织可以更好地降低网络运营成本。

对网络供应商来说,选择可以随之扩展的数据中心合作伙伴非常重要。许多公司在锁定环境之前不会考虑扩展,因此会面临巨大的转换成本。Iron Mountain公司的重点是将数据中心客户引入生态系统,在那里他们可以有效地扩展网络和数据中心的容量,以满足超大规模的需求。

  1. 云迁移

云迁移是当今许多组织面临的挑战。通过将业务迁移到云端,组织实际上从操作系统级别的工作进行外包,并在第三方提供的虚拟化平台上运行其应用程序。组织必须决定哪些数据、应用程序和业务逻辑在云中运行,哪些不在云中运行。这还包括一个评估安全性、合规性、控制任务的全新范例。

数据迁移和提取是任何云迁移策略中的关键考虑因素。其中包括管理访问和云计算到内部部署数据中心的连接。

许多组织将围绕何时使用公共云与何时使用私有云制定不断发展的战略,在所有情况下,连接混合IT部署的连接至关重要。

  1. 安全性

信息安全有三个主要支柱:机密性、完整性、信息可用性。当查看这些内容时,需要考虑与谁合作以及采用什么方法来实现这一点。容量和可扩展性帮助组织实现目标。物理安全可以影响所有这三个方面。

物理安全是许多组织忽略的主题。他们可能在网络安全方面有一个强大的计划,但是物理访问设备也很重要。物理安全的失效会影响数据的机密性、完整性、可用性。

管理物理安全对于一些组织来说是一个很有挑战性的问题。这就是拥有可靠数据中心合作伙伴的关键所在。

组织不仅需要评估和考虑自己的数据保护实践,还需要评估和考虑每个供应商和合作伙伴的数据保护实践。

  1. 合规性

隐私是目前大多数合规计划的前沿和核心问题。许多组织都在努力弄清楚新的隐私法律要求如何影响其合规计划和IT战略。围绕GDPR法规创建的例法并不多,但占到企业收入4%的罚款是相当可观的,因此很容易理解为什么企业会为此担心。

人们看到的另一个趋势是更加重视供应链的完整性管理。这意味着企业的供应商需要更加勤勉。组织不仅需要评估和考虑自己的数据保护实践,还需要评估和考虑每个供应商和合作伙伴的数据保护实践。

组织需要他们可以信任的合作伙伴来保存和管理这些数据,以及相应的合同条款。对于某些组织而言,由于从合规性和审计角度审查新供应商所需的勤勉程度,新的供应商可能需要长达12到18个月的时间。因此,一些组织减少了与之合作的供应商数量,从数量更少的公司购买更多服务。

这些只是当今网络工程师和架构师面临的一些问题,但现在是应对此类挑战的*佳时机,因为市场提供了一些解决方案来帮助组织解决问题,而现在是一个充满动态挑战和解决方案的激动人心的时刻。

私有云的构建组成

无论在公有云还是私有云中,你都无需去考虑底层基础设施,而只需要通过虚拟机和网络处理业务。当然,硬件在供应商那里。如果你正在构建一个私有云,会有很多选项来决定如何去构建它。每个选项都有不同的特性、安全性能和成本,但是在任何一种情况下,你都必须保留大量的安全责任。

私有云

这些选项与传统的服务器部署模式类似:你可以部署在自己的服务器上,也可以在一个联合本地中心部署,你甚至可以在“托管但是专用”的基础上使用一个传统的托管服务。

这些指南适用于混合云及私有云。事实上,大多数组织都无法将完全私有的云适当化,但是他们可以为混合模型提供一个很好的案例。在混合云中,你可以通过公有云服务集成一个云并将其运行在由你直接管理的系统上。目前在市场上占据主要地位的公有云——AWS、微软Azure和谷歌云平台——都对这种集成提供了广泛的支持。

有很多的因素会致使你需要在一个私有环境中运行部分或全部系统。通常,依从性、安全性和性能会是主要因素,而且这些因素可能也会对你如何构建、在哪里构建私有云产生影响。

例如,你可能必须将数据保存在某个国家。你也有可能需要安装专业的硬件或使用非传统的配置。也许在公有云中为虚拟机设置的CPU/RAM配置不适合你的需求。也许你有基于GPU的大数据分析系统。你可能还会担心网络延迟。你可以在某些位置通过私有云提供更快的服务,特别是在需要本地处理时。

在自身场地部署,你需要提供一个数据中心,包括电力、电力冗余、HVAC、物理安全、物理网络基础设施和很多的工作人员。对于大多数组织来说,很难去调整。更便宜而且会同样好的方法是只把你的系统和硬件掌握在自己手里,在这个方案中,你拥有计算、存储和网络硬件,并且可以完全控制所有数据,直到它到达传输点。

而联合本地供应商则负责设施、物理安全、消防安全、电力和电力冗余、HVAC和网络连接,以及你能运行专用线路的能力。这些服务减去了很多费用和麻烦,让你能够更专注于自身业务核心。联合本地化的安排可以同时考虑到专业硬件和非正统的配置,它可以很好地改善你的网络性能。

不过联合本地供应商无法阻止你因为某些错误而使你的系统和数据暴露在攻击中,特别是在任何面向网络的情况下。解决办法通常有:确保数据在休眠和传输时是被加密的;保持对身份、身份验证和授权的控制;使用虚拟的下一代防火墙保护面向网络的工作负载;遵循*少特权原则。

托管私有云是另一个使成本下降的方案。上面所描述的那些可能会运行在联合本地设施中的公司,虽然会被承诺硬件是专用化的,但经常会在不明的情况下与他人共享其他资源,有时还会被限制控制选项。你可能不会得到一个单独的网络段或完全管理服务器的能力。在多租户、公有云环境中,肯定存在比你更大的隔离性,但是你需要仔细阅读这些难懂的条文,以确保托管服务满足你的需要,并满足计算主机所需的所有安全职责。

由于各种原因,大型、复杂的组织常常需要维护某些系统的控制。云架构仍然是这些用例的未来,但在这种情况下,它们仍然具有保护数据和软件的义务。

构建私有云时,需要考虑哪些问题?

私有云让企业能够保护并控制应用程序和数据,同时让开发团队能够更快速、更顺畅地提供业务价值。但是虽然构建私有云有望彻底改变IT,要是没有认真的规划和准备,它也无异于是一次成本高昂的科学试验。下面这十个要点有助于确保成功。

  1. 让利益相关者参与进来。私有云并不是纯粹的IT项目。将来实际使用的各个业务部门都应该参与进来,搞清楚规范和可交付成果。云改变了IT部门和业务部门之间的关系。双方都要参与其中,搞清楚并接受这种关系因私有云而发生怎样的变化。
  2. 考虑使用场合。不用说,你需要认真考虑私有云的使用场合。如果说云的使用者没有准备好使用自助服务,仍需要IT部门插手资源的配置和使用,这表明他们还没有准备好云。构建私有云的一个必要前提通常是,用户答应,私有云建成后,就使用它。不过,要确保需求没有过于单单针对某一个项目,那样它可以扩大范围,支持企业的其余部门。
  3. 度量指标是关键。参与云项目的所有利益相关者都应该就可度量的指标达成一致,这些度量指标将定义项目的可交付成果和成功。常常很难量化公司获得的敏捷性具有的好处。然而,评估私有云项目时,从提升生产力或缩短时间方面来确定可度量的目标很有用。
  4. 避免复制公共云。如果团队决意在本地环境复制公共云(AWS、Azure或GCE等),通常不会成功。私有云的设计、架构和实施应该取决于业务部门及应用软件的要求,而不是公共云中的功能特性。公共云旨在服务于一大批客户,提供对某家企业来说可能毫无用处的数百个服务。目标应该是确保目标项目的必要条件得到了满足。
  5. 专注于敏捷性。要考虑云如何为你的团队带来敏捷性,设计云时让这个好处*大化。IT部门和业务部门之间的关系应当得到简化,并为云用户提供便利。这种便利从业务部门开发及/或部署应用程序的速度方面来看应当具有实实在在的好处。
  6. 着眼应用程序而不是工作负载。传统的IT项目通常基于来自针对某个应用程序的资源配置*后阶段的需求。在私有云中,设计应用程序架构时着眼于上游为构建合适的云提供了*大的成功保障。应用程序的架构其实可以设计成云原生,这就能大大提高私有云项目的成功几率。
  7. 避免格格不入。私有云是一种非常灵活的资源池。然而,不是每个应用程序都很适合。专注于评估应用程序的需求,之后再将传统的整体式应用程序迁移到私有云。一个经验法则是,如果应用程序在物理机上运行,它可能还没有准备好迁移到云端。关注的*个应用程序应该能够按需扩展,能够处理随机的基础设施部件或应用程序组件偶尔出现的故障。
  8. 云移植性必不可少。混合之道才是云的未来。每个团队都要考虑自己想不想要应用程序能够在私有云和公共云之间移植,甚至能够跨多个公共云移植。私有云的设计和应用程序的设计都影响能否实现可移植性。一个简单的经验法则是,如果应用程序能够跨多个公共云移植,那么将来可以跨私有云和公共云移植的可能性相当大。
  9. 使用应用程序*佳实践。开发团队得认识到开发云原生应用程序方面的*佳实践,以便提高私有云项目的成功几率。12因子应用程序准则就是这样一套*佳实践,有助于开发出云原生应用程序。
  10. 为导入和迁移作好规划。并不习惯于云的传统开发团队在开发的各个阶段需要帮助,以便使用私有云。将团队导入到云需要规划和投入资源,私有云项目应考虑到这方面。将应用程序迁移到私有云是开发团队需要完成的一项重要工作;只要开发团队将这方面计入到了时间表中,项目才会成功。

私有云是企业的一条转型道路。但是就像任何转变一样,私有云需要全面考虑、认真投入和坚持不懈。如果企业能关注上述几条实践,就能顺利实现转型,让业务部门可以更快速地提供价值,将IT部门视作这场转变的推手。

向公有云迁移,需要注意哪些问题

业务迁移需全局考虑

仔细挑选那些适合以及不适合迁移到云中的服务。例如,IaaS云计算服务相比早前的计算和带宽费用拥有成本优势,不过对于那些具有较高可用性和可靠性需求的企业服务来说或许并非*具成本效益的选择,至少目前是这样。在公有云服务内建设等效系统所带来的复杂性和开支往往会抵消预期节省的成本,并降低了运营环境的透明度。

准备充分少烦恼

企业需要判断,对于它们的客户或其自身的连续性而言,哪些服务至关重要。以及,排除成本因素后,这些服务还是否有必要运行在云中。此外,企业还需要准备应变计划,这不仅包括传统的基础设施也包括云中。众多企业依然认为,弹性是公有云服务与生俱来的固有品质,但与任何事物一样,我们同样需要对它进行规划。一个基本的真理是,如果云计算服务商出现问题,用户也必然因此被殃及池鱼。

仔细研读合同细则

企业需要充分理解其服务提供商真正能提供的服务等级水平(SLAs)。例如,服务提供商的网络性能下降或将有损企业用户的声誉,就像宕机故障那样,因此,服务提供商的无故障运行时间并非云服务性能的唯一判别标准。服务水平协议必须包括诸如当服务中断是服务提供商将如何作为,违约责任,*长恢复时段,以及当企业用户希望另择它家时需要办理的相关手续及额外费用。

跟踪用户及其使用情况

企业需要寻找管理用户身份及访问自建和基于云的应用的解决方案。随着组织机构将越来越多的重要业务迁移到云中,为正确、有效地控制组织机构的IT资产,桥接混合环境的身份和访问管理功能是必不可少的。此外,支持移动环境的移动接入和认证管理也将越来越重要。在多终端接入时代,许多终端的接入都在组织机构的管控范围之外,因此,安全性和可靠性也是不可或缺的重要元素。

明确企业数据存储的位置

即便企业用户在云中存储的并非重要数据,服务提供商仍需提供企业级安全进程以保护这些或静止或活跃的数据。存储区域将取决于云服务提供商而在云环境中转移,变化频率远远超过了那些几乎完全一成不变的传统数据中心环境,因此,有助确保内容合规性的企业级解决方案也是必要的选择。

综之,有意向使用公有云的企业必须确保包括云环境在内的跨硬件和虚拟IT环境的安全性,充分理解第三方服务提供商真正能够提供的一切服务和支持,并确它们保拥有足以支撑其许下诺言的相应策略:
♦身份和访问管理
♦多渠道信息访问
♦多数据存储位置
♦响应客户需求
♦提高运营效率
♦可靠性
♦可扩展性

什么是固态硬盘,固态硬盘(SSD)的工作原理是什么

所有计算机都需要一种方法来存储、检索和共享数字信息,这通常是通过硬盘驱动器完成的。硬盘驱动器使用一个或多个快速旋转的磁盘或涂有磁性材料的盘片磁性存储数据。*早的硬盘非常大而且非常昂贵。

目前,有两种主要类型的驱动器用于存储数据:硬盘驱动器和SSD,今天我们主要关注SSD。

什么是SSD?固态硬盘是一种存储设备,它将数据保存在闪存中,而不是像硬盘驱动器之类的磁性系统。

固态硬盘之所以如此命名,是因为它们不依赖于移动部件或旋转磁盘。相反,数据被保存到一组存储库中,就像你可以随身携带的闪存一样。基本上,SSD就是安装在计算机/服务器内部的闪存驱动器的放大版。

SSD容量

目前市场上比较流行的是256GB的容量格式,存储范围从64GB一路攀升至1TB,专业厂商提供TB级的产品,具体取决于制造厂商的设计。容量在128GB和256GB之间的固态硬盘相对来说性价比更高。

SSD可靠性

SSD驱动器没有可磨损或损坏的运动部件,这比常规硬盘驱动器提供了更好的性能和更高的可靠性。此外,SSD还提供增强的数据完整性和耐用性,因为它们即使在未通电时也能保留数据。

SSD性能

使用SSD,你的数据以更快的速度移动,这将提高你的服务器整体速度和响应速度,从而提供更可预测的生命周期。典型的SSD具有40到100微秒的访问速度,这比普通硬盘驱动器快近100倍。更快的访问速度意味着程序可以更快地运行,并且工作在服务器上的压力更小。

SSD电源要求

SSD比其他类型的存储介质需要更少的电力和冷却,因为它们产生的热量远远低于通过磁盘旋转产生热量的普通硬盘驱动器。

在负载情况下,SSD可以在2.5–3.5W的功率范围内使用。由于SSD驱动器性能更好,与传统硬盘驱动器相比,它们在空闲状态下花费的时间更多。这仅仅意味着SSD比普通硬盘驱动器提供的每瓦特效率提高了一个数量级。

为什么SSD驱动器对你很重要

在当前服务器设置中使用SSD驱动器的好处将在容量、性能和可靠性方面得到全面提升。这意味着,随着这种类型的驱动器的添加,你将能够存储的数据量将增加,每千兆字节的总成本将总体降低。如果你要渲染图形或处理视频,SSD驱动器可以在整体传输数据时节省大量时间。如果分析大量信息,SSD会大大减少处理时间和服务器负载。

此外,实时播放这些视频的能力将大大提高,这将允许无延迟的视频流。从长远来看,SSD将提供你所需要的速度、耐力和稳定性,以确保你的信息被准确地共享。所以说,SSD驱动器对你的业务发展能够起着关键性的作用。