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

简介:

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

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

并不是所有的基础架构服务都平等,有些服务没那么关键,如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

相关文章
|
2月前
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
164 0
|
2月前
|
文字识别 运维 监控
架构解密|一步步打造高可用的 JOCR OCR 识别服务
本文深入解析了JOCR OCR识别服务的高可用架构设计,涵盖从用户上传、智能调度、核心识别到容错监控的完整链路,助力打造高性能、低成本的工业级OCR服务。
105 0
架构解密|一步步打造高可用的 JOCR OCR 识别服务
|
10月前
|
运维 监控 负载均衡
动态服务管理平台:驱动微服务架构的高效引擎
动态服务管理平台:驱动微服务架构的高效引擎
190 17
|
10月前
|
运维 监控 负载均衡
探索微服务架构下的服务治理:动态服务管理平台深度解析
探索微服务架构下的服务治理:动态服务管理平台深度解析
|
10月前
|
运维 监控 安全
探索微服务架构下的服务治理:动态服务管理平台的力量
探索微服务架构下的服务治理:动态服务管理平台的力量
|
6月前
|
消息中间件 人工智能 监控
文生图架构设计原来如此简单之分布式服务
想象一下,当成千上万的用户同时要求AI画图,如何公平高效地处理这些请求?文生图/图生图大模型的架构设计看似复杂,实则遵循简单而有效的原则:合理排队、分工明确、防患未然。
214 14
文生图架构设计原来如此简单之分布式服务
|
11月前
|
Cloud Native Java API
聊聊从单体到微服务架构服务演化过程
本文介绍了从单体应用到微服务再到云原生架构的演进过程。单体应用虽易于搭建和部署,但难以局部更新;面向服务架构(SOA)通过模块化和服务总线提升了组件复用性和分布式部署能力;微服务则进一步实现了服务的独立开发与部署,提高了灵活性;云原生架构则利用容器化、微服务和自动化工具,实现了应用在动态环境中的弹性扩展与高效管理。这一演进体现了软件架构向着更灵活、更高效的方向发展。
|
12月前
|
存储 Linux KVM
Proxmox VE (PVE) 主要架构和重要服务介绍
Proxmox VE (PVE) 是一款开源的虚拟化平台,它基于 KVM (Kernel-based Virtual Machine) 和 LXC (Linux Containers) 技术,支持虚拟机和容器的运行。PVE 还提供高可用集群管理、软件定义存储、备份和恢复以及网络管理等企业级功能。
2630 7
|
9月前
|
存储 JavaScript 开发工具
基于HarmonyOS 5.0(NEXT)与SpringCloud架构的跨平台应用开发与服务集成研究【实战】
本次的.HarmonyOS Next ,ArkTS语言,HarmonyOS的元服务和DevEco Studio 开发工具,为开发者提供了构建现代化、轻量化、高性能应用的便捷方式。这些技术和工具将帮助开发者更好地适应未来的智能设备和服务提供方式。
基于HarmonyOS 5.0(NEXT)与SpringCloud架构的跨平台应用开发与服务集成研究【实战】
|
9月前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
212 12

热门文章

最新文章