《VMware vSphere设计(原书第2版)》——1.2 vSphere设计的不同层面

简介:

本节书摘来自华章出版社《VMware vSphere设计(原书第2版)》一 书中的第1章,第1.2节,作者:[美] 福布斯·格思里(Forbes Guthrie)斯科特·罗威(Scott Lowe)肯德里克·科尔曼(Kendrick Coleman),更多章节内容可以访问云栖社区“华章计算机”公众号查看。

1.2 vSphere设计的不同层面

如上一节所述和图1-1所示,vSphere设计必须阐述三个层面,否则就不是完整的设计。这三个层面是:技术、组织和运维,三者再通过功能需求统一起来。但是设计时,还必须具体定义每个层面内的众多决策点。
区分三个层面的最好方法就是了解各层面包含的决策点类型,图1-4详细描述了这些内容。
vSphere设计的每个层面中,你会根据功能需求进行决策,紧接着是交互评审(如图1-3所示)以确保决策依然满足功能需求。本节将通过分析层面涉及的一些决策点,更深入细致地研究每个层面。
首先介绍技术层面。

ef63a1470aecf1edbe11bd36a5d4ef0d94df355b

1.2.1 技术层面

IT人士最容易将技术层面与设计联系起来,技术层面包括很多构成最终虚拟环境的技术部件,例如:什么服务器、多少内存(RAM)、数据存储要配置什么样的存储阵列和网络配置是什么样的。你也可以认为技术层面指的就是“物理设计”,虽然它确实也包含一些逻辑内容。如图1-5所示,技术层面有很多决策点,用于判断这些技术是否需要包含在设计中。

3d4d0ae900ef820c4550f03d5529d3108b005525

保证基础层面的完整性是很重要的,所以设计必须包含至少以下方面:
虚拟环境中服务器的类型和数量。
服务器CPU的数量、类型和速度。
服务器RAM的数量。
共享存储的连接方式。
共享存储的类型或配置。
有效物理网卡的数量。
服务器网卡的模式和生产商。
环境中虚拟交换机和分布式虚拟交换机的具体配置。
设备所需的功率消耗。
设备所需的制冷消耗。
设备所需的楼层空间或者机架空间。
当然,要设计VMware vSphere虚拟环境,这个清单仅仅是需要考虑的一小部分而已。后续章节将更详细地介绍这些技术。例如,第5章将介绍VMware vSphere网络技术,第6章将更深入地探讨共享存储技术。
一个完整且全面的设计除了阐述技术层面外,还要包括组织层面。

1.2.2 组织层面

虽然vSphere设计中技术层面很重要,但组织层面也同样重要。在组织层面,我们将集中探讨关于“谁”的难题,如图1-6所示。

670a7c8555a0c398f80c7069ef542a1533d374a0

刚开始,你可能会觉得“谁”的问题并不重要,或者不属于你的职责范畴。难道这些不是应该由客户自己决定的吗?从某个方面说,的确是的。这些决策和技术层面的“什么”问题一样都是由功能需求驱动的。通过1.4节,你会了解到从客户或组织单位(如果是你自己的单位)那里收集功能需求其实就是收集这样的信息:在虚拟基础设施环境中,各项任务都是由谁来负责的。
关于“谁”的这些问题,还有一件事需要考虑。这就是客户或公司可能并不知道某个设计层面到底由谁负责。对刚刚接触虚拟化的组织来说,组织内聚集了服务器管理员、网络管理员、存储管理员和安全管理员,这通常意味着他们很困惑,并不清楚谁能够或者应该对新的VMware vSphere环境中的不同区域负责。通过将这些问题的答案渗透到你的设计中,就可以帮助客户(或者你自己的单位)更好地理解如何划分职责,知道谁应该对哪个区域负责。
VMware vSphere设计的最后一个层面提出了一个很重要但常常会被忽略的问题:如何运维虚拟环境?下面将讨论这个层面:运维层面。

1.2.3  运维层面

VMware vSphere设计的运维层面回答了关于“如何”的一些问题,如图1-7所示。

fd5e0d40a287b1757b4817fc32c45eb770fd0ac8

