Поиск по сайту:

5 способов улучшить настройку рабочего сервера веб-приложений


Введение

Как только ваше приложение будет запущено и запущено в среде облачного сервера, вам может быть интересно, как вы можете улучшить свою серверную среду, чтобы совершить скачок от «оно работает» к полноценной производственной среде. Эта статья поможет вам начать работу с планирование и внедрение производственной среды путем создания свободного определения «производства» в контексте веб-приложения в среде облачного сервера и демонстрации некоторых компонентов, которые вы можете добавить в существующую архитектуру для осуществления перехода.

В целях этой демонстрации давайте предположим, что мы начинаем с установки, аналогичной той, что описана в 5 общих настройках сервера, например, эта среда с двумя серверами, которая просто обслуживает веб-приложение:

Ваша фактическая установка может быть проще или сложнее, но общие идеи и компоненты, обсуждаемые здесь, должны в некоторой степени применяться к любой серверной среде.

Давайте начнем с определения того, что мы имеем в виду, когда говорим «производственная среда».

Что такое производственная среда?

Серверная среда для веб-приложения в общем смысле состоит из оборудования, программного обеспечения, данных, оперативных планов и персонала, необходимого для обеспечения работы приложения. Под производственной средой обычно понимается серверная среда, которая была разработана и реализована с учетом допустимых уровней следующих факторов:

  • Доступность. Возможность использования приложения предполагаемыми пользователями в течение объявленных часов. Доступность может быть нарушена из-за любого сбоя, который достаточно сильно влияет на критический компонент (например, сбой приложения из-за ошибки, сбой устройства хранения базы данных или системный администратор случайно отключил сервер приложений).

Одним из способов повысить доступность является уменьшение количества единичных точек отказа в среде. Например, использование статического IP-адреса и службы мониторинга отказоустойчивости гарантирует, что пользователи получат доступ только к статье о здоровой нагрузке по балансировке нагрузки.

  • Возможность восстановления: возможность восстановления среды приложения в случае сбоя системы или потери данных. Если критический компонент выходит из строя и не подлежит восстановлению, доступность становится недоступной. Улучшение ремонтопригодности, родственной концепции, сокращает время, необходимое для выполнения данного процесса восстановления в случае сбоя, и, следовательно, может повысить доступность в случае сбоя.
  • Производительность: приложение работает так, как ожидалось, при средней или пиковой нагрузке (например, оно достаточно быстро реагирует). Хотя производительность очень важна для ваших пользователей, она имеет значение только в том случае, если приложение доступно.

Потратьте некоторое время, чтобы определить приемлемые уровни для каждого из только что упомянутых элементов в контексте вашего приложения. Это зависит от важности и характера рассматриваемого приложения. Например, вполне допустимо, что личный блог, который обслуживает небольшое количество посетителей, страдает от случайных простоев или низкой производительности, если блог можно восстановить, но интернет-магазин компании должен стремиться к очень высоким оценкам по всем направлениям. Конечно, было бы неплохо достичь 100% в каждой категории, для каждого приложения, но это часто неосуществимо из-за нехватки времени и денег.

Обратите внимание, что мы не упомянули (а) надежность оборудования, вероятность того, что данный компонент оборудования будет функционировать должным образом в течение определенного периода времени до отказа, или (б) безопасность в качестве факторов. Это связано с тем, что мы исходим из того, что (а) используемые вами облачные серверы в целом надежны, но могут выйти из строя (поскольку они работают на физических серверах), и (б) вы следуете лучшим практикам безопасности в меру своих возможностей — проще говоря, они выходят за рамки этой статьи. Однако вы должны знать, что надежность и безопасность являются факторами, которые могут напрямую влиять на доступность, и оба могут способствовать необходимости восстановления.

Вместо того, чтобы показывать вам пошаговую процедуру создания производственной среды, что невозможно из-за различных потребностей и характера каждого приложения, мы представим некоторые материальные компоненты, которые можно использовать для преобразования вашей существующей установки в производственную среду.

