сайзинг оборудования что это
Сайзинг оборудования что это
Сайзинг для современных информационных систем
Сегодня, после очередного обсуждения сайзинга под ERP систему, решил изложить мою версию процесса выбора и приобретения оборудования в письменной форме.
Мотивы и цели IT-директора или руководителя проекта внедрения информационной системы всегда понятны и прозрачны. С самого начала имеется желание знать, а во-сколько обойдется внедрение той или иной системы (и вопрос покупки «железа» возникает чуть ли ни сразу).
Процесс внедрения системы обычно делится на несколько этапов, а именно:
1. Предпроект
2. Концепт
3. Прототип
4. Тестирование
5. Пилот
6. Эксплуатация
Этапов проекта может быть сколь угодно много, но основные именно эти. По моим наблюдениям, на большинстве проектов вопрос покупки «железа» под промышленную систему встает на самых ранних фазах. Я отлично понимаю, что перед стартом проекта высшее руководство требует вполне конкретного и обоснованного бюджета и мало кому понравится, когда проект начинает вылезать за рамки утвержденных сумм. И если несколько человеко-дней на консалтинг в плюс или в минус к бюджету не столь критичны, то, например, неправильно выбранное и закупленное серверное оборудование — достаточно серьезная головная боль.
Как снизить риски при выборе оборудования и заложить необходимые суммы в бюджет?
Все начинается с дизайна технической архитектуры системы. Большинство систем имеет трехзвенную архитектуру и т. д. и все такое прочее. Обладая этими знаниями рисуется определенная картинка с серверами баз данных, серверами приложений, концентраторами, шкафами, источниками бесперебойного питания и т. д. Выясняются требования бизнеса к системе, а именно, сколько система может простаивать на профилактике, лимиты на восстановление системы, время отклика при работе с системой и много другое, что может повлиять на количество и мощь оборудования. Если бизнес требует 24?7×365, то встает вопрос о резервном центре и возможности/невозможности использования его мощностей при работе в штатном режиме. В результате число серверов может увеличиться вдвое.
Приведу схемку 24?7×365
С одной стороны, все понятно, вот они все наши «железяки», бери и считай. Но! Не все так просто. Предположим, что у нас имеется необходимость вести разработки и их где-то тестировать (на самом деле и предполагать не нужно, без этого не обходится ни один проект). Сразу встает вопрос о системном ландшафте, включающем в себя системы разработки, тестирования и саму промышленную систему. А ведь это тоже оборудование, которое следует иметь ввиду и без которого нельзя, но его нет на схеме, представленной выше. А резервное копирование? А средства коммутации, серверные комнаты, шкафы под оборудование, энергоснабжение, кондиционирование?
Предположим, что под разработку и тестирование у нас имеется старое оборудование, сетевая инфраструктура вполне устраивает и нам действительно необходимо «железо» только под промышленную систему.
Итак, процесс закупки оборудования:
1. У нас есть схема системы (например, которая приведена выше).
2. Мы выбрали «железного» вендора, к которому больше душа лежит или продукция которого является стандартом нашей организации.
3. Мы (предположительно) знаем количество пользователей, которые будут работать в системе и их системные роли (кадровики, коммерсанты, производственники, бухгалтера и прочие финансисты).
4. Имея на руках перечисленные выше данные, обращаемся к «железному» вендору за расчетом и коммерческим предложением. У крупных вендоров имеются специализированные конфигураторы для популярных промышленных информационных систем, которые на основе заполненных опросников (обычно заполняются совместно с «железным» вендором), произведут выбор оборудования, составление спецификации и ее расценку.
5. Цифры, полученные пункте 4, следует внести в бюджет, защитить его и на этом успокоиться.
6. Начать проект и настройку системы на том оборудовании, которое было выбрано под эти цели (из имеющегося или закупленного специально для начальных стадий проекта). Согласитесь, чтобы настраивать систему силами нескольких консультантов (даже десятков), супердома от известных «железных» брендов не требуются.
7. Один из самых важных пунктов. Система настроена и начато тестирование. Именно в этот период можно получить реальные цифры. Узнать сколько ресурсов потребляют пользователи и смоделировать нагрузку, с которой придется справляться промышленной системе.
8. Имея на руках расчеты из пункта 7 можно возвращаться к спецификации вендора и смотреть, насколько мы ошиблись. Ошиблись в большую сторону, хорошо. Сэкономим. В меньшую, тоже неплохо, потому как приобрети мы оборудование на ранних фазах проекта, что бы мы с ним в дальнейшем делали? Ситуация неприятная, но на самом деле не фатально критическая. Все таки «железо» можно масштабировать по вертикали (добавляя процессоры и оперативную память), а современные информационные системы масштабируются горизонтально (за счет добавления серверов приложений или узлов в кластер серверов баз данных).
9. Приобретаем «железо» для промышленной системы.
10. Запускаем систему в промышленную эксплуатацию на приобретенном оборудовании.
Еще один аргумент, почему не следует спешить с покупкой серверного оборудования. Сколько в среднем идет проект внедрения системы? Год! В течении этого года многое может измениться. Как минимум, выбранное оборудование несколько морально устареет и скорее всего подешевеет. Плюс ко всему, на рынке может появиться более интересное «железо».
Сайзинг как показатель эффективности ИТ-службы
Опубликовано:
6 мая 2013 в 12:13
С точки зрения современной сервисной модели сотрудникам организации и ее руководству не важно, как и с помощью каких средств в компании реализована работа той или иной информационной системы (ИС), в частности системы DIRECTUM. Одним из показателей эффективности существующей ИС является обеспечение приемлемой задержки при выполнении автоматизированных операций бизнес-процессов предприятия. Поэтому практика сайзинга ИТ-решений продолжает набирать популярность как во всем мире, так и в России.
Что такое сайзинг и для чего он нужен бизнесу?
Под сайзингом понимается процесс детального планирования аппаратной части информационной системы предприятия под конкретные бизнес-процессы. Проще говоря, как и любое бизнес-приложение, система DIRECTUM требует определенной подготовки ИТ-инфраструктуры перед внедрением.
Каждая организация со временем формирует показатели эффективности, привязанные к бизнес-процессам предприятия. Поскольку ИТ-служба, в том или ином виде, в подавляющем большинстве случаев является вспомогательным подразделением организации, к показателям эффективности ИТ-службы относятся:
В данном контексте применение сайзинга как силами ИТ-службы, так и силами вендора/интегратора/аутсорсера, обеспечит рост качественных показателей ИТ-службы за счет рационального использования ресурсов, а также экономии времени на доработку аппаратной части под бизнес-задачи предприятия за счет детального анализа требований бизнес-процессов на этапе внедрения.
Стратегия сайзинга
Чем точнее постановка задачи на начальном этапе ее решения, тем точнее результат. В случае сайзинга данное утверждение также работает.
В мировой практике выделяют три основные модели сайзинга:
Тестовая модель обеспечивает наивысшую точность результата, однако ошибки, допущенные при построении данной модели, могут сильно отразиться на конечных результатах. Чего нельзя сказать о Пользовательской модели, она менее точная, чем вторая и третья модели, но предоставляет объективную информацию о необходимых характеристиках ИТ-инфраструктуры компании для внедрения бизнес-приложения.
Модели друг друга не исключают, а наоборот дополняют и уточняют. Однако при построении стратегии сайзинга модели следует применять в порядке повышения их точности.
На рисунке, расположенном ниже, представлена стратегия, рекомендуемая Службой поддержки DIRECTUM при проведении сайзинга на этапах ознакомления с системой DIRECTUM, ее внедрения и поддержки.
Заинтересованность компании в DIRECTUM
В случае, когда компания исследует возможность внедрения системы DIRECTUM, о каких-либо существенных вложениях в сайзинг на данном этапе не может быть и речи. Поэтому рекомендуется использовать наиболее дешевую модель сайзинга – Пользовательскую модель.
На этапе знакомства с DIRECTUM, заинтересованная компания может произвести сайзинг по этой модели и удостовериться, что ИТ-инфраструктура компании обладает достаточными характеристиками для внедрения данного бизнес-приложения. Если же существующая ИТ-инфраструктура не удовлетворяет по ряду характеристик, то сайзинг по данной модели позволит выявить, какие характеристики необходимо улучшить.
Служба поддержки DIRECTUM рекомендует производить такой сайзинг при изучении возможности внедрения системы DIRECTUM. Точность данного сайзинга не высока, но полученные результаты помогут вашей компании сделать необходимые выводы о возможности внедрения DIRECTUM. Временные затраты на проведение данного сайзинга минимальны.
На этапе внедрения требуются более точные данные о возможностях ИТ-инфраструктуры компании. Самым точным сайзингом, а также самым дорогостоящим, является сайзинг по Тестовой модели, поскольку в процессе такого сайзинга требуется полная установка и настройка исследуемой системы на существующем оборудовании, а также проведение необходимых нагрузочных тестов. Диапазон, в котором необходимо производить нагрузочное тестирование, может быть заранее не известен, а также начальная настройка системы может быть неточной, поэтому вероятность проведения повторного сайзинга высока. Поэтому перед проведением сайзинга по Тестовой модели можно порекомендовать проведение сайзинга по Транзакционной модели. Благодаря тому, что при построении нагрузочных тестов для Транзакционной модели используются заранее известная информация об объемах данных и транзакций, границы тестирования определены. Сайзинг по Транзакционной модели предоставит довольно точную информацию, которую можно использовать в процессе внедрения, а также позволит определить диапазон, в котором можно производить тесты производительности (сайзинг по Тестовой модели).
При внедрении DIRECTUM необходимость в проведении сайзинга по Пользовательской модели отсутствует, однако, если ранее такой сайзинг был произведен, полученные результаты можно использовать при проведении сайзинга по Транзакционной модели, что повысит точность результатов.
При проведении сайзинга на данном этапе рекомендуется привлекать специалистов службы поддержки DIRECTUM. Специалисты службы поддержки DIRECTUM располагают достаточными компетенциями для оказания помощи в проведении сайзинга по Транзакционной и Тестовой моделям. Служба поддержки DIRECTUM рекомендует при внедрении системы DIRECTUM производить ее стартовую диагностику. Это позволит повысить качество последующей поддержки системы DIRECTUM.
На этапе поддержки DIRECTUM компания обладает всеми необходимыми данными для проведения сайзинга по каждой из трех моделей. Поэтому компания может использовать сайзинг для уточнения достаточности существующей ИТ-инфраструктуры для текущих бизнес-задач.
На данном этапе сайзинг желательно производить в случае планируемых изменений характеристик бизнес-процессов компании, числа пользователей, характеристик ИТ-инфраструктуры и т.д. Другими словами, на данном этапе рекомендуется применять проактивный подход к процессам автоматизации бизнес-процессов компании, а именно:
Служба поддержки DIRECTUM может оказать необходимую помощь в построении необходимой модели, в подготовке необходимых профилей нагрузки, а также окажет помощь в процессе проведения сайзинга.
В каком виде должны быть представлены результаты сайзинга?
Сайзинг довольно сложный процесс и не может быть сделан устно, либо завершаться предоставлением типовых рекомендаций заказчику. Итогом проведения сайзинга является детальный отчет с результатами исследования, которые обоснованы измерениями и статистическими расчетами.
Требования, которые должны быть отражены в отчете по итогам сайзинга:
Использование сайзинга в процессах внедрения бизнес-приложений может служить одним из критериев оценки эффективности работы ИТ-службы. Применение сайзинга означает переход на новый уровень знаний, использование новых современных методов работы и концепций проектирования ИТ-инфраструктуры предприятия. В целом применение сайзинга ведет к повышению эффективности автоматизации бизнес-процессов предприятия, но ни в коем случае нельзя забывать о человеческом факторе, который как минимум на половину определяет, насколько хорошо работает то или иное подразделение организации.
Сайзинг ECM-системы
Под сайзингом (планированием нагрузки) в общем случае понимается процесс детального планирования ИТ-инфраструктуры предприятия под конкретные бизнес-задачи, выполняемые бизнес-приложением. В данной статье будут рассмотрены особенности процесса сайзинга ECM-системы.
Общие сведения о сайзинге
Под сайзингом (или планированием нагрузки) в общем случае понимается процесс детального планирования ИТ-инфраструктуры предприятия под конкретные бизнес-задачи, выполняемые бизнес-приложением (в частности ECM-системой).
В мировой практике выделяют три основные модели сайзинга (планирования нагрузки):
Тестовая модель обеспечивает наивысшую точность результатов планирования нагрузки, однако ошибки, допущенные при построении данной модели, могут сильно сказаться на конечных результатах. Чего нельзя сказать о Пользовательской модели, планирование нагрузки по этой модели предоставляет менее точные результаты, но позволяет получить объективную и достаточную информацию о характеристиках ИТ-инфраструктуры компании.
Модели друг друга не исключают, а наоборот дополняют и уточняют, поэтому при построении стратегии планирования нагрузки для ECM-системы, модели следует применять в порядке повышения их точности.
Сайзинг на разных этапах жизни ECM-системы
Разные модели сайзинга могут применяться на разных этапах жизни ECM-системы. Выбор той или иной модели обусловлен ее стоимостью и точностью.
В случае, когда компания исследует возможность внедрения ECM-системы, о каких-либо существенных вложениях в планирование нагрузки на данном этапе не может быть и речи. Поэтому рекомендуется использовать наиболее дешевую модель – Пользовательскую модель. Планирование нагрузки по Пользовательской модели наименее точное, но позволяет получить объективные данные о возможности внедрения ECM-системы на существующей ИТ-инфраструктуре компании.
На этапе внедрения требуются более точные данные о возможностях ИТ-инфраструктуры компании. Самым точным планированием нагрузки, а также самым дорогим, является планирование нагрузки по Тестовой модели, поскольку в этом случае требуется полная установка и настройка исследуемой системы на существующем оборудовании, а также проведение необходимых нагрузочных тестов. Диапазон, в котором необходимо производить нагрузочное тестирование, может быть заранее не известен, а также начальная настройка системы может быть неточной, поэтому вероятность проведения повторного планирования нагрузки высока. Поэтому перед проведением такого сайзинга можно использовать Транзакционную модель. Благодаря тому, что при построении нагрузочных тестов для Транзакционной модели используются заранее известная информация об объемах данных и транзакций, границы тестирования определены. Планирование нагрузки по Транзакционной модели предоставляет довольно точную информацию, которую можно использовать в процессе внедрения, а также позволяет определить требуемые настройки для ECM-системы и диапазон, в котором можно производить тесты производительности.
На этапе поддержки ECM-системы компания обладает всеми необходимыми данными для проведения планирования нагрузки по каждой из трех моделей. Поэтому компания может использовать планирование нагрузки по любой модели для уточнения достаточности существующей ИТ-инфраструктуры для решения текущих бизнес-задач. Другими словами, на данном этапе рекомендуется применять проактивный подход к процессам автоматизации бизнес-процессов компании, а именно:
Нагрузочное тестирование и сайзинг
Основным источником аналитических данных в процессе сайзинга по каждой модели является нагрузочное тестирование производительности внедряемой ECM-системы на ИТ-инфраструктуре компании-заказчика. Нагрузочное тестирование также может производиться вендором на тестовом стенде, который имитирует ИТ-инфраструктуру компании-заказчика.
Существуют следующие типы нагрузочного тестирования:
Стрессовое тестирование позволяет проверить, насколько выбранная ECM-система работоспособна в условиях стресса на существующей ИТ-инфраструктуре компании, а также оценить способность ECM-системы к регенерации, т.е. к возвращению в нормальное состояние после прекращения воздействия стресса. Стрессом в данном случае может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера.
Ниже представлена таблица соответствия типов нагрузочного тестирования моделям сайзинга.
Тип нагрузочного тестирования
Пользовательская модель. Модель, построенная на числе пользователей
Транзакционная модель. Модель, построенная на производительности
Тестовая модель. Модель на основе тестов производительности
Вспомогательные программные продукты
При проведении сайзинга ECM-системы также можно использовать любые программные средства, позволяющие получить количественные данные о нагрузках на ИТ-инфраструктуру и ее характеристиках:
Планирование нагрузки для ECM-системы довольно сложный процесс и не может быть сделан устно, либо завершаться предоставлением типовых рекомендаций компании-заказчику. Итогом проведения сайзинга является детальный отчет с описанием результатов исследования, которые обоснованы измерениями и статистическими расчетами.
В отчете по сайзингу ECM-системы должны быть отражены, как минимум, следующие данные:
В заключении хотелось бы отметить то, что использование планирования нагрузки в процессах внедрение любых бизнес-приложений обеспечит рост качественных показателей компании в целом за счет рационального использования ресурсов, а также экономии времени на доработку ИТ-инфраструктуры под особенности того или иного бизнес-приложения (в частности ECM-системы) за счет детального анализа требований бизнес-процессов предприятия на начальном этапе внедрения. Применение сайзинга означает переход на новый уровень знаний, использование новых современных методов работы и концепций проектирования ИТ-инфраструктуры предприятия.
Сайзинг хранилищ данных
Сегодня большинство успешных предприятий проявляет серьезный интерес к средствам Business Intelligence (BI) и Хранилищам данных (ХД), так как они обеспечивают понимание бизнеса и позволяют поддерживать конкурентную позицию на рынке. Однако одна из самых ярких тенденций последних лет — невероятный темп роста объемов данных. Чтобы адаптироваться к этим объемам, необходимо грамотно строить крупные Хранилища, которые смогут успешно функционировать и обеспечивать постоянно растущую окупаемость вложений.
Для эффективной обработки больших объемов данных необходимо выйти за рамки простого хранения их в ХД, и поставить задачу определения оптимальной конфигурации аппаратно-программных средств — сайзинга (sizing).
Один из ключевых элементов, обеспечивающих успех сайзинга — аппаратное обеспечение для хранения, обработки и упрощения движения данных.
Очевидно, что крупное Хранилище требует больших объемов носителей информации, но к этому не сводятся все вопросы сайзинга. Обеспечение большого объема хранимых данных еще не говорит о том, что система хорошо оборудована для обработки информации в разумные интервалы времени. К сожалению, в процессе сайзинга часто делается слишком большой упор на емкость и функциональность запоминающих устройств. Однако без учета характеристик системы ввода-вывода могут возникать длительные простои в использовании процессорных мощностей. Поэтому вне зависимости от используемой методологии, результатом сайзинга должен быть хороший баланс пропорционально масштабируемых ресурсов. При этом важно сохранить возможность минимальных перенастроек в будущем.
Проблемы сайзинга
Сайзинг системы ХД должен проводиться на экспериментальных данных, без этого задача становится очень сложной. В отличие от расчета традиционной OLTP-нагрузки, в ситуации с Хранилищами может использоваться лишь некоторая часть общей информации о производительности.
Если полную нагрузку OLTP-системы можно рассчитать, исходя из нагрузки на каждую отдельную транзакцию, а ресурсы масштабируются в зависимости от количества транзакций и пользователей, то в случае с ХД все иначе. Единица нагрузки в Хранилище — величина переменная, не связанная напрямую с объемом данных. Эта изменчивость осложняет сравнение утилизации ресурсов различных ХД-приложений, а, следовательно, и оценку требований к вновь создаваемой системе.
За много лет существования ХД-технологии сформировалась целая система планирования мощностей и оценки использования ресурсов. К сожалению, большая часть информации недоступна или неприменима к каждому новому проекту. Нерегламентируемая природа ХД-нагрузки осложняет сравнение разных систем.
Оценка вычислительных мощностей (процессорного блока) в Хранилище — сложная задача, в том числе, и потому, что требования к ЦП зависят от сложности запросов. Чтобы построить базу знаний, на основе которой вычисляются параметры процессора (или нескольких процессоров) для конкретной нагрузки Хранилища, необходимо провести экспериментальные тестирования, использовать отраслевые критерии, найти экспертов и проявить немало изобретательности. Не имея возможности тестирования пробных запросов, даже хороший специалист вряд ли оценит потребности в ресурсах.
Точность в задаче сайзинга
Сложная методология сайзинга создает ложное ощущение точности, но при этом не всегда обеспечивает правильную оценку. На самом деле, разумный расчет параметров системы возможен только при исчерпывающей информации об объемах данных, требованиях к ресурсам для всех возможных запросов, а также при наличии экспертного опыта.
Каждый проект сайзинга подразумевает некоторый уровень точности и диапазон допустимой ошибки в зависимости от сложности приложений. Эта задача требует расчета рисков и планирования непредвиденных затрат.
Кроме того, можно провести эталонное тестирование для конкретного приложения и данных. Однако это обычно оказывается очень дорого. В большинстве случаев приложение разрабатывается после установки аппаратного обеспечения, и поэтому эталонный анализ системы до покупки аппаратных средств невозможен.
По мере повышения качества данных сайзинговые оценки становятся более точными.
Этапы сайзинга Хранилища данных
Чтобы грамотно оценить размеры системы и добиться оптимальной эффективности, необходимо выполнить ряд шагов:
Оценивая нагрузку, важно иметь опыт работы с Хранилищами данных, хорошо разбираться в конкретной СУБД, а также в предметной области.
Три основных системных ресурса, которые зависят от нагрузки Хранилища — следующие:
Существует два основных фактора, связанных с нагрузкой:
Требования к хранению и обработке влияют на все системные компоненты. Рассмотрим каждый фактор в отдельности.
Требования к объему запоминающих устройств (к дисковому пространству)
Оценка дискового пространства для хранения данных — это самый простой аспект сайзинга системы. Удивительно, что многие проекты сайзинга сосредоточены исключительно на нем. При планировании ХД-проекта расчет объема данных не составляет труда, во всяком случае, если известен исчерпывающий перечень источников данных.
Например, если информация извлекается из существующей транзакционной системы, то ее объем либо известен, либо очень легко поддается оценке.
Какие данные наиболее ценные?
Если бюджет проекта ограничен, то приходится регулировать поступление тех или иных данных в Хранилище. Решения должны приниматься на основе их ценности для бизнеса. Далее нужно провести вычисление минимальных объемов. Затем можно проанализировать ситуацию и выяснить, что еще необходимо включить в Хранилище в зависимости от ресурсов проекта.
Одной из главных рекомендаций является выбор данных, относящихся к различным областям деятельности компании, и лишь во вторую очередь — использование дополнительных уровней исторической информации. Одним словом широта информации имеет приоритет над глубиной.
Иногда, в попытке сократить объем Хранилища, приходится выполнять дополнительные операции загрузки-выгрузки данных (например, загружать детальные данные только за определенные периоды (поквартально, посезонно), а за остальные периоды хранить лишь итоговые показатели). В итоге все эти операции оказываются дороже, чем расширение ХД.
Как оцениваются объемы?
Среди компонентов, требующих пространства на запоминающем устройстве, нужно назвать следующие:
Большинство поставщиков БД обеспечивает подробную документацию, позволяющую вычислить размеры всех таблиц и индексов в СУБД для любой заданной схемы.
Что касается пространства, необходимого для журналов СУБД, то оно напрямую зависит от частоты обновления ХД. Однако чаще всего этот показатель составляет не более 0.1 процента от всего размера Хранилища на цикл обновления.
Если в СУБД выполняются запросы, в которые входят крупные операции объединения, агрегирования, сортировки, то необходима память для хранения промежуточных или частично обработанных данных. По мере того, как база данных приближается к границам выделенной памяти, для временного хранения частично обработанных данных используется дисковое пространство и высвобождается память для дальнейшей обработки. Большинство ХД-систем обрабатывает больше данных, чем может храниться в памяти, поэтому им необходимо пространство для временной БД. Оценивать требования к временной базе трудно, так как на них оказывают влияние несколько внешних факторов, таких как размеры системной памяти и параллельность обработки. Обычно для оценки данного параметра опытному специалисту в области ХД требуется помощь поставщика СУБД. Недооценка требований к пространству для временной базы может привести к неправильному выполнению больших запросов или к ограничению параллельного выполнения запросов.
Большинство проектов ХД требует некоторого дискового пространства для подготовки исходных данных — этапа развертывания. В зависимости от операционных процедур требования к пространству могут сильно различаться.
Описаные выше оценки — это минимальные требования к объему запоминающих устройств. Существует еще несколько факторов, которые влияют на конфигурацию Хранилища в целом. В том числе:
Например, предположим, что требования к Хранилищу покрываются 11 дисками, но в системе есть два дисковых контроллера. Тогда будет лучше использовать шесть дисков на каждый контроллер, чтобы равномерно распределить операции ввода-вывода.
Регулирование количества дисков из соображений производительности может привести к появлению дополнительного пространства. Однако задача балансировки эффективности и расходов всегда остается очень важной и зависит от приоритетов проекта.
Характеристики обработки данных
Даже в нерегламентируемой среде количество формулируемых запросов все-таки ограничено, и их можно разделить на несколько общих категорий. Например, ресурсы процессора в основном потребляют запросы со значительным количеством арифметических операций в расчете на строку данных. Другие же запросы, требующие простых операций фильтрации на больших объемах данных — связаны с системой ввода-вывода. Важно помнить, что потребности в ресурсах для различных категорий запросов разные, и при выполнении сайзинга системы важно как можно точнее классифицировать эти категории.
Отдельно взятая функциональная единица ХД — запрос — может быть распараллелена, чтобы максимально повысить потребление ресурсов и добиться ответа за кратчайшее время. Время на выполнение запроса в ХД-системе может колебаться в зависимости от ситуации, в том числе, от сочетания запросов, выполняемых в один и тот же момент времени.
Только специалист по загрузке Хранилища с помощью поставщика СУБД и архитектора данных способен проанализировать схему и спрогнозировать потребности в ресурсах для потенциальных запросов.
Классификация запросов
Для систематизации и упрощения анализа проводится классифицирование запросов. Этот процесс начинается с четкого исследования схемы БД, характеристик данных и запросов. Цель состоит в следующем:
В зависимости от конструкций, используемых в запросах, и от знания самих данных можно оценить минимальное количество данных, которое будет вовлечено в запрос.
Запросы можно классифицировать по-разному, например:
Кроме того, запросы классифицируется в зависимости от доминирования тех или иных ресурсов при их выполнении. Для этого оценивается интенсивность обработки, необходимой для тех данных, которые вовлечены в исполнение запроса. Очень часто такие оценки базируются исключительно на опыте специалиста, который решает данную задачу.
После того, как все характеристики разнообразных запросов подробнейшим образом рассмотрены, можно выяснить, какие из запросов требуют больших ресурсов процессора, а какие — ресурсов системы ввода-вывода (всю эту информацию удобно систематизировать в классификационной таблице запросов). Таким образом, станет очевидно, для каких задач необходимо конфигурирование системы с ориентацией на процессорные мощности, а для каких — на пропускную способность системы ввода-вывода.
Различные режимы функционирования
Для большинства Хранилищ данных характерен многорежимный тип функционирования. Для разных режимов могут иметься разные требования к потреблению ресурсов, и необходимо их сбалансировать. В зависимости от времени суток или года, от класса пользователей потребности могут быть очень разными. Выполняя сайзинг системы, нужно учитывать все режимы и выставлять приоритеты в случае возникновения конфликта требований.
Если пользователи системы работают по определенному графику и имеют выделенное время на выполнение своих индивидуальных запросов, то, очевидно, мы имеем режим обработки запроса от одного пользователя (или так называемый единичный поток запросов). Тогда главной задачей является максимально короткое время выполнения запроса. С другой стороны, если в системе одновременно оперирует несколько пользователей, и для них не так важна временная задержка, то эффективность одного потока не имеет принципиально значения, но зато критическим фактором становится пропускная способность сети.
Во многих ситуациях такие параметры, как ограниченная память или сетевые ресурсы, могут привести к холостой работе процессоров или сети. Цель состоит в том, чтобы сконфигурировать систему таким образом, чтобы она отвечала требованиям нагрузки и как можно больше приблизилась к границам использования ресурсов. Насыщенные вычислительные мощности и максимизация подсистемы ввода-вывода в течение основного времени функционирования обеспечат наилучшую окупаемость вложений.
Бизнес-требования
Очевидно, что основная цель инфраструктуры Хранилища данных — решать бизнес-проблемы. Поэтому так важно собрать все бизнес-требования, касающиеся сайзинга и преобразовать их в требования к системе. Например, некоторое подразделение может потребовать перезагрузки данных из транзакционной системы в Хранилище раз в неделю, и такую задачу нужно выполнить в течение 6 часов. Это требования нужно транслировать во всевозможные показатели чтения, записи и обработки данных, чтобы гарантировать наличие в системе достаточных ресурсов.
Все бизнес-требования можно связать с конкретными показателями системы. В процессе сайзинга можно использовать эту взаимосвязь, гарантируя тем самым, что, внедряя систему ХД, организация получит именно то, что исходно требовалось.
Результаты сайзинга
После сбора всех соответствующих данных о нагрузке, бизнес-требованиях и данных информацию можно объединить в единое руководство по сайзингу и конфигурированию Хранилища. А именно провести:
Заключение
Сайзинг для Хранилища данных — это сложная задача, требующая опыта для точной оценки конфигурации, которая отвечает требованиям бизнеса. Качество сайзинговых оценок зависит от точности данных, используемых в процессе. Выполнив некоторый анализ и охарактеризовав нагрузку, можно существенно повысить окупаемость уровень оптимизации системы. В отсутствие данных о нагрузке все оценки могут быть очень приблизительными.
Чтобы добиться успешного проекта, необходимо разработать гибкие планы конфигурирования систем, сбалансированных с точки зрения ресурсов. Для кластерных конфигураций нужно гарантировать, что основные составляющие системы хорошо сбалансированы сами по себе и отвечают требованиям к системе ввода-вывода и процессорным мощностям для их собственной нагрузки. Разные компании принципиально отличаются друг от друга, следовательно, различаются и их Хранилища. Поэтому задача сайзинга каждый раз требует творческого подхода.