情境描述

一家虚构漫画发行公司– Magenicons决定要对公司的IT设备做现代化升级，以增加系统的可靠性，同时节省成本的支出。IT部门的员工认为采用云端计算可以在IT 基础架构和应用程式方面提升灵活性。公司选择一个既有的基于内网的费用报告应用程式做为云端迁移策略的POC前期功能验证。

背景资料

费用报告应用程式是一个以网站为基础的标准二层式架构，依靠本地的Microsoft IIS server，并在内部部属Microsoft SQL server以分散式方式储存资料。第二个本地的IIS server也提供auditing服务。透过本地的AD网域执行个体进行身分验证后才能存取应用程式，同时应用程式的服务帐户透过SQL Server的身份验证来保护资料存取。

计画达成方式

为了将风险最小化同时提升公司团队云端知识和经验，Magenicons希望分阶段执行计画，每个阶段都有明确要完成的目标。这些目标会用来评估云端运算对公司的长期可行性。GCP因平台的强大功能和Google极佳的技术声誉被选为云端服务的供应商。

• 阶段1：使用Google IaaS 基础架构即服务将应用程式转移到GCE
  • 目标：GCE 可以使用最低的成本，结合lift-and-shift 无痛转移费用报告应用程式。特别的是，公司希望能够尽量不修改现有应用程式码，将应用程式移转到云端。
  • 必要条件：环境的设定，像是建立GCP 和Magenicons 公司内部之间的网路连线，将是现阶段支援lift-and-shift 无痛应用程式移转的必要条件。
• 阶段2：透过云端服务提高可用性(HA)
  • 目标：一旦应用程式能成功在云端运作后，Magenicons公司希望增加SQL Server的高可用性，以降低应用程式可能停机的风险。AlwaysOn Availability Groups是SQL Server建议的解决方案，让使用者能够配置抄写副本，当故障发生就能够自动转移。GCP支援Windows Server Failoverr Clustering (WSFC)和SQL Server AlwaysOn Availability Groups。
• 阶段3：透过云端服务进行灾害恢复(DR)
  • 目标：Magenicons 公司想藉由将内部部属的AD 扩展到云端，进一步提升应用程式的可用性来改善DR 计画。在DR 情况发生时，这提供了保护AD 的成本效能考量选项。当公司的实体资料中心遇到停电或灾难事故，在GCP 中做为AD DC 的VM 主机仍能提供服务，会让部署到云端和本地端跟AD 整合的应用程式不会受到影响。此外，在云端一起布署AD 服务的应用程式，通常也会缩短网路的延迟，进而改善系统回应时间。

当前的本地系统部署架构

系统是使用标准ASP.NET MVC应用程式架构作为内部网路环境。该应用程序部署在IIS服务的网站，使用已经加入AD网域的Windows主机。系统保护透过Windows整合式验证来控管所有应用程式的存取。连接SQL Server的方式也是相当标准，使用SQL Server身分认证和网域服务帐户的使用者ID和密码。

最终目标的云端系统架构

最终的目标系统架构应该与原始的本地系统类似，因为它将GCP 视为本地资料中心的延伸，透过VPN 虚拟私人网路存取，并具有SQL Server HA 高可用和AD DR 灾难复原的附加功能。

操作指南

实现阶段一目标

第一阶段的目标想要透过lift-and-shift无痛转移费用报告应用程式到云端，有三个主要的工作必须完成：

1.为Project专案建立适合的GCP网路
2.从Magenicons公司建立VPN连结到GCP云端
3.建立需要的VM执行个体支援应用程式
4.进行必要的配置或程式码的修改，以支援lift-and -shift无痛转移

建立GCP 网路

GCP网络将VM彼此连接并连接到外部网路，让使用者可以区隔他们的网段，建立防火墙规则来控制存取，以及建立静态路由转发流量到特地目的地。随着Project专案在不同阶段的发展，将会需要这些功能。关于GCP网路的教学细节可参考此连结。

重要提醒：

可以使用任何支援类型的子网路模式(自动或自订) 来实现第一阶段的目标。然而，为了安装SQL Server AlwaysOn Availability Groups，必须使用自订的子网路，第二阶段的详细内容说明如下。因此，如果终究会安装此功能，强烈建议从一开始就建立自订子网路，避免不必要的修改或重建工作。

建立site-to-site VPN

建立VPN是很直觉的动作，专案团队不会遇到任何问题，只要根据Google documentation设定，VPN功能就可以在一天内上线运作。

建立VMs 支援云端系统架构

可透过以下三种方式在Compute Engine 上建立VMs：

1. point-and-click 点选介面：订阅者入口网站中的Google Cloud Console
2. REST API
3. 命令提示字元介面(CLI)，在Google的case中称为gcloud命令提示字元介面

由于团队了解自动化是云端运算长期可持续性的关键因素，基于程式码的方法，选择gcloud 命令提示字元介面成为他们的首选。

使用CLI是相当容易的，只要从Google下载gcloud命令提示字元介面并按照文件操作即可。以下提供建立一个Windows Server执行个体的截图。

