企业级IaaS架构的深度解析

本文涉及的产品
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
云解析 DNS,旗舰版 1个月
简介: 根据IDC的分析报告,美国和中国云计算产业发展差异巨大:美国以公有云为主,SaaS最大、IaaS最小;而中国截然相反,以私有云为主,IaaS占了大约50%的份额。

一、 关于云


1. 云产业分析


根据IDC的分析报告,美国和中国云计算产业发展差异巨大:美国以公有云为主,SaaS最大、IaaS最小;而中国截然相反,以私有云为主,IaaS占了大约50%的份额。


究其原因,跟中美两国云计算产业发展的阶段、成熟度有很大关系。


中国的公有云主要使用者是小微、创新企业等。我认为IaaS公有云已经或者将要巨头化,PaaS还有机会,SaaS会是云计算几大分类中的爆发点,但是要看准行业。


在诸多产业中,中国云计算私有云市场主要的客户来自:通讯、金融、政府。金融行业受安全、政策、法规的约束,几乎不会选择公有云,大型国有银行私有云的建设步骤也很谨慎、渐进式,会首先考虑迁移非核心应用;小金融相对对新技术比较开放,会实验一些开源的技术,如Openstack、ceph等。


政府由于“十二五”、“十三五”政策持续推动、对于政务云建设的现实需求、统一纳管基础设施资源、节省成本等考虑,对云计算的投入较大。


2. 国内有私有云需求的四类企业


a) 政策驱动


因为政策持续推动、创新补助、领导要求(政绩)等原因,需要上云的企事业单位、行政机关。


b) 人云亦云


不解释,:)。


c) 新技术跟进


看见新技术的发展、成熟,希望在其中分一杯羹,也包括IDC之类的转型企业。和上一类的区别一个是模糊的、被动的,一个是有自主想法、主动的。


d) 为业务而云


因为业务发展规模(含弹性)、统一上收资源、成本等考虑云。主要也分两类大型互联网企业和传统大型企业。


前者因为业务发展需要考虑云计算,从成本、技术可控性考虑,会采用大量的开源技术,同时会对硬件、软件提出改造要求,大力发展分布式、集群技术以适应其性能、可靠性等需求。典型的代表是阿里等。


而传统大型企业走的是另一条路,相对稳健,会选用成熟可靠的商业化解决方案为主,如虚拟化选择VMWare。另一方面,这类企业相对比较谨慎,会以规划咨询、POC、招标、建设、交付、运维相对固定的模式去建设云。典型的代表是大型央企。


3. IaaS、PaaS、SaaS分析


我把顺序放过来,先说SaaS,再说PaaS,IaaS。


SaaS我认为主要会在三种情况下出现:


a) 行业SaaS


有行业属性的SaaS,如教育、医疗、培训等。


b) 工具化SaaS


比如workday类似的管理工具、office365类似的文档工具等。


c) 大型企业(组织机构)内部SaaS


有些企业内部,各地/部门业务类型相对一致,使用SaaS软件统一上收权限,节省成本等。


如我之前所说,如果找准行业、方向,SaaS可能是创业的大风口。


PaaS的实现我认为有两种:


a) 基于商业化自动部署工具的


大型企业考虑人员技能、维护成本、可靠性等要求,较多选择类似方案。HP、IBM、BMC等都有类似的工具。自行实现的话,可以考虑流程引擎加上脚本执行器再加部署包。


b) 基于开源框架和软件的


选择cloudfundry、openshift框架,加docker等技术,目前随着相关技术的成熟,越来越受到关注。上述的几个大外企实际上也有类似的实现。


IaaS的情况比较复杂,我认为难度主要在理清几个头绪:


a) 业务对于底层资源的要求、约束


联想的架构师团队正在做一件事情,就是梳理业界存在的十几种主要的企业业务架构(如电商、搜索等等),分析和总结它们对于资源的各方面要求,如计算能力、IO等等。


b) 服务的设计、编排


需要从业务的承载要求、客户消费方式、业务系统架构、部署方式、虚拟化方式、集群、资源类型做统一的规划设计。根据对客户现有情况的分析,尤其是IT系统现状、痛点等,得出客户的期望,进而设计出客户需要的服务。


c) 服务与资源的关系


