软件定义数据中心 Windows Server SDDC技术与实践(txt+pdf+epub+mobi电子书下载)


发布时间:2020-08-10 00:46:21

点击下载

作者:黄利军

出版社:人民邮电出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

软件定义数据中心 Windows Server SDDC技术与实践

软件定义数据中心 Windows Server SDDC技术与实践试读:

前言

通过对自身的审视和对身边IT 技术专家的观察,我发现对于我们来说,掌握一项新的技术或熟悉一个新的产品,大都是闻而后知,知而后学,学以致用,用以知其然。然而Windows Server作为一个简单的、易上手的操作系统,很多时候Windows IT Pro对其的认知是反其道而行的,因为我们太过于熟悉它的操作而忽略了去探索其原理。现在新技术层出不穷,过快的技术更迭让我们在学习之路上缺乏相对系统的资料。近几年有幸接触微软Windows Server SDDC技术并有机会参与实践,积累了一些经验。书以载道,我将有限的经验和学习笔记汇集成书,将知识传递给广大的技术人员,希望对各位有所帮助。虽然技术和水平有限,眼界也还不够开阔,但我会尽力提高本书的质量和阅读感受,力求将信息传递清晰。

为什么要起这个书名?我是怎么理解软件定义数据中心(书里提到的SDDC和软件定义数据中心是同一个概念)的?也许我的理解和您不同,您和您身边的人又不同。这里,我想先用一段感性的语言来说明软件定义数据中心,然后以理性的技术概念和实践开启这本书的创作之旅。

每个软件定义数据中心的建设都经历了一个精细的营造过程,软件定义数据中心不完全采用全新技术,而是新老技术相结合,老技术在软件定义数据中心里得以传承,新技术在软件定义数据中心里得以发扬。新老技术的重组和编排,辅助以优良的设计为数据中心营造出新的气象。Windows Server作为云操作系统,跨出了服务器的管理边界,以数据中心为管理单元进行管理。Windows Server云操作系统所驱动的三驾马车——软件定义计算、软件定义存储、软件定义网络,让Windows Server掌控着数据中心的网络资源、存储资源和计算资源,信息的水流在数据中心的大河里汩汩流淌,奔腾不息,流向互联网大海。

技术要回归现实才能落地,在软件定义数据中心中,所有的传统硬件资源——计算、存储、可用性、网络等通过软件对固件进行解耦合实现数据中心模块的虚拟化,再通过软件技术以自动化的方式重组实现模块的灵活拼装。SDDC的每一个模块都像一块橡皮泥,比传统硬件固件更具有可塑性,也更加灵活自由。SDDC以渐进式和颠覆式相结合的节奏向前推进,SDDC不是软件取代硬件的变革过程,而是软件和传统硬件结合,相得益彰,即使在未来,发展线路亦是如此。微软作为一个老牌软件厂商,在SDDC发展上自然不甘落后,在写这本书的时候Windows Server已经20周岁了,微软Windows Server服务器虚拟化技术、会话虚拟化技术以及高可用性技术已经为广大客户所采用,软件定义存储和软件定义网络也在努力向前发展。本书内容提纲

本书分为7章,每章具体内容简介如下。

第1章我们漫谈微软数据中心建设,先从微软公司大型数据中心发展历程和微软软件定义数据中心的发展道路给大家展现微软数据中心的一角和SDDC现状,然后浅谈SDDC所定义的模型如何改善数据中心的转变。

第2章讲软件定义高可用,为什么称之为软件定义高可用呢,我们首先来看数据中心的画像,在可用性这个维度,一个优秀的数据中心一定要考虑高度可用和可靠的电路、制冷设备、网络硬件及网络线路、服务器及其部件、存储及存储链路……比如UPS、双路电路、交换机堆叠、RAID技术、双路电源、存储MPIO等的高可用都是通过硬件自身来实现的。当我们聚焦在微软Windows Server SDDC的画像时,除了可以看到硬件高可用,系统级以上的高可用完全由Windows Server实现—— 一个用了十几年的技术,Windows Server故障转移群集(通常我们简称为Windows Server群集)。同样,Windows Server群集实现的高可用贯穿在SDDC堆栈里,因此软件定义的高可用在SDDC里起着重要的作用。如果说软件定义数据中心有三驾马车,那么高可用就是这些马车的轮子和车架。VMWare ESX和Citrix XenServer实现虚机的实时迁移同样要用到高可用技术,在VMWare里称之为HA,虽然不是群集技术,但也属于软件定义高可用的范畴。在冠以软件定义高可用的名字下,我们具体介绍的是Windows Server群集。因为很多读者接触过Windows Server群集,所以这本书里我尽量写它的工作方式和机理。如果您对Windows Server故障转移群集的熟悉程度需要进一步加深,希望本书的内容可以帮助您更进一步了解群集的工作方式,哪怕这种帮助只是一点点。

