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

Работа одного прикладного решения в разных условиях

Система 1С:Предприятие 8 имеет хорошие возможности масштабирования. Она позволяет работать как в файловом варианте, так и с использованием технологии «клиент-сервер».

• Персональное использование, файловый вариант работы
  При работе в файловом варианте платформа может работать с локальной информационной базой, расположенной на том же компьютере, на котором работает пользователь. Такой вариант работы может использоваться в домашних условиях или при работе на ноутбуке.
• Небольшая рабочая группа, файловый вариант работы
  Файловый вариант также обеспечивает возможность работы по локальной сети нескольких пользователей с одной информационной базой. Такой способ работы может использоваться в небольших рабочих группах, он прост в установке и эксплуатации.
• Крупное предприятие, клиент-серверный вариант работы
  Для больших рабочих групп и в масштабах предприятия может применяться клиент-серверный вариант работы, основанный на трехуровневой архитектуре с использованием сервера 1С:Предприятия 8 и отдельной системы управления базами данных. Он обеспечивает надежное хранение данных и их эффективную обработку при одновременной работе большого количества пользователей.
• Холдинг, распределенная информационная база
  Крупные холдинговые компании могут использовать работу в распределенной информационной базе, сочетающуюся с применением как файлового, так и клиент-серверного вариантов работы. Распределенная информационная база позволяет объединить удаленные друг от друга подразделения холдинга, а каждое из этих подразделений может использовать, в свою очередь, файловый или клиет-серверный варианты работы. Механизм распределенной информационной базы будет обеспечивать идентичность конфигураций, используемых в каждом из подразделений холдинга, и осуществлять обмен данными между отдельными информационными базами, входящими с состав распределенной системы.

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

Многопользовательская работа

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

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

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

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

Механизмы оптимизации

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

Выполнение на сервере

В варианте клиент-сервер использование сервера 1С:Предприятия 8 позволяет сосредоточить на нем выполнение наиболее объемных операций по обработке данных. Например, при выполнении даже весьма сложных запросов программа, работающая у пользователя, будет получать только необходимую ей выборку, а вся промежуточная обработка будет выполняться на сервере. Обычно увеличить мощность сервера гораздо проще, чем обновить весь парк клиентских машин.

Кэширование данных

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

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

При работе в клиент-серверном варианте вся работа прикладных объектов выполняется только на сервере. Функциональность форм и командного интерфейса также реализована на сервере.

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

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

Версии 8.1 и 8.0 - сравнение производительности и масштабируемости

Для оценки того, как изменилась производительность и масштабируемость системы в различных условиях в версии 8.1 было проведен ряд тестов:

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

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

для 1С:Предприятия 8.

Версии 7.7 и 8.0 - сравнение производительности и масштабируемости

Для оценки производительности и масштабируемости клиент-серверной версии 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 показывает, что система позволяет решать задачи различной степени сложности - от автоматизации одного рабочего места до создания информационных систем масштаба предприятия.

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

Олег Спиряев

В последнее время нередки утверждения, что серверы среднего и старшего класса активно заменяются на группы серверов начального уровня, объединенные в стойки или кластеры. Однако некоторые эксперты с этим не согласны. Так, по данным Dataquest, доля моделей ценой от 500 тыс. долл. и выше (к ним относятся средние и старшие серверы SMP) в общем объеме продаж серверов с 2000 до 2002 г. выросла с 38 до 52%.

Другие данные, полученные компанией IDC, свидетельствуют о росте (по крайней мере, по числу машин) в секторе младших моделей серверов - с двумя процессорами. IDC также предсказывает, что в 2005 г. самой распространенной операционной системой для серверов стоимостью от 50 тыс. до 3 млн долл. будет Unix. Из сравнения этих данных видно, что Unix-серверы среднего и старшего класса останутся преобладающей платформой для центров обработки данных, но будут дополняться все растущим числом небольших (обычно двухпроцессорных) серверов.

Эта тенденция сложилась в результате выделения в центрах обработки данных разных уровней вычислений (рис. 1). Уровень 1, или фронтальный уровень, постепенно переходит на модель горизонтального масштабирования небольших серверов, а на уровне 3 (уровне баз данных) преобладают серверы с вертикальным масштабированием. Уровень 2 (уровень приложений) становится областью, где сосуществуют вертикальная и горизонтальная архитектуры.

Вертикальная и горизонтальная архитектуры

Рассмотрим основные различия между вертикальной и горизонтальной архитектурами. Серверы с вертикальным масштабированием - это большие SMP-системы (с симметричной многопроцессорной обработкой или совместно используемой памятью), насчитывающие свыше четырех центральных процессоров. В них используется только одна копия ОС, управляющая работой всех процессоров, памяти и компонентов ввода-вывода. Обычно все эти ресурсы размещены в одной стойке или шкафу. Межсоединения у таких серверов осуществляются по высокоскоростной центральной или объединительной панели с небольшим временем запаздывания и согласованным доступом к кэш-памяти. Добавить ресурсы можно путем установки внутрь шкафа дополнительных системных плат. В системах с вертикальной архитектурой (или SMP-системах) память используется совместно, т. е. все процессоры и компоненты ввода-вывода получают доступ ко всей памяти. Пользователь "видит" память как единый большой объект.

