Вертикальное и горизонтальное масштабирование

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

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

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

Содержание

Вертикальное и горизонтальное масштабирование [ править | править код ]

Вертикальное масштабирование [ править | править код ]

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

Горизонтальное масштабирование [ править | править код ]

Горизонтальное масштабирование — разбиение системы на более мелкие структурные компоненты и разнесение их по отдельным физическим машинам (или их группам), и (или) увеличение количества серверов, параллельно выполняющих одну и ту же функцию. Масштабируемость в этом контексте означает возможность добавлять к системе новые узлы, серверы, процессоры для увеличения общей производительности. Этот способ масштабирования может требовать внесения изменений в программы, чтобы программы могли в полной мере пользоваться возросшим количеством ресурсов. [1]

Показатели [ править | править код ]

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

• сильная масштабируемость — показывает, как меняется время решения задачи с увеличением количества процессоров (или вычислительных узлов) при неизменном общем объёме задачи [2] ;
• слабая масштабируемость — показывает, как меняется время решения задачи с увеличением количества процессоров (узлов) при неизменном объёме задачи для одного процессора (или узла).

Возможность масштабирования информационной системы – как горизонтальное , так и вертикальное – является одним из самых важных факторов, на которые стоит обращать при выборе средства автоматизации деятельности любой организации. Если выбранное решение невозможно будет масштабировать, или каждая стадия роста бизнеса будет приводить к сложностям с сопровождением и развитием такого программного продукта, то не следует даже начинать его использовать. Мы разрабатывали СЭД ЛЕТОГРАФ с учетом высоких требований к масштабированию.

Необходимость в горизонтальном или вертикальном масштабировании возникает в связи с созданием корпоративных высоконагруженных ИТ-систем, в которых работают тысячи или даже десятки тысяч пользователей. Однако поддерживать одновременную работу большого числа пользователей могут далеко не все СЭД. Только если в СЭД на уровне архитектуры заложены возможности по наращиванию количества пользователей без потери производительности – только в этом случае масштабирование будет успешным. Созданная нами система ЛЕТОГРАФ была разработана таким образом, чтобы идеально масштабироваться как горизонтально, так и вертикально. Это достигается как за счет архитектуры самой системы и того прикладного кода, который мы разработали, так и за счет функционала СУБД InterSystems Caché, на которой наша СЭД построена.

СУБД Caché – это современная система управления базами данных и среда для быстрой разработки приложений. В основе этой СУБД лежит технология, которая обеспечивает быстродействие и высокую производительность, масштабируемость и надежность. При этом аппаратные требования системы остаются довольно скромными.

СУБД Caché сохраняет высокую производительность даже при работе с огромными массивами данных и большим числом серверов в распределенных системах. При этом доступ к данным осуществляется через объекты, высокопроизводительные SQL-запросы и путем прямой обработки многомерных структур данных.

Вертикальное масштабирование

Вертикальное масштабирование предполагает наращивание мощности сервера и его возможностей, связанных с дисковой подсистемой. ЛЕТОГРАФ поддерживает современную процессорную архитектуру, что позволяет обрабатывать большие объемы данных в несколько потоков. При этом сами данные в СЭД организованы таким образом, чтобы их можно было легко разносить по СХД на разные диски. Такой подход позволяет равномерно распределить нагрузку на хранилища данных и минимизировать ее при чтении данных непосредственно из базы, а значит и падения производительности системы удастся избежать даже при одновременной работе большого количества пользователей.

Еще на этапе разработки платформы мы понимали, что вертикальное масштабирование – одна из ключевых возможностей системы, потребность в которой со временем будет только увеличиваться. Мы разработали систему таким образом, чтобы процессы работы каждого пользователя были выделены в отдельные системные процессы, которые между собой не пересекаются благодаря тому, что базы данных эффективно делят доступ к информации. При этом количество блокировок данных в СЭД ЛЕТОГРАФ минимизировано и нет «узкого горла» ни при чтении данных, ни при их записи.

Архитектура СЭД ЛЕТОГРАФ позволяет распределять данные на несколько физических или виртуальных серверов. Благодаря такому распределению каждый из пользователей работает в изолированном процессе, а требуемые данные эффективно кэшируются с использованием технологий СУБД Caché. Время блокировки данных минимизировано: все транзакции выстроены таким образом, чтобы переводить данные в эксклюзивный режим доступа лишь на очень короткое время. При этом даже такие высоконагруженные с точки зрения количества обращений к диску данные, как журналы, индексы, данные объектов, потоки, логи действий пользователей, распределены таким образом, что средняя нагрузка на подсистему остается равномерной и не приводит к задержкам. Такой подход позволяет эффективно вертикально масштабировать систему, распределяя нагрузку между серверами или виртуальными дисками.