有了可用性做保证,我们开始第3章软件定义存储(书里提到的SDS和软件定义存储是同一个概念)的介绍,作为数据中心的心脏部分——存储,在数据中心里扮演的角色至关重要,这一节里我们将从Windows Server 2012(R2)的第一代SDS开始介绍,内容覆盖SDS的一些关键技术,介绍SDS高可用结构并深入分析SDS可用性,帮助了解SDS的硬件结构以及如何安装、配置和使用SDS。接着介绍Windows Server 2016引领的第二代SDS的新技术的突破,结构的升级变化,以及第二代SDS的硬件结构以及如何安装、配置和使用第二代SDS。第二代SDS还有延伸的内容,包括用于数据容灾的存储复制技术,用于管理存储资源分配的存储QoS技术。希望这些技术能帮助您理解、深入学习Windows Server SDS,也希望能够对您如何使用和设计SDS有所启发。

如果说存储作为数据中心的心脏存储数据中心的血液,那么下一部分我们开始介绍第4章软件定义网络(书里提到的SDN和软件定义网络是同一个概念),网络就像人体的动静脉,像血液一样通过动脉或静脉在心脏和各个器官之间流动,数据在存储和计算单元连接的网络里流动。在这一章里,我们将根据Windows Server 2012的第一代SDN介绍SDN的一些基础理论、关键技术,帮助各位了解SDN的结构以及如何安装、配置和使用SDN,接着介绍Windows Server 2016引领的第二代SDN的新技术的突破和网络功能虚拟化(书里提到的NFV和网络功能虚拟化是同一个概念),NFV和第二代SDN如何结合实现完整的软件定义网络框架,同时介绍如何通过模板配置SDN和NFV模块。

第5章我们介绍Windows Server服务器虚拟化和会话虚拟化,这两项技术对于大家来说是最为熟悉的,建议大家也不要忽略这一章,因为里面有我们用过百遍但是未必熟悉其原理的技术的详细介绍,对于大家了解原理可能有些许帮助,比如虚拟CPU分配、动态内存、NUMA、巨型帧、VMQ、SR-IOV等“只闻其声不见其人”的技术。在会话虚拟化中,有一些我们之前在项目里积累的实用技巧,帮助大家学以致用。虽然大家对服务器虚拟化和RDS已经很面熟,但是重温或者深入学习可让你更进一步了解服务器虚拟化和RDS的“脾气”,从而进入知其所以然的境界。

接下来我们在第6章里讲解Windows Server 2016实现SDDC冲刺的最后一棒——容器技术(书里提到的Container和容器是同一个概念)。Windows容器技术是微软实现类似于Linux容器的技术,Docker技术来势汹汹,大有取代服务器虚拟化的架势。现在我们身边谈论Docker和容器技术的人越来越多,这本书关注在Windows Server 2016容器技术的基本概念的介绍。

由于Windows容器刚面市,加之笔者接触Windows容器时间有限,知识的广度和深度也有限,在写这一章时得到了彭爱华老师的指导和启发,彭爱华老师是最早接触Windows Server容器的技术专家。笔者在写作这一章时恰逢Windows Server 2016预发布之际,期间拜读了“华来四”(由彭爱华、黄爱华、祁清华和程尊华4位名字里带华的专家创建,用于分享原创的Azure、docker和混合云相关技术)关于Windows容器的引路文章。要延续并深入学习Windows容器技术,推荐大家关注华来四微信公众号(sysinternal)作为线上学习的渠道,保持对Windows容器的持续关注,了解Windows容器技术的动态。

最后一章我们将以案例说明Windows Server SDDC的实现,在这章里我们将展示部分SDDC技术在新的SDDC结构中的细节,同时展示SDDC架构原型,这一章我们笔墨不多,但是有用心制作的逻辑架构图,以飨读者。本章作为本书的收尾,有Windows Server SDDC落地之实。

本书除了Windows Server这个主角以外,还会在部分章节里提到System Center Virtual Machine Manager(简称SCVMM)和Windows Azure Pack(简称WAP),System Center和WAP是实现SDDC管理模块的方案,但是本书的主题专注于Windows Server SDDC,所以SCVMM和WAP我们并没有单独列为一章,而是穿插在虚拟化、SDS,SDN章节里一起讨论。大家如果对System Center有兴趣可以去了解九叔所著的《微软System Center 2012 R2私有云部署实战》一书。本书读者对象

因为Windows Server使用率高,所以我相信业界大部分的系统工程师对Windows Server都不会陌生,虽然每个专家掌握的程度有深有浅,掌握的知识点也不同。本书适用的读者较为广泛,不管您是初出茅庐的Windows Server系统工程师,还是已经对Windows Server有较为丰富的经验,这本书都有可能不同程度地帮助你学习Windows Server SDDC技术。如果不巧您刚好不在Windows Server这个圈子里,甚至都不曾了解过Windows Server技术,但是需要初步了解Windows Server SDDC技术,这本书也可以作为基础材料辅助您“半路出家”学习Windows Server SDDC技术,因为这些新技术的知识点对Windows Server传统知识点的依赖性和关联性不大。

当然我们需要了解云计算和行业中的一些关键术语,在阅读过程中才不会被一些新名词或者思路所磕绊。致读者

