5种方法来改善你的生产Web应用程序服务器设置
2015-02-11
分类：系统运维
阅读()
评论()
介绍
一旦您的应用程序在云服务器环境中启动并运行，您可能会想知道如何改进您的服务器环境，使其从“正常运行”飞跃到完整的生产环境。本文将帮助您开始规划和实现生产环境，方法是在云服务器环境中的Web应用程序的上下文中创建“生产”的宽松定义，并显示一些可添加到现有架构使转型。 出于演示的目的，让我们假设我们开始类似一个中描述的设置
5个通用服务器设置 ，这样只需提供一个Web应用程序这两个服务器环境：
您的实际安装可能更简单或更复杂，但在此讨论的一般想法和组件应适用于任何服务器环境在一定程度上。 让我们开始定义当我们说“生产环境”时我们的意思。
什么是生产环境？
在一般意义上，用于web应用的服务器环境包括保持应用工作所需的硬件，软件，数据，操作计划和人员。生产环境通常指的是设计和实施的服务器环境，其中考虑了这些因素的可接受水平：
- 可用性 ：在公布的时间是由它的预定用户可用的能力，为应用程序。可用性可能会由于严重影响关键组件的任何故障（例如，由于错误，数据库存储设备故障或系统管理员意外关闭应用程序服务器而导致应用程序崩溃）中断。
促进可用性的一种方法是减少环境中的
单点故障的数量。 例如，使用静态IP和监控故障切换服务，确保用户只能访问健康负载balancers.To了解更多信息，请参阅
如何使用浮动IP地址本节中 ，这
条负载均衡 。
- 可恢复 ：在系统故障或数据丢失的情况下恢复的应用程序环境的能力。 如果关键组件出现故障，并且无法恢复，则可用性将不存在。 提高可维护性 ，一个相关的概念，减少了在发生故障的情况下，执行一个给定的恢复过程所需要的时间，因此，可以在发生故障的情况下，提高可用性
- 性能 ：应用程序执行平均值或峰值负载下预期（例如，它是合理的响应）。虽然对您的用户非常重要，但只有在应用程序可用时，性能才有意义
花一些时间在应用程序的上下文中为上面提到的每个项目定义可接受的级别。这将根据所讨论的应用的重要性和性质而变化。例如，只要博客可以恢复，但是公司的在线商店应该争取非常高的标记，那么为少数访问者服务的个人博客可能会偶尔遇到停机时间或性能不佳。当然，在每个类别中实现100％是很好的，对于每个应用程序，但由于时间和金钱的限制，这通常是不可行的。 注意，我们没有提到（a）硬件可靠性，给定硬件组件将在故障前的指定时间内正常工作的概率，或（b）安全性作为因素。这是因为我们假设（a）您使用的云服务器通常可靠，但有潜在的故障（因为它们在物理服务器上运行），以及（b）您正在使用最佳的能力的安全最佳实践，简单地说，它们超出了本文的范围。但是，您应该意识到，可靠性和安全性是可以直接影响可用性的因素，并且两者都可以促进可恢复性的需要。 我们将展示一些可用于将现有设置转换为生产环境的有形组件，而不是向您展示创建生产环境的逐步过程，这是不可能的，因为每个应用程序的不同需求和性质。 让我们来看看组件！
备份系统
备份系统将允许您创建数据的定期备份，并从备份还原数据。备份还允许在数据中的回滚，到以前的状态，在意外删除或不期望的修改的情况下，可能由于各种原因，包括人为错误发生。所有计算机硬件在某个时间点都有失败的机会，这可能会导致数据丢失。考虑到这一点，您应该保留所有重要数据的最近备份。
生产所需？是
的 。 备份系统可以减轻数据丢失，这是必要的实现可恢复，因此，辅助可用性数据的事件的影响损失，但它必须在用固体
恢复计划 ，这是在下一节讨论一起使用。请注意，DigitalOcean的基于快照的备份可能不足以满足您的所有备份需求，因为它不适合备份活动数据库和其他具有高磁盘写入I / O的应用程序 - 如果您运行这些类型的应用程序，或者想要更多的备份调度灵活性，一定要使用另一个备份系统，如Bacula。
上图是基本备份系统的示例。备份服务器驻留在与应用程序服务器相同的数据中心，在那里创建初始备份。随后，将备份的异地副本发送到不同数据中心中的服务器，以确保在例如自然灾害的情况下保存数据。
注意事项
- 备份选择：你将备份的数据。最低限度地，备份您无法从备用源可靠地再现的任何数据
- 备份计划：何时以及如何频繁，您将执行完全备份或增量备份。必须对某些类型的数据（例如活动数据库）进行备份，这可能会影响备份计划
- 数据保存期：你能维持多久备份删除前
- 对于备份磁盘空间：三个以前项目的组合影响的磁盘空间备份，系统将要求量。利用压缩和增量备份来减少备份所需的磁盘空间
- 异地备份：为保障您对当地的灾害备份，一个特定的数据中心内，最好是在地理上分开的位置，以保持您的备份副本。在上图中，为此目的将NYC3的备份复制到SFO1
- 备份恢复测试：定期测试备份还原过程，以确保您的备份正常工作
相关教程
2.恢复计划
恢复计划是一系列文档化的过程，用于从生产环境中的潜在故障或管理错误中恢复。至少，您将需要一个恢复计划，用于您认为不可避免发生的每个故障情况，例如服务器硬件故障或意外删除数据。例如，服务器故障的非常基本的恢复计划可能包括执行初始服务器部署所需的步骤列表，以及用于从备份恢复应用程序数据的额外过程。除了良好的文档，更好的恢复计划可以利用部署脚本和配置管理工具（如Ansible，Chef或Puppet）来帮助自动化和加快恢复过程。
生产所需？是
的 。虽然恢复计划不是作为服务器环境中的软件存在，但它们是生产设置的必要组件。它们使您能够有效地利用备份，并提供重建环境或在需要时回滚到所需状态的蓝图。
上图是故障数据库服务器的恢复计划的概述。在这种情况下，数据库服务器将被安装了相同软件的新的数据库服务器替换，并且最后一个完好的备份将用于恢复服务器配置和数据。最后，应用服务器将被配置为使用新的数据库服务器。
注意事项
- 程序文档：本文档集应遵循的故障事件。一个好的起点是构建一个一步一步的文档，您可以按照该文档重建失败的服务器，然后添加从备份还原各种应用程序数据和配置的步骤
- 自动化工具：脚本和配置管理软件提供自动化，从而可以提高部署和恢复过程。虽然逐步指南通常足以简单地从故障中恢复，但是它们必须由人执行，因此不像自动化过程那样快或一致
- 关键组件：所必需的应用程序正常运行的组件。在上面的示例中，应用程序和数据库服务器都是关键组件，因为如果任一个失败，应用程序将不可用
- 单点故障：不具有自动故障切换机制的关键组件被认为是单一故障点。您应该尽力消除单点故障，以提高可用性
- 修订：更新你的文档作为部署和恢复过程改进
3.负载平衡
负载平衡可以添加到服务器环境中，以通过在多个服务器之间分配工作负载来提高性能和可用性。如果其中一个负载平衡的服务器失败，其他服务器将处理传入流量，直到失败的服务器再次变得正常。在云服务器环境中，通常可以通过在运行应用程序的特定组件的多个服务器之前添加负载平衡器服务器（负载平衡器（逆向代理）软件）来实现负载平衡。
生产所需吗？不一定。负载平衡并不总是需要在生产环境中，但它可以是一个有效的方法来减少系统中的单点故障数，如果实现正确。它还可以通过水平缩放添加更多容量来提高性能。
上图添加了一个额外的应用服务器来共享负载，负载均衡器负责在两个应用服务器之间传播用户请求。如果单个应用程序服务器努力跟上流量，这种设置可以帮助提高性能，并且还可以在应用程序服务器之一故障时帮助保持应用程序可用性。但是，它在数据库服务器和负载均衡器服务器本身中仍然有两个单点故障。
注意事项
- 负载平衡式组件：在环境中不是所有的组件可以很容易地负载均衡。必须特别考虑某些类型的软件，如数据库或有状态应用程序
- 应用数据复制：如果一个负载均衡应用服务器存储应用本地数据，如上传的文件，该数据必须通过方法如复制或共享文件系统提供给其他应用服务器。这是必要的，以确保应用数据将可用，而不管选择哪个应用服务器来服务用户请求
- 性能瓶颈：如果负载平衡器没有足够的资源或配置不正确，它实际上可以降低你的应用程序的性能
- 单点故障：当负载平衡，可用于消除单点故障，计划不周的负载均衡实际上可以增加失败的多单点。通过包含第二个负载均衡器（在该对前面具有静态IP，根据可用性将流量发送到另一个负载均衡器）来增强负载均衡。
相关教程
4.监测
监视可以通过跟踪服务的状态和服务器资源利用率的趋势来支持服务器环境，从而为您的环境提供极大的可见性。监视系统的最大优点之一是，它们可以配置为在服务或服务器关闭时触发操作，例如运行脚本或发送通知，或者某个资源（如CPU，内存或存储，过度利用。通过这些通知，您可以在发生任何问题时立即对其进行响应，这有助于最大限度地减少或防止应用程序的停机时间。
需要生产？不一定，但需要用于监测随着生产环境生长在大小和复杂性。它提供了一个简单的方法来跟踪您的关键服务和服务器资源。反过来，监控可以提高可恢复性，并通知您的设置的规划和维护。
上图是监控系统的示例。通常，监视服务器将从在应用和数据库服务器上运行的代理软件请求状态数据，并且每个代理将用软件和硬件状态信息进行响应。然后，系统的管理员可以使用监视控制台来查看应用程序的总体状态，并根据需要向下钻取更详细的信息。
注意事项
- 服务监视：提供的服务和软件，你将监视。最低限度，您应该监视所有需要处于正常运行状态的服务的状态，以使应用程序正常运行
- 资源监视：你将监视的资源。资源的示例包括CPU，内存，存储和网络利用率，以及服务器作为一个整体的状态
- 数据保存：时间您保留丢弃之前，监测数据的时间。这与您选择要监视的项目一起，将影响监视系统所需的磁盘空间量
- 问题检测规则：确定一个服务或资源是否处于正常状态的阈值和规则。例如，如果服务或服务器正在运行和服务请求，则服务或服务器可以被认为是健康的，而诸如存储的资源可以在其使用达到特定阈值时触发警告一定时间量
- 通知规则：即确定是否通知应发送阈值和规则。虽然通知很重要，但同样重要的是调整通知规则，以免收到太多通知;一个充满警告和警报的收件箱通常会被忽略，使得它们几乎与没有通知一样无用
相关教程
集中日志
集中式日志记录可以支持服务器环境，通过提供一种简单的方式来查看和搜索日志，这些日志通常在单个位置上存储在整个环境中的各个服务器上。除了无需登录到单个服务器以读取日志的便利之外，集中式日志记录还允许您通过在特定时间段内关联多个服务器的日志和指标来轻松识别跨多个服务器的问题。它还为日志保留提供了更大的灵活性，因为本地日志可以从应用程序服务器卸载到具有自己独立存储的集中式日志服务器。
生产所需吗？没有，但像监控，集中日志可以提供宝贵的洞察您的服务器环境，因为它生长在大小和复杂性。除了比传统的日志记录更方便，它使您能够更加可见地快速审核服务器日志。
上图是集中式日志系统的简化示例。日志传送代理安装在每个服务器上，并配置为将重要的应用程序和数据库日志发送到集中日志记录服务器。系统的管理员然后可以从单个控制台查看，过滤和搜索所有重要日志。
注意事项
- 日志收集：特定的日志，你会从你的服务器运到集中式日志服务器。您应该从所有服务器收集重要日志
- 数据保存：那你丢弃它们之前保留日志的时间段。这与您选择要收集的日志一起，将影响集中日志系统所需的磁盘空间量
- 日志过滤器：解析普通登录到结构化的日志数据的过滤器。过滤日志将提高以有意义的方式查询，分析和绘制数据的能力
- 服务器的时钟：确保您的服务器的时钟同步，并使用设置为相同的时区，所以你的日志时间表在您的整个环境是准确的
相关教程
结论
当您将所有组件放在一起时，您的生产环境可能如下所示：
现在您已经熟悉了可用于支持和改进生产服务器设置的组件，您应该考虑如何将它们集成到您自己的服务器环境中。当然，我们没有涵盖一切可能性，但这应该给你一个想法，从哪里开始。记住基于可用资源和自己的生产目标的平衡来设计和实现服务器环境。 如果您有兴趣建立类似上面的环境，看看这个教程：
构建用于生产：Web应用程序 。
觉得文章有用就打赏一下文章作者
支付宝扫一扫打赏
微信扫一扫打赏
