Масштабируемость

Способность системы справляться с возрастающим объемом работы.

Масштабируемость — это свойство системы справляться с растущим объемом работы. Одно из определений программных систем указывает, что это можно сделать путем добавления ресурсов в систему. ^[1]

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

В вычислениях масштабируемость является характеристикой компьютеров, сетей, алгоритмов , сетевых протоколов , программ и приложений. Примером может служить поисковая система , которая должна поддерживать растущее число пользователей и количество индексируемых ею тем . ^[3] Webscale — это компьютерный архитектурный подход, который привносит возможности крупных компаний, занимающихся облачными вычислениями, в корпоративные центры обработки данных. ^[4]

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

В математике масштабируемость в основном относится к замыканию при скалярном умножении .

В промышленном проектировании и производстве масштабируемость означает способность процесса, системы или организации справляться с растущей рабочей нагрузкой, адаптироваться к растущим требованиям и поддерживать операционную эффективность. Масштабируемая система может эффективно управлять увеличением объемов производства, созданием новых линеек продукции или расширением рынков без ущерба для качества и производительности. В этом контексте масштабируемость является жизненно важным фактором для компаний, стремящихся удовлетворить ожидания клиентов, оставаться конкурентоспособными и достичь устойчивого роста. Факторы, влияющие на масштабируемость, включают гибкость производственного процесса, адаптируемость рабочей силы и интеграцию передовых технологий. Внедряя масштабируемые решения, компании могут оптимизировать использование ресурсов, сократить расходы и оптимизировать свою деятельность. Масштабируемость в промышленном проектировании и производстве позволяет предприятиям реагировать на меняющиеся рыночные условия, извлекать выгоду из появляющихся возможностей и процветать в постоянно меняющемся глобальном ландшафте. ^{[ нужна цитата ]}

Примеры

Система управления инцидентами (ICS) используется агентствами экстренного реагирования в США. ICS может масштабировать координацию ресурсов от пожара на обочине дороги с одним двигателем до лесного пожара на межгосударственном уровне. Первый ресурс на месте происшествия устанавливает командование, наделенное полномочиями распоряжаться ресурсами и делегировать ответственность (управление пятью-семью офицерами, которые снова делегируют до семи офицеров, и так далее по мере развития инцидента). По мере развития инцидента командование принимают на себя более старшие офицеры. ^[5]

Размеры

Масштабируемость можно измерить по нескольким измерениям, например: ^[6]

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

Домены

• Протокол маршрутизации считается масштабируемым относительно размера сети, если размер необходимой таблицы маршрутизации на каждом узле растет как O (log N ), где N — количество узлов в сети. Некоторые ранние одноранговые (P2P) реализации Gnutella имели проблемы с масштабированием. Каждый запрос к узлу рассылал свои запросы всем узлам. Спрос на каждый пир увеличился пропорционально общему количеству пиров, быстро исчерпав их возможности. Другие P2P-системы, такие как BitTorrent, хорошо масштабируются, поскольку спрос на каждого узла не зависит от количества узлов. Ничто не централизовано, поэтому система может расширяться бесконечно без каких-либо ресурсов, кроме самих узлов.
• Масштабируемая онлайн-система обработки транзакций или система управления базами данных — это система, которую можно модернизировать для обработки большего количества транзакций путем добавления новых процессоров, устройств и хранилищ, и которую можно легко и прозрачно модернизировать, не выключая ее.
• Распределенная природа системы доменных имен (DNS) позволяет ей работать эффективно, обслуживая миллиарды хостов во всемирной сети Интернет .

Горизонтальное (уменьшение масштаба) и вертикальное масштабирование (увеличение масштаба).

Ресурсы делятся на две большие категории: горизонтальные и вертикальные. ^[7]

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

Горизонтальное масштабирование (из/внутрь) означает добавление дополнительных узлов в систему (или удаление узлов из нее), например добавление нового компьютера к распределенному программному приложению. Примером может быть масштабирование с одного веб-сервера до трех. Высокопроизводительные вычислительные приложения, такие как сейсмический анализ и биотехнологии , горизонтально масштабируют рабочие нагрузки для поддержки задач, которые когда-то требовали дорогих суперкомпьютеров . Другие рабочие нагрузки, такие как крупные социальные сети, превышают возможности крупнейшего суперкомпьютера и могут обрабатываться только масштабируемыми системами. Для использования этой масштабируемости требуется программное обеспечение для эффективного управления и обслуживания ресурсов. ^[6]

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

Вертикальное масштабирование (вверх/вниз) означает добавление ресурсов (или удаление ресурсов) из одного узла, обычно связанное с добавлением процессоров, памяти или хранилища на один компьютер. ^[6]

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

Масштабируемость сети

Виртуализация сетевых функций определяет эти термины по-разному: увеличение/уменьшение масштабирования — это возможность масштабирования путем добавления/удаления экземпляров ресурсов (например, виртуальной машины), тогда как масштабирование вверх/вниз — это возможность масштабирования путем изменения выделенных ресурсов (например, памяти/ЦП). /вместимость склада). ^[8]

Масштабируемость базы данных

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

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

Сильная и конечная согласованность (хранение)

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

Многие кластеры хранения данных с открытым исходным кодом и даже коммерческие масштабируемые кластеры хранения данных, особенно построенные на основе стандартного оборудования и сетей ПК, обеспечивают только итоговую согласованность, например некоторые базы данных NoSQL, такие как CouchDB и другие, упомянутые выше. Операции записи делают другие копии недействительными, но часто не ждут их подтверждения. Операции чтения обычно не проверяют каждую избыточную копию перед ответом, что может привести к пропуску предыдущей операции записи. Большой объем трафика сигналов метаданных потребует специализированного оборудования и коротких расстояний для обработки с приемлемой производительностью (т. е. действовать как некластеризованное устройство хранения или база данных). ^{[ нужна цитата ]}

