今天,咱们来聊聊形而上

话说投身公有云也半年有余了,陆陆续续接触用户,帮助解决了一些问题。过程中发现固然有少部分平台故障,或者是软件bug,但更多问题的产生原因却在于云平台的特殊性,如果只是简单的按照本地机房的方式去使用公有云,势必会引起后续的故障;也就是说,很多问题是娘胎里带出来的。

下边就以一个简单的三层架构网站(web+中间件+DB)为例来初步聊聊公有云部署需要注意的地方,希望对大家有所启发。

需求分析

通常,在计划一个业务系统的IT架构时,会考虑如下几个方面要求:

  1. 业务持续:如同物理设备一样,公有云的虚机等也会由于各种原因出现不能访问的情况,如何避免单一续集故障导致的业务中断时系统架构设计首要注意之处
  2. 数据安全:数据安全是个大框,包括如何防篡改、防丢失、防泄密等
  3. 网络安全:防止未经允许的网络访问,以及来自网络的攻击
  4. 可扩展性:随着业务发展,可随时灵活的调整资源,弹性扩张或收缩,以满足业务需求

所以,在公有云部署时,应围绕这些因素设计。

公有云的限制

公有云是一个多租户系统,所以在设计时首先要考虑避免用户之间的干扰,包括用户网络、数据隔离,以及性能方面的限制。而这一点恰好是最容易忽略之处。

案例:某客户新业务上线,为新业务添加外部固定ip不成功,开case发现,目前使用的外部ip已达到每订阅20个外部ip上限,需要申请提升,导致业务上线推后

在Azure官网,有一篇专门文档说明Azure订阅的限制:

Azure 订阅和服务限制、配额和约束

所以在架构设计之初,首先要考虑使用到的各种资源的限制,做好规划,如果有超过限制的需求,提前做申请。并且在日常运维过程中及时记录变更情况,当发现资源快达到限制时,提前准备应对计划(例如新开订阅、提前申请提升限制、清理不再使用的资源等)。

规划先行

俗话说,磨刀不误砍柴工。同样在公有云上部署项目,也需要提前做好规划和准备:

系统拓扑图

首先,对于要实施的系统,要有一个清晰的拓扑图,以便于了解整个系统的架构,并以此为蓝本设计实施。例如本文举例的三层网络架构,设计拓扑图如下:

mark

在此拓扑图中可以看到部署的资源和相互间的关系。

命名规则

这一点往往容易忽略,但是如果没有一个好的命名规则,日后维护就成一锅粥,需要反复查找核对。命名规则主要指定:

  • 每种类型资源的命名前缀:例如资源组同意rg开头、虚机统一vm开头等
  • 每个资源的名字规范:例如数据库服务器按vmDBServer01、vmDBServer02等依次命名,需要注意在Azure上具体每个资源的命名规范,例如是否允许大写字母,是否允许特殊字符等。

文档记录

制定表格,详细记录每种资源具体细节,例如对虚机:

虚机名 操作系统及版本 机型 用途 配置 IP 用户名 密码
vmDBServer01 CentOS7.3 D4 数据库服务器 8Core/28GB/30GB OS disk/4*100GB Data Disk 10.0.0.132 webadmin WebAdmin@12345

可根据具体情况制定文档管理的规范。

——————分割一下——————

但是规划并不是做好就万事大吉了,还需注意:

  • 有系统变更时随时更新相应文档
  • 注意文档的保密,避免被泄露出现安全问题

网络的设计

IP规划

Azure下,大部分情况虚机的ip地址都是动态分配,所以一般先对网络进行规划和配置,而不是在建立虚机时再来建立。

如果没有特殊需求的情况下,建议把一个业务放到一个vnet里,然后再将业务的各模块分类放在不同的subnet里,一般统一管理和制定安全策略。需要注意的地方是ip段的选择,尽量做到范围适中,既能满足未来业务发展需求,又避免占用过多ip地址,导致需要将不同业务放到同一个vnet里。

还是以本文的网站架构为例,目前规划有2台web server,3台中间件服务器,3台数据库服务器,未来每种服务器的数量不会超过20台,即使算上负载均衡设备等,合计用到的ip地址不超过100个,所以vnet用一个c类段足够,然后在往下分配subnet,所以可以做如下网络划分:

