) Здравствуйте! Я Александр Макаров, и вы можете меня знать по фреймворку «Yii» — я один из его разработчиков. У меня также есть full-time работа — и это уже не стартап — Stay.com, который занимается путешествиями.

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

Что такое масштабирование, вообще? Это возможность увеличить производительность проекта за минимальное время путем добавления ресурсов.

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

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

Самый классный вопрос, который задают, — а зачем оно надо, если у меня все и на одном сервере прекрасно работает? На самом-то деле, надо проверить, что будет. Т.е., сейчас оно работает, но что будет потом? Есть две замечательные утилиты — ab и siege, которые как бы нагоняют тучу пользователей конкурента, которые начинают долбить сервер, пытаются запросить странички, послать какие-то запросы. Вы должны указать, что им делать, а утилиты формируют такие вот отчеты:

Главные два параметра: n — количество запросов, которые надо сделать, с — количество одновременных запросов. Таким образом они проверяют конкурентность.

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

Есть еще один параметр — Response time — время ответа, за которое в среднем сервер отдал страничку. Оно бывает разное, но известно, что около 300 мс — это норма, а что выше — уже не очень хорошо, потому что эти 300 мс отрабатывает сервер, к этому прибавляются еще 300-600 мс, которые отрабатывает клиент, т.е. пока все загрузится — стили, картинки и остальное — тоже проходит время.

Бывает, что на самом деле пока и не надо заботиться о масштабировании — идем на сервер, обновляем PHP, получаем 40% прироста производительности и все круто. Далее настраиваем Opcache, тюним его. Opcache, кстати, тюнится так же, как и APC, скриптом, который можно найти в репозитории у Расмуса Лердорфа и который показывает хиты и мисы, где хиты — это сколько раз PHP пошел в кэш, а мисы — сколько раз он пошел в файловую систему доставать файлики. Если прогнать весь сайт, либо запустить туда какой-то краулер по ссылкам, либо вручную потыкать, то у нас будет статистика по этим хитам и мисам. Если хитов 100%, а мисов — 0%, значит, все нормально, а если есть мисы, то надо выделить больше памяти, чтобы весь наш код влез в Opcache. Это частая ошибка, которую допускают — вроде Opcache есть, но что-то не работает…

Еще часто начинают масштабировать, но не смотрят, вообще, из-за чего все работает медленно. Чаще всего лезем в базу, смотрим — индексов нет, ставим индексы — все сразу залетало, еще на 2 года хватит, красота!

Ну, еще надо включить кэш, заменить apache на nginx и php-fpm, чтобы сэкономить память. Будет все классно.

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

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

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

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

На что нужно обращать внимание прямо сейчас при мониторинге? Это:

1. доступность, т.е. жив сервер, вообще, или нет;
2. нехватка ресурсов диска, процессора и т.д.;
3. ошибки.

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

Этот доклад - расшифровка одного из лучших выступлений на обучающей конференции разработчиков высоконагруженных систем за 2015 год.

Старьё! - скажите вы.
- Вечные ценности! - ответим мы. Добавить метки

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

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

Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.

К концу 2012 года более 50% приложений работающих на х86 платформе виртуализированы. Вместе с тем виртуализировано только 20% бизнес критических приложений.

Это из-за того что ИТ отделы не доверяют платформам виртуализации? Считают ли они платформы виртуализации не достаточно стабильными для поддержки работы критически важных приложений?

За последние 10 лет VMware доказала что виртуализация это уже реальность, и, фактически, виртуализированные приложения часто более стабильны, когда работают на инфраструктуре под управлением VMware.

Тогда если доверие или стабильность не являются проблемой в чём же причина того что ИТ отделы еще не виртуализировали оставшиеся приложения?

Scale out
Scale out или горизонтальное масштабирование - добавление новых ресурсов в инфраструктуру, например, серверов в кластер.

Так как цены продолжают падать, а производительность расти то дешёвые, commodity (широкого потребления) сервера являются идеальным решением для горизонтального масштабирования, и могут быть собраны в большие кластера для объединения вычислительных ресурсов.

Последние семь лет архитекторы инфраструктур на VMware молились на горизонтальное масштабирование. Кто-то может аргументировать за использование именного этого подхода, но он тоже имеет свои нюансы, и всё зависит от требований бизнеса. Плюс горизонтального масштабирования в том, что commodity сервера дёшевы, и в случае выхода сервера из строя это влияет на небольшое количество ВМ. Минус в бОльших затратах на лицензии на vSphere, большие требования к площади ЦОД, и обычно такие commodity сервера не обладают большими вычислительными ресурсами.

