引言

一旦应用程序在云服务器环境中启动并运行,您可能想知道如何改进服务器环境,从而实现从“它可以工作”到成熟的生产环境的飞跃。 本文将通过在云服务器环境中的 web 应用程序上下文中创建一个松散的“生产”定义,并通过向您展示一些可以添加到现有体系结构中以完成转换的组件,帮助您开始规划和实现生产环境。

为了这个演示的目的,让我们假设我们从一个类似于5个公共服务器设置的设置开始,就像这个简单的服务于 web 应用的双服务器环境:

您的实际设置可能更简单或更复杂,但此处讨论的一般思想和组件应该在某种程度上适用于任何服务器环境。

让我们从定义我们所说的“生产环境”开始。

什么是生产环境?

一般来说,web 应用程序的服务器环境由硬件、软件、数据、操作计划和维持应用程序工作所必需的人员组成。 生产环境通常指的是服务器环境,它的设计和实现充分考虑了这些因素的可接受水平:

  • 可用性: 应用程序在广告时间内可供其预期用户使用的能力。 任何严重影响关键组件的故障都可能破坏可用性(例如由于 bug 导致应用程序崩溃,数据库存储设备故障,或者应用系统管理员无意中关闭了应用服务器)。

提高可用性的一种方法是减少环境中单点故障的数量。 例如,使用静态 IP 和监视故障转移服务可以确保用户只访问健康的负载平衡器。

  • 可恢复性: 在系统故障或数据丢失时恢复应用程序环境的能力。 如果一个关键组件失败,并且不可恢复,可用性将变得不存在。 提高可维护性是一个相关的概念,它减少了在发生故障时执行给定恢复过程所需的时间,因此可以在发生故障时提高可用性
  • 性能: 应用程序在平均负载或峰值负载下按预期执行(例如,它是合理响应的)。 虽然对于用户来说非常重要,但是只有当应用程序可用时,性能才是最重要的

在应用程序的上下文中,花一些时间为刚才提到的每个项目定义可接受的级别。 这取决于有关应用程序的重要性和性质。 例如,只要博客可以恢复,个人博客服务很少的访问者遭受偶尔的停机或糟糕的表现可能是可以接受的,但公司的在线商店应该争取非常高的评分全面。 当然,对于每个应用程序,在每个类别中实现100% 是很好的,但是由于时间和资金的限制,这通常是不可行的。

请注意,我们没有提到(a)硬件可靠性,给定的硬件组件在故障前一段时间内正常工作的概率,或(b)安全性作为因素。 这是因为我们假设(a)您正在使用的云服务器通常是可靠的,但有可能出现故障(因为它们在物理服务器上运行) ,以及(b)您正在尽可能遵循安全最佳实践ー简单地说,它们超出了本文的范围。 但是,您应该知道,可靠性和安全性是可以直接影响可用性的因素,而且两者都可以满足可恢复性的需要。

由于每个应用程序的不同需求和性质,我们不会一步一步地向您展示创建生产环境的过程,而是提供一些有形的组件,可以利用这些组件将您的现有设置转换为生产环境。

让我们来看看这些组件!

1. 备份系统

备份系统将允许您定期创建数据备份,并从备份中恢复数据。 备份还允许在意外删除或意外修改时将数据回滚到以前的状态,这可能由于包括人为错误在内的各种原因而发生。 所有的计算机硬件都有可能在某个时间点出现故障,这可能会导致数据丢失。 考虑到这一点,您应该保持所有重要数据的最新备份。

生产需要? ? 是的。 备份系统可以减轻数据丢失的影响,这对于实现可恢复性是必要的,因此,在数据丢失的情况下有助于提供数据ー但它必须与坚实的恢复计划一起使用,下一节将对此进行讨论。 请注意,DigitalOcean 的基于快照的备份可能不足以满足您的所有备份需求,因为它不太适合对主动数据库和磁盘写入 i / o 较高的其他应用程序进行备份ー如果您运行这些类型的应用程序,或希望更大的备份调度灵活性,请务必使用另一个备份系统,如 Bacula。

上图是一个基本备份系统的例子。 备份服务器与应用程序服务器位于同一个数据中心,在这里创建初始备份。 随后,备份的非现场副本会被发送到另一个数据中心的服务器上,以确保数据在发生自然灾害时得到保存。

考虑因素

  • 备份选择: 要备份的数据。 最低限度,备份任何无法从其他来源可靠地重现的数据
  • 备份计划: 执行完整备份或增量备份的时间和频率。 对于某些类型的数据(如活动数据库)的备份,必须特别注意,这可能会影响备份计划
  • 数据保留期: 在删除备份之前保留备份的时间
  • 备份的磁盘空间: 前面三项的组合会影响备份系统所需的磁盘空间量。 利用压缩和增量备份减少备份所需的磁盘空间
  • 非现场备份: 为了保护您的备份免受本地灾难的影响,在特定的数据中心中,最好将备份的副本保存在一个地理位置不同的位置。 在上图中,NYC3的备份被复制到 SFO1中
  • 备份恢复测试: 定期测试备份恢复过程,以确保备份正常工作

