TOC

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

Вступление

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

Для целей этой демонстрации давайте предположим, что мы начинаем с установки, аналогичной описанной в https://www.digitalocean.com/community/tutorials/5-common-server-setups-for-your-web- application [5 Common Server Setups], как эта двухсерверная среда, которая просто обслуживает веб-приложение:

изображение: https: //assets.digitalocean.com/articles/architecture/production/it_works.png [Настройка приложения]

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

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

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

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

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

Одним из способов повышения доступности является уменьшение количества единичных точек отказа в среде. Например, использование статического IP-адреса и службы аварийного переключения мониторинга обеспечивает пользователям доступ только к исправным балансировщикам нагрузки. Чтобы узнать больше, прочитайте https://www.digitalocean.com/community/tutorials/how-to-use-floating-ips- on-digitalocean # как выполнить настройку [этот раздел Как использовать плавающие IP-адреса] и этот https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx -балансировка нагрузки [статья о балансировке нагрузки].

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

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

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

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

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

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

[[1-backup-system]] === 1. Система резервного копирования

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

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

изображение: https: //assets.digitalocean.com/articles/architecture/production/backup_system.png [Пример системы резервного копирования]

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

Соображения

  • * Выбор резервной копии: * Данные, которые вы будете резервировать. Как минимум, создайте резервную копию любых данных, которые вы не можете надежно воспроизвести из альтернативного источника.

  • * Расписание резервного копирования: * Когда и как часто вы будете выполнять полное или инкрементное резервное копирование. Особые соображения должны быть приняты для резервного копирования определенных типов данных, таких как активные базы данных, которые могут повлиять на ваш график резервного копирования

  • * Срок хранения данных: * Как долго вы будете хранить резервные копии, прежде чем удалять их

  • * Дисковое пространство для резервных копий: * Сочетание трех предыдущих элементов влияет на объем дискового пространства, который потребуется вашей системе резервного копирования. Воспользуйтесь преимуществами сжатия и добавочного резервного копирования, чтобы уменьшить дисковое пространство, необходимое для резервного копирования.

  • * Резервное копирование вне сайта: * Для защиты ваших резервных копий от локальных бедствий в пределах определенного центра обработки данных желательно хранить копии ваших резервных копий в географически отдельном месте. На приведенной выше схеме резервные копии NYC3 для этой цели копируются в SFO1.

  • * Тесты восстановления резервной копии: * Периодически проверяйте процесс восстановления резервной копии, чтобы убедиться, что ваши резервные копии работают должным образом

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

[[2-recovery-plans]] === 2. Планы восстановления

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

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

изображение: https: //assets.digitalocean.com/articles/architecture/production/recovery_plans.png [Примеры планов восстановления]

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

Соображения

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

  • * Инструменты автоматизации: * Сценарии и программное обеспечение для управления конфигурацией обеспечивают автоматизацию, которая может улучшить процессы развертывания и восстановления. Несмотря на то, что пошаговые инструкции часто достаточны для простого восстановления после сбоя, они должны выполняться человеком и, следовательно, не такие быстрые и последовательные, как автоматизированный процесс.

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

  • * Отдельные точки отказа: * Критические компоненты, которые не имеют механизма автоматического переключения при сбое, считаются единой точкой отказа. Вы должны попытаться устранить отдельные точки отказа, в меру своих возможностей, чтобы улучшить доступность

  • * Редакции: * Обновляйте документацию по мере улучшения процесса развертывания и восстановления.

[[3-load-balancing]] === 3. Балансировки нагрузки

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

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

изображение: https: //assets.digitalocean.com/articles/architecture/production/load_balancing.png [Балансировка нагрузки]

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

Соображения

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

  • * Репликация данных приложения: * Если сервер приложений с балансировкой нагрузки хранит данные приложения локально, такие как загруженные файлы, эти данные должны быть доступны для других серверов приложений с помощью таких методов, как репликация или общие файловые системы. Это необходимо для обеспечения доступности данных приложения независимо от того, какой сервер приложений выбран для обслуживания пользовательского запроса.

  • * Узкие места в производительности: * Если у балансировщика нагрузки недостаточно ресурсов или он не настроен должным образом, это может фактически снизить производительность вашего приложения.

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

[[4-monitoring]] === 4. мониторинг

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

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

изображение: https: //assets.digitalocean.com/articles/architecture/production/monitoring.png [Пример мониторинга]

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

Соображения

  • * Услуги для мониторинга: * Услуги и программное обеспечение, которое вы будете контролировать. Как минимум, вы должны следить за состоянием всех служб, которые должны быть в исправном состоянии, чтобы ваше приложение функционировало правильно

  • * Ресурсы для мониторинга: * Ресурсы, которые вы будете контролировать. Примеры ресурсов включают использование процессора, памяти, хранилища и сети, а также состояние сервера в целом.

  • * Хранение данных: * Период времени, в течение которого вы сохраняете данные мониторинга перед их сбросом. Это, наряду с выбором элементов для мониторинга, повлияет на объем дискового пространства, который потребуется вашей системе мониторинга.

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

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

[[5-centralized-logging]] === 5. Централизованное ведение журнала

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

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

изображение: https: //assets.digitalocean.com/articles/architecture/production/centralized_logging.png [Централизованное ведение журнала]

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

Соображения

  • * Журналы для сбора: * Конкретные журналы, которые вы будете отправлять с ваших серверов на централизованный сервер журналов. Вы должны собрать важные журналы со всех ваших серверов

  • * Хранение данных: * Период времени, в течение которого вы сохраняете журналы до их удаления. Это, наряду с выбором журналов для сбора, повлияет на объем дискового пространства, который потребуется вашей централизованной системе журналирования.

  • * Log Filters: * Фильтры, которые анализируют простые журналы в структурированные данные журнала. Фильтрация журналов улучшит вашу способность запрашивать, анализировать и графически представлять данные осмысленными способами.

  • * Часы сервера: * Убедитесь, что часы на ваших серверах синхронизированы и установлены на один и тот же часовой пояс, поэтому временная шкала вашего журнала точна во всей вашей среде.

Заключение

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

Изображение: HTTPS: //assets.digitalocean.com/articles/architecture/production/production.png [Производство]

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

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

Related