既然您已经开始阅读本书,相信一定对本书有一定的期待和期望,衷心希望您能在阅读本书后有所收获和启发。如果对本书的内容有任何问题或者建议,欢迎与我联系和互动,可以把您的问题发送到我的个人邮箱leejoneh@139.com,或者与本书的责任编辑王峰松联系,工作邮箱为wangfengsong@ptpress.com.cn。第1章 微软数据中心与SDDC漫谈

第1章包含4个小节,第1节我们将通过文字带领大家简单“参观”一下微软自己创建的数据中心,看看微软如何在海量计算背景下建设数据中心;第2节介绍混合云的概念、微软混合云和混合云实现;第3节和第4节介绍微软云计算和实现云计算的SDDC发展概况,以及微软如何与其他厂家和开源组织合作来将云计算大范围落地。1.1 微软数据中心建设之道

微软在数据中心业务领域一直扮演改革者和先驱者的角色。目前微软自有业务和公有云数据中心在全球已经超过30个,物理服务器数量超过百万之巨,为全球广大客户提供Microsoft Azure、Office 365、Bing、Xbox Live、Skype、SkyDrive、Outlook邮箱等上百种主流云服务,微软已成为世界最顶级的数据中心运营商之一和云服务提供商之一。这些数据中心不是一朝一夕建成的,而是耗时二十多年,历经四代的优化和创新而发展起来的,每座数据中心都堪称“高大上”,不仅规模庞大,稳定可靠,而且设计优良,更是节能先锋,在数据中心建设方面首屈一指,引领潮流。

微软从1989年开始着手建立自己的数据中心,因为那时的数据量并不大,微软相应的第一代数据中心规模也并不大,数据中心设计也鲜有创新,但是微软仍然坚持数据中心为战略性投资,以支撑微软在数据中心不断增长的服务。2007年微软在昆西建设的第二代数据中心彰显着微软加速向超级数据中心发展的策略,让微软加速跑进百万服务器俱乐部。昆西数据中心是微软第一个第二代数据中心,占地70 000多平方米,规模堪比10个足球场,为业界树立了数据中心新的标准。第二代数据中心追求的是高密度计算、稳定、安全和节能。该数据中心坐落在瓦纳普姆水电站旁边,充分享受着水力发电的便利和清洁能源的环保,并同时引进水冷辅助数据中心降温。通过高密度部署和综合降温方式,微软第二代数据中心的能耗PUE(Power Usage Effectiveness,能源效率指标)为1.5,在当时业界处于绝对领先的水平。

微软在第二代数据中心建设的基础上,使用模块化建设,同等规模数据中心建设周期大为缩短。2009年,微软在芝加哥建成第一个第三代数据中心。芝加哥第三代数据中心使用集装箱模块存放物理服务器,服务器是定制的,设计成1U高和标准宽度一半的尺寸,每个集装箱容纳的物理服务器达到2400台之多。这些内置了高密度服务器的集装箱沉重但是不笨重,集装箱拉到数据中心后,可通过导轨轻松移动就位,只要将水电网模块接入就位的集装箱即可实现快速的组装。我们可以从图1-1所示看到芝加哥数据中心的缩影。图1-1 微软芝加哥第三代数据中心

芝加哥第三代数据中心更加环保,该数据中心采用了大型的冷水机组,布置的冷却水管长度达到12公里,PUE达到1.25,在绿色数据中心道路上迈出了关键的一步,为行业所称赞。

不仅于此,微软数据中心发展之路并未停止,2010年在都柏林建成的第四代数据中心,具有划时代的意义。第四代数据中心采用了IT-PAC(IT Pre-Assembled Component,IT预装配件)模块,将UPS、配电设备和服务器设备配置成不同的集装箱模块,在数据中心进行快速的组装,使得同规模数据中心的部署周期缩减到之前的一半。更值得一提的是,借助都柏林地理位置和气候的优势,位于都柏林的第四代数据中心采用天然冷气辅助降温,整个数据中心环绕着冷气管道,管道深入到集装箱内部,将从外部抽进来的冷空气输送到各个IT-PAC模块。都柏林数据中心规模庞大,号称服务器农场,但PUE却仅为1.15,是真正的绿色IT数据中心。微软都柏林数据中心也一改以往人们对数据中心高碳排放的负面印象,并于2010年问鼎欧洲最佳数据中心的称号,树立了数据中心新的里程碑。我们可以从图1-2所示看到都柏林数据中心的缩影。图1-2 微软都柏林第四代数据中心

微软还在不断扩张数据中心的规模和优化数据中心的设计,面对这些恢宏的数据中心,微软并没有采用人海战术来管理,而是使用先进的技术和流程有条不紊地管理着这些服务器,数以百万计的服务器由微软全球基础服务(Global Foundation Service,GFS)集中远程监控。虽然芝加哥数据中心的服务器超过了10万台,但是数据中心现场包括安防人员也只不过三四十号人。

微软这些大型的数据中心及其服务器通过高速的网络为全球用户提供海量的计算和存储,不论是Microsoft Azure和Office 365这些企业级的云服务,还是Outlook邮箱和Xbox Live这些消费级服务,访问量和使用量都已达到上亿甚至十亿以上级别,并处于一个不断上升的过程。正如微软数据中心业务总经理凯文蒂蒙斯所说,身处数据中心听到的“嗡嗡”的轰鸣声正是互联网心跳的声音。1.2 微软混合云之路

