BC/NW 2013: №1 (22):10.1

 

СИСТЕМНАЯ ИНТЕГРАЦИЯ: ИСКУССТВО ИЛИ РЕМЕСЛО

 

В.О.Рыбинцев

 

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

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

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

 

1. Базовые правила Системной интеграции

 

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

 

Правило системной интеграции № 1: прикладная задача – это главное!

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

 

Правило системной интеграции № 2: обеспечивай разумную достаточность качества информационной систем (ИС).

На рынке существует огромное количество различных технологий и продуктов, которые конкурируют друг с другом. По экономическим соображениям невозможно собрать ИС на основе самых, самых, самых передовых технологий. Все должно быть подчинено решению прикладной задачи заказчика с требуемым ему качеством. Качество и, следовательно, стоимость компонентов системы должна приводить к достаточному для заказчика качеству функционирования системы в целом. Бессмысленно строить систему с большим запасом по производительности, масштабируемости и/или надежности. Жизненный цикл ИС может отказаться таким, что заложенной в процессе построения системы избыточностью заказчик просто не успеет  воспользоваться!

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

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

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

 

Правило системной интеграции № 3: ориентируйся на долгосрочные отношения с заказчиком.

Когда Системный интегратор может сказать, что некоторый заказчик – это его заказчик? Многие считают, что это происходит в тот момент, когда деньги заказчика поступили на  счет интегратора. Это не так. Заказчика можно считать своим, когда он заплатил второй раз.

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

 

2. Задачи Системной интеграции

 

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

Если Системный интегратор спрашивает заказчика: «Чего изволите?», - это   обычный продавец. Такие люди (фирмы) тоже нужны и весьма уважаемы, но это другая профессия.   Если заказчик говорит: поставьте мне кластер с параметрами (перечень), дисковый массив с параметрами (перечень), программное обеспечение (перечень) – эта   задача тоже не имеет никакого отношения к интеграции. Это задача  закупки. Системный интегратор должен воспринять от специалиста по оптимизации бизнес-процессов (четвертый уровень пирамиды [1]) общую задачу и перевести ее на язык информационных технологий :

·        разработать общую архитектуру (общие принципы функционирования) информационной системы;

·        выбрать нужное прикладное и системное программное обеспечение (сформировать профиль SW);

·        выбрать нужное оборудование (сформировать профиль HW);

·        обеспечить требуемое качество функционирования системы (за счет SW, HW, создания инфраструктуры,  регламентов работы, инструкций, организации обучения и технического обслуживания) при заданных ограничениях на стоимость.

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

В известной триаде «для чего, что и как» [1] Системная интеграция  занимает среднее положение, отвечая на вопрос «что», что нужно сделать, чтобы решить задачу. Постановщик задачи (четвертый слой пирамиды [1]) отвечает на вопрос «для чего», а специалисты в конкретных областях (два нижних слоя пирамиды) отвечают на вопрос «как», как сделать так, чтобы выбранные интегратором компоненты ИС образовали работоспособную конструкцию. Чрезвычайно важно, чтобы Системный интегратор обладал набором знаний, позволяющим ему, с одной стороны, оценить принципиальную реализуемость пожеланий заказчика, а с другой стороны, правильно сформулировать локальные задачи специалистам (серверное оборудование, системы хранения данных, сети, электропитание, пожаротушение и пр.)

При этом необходимо учесть большое число самых разнообразных факторов (ниже они просто перечисляются):

·        ненадежность технических средств

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

·        наличие ошибок в программном обеспечении

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

·        квалификация персонала

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

·        возможность пожара и других техногенных факторов

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

·        климатические условия

Если устанавливаете систему кондиционирования, то нужно понимать, как она будет работать летом (в жару) и как она будет работать зимой (в мороз). Что будет, если она откажет?

·        доступность электрической энергии

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

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

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

·        доступность внешних коммуникаций

Может оказаться, что решение проблемы «последней мили» в выбранном районе делает проект бесперспективным.

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

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

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

 

3. Классификация прикладных задач по требованиям к информационным технологиям

 

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

