Data Center 升级指南
世界上没有完全一样的组织，不可生搬硬套其他组织的迁移之旅。请遵循我们的分步升级指南，确保从 Atlassian Server 顺利过渡到 Data Center。
评估
每个组织的需求和要求各有不同，因此您务必要了解自己的选择，以进行成功的升级规划。
了解您的架构和基础架构要求
是否决定使用 Data Center？您需要了解所支持的 Data Center 架构和部署配置。
Data Center 可通过两种不同方式进行部署，分别为：非集群方式和集群方式。两种方式均支持您使用企业功能，但两者之间要考虑的问题各有不同。下表列出了非集群架构和集群架构之间的区别：
非集群 推荐
基础设施要求
非集群体系结构支持您基于现有基础架构升级到 Data Center，使您无需对基础架构进行任何变更。
推荐用例
我们建议所有客户使用非集群升级路径升级到 Data Center。如果需要，客户可以在升级到 Data Center 后实施集群体系结构。
优势
非集群升级通常是许多客户开始他们的 Data Center 之旅的地方。我们建议您利用这 2 分钟的升级来确保平稳过渡。
集群
我们建议所有客户首先使用非集群升级路径升级到 Data Center。成功升级 Data Center 后，客户可以在需要时实施集群体系结构。
基础设施要求
在集群中需要有以下组件才能升级到 Data Center：
- 负载均衡器
- 应用节点
- 所有应用节点都可访问的文件系统
- ElasticSearch 节点 (Bitbucket)
推荐用例
- 您需要高可用性
- 您想要在不停机的情况下升级
- 您期望短期内发展到超大规模。
优势
解锁集群可以提供的 Enterprise 功能：
- Enterprise 功能和能力
- 高可用性和故障转移——如果您的应用集群中的一个节点发生故障，其他节点将承担更多负荷，确保您的用户能够无间断访问产品。
- 即时可扩展性——无需停机或增加许可证费用即可在集群中添加新的节点。索引和应用可自动同步。
- 灾难恢复——部署离线灾难恢复系统，即使整个系统中断，仍可保持业务连续性。共享产品索引方便您快速重新运行。
规划和准备
现在，您已经选择了 Data Center 路径，并已准备好开始制定详细的升级计划。
制定时间表 必要
您可以参考下面的基本时间线来衡量您的升级时间。
| | 非集群 | 集群 |
|---|---|---|
| 规划 | 非集群 0–2 周 | 集群 1 个月以上 |
| 试运行 | 非集群 0–1 周 | 集群 3–6 个月 |
| 线上推出 | 非集群 0–1 周 | 集群 大约 6–9 个月 |
此处所列的时间线是基于已成功升级到 Data Center 的许多客户推断得出的，但需要注意的是，实际时间线将根据您环境的特有因素而变化，其中包括但不限于环境规模、复杂性和准备情况。
定义您的 Data Center 环境 必要
应用层
实例和位置
- 是否想要联合或整合您的实例？
- 您未来的增长情况会如何？
- 是否需要隔离任何数据？
- 您的团队有多少个环境，例如预备或生产环境？
实例配置文件
- 将有多少人访问您的实例？
- 您的团队将在何处？
- 您的实例中当前有多少数据，您计划向您的实例添加多少数据？
应用、集成和自定义
您是需要它们全部，还是借此进行简化？
基础架构层
实例规模调整
- 您对未来增长有何预测？
- 您是否遇到过用户流量较低的情况？
有关更多信息，请参阅此处的节点规模调整概述。
帐户结构
- 您的环境应部署在哪些帐户下？
- 您是否希望将不同的帐户与您的每个环境相关联？
- 您是否希望 Data Center 产品与其他 CI/CD 或协作工具共用同一帐户？
治理模型
- 您的治理模型是什么样的？
- 您的最低系统标准是什么？
- 您是否在使用集中日志记录？
- 您的用户管理需求是什么？
考虑将 AWS 登陆区和 AWS System Manager 用作治理模型的一部分。
VPC
-
是否要使用新的虚拟私有云 (VPC)？
无论您是想在新 VPC 中部署，还是想使用现有的 VPC，您都可以利用 Atlassian Standard Infrastructure (ASI) 模板。
- 是否存在您想要更改的网络原则，例如：限制办公室和 VPN 网络路由的公共互联网访问和内部 IP 寻址？
- 是否应该使用 TLS 证书？
地理位置
-
如果使用现有的 VPC，您是否制定了办公室和 VPN 网络访问计划？
我们建议您允许从所有办公室和 VPN 进行访问，因为您的产品使用量很可能会随着时间的推移而增长。
Direct Connect
- 您想使用 Direct Connect 来提高性能和安全性吗？
- 您需要从 Server 实例迁移多少数据至 Data Center？
如果您想要移动大量数据，可能还需要考虑使用 AWS Snow Family 资源。
业务持续性与灾难恢复
备份
您的备份策略是什么？
我们建议您结合使用 AWS 中内置的现有备份策略和备份功能。有关更多信息，请参阅：
AWS 提供的基础架构服务不太容易出现单次中断。
区域故障转移
您是否需要在不同地区实现冷、暖或热站点？
通常，可以通过在多个可用区域中运行服务来满足您的灾难恢复需求，但是您可能还想减少区域中断事件。在决定是否要在不同地区实施这些站点时，请考虑以下内容：
- 基础架构和数据传输的成本
- 恢复速度与 AWS
- 维护和测试恢复站点所花费的时间
- 站点运行成本
升级到 Data Center（非集群式） 推荐
我们建议所有客户使用非集群体系结构升级到 Data Center。非集群升级是一种更快、更简化的升级选项，可更快地访问 Data Center 的安全、支持和企业功能。
升级到 Data Center（集群式） 不推荐
由于升级的复杂性，我们不建议从一开始就在集群体系结构上升级到 Data Center。我们建议所有客户首先使用非集群升级路径升级到 Data Center。之后，需要集群体系结构的客户可以开始实施。
在非集群体系结构上升级到 Data Center 后，如果您需要高可用性，则可以实施集群体系结构。
获得您的集群所需要的基础设施
要在集群中部署 Data Center，您需要获得以下组件：
- 数据库
- 负载均衡器
- 应用节点
- 共享文件系统
- ElasticSearch 节点 (Bitbucket)
负载均衡器
如果您已在集群中部署，则您的用户请求首先接触的便是负载均衡器。用户请求进入负载均衡器后，负载均衡器会将每个请求分散至应用节点。您可以使用硬件负载均衡器，也可以使用基于软件的负载均衡器。无论是硬件负载均衡器还是软件负载均衡器，均应使用高速 LAN 连接到应用集群，以确保高带宽和低延迟。所有软件负载均衡器应在专用机器上运行。
Data Center 产品假设在一个会话中，每个用户请求均会转到同一节点。如果请求转到了不同节点，用户可能会意外退出，甚至会丢失存储在会话中的信息。因此，需要通过在负载均衡器上启用基于 Cookie 的“粘性会话”（或会话亲缘性），将会话绑定到同一节点。在使用基于 Cookie 的粘性会话时，可以使用产品发出的 Cookie，也可以使用负载均衡器生成的 Cookie。
通过向负载均衡解决方案添加冗余来增加额外保护层，防止负载均衡器造成单点故障。为此，您可以通过在主动-被动配置中设置两个负载均衡器，并在两个负载均衡器之间使用一个虚拟 IP 地址。如果主动负载均衡器发生故障，故障会被转入被动负载均衡器。
有关更多信息，请参阅负载均衡器配置选项。
应用节点
应用节点指实际产品所在位置。您的 Data Center 集群中的所有节点均须在相同版本的产品上运行，且应放置在一起，以最大限度减少延迟。但您可以启用内容交付网络 (CDN) 来为您分布在各地的团队提供性能支持。这些节点应配置到一个集群中，并作为一个整体来为您的用户提供产品服务。您的集群中的节点数量取决于您的需求和您配置产品的方式。通常情况下，我们发现对于大部分集群来说，2-4 个节点就已足够。您可参考我们的节点规模调整指南，以帮助您做出正确的决策。
Bitbucket 需要一个额外的应用节点，专门用于 ElasticSearch，从而实现代码搜索。
共享文件系统
共享文件系统是指可从任意应用节点都可访问的数据存储位置，例如：附加文件和 Git 存储库。
在 Data Center 环境中，您需要将共享文件系统设置为其自己的节点。您可将任何基于 NFS 的 NAS 或 SAN 程序用作您的共享文件系统，但我们建议使用 NFS3 来维持您的性能。只是不可使用 DFS 等分布式协议，因为这些协议不受支持。
创建暂存环境
为了成功升级到多节点，我们建议在投入生产环境之前，先创建一个预演环境来试用 Data Center。
您的暂存环境应基本复制您的生产环境，包括所有反向代理、SSL 配置或负载均衡器。您可以决定使用不同的物理服务器或虚拟化解决方案。其中的关键在于确保该暂存环境是您生产环境的适当副本。
与专家对话
对迁移选项或路径有疑问？从我们的迁移专家团队那获取专家指导。