Исследование высоконагруженных компьютерных систем. Дипломная (ВКР). Информационное обеспечение, программирование.

🛑 👉🏻👉🏻👉🏻 ИНФОРМАЦИЯ ДОСТУПНА ЗДЕСЬ ЖМИТЕ 👈🏻👈🏻👈🏻

Информационное обеспечение, программирование

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


Помощь в написании работы, которую точно примут!

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

Не нашел материал для своей работы?


Поможем написать качественную работу Без плагиата!

Исследование высоконагруженных компьютерных систем


Web 2.0методика проектирования систем, путем учета сетевых взаимодействийNoSQLnot only SQL - ряд подходов, направленных на реализацию хранилищ баз данныхБДбаза данныхHTMLHyperText Markup LanguageNginxвеб-сервер и почтовый прокси-сервер , работающий на Unix -подобных операционных системахURLUniform Resource Locator - единообразный локатор (определитель местонахождения) ресурсаAPIинтерфейс создания приложенийGFSGoogle File System - распределенная файловая системаСУБДсистема управления базами данных

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

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

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

Целью работы является исследование конкретно взятых высоконагруженных систем Google и Вконтакте; изучение их архитектуры, оборудования и платформ на которых они реализованы.


1. Что такое высоконагруженные компьютерные системы


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

Итак, что же такое высоконагруженная система? Ответ на этот вопрос стоит начать с описания качественных свойств такого рода систем.


1.1 Традиционные качества высоконагруженной системы


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

приведенные факторы являются количественными, а не качественными.

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


1.1.1 Многопользовательская система

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

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

Если посмотреть на статистику Московского метрополитена за 2010 год, то окажется, что средняя часовая нагрузка на систему максимальна в диапазоне от 8 до 9 часов утра. За этот час через турникеты проходят приблизительно 720 тысяч человек. Что порождает необходимость не менее 200 раз в секунду проверять статус предъявленных проездных и принимать решение о пропуске того или иного человека через турникет. В Интернете существует масса высоконагруженных ресурсов с подобными показателями пропускной способности. Например, статистика по StackOverflow за тот же 2010-й год показывает, что их средняя пропускная способность находится в диапазоне 100-150 хитов в секунду.

Определенно у метрополитена более высокие требования к пропускной способности. Но значит ли это что Московский метрополитен можно считать более высоконагруженным чем StackOverflow? Вряд ли, в частности потому, что эти две системы оперируют несравнимыми объемами информации.

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


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

необходимости обрабатывать возрастающие объемы данных;

необходимости живучести системы в случаях отказа части серверов.

Большинство высоконагруженных приложений являются Интернет-приложениями. А отличительной особенностью современного Интернета основанного на концепции Web 2.0 является тот факт, что сами пользователи генерируют данные, которые они сами же в итоге и потребляют. Это приводит к тому, что чем больше пользователей, тем больше потенциальный объем хранимых данных.

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

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

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


1.1.3 Позитивная динамика по пользователям и данным

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

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


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


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

Контроль над ресурсами является неотъемлемой частью работы с высоконагруженным проектом.

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

Высоконагруженная система - это интерактивная распределенная система, которая требует постоянного контроля над собственными ресурсами. В противном случае она перестает работать.

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

изменения паттернов поведения аудитории, в том числе и сезонные.

В основном темы докладов на конференциях посвященных тематике разработки высоконагруженных систем можно свести к двум основополагающим направлениям:

как решать существующие задачи, используя меньше ресурсов (практически все NoSQL БД, оптимизация);

как имея больше ресурсов решать пропорционально больший объем задач (message queueing, распределенные вычисления, распределенные БД, параллелизм).


1.2 Высоконагруженный проект - это интернет приложение


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

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

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

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

В контексте высокой нагрузки список первостепенных задач, которые стоят перед разработчиками:

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

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

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


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

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

В общем случае, отложенные вычисления осуществляются по принципу:

Одной из разновидностей предварительных вычислений является кэширование.


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

Кэширование сегодня является неотъемлемой частью любого Web-проекта, не обязательно высоконагруженного. Для каждого ресурса критичной для пользователя является такая характеристика, как время отклика сервера. Увеличение времени отклика сервера приводит к оттоку посетителей. Следовательно, необходимо минимизировать время отклика: для этого необходимо уменьшать время, требуемое на формирование ответа пользователю, а ответ пользователю требует получить данные из каких-то внешних ресурсов (backend). Этими ресурсами могут быть как базы данных, так и любые другие относительно медленные источники данных (например, удаленный файловый сервер, на котором мы уточняем количество свободного места). Для генерации одной страницы достаточно сложного ресурса нам может потребоваться совершить десятки подобных обращений. Многие из них будут быстрыми: 20 миллисекунд и меньше, однако всегда существует некоторое небольшое количество запросов, время вычисления которых может исчисляться секундами или минутами (даже в самой оптимизированной системе они могут быть, хотя их количество должно быть минимально). Если сложить всё время, которое мы затратим на ожидание результатов запросов (если же мы будем выполнять запросы параллельно, то возьмем время вычисления самого долгого запроса), мы получим неудовлетворительное время отклика.

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


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

Кэш всегда лучше, чем исходный источник данных: кэш ЦП (центральный процессор) на порядки быстрее оперативной памяти, однако мы не можем сделать оперативную память такой же быстрой, как кэш - это экономически неэффективно и технически сложно. Буфер жесткого диска удовлетворяет запросы за данными на порядки быстрее самого жесткого диска, однако буфер не обладает свойством запоминать данные при отключении питания - в этом смысле он хуже самого устройства. Аналогичная ситуация и с кэшированием в Web е: кэш быстрее и эффективнее, чем backend, однако он обычно в случае перезапуска или падения сервера не может сохранить данные, а также не обладает логикой по вычислению каких-либо результатов: он умеет возвращать лишь то, что мы ранее в него положили.


Memcached <#"justify">2.1.4 Общая схема кэширования

В общем случае схема кэширования выглядит следующим образом: frontend у (той части проекта, которая формирует ответ пользователю) требуется получить данные какой-то выборки. Frontend обращается к быстрому как гепард серверу memcached за кэшом выборки (get-запрос) (рисунок 1). Если соответствующий ключ будет обнаружен, работа на этом заканчивается. В противном случае следует обращение к тяжелому, неповоротливому, но мощному (как слон) backend у, в роли которого чаще всего выступает база данных. Полученный результат сразу же записывается в memcached в качестве кэша (set-запрос). При этом обычно для ключа задается максимальное время жизни (срок годности), который соответствует моменту сброса кэша.



Рисунок 1 - Общая схема кэширования


Такая стандартная схема кэширования реализуется всегда. Вместо memcached в некоторых проектах могут использоваться локальные файлы, иные способы хранения (другая БД, кэш PHP-акселератора и т.п.).


Каким же образом устроен memcached? Как ему удаётся работать настолько быстро, что даже десятки запросов к memcached, необходимых для обработки одной страницы сайта, не приводят к существенной задержке. При этом memcached крайне нетребователен к вычислительным ресурсам: на нагруженной инсталляции процессорное время, использованное им, редко превышает 10%.

Во-первых, memcached спроектирован так, чтобы все его операции имели алгоритмическую сложность O(1), т.е. время выполнения любой операции не зависит от количества ключей, которые хранит memcached. Это означает, что некоторые операции (или возможности) будут отсутствовать в нём, если их реализация требует всего лишь линейного (O(n)) времени. Так, в memcached отсутствуют возможность объединения ключей «в папки», т.е. какой-либо группировки ключей, также мы не найдем групповых операций над ключами или их значениями.

Основными оптимизированными операциями является выделение/освобождение блоков памяти под хранение ключей, определение политики самых неиспользуемых ключей (LRU) для очистки кэша при нехватке памяти. Поиск ключей происходит через хэширование, поэтому имеет сложность O(1).

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

По сути, можно сказать, что время отклика сервера memcached определяется только сетевыми издержками и практически равно времени передачи пакета от frontend а до сервера memcached (RTT). Такие характеристики позволяют использовать memcached в высоконагруженных web-проектах для решения различных задач, в том числе и для кэширования данных.


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

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

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

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

Можно разделить данные, которые мы храним в memcached, по степени критичности их потери.

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

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