人们对混合云(Hybrid Cloud)的定义层出不穷,在笔者看来,混合云并不是什么新技术,而是一种由公有云和私有云组合成的新的表现形式。类似于现在国家重点发展的油电混合动力汽车,电动机动力不是全新的技术,内燃机动力也由来已久,二者形成新的动力组合,混合云也通过整合了私有云和公有云各自的优势资源组成新的云的形式。就像现在汽车混合动力技术发展了清洁燃料和太阳能能源技术一样,公有云也衍生了社区云、园区云和托管云等规模稍小的公有云。为了界限清晰地讲述混合云,我们暂且把社区云、园区云和托管云统统归为公有云。本质上,混合云的实现是混合必要的IT资源,每个用户的混合云都有不同的资源混合比,按照不同的资源混合比,笔者将混合云分为如下几类。

轻度混合云。轻度混合云具体表现为,用户自己建立了自己的SDDC数据中心运行企业主要的业务系统,这类业务的系统和数据完全由企业自己掌控;将部分业务系统部署在公有云,客户部署在自己的私有云和公有云的系统并没有数据和消息的交换和移动,但是实现了将私有云/公有云数据离线灾难备份到公有云/私有云。轻度混合云除了可以借力公有云的各项优势,还可以使用公有云的PaaS和SaaS得天独厚的资源,比如使用微软公司Azure的IoT Hub、移动服务、Hadoop、媒体服务、机器学习等用于测试和生产。轻度混合云可以使用统一的管理接口实现特定公有云和私有云的统一管理,比如统一的视图和基本的启停操作。

中度混合云。中度混合云具体表现为,用户自己建立了自己的SDDC数据中心运行企业部分业务系统,并且将部分业务系统部署在公有云,用户将自己的SDDC数据中心网络和自己在公有云的私有虚拟网络通过S2S VPN隧道连接起来,让客户部署在自己的私有云和公有云的系统实现无缝的数据和消息的交换和移动。比方说将业务系统的前端和后端分别部署到公有云和私有云,并同步实现了将私有云/公有云数据在线异步灾备到公有云/私有云。但是受到Internet带宽这个硬条件的限制,在中国内地,实现大量数据和消息的交换和移动的实时性并不理想,对于一些轻量级数据和消息的应用还是可以期待的。中度混合云可以使用统一的管理接口实现特定公有云和私有云的统一管理。

高度混合云。高度混合云具体表现为,在中度混合云基础之上,实现更为统一和自动化的管理,包括统一管理不同的公有云,实现全面的监控。更重要的是,私有云和公有云实现了共享类似的框架和广泛的开发语言,开发的应用可以统一部署到私有云和公有云,虚拟机可以按需迁移,形成一个融合贯通的结构。对于客户来说,无论业务运行在哪个位置,都是一样的,在他们看来是“One Cloud”。

高度混合云目前还是个理想的目标,但是现在已经有客户进入轻度混合云阶段,并向中度混合云迈进。纵观整个行业,数据中心的形式也是混合存在的,包括传统、私有云、公有云,而且这种形式会存在相当长一段时间并且呈现类似于正态分布的形态,如图1-3所示。对于每一个已经运营自有数据中心多年的客户来说,不需要制定100%上云的目标,而是混合传统、私有云、公有云3种形式,并以渐进式的变化达到类似于正态分布的形态。图1-3 传统、私有云、公有云正态分布形态

混合云是微软不懈追求的目标,微软已经提供了我们早已熟悉的混合云服务,包括Office 365和On-premise Office服务(邮件、协作和Office程序)以及Dynamic CRM Online和On-premise Dynamic CRM等服务。几年前,微软提出了Cloud OS的概念,在形式上看,Cloud OS不是一个具体的Windows或者Linux操作系统,它超越了System OS,System OS只能实现服务器的管理,而Cloud OS管理的最小量级是数据中心,Cloud OS负责组建数据中心的网络、存储、计算和应用。Cloud OS和SDDC理念高度一致,Cloud OS兼顾了私有云、公有云、服务商云3种形式,微软SDDC和其他厂家的SDDC所不同的是,Cloud OS目标在于构建混合且一致的云平台,将用于微软自己公有云里的技术框架和设计思路传承到私有云和服务商云,如图1-4所示。微软在建设大型数据中心的过程中积累了丰富的SDDC经验和完善的PaaS及SaaS服务,Cloud OS的重点在于指导基础结构的建设。Cloud OS指导包含了来自微软公有云的直接的技术传承,比如用于Azure的虚拟化和SDN技术,SDS技术以及云门户、云资源框架(Windows Azure Pack和Microsoft Azure Stack)等;也包含了数据中心的设计思想,比如高可用设计、Spine-Leaf(叶脊)组网结构、故障域设计等;同时辅助以一致的开发接口和UI风格传承,从内到外,从使用体验到界面都保持着高度的一致。图1-4 Cloud OS一致的平台

