AWS 运维

Posted 2023-03-17

参考技术A AWS的故障

从我们2011年接触AWS至今，比较大一点的故障多集中于2012年，小故障每年零零星星还会有一些，总的来说AWS的稳定性和可靠性是越来越好。

这边先简单介绍一下，AWS每一个区域（Region）都会有多个可用区（Availability Zone，简称AZ），可用区之间互相独立，不受其他可用区故障的影响。

我们遇到过一个可用区（AZ）故障，最初的表象是网络时断时续，API Error Rate增加，AWS论坛里面也很有很多人报这个问题，当时没有回应。接下来，网络开始大面积中断，直到整个可用区的EC2服务处于几乎不可用的状态，AWS网站开始告知可用区故障的信息。

再往下，该地区的AWS Management Console也基本刷不出内容。我们自己的监控系统，产生大量的告警，且持续了一个多小时，当时也吓出一身冷汗。因为无法进行直接的人工干预--AWS API直接返回503服务不可用.

另外，AWS文档中提到的关于可用区挂掉后，新的机器会在另一个区自动创建的功能，似乎当时也没有起效。不过，好在我们的机器都是多可用区部署，除个别非关键组件单点，以及AWS API暂时不可用外，另一个可用区的网络并没有受到影响，对外服务也没有受到干扰。

这个事件过后，我们开始反省，如果再发生要怎么办？（后来还真发生了）

保持多可用区部署且无状态，避免单点服务，增加更细的监控点（比如对所使用的AWS服务本身）。

ELB要打开Cross-Zone Balancing功能，按实际机器数量来均分流量，默认是按可用区均分流量。

增加Fault Tolerance测试，类似Netflix Chaos Monkey的做法，评估我们所使用的每个AWS服务故障时，对服务可能产生的影响。

跨地区的切换，比如：东京不可用，就把用户流量切到新加坡。

购买AWS Support Plan，解决AWS故障时信息不透明且无人可帮忙的困境。

零星小故障总结：

定时事件，虽然官方不叫故障，属于我个人意见。有些底层的硬件存在故障或者需要更新，AWS会提前通知，到时间，通常情况下机器会被停掉重启。比较烦人的点就是冷不丁就冒出来了，通常都必须要去关注，当然不同的事件级别不同，出现时还是小心为好，找好维护时间窗，早点解决。

有时候机器会被意外关掉，重启或者短暂网络故障，通常都不会有通知，而此时AutoScaling健康检查也相应失效。这种问题现在变得越来越少，主要靠监控发现，然后找AWS Support一起跟踪确认原因。

如果使用DNS来帮助服务发现，就要小心Route53的API调用限制，因为Route53是全局服务，API调用数量的计算按一定时间内，所有地区调用的总和。这个本质上不算故障。

自动伸缩

自动伸缩（AutoScaling）可以认为是AWS的核心功能，可根据用户的业务需求和策略，自动调整其弹性计算资源。

可用性和稳定性是通过定时健康状况检查和自动替换机器来做到的，包括EC2本身的健壮检查、使用ELB的健康监控，甚至自定义的监控通过API反馈给AutoScaling服务。

伸缩规则分为两种：简单规则和步进规则。

a. 简单规则，只根据一条规则增减容量，比如当平均CPU超过70%，增加两台机器。Cloud Watch会去自动监控这个指标，达到时就会告警，触发伸缩行为。这边要注意的是伸缩行为的发生必须等待其他伸缩行为完成，再响应告警。其中，增减的数量可以是定值也可以是百分比，同样Cloud Watch中监控到的数据，也可是通过API自定义灌入的。

b. 步进规则，早先AWS并不支持，它包含一组规则。比如CPU在40%-50%时加一台机器，50%-70%加两台，70%以上加四台等等。此时，若已有伸缩行为发生，该规则还会继续响应告警，中间会有一个预热时间，时间不到，这个机器的指标都不会计入。和简单规则相比，这种规则的伸缩行为无锁，且持续统计指标，及时触发，推荐使用。

关掉的机器不能做特定选择，但会有一些模糊的规则：运行时间最久的，隶属的伸缩规则最老的，接近一个小时的开机时间等等。

对于是事先准备预编译好的AMI还是通过配置管理工具现场安装，对预热时间比较敏感的服务，推荐是前者。

介绍完AWS中的自动伸缩服务，引出一个关键问题就是如何设置一个合理的规则，来比较精细地平衡成本和负载。这些都需要通过大量的测试来做权衡判断。

设计伸缩规则，需要注意的地方是：

这是一整个系统的调优过程，涉及到的参数，可能不仅仅是规则本身，比如，使用ELB的，还要考虑到相关的性能参数。

