Что такое масштабируемость по рабочим местам

Опубликовано: 17.09.2024

Масштабируемость 1С Предприятия 8 предполагает уменьшение зависимости производительности системы от внешней нагрузки (числа одновременно работающих пользователей, оформляемой документации и объема хранимых данных). Иными словами, масштабируемость означает более высокую производительность системы при том же уровне нагрузки.

Факторы, влияющие на производительность программ 1C

На производительность программ 1с шказывает влияние целый спектр факторов. Основные из них:

Способ работы с информационной базой - клиент-серверный или файловый.

Число одновременно работающих пользователей. При работе одновременно до 11 пользователей – допустим файловый вариант работы, более 11 – клиент-серверный (PostgreSQL или MSSQLServer).

Объем информационной базы. При расширении информационной базы необходимо перейти на клиент-серверный способ работы. Кроме того, для увеличения производительности 1с рекомендуется применять дисковую подсистему на сервере информационной базы данных FC или SAS.

Пропускная способность локальной вычислительной сети. Необходимую производительность обеспечивает класс 100Mbit и выше.

Характеристики аппаратной части сервера и рабочего места пользователя.

Цели тестирования

Одной из задач, которые решались при разработке 1С:Предприятия 8.1, являлось повышение производительности и масштабируемости системы. При этом учитывался опыт использования 1С:Предприятия 8 на больших внедрениях и результаты многочисленных нагрузочных испытаний системы в различных режимах.

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

В частности, была проведена оптимизация:

Работы встроенного языка

Внутренней параллельности сервера 1С:Предприятия

Обмена данными между клиентом и сервером 1С:Предприятия

Алгоритмов записи движений документов

Кроме того была значительно переработана архитектура системы в клиент-серверном варианте работы – реализован кластер серверов 1С:Предприятия, использование которого позволяет распределить нагрузку между несколькими серверными рабочими процессами (в том числе расположенными на различных компьютерах) и таким образом повысить общую масштабируемость системы.

Настоящее тестирование 1c проводилось с целью оценки достигнутых показателей производительности и масштабируемости 1С:Предприятия 8.1 в различных условиях.

Были проведены следующие тесты:

Оценка производительности и масштабируемости системы при одновременной работе большого количества пользователей

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

Оценка производительности на отдельных видах операций

Полученные показатели 1С:Предприятия 8.1 сравнивались с аналогичными показателями для 1С:Предприятия 8.

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

Общие результаты тестирования

1С:Предприятие 8.1 продемонстрировало значительное улучшение показателей производительности на всех проведенных тестах.

Тест

Улучшение
(раз)

Масштабируемость при работе большого количества пользователей

Общая пропускная способность системы

до 1.5

Масштабируемость при пиковых нагрузках

Общая пропускная способность системы

до 2.3

Время проведения документа

до 2.4

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

Общая пропускная способность системы

до 3.8

Время проведения документа

до 3.8

Показатели производительности на отдельных операциях

Запись и проведение документа

до 1.6

до 1.8

до 4

Объем занимаемой оперативной памяти

до 1.4

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

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

В данном тесте оценивалась масштабируемость системы 1с предприятие 8 при одновременной работе большого количества пользователей, то есть ее способность справляться с поступающим объемом информации за приемлемое время.

При заданных условиях тестирования 1С:Предприятие 8.1 продемонстрировало значительное улучшение показателей производительности и масштабируемости по сравнению с 1С:Предприятием 8. Так пропускная способность системы при одновременной работе 200 пользователей выросла почти в 1.5 раза, а время записи и проведения документа составило менее 3.5 секунд.

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

Условия тестирования

Тестирование проводилось на примере документа РеализацияТоваровУслуг типовой конфигурации УПП 1.2. При помощи 1С:ТестЦентра был описан многопользовательский сценарий тестирования со следующими параметрами:

Количество одновременно работающих пользователей: от 1 до 200
Выполняемая операция: создание и проведение нового документа РеализацияТоваровУслуг
Количество строк в табличной части «Товары»: 20
Каждый тестовый пользователь создает документы со своим уникальным набором товаров, то есть все движения документов записываются параллельно, не приводя к блокировкам.
Количество строк в табличной части «Услуги»: 0
Пользователи вводят документы с паузой 60 секунд
Расчет себестоимости списываемых товаров не производится (в выбранном режиме используется механизм регламентного расчета себестоимости).

Следует отметить, что смоделированная нагрузка на систему значительно превышает нагрузку, которая наблюдается в реальных условиях. По результатам опроса обычный пользователь вводит в среднем 300 строк документа в час. В данном тесте при одновременной работе 200 пользователей на 1С:Предприятии 8.1 тестовый пользователь вводил 965 строк в час, то есть интенсивность его работы была выше в 3.2 раза.

Во время проведения документа система выполняла следующие действия:

