Windows Admin Center 高可用部署

赵小黑

　　本文老王将为大家实作Windows Admin Center的高可用部署，相信有了高可用的架构支持将更进一步推进该产品的落地
　　环境介绍
　　08dc2
　　lan 10.0.0.2 255.0.0.0
　　16server1
　　lan 10.0.0.3 255.0.0.0 dns 10.0.0.2
　　clus 18.0.0.3 255.0.0.0
　　storage 30.0.0.3 255.0.0.0
16server2
lan 10.0.0.4 255.0.0.0 dns 10.0.0.2
clus 18.0.0.4 255.0.0.0
storage 30.0.0.4 255.0.0.0


Windows Admin Center (下文简称WAC) 支持部署平台：Windows 10 ,Windows Server 2016，Windows Server 2019
WAC支持管理的服务器客户端：Windows Server 2008R2，2012，2012R2，2016，2019，  HyperV-Server 2012R2，2016，Windows 10
管理Server 2008R2 需要事先安装.NET4.5.2 WMF5.1
管理Server 2012R2 需要事先安装WMF5.1
管理Hyper-V Server 2012R2需要事先安装WMF5.1，启用远程管理，启用文件服务器角色，为PowerShell启用Hyper-V模块
管理Hyper-V Server 2016需要事先启用远程管理，启用文件服务器角色，为PowerShell启用Hyper-V模块


Windows Admin Center 高可用部署思路


WAC目前未采取前后端分离架构，呈现在Windows上面只是一个Windows Admin Center的应用服务，高可用部署采用WSFC架构，通过A/P部署的方式在两台节点分别安装WAC文件，WSFC对WAC服务进行群集应用，检测该服务健康状况，如果所在节点宕机，则在另外节点启动挂载WAC服务


WAC先决条件

• 已经安装好的WSFC群集
  
• 群集提供正常可用CSV，用于存放WAC数据库文件，CSV底层可以是SAN，ISCSI，S2D，JBOD架构
  
• 下载WAC高可用部署脚本，部署过程全部由脚本自动化完成
  
  
• 事先准备可导出私钥证书模板，申请证书，将证书导出放在与脚本相同文件夹
  
• 将脚本与证书文件夹复制到群集每一个节点相同路径下
  

WAC可以整合的2016，2019技术

• WAC本身可以部署在一个S2D群集上
  
• WAC现已支持管理存储副本
  
• WAC现已可以监控Hyper-V 2016 SDN
  
• 2019最新存储迁移技术只能在WAC上面管理操作
  
• WAC现已公开SDK，编写SDK扩展时可以使用PS脚本
  

当前老王已经部署好了一个WSFC群集，采用文件共享见证，节点与CNO放置在默认OU下

http://s1.运维网.com/images/20180706/1530860444599461.png
存储采用S2D架构
Enable-ClusterS2D -CacheState disabled -Autoconfig 0 -SkipEligibilityChecks
稍后会在S2D上层创建CSV，WAC会将WAC运作过程需要的数据库文件，界面文件等统一存在CSV中，如果测试环境，或者WAC管理的主机不多，数据库量不大，可以不用考虑缓存机构，如果WAC管理主机很多，使用的人也很多，建议可以考虑配置缓存架构以提高管理效率
http://s1.运维网.com/images/20180706/1530860474884038.png
基于群集磁盘创建一个CSV
http://s1.运维网.com/images/20180706/1530860721443292.png
准备一张可以导出私钥的证书，默认情况下我们通过MMC向企业CA申请的证书是不支持导出私钥的，因此需要我们复制新建证书模板，登陆证书服务器，打开证书模板，复制Web服务器证书模板，在请求处理页面勾选 允许导出私钥
http://s1.运维网.com/images/20180706/1530861099392833.png
在常规界面勾选在AD中发布证书
http://s1.运维网.com/images/20180706/1530861158311882.png
在安全界面下，添加计算机对象，Domain Computers 勾选注册权限，或考虑安全因素也可以仅添加WAC群集节点允许注册。
http://s1.运维网.com/images/20180706/1530861223694723.png
证书模板处新建要颁发的证书模板，选择我们自定义的证书模板
http://s1.运维网.com/images/20180706/1530861320994991.png
发布完成后回到群集节点上通过 MMC - 计算机账户 - 个人 申请证书，可以看到我们刚才在CA中新发布的证书模板
http://s1.运维网.com/images/20180706/1530861397652195.png
在证书申请处选择配置详细信息
公用名处添加WAC群集 VCO名称，创建完成群集后大家会通过这个名称访问WAC，因此务必确保证书名称一致
备用名处添加DNS名称，WAC VCO名称，各节点FQDN名称
http://s1.运维网.com/images/20180706/1530861433993857.png
配置完成后将带私钥证书导出 放入群集脚本文件与安装文件相同路径，然后将此文件夹复制到群集各个节点相同路径
WAC群集安装脚本下载地址 http://aka.ms/WACHASetupScripts
WAC 1804下载地址 http://aka.ms/WACDownload，1804是目前已经GA的版本，本文采用1804版本进行部署，更新版本可以在Insider中心下载
http://s1.运维网.com/images/20180706/1530861511249995.png
先决条件都准备就绪后在其中一个群集节点上面以管理员身份打开Windows Power Shell，准备进行安装
脚本命令说明如下