很多人搞不清楚什么是服务,什么是资源,甚至有个号称云架构师的人跟我说,他实习了对虚拟化的纳管、资源调度,就是完整的云。


资源(resource):在系统中, 基础设施、network设备,VM、host、OS、CPU、Memory、存储、software等等都被视作可分配资源。


服务是云计算的核心特征,根据业务要求等可以编排服务,使之能让客户消费,通常会绑定价格、SLA等一些附带属性。


d) 租户与组织的关系


要想清楚,根据客户现状,组织与租户怎么对应,是1对1,1对多,还是多对多。


e) 资源调度的原则


要考虑资源调度策略、资源类型、性能要求,同时要考虑弹性的时候如何伸缩。经常会有只能scale out,不能scale in,或者频繁scale out、in的情况出现。那么在考虑弹性判断条件、算法的时候,要综合几种监控告警数据,如业务、资源。


二、 IaaS方案


1. IaaS架构影响因素


如我之前在群里所说的,个人认为很多因素都会影响企业IaaS架构的选择,主要有以下一些:


a) 企业IT发展规划


b) 企业组织架构


c) 企业管理制度


d) 业务类型


e) 应用层次


f) 人员技能


g) 技术成熟度


h) 成本


i) 周期


j) 运维体制


k) 。。。


如果不考虑其中的某个因素,都有可能导致项目的失败。我曾经亲身经历过,因为管理和客户组织架构原因导致的云项目失败。客户在实施云计算建设之前,业务部门是强势部门,IT部门是支撑部门,而在规划和建设中忽略了客户组织架构的影响因素。IT部门变成了云平台的管理者,业务部门成为相对弱势的云服务消费者,导致客户内部组织架构重组、项目停滞。


2. 私有云IaaS平台构成


我这里讲的是广义的云平台,我一般认为分成几大部分:门户(管理和自服务)、服务层、统一资源层(含适配器层)、基础设施(含虚拟化),紧密相关的有BSS、OSS子系统;外部可能交互的系统有ITSM、CMDB、外部监控系统、4A系统和通知系统等。我画了一个主要部件的草图,方便大家理解:




a) 门户分为管理和自服务,分别给管理员和普通用户提供服务;用于展示基础设施、平台及软件服务,并控制用户接入方式,对用户的访问范围、界面的展示方式做设定等。以便于管理员和普通用户获取服务的信息,申请并使用各类服务。


b) 服务层指服务构建与设计的逻辑组件,它负责定义服务的结构、流程等信息,组装原子服务,生成业务服务,发布到服务目录,监控服务运行状况等,形成完整的服务生命周期管理。业务用户可以通过服务管理层获取云计算服务;管理员可以通过服务管理层监控所有服务实例的整体状况;服务开发人员可以通过服务管理层定义和发布服务。服务管理层将以业务服务的形式对外发布所有的服务操作接口。


c) 资源层指管理和调度软硬件资源的逻辑组件,它负责构建资源池,生成简单资源供应的技术服务(原子服务),定义资源运维的操作流程。为了组成资源池,一般将同质的设备集中安装,相互连接,并通过一定的管理软件来监管和配置。资源池由同质的一组资源组成,用户可以通过资源管理层软件从资源池中申请资源,指定该资源实例的配置,并管理其运行。管理员可以监控每个资源池的资源使用率,健康状况和性能状况。资源管理层将以技术服务的形式对外发布所有的资源操作接口。这一层要屏蔽掉虚拟化等的差异,使得上层无法感知。


d) 基础设施包括计算、存储、网络,其中计算含各种异构虚拟化。


e) BSS和OSS源自电信行业的B和O,BSS负责营销、结算等功能;OSS负责监控、安全等。不展开了。


3. 虚拟化异构


能否支持X86虚拟化异构、异构的支持广度是衡量一个云资源管理平台(区别与云服务管理平台)的一个重要标准。目前主流的虚拟化软件有几种:


a) Vmware


b) Hyper-v


c) Xen


d) Kvm


e) 在kvm和xen上演化的各种版本


在此不考虑lxc等。


主要的实现思路是在资源层做统一纳管,用一套接口整合,也即适配器模式,每种使用一个适配器。在实际开发中,一般接口做二次抽象。


目前最常见的异构是VMWareKVM(Openstack纳管),目前有几种途径:


