SpeedUpYourWebsite.v1.2_img_25

Балансировка на стороне клиента

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

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

Round-Robin DNS

Популярным, хотя и очень простым подходом для балансировки запросов является циклический DNS. Он подразумевает создание нескольких записей в таблице DNS для одного домена. Например, мы хотим распределять нагрузку для сайта www.loadbalancedwebsite.ru, и у нас есть два сервера с IP адресами 64.13.192.120 и 64.13.192.121, соответственно. Для того чтобы реализовать циклический DNS для распределения запросов, можно просто создать следующие записи в DNS:

www.loadbalancedwebsite.ru 64.13.192.120
www.loadbalancedwebsite.ru 64.13.192.121

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

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

Балансировка на сервере

Другим популярным подходом для балансировки запросов является создание одного выделенного сервера, который отвечает за распределение запросов. Примерами таких серверов могут быть специальное оборудование или программные решения, например, F5- BIG-IP или Linux Virtual Server Project. Выделенный балансировщик принимает запросы и распределяет их между внутренним кластером веб-серверов. Балансировщик отвечает за обнаружение отказавшего сервера и распределение запросов по остальным. Для повышения надежности в эту схему может быть добавлен дополнительный балансировщик, который включается, когда отказывает основной.

Минусы этого подхода:

1. Существует предел запросов, которые могут быть приняты самим балансировщиком. Однако эта проблема решается введением в схему циклического DNS.

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

Балансировка на стороне клиента

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

Вместо того, чтобы сказать клиенту, что у нас единственный сервер, можно сообщить о нескольких серверах – s1.loadbalancedsite.ru, s2.loadbalancedsite.ru и так далее. При этом клиентское приложение может случайным образом выбирать сервер для подключения и пытаться получить данные с него. Если сервер не доступен или не отвечает длительное время, клиент сам выберет другой сервер, и так далее, пока не получит свои данные.

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

SpeedUpYourWebsite.v1.2_img_25

Рис. 25. Пример балансировки нагрузки и масштабируемости на клиенте

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

Сейчас сервер обеспечивает такие ресурсы, как картинки. Но этот факт становится не столь очевидным, если рассмотреть технику CSS Sprites, когда одна картинка является источником для нескольких и CSS/JavaScript используется для «вытягивания» каждой отдельной картинки из источника. Сейчас многие приложения осуществляют только AJAX- или Flash-запросы к серверу (а не загружают каждый раз с него итоговый документ). Поэтому стандартное настольное и веб-приложение очень похожи в смысле серверных вызовов.

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

1. Клиентский код: JavaScript и(ли) SWF (для Flash-клиентов).

2. Ресурсы: картинки, CSS (Каскадные Таблицы Стилей), аудио-, видео- и HTML- документы.

3. Серверный код: внутренняя логика для обеспечения нужных клиентам данных.

Заметно проще повысить доступность и масштабируемость HTML-кода страниц и других файлов, требуемых на клиенте, чем осуществить то же самое для серверных приложений: доставка статического содержания требует значительно меньше ресурсов. К тому же существует возможность выложить клиентский код через достаточно проверенные сервисы, например, S3 от Amazon Web Services. Как только у нас есть код и ресурсы, обслуживаемые высоконадежной системой доставки содержания, мы можем уже подумать над балансировкой нагрузки на серверные мощности.

Мы можем включить список доступных серверов в клиентский код точно так же, как сделали бы это для настольного приложения. У веб-приложения доступен файл servers.xml, в котором находится список текущих серверов. Оно пытается связаться (используя AJAX или Flash) с каждым сервером в списке, пока не получит ответ. Таким образом, весь алгоритм на клиенте выглядит примерно так:

1. Загружаем файл www.loadbalancedwebsite.ru/servers.xml, который выложен вместе с клиентским кодом и другими ресурсами и содержит список доступных серверов, например, в следующем виде:

<servers> <server>s1.myloadbalancedwebsite.com</server> <server>s2.myloadbalancedwebsite.com</server> <server>s3.myloadbalancedwebsite.com</server> <server>s4.myloadbalancedwebsite.com</server> </servers>

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

3. На клиенте существует заранее установленное время ожидания запроса; если оно превышено, то возвращаемся к шагу 2.

Осуществляем кросс-доменные запросы

Даже при небольшом опыте работы с AJAX уже должно было возникнуть закономерное возражение: «Это не будет работать из-за кросс-доменной безопасности» (для предотвращения XSS-атак). Давайте рассмотрим и этот вопрос.

Для обеспечения безопасности пользователей веб-браузеры и Flash-клиенты блокирует пользовательские вызовы к другим доменам. Например, если клиентский код хочет обратиться к серверу s1.loadbalancedwebsite.ru, он должен быть загружен только с того же домена, s1.loadbalancedwebsite.ru. Запросы от клиентов на другие домены будут заблокированы. Для того чтобы обеспечить работоспособность описанной выше схемы балансировки, из клиентского кода на www.loadbalancedwebsite.ru требуется совершать обращения к серверам с другими доменами (например, к s1.loadbalancedwebsite.ru).

Для Flash-клиентов можно просто создать файл crossdomain.xml, который будет разрешать запросы на *.loadbalancedwebsite.ru:

<cross-domain-policy>
<allow-access-from domain=”*.myloadbalancedwebsite.com”/>
</cross-domain-policy>

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

Но что, если на клиенте используется XMLHttpRequest? XHR попросту запрещает клиенту запрашивать отличный от исходного домена сервер. Однако, существует небольшая лазейка: если клиент и сервер использует одинаковый домен верхнего уровня (для нашего примера это www.loadbalancedwebsite.ru и s1.loadbalancedsite.ru), то можно осуществлять AJAX-вызовы с использованием iframe и уже через него загружать документы с сервера. Браузеры позволяют скриптам обращаться к такому iframe как к «родному», – таким образом, становится возможным доставлять данные с помощью серверного вызова через iframe, если скрипты были загружены с того же домена верхнего уровня.

А если все же AJAX?

Применение динамической загрузки скриптов (она описана в начале седьмой главы) для осуществления запросов позволяет обойти ограничения по безопасности, ибо разрешает кросс-доменные вызовы. Однако эту проблему можно разрешить намного проще. Кросс- доменные запросы между доменами httр://a.site.ru, httр://b.site.ru на httр://site.ru допустимы через свойство document.domain, которое надо (в данном случае) установить в site.ru:

// на странице a.site.ru

document.domain=’site.ru’

// все, теперь можно делать XmlHttpRequest на site.ru
req.open(“post”, ‘http://site.ru/result.php’)

Проблема оказывается решенной.

Преимущества балансировки на стороне клиента

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

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

2. Незаметное выключение неработающего сервера из кластера. У клиента всегда есть возможность подключиться к другому серверу, если первый не отвечает дольше заранее определенного времени. Таким образом, подключение клиента «мягко» передается от одного сервера другому.

3. Работающий кластер доступен для клиента как один сервер. В нашем примере пользователь просто открывает в браузере http://www.loadbalancedwebsite.ru/, который и является для клиента единственным доступным сервером. Использование всех остальных «зеркал» происходит абсолютно незаметно.

Подведем итог: каковы же преимущества балансировки на стороне клиента перед балансировкой на стороне сервера? Наиболее очевидное заключается в том, что не требуется специальное балансирующее оборудование (хотя сам клиентский код будет являться достаточно сложным, полноценным веб-приложением), и не будет никакой необходимости настраивать аппаратную часть или проверять зеркальность вторичного балансировщика для страховки основного. Если сервер не доступен, его можно просто исключить из файла servers.xml.

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

Используем Cloud Computing для балансировки на стороне клиента

В качестве серверной основы приложения можно рассмотреть сервисы Simple Storage Service (S3) и Elastic Computing Cloud (EC2) от Amazon Web Services ( http://aws.amazon.com/ ).

Изначально сервис S3 предоставлял прекрасную возможность для хранения и доставки видео-сообщений, а EC2 был спроектирован именно для работы с S3. Он позволяет расширять свои мощности для поддержки большого количества пользователей весьма просто. Мощности EC2 могут быть задействованы в любое время путем простого запуска образа виртуальной машины. Каждая такая машина стоит 10 центов в час или 72 доллара в месяц. Но что более всего привлекает в EC2, так это гибкость вычислительных ресурсов: виртуальные машины EC2 могут быть отключены, когда они не используются. Например, если у приложения больше трафика в дневное время, чем ночью, то можно подключать больше серверов днем, тем самым сильно повышая денежную эффективность решения в плане хостинга.

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

Пример приложения

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

Чуть раньше указывалось на использование файла servers.xml для оповещения клиента о доступных серверах, но для S3 можно использовать более простой способ. При обращении к сегменту S3 (сегментом в S3 называют хранимую группу файлов; идея похожа на папки файлов) без каких-либо дополнительных аргументов, сервис просто перечисляет все ключи, соответствующие заданному префиксу. Таким образом, для каждой из виртуальных машин приложения на базе EC2 запускается по cron скрипту, который регистрирует сервер как часть общего кластера, просто создавая пустой файл с ключами servers/{AWS IP адреса} в публично доступном сегменте S3.

Например, по адресу http://s3.amazonaws.com/application/?actions=loadlist будет находиться следующий файл:

<ListBucketResult>
    <Name>voxlite</Name> 
    <Prefix>servers</Prefix> 
    <Marker/> 
    <MaxKeys>1000</MaxKeys> 
    <IsTruncated>false</IsTruncated> 
    <Contents> 
        <Key>servers/216.255.255.1</Key> 
        <LastModified>2007-07-18T02:01:25.000Z</LastModified>
        <ETag>”d41d8cd98f00b204e9800998ecf8427e”</ETag> 
        <Size>0</Size> 
        <StorageClass>STANDARD</StorageClass> 
    </Contents> 
    <Contents> 
        <Key>servers/216.255.255.2</Key> 
        <LastModified>2007-07-20T16:32:22.000Z</LastModified>
         <ETag>”d41d8cd98f00b204e9800998ecf8427e”</ETag> 
        <Size>0</Size> 
        <StorageClass>STANDARD</StorageClass> 
    </Contents>
</ListBucketResult>

В этом примере присутствуют два EC2 сервера в кластере, с IP адресами 216.255.255.1 и 216.255.255.2, соответственно.

Логика для скрипта, запускающегося по расписанию

1. Загрузить и разобрать http://s3.amazonaws.com/application/?actions=loadlist .

2. Если текущий сервер отсутствует в списке, создать пустой файл в сегменте с ключом servers/{IP адрес EC2 сервера}.

3. Проверить, доступны ли остальные серверы, записанные в сегменте, проверив связь до них, используя внутренний AWS IP адрес. Если связь установить не удается, то ключ сервера из сегмента удаляется.

Так как скрипт, запускающийся по cron, является частью виртуальной машины EC2, каждая такая машина автоматически регистрируется как доступный сервер в кластере. Клиентский код (AJAX или Flash) разбирает список ключей в сегменте, вычленяет внешнее имя AWS сервера и добавляет его в массив для случайного выбора при соединении, как описано выше при рассмотрении файла servers.xml.

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

Материалы близкой тематики:

Posted in Разгони свой сайт.