Уже, наверное, только ленивый не повторил десять раз, что ковид послужил катализатором взрывного роста как самих облаков, так и разного рода облачных сервисов. Словом, всё, что как-то относится к облачной теме, стало резко расти и увеличиваться в объёмах. Причина банальная: всех разогнали по домам, и для многих возросшие нагрузки на их сервисы послужили тем самым громом, после которого надо перекреститься и начинать уже что-то делать. Вот все и начали срочно мигрировать. У кого-то процесс перехода прошёл гладко, у кого-то не очень, однако все мы как-то научились жить в новой реальности и теперь, когда вау-эффект прошёл, многие компании стали переключаться с чисто инфраструктурных вопросов на вопрос сохранности данных. Когда твои сервера у тебя под боком, ты сам себе хозяин и молодец. А что делать, когда твои продукты крутятся не пойми где? Довериться надежности облака? Бекапить облачные сервисы другими сервисами этого же облака? Бекапить из облака на землю? Бекапить одно облако в другое? Вопрос важный, ответ не ясен, давайте разбираться.
Для начала повторим банальное, но важное утверждение: облака - не серебряная пуля и не ответ на главный вопрос жизни, Вселенной и всего такого. Облако - это просто элемент инфраструктуры, который позволяет вам решать возникшие у вас задачи. И если сами облака работают уже достаточно стабильно и предсказуемо, то на идеологическом уровне всё ещё имеются проблемы. И основная заключена в том, что, начав использовать облако, вы получаете как бы две инфраструктуры: классическую и облачную. То есть каждая управляется своими инструментами и из разных мест, хотя всё IT сообщество последние годы стремится исключительно к унификации. Значит облако должно быть не обособленным куском инфраструктуры, а просто одной из её частей и не требовать к себе внимания больше, чем все остальные.
Лет 10-12 назад все боялись виртуализации и смотрели на неё исключительно как на диковинку заморскую. А знаете, какими были первые внедрения виртуальных машин? Исключительно в качестве DR (disaster recovery) площадок. То есть технология новая, чего от неё ждать - непонятно, и перевозить туда продакшн боязно. Поэтому мы её пока будем изучать в лабораторных условиях, а на случай аварии пусть стоит в углу готовая к бою копия инфраструктуры. Потом могла или авария случиться, или просто IT отдел набирался смелости и начинал мигрировать часть сервисов. Причины тут не важны, тут интересны последствия: после миграции на виртуалки всё продолжало работать не хуже, чем до этого. Только вот оперировать этим становилось на порядок удобнее. Затем неизбежно вставал вопрос: “Ок, виртуализация - это здорово и удобно, но как нам переехать обратно?”. А обратно было уже не переехать. Во всяком случае не настолько просто, как при переходе на виртуалки. Да и сами люди уже не хотели возвращаться к старой модели, ибо новая на практике доказала свою эффективность и удобство.
И с облаками (особенно IaaS) сейчас происходит ровно тот же сценарий: мы их боимся > давайте потестируем и организуем облачную DR площадку > частично перевозим прод > оказывается, оно работает и это удобно > обратно вернуться сложно, да и не очень хочется, если честно. Всё это и привело к взрывному росту популярности. Даже в самой далёкой от IT компании если сейчас поднять вопрос о модной нынче цифровой трансформации, мало кто захочет заниматься закупками железа, планированием его размещения и ждать поставки полгода, если задачу можно решить созданием нескольких учёток в AWS/Azure, сидя дома на диване. Плюс многие компании сейчас воочию убедились в необходимости иметь под рукой возможность быстро масштабироваться в любую сторону. И быстрого - это значит здесь и сейчас, а не зависеть от поставщиков и прочих непредсказуемых факторов.
Но по неведомой причине во время всех этих переездов и миграций многие забывают про такую фундаментальную вещь, как вопрос сохранности данных и создание резервных копий. Возможно, даже не забывают, а просто, столкнувшись с полностью новой парадигмой, не находят быстрый ответ, и проблема откладывается в долгий ящик.
Когда у нас был железный сервер, с ним всё было просто и понятно. Когда он превратился в виртуальную машину, сначала было непонятно, но со временем появились приложения для бекапа виртуальных машин - и вот они бекапятся так же, как и обычные сервера. Теперь машина переехала в облако, и в первый момент у нас основной вопрос - не “куда её бекапить”, а “как вообще её бекапить”?
Первое, что приходит в голову - это сделать бекап машины изнутри, как было заведено ещё со времён больших железных серверов. Решение хорошее, но крайне далёкое от оптимального. Ведь в случае авари�� у нас будет образ, для разворачивания которого надо первоначально развернуть машину, не ошибиться с её конфигурацией и надеяться, что со стороны облака не было изменений, из-за которых гостевая ОС не захочет стартовать на новой машине. Потом туда надо залить бекап и развернуть его. И хорошо бы по пути не разориться на платежах за трафик, IO и прочее. Как вариант, мы можем делать бекап только приложений, забирая дамп условной базы данных, но тут мы обрекаем себя на ещё большее количество увлекательных приключений при восстановлении. Да и интеграция всего этого в существующие процессы резервного копирования априори выглядит как нагромождение костылей.
Второй приходящий в голову сценарий - это посмотреть в сторону предлагаемых самим облаком решений. Тут есть два варианта развития событий. В первом варианте облачный провайдер строит своё облако на публичном коробочном решении - VMware Cloud, например. Плюс этого подхода в том, что для таких решений давно есть соответствующие продукты, которые будут работать с предсказуемым результатом. Тот же VMware Cloud - отличный пример таких интеграций, так как есть огромное количество клауд-провайдеров, где прямо заявляется о наличии услуги бекапов машин с помощью Veeam. В результате мы получаем знакомое решение, с понятным результатом и возможностями по интеграции. Звучит неплохо.
Другой вариант - это когда провайдер делает своё облако на закрытом решении. Причём отнесём сюда не только AWS, Azure и т.д., но и провайдеров, построивших своё облако на решениях, требующих тщательной доработки напильником под свои нужды, вроде OpenStack. Обычн�� такие провайдеры предлагают некие встроенные решения, однако при ближайшем рассмотрении они зачастую очень бедны по своему функционалу и накладывают массу ограничений на бекапируемые машины. Даже если посмотреть на AWS, то предлагаемое ими решение не будет претендовать на звание хотя бы хорошего из-за имеющихся ограничений. Например, бекапы автоматически складываются на S3 с последующим переездом в Glacier, без альтернативных путей. Здорово, конечно, но что делать если этот вариант не подходит? А что в это время будет происходить с приложениями внутри виртуалки и насколько они хорошо будут себя чувствовать после рестора? Тут вся проблема в том, что Amazon предлагает именно законченное решение, а не технический инструмент для выстраивания необходимого сервиса. Причина такого поведения проста: сделать и поддерживать гибкий инструмент в разы сложнее, чем законченное решение с парой опций, которое охватит потребности вероятного большинства клиентов. Профильная задача облачного провайдера - это поддержание функционирования облака, а всё остальное идёт по остаточному принципу. Так что инструмент для галочки есть, но решать свои задачи до конца мы им не можем. А про интеграцию с существующими решениями даже заикаться не будем. Её нет и не предвидится.
Так что в этом месте на сцену выскакивают 3rd party решения, использующие предоставляемые облаками API и старающиеся реализовать максимум гибкости в имеющихся условиях. Вроде наших Veeam Backup for Microsoft Azure, for AWS и прочих Office 365. Все они построены на стандартных API, однако позволяют реализовать логику резервного копирования, схожую с той, к которой вы привыкли до облаков, и, что самое важное: прозрачно интегрировать эти процессы в существующую инфраструктуру. Да, там есть свои чисто технические ограничения из-за предоставляемых вендором возможностей, однако с каждым релизом список доступных функций становится всё больше и больше.
И это чистая правда: если верить отзывам клиентов, то возможность интеграции облачных бекапов в общий пайплайн (назовём это так) вашего резервного копирования - это именно то, чего им так недостаёт в наше увлекательное облачное время. То есть раньше у нас весь выбор действий был ограничен возможностью бекапить машину из AWS в S3. И туда же её и восстановить. Получается классическое standalone-решение на минималках. А теперь рассмотрим облачный бекап в качестве равноценного участника всей инфраструктуры. Первым делом хочется скачать бекап из облака и положить его рядом с остальными. Причём скачать не просто в виде набора файлов, а чтобы наше бекапное приложение сохранило возможность полноценного оперирования им. Да, AWS даёт нам околобесплатный Glacier для долгосрочного хранения, однако ждать до нескольких дней для восстановления данных - это даже не смешно. Конечно, несколько дней - это максимальный срок, указанный в договоре, и скорее всего данные будут доступны раньше, но кто захочет добровольно попасть в то меньшинство, которое не “скорее всего”?
Но это пока не самое интересное. Как все мы понимаем, бекапы делаются не ради бекапов, а ради возможности восстановления. И будет странно ожидать от облачного провайдера возможности восстановить его виртуалки в вашу наземную инфраструктуру или, случись что, в другое облако. Однако мы эту возможность даём и позволяем восстанавливать ваши рабочие данные хоть в виде виртуалки в гипервизоре, хоть на обычный железный сервер, хоть перегонять машины из AWS в Azure. Про банальное желание восстановить отдельные файлы из машины или отдельные элементы приложений даже говорить не буду, так как это само собой разумеющийся функционал.
Следующий неочевидный нюанс: контроль расходов. Насколько точно вы сможете спрогнозировать размер счёта за создание и хранение бекапа на S3? Да, записать туда данные будет ничего не стоить, но каждая операция верификации записанных данных уже будет стоить денег. А что с созданием инкрементов, когда данные дописываются с оглядкой на уже хранящиеся (да-да, это снова масса платных операций чтения)? А сколько будет стоить удалить устаревшие точки? Словом, курочка по зёрнышку - и в конце месяца за казавшийся недорогим S3 вам может прийти крайне неприятный счёт. Поэтому при работе с облачными данными надо стараться чётко понимать, сколько будет стоить каждое ваше телодвижение и как можно сохранить максимальное количество денег. Мы в Veeam настолько преисполнились это темой, что разработали собственный калькулятор, позволяющий довольно неплохо предсказывать стоимость хранения ваших бекапов. Да, подобный сервис можно и самому организовать через калькулятор AWS, однако давайте прикинем, сколько надо учесть переменных: стоимость EBS снапшотов, стоимость самого S3 хранилища, стоимость работы воркера (машины, которая занимается созданием бекапов), не забываем про потребление трафика на случай использования разных регионов или желания скачать бекап, и помним про стоимость всех операций внутри S3. Так что не самое очевидное уравнение получается.
Исходя из всего сказанного выше, напрашивается очевидный вывод: сейчас уже не надо искать ответ на вопрос “Как мне бекапить данные в облаке”. Он давно решён, и на рынке есть решения на любой вкус. Однако на чём сейчас стоит сосредоточить своё внимание, так это на поиске ответа на вопрос “Как мне сделать платформу для резервного копирования, чтобы я из единой консоли мог бекапить и восстанавливать свои данные независимо от того, где они находятся и куда мне хочется их восстановить?”. Это и позволит вам рассматривать облако как полноценного участника вашей инфраструктуры, а не в виде обособленного ее элемента.