Горизонтальное масштабирование

Горизонтальное масштабирование – это распределение сессий пользователей по разным серверам (равномерная загрузка серверов приложений и возможность подключать дополнительные сервера приложений), а также распределение данных по разным серверам БД, что обеспечивает высокую производительность системы, при этом не приводя к снижению отказоустойчивости. Для горизонтального масштабирования в системе ЛЕТОГРАФ предусмотрен целый ряд возможностей.

Прежде всего, это масштабирование нагрузки благодаря Enterprise Cache Protocol (ECP, протокол распределенного кэша), протоколу, используемому в СУБД InterSystems Caché. Преимущество ECP заключается в инновационном подходе к кэшированию данных. В рамках данного протокола пользовательские процессы, которые работают на серверах приложений (или ECP-клиентах) СУБД и обслуживают запросы, получают доступ к локальному кэшу недавно использованных данных. И только если этих данных недостаточно, ECP-клиент обращается к базе данных. С помощью протокола ECP выполняется автоматическое управление кэшем: наиболее часто используемые данные сохраняются в кэше, часто обновляемые данные периодически реплицируются, обеспечивая постоянное целостность и корректность данных на всех ECP-клиентах. При этом внутренний алгоритм InterSystems Caché предполагает, что базы данных синхронизируются между ECP-клиентом и ECP-сервером.

Фактически использование технологий СУБД Caché позволяет легко и быстро масштабировать нагрузку по серверам приложений, обеспечив таким образом подключение большого числа пользователей к одному серверу базы данных благодаря использованию ECP-протокола.

Так как информация, которую затребовал тот или иной пользователь, может быть задействована на нескольких ECP-клиентах, необходимо блокировать данные на короткий период времени, быстро выполнять транзакции, не выполняя внутренних вычислений. И мы успешно это реализовали. Данная технология позволяет нам эффективно масштабировать систему в ситуации, когда используются один сервер базы данных и несколько серверов, на которых работают пользовательские процессы. Технологическая особенность СУБД Caché заключается в том, что она поддерживает корректность транзакций в рамках одного ECP-сервера вне зависимости от количества ECP-клиентов, которые к ней подключены. В случае, когда у нас один ECP-сервер и множество ECP-клиентов, эта задача великолепно решается, потому что все транзакции идут на одном сервере базы данных.

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

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

В СЭД ЛЕТОГРАФ реализован механизм шардинга , благодаря которому мы на уровне настроек системы (без применения программирования), даем возможность описать правила и принципы разнесения самих данных по разным серверам БД. Несмотря на то, что с точки зрения структуры баз данных информация, хранящаяся на каждом сервере одинакова, сама информация отличается принципиально в зависимости от организации или каких-либо других признаков, которые являются значимыми для конкретной задачи. Используя технологию шардинга можно добиться, что в 95-99 % случаев пользователи будут работать только со своей «порцией данных», и не потребуется в рамках сессии обращаться к разным серверам БД.

На возможности масштабирования СЭД ЛЕТОГРАФ влияет и то, данные могут по разному обрабатываться. Например, в документы (даже созданные несколько лет назад) могут вноситься изменения, а в журнал действий пользователей записи только добавляются (ни одна запись не может быть ни удалена, ни изменена). Механизмы, которые используются в СЭД ЛЕТОГРАФ, позволяют дополнительно повысить производительность системы и улучшить масштабирование за счет ведения таких журналов на отдельных серверах БД – причем, как в случае односерверной, так и многосерверной конфигурации. Такой подход ориентирован на снижение нагрузки на основные сервера БД.

Аналогичная ситуация возникает и контентом (“информационным содержанием” СЭД). Так как система ЛЕТОГРАФ работает с большим объемом контента – это терабайты данных, миллионы файлов и документов – разумно предположить, что контент, который попадает в систему, ни при каких условиях не должен пострадать. Поэтому мы также выносим хранение файлов на отдельные сервера баз данных и обеспечиваем таким образом дополнительно горизонтальное масштабирование.

Программное обеспечение фронт-энда