Cloud OS将微软公有云技术、框架、开发接口和UI风格传承到服务商云和私有云,但这只完成了混合云的第一步,在这一步,仅能实现轻度混合云。微软的混合云还不仅于此,微软公司内部通过SDN技术BYON(Bring Your Own Network,自带网络上云),让用户在上云的过程中更方便。只要在Microsoft Azure里定义好虚拟子网,虚机便可从客户自己的数据中心迁移到Microsoft Azure,并仍然保留着原来的IP地址,减少了迁移的设计和准备工作量。同时,Microsoft Azure SDN技术包含了HNV网关(Hyper-V Network Virtualization,简称为HNV,本文中HNV和Hyper-V网络虚拟化是同一个意思),用于提供S2S VPN服务,让客户数据中心通过S2S VPN隧道和自己在Microsoft Azure里的虚拟子网互通。连接客户自己数据中心和Auzre数据中心VPN隧道是实现中度混合云的基础,同时让混合云的管理也变得更加直接。Cloud OS能将技术传承复制到服务商云和私有云,意味着客户私有云和服务商云同样能依靠S2S VPN隧道连通,因此在Cloud OS技术体系里构建的混合云画像也变得更加完整。如果不存在异构平台,不考虑网络带宽的问题,Cloud OS构建的混合云已经非常接近高度混合云了。1.3 微软SDDC发展之计

打开电脑,你会发现软件正在“统治”着世界,数据中心也不能例外,随着数据中心的规模越来越大,网络越来越复杂,存储量越来越膨胀,应用可用度要求越来越高,无论是云服务器提供商还是企业用户,对SDDC的青睐日益明显。微软在某些新技术领域属于倡导者,大家可能并不熟悉,最早的并被广泛认可的SDN组织ONF(Open Networking Foundation)就是由微软、谷歌和Facebook联合发起的,ONF用于定义SDN标准和推动SDN的产业化,由此可见微软在SDN的积极性。微软在SDDC概念被提出来之前,便提出了数据中心转型(Transform the Datacenter)的构想,并同时提出了Cloud OS云操作系统的概念。数据中心转型和SDDC的目标和技术实现如出一辙,微软长期实践着“Transform the Datacenter”的目标,微软众多庞大的数据中心“硬朗”的外表里通过云操作系统植入了SDDC这颗“柔软的芯”。数据中心设计理念和思路在不断更新迭代,所使用的软件技术也不断推陈出新。微软不仅自身在实践着数据中心转型的目标,还希望将目标带给客户。20年磨一剑,Windows Server锻造出了很好的数据中心基因,尤其在基础架构层面的影响力,我们可以从活动目录谈起,从文件服务器谈起,从Windows Server所支持的具有庞大用户群的Exchange Server和SQL Server谈起……总之,在x86市场占有绝对优势的Windows Server一直默默耕耘,紧跟技术发展趋势,Windows Server 2008实现了软件定义计算(服务器虚拟化)的从0到1,Windows Server 2012实现了SDS和SDN的从无到有,Windows Server 2016则初步实现了容器技术。

在SDDC的时代,百家争鸣,技术各有所长,然而技术本身都有相通性,我们可以从别人那里看到自己的影子。Windows Server也完成了几次华丽的转身,Windows Server作为构成云计算浪潮的一部分,服务器虚拟化对传统物理服务器的冲击非常明显,Hyper-V作为微软SDDC的当家者,随着Windows Server 2008发布首度进入虚拟化领域到现在,技术越来越全面,越来越成熟,赢得了越来越多的客户的青睐。

微软Hyper-V不断发力,依靠成熟的功能和完善的技术获得了不错的反响。微软虚拟化表现得怎么样呢?我们不妨用Gartner报告进行简单的分析,Windows Server 2008刚发布就备受关注,一举进入Gartner高等级象限,充分被分析师和市场所看好。Windows Server也不负众望,凭着快速的客户增长和技术的快速更新,在Windows Server 2008 R2发布不久便一个健步越到了虚拟化魔力图第一象限,在之后几年时间里不断提高市场占有率,其功能不断完善和成熟,我们不妨仔细看看图1-5。图1-5 Gartner x86服务器虚拟化魔力象限图

2015到2016年,Windows Server服务器虚拟化凭着不俗的表现稳稳占据着Gartner魔力象限的第一象限,并且不断向第一象限更具挑战性的位置攀升。在2016年秋季发布的Gartner魔力象限里微软服务器虚拟化和VMWare的距离进一步缩小,如图1-6所示。图1-6 Gartner 2015~2016年虚拟化魔力象限图