vnet划分:

vnet名 IP段
vnetWeb 10.0.0.0/24

subnet划分:

subnet名 用途 ip段
subnetWeb web服务器 10.0.0.0/26
subnetMiddleware 中间件服务器 10.0.0.64/26
subnetDB 数据库服务器 10.0.0.128/26

这样在建立虚机时,只需选择对应的subnet,就会自动获得该网段的ip地址。

网络安全组

网络设计的另一重要因素是安全,应遵循最小化原则,只允许必须的访问请求通过网络。Azure最常用的网络安全组件是NSG(网络安全组)。对NSG的配置应遵循如下最佳实践:

  1. Azure可以将NSG部署在subnet,也可以部署在虚机,一般情况下,对功能模块的安全规则的NSG部署在subnet,这样可以统一对同一个subnet里的vm进行安全管理,避免NSG调整都需要在每个虚机上进行容易有人为误操作。
  2. NSG的执行原则是优先配置,执行到第一条满足条件的规则后就不会再往下执行,所以高优先级的规则需要排在前边。
  3. 每个规则的编号之间应留出一定空余,便于插入新规则。
  4. 制定一条优先级最低的规则禁止所有访问,以防止不安全的入侵。

以本例中的数据库服务器为例,需要允许中间件服务器访问所有数据库服务器的3306端口(MySql端口),允许堡垒机(10.0.1.4)访问22端口(ssh端口),其他网络访问均被拒绝。根据此要求,我们可以为subnetDB制定如下NSG规则:

规则名:nsgDB

规则条目:

优先级 名称 端口 协议 目标 操作
105 allow-DB 3306 TCP 10.0.0.64/26 10.0.0.128/26 允许
150 allow-ssh 22 TCP 10.0.1.4 10.0.0.128/26 允许
4050 deny-all * any * * 拒绝

堡垒机

除了对外提供业务访问的虚机,其他虚机不应分配外部IP,提高安全性并解决成本;即使提供外部业务访问的虚机,也不应将管理端口暴露在外网。对所有虚机的管理均应该通过堡垒机进行。

如果不同的虚机如果有不同的管理人员,应通过多台堡垒机等方式做隔离,最小化每个人的管理权限。

——————再分割一下——————

网络还有很多其他内容,例如WAF、DDos防护、UDR等,在此就不一一赘述,可根据实际需要按相应最佳实践规划部署。

存储

在Azure里,存储不同于通常所说的DAS、NAS、SAN,而是作为一种服务:

mark

Disk

Disk即虚机的硬盘镜像文件,需要关注容量和性能。配置和使用Disk时,请注意:

  1. 避免在同一个存储账户里放置太多磁盘,避免超过20,000IOPS限制,导致虚机宕机;建议使用托管磁盘避免此问题。非托管磁盘转化为托管磁盘的方式如下:

    非托管磁盘转化为托管磁盘

  2. 不要再D盘或sdb存放重要的、需要持久化的数据!不要再D盘或sdb存放重要的、需要持久化的数据!不要再D盘或sdb存放重要的、需要持久化的数据!重要的事情说三遍。D盘或sdb是Azure赠送给用户的一块高速临时磁盘,但是重新分配资源时,其中数据可能丢失,所以只能用来存放临时文件(如页面文件、临时表等)。

  3. 选择高级磁盘提升性能,而不是通过使用cache的方式,避免出现数据落盘不一致的情况。

  4. 通过多块磁盘做软raid方式解决单块磁盘性能和容量不足的问题,raid0就可以,Azure从底层保证了单块磁盘的安全性。

  5. 注意选择虚机的型号,避免虚机的最大磁盘数量和IOPS成为瓶颈。

  6. Azure目前不支持Share Disk。

Files

Files提供了smb2.1和3.0的文件共享服务。

很多功能都需要使用相同的文件,例如web服务的静态页面、配置文件、图片等。如果这些文件存放在虚机内部,更新的时候需要每台虚机操作,容易出现故障。这时候就可以通过Files服务来解决,所有的文件放置在Files,再共享给虚机即可。

但是由于版本限制,Files对Linux支持有OS版本要求,具体可参见:

