为什么不能把基础架构服务都虚拟化?

简介:

如果虚拟平台对承载关键应用足够的话,为什么不是所有的基础架构服务都虚拟化?

 为什么不能把基础架构服务都虚拟化?

并不是所有的基础架构服务都平等,有些服务没那么关键,如PXE启动服务器只是偶尔用于构建新的服务器。其他的非常关键,如DNS服务标注了公司里外所有东西的位置。

多数IT企业已经将不太重要的服务进行了虚拟,而一些比较关键的基础架构服务仍然在物理主机上。是时候对这些服务进行虚拟了?它们应该与现有工作负载一起和谐相处还是需要独立环境?

数据中心放弃在关键基础架构中使用虚拟化主要是因为在发生问题时,我们该如何管理虚拟化平台。我们依赖IT基础架构服务进行故障修复。如果整个基础架构存活在虚拟平台上,平台跨了我们还有啥?如果企业对此种情况没有准备机制的话,我可以负责任告诉你要重新拿回系统控制权很难。不过就算有一些规划,通常有可能冒着停工的风险去虚拟关键服务。

留在物理服务器上的IT基础架构服务通常是活动目录AD域控制器,有时是多个控制器。它们提供认证,为分辨率(DNS)与DHCP命名。

活动目录允许向外扩展的冗余模式:多个控制器共享AD工作负载,并在控制器出现问题时持续运营。确保Global Catalog的AD角色,以及DHCP和DNS服务器角色在崩溃前位于多个虚拟机上。这些服务不管平台是否崩溃都该可用。

适当的规划能让虚拟基础架构在一个甚至多个故障下存活,持续为应用交付服务。

小型IT部署

在虚拟化IT基础架构服务时,拥有少于六台虚拟服务器,且只有一个数据中心的IT企业的选择有限。在这样小的规模下,企业可能依赖员工的手动努力来保持IT基础架构服务持续运转。更小的企业可能更有信心,他们的员工可以克服任何进程与自动化的毛病,但所有大型企业想要标准化与自动化,以便处理每件不可预测的事情。

如果系统工程师有恢复服务的经验,小型企业可以将他们所有的基础架构服务放在虚拟化平台上。如果仅仅是员工够勇敢还不够,那么据算小型企业也需要像大企业那样做,这意味着投入更多资金。

单点站点,管理集群

小型部署的下一个向上扩展仅仅包括一个站点,让其成为多个虚拟服务器的家(VMware ESXi与vSphere虚拟化就是如此),构建一个管理集群是很节省成本的。交付应用到终端用户的虚拟机运行在一个或多个工作负载虚拟集群中。管理集群是一套独立的ESXi服务器设置,只运行基础架构虚拟机。

管理集群通常是两台ESXi服务器,比主要的虚拟集群使用的CPU与RAM要少。该管理集群应该有自己的存储与网络,独立于工作负载集群使用的资源,提升安全度。管理集群可能包含单个或多个控制器,以及用于工作负载集群的vCenter Server及其数据库,还有另一个vSphere管理服务器。

有了这样的隔离,工作负载集群中的故障将不会限制管理集群或解决故障的功能。管理集群中的错误将不会影响到工作负载集群。

通常,IT企业在管理集群中放置一个或两个域控制器,在工作负载集群中放得更多。这些控制器一旦铺展开,就没有一个故障就能破坏所有基础服务的能力。

多站点

最后的扩展就是企业有两个或更多站点,每个都托管vSphere集群。在多个站点放置控制器比使用管理集群拥有更多冗余。每个站点从自己的控制器获得服务,但可能在没有本地控制器的情况下使用远程的高定。


作者:何妍 

来源:51CTO