.\Install-WindowsAdminCenterHA.ps1 -ClusterStorage C:\ClusterStorage\Volume1 -ClientAccessPoint wac -MSIPath C:\WACFile\WindowsAdminCenter.msi -CertPath C:\WACFile\wac.pfx -CertPassword $cerpassword -StaticAddress 10.0.0.20
http://s1.运维网.com/images/20180706/1530861993961779.png
　　-ClusterStorage：群集共享卷的本地路径，用于存储Windows管理中心数据。
　　-ClientAccessPoint：选择将用于访问Windows管理中心的名称，例如填写wac，安装完成后将以wac.oa.com访问WAC
　　-StaticAddress： WAC VCO对应的群集IP地址
　　-MsiPath：Windows管理中心.msi文件的路径
　　-CertPath： 证书.pfx文件路径
　　-CertPassword： 提供的证书.pfx的SecureString密码
　　-GenerateSslCert： 可选，如果不想提供签名证书，请包含此参数标志以生成自签名证书 ，自签名证书将在90天后过期
　　-PortNumber： 可选，如果未指定端口，则网关服务将部署在443端口（HTTPS）上 可在此参数中指定使用其他端口
脚本会在每个节点上面安装WAC文件，只不过同一时间只有一个节点的WAC服务开启，其它节点停止待命
http://s1.运维网.com/images/20180706/1530862473863652.png
安装完成后打开CSV可以看到如下文件夹架构
http://s1.运维网.com/images/20180706/1530862509488594.png
打开DB文件夹可以看到WAC运行过程中所存储的DB文件格式，可见是Windows上面传统的EDB格式，有检查点文件，临时文件，数据库文件等，当我们在其中一个节点上面打开WAC执行管理操作，该节点宕机后，另外节点启动时将去CSV这个路径下加载捞取WAC管理数据
http://s1.运维网.com/images/20180706/1530862534129643.png
安装完成WAC界面如下，正常情况下如果按照老王介绍的步骤去安装证书，SSL这里应该是绿色信任，如果证书不信任请检查证书申请步骤时名称是否有误
http://s1.运维网.com/images/20180706/1530862631301600.png


对比2017年9月24号老王写Honolulu时，Windows Admin Center已经有了不少增强


支持直接进行存储副本管理
http://s1.运维网.com/images/20180706/1530862749221830.png


支持了授权管理，Azure整合
http://s1.运维网.com/images/20180706/1530862767877957.png
实际测试故障转移情况，当前WAC主要由16server2提供服务，老王直接将其断电
http://s1.运维网.com/images/20180706/1530862819311654.png


在我的虚拟化实验环境中，从16server2宕机，到16server1接管提供服务，一共宕机了2-3分钟，根据我的观察并不是能ping通了，就可以使用了，即便是ping通之后仍然要等到1-2分钟之后，网页才可以正式打开，因为它前后端都在一起，因为当一个节点宕机，在另外一个节点启动时，必然需要重新加载前后端的步骤，因此这部分加载的时间也会算作宕机时间，具体时间长短视机器性能决定，经过2-3分钟的故障转移时间 可以看到此时是由16server1提供服务，但是管理数据都还在，并不需要重新添加


http://s1.运维网.com/images/20180706/1530862863894876.png
WAC简单来说它是微软下一代的服务器管理中心，折中于单机管理工具与私有云之间的一个轻量级数据中心管理平台，管理员将可以通过WAC portal完成百分之70以上微软平台系统管理工作，解除了原来每天一上班需要开很多个管理工具的烦恼，通过一个网关平台管理私有云 公有云 虚拟机 物理机，从最初它作为Honolulu项目时就被微软寄予厚望，发展到今天的WAC，它更为极致，更为实用。增强了对于虚拟化，S2D，SDN的管控，打通了到AzureAD , Azure Backup, Azure File Sync, disaster recovery的混合云集成，增强了授权访问，开放了SDK开发规范，吸引开发人员和供应商生态，支持企业级高可用部署，支持脚本检视器，这样的趋势看来WAC未来的关键词会是混合，灵活，实用轻量


从另外一份更新的消息看来下一版的WAC还将引入system insight功能，能够帮助管理员预测服务器 群集性能峰值，并且能够设定在达到峰值时需要采取的自动化操作，坦白说这可能是很多管理员梦寐以求的功能，但是随之而来老王也担心WAC会因此而变沉，因为分析预测需要数据库以及分析引擎的支持，不知道最终呈现出来会是什么样子，希望不会违背WAC的初衷把，目前这个产品在我看来很强，从system insight可以看出微软有意为这个产品赋予智能的标签，同时，Windows Server 2019中微软也做了个试探，将存储迁移这项新功能只能够通过WAC操作，目的应该是试验一下大家对于WAC的接受程度，如果接受程度好，可能以后新功能都会只在WAC上面上线，因此大家现在了解和使用WAC是很有必要的


未来我希望这个产品就这样，保持轻盈，保持实用，未来也许会带来的改变，我认为微软会考虑到IT人员编辑扩展方面，也许会引入一些便于IT人员操作的无代码扩展工具，身份验证和界面定制应该会更灵活，也许会对客户端管理上面进行一些增强，例如可以远程为客户端演示，远程盘点统计客户端资产，远程直接下发软件。服务器管理上面我认为WAC将主要关注2016 2019的新功能模块，例如SDS，SDN，微软会不断在WAC上面优化这两项功能的管理体验，会考虑对接Linux，容器等新兴技术。