«Совсем не должны терять». удобен для хранения сессий пользователей - все сессии равнодоступны со всех серверов, входящих в кластер frontend ов. Так вот содержимое сессий не хотелось бы терять никогда - иначе пользователей на сайте будет «разлогинивать». Как попытаться избежать? Можно дублировать ключи сессий на нескольких серверах memcached из кластера, так вероятность потери снижается.

Если нам нужна WEB-страница, которая формируется несколько сот миллисекунд или даже секунд, то можно ее сформировать один раз, запомнить в каком-то буфере, и потом отдавать по мере необходимости.

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

Кэширование осуществляется на разных уровнях, начиная от сохранения в кэше браузера HTML страниц, логотипов и картинок, сохранения HTML-страниц и статического контента (картинки) в прокси-серверах и кэше WEB-сервера.

Кэширование результатов трансляции опкода специальными кэшерами и акселераторами. Применительно к РНР: АРС, XCache, eAccelerator, ZendAccelerator и т.д.

Кэширование на уровне WEB-приложения осуществляется либо с использованием файловой системы, БД или специальными кэширующими демонами.


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

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

Далее, фронтэнд, по мере необходимости выбирает нужную информацию из кэша, формирует HTML страницу и отдает запрашиваемому браузеру. В результате имеем 5-10 кратное повышение производительности.


2.2.1 А как же это всё использовать

Вся суть HighLoad проектов сводится к принципу "Быстро взял - быстро отдал". Как минимизировать скорость отдачи страницы. Логика отдачи такова:

часть данных выносим в отдельную логику, подготавливать их отдельными скриптами или демонами. Отдавать их отдельными AJAX запросами, а HTML формировать на стороне клиента (браузера). Тем самым мы уменьшаем время на формирование и передачу выходных данных. Такими данными могут быть счетчики сообщений, просмотров, "Что нового у друзей" и так далее;

Например, стоит задача постраничной навигации по списку некоторой выборки: определенной категории товаров или объектов. Классическое решение - это использование в операторе SELECT (на примере MySQL) ключевых слов LIMIT/OFFSET. Для первой страницы выдачи значение LIMIT равно кол-во записей выдачи, как правило, это 10, 20 или 50, а OFFSET равно 0. Для последующих страниц, OFFSET равно (Np -1)* Psize, где Np - номер страницы, Psize = значению LIMIT - размер выдачи на одной странице.

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

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

Выделяют следующие виды кэширования:

Обычно хранят сериализованный массив данных. Ключом может быть:

элемент данных запроса в ключевом слове WHERE, например id, наименование категории и прочие. Обычно с префиксом: catid_12321;

значение хеша (md5) от всего текста запроса.

$data = db->query($sql);>set($key, $data)

Многие современные фреймворки осуществляют кэширование блоками. Блоком является некий блок вывода, который рассчитывается отдельным бэкенд-контроллером.

Однако можно использовать для кэширования средства ssi (server side include - включение на стороне сервера). В частности в nginx используется следующий подход:

каждый блок вызывает не тяжелый php скрипт, который формирует HTML;

после отработки скрипт кладется c некоторым ключом в memcache;

при обращении на внутренний url, который указан в шаблоне-сборщике (ssi шаблоне), идет обращение к модулю ngx_http_memcached. Если данных там нет, HTTP ERROR 404, то происходит переориентирование на внутренний url, который вызывает необходимый PHP скрипт.

Можно осуществить кэширование страницы, по принципу кэширования данных, но уже кэшировать результирующий HTML, который формируется бэкендом. Однако, производительней если кэширование будет осуществлять WEB сервер. Обычно кэшируют домашнюю страницу (index.html) и статические наиболее часто запрашиваемые страницы.


Отдача контента в HighLoad проектах сводится к задаче "как можно быстрее отдать". Как этого достичь:

быстро изъять или рассчитать необходимые данные;

как можно быстрее отдать, полученный HTML.

Как можно быстро собрать данные - это либо изъять уже готовые данные (кэширование). Либо раскидать поиск данных по нескольким машинам, если многочисленные данные у нас распределены по нескольким серверам.
Для поиска в распределенных хранилищах данных используется технология от Google для обработки больших массивов данных MapReduce.

каждый узел в системе считывает свою часть данных и образует из них пары «ключ-значение»;