和组织层面一样,你可能会问:“在VMware vSphere设计中,为什么要定义运维流程?这些不都是组织内部早就知道的那些运维任务吗?”
对刚刚接触虚拟化的组织来说,答案是否定的,他们不知道。虚拟化改变了数据中心的运维方式,所以首次实施虚拟化的客户或公司必须在设计中清晰定义这些运维性的决策。
即使是对虚拟化比较熟悉的组织,运维层面依然是一个全面且完整的VMware vSphere设计的关键部分。“当前设计的技术层面中关于‘谁’的决策和之前的决策存在差异”的现象是很可能存在的。这是因为服务器模型会改变,存储供应商会推出带有新功能的新产品,还会有新的运维需求。网络供应商也会不断改变其产品的工作方式。这些因素加在一起,就形成了一个需求:每个设计中都要包含运维信息,以确保实施此设计的组织在运维环境时有足够的信息可供参考。
举个例子,假设一个组织应用虚拟化环境已经很多年了。它在HP ProLant机架式服务器(服务器通过光纤通道(FC)连接NetApp的存储阵列)上部署了VMware Infrastructure 3 (VI3)。现在,该公司要实施这样的虚拟环境:在Cisco统一计算系统(Cisco Unified Computing Systems,UCS)上部署VMware vSphere 5.1,通过以太网光纤通道(FC over Ethernet,FCoE)连接Cisco的统一计算系统和Dell的Compellent 存储矩阵。你觉得以前的运维流程会和这次的一样吗?当然不一样。就像技术在不断更新一样,运维也同样在与时俱进,这就是为什么运维层面对新VMware vSphere用户和已有用户都重要的原因。
将设计决策分成三组,划归技术层面、组织层面和运维层面,这有助于确保架构师的设计的完整性,也就是说覆盖到了构建满足功能需求的vSphere环境所需的方方面面。但是,这些层面并不会帮我们决定实现功能需求的具体方法。那么,在每个层面中能帮助我们做决策的指导原则是什么呢?请看下一节。

相关文章
|
2月前
|
存储 监控 固态存储
【vSAN分布式存储服务器数据恢复】VMware vSphere vSAN 分布式存储虚拟化平台VMDK文件1KB问题数据恢复案例
在一例vSAN分布式存储故障中,因替换故障闪存盘后磁盘组失效,一台采用RAID0策略且未使用置备的虚拟机VMDK文件受损,仅余1KB大小。经分析发现,该VMDK文件与内部虚拟对象关联失效导致。恢复方案包括定位虚拟对象及组件的具体物理位置,解析分配空间,并手动重组RAID0结构以恢复数据。此案例强调了深入理解vSAN分布式存储机制的重要性,以及定制化数据恢复方案的有效性。
80 5
|
2月前
|
存储 固态存储 虚拟化
【vSAN分布式存储服务器数据恢复】VMware vSphere vSAN ESXi超融合HCI分布式存储数据恢复案例
近期,我司处理了一个由10台华为OceanStor存储组成的vSAN超融合架构,其中一台存储闪存盘出现故障,用户取下后用新的闪存盘代替,然后对该闪存盘所在的磁盘组进行重建,导致集群中一台使用0置备策略的虚拟机数据丢失。
64 6
|
5月前
|
JSON 监控 数据库
使用Telegraf+Influxdb+Grafana配置VMware vSphere监控大屏
使用Telegraf+Influxdb+Grafana配置VMware vSphere监控大屏
188 0
|
虚拟化
VMware vSphere Client中虚拟机“Disc Found”解决方法
VMware vSphere Client中虚拟机“Disc Found”解决方法
|
监控 负载均衡 安全
VMware vSphere 5.5 高可用性 2
VMware vSphere 5.5 高可用性
216 0
|
存储 资源调度 监控
VMware vSphere 5.5 高可用性 1
VMware vSphere 5.5 高可用性
105 0
|
存储 运维 程序员
[运维]VMware vSphere介绍
[运维]VMware vSphere介绍
184 1
|
存储 文件存储 开发工具
【VMware vSphere 7】虚拟化概述(一)
【VMware vSphere 7】虚拟化概述(一)
219 0
|
存储 测试技术 API
分享:VMware vSphere API玩法
分享:VMware vSphere API玩法
658 0