以下是project 各阶段所需的VMs 及roles：

• 阶段1
  • IIS Web Server
  • SQL Server
• 阶段2
  • 一个额外的SQL Server 执行个体作为SQL Server Availability Group 抄写副本的一部分
• 阶段3
  • 在GCP 运作的一个AD Domain Controller 网域主控站执行个体，能够完全复制本地AD Domain Controller 网域主控站的资料

除了上述提到关于建立VM 的方法，GCP 还提供了另一个在建立VM instances 时能省下大量时间的替代方案：Google Cloud Launcher。Google Cloud Launcher 是一个marketplace 市集，准备好让第三方的伙伴可以开发堆叠、解决方案和服务。如果工作类型符合可用的功能，只需要简单地点击几下便可建立需要的VM。

对于第一阶段的开发人员，需要一个具备ASP.NET 4.6的IIS网页主机和安装支援的.NET Framework版本。一般建立VM的方法，必须建立包含OS VM虚拟主机，以及手动安装各种.NET Framework和ASP.NET的元件。然而使用Cloud Launcher for ASP.NET，可以让过程变得相当简单。

1. 前往以下连接：https://console.cloud.google.com/launcher
2. 在搜寻列输入asp.net，并点选搜寻结果来启动Cloud Launcher for ASP.NET Framework。

3. 填写部署的规格细节，像是机器名称、磁碟、CPU 大小

4. 只需要几分钟，想要的VM 虚拟主机和相关元件就会产生

至于SQL Server instance 的建立，团队使用以下的gcloud 命令提示字元介面来产生映像档：

The gcloud command line interface (CLI) compute instances create “magcustom-sql1” –machine-type “n1-standard-4” –zone “us-central1-a” –subnet “wsfcsubnet1” –image-project windows-sql-cloud –image-family sql-ent-2016-win-2016–boot-disk-size “200” –b​​oot-disk-type “pd-ssd” –private-network-ip=10.201.1.3 –can-ip-forward

提醒：在project的第二阶段，当团队要建立SQL Server HA时，需要设立特定的网路路由(详细内容请参考第二阶段)。因此这个VM instance的内部IP address需要依据第2阶段中所描述的网络设计。这是’private-network-ip’参数在建立instance时被指定采用内部网路IP address的原因。如果此参数用于指定特定的IP address，之后不能更改静态IP address，可能会造成失去instance存取权限的风险。使用CLI部署Cloud Launcher解决方案会受Cloud Launcher服务条款和相关费用的约束。

程式码部属

在配置并正确设定IIS VM 后，团队的下一个任务就是在instance 上部属程式码。ˊ这必须透过Microsoft 众多产品之一来完成：Web Deploy。

Web Deploy是一个成熟、可扩展的client-server工具，在开发人员或SysOps的workspace工作区之间，用来将网站内容部署到IIS instance执行个体上。实际的运作机制已在ASP.NET社群中详细记载，且超出了本文件的范围，但可以在此文当中看到这项技术的简介。

确保安全性的最佳作法，就是将包含敏感的设定档案永远加密，例如：凭证或其他的私密资料。如此可以改善安全性，即使骇客获得您的设定档案，仍能让未经授权的存取变得困难，同样的原则也适用于这个应用程式。

.NET Framework 包含两个受保护内建的配置提供者，可以用来加密配置文件。RsaProtectedConfigurationProvider class 的种类使用RSACryptoServiceProvider来加密设定的部分，而DpapiProtectedConfigurationProvider class 的种类使用Windows Data Protection API (DPAPI) 来加密设定的部分。但是，考量费用报告应用程式需要整合安全性和模拟的使用情况，RSACryptoServiceProvider 并不是个合适的选择，因为它需要授予RSA Key Container 密钥容器存取权限，用于大量使用者群组的加密。

敏感资料的加密是部署过程的一部分

使用DpapiProtectedConfigurationProvider 的其中一个主要的缺点，因为它不是Web Deploy 预设的配置提供者，因此在部署的过程中无法替敏感资料自动加密。在经过一番研究之后，Magenicons 的开发人员提出一个解决方案，只要呼叫一次MSBuild，就可以(在部署主机) 建立、部署和加密敏感的资料。这个解决方要求利用PowerShell 的Invoke-command cmdlet 命令提示字元，它可以在本地或远端电脑执行命令。结合此能力与MSBuild 的嵌入式脚本的扩展功能，用于各种建构和部署事件(于MSDeployPublish 之后)，团队能够优化建构/部属的程序，能够增强应用程式的安全性。

阶段二

建立SQL Server AlwaysOn Availability Groups 高可用性群组

企业级SQL Server 的工作负载需要支援HA 高可用和DR 灾难复原。AlwaysOn Availability Group 是SQL Server 旗舰版的HA/DR 解决办法。这项技术提供server 热备援以及为资料库提供资料抄写复本。AlwaysOn 还针对一个或多个次要复本，提供唯读的存取权限，在报表主机和其他唯读的使用情境下，可以减轻主要资料库的负担。

