Частное облако на старом железе: опыт, возможности, риски
Отказ крупных публичных облачных сервисов работать с российскими компаниями вынуждает бизнес и госпредприятия искать альтернативу. Миграция в новое облако сопряжена с рисками, которые зависят от конкретной компании, характера систем, работающих с облачным хранилищем. Иногда логичными представляются небольшие частные облака на базе старых ЦОДов, альтернативное решение – ориентироваться исключительно на публичные облачные сервисы российских вендоров.
В нашей компании накоплен опыт с различными архитектурами облачных решений и мы готовы им поделиться. В этом материале о том, как мы использовали частные и публичные облачные сервисы, где и когда имеет смысл их использовать, какие критерии следует применять при выборе формата и архитектуры.
Как было раньше
Я впервые с частными облаками столкнулся в Болгарии в 2008 году. Тогда облачные решения предлагались HP и Microsoft. Это были передовые решения, о которых мало сообщали публично. Облако от HP в тот момент представляло собой две-три стойки, которые устанавливались на территории заказчика.
При этом существовало несколько форм использования, в частности, подписка, аренда, лизинг и покупка. Тогда это была масштабируемая и управляемая архитектура, которая фактически дублировала возможности современных публичных и частных облаков в виде комплексного решения в ЦОДе заказчика.
Естественно использовался собственный софт, корректно настраивающий облако, а также поддержка со стороны вендора. В то же время Microsoft уже начали предлагать публичные облака, однако их использование на промышленных объектах в то время было проблематичной, в силу осторожного недоверия к идеям применения публичного облака для критической инфраструктуры.
Это спровоцировало использование частных облаков, которые спасали в тот момент, когда оборудования в ЦОДе выходили из строя или переполнялись. Тогда же компания начала использовать услуги Microsoft, что позволило оценить преимущества как публичных, так и частных облачных решений.
Опыт в холдинге «Энергетика, системная интеграция» (ГК «ЭнСи»)
В ГК «ЭнСи» мы приняли решение совместить частное и публичное облако, объединить их в гибридный вариант. Критическая инфраструктура размещалась в частном ЦОД для бухгалтерии и финансового софта. Первое гибридное облако в ЕАЕ-Консалт построили в 2014-м году. Использовавшийся для этого ЦОД мы не покупали, а взяли в лизинг – применяли оборудование по подписке с правом последующего выкупа через пять лет.
Со временем пришло понимание, что содержание ЦОДа — дорогое удовольствие, рационально, использование инфраструктуры публичного облака. Проблемой частных облаков стала постоянная поддержка, контроль, продление гарантийных обязательств вендора. Очевидно, что дешевле и удобнее приобретать конечную услугу.
Самостоятельный опыт ЕАЕ-Консалт
Остановились на сотрудничестве с Яндекс Облаком и Microsoft. Старые стойки, доставшиеся компании после завершения срока договора лизинга, мы стали использовать в качестве “песочницы” для тестирования и экспериментов с новыми решениями. Критическая инфраструктура мигрировала в публичные облака.
В итоге приняли для себя решение о том, что уже приобретённое оборудование будем использовать, пока работает. Так, железо уже не требует затрат, лизинг выплачен, а критической инфраструктуре ничего не угрожает – данные размещены в публичном облаке.
Когда компания вышла из состава холдинга и начались сложные времена - этот ЦОД серьёзно выручил. Решения Microsoft приемлемы по стоимости, когда речь идёт о крупном холдинге, но для небольшой компании такое публичное облако стало серьезным финансовым бременем.
Лучшим выходом оказалось выгрузить данные в купленные когда-то стойки и работать с ними как с небольшим частным облаком. Решение, безусловно, было скромнее по уровню доступности, отказоустойчивости и производительности, но его вполне хватало для работы с данными ЕАЕ-Консалт, которые раньше размещались в облаке Microsoft.
Сопоставление стоимости и уровня доступности
Принимая решение об использовании частного облака, вы оказываетесь перед дилеммой. С одной стороны, владелец собственного ЦОДа способен сам всё контролировать и безопасность данных зависит исключительно от него. С другой – сопоставимое по уровню доступности публичное облако дешевле. Как правило, частные ЦОДы, равные по возможностям публичным облакам, никто не создает.
Таким образом, создавая частное облако, важно рассчитывать стоимость овчинки и выделки и понимать, какого рода оборудование нужно для размещения тех данных и инфраструктуры, для которых будет использоваться ЦОД. Существуют компании, в которых даже пятиминутные отказы оборудования будут сопряжены с большими убытками. Для ретейлеров, банков, финтех-компаний, системообразующих предприятий, промышленных гигантов такие сбои особенно болезненны.
В подобных случаях для критической инфраструктуры и процессов, требующих отказоустойчивости, лучше использовать публичные облака или создавать ЦОДы для частного облака, сравнимые по уровню доступности и надежности. Использовать здесь старое «железо» опасно и неразумно.
Овчинка и выделка в вопросе выбора архитектуры
Когда речь не идет о столь высоких рисках, которые требуют постоянной работы и обязательного мгновенного disaster recovery, можно вполне обойтись частным облаком. Например, если речь о бухгалтерии небольшой компании, где время проведения транзакции и возможных задержек в результате отказа серверного оборудования не является критичным. Обычно 30-60 минут, которые не будет работать система, не более чем повод посидеть в новостях или устроить небольшой перерыв в работе.
Таким образом, вопрос архитектуры и самой возможности использования частного облака необходимо решать исходя из экономической целесообразности в той или иной ситуации, в конкретной компании и для реализации конкретных целей.
Срок жизни оборудования, или Что можно использовать?
Известно, что большинство вендоров рекомендуют использовать серверное оборудование не более пяти лет. По нашему опыту, модели серверов, хранилищ, коммутаторов, произведенные в 2013-2014 году, можно использовать и сегодня для всего, что не касается критической инфраструктуры предприятия. Коммутаторы устаревают значительно медленнее стоек, их можно смело использовать 10 лет. То оборудование, которое мы брали в лизинг, не будет ломаться, если его не отключать.
Учитывая деградацию и износ некоторых отдельных деталей и устройств в этом оборудовании, достаточно просто периодически уменьшать емкость. Мы прогнозируем, что наш ЦОД продолжит работать еще два года в щадящем режиме. Важно также понимать, что производительность серверов будет существенно ниже, чем у современного оборудования.
Так, целая стойка с серверами Fujitsu, которой мы пользуемся с 2015 года, по производительности будет равна четырем современным серверам HP. Тем не менее большинство приложений на старой стойке будет работать так же, как на современном оборудовании, и лишь плотность размещения приложений будет меньше. Вместо десяти виртуальных машин на одном сервере в новом будет три.
Российское серверное оборудование
В России уже ведется производство серверного оборудования как на базе процессоров «Байкал», так и на базе процессоров Intel и AMD. Можно прогнозировать, что в течение трех – пяти лет на российских процессорах можно будет создать сервер, сопоставимый по производительности с зарубежными 2010-2011 гг. Такие серверы смогут покрыть большинство базовых потребностей российских компаний. В этот временной промежуток, за который должно появиться российское оборудование, альтернативой для критических процессов и данных могут стать частные облака на старом «железе» (оборудование, выпущенное не раньше 2013 года).
В сухом остатке
До появления российских серверов частные облака на старом «железе» сохранят свою актуальность. Имеет смысл использовать их для некритических данных, там, где нет жестких критериев отказоустойчивости и времени восстановления работы при сбое. Для всех критических данных имеет смысл приобретать публичное облако – его уровень доступности выше, а риски при отказах несопоставимо ниже.
Старое серверное оборудование сохраняет работоспособность на протяжении 10 лет, при этом падает его производительность. Наибольшая проблема при использовании сервера – плотность размещения приложений со временем падает в три-четыре раза. Наиболее оптимальным, на наш взгляд, решением станет гибридное облако. Частный ЦОД и публичный сервис – страховка друг друга для снижения рисков.
Опубликовано 06.07.2022