В качестве фронт-энда в СЭД ЛЕТОГРАФ используются Apache и HAProxy. HAProxy отвечает за балансировку нагрузки между веб-серверами Apache. HAProxy, как показал опыт работы системы, зарекомендовал себя как наиболее эффективное решение, способное обеспечить поддержку работы большого числа пользователей и необходимый контроль за отказоустойчивостью.

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

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

Пример реализации проекта

Архитектура ЛЕТОГРАФ позволяет добиться существенных результатов в сокращении времени отклика и повышении производительности системы. В рамках одного из наших проектов в СЭД хранится 23,5 Тбайт данных. Из них 14,7 Тбайт (63%) приходится на потоки (“прикрепленные к карточкам файлы”), 3,5 Тбайт (15%) – на отчетные формы, такие как таблицы отчетов, которые формируются в асинхронном режиме, могут запускаться как по расписанию, так и по требованию пользователя и представляют собой сводную таблицу, любые данные в которой можно детализировать до объекта. Еще 1,6 Тбайт (7%) – это протокол пользовательских операций, а все остальное (16%) – данные карточек и индексы.

В данной системе работает более 11 тыс. пользователей, 2 тыс. из них работают одновременно, а в дни пиковой нагрузки число одновременно работающих в СЭД сотрудников превышает 3 тыс. Количество записей в журнале уже превысило 5,5 млрд, а учетных карточек – почти достигло полумиллиарда.

В качестве сервера базы данных в данном проекте установлен отказоустойчивый кластер из двух физических серверов с тремя инсталляциями СУБД, а также резервный сервер. Десять серверов приложений (и один резервный) обрабатывают пользовательские сессии и обеспечивают формирование асинхронных отчетов. 2 сервера HAProxy выполняют функции балансировщиков. В случае проблем с одним из серверов, выполняется автоматическая передача его IP-адреса на другой сервер. Также предусмотрены сервер индексации файлов и сервер распознавания (обеспечивающий распознавание текста отсканированных бумажных документов при размещении электронных образов в систему).

Резюме

В СЭД ЛЕТОГРАФ предусмотрено большое количество разнообразных механизмов масштабирования. Мы предлагаем своеобразный пирог, в основе которого лежит сервер (физический или виртуальный), на который устанавливается операционная система. Поверх нее стоит СУБД InterSystems Caché, внутри которой располагается код платформы. А уже над ним – настройки системы ЛЕТОГРАФ, благодаря которым СЭД полностью конфигурируется. И такой пирог размещен на каждом сервере. Сервера между собой связаны определенным образом за счет выбранных конфигураций. И последний слой – это HAProxy, распределяющий между серверами запросы пользователей. Такая архитектура позволяет нам поддерживать масштабирование и обеспечивать все необходимые механизмы мониторинга. В результате конечные пользователи получают быстро работающую СЭД, а ИТ-специалисты – простую в управлении и обслуживании, унифицированную систему, без огромного числа составляющих, которые в случае высоконагруженных приложений приходится постоянно контролировать и администрировать. Кроме того, в зависимости от изменения потребностей организации СЭД ЛЕТОГРАФ легко переконфигурировать, добавив новые серверы или дисковые возможности.

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

Возможности для масштабирования для серверов баз данных определяются применяемыми программными решениями: чаще всего это реляционные базы данных (MySQL, Postgresql) или NoSQL (MongoDB, Cassandra и др).

Горизонтальное масштабирование для серверов баз данных при больших нагрузках значительно дешевле

Веб-проект обычно начинают на одном сервере, ресурсы которого при росте заканчиваются. В такой ситуации возможны 2 варианта:

• перенести сайт на более мощный сервер
• добавить еще один сервер небольшой мощности с объединить машины в кластер

MySQL является самой популярной RDBMS и, как и любая из них, требует для работы под нагрузкой много серверных ресурсов. Масштабирование возможно, в основном, вверх. Есть шардинг (для его настройки требуется вносить изменения в код) и репликация, которая может быть сложной в поддержке.

Вертикальное масштабирование

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

Таким образом с MySQL нужен будет сервер с большим количеством CPU и оперативной памяти, такие сервера имеют значительную стоимость.

Горизонтальное масштабирование
С MongoDB можно добавить еще один средний сервер и полученное решение будет стабильно работать давая дополнительно отказоустойчивость.

Scale-out или горизонтальное масштабирование является закономерным этапом развития инфраструктуры. Любой сервер имеет ограничения и когда они достигнуты или когда стоимость более мощного сервера оказывается неоправданно высокой добавляются новые машины. Нагрузка распределяется между ними. Также это дает отказоустойчивость.

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

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