当前位置:首页 > 问答 > 正文

SQL Azure数据库部署那些事儿,经验分享和踩过的坑上篇

(引用来源:基于个人项目实践经验总结)

今天咱们就来聊聊在微软的Azure云上部署SQL数据库遇到的那些事儿,这可不是什么官方教程,纯粹是摸着石头过河,用真金白银和加班时间换来的经验教训,上篇主要聚焦在部署前的规划和选择阶段,这一步要是走错了,后面可就全是坑了。

第一件事儿:选型!不是越贵越好,合适才是王道

刚接触Azure SQL Database的时候,一看服务列表,有点懵,啥叫“DTU”?啥叫“vCore”?这俩有啥区别?感觉像在选汽车发动机。

DTU(数据库事务单元)这个东西,可以理解成一个“套餐”,它把计算、存储和IO资源打包在一起卖给你,比如你选个100个DTU的套餐,就相当于订了一份包含固定分量米饭、菜和汤的套餐,好处是省心,不用操心背后CPU用了多少,硬盘IOPS是多少,微软都给你配好了,对于大多数常规应用,业务量波动不是特别大的,用DTU模型挺方便的,价格也相对容易预估。

vCore(虚拟核心)模型就不一样了,它是“单点”模式,你可以单独选择CPU核心的数量、单独选择硬盘的类型和大小(比如是普通硬盘还是SSD),甚至还可以选择是否使用Azure混合权益(就是你如果本来有SQL Server许可证,可以带过来省钱),这个模式特别适合那些对性能有非常精细要求,或者需要完全掌控资源配比的场景,比如你知道你的应用是CPU密集型,或者对磁盘读写速度有极致要求,那用vCore就能把钱花在刀刃上。

我踩过的坑就在这里,当时有个项目,为了“性能最大化”,一拍脑袋就选了vCore模式,还配了很高的IOPS,结果上线后发现,大部分时间CPU闲得发慌,但费用却居高不下,后来仔细分析监控数据才发现,其实那个阶段用个高等级的DTU套餐就绰绰有余了,能省下将近30%的成本,选型前一定要对自己的业务负载有个基本判断,看看是计算密集型还是IO密集型,流量是否平稳,千万别觉得贵的、灵活的就一定是好的。

第二件事儿:地理位置,不只是距离问题

部署数据库的时候,你得选一个“区域”,比如东亚(通常在香港)、东南亚、美国东部等等,最开始我觉得,这有啥好选的,用户主要在国内,当然选东亚啊,延迟最低。

但实际情况复杂得多,你得考虑“高可用性”,Azure SQL Database默认就提供了99.99%的SLA(服务等级协议),它的实现方式是在你选择的 primary region(主区域)内,自动维护一个主数据库和几个同步的副本,但注意,这只是在一个地理区域内的冗余,如果整个区域发生重大故障(虽然概率极低),你的数据库可能就访问不了了。

这时候就需要用到“异地复制”功能,你可以手动设置一个次要区域,比如把东亚的数据库异步复制到东南亚,这样东亚的主库挂了,你可以手动或者配置自动故障转移到东南亚的库上,这又带来一个新问题:成本!因为你在另一个区域也创建了一个同等规模的数据库实例(虽然是只读的),这可是实打实的双倍费用,要不要做异地容灾,取决于你的业务对连续性的要求有多高,以及你愿意为此付出多少成本,不能盲目开启。

另一个坑是关于数据合规性的,如果你的业务涉及敏感数据,比如用户个人信息,并且有法规要求数据必须存储在国内,那么你就不能选择海外的区域,Azure在中国有由世纪互联运营的版本,那个才是合规的选择,一开始没搞清楚国际版和国内版的区别,可能会在后期造成大麻烦。

第三件事儿:防火墙规则,安全的第一道门

Azure SQL Database默认是“拒绝对外连接”的,非常安全,也意味着你本地电脑的SSMS(SQL Server Management Studio)根本连不上它,你必须设置防火墙规则,告诉Azure:“允许来自这个IP地址的访问”。

这里有几个小坑点,一是“允许Azure服务和资源访问此服务器”这个选项,如果勾选了,意味着所有在Azure内部运行的资源(比如你的Web应用服务、虚拟机等)都可以不经防火墙验证直接连接数据库,这在开发和测试阶段很方便,但从安全角度讲,范围太宽了,更安全的做法是不勾选,然后为你具体的Azure服务(比如App Service)分配一个出站IP,再把这个IP单独加到防火墙规则里。

二是动态IP问题,很多公司办公室或者家里的宽带IP不是固定的,你今天加的IP,可能明天就变了,然后你就发现突然连不上数据库了,还得去改规则,解决办法是,如果可以,尽量使用VPN或者Express Route等具有固定IP的通道来访问管理数据库,或者在开发阶段临时添加,用完即删。

就是上篇的内容,主要总结了在点击“创建”按钮之前就需要想清楚的几个大问题:服务层级怎么选、放在哪个地方最合适、访问安全如何控制,这些问题看似基础,但一旦选错,后期调整起来要么费钱,要么费力,甚至需要停机迁移,下篇我们会接着聊部署之后,在性能调优、备份恢复等方面遇到的实际问题和解决办法。

SQL Azure数据库部署那些事儿,经验分享和踩过的坑上篇