При альтернативном, горизонтальном масштабировании системы соединяются через сеть или объединяются в кластер. Для межсоединений обычно используются стандартные сетевые технологии, такие, как Fast Ethernet, Gigabit Ethernet (GBE) и Scalable Coherent Interconnect (SCI), дающие меньшую пропускную способность и большее запаздывание по сравнению с вертикальными системами. Ресурсы в этом случае распределяются между узлами, обычно содержащими от одного до четырех процессоров; каждый узел имеет собственный процессор и память и может иметь собственную подсистему ввода-вывода или использовать ее совместно с другими узлами. На каждом узле работает отдельная копия ОС. Ресурсы расширяются за счет добавления узлов, но не добавления ресурсов в узел. Память в горизонтальных системах распределена, т. е. у каждого узла есть собственная память, к которой напрямую обращаются его процессоры и подсистема ввода-вывода. Доступ к этим ресурсам с другого узла происходит намного медленнее, чем с узла, где они расположены. Кроме того, при горизонтальной архитектуре отсутствует согласованный доступ узлов к памяти, а используемые приложения потребляют относительно немного ресурсов, поэтому они "умещаются" на одном узле и им не нужен согласованный доступ. Если же приложению потребуется несколько узлов, то оно само должно обеспечить согласованный доступ к памяти.

Если горизонтальная система удовлетворяет требованиям приложений, то такая архитектура предпочтительна, поскольку расходы на ее приобретение меньше. Обычно стоимость приобретения в расчете на один процессор у горизонтальных систем ниже, чем у вертикальных. Разница в цене объясняется тем, что в вертикальных системах применяются более мощные функции надежности, доступности и обслуживаемости - RAS (reliability, availability, serviceability), а также высокопроизводительные межсоединения. Однако есть ряд ограничений на применение систем с горизонтальной архитектурой. Ниже мы обсудим, в каких условиях возможно применение горизонтальных систем и когда обязательно вертикальное масштабирование.

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

Недавно появившиеся на рынке модульные, или blade-серверы, обычно оборудуемые одним-двумя процессорами, - пример горизонтальных серверов. Здесь кластер состоит из небольших узлов, в каждом из которых установлен SMP-сервер начального уровня с числом центральных процессоров от 1 до 4.

Другой способ горизонтального масштабирования - это большие вычислительные системы с массовым параллелизмом (MPP), состоящие из множества установленных в одном шкафу небольших процессоров, каждый из которых имеет собственную копию ОС или копию микроядра ОС. В настоящее время выпускаются всего несколько систем MPP, которые чаще всего представляют специализированные решения. Это, например, системы Terradata производства компании NCR, IBM RS/6000SP (SP-2) и HP Tandem non-stop.

Таблица 1. Особенности вертикальной и горизонтальной архитектур

Параметр	Вертикальные системы	Горизонтальные системы
Память	Большая совместно используемая	Небольшая выделенная
Потоки	Много взаимозависимых потоков	Много независимых потоков
Межсоединения	Сильносвязанные внутренние	Слабосвязанные внешние
RAS	Мощные RAS одиночной системы	Мощные RAS с использованием репликации
Центральные процессоры	Много стандартных	Много стандартных
ОС	Одна копия ОС на множество центральных процессоров	Несколько копий ОС (по одной копии на 1-4 процессора)
Компоновка	В одном шкафу	Размещение большого числа серверов в стойке
Плотность размещения		Высокая плотность размещения процессоров на единицу площади пола
Оборудование	Стандартное и специально разработанное	Стандартное
Масштабирование	В пределах корпуса одного сервера	В масштабе нескольких серверов
Расширение	Путем установки в сервер дополнительных компонентов	Путем добавления новых узлов
Архитектура	64-разрядная	32- и 64-разрядная

Табл. 1 позволяет провести сравнительный анализ вертикальной и горизонтальной архитектур.

