Прогнозирование сбоев систем

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

Поиск точки отказа

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

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

• Сколько запросов в секунду способен обработать сервер базы данных в конкретной аппаратной конфигурации?
• При каком предельном количестве запросов в секунду (QPS) снижение производительности начнет влиять на впечатления пользователя от работы с сайтом?

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

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

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

Например, для распределения нагрузки LAMP-приложение может использовать два сервера MySQL: основная база данных для записи оперативной информации и дополнительная — только для чтения.

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

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

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