a) 自己实现,调用vcenter或vsphere的接口


推荐使用这种方式。


b) 各企业商业发行版


如,mirantis、hp hellion os商业版、racespace等,基本上不尽成熟,或者高级功能有缺陷。


c) VIO(VMWare Intergrated Openstack)


很多人跟我推荐VIO,我反对,理由有几点:


1. 遗产系统接管。如果对于已有的VMWare虚拟化,VIO无法接管


2. 性能。VIO部署在虚拟机上,作为vcenter插件,性能无法保障。


3. VIO本质上还是Openstack的一个实现,没有高级功能。


4. 如果需要SDN,要集成NSX,成本等各方面都需要考虑。


4. 小机与X86异构


除了X86虚拟化异构,还要考虑小机(主要是IBM power)、物理机、虚拟机的供应,这时也要考虑小机的纳管需求。采用的方式也是在资源层统一纳管,但接口会有独特性,一般用流程引擎调HMC解决。


5. Openstack及其应用场景


Openstack现在持续火热,各大厂商都在积极参与,本人也参加过openstack峰会。结合工作中的实际,我认为Openstack长期来讲是个好东西,适合一定场景的应用范围,但并不普适。可以应用在:


a) 开发测试环境


b) 非关键业务


c) 科研实验环境


我认为Openstack需要解决的问题有:


a) 稳定性


b) 可升级


c) 高级功能,如HA等


d) 遗产接管


此外,我认为Openstack存在贪多求快的问题,面铺的广,不够扎实,主要使用的还是那几个核心模块。


6. SDN不是企业级私有云基本需求


我曾经设计了一个集成SDN和NFV(部分功能,如SLB、VFW等)对的拓扑设计器,但在具体的企业级客户中,并没有太多客户迫切需要SDN。都会提到、以后扩展到SDN的实现,而不是眼前。


我认为SDN主要应用在几个场景:


a) 公有云,租户定义私有网络


b) 私有云,需要频繁变更网络拓扑的环境,如开发测试、科研等


c) 电信、IDC等


7. 云管平台部署架构


云管平台的部署和普通的SaaS网站没有什么不同,都是SLB加HA,后端应用集群、数据库集群,一般没有很大的压力。




三、 云不一定节省成本(我知道我说在这个可能很多同行要扔搬砖,可是作为一个驾狗狮,虽千万人吾往矣。。。)


1. 规划、设计和建设周期长。云平台要承载所有准备上云的业务系统,考虑因素较多,如前述。


2. 前期采购成本高,前期资源池建设采购的设备数量较多,占用大量的机房、电源等资源,投资和运维成本均较高,一定时间内会闲置。前期规划能力不足,也会造成资源浪费。


3. 对企业的组织管理制度可能会有调整、单体人员技能会有较高要求,造成行政和人员成本升高。


4. 管理维护成本高、维护力量无法分层:维护人员要分成不同的团队,分别管理云平台和业务,必须熟悉平台所涉及的所有的软硬件资源,维护效率不高


5. 人云亦云,并不少见,尤其是资源池较小的情况下,纯属浪费。


云服务器ECS地址:阿里云·云小站

