AWS Lightsail 修改 DB 参数

AWS 推出的 Lightsail Database 是目前比较实惠的托管 DB 方案。不过相对来说,Lightsail 的控制面板功能较少,很多参数无法修改。经过搜索发现,其实我们有很多参数可以调,只是需要通过命令行的方式来调整。

准备工作

安装 aws-cli 工具

https://aws.amazon.com/cli/

https://lightsail.aws.amazon.com/ls/docs/en_us/articles/lightsail-how-to-set-up-and-configure-aws-cli

Linux:

sudo apt-get install awscli

MacOS:

brew install awscli

Python(通用):

pip install awscli

设置 Access Key

https://lightsail.aws.amazon.com/ls/docs/en_us/articles/lightsail-how-to-set-up-access-keys-to-use-sdk-api-cli

先在 AWS 控制台新建用户或 Key:

https://console.aws.amazon.com/iam/home#/users

然后执行:

aws configure

按照提示依次输入:

AWS Access Key ID 控制台中创建的 Key
AWS Secret Access Key 控制台中创建的 Key 对于的 Secret
Default region name 可用区,https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html
Default output format 输出格式,建议 json

获取现有设置

aws lightsail get-relational-database-parameters --relational-database-name DatabaseName > current_params.json

注意 DatabaseName 替换为创建 DB 时设置的名称。就是 Lightsail 控制面板里显示的那个。

执行成功后打开 json 文件,可以看到所有变量。

注意每个变量有几个属性:

Allowed values 允许的变量范围
Apply method 变量的生效时间。immediate 表示立即生效,pending-reboot 表示重启后生效
Apply type 底层引擎支持的生效方式。dynamic 动态,可以立即生效,static 静态,必须重启后才能生效
Data type 数据类型
Description 变量描述
Is modifiable 能否修改
Parameter name 变量名

这里我们用最大连接数举例:

{
    "allowedValues": "1-100000",
    "applyMethod": "pending-reboot",
    "applyType": "dynamic",
    "dataType": "integer",
    "description": "The number of simultaneous client connections allowed.",
    "isModifiable": true,
    "parameterName": "max_connections",
    "parameterValue": "{DBInstanceClassMemory/12582880}"
}

可以看到,最大连接数是一个动态变量,整型,可修改。默认是实例内存大小/12582880,也就是 1G 内存约 80 个链接。实际比这个数值少,没有具体深究。

修改设置

找到了对于的参数,就可以修改了。修改参数使用的指令是:

aws lightsail update-relational-database-parameters --relational-database-name DatabaseName --parameters "parameterName=ParameterName,parameterValue=NewParameterValue,applyMethod=ApplyMethod"

DatabaseName 是实例名,ParameterName 替换为要修改的变量,NewParameterValue 替换为变量的值,ApplyMethod 替换为想要的生效方式。

比如,我们修改最大连接数到 1000,重启后生效,对应的命令为:

aws lightsail update-relational-database-parameters --relational-database-name DatabaseName --parameters "parameterName=max_connections,parameterValue=1000,applyMethod=pending-reboot"

成功后会收到这样的响应:

{
    "operations": [
        {
            "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
            "resourceName": "DatabaseName",
            "resourceType": "RelationalDatabase",
            "createdAt": 1570000000.000,
            "location": {
                "availabilityZone": "ap-northeast-1a",
                "regionName": "ap-northeast-1"
            },
            "isTerminal": true,
            "operationDetails": "",
            "operationType": "UpdateRelationalDatabaseParameters",
            "status": "Succeeded",
            "statusChangedAt": 1570000000.000
        }
    ]
}

看到 status Succeeded 就是设置成功啦!

官方文档:

https://lightsail.aws.amazon.com/ls/docs/en_us/articles/amazon-lightsail-updating-database-parameters

 

各家云上 Kubernetes 服务对比

最近在研究 GitLab 的 DevOps 工作流,看到 GitLab 可以和 K8s 通过 API 进行交互,于是决定研究一下各种云的 K8s 服务,做一个简单的对比。

部署方式

根据部署方式的不同,我们可以将不同的云服务进行分类:

  • 全托管:Master 节点和 Worker 节点完全由云来管理,只提供 API 来调用,一般按照实际的 CPU 和内存使用来计费
  • 半托管:Master 节点由云来管理,自行购买 Worker 节点。可以修改部分 Master 节点的配置,所有容器在自己的机器上运行
  • 全独立:Master 节点和 Worker 节点都由用户管理,云只负责节点的初始化和小部分维护工作。可以修改几乎所有 Master 的配置,整个集群完全独立

首先来看下各个云提供商所提供的服务类型:

提供商\类型 全托管 半托管 全独立
腾讯云 CIS TKE TKE 独立部署
阿里云 Serverless Kubernetes Kubernetes 托管版 Kubernetes
Azure 容器实例 Kubernetes 服务 /
AWS ECS EKS /
GCP / GKE GKE On-Prem
仅能在非 GCE 机器部署

其中,全托管模式只有阿里云提供 k8s API 调用,其余提供商都不直接支持 k8s API

半托管模式基本相似,都是由云服务商运行 Master Node,区别在于 AWS 的 EKS 对 Master 节点收费,其余服务商均不收取 Master 节点的费用。

版本支持

然后再来看看各个服务商对于 k8s 版本的支持:

提供商\版本 最低版本 最高版本 是否支持升级
腾讯云 1.8.13 1.12.4
阿里云 1.11.5 1.12.6
Azure 1.10.12 1.14.0
AWS 1.10 1.12
GCP 1.11.10 1.13.6

可以看到,除了 Azure 对于新版的支持非常激进外,大部分云提供商都很谨慎的对版本升级进行跟进。GCP 是个例外,毕竟 K8s 是 Google 搞出来的,似乎比所有人都更激进。

价格

最后再来看看各个服务商的价格:

提供商\版本 Master 节点 常驻 Worker 突发 Worker
腾讯云 / ¥49.5/m 同 ECS
阿里云 / 至少两个
2c4G
$57.41/m
¥396.129/m
Azure / 至少一个
2c4G
$49.18/m
¥339.342/m
同普通虚拟机
AWS $0.20/hr
¥1.38/hr
¥993.6/m
/ 同 ECS
GCP / 1c1.7G
$13.8/m
¥95.22/m
同 GCS
$0.031611 / vCPU hour
$0.004237 / GB hour
按秒计费,最低 1 分钟

1美元按6.9人民币计算

总体来说,如果是不常用的集群,节点费用上 GCP 较低,AWS 则由于 Master 管理费的存在很不划算。

而阿里云则是比较奇葩,基础版本的机型无法使用。内存 CPU 较小的机型则不能使用阿里定制的网络插件。而且,阿里云是唯一一个必须至少有 2 个常驻节点的服务商。所以整体来说成本较高。

总结

对于短时间使用的测试集群,腾讯云是一个不错的选择。整体价格低廉,成本低。GCP 也非常不错,就算是长时间闲置也不会有太高的花费。

对于生产集群,考虑服务稳定性和后续的持续维护性,Azure 和 GCP 都是不错的选择。Azure 价格略高,但是相对来说周边生态较好。GCP 则费用低廉。如果对 Azure 周边生态有所依赖的,可以尝试一下。而对于个人开发者来说,由于 GCP 还有免费额度,可能是初期一个较好的选择。

IPv6 地址处理时的小 Bug

众所周知,IPv6 地址中可以用 ::  来省略一连串的 0,于是,在某些情况下,如果 0 被过度合并了,就会导致地址解析的问题。

最近在 AWS 上启用 IPv6 的时候就遇到了这个情况,AWS 分配给我的地址段是:

2406:da14:5c9::/56

可以看出,AWS 实际给我分配的地址是:

2406:da14:5c9:0000::/56

但是由于连续 0 的省略策略,导致 5c9 之后的真正可以被划分的部分被省略了。于是在 AWS 的系统中,子网划分页面就显示成了这样:

2406:da14:5__::/64

按照正常逻辑应该是这样:

2406:da14:5c9:00__:/56

结果当然就悲剧了。这里我除了填 c9 之外,任何的值都会导致划分出的子网不在上面的地址段内,导致划分失败。

所幸的是 AWS 的系统可以随意的解绑地址段,然后重新分配。于是重新分配之后就好了。

不过这里也是对我们的一个提醒:由于 IPv6 地址书写的特殊性,连续 0 会被缩写,那么在进行地址读取和判断的时候,就一定要先做 ::  的展开,再去做判断哦。