此参考体系结构演示如何使用 Linux 上适用于数据层的 Apache Cassandra 部署为 N 层应用程序配置的虚拟机 (VM) 和虚拟网络。
体系结构
下载此体系结构的 Visio 文件。
工作流
该体系结构具有以下组件。
常规
资源组。 资源组用于对 Azure 资源进行分组，以便可以按生存期、所有者或其他条件对其进行管理。
可用性区域。 可用性区域是 Azure 区域中的物理位置。 每个区域由一个或多个具有独立电源、冷却和网络的数据中心组成。 通过跨区域放置 VM，应用程序可复原区域内的故障。
网络和负载均衡
虚拟网络和子网。 每个 Azure VM 都会部署到可细分为子网的虚拟网络中。 为每个层创建一个单独的子网。
应用程序网关。 应用程序网关是 7 层负载均衡器。 在此体系结构中，它将 HTTP 请求路由到 Web 前端。 应用程序网关还提供一个 Web 应用程序防火墙 (WAF)，出现常见的漏洞和攻击时，WAF 可以保护应用程序。
负载均衡器。 请使用 Azure 标准负载均衡器将网络流量从 Web 层分配到业务层。
网络安全组 (NSG)。 请使用 NSG 限制虚拟网络内的网络流量。 例如，在此处显示的三层体系结构中，数据库层不接受来自 Web 前端的流量，仅接受来自业务层和管理子网的流量。
DDoS 防护。 尽管 Azure 平台提供基本的保护来防范分布式拒绝服务 (DDoS) 攻击，但我们建议使用 Azure DDoS 网络保护，它提供增强的 DDoS 缓解功能。 请参阅安全注意事项。
Azure DNS。 Azure DNS 是 DNS 域的托管服务。 它使用 Microsoft Azure 基础结构提供名称解析。 通过在 Azure 中托管域，可以使用与其他 Azure 服务相同的凭据、API、工具和计费来管理 DNS 记录。
虚拟机
Apache Cassandra 数据库。 通过启用复制和故障转移，在数据层提供高可用性。
OpsCenter。 部署监视解决方案（例如 DataStax OpsCenter）来监视 Cassandra 群集。
Jump box。 也称为守护主机。 网络上的一个安全 VM，管理员使用它来连接到其他 VM。 跳转盒中的某个 NSG 只允许来自安全列表中的公共 IP 地址的远程流量。 该 NSG 应允许远程桌面协议 (RDP) 流量。
建议
你的要求可能不同于此处描述的体系结构。 请使用以下建议作为入手点。
虚拟机
有关配置 VM 的建议，请参阅在 Azure 上运行 Linux VM。
虚拟网络
创建虚拟网络时，请确定每个子网中的资源需要多少 IP 地址。 使用[无类别域际路由选择 (CIDR)] 表示法为所需的 IP 地址指定子网掩码和足够大的网络地址范围。 使用标准专用 IP 地址块内的一个地址空间，这些地址块为 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16。
如果以后需要在虚拟网络与本地网络之间设置一个网关，请选择一个不与本地网络重叠的地址范围。 在创建虚拟网络后，将无法更改地址范围。
在设计子网时一定要牢记功能和安全要求。 同一层或同一角色中的所有 VM 应当置于同一子网，这可能是一个安全边界。 有关设计 VNet 和子网的详细信息，请参阅规划和设计 Azure 虚拟网络。
应用程序网关
有关配置应用程序网关的信息，请参阅应用程序网关配置概述。
负载均衡器
不要直接向 Internet 公开 VM。 应该为每个 VM 提供专用 IP 地址。 客户端使用与应用程序网关相关联的 IP 地址进行连接。
定义用于将网络流量定向到 VM 的负载均衡器规则。 例如，要启用 HTTP 流量，请创建将前端配置中的端口 80 映射到后端地址池上的端口 80 的规则。 当客户端将 HTTP 请求发送到端口 80 时，负载均衡器会通过使用包括源 IP 地址的哈希算法选择后端 IP 地址。 客户端请求将在所有 VM 之间分配。
网络安全组
使用 NSG 规则限制各个层之间的流量。 例如，在上面显示的三层体系结构中，Web 层不直接与数据库层进行通信。 为强制实现此目的，数据库层应当阻止来自 Web 层子网的传入流量。
- 拒绝来自虚拟网络的所有入站流量。 （在规则中使用
VIRTUAL_NETWORK标记。） - 允许来自业务层子网的入站流量。
- 允许来自数据库层子网本身的入站流量。 此规则允许在数据库 VM 之间通信，这是进行数据库复制和故障转移所必需的。
- 允许来自 Jumpbox 子网的 SSH 流量（端口 22）。 此规则允许管理员从 jumpbox 连接到数据库层。
创建优先级比第一项规则更高的规则 2 - 4，以便替代第一项规则。
Cassandra
我们建议将 DataStax Enterprise 用于生产用途，但这些建议适用于任何 Cassandra 版本。 有关在 Azure 中运行 DataStax 的详细信息，请参阅适用于 Azure 的 DataStax Enterprise 部署指南。
以机架感知模式配置节点。 将故障域映射到 cassandra-rackdc.properties 文件中的机架。
群集前面不需要负载均衡器。 客户端会直接连接到群集中的节点。
此体系结构的部署脚本使用名称解析将群集内通信 (gossip) 的种子节点初始化。 要启用名称解析，部署会创建包含 Cassandra 节点 A 记录的 Azure 专用 DNS 区域。 根据初始化脚本，你或许可以改用静态 IP 地址。
注意
Azure 专用 DNS 当前为公共预览版。
Jumpbox
不允许 SSH 从公共 Internet 访问运行应用程序工作负载的 VM。 相反，对这些 VM 的所有 SSH 访问都必须通过 jumpbox 进行。 管理员登录到 jumpbox，然后从 jumpbox 登录到其他 VM。 Jumpbox 允许来自 Internet 的 SSH 流量，但仅允许来自已知的安全 IP 地址的流量。
Jumpbox 的性能要求非常低，因此请选择一个较小的 VM 大小。 为 jumpbox 创建一个公共 IP 地址。 将 Jumpbox 放置在与其他 VM 相同的虚拟网络中，但将其置于一个单独的管理子网中。
要确保 Jumpbox 的安全，请添加一项 NSG 规则，仅允许来自一组安全的公共 IP 地址的 SSH 连接。 为其他子网配置 NSG 以允许来自管理子网的 SSH 流量。
注意事项
可伸缩性
规模集
对于 Web 和业务层，请考虑使用虚拟机规模集，而不要在可用性集中部署独立的 VM。 使用规模集可以轻松部署和管理一组相同的 VM 并根据性能指标自动缩放 VM。 VM 上的负载增加时，会自动向负载均衡器添加更多 VM。
有两种基本方法可用来配置规模集中部署的 VM：
在部署 VM 后使用扩展对其进行配置。 使用此方法时，启动新 VM 实例的所需时间可能会长于启动不带扩展的 VM 的所需时间。
使用自定义磁盘映像部署托管磁盘。 此选项的部署速度可能更快。 但是，它要求将映像保持最新。
有关详细信息，请参阅规模集的设计注意事项。
提示
在使用任何自动缩放解决方案时，请早早提前使用生产级工作负荷测试它。
订阅限制
每个 Azure 订阅都有适用的默认限制，包括每个区域的最大 VM 数量。 可以通过提出支持请求来提高上限。 有关详细信息，请参阅 Azure 订阅和服务限制、配额与约束。
应用程序网关
应用程序网关支持固定容量模式或自动缩放模式。 固定容量模式对具有一致性和可预测工作负荷的方案非常有用。 请考虑对具有可变流量的工作负载使用自动缩放模式。 有关详细信息，请参阅自动缩放和区域冗余应用程序网关 v2。
性能效率
要在 Azure VM 上的 Cassandra 中获取最佳性能，请参阅在 Azure VM 上运行 Apache Cassandra 中的建议。
可用性
可用性区域在单个区域中提供最佳复原能力。 如果需要更高的可用性，请考虑跨两个区域复制应用程序。
并非所有区域都支持可用性区域，也并非所有区域都支持所有 VM 大小。 运行以下 Azure CLI 命令，查找区域内每个 VM 大小支持的区域：
az vm list-skus --resource-type virtualMachines --zone false --location <location> \
--query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table
如果将此体系结构部署到不支持可用性区域的区域，请将每层的 VM 放在一个可用性集中。 具有同一可用性的 VM 能跨多个物理服务器、计算机架、存储单元和网络交换机进行部署，可实现冗余。 规模集自动使用充当隐式可用性集的位置组。
当部署到可用性区域时，请使用 Azure 负载均衡器的标准 SKU 和应用程序网关的 v2 SKU。 这些 SKU 支持跨区域冗余。 有关详细信息，请参阅：
单个应用程序网关部署可以运行多个网关实例。 对于生产工作负载，至少运行两个实例。
Cassandra 群集
对于 Cassandra 群集，故障转移方案取决于应用程序使用的一致性级别以及副本数目。 有关 Cassandra 中一致性级别和使用情况的信息，请参阅配置数据一致性和 Cassandra：有多少节点与 Quorum 通信？Cassandra 中的数据可用性取决于应用程序使用的一致性级别和复制机制。 有关 Cassandra 中的复制，请参阅 NoSQL 数据库的数据复制说明。
运行状况探测
应用程序网关和负载均衡器都使用运行状况探测来监视 VM 实例的可用性。
- 应用程序网关始终使用 HTTP 探测。
- 负载均衡器可以测试 HTTP 或 TCP。 通常，如果 VM 运行 HTTP 服务器，请使用 HTTP 探测。 否则使用 TCP。
如果探测在超时期限内无法到达实例，网关或负载均衡器将停止向该 VM 发送流量。 如果该 VM 再次可用，探测将继续检查，并将 VM 返回到后端池。
HTTP 探测将 HTTP GET 请求发送到指定路径并侦听 HTTP 200 响应。 此路径可以是根路径 ("/")，也可以是一个运行状况监视终结点，该终结点实现某些自定义逻辑来检查应用程序运行状况。 终结点必须允许匿名 HTTP 请求。
有关运行状况探测的详细信息，请参阅：
有关设计运行状况探测终结点的注意事项，请参阅运行状况终结点监视模式。
成本优化
使用 Azure 定价计算器估算成本。 下面是一些其他注意事项。
虚拟机规模集
虚拟机规模集适用于所有 Linux VM 大小。 只需为部署的 Azure VM 以及消耗的任何其他底层基础结构资源（例如存储和网络）付费。 虚拟机规模集服务本身不收取额外费用。
有关单个 VM 定价选项的信息，请参阅 Linux VM 定价。
负载均衡器
你只需为配置的负载平衡和出站规则的数量付费。 入站网络地址转换 (NAT) 规则是免费的。 如果未配置规则，则标准负载均衡器不按小时收费。
有关详细信息，请参阅 Microsoft Azure 架构良好的框架中的“成本”部分。
安全性
虚拟网络是 Azure 中的流量隔离边界。 一个虚拟网络中的 VM 无法与另一个虚拟网络中的 VM 直接通信。 同一个虚拟网络中的 VM 之间可以通信，除非你创建网络安全组 (NSG) 来限制流量。 有关详细信息，请参阅 Microsoft 云服务和网络安全性。
对于传入 Internet 流量，负载均衡器规则定义哪些流量可以到达后端。 但是，负载均衡器规则不支持 IP 安全列表，因此如果要将某些公共 IP 地址添加到安全列表，请将 NSG 添加到子网。
外围网络。 请考虑添加一个网络虚拟设备 (NVA) 以在 Internet 与 Azure 虚拟网络之间创建一个外围网络。 NVA 是虚拟设备的一个通用术语，可以执行与网络相关的任务，例如防火墙、包检查、审核和自定义路由。 有关详细信息，请参阅在 Azure 与 Internet 之间实现外围网络。
加密。 加密静态的敏感数据并使用 Azure Key Vault 管理数据库加密密钥。 Key Vault 可以将加密密钥存储在硬件安全模块 (HSM) 中。 另外，建议将应用程序机密（例如数据库连接字符串）也存储在 Key Vault 中。
DDOS 防护。 Azure 平台默认提供基本 DDoS 保护。 这种基本保护旨在将 Azure 基础结构作为一个整体进行保护。 尽管已自动启用基本 DDoS 保护，但我们建议使用 Azure DDoS 网络保护。 网络保护基于应用程序的网络流量模式使用自适应优化来检测威胁。 这样，它便可以针对基础结构范围的 DDoS 策略忽略的 DDoS 攻击应用缓解措施。 网络保护还通过 Azure Monitor 提供警报、遥测和分析。 有关详细信息，请参阅 Azure DDoS 防护：最佳做法和参考体系结构。
卓越运营
由于所有主要资源及其依赖关系在此体系结构中都位于同一个虚拟网络中，因此它们被隔离在同一个基本工作负载中。 通过工作负荷隔离，可以更轻松地将工作负荷的特定资源关联到某个 DevOps 团队，使该团队能够独立管理这些资源的所有方面。 这种隔离可使 DevOps 团队和服务执行持续集成和持续交付 (CI/CD)。
还可以使用不同的部署模板，并将它们与 Azure DevOps Services 集成，以便在几分钟内预配不同的环境，例如仅在需要时复制生产场景或负载测试环境，从而节省成本。
在此情况下，虚拟机是使用虚拟机扩展配置的，因为它们为安装某些附加软件（如 Apache Cassandra）提供了可能性。 特别是自定义脚本扩展支持在虚拟机上下载和执行任意代码，因此能对 Azure VM 的操作系统进行无限制的自定义。 仅在 VM 创建时安装和执行 VM 扩展。 这意味着，如果操作系统在后期配置不正确，将需要手动干预才能将其恢复到正确的状态。 配置管理工具可用于解决此问题。
请考虑使用 Azure Monitor 来分析和优化基础结构的性能，在不登录到虚拟机的情况下监视和诊断网络问题。 Application Insights 实际上是 Azure Monitor 的组件之一，为你提供丰富的指标和日志来验证整个 Azure 环境的状态。 Azure Monitor 有助于跟踪基础结构状态。
确保不仅要监视支持应用程序代码的计算元素，还要监视你的数据平台，特别是数据库，因为应用程序数据层的低性能可能会产生严重后果。
为了测试运行应用程序的 Azure 环境，应采用与应用程序代码相同的机制进行版本控制和部署，然后也可以使用 DevOps 测试范例进行测试和验证。
有关详细信息，请参阅 Microsoft Azure 架构良好的框架中的卓越运营部分。