openstack 架构设计及应用场景(一)

opentack将它自己的体系架构分了几种应用场景:

  • General purpose
  • Compute focused
  • Storage focused
  • Network focused
  • Multi-site
  • Hybrid

其中general perpose 通用场景的example 如下:

一家公司主要提供web应用,有tomcat、nginx、mariadb。这样的场景用openstack来做就是上面这个图,使用物理的负载均衡设备来进行负载均衡,没有用到neutron服务,启用了object来存储web的静态资源如图片等。用cinder storge来做image存储和数据存储,mariadb的数据存到专门的存储设备上,而其他的如tomcat和nginx就使用nova compute来实现,坏掉一个也无所谓。cpu的覆盖比16:1,内存覆盖比1.5:1。

通过这个例子,也可以勾勒出大多数中小公司使用openstack时的架构。

其他的场景后续慢慢介绍。

时间: 2024-11-10 19:54:06

openstack 架构设计及应用场景(一)的相关文章

OpenStack之路: OpenStack架构设计指南 - 一般用途云架构(摘录并翻译)

第二章. 一般用途General purpose 目录 用户需求 技术考虑因素 运维考虑因素 架构体系 规范性示例 一般用途云架构是开始建设云实施的常常被考虑使用的方案,这种价格原本就是被设计为平衡所有组件,而且在整个计算环境中不强调任何特殊因素.云架构的设计必须给予计算.网络,及存储组件相同的权重.一般用途云架构在私有云.公有云及混合云环境中都较常见,这也就使得这种价格可以用于很多不同的案例. 注: 一般用途云架构是均匀分布部署的,而且不适合用于特殊环境或者边缘使用案例. 一般用途云架构的常见

OpenStack之路: OpenStack架构设计指南 - 概述(摘录并翻译)

OpenStack是在云技术淘金过程中的领导者,作为一个组织,让形形色色的企业发现了可以以更大的灵活性和速度,向市场推出自助服务的云计算及基础架构即服务(IaaS)产品.然而,为了能够真正享受到这些好处,云必须通过适当的架构设计. 一个良好的云计算架构,应该是一个稳定的IT环境,可以提供方便访问所需的资源,基于使用的计算费用,按需求增加额外的容量,灾难恢复和安全的环境:一个良好架构的云计算平台不能奇迹般地自身建成的.这需要仔细考虑多种因素,包括技术和非技术的. 目前没有单一的架构是"非常合适&q

架构设计:系统间通信(32)——其他消息中间件及场景应用(下2)

(接上文<架构设计:系统间通信(31)--其他消息中间件及场景应用(下1)>) 5-3.解决方案二:改进半侵入式方案 5-3-1.解决方法一的问题所在 方案一并不是最好的半侵入式方案,却容易理解架构师的设计意图:至少做到业务级隔离.方案一最大的优点在于日志采集逻辑和业务处理逻辑彼此隔离,当业务逻辑发生变化的时候,并不会影响日志采集逻辑. 但是我们能为方案一列举的问题却可以远远多于方案一的优点: 需要为不同开发语言分别提供客户端API包.上文中我们介绍的示例使用JAVA语言,于是 事件/日志采集

架构设计:系统间通信(33)——其他消息中间件及场景应用(下3)

=================================== (接上文:<架构设计:系统间通信(32)--其他消息中间件及场景应用(下2)>) 5-7.解决方案三:非侵入式方案 以上两种方案中为了让业务系统能够集成日志采集功能,我们或多或少需要在业务系统端编写一些代码.虽然通过一些代码结构的设计,可以减少甚至完全隔离这些代码和业务代码的耦合度,但是毕竟需要业务开发团队花费精力对这些代码进行维护,业务系统部署时业务对这些代码的配置信息做相应的调整. 这里我们再为读者介绍一种非侵入式的日

架构设计:负载均衡层设计方案(1)——负载场景和解决方式

在上一篇<标准Web系统的架构分层>文章中,我们概述了WEB系统架构中的分层架设体系,介绍了包括负载均衡层.业务层.业务通信层.数据存储层的作用和存在意义.从本片文章开始,我们将首先详细讲解负载均衡层的架构原理和选型场景. 1.不同的负载场景 我们知道负载均衡层的作用是“将来源于外部的处理压力通过某种规律/手段分摊到内部各个处理节点上”,那么不同的业务场景需要的负载均衡方式又是不一样的,架构师还要考虑架构方案的成本.可扩展性.运维难易度等问题.下面我们先介绍几种典型的不同业务场景,大家也可以先

架构设计:系统间通信(30)——Kafka及场景应用(中3)

接上文:<架构设计:系统间通信(29)--Kafka及场景应用(中2)> 4-5.Kafka原理:消费者 作为Apache Kafka消息队列,它的性能指标相当一部分取决于消费者们的性能--只要消息能被快速消费掉不在Broker端形成拥堵,整个Apache Kafka就不会出现性能瓶颈问题. 4-5-1.基本使用 我们首先使用Kafka Client For JAVA API为各位读者演示一下最简单的Kafka消费者端的使用.以下示例代码可以和上文中所给出的生产者代码相对应,形成一个完整的消息

架构设计:系统间通信(28)——Kafka及场景应用(中1)

(接上文<架构设计:系统间通信(27)--其他消息中间件及场景应用(上)>) 在本月初的写作计划中,我本来只打算粗略介绍一下Kafka(同样是因为进度原因).但是,最近有很多朋友要求我详细讲讲Kafka的设计和使用,另外两年前我在研究Kafka准备将其应用到生产环境时,由于没有仔细理解Kafka的设计结构所导致的问题最后也还没有进行交代.所以我决定即使耽误一些时间,也要将Kafka的原理和使用场景给读者详细讨论讨论.这样,也算是对两年来自己学习和使用Kafka的一个总结. 4.Kafka及特性

架构设计:系统间通信(27)——其他消息中间件及场景应用(上)

1.概述 目前业界有很多消息中间件可供大家选择,主要分为两类:需要付费的商业软件和开源共享的非商业软件.对于商业软件您和您的团队可以选择IBM WebSphere集成的MQ功能,也可以选择Oracle WebLogic集成的MQ功能.本文首先介绍除Apache ActiveMQ以外的两款开源共享的消息中间件产品,然后列举三个实际的业务常见,为读者介绍如何在这些实际业务中使用消息中间件解决问题. 2.RabbitMQ及特性 RabbitMQ基于Erlang语言开发和运行.它与Apache Acti

TYPESDK手游聚合SDK服务端设计思路与架构之一:应用场景分析

TYPESDK 服务端设计思路与架构之一:应用场景分析 作为一个渠道SDK统一接入框架,TYPESDK从一开始,所面对的需求场景就是多款游戏,通过一个统一的SDK服务端,能够同时接入几十个甚至几百个各种渠道的SDK.而且这些渠道接口的具体接入字段和接入逻辑,每个月以至每周,都可能发生或大或小的变动.在这样一个复杂的应用场景下,我们应该如何设计一个足够强大而又足够灵活的SDK服务端呢? 首先我们需要厘清,在整个应用场景中,TYPESDK所处的位置,以及它所需要实现的核心功能. 图1 如图1所示,T