Можно, конечно, перенести IP-адрес на соседний сервер, который может нести нагрузку. Однако данная процедура весьма хлопотная, чтобы проводить ее в условиях аврала.
Балансировка на сервере
Другим популярным подходом для балансировки запросов является создание одного выделенного сервера, который отвечает за распределение запросов. Примерами таких серверов могут быть специальное оборудование или программные решения, например F5-BIG-IP или Linux Virtual Server Project. Выделенный балансировщик принимает запросы и распределяет их уже внутри кластера веб-серверов. Балансировщик отвечает за обнаружение отказавшего сервера и распределение запросов по остальным. Для повышения надежности в эту схему может быть добавлен дополнительный балансировщик, который включается, когда отказывает основной.
Минусы этого подхода:
Существует предел запросов, которые могут быть приняты самим балансировщиком. Однако эта проблема решается введением в схему циклического DNS.
Поддержка балансировщика может обходиться в круглую сумму, доходя до десятков тысяч долларов. К тому же запасной балансировщик большую часть времени простаивает в ожидании, когда откажет основной.
Балансировка на стороне клиента
Существует еще один подход для распределения нагрузки на серверы от современных веб-приложений, который не нуждается в дополнительном балансирующем оборудовании, и отказ одного из серверов происходит гораздо более незаметно для клиента, чем в случае циклического DNS. Прежде чем мы углубимся в детали, давайте представим себе настольное приложение, которому требуется установить связь с серверами в интернете для получения данных. Если наше приложение создает больше запросов к удаленному серверу, чем тот может поддерживать при помощи единственной машины, нам потребуется решение для балансировки нагрузки. Можем ли мы воспользоваться циклическим DNS или балансировщиком нагрузки, описанным выше? Конечно, но существует более дешевое и надежное решение.
Вместо того чтобы сказать клиенту, что у нас единственный сервер, можно сообщить о нескольких серверах — s1.loadbalancedsite.ru, s2.loadbalancedsite.ru и так далее. При этом клиентское приложение может случайным образом выбирать сервер для подключения и пытаться получить данные с него. Если сервер недоступен или не отвечает длительное время, клиент сам выберет другой сервер, и так далее, пока не получит свои данные.
В отличие от веб-приложений, которые хранят код (Javascript или Flash) на одном сервере, обеспечивающем доступ к этой информации, клиентское приложение не зависимо от сервера. Оно может само выбирать между серверами на стороне клиента для обеспечения масштабируемости приложения (рис. 5.3).
Рис. 5.3. Пример балансировки нагрузки и масштабируемости на клиенте
Итак, можно ли эту технику применить к веб-приложениям? Веб-приложения самой своей сутью размывают границу между клиентской и серверной частями любого стандартного приложения. Веб-приложения, написанные на PHP, часто смешивают серверный и клиентский код в одном документе. Даже при использовании паттерна MVC (модель-вид-контроллер), когда код, который генерирует уровень представления (HTML), отделен от серверной логики, все равно сервер создает и доставляет представление страницы.
Сейчас сервер обеспечивает такие ресурсы, как картинки. Но этот факт становится не столь очевидным, если рассмотреть технику CSS Sprites, когда одна картинка является источником для нескольких и CSS/JavaScript используется для «вытягивания» каждой отдельной картинки из источника. Сейчас многие приложения осуществляют только AJAX- или Flash-запросы к серверу (а не загружают каждый раз с него итоговый документ). Поэтому стандартное настольное и веб-приложение очень похожи в смысле серверных вызовов.
Для обеспечения балансировки на стороне клиента от современного веб-приложения требуется три основных составляющих:
Клиентский код: JavaScript и(ли) SWF (для Flash-клиентов).
Ресурсы: картинки, CSS (Каскадные Таблицы Стилей), аудио-, видео- и HTML-документы.
Серверный код: внутренняя логика для обеспечения нужных клиентам данных.