buxcon
1
- nebula 版本：Nebula Graph on AWS, 3.1.2
- 部署方式：分布式
- 安装方式：AWS QuickStart, "Deploy NebulaGraph into an existing VPC"模板
- 是否为线上版本：N
- 模板参数
- 问题的具体描述
创建BastionStack的嵌套模板（https://${S3Bucket}.s3.${S3Region}.${AWS::URLSuffix}/${QSS3KeyPrefix}submodules/quickstart-linux-bastion/templates/linux-bastion.template）运行失败，失败步骤为创建BastionAutoScalingGroup，无更具体的报错信息：
但此时AutoScalingGroup实际上似乎已经创建完成：
重新运行无法解决此问题。
（另外，如果使用“Deploy NebulaGraph into a new VPC”模板则可以正常部署，但该模板不适用于我们的场景）
我注意到“Deploy NebulaGraph into an existing VPC”模板中PublicSubnet1ID和PublicSubnet2ID引用了同一个参数，但在“Deploy NebulaGraph into a new VPC”模板中它们则是两个不同的参数，会与此有关吗？
buxcon
3
我试着手动模拟linux-bastion.template中的cfn_success方法，会报ConnectionError，不知道我模拟的姿势对不对。。
这是我的测试参数
AccessCIDR 0.0.0.0/0
BastionAMIOS Amazon-Linux2-HVM
BastionInstanceType t2.micro
DashboardInstanceType t3.medium
EnableDashboard true
EnableExplorer true
ExplorerInstanceType t3.medium
GraphInstanceType t3.large
GraphNodeCount 1
GraphVolumeSize 10
GraphVolumeType gp2
KeyPairName kevin-test
MetaInstanceType c5.large
MetaNodeCount 1
MetaVolumeSize 20
MetaVolumeType gp2
NebulaGraphVersion 3.1.2
PrivateSubnet1AID subnet-08c94753482a2a80e
PrivateSubnet2AID
PrivateSubnet3AID
PublicSubnet1ID subnet-089cca2923121a1d3
QSS3BucketName aws-quickstart
QSS3BucketRegion us-east-1
QSS3KeyPrefix quickstart-vesoft-nebula-graph-cloud/
RemoteAccessCIDR 0.0.0.0/0
StorageInstanceType c5.large
StorageNodeCount 1
StorageVolumeSize 32
StorageVolumeType gp2
VPCCIDR 10.0.0.0/16
VPCID vpc-0f2621f13a2db6ee7
流程跑完是成功的
buxcon
6
使用了可以说和你相同的配置，但还是报同样的错
AccessCIDR 0.0.0.0/0
BastionAMIOS Amazon-Linux2-HVM
BastionInstanceType t2.micro
DashboardInstanceType t3.medium
EnableDashboard true
EnableExplorer true
ExplorerInstanceType t3.medium
GraphInstanceType t3.large
GraphNodeCount 1
GraphVolumeSize 10
GraphVolumeType gp2
KeyPairName key-pair-zhangweiran01-sh-office-pc
MetaInstanceType c5.large
MetaNodeCount 1
MetaVolumeSize 20
MetaVolumeType gp2
NebulaGraphVersion 3.1.2
PrivateSubnet1AID subnet-0e09c80c4c22c0fab
PrivateSubnet2AID
PrivateSubnet3AID
PublicSubnet1ID subnet-0a7c61a660234a7a9
QSS3BucketName aws-quickstart
QSS3BucketRegion us-east-1
QSS3KeyPrefix quickstart-vesoft-nebula-graph-cloud/
RemoteAccessCIDR 0.0.0.0/0
StorageInstanceType c5.large
StorageNodeCount 1
StorageVolumeSize 32
StorageVolumeType gp2
VPCCIDR 10.0.0.0/16
VPCID vpc-0b6a29b01f4175c28
从时间上看，每次失败都是超过了CreationPolicy的超时时间
buxcon
7
这是创建出的AutoScaling组Bastion实例的cloud-init相关log：
cloud-init日志.zip (212.5 KB)
但我没找到cfn-signal相关log
buxcon
8
我的推测是stack没有收到ec2实例发送的cfn-signal消息，进而未能满足模板中AutoScalingCreationPolicy.MinSuccessfulInstancesPercent=100的要求，进而失败。
于是我在ec2上手动模拟cfn消息的发送：
/opt/aws/bin/cfn-signal -e 0 --stack vesoft-nebula-graph-cloud-BastionStack-CB5W8KSFDJZ4 --region ap-northeast-1 --resource BastionAutoScalingGroup
回报连接错误：
所以在我们自有的VPC中部署，网络相关的配置有什么特别需要注意的吗？
buxcon
10
经过一些摸索解决了问题，分享一下我的主要操作：
1、当BastionAutoScalingGroup的机器创建出时，立刻到机器上做两件操作：
sudo yum install git
sudo echo "nameserver 某个DNS" >> /etc/resolv.conf
然后等待BastionAutoScalingGroup的自动重试，自动重试后该步骤便会成功。
2、调整配置中的 Network configuration - Permitted IP range 字段，将掩码放开到8。
经过这两个步骤，整个部署流程就会成功。
解释一下这些操作的原因：
- 你们的linux-bastion.template模板中，681行的命令会运行失败，导致创建出的Bastion缺少git，进而导致cloud-init中git clone相关命令无法执行成功
- 模板创建出的Bastion机器，/etc/resolv.conf文件是空的，导致它无法联网，进而无法向CloudFormation发送cfn-signal消息
- 默认的Permitted IP range放开的范围太小，Storage、Meta等机器的Private IP常常是10.a.b.c(a!=0)，所以当掩码是16时，创建出的安全组会拦住Storage和Meta间的流量
部署模板大概还可以优化一下，感谢 
1 个赞
buxcon
11
对了顺便问一下，我通过CloudFormation方式部署完3.1.2，假如后续出了3.2.0之类的新版本，有什么便捷升级方式吗？
buxcon
12
另外这样部署的版本是企业版？会自动通过AWS收费还是需要单独申请License？
企业版，当前需要单独申请license，未来会推出线上激活功能
bastion是我们引用的aws库，这部分我们可以再优化下做成可配置，防止意外阻碍整体流程
1 个赞
system
关闭
16
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。
