Что делать со старым железом и СХД при переходе на гиперконвергентную инфраструктуру
При переходе с классической инфраструктуры на гиперконвергентную часть железа от старой конвергентной инфраструктуры, например СХД, остается невостребованной. Так происходит при внедрении vStack — гиперконвергентной платформы, разработанной в ITGLOBAL.COM. Если у компании было 24 сервера Dell и три СХД, то при переходе на vStack она собирает из них два кластера из 12 узлов. Серверы будут работать и дальше, но СХД из новой инфраструктуры выпадут.
Встает вопрос, как найти им новое применение и при этом оптимизировать расходы. Вместе с vStack мы разобради несколько вариантов и выяснили, как можно эффективно использовать старое железо.
Обеспечьте работу тестовых сред
Разработка любого сложного программного продукта быстро замедляется, если у вас нет тестовой среды для всего решения в целом. Тестовый контур требует использования соразмерного объема ресурсов. Необязательно выделять столько же ресурсов, как и на промышленном контуре, но если такая возможность есть, это даст больше предсказуемости, а также исключит проблемы, связанные с неравноценностью ресурсной базы.
Но со временем количество контуров может приблизиться к количеству команд. То есть рано или поздно менеджер или CIO, который отвечает за бюджет, обнаруживает следующую картину: каждая из команд «выбила» себе по собственному тестовому контуру.
Даже если изначально контуров меньше, чем команд, со временем к менеджеру приходят лиды и говорят: «Это не совсем честно — у одних есть свой контур, а у нас нет, чем мы хуже? В прошлом спринте команда интерфейсов выкатила обновление и сломала всю схему. В итоге у них успешный спринт, а мы потеряли две недели работы».
Евгений Гаврилов, руководитель проекта vStack
Если в продукте 12 команд, то получается 12 контуров. При этом бюджет на тестовые среды в несколько раз больше, чем на продуктовую среду, и, конечно, любой менеджер захочет сократить расходы на тестовые среды.
Есть два способа сделать это. Первый вариант — использовать старое железо, которое сняли с поддержки. Второй вариант — виртуализация, которая дает возможность использовать переподписку ресурсов.
Во втором случае нет необходимости выделенного аппаратного обеспечения в каждом контуре. Даже если у вас 12 контуров тестирования, то это не является проблемой, так как они не потребляют 100% разделяемых ресурсов в режиме »24/7».
Например, команда интерфейсов деплоит по вторникам, а нагрузочное тестирование проводит по четвергам; у другой команды деплой по средам, а нагрузочное тестирование по пятницам. При этом у одной команды тестирование занимает час, у другой — полтора часа, а у третьей всего 20–30 минут. Команды эффективно используют одно и то же аппаратное обеспечение и не конкурируют за его ресурсы.
Достаточно разместить контуры в одной виртуальной среде, которая не требует дорогих комплектующих. Инфраструктуру этой виртуальной среды можно развернуть на потребительском железе, и в итоге вы прилично сэкономите.
Обеспечьте работу ресурсов резервирования
Простые приложения, которые не требуют систем хранения, хорошо работают в публичных облаках, но как только появляется что-то более сложное, то возникают другие потребности. Например, если нужно синхронизировать данные на рабочем и standby-серверах или делать регулярный бэкап.
Возьмем крупную компанию, известного EDI-провайдера и оператора электронного документооборота. Её приложение не работало и не будет работать в облаках, так как использует огромные базы данных. Оно требует наличия собственных инфраструктуры и сред, обладающих характеристиками, недоступными в публичных облаках.
Как и в любой инфраструктуре, где есть большие базы данных, необходимо создавать некоторое количество реплик этих БД. Наличие реплики гарантирует, что данные не пропадут в один момент. В компании может быть и 2–3 реплики промышленной БД на различном железе, в том числе на старых СХД.
Во многих компаниях до сих пор стоят устаревшие СХД, которые не обеспечивают производительности, а выполняют единственную функцию — хранение данных. И это происходит до тех пор, пока оборудование совсем не перестанет работать.
Выделите под информационные системы с высокими RTO и RPO
Представим, что компания использует большое количество массивных информационных систем: ERP, CRM, BI, ABS и другие. Часть из них — сверхважные, эффективность работы которых напрямую влияет на ключевые бизнес-метрики. Целевые показатели RTO и RPO для них должны быть минимальны и близки к нулю.
Однако существуют менее важные системы, простой которых в течение часа не скажется на работоспособности компании. Для этих информационных систем можно использовать старые СХД. Нельзя однозначно сказать, под работу каких именно систем стоит выделять невостребованное железо — это должна решить компания, опираясь на RTO/RPO каждой системы, а также на степень влияния на бизнес.
В чем заключается проблема «старого» железа»?
Миграция сложных информационных систем или инфраструктур всегда происходит «в стороне», на «другом» оборудовании. Это связано с тем, что миграция сама по себе является очень длительным процессом и может быть признана несостоявшейся. В таком случае продолжается эксплуатация имеющегося оборудования или инфраструктуры.
Поэтому некорректно утверждать, что «проблема старого железа» возникает исключительно при переходе на гиперконвергентные решения. В той же мере она присутствует, когда сложные информационные системы мигрируют с одной СХД на другую, с одной SAN на другую и так далее. Как следствие — проблема старого железа не нова, а её решение не отличается оригинальностью.
Полный текст статьи читайте на Компьютерра