Application  SW1             существенно отличается от                   Application SW 2

       System SW1              очень похоже на              System SW 2

                               HW1     практически совпадает с    HW2

Важная задача – выделить такие общие черты у прикладных задач, которые являются существенными для выбора тех или иных информационных технологий. Есть надежда, что проведение классификации прикладных задач позволит разделить безграничное множество ИС на некоторое обозримое число типов, для каждого из которых удастся выработать конкретные рекомендации (приемы, решения). Тогда можно будет сформировать конечный набор правил типа: если ИС ориентирована на решение прикладной задачи типа А, то для ее решения нужно применять технологии Т1, Т3 и Т6, а если к типу В, то Т2, Т4 и Т5.

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

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

Ошибки бывают:

·        технические (мало памяти, дисков, процессоров);

·        технологические (вместо системы хранения SAN использовали NAS);

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

Технические ошибки исправляются достаточно легко (дешево), технологические – уже труднее (дороже), а методологические – это очень дорого (нужно просто перестраивать центр).

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

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

Определим следующие направления классификации прикладных задач:

·        Прикладные задачи, требующие от информационной системы вычислительной мощности   («compute-centric»).

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

·        Задачи, требующие от информационной системы высокой пропускной способности («throughput-centric»).

К категории Throughput-centric относятся прикладные задачи, ориентированные на обработку большого потока простых задач. Понятно, что поток задач в той или иной степени присутствует всегда, но в данном случае именно наличие интенсивного потока задач, требующих обработки, является определяющим признаком. При этом каждая задача может быть весьма простой. Это класс задач типа «клиент – сервер». Скажем, продажа авиабилетов. Здесь важно количество задач (запросов), обслуженных в единицу времени.

·        Задачи, требующие от информационной системы умения манипулировать большими объемами информации  («data-centric»).

К категории Data-centric относятся прикладные задачи, особенностью которых является работа с большими объемами информации. Понятно, что при решении всех задач в той или иной степени идет работа с информацией, но в данном случае хранение и извлечение больших объемов данных является определяющим признаком. Примером является работа с базами данных (ORACLE, DB2, SYBASE, MS-SQL).

·        Задачи, требующие от информационной системы существенной  распределенности в пространстве и независимости от местоположения компонентов («network-centric»).

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

·        Задачи, требующие от информационной системы умения манипулировать графической информацией («graphics-centric»).

К категории Graphic-centric относятся прикладные задачи, осуществляющие обработку трехмерной графики в реальном масштабе времени. Понятно, что сегодня многие приложения включают трехмерную графику, но для некоторых из них именно этот признак является определяющим. Пример – современные видеоэффекты в кино, механический САПР, отображение геолого-геофизической информации. Важно, что обсчет графики сводится к выполнению объемных вычислений с плавающей точкой. Просто потом результат этих расчетов представляется в виде изображения. В простейших случаях эта задача решается установкой специального графического ускорителя. Здесь нет (почти) задачи для Системной интеграции. В сложных случаях эта задача близка к задаче выполнения сложных вычислений, и для ее решения применяются те же подходы, что и для Сompute-centric приложений. Поэтому, не будем выделять этот класс задач в отдельную категорию, а включим их в задачи типа Compute-centric.

На плоскости можно образовать следующую систему координат: «data-centric – network-centric» и  «througthput-centric  – compute-centric».

 

 

Рис. 3. Классификация прикладных задач

По-русски это звучит следующим образом:

·        «пропускная способность – производительность» -  вертикальная ось;

·        «ориентация на сконцентрированные данные – ориентация на сетевой доступ» - горизонтальная ось.

В данной системе координат следует выделить следующие три принципиальные группы информационных систем:

Data-centric & throughput-centric – работа с потоком задач, ориентированных на операции с большими объемами информации. Это базы данных  всех возможных типов на основе промышленных СУБД: ORACLE, DB2, SYBASE, MS SQL и некоторые другие. Такие системы должны обеспечивать обработку интенсивных потоков запросов к базе данных большого объема (работа многих сотен и даже тысяч пользователей с базой данных много гигабайтного или терабайтного объема).  Будем назвать этот класс задач – DB (database).