Давайте посмотрим на компоненты!

1. Система резервного копирования

Система резервного копирования предоставит вам возможность создавать периодические резервные копии ваших данных и восстанавливать данные из резервных копий. Резервные копии также позволяют выполнять откат ваших данных к предыдущему состоянию в случае случайного удаления или нежелательного изменения, которое может произойти по разным причинам, включая человеческую ошибку. У всего компьютерного оборудования есть вероятность сбоя в какой-то момент времени, что потенциально может привести к потере данных. Имея это в виду, вы должны поддерживать последние резервные копии всех ваших важных данных.

Требуется для производства? Да. Система резервного копирования может смягчить последствия потери данных, что необходимо для обеспечения возможности восстановления и, следовательно, повышает доступность в случае потери данных, но ее необходимо использовать в сочетании с надежными планами восстановления, которые обсуждаются в следующем разделе. Обратите внимание, что резервных копий на основе моментальных снимков DigitalOcean может быть недостаточно для всех ваших потребностей в резервном копировании, поскольку он не очень подходит для создания резервных копий активных баз данных и других приложений с большим объемом операций ввода-вывода на диск — если вы запускаете эти типы приложений, или вам нужна большая гибкость планирования резервного копирования, обязательно используйте другую систему резервного копирования, такую как Bacula.

На приведенной выше диаграмме показан пример базовой системы резервного копирования. Сервер резервного копирования находится в том же центре обработки данных, что и серверы приложений, где создаются исходные резервные копии. Позже копии резервных копий за пределами площадки создаются на сервере в другом центре обработки данных, чтобы обеспечить сохранность данных в случае, скажем, стихийного бедствия.

Соображения

  • Выбор для резервного копирования: данные, для которых будет выполняться резервное копирование. Как минимум, создайте резервную копию любых данных, которые вы не можете надежно воспроизвести из альтернативного источника.
  • Расписание резервного копирования. Когда и как часто вы будете выполнять полное или добавочное резервное копирование. Особое внимание следует уделить резервному копированию определенных типов данных, например активных баз данных, которые могут повлиять на расписание резервного копирования.
  • Срок хранения данных: как долго вы будете хранить резервные копии перед их удалением.
  • Дисковое пространство для резервных копий. Сочетание трех предыдущих пунктов влияет на объем дискового пространства, которое потребуется вашей системе резервного копирования. Воспользуйтесь преимуществами сжатия и добавочного резервного копирования, чтобы уменьшить дисковое пространство, необходимое для ваших резервных копий.
  • Резервные копии за пределами площадки. Чтобы защитить резервные копии от локальных аварий в определенном центре обработки данных, рекомендуется хранить копии резервных копий в географически обособленном расположении. На приведенной выше диаграмме для этой цели резервные копии NYC3 копируются в SFO1.
  • Тесты восстановления резервных копий. Периодически проверяйте процесс восстановления резервных копий, чтобы убедиться, что резервные копии работают правильно.

Связанные учебники

  • Как выбрать эффективную стратегию резервного копирования для вашего VPS
  • Как установить сервер Bacula в Ubuntu 14.04
  • Как использовать Rsync для синхронизации локальных и удаленных каталогов на VPS
  • Понимание резервных копий дроплетов DigitalOcean

2. Планы восстановления

Планы восстановления — это набор документированных процедур восстановления после потенциальных сбоев или ошибок администрирования в производственной среде. Как минимум, вам понадобится план восстановления для каждого аварийного сценария, который, по вашему мнению, неизбежно произойдет, например, сбой серверного оборудования или случайное удаление данных. Например, очень простой план восстановления после сбоя сервера может состоять из списка шагов, которые вы предприняли для первоначального развертывания сервера, с дополнительными процедурами для восстановления данных приложения из резервных копий. Лучший план восстановления может, в дополнение к хорошей документации, использовать сценарии развертывания и инструменты управления конфигурацией, такие как Ansible, Chef или Puppet, чтобы помочь автоматизировать и ускорить процесс восстановления.

