首页 > 资源 > 文章详情
Google Cloud 中的着陆区设计
本文档简要介绍了如何在 Google Cloud 中设计着陆区。着陆区是一个模块化且可扩缩的配置，让组织可以借助 Google Cloud 来满足其业务需求。着陆区通常是在云环境中部署企业工作负载的前提条件。
本文档面向希望大致了解以下内容的解决方案架构师、技术从业人员和执行利益相关方：
Google Cloud 中着陆区的典型元素
在哪里可以找到有关着陆区设计的详细信息
如何为企业部署着陆区
本文档是系列文章中的一篇，可帮助您了解如何设计和构建着陆区项目。本系列中的其他文档将指导您完成在设计组织着陆区时需要做出的总体决策。在本系列中，您将了解以下内容：
Google Cloud 中的着陆区设计
确定如何为 Google Cloud 中的身份进行初始配置
确定 Google Cloud 着陆区的资源层次结构
确定 Google Cloud 着陆区的网络设计
确定 Google Cloud 着陆区的安全性
本系列文章没有明确涉及金融服务或医疗保健等监管行业的合规性要求。
什么是 Google Cloud 着陆区？
着陆区可帮助您的企业更安全地部署、使用和扩缩 Google Cloud 服务。着陆区是动态的，随着企业越来越多地采用基于云的工作负载，着陆区也会不断增长。
完成组织的基础设置后，您便可以开始部署着陆区。基础设置包括创建组织资源和创建结算帐号（在线或帐单结算）。
着陆区跨多个区域，涉及身份、资源管理、安全性和网络等不同元素。着陆区也可以包含许多其他元素，如着陆区的元素中所述。
下图显示了一个着陆区的实现示例。该图展示了 Google Cloud 中一个使用混合云和本地连接的基础架构即服务 (IaaS) 用例：
上图中的示例架构展示了一个包含以下 Google Cloud 服务和功能的 Google Cloud 着陆区：
Resource Manager，使用组织政策定义一个资源层次结构。
一个 Cloud Identity 帐号，与本地身份提供方和 Identity and Access Management (IAM) 同步，从而提供对 Google Cloud 资源的精细访问权限。
一个包含以下内容的网络部署：
每个环境（生产、开发和测试）的共享 VPC 网络，用于将多个项目中的资源连接到 VPC 网络。
虚拟私有云 (VPC) 防火墙规则，用于控制进出共享 VPC 网络中的工作负载的连接。
一个 Cloud NAT 网关，允许从这些网络中的资源到互联网之间进行出站连接，而不需要外部 IP 地址。
Cloud Interconnect，用于连接本地应用和用户。（或者，您也可以选择专用互连或合作伙伴互连。）
Cloud VPN，用于连接到其他云服务提供商。
一个 Cloud DNS 专用可用区，用于托管您在 Google Cloud 中的部署的 DNS 记录。
部署在共享 VPC 网络中的多个服务项目。这些服务项目用于托管您的应用资源。
Google Cloud 运维套件，包括用于监控的 Cloud Monitoring 和用于日志记录的 Cloud Logging。Cloud Audit Logs、防火墙规则日志记录和 VPC 流日志，有助于确保所有必要的数据均已记录且可用于分析。
每个环境的 VPC Service Controls 边界，包含共享 VPC 和本地环境。安全边界可将服务和资源隔离开来，这有助于降低受支持的 Google Cloud 服务发生数据渗漏的风险。
上图只是一个示例，因为着陆区不存在唯一实现或标准实现。您的企业必须根据不同的因素做出许多设计选择，这些因素包括：
您的行业
您的组织结构和流程
您的安全与合规性要求
您要迁移到 Google Cloud 的工作负载
您现有的 IT 基础架构和其他云环境
您的企业和客户的位置
何时构建着陆区
我们建议您首先构建着陆区，然后再在 Google Cloud 上部署第一个企业工作负载，因为着陆区可为您提供以下功能：
安全的基础
面向企业工作负载的网络
管理内部费用分布所需的工具
但是，由于着陆区是模块化的，因此着陆区的第一个迭代版本通常不是您的最终版本。为此，我们建议您在设计着陆区时考虑可扩缩性和增长因素。例如，如果您的第一个工作负载不需要访问本地网络资源，那么您可以稍后再构建与本地环境的连接。
根据您的组织需求以及计划在 Google Cloud 上运行的工作负载类型，某些工作负载可能具有不同的要求。例如，某些工作负载可能具有特别的可扩缩性或合规性要求。在这些情况下，您的组织可能需要多个着陆区：一个着陆区用于托管大多数工作负载，另一个单独的着陆区则用于托管那些特别的工作负载。您可以在这些着陆区之间共享一些基础元素（例如身份、结算、组织节点）和部分组织政策。但是，其他元素（例如网络设置、部署机制和某些文件夹级层的政策）可能会有所不同。
着陆区的元素
着陆区要求您在 Google Cloud 上设计以下核心元素：
身份预配
资源层次结构
网络
安全控制
除了这些核心元素之外，您的企业可能还有一些额外的要求。下表介绍了这些元素以及在哪里可以找到有关这些元素的详细信息。
| 着陆区元素 | 说明 |
|---|---|
| 监控和日志记录 | 设计监控和日志记录策略，确保所有相关数据均得到记录，并提供用于直观呈现数据和提醒的信息中心，以便在出现任何可操作的异常时通知您。 如需了解详情，请参阅以下内容：
|
| 备份和灾难恢复 | 设计备份和灾难恢复策略。 如需了解详情，请参阅以下内容：
|
| 法规遵从 | 遵循与您的组织相关的合规性框架。 如需了解详情，请参阅合规性资源中心。 |
| 成本效益和控制 | 在 Google Cloud 上设计针对费用优化的基础并监控您的费用。 如需了解详情，请参阅以下内容：
|
| API 管理 | 为您的 API 设计可扩缩的解决方案。如需了解详情，请参阅 Apigee API Management。 |
| 集群管理 | 设计遵循最佳做法的 Google Kubernetes Engine (GKE) 集群来构建可扩缩、弹性佳且可观测的服务。 详情请参阅以下内容：
|
您需要规划着陆区的设计和部署流程。您必须有正确的团队来执行任务，并使用项目管理流程。我们还建议您遵循本系列文章中介绍的技术最佳做法。
组建团队
组建一个由涉及组织中多个技术职能的人员构成的团队。该团队必须包含可以构建所有着陆区元素（包括安全性、身份、网络和操作）的人员。确定一个了解 Google Cloud 的云从业人员来指导该团队。您的团队应包含负责管理项目的成员和跟踪所取得成就的成员，还应包含负责与应用或业务所有者协作的成员。
确保所有利益相关方都参与此流程的早期阶段。这些利益相关方必须共同了解该流程的适用范围，并在项目启动时做出总体决策。
管理着陆区项目
设计和部署着陆区可能需要数周的时间，因此项目管理至关重要。确保明确定义项目目标，并将其传达给所有利益相关方，并且使各方都能收到有关任何项目变更的最新信息。定义常规检查点，并根据将操作流程和意外延迟考虑在内的现实时间表对各里程碑设定达成一致。
为了最好地与业务需求保持一致，请围绕您希望首先在 Google Cloud 中部署的用例规划初始着陆区部署。我们建议您首先部署最容易在 Google Cloud 上运行的那些工作负载（例如横向扩缩多层 Web 应用）。这些工作负载可能是新工作负载，也可能是现有工作负载。
由于着陆区是模块化的，因此初始设计应围绕迁移第一个工作负载所需的元素，稍后再计划添加其他元素。
遵循技术最佳做法
请考虑使用基础架构即代码 (IaC)，例如通过使用 Terraform 来实现该架构。IaC 可帮助您实现部署的可重复性和模块化。使用 GitOps 构建一个用于部署云基础架构更改的 CI/CD 流水线，这有助于确保您遵循内部准则并实施正确的控制措施。
设计着陆区时，请确保您和您的团队将技术方面的一些最佳做法考虑在内。如需详细了解可用的着陆区选项，请参阅本系列中的其他指南。除本系列文章之外，下表还提供了一些框架、指南和蓝图，您可以根据您的使用场景使用它们来实现最佳做法。
| 相关文档 | 说明 |
|---|---|
| Google Cloud 架构框架 | 提供了一些建议和最佳做法，可帮助架构师、开发者、管理员和其他云从业人员设计和运营安全、高效、弹性佳、高性能且经济实惠的云拓扑。 |
| 安全基础蓝图 | 从专业的角度提供了 Google Cloud 安全性方面的最佳做法，面向首席信息安全官、安全从业人员、风险管理人员或合规专员。 |
| Terraform 蓝图 | 提供了打包为 Terraform 模块并可用于为 Google Cloud 创建资源的蓝图和模块的列表。 |
着陆区设置帮助
Google Cloud 提供以下选项来帮助您设置着陆区：
Google Cloud 合作伙伴
Google Cloud 专业服务
Google Cloud 第一个工作负载迁移计划
使用 Cloud 控制台中的云基础设置指南的自助方法
所有这些产品都提供经过专门设计的方法，以满足全球不同行业和业务规模的需求。为了帮助您选择最适合您的使用场景的方法，我们建议您与 Google Cloud 客户支持团队一起进行选择，以确保项目成功执行。
文章信息
相关推荐