Network-centric & throughput-centric – это работа с потоком запросов от большого числа (тысячи) существенно распределенных пользователей за относительно простой и незначительной по объему информацией. Это работа всех web-приложений. Будем называть этот класс задач – WEB.

Compute-centric – это класс задач, связанных со сложными математическими расчетами. При этом, объемы перерабатываемых данных не имеют значения и местоположение пользователей тоже, так как затраты времени на сам расчет многократно превышают время загрузки-выгрузки данных и время доставки результатов расчета к пользователю. Пример – обработка данных сейсморазведки, метеорологические моделирование, моделирование ядерного взрыва. Будем называть этот класс задач – HPC (High Performance Computing)

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

 

                               Рис. 3  Пространство прикладных задач

 

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

 

4. Оценка производительности информационных систем

 

После классификации прикладных задач неизбежно возникает необходимость сравнения представленных на рынке технологий и инструментов, с помощью которых эти задачи могут быть решены. Какие это инструменты/технологии? Например, серверное оборудование, сетевое оборудование, системы хранения данных.  Как оценить возможности тех или иных серверов, решающих перечисленные типы задач, и сравнить однотипные между собой. Нужны какие-то метрики (метры, секунды, кг). В случае с ИС прежде всего говорят о производительности. Это самый понятный и очевидный критерий.  В самом общем смысле – это количество задач заданного класса, которое система решает в единицу времени, либо обратная величина – время решения одной задачи. Однако очевидно, что производительность для разных типов задач должна измеряться в разных единицах. Для задач типа HPC важно время решения именно счетной задачи, а для задач типа DB – количество обслуженных обращений  к базе данных в единицу времени.

Сразу оговоримся. Мы рассматриваем аспект производительности некоторого комплекса, состоящего из аппаратуры, системного программного обеспечения и программного обеспечения промежуточного уровня. Этот аспект, безусловно, важен, но отметим, что он далеко не единственен. Не менее важным аспектом является, например, аспект доступности приложения. Доступность – это вероятность того, что при обращении к приложению его удается застать в работоспособном состоянии. Что толку от самой производительной платформы, если ее не удается застать работающей! Поэтому, обеспечение доступности приложения – это другая очень важная задача.

Есть и другие аспекты. Например, безопасность. В целом ряде случаев именно аспект безопасности может быть самым главным, и основные средства будут затрачены именно на достижение требуемого уровня безопасности.  

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

Рассмотрим некоторые из наиболее распространенных тестов.

Прежде отметим, что есть набор тестов, с помощью которых измеряются и сравниваются возможности аппаратуры. Это универсальные тесты. Они ориентированы на оценку производительности оборудования (процессоров, памяти, дисковых накопителей) и, во многом, инвариантны по отношению к классу решаемой задачи. Тем не менее, часто они оказываются весьма полезными при сравнении технических решений. Начнем именно с них, а потом перейдем к тестам, ориентированным на тип прикладной задачи. Такие тесты, ориентированные на конкретные типы прикладных задач, будем называть специальными, так как с их помощью можно оценить производительность системы на конкретном классе задач (DB, HPC, WEB).

Первая группа универсальных тестов ориентирована на оценку производительности процессоров. Это тесты SPECfp2006 для операций с плавающей точкой и  SPECint2006 для целочисленных вычислений. SPEC – это организация, специализирующаяся на проведении тестов, а все результаты тестирования и описания самих тестов приведены на сайте www.spec.org .

Тесты SPECfp2006 и SPECint2006 измеряют производительность процессора и памяти, а это – центральные компоненты любого компьютера. В данных тестах измеряется время решения определенного набора задач, которое затем сравнивается с временем решения этого тестового набора задач на сервере Sun Enterprise Ultra 2 c процессорами UltraSPARC II. Результат показывает, во сколько раз тестируемая платформа лучше эталонной. Если в таблице результатов указано, что для некоторой платформы результат SPECfp2006 равен 2.5, то это означает, что тестируемая платформа решила тестовый набор задач в 2.5 раза быстрее Sun Ultra 2. Очевидно, чем значения теста больше, тем лучше. Важно, что отдельно оценивается производительность по целочисленным операциям и операциям с плавающей точкой.