Требуется для производства? Да. Хотя планы восстановления не существуют как программное обеспечение в вашей серверной среде, они являются необходимым компонентом для производственной установки. Они позволяют эффективно использовать ваши резервные копии и предоставляют план для восстановления вашей среды или отката к желаемому состоянию, когда возникает необходимость.

На приведенной выше диаграмме представлен обзор плана восстановления отказавшего сервера базы данных. В этом случае сервер базы данных будет заменен новым с тем же установленным программным обеспечением, а для восстановления конфигурации и данных сервера будет использована последняя исправная резервная копия. Наконец, сервер приложений будет настроен на использование нового сервера базы данных.

Соображения

  • Документация по процедуре: набор документов, которым следует следовать в случае сбоя. Хорошей отправной точкой является создание пошагового документа, которому вы можете следовать, чтобы восстановить отказавший сервер, а затем добавить шаги для восстановления различных данных приложения и конфигурации из резервных копий.
  • Инструменты автоматизации. Сценарии и программное обеспечение для управления конфигурацией обеспечивают автоматизацию, которая может улучшить процессы развертывания и восстановления. Хотя пошаговые руководства часто подходят для простого восстановления после сбоя, они должны выполняться человеком и, следовательно, не так быстры и последовательны, как автоматизированный процесс.
  • Важнейшие компоненты. Компоненты, необходимые для правильной работы приложения. В приведенном выше примере и серверы приложений, и серверы баз данных являются критически важными компонентами, поскольку в случае сбоя одного из них приложение станет недоступным
  • Единые точки отказа. Критические компоненты, не имеющие механизма автоматического перехода на другой ресурс, считаются единой точкой отказа. Вы должны попытаться устранить единые точки отказа, насколько это возможно, чтобы повысить доступность.
  • Версии: обновляйте документацию по мере улучшения процесса развертывания и восстановления.

3. Балансировка нагрузки

В серверную среду можно добавить балансировку нагрузки, чтобы повысить производительность и доступность за счет распределения рабочей нагрузки между несколькими серверами. Если один из серверов с балансировкой нагрузки выходит из строя, другие серверы будут обрабатывать входящий трафик до тех пор, пока отказавший сервер снова не станет работоспособным. В среде облачных серверов балансировка нагрузки обычно может быть реализована путем добавления сервера балансировки нагрузки, на котором выполняется программное обеспечение балансировки нагрузки (обратный прокси-сервер), перед несколькими серверами, на которых выполняется определенный компонент приложения.

Требуется для производства? Не обязательно. Балансировка нагрузки не всегда требуется для производственной среды, но при правильной реализации она может быть эффективным способом уменьшить количество единых точек отказа в системе. Это также может повысить производительность за счет увеличения емкости за счет горизонтального масштабирования.

На схеме выше добавлен дополнительный сервер приложений для распределения нагрузки и балансировщик нагрузки для распределения пользовательских запросов между обоими серверами приложений. Эта настройка может повысить производительность, если единственный сервер приложений не справляется с трафиком, а также может помочь сохранить доступность приложения в случае сбоя одного из серверов приложений. Однако у него по-прежнему есть две единые точки отказа: сервер базы данных и сам сервер балансировщика нагрузки.

Примечание. Балансировщики нагрузки DigitalOcean — это полностью управляемая высокодоступная служба балансировки нагрузки. Если вы запускаете свое приложение в DigitalOcean, служба Load Balancer может хорошо подойти для вашей среды.

