Утилизация ресурсов сервера что это
Анализ утилизации СХД
Как понять, что СХД плохо? Как определить что запас производительности исчерпан? Какие параметры об этом свидетельствуют? В этой статье речь пойдет об анализе утилизации СХД, а также выявлении и прогнозировании проблем связанных с производительностью. Материал может быть не интересен опытным storage администраторам, поскольку будут рассмотрены только общие моменты, без углубления в логику работы хитрых механизмов оптимизации производительности.
Для начала определимся с терминологией. Есть несколько терминов и аббревиатур близких по смыслу: СХД, дисковый массив, SAN, Storage Array или просто Storage. Попробую внести ясность.
SAN — Storage Area Network или сеть хранения данных, это совокупность оборудования осуществляющая передачу трафика между сервером и системой хранения данных.
СХД — система хранения данных или дисковый массив, оборудование на котором хранятся данные с возможностью оперативного доступа. Есть еще архивные хранилища, но здесь мы их рассматривать не будем. Аббревиатура СХД так же может употребляться как сокращение от сеть хранения данных, но среди русскоговорящих специалистов термин СХД закрепился именно за системой хранения данных.
СХД могут обеспечивать два способа доступа к данным:
Для оценки производительности СХД используют три основные метрики
Рассмотрим наиболее типичные проявления проблем производительности СХД по показателям Service Time, IO/s и MB/s.
Повышенный Service Time
Для каждого СХД есть крайнее значение Service Time которое соответствует максимальной производительности, другими словами, незначительное увеличение нагрузки приведет к существенному повышению Service Time, вызвав тем самым деградацию требовательных к задержкам приложений.
Для примера, ниже графики зависимости Service Time от IOPS для двух конфигураций СХД.
ST для All flash СХД, 2 Node, 24×1.9 TB SSD, RAID 5, Random 32k, 50/50 Read/Write.
ST для классического СХД, 2 Node, 24×1.8 TB HDD, RAID 5, Random 32k, 50/50 Read/Write.
В общих случаях для All Flash СХД приемлемым считается Service time меньше 1ms, а для классических СХД до 20ms. Порог приемлемого Service time зависит от числа контроллеров, скорости дисков и конечно модели самой СХД, и может отличаться от приведенных значений.
Также нужно учитывать до какого уровня задержек дисковой подсистемы сохраняется нормальная работоспособность приложения, и всегда иметь необходимый запас.
Планка по MB/s
Чаще всего свидетельствует об исчерпании пропускной способности канала или FC адаптера.
Конкурирующие значения по MB/s или IO/s
Сумма (оранжевый график) двух или более параметров на отрезке времени имеет константу и не превышает ее в какой-либо момент. Такая ситуация может наблюдаться в случае конкуренции за пропускную способность канала или порта СХД.
Понижение IO при возрастании ST
В случае если процентное распределение размеров блока не изменилось, но при этом ST начинает повышаться, а IO падать, это может свидетельствовать об аппаратных проблемах с СХД, деградации одного из контроллеров или высокой утилизации CPU.
Утилизация CPU
Утилизация CPU контроллеров СХД в общих случаях не должна превышать 70%, если она постоянно выше 70%, то это свидетельствует об отсутствии запаса производительности СХД.
Тут нужно отметить, что СХД можно разделить на две большие группы:
Медленный рост IO на чтение
Такая проблема может наблюдаться в случае если СХД использует тиринг размещения данных между носителями разной скорости (например, SSD и NL SATA).
К примеру: некая БД работает с высокой нагрузкой один день в неделю, а остальное время простаивает, в таком случае данные к которым давно не было обращений перейдут на носители с малой скоростью, и скорость чтения будет постепенно расти при переходе (так называемом прогреве данных) на быстрые носители.
Какой характер нагрузки не свидетельствует о проблемах?
Пилообразный график IO
Прыгающие значения IO
Все перечисленные примеры нагрузки не свидетельствуют о каких-либо проблемах на стороне СХД. Нагрузка создается хостом подключенным к СХД и зависит от логики процессов использующих дисковое пространство.
Как определить трешхолды для Service Time, IO/s и MB/s?
Данные параметры можно рассчитать теоретически, складывая производительность дисков и считая пенальти выбранного уровня RAID, также можно воспользоваться сайзерами при наличие оных, но расчет будет очень приблизительным, поскольку не будет учитываться реальный профиль нагрузки. Для определения точных пороговых значений, свидетельствующих например о 90% загрузке СХД, необходимо провести нагрузочное тестирование при помощи специального ПО, сформировав профиль нагрузки близкий к реальному и замерить максимальные значения IO/s и MB/s. Но как быть с Service Time? Тут зависимость нелинейная. Для определения Service Time соответствующего 90% загрузке нужно просто сгенерировать 90% от максимально достигнутого значения по IO. Полученные результаты можно экстраполировать на близкие по конфигурации СХД.
Видеоэкскурсия в ЦОД: Стратегия создания дата-центров
Компания Intel прошла долгий путь, прежде чем выработать стратегию в области центров обработки данных. Исторически было так, что в тех местах, где компания покупала или строила здания, размещались и дата-центры для нужд находящихся там подразделений разработчиков. Опыт показал, что это не очень эффективно. При таком подходе количество дата-центров Intel превысило 150 и, соответственно, они стали очень дорогой частью ресурсов корпорации. Поэтому был принят ряд решений, направленных на уменьшение общей стоимости владения дата-центрами. Рассмотрим подробнее ряд методик, благодаря которым и была сформирована общая стратегия для центров обработки данных компании Intel.
1. Своевременная проактивная замена серверного парка
В компании действует четырехгодичный цикл обновления серверов. Эта методика доказала свою эффективность. В зависимости от поколений процессоров соотношения числа новых и заменяемых серверов изменяется, бывает, например 1 к 10 или 1 к 15. В результате обновления, с одной стороны, достигается серьезная экономия электричества, поскольку новые системы энергоэффективнее, с другой стороны, увеличивается производительность.
2. Виртуализация ресурсов
Особенно это касается той части оборудования, которая обеспечивает офисную деятельность. Простой пример — имеются Web-сервер, почтовый сервер, DNS-сервер. Каждый из них загружает ресурсы выделенного физического сервера, скажем, на 10%. Это неэффективно, конечно, и если их посредством виртуализации разместить на одном компьютере, получится дешевле и проще в обслуживании. Виртуализация является первым серьезным шагом на пути к ГРИД-вычислениям и в итоге к внедрению облачных вычислений. Intel очень активно сейчас занимается строительством своих собственных внутренних облаков.
3. Консолидация серверов
За последние 5 лет количество дата-центров было значительно сокращено: со 150 до 93. Кроме этого, компания стремится и к сокращению количества серверных комнат. Понятно, что несколько маленьких серверных комнат с загрузкой порядка 40% в обслуживании обходятся дороже, чем одна большая комната с загрузкой 60-70%. Этот этап проходил в Intel несколько лет назад, была реализована большая программа мероприятий направленных на консолидацию, оказавшаяся очень успешной, что позволило сделать содержание дата-центров менее затратным.
4. Увеличение утилизации серверов
То есть повышение степени загрузки оборудования. В первую очередь здесь обращается внимание на ряд моментов. Так, весь серверный парк компании разделен на 4 части по направлениям использования — Design, Office, Manufacturing, Enterprise (сокращенно DOME). Сегмент Manufacturing в этом процессе практически не задействован, поскольку обеспечивает поддержку работы фабрик. Что касается остальных классов серверов, то как правило Office и Enterprise объединяют вместе, потому что по задачам и оборудованию они очень похожи, и отдельно существует Design-ресурсы, т.е. поддержка конструирования и разработок.
Повышение утилизации самих серверов достигается в первую очередь за счет внедрения виртуализации. В Intel есть две основные программы по виртуализации — DCU (виртуализация дизайнерского ПО, больших серверных пулов) и DCV (виртуализация в сегментах Office и Enterprise). Наибольший интерес для других компаний, видимо, представляет опыт компании Intel в виртуализации по программе DCV. Здесь речь идет об обычной практике, когда на одну физическую машину ставится от 4 до 8 виртуальных машин, и утилизация ее ресурсов повышается. Растет эффективность использования таких серверов, быстрее отрабатываются затраченные средства.
5. Применение эффективных средств охлаждения и энергосбережения
При строительстве новых комнат и ЦОД’ов, как и при модернизации существующих, огромное значение приобретает энергоэффективность новых технологий. Например, Intel придерживается в своих дата-центрах воздушного охлаждения и существует ряд методик, чтобы снизить операционные затраты при таком подходе. Об этом мы говорили в четырех предыдущих статьях, напомним — это внедрение стоек с вытяжкой, свободное охлаждение (free cooling), система рекуперации тепла… Даже такие элементарные вещи, как использование заглушек в стойках, снижает нагрузку на системы охлаждения и уменьшает затраты на электроэнергию.
Данная стратегия — это не заранее четко сформулированная программа действий, а просто опыт компании Intel, результат проб и ошибок, накопленный на протяжении многих лет. Если в самом начале глобальной целью являлось максимальное сокращение количества дата-центров, чуть ли не до 18-20 штук, то с течением времени стало понятно, что это невозможно физически и все равно какой-то объем оборудования должен находиться в удаленных местах, а не только на больших хабах. Потому что и WAN-каналы на сегодняшний момент не позволяют консолидировать все в такой высокой степени, и еще масса вещей препятствует или делает нецелесообразной такую концентрацию серверных ресурсов. Поэтому было решено вместо столь глобальной консолидации перейти к повышению утилизации дата-центров. Ведь главная цель — минимизировать капитальные вложений в ЦОД’ы, то есть не строить новые, а эффективно использовать уже имеющиеся. Строительство нового ЦОД’а — это колоссальные деньги, миллионы и миллионы долларов в зависимости от его размера. И вот тут появился ряд методик, как добиться наилучшего использования существующих ресурсов, включая цикл обновления серверов, виртуализацию, облака и т.д., который и сложился в имеющуюся на сегодняшний день стратегию для дата-центров компании Intel.
Задать вопрос Леониду Шишлову можно в сообществе профессионалов Intel.
Анализ ключевых показателей производительности — часть 3, последняя, про системные и сервисные метрики
Мы заканчиваем публикацию перевода по тестированию и анализу производительности от команды Patterns&Practices о том, с чем нужно есть ключевые показатели производительности. За перевод спасибо Игорю Щегловитову из Лаборатории Касперского. Остальные наши статьи по теме тестирования можно найти по тегу mstesting
В первой статье цикла по анализу ключевых показателей производительности мы наладили контекст, теперь переходим к конкретным вещам. Во второй посмотрели на анализ пользовательских, бизнесовых показателей/метрик и показателей, необходимых к анализу внутри приложения. В этой, заключительной — про системные и сервисные (в т.ч. зависимых сервисов) метрики.
Итак,
Системные метрики.
Системные метрики позволяют определять, какие системные ресурсы используются и где могут возникать конфликты ресурсов. Эти метрики направлена на отслеживание ресурсов уровня машины, таких как память, сеть, процессор и утилизация диска. Эти метрики могут дать представление о внутренних конфликтах лежащих в основе компьютера.
Вы также можете отслеживать данные метрики для определения аспектов производительности – нужно понимать, если ли зависимость между системными показателями и нагрузкой на приложение. Возможно, вам потребуются дополнительные аппаратные ресурсы (виртуальные или реальные). Если при постоянной нагрузке происходит увеличение значений данных метрик, то это может быть обусловлено внешними факторами — фоновыми задачами, регулярно-выполняющимися заданиями, сетевой активностью или I/O устройства.
Как собирать
Вы можете использовать Azure Diagnostics для сбора данных диагностики для для отладки и устранения неполадок, измерения производительности, мониторинга использования ресурсов, анализа трафика, планирования необходимых ресурсов и аудита. После сбора диагностики ее можно перенести в Microsoft Azure Storage для дальнейшей обработки.
Другой способ для сбора и анализа диагностических данных — это использование PerfView. Этот инструмент позволяет исследовать следующие аспекты:
Изначально PerfView был предназначен для локального запуска, но теперь он может быть использован для сбора данных из Web и Worker ролей облачных сервисов Azure. Вы можете использовать NuGet-пакет AzureRemotePerfView для установки и запуска PerfView удаленно на серверах ролей, после чего скачать и проанализировать полученные данные локально.
Windows Azure Diagnostics и PerfView полезны для анализа используемых ресурсов “постфактум”. Однако, при применении таких практик как DevOps, необходимо мониторить “живые” данные производительности для обнаружения возможных проблем производительности еще до того, как они произойдут. APM-инструменты могут предоставлять такую информацию. Например, утилиты Troubleshooting tools для веб-приложений на портале Azure могут отображать различные графики, показывающие память, процессор и утилизацию сети.
На портале Azure есть “health dashboard”, показывающий общие системные метрики.
Аналогичным образом, панель Diagnostic позволяет отслеживать заранее настроенный набор наиболее часто используемых счетчиков производительности. Здесь вы можете определить специальные правила, при выполнении которых оператор будет получать специальные нотификации, например, когда значение счетчика сильно превысит определенное значение.
Веб-портал Azure может отображать данные о производительности в течении 7 дней. Если вам нужен доступ данных за более длительный период, то данные о производительности нужно выгружать напрямую в Azure Storage.
Websites Process Explorer позволяет вам просматривать детали отдельных процессов запущенных на веб-сайте, а также отслеживать корреляции между использованием различных системных ресурсов.
New Relic и многие другие APM имеют схожие функции. Ниже приведено несколько примеров.
Мониторинг системных ресурсов делится на категории, которые охватывают утилизацию памяти (физической и управляемой), пропускную способность сети, работу процессора и операции дискового ввода вывода (I/O). В следующих разделах описано, на что следует обратить внимание.
Использование физической памяти
Существует две основные причины ошибки OutOfMemory – процесс превышает выделенное для него пространство виртуальной памяти либо операционная система оказывается неспособной выделить дополнительную физическую память для процесса. Второй случай является самым распространенным.
Вы можете использовать описанные ниже счетчики производительности для оценки нагрузки на память:
Также следует учитывать, что большие объемы памяти могут привести к фрагментации (когда свободной физической памяти в соседних блоках недостаточно), поэтому система, которая показывает, что имеет достаточно свободной памяти, может оказаться не в состоянии выделить эту память для конкретного процесса.
Многие APM-инструменты предоставляют сведения об использовании процессами системной памяти без необходимости глубокого понимания о принципах работы памяти. На графике ниже показана пропускная способность (левая ось) и время отклика (правая ось) для приложения, находящегося под постоянной нагрузкой. Примерно после 6 минут производительность внезапно падает, и время отклика начинает “прыгать”, по прошествии нескольких минут происходит показателей.
Результаты нагрузочного тестирования приложения
Записанная с помощью New Relic телеметрия показывает избыточное выделение памяти, которое вызывает сбой операций с последующим восстановлением. Использованная память растет за счет файла подкачки. Такое поведение является классическим симптомом утечки памяти.
Телеметрия, показывающая избыточное выделение памяти
Примечание: В статье Investigating Memory Leaks in Azure Web Sites with Visual Studio 2013 содержится инструкция, показывающая как использовать Visual Studio и Azure Diagnostics для мониторинга использования памяти в веб-приложении в Azure.
Использование управляемой памяти
.NET приложения используют управляемую память, которая контролируется CLR (Common Language Runtime). Среда CLR проецирует управляемую память на физическую. Приложения запрашивают у CLR управляемую память, и CLR отвечает за выделение требуемой и освобождение неиспользуемой памяти. Перемещая структуры данных по блокам, CLR обеспечивает компоновку этого типа памяти, уменьшая тем самым фрагментацию.
Управляемые приложения имеют дополнительный набор счетчиков производительности. В статье Investigating Memory Issues содержится детальное описание ключевых счетчиков. Ниже описаны наиболее важные счетчики производительности:
Отечественный производитель серверов = самосбор?
С давних пор ведётся «холивар» на тему как называть российские компании, которые занимаются сборкой компьютерного и серверного оборудования — производителями или «самосборщиками»? Одни считают, что если сервер или ПК собран на конвейерном или стапельном производстве, прошёл тестирование и имеет гарантию на готовое изделие, а не на отдельные компоненты от производителя комплектующих — то такую компанию можно смело называть производителем. Другие, напротив, считают производителями только те компании, которые паяют платы, а все остальные — просто самосбор.
Если углубиться в вопрос и рассмотреть примеры мировых брендов, то эта грань окажется не такой явной, как кажется на первый взгляд. Мало кто из мировых производителей серверного оборудования самостоятельно выполняет полный цикл производства. В основном, это ограничивается разработкой дизайна и/или использованием ресурсов ODM-производителей — Foxconn, Quanta, Mitac, Chenbro, Supermicro и прочих.
На данный момент прочно закрепились олигополии практически во всех сферах производства компьютерных и серверных комплектующих. Производителям серверного оборудования бессмысленно и экономически не выгодно изобретать «велосипед заново».
Рассмотрим на примерах содержимое серверов некоторых общепризнанных брендов. Что мы видим: корпус Huawei — или всё таки Supermicro? RAID-контроллер Lenovo/IBM — или может быть LSI/Avago? Диски HP — или Seagate? И память ставится не HP, а Hynix или Samsung.
Диск HP с парт-номером Seagate
Диск HP с парт-номером Hitachi
Так выглядит оперативная память многих производителей серверов: на ней оригинальные стикеры Hynix, Kingston, Samsung
Материнские платы хоть и выполняются по уникальному дизайну, но паяются на производствах всё тех же Foxconn, MiTAC и прочих ODM.
Понятное дело, что изменения, внесённые в оригинальные продукты, существенны — это может быть и разработка уникального дизайна, и написание собственного BIOS. Но иногда — это банальное переклеивание стикеров, с соответствующей программно-аппаратной валидацией.
Также остаётся вопрос фактической сборки — многие импортные бренды поставляются в Россию в разобранном виде (или разбираются здесь дистрибуторами). В итоге, сборка производится всё равно здесь, у нас, в России — силами дистрибуторов, интеграторов или конечного пользователя. Не смотря на это — некоторые серверы продаются как готовые изделия, произведенные на оригинальных сборочных производствах, однако такие системы почти всегда имеют большой срок поставки, от 8-12 недель, и даже больше.
Основными особенностями брендового сервера являются:
1. Обеспечение максимальной совместимости и стабильности работы всех компонентов системы — отчасти это достигается использованием оптимизированных прошивок и драйверов.
2. Комплекс услуг, который потребитель получает вместе с сервером, и который сопровождает его во время эксплуатации. Этот комплекс включает: оптимизацию конфигурации, технический пресейл, сборку и тестирование, технические консультации и гарантийный сервис.
Что есть отечественный производитель серверного оборудования?
В последнее время сборкой серверов занимаются все кому не лень. Даже некоторые дистрибуторы комплектующих, нарушая структуру взаимодействия с партнёрами, уже перестали стесняться продавать напрямую конечникам оборудование собственной сборки.
Сборкой сейчас никого не удивишь. Собирают везде: от радио-рынков и интернет-магазинов, до реселлеров и интеграторов.
Но есть и специализированные компании. На сегодняшний день на отечественном рынке работает несколько таких производителей и интеграторов, выпускающих серверное оборудование под своей торговой маркой.
Компания STSS одна из тех, кто производит собственный продукт, и на нашем примере я хочу продемонстрировать, чем мы отличаемся от большинства компаний, предлагающих наряду с продажей комплектующих услуги по сборке.
Для этого я собираюсь описать функциональные подразделения компании, само по себе наличие и уровень компетенции которых отличают ответственного производителя от самосборщика.
Лаборатория
В задачи лаборатории входит подготовка новой модели сервера к серийному производству. Когда речь идет о готовых платформах (Intel, Supermicro, Asus, Tyan), трудностей меньше, т.к. основные компоненты, такие как корпус с бэкплейнами и дисковыми корзинами, блоки питания, материнская плата и вентиляторы охлаждения, уже входят в состав платформы и совместимы между собой. Но если необходимо создать типовую модель с обширным конфигуратором — полная проверка и подготовка превращаются в длительный и кропотливый процесс. Сюда входит ряд основных мероприятий, в процессе которых инженеры сталкиваются с проблемами, многие из которых никогда не возникают в процессе обычной эксплуатации:
1. Проверка механической совместимости компонентов. Выявление несовместимости по габаритным размерам или длине кабелей.
Входной контроль
Эта внутренняя процедура проверки поступающих на склад комплектующих, позволяет исключить попадание брака на производство. В результате нам удаётся выдержать фактический срок производства сервера на уровне 3-5 дней для стандартных моделей, при заявленном сроке в 7-10 дней. Тесты упрощённые, не нагрузочные и отсеивают компоненты с явным браком.
Производство
Сборка серверного оборудования и СХД производится на стапелях опытными инженерами в строгом соответствии технологической карте. Производится установка и прошивка компонентов, инициализация RAID-массивов. Установка ОС и настройка драйверов производится в технологической сети в автоматизированном режиме.
Производство сервера на базе отечественной серверной платформы E-Class от компании «Т-Платформы» (Скорость записи x5)
Производство сервера на базе компонентов Supermicro (Скорость записи x10)
Перед отправкой сервера на тесты, инженер отдела контроля качества производит оценку изделия по следующим критериям:
1. Соответствие комплектации.
2. Наличие внешних повреждений.
3. Качество крепления компонентов.
4. Качество укладки и крепления кабелей.
Если изделие соответствует всем нормам и стандартам сборки компании, оно отправляется в тестовую зону.
Нагрузочное тестирование
На тестовом стенде сервер подвергается длительной нагрузке на все подсистемы. Для этого специально разработана методика, которая обеспечивает максимальную утилизацию ресурсов аппаратной части сервера с помощью программного комплекса. Это позволяет выявить неисправность или несовместимость оборудования. Методика заключается в следующем: Запускается скрипт, который производит опрос системы и определяет состав оборудования и версии драйверов. В зависимости от комплектации скрипт запускает последовательно множество тестов и их комбинаций.
Сюда относятся: десятки последовательных программных перезагрузок (soft reset), специализированные тесты графической подсистемы такие как SPECviewperf, 3DMark, специализированные тесты нагрузки процессоров от производителей, которые в отличие от популярного BurnInTest грузят абсолютно все блоки процессора, выводя его на расчетный TDP, собственные специализированные тесты дисковой подсистемы, имитирующие все виды нагрузок (линейные, случайные, смешанные) и прочий нагрузочный функционал, который нагружает и проверяет работоспособность процессоров и памяти, сетевых и дисковых контроллеров, всех накопителей, оптических приводов, графических сопроцессоров и прочих дополнительных устройств.
Стандартное тестирование длится от 18 до 30 часов в зависимости от конфигурации. Подобная методика тестирования готового изделия позволяет нам практически полностью исключить выпуск нестабильно работающего оборудования.
Гарантийный сервис
Благодаря нагрузочным тестам и выходному контролю, почти 100% от всех гарантийных случаев составляет выход из строя комплектующих после длительной эксплуатации — жесткие диски, затем блоки питания, значительно реже — платы распределения питания, бэкплейны, модули памяти. Крайне редко — материнские платы со скрытым браком, видеоадаптеры и RAID-контроллеры.
Преобладающее большинство обращений по гарантии приходится на последний, третий год гарантийного срока изделия. Процент гарантийных обращений крайне мал, но в количественном измерении, учитывая объёмы произведённых серверов, он весьма значителен. И это не смотря на все меры контроля и проверки.
Поэтому уровень гарантийного сервиса — это одно из основных преимуществ качественного производителя перед т.н. «самосборщиком». Приобретая «самосборный» сервер, пользователь зачастую получает сборщика в виде «прослойки» между конечным потребителем и производителем комплектующих. Даже если у клиента есть возможность обращаться по гарантии к такому сборщику напрямую, проблема всё равно транслируется производителю, и это существенно увеличивает срок реакции. Экспертиза и замена зачастую производится производителем комплектующих, и клиент вынужден ждать, когда пройдут все процедуры.
Наша компания, как уважающий себя производитель серверов, гарантийный сервис обеспечивает самостоятельно.
Особенности нашей гарантии:
Срок гарантийного обслуживания 3 года. Это стандартный минимальный срок обслуживания по гарантии в сервисном центре, который распространяется на все компоненты сервера. Даже на оптические приводы, вентиляторы и батарейки RAID-контроллеров, где гарантийный срок, заявленный производителем данных компонентов не превышает обычно одного года, а в ряде случаев составляет 6 месяцев. Тем не менее, трёхлетней гарантией обеспечивается всё изделие.
Сервисные центры во всех крупных городах России. Более 70 сервисных центров обслуживают по гарантии оборудование STSS Flagman и позволяют решать простые вопросы и проблемы средней сложности на месте.
Диагностика неисправности собственной сервисной службой. Во-первых: это позволяет максимально сократить время реакции. Во-вторых: диагностируется изделие в сборе, а не предположительно неисправный компонент — это позволяет избежать замены рабочей комплектующей на рабочую, и сократить время ремонта. Но если по полученным от клиента данным инженер удалённо точно определил неисправность — возможна упреждающая замена неисправной комплектующей, в основном это применимо к дискам, памяти и блокам питания с горячей заменой.
Расширенный гарантийный сервис. Гарантийные планы с увеличенным сроком обслуживания, сокращенным временем реакции и исправления неисправности, позволяют клиенту подобрать оптимальный уровень страховки от длительного простоя оборудования.
Технический пресейл
Не все наши клиенты способны определить потенциальную нагрузку на сервер, учитывая особенности ПО и выполняемых задач.
Если клиент знает условия эксплуатации, тип и уровень планируемых задач для сервера или СХД, но не знает как это сопоставить с требуемой конфигурацией «железа» — наш пресейл-инженер подбирает необходимую конфигурацию.
Расчет ведётся исходя из следующих параметров:
1. Исходя из типа и уровня сложности планируемых задач определяется оптимальная конфигурация вычислительной, дисковой и графической подсистем, тип и производительность сетевых контроллеров.
2. Учитывая необходимость в масштабировании системы в будущем, выбирается платформа с запасом для расширения. В зависимости от задачи, закладываются свободные дисковые отсеки, более мощный блок питания, свободные слоты под PCI-E-устройства и ОЗУ. В некоторых случаях заказчику требуется свободный сокет для увеличения вычислительной мощности в будущем.
3. Понимая требования к отказоустойчивости сервера, подбирается уровень RAID-массива, закладываются двойные блоки питания и другие элементы отказоустойчивости. Рассматриваются возможности резервирования SAS-экспандеров и RAID-контроллеров, а в ряде случаев, когда необходима наивысшая доступность — проектируется кластер без единой точки отказа.
4. В зависимости от уровня критичности отказа сервера и стоимости простоя бизнес-процессов, подбирается оптимальный гарантийный план, позволяющий минимизировать затраты заказчика в случае выхода сервера из строя.
С виду может показаться, что это не сложно, но в реальности процесс подбора действительно оптимальной конфигурации под конкретные задачи весьма не прост. Необходимо оценить, какие параметры аппаратных ресурсов использует ПО. Что в данном случае важней — частота процессора или количество ядер? Канальность, частота или объем памяти? IOPs или MB/s? Объем видеопамяти или мощность видеопроцессора?
Выявление и ликвидация «узких мест» системы, позволяет построить сбалансированную систему, которая будет выполнять задачи заказчика с максимальной эффективностью.
Если задача не тривиальна, и пресейл-инженер не может сходу спроектировать решение, остаётся тестирование в реальных условиях на реальных задачах с анализом результатов. Это может производиться и в нашей лаборатории и на площадке заказчика.
Продуктовый маркетинг
Задача продуктового маркетинга направлена на то, чтобы предложить клиенту не просто перечень комплектующих в той или иной платформе, а готовое программно-аппаратное решение под конкретные задачи. Серверы, СХД и рабочие станции классифицируются и позиционируются не только по техническим характеристикам, но и по функциям и ролевым предназначениям.
Причём продукты эти сбалансированы, протестированы и оптимизированы под выполнение конкретных задач пользователя.
Примером подобных решений могут быть серверы для видеонаблюдения или ВКС, хосты виртуализации, графические фермы и отказоустойчивые кластеры. Всё это позволяет заказчику быстрей определиться с конфигурацией решения и не «изобретать велосипед»
Почему наш подход востребован на рынке?
Кто-нибудь задавался вопросом почему мы все в принципе пользуемся платными услугами? Даже не теми, которые уникальны, а теми, которые могли бы заменить своими силами и средствами.
Например: доставка, автомойка, автосервис, различные агенства (туристические услуги, организация праздников и мероприятий и пр.), прачечная, столовая общественного питания. Этот список можно продолжать бесконечно.
Такая же ситуация наблюдается и в сфере бизнеса. Есть компании, которые пользуются сторонними услугами практически всех категорий, не связанных с прямым бизнес-процессом и вектором компании. Примером тому могут стать услуги: охранных предприятий, клининговых компаний, IT-аутсорсинга, кадровых агенств. Почему компании платят не маленькие деньги за подобные услуги и не пытаются выполнять их собственными силами? Почему организации арендуют склады, дата-центры и пользуются услугами логистических компаний? Они что, не способны реализовать всё это своими силами?
Как правило руководители таких предприятий хорошо умеют считать деньги.
Зачем раздувать штат работников и, как следствие, руководителей этих работников, проводить обучение, расширять офисные площади, когда можно воспользоваться услугами специализированной фирмы, которая сделает всё качественно, быстро и, скорей всего, за меньшие деньги? Компания при этом продолжает работать и зарабатывать тем, на чём специализируется, для чего и создавалась.
Я вижу две основные причины, по которым организации пользуются аутсорсингом:
1. Деньги. Затраты на всестороннее развитие и содержание инфраструктуры компании либо не окупаются, либо окупаются очень долго.
2. И деньги. Время и ресурсы, высвобожденные при использовании аутсорсинга, позволяют заработать денег больше, чем затраты на него.
Грамотный финансист и CIO скажет Вам, что OPEX почти всегда лучше чем CAPEX
Наши заказчики принадлежат различным отраслям и сегментам российского бизнеса и государственных образований. Одни имеют отдел IT, другие не имеют. У одних есть необходимые компетенции в сфере серверного оборудования, у других нет.
Есть заказчики, которые могут реализовать большую часть наших услуг своими силами, но они приходят к нам. Почему?
Потому что обращаясь к нам, они получают готовый сертифицированный продукт с гарантией качества. Избегая все вышеперечисленные трудности, с которыми они могут столкнуться, наши заказчики направляют свои усилия на основное направление фирмы: будь то разработка ПО или системная интеграция, торговля или производство.
Заключение
Надеюсь у меня получилось провести более-менее оформленную грань между производителями и «самосборщиками» на примере нашей компании. Мы продолжаем развиваться и расширять спектр услуг, сохраняя при этом основной вектор — серверы, СХД, комплексные инфраструктурные решения. На данный момент мы заканчиваем реорганизацию демозоны в Московском офисе. Здесь будут демонстрироваться решения по виртуализации и кластеризации. Развернуты системы видеонаблюдения основных отечественных разработчиков. Решения по активному шумоподавлению для серверных шкафов.
Наша демозона открыта для заказчиков с реальными задачами, требующими тестирования производительности реального программно-аппаратного решения. После реорганизации будет открыт доступ для тестирования извне и демонстрации работы решений удалённо.
Спасибо за внимание, жду Ваших комментариев и ответов в опросе!