一、背景
开这个blog两年了，此前一直是以普通EC2方式运行Wordpress，并使用托管的RDS运行数据库。由于PHP的跨平台特性，这次升级配置转向了AWS自研的ARM架构的Graviton 2处理器的实例。
1、Graviton 2介绍
关于Graviton2的介绍如下：
AWS Graviton 由 Amazon Web Services 使用 64 位 Arm Neoverse 内核定制而成，为在 Amazon EC2 中运行的云工作负载提供更高的性价比。Amazon EC2 提供更为广泛且深入的计算实例组合，其中包括许多由新一代 Intel 和 AMD 处理器提供支持的实例。AWS Graviton 处理器带来更多选择，帮助客户优化性能和降低工作负载成本。AWS Graviton2 处理器不管在性能还是功能上都实现了巨大的飞跃。它们为 Amazon EC2 通用型（M6g、M6gd、T4g）、计算优化型（C6g、C6gd、C6gn）和内存优化型（R6g、R6gd、X2gd）实例提供支持，与当前这一代基于 x86 的实例相比，可为广泛的工作负载（如应用程序服务器、微服务、高性能计算、基于 CPU 的机器学习推理、视频编码、电子设计自动化、游戏、开源数据库和内存中的缓存）提供高达 40% 的性价比提升。它们可以提供高 7 倍的性能、多 4 倍的计算核心、快 5 倍的内存和大 2 倍的缓存。
参考网址：
https://aws.amazon.com/cn/ec2/graviton/?nc1=h_ls
2、迁移场景
迁移场景 1：迁移场景1因为wordpress使用了S3插件，所有image上传都自动上传到S3，且自动映射为CloudFront发布点上绑定的CNAME域名，因此全过程是无需迁移静态文件的，只迁移PHP文件、HTML、CSS等wordpress程序本身。
迁移场景 2：将Wordpress原EC2 EBS磁盘迁移到EFS文件系统。由于Wordpress是带有自升级的功能， 因此代码发布并不是从git获取push，也不是获取新的docker镜像，而是应用程序直接对web目录进行读写获取新的文件。这种方式不是典型的CICD，更类似传统商用软件可能会读写本地目录的场景。从将应用和计算分离的角度来说，应将Wordpress完全从EBS上抽离，将EC2做到无状态可替换。由此可以显著简化集群管理、Spot管理、Launch Template启动模版、ASG弹性扩展组、拉起新容器等各种场景下的管理复杂度。综上所述，这次更换Graviton2，顺便把文件系统也更换下。
二、升级过程
1、配置新环境
- 创建EFS共享存储服务
- 创建新的Graviton2 EC2实例
- 使用为ARM处理器优化的Amazon Linux 2系统（兼容CentOS7）并打补丁到最新，高版本php通过amazon-linux-extras install php7.4 完成自动安装
- 将EFS挂载到新的EC2实例上
- 使用yum方式对php查漏补缺安装php-gd、php-xml、php-mbstring、php-pecl-imagick等RPM包
- 各种重启服务，测试php正常
- 绑定原先EC2使用的IAM Role
- 检查其他Agent的安装配置情况
- 检查其他定期任务情况
2、迁移原环境
- 将原使用Intel处理器的EC2挂载EFS共享存储
- 复制整个web目录到EFS
- 复制apache配置文件
3、迁移割接
- 将EFS上的数据复制到新的Graviton2实例上，并修正目录owner
- 在新的EC2上启动服务并测试
- 将新的EC2加入ALB的Target Group
- 确认流量正常送达，旧的实例从目标组中摘除
至此EC2计算环境升级到Graviton2处理器完成。
4、数据库迁移
数据库使用的是Aurora MySQL。AWS Aurora MySQL与普通RDS MySQL的区别是：
- Aurora的高可用是两台独立节点，1个写入节点，1个只读节点，只读节点兼HA高可用的备用需求
- RDS MySQL的高可用是一对多AZ节点，只有主节点可见，备用节点不可见；额外按需配置只读节点
从以上高可用对比可以看出，Aurora对于数据库升级更换更为友好。从X86架构更换到Graviton2的Aurora步骤建议如下：
- 将Reader节点修改配置，从原来的r5修改为r6g；需要数分钟升级，等待启动稳定后，做下读取测试
- 执行Fail-over，切换写入节点和只读节点，将上一步修改完成的r6g节点promo为主节点，接收业务写入；切换稳定后，做读取和写入测试
- 将剩余的已经降级为reader节点的r5实例修改配置，改为r6g节点；需要数分钟升级，等待启动稳定后，做下读取测试
数据库升级到Graviton2处理器完成。
需要注意的是，使用Performance Insight有最小数据库规格要求，在t4g等机型上，内存不够大不被支持。这个特性在之前Intel处理器的机型上也是一致的，变配时候需要注意功能和规格对应关系。
三、结束
至此更换Graviton2处理器的过程完成，全过程大约1-2小时完成，大部分时间花在找wordpress的需要的simleXML RPM包上。因此也可以看出，通用脚本语言兼容良好，迁移。现在即可开始享用Graviton2处理器可获得更高性能、更低成本。