Тесты существуют в варианте base (как есть) и в варианте peak (максимально возможный результат после оптимизации). Лучше ориентироваться на base, так как в реальной жизни  оптимизацию реального приложения провести весьма проблематично.

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

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

Вторая группа универсальных тестов ориентирована на измерение способности серверов обрабатывать множество (поток) счетных задач. Это тесты типа SPECfp_rate2006 и SPECint_rate2006. Эти тесты измеряют количество типовых задач, которое тестируемая система способна решить в единицу времени. Для этого при тестировании на системе запускается несколько задач одновременно (тех же самых, что в тесте SPECfp2006 и SPECint2006). При этом число задач равно числу (процессоров/ядер/потоков). Эти тесты измеряют пропускную способность системы. Понятно, что с ростом числа процессоров, пропускная способность увеличивается. Сравнение идет по-прежнему с эталонной системой – Sun Ultra 2. Если некоторая система имеет показатель 2.5, то это означает, что она решает в единицу времени в 2.5 раза больше тестовых задач (int или fp), чем Sun Ultra 2. Тест позволяет оценить масштабируемость системы на счетных задачах с ростом числа процессоров.

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

Третья группа универсальных тестов оценивает пропускную способность ввода-вывода при взаимодействии с системами хранения данных. Это тесты типа  SPC (Storage Performance). Информацию о них можно получить на сайте www.storageperformance.org .

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

Второй тест – SPC-2, измеряет пропускную способность системы хранения данных вместе с контроллером в Мбайт/с, т.е. измеряет потоковую производительность (важно, например, для видео по запросу).

Универсальные тесты позволяют оценить некоторую аппаратную платформу и сравнить несколько альтернативных вариантов, чтобы выбрать лучшую по некоторому критерию. Если несколько платформ показывают близкие результаты,   часто для выбора пользуются соотношением price/performance, т.е. делят результат теста на стоимость системы. Понятно, что чем меньше это значение, тем лучше.

Универсальные тесты применяют в том случае, когда сложно классифицировать реальную задачу. Если задачу удалось отнести к одному из обозначенных ранее классов (DB, WEB, HPC), то для оценки аппаратной платформы используют специальные тесты производительности. Так для задач типа DB используют тесты TPC, измеряющие производительность платформы при работе с базой данных в количестве транзакций в минуту. Поскольку запросы могут быть разными, выделяют OLTP (короткие) SQL запросы   и аналитические (длинные) SQL запросы. Им соответствуют тесты типа TPC-C/TPC-D и TPC-H. Описание и результаты тестирования находятся на сайте www.tpc.org . Очевидно, что результаты зависят не только от аппаратной платформы, но и от используемой СУБД (ORACLE, DB2, SYBASE, MS-SQL). Тесты, ориентированные на сложные запросы (TPC-H) проводятся еще и на базах данных разного объема, так как это принципиально важно.

Для задач типа WEB используются тесты SPECweb_2009. Метрикой является количество web-сессий, которые аппаратная платформа с установленным на ней программным обеспечением apache и tomcat, способна поддерживать с требуемым качеством. Описание теста и результаты тестирования находятся на сайте www.spec.org .

Для задач типа HPC используется тест LINPACK, который измеряет время решения системы линейных уравнений разного размера, а метрикой является количество операций с плавающей точкой в секунду (flops). Так как нужное для решения задачи число операций теоретически известно, получив время решения системы уравнений легко вычисляют производительность во флопсах (floating operations per second). Когда вы слышите слова Гигафлопс или Терафлорс, знайте – это результат измерения по тесту LINPACK. Именно по этому тесту ранжируются самые мощные компьютеры в мире (TOP500), список которых можно увидеть на сайте www.top500.org, а описание теста – на сайте www.netlib.org . Так как многие реальные счетные задачи сводятся к решению системы линейных уравнений, этот тест хорошо отражает счетную производительность комплекса. В отличии от теста типа SPECfp_2006, тест LINPACK хорошо распараллеливается и, потому, тестирует не один процессор/ядро, а всю систему целиком.

