Понятие конвергентной инфраструктуры существует с конца 2000-х годов. Тем не менее, реальное проникновение этой технологии на рынок, особенно в России, пока нельзя назвать значительным. В 2015 году российская компания IBS представила гиперконвергентную платформу собственной разработки – «Скала-Р». За полтора года специалисты компании ответили на множество вопросов российских ИТ-инженеров и менеджеров о том, что же такое гиперконвергентная платформа, чем она отличается от всего остального на рынке ИТ и зачем она нужна, если «и так все работает». Мы подготовили ответы на самые частые – и не всегда простые для нас – вопросы и делимся с вами нашим пониманием конвергентности.
Самое главное про конвергентную инфраструктуру: это нерушимый союз оборудования и программного обеспечения. Оборудование – это вычислительные мощности, сеть, диски. Программное обеспечение – виртуализация, мониторинг, управление, то есть функции, которые раньше выполнялись специализированными программными и аппаратными компонентами.
В конвергентной инфраструктуре задача хранения решается аппаратным способом – с помощью сетей хранения данных (SAN). В гиперконвергентной инфраструктуре СХД строится на серверных накопителях с помощью технологий программно-определяемого хранения (SDS).
Вот четыре преимущества, которые, с нашей точки зрения, отличают гиперконвергентную среду от классической:
С ростом валютного курса затраты на сопровождение существующих ИТ-систем резко выросли. Оставлять информационные технологии без поддержки производителей нельзя, а это значит, что меньше средств остается на развитие ИТ. Конечно же, компании озабочены вопросом, как сократить стоимость поддержки, чтобы продолжать развивать свои ИТ-системы в ногу со временем. Бюджетные ограничения стали для российских компаний триггером перехода на гиперконвергентные платформы.
Другой триггер – это подошедший срок замены основной инфраструктуры. После 3–5 лет эксплуатации стоимость сопровождения оборудования и ПО возрастает, плюс прогресс в области аппаратного обеспечения позволяет за сравнимые деньги эксплуатировать в разы более производительные системы. Перевод части (или всех) систем на гиперконвергентную платформу особенно уместен в момент обновления базовой инфраструктуры.
На самом деле технологии устаревают каждый день. Постоянно выходят новые процессоры, диски, коммутаторы, обновляются прошивки и версии консолей управления.
Если в случае с проприетарной системой через 3–5 лет вам придется покупать все заново и отдельным проектом переводить инфраструктуру на новую версию, то в случае с гиперконвергентной системой достаточно будет подключить новые узлы с современной «начинкой». Система сама их подхватит и начнет использовать в соответствии с настроенной стратегией. Перераспределение задач и нагрузки произойдет автоматически.
Наоборот, гиперконвергенция – это одно из самых популярных архитектурных решений в духе «веб-масштаба». Она реализует все основные принципы, заложенные в инфраструктуру интернет-гигантов: заменяемые «строительные блоки», построенные на компонентах массового класса, постоянная балансировка ресурсов, неограниченная горизонтальная масштабируемость и бесперебойная работа в условиях отказа устройств и целых узлов. Другое дело, что это не единственное решение в стиле web-scale. Тот же Facebook использует «дезагрегированную архитектуру», которая состоит из узлов различного назначения – вычислительные мощности, сеть хранения, вычисления с использованием ускорителей. Мы реализуем элементы такого архитектурного шаблона в специализированных комплексах для СУБД и аналитики.
Все подходы из категории web-scale, в том числе гиперконвергентные решения, несут принципиально другую модель проектирования и эксплуатации ИТ-инфраструктур. Они позволяют работать на уровень выше вычислителей, сетевого оборудования, сети хранения – все это становится программно-определяемыми компонентами, а система сама решает, на каких узлах их физически разместить, следит за «здоровьем» составных частей, выводит из эксплуатации непригодные и подключает новые компоненты. Администратор только задает основные параметры конфигурации, а система самостоятельно определяет, на каких узлах разместить запрошенный ресурс.
У каждого в кармане сейчас есть смартфон, в который встроена камера, фонарик и GPS-приемник. Снимки с камеры уступают профессиональным, на встроенный фонарик нельзя положиться в водном походе, GPS быстро «высаживает» батарейку. Но давайте не будем себя обманывать: 9 из 10 человек никогда не возьмут в руки профессиональную камеру, купленный фонарик будет использоваться пару раз в год, а телефонный GPS будет работать в машине, подключенный к прикуривателю. Смартфон прекрасно решает задачи пользователей, он приспособлен к пользовательским сценариям и удобен своей универсальностью.
То же самое с гиперконвергентной платформой – это швейцарский нож, который удобно «носить в кармане», а референсные конфигурации, если пользоваться аналогией, заставляют возить за собой большой и тяжелый чемодан на колесиках. Именно из-за следования референсным конфигурациям чаще всего возникает «ИТ-зоопарк» – технологически неоднородная инфраструктура, которую трудно поддерживать и развивать.
Помимо единой точки поддержки и интеграции оборудования и SDS, у гиперконвергентной инфраструктуры есть еще две отличительные особенности.
Первая – система должна уметь «подхватывать» новое оборудование и автоматически включать его в соответствующий контур с минимальным участием человека. В отчете Forrester Research указано: «Гиперконвергентная система должна быть способной добавлять новый блок емкостью до 100 ТБ не более чем за 15 минут времени работы оператора, при этом имеющиеся компоненты кластера не должны требовать административного вмешательства».
Вторая особенность заключается в том, что инструменты мониторинга и управления должны охватывать всю систему целиком. В единой консоли вы контролируете все параметры системы и в случае сбоя можете сразу понять, что является его причиной, и в единой консоли вы управляете виртуализацией, сетью и системой хранения.
Узкоспециализированные задачи остаются, от них никуда не денешься. Однако по нашему опыту более половины проблем с работоспособностью конечных приложений появляются или усугубляются на стыке систем, когда источник ошибки не определен и может быть сразу в нескольких модулях. В таких случаях унифицированный мониторинг и управление помогают избежать ситуаций, когда «починили и там, и там», а система снова не работает – потому что «чинить» надо было что-то одно.
Вот более позитивный пример. Представьте себе: вы меняете диски в СХД на более быстрые. Вам надо переконфигурировать и SDS, и интерконнект, чтобы сеть не стала узким местом. Это удобнее, быстрее и безопаснее (ничего не забудем) делать из одного инструмента управления, а не из разных.
Безусловно, вы можете самостоятельно собрать гиперконвергентную платформу. Два вопроса, которые нужно себе задать перед тем, как браться за это дело: «сколько ресурсов я потрачу сейчас и в течение 3-5 лет» и «уверен ли я, что сбалансированно подберу компоненты». Можно выбрать разные процессоры, разные сетевые решения, разные варианты организации СХД, всевозможное ПО и проверить все это в разных комбинациях в работе друг с другом под нагрузкой. Сколько сил потребует такое исследование?
Мы, системный интегратор с не одной сотней проектов за плечами, потратили больше полугода на то, чтобы сформировать первые варианты «начинки» нашего продукта, и еще столько же силами большой команды мы тестировали, проверяли, конфигурировали оборудование на совместимость друг с другом в типовых сценариях использования.
За это время мы научились решать множество мелких и крупных задач совместимости оборудования и ПО. Ведь речь идет о таком сложном инфраструктурном ПО, как системы виртуализации и программно-определяемые сети хранения, где такие задачи на сопряжение особенно нетривиальны: чтобы вся конструкция работала слаженно, сбалансированно, использовала по максимуму паспортные возможности оборудования в любых условиях и бесшовно отрабатывала все нештатные ситуации, требуется перебрать сотни комбинаций и тысячи параметров, провести десятки испытаний для каждого такого варианта, убедиться в стабильности работы самых распространенных СУБД, серверов приложений, прикладных сервисов и систем, выявить особенности работы с ними и практически рассчитать для них показатели назначения – все это время и труд высококвалифицированных специалистов.
Надо принимать во внимание, что жизненный цикл оборудования и ПО – 3–5 лет, если только речь не идет о каком-нибудь приложении, замороженном на многие годы, живущем без доработок, обновлений, с предсказанной на 10 лет вперед нагрузкой. Через 3–5 лет вам придется менять вычислители, коммутацию, накопители и обновлять софт. На подбор и подгонку компонентов вы потратите примерно столько же времени, сколько на создание новой системы.
Вот тут-то гибкость конвергентных инфраструктур будет очень кстати. Конвергентная система обновляется и наращивается строительными блоками, и этот процесс может быть поэтапным. Нужно лишь планировать необходимые вычислительные мощности и ресурсы хранения в целом, не углубляясь в специфики приложений. Обновление «начинки» блоков и проверку совместимости за вас будет делать производитель.
Интегратору придется пройти тот же путь, что и любому другому производителю конвергентных сред, и наступить на все или почти на все грабли. Это точно самый дорогой и не самый быстрый способ.
Можно мыслить категориями отдельных подсистем: вот вычислители, вот хранилище, вот сеть. При таком подходе для каждого Line-of-Business-приложения можно построить идеальную инфраструктуру, в которой оно точно будет хорошо работать. Минусом будет обилие систем, производителей, ПО, консолей, требуемых знаний, SLA, ресурсов для поддержки и развития ИТ-хозяйства, а в конечном итоге – рисков для бизнеса.
Есть и другой подход: не ухудшая эксплуатационные характеристики LoB-приложений, использовать унифицированную инфраструктуру, которая гарантированно обеспечит работоспособность всех ИТ-систем и при этом будет проста в обслуживании за счет стандартизации.
На практике, конечно, применяется нечто среднее между двумя подходами. У крупных заказчиков, как правило, есть стандарты на оборудование, на версии ОС и прикладного ПО. Гиперконвергентные платформы позволяют переходить ко второму подходу быстрее и дешевле, потому что значительная часть работ по стандартизации ИТ-инфраструктуры ложится на производителя платформы.
Это традиционный подход «сверху вниз». Именно его рекомендуют производители прикладных решений, потому что он минимизирует их собственные риски. Софт, установленный на «свои» технологии, в свою очередь установленные на «свою» инфраструктуру, точно будет работать без сбоев. Цена за это – возрастающая из-за разобщенности компонентов стоимость поддержки и развития инфраструктуры. Заметьте, эту цену платит конечный потребитель, клиент, а не производитель прикладного ПО.
Мы уверены, что стоимость владения инфраструктурой можно и нужно снижать за счет движения и «сверху вниз», и «снизу вверх», когда требования производителей ПО в части технологий и инфраструктуры встречаются с требованиями со стороны компании-клиента. Роль производителя конвергентной платформы – в постоянной медиации, сопряжении прикладных пакетов со стандартными «кубиками» гиперконвергентной платформы. Реальный экономический эффект от снижения расходов на поддержку и сопровождение инфраструктуры несравним с потенциальным эффектом «бантиков», от которых, возможно, придется отказаться.
Мы постоянно и очень внимательно изучаем все, что происходит с OpenStack. Это развивающийся комплекс свободных проектов, нацеленный на провайдеров облачных услуг, хотя в последние годы крупные организации все чаще используют его для создания внутренних инфраструктурных решений. Но важно отличать составляющие и функциональные возможности гиперконвергентных систем от конгломерата проектов, объединенных под эгидой OpenStack. В гиперконвергентной системе конкретное программное обеспечение специально подобрано для оптимальной работы с конкретным оборудованием, и наоборот.
Как мы уже говорили, в сложных системах очень много проблем возникает на стыке компонентов. OpenStack не исключение (пока, во всяком случае): действительно опытных специалистов, которые знают все пограничные особенности, мало, и не все проекты OpenStack достаточно зрелые.
Проекты OpenStack обновляются несколько раз в год. Задача обновления ложится на плечи ИТ-персонала компании, а все риски — на бизнес. Поддержка и развитие компонентов OpenStack осуществляется сообществом, а не коммерчески мотивированными компаниями, хотя таковые и могут быть частью сообщества. В связи с упомянутой сложностью и вариативностью технологий OpenStack даже коммерческая поддержка внедрения, скорее всего, будет сложнее и дороже, чем поддержка готового решения.
В случае с серийной гиперконвергентной платформой стыковыми проблемами, развитием и поддержкой занимается производитель, он же несет ответственность в рамках SLA. Ваши специалисты могут тратить больше времени на развитие технологий, а не на их сопровождение.
С другой стороны, OpenStack настолько многообразен и универсален, что его средствами можно управлять и гиперконвергентной инфраструктурой, и даже несколькими виртуализированными инфраструктурами от разных производителей. В случае со «Скалой-Р» все программные решения – от виртуализации и программно-определяемой сети хранения до управления и мониторинга – хорошо интегрируются с соответствующими модулями OpenStack. Так что компании, которые используют или предполагают использовать OpenStack, могут интегрировать нашу гиперконвергентную платформу в общий контур управления инфраструктурой.
Когда мы работали над архитектурой «Скалы-Р», мы анализировали профили нагрузки для десятков прикладных систем и поняли, что на примерно одинаковых параметрах (объем данных, количество пользователей и т. д.) получается относительно типовая нагрузка.
Это дало нам возможность создать готовое решение, которое подходит для большого спектра инфраструктурных задач и строится на обыкновенных недорогих компонентах.
Но не всегда первый подход давал требуемый результат. Например, сначала мы использовали 10-гигабитную сеть, но вскоре поняли, что в некоторых случаях она становится узким местом. Для унификации и надежности мы во всех наших продуктах перешли на сеть с пропускной способностью 56Гб.
Есть приложения, которые генерируют такую нагрузку, что ее нельзя обрабатывать типовым решением. Примеры – визуальная аналитика больших массивов данных, высокоинтенсивные транзакционные системы. Под такие задачи мы создаем специализированные продукты, которые отличаются не только компонентами, но и архитектурой. Например, для вычислений в нагруженных аналитических системах мы используем GPU.
Возвращаясь к аналогии со смартфонами, заметим, что даже у самого консервативного производителя в линейке есть несколько вариантов продуктов, которые отвечают разным сценариям и потребностям пользователей. Такая же ситуация с конвергентными платформами: да, это готовое решение, которое вы выбираете из линейки производителя с учетом своих потребностей.
Например, в нашей линейке есть несколько базовых предложений, которые отличаются по сценариям использования: продукт, основной сценарий для которого – СХД, продукт, оптимизированный под вычисления, и т. д. Для особенных задач, например, аналитики in-memory, мы предлагаем специализированные решения с вычислителями на основе GPU. Общая архитектура при этом остается модульной: если мощному вычислителю требуется быстрое хранилище, можно использовать совместно разные продукты из нашей линейки.
Гиперконвергентная платформа тем и хороша, что ее просто и недорого масштабировать под задачу любого класса. Другое дело, что за «простыми и недорогими» действиями для клиента лежит много экспертизы и работы на стороне производителя.
Производители предлагают разные продукты для разных целей. Мы поставляем «Скалу-Р» как проверенную и предсказуемую основу для ERP-систем, систем документооборота, коммуникации и совместной работы, проектов виртуализации рабочих мест, аналитических систем, резервного копирования и других задач. Нами протестированы разные варианты и конфигурации самых популярных СУБД, серверов приложений. От конкретных потребностей зависит конфигурация оборудования, системного и прикладного ПО — мы отвечаем за работоспособность комплекса в целом.
Например, Московский Энергетический Институт использует нашу платформу для работы аналитической системы. Судостроительный завод «Янтарь», входящий в ОСК, эксплуатирует «Скалу-Р» для управления конструкторской документацией и работы внутренних приложений.
В основе гиперконвергентной платформы лежит оборудование «массового класса»: процессоры x86, память, сеть, накопители. Заменой этих компонентов на более производительные и простым добавлением узлов можно масштабировать систему до нужных параметров. Особенность в том, что при замене или добавлении любого компонента нет необходимости останавливать всю систему.
Один из наших партнеров проводил нагрузочное тестирование почтовой системы для пяти тысяч пользователей. Испытаниям подверглась начальная версия «Скалы-Р» с обычными дисковыми накопителями. Мы начали давать нагрузку и ближе к максимальным значениям поняли, что система не справится. Не останавливая стенд и не меняя конфигурации сети хранения, мы заменили все шпиндельные диски на SSD. Система автоматически перераспределила данные между новыми и старыми накопителями, и на весь апгрейд ушло меньше двух дней. После этого комплекс справился с пятью тысячами пользователей, потом с шестью, с семью, и, наконец, после восьми тысяч перестала справляться уже нагрузочная система. Мы решили остановиться, потому что для всех было очевидно, что задача уже решена, а предел быстродействия еще не достигнут.
Конвергентные платформы строятся на массовом (commodity) оборудовании. Производитель тестирует и проверяет его как на банальную совместимость, так и на надежность, отказоустойчивость и соответствие заявленным показателям. Мы не ограничиваем наших клиентов в самостоятельной покупке и замене компонентов, если эти компоненты прошли нашу проверку, и продолжаем обслуживать систему и нести за нее ответственность. Но если вы вставите в сервер SSD для настольной системы, вряд ли производитель сервера будет готов нести ответственность за сбои в работе системы корпоративного масштаба.
Типовая конфигурация не означает зафиксированного списка оборудования и ПО – она означает постоянную работу по подбору современных компонентов. Вместе с этим ответственность поставщика за работоспособность системы требует согласованного подхода в модернизации.
Во-первых, такой сценарий маловероятен по определению гиперконвергентной платформы. Ведь это не только подобранное и протестированное оборудование и ПО, это еще и системы защиты, резервирования (в том числе по питанию), отказоустойчивости, виртуализации.
Во-вторых, даже в такой – и особенно в такой – неприятной гипотетической ситуации гиперконвергентная платформа имеет преимущества перед классической. Так как ответственность и гарантийные обязательства несет одна компания, поставщик платформы, весь комплекс мероприятий по исправлению ситуации ложится на плечи единственного контрактора, а не пула разобщенных поставщиков. Именно поставщик принимает первичный запрос, если необходимо – осуществляет его диспетчеризацию на собственную вторую линию или в поддержку производителей отдельных компонентов. После локализации причины сбоя специалисты производителя гиперконвергентной платформы самостоятельно или через персонал компании-клиента исправляют проблему.
У нас как у производителя есть постоянный доступ и контакт с техподдержкой компаний, решения которых мы используем: DEPO, «Росплатформа», Acronis и других. В критических случаях наши инженеры выезжают на место аварии для решения проблемы, в том числе с заменой оборудования, не позднее следующего бизнес-дня (для Москвы).
Главное отличие – в модели управления. Управление виртуализацией должно работать в тесной связке с мониторингом и конфигурацией сети и системы хранения.
Например, виртуализация в «Скале-Р» работает на технологии «Росплатформы». Решение использовать «Р-виртуализацию» (продукт «Росплатформы», ранее – Virtuozzo от Parallels) мы приняли с оглядкой на стоимость, санкционную безопасность и зрелость их продукта. Хотя их «Р-виртуализация», может быть, и уступает в деталях решениям на базе VMware, но нашей задачей было создать типовой продукт за минимальную стоимость, будучи при этом уверенными в его перспективах. «Р-виртуализация» идеально подходит под этот профиль: продукт растет, его используют сотни компаний в России и за рубежом, он отлично справляется с основной задачей – гипервизорной и контейнерной виртуализацией. При этом его стоимость на 30% ниже, чем у функциональных аналогов, и он безопасен с точки зрения санкций. Более того – он изначально тесно интегрирован с программно-определяемой сетью хранения «Р-хранилище».
Гиперконвергентную платформу важно контролировать как единое целое. Как мы говорили, очень много проблем возникает на стыке технологий, и мониторинг должен уметь обнаруживать и раскрывать их. Поэтому единственный тонкий момент в использовании существующей системы мониторинга – насколько она «умеет» контролировать конкретные программные и аппаратные решения, примененные в гиперконвергентной платформе.
Когда мы проектировали мониторинг для «Скалы-Р», мы рассмотрели несколько решений и поняли, что даже с самыми лучшими (и, соответственно, дорогими) нам придется попотеть, чтобы объединить потоки от процессоров, сети, памяти, устройств хранения и GPU с информацией от «Росплатформы» и другого инфраструктурного ПО. В итоге мы разработали собственную систему IBS Monitoring, которая позволяет контролировать и управлять всей платформой как одним организмом.
Мониторинг гиперконвергентной платформы, во всяком случае нашей, может быть использован как источник консолидированной информации для большого «зонтичного» мониторинга. Готовые коннекторы позволяют подключить наш мониторинг к IBM Tivoli, HP OpenView, Microsoft SCOM, Zabbix и прочим системам. Два мониторинга будут только если вы сами этого захотите.
Сможете, конечно. IBS Monitoring способен контролировать производительность, транзакции, сервисы, события, данные, интерфейсы, взаимосвязи систем – нужно только один раз сконфигурировать его для работы с вашим оборудованием и ПО. Система полностью документирована на русском языке. Вы можете как использовать ее в качестве источника информации для другой системы мониторинга, так и построить на ней полноценное решение для мониторинга всей инфраструктуры, конвергентной или нет.
Технология программно-определяемой сети хранения способна работать с той степенью отказоустойчивости, которая вам нужна. Данные по умолчанию реплицируются на несколько устройств хранения в разных узлах, и выход из строя одного или нескольких накопителей или даже узлов не приводит к катастрофическим последствиям, потому что система автоматически пересоздает потерянные копии данных на работоспособных накопителях.
Поэтому, если говорить про гиперконвергентные платформы и резервное копирование, вопрос, скорее, надо поставить так: можно ли использовать их как хранилище для резервных копий? Ответ – можно. В частности, в нашей линейке есть продукт, оптимизированный для хранения больших объемов данных. Мы проверили его совместно с известными решениями для резервного копирования и гарантируем, что он совместим и оптимально работает с точки зрения быстродействия.
Кстати, в последнее время с ростом объемов данных для резервирования возрастают требования именно к производительности систем хранения, чтобы резервное копирование успевало уложиться в отведенное для процедуры время, например, за ночь. В этом случае для организации системы хранения мы используем не дисковые, а твердотельные накопители. В то же время есть задачи, для которых использовать SSD – это как стрелять из пушки по воробьям, поэтому мы не отказываемся от HDD совсем. Нам важно удерживать баланс типового решения.
Так же, как и любой другой объект информационных технологий: включить ее в общий контур безопасности. Многие наши заказчики предъявляют особые требования к защищенности комплексов, для таких случаев мы разработали специальные конфигурации, где используются решения безопасности от «МФИ Софт», «Позитив Текнолоджис», «Код безопасности» и других.
Каждый производитель решает этот вопрос по-своему. Мы создавали «Скалу-Р» с учетом экономических реалий рынка, требований российских регуляторов и политической ситуации. Мы тщательно следим за требованиями государства к производителям продукции, поставляемой в государственные и муниципальные органы, и с уверенностью заявляем, что предлагаем самый «российско-ориентированный» гиперконвергентный комплекс широкой доступности. «Скала-Р» полностью соответствует текущим государственным требованиям и будет соответствовать им в будущем. Понятно, что совсем не зависеть от импортных поставщиков не получится: процессоры, память, накопители, сетевое оборудование закупаются за рубежом. Но важно, что у нас нет санкционно чувствительных элементов: либо это компоненты, доступные на массовом рынке, сбыт которых не контролируется поставщиком, либо это компоненты от поставщиков из стран, не поддерживающих санкции (КНР, Тайвань, Израиль). Там, где это возможно, мы используем отечественные разработки – серверы DEPO, виртуализацию и СХД «Росплатформы», собственную разработку IBS – IBS Monitoring, выбираем российских производителей базового и прикладного ПО, которые не зависят от санкций и готовы открывать исходные коды, если на то есть требование регуляторов.
В случае со «Скалой-Р» вы точно сможете аттестовать под соответствующие требования. Во первых, IBS имеет четкие договоренности с производителями компонентов ПО, входящего в «Скалу-Р», относительно раскрытия и предоставления исходных кодов и всей необходимой документации, что позволит IBS провести сертификацию ПО на «недокументированные возможности». Во-вторых, в комплексе используются некоторые наложенные средства защиты информации, и в рамках технологического партнерства с IBS с российскими вендорами указанных средств обеспечивается поддержка программной платформы «Скала-Р».
В случае с зарубежными гиперконвергентными платформами ситуация может быть несколько иной.
У каждого производителя здесь свой путь. У западных производителей обучение ведется через документацию, курсы, тренинги. В нашем случае мы предоставляем полную документацию на русском языке и проводим «живые сессии», где наши архитекторы работают со специалистами заказчика. На таких сессиях мы объясняем архитектуру, ключевые особенности по поддержке и администрированию системы, рассказываем, как она работает, как расширяется, что делать в случае сбоев, аварий.
Технические детали разъясняются инженерами с учетом конкретной реализации и всех ее хитростей. Мы всегда делимся знаниями, полученными в ходе конфигурации каждой задачи. Мы обучаем больше через живой контакт, чем через бумагу и презентации.
Прежде всего, надо определить задачу, разобраться, что и почему не устраивает сейчас и как должно быть, и параллельно изучать предложения производителей гиперконвергентных решений с точки зрений удобства обслуживания.
Скорее всего, вы захотите провести стендовые испытания. Для этого понадобится программа и методика испытаний. На стенде вы сможете оценить не только возможности масштабирования, но и удобство мониторинга и управления конвергентной платформой в деле.
Здесь надо подчеркнуть, что в случае с IBS и «Скалой-Р» снимаются многие барьеры, присущие западным производителям: языковые, административные, политические. В классическом сценарии есть производитель гиперконвергентной платформы, есть дистрибьютор, есть реселлер и интегратор. В нашем случае цепочка сокращается: мы создаем продукт, используя свои собственные и партнерские решения, и отвечаем за его внедрение и функционирование перед конечным заказчиком. Поэтому все делаем очень быстро, в том числе стендирование, конфигурацию, поставку и запуск.