相关教程

  • 如何为 VPS 选择有效的备份策略
  • 如何在 Ubuntu 14.04上安装 Bacula 服务器
  • 如何使用 Rsync 来同步 VPS 上的本地和远程目录
  • 理解 DigitalOcean 液滴备份

2. 恢复计划

恢复计划是一组用于从生产环境中的潜在故障或管理错误中进行恢复的文档化过程。 至少,您需要针对每个您认为将不可避免地发生的严重情况(如服务器硬件故障或意外数据删除)制定恢复计划。 例如,一个非常基本的服务器故障恢复计划可以包含执行初始服务器部署的步骤列表,以及从备份恢复应用程序数据的额外步骤。 一个更好的恢复计划,除了好的文档之外,还可以利用部署脚本和组态管理工具,如 Ansible、 Chef 或 Puppet,来帮助自动化和加快恢复过程。

生产需要? ? 是的。 尽管恢复计划在服务器环境中并不作为软件存在,但它们是生产设置的必要组件。 它们使您能够有效地利用备份,并为重建环境或在需要时回滚到所需状态提供蓝图。

上图是故障数据库服务器的恢复计划的概述。 在这种情况下,数据库服务器将被安装了相同软件的新服务器取代,最后一个良好的备份将用于恢复服务器配置和数据。 最后,应用程序服务器将配置为使用新的数据库服务器。

考虑因素

  • 过程文档: 在故障事件中应该遵循的一组文档。 一个好的起点是构建一个逐步的文档,您可以按照这个文档重新构建一个失败的服务器,然后添加从备份恢复各种应用程序数据和配置的步骤
  • 自动化工具: 脚本和组态管理软件提供自动化,这可以改善部署和恢复过程。 虽然逐步指南通常足以简单地从故障中恢复,但它们必须由一个人执行,因此不像自动化过程那样快或一致
  • 关键组件: 应用程序正常运行所必需的组件。 在上面的示例中,应用程序和数据库服务器都是关键组件,因为如果其中一个失败,应用程序将变得不可用
  • 单点故障: 没有自动故障转移机制的关键组件被认为是单点故障。 您应该尽最大努力消除单点故障,以提高可用性
  • 修订: 随着部署和恢复过程的改进,更新文档

3. 负载平衡

可以将负载平衡添加到服务器环境中,以通过跨多个服务器分布工作负载来提高性能和可用性。 如果负载平衡的服务器之一发生故障,其他服务器将处理传入的流量,直到故障的服务器恢复正常。 在云服务器环境中,负载均衡通常可以通过添加一个负载均衡器服务器来实现,该服务器在运行应用程序特定组件的多个服务器前运行负载均衡器(反向代理)软件。

生产需要? ? 不一定。 在生产环境中并不总是需要负载平衡,但是如果实现正确,它可以成为减少系统中单点故障的有效方法。 它还可以通过水平扩展增加更多的容量来提高性能。

上面的图表增加了一个额外的应用程序服务器来共享负载,以及一个负载均衡器来跨两个应用程序服务器分散用户请求。 如果单个应用程序服务器难以跟上流量,这种设置可以帮助提高性能,而且如果其中一个应用程序服务器出现故障,它还可以帮助保持应用程序可用。 但是,在数据库服务器和负载均衡器服务器本身中,它仍然有两个单点故障。

注意: DigitalOcean 负载均衡器是一个完全管理的、高可用的负载均衡服务。 如果您正在 DigitalOcean 上运行应用程序,那么负载均衡器服务可能非常适合您的环境。

考虑因素

  • 负载均衡组件: 并非环境中的所有组件都能轻松地进行负载均衡。 必须特别考虑某些类型的软件,如数据库或有状态的应用程序
  • 应用程序数据复制: 如果负载均衡的应用程序服务器在本地存储应用程序数据,例如上传的文件,那么这些数据必须通过复制或共享文件系统等方法提供给其他应用程序服务器。 这对于确保无论选择哪个应用程序服务器来服务用户请求,应用程序数据都是可用的是必要的
  • 性能瓶颈: 如果负载均衡器没有足够的资源或者配置不当,实际上会降低应用程序的性能
  • 单点故障: 虽然负载平衡可以用来消除单点故障,但计划不周的负载平衡实际上会增加更多单点故障。 负载均衡是通过包含第二个负载均衡器来增强的,该负载均衡器在根据可用性将流量发送到其中一个负载对的前面有一个静态 IP。

相关教程

  • Haproxy 和负载平衡概念介绍
  • 如何在 Ubuntu 14.04上使用 HAProxy 实现 SSL 终止
  • 如何在 Ubuntu 14.04上使用 HAProxy 作为 WordPress 和 Nginx 的第七层负载平衡器
  • 理解 Nginx HTTP 代理、负载平衡、缓冲和缓存
  • 如何创建你的第一个数字式负载平衡器
  • 如何使用浮动 ip

