介绍Iaas架构规划范例开始并搭配零售业官网的案例说明Youtube视频

这堂课程将从介绍Iaas架构规划范例开始,并搭配零售业官网的案例说明,零售业官网架构是很经典的三层式架构,有Web,App,DB,想了解更多Iaas架构规划就快来一探究竟吧!

哈罗大家好,我叫Afra

欢迎来到微软技术捷运IT Infra线

今天我要跟大家分享的是Azure的Iaas架构规划范例

我会以一个零售业官网的案例来举例

我在微软担任Azure的Technology Solutions Professional

那就让我们开始吧

那我们先直接看这张架构图,它是一个零售业官网的范例

是我们实际遇到的一个客户案例

那可以很清楚的看到它其实是一个非常经典的三层式架构

有Web、有App、有DB

那我们图中看到的实线其实就是Azure的环境

这个蓝色实线是Azure的环境

蓝色的虚线就是Azure上的Virtual network就是虚拟网络

所以我们三块是以三个虚拟网络来分开的

那我们会看到图上其实会有这个蓝色的小盾牌

NSG它其实就代表Network Security Group

那我等一下後面再详述到底它是有什麽作用的

那我们在这个图上可以看到其实我们可以在VM上设定NSG

我们也可以在Virtual network上来设定NSG

所以其实我们是可以在不同层级上都去设定这个NSG的

那从User它从Browser进来这个官网开始好了

那一开始如果这个网站是一个跨区域性的网站

可能它是遍布全球服务全球的网站的话

那我可能需要Traffic Manager在DNS level来做分流的服务

除了Traffic Manager以外,进入网站之後我要做load balance

或是我要做WAF

那我就会使用Azure上的Application Gateway来做

那一样後面会再就Application Gateway来做更深入的探讨

那它其实就是第七层的一个load balancer

那也可以当做Web application的一个Firewall

我们也会有它基本该有的服务

我们看到一台一台蓝色这些都是虚拟机器

那上面的规格大家可以不用细看

那其实是当初给那个客户的一个建议

其实我们可以看到像我们虚拟机器有非常多种类型

我们可能有些是记忆体优化,可能有些是compute优化

那这些不同的VM,我们在Web或者我们在DB的选择上

我们可能会选择不同类型的VM来符合我们的需求

这张图上可以看到後面有Azure Backup跟Site Recovery

所以其实在Azure上你可以做完这些所有的东西

你也可以把Backup或是Site Recovery也考虑进去

那这个环境因为这个客户想要跟他地端的环境做串接

所以这边也规划了一个VPN

透过两个VPN Gateway串联connection

把这个VPN接起来可以跟地端环境做一个VPN的串接

那在监控方面这客户当时我们也建议他使用Security Center

也就是我们的监控工具

我们有另外一集也是我讲的在介绍Security Center

大家可以去看一下

那另外还有针对App本身可能

User view、User click的Application Insights

其实很多客户会把Application Insights跟Google Analytics

搭配使用来监控它的Application本身

那我们就进到下一页开始介绍Network Security Group

Network Security Group非常简单明了的就是在

过滤进出VM或是Subnet的流量

那你就是可以去设定inbound或者outbound的rule

那它是一个免费的服务

那实务上我们可以拿它来做什麽?

其实你就是可以去设定说那些Port可以连到这台VM

或是这个Virtual network阻止异常流量的进入

也可以避免……

如果今天这个VM你是不希望它跟Internet连接的

你也是可以去做这些设定

或是机器之间阻止VM、Subnet之间的互联

那我们可以来看一下Portal

这个Network Security Group它的设定页面大概长什麽样子

这边我们可以看到的是……

我Demo做的一个Network Security Group的范例

我们可以看到一进来这边其实很简单

就是inbound security rules跟outbound security rules

那这三个……65000到65500这三个其实是它预设给的

所以其实inbound方面

它一开始就会给allow vnet inbound这样子的rule

还有deny all inbound这样子的rule让你不用再特别去设定

所以inbound跟outbound一开始它都会先给三个预设的rule