基于上述的原因，Magenicons 公司的IT 员工选择这项技术来达成专案HA 高可用的需求。刚好Google 近期在Compute Engine 新增对SQL Server AlwaysOn Availability Group 的支援。

在计画安装AlwaysOn Availability Groups 时，有几个要求需要特别注意：

1.目前AlwaysOn Availability Groups只能在GCP的子网路类型中安装和支援，它无法在legacy旧版网路中安装。此外，子望路必须在处于自定义模式，不能是预设的自动模式(两种网路类型的差异和子网路模式的详细说明可参考此文 )。
2. AlwaysOn Availability Group中的每个节点都必须在不同的子网路中，因此需要设置至少两个子网路。
3.每个资料库的抄写复本由WSFC cluster故障移转丛集服务不同节点上的SQL Server的instance托管。
4.要实现双节点的故障转移丛集服务，必须准备四个静态IP address用来配置给cluster丛集服务本身和Availability Group Listener监听器。其中有一个很重要的点，这些指定的IP address必须不同于cluster节点实际IP address用到网段的范围，但仍可以利用适当的子网路遮罩定址来找到。

让我们来看一个简单的例子：

如果子网路是10.0.1.0/24，VM的静态IP和子网路遮罩被设为10.0.1.4和d 255.255.0.0 (/16)。从VM方面来看，可循址的子网路是10.0.0.0/16。因此，必须选择VM所在的10.0.1.0/24子网路之外的IP address，像是挑选10.0.2.4当成listener的IP address，但是仍然可以从guest端找得到，因为使用更广的子网路遮罩。必须对WSFC和Availability Group Listener需要的所有IP address实施这个要求。下表提供了整个设定所需的简单网路位址范例，逐步教学说明可参考此文。AlwaysOn Installation安装的网路地址范例：

subnetworks	IP addresses ranges
wsfcsubnet1	10.201.1.32/29
wsfcsubnet2	10.202.1.32/29

 

Node Instances		subnetworks	WSFC		Availability Group Listener
magcustom-sql 1	10.201.1.34	wsfcsubnet1	magcustom-wsfc	10.201.1.50	magcustom-as	10.201.1.51
magcustom-sql 2	10.202.1.34	wsfcsubnet2		10.202.1.51		10.202.1.51

5.最后，如逐步教学所说的，为了让listener 和cluster 可以连到丛集节点instance，针对cluster 和availability group listener 需要设定网路路由。想要建立网路路由只需要依照教学中所提供的范例命令操作即可(依据自己的需要修改，以符合需要的网路结构)。

阶段三

设定AD 复写到云端做为备援

作为整个project 的基本目标，GCP 中的网路应该被视为Magenicons 本地网络的扩展，应用程式才可以无缝接轨从地端移转到云端。只要两站台之间的VPN 设定成功，就可以像在外点分公司的办公室一样，在GCP 中建立AD DC 网域主控站和DNS 名称伺服器。一旦设定好开始运作，在GCP 中运行的application 应用程式就不需要透过internet 外部网路进行身分认证和名称解析，这会提高系统的性能。

下图是动线的描绘：

利用Compute Engine 建立AD DC 的过程和其他VM role 很类似。第一项任务是藉由下列的gcloud 命令来产生VM instance：

gcloud compute instances create your-dc-machine-name –machine-type n1-standard-1 \ –boot-disk-type pd-ssd –image-project windows-cloud \ –image-family windows-2016 –boot-disk- size 200GB \ –zone us-central1-a –subnet wsfcsubnet3 –private-network-ip=10.2.0.100

一旦VM 建立完成，接着需要执行site to site 站对站或intra-site 站台间的网域资料复制工作：

在本地的DC 上

• 在GCP 建立一个新的站台

 

• 在Active Directory Sites and Services 网域站台和服务增加GCP 子网路

 

在GCP AD DC 网域主控站操作

 

• 将预设的DNS IP 更改为指向现有本地DC

• 将VM 加到本地网域

  

 

• 安装Active Directory

 

 

• 将VM 升级成为网域主控站

  

 

• 重新开机之后，修改DNS 设定，以便将VM 指向自己来进行DNS 名称查询

有关AD Replication网域复写，在各种网路拓朴中运作的细节(包含这里使用的)，可参考此文件。

结语

在专案完成之后，三个阶段都成功完成而且实现了想要的目标。Magenicons IT 员工发现利用云端的经验是相当直觉且有效率的。GCP 的入口网站简单明了。完成各种任务所需要的主题文件，在Google 网站和支援(有提供免费和付费的版本) 有很多的资源且容易上手。除了SQL Server AlwaysOn 要求的技术文件，需要花一些时间消化和做实验测试之外，员工在专案上并没有遇到任何阻碍。最令人印象深刻的是，除了修改web.config 设定档的应用程式连接字串(为了连接到新的HA SQL Server instance)，不需要修改任何一行程式码，就能够将系统部署到云端。