相关文章
|
1天前
|
机器学习/深度学习 人工智能 自然语言处理
企业级API集成方案:基于阿里云函数计算调用DeepSeek全解析
DeepSeek R1 是一款先进的大规模深度学习模型,专为自然语言处理等复杂任务设计。它具备高效的架构、强大的泛化能力和优化的参数管理,适用于文本生成、智能问答、代码生成和数据分析等领域。阿里云平台提供了高性能计算资源、合规与数据安全、低延迟覆盖和成本效益等优势,支持用户便捷部署和调用 DeepSeek R1 模型,确保快速响应和稳定服务。通过阿里云百炼模型服务,用户可以轻松体验满血版 DeepSeek R1,并享受免费试用和灵活的API调用方式。
|
7天前
|
存储 人工智能 并行计算
2025年阿里云弹性裸金属服务器架构解析与资源配置方案
🚀 核心特性与技术创新:提供100%物理机性能输出,支持NVIDIA A100/V100 GPU直通,无虚拟化层损耗。网络与存储优化,400万PPS吞吐量,ESSD云盘IOPS达100万,RDMA延迟<5μs。全球部署覆盖华北、华东、华南及海外节点,支持跨地域负载均衡。典型应用场景包括AI训练、科学计算等,支持分布式训练和并行计算框架。弹性裸金属服务器+OSS存储+高速网络综合部署,满足高性能计算需求。
|
10天前
|
传感器 监控 安全
智慧工地云平台的技术架构解析:微服务+Spring Cloud如何支撑海量数据?
慧工地解决方案依托AI、物联网和BIM技术,实现对施工现场的全方位、立体化管理。通过规范施工、减少安全隐患、节省人力、降低运营成本,提升工地管理的安全性、效率和精益度。该方案适用于大型建筑、基础设施、房地产开发等场景,具备微服务架构、大数据与AI分析、物联网设备联网、多端协同等创新点,推动建筑行业向数字化、智能化转型。未来将融合5G、区块链等技术,助力智慧城市建设。
|
21天前
|
XML Java 开发者
Spring底层架构核心概念解析
理解 Spring 框架的核心概念对于开发和维护 Spring 应用程序至关重要。IOC 和 AOP 是其两个关键特性,通过依赖注入和面向切面编程实现了高效的模块化和松耦合设计。Spring 容器管理着 Beans 的生命周期和配置,而核心模块为各种应用场景提供了丰富的功能支持。通过全面掌握这些核心概念,开发者可以更加高效地利用 Spring 框架开发企业级应用。
73 18
|
1月前
|
人工智能 安全 Java
微服务引擎 MSE:打造通用的企业级微服务架构
微服务引擎MSE致力于打造通用的企业级微服务架构,涵盖四大核心内容:微服务技术趋势与挑战、MSE应对方案、拥抱开源及最佳实践。MSE通过流量入口、内部流量管理、服务治理等模块,提供高可用、跨语言支持和性能优化。此外,MSE坚持开放,推动云原生与AI融合,助力企业实现无缝迁移和高效运维。
|
2月前
|
运维 监控 持续交付
微服务架构解析:跨越传统架构的技术革命
微服务架构(Microservices Architecture)是一种软件架构风格,它将一个大型的单体应用拆分为多个小而独立的服务,每个服务都可以独立开发、部署和扩展。
556 36
微服务架构解析:跨越传统架构的技术革命
|
2月前
|
存储 Linux API
深入探索Android系统架构:从内核到应用层的全面解析
本文旨在为读者提供一份详尽的Android系统架构分析,从底层的Linux内核到顶层的应用程序框架。我们将探讨Android系统的模块化设计、各层之间的交互机制以及它们如何共同协作以支持丰富多样的应用生态。通过本篇文章,开发者和爱好者可以更深入理解Android平台的工作原理,从而优化开发流程和提升应用性能。
|
3月前
|
SQL 数据可视化 数据库
多维度解析低代码:从技术架构到插件生态
本文深入解析低代码平台,从技术架构到插件生态,探讨其在企业数字化转型中的作用。低代码平台通过图形化界面和模块化设计降低开发门槛,加速应用开发与部署,提高市场响应速度。文章重点分析开源低代码平台的优势,如透明架构、兼容性与扩展性、可定制化开发等,并详细介绍了核心技术架构、数据处理与功能模块、插件生态及数据可视化等方面,展示了低代码平台如何支持企业在数字化转型中实现更高灵活性和创新。
76 1
|
1月前
|
自然语言处理 数据处理 索引
mindspeed-llm源码解析(一)preprocess_data
mindspeed-llm是昇腾模型套件代码仓,原来叫"modelLink"。这篇文章带大家阅读一下数据处理脚本preprocess_data.py(基于1.0.0分支),数据处理是模型训练的第一步,经常会用到。
53 0
|
2月前
|
存储 设计模式 算法
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
行为型模式用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务,它涉及算法与对象间职责的分配。行为型模式分为类行为模式和对象行为模式,前者采用继承机制来在类间分派行为,后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象行为模式比类行为模式具有更大的灵活性。 行为型模式分为: • 模板方法模式 • 策略模式 • 命令模式 • 职责链模式 • 状态模式 • 观察者模式 • 中介者模式 • 迭代器模式 • 访问者模式 • 备忘录模式 • 解释器模式
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析

热门文章

最新文章

推荐镜像

更多