сформированные пары преобразуются по определенному алгоритму в новые пары «ключ-значение» в соответствии от месторасположения (стадия Map);

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

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


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


Наиболее известным продуктом по распределению задач является Gearman <#"justify">2.4.2 Сервера очередей

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

Какие задачи могут решать сервера очередей:

новостная лента, всякого рода подписки;

асинхронная обработка фоновых "тяжелых" задач;

обработка медиа контента: фото и видео;

AMQP - Advanced Message Queue Protocol;

STOMP - Simple (or Streaming) Text Oriented Message Protocol;

XMPP - Extensible Messaging and Presence Protocol.

Простой сервер очередей MemcachedQ, использует memcached протокол get/set, реализован как надстройка над memcached. Простой, эффективный и не требует дополнительных клиентов и библиотек.- (так же ØMQ, ZeroMQ, 0MQ или ZMQ) высокопроизводительный сервер, реализующий протокол AMQP 1.0., ActiveMQ - сервера очередей, реализуют протокол AMQP.- REST надстройка над redis, реализация redis с версии 2.0 имеет возможность работать с подписками.

Очереди в redis реализовались, как работа со списками: писалось (клалось в очередь) в начало списка LPUSH, а читалось с конца спичка (бралось из очереди) RPOP.


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

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




Рисунок 3 - Балансировка WEB-сервера


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

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

Round robin. Из доступных серверов строится очередь и балансировщик выбирает первый в очереди. После выполнения запроса сервер перемещается в конец очереди;

меньшее количество соединений. Балансировщик ведет учет количества незакрытых соединений и выбирает тот сервер, у которого таких соединений меньше;

использование "веса" серверов. Каждому серверу в зависимости от мощности присваивается вес, который используется для ранжирования.

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

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


Рисунок 4 - Тривиальная схема балансировщика нагрузки двух WEB-серверов


Для реализации программного балансировщика есть много решений, например:

Балансировка серверов БД, осуществляется специальными прокси серверами. Для MySQL - это MySQLProxy. Для PostgreSQL это сочетание PgProxy и PgBouncer. Один является пулом соединений, а второй балансировщиком нагрузки.


Такой продукт, как memcached и redis имеют встроенные средства балансировки.

Если для балансировки WEB запросов и запросов к БД используется алгоритм round-robin.

То для балансировки кэшей используется алгоритм ketama, суть которого в том, чтобы закрепить ключи за серверами и при добавлении нового сервера в кластер кэшей не нарушить распределение ключей по серверам кластера. Например, если номер сервера будет выбиратьс
Похожие работы на - Исследование высоконагруженных компьютерных систем Дипломная (ВКР). Информационное обеспечение, программирование.
Реферат по теме Євген Чикаленко - меценат української культури
Курсовая Работа На Заказ Запорожье
Контрольная Работа По Теме П
Реферат по теме Формирование самоконтроля в процессе обучения математике по системе Д.Б.Эльконина - В.В.Давыдова в начальных классах
Аудит Расчетов По Оплате Труда Курсовая Работа
Эссе Образ Педагога В Художественной Литературе
Курсовая работа по теме Род Полынь во флоре Тихорецкого района
Реферат: «использование технологий xml и com для решения задач статистической радиофизики»
Оценка Исторического Сочинения Егэ
Прокурор В Уголовном Процессе Курсовая
Реферат: Анализ и оценивание государственных программ и отраслевых политик Обязательная учебная дисциплина для 3-го курса факультета Гиму гу-вшэ 2 и 3 модуль 2008/09 уч год
Курсовая работа по теме Акционерная собственность
Реферат по теме Правовое государство и Украина
Отчет По Практике В Мфц Юристу
Досрочное Сочинение По Русскому 2022
Контрольная работа по теме Развитие сердечно-сосудистой системы. III и IV и VI пары черепно-мозговых нервов.
Анализ обеспеченности запасов и источниками их формирования
Курсовая работа: Основные принципы, этапы и техника составления годовой бухгалтерской отчетности
Дипломная работа по теме Обслуживание электроустановок промышленных предприятий
Темы Сочинений По Повести Гоголя Портрет
Реферат: Pizarro Essay Research Paper Francisco PizarroBorn in
Курсовая работа: Педагогика в системе наук
Реферат: Учет расчетов с бюджетом по налогам