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

Организационные сложные системы map.jpg
Комплексные системы
Темы

Масштабируемость это свойство системы обрабатывать растущий объем работы путем добавления ресурсов в систему.[1]

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

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

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

Примеры

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

Размеры

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

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

Домены

  • А протокол маршрутизации считается масштабируемым по отношению к размеру сети, если размер необходимого таблица маршрутизации на каждом узле растет как О (бревно N), где N количество узлов в сети. Некоторые ранние пиринговый (P2P) реализации Гнутелла были проблемы с масштабированием. Запрос каждого узла затоплен его запросы ко всем узлам. Спрос на каждый одноранговый узел увеличивался пропорционально общему количеству одноранговых узлов, быстро превышая их возможности. Другие системы P2P, такие как BitTorrent хорошо масштабируется, потому что спрос на каждого однорангового узла не зависит от количества одноранговых узлов. Ничто не является централизованным, поэтому система может неограниченно расширяться без каких-либо ресурсов, кроме самих узлов.
  • Масштабируемый онлайн-обработка транзакций система или система управления базами данных Это тот, который можно обновить для обработки большего количества транзакций, добавив новые процессоры, устройства и хранилище, и который можно обновить легко и прозрачно, не выключая его.
  • Распределенный характер система доменных имен позволяет ему работать эффективно, обслуживая миллиарды хозяева по всему миру Интернет.

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

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

По горизонтали или по горизонтали

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

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

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

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

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

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

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

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

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

Сильная или возможная согласованность (хранение)

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

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

Если ожидается высокая согласованность данных, ищите следующие индикаторы:

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

Индикаторы для в конечном итоге согласованных проектов (не подходящих для транзакционных приложений!):

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

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

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

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

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

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

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

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

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

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

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

  1. ^ Бонди, Андре Б. (2000). Характеристики масштабируемости и их влияние на производительность. Труды второго международного семинара по программному обеспечению и производительности - WOSP '00. п. 195. Дои:10.1145/350391.350432. ISBN  158113195X.
  2. ^ Хилл, Марк Д. (1990). «Что такое масштабируемость?». Новости компьютерной архитектуры 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). Электронная коммерция: бизнес, технологии, общество. Пирсон Прентис Холл / Пирсон Образование. ISBN  9780136006459.
  4. ^ «Почему будущее за веб-масштабированием». Сетевой мир. 2020-02-13. Получено 2017-06-01.
  5. ^ Бигли, Грегори А .; Робертс, Карлин Х. (2001-12-01). «Система управления инцидентами: высоконадежная организация для сложных и нестабильных рабочих сред». Журнал Академии Менеджмента. 44 (6): 1281–1299. Дои:10.5465/3069401. ISSN  0001-4273.
  6. ^ а б c Хешам эль-Ревини и Мостафа Абд-эль-Барр (апрель 2005 г.). Расширенная компьютерная архитектура и параллельная обработка. Джон Уайли и сыновья. п. 66. ISBN  978-0-471-47839-3.
  7. ^ Майкл, Магед; Moreira, Jose E .; Шилоах, Дорон; Вишневски, Роберт В. (26 марта 2007 г.). Масштабирование x Масштабирование: пример использования Nutch / Lucene. 2007 Международный симпозиум по параллельной и распределенной обработке IEEE. п. 1. Дои:10.1109 / IPDPS.2007.370631. ISBN  978-1-4244-0909-9.
  8. ^ «Виртуализация сетевых функций (NFV); терминология основных концепций в NFV» (PDF).[мертвая ссылка ]
  9. ^ Садек Дроби (11 января 2008 г.). «Конечная последовательность Вернера Фогельса». InfoQ. Получено 8 апреля, 2017.
  10. ^ «Слабое масштабирование DL_POLY 3». STFC Департамент вычислительной науки и техники. Архивировано из оригинал 7 марта 2014 г.. Получено 8 марта, 2014.

внешняя ссылка