Движения по разделам управленческого учета:
- Взаиморасчеты с контрагентами: увеличение фактической задолженности контрагента
- Продажи: увеличение объема продаж по предприятию
- Списание товара со склада предприятия с контролем достаточности остатка товаров
- Снятие резерва, выполненного под заказ покупателя с контролем достаточности резерва
- Списание товара принадлежащего организации с контролем достаточности остатка товаров
- Расчеты с контрагентами: увеличение оперативной задолженности контрагента
- Движения по регистрам подсистемы НДС
- Формирование проводок по бухгалтерскому и налоговому учету:
  - По выручке (бухгалтерский и налоговый учет)
  - По НДС (бухгалтерский учет)
  - По взаиморасчетам (бухгалтерский учет)
  - По суммовым разницам (бухгалтерский и налоговый учет)
  - По курсовым разницам (бухгалтерский учет)
  При проведении тестирования измерялись следующие показатели производительности:
  - Фактическая пропускная способность системы – количество строк документов, обработанных системой в единицу времени.
  - Среднее время записи и проведения одного документа
  Тестирование проводилось на следующем тестовом стенде:
  - Сервер 1С:Предприятия:
    - Процессоры: 2 * Intel Xeon MP, 2800 МГц
    - Оперативная память: 4 096 Мб
    - Дисковая подсистема: 2 * Ultra320 SCSI RAID 0 (stripe)
    - Процессоры: 2 * DualCore Intel Xeon, 2666 МГц
    - Оперативная память: 8 192 Мб
    - Дисковая подсистема: 6 дисков в режиме Ultra320 SCSI RAID 0 (stripe)
    Результаты
    
    Масштабируемость системы характеризуется объемом информации, которая может быть обработана системой в единицу времени. При увеличении количества одновременно работающих пользователей, объем обработанной информации должен пропорционально возрастать при сохранении приемлемого времени выполнения операции. То есть, система должна справляться с растущей нагрузкой.
    
    Рассмотрим диаграмму зависимости количества строк документов, обрабатываемых системой в единицу времени, от количества одновременно работающих тестовых пользователей для 1С:Предприятия 8 и 8.1:
    
    При одновременной работе 200 тестовых пользователей на данном тесте пропускная способность системы на платформе 1С:Предприятие 8.1 составила более 190 000 строк документов в час, что почти в 1.5 раза выше соответствующего показателя для 1С:Предприятия 8.
    
    1С:Предприятие 8.1 уверенно справляется с этой нагрузкой и не достигает предела общей пропускной способности при данных условиях тестирования. Система демонстрирует устойчивую тенденцию к дальнейшему росту общей пропускной способности при увеличении количества одновременно работающих пользователей.
    
    Рассмотрим эту же зависимость в пересчете на одного тестового пользователя системы – диаграмму относительной пропускной способности.
    
    При увеличении количества одновременно работающих пользователей в 10 раз (с 20 до 200) относительная пропускная способность системы на платформе 1С:Предприятие 8.1 уменьшается всего на 4.6%. То есть, подключение к системе новых пользователей практически не отражается на общей производительности системы.
    
    Другим важным показателем производительности является среднее время записи и проведения документа. При увеличении количества одновременно работающих пользователей это время должно оставаться в приемлемых пределах для того, чтобы обеспечить комфортную работу пользователей системы и соответствие требованиям бизнес-процессов автоматизируемого предприятия.
    
    Рассмотрим диаграмму зависимости среднего времени записи и проведения документа от количества одновременно работающих тестовых пользователей для 1С:Предприятия 8 и 8.1:
    
    При одновременной работе 200 тестовых пользователей на данном тесте среднее время записи и проведения одного документа составило 3.47 секунды.
    
    Таким образом, 1С:Предприятие 8.1 демонстрирует значительно лучшую масштабируемость по сравнению с предыдущей версией на тесте с параллельным вводом документов большим количеством пользователей.
    
    Производительность и масштабируемость при пиковых нагрузках
    
    В данном тесте оценивалась работа системы в режиме пиковых нагрузок. Интенсивность работы тестовых пользователей в заданных условиях значительно превышает возможности реальных пользователей. Однако именно такое тестирование позволяет наиболее наглядно оценить результаты оптимизации, а так же эффект от использования новых возможностей платформы.
    
    В условиях пиковой нагрузки 1С:Предприятие 8.1 продемонстрировало значительное улучшение показателей производительности по сравнению с 1С:Предприятием 8. Пропускная способность системы выросла в 2.3 раза, а среднее время проведения одного документа сократилось в 2.4 раза.
    
    С точки зрения повышения масштабируемости крайне важно иметь возможность распределять нагрузку в системе. В 1С:Предприятии 8 можно было распределять нагрузку между клиентами и сервером предприятия. В версии 8.1 к этому добавилась возможность распределения нагрузки между несколькими рабочими процессами 1С:Предприятия - в том числе, находящимися на разных компьютерах сети.
    
    Для оценки эффекта от использования кластера серверов, тестирование в условиях пиковой нагрузки было проведено для кластера из 2-х рабочих процессов 1С:Предприятия 8.1, расположенных на разных компьютерах. В этом тесте пропускная способность системы на платформе 8.1 по сравнению с 8 выросла в 3.8 раз, а время проведения документа сократилось во столько же.
    
    Условия тестирования
    
    Тестирование проводилось на примере документа РеализацияТоваровУслуг типовой конфигурации УПП 1.2. Параметры данного теста были идентичны предыдущему за следующими исключениями:
    - Количество одновременно работающих пользователей: 20
    - Пользователи вводят документы без паузы
    - Количество строк в табличной части «Товары»: 5
    Тестирование проводилось на следующем тестовом стенде:
    - Сервер 1С:Предприятия (для работы без кластера и для процесса 1 в кластере):
      - Процессор: DualCore Intel Xeon MP, 3000 МГц
      - Оперативная память: 8 192 Мб
      - Дисковая подсистема: 4 * Ultra320 SCSI RAID 0 (stripe)
      - Процессор: 2 * Intel Xeon MP, 2800 МГц
      - Оперативная память: 8 192 Мб
      - Дисковая подсистема: 8 * Ultra320 SCSI RAID 0 (stripe)
      - Процессоры: 2 * DualCore Intel Xeon, 2666 МГц
      - Оперативная память: 8 192 Мб
      - Дисковая подсистема: 6 дисков в режиме Ultra320 SCSI RAID 0 (stripe)
      Результаты
      
      Тестирование 1С Предприятие 8 на пиковых режимах позволяет оценить ее работоспособность и производительность в ситуации резкого увеличения нагрузки до предельных значений. Хорошо мастабируемая система в таких условиях должна демонстрировать устойчивую работу и приемлемое время выполнения операций.
      
      Рассмотрим диаграмму фактической пропускной способности системы (строк документов в час) при использовании 1С:Предприятия 8, 1С:Предприятия 8.1 без использования кластера и 1С:Предприятия 8.1 с использованием кластера из 2 рабочих процессов.
      
      Масштабируемость — это способность системы адаптироваться к расширению предъявляемых требований и возрастанию объемов решаемых задач.
      
      Работа одного прикладного решения в разных условиях
      
      Система «1С:Предприятие 8» имеет хорошие возможности масштабирования. Она позволяет работать как в файловом варианте, так и с использованием технологии «клиент-сервер».
      
      При работе в файловом варианте платформа может работать с локальной информационной базой, расположенной на том же компьютере, на котором работает пользователь. Такой вариант работы может использоваться в домашних условиях или при работе на ноутбуке.
      
      Файловый вариант также обеспечивает возможность работы по локальной сети нескольких пользователей с одной информационной базой. Такой способ работы может использоваться в небольших рабочих группах, он прост в установке и эксплуатации.
      
      Для больших рабочих групп и в масштабах предприятия может применяться клиент-серверный вариант работы, основанный на трехуровневой архитектуре с использованием кластера серверов «1С:Предприятия 8» и отдельной системы управления базами данных. Он обеспечивает надежное хранение данных и их эффективную обработку при одновременной работе большого количества пользователей.
      
      Крупные холдинговые компании могут использовать работу в распределенной информационной базе, сочетающуюся с применением как файлового, так и клиент-серверного вариантов работы. Распределенная информационная база позволяет объединить удаленные друг от друга подразделения холдинга, а каждое из этих подразделений может использовать, в свою очередь, файловый или клиент-серверный варианты работы. Механизм распределенной информационной базы будет обеспечивать идентичность конфигураций, используемых в каждом из подразделений холдинга, и осуществлять обмен данными между отдельными информационными базами, входящими с состав распределенной системы.
      
      Важно отметить, что одни и те же прикладные решения (конфигурации) могут использоваться как в файловом, так и в клиент-серверном варианте работы. При переходе от файлового варианта к технологии «клиент-сервер» не требуется вносить изменения в прикладное решение. Поэтому выбор варианта работы целиком зависит от потребностей заказчика и его финансовых возможностей. На начальной стадии можно работать в файловом варианте, а затем с увеличением количества пользователей и объема базы данных можно легко перейти на клиент-серверный вариант работы со своей информационной базы.
      
      Многопользовательская работа
      
      Одним из основных показателей масштабируемости системы является возможность эффективной работы при увеличении количества решаемых задач, объема обрабатываемых данных и количества интенсивно работающих пользователей.
      
      В варианте клиент-сервер обеспечивается возможность параллельной работы большого количества пользователей. Как показывают тесты, с ростом числа пользователей скорость ввода документов уменьшается очень медленно. Это означает, что при увеличении количества интенсивно работающих пользователей скорость реакции автоматизированной системы остается на приемлемом уровне.
      
      В модели данных, поддерживаемой системой «1С:Предприятие 8», не существует таблиц базы данных, однозначно приводящих к конкурентному доступу со стороны нескольких пользователей. Конкурентный доступ возникает только при обращении к логически связанным данным и не затрагивает данные, не связанные между собой с точки зрения предметной области.
      
      При выполнении регламентных операций исключены ситуации, когда для начала работы в некотором отчетном периоде требуется установка монопольного режима. Регламентные операции могут выполняться в удобные для пользователей и организации моменты времени. Монопольный режим устанавливается не при запуске системы, а в тот момент, когда необходимо выполнение операции, требующей его включения. После выполнения таких операций монопольный режим может быть отключен.
      
      Механизмы оптимизации
      
      Технологическая платформа «1С:Предприятия 8» содержит ряд механизмов, оптимизирующих скорость работы прикладных решений.
      
      Управление блокировками в транзакции
      
      Режим управляемых блокировок в транзакции позволяет управлять блокировками данных в терминах предметной области и повышает параллельность работы пользователей. Подробнее…
      
      Выполнение на сервере
      
      В варианте клиент-сервер использование сервера «1С:Предприятия 8» позволяет сосредоточить на нем выполнение наиболее объемных операций по обработке данных. Например, при выполнении даже весьма сложных запросов программа, работающая у пользователя, будет получать только необходимую ей выборку, а вся промежуточная обработка будет выполняться на сервере. Обычно увеличить мощность сервера гораздо проще, чем обновить весь парк клиентских машин.
      
      Кэширование данных
      
      Система «1С:Предприятие 8» использует механизм кэширования данных, считанных из базы данных при использовании объектной техники. При обращении к реквизиту объекта выполняется чтение всех данных объекта в кэш, расположенный в оперативной памяти. Последующие обращения к реквизитам того же объекта будут направляться уже в кэш, а не в базу данных, что значительно сокращает время, затрачиваемое на получение нужных данных.
      
      Работа встроенного языка на сервере
      
      При работе в клиент-серверном варианте вся работа прикладных объектов выполняется только на сервере. Функциональность форм и командного интерфейса также реализована на сервере.
      
      На сервере выполняется подготовка данных формы, расположение элементов, запись данных формы после изменения. На клиенте отображается уже подготовленная на сервере форма, выполняется ввод данных и вызовы сервера для записи введенных данных и других необходимых действий.
      
      Аналогично командный интерфейс формируется на сервере и отображается на клиенте. Также и отчеты формируются полностью на сервере и отображаются на клиенте.
      
      Примеры технологических параметров внедрений решения «Управление производственным предприятием»
      
      В этом разделе публикуется развернутая информация о технологических параметрах внедрений «1C:Предприятие 8. Управление производственным предприятием» на предприятиях различного масштаба и профиля деятельности.
      
      Цель раздела — ознакомить ИТ- специалистов с данными о реально используемом оборудовании и с примерами нагрузки реальных внедрений «1С:Предприятия 8».
      
      Также эта информация может быть полезна и для пользователей всех программ системы «1С:Предприятие 8».
      
      1С:Центр управления производительностью — инструмент мониторинга и анализа производительности
      
      1С:Центр управления производительностью (1С:ЦУП) — инструмент мониторинга и анализа производительности информационных систем на платформе «1С:Предприятие 8». 1С:ЦУП предназначен для оценки производительности системы, сбора подробной технической информации об имеющихся проблемах производительности и анализа этой информации с целью дальнейшей оптимизации. Подробнее…
      
      1С:ТестЦентр — инструмент автоматизации нагрузочных испытаний
      
      1С:ТестЦентр — инструмент автоматизации многопользовательских нагрузочных испытаний информационных систем на платформе «1С:Предприятие 8». С его помощью можно моделировать работу предприятия без участия реальных пользователей, что позволяет оценивать применимость, производительность и масштабируемость информационной системы в реальных условиях. Подробнее…
      
      Внедрение корпоративных информационных систем на платформе «1С:Предприятие 8»
      
      Опыт внедрения прикладных решений на платформе «1С:Предприятие 8» показывает, что система позволяет решать задачи различной степени сложности — от автоматизации одного рабочего места до создания информационных систем масштаба предприятия.
      
      В то же время, внедрение большой информационной системы предъявляет повышенные требования по сравнению с небольшим или средним внедрением. Информационная система масштаба предприятия должна обеспечивать приемлемую производительность в условиях одновременной и интенсивной работы большого количества пользователей, которые используют одни и те же информационные и аппаратные ресурсы в конкурентном режиме. Подробнее…
      
      База знаний по технологическим вопросам крупных внедрений
      
      Фирма «1С», совместно с сертифицированными «1С:Экспертами по технологическим вопросам» и другими техническими специалистами, ведет и регулярно обновляет базу знаний по технологическим вопросам крупных внедрений.
      
      Нефункциональные требования широко представлены в литературе. Нет недостатка в определениях и примерах нефункциональных требований. Международный институт бизнес-анализа (IIBA) определяет нефункциональные требования следующим образом:
      
      Ключевыми словами в этом определении являются «не имеют прямого отношения к поведению или функциональности решения». Это либо «условия», либо «качества».
      
      Условия: они являются внешними или внутренними ограничениями. Внутренние ограничения — это политика и саморегулирование организации, в то время как внешние ограничения — это государственные правила, отраслевые стандараты и другие параметры, определяющие бизнес-среду.
      
      Качества: это бизнес-требования, которые определяют не системное поведение и не связаны с процессом, а являются требованиями к качеству решения.
      
      Примеры:
      
      i) Условия
      а. Брендинг,
      б. Конфиденциальность данных,
      с. Совместимость с PCI;
      
      ii) Качества
      а. Доступность,
      б. Производительность.
      
      Даже самый опытный бизнес-аналитик прикладывает немало усилий, чтобы выявить нефункциональные требования. Основная причина таких трудностей заключается в том, что нефункциональные требования являются не простыми для их выявления, и не существует заранее определенного процесса их идентификации. Чтобы определить эти требования, нужно быть творческим и думать широко, выходя за определенные рамки!
      
      ЗАЧЕМ НУЖНЫ «НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ»
      
      В соответствии со всеми типами требований, пропуск того или иного требования может потенциально поставить под угрозу целостность и полноту решения. Функциональные и нефункциональные требования тесно связанны между собой множественными взаимосвязями.
      
      Обычно основное внимание уделяется функциональному аспекту требований, а значение нефункциональных требований часто недооценивается.
      
      Почему же нефункциональные требования недооцениваются?
      
      1. Основное внимание уделяется функциональным требованиям, поскольку они дают ощутимую отдачу. Нефункциональные требования же вносят вклад в инфраструктуру, а не в поведение системы. Инфраструктура бизнеса, являющаяся неосязаемой, представляется незначительной.
      
      2. Команда доставки решения вознаграждается и измеряется с точки зрения системных функций, процессов и поведения. Бизнес-пользователи рассматривают нефункциональные требования как «ИТ-требования», а ИТ рассматривает любые «потребности» как бизнес-потребности, а не технологии. Технология обеспечивает обслуживание, а бизнес управляет потребностями. В ходе этого процессе ИТ иногда забывает, что у них только «консультативная» роль.
      
      Каждое решение достигает эффективности из исчерпывающего списка требований, собранных как в начале, так и во время процесса внедрения. Требования могут быть разделены на две широкие категории: существенные и фундаментальные. Существенные требования вытекают из их аналогии с «функциональными требованиями» и, как представляется, имеют непосредственное отношение к решению. Однако так называемые фундаментальные требования могут не иметь прямой связи с решением, но они имеют основополагающее значение для создания устойчивой среды, в которой сохраняются существенные функциональные требования. Поэтому эти «нефункциональные требования» составляют структуру и инфраструктуру, которые поддерживают системные решения.
      
      ЧТО ТАКОЕ МАСШТАБИРУЕМОСТЬ?
      
      Масштабируемость — это способность системы или процесса обрабатывать увеличенный объем операций без ограничений или структурных узких мест. Каждая бизнес-модель имеет первостепенное значение для генерации бизнеса, что приводит к увеличению объема транзакций и последующему увеличению операционной деятельности. Масштабирование операций для обработки расширяющейся деловой активности присуще и встроено в дизайн системы. Масштабируемость можно разделить на две категории: физическую и нематериальную.
      
      1. Физическая масштабируемость
      
      Она относится к тем параметрам, которые имеют решающее значение для обеспечения того, чтобы организация была оснащена средствами (возможно, дополнительными) для обработки увеличивающегося числа операций. Это подразумевает физическую устойчивость. Это указывает на наличие факторов, необходимых с точки зрения физических компонентов процесса для обеспечения устойчивости (т.е. хранения данных, пропускной способности сети, аппаратного обеспечения и т.д.).
      
      Что значит быть устойчивым? Это отвечает текущим требованиям, не ставя под угрозу способность поддерживать будущие потребности. Например, если характеристики сетевого решения поддерживают текущие потребности, то они также должны быть способны поддерживать будущие потребности в течение ближайших трех-пяти лет. В целом, устойчивость определяется и оценивается с помощью прогнозов на три-пять лет.
      
      Почему нужно определять потребность в устойчивости при разработке бизнес-модели / решения? Устойчивая бизнес-модель основывается на своем дизайне и структуре, которые лучше всего подходят для достижения решения посредством стабильных и надежных систем, процессов и инфраструктуры. Физическая устойчивость направлена на достижение двух основных характеристик: стабильности и надежности бизнес- и технологических решений.
      
      Стабильность: то, что позволяет бизнесу оставаться стабильным, устойчивым к внешним воздействиям. ИТ-инфраструктура устойчива и гарантирует поддержку бизнес-операций в течение предполагаемого периода в будущем.
      
      Надежность: если бизнес постоянно растет в течение пяти лет, а инфраструктура при этом остается устойчивой. Надежность позволяет бизнесу сосредоточиться на своих основных компетенциях в устойчивой инфраструктуре.
      
      2. Нематериальная масштабируемость
      
      Это относится к присущей способности поддерживать нефизический рост. Рост бизнеса имеет решающее значение для поддержания рыночной доли и конкурентоспособности. Рост может быть как внутренним, так и внешним, основанным на принятых драйверах и стратегиях. Ниже приведены несколько примеров:
      
      * Новые продукты, которые будут размещаться на одной платформе / решении
      * Дополнительные бренды (для мультибрендовых организаций)
      * Дополнительные бизнес-процессы
      
      В чем разница между физическим и нематериальным? Хотя оба они могут казаться похожими, они не идентичны. Решение может быть устойчивым физически, но может не поддерживать неосязаемый рост. Например, если объем операций увеличивается, то решение должно быть устойчивым физически. Если бизнес вводит новые продукты, то это классифицируется как неосязаемый рост, и решение должно иметь масштабируемые функции и процессы (не физические) для поддержки этого роста.
      
      Зачем нам нужно определять требования к нематериальной масштабируемости? Необходимость определения требований к нематериальной масштабируемости становится необходимой, поскольку она является предпосылкой, которая поддерживает рост. Требования к масштабируемости, по сути, являются отражением стремления организации к росту и необходимостью решения для поддержки роста с минимальными изменениями и нарушением повседневной деятельности.
      
      КАК ОПРЕДЕЛЯТЬ ТРЕБОВАНИЯ К МАСШТАБИРУЕМОСТИ?
      
      Нет простого объяснения или простой методологии для определения требований к масштабируемости. Крайне субъективно и относительно сложно определить условия и особенности, необходимые для принятия устойчивого решения. Это одна из причин, почему это называется «анализом». Ниже приведен подход, который всегда работал для автора. Однако это не подходит для всех подобных ситуаций.
      
      Физическая масштабируемость:
      
      1. Определите физические компоненты решения, которые необходимо масштабировать.
      2. Определите функции, которые могут сделать определенный компонент масштабируемым.
      3. Определите параметры для измерения функций.
      4. Определите значения каждого параметра, определенного выше. Это нефункциональные требования (определение параметра).
      
      Ответы на эти вопросы нужно формулировать с точки зрения бизнеса, а не с точки зрения ИТ.
      
      Ситуация: ваша организация является финансовым учреждением, которое выпускает кредитные карты клиентам. Она прикладывает усилия для преобразования своих технологий и систем.
      
      Какие вопросы следует задать, чтобы начать анализ идентификации физической масштабируемости? В целях упрощения мы сузим сферу действия. Ниже приведены некоторые примеры:
      
      1. Каков текущий объем клиентов, транзакций, счетов и т.д.?
      2. Какие объемы ожидаются от работы систем в первый день?
      3. Каков ежегодный рост объема (клиентов, транзакций и т.д.), ожидаемый в ближайшие три-пять лет?
      
      Вопрос 1 следует задать для определения текущего состояния.
      
      Вопрос 2 определяет непосредственное требование с первого дня жизни (эксплуатации).
      
      Вопрос 3 является вкладом в определение требования масштабируемости решения. Например, если организация прогнозирует рост новых клиентов на 10% в год и ежегодный рост числа транзакций на 15%, то требования к масштабируемости могут быть следующими:
      
      1. Решение должно поддерживать ежегодный рост на 10% новых клиентов.
      2. Решение должно поддерживать ежегодный рост на 15% от предыдущего количества транзакций.
      
      Однако, в этом примере, я бы предложил дополнительно определить ожидания того, что требование предполагает «поддержку» (т.е. технология не требует каких-либо изменений для обработки роста)?
      
      Нематериальная масштабируемость:
      
      Это рост бизнеса, а не развитие технологий, инфраструктуры или логистики. Это будет варьироваться от одного бизнеса к другому и зависит от специфики предметной области. Поэтому знание бизнеса и промышленности, разработанное с помощью экспертного исследования, является ключом к определению параметров масштабируемости на уровне детализации. Тем не менее, бизнес-стратегия высокого уровня формулируется на основе детализации из определения видения организации.
      
      Ситуация: ваша организация является финансовым учреждением, которое выпускает кредитные карты своим клиентам. Она прикладывает усилия для преобразования своих технологий и систем.
      
      Какие вопросы следует задать, чтобы начать анализ идентификации нематериальной масштабируемости? В целях упрощения мы сузим сферу действия. Ниже приведены некоторые примеры:
      
      1. Планирует ли организация выпускать новые продукты (например, мобильные платежи, продукты, подобные Apple Pay или Bitcoin)?
      2. Есть ли какие-либо будущие приобретения или слияния с аналогичными предприятиями?
      3. Какова стратегия организации (т.е. новые каналы сбыта, выход на новые рынки и т.д.)?
      
      Эти вопросы помогают определить нематериальный рост. Например, если организация планирует запустить новый бренд продуктов для кредитных карт, тогда требования к масштабируемости будут следующими:
      
      1. Решение должно быть в состоянии разместить два разных бренда: Brand A и Brand B.
      2. Оба бренда должны иметь возможность использовать одни и те же системы и процессы.
      
      Эти требования достаточно высокоуровневы и приведены только в качестве примера. В реальном сценарии они должны быть изучены более подробно.
      
      Нет простого метода определения нефункциональных требований. Относительно сложно определить условия и функции, необходимые для создания масштабируемого решения.
      
      __________________________________________________________
      Автор: Адам Алами, доктор философии, ИТ-университет Копенгагена
      
      Адам Алами — кандидат наук в ИТ-университете Копенгагена. Адам обладает богатым опытом в области информационных технологий. Он начал свою карьеру в качестве разработчика программного обеспечения, затем перешел в бизнес-анализ и управление проектами. Его 20-летний опыт связан с крупными проектами трансформации бизнеса и совершенствованием процессов. Он накопил богатый передовой опыт в крупных проектах в области трансформации предприятий, интеграции, миграции и модернизации систем.
      
      У него есть ряд академических достижений. Он имеет степень бакалавра по разработке программного обеспечения в Университете Квебека Монреаля (UQÀM) и степень магистра по вычислительной технике в Технологическом университете Сиднея (UTS).
      
      Как-то передо мной встал вопрос, что такое масштабируемость и как это связано с зависимостью/независимостью от центрального процессора? В результате получилась небольшая статья, которую и предлагаю Вашему вниманию.
      
      Начну с того, что постараюсь кратко объяснить, что же такое процессорная зависимость (CPU dependency) применительно к 3D-ускорителям. Дело в том, что ни один из существующих 3D-ускорителей пользовательского класса не ускоряет весь процесс обсчета трехмерной сцены (геометрические преобразования, просчет освещенности, отсечение невидимых поверхностей и т.д.). Разные ускорители ускоряют разные этапы, обычно лежащие где-то ближе к концу цепочки вычислений - растеризацию (т.е. перевод двумерного векторного изображения в двумерное растровое изображение) и наложение текстур. Вся остальная работа ложится на плечи центрального процессора (CPU). При этом для организации взаимодействия с 3D-ускорителем обычно требуется некоторое дополнительное число шагов. Процессорная зависимость, таким образом, слагается из 2-х компонент — процента вычислений, НЕ ускоряемых картой, и процента дополнительных вычислений, которые производятся уже графическим процессором.
      
      Как процессорная зависимость связана с масштабируемостью, т.е. возможностью роста производительности карточки с ростом производительности процессора? В большинстве случаев имеется некоторый отрезок процессорной мощности, при котором карточка демонстрирует почти линейный рост производительности. Связано это с тем, что процессор не успевает готовить данные для графического ускорителя, и любые данные обрабатываются до поступления следующей порции. При этом, очевидно, что чем больший участок тракта вычислений берет на себя графический акселератор, тем меньше нагрузка на процессор, а значит, CPU быстрее готовит данные, и, в результате, сужается участок линейного масштабирования. Отсюда следует, что чем менее процессорно-зависима карточка-ускоритель, тем она обычно менее масштабируема.
      
      Начиная с какого-то момента, графический акселератор начинает все больше и больше тормозить процессор, и при неограниченном росте производительности последнего скорость рендеринга становится постоянной, стремясь к пиковой производительности ускорителя.
      
      Конечно, эта модель несколько упрощенная. В реальных системах процессору всегда найдется, чем заняться, к тому же пропускные способности шин, передающих данные, на сегодня весьма ограничены. Что, кстати, является еще одним узким местом на пути достижения максимальной производительности.
      
      В качестве оценки предельной производительности карточки можно использовать известные характеристики количества треугольников, которые она может обработать в секунду, и скорость закраски (fill-rate), т.е. количество текстурированных и отфильтрованных пикселов, выводимых в одну секунду. Возьмем для примера две карточки: 3Dfx Voodoo и nVidia Riva TNT.
      - 3dfx Voodoo: 750 тыс. треуг./сек, 40 млн.пикселей/сек
      - nVidia Riva TNT: 2 млн. треуг./сек, 200 млн.пикселей/сек
      - при сложности сцены в 10 тыс. треуг. — 75 fps.
      - при разрешении 640х480 и глубине перекрытия 4 — 32 fps.
      Как видим, теоретические данные очень неплохо согласуются с практическими (эти параметры приблизительно соответствуют Quake 2).
      - при сложности сцены в 10 тыс. треуг — 200 fps.
      - при разрешении 640х480 и глубине перекрытия 4 — 162 fps.
      - при разрешении 800х600 и глубине перекрытия 4 — 104 fps.
      - при разрешении 1024х768 и глубине перекрытия 4 — 63 fps.
      Что следует из этих цифр? Очень простой вывод. Начиная с какого-то уровня, производительность 3D-ускорителя уже не играет роли (глазу все равно, 160 или 60 fps он видит). Все теперь упирается в процессорную зависимость, т.е. в то, какой процессор нужен, чтобы достичь подобных пиковых значений. Вот почему я с большим скепсисом читаю характеристики вновь появляющихся 3D-ускорителей. Также легко видеть, что приведенные ускорители (как и подавляющее большинство остальных) ограничены именно скоростью закраски, тогда как для процессора основная нагрузка исходит от процесса геометрических преобразований, т.е., усилия разработчиков сосредоточены несколько не в том месте, где надо бы.
      
      Перевод статьи «Scalability: Growing a System in Different Directions».
      
      Вокруг распределенных систем ходит много разговоров, но все они крутятся, собственно, вокруг размеров. Причем, говоря о размере, люди обычно подразумевают размер самой системы. И когда дело касается распределенных систем, оказывается, размер действительно имеет значение.
      
      Сфера компьютерных вычислений имеет удивительно длинную историю. Но если мы говорим о распределенных системах, то история немного отличается. Распределенные вычисления в нашем современном понимании начали появляться в поздние 1960-е и ранние 1970-е, когда компьютеры начали взаимодействовать в сетях (Ethernet).
      
      В течение следующего десятилетия распределенные вычисления становились все более распространенными. Любопытно, что системы начали становиться «распределенными», когда появилась одна массивная распределенная система – интернет.
      
      К 1980-м компьютеры уже использовались повсеместно, а доступ к интернету (и другим сетям) стал более обыденным. Не углубляясь в детали, можно заключить, что машин стало больше, а кроме того, они стали гораздо больше взаимодействовать друг с другом.
      
      Такой тип «роста» имеет собственное название в царстве распределенных систем. Фактически, сегодня многие инженеры (и не только занимающиеся распределенными системами) довольно широко используют этот термин. Я говорю, конечно же, о масштабируемости. Итак, давайте рассмотрим, что такое масштабируемая распределенная система, а также – каким образом система может расти.
      
      Как происходит масштабирование?
      
      Масштабируемость системы может означать много различных вещей в зависимости от того, с чем имеет дело эта система, а также от того, какая часть системы растет. Но в общих чертах можно сказать, что если система обладает масштабируемостью, значит, она может продолжать справляться со своей работой и действовать эффективно в условиях своего роста.
      
      Но что такое «рост»? Какая часть системы увеличивается?
      
      Говоря о том, что система растет, в разных случаях мы, скорее всего, будем иметь в виду разные вещи. Другими словами, система запросто может расти в разных направлениях.
      
      Определение: масштабируемой распределенной системой называется такая система, которая продолжает эффективно работать по мере возрастания количества пользователей и ресурсов.
      Например, мы можем утверждать, что система растет, если растет число пользователей, взаимодействующих с ней. Если с системой работало 5 тысяч пользователей и вдруг их число возросло до 50 тысяч, это определенно своего рода рост системы!
      
      Как система может расти? Больше данных, больше процессов, больше машин, больше пользователей. Обычно система растет не в одном направлении!
      Но система также может расти и в плане ее собственных ресурсов. Например, однажды она может получить особенно высокий трафик, а следовательно, очень большое количество данных, которые нужно обрабатывать. Или система может особенно интенсивно использоваться в определенный период времени, что приведет к значительному росту количества одновременно запущенных процессов. Или вот еще пример: единая система может расти за счет числа физических машин (серверов) внутри нее.
      
      Все эти вещи – данные, процессы, машины – представляют собой различные направления, по которым может происходить рост системы. И, как мы выяснили ранее, наплыв пользователей это тоже один из видов роста системы.
      
      На самом деле в реальном мире распределенные системы растут не в одном направлении, а в нескольких одновременно. Например, мы можем заметить, что в результате наплыва пользователей возросло и количество данных. А для обработки большего количества данных мы добавляем новые серверы или базы данных.
      
      В реальном мире распределенная система имеет тенденцию расти в больше, чем в одном направлении.
      
      Измеряем масштабируемость: масштабируемость по размеру, географическая и административная масштабируемость
      С учетом того, что система может расти по-разному, имеет смысл говорить о масштабируемости системы в привязке к тому, как именно она растет. Чтобы конкретизировать форму масштабируемости, придумано несколько терминов. Основные из них – масштабируемость по размеру, географическая масштабируемость и административная масштабируемость. Это три формы часто называют измерениями масштабируемости. Давайте рассмотрим каждую из них подробнее.
      
      Рост, измеряемый количественно
      
      Первое измерение масштабируемости лежит на пересечении двух вещей, которые мы уже обсуждали: количества пользователей и количества ресурсов (какими бы эти ресурсы ни были). Мы знаем, что и то, и другое может возрастать количественно. Когда такое происходит, мы говорим, что система увеличилась в размерах.
      
      Если система обладает масштабируемостью по размеру, это означает, что она сохраняет свою производительность и остается пригодной к использованию независимо от того, как много ресурсов она может получить.
      
      Мы можем решить увеличить объем базы данных или на несколько часов добавить серверы для обработки большего потока данных. Но если наша система масштабируется по размеру, добавление новых узлов не должно отрицательно сказаться на производительности. То есть, если мы решили добавить больше узлов для обработки ресурсов или обслуживания пользователей, в результате не должны упасть производительность и эффективность работы всей системы. Наша система должна иметь возможность продолжать работу на уровне, который ожидают от нее пользователи, и, разумеется, для пользователей работа с этой системой не должна замедлиться.
      
      Рост с увеличением сложности
      
      До сих пор мы говорили о добавлении ресурсов или пользователей в функционирующую систему. Но по мере роста системы мы можем обнаружить, что добавление узлов не решает проблему. Фактически, порой само это добавление может приводить к непредсказуемым последствиям.
      
      На первый взгляд может показаться, что добавить узлы или ресурсы в систему довольно легко. Однако это очень наивный подход к сложной проблеме. Если речь идет о распределенной системе, географическая и административная масштабируемость имеют много нюансов, которые могут быть не слишком очевидными.
      
      Увеличение расстояний
      
      Когда система начинает существенно увеличиваться в размерах, мы должны обдумать еще один вопрос: где конкретно расположены наши ресурсы? Здесь и выходит на сцену географическая масштабируемость.
      
      Если система обладает географической масштабируемостью, она может продолжать эффективно функционировать и использоваться вне зависимости от расстояния между пользователями и ресурсами системы.
      
      Добавление еще одного узла в нашу систему может казаться простым делом. Но мы помним, что наша цель – создание системы, которая продолжит эффективно функционировать, и к которой по-прежнему смогут легко получать доступ пользователи. В этих условиях добавление нового узла осложняет достижение нашей цели.
      
      Мы, конечно, можем добавлять новые узлы в нашу систему и без учета дистанций между ними. Но это зависит от расположения узлов и расстояния между ними и пользователями. Под расстоянием следует понимать буквальное физическое пространство между ними, т. е., расстояние в географическом смысле.
      
      Если система обладает географической масштабируемостью, добавление новых узлов не увеличивает количество времени, необходимого для коммуникации между ними.
      
      Таким образом, добавляя каждый новый узел, нужно учитывать его физическое расположение по отношению к остальным частям системы.
      
      Рост затрачиваемых усилий
      
      Наконец, если система растет по размеру и в географическом плане, возникает последний вопрос: кто будет наблюдать за новыми частями расширяющейся системы? Мы подобрались к административной масштабируемости.
      
      Если система обладает административной масштабируемостью, добавление новых узлов не должно вызывать существенного роста количества усилий, необходимых для управления этими новыми узлами.
      
      Это особенно важно, если система используется многими администраторами (людьми или организациями, запускающими эту систему наравне с другими людьми и организациями). Каждый из них должен иметь возможность использовать систему, даже когда ею уже пользуются другие.
      
      Административная масштабируемость это еще одно измерение масштабируемости, о котором часто забывают. И если нам легко счесть добавление еще одного узла простым решением проблемы роста системы, нам так же легко забыть, что добавление ресурсов в систему означает, что в будущем понадобятся дополнительные усилия для их поддержки.
      
      В системе, обладающей административной масштабируемостью, добавление ресурсов по мере роста системы не должно вызывать сильного увеличения управленческих усилий.
      
      Если для масштабирования нашей системы нам потребовалось добавить целый дата-центр узлов, мы должны суметь прикинуть количество человеко-часов, которое потребуется на поддержку этих узлов и их работоспособности.
      
      Очень часто, говоря о том, что нужно сделать систему масштабируемой, разработчики на самом деле думают только об увеличении размеров системы. Однако, как и многие другие вещи, распределенные системы развиваются больше, чем в одном направлении. Масштабируемость по размеру это лишь один из аспектов проблемы. Очень важно учитывать также географическую и административную масштабируемость. А обратив внимание на каждый из этих аспектов, мы обнаружим множество нюансов и своих сложностей.
      
      Читайте также: