Трудности прогнозирования
При проектировании любых информационных систем одной из существенных задач является планирование её производительности. Ведь всем нам хочется получать ответы на наши запросы и реакцию на наши действия быстро.
Этой цели легко достичь, применив более мощное вычислительное оборудование, но как любой ресурс оно имеет свою стоимость. Поэтому в реальных условиях стараются найти разумное соотношение между ожидаемой нагрузкой на проектируемую информационную систему и характеристиками её аппаратной части.
Поиск правильного номинального уровня производительности представляет особую трудность в случае публичных информационных систем типа социальных сетей, интернет-магазинов, досок объявлений, видеохостинга и т. д.
Например, после какой-нибудь рекламы нагрузка на эти сервисы может за считанные часы измениться даже не в разы, а на порядок. В коммерческом плане, это — очень хорошо, но если нагрузка на сайт превысить некий критический порог, он просто перестанет работать, и деньги, потраченные на рекламу, не принесут пользы. Наоборот, неработающий сайт может вызвать обратный, негативный, эффект.
Потребность изменить производительность информационной системы может возникнуть и в менее острых ситуациях. Например, при постепенном увеличении нагрузки или при очевидной избыточности изначально запланированной мощности.
Понимая возможность возникновения таких ситуаций, проектировщики информационных систем стараются предусмотреть в них средства масштабирования, то есть возможность изменения её производительности посредством относительно малых изменений, не нарушающих фундаментальной архитектуры системы.
Масштабирование системы
Этому вопросу посвящена наша статья «Масштабирование в облаке».
Кратко, выделяют два подхода с условными названиями: вертикальное и горизонтальное масштабирование.
Вертикальное масштабирование — это изменение мощности отдельного элемента информационной системы. На примере промышленного предприятия, это означает замену одного станка другим с большей или меньшей производительностью.
Горизонтальное масштабирование — это применение вместо одного элемента нескольких однотипных, работающих параллельно так, чтобы суммарно обеспечить требующуюся производительность.
Масштабировать вертикально намного проще и быстрее, чем масштабировать горизонтально. Но вертикальное масштабирование имеет существенно меньшие пределы наращивания производительности.
Типовая архитектура
При проектировании информационных систем уже давно применяется подход, при котором она разделяется на несколько функциональных уровней.
Чаще применяют три уровня: хранение данных, их обработка и представление.
В эту трёхуровневую архитектуру хорошо вписывается метод горизонтального масштабирования. Работу элементов на каждом из уровней можно запараллелить, объединив их в функциональную группу. Эти группы совместно работающих элементов часто называют кластерами или пулами ресурсов.
Совсем необязательно, чтобы в каждой группе было много элементов. Иногда уже два элемента могут заметно улучшить характеристики системы.
Для правильной работы элементов в группе требуется их как-то координировать, распределять между ними общую нагрузку. Такое распределение называется балансировкой нагрузки.
Существуют разные подходы к её организации.
Цели распределения нагрузки
Основных целей три: улучшение производительности системы, повышение её отказоустойчивости и обеспечение бесперебойной работы.
Благодаря наличию в группе однотипных элементов, в неё можно добавлять новые элементы или исключать имеющиеся, чтобы привести общую производительность к желанному значению.
Использование нескольких элементов вместо одного повышает отказоустойчивость системы, так как выход из строя одного элемента не остановит работы остальных и группы, в целом.
Присутствие нескольких элементов в группе позволяет планово перераспределить нагрузку между элементами так, чтобы появилась возможность выполнить ремонт или обслуживание одного из них без прекращения работы всей компьютерной системы.
Варианты балансировки нагрузки
Термины распределение нагрузки и балансировка нагрузки — близкие, но не вполне взаимозаменяемые.
Слово «балансировка» всегда предполагает динамический процесс, а распределение может быть ещё и статическим или псевдодинамическим. То есть балансировка нагрузки является частным случаем её распределения, при котором учитываются какие-то дополнительные изменяющиеся факторы.
Методов распределения нагрузки существует много.
Статическое распределение
Лучше объяснить на примерах.
Предположим, у вас имеется 1000 пользователей и два идентичных веб-сервера для обслуживания этих пользователей. Вы можете сконфигурировать подсистему аутентификации ваших пользователей так, чтобы пользователи с идентификаторами с 1 до 500 обслуживались одним сервером, а с идентификаторами от 501 до 1000 — другим. Таким образом вы направите на каждый из двух своих серверов по 50% общей нагрузки.
Серверы в группе необязательно должны быть одинаковыми. Если один из них более мощный, а другой — менее, распределение пользователей между ними может сделать неравномерным, пропорциональным производительности серверов.
Второй пример — географический. Пользователей из одного региона вы можете направлять на один сервер, а из другого — на другой.
При статическом распределении привязка пользователя к конкретному серверу постоянная, не меняющаяся не по каким условиям.
Псевдодинамическое распределение
Почему о нём зашла речь до рассмотрения динамического распределения? — Потому что алгоритмы и реализация динамического распределения более сложные.
Чем плох метод статического распределения? — Тем, что в случае изменения ситуации внутри информационной системы или вокруг неё, потребуется каким-то способом вовремя заметить перемены и вручную изменить настройки.
Рассмотрим прежние примеры. Активность пользователей из одной половины списка может оказаться заметно выше активности пользователей из другой половины. Общее число пользователей может увеличиться. Активность пользователей из разных регионов может существенно изменяться в зависимости от времени суток или дней недели.
Указанные особенности и процессы можно нивелировать, если распределить запросы между имеющимися серверами циклически или в случайном порядке.
Неравенство производительностей серверов в группе можно учесть, например, отправляя 30% запросов на один сервер, 50% — на второй и 20% — на третий.
Не все знают, что проще всего организовать случайное распределение запросов между несколькими серверами с помощью… DNS.
Если DNS-серверу, поддерживающему ваше доменное имя, сообщить, что этому домену соответствует несколько IP-адресов, сервер будет выдавать эти адреса в случайном или циклическом порядке. При этом нет никаких ограничений на сами адреса — каждый из серверов вашей информационной системы может находиться где угодно в интернете.
У этого метода есть недостатки.
Если один из серверов пула перестанет работать, пользователи, направленные на него, столкнутся с сообщением об ошибке. После следующей попытки они попадут на работающий сервер, но у части других пользователей ошибки будут продолжать возникать.
Для исправления ситуации потребуется вручную подкорректировать список IP-адресов на доменном сервере.
Из-за кэширования IP-адресов в DNS изменения списка адресов прикладных серверов не сразу дойдут до клиентских приложений. Периодичность обновления данных в кэше можно сократить соответствующей настройкой. Но при этом надо понимать, что от такой настройки возрастёт нагрузка на DNS-сервер.
Кроме того, этот метод не позволяет распределить нагрузку между прикладными серверами неравномерно.
Динамическое распределение
В качестве другого средства распределения нагрузки используют специализированные программные или аппаратные балансировщики.
Они могут обеспечить разные алгоритмы распределения запросов между серверами, в том числе, такие, при которых учитывается текущего состояния серверов или других влияющие факторы. Именно такое распределение следует называть динамическим.
В качестве программных балансировщиков HTTP-запросов часто используют разного рода прокси-серверы, перенаправляющие запросы по установленным правилам куда следует.
Проблемы балансировки нагрузки
Распределённые системы обладают такими замечательными свойствами как высокая и адаптивная производительность, высокая отказоустойчивость, хорошая ремонтопригодность. Но при этом они порождают ряд проблем.
Хранение сессии
В большинстве информационных систем, поддерживающих аутентификацию пользователей, также требуется поддерживать пользовательские сессии — набор контекстных переменных, которые создаются на сервере при обращении пользователя к сервису.
В распределённых информационных системах разные запросы пользователя в общем случае попадают на разные серверы пула. Но нельзя же требовать от пользователя по несколько раз подряд указывать свои учётные данные. Да и контекст на разных серверах всё равно окажется разным.
Для обеспечения сессий в распределённых системах применяют несколько методов.
Сессионные переменные хранят не на каждом сервере, а в общей сетевой папке или в базе данных, одинаково доступных всем прикладным серверам.
Другим, более сложным и менее гибким, подходом является привязка пользователя к конкретному серверу на время сессии. В этом случае существенно возрастёт нагрузка на балансировщик нагрузки, а общая надёжность системы может снизиться.
Кэширование содержания
В распределённых информационных системах требуется принимать дополнительные меры для правильного размещения кэшированных данных. Ведь также как сессионные переменные, они должны быть одинаково доступны всем серверам пула. Применяется аналогичный подход: кэш размещается в сетевой папке с общим доступом со всех серверов.
Остановка сервера
По каким-то причинам сервер, входящий в кластер, может прекратить свою работу. Для сохранения нормальной работы кластера, в целом, балансировщик должен вовремя узнать об аварийной ситуации и автоматически исключить из кластера сломавшийся сервер.
Заключение
Использование несколько относительно небольших серверов вместо одного большого связано с рядом сложностей и трудностей, однако они с лихвой перекрываются преимуществами распределённой информационной системы:
- возможность практически бесконечного наращивания производительности;
- возможность снижения производительности при необходимости;
- существенный рост надёжности;
- увеличение ремонтопригодности.
P. S. Ещё немного интересных статей