Соображения

  • Компоненты с балансировкой нагрузки. Не все компоненты в среде можно легко балансировать по нагрузке. Особое внимание следует уделять определенным типам программного обеспечения, таким как базы данных или приложения с отслеживанием состояния.
  • Репликация данных приложений. Если сервер приложений с балансировкой нагрузки хранит данные приложений локально, например загруженные файлы, эти данные должны быть доступны для других серверов приложений с помощью таких методов, как репликация или общие файловые системы. Это необходимо для того, чтобы данные приложения были доступны независимо от того, какой сервер приложений выбран для обслуживания запроса пользователя.
  • Узкие места в производительности. Если у балансировщика нагрузки недостаточно ресурсов или он неправильно настроен, это может фактически снизить производительность вашего приложения.
  • Единичные точки отказа. Хотя балансировка нагрузки может использоваться для устранения единых точек отказа, плохо спланированная балансировка нагрузки может фактически добавить больше таких точек. Балансировка нагрузки улучшена за счет включения второго балансировщика нагрузки со статическим IP-адресом перед парой, которая отправляет трафик на один или другой в зависимости от доступности.

Связанные учебники

  • Введение в HAProxy и концепции балансировки нагрузки
  • Как реализовать терминацию SSL с помощью HAProxy в Ubuntu 14.04
  • Как использовать HAProxy в качестве балансировщика нагрузки уровня 7 для WordPress и Nginx в Ubuntu 14.04
  • Общие сведения о прокси-сервере Nginx HTTP, балансировке нагрузки, буферизации и кэшировании
  • Как создать свой первый балансировщик нагрузки DigitalOcean
  • Как использовать зарезервированные IP-адреса

4. Мониторинг

Мониторинг может поддерживать серверную среду, отслеживая состояние служб и тенденции использования ресурсов вашего сервера, тем самым обеспечивая большую видимость вашей среды. Одним из самых больших преимуществ систем мониторинга является то, что их можно настроить для запуска действия, такого как запуск сценария или отправка уведомления, когда служба или сервер выходят из строя, или если определенный ресурс, такой как ЦП, память или хранения, становится чрезмерно используемым. Эти уведомления позволяют вам реагировать на любые проблемы, как только они возникают, что может помочь свести к минимуму или предотвратить время простоя вашего приложения.

Требуется для производства? Не обязательно, но потребность в мониторинге возрастает по мере увеличения размеров и сложности производственной среды. Он предоставляет простой способ отслеживать критически важные службы и ресурсы сервера. В свою очередь, мониторинг может улучшить возможность восстановления и информировать о планировании и обслуживании вашей установки.

На приведенной выше схеме показан пример системы мониторинга. Как правило, сервер мониторинга запрашивает данные о состоянии у программного обеспечения агента, работающего на серверах приложений и баз данных, и каждый агент отвечает информацией о состоянии программного и аппаратного обеспечения. Затем администраторы системы могут использовать консоль мониторинга для просмотра общего состояния приложения и получения более подробной информации по мере необходимости.

Соображения

  • Службы для мониторинга. Службы и программное обеспечение, которые вы будете отслеживать. Как минимум, вы должны отслеживать состояние всех служб, которые должны быть в рабочем состоянии, чтобы ваше приложение работало должным образом
  • Ресурсы для мониторинга. Ресурсы, которые вы будете отслеживать. Примеры ресурсов включают использование ЦП, памяти, хранилища и сети, а также состояние сервера в целом.
  • Сохранение данных: период времени, в течение которого вы сохраняете данные мониторинга перед их удалением. Это, наряду с вашим выбором элементов для мониторинга, повлияет на объем дискового пространства, которое потребуется вашей системе мониторинга
  • Правила обнаружения проблем: пороговые значения и правила, определяющие, находится ли служба или ресурс в нормальном состоянии. Например, служба или сервер могут считаться работоспособными, если они работают и обслуживают запросы, тогда как ресурс, такой как хранилище, может вызывать предупреждение, если его использование достигает определенного порога в течение определенного периода времени.
  • Правила уведомления: пороговые значения и правила, определяющие необходимость отправки уведомления. Хотя уведомления важны, не менее важно настроить правила уведомлений, чтобы вы не получали их слишком много; почтовый ящик, полный предупреждений и предупреждений, часто игнорируется, что делает их почти такими же бесполезными, как и отсутствие уведомлений.