• В вертикальных системах память используется совместно и обеспечивается согласованный доступ к кэш-памяти.
• Вертикальные системы идеальны для потоков выполнения задач, которые должны обмениваться данными между собой.
• Вертикальные системы характеризуются мощными функциями RAS, а в горизонтальных системах доступность реализуется с помощью массивной репликации (в кластер соединяются несколько узлов, поэтому отказ одного из них мало влияет на работу всей системы).
• В вертикальных системах одна копия ОС охватывает все ресурсы. Некоторые вертикальные системы, например, мидфреймы и серверы класса high-end Sun Microsystems (от Sun Fire 4800 до Sun Fire 15K), можно разделить на меньшие вертикальные серверы.
• В вертикальных системах используется максимально возможное число стандартных компонентов, но некоторые основные составляющие (например, межсоединения) специально разрабатываются.
• Вертикальные системы можно расширять, устанавливая в существующий каркас дополнительные компоненты (более мощные процессоры, добавочную память, дополнительные и более производительные соединения ввода-вывода и т. п.). Горизонтальные системы расширяются за счет добавления узла или замены старых узлов на новые.
• Практически все вертикальные системы 64-разрядные, а горизонтальные могут быть как 32-разрядными, так и 64-разрядными.

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

Таблица 2. Типы приложений для вертикальной и горизонтальной архитектур

Для небольших и модульных серверов хорошо подходят приложения, которые не используют информацию о состоянии, невелики по масштабу и легко реплицируются. А для приложений, использующих информацию о состоянии и большие объемы данных, требующих интенсивной передачи данных внутри системы, идеальным решением будут вертикальные серверы. На рынке высокопроизводительных технических вычислений (HPTC) имеется множество приложений, в которых потоки зависят друг от друга и обмениваются данными между собой. Существуют также приложения, которым нужны большие объемы совместно используемой памяти. Для этих двух типов приложений лучше всего подходят большие SMP-серверы. Однако имеются и такие приложения HPTC, в которых потоки исполнения независимы и им не требуется совместно используемая память большого объема. Такие приложения можно разбивать на разделы, и потому для их выполнения идеальны кластеры небольших серверов. Аналогичным образом некоторые коммерческие приложения поддерживают разделы, и для них оптимальны горизонтальные серверы, а другие нельзя разбить на разделы, поэтому для них лучшая платформа - это вертикальные серверы.

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

Все крупные центры обработки данных представляют собой параллельные компьютеры. Здесь даже кластеры можно рассматривать как особый тип параллельных систем. Для получения высокой производительности требуется сбалансированная система с мощными процессорами, работающими на высокой скорости межсоединениями и подсистемой ввода-вывода, масштабируемой ОС, оптимизированными приложениями и совершенными функциями RAS.

Процессоры и системные межсоединения

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

Кроме того, по мере роста числа процессоров в параллельной системе на первый план выходит не их мощность, а системные межсоединения. Именно они отвечают за перемещение данных с диска, из памяти и из сети к процессору. В кластере в качестве межсоединения выступает сетевое соединение, например, Fast Ethernet или Gigabit Ethernet. Кластерные межсоединения перемещают данные между узлами, а системные - внутри отдельной системы. Если межсоединение работает слишком медленно, то процессор в ожидании данных будет простаивать.

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

Основное техническое различие между горизонтальными и вертикальными системами - это пропускная способность и запаздывание их межсоединений. У межсоединений кластеров пропускная способность может составлять от 125 Мбайт/с для Fast Ethernet до 200 Мбайт/с для SCI, а запаздывание - от 100 тыс. нс для GBE и до 10 тыс. нс для SCI. С помощью интерфейса InfiniBand возможно реализовать более быстрые межсоединения с пиковой скоростью от примерно 250 Мбайт/с для первой версии и до 3 Гбайт/с для последующих.

Ввод и вывод

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

Операционная система

Даже лучшее оборудование оказывается неэффективным, если ОС недостаточно масштабируема. Для горизонтальных систем масштабируемость ОС не столь важна, потому что в отдельном узле или с отдельной копией ОС работает не более четырех процессоров.

Доступность системы

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

Оптимизированные приложения

Приложения необходимо оптимизировать для архитектуры вычислительной системы. Легче всего писать и оптимизировать приложения для SMP-систем. Основные коммерческие приложения оптимизированы именно для SMP-систем и даже разрабатывались на них, поэтому SMP доминируют на рынке систем среднего класса и high-end последние десять лет.

Размер приложений

Как уже отмечалось, в больших SMP-системах используются высокоскоростные межсоединения, обеспечивающие достаточную производительность системы. В горизонтальных системах могут возникать проблемы с производительностью из-за низкой пропускной способности и значительной задержки межсоединений в тех случаях, когда требуется часто передавать данные между узлами. Однако некоторым приложениям для достижения высокой производительности не нужна высокая скорость межсоединений - обычно это небольшие приложения и приложения, которые можно легко реплицировать (например, Web-серверы, прокси-серверы, брандмауэры и небольшие серверы приложений). В таких горизонтальных системах каждый узел выполняет небольшую задачу независимо от работы всех остальных.

Например, в случае горизонтальной архитектуры (или архитектуры с распределенной памятью) четыре процессорных узла (каждый с отдельным ОЗУ и выделенной либо используемой совместно подсистемой ввода-вывода) могут использовать сетевое межсоединение, например, Gigabit Ethernet. В этой вычислительной среде выполняются рабочие нагрузки трех типов. Самая маленькая нагрузка помещается на одном узле, но по мере ее увеличения для выполнения требуется уже несколько узлов. Как утверждают специалисты, при выполнении одной задачи на нескольких узлах производительность значительно ухудшается из-за медленных межузловых межсоединений. Небольшие нагрузки, которым не нужно обмениваться данными между собой, прекрасно сочетаются с горизонтальной архитектурой, но при выполнении в ней крупномасштабных нагрузок возникают проблемы.

Конфигурация большой системы SMP может включать, например, до 100 процессоров, 576 Гбайт совместно используемой памяти и высокоскоростные межсоединения. Такая система может обрабатывать все типы нагрузок, поскольку в ней отсутствует обмен данными между узлами и эффективно осуществляется обмен данными между процессами. Все центральные процессоры могут одновременно получить доступ ко всем дискам, всей памяти и сетевым соединениям - это ключевая особенность SMP-систем (или вертикальных систем).

Часто возникает вопрос о целесообразности размещения на больших SMP малых нагрузок. Хотя в техническом плане это возможно, с экономической точки зрения такой подход себя не оправдывает. Для больших SMP стоимость приобретения в расчете на один процессор выше, чем для маленьких систем. Поэтому если приложение может работать на небольшом узле (или нескольких небольших узлах) и это не создает серьезных проблем с управлением, для его развертывания лучше подходит горизонтальное масштабирование. Но если приложение слишком велико и не может выполняться на небольшом узле (или нескольких таких узлах), то крупный SMP-сервер будет оптимальным вариантом с точки зрения как производительности, так и системного администрирования.

Производительность на уровне базы данных

Основной вопрос здесь - сравнение производительности одиночных средних и больших SMP-серверов с кластером небольших серверов (не более четырех процессоров).

При обсуждении масштабируемости фирмы-производители используют ряд специальных терминов. Так, рост производительности (Speedup) для SMP определяется как отношение скоростей выполнения приложения на нескольких процессорах и на одном. Линейный рост производительности (Linear speedup) означает, например, что на 40 процессорах приложение работает в 40 раз (40x) быстрее, чем на одном. Рост производительности не зависит от числа процессоров, т. е. для конфигурации из 24 процессоров он будет таким же, как для 48 процессоров. Рост производительности кластера (Cluster speedup) отличается только тем, что при его расчете берется число узлов, а не процессоров. Как и рост производительности SMP, рост производительности кластера остается постоянным для разного числа узлов.

Эффективность масштабирования (Scaling efficiency) характеризует способность приложений, особенно кластерных, масштабироваться на большое число узлов. Обычно считается, что эффективность масштабирования зависит от числа узлов, участвующих в измерении. Эффективность масштабирования SMP (SMP scaling efficiency) - это рост производительности, деленный на число процессоров, а эффективность кластера (Cluster efficiency) - это рост производительности кластера, деленный на число узлов в нем. Нужно понимать, в чем смысл этих параметров, чтобы не складывалась неправильная картина, поскольку эффективность масштабирования 90% на двух узлах - это не то же самое, что эффективность масштабирования 90% на четырех узлах.

На рис. 2 приведены три графика: идеальная линейная масштабируемость, масштабируемость 24-процессорного SMP-сервера в 95% и масштабируемость кластера из двух 4-процессорных серверов в 90%. Видно, что существуют определенные ограничения на масштабируемость баз данных в кластерах (при горизонтальном масштабировании). Соединяя вместе много маленьких серверов, не удается получить масштабируемость, необходимую для средних и крупных приложений. Причина этого - ограничения пропускной способности внутрикластерных межсоединений, дополнительная нагрузка на ПО баз данных, связанная с управлением кластером, и трудности написания приложений для кластерных сред с распределенной памятью.

Опубликованные результаты эталонных тестов показывают, например, что у Oracle9i RAC (Real Application Cluster) рост производительности составляет 1,8 и эффективность масштабирования равна 90%. Такая эффективность масштабируемости может показаться достаточно высокой, но на самом деле масштабируемость 90% для четырех узлов оказывается неэффективной, если сравнить ее с результатами больших SMP-серверов.

Производительность на уровне приложений

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

В большинстве случаев уровню сервера приложений требуется намного больше процессоров, чем уровню базы данных в расчете на отдельный прикладной сервис. Например, в случае SAP R/3 это соотношение составляет примерно 10 процессоров на каждый процессор базы данных, т. е. если SAP R/3 требуется 20 процессоров для уровня базы данных, то на уровне приложений должно быть примерно 200 процессоров. Вопрос заключается в том, что выгоднее развернуть - 100 двухпроцессорных серверов или десять 20-процессорных. Аналогичным образом в Oracle соотношение процессоров приложений к процессорам баз данных равно примерно 5 к 1.

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

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

В то же время расходы на управление и обслуживание инфраструктуры у горизонтальной архитектуры могут оказаться более высокими. При развертывании на горизонтальных системах используются многочисленные копии ОС и ПО серверов приложений. Затраты же на поддержание инфраструктуры обычно растут пропорционально числу копий ОС и приложений. Кроме того, для горизонтальной архитектуры резервное копирование и восстановление после аварий становится децентрализованным, и управлять сетевой инфраструктурой сложнее.

Стоимость системного администрирования с трудом поддается измерениям. Обычно модели для сравнения горизонтального и вертикального развертывания прикладных серверов показывают, что управление меньшим числом более мощных серверов (вертикальных серверов) обходится дешевле, чем управление множеством небольших серверов. В целом при выборе типа архитектуры для развертывания уровня приложений ИТ-менеджеры должны детально проанализировать стоимость приобретения оборудования.

Влияние архитектуры на доступность

Доступность крайне важна для современных центров обработки данных - сервисы приложений должны быть доступны в режиме 24x7x365 (24 часа в сутки, 7 дней в неделю, 365 дней в году). В зависимости от потребностей конкретного центра обработки данных используются разные схемы обеспечения высокой доступности. Для выбора конкретного решения необходимо определить допустимое время простоев (запланированных и незапланированных). На рис. 3 показано, как процент доступности отражается на продолжительности простоев.

По мере роста требований к доступности растет и стоимость решения. Менеджеры центров обработки данных должны определить, какое сочетание стоимости, сложности и доступности наилучшим образом соответствует требованиям к уровню сервиса. Центры обработки данных, которым нужна доступность примерно 99,95%, могут развернуть одиночный SMP-сервер с такими функциями RAS, как полное резервирование аппаратуры и обслуживание в онлайновом режиме.

Однако для достижения доступности выше 99,95% потребуется кластер. ПО Sun Cluster с переключением при отказе HA (High Availability - высокой доступности) обеспечивает доступность 99,975%. Переключение при отказе HA использует основной сервер и находящийся в горячем резерве; при отказе основного сервера резервный берет на себя его нагрузку. Время перезапуска сервиса зависит от приложений и может занять несколько минут, особенно в случае приложений баз данных, которым для восстановления транзакций требуется откат с обработкой большого объема данных.

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

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

Для трехуровневой архитектуры хорошим примером горизонтальной высокой доступности служит развертывание Web-серверов. Можно развернуть много небольших серверов, на каждом из которых будет установлена отдельная копия ПО Web-сервера. Если один Web-сервер выйдет из строя, его транзакции перераспределяются между остальными работоспособными серверами. В случае серверов приложений они могут размещаться как на горизонтальных, так и на вертикальных серверах, и высокая доступность реализуется с помощью дублирования. Независимо от того, развертывается ли несколько крупных SMP-серверов или много небольших, дублирование остается основным способом обеспечения высокого RAS на уровне приложений.

Однако для уровня баз данных ситуация меняется. Базы данных сохраняют состояние и по своей природе требуют в большинстве случаев разделения данных и возможности доступа к ним со всех процессоров/узлов. Это означает, что для высокой доступности с помощью дублирования нужно использовать такое ПО кластеризации, как Sun Cluster или Oracle9i RAC (для очень высокой доступности).

Выводы

Как у вертикальной, так и у горизонтальной архитектуры есть своя ниша в сегодняшнем центре обработки данных. Хотя сегодня основное внимание сосредоточено на таких новых технологиях, как модульные серверы и параллельные базы данных, на рынке сохраняется высокий спрос на серверы среднего класса и класса high-end.

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

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

Среди многочисленных функций информационной системы, необходимых для управления сетевой логистикой, остановимся вначале на двух ключевых "сетевых" функциях: управление ассортиментом и поддержка категорийного менеджмента.

1. Управление ассортиментом в сетевой торговой компании.

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

Чем качественнее она решается, тем эффективнее развивается розничное торговое предприятие в целом и тем выше его конкурентоспособность.

Задачу управления ассортиментом можно условно разделить на две подзадачи – "внешнюю" и "внутреннюю".

Первая направлена на работу с покупателем в части ассортимента, вторая – на облегчение работы персонала с ассортиментными категориями.

Успешное решение данных задач должно привести к улучшению результатов продаж товаров.

Для эффективного решения "внешней" группы задач необходимо:

• 1) предоставить информацию о товарах покупателям. Информационные и мультимедийные вспомогательные системы призваны помочь покупателям сориентироваться в безграничном море товаров, сделать правильный выбор и получить ценную информацию в кратчайший срок. В то же время они помогают розничным торговцам проанализировать покупательские предпочтения, стимулировать продажу необходимого товара, оптимизировать компоновку торгового зала, рационально размещать ассортимент, что обеспечивает успешное решение внешних задач автоматизации управления ассортиментом;
• 2) решить задачи персонального маркетинга. Реализация функции персонального маркетинга является одной из важнейших задач управления ассортиментом для форматов "супермаркет" и "гипермаркет". Причем, если для супермаркета наибольшую актуальность имеет ведение именно адресного персонального маркетинга с отслеживанием колебаний в предпочтениях конкретных постоянных клиентов данного магазина, то для гипермаркета имеет значение работа с типовыми группами клиентов, принадлежащими к условно определенной категории постоянных покупателей. Что касается дискаунтеров, то персональный маркетинг для них менее актуален. Для выявления предпочтений постоянных покупателей наличие в информационной системе возможности проведения всестороннего анализа продаж и определения структуры покупок также является крайне важной задачей;
• 3) провести качественный визуальный мерчандайзинг. Эффективная выкладка товаров на полках магазинов существенно увеличивает объемы продаж. Для оценки качества решения задач визуального мерчандайзинга информационная система должна иметь возможность ведения и анализа планограмм, описывающих размещение товаров на полках магазинов.

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

1) процесс управления активным ассортиментом (ведение ассортиментных матриц).

Дело в том, что информация о товаре, когда-либо внесенная в базу данных, остается в ней длительное время. Например, при актуальном ассортименте в 7000 наименований товаров в системе может храниться 20–30 тыс. наименований товаров. В этих условиях необходимо предоставить пользователю системы возможность работать только с актуальной информацией об активном ассортименте (рис. 3.4).

Рис. 3.4.

Для решения этой задачи требуется обеспечить выполнение следующих функций:

• введение товара в активный ассортимент. Этому процессу, как правило, предшествует серия пробных маркетинговых мероприятий с данным товаром, подготовка логистики и предпродажная подготовка товара;
• прекращение закупок товара, как первая фаза выведения товара из активного ассортимента. В качестве типовых причин данного процесса можно назвать:
  • а) неудовлетворенность результатами продаж товара;
  • б) смена ассортимента производителем;
  • в) наличие проблем взаимоотношений с поставщиком; и др.;
• прекращение пополнения запасов с распределительного центра компании;
• прекращение работы с товаром, как окончательная фаза вывода товара из ассортимента в информационной

системе (обычно происходит при достижении нулевых запасов);

Удаление информации о товарах на кассовых системах (осуществляется, как правило, после проведения инвентаризации).

Преимущества автоматизации данного бизнес-процесса :

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

Автоматизация данного бизнес-процесса позволяет не допустить движение товара на объект управления, к ассортиментным матрицам которого этот товар не принадлежит (рис. 3.5).

Рис. 3.5.

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

2. Процесс поддержки категорийного менеджмента посредством формирования товарных ракурсов и ракурсов объектов управления, с которыми работает конкретный категорийный менеджер.

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

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

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

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

При этом существует как минимум два базовых типа товарных ракурсов – статические и динамические.

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

В случае определения статического товарного ракурса множество товаров фактически фиксируется как поименованный список (рис. 3.6). Он удобен для строгой фиксации множества (например, для проведения анализа).

Рис. 3.6.

С целью эффективного администрирования товарных ракурсов для определения бизнес-единиц лучше их определять на узлах классификатора товаров. Назовем такие ракурсы динамическими (рис. 3.7).

Рис. 3.7.

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

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

Аналогично формируется ракурс на объекты управления – это статический ракурс, определяющий список магазинов и распределительных центров, в рамках которых осуществляет свою деятельность конкретный категорийный менеджер (рис. 3.8).

Рис. 3.8.

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

Эта функция очень важна при реализации логистической концепции VMI, когда поставщик или производитель участвует в управлении цепи поставок "своих" товаров.

В заключение сформулируем несколько выводов из вышесказанного:

• 1) управление ассортиментом торгового предприятия является важнейшей задачей, от качества решения которой напрямую зависит его успех;
• 2) решения внешней группы задач управления ассортиментом, особенно торговых предприятий больших форматов, призваны обеспечить системы информирования покупателей (информационные киоски, мультимедийные терминалы, информационные тележки и т.п.);
• 3) возможность ведения в информационной системе ассортиментных матриц, товарных ракурсов и ракурсов объектов управления облегчает возможность решения внутренней группы задач управления ассортиментом, которая напрямую связана с качеством реализации функции категорийного менеджмента на торговом предприятии.

Масштабируемость информационной системы

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

При этом надо учитывать два аспекта – адекватность росту и масштабируемость системы.

Если рост компании сопровождается непропорциональным увеличением расходов на ИТ-инфраструктуру, значит, информационная система не способна оптимально поддержать расширение бизнеса.

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

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

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

Для обеспечения масштабируемости информационной системы (возможность обеспечить работу требуемого числа пользователей, оперировать необходимым объемом информации при удовлетворяющей производительности) необходимо правильно выбрать платформу – соответствующее программное обеспечение и серверное оборудование.

Если розничная компания растет, объемы информации о продажах исчисляются не в гигабайтах, а в терабайтах, и без использования "индустриальных", масштабируемых систем управления базами данных типа Oracle, Progress и др. здесь не обойтись.

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

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

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

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

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

Масштабируемость достигается на различных уровнях: а) Техническом; б) Системном; в) Сетевом; г) СУБД; д) Прикладном. Для ОС масштабируемость означает, что ОС не привязана к однопроцессорной архитектуре процессора. В случае усложнения стоящих перед пользователем задач и расширения предъявляемых к компьютерной сети требований, ОС должна обеспечивать возможность добавления более мощных и производительных серверов и рабочих станций в корпоративной сети. Можно рассматривать масштабируемость технических средств, программных средств, масштабируемость системы в целом. В основе масштабируемости лежат такие технологии как: а) Международные стандарты; б) Сетевые и телекоммуникационные технологии; в) Операционные системы; г) Технология клиент/сервер и ряд других средств.

Конец работы -

Эта тема принадлежит разделу:

Компьютерные информационные технологии в управлении. Классификация систем управления

Цель КИС подготовка к использованию современных информационных технологий в рамках КИС как инструмента для решения научных и практических задач в.. Понятие информационной технологии Корпоративные информационные..

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ:

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Твитнуть

Все темы данного раздела:

Понятие информационной технологии. Корпоративные информационные технологии
Технология – сис-ма взаимосвязанных способов обработки материалов и приемов изготовления продукции в производственном процессе. Информационные технологии – система взаимосвязанных мет

Технология обработки информации. Понятие совместимости, открытости и модульности
Информация – совокупность фактов, явлений, событий, представляющих интерес, подлежащих регистрации и обработке. Это подразумевает наличие двух моментов: источник и приемник (потребитель) информации

Виды обеспечения информационных систем
Виды обеспечения АСОЭИ: а) Технические; б)Математические; в)Лингвистические; г)Программные. Информационное обеспечение – система классификации и кодирования информации, технологическая схема обрабо

Архитектура корпоративной информационной системы
Архитектура КИС состоит из нескольких уровней: а)Информационно-логический уровень–представляет собой совокупность потоков данных и центров (узлов) возникновения, потребления

Требования к корпоративным информационным системам
Процессы активного совершенствования технологий обработки информации являются следствием того, что к современным информационным системам (КИС) все чаще предъявляются следующие требования: а) структ

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

Международные стандарты в области компьютерных информационных технологий
В настоящее время всемирное распространение получил комплекс стандартов на систему качества предприятия, разработанный ISO (International Standards Organization), точнее, техническим комитетом ISO/

Информационные модели объекта управления
Современное предприятие можно рассматривать как эффективный информационный центр, источниками информации которого являются внешняя и внутренняя деловая среда. Внешняя деловая среда –

Информационное обеспечение корпоративных информационных систем
Информационное обеспечение – система классификации и кодирования информации, технологическая схема обработки данных, нормативно-справочная информация, система документооборота и т.д. Информационное

Политика формирования информационных ресурсов как единого информационного пространства
Для обеспечения взаимодействия информационных ресурсов различного уровня необходимы: а) Использование современных информационных технологий; б) Современная транспортная информационная среда; в) Еди

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

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

Операционные системы (ОС). Технологии ОС
Среди системных программ особое место занимает операционная система (ОС). Под операционной системой (ОС) (Operating System)понимают комплекс программ, осуществляющих управле