云时代的下一波浪潮冲击的就是存储领域,微软涉足存储领域要从Windows Storage Server谈起,Windows Storage Server主打为企业提供NAS存储,主要通过OEM的渠道提供。虽然Windows Storage Server 2003到2008 R2这几年里积累了一定数量的客户,但不愠不火的市场没有表现微软在存储方面的坚定决心。21世纪10年代SDDC的概念被提出来,传统和新兴的存储公司纷纷竖起软件定义存储的旗帜,一时热闹不已,呈现百花齐放的趋势。2012年,微软猛然发力,在Windows Server 2012引入存储空间技术,正式向业界宣布其涉足软件定义的存储领域,让很多人充满了期待。和服务器虚拟化一样,一个颠覆式的变革技术总是让人踌躇不前,一边展望着新技术带来的各种惊喜,一边对新技术的能力也抱有一定的怀疑。在Windows Server 2012发布不久,笔者加入联想并有幸参与了微软SDDC私有云项目,我们大胆地摒弃了传统的SAN存储方案,转而使用Windows Server存储空间和SMB 3.0软件定义的存储。在实践中我们体会到Windows Server SDS的灵活性,以及成本上的优势,Windows Server贯穿SDDC的堆栈,上至虚拟化,下到存储,一脉相承,让管理变得尤为简单。Windows Server 2016的发布带来了新的气象,第二代SDS继承了Windows Server 2012 SDS的功能,保留了共享SDS结构的同时兼顾分布式结构和超融合结构,如果说Windows Server 2012实现了SDS的0到1,那么Windows Server 2016正努力走在实现1到100的路上。

只要接触过Windows Server,对微软在终端网络方面的技术应该不会陌生,将Windows Server DNS和DHCP作为企业解析服务和IP地址分发服务的企业不胜枚举。而微软在这一亩三分地里一耕耘就是十几年,除了不断改善DNS和DHCP服务之外,Windows Server还在网络其他方面不断地探索——RRAS服务提供路由和VPN服务,并在RRAS基础上使用Direct Access构建无缝的VPN体验;IP地址管理(IPAM)功能,用于发现、监控、审计以及管理企业网络IP地址空间和相关基础架构服务器的框架。Windows Server除了正在不断扩展网络能力,为了完善服务器虚拟化还在和网络硬件厂家就某些技术点展开深度合作,SR-IOV,VMQ,vRSS,IPSec任务卸载、QoS等虚拟化网络加速技术正逐渐集成在服务器虚拟化里。微软在Windows Server 2012上第一次开始了SDN技术的尝试,并联合Intel、HP等公司共同开发了NVGRE Overlay隧道封装协议,结合RRAS网关技术和硬件网关技术实现了较为完整的SDN服务。Windows Server 2016 SDN使用了使用更为广泛的Overlay隧道协议——VXLAN,并同时新增了NFV投资。

当然,作为SDDC的管理层面,除了Windows Server提供的用于自动化管理的PowerShell工具,微软还有由来已久的成熟方案——System Center。本书虽然没有用单独的章节介绍System Center,但是System Center是不可或缺的,我们在第3章的3.1.7节里介绍了SCVMM对SDS的管理,在第4章里介绍了SCVMM SDN的管理。除此以外,System Center还提供了监控、自动化编排、备份和服务管理等组件,这里我们不再详细描述。

可以说,SDDC是一个逐渐拿走别人奶酪的过程,拿走的不仅仅有IT硬件设备厂家的奶酪,还有传统软件厂家的奶酪,奶酪的主人要做的不是去维持现在的奶酪,而是积极地去创新,去挖掘,以适应这个不断变化的世界。Windows Server SDDC已经迈开了坚定的一步,某些模块的技术已经非常成熟,某些模块仍需要进一步提高和改进。1.4 微软SDDC云落地之策

如果说云计算带来了信息时代的战国争雄的局面,那么合纵连横将是一个战略制高点,合纵连横的策略的推手就是SDDC,SDDC打破了传统数据中心软硬件各自维护自己阵营的局面。在信息时代,合纵连横的目的不是为了一家独大,而是互通有无,整合资源,形成一个完善的云生态。作为x86主流操作系统的厂家,微软最初和Intel形成了坚固的Wintel联盟,也不乏和AMD、Lenovo、HP、DELL、LSI、Broadcom等硬件厂家的深度合作。

在SDDC发展的道路上需要有更加深远的视野,在合纵方面微软的表现有:加紧和各大服务器厂家紧密协作,让Intel-VT和AMD-V技术加速Windows Server虚拟化的普及;Cisco Nexus、5Nine、NEC、InMon等网络技术厂家实现了Hyper-V虚拟交换机的扩展能力;在网络层面起草并联合Intel、HP和DELL正式提议NVGRE Overlay隧道协议帮助实现SDN;微软和JBOD厂家、x86服务器厂家以及存储控制器厂家合作进一步实现I/O虚拟化,推进SDS的发展。

在SDDC发展的道路上也需要有更加广阔的视野,微软公司在连横方面表现有:微软跨平台的策略,微软在全面进军云时代的同时,以更加开放的姿态迎接云计算的发展,积极拥抱开源和异构,并努力在以下3个维度做好落实。在云的维度,Microsoft Azure平台不仅有Windows Server虚机,还有Linux虚机on Azure,Microsoft Azure不仅支持.NET,还支持JAVA、PHP、NodeJS等开发语言,Azure所支持的关系型数据服务不止SQL Server,还有Oracle和MySQL;在操作系统维度,Ubuntu on Windows和PowerShell in Linux的消息一个接一个;在数据库维度,SQL Server不再只运行于Windows Server之上,还能运行在Linux操作系统之上。