Связанные учебники

  • Как установить Nagios 4 и контролировать свои серверы в Ubuntu 14.04
  • Как использовать Icinga для мониторинга ваших серверов и служб в Ubuntu 14.04
  • Как установить Zabbix на Ubuntu и настроить его для мониторинга нескольких серверов VPS
  • Мониторинг и управление сетью с помощью SNMP
  • Как настроить Sensu Monitoring, RabbitMQ и Redis в Ubuntu 14.04

5. Централизованное ведение журнала

Централизованное ведение журналов может поддерживать серверную среду, предоставляя простой способ просмотра и поиска журналов, которые обычно хранятся локально на отдельных серверах во всей вашей среде, в одном месте. Помимо удобства, заключающегося в том, что не нужно входить на отдельные серверы для чтения журналов, централизованное ведение журналов также позволяет легко выявлять проблемы, охватывающие несколько серверов, путем сопоставления их журналов и показателей за определенный период времени. Это также обеспечивает большую гибкость с точки зрения хранения журналов, поскольку локальные журналы могут быть выгружены с серверов приложений на централизованный сервер журналов, который имеет собственное независимое хранилище.

Требуется для производства? Нет, но, как и мониторинг, централизованное ведение журналов может предоставить бесценную информацию о вашей серверной среде по мере ее роста и сложности. Помимо того, что он более удобен, чем традиционное ведение журналов, он позволяет вам быстро проверять журналы сервера с большей наглядностью.

Диаграмма выше представляет собой упрощенный пример централизованной системы ведения журналов. Агент доставки журналов установлен на каждом сервере и настроен для отправки важных журналов приложений и баз данных на централизованный сервер журналов. Затем администраторы системы могут просматривать, фильтровать и искать все важные журналы с единой консоли.

Соображения

  • Журналы для сбора. Отдельные журналы, которые вы будете отправлять со своих серверов на централизованный сервер журналов. Вам следует собрать важные журналы со всех ваших серверов.
  • Сохранение данных: период времени, в течение которого вы храните журналы перед их удалением. Это, наряду с вашим выбором журналов для сбора, повлияет на объем дискового пространства, который потребуется вашей централизованной системе ведения журналов
  • Фильтры журналов. Фильтры, преобразующие простые журналы в структурированные данные журналов. Фильтрация журналов улучшит ваши возможности запрашивать, анализировать и отображать данные в виде графиков.
  • Часы серверов. Убедитесь, что часы ваших серверов синхронизированы и настроены на один и тот же часовой пояс, чтобы ваша временная шкала журнала была точной во всей вашей среде.

Связанные учебники

  • Как установить Elasticsearch, Logstash и Kibana 4 в Ubuntu 14.04
  • Как использовать приложение DigitalOcean ELK Stack для быстрого запуска
  • Введение в отслеживание статистики на серверах
  • Как установить Graylog2 и централизовать журналы в Ubuntu 14.04

Заключение

Когда вы соберете все компоненты вместе, ваша производственная среда может выглядеть примерно так:

Теперь, когда вы знакомы с компонентами, которые можно использовать для поддержки и улучшения настройки рабочего сервера, вам следует подумать о том, как вы можете интегрировать их в свои собственные серверные среды. Конечно, мы не рассмотрели все возможности, но это должно дать вам представление о том, с чего начать. Не забудьте спроектировать и внедрить серверную среду на основе баланса доступных ресурсов и собственных производственных целей.

Если вы заинтересованы в настройке среды, подобной приведенной выше, ознакомьтесь с этим руководством: Сборка для производства: веб-приложения.