Scale up
Вертикальное масштабирование - добавление вычислительных ресурсов в какой-то уже используемый сервер. Обычно это процессоры или оперативная память.

Обычно такие сервера довольно мощные - с поддержкой 4 процессоров и 512ГБ памяти. Кроме того встречаются системы с 8 процессорами и 1ТБ памяти, а некоторым повезло увидеть даже 16-ти процессорные сервера с 4ТБ памяти. И нет, это не мейнфреймы или что-то типа того, это сервера на основе классической х86 архитектуры.

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

• Недостаточные возможности по масштабированию. Нагрузки с высокими требованиями к объёму вычислительных ресурсов являются проблемой из-за ограниченного объёма ресурсов доступных с дешёвыми commodity серверами.
• Недостаточная надёжность. Commodity оборудование или аппаратное обеспечение использующее такие компоненты может быть менее надёжным. Проблему надёжности можно решить с помощью функций о которых я расскажу в следующих статьях.
• Увеличение сложности управления и рост операционных расходов. Легче управлять 100 серверами, а не 1000, ну и, как следствие, 10 серверами управлять проще чем 100. Тоже самое касается и операционных расходов - 10 серверов гораздо дешевле поддерживать чем 100.

С выходом vSphere 5 количество ресурсов, доступных одной ВМ выросло в 4 раза.

А с выходом vSphere 5.1 монструозные ВМ могут быть еще монструознее.

Для того чтобы vSphere 5.1 могла запустить ВМ-монстра планировщику необходимо иметь и спланировать запуск потоков на 64 физических процессорах. Не так много серверов, которые могут поддерживать столько ядер, а серверов с поддержкой 16 сокетов и 160 ядер и того меньше.

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

Glueless архитектура
Данная архитектура была разработана в Intel, и представлена в Intel Xeon E7.

Для связи между устройствами ввода-вывода, сетевыми интерфейсами и процессорам используется специально разработанная шина QPI.

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

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

Преимущества такой архитектуры:

• Нет необходимости в специальной разработке или специализации у производителя серверов
• Любой производитель серверов может выпускать 8-ми процессорные сервера
• Снижается стоимость как 4-ёх так и 8-ми процессорного сервера

• Общая стоимость владения растёт при горизонтальном масштабировании
• Архитектура ограничена 8-ми процессорными серверами
• Тяжело поддерживать целостность кэша при увеличении сокетов
• Нелинейный рост производительности
• Соотношение цены к производительности падает
• Неоптимальная эффективность при использовании больших ВМ
• Вплоть до 65% пропускной способности шины уходит на широковещательные сообщения болтливого протокола QPI

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

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

Glued архитектура
Для решения описанных выше проблем разработчики аппаратного обеспечения разработали glued архитектуру. Данная архитектура использует внешний контроллер нод для организации взаимосвязи островков QPI - кластеров процессоров.

Intel QPI предлагает специальное масштабируемое решение - eXternal Node-Controllers (или XNC), практическая реализация которого разрабатывается сторонними OEM компаниями. Внешний контроллер нод, используемый начиная с Intel Xeon E7-4800, со встроенным контроллером памяти, включает в себя также систему Cache Coherent Non-Uniform Memory Access (ccNUMA) задача которой отслеживать актуальность данных в каждой строке памяти процессорного кэша были актуальные данные.

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

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

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

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

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

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

Разбиение системы на более мелкие структурные компоненты и разнесение их по отдельным физическим машинам (или их группам) и/или увеличение количества серверов параллельно выполняющих одну и ту же функцию.

Примечания

См. также

Ссылки

Wikimedia Foundation . 2010 .

Смотреть что такое "Масштабируемость" в других словарях:

масштабируемость - расширяемость Характеристика приложения, которое исполняется на разных платформах и варьируется в размерах (например, на PC под Windows и на рабочей станции Sun под Unix). Для аппаратных средств предсказуемый рост системных характеристик при… …

масштабируемость - 3.1.43 масштабируемость (scalability): Способность обеспечивать функциональные возможности вверх и вниз по упорядоченному ряду прикладных платформ, отличающихся по быстродействию и ресурсам. Источник … Словарь-справочник терминов нормативно-технической документации