OS Unix и структурные решения в корпоративных информационных системах. Понятие мобильности
Начало разработок ОС Unix было положено фирмой Bell Laboratories в 1968 г. Была предложена многопользовательская 32-х разрядная ОС Unix для Main Frame. В 1976 г. компания AT&T (куда входила и B

Понятие компьютерных сетей и их характеристика
Компьютерная сеть – это комплекс территориально рассредоточенных ЭВМ, связанных между собой каналами передачи данных целях эффективного использования вычислительных ресурсов. Целесообразност

Состав компьютерных сетей
В состав компьютерных сетей входят технические, программные и информационные средства. То есть компьютерную сеть можно рассматривать как систему с распределенными по территории аппаратурными, прогр

Архитектура компьютерных сетей
В общем случае архитектуру компьютерных сетей можно рассматривать с двух точек зрения – это физическая организация компьютерной сети (топология сети) и организация сети на логическом уров

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

Структура глобальных компьютерных сетей
Глобальные сети (WAN, Wide Area Networks) это системы с широкополосными каналами и позволяют организовать взаимодействие между компьютерами на больших расстояниях. В идеале глобальная компьютерная

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

Протоколы Internet
Протокол в данном случае - это, образно говоря, «язык», используемый компьютерами для обмена данными при работе в сети. Чтобы различные компьютеры сети могли взаимодействовать, они должны «разговар

Адресация Internet
Интернет- всемирная система объединённых компьютерных сетей, построенная на использовании протокола IP и маршрутизации пакетов данных. Интернет образует глобальное информационное пространство, служ

Масштабируемость - такое свойство вычислительной системы, которое обеспечивает предсказуемый рост системных характеристик, например, числа поддерживаемых пользователей, быстроты реакции, общей производительности и пр., при добавлении к ней вычислительных ресурсов. В случае сервера СУБД можно рассматривать два способа масштабирования - вертикальный и горизонтальный (рис. 2).

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

Вертикальное масштабирование подразумевает увеличение мощности отдельного сервера СУБД и достигается заменой аппаратного обеспечения (процессора, дисков) на более быстродействующее или добавлением дополнительных узлов. Хорошим примером может служить увеличение числа процессоров в симметричных многопроцессорных (SMP) платформах. При этом программное обеспечение сервера не должно изменяться (в частности, нельзя требовать закупки дополнительных модулей), так как это увеличило бы сложность администрирования и ухудшило предсказуемость поведения системы. Независимо от того, какой способ масштабирования использован, выигрыш определяется тем, насколько полно программы сервера используют доступные вычислительные ресурсы. В дальнейших оценках мы будем рассматривать вертикальное масштабирование, испытывающее, по мнению аналитиков, наибольший рост на современном компьютерном рынке.

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

• поддержка многопроцессорной обработки;
• гибкость архитектуры.

Многопроцессорные системы

Для вертикального масштабирования все чаще используются симметричные многопроцессорные системы (SMP), поскольку в этом случае не требуется смены платформы, т.е. операционной системы, аппаратного обеспечения, а также навыков администрирования. С этой целью возможно также применение систем с массовым параллелизмом (MPP), но пока их использование ограничивается специальными задачами, например, расчетными. При оценке сервера СУБД с параллельной архитектурой целесообразно обратить внимание на две основные характеристики расширяемости архитектуры: адекватности и прозрачности.

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

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

Качественная поддержка многопроцессорной обработки требует от сервера баз данных способности самостоятельно планировать выполнение множества обслуживаемых запросов, что обеспечило бы наиболее полное разделение доступных вычислительных ресурсов между задачами сервера. Запросы могут обрабатываться последовательно несколькими задачами или разделяться на подзадачи, которые, в свою очередь, могут быть выполнены параллельно (рис. 3). Последнее более оптимально, поскольку правильная реализация этого механизма обеспечивает выгоды, независимые от типов запросов и приложений. На эффективность обработки огромное воздействие оказывает уровень гранулярности рассматриваемых задачей-планировщиком операций. При грубой гранулярности, например, на уровне отдельных SQL-запросов, разделение ресурсов вычислительной системы (процессоров, памяти, дисков) не будет оптимальным - задача будет простаивать, ожидая окончания необходимых для завершения SQL-запроса операций ввода/вывода, хотя бы в очереди к ней стояли другие запросы, требующие значительной вычислительной работы. При более тонкой гранулярности разделение ресурсов происходит даже внутри одного SQL-запроса, что еще нагляднее проявляется при параллельной обработке нескольких запросов. Применение планировщика обеспечивает привлечение больших ресурсов системы к решению собственно задач обслуживания базы данных и минимизирует простои.

Гибкость архитектуры

Независимо от степени мобильности, поддержки стандартов, параллелизма и других полезных качеств, производительность СУБД, имеющей ощутимые встроенные архитектурные ограничения, не может наращиваться свободно. Наличие документированных или практических ограничений на число и размеры объектов базы данных и буферов памяти, количество одновременных подключений, на глубину рекурсии вызова процедур и подчиненных запросов (subqueries) или срабатывания триггеров базы данных является таким же ограничением применимости СУБД как, например, невозможность переноса на несколько вычислительных платформ. Параметры, ограничивающие сложность запросов к базе данных, в особенности размеры динамических буферов и стека для рекурсивных вызовов, должны настраиваться в динамике и не требовать остановки системы для реконфигурации. Нет смысла покупать новый мощный сервер, если ожидания не могут быть удовлетворены из-за внутренних ограничений СУБД.

Обычно узким местом является невозможность динамической подстройки характеристик программ сервера баз данных. Способность на ходу определять такие параметры, как объем потребляемой памяти, число занятых процессоров, количество параллельных потоков выполнения заданий (будь то настоящие потоки (threads), процессы операционной системы или виртуальные процессоры) и количество фрагментов таблиц и индексов баз данных, а также их распределение по физическим дискам БЕЗ останова и перезапуска системы является требованием, вытекающим из сути современных приложений. В идеальном варианте каждый из этих параметров можно было бы изменить динамически в заданных для конкретного пользователя пределах.