知识库

使用 CloudFormation 在 AWS 上部署 Neo4j

本文档说明了如何使用 CloudFormation 在 AWS 上通过虚拟机部署 Neo4j 集群。

基础

Neo4j CloudFormation 模板允许在 AWS 上以虚拟机的形式部署任意规模的因果集群,几乎可以使用任何机器类型。这些模板基于 Neo4j Cloud VMs,该镜像已在 Amazon(AMI)上提供。

AWS Marketplace

Neo4j Enterprise 因果集群已在 AWS Marketplace 上可用,可通过 此链接 找到。

本文讨论的 CloudFormation 模板与该 Marketplace 列表使用的模板相同。因此,如果您不需要对 CloudFormation 模板进行任何修改,直接使用 Marketplace 选项可能更为便捷,该选项为 BYOL(自带许可),不收取额外的按小时计费。

本文面向需要自定义默认部署选项的客户。

可用性

JSON 格式的模板已放置在公共 S3 存储桶 s3://neo4j-cloudformation 中。提供两类模板:一种用于单实例独立的 Neo4j 安装,另一种用于因果集群设置。本文其余部分将重点讨论因果集群设置。单实例的模板遵循相同的通用规则和架构,只是创建单个 VM 而非可配置数量的 VM。

模板已为许多(但并非全部)Neo4j 版本提供。例如,3.5.12 版本的 CloudFormation 模板完整公共 URL 为 https://s3.amazonaws.com/neo4j-cloudformation/neo4j-enterprise-stack-3.5.12.json

不同版本之间模板结构的基础是相同的,唯一主要差异在于所使用的 AMI 对应的 Neo4j 版本。

架构

可在此处查看 CloudFormation 模板遵循的部署架构

aws ec2 diagram

通常情况下,会创建一个新的 AWS VPC,在三个子网(分别位于同一地区的不同可用区)中轮流放置核心节点和只读副本。CloudFormation 模板的限制是只能在拥有 ≥3 个可用区的区域使用,以实现这种分散部署;在某个可用区出现故障时,数据库仍能保持可用。

客户 VPC

您最可能需要修改模板的原因是希望将 Neo4j 集群放入已有的 VPC 中。

目前 CloudFormation 模板默认不支持将新集群放入已有 VPC,因为涉及的因素太多(如子网剩余 IP 地址数量、已有路由规则等),难以保证可靠操作。完全可以实现,只是需要贵组织自行定制,以确保这些因素均已得到考虑。

以下是检查模板时的简要清单:

  • 虚拟机与子网的关联

  • 通常无需创建互联网网关

使用

要从 JSON 文件创建 CloudFormation 堆栈,请自定义以下命令,并根据需要替换参数

$ aws cloudformation create-stack \
   --stack-name StackyMcGrapherston \
   --template-body file://neo4j-enterprise-stack.json \
   --parameters ParameterKey=ClusterNodes,ParameterValue=3 \
                ParameterKey=InstanceType,ParameterValue=m3.medium \
                ParameterKey=NetworkWhitelist,ParameterValue=0.0.0.0/0 \
                ParameterKey=Password,ParameterValue=s00pers3cret \
                ParameterKey=SSHKeyName,ParameterValue=my-ssh-key-name \
                ParameterKey=VolumeSizeGB,ParameterValue=37 \
                ParameterKey=VolumeType,ParameterValue=gp2 \
  --capabilities CAPABILITY_NAMED_IAM

此命令将创建一个运行在 m3.medium 实例上的 3 节点因果集群,对整个互联网开放(因为我们将网络白名单设为 0.0.0.0/0),使用提供的 Neo4j 用户密码初始化数据库,并通过指定的 SSH 密钥直接进行 SSH 登录。每个节点分配 37 GB GP2 存储。

有关可用的其他参数,请查阅模板顶部的参数列表。其他选项还包括创建若干只读副本的能力。

持续管理

CloudFormation 并未自动化集群本身的运维,也未提供太多自动伸缩功能。因此,基础设施部署完成后,管理和自定义配置需要通过拥有 SSH 访问权限的运维人员自行完成。

代码来源

构建任意版本 Neo4j AMI 或 CloudFormation 模板的代码位于 私有 GitHub 仓库。可根据请求授予客户访问权限,但仓库不会公开。

成品的 CloudFormation 模板因为 CloudFormation 的工作方式而难以直接编辑。例如,CloudFormation 本身不支持动态创建可变数量的资源(如用户自定义的核心节点数),因此最终模板包含了最多可创建 9 个核心节点的代码,并通过条件判断实现用户选择的数量。在 GitHub 仓库中,我们使用名为 jinja 的模板语言生成 CloudFormation 模板,使其在模块化阅读和管理上更为友好。如果需要进行大量修改,建议基于这些 Jinja 模板进行工作,而不是直接编辑原始的 CloudFormation 模板。

© . This site is unofficial and not affiliated with Neo4j, Inc.