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

Катастрофа может произойти из-за выхода из строя питания или охлаждения вычислительных центров, а также в результате стихийных бедствий (например, землетрясения). Возможны и другие неприятности (скажем, ошибки при проведении строительных работ или взрывы), нарушающие работу питания, охлаждения или каналов связи, необходимых для вашего сайта. Независимо от причин последствия всегда одинаковы — сайт перестает работать. Безусловно, способность предоставления трафика в аварийных условиях является важной частью веб-деятельности и архитектуры, а управление мощностями должно учитывать и чрезвычайные обстоятельства. Аварийное восстановление (DR, Disaster Recovery) является лишь одной из частей планирования непрерывности бизнеса (ВСР, Business Continuity Planning) — более крупной логистической программы, обеспечивающей непрерывность ведения бизнеса перед лицом различных случаев отказа.

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

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

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

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

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

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

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

Со времени появления многоуровневых (tiered) и неразделяемых (shared-nothing) архитектур горизонтальное масштабирование получило широкое признание благодаря своим преимуществам перед вертикальным масштабированием в том, что касается веб-приложений. Способность системы к горизонтальному масштабированию подразумевает, что ваше приложение разработано соответствующим образом и может обеспечить работу базы данных в распределенном режиме. Замечательные применения методов разработки на базе горизонтального масштабирования представлены в упоминавшихся книгах Хендерсона и Шлосснейгла.

Если вы будете опираться исключительно на вертикальное масштабирование, возникнет опасность того, что непрестанное обновление компонентов одного компьютера приведет к резкому возрастанию затрат. Также возникнет риск появления единой точки отказа (SPOE Single Point of Failure).

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

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

Для нас это означает, что все узлы с интенсивным использованием процессоров и памяти можно «обновить», используя меньшее количество серверов с более мощными процессорами и большими объемами памяти.

Для компьютеров, интенсивно работающих с дисками, это может означать возможность перехода на меньшее количество компьютеров с большим количеством дисков. В качестве примера рассмотрим недавнее обновление Flickr.

Изначально было 67 двухпроцессорных веб-серверов с 4 Гбайт памяти и одним диском SATA. Клиентский уровень в основном интенсивно использует процессор, обрабатывая запросы от клиентских браузеров, обращаясь с запросами к базе данных и принимая загружаемые фотографии. На этих 67 компьютерах, оснащенных процессорами Intel Xeon 2,80 ГГц, работали Apache и РНР.

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

С восемью ядрами процессоров Intel Xeon L5320 1,86 ГГц сотрудники смогли заменить 67 серверов всего 18 новыми серверами. На рисунке показано, насколько в результате сократилась средняя нагрузка на сервер (в границах всего кластера)

Рисунок демонстрирует снижение средней нагрузки, которое произошло после исключения 67 компьютеров из рабочего пула и передачи той же производственной нагрузки 18 новым компьютерам. Конечно, график выглядит очень эффектно, но, возможно, средняя нагрузка — не лучший показатель для пояснения диагонального масштабирования.

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

Таблица. Сравнение архитектур серверов

Если на основании анализа трафика предположить, что серверы работают в среднем на 60% от пиковой нагрузки, получится, что используется около 30 % от использовавшейся ранее мощности. Кроме того, эта замена сэкономила 49U единиц стоечного пространства, так как каждому серверу достаточно 1U места. В результате диагональное масштабирование привело к освобождению более чем одной полной стандартной стойки 42U. Неплохо, согласитесь.

Архитектура определяет основную схему объединения всех компонентов bаск-end-подсистемы как аппаратных, так и программных. Она играет важнейшую роль в возможности планирования и управления мощностями. Проектирование архитектуры может быть весьма нетривиальным делом, к счастью, есть пара отличных книг, которые нам в этом помогут: «Building Scalable Web Sites» Кэла Хендерсона (Cal Henderson) и «Scalable Internet Architectures» Teo Шлосснейгла.

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

Объекты измерений

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

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

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

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

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

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

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

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

Сервер базы данных

Как увеличение количества запросов к базе данных в секунду будет влиять на:

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

Веб-сервер

Как увеличение количества запросов к веб-серверу в секунду будет влиять на:

• использование диска;
• ожидание ввода/вывода;
• использование оперативной памяти;
• использование процессора?

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

Точки масштабирования

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

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

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

Каждый сервер в нашем примере располагает конечным объемом следующих аппаратных ресурсов:

• Пропускная способность диска.
• Дисковое пространство.
• Процессор.
• Оперативная память.
• Сетевые ресурсы.

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

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

Разумеется, конечной целью планирования мощностей является быстрота и удобство работы пользователей. Кроме мощностей, существует ряд других факторов, которые могут отразиться на впечатлениях пользователей. Некоторые сайты работают медленно даже при избытке мощностей. Методы создания быстрых веб-страниц выходят за рамки этого раздела, но вы можете найти массу полезной информации по этой теме в замечательной книге Стива Соудерса (Steve Souders) High Perfoimance Web Sites.

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

При предоставлении статического веб-контента неприемлемые задержки при высоких объемах данных могут возникнуть еще до того, как метрики системного уровня (процессор, диск, память) выдадут тревожный сигнал. Как уже говорилось ранее, проблемы могут быть обусловлены в большей степени конструкцией веб- страницы, нежели мощностями серверов, поставляющих контент. Но поскольку изменение мощностей связано с относительно высокими затратами, этот вопрос стоит изучить подробнее. Субъективная заторможенность веб-страниц может объясняться не отсутствием необходимых мощностей, а тем, что страница попросту слишком тяжеловесна (один из ключевых моментов книги Соудерса). Анализируя жалобы на медленную работу сайта с точки зрения пользователей, желательно определить ее причину. Проблема может решаться (1) добавлением мощностей и (2) изменением «веса» страницы. Первое решение зачастую сопряжено с большими затратами, чем второе. Интерпретация результатов измерений даст точный ответ.

Flickr, например, предоставляет десятки тысяч фотографий в секунду. Каждый фото сервер способен выдавать изображения с заранее известной частотой, но только до достижения своего предела. Компания задает этот максимум не в параметрах скорости записи/чтения на диск, затрат ресурсов процессора или памяти, а в количестве изображений, которые могут быть предоставлены сервером до того, как «время предоставления» для каждого изображения превысит заданное значение.

Веб-службы получают все большее распространение в современном мире гибридных решений Web 2.0. Хотя многие веб-службы предоставляют открытые API, на основе которых независимые разработчики могут строить свои приложения, от этих API также зависят отношения «бизнес-бизнес».

Таким образом, компании обычно связывают свои потоки поступления доходов с беспрепятственным доступом к этим API. Это может означать, что ваши деловые партнеры рассчитывают на определенный уровень доступности или производительности ваших API, измеряемый в относительном времени доступности (например, 99,99%) или заранее согласованной частоте запросов к API.

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

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

Некоторые SLA гарантируют, что сервис будет доступен определенный процент времени, например 99,99%. Это означает, что 0,01 % от общего времени сервис может быть недоступен и при этом все равно останется в границах SLA. Другие SLA требуют, чтобы интенсивность использования сервиса оставалась в разумных пределах. В этом случае типичными параметрами будут ограничения частоты запросов, используемого дискового пространства и объема передаваемых данных.

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

Acme Hosting, Inc. приложит коммерчески оправданные усилия к тому, чтобы план SuperHostingPlan оставался доступным с ежемесячным процентом работоспособного времени (см. ниже) не менее 99 9% в пределах каждого месячного цикла оплаты. В том спучае, если Acme Hosting, Inc. не выполнит это обязательство, другая сторона получает право на бесплатное обслуживание в течение следующего времени:

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

30 дней = 720 часов = 43 200 минут
99 9% от 43 200 минут = 43 156,8 минуты
43 200 минут — 43 156,8 минуты = 43,2 минуты

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

Таблица. Проценты SLA и допустимые простои

Термин «пять девяток» часто используется при обсуждении SLA и доступности. Он означает доступность 99,999% и встречается в маркетинговой литературе не реже, чем в технической. Считается, что сайт или система с уровнем доступности «пять девяток» обладает высокой доступностью.

Показатели доступности SLA определяют уровень доверия к сервису веб-сайта, но они также подразумевают, что простой непосредственно преобразуются в недополученную прибыль. На мой взгляд, простая математика здесь не совсем корректна. Если ваш сервис, приносящий $3000 прибыли в минуту, недоступен в течение 10 минут, предполагается, что вы потеряли $30 000. На самом же деле клиенты могут продолжить работу позднее и купить всё, что они собирались купить в момент сбоя. Кроме того, ваш бизнес может вкладывать дополнительные средства в службу поддержки клиентов, чтобы сбои не отражались на ваших заработках.

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

Ваш сайт должен быть доступен не только для коллег тестирующих сайт из офиса на соседней улице, но и для реальных посетителей, которые могут находиться в других странах и пользоваться медленными каналами связи. Некоторые крупные компании решили постоянно отслеживать производительность (и доступность) своих сайтов при помощи таких служб, как Keynote (http://keynote.com) или Gome/ ( http://gomez.com). Эти коммерческие службы используют глобальные компьютерные сети, которые постоянно опрашивают веб-страницы своих клиентов и регистрируют время отклика. Серверы отслеживают собранные данные и строят удобную диаграмму производительности и работоспособности сайта для разных географических зон по всему миру.

Так как Keynote и Gomez считаются «объективными» независимыми наблюдателями, эта статистика может использоваться для выработки условий или проверки выполнения соглашений об уровне обслуживания (SLA. Service Level Agreement) с партнерскими компаниями или сайтами (мы еще поговорим о SLA позднее). Keynote и Gomez относятся к службам корпоративного уровня, кроме них существует множество низкобюджетных альтернатив, в том числе PingDom (http://pingdom.com), SiteUptime (http://siteuptime.com) и Alertra (http://alertra.com).

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

• Имитирует ли система действия человека?
• Кэширует ли она объекты, как это делает обычный браузер? Почему?
• Можно ли определить, сколько времени тратится на передачу данных по сети, а сколько на сервере — и в совокупности, и для каждого объекта по отдельности?
• Можно ли определить, какими причинами обусловлен сбой или непредвиденно высокое время ожидания — проблемами в работе географических сетей или сбоями измерительной системы?

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

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

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

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

• Производительность
  • Внешний мониторинг сервиса
  • Бизнес-требования
  • Ожидания пользователей
• Мощности
• Системные метрики
• Ресурсные «потолки».

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

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

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

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