4. 监控

监视可以通过跟踪服务的状态和服务器资源利用的趋势来支持服务器环境,从而提供对环境的极大可见性。 监视系统的最大好处之一是,当服务或服务器出现故障,或者某个资源(如 CPU、内存或存储)过度使用时,可以将它们配置为触发一个动作,例如运行脚本或发送通知。 这些通知使您能够在任何问题发生时立即作出反应,从而有助于最小化或防止应用程序停机。

生产需要? ? 不一定,但是随着生产环境的规模和复杂性的增加,对监控的需求也会增加。 它提供了一种简单的方法来跟踪关键服务和服务器资源。 反过来,监视可以提高恢复性,并为设置的规划和维护提供信息。

上图是一个监控系统的例子。 通常,监视服务器将从运行在应用程序和数据库服务器上的代理软件请求状态数据,每个代理将响应软件和硬件状态信息。 然后,系统管理员可以使用监视控制台查看应用程序的总体状态,并根据需要深入到更详细的信息。

考虑因素

  • 监视服务: 您将监视的服务和软件。 至少,您应该监视所有需要处于健康运行状态的服务的状态,以便您的应用程序正常运行
  • 监视资源: 您将监视的资源。 资源的示例包括 CPU、内存、存储和网络利用率,以及整个服务器的状态
  • 数据保留: 在丢弃监视数据之前保留监视数据的时间段。 这将影响监视系统所需的磁盘空间量,同时还会影响要监视的项目的选择
  • 问题检测规则: 确定服务或资源是否处于 OK 状态的阈值和规则。 例如,如果一个服务或服务器正在运行和服务请求,那么它可能被认为是健康的,而如果资源(如存储)的利用率在一定时间内达到某个阈值,则可能触发警告
  • 通知规则: 确定是否应该发送通知的阈值和规则。 虽然通知很重要,但同样重要的是调整你的通知规则,这样你就不会收到太多的通知; 一个装满警告和提醒的收件箱经常会被忽略,使它们几乎和没有通知一样无用

相关教程

  • 如何在 Ubuntu 14.04上安装 Nagios 4并监控你的服务器
  • 如何在 Ubuntu 14.04上使用 Icinga 来监视你的服务器和服务
  • 如何在 Ubuntu 上安装 Zabbix 并配置它来监视多个 VPS 服务器
  • 使用 SNMP 监视和管理网络
  • 如何在 Ubuntu 14.04上配置 Sensu Monitoring、 RabbitMQ 和 Redis

5. 集中式日志记录

集中式日志记录可以通过提供查看和搜索日志的简单方法支持服务器环境,这些日志通常存储在跨整个环境的单个服务器上的一个地方。 除了不必登录到单独的服务器来读取日志的便利之外,集中式日志记录还允许您通过在特定的时间框架内关联多个服务器的日志和指标,轻松识别跨多个服务器的问题。 它还在日志保留方面提供了更大的灵活性,因为本地日志可以从应用服务器卸载到具有自己独立存储的集中式日志服务器。

生产需要? ? 不,但是与监视一样,集中式日志记录可以提供对服务器环境的宝贵洞察力,因为服务器环境的规模和复杂性在不断增长。 除了比传统的日志记录更方便之外,它还使您能够以更高的可见性快速审计服务器日志。

上图是集中式日志记录系统的一个简化示例。 在每个服务器上安装一个日志传送代理,并将其配置为将重要的应用程序和数据库日志发送到集中的日志服务器。 然后,系统管理员可以从单个控制台查看、筛选和搜索所有重要日志。

考虑因素

  • 要收集的日志: 将从服务器发送到集中日志服务器的特定日志。 您应该从所有服务器收集重要的日志
  • 数据保留: 在丢弃日志之前保留日志的时间段。 这将影响集中式日志记录系统所需的磁盘空间量,同时还会影响要收集的日志的选择
  • 日志过滤器: 将普通日志解析为结构化日志数据的过滤器。 过滤日志将提高您以有意义的方式查询、分析和绘制数据图形的能力
  • 服务器时钟: 确保服务器的时钟是同步的,并且设置为相同的时区,这样您的日志时间线在整个环境中都是准确的

相关教程

  • 如何在 Ubuntu 14.04上安装 Elasticsearch、 Logstash 和 Kibana 4
  • 如何使用数字笔记本 ELK 堆栈一键式应用
  • 服务器跟踪统计介绍
  • 如何在 Ubuntu 14.04上安装 Graylog2和集中日志

总结

当您将所有组件放在一起时,您的生产环境可能是这样的:

既然您已经熟悉了可用于支持和改进生产服务器设置的组件,那么您应该考虑如何将它们集成到您自己的服务器环境中。 当然,我们没有涵盖所有的可能性,但是这应该给你一个从哪里开始的想法。 请记住,要基于可用资源和自己的生产目标的平衡来设计和实现服务器环境。

如果您有兴趣设置类似上面的环境,请参阅本教程: 构建生产环境: Web 应用程序。