5 способов оптимизировать настройку сервера производства

Amber

6 лет назад

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

Для начала предположим, что у нас есть тестовая среда из двух серверов, которые обслуживают одно веб-приложение.

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

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

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

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

Читайте также:

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

Обратите внимание, что здесь не упоминаются такие факторы:

надежность аппаратного обеспечения (вероятность того, что данный аппаратный компонент будет функционировать должным образом в течение определенного количества времени перед сбоем);
и безопасность.

Это связано с тем, что мы предполагаем, что:

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

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

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

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

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

Роль систем резервного копирования в среде производства очень важна.

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

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

Для настройки резервного копирования нужно выбрать:

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

Читайте также:

Планирование восстановления

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

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

Роль планирования восстановления в среде производства очень важна.

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

Для создания планов восстановления нужно предусмотреть:

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

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

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

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

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

При настройке балансировки нагрузки нужно учитывать следующее:

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

Читайте также:

Мониторинг

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

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

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

Настраивая мониторинг, нужно иметь в виду:

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

Читайте также:

Централизованное логирование

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

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

При настройке централизованного логирования нужно продумать:

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

Читайте также:

Заключение

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