相关文章
|
10天前
|
消息中间件 API 开发者
深入理解微服务架构中的服务通信与数据一致性
【7月更文挑战第15天】在微服务架构中,各个独立部署的服务之间如何高效、可靠地通信以及保持数据一致性是设计时必须考虑的关键问题。本文将探讨微服务间的通信机制和数据一致性策略,包括同步与异步通信方式的比较、事件驱动架构的应用以及CAP定理对数据一致性的影响。文章旨在为后端开发者提供实现微服务间高效通信和数据一致性的实用指导。
|
9天前
|
消息中间件 负载均衡 网络协议
探索微服务架构中的服务通信模式
【7月更文挑战第16天】在微服务架构的海洋中,服务间的通信宛如细丝相连,维系着整个系统的协同与和谐。本文将深入探讨微服务之间如何通过同步与异步通信模式进行交互,并剖析这些模式背后的技术原理及其对系统性能和可扩展性的影响。我们将从理论到实践,一探究竟。
43 6
|
10天前
|
负载均衡 监控 Kubernetes
Service Mesh 是一种用于处理服务间通信的基础设施层,它通常与微服务架构一起使用,以提供诸如服务发现、负载均衡、熔断、监控、追踪和安全性等功能。
Service Mesh 是一种用于处理服务间通信的基础设施层,它通常与微服务架构一起使用,以提供诸如服务发现、负载均衡、熔断、监控、追踪和安全性等功能。
|
1月前
|
消息中间件 传感器 Cloud Native
事件驱动作为分布式异步服务架构
【6月更文挑战第25天】本文介绍事件驱动架构(EDA)是异步分布式设计的关键模式,适用于高扩展性需求。EDA提升服务韧性,支持CQRS、数据通知、开放式接口和事件流处理。然而,其脆弱性包括组件控制、数据交换、逻辑关系复杂性、潜在死循环和高并发挑战。EDA在云原生环境,如Serverless,中尤其适用。
48 2
事件驱动作为分布式异步服务架构
|
10天前
|
消息中间件 API 数据库
在微服务架构中,每个服务通常都是一个独立运行、独立部署、独立扩展的组件,它们之间通过轻量级的通信机制(如HTTP/RESTful API、gRPC等)进行通信。
在微服务架构中,每个服务通常都是一个独立运行、独立部署、独立扩展的组件,它们之间通过轻量级的通信机制(如HTTP/RESTful API、gRPC等)进行通信。
|
14天前
|
消息中间件 API 开发者
探索微服务架构中的服务通信模式
【7月更文挑战第11天】在微服务架构的世界中,服务的通信是构建高效、可维护系统的关键。本文将深入探讨微服务架构中常见的服务通信模式,包括同步通信与异步通信机制,并比较它们在不同场景下的适用性及优缺点。文章旨在为后端开发者提供一份实用的指南,帮助他们在选择适合自己项目需求的通信模式时做出明智的决策。
|
1月前
|
存储 前端开发 关系型数据库
在服务的数据驱动中使用三层架构
【6月更文挑战第17天】 三层架构是软件设计中的一种经典模式,将应用分为表示层(UI)、应用层(BLL)和数据层(DAL)。相比于双层架构,三层架构提供了更好的模块化和安全性。多层架构虽少见,但三层架构在现代云原生技术中依然重要,常与微服务结合使用。
35 2
在服务的数据驱动中使用三层架构
|
17天前
|
运维 监控 负载均衡
云原生架构的演进:从微服务到服务的网格
【7月更文挑战第8天】云原生技术正以惊人的速度不断进化,其核心理念是构建可扩展、灵活且高度可靠的应用程序。本文将深入探讨云原生架构的关键组成部分,特别是微服务和服务网格,以及它们如何共同推动现代软件的发展。我们将通过一个具体的案例分析,揭示这些技术如何在现实世界中被应用来提升业务敏捷性和操作效率。
|
1月前
|
存储 数据处理 数据库
理解在服务架构中的事件驱动
【6月更文挑战第14天】网络架构和软件设计常基于ISO七层模型和三层应用架构,强调数据处理的重要性。事件驱动架构(EDA)以事件为中心,改变传统设计方式,解决系统问题。事件是触发通知或状态变化的操作,如用户下单。EDA适用于微服务通信、工作流程自动化、SaaS集成和基础设施自动化等场景,提高系统敏捷性和可扩展性。然而,EDA并非万能,需根据需求选择合适的设计方案。
83 1
理解在服务架构中的事件驱动
|
25天前
|
消息中间件 存储 运维
微服务架构中的服务通信与数据一致性策略
【6月更文挑战第29天】本文深入探讨了微服务架构下的服务间通信和数据一致性问题,提出了一系列解决方案。文章首先分析了微服务环境下面临的主要挑战,随后详细介绍了同步和异步通信模式,并对比了它们在不同场景下的适用性。接着,文章讨论了实现数据一致性的几种策略,包括两阶段提交、补偿事务以及最终一致性,每种策略都配以实际案例分析。最后,结合当前技术趋势,展望了微服务通信和数据一致性处理的未来发展方向。