Azure 建议

针对 Azure 的建议

生产就绪群集配置

这些建议的依据是多年来多个 DC/OS 群集的运行，以及在实时生产负载下扩展有状态和无状态服务的组合等经验。您的服务组合可能执行方式不同，但本文讨论的原则和经验仍然适用。

通用机器配置

我们建议在 VM 上禁用交换，这通常是 Azure Linux 图像的默认设置。我们发现，使用临时固态硬盘进行交换（通过 WAAgent 配置）可能会与 D 系列 VM 的磁盘缓存配置发生冲突。其他 VM 系列（如 L 系列）可以使用固态硬盘进行交换和其他用途。

有关磁盘配置的详细信息，请参阅以下部分。应使用监控（例如，带有 Prometheus 的 Node Exporter）识别和警告工作负载接近 Azure 定义的限制范围。

网络

Azure 上的原始网络性能大致由 VM 大小决定。具有 8 个或更多内核的 VM（如 Standard_D8_v3）可用于 Azure 加速网络 (SR-IOV). 使用 SR-IOV，而不是依靠 Azure 虚拟机管理程序 vswitch，延迟更低、可用性更高且带宽更稳定。例如，在我们的测试中，不使用 SR-IOV 的 Standard_D16s_v3 可以在两个虚拟机之间推送大约 450MB/s 的数据，而相同大小的机器在使用 SR-IOV 后，可推送将近 1000MB/s 的数据。因此，应尽可能部署 SR-IOV，并且应对实例大小进行基准测试（例如，使用 iperf3），确保满足您的网络要求。

另外，虽然每个虚拟机都支持多个 NIC，但是带宽取决于 VM，而不是 NIC。因此，将网络分割为控制和数据板块（或其他网络）可能对组织或安全目的有用，需要 Linux 级流量成形才能实现带宽控制。

磁盘配置

为了在 Azure 上实现高性能的可靠群集操作，建议使用具有特定磁盘配置的优质固态硬盘。托管磁盘 (MD) 比非托管磁盘 (UMD) 更能避免存储帐户限制：Azure fabric 将适当地放置托管磁盘，以满足保证的 SLA 要求。UMD 的存储帐户限制已记录在 此处.

在 Azure 上，优质固态硬盘具有有限数量的同步 IOP，可能受底层磁盘结构延迟的限制。etcd，Zookeeper 和使用预写式日志 (WAL) 的数据库等服务对此 I/O 配置特别敏感。因此，本文所述的大部分系统工程都集中探讨如何尽量减少和/或消除 Azure 磁盘上的 I/O 争用。另外，超过机器上的 I/O 分配会导致限流。可在 [揭秘 Azure VM 存储性能和限流] 上学习本文章。(https://blogs.technet.microsoft.com/xiangwu/2017/05/14/azure-vm-storage-performance-and-throttling-demystify/) 详细了解本文所提供建议的理论背景。

鉴于需要与异步 I/O 负载分离同步以维持性能，我们推荐以下磁盘安装配置：

  • 管理节点：
    • / - P10
    • /var/lib/etcd -（用于在 CorEos 上运行 etcd 的节点） - P10
    • /var/log - P10
    • /var/lib/dcos/exhibitor - P10
  • 公共代理：
    • / - P10
    • /var/log - P10
    • /var/lib/docker - P10
    • /var/lib/mesos/slave - P10
  • 专用代理：
    • / - P10
    • /var/log - P10
    • /var/lib/docker - P10
    • /var/lib/mesos/slave - P20

运行磁盘较小和/或更少的群集是当然可能的，但在生产中的使用证明，上述配置已经对任何非极小型大小的群集都具有重大优势。此外，我们建议使用 Mesos MOUNT 磁盘资源，将适当的高级固态硬盘安装到 /dcos/volume0 ... /dcos/volumeN ，可在之后专门用于数据密集型服务，而不会导致 I/O 争用。对于 postgres 或 mysql 等数据密集型服务，应考虑将 LVM RAID 条带连接到这些 MOUNT 资源，以增加每秒数据库的可能处理量。

关于配置磁盘缓存，请遵守以下一般规则：

  • 操作系统磁盘应设置为 ReadWrite.
  • 具有混合或读取重负载（数据库大宗存储等）的数据磁盘应设置为 ReadOnly.
  • 具有高顺序写入负载的数据磁盘（WAL 磁盘）应设置为 None.