Всякий раз, когда ожидается высокая согласованность данных, обратите внимание на эти индикаторы: ^{[ нужна ссылка ]}

• использование InfiniBand, Fibrechannel или аналогичных сетей с низкой задержкой, чтобы избежать снижения производительности при увеличении размера кластера и количества избыточных копий.
• короткие длины кабелей и ограниченная физическая протяженность, что позволяет избежать ухудшения характеристик во время прохождения сигнала.
• механизмы большинства/кворума, гарантирующие согласованность данных всякий раз, когда части кластера становятся недоступными.

Индикаторами для окончательно согласованных проектов (не подходящих для транзакционных приложений!) являются: ^{[ нужна ссылка ]}

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

Настройка производительности и аппаратная масштабируемость

Часто советуют сосредоточить внимание при проектировании системы на масштабируемости оборудования, а не на емкости. Обычно дешевле добавить новый узел в систему, чтобы добиться повышения производительности, чем участвовать в настройке производительности для увеличения мощности, с которой может справиться каждый узел. Но этот подход может иметь уменьшающуюся отдачу (как обсуждается в разделе «Проектирование производительности» ). Например: предположим, что 70% программы можно ускорить, если ее распараллелить и запустить на нескольких процессорах вместо одного. Если это часть вычислений, которая является последовательной, и это часть, которую можно распараллелить, максимальное ускорение , которого можно достичь с помощью процессоров P, определяется в соответствии с законом Амдала : ${\displaystyle \alpha }$ ${\displaystyle 1-\alpha }$

${\displaystyle {\frac {1}{\alpha +{\frac {1-\alpha }{P}}}}.}$

Подстановка значения для этого примера с использованием 4 процессоров дает

${\displaystyle {\frac {1}{0.3+{\frac {1-0.3}{4}}}}=2.105.}$

Удвоение вычислительной мощности до 8 процессоров дает

${\displaystyle {\frac {1}{0.3+{\frac {1-0.3}{8}}}}=2.581.}$

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

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

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

• Сильное масштабирование определяется как изменение времени решения в зависимости от количества процессоров при фиксированном общем размере задачи.
• Слабое масштабирование определяется как изменение времени решения в зависимости от количества процессоров при фиксированном размере задачи на процессор . ^[10]

Смотрите также

• Теория сложности вычислений
• Расширяемость
• Закон Густавсона
• Список атрибутов качества системы
• Балансировка нагрузки (вычисления)
• Лок (информатика)
• NoSQL
• Масштабируемое кодирование видео (SVC)
• Сходство (модель)
• Масштаб (аналитический инструмент)

Рекомендации

1. Бонди, Андре Б. (2000). Характеристики масштабируемости и их влияние на производительность . Материалы второго международного семинара по программному обеспечению и производительности – WOSP '00. п. 195. дои : 10.1145/350391.350432. ISBN 158113195X.
2. Хилл, Марк Д. (1990). «Что такое масштабируемость?» (PDF) . Новости компьютерной архитектуры ACM SIGARCH . 18 (4): 18. дои : 10.1145/121973.121975. S2CID  1232925.и Дубок, Летисия; Розенблюм, Дэвид С.; Уикс, Тони (2006). Платформа для моделирования и анализа масштабируемости программных систем (PDF) . Материалы 28-й международной конференции по программной инженерии – ICSE '06. п. 949. дои : 10.1145/1134285.1134460. ISBN
    1595933751.
3. Лаудон, Кеннет Крейг; Трэвер, Кэрол Гуэрсио (2008). Электронная коммерция: бизнес, технологии, общество. Пирсон Прентис Холл/Pearson Education. ISBN 9780136006459.
4. «Почему будущее за веб-масштабированием» . Сетевой мир . 13 февраля 2020 г. Проверено 1 июня 2017 г.
5. Бигли, Грегори А.; Робертс, Карлин Х. (1 декабря 2001 г.). «Система управления инцидентами: организация высокой надежности для сложных и нестабильных задач». Журнал Академии менеджмента . 44 (6): 1281–1299. дои : 10.5465/3069401. ISSN  0001-4273.
6. Хешам Эль-Ревини и Мостафа Абд-эль-Барр (апрель 2005 г.). Усовершенствованная компьютерная архитектура и параллельная обработка. Джон Уайли и сыновья . п. 66. ИСБН 978-0-471-47839-3.
7. Майкл, Магед; Морейра, Хосе Э.; Шилоах, Дорон; Вишневский, Роберт В. (26 марта 2007 г.). Увеличение x уменьшение масштаба: пример использования Nutch/Lucene . 2007 Международный симпозиум IEEE по параллельной и распределенной обработке. п. 1. дои :10.1109/IPDPS.2007.370631. ISBN 978-1-4244-0909-9.
8. «Виртуализация сетевых функций (NFV); Терминология основных концепций NFV». Архивировано из оригинала (PDF) 11 мая 2020 г. Проверено 12 января 2016 г.
9. Садек Дроби (11 января 2008 г.). «Возможная последовательность Вернера Фогельса». ИнфоQ . Проверено 8 апреля 2017 г.
10. «Слабое масштабирование DL_POLY 3» . Департамент вычислительной науки и техники STFC. Архивировано из оригинала 7 марта 2014 года . Проверено 8 марта 2014 г.

Внешние ссылки

• Ссылки на разнообразные учебные ресурсы – страница курируется проектом memcached .
• Масштабируемое определение - Информационный проект Linux (LINFO)
• Масштаб в распределенных системах Б. Клиффорд Нойман, В: Чтения по распределенным вычислительным системам , IEEE Computer Society Press, 1994.