что такое горизонтальное и вертикальное масштабирование
Горизонтальное и вертикальное масштабирование в ЛЕТОГРАФ
Необходимость в горизонтальном или вертикальном масштабировании возникает в связи с созданием корпоративных высоконагруженных ИТ-систем, в которых работают тысячи или даже десятки тысяч пользователей. Однако поддерживать одновременную работу большого числа пользователей могут далеко не все СЭД. Только если в СЭД на уровне архитектуры заложены возможности по наращиванию количества пользователей без потери производительности – только в этом случае масштабирование будет успешным. Созданная нами система ЛЕТОГРАФ была разработана таким образом, чтобы идеально масштабироваться как горизонтально, так и вертикально. Это достигается как за счет архитектуры самой системы и того прикладного кода, который мы разработали, так и за счет функционала СУБД 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-клиентов, эта задача великолепно решается, потому что все транзакции идут на одном сервере базы данных.
Мы на этом не остановились, пошли дальше и поддержали те механизмы, которые позволяют использовать в конфигурации СЭД не только один сервер базы данных, но и несколько.
Опыт показывает, что даже в высоконагруженных системах всегда удается четко разделить данные между серверами БД на основании определенных признаков. Например, если несколько организаций объединены в холдинг, то пользователями из одной структурной единицы вряд ли когда-нибудь будут востребованы данные, которые касаются другого подразделения. Это позволяет на уровне алгоритмов разделять и хранить такие данные на разных серверах БД, повышая таким образом возможности горизонтального масштабирования.
На возможности масштабирования СЭД ЛЕТОГРАФ влияет и то, данные могут по разному обрабатываться. Например, в документы (даже созданные несколько лет назад) могут вноситься изменения, а в журнал действий пользователей записи только добавляются (ни одна запись не может быть ни удалена, ни изменена). Механизмы, которые используются в СЭД ЛЕТОГРАФ, позволяют дополнительно повысить производительность системы и улучшить масштабирование за счет ведения таких журналов на отдельных серверах БД – причем, как в случае односерверной, так и многосерверной конфигурации. Такой подход ориентирован на снижение нагрузки на основные сервера БД.
Аналогичная ситуация возникает и контентом (“информационным содержанием” СЭД). Так как система ЛЕТОГРАФ работает с большим объемом контента – это терабайты данных, миллионы файлов и документов – разумно предположить, что контент, который попадает в систему, ни при каких условиях не должен пострадать. Поэтому мы также выносим хранение файлов на отдельные сервера баз данных и обеспечиваем таким образом дополнительно горизонтальное масштабирование.
Программное обеспечение фронт-энда
В качестве фронт-энда в СЭД ЛЕТОГРАФ используются 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, распределяющий между серверами запросы пользователей. Такая архитектура позволяет нам поддерживать масштабирование и обеспечивать все необходимые механизмы мониторинга. В результате конечные пользователи получают быстро работающую СЭД, а ИТ-специалисты – простую в управлении и обслуживании, унифицированную систему, без огромного числа составляющих, которые в случае высоконагруженных приложений приходится постоянно контролировать и администрировать. Кроме того, в зависимости от изменения потребностей организации СЭД ЛЕТОГРАФ легко переконфигурировать, добавив новые серверы или дисковые возможности.
В экономическом контексте масштабируемая бизнес-модель подразумевает, что компания может увеличить продажи при увеличении ресурсов. Например, система доставки пакетов является масштабируемой, потому что можно доставить больше пакетов, добавив больше средств доставки. Однако, если бы все пакеты сначала прошли через один склад для сортировки, система не была бы масштабируемой, потому что один склад может обрабатывать только ограниченное количество пакетов.
СОДЕРЖАНИЕ
Примеры
Система управления инцидентами (ICS) используется агентствами экстренного реагирования в США. ICS может масштабировать координацию ресурсов от однодвигательного придорожного пожара до межгосударственного лесного пожара. Первый ресурс на сцене устанавливает команду с полномочиями распоряжаться ресурсами и делегировать ответственность (управление пятью-семью офицерами, которые снова будут делегировать до семи, и далее по мере роста инцидента). По мере развития инцидента командование принимает более старшие офицеры.
Габаритные размеры
Масштабируемость можно измерить по нескольким параметрам, таким как:
Домены
Горизонтальное (масштабирование) и вертикальное масштабирование (масштабирование)
Ресурсы делятся на две большие категории: горизонтальные и вертикальные.
По горизонтали или по горизонтали
Вертикально или в увеличенном масштабе
Вертикальное масштабирование (вверх / вниз) означает добавление ресурсов к одному узлу (или удаление ресурсов из него), как правило, с добавлением ЦП, памяти или хранилища к одному компьютеру.
Масштабируемость сети
Масштабируемость базы данных
Масштабируемость баз данных требует, чтобы система баз данных могла выполнять дополнительную работу с учетом больших аппаратных ресурсов, таких как дополнительные серверы, процессоры, память и хранилище. Рабочие нагрузки продолжали расти, и требования к базам данных последовали их примеру.
Алгоритмические инновации включают блокировку на уровне строк, а также секционирование таблиц и индексов. Архитектурные инновации включают архитектуры без общего доступа и с общим доступом для управления конфигурациями с несколькими серверами.
Сильная или конечная согласованность (хранение)
Многие кластеры хранения с открытым исходным кодом и даже коммерческие горизонтально масштабируемые кластеры, особенно построенные на основе стандартного оборудования ПК и сетей, обеспечивают только конечную согласованность. Идентифицируйте некоторые базы данных NoSQL, такие как CouchDB и другие, упомянутые выше. Операции записи делают другие копии недействительными, но часто не ждут их подтверждения. Операции чтения обычно не проверяют каждую избыточную копию перед ответом, что может привести к пропуску предыдущей операции записи. Большой объем сигнального трафика метаданных потребует специализированного оборудования и небольших расстояний для обработки с приемлемой производительностью (т. Е. Действует как некластеризованное запоминающее устройство или база данных).
Когда ожидается высокая согласованность данных, обратите внимание на следующие индикаторы:
Индикаторы для в конечном итоге согласованных проектов (не подходящих для транзакционных приложений!):
Оптимизация производительности и масштабируемость оборудования
Подстановка значения для этого примера с использованием 4 процессоров дает
Удвоение вычислительной мощности до 8 процессоров дает
Удвоение вычислительной мощности ускорило процесс примерно на одну пятую. Если бы всю задачу можно было распараллелить, скорость также удвоилась бы. Поэтому добавление большего количества оборудования не обязательно является оптимальным подходом.
Слабое против сильного масштабирования
У высокопроизводительных вычислений есть два общих понятия масштабируемости:
Вертикальное и горизонтальное масштабирование в блокчейне
1. Что такое вертикальное и горизонтальное масштабирование?
Вертикальное масштабирование влечет за собой расширение сети за счет добавления большей мощности и памяти для основного процессора системы, тогда как горизонтальное масштабирование предполагает добавление большего количества узлов (то есть машин) в структуру существующей системы.
Имея дело с вопросом масштабируемости, важно понимать, что эта концепция обычно требуется, когда нужно увеличить пропускную способность транзакции конкретной платформы.
Вертикальное масштабирование по отношению к традиционной клиент-серверной архитектуре означает модернизацию существующего аппаратного обеспечения системы для включения большей вычислительной мощности и памяти. В том же духе горизонтальное масштабирование связано с изменением базовой структуры самой платформы – для создания кластера серверов, способных легко обрабатывать увеличенное количество входящих запросов транзакций.
2. Хорошо ли работает масштабирование с блокчейнами?
Масштабирование лучше всего работает с традиционными базами данных. Тем не менее, с точки зрения безопасности, масштабируемые блокчейны более полезны и прагматичны, но здесь есть компромисс.
При импорте концепции масштабируемости в контексте технологии блокчейн следует подчеркнуть, что, поскольку блокчейн системы уже являются распределенными сетями, сложно увеличить общую пропускную способность сети, просто добавив больше аппаратных объектов, таких как майнеры, узлы или средства проверки.
В это же время горизонтальное масштабирование имеет тенденцию увеличивать доверие или безопасность сети, это обычно приводит к снижению общей производительности (пропускной способности обработки транзакций) системы.
С другой стороны, вертикальное масштабирование обычно означает ускорение и укрепление каждого внутреннего компонента системы. Это, с точки зрения распределенной системы на основе регистров, подразумевает использование суперкомпьютерных узлов. Однако недостатком всего этого является то, что только несколько человек могут работать с такими узлами.
3. Как выполняется масштабирование?
Вертикальное масштабирование осуществляется путем повышения эффективности каждой отдельной транзакции, тогда как горизонтальное масштабирование достигается за счет увеличения общей пропускной способности платформы.
Проще говоря, общие улучшения масштабируемости осуществляются с использованием концепции, называемой «многоуровневой», при которой каждый отдельный компонент конкретной системы взаимодействует со своими цифровыми аналогами каким-то последовательным и иерархическим способом.
Кроме того, когда речь идет о блокчейнах, разработчики стремятся поддерживать неизменность своей базовой цепочки, что, в свою очередь, позволяет уровню масштабируемости использовать безопасность родительской цепочки. Примером, который отлично подчеркивает вышеупомянутую концепцию, является Lightning Network – технология, которая использует безопасность Биткоин для увеличения общей пропускной способности системы.
Теперь, когда мы имеем дело с горизонтальным и вертикальным масштабированием, мы видим, что первое реализовано путем добавления большего количества кластеров или виртуальных машин в систему – для обработки растущей нагрузки транзакций. Вертикальное масштабирование, с другой стороны, достигается путем добавления большей вычислительной мощности (или памяти) к существующей виртуальной машине, чтобы повысить производительность.
Тем не менее, грядущее обновление Ethereum 2.0 вызвало много шумихи, поскольку оно стремится улучшить общую транзакционную мощность проекта с помощью ряда различных конструктивных изменений, причем одним из основных является разделение.
Внедрив эти изменения, базовая структура Ethereum будет перенесена из одной среды выполнения в несколько сред выполнения, которые будут проверять транзакции асинхронно и параллельно.
4. Когда использовать горизонтальное или вертикальное масштабирование?
Чистое вертикальное масштабирование ограничено по своей эффективности, но его относительно легко достичь. Горизонтальное масштабирование помогает улучшить общую пропускную способность системы, но требует больше времени для разработки.
Чтобы лучше понять проблему, можно проверить производительность системы в узких местах. Узкое место представляет собой ситуацию, в которой к конкретной системе предъявляется чрезмерный спрос, что приводит к серьезному влиянию на общую производительность платформы.
Например, если существует проблема с недостаточной локальной памятью виртуальной машины для обработки всех входящих транзакций, вертикальная шкала может помочь решить проблему – поскольку добавление дополнительной памяти в платформу может снизить общую нагрузку.
С другой стороны, если нагрузка входящей транзакции не может быть обработана существующим аппаратным обеспечением платформы, то, используя горизонтальный масштаб (то есть добавление дополнительных процессорных блоков), можно устранить проблему.
Чтобы проиллюстрировать вышеупомянутую концепцию в максимально простой форме, Джонатан Р. Брандт, руководитель инициатив по корпоративным технологиям, который вел курс по блокчейну, который в настоящее время преподает в различных государственных колледжах и университетах Миннесоты, сказал:
«В борьбе с преступностью Халк масштабируется вертикально, а Лига справедливости – горизонтально. В Биткоине сервер майнинга можно масштабировать по вертикали, увеличивая объем памяти или обновляя графический процессор, и он может масштабироваться по горизонтали, объединяя серверы ».
5. Существуют ли заслуживающие внимания решения по масштабированию блокчейнов?
За последние пару лет ряд компаний работали над решением проблем масштабируемости, которые мешают криптографическому сектору.
Новейшая технология, созданная vCPU: LiquidApps – это решение для горизонтального масштабирования, которое было разработано, чтобы позволить разработчикам получить доступ к большему количеству децентрализованных вычислительных ресурсов, поставляя задачи децентрализованным приложениям, поставщикам услуг (DApp) для чтения запросов по цепочке, выполнения обработки и возвращая результаты запрашивающему DApp. Одним из главных достоинств продажи vCPU является его способность позволить DApps выбирать уровень доверия, который подходит в соответствии с потребностями и требованиями конкретного варианта использования.
Другой пример – EOS. Основная цель EOS – решает многие существующие в отрасли проблемы масштабируемости. Основным отличием EOS от vCPU является его технология параллельной обработки, которая стала возможной благодаря использованию определенных элементов, связанных с вертикальным масштабированием (то есть добавлением вычислительной мощности).
С другой стороны, временный протокол Temtum гарантирует, что данные могут совместно использоваться узлами, даже если текущий узел не имеет необходимого пространства для хранения полного блокчейна – тем самым снижая барьер входа для новых узлов, присоединяющихся к сети.
Стоимость входа для участия в сети низка, поэтому количество ресурсов, необходимых для запуска узлов, невелико, что позволяет полностью использовать возможности незанятых узлов (что большинство криптовалют в настоящее время не могут сделать), увеличивая тем самым общую производительность.
Другие соответствующие примеры включают Ziliqa, ETH 2.0 и Iota.
6. Какие ключевые моменты следует помнить о масштабируемости?
Это все о централизации против децентрализации.
Для блокчейн платформ масштабируемость данной цепочки часто сводится к уровню децентрализации, которым обладает сеть. Сильно децентрализованные экосистемы (такие как Биткоин) работают довольно медленно, в то время как сети, которые являются более централизованными (например, EOS, с 21 блочным производителем), намного быстрее.
Поэтому, имея меньше узлов, производящих блоки, как правило, все становится быстрее. Однако централизация уменьшает интересные свойства, которыми изначально обладают блокчейны, а именно: их устойчивость к цензуре, прозрачность и общая неизменность.
Записки виртуального админа
Новости, обзоры и заметки о виртуальных машинах и платформах виртуализации.
вторник, 18 июня 2013 г.
Горизонтальное и вертикальное масштабирование. Взгляд со стороны бизнес приложений.
Это из-за того что ИТ отделы не доверяют платформам виртуализации? Считают ли они платформы виртуализации не достаточно стабильными для поддержки работы критически важных приложений?
За последние 10 лет VMware доказала что виртуализация это уже реальность, и, фактически, виртуализированные приложения часто более стабильны, когда работают на инфраструктуре под управлением VMware.
Тогда если доверие или стабильность не являются проблемой в чём же причина того что ИТ отделы еще не виртуализировали оставшиеся приложения?
Так как цены продолжают падать, а производительность расти то дешёвые, commodity (широкого потребления) сервера являются идеальным решением для горизонтального масштабирования, и могут быть собраны в большие кластера для объединения вычислительных ресурсов.
Последние семь лет архитекторы инфраструктур на VMware молились на горизонтальное масштабирование. Кто-то может аргументировать за использование именного этого подхода, но он тоже имеет свои нюансы, и всё зависит от требований бизнеса. Плюс горизонтального масштабирования в том, что commodity сервера дёшевы, и в случае выхода сервера из строя это влияет на небольшое количество ВМ. Минус в бОльших затратах на лицензии на vSphere, большие требования к площади ЦОД, и обычно такие commodity сервера не обладают большими вычислительными ресурсами.
Переход ко второй волне виртуализации, которая обеспечивает гибкость предоставляемую данной технологией для бизнес критических приложений, оказывает сегодня огромное давление на используемые сегодня инфраструктуры VMware из-за следующих проблем:
С выходом vSphere 5 количество ресурсов, доступных одной ВМ выросло в 4 раза.
А с выходом vSphere 5.1 монструозные ВМ могут быть еще монструознее.
Для того чтобы vSphere 5.1 могла запустить ВМ-монстра планировщику необходимо иметь и спланировать запуск потоков на 64 физических процессорах. Не так много серверов, которые могут поддерживать столько ядер, а серверов с поддержкой 16 сокетов и 160 ядер и того меньше.
Всего существует два типа вертикального масштабирования серверов: glueless и glued. На русский язык эти слова переводятся так: без интегрирующих технологий и с интегрирующими технологиями, соответственно.
Glueless архитектура
Данная архитектура была разработана в Intel, и представлена в Intel Xeon E7.
Для связи между устройствами ввода-вывода, сетевыми интерфейсами и процессорам используется специально разработанная шина QPI.
В серверах с 4-мя процессоров все они соединяются между собой напрямую через эту шину. Glueless процессор использует один из каналов для подключения процессора к интерфейсам ввода-вывода, а остальные три для подключения к соседним процессорам.
В 8-ми процессорном сервере каждый процессор напрямую подключается к трём соседним, и через другой процессор к другим четырём.
Основные приложения, производительность которых страдает от недостатков протокола QPI это Java приложения, большие БД, чувствительные к задержкам приложения.
Результатом вертикального масштабирования должно быть отсутствие бутылочного горлышка, иначе данная архитектура становится бессмысленной. Таким образом, линейность увеличения производительности должна соответствовать линейности добавления ресурсов.
Задержки между процессором и памятью в ccNUMA зависят от местоположения этих двух компонентов в отношении друг друга, в результате XNC контроллеры становятся критически важным компонентом сервера, и очень небольшое количество производителей серверов могут разработать сервера с возможностью вертикального масштабирования.