在 Linux 中使用 Azure 文件存储

另外,Files还有一个小彩蛋,在Windows平台,Files支持跨Region访问,甚至是跨azure.cn和azure.com,这样就可以实现一些很难实现的功能。

——————分割线又来了——————

存储还有很多其他例如安全、备份等方面的要求,在此不一一列举,根据实际要求配置。

虚机

作为Iaas服务的核心,虚机是日常打交道最多的Azure资源。网络和存储等都会对虚机的使用造成影响,而虚机本身在规划部署时,也应该遵循一定规则:

可用性集

本地部署时,为了保证业务持续性,通常会采用HA等方式做保障,并且将HA的成员从物理上分散到不同主机,避免单一主机故障导致业务中断。

而在Azure云平台,虚机是逻辑层的资源,和底层物理平台完全隔离,用户不能决定虚机在物理平台上的分布。所以,Azure引入了可用性集的概念。

简单来说,Azure把出现故障或底层软件更新影响到的范围定义为域(故障域和更新域),可用性集里包含了若干故障域和更新域,同一可用性集里的虚机会最大限度均匀分布在不同故障域和更新域。这样,当一个故障域或更新域停机时,业务续集不至于被一锅端。

这么好的东西居然是免费的,当然要想用好也需要遵守一些规则:

  1. 虚机的可用性集属性不能修改,换句话说,如果建立虚机时没有配置可用性集,创建好后无法也加入。已加入可用性集的虚机不能退出也不能修改加入其他可用性集。所以,创建虚机时,无论是否必须,都创建一个可用性集,避免以后的修改。
  2. 不要将多个不同用途的虚机加入同一个可用性集,应该为每种用途创建单独的可用性集。例如:一个可用性集有2个故障域(FD0和FD1),当两个DB Server和两个Web Server同时放入该可用性集时,Azure并不知道这些虚机的用途,有可能两个DB Server都放到FD0,两个Web Server都放到FD1,这时,当某一个故障域出现问题,DB或Web的全部主机都失去响应,导致业务中断。
  3. 可用性集与负载均衡最配哦。负载均衡后端主机只能添加同一个可用性集里的虚机,如果没有设置可用性集,无法使用负债均衡。
  4. 托管磁盘和可用性集也是最配哦。如下图:

mark

​ 可用性集里的虚机如果使用托管磁盘,Azure会自动将磁盘分到不同的Storage Unit,以提高安全性。

虚机设计

云上的虚机最大的特点就是需要适应动态的伸缩,故此,云转型不是简单的P2V,或者将其他虚机格式转化为Azure的虚机。所以松耦合是最适合云的架构。松耦合对虚机的设计提出要求:

  1. 尽可能将虚机无状态化,虚机内部无需持久化数据,所用的数据由服务(如Files文件共享)提供。

  2. 虚机镜像文件模板化,可快速从镜像文件批量生成多台虚机。需要注意之处,建立同样多台虚机一定要通过模板来创建虚机,而不是简单的复制,否则多台虚机的UUID冲突,会导致不可预期的故障。

    案例:某客户的多台Web Server不定期的无法访问Files服务提供共享文件,检查发现这几台Server的UUID相同,与客户沟通,多台虚机是直接通过复制方式创建,后来将原始虚机通用化后制作成模板,然后通过模板创建虚机解决此问题。

  3. 合理选择虚机型号,满足性能需求同时最大化性价比,并注意不同续集的磁盘即网络性能限制,避免成为瓶颈。

  4. 如果有长期使用固定型号的虚机,使用CPP方式节约成本。

  5. 启用诊断日志便于在虚机故障时进行排错。

  6. 自定义虚机注意兼容性。

  7. 配置虚机的软件和服务自启动,保证续集切换时业务自动持续。

    案例:某客户配置好MySQL的主从复制及可用性集,但是当主库宕机时,从库未自动接管业务,后经检查发现,从库的MySQL服务未设置自动启动

其他

除此之外,云架构还有许多最佳实践建议,例如生产和开发放到不同的资源组,slb的银色数量限制,vpn连接的参数设定等。

本文只是从Iaas层面最常用的几个功能对云架构的设计做简单探讨,希望能对广大上云的读者有所帮助和启发。