当然,除了从深度和广度合作,微软也在努力锻炼内力,不断更新技术的同时也在加强和伙伴的合作,合作伙伴也不仅限于前面所列的软硬件厂家,还包括微软原有的合作生态圈,这些生态圈通过整合或者二次开发为满足客户的需求走完最后一公里。在SDDC方面,微软通过和国内外大量的合作伙伴构成Cloud OS Network(COSN)生态圈来帮助SDDC架构设计和落地,而构建在SDDC基础上的新兴的大数据、机器学习以及IoT等方面也涌现出大量的合作伙伴。第2章 软件定义高可用

不管SDDC技术多么华丽,基础一定要牢靠,以保证必要的可靠和可用度。我们把SDDC的3个核心模块比喻成3驾马车,那么软件定义高可用就意味着我们要先铺平道路。如果您在浏览目录时发现我们在本章讨论的是一个已经被广泛使用的“陈旧”的Windows Server群集技术时,不要急着跳过这一章,因为这一章我们将在讲解日常使用Windows Server群集的基础上稍微拓展一点儿介绍Windows Server群集的原理。当然,如果您已经掌握的知识比本章介绍的更深入,那么请忽略这一章。

在这一章里,我们将在第2节介绍构成群集资源和数据库等的群集组件;在第3节介绍驱动群集和管理群集的群集服务;在第4、5、6节简单介绍群集仲裁原理和Windows Server升级带来的仲裁的变化以及如何设置群集仲裁;从第7节开始讲解群集网络角色及其配置,群集网络流量及其配置,群集网络角色和流量之间的匹配关系,群集网络的QoS和带宽控制等;第8节和第9节讲述群集节点的健康监控以及群集资源的监控和管理。2.1 实现技术

无高可用不成数据中心,可用性是数据中心设计时第一要考虑的因素。Windows Server故障转移群集作为应用的高可用基础,在数据中心里支撑着基础架构平台及应用的平稳和持续运行,对数据中心的稳定起到举足轻重的作用。具体来说,软件定义高可用可以在服务器虚拟化中实现虚机实时迁移,在SDS中实现故障域和存储控制器容错,在上层实现SQL/Exchange等应用故障切换。之所以把Windows Server故障转移群集放在第一章,是因为群集不是独立的,群集和后续章节的内容也有紧密的关联。我们以软件定义高可用之名,以Windows Server群集之实讲解Windows Server SDDC高可用的实现和运行机制。2.2 群集组件

Windows Server群集组件可以从图2-1所示的提纲式的结构图说起,然后在后面的章节逐一展开,详细介绍。Windows Server群集组件由多个组件组成,很多用户都觉得Windows Server群集比较复杂,希望能够变得简单,但是我一直认为复杂的另外一层含义就是全面,作为高可用基础系统,群集的全面性是维系整个系统可用的根基。Windows Server群集组件虽然多,但可粗分为3个核心部分——群集服务、群集资源和群集管理,外加各自的附属组件,共同组成完整的群集。在群集里我们最关心的是群集应用,而群集应用由群集资源组成,群集资源是构成群集和应用的基本元素,是群集和应用的一砖一瓦,所以群集资源和资源监视可以归为一组。构成群集最核心的组件是群集服务,群集服务就是群集这部“汽车”的发动机和变速机构,维持着群集体系的启动、运转及停止。群集服务在每个节点里有很高的优先级,起到控制群集活动、维持群集数据库、组织节点通信、操作故障转移和配置群集等作用,群集服务连同其云宿主节点、群集数据库、磁盘和网络驱动可归为另一组。但是群集服务深入于后台,往往不容易了解和操控,因此群集为我们提供了方便的管理工具,包括群集管理器和PowerShell群集模块,群集管理工具提供友好的操作窗口,就像汽车的方向盘和档位以及各种控制按钮,让我们操作起来得心应手。图2-1 Windows Server群集组件2.2.1 群集资源

要了解群集和应用构成的元素,我们需要知道什么是群集资源,群集资源指的是构成群集和被群集管理的资源,笔者喜欢将群集资源分为3大类:第一类是构建群集自身的资源,包括群集名称、群集IP地址、仲裁见证等,这些资源在群集和仲裁的配置同时进行初始化;第二类资源是群集的标准资源,包括文件服务、虚机、DHCP等,这类群集资源已经集成在群集资源库里,可以在群集管理控制台的角色里进行配置;第三类是非标准群集资源,非标准资源构成两种不同的群集应用,一种是群集感知的应用(比如SQL Server,Exchange Server等),另一种是非群集感知的应用(第三方应用)。下面以Hyper-V和SQL Server数据库两个常用的应用为例,简单介绍一下群集资源的构成。

先来看看Hyper-V群集,要查看Hyper-V群集里面有哪些资源,可以在Hyper-V群集的节点上运行以下Get-ClusterResource PowerShell示例命令。PS C:\> Get-ClusterResource |select Name, ResourceType, OwnerGroup| Sort-ObjectOwnerGroupName           ResourceType           OwnerGroup----           ------------           ----------Cluster IP Address    IP Address            Cluster GroupCluster Name       Network Name           Cluster GroupFile Share Witness    File Share Witness        Cluster GroupCluster-HRB        Network Name           Cluster-HRBIP Address 192.168.1.5  IP Address            Cluster-HRBHyper-V Replica BrokerCluster-HRB       Virtual Machine Replication Broker Cluster-HRBVM01           Virtual Machine          VM01 ResourcesVM01 Configuration    Virtual Machine Configuration   VM01 Resources