Но, следует отметить еще раз: реальные задачи могут быть весьма далеки от тестовых. Поэтому, выводы о производительности некоторой аппаратной платформы на конкретной прикладной задаче, сделанные на основе перечисленных тестов, могут быть не совсем правильными, и, чем сложнее реальная задача, тем эта ошибка может быть больше. Если требуется уложиться в выделенный бюджет, а система сложна, можно вложить излишние деньги в одну ее часть в ущерб другим, создав «узкое место», которое испортит характеристики системы в целом. Поэтому, в мире существуют тесты, по сути являющиеся реальными прикладными задачами. Эти задачи весьма сложны и полученные на них результаты очень точно отражают и предсказывают поведение системы. К таким тестам относятся корпоративные тесты компании SAP для системы управления предприятием R/3.

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

У компании SAP единицей измерения производительности является saps. При этом разные аппаратные платформы оцениваются в этих saps-ах на разных задачах (в R/3 множество модулей, каждый из которых решает свою задачу: управление персоналом, финансы, снабжение, склад и др.). В рамках этого теста тестируется и 2-tier и 3-tier архитектура, т.е и база данных, и сервер приложений. Это действительно сложный тест, который требует от системы и высокой производительности на задачах типа DB и на задачах типа WEB, т.е. это DB+WEB приложение. Таких приложений в мире достаточно много (любая система управления предприятием работает так же, и потому, выбор аппаратной платформы для нее может быть произведен на основе результатов тестирования по тестам SAP). Описание тестов и результаты тестирования можно найти на сайте www.sap.com . Для того чтобы тесты производительности SAP соответствовали реальным условиям эксплуатации и могли использоваться для сайзинга (выбора параметров аппаратной платформы) в них симулируется поведение клиента, заполняющего стандартные формы. Каждому такому симулированному клиенту задается среднее время задержки в 10 секунд перед выполнением очередного шага в диалогах, что соответствует среднему реальному времени размышления опытного оператора. Во время выполнения тестов число одновременно работающих симулированных клиентов непрерывно увеличивают до тех пор, пока время отклика системы в диалоговом режиме не превысит установленные спецификацией на тесты 2 секунды. В связи с  направленностью тестов на понимание их результатов людьми, принимающими решения, не обязанными разбираться в технических деталях и терминах, результатам теста является число полностью обработанных бизнес операций. Такими операциями могут быть: число введенных заказов, число произведенных товаров, число заказов на сборку и т.д. Это и есть saps.

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

Наиболее информативным для оценки считается тест модуля SD (sales and distribution). Но, безусловно, существуют и другие тесты (FI – financial accounting, HR – human resources, PP – production planning и др.).  

Таким образом, существует целый набор инструментов, с помощью которых можно сравнить несколько разных аппаратных платформ и выбрать лучшую из них в заданном смысле (в данном случае – по производительности). Очень часто, требования к аппаратной платформе задаются именно в виде значения по некоторому тесту. Например,  комплекс должен обеспечивать N saps на тесте SD. Далее, Системный интегратор должен предложить некоторое решение, обеспечив минимальную стоимость. Поскольку, все это происходит в конкурентной среде (несколько интеграторов борются за право выполнить проект), возникает очень сложный и важный вопрос: каким образом добиться нужной производительности, потратив средства максимально эффективно. Но при этом нельзя забывать, что услуги самого Системного интегратора весьма дороги. Так будет ли привлечение Системного интегратора экономически целесообразным? Системная интеграция – это экономия средств или дополнительные затраты? Ответ на этот вопрос – предмет отдельного обсуждения.

 

Продолжение следует…

 

 

1. Рыбинцев В.О. Системная интеграция – это просто! http://network-journal.mpei.ac.ru/cgi-bin/main.pl?l=ru&n=21&pa=13&ar=1