这个规则可能会随程序的变革而变化，最好做到自动化。

加机器要早，减机器要慢。负载开始增加时早作打算，因为中间有可能会产生新机器启动失败等问题，另外算上机器启动时间和服务到位的时间，早打算可以避免容量跟不上的问题；减机器时，要慢慢来，稳稳地进行。否则，一方面避免连接被硬生生掐断，另一方面由于减机器过快，而负载仍在，导致又要增加机器，这使得伸缩行为太过频繁，成本和稳定性会受到影响。

采集机器的CPU数据，尽量使用Cloud Watch的，本机采集的数据不一定准确。

应用本身需要记录足够的性能数据，写入日志，方便后期数据整理。

如果有条件，可以尝试建立一个简单的数据模型来实际分析。

AWS上新一代运维与DevOps研讨会

随着云平台被越来越多的企业认可和使用，越来越多的用户开始在云平台上部署自己的应用。着眼于此，上海冠闵信息科技有限公司与AWS亚马逊云联手举办“AWS上新一代运维与DevOps研讨会”主题活动！

本次研讨会于昨日在思南公馆宴会厅举行，这栋有着外廊式特色的建筑始于1920年，当历史建筑与现代科技相碰撞，也是别有一番风味。

上海冠闵 COO  ——颜伟志先生作为本次研讨会主办方之一上台感谢所有客户前来，并对今天的会议行程做了简单介绍。

AWS China Principal BD——顾圣峰先生用其风趣幽默的言语风格简单做了开场致辞，在轻松的气氛中，迅速揭开了今天研讨会的序幕。

在欢声笑语中，AWS BD——王海波先生为我们带来AWS中国区域更新介绍。众所周知，AWS在去年12.12发布了宁夏区域，至今已有5个月，王海波先生详细为我们介绍了北京区和宁夏区的不同点以及各自更新的地方。席间，客户提问络绎不绝，王海波先生也用其专业知识仔细为每一位客户耐心解答！

其次由上海冠闵CTO——Mark Kong为大家介绍了AWS新一代MSP及云管理平台的演讲。上海冠闵作为国内唯一一家AWS最高级别的核心级咨询合作伙伴（Premier Consulting Partner）以及AWS认证托管服务提供商（MSP）的合作伙伴，我们有足够的能力以及经验为中国本地客户服务。

我们更现场演示了由冠闵自主开发的高效云管理平台——御云者CloudEasy。作为AWS的最佳实践者，充分依靠API Gateway, Lambda和AWS大数据提供海量级和自动化的AI智能监控数据处理支持，并且在国内已经能够做到率先支持跨北京与宁夏2个区域的监控，为客户使用AWS服务提供友好的体验，起到提高效率，节省成本的作用。其清晰友好的界面以及全方位的可视化监控，更能大幅提高企业在云平台服务上的管理能力！

#最后大家也纷纷举起手机扫描我们的微信二维码了解更多信息#

在风起云涌的云计算时代，运维已跟DevOps密切相关，开发运维一体化使得运维人员变得尤为重要。 运维人员需了解一些开发运维DevOps新趋势，来应对飞速的变化。考虑到众多企业客户已经了解到DevOps可以与业务目标更完美的结合，本次研讨会还请到了玫琳凯信息技术架构副总监——戴成彬先生为我们带来AWS上运维与DevOps实践分享！

会上戴成彬先生不光提到了DevOps的前世今生，更分享了他们自己的实践经验。包括玫琳凯为什么选择上云，一开始用了其他云平台后为什么改成使用AWS，为什么要用DevOps，以及为何采用ITOA（IT Operations Analytics）等分别分享了玫琳凯在每个阶段宝贵的实践经验。

DevOps突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。换句话说，DevOps希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。

戴成彬先生用他本身的实践经验对在场的听众做了详细的讲解，同时对于冠闵作为玫琳凯的MSP服务提供商所展现的的服务质量及技术先进性做出了极大的赞赏，这对我们也是极大的鼓励！

在充满文化历史的思南公馆，我们当然也准备了品酒会给大家，还请到了Riedel品牌经理——熊晓敏先生为我们讲解不同的葡萄酒杯搭配不同的葡萄酒的重要性。现场熊晓敏先生还用简单的冰水实验来使我们明白其中的奥妙。

满满的干货分享结束以后，上海冠闵还为大家准备了精美的晚餐供大家品尝。期间大家的热情交流气氛随着美食也异常高涨，也为这次的研讨会画下完美的句点！

上海冠闵携手AWS共同期待与各位嘉宾的再次相聚！

Every Cloud Has a Silver Lining