Это было в 2016 году. У одного крупнейшего в России ритейлера стояла глобальная задача перейти на новую ERP-систему. Поскольку основные усилия были сосредоточены на перестроении бизнес-процессов, заказчик решил отдать задачи по ИТ на аутсорс и обратился к нам. Мы предложили ему комплексную услугу по аутсорсингу и аренде инфраструктуры, куда входили СХД, СРК, СУБД, виртуализация, физические серверы, сетевая инфраструктура.
После того, как завершился начальный этап внедрения продуктива, выявились ряд проблем, которые потенциально могли влиять на производительность и отказоустойчивость созданной системы. И таким «узким местом» стала виртуализация. О том, почему мы решили уйти от enterprise-решения на Open Source, а также почему этот опыт в текущих реалиях может быть полезным, мы и собираемся рассказать в сегодняшнем посте.
Великий и ужасный Open Source
Заказчик полностью доверился нашей экспертизе в части подбора оптимальных для него по стоимости и производительности инфраструктуры и софта. Флагманом корпоративного сегмента виртуализации на тот момент был VMware — удовольствие не из дешевых, но и продукты с открытым исходным кодом изначально мы не рассматривали, поскольку отдавали себе отчет в том, что не готовы взять на себя риски, оставшись с проблемой один на один, без участия вендора. Поддержка профессионального коммьюнити казалась чем-то далеким и ненадежным. В итоге мы сделали выбор в пользу Oracle VM, у которого техподдержка стоила адекватных денег, вендор позиционировал его как enterprise-продукт, и по функционалу он не уступал проприетарным решениям.
Постепенно функциональная нагрузка на системы ритейлера стала расти, также поменялись требования к производительности. Выяснилось, что первоначальный расчетный сайзинг от вендора приложений уже не соответствовал текущей нагрузке. Стало не хватать производительности сетевых драйверов виртуальных машин. Реальная производительность была сильно ниже заявленной. Вендор проблему подтвердил, но ее решение мы ждали в течение года.
За это время мы успели начать проекты по модернизации существующей инфраструктуры. Но тут на нас обрушились новые проблемы, гораздо более критичные, поскольку они касались отказоустойчивости и стабильной работы кластера виртуализации. Например, когда ВМ мигрировала на новый хост, она могла внезапно перезагрузиться, не смигрировать без объяснения причины, что сильно тормозило процесс переезда на новое оборудование.
Другой важной проблемой стали периодические перезагрузки хостов виртуализации. В части случаев причиной могла стать неудачная миграция виртуальной машины на новый сервер, причем перезагружался именно новый сервер со всеми ВМ на нем. Проблемы, как обычно, были вендору озвучены, и снова мы не смогли получить оперативной поддержки.
И мы, и заказчик уже отчаялись бороться с «ветряными мельницами», поэтому нам пришлось рассматривать для этого проекта альтернативное решение.
Чтобы сохранить требуемые SLA, мы предложили удачно показавшее себя в тестировании решение oVirt, которое выигрывало в надежности и производительности. Эта Open Source платформа на тот момент уже достигла технологической зрелости, и в ней были устранены основные баги, в частности, связанные с работой Windows.
Сроки проекта по модернизации поджимали, а решение проблемы от Oracle VM так и не поступило. Решили совместить миграцию со сменой платформы виртуализации, чтобы наверстать упущенное время. С заказчиком удалось быстро согласовать ряд критически важных параметров времени простоя, и миграция прошла за рекордно короткие сроки – всего за две недели.
Риск — дело благородное
Характерно, что с тех пор, как мы перенесли все на oVirt, никаких особых проблем в технической части не было. Тем не менее, человеческий фактор еще никто не отменял, и заказчик еще в течение нескольких лет с трепетом и дрожью вспоминал виртуализацию как «шкатулку проклятья», от которой можно ожидать всё что угодно.
Резюмируя этот кейс, хотим отметить, что заказчик оказался доволен виртуализацией на Open Source, более того, если ранее он располагал свои системы на общей ферме вместе с другими нашими клиентами, то теперь у него две собственные фермы для продуктивных систем, тестов и разработки под управлением oVirt. И системы продолжают уверенно расти и развиваться и по сей день. Безусловно, такое решение является отказоустойчивым и надежным.
К сожалению, в платных продуктах маркетинговые обещания могут не соответствовать действительности, поэтому при выборе решения надо, в первую очередь, основываться на всестороннем тестировании. При этом условии, вполне можно рассматривать Open Source как достойную альтернативу проприетарным решениям. Зачастую, можно получить требуемый функционал за меньшую стоимость.
В 2020 году мы провели модернизацию систем ритейлера, в ходе которой обновили гипервизор и его расширение до актуальной версии. При этом перейти на какой-то другой продукт желания у заказчика не возникло.
На нашей практике этот пример — уникальный. На российском рынке достаточно компаний, готовых развернуть виртуализацию на Open Source. Однако разместить на oVirt крупную ERP-систему? С таким опытом мы не сталкивались. Мы считаем, что можно смело располагать продуктивные системы любого объема и тесты на таком решении — это не повлечет особых рисков, но позволит существенно сэкономить бюджет.
Разворачивали ли вы продуктивные системы на Open Source продуктах? С какими трудностями вам пришлось при этом столкнуться, и, главное, как их удалось обойти?
Jet Service Team