Критериев выбора сервера под ту или иную прикладную задачу множество. Однако, несомненно, в последнее время часть критериев стала выдвигаться на первый план. В частности, компании стали больше обращать внимания на стоимость владения сервером. Одна из самых сложных задач при выборе сервера ѕ достижение оптимума, оптимального соотношения между необходимой для конкретной задачи производительностью, резервами и возможностями расширения и стоимостью. Наш опыт общения с читателями показывает, что зачастую, боясь ошибиться, компании покупают избыточную производительность, порой заметно избыточную. По оценкам некоторых экспертов, российские компании сегодня перенасыщены вычислительными ресурсами.
Каковы критерии выбора сервера сегодня? Каким образом выбрать оптимальный сервер под ту или иную задачу ѕоб этом мы говорили с участниками нашего круглого стола.
Участники:
От Intelligent Enterprise в круглом столе принимали участие: Константин Зимин, заместитель главного редактора |
Как подходят российские компании к выбору сервера? Каковы критерии выбора? Какую роль в выборе серверов играют цена, брэнд, совет друга? Достаточно ли на рынке информации для выбора сервера?
Дмитрий Захаров
Мне представляется, что всегда один из главных критериев выбора — это соотношение затрат и той потребительской стоимости, которую покупатель получает за свои деньги. Затраты посчитать легко, а определение потребительской стоимости не столь очевидно и сильно зависит от ситуации, в которой находится заказчик. Например, очевидно, что одна из важных составляющих этого понятия — надежность сервера, которая в конечном счете определяется ценой его простоя. Для каждой из ситуаций эта цена рассчитывается по-разному, но в России процедуры такой оценки не слишком устоялись. На мой взгляд, сегодня для очень многих заказчиков цена простоя сервера не столь высока, поскольку бизнес не очень зависит от таких простоев. Однако в связи с тем, что наша экономика становится более организованной, цена ошибки становится более понятной и более высокой. Мы проходим тот же путь, каким шла вся мировая экономика, но находимся пока на ранних стадиях этого процесса.
Со временем цена простоя возрастает. Стоимость ИТ-персонала также возрастает, что делает более оправданным увеличение начальных вложений в серверы, которые обходятся дороже, но обеспечивают большую надежность и лучшую управляемость. Движение, как на мировом рынке, так и на российском, направлено именно в сторону повышения стоимости простоя и стоимости управляющего персонала. Это постепенно делает начальную стоимость сервера менее значимым фактором, чем она была несколько лет назад.
Сергей Бугрин
Прежде всего все определяется тем, какие приложения будут установлены на сервере и какую нагрузку он будет испытывать. Есть приложения, которые должны быть доступны двадцать четыре часа семь дней в неделю, а есть приложения, простой которых в несколько часов не критичен для работы компании. Более того, при росте нагрузки на сервер или при всплеске активности при работе с конкретным приложением возникает вопрос масштабируемости сервера и возможности объединения их в кластеры. Важна также способность системы восстанавливаться: возникла ошибка, сервер восстановился, прошла диагностика, но приложение продолжает работать.
Рассуждая об этом, очень важно выйти за границы менталитета просто PC-сервера. Сервер — это не только файл-сервер, не сервер одного приложения. Современные организации, предприятия используют десятки, а иногда сотни и тысячи приложений, и вопросы консолидации серверов встают очень остро. Эффективная консолидация дает возможность запускать необходимые приложения на одном сервере. Соответственно повышаются требования к квалификации системных инженеров, но одновременно сокращается количество обслуживающего персонала.
Алексей Устинов
Несомненно, есть такие критерии, которые будут одинаковы для всех категорий серверов. Но сервер в понимании компаний малого и среднего бизнеса — это одно. Для более крупных компаний сервер — это совсем другое, и критерии выбора должны различаться. Для SMB-компаний главными критериями будут цена и производительность. Эти компании еще не подсчитывают цену простоя сервера в силу того, что бизнес у них не очень большой. Для них понятие TCO — это то, о чем они пока только читали, но реально не применяли. В крупных компаниях есть ИТ-отдел, который строит ИТ-политику и знает, сколько может стоить обслуживание серверов. Там понимают, что иногда цена самого сервера меньше расходов на его обслуживание.
Цена эксплуатации складывается из разных составляющих. Одна из них — расходы, связанные с поиском и устранением неисправностей. Настоящие серверы должны обладать так называемыми RAS-характеристиками (Reliability — надежность, Availability — высокий коэффициент готовности, Serviceability — простота обслуживания). Еще к этому иногда добавляют Useability (удобство эксплуатации) и Manageability (легкость управления). Характеристики, которые уменьшают цену обслуживания, очень важны. Существенно, сколько ресурсов и времени администратор должен тратить, чтобы следить за работоспособностью сервера. Поддерживает ли сервер удаленное управление, есть ли встроенные средства самодиагностики, которые ведут мониторинг температуры, вентиляторов, электрических параметров, и позволяют ли они оповестить администратора, если какой-то параметр вышел за пределы допустимого. В идеале, где бы администратор ни был, сервер должен сообщить ему, что с ним что-то происходит. Где бы ни находился администратор, он должен иметь возможность удаленно зайти на сервер и посмотреть, что же случилось. В части российских компаний это прекрасно понимают.
Александр Кузин
Если у компании есть опыт использования информационной системы, то такая компания при выборе сервера, как правило, в первую очередь будет интересоваться надежностью и ТСО. Большинство же компаний начинали свою ИТ-историю с нуля, с обыкновенного персонального компьютера. На каком-то этапе появлялся самый мощный компьютер — сервер. Поэтому к покупке средства производства (сервера) они подходят так же, как обыкновенный покупатель — к покупке компьютера для дома, и интересуются только соотношением цена/производительность. Чем дольше будет бизнес-история компаний, тем фундаментальнее будет и подход к выбору стратегии развития, а следовательно, и к стратегии развития ИТ-подразделения и компьютерной техники соответственно.
Михаил Елашкин
Проблема выбора любой системы укладывается в отрезок от «религиозной веры» до «полностью прагматичного подхода». Чем меньше у человека информации, тем больше «религиозности» в его построениях. Безусловно, я имею в виду человека, который реально стремится к оптимальному выбору и использует всю доступную ему информацию. К сожалению, среди ИТ-специалистов довольно часто встречаются фанатики, которые выбрали «любимую» систему раз и навсегда и глухи к любым доводам.
На мой взгляд, сегодня российские специалисты двигаются от «религиозного» подхода к «прагматическому». Но последний пока еще недостижим. Основные препятствия на этом пути — недостаток информации и недостаточная квалификация для использования существующей информации. Действительно, доступно вполне достаточное количество результатов тестов серверов, но ими редко пользуются. Наша компания, Elashkin Research, провела исследование и выяснила, что осведомленность российских потребителей серверов о тестах TPC составила 2,7 балла по пятибалльной шкале. А ведь это открытая, бесплатная и весьма полезная информация. В реальной жизни большинство потребителей делают выбор на основе собственного опыта, но он далеко не полон и не систематизирован.
Ренат Юсупов
Я считаю, что универсальных критериев нет и критерии абсолютно невозможно ранжировать. Например, надежность 99,999 — совершенно правильный критерий, важный для больших компаний. А для маленькой компании… Нужно доверять экспертизе поставщиков. Именно поставщиков, потому что они свои серверы знают лучше, проводят предварительный технический анализ, они их позиционируют в различные целевые группы и четко выделяют именно те параметры, которые они считают для этой группы наиболее важными. Если экспертиза у продавца больше, а у покупателя меньше, то доверяйте продавцу.
Но и здесь можно ошибиться. Скажем, компания, которая продает двадцать или даже двести серверов в год, — это не серверная компания. Она не может иметь достаточного опыта, у нее очень мало экспертизы, и это становится риском заказчика.
Михаил Елашкин
Я не согласен, что нужно доверять поставщикам. Действительно, у многих поставщиков накоплен очень большой опыт, но где гарантия, что они используют его во благо заказчика? Кроме того, большая часть поставщиков несвободна от маркетинговых влияний. Всегда существует конфликт интересов между продавцом и покупателем. В этих условиях я бы рекомендовал работать с поставщиком, но постоянно проверять его рекомендации.
Дмитрий Захаров
Поскольку задача выбора многокритериальная и очень сложная, решать ее математическим путем тяжело. И, наверное, она в большой степени решается коллективным интеллектом рынка, который делает выбор в пользу одной или другой компании, основываясь в конечном счете на репутации этой компании в течение длительного времени. Если компания — лидер рынка, то это положение дел имеет свои обоснования и почти никогда не бывает случайным. Репутация поставщика — это часть брэнда.
Но все критерии выбора — качественные. Они совершенно не позволяют сделать выбор конкретной конфигурации сервера, оптимальной в том или ином случае. Скажем, сервер куплен три года назад, теперь стал маловат, какой купить новый? Часто приходится слышать мнение, что российские предприятия перенасыщены вычислительной техникой. Они перекупили серверной мощности и переплатили за нее.
Ренат Юсупов
Когда ИТ-менеджер покупает сервер, он может ошибиться только в одну сторону. Ограничения снизу всегда существуют — это производительность. Плохо, если не докупят мощности, если перекупят — не так страшно. У систем не бывает лишней мощности, она моментально чем-то заполняется. Как только появляется свободный ресурс, то его мгновенно используют — под дополнительные приложения, под развитие. Все зависит от типа компании. Если компания динамично и быстро развивается и у нее хватает средств, то это не такая большая ошибка, возможно, она потом даже обернется небольшим преимуществом. Я считаю, что не очень страшно ошибиться в эту сторону.
Если заказчик общается с поставщиком, у которого есть технические консультанты, база знаний, тестовые лаборатории, то вероятность «ошибки вниз» не очень большая.
Но как быть с оптимизацией затрат? Кроме того, опыт общения с российскими компаниями, устанавливающими серверы для систем автоматизации предприятия, показывает, что зачастую ошибка «вверх» достигает 100%! Так что вопрос остается: как купить оптимальный сервер под конкретную задачу? Часто компании доверяют выбор поставщику ПО, которое будет работать на этом сервере. Существует точка зрения, что поставщики серверов в принципе не способны сделать сайзинг сервера под конкретную систему, поскольку не являются специалистами в этом ПО. Кроме того, доверять поставщику все же страшновато…
Михаил Елашкин
Сайзинг на Западе давно стал стандартной процедурой для большинства компаний. А в русском языке пока даже нет адекватного перевода. Но следует понимать, что «не все сайзинги одинаково полезны».
В принципе существуют четыре различных способа сайзинга. Первый основывается на числе пользователей. Большинство производителей говорят: если у вас есть СУБД DB2 или Oracle, есть сто пользователей, из них двадцать активных, тридцать пассивных, то вам нужен такой-то сервер. Это самый простой вариант сайзинга. В этом случае мы ничего не знаем о сложности транзакций, количестве данных на каждого пользователя, общем объеме данных в системе.
Второй вариант исходит из производительности системы. Эта модель сложнее, чем предыдущая, но в ней делаются определенные допущения. Скажем, считается, что производительность зависит только от производительности процессора. Увеличивая число пользователей, мы линейно увеличиваем нагрузку на систему. При этом сложные операции типа отчетов делаются при минимальной загрузке системы. Пример такой системы сайзинга — использование SAPS компании SAP.
Третий вариант — сайзинг на основе теста системы. Здесь гораздо меньше упрощений. Основное допущение — считается, что нагрузка на систему каждого модуля независима. И четвертый способ, самый сложный в исполнении, но самый близкий к реальности, — пилотный проект. Создается пилотная система с реальной нагрузкой, только вместо трехсот человек берут тридцать, получают профили их работы, а потом на основании этих профилей оценивают производительность.
При этом я хочу отметить интересный момент: на самом деле сложнее не значит лучше. Как ни странно, иногда сайзинг, основанный на числе пользователей, дает лучшие результаты, чем все остальные. Это связано с тем, что чем сложнее методика сайзинга, тем легче в ней сделать ошибку. Иначе говоря, у нас есть спектр возможностей: на левом фланге — тесты процессорной мощности, на правом — пилотные проекты. Это дает широкие возможности для сайзинга, но необходимо хорошо понимать достоинства и недостатки каждого метода.
Сергей Бугрин
Важную роль в сайзинге играют центры компетенции. Скажем, у SAP есть такой центр в Альдорфе, там представлены практически все производители серверов и делается сайзинг. Это либо третий, либо четвертый тип сайзинга. Да, методы, в которых используются универсальные тесты, прикладные тесты, имитация количества пользователей, достаточно интересны. Но далеко не все здесь однозначно. Одни компании соглашаются с этими оценками, другие не соглашаются. У каждого есть своя причина, и она вполне оправданна.
Михаил Елашкин
Сегодня сайзинг доступен всем клиентам крупных компаний. Можно использовать результаты универсальных тестов, таких, как TPC, но чтобы понять, как этим воспользоваться, нужна соответствующая квалификация. Там есть много тонкостей, которые нужно знать. Для больших систем выбор однозначен — прикладные тесты SAP и аналогичные им. Эти тесты значительно более информативны, так как они в условиях реальной работы приложения нагружают все компоненты системы.
Кроме того, свои программы сайзинга имеют многие производители серверов. У Hewlett-Packard, например, есть целый сайт, который она унаследовала от Compaq, там представлено больше двадцати типов приложений, для которых можно сделать сайзинг. Причем результаты весьма впечатляют. У меня есть данные об экспериментальной проверке сайзинга Hewlett-Packard (изменяли объем памяти, число процессоров и т. п. и измеряли производительность). И вывод оказался весьма интересным — самые простые сайзеры давали очень хороший результат. Он был несколько завышен, примерно на 30%, но такой запас, я думаю, объясняется тем, что компания просто страхуется.
Дмитрий Захаров
Если компания, имеющая хорошую репутацию на рынке, предлагает сайзинг, то, на мой взгляд, этим предложением можно и нужно пользоваться. Потому что эта компания отвечает за то, что она предлагает, иначе она не была бы одним из лидеров рынка. И, наверное, в подавляющем большинстве случаев это адекватный инструмент. Кончено, он дает немного завышенную оценку, потому что в том и есть смысл всякого сайзинга — прежде всего ни в коем случае не ошибиться в нижнюю сторону, но и не слишком сильно ошибиться в верхнюю. Нужно пользоваться такими ресурсами: в некотором смысле это бесплатный или почти бесплатный консалтинг. По крайней мере тут можно получить консалтинг по минимальной цене.
Но почему, если есть такое количество полезных инструментов, остаются проблемы с выбором сервера?
Ренат Юсупов
Дело в том, что при сайзинге есть определенная доля лукавства. На самом деле сайзинг рассчитывается под фиксированную конфигурацию, с фиксированным количеством машин, фиксированной пропускной способностью сети. Но никакая ИТ-инфраструктура не может быть фиксированной, она постоянно меняется, ухудшается или улучшается. Поэтому HP делает запас 30%, многие другие — 50%. Делая выбор на основе сайзинга, это надо понимать. У больших серверных компаний, у которых есть опыт продаж, сайзинг делается в головах технических экспертов. И зачастую он дает более точные оценки.
Александр Кузин
Сайзеры — это универсальные, но не точные инструменты. Для конкретного программно-аппаратного воплощения системы, с десятками настроечных параметров, индивидуальных постоянных и переменных нагрузок, гораздо важнее практический опыт менеджеров проектов и инженеров компании — системного интегратора. Потребителю дешевле будет обратиться в компанию, имеющую опыт похожих внедрений, чем решать проблему самостоятельно.
Дмитрий Захаров
Мне кажется, есть различные потребности в сайзинге. Те центры компетенции, о которых мы говорим, нацелены на «тяжелые» решения, где велика цена ошибки, и позволяют адекватно представить себе, что будет. Но на самом деле подавляющее большинство задач стандартны и обкатаны. У любого ИТ-эксперта в голове есть представление о том, каким должен быть сайзинг в этих случаях. Много ли на рынке проблем с сайзингом “1C”? Подозреваю, что немного, потому что задача стандартная и сайзинг достаточно очевиден. Автоматические стандартные сайзинги дают адекватное представление в большинстве не очень сложных случаев.
Сергей Бугрин
Да, крупные компании применяют сайзинг, скажем, основанный на SAPS. Однако очень малое число российских компаний работают с центрами компетенции. Проблема — отсутствие культуры. Кроме того, если задача немного усложняется, то SAPS уже не играют большой роли, увеличивается количество параметров и возникают ошибки. Тогда результаты теста отправляют экспертам. И эксперты тоже страхуются. А страховка мгновенно увеличивает стоимость сервера. Несмотря на наличие сайзеров и экспертов, задача на самом деле очень нетривиальная. Понимая, что нужно дать какие-то определенные гарантии, поставщики серверов начинают делать дополнительные шаги. «Давайте остановимся на такой-то конфигурации, мы считаем, что наш сервер будет работать с такой-то производительностью, а если не будет, то мы вам бесплатно добавим энное количество процессоров».
Михаил Елашкин
Увы, сайзинг — вещь дорогая. Дело в том, что это очень квалифицированная работа. Анализ производительности тяжелых систем уровня предприятия в России могут сделать единицы. Но в принципе я считаю, что развитие пойдет в эту сторону. Сейчас у “1C” нет сайзинга, но думаю, что будет, не сегодня, так завтра, в том или ином виде.
Алексей Устинов
У покупателя есть довольно широкий набор средств для оценки производительности сервера. На одном полюсе этого спектра — простые синтетические тесты производительности процессоров или отдельных аппаратных подсистем сервера. Далее следуют тесты производительности (benchmarks) отдельных приложений, такие, как WebBench или MMBP. Но такие тесты не дают реальной картины, поскольку измеряют производительность приложения изолированно, без учета нагрузки от других приложений, запущенных на том же сервере. Результаты будут более точными, если попытаться смоделировать тот набор приложений, который используется в реальной жизни. Однако и этого недостаточно, поскольку такой подход не учитывает характеристик реальной сети, где нагрузка, скажем, меняется во времени. Поэтому только реальная нагрузка, с реальными задачами, в реальной сети покажет реальную производительность. Как говаривал классик: «Практика — критерий истины».
В нашей стране мы неоднократно наблюдали более дешевый вариант сайзинга. Многие российские сборщики идут на то, чтобы предоставить заказчикам оборудование на бесплатное тестирование. Компания берет систему, на которую ставит все свое прикладное ПО и пытается воспроизвести рабочую нагрузку. Бывают случаи, когда администратор ночью переключает приложение с одного сервера на другой и никто не подозревает об этом. Да, риск есть, но я считаю, что это правильно, это высший класс сайзинга. Хотя, если есть возможность, лучше провести пилотный проект. Лучше всего — проверка в реальной ситуации.
В первую очередь имеется в виду возможность финансовая. А как определить, тратить ли средства на экспертизу, или цена ошибки будет меньше этих средств? С какого уровня решений сайзинг полезен? Какова цена ошибки? Может быть, игра не стоит свеч? Кроме того, как поступить тем, у кого заведомо нет средств на экспертизу? Ведь в этом случае отказ от оптимизации приведет к тому, что самым правильным будет ответ — чем дороже, тем лучше.
Ренат Юсупов
Каждый заказчик должен сам оценивать цену своей ошибки. Если задачи критичны для компании и цена бизнеса гораздо выше стоимости этой инфраструктуры, то однозначно нужно вкладываться в более глубокую экспертизу. Если не хватает финансов на проведение сайзинга — рискуйте, используйте здравый смысл и любые доступные источники бесплатной информации. Зачастую можно почти не глядя выбрать сервер в два раза мощнее, цена ошибки будет не очень высока, а сервер довольно дешев. У производителя есть свое видение, как будет работать его сервер, и он предлагает это видение зачастую бесплатно. Так, сайзинг для нас — это совершенно условное понятие, поскольку мы пока ограничены количеством процессоров. По моему мнению, сайзинг необходим, если система стоит от 100 тыс. долл. Это системы с восемью и более процессорами.
И не всегда ИТ-менеджеру выгоднее купить подороже. ИТ-менеджер — дипломат. С одной стороны, на него давит задача, которую он решает, с другой — есть финансовое давление со стороны компании. Он все эти факты суммирует и выбирает оптимальное решение. Если ИТ-менеджер дал неправильные рекомендации, это определяет срок его жизни в компании. Его ответственность на самом деле очень высока. Если ИТ-менеджер вовлечен в бизнес-процессы компании и понимает финансовую сторону вопроса, то тогда, я думаю, решения будут более или менее взвешенными.
Михаил Елашкин
Сайзинг, пилотный проект — все это позволяет ИТ-менеджеру сделать выбор и дальше его защищать. Но финансовому директору не нужно рассказывать про сайзинг. Разговор идет на финансовом языке — «мы должны внести такие-то деньги, которые позволят нам автоматизировать процесс, свести к минимуму время простоя». Поэтому вся эта информация нужна ИТ-менеджеру для того, чтобы он сам принял решение. Вся ответственность лежит на нем.
Я думаю, что чем меньше размер сделки, тем выше роль брэнда. Чем меньше размер сделки, тем меньше нужно тратить на принятие решения. Действительно, бессмысленно при цене сервера в 2000 долл. тратить 200 тыс. на его выбор. А для совсем небольших систем (до четырех процессоров) самый дешевый способ — это выбрать брэнд.
Алексей Устинов
Если недостаточно финансовых ресурсов для проведения экспертизы, есть опыт других. Можно использовать решения, проверенные в компании такого же размера в той же индустрии, например, взять такой же банк, с тем же количеством сотрудников. Здесь помогает информация об опыте успешных инсталляций техники, которые поставщики серверов публикуют в виде «историй внедрения». Это особенно важно для тех компаний, которые не могут себе позволить пилотный проект. Нельзя сказать, что ИТ-менеджеры на 100% доверяют опыту поставщиков серверов. Однако в условиях ограниченного бюджета логично собрать всю имеющуюся информацию.
Ренат Юсупов
Есть еще один вариант — не вкладываться в экспертизу, а просто послать пару инженеров на курсы, например, в Oracle. Это намного дешевле, и это реальная экспертиза, обладая которой они потом будут делать гораздо более разумный выбор. То есть мой совет — вкладываться в свой персонал.
А помощь независимого консультанта? Мы привыкли, что консультанты привлекаются, когда внедряется ERP-система. Но когда мы говорим об инфраструктуре, этот вопрос как-то обходят стороной…
Михаил Елашкин
Не нужно думать, что ИТ-менеджер совсем одинок. Я участвовал в проекте, где одна крупная нефтяная компания для написания тендерной документации привлекла аутсорсинговую компанию. Другой внешней компании был поручен аудит тендера. Если не хватает собственной компетенции и в этом не стыдно признаться, всегда можно привлечь экспертов. Но даже когда тендер проводит маленькая компания из десяти человек, в тендерную комиссию можно пригласить преподавателя университета, какого-то известного в городе ИТ-специалиста и т. д. Это вполне по средствам и небольшим региональным компаниям. К сожалению, консультант в России чаще всего зарабатывает продажей техники, ПО, услуг. Как-то не принято у нас платить только за советы. В классическом, западном понимании консультант ничего не продает, а только дает советы за деньги.
Дмитрий Захаров
Нужно иметь в виду, что путь с использованием консультанта тоже не лишен подводных камней, у консультанта тоже свои интересы. Ему интересно, чтобы вы взяли систему подороже, потому что она страхует его от «ошибки вниз» и повышает значимость его работы. «Ошибка вниз» для него смертельна. «Ошибку вверх» скорее всего не заметят.
Алексей Устинов
Именно поэтому очень часто в роли консультанта выступает тот поставщик, с которым компания работает не один год. Практика убедила — да, ему можно доверять. Понятно, что и поставщику будет невыгодно что-то «впарить». Очень часто ИТ-менеджер работает вместе с консультантом компании-поставщика, и я считаю, что это неплохой симбиоз, если оба заинтересованы в том, чтобы проект прошел успешно.
Выбор оптимального сервера — это искусствоВладимир Шибанов, генеральный директор компании "Аквариус" При выборе сервера нужно прежде всего исходить из особенностей задач, которые планируется на нем решать. Сначала нужно определить потребности программ и операционной системы, которые будут исполняться на сервере. Важно предусмотреть в конфигурации запас аппаратных ресурсов для будущего роста нагрузки на сервер. Нахождение баланса между стоимостью, производительностью сервера и возможностями его расширения — это искусство, обучение которому стоит денег и немалого времени. Общие рецепты дать трудно. Есть два эмпирических правила: "не существует дискового пространства такого объема, который невозможно загадить за пару месяцев" и "оперативной памяти сервера не хватает всегда". Серверы, в отличие от ПК и рабочих станций, не могут эффективно функционировать вне сети, а их загруженность в решающей мере определяется конфигурацией сети, требованиями клиентских приложений и прочими внешними факторами. Поэтому подбирать оптимальную конфигурацию сервера должен поставщик решения или, при отказе от услуг внешних интеграторов, штатные инженеры ИТ-отдела, ведь именно этим специалистам лучше всего известна инфраструктура сети заказчика. Сайзеры и специализированные тесты помогают в решении этой задачи, но с оговорками: каждая задача, как правило, уникальна, особенно при "зоопарке" унаследованных решений на нашем корпоративном рынке. Что касается «тяжелых» серверов, то это понятие весьма расплывчатое. Для кого-то даже кластеры из четырехпроцессорных серверов оказываются слишком «легким» решением, а кто-то и двухпроцессорные системы на Xeon считает для себя неподъемными. Так что система весов определяется скорее субъективно, чем подсчетами популяции процессоров, километров памяти и тонн дискового пространства. В общем случае можно сказать, что покупка сервера любой степени тяжести оправданна, если он постоянно готов без задержек и простоев обслуживать такие задачи клиентов, с которыми более слабые решения не справляются. |
Как правило, задача выбора инфраструктуры под систему автоматизации предприятия выделяется как отдельная задача или проект. В этом случае, возможно, его стоит оценить как инвестиционный проект с точки зрения ROI? Или хотя бы в рамках проекта можно попытаться оценить стоимость владения сервером на протяжении срока его службы.
Михаил Елашкин
Если разговаривать в финансовых терминах, то серверы обычно не выделяются в отдельный проект и его ROI не считается. Но TCO и ROI — не единственный способ оценки эффективности проекта. Эту ситуацию можно рассматривать в системе сбалансированных показателей. Это довольно популярная сегодня методика. Есть довольно простые методики сравнения ROI двух вариантов в случае какой-то альтернативы, без вычисления численных значений, просто на уровне больше — меньше. Существует много интересных методик, но даже на Западе они еще очень мало распространены. Да, они приблизительные, проблема-то сложная. Но ее можно и нужно начинать решать уже сегодня.
И тем не менее, как посчитать TCO сервера на протяжении срока службы? И каков вообще срок службы сервера?
Ренат Юсупов
В общем случае стоимость владения сервером состоит из нескольких составляющих: закупочная стоимость, стоимость модернизации и стоимость сервиса. Опыт серверной компании, которая больше восьми лет живет на рынке, показывает следующее: апгрейд — это практически нереальная операция в процессе жизни сервера. Она осуществима, но за совершенно безумные деньги, и эффективность ее несоизмерима с затратами. Простой пример: через три года работы сервера вы пытаетесь модернизировать процессор в многопроцессорном сервере. Найти такой процессор практически невозможно. Точнее, найти можно, но только у крупных брэндов, которые действительно держат запасы, и стоимость его будет высока. Иногда дешевле просто найти новый сервер. Технологии меняются с огромной скоростью. Например, практически раз в год или полтора года сменяется поколение жестких дисков. А сервер — это долгоживущий продукт, в идеале его нужно включить и забыть о нем.
Поэтому я бы вынес за скобки апгрейд и оставил только две основные части. Первая — это как раз первоначальные вложения, где нужно оптимально просчитать конфигурацию, потому что сервер должен после покупки еще три-четыре года эксплуатироваться. Я считаю, что стоит вложиться вначале, потому что это дешевле с точки зрения ТСО. Причем обслуживание избыточного сервера тоже будет существенно дешевле. Разумно на этапе проектирования и закупки своего сервера закладывать некую избыточную надежность, резервирование систем и т. д., хотя это потребует дополнительных затрат. Есть стандартные технологии, которые обеспечивают минимальный уровень надежности, — RAID-массивы, резервирование блоков питания, удаленное управление, кластеры, и в 90% случаев, я считаю, этого вполне достаточно.
Практика показывает, что уже три года назад качество разработок и производственные технологии достигли такого уровня надежности, что время работы на отказ каждого компонента стало достаточно высоким. Движущихся частей (вентиляторы, жесткие диски) становится все меньше, а технологии — все лучше. И физический срок жизни сервера удлиняется. Даже не очень желая того, производители вынуждены это делать, потому что технологии развиваются, от них никуда не денешься. Мое мнение — львиную долю стоимости владения сервером нужно закладывать именно на этапе покупки.
Что касается времени жизни, то технологии уходят, и эти изменения не согласованы. PCI-карты исчезнут с рынка, и примерно через три года обычную PCI-карту купить будет практически невозможно. Слишком это будет дорого. Срок жизни каждой ключевой технологии — в среднем лет десять. И таких технологий и стандартов в аппаратном обеспечении семь-восемь. В среднем получается три года. Но три года жизни сервера — это только начало. Потом серверы перемещают на более простые задачи, и в целом они живут примерно 5—7 лет. Обычно раз в три года меняется ядро серверной инфраструктуры. Сервер передается под менее значимые приложения, а на более значимые покупается более современный.
Сергей Бугрин
Для RISC-серверов время жизни немного подольше. Наверное, можно назвать пять лет — до тех пор, пока существует апгрейд от одной модели на другую, а он существует достаточно долго. С точки зрения апгрейда срок жизни — около пяти лет. И при этом более 18 лет работы сервера — это совершенно нормально. Проблема в том, что технологии сейчас развиваются чрезвычайно быстро, и чтобы оставаться на гребне, техническое перевооружение приходится проводить очень часто. Еще два-три года назад IBM не продавала серверы с избыточным количеством процессоров, которые можно было включить и активизировать микрокодом. Эта технология направлена на увеличение производительности системы. То же самое и с оперативной памятью. Но реально все это на срок жизни не влияет.
Алексей Устинов
Согласен, в малом и среднем бизнесе техника не выбрасывается. Самое новое появляется в рекламном отделе, старое передвигается в бухгалтерию, на склад. Срок жизни техники довольно велик, а у сервера — тем более. Если задача не меняется, не меняются и требования к серверу. И в России много таких примеров, когда сервер, поставленный десять лет назад, успешно справляется со своими задачами.
Но классический взгляд состоит в том, что стоимость обслуживания сервера должна существенно возрастать через три-пять лет.
Сергей Бугрин
Это не всегда так. У серверов бывает нетипичное применение. Например, стоит AS/400 в гостинице, и больше там не нужно. Количество номеров не увеличивается, количество приложений то же. И сервер работает уже больше двадцати лет.
Михаил Елашкин
Как ни странно, но часто замена серверов не оправдана экономическими или техническими причинами. Зачастую старые серверы более эффективны, чем новые. Я могу назвать целый ряд примеров. Считается хорошим тоном «пнуть» мэйнфреймы, а ведь с точки зрения надежности и эффективности (не как «числодробилка», а как система массового обслуживания) они до сих пор исключительно хороши. Некоторые из DEC’овских машин до сих пор лучшие в своем классе. Есть задачи, где практически невозможно найти замену OpenVMS. Согласно западным исследованиям, до 60% времени, денег и ресурсов отделы ИТ тратят на обслуживание унаследованных систем. Но при этом мало кто учитывает, какую долю работы они выполняют. Так что если считать ROI, то неплохо бы посчитать сначала отдачу от уже существующих систем.
Ренат Юсупов
Тем не менее я считаю, что ядро информационной системы, в котором исполняются ключевые приложения в виде сервера транзакций, СУБД или учетной системы, должно быть всегда современным и обновляться в среднем не реже, чем раз в три года. Не реже.
Интуитивная задача, базирующаяся на компетенции компанииВрам Александрян, первый заместитель генерального директора группы компаний "Борлас".При построении любой автоматизированной системы управления, естественно, требуется серверная платформа. Выбор конкретного сервера, как правило, задача многовариантная. Даже тогда, когда выбрана фирма-производитель, можно столкнуться с необходимостью выбора между различными классами серверов, имеющими при приблизительно равной производительности отнюдь не равную цену. Выбор не всегда определяется только требованиями к производительности, не всегда оправданны и повышенные требования к масштабируемости и надежности платформы. Оптимальный выбор, на мой взгляд, возможен лишь в том случае, если ясны не только сиюминутные конкретные задачи, но виден и путь развития системы, хотя бы на ближайшие два-три года. Готовых рецептов нахождения баланса между стоимостью, производительностью сервера и возможностями его расширения, к сожалению, не существует. На мой взгляд, это интуитивная задача, которая базируется на компетенции компании, ее опыте и знании рынка. Здесь необходимо учитывать очень много факторов — не только возможности расширения сегодняшнего семейства серверов на предприятии, но и динамику всего компьютерного рынка с учетом появления новых поколений аппаратных решений и новых технологий. Думаю, оптимальный вариант таков: сервер должен иметь производительность, обеспечивающую комфортную работу системы с возможностью ее масштабируемости на ближайшие два-три года, а также ту степень надежности и отказоустойчивости, которая диктуется поставленными перед системой задачами. Если эти задачи в высокой степени критичны, необходима высокая отказоустойчивость сервера, что ведет, естественно, к его удорожанию. «Тяжелые» серверы оправданны в тех случаях, когда речь идет о критических решениях и отказоустойчивость и надежность этих решений ставится во главу угла. Проводить сайзинг сервера должен поставщик решения, который в конечном счете и отвечает за работоспособность системы, а не производитель ПО или сервера. Ведь ясно, что целевые установки у производителя и у заказчика разные. Обращаться к открытым сайзерам и специализированным тестам можно, но подходить к ним надо достаточно осторожно, исключительно ради предварительных прикидок. |