Способность программного обеспечения корректно работать на малых и на больших системах с производительностью, которая увеличивается пропорционально вычислительной мощности системы. По английски: Scalability См. также: Открытые системы Программное … Финансовый словарь

масштабируемость системы (в SCADA) - масштабируемость системы [Интент] Масштабируемость системы. Это означает, что разработанный проект можно опробовать на одном компьютере или маленькой сети и затем расширять систему (в соответствии с программой развития, бюджетом и т. д.) без… … Справочник технического переводчика

масштабируемость (в информационных технологиях) - Способность ИТ услуги, процесса, конфигурационной единицы и т.п., выполнять свою ранее согласованную функцию, в случае изменения рабочей нагрузки или охвата. [Словарь терминов ITIL версия 1.0, 29 июля 2011 г.] EN scalability The ability of an IT… … Справочник технического переводчика

масштабируемость (приложения) - масштабируемость расширяемость Характеристика приложения, которое исполняется на разных платформах и варьируется в размерах (например, на PC под Windows и на рабочей станции Sun под Unix). Для аппаратных средств предсказуемый рост системных… … Справочник технического переводчика

масштабируемость (сети и системы связи) - Критерий экономически эффективной системы автоматизации подстанции, учитывающий различные функциональные характеристики, различные интеллектуальные электронные устройства, размер подстанции и диапазоны напряжений подстанции. [ГОСТ Р 54325 2011… … Справочник технического переводчика

масштабируемость в широких пределах - — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN terabyte scalability … Справочник технического переводчика

горизонтальная масштабируемость - Наращивание мощности системы добавлением узлов в кластер. Тематики информационные технологии в целом EN horizontal scalability … Справочник технического переводчика

SCALABILITY - масштабируемость - один из основных принципов построения открытых систем, гарантирует сохранение инвестиций в информацию и ПО при переходе на более мощную аппаратную платформу … Словарь электронного бизнеса

Книги

• Microsoft SharePoint 2010. Полное руководство , Майкл Ноэл, Колин Спенс. В книге рассматриваются все новые возможности SharePoint - от новых компонентов социальных сетей до усовершенствованного поиска - которые помогают максимально задействовать как SharePoint…

Горизонтальное масштабирование серверов баз данных для OLTP-систем, или что есть на рынке

• Администрирование баз данных ,
• Серверная оптимизация

Как правило, в крупных и средних компаниях существуют высоконагруженные транзакционные информационные системы, которые являются важнейшей составляющей бизнеса, их называют OLTP-системами. С ростом бизнеса нагрузка увеличивается очень быстро, поэтому задача увеличения производительности имеющихся ресурсов под серверы баз данных, стоит очень остро. Зачастую для решения задачи увеличения производительности серверов баз данных приобретается более мощное оборудования (так называемое «вертикальное» масштабирование), но этот способ имеет очень существенный минус: компания рано или поздно купит сервер баз данных максимальной производительности по приемлемой цене, и что делать дальше? Дальше перспективы для бизнеса могут быть не такие радужные – во многих случаях речь идет об ухудшении репутации компании, невозможности обслужить клиентов в моменты повышенного спроса, значительной потере прибыли.

Для исключения подобных ситуаций и обеспечения работоспособности OLTP-систем многие компании идут по пути «горизонтального» масштабирования серверов баз данных. В отличие от наращивания производительности основного сервера («вертикальное» масштабирование) при «горизонтальном» масштабировании серверы объединяются в кластер (набор), и нагрузка на серверы БД распределяется между ними. Этот подход более технологичный, так как кроме очевидных преимуществ в виде возможности увеличения производительности путем добавления новых серверов, решается задача достижения отказо- и катастрофоустойчивости.

Многие ИТ-компании в России и мире занимаются разработкой подобных решений, ниже я попытаюсь рассказать о них более подробно.

Первое решение - Oracle RAC (Real Application Cluster - появилось еще в далеком 2001 году в версии 9i для повышения доступности и производительности в высоконагруженных системах на базе СУБД Oracle. Оно позволяет распределить нагрузку на высоконагруженную базу данных между серверами БД и тем самым увеличить возможности OLTP-системы по беспроблемному росту информационных потоков. Для получения более подробной информации можно обратиться к документации или книгам издательства Oracle Press. Поэтому остановлюсь на некоторых моментах, интересных с точки зрения принципа работы.

Т.к. в Oracle RAC реализована архитектура Shared-everything (со всеми присущими ей преимуществами и недостатками), то для каждого сервера в Oracle RAC существует свой кэш, в который попадают данные SQL запросов, выполненных на нём. Также существует глобальный кэш кластера, реализованный с помощью технологи Cache Fusion, который синхронизируется с локальными кэшами серверов по данным. Особую роль в координации ресурсов кластера и объединения кэша играет структура данных Global Resource Directory, в которой фиксируется на каком сервере, какие данные и по каким объектам актуальны; какой режим блокировок для объекта на экземпляре. Вся эта информация помогает принять решение, на какой сервер с точки зрения производительности лучше отправить запрос SQL, так как в случае неправильного решения время запроса SQL увеличится за счет времени на синхронизацию данных между кэшами.

Важная особенность такого подхода к распределению нагрузки между серверами БД - необходимость учета «разнообразия» траффика SQL от OLTP-системы. В случаях, когда запросы SQL извлекают данные из многих таблиц одновременно, и интенсивность изменения в этих таблицах большая, возможна потеря времени на синхронизацию данных кэша между различными серверами кластера (именно по этой причине нужен быстрый и надежный interconnect между серверами). Это, в свою очередь, может привести к ухудшению отклика OLTP-системы, и преимущества от использования Oracle RAC могут быть полностью нивелированы.

Плюсы:

• Active/Active кластер
• Балансировка нагрузки
• Масштабирование с увеличением производительности, но и увеличением доступности
• Практически линейное увеличение производительности при добавлении новых узлов в кластер
• «Прозрачное» для приложений масштабирование

Минусы:

• Работает только с СУБД Oracle
• Для работы желателен высокопроизводительный interconnect с низкими задержками
• СХД может быть единой точкой отказа. Для обеспечения высокого уровня отказоустойчивости RAC нужно комбинировать со standby или зеркалированием СХД.

Второе решение - Citrix NetScaler – реализует горизонтальное масштабирование серверов БД для OLTP-систем на базе MS SQL Server и MySQL иначе, чем Oracle RAC. С техническими особенностями можно ознакомиться, пройдя по ссылке .

Если в Oracle RAC серверы баз данных синхронизируются автоматически, то Citrix NetScaler для синхронизации должен использовать сторонние технологии: AlwaysOn от Microsoft, MySQL replication. Само же решение Citrix NetScaler является прокси-сервером между уровнем приложения (сервер приложения, web-сервер) и серверами баз данных, таким образом все запросы SQL к серверу БД проходят через него.

По спецификации решение умеет распознавать сигнатуру запросов SQL (на чтение или запись данных) и перенаправлять их на нужные (определенные настройками) сервера в кластере. Задержка на обработку запроса SQL прокси-сервером минимальна, поэтому отклик OLTP-системы не должен ухудшиться после внедрения. Несмотря на этот плюс, возможности для балансировки нагрузки от запросов SQL также зависят от особенностей траффика OLTP-системы. Во многих OLTP-системах измененные данные в транзакции сразу считываются следующим запросом SQL для дальнейшей работы. Учитывая особенности такой технологии, как например MS AlwaysOn, данные на дополнительных серверах отстают от основного на некоторое время (в синхронном и асинхронном режиме). Без учета этого факта приложение и пользователь могут получить ситуацию, при которой добавленные данные будут отсутствовать в выборке следующего запроса SQL. Как правило, технологию Citrix NetScaler рекомендуют использовать не в автоматическом режиме, а в ручном, поэтому сфера ее применения ограничивается несложными запросами к БД в веб-приложениях.

Третья технология - Softpoint Data Cluster – российская разработка, которая схожа с двумя предыдущими, при этом в ряде моментов более применима к практическим задачам по «горизонтальному» масштабированию серверов баз данных для OLTP- систем. Более подробную информацию о продукте можно найти на сайте вендора .

Технология на первый взгляд похожа на Citrix NetScaler, так как представляет собой прокси-сервер между уровнем приложения и уровнем базы данных, а также тесно интегрирована с технологиями синхронизации БД (например, MS AlwaysOn), но в отличие от Citrix NetScaler отслеживает рассинхронизации серверов БД в кластере и полностью гарантирует непротиворечивость данных в выборках, где бы на серверах ни выполнялся запрос SQL. Эта особенность позволяет без адаптации к трафику приложения обеспечить автоматическую балансировку нагрузки.

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