在Hyper-V群集里除了有群集名称、群集IP地址和仲裁见证等第一类群集资源以外,还有两个第二类资源——一个是虚拟机资源,另外一个是虚机复制代理(Hyper-V虚机复制功能,我们将在5.1.7.5节详细介绍)。如果在Hyper-V故障转移群集里删除一台高可用虚机(只是将虚机从高可用角色里排除,并非从Hyper-V里删除虚机),会发现群集弹出提示,表明我们要删除的虚机包含了两个资源,这两个资源就是虚机和虚机配置。

同样,可以在SQL Server群集的节点上运行命令查看SQL Server群集的群集资源类型,示例如下。Name          ResourceType       OwnerGroup ----          ------------       ---------- File Share Witness  File Share Witness    Cluster GroupCluster Name      Network Name       Cluster GroupCluster IP Address   IP Address        Cluster GroupCluster Disk      Physical Disk      SQL Server(MSSQLSERVER)SQL Server Agent    SQL Server Agent     SQL Server(MSSQLSERVER)SQL IP Address     IP Address        SQL Server(MSSQLSERVER)SQL Network Name    Network Name       SQL Server(MSSQLSERVER)SQL Server       SQL Server        SQL Server(MSSQLSERVER)

在SQL Server服务器群集里除了群集名称、群集IP地址和仲裁见证等第一类群集资源以外,还有SQL Server相关的第三类群集资源。

和群集资源并行存在的还有群集资源DLL,群集资源DLL包含管理各种群集资源的指令和说明,其最重要的职责是检测应用程序故障。资源DLL由应用程序提供并最终群集化,它是应用程序和群集之间的代理。当群集服务提交请求给群集资源时,请求传递给资源监视器,资源监视器为群集资源调用资源DLL入口,群集要停止或者启动应用程序,群集会通知资源DLL,DLL再向应用程序转达信息。比如群集里配置高可用虚机后,虚机资源和相关的DLL和VMMS服务通信,控制虚机启动、停止,并定期检查虚机的健康状态。2.2.2 群集资源组

在2.2.1节提到查询群集资源的时候,使用Sort-Object对群集资源按照所有者组进行归类排序,可以看到多个资源属于同一个“所有者”组,这个所有者组对应的就是群集资源组。群集资源组是一个或者多个相互依赖的群集资源集合,因为群集资源组里面的资源是相互依赖的整体,所以群集通常以资源组为单元进行管理和监控。资源组资源这种密不可分的特性,意味着同属于一个群集资源组的原生资源(比如同一个实例里的SQL Server组件,为SQL Server实例分配的群集磁盘不属于群集实例)总是在同一个群集节点上运行,而不会分开运行在不同的群集节点上,在故障转移时,整个群集资源组同时转移到其他节点。因为群集资源组之间没有依赖关系,各个群集资源组可以独立启动或停止,当某个资源组停止时,群集资源组里面的资源全部停止。

举个SQL Server数据库的例子,在故障转移群集部署一个高可用SQL Server实例后,在SQL Server故障转移群集里会生成一个名为SQL Server的资源组。使用PowerShell查询到SQL Server的资源组信息示例如下。Name            ResourceType     OwnerGroup ----            ------------     ---------- ………            ………………       ……………… Cluster Disk        Physical Disk     SQL Server(MSSQLSERVER)SQL Server Agent      SQL Server Agent   SQL Server(MSSQLSERVER)SQL IP Address       IP Address      SQL Server(MSSQLSERVER)SQL Network Name      Network Name     SQL Server(MSSQLSERVER)SQL Server         SQL Server       SQL Server(MSSQLSERVER)

SQL Server群集资源组里包含5个资源,分别如下。

群集磁盘。即使在单机环境,SQL Server也必须要有磁盘存储数据库相关文件,而群集磁盘资源用于保存群集SQL Server实例文件、数据库和日志等文件。在群集上创建SQL Server高可用实例时可以指定群集磁盘,也可以给SQL Server实例指派群集磁盘(比如在故障恢复后群集卷脱离了SQL Server实例)。当然,在新的Windows Server SDDC结构里,群集磁盘不再是唯一的存储资源,CSV(详见3.1.2.12节)和SOFS SMB(详见3.1.2.15节)都可以作为SQL Server存储资源。

SQL Server实例。默认或者命名实例,一个示例实际上是一个SQL Server引擎,这个实例同时只能归一个群集节点所有。

SQL Server代理。和SQL Server实例成对存在。

SQL IP地址。用于应用访问和连接SQL Server的IP地址。

SQL网络名称。用于应用访问和连接的网络名称,这个名称和SQL IP是成对存在的。

资源组里面的资源存在相互依赖的关系,SQL Server群集资源组资源之间的关系如图2-2所示,SQL Server群集实例必须具备实例网络名称和群集磁盘,而实例网络名称又需要解析成IP地址才能被应用访问。图2-2 SQL Server群集资源组

试读结束[说明:试读内容隐藏了图片]

下载完整电子书


相关推荐

最新文章


© 2020 txtepub下载