那100到300其实是我另外新增上去的rule

那我们要怎麽新增rule呢?其实非常简单

我们就在这边inbound,比如说我inbound想要新增rule

我就add一个新的rule

那这边数字的含义就是它的priority

所以你设定这个规则之後它就会自动去扫描你的priority

你数字越小会越先扫描

要是你可以apply这个rule它就会优先apply这个rule

它就一个一个扫下来,扫到最後如果都没有rule可以apply

它就apply最後这个65500 deny all inbound它是最後一个rule

所以source来源可以去定义可能是IP address、Service tag

或者是Application Security Group

那destination也一样我们可以去做设定

Protocol可以选择,那这个priority我们可以输入

比如说我们可以设定100、200、300

那大概可以设到2000条规则

所以从1到2000之间可以去设定

但通常我们会把range拉比较宽一点给自己一个余阈

所以通常我们可能就是100、200、300、500、550去设定

我们会给中间留一些空隙为了保险起见

好,那你可以给它一个名字

然後去底下描述这个rule是做什麽用的

比如说OK……像这个rule就是我要allow RDP进入

我就设了一个这样子的rule

那设了之後你可以把这个rule delete如果你不需要了

接下来我要讲的其实就是

这个Application Gateway就是load balance的部分

其实Azure上有两个load balancer

一个是纯粹就叫low balancer

它是给level 3、level 4的网路做导流的

那这个Application Gateway是可以当第7层的low balancer

其实Application Gateway它主要里面含有4个元件

首先是public IP,它的public IP可以充当Listener的角色

那再来是HTTP Settings,那再来是这个Probe

这个Probe就是会一直去探测後面的backend pool

比如说你可能接的是VM,可能接的是Azure上的Web App

可能接的是DB之类的

那这个Probe就像一个探测针

它可能……你可以去设定规则

那这三个元件Listener、HTTP Settings跟Probe

它们都是可以透过这个rules去做设定的

所以我们可以看到这个箭头都指向rules

它可以透过这个application的rule去做这些设定

那他的功能非常简易,OK

在Listener可以设定到底是一个public IP还是private IP

这个Probe像刚才讲的可以检查後端的服务是不是还活着

你可以去设定比如说每5分钟请你往後检查一次

比如说一个规则可能是当你每5分钟检查一次、检查两次

这个服务都没有回应的时候就代表这个服务是down了

请你赶快帮我导流到另外一台VM

你可以去设定这个时间点的探测规则

那再来是在HTTP Settings这边可以去定义Protocol、

Cookie、Affinity、Host、Name、Connection Draining

这些东西,那这其实就是Application Gateway的用处

那刚讲到Application除了可以作为第7层的low balancer之外

它也可以作为WAF对吧?

那其实我们Azure上的WAF遵循的是OWASP的这个规范

那我们可以抵挡它Top 10的攻击类型

包含非常常见的SQL插入保护、跨网站指令码保护、

HTTP走私要求、HTTP通讯协定的违规异常、协定异常等等

等等这些我们都可以防范

那我们这边可以很简单看到Application在这个场景里的作用

它可以去抵挡像这个XSS attack或SQL injection

遇到这些违规异常的攻击,它会直接把它挡下来

大家还记得一开始的架构图吗?

Azure上的CDN除了我们很常见就是那些静态资料之外

Azure CDN上还有一个DSA

也就是Dynamic Site Acceleration

它也可以去透过最佳化网络的那种路由的路径

来加速那些没有办法catch的、比较动态的

像是可能购物车这样子比较动态的网站场景

所以其实Azure CDN它有非常多作用

包含大量档案的下载、加速streaming的影音

或是静态的影音图片这些我们都可以去做加速

Azure CDN其实台湾是有POP点的

虽然台湾目前还没有data center,但台湾是有CDN的

我这边有放DDoS的服务

就是说放在Web的前面让它抵挡DDoS的攻击

我们都知道DDoS攻击就是真的非常麻烦

它其实就是大量的流量进来

你最难区分的就是到底哪些是恶意流量、那些是正常的流量

其实我听过一个非常有趣的说法

我们都知道DDoS攻击通常会攻击OSI 7层架构里的

第3层、第4层以及第7层,也就是传输层、网络层跟应用层

那这三层的攻击我看到一个非常有趣的说法

它是说如果把我们的服务比喻成一个商店的话

其实第3层的攻击就像是

我们在商店的大马路门口挤一大堆人就让你商店进都进不去

第4层也就是网络层的攻击就像是

我在商店的走道里站了一大堆人

让你根本就没有办法去货架取你要的商品

第4层的攻击就像是把你的资源全部都吃掉

你没有办法去取那些你要的商品

把你的memory、把你的compute全部资源都消耗掉

那第7层就像是结帐柜台排了一大堆人假装要结帐

所以我觉得这个比喻非常好,大家可以去思考一下

然後怎麽针对这三层做DDoS的防御

那其实我们Azure上的这个DDoS服务它会去

它在你启用这个DDoS服务的期间

我们有两种场景一种是免费版、一种是标准版

那你只要启用标准版的防护,它会执行的安全检查有3种

首先是它会确定封包符合网际网络规范的格式

规范并且格式没有错,那个封包有没有title

什麽哪里有没有什麽奇怪的东西,这些它会去做确认

那再来是它也会去跟用户端互动

判断这个流量是不是诈骗的封包

那第3个是要去速度限制封包

如果没有其他强制方法可以执行的话

那这边我们可以看到就是DDoS在这边

public IP进来之後它就会去跑一个自动化的policy

那这个policy目前在Azure上还没有办法做客制化的设定

那这个policy是我们总结微软多年被攻击的经验

给出一个自动化判定到底哪些是恶意流量或正常流量的方法

并且透过微软遍布全球的网络骨干尽可能去疏散流量

尽量确保你的服务不要down

所以其实我们给的是一个自动化DDoS判定的模型

机器学习模型

那你只要启动之後它自动就会套用这个policy

你不需要再去多做任何设定

并且这些DDoS攻击的情况,包含可能UDP、TCP这些情况

我们可以透过Azure上一个Azure Monitor的工具去做监控

那监控的图片就会像这样子

它就说针对哪一个computer大概flow是多少

那大概像这个就是我们可以看到这些metric

像这就是TCP DDoS的攻击

那这些资料会在Azure Monitor保存30天

那你可以去在这上面设定alert

发生攻击的时候开始跟结束的时间都请你通知我

所以我们可以去接收这些alert

那其实我们在Azure上启用DDoS服务的方法非常简单

首先你是先create一个DDoS的plan

create完之後因为我们DDoS的服务是跟着Virtual network

是跟着Azure的虚拟网络的,所以我们还会是

你可以想象一个虚拟网络层,它就会是保护整个虚拟网络

所以我们可以在进入虚拟网络之後这边的DDoS保护里

我们预设是会帮大家启用基本也就是免费版

那我们按标准版之後

我刚不是说你会先开启一个DDoS的plan

在这边选用你要用的是哪一个plan

之後你按储存,它就启用

那我们DDoS的计费方式是它会有一个启动的月费

那再来还有流量的费用

那详细的话都可以去我们Azure的计算机上看标准版的定价

所以其实这就是一个非常经典的

如果你只想要启用Azure上非常单纯的IIS服务的话

那我们会建议的架构规划范例

那其实在Azure上我们还有非常多的Pass层级的服务

像这边我们看到的Web、App和DB三个

我们也可以启用Azure上Pass的SQL database

甚至是customer DB等等全域性发散资料库

或是Web跟App可以使用我们的App Service来取代

它会有auto scaling或是

自动帮你处理好low balance的事情这样子的Pass服务

所以其实这只是一个IIS层级的架构参考

也非常欢迎大家在Infra层面都上手之後

去使用看看我们的Pass层级的服务

好,那今天的介绍就到这里

那有任何问题的话欢迎上Azure官网参考我们的文件

或者是联系微软业务窗口

期待下一次Youtube视频影片跟你们再见,拜拜。