Уже, наверное, только ленивый не повторил десять раз, что ковид послужил катализатором взрывного роста как самих облаков, так и разного рода облачных сервисов. Словом, всё, что как-то относится к облачной теме, стало резко расти и увеличиваться в объёмах. Причина банальная: всех разогнали по домам, и для многих возросшие нагрузки на их сервисы послужили тем самым громом, после которого надо перекреститься и начинать уже что-то делать. Вот все и начали срочно мигрировать. У кого-то процесс перехода прошёл гладко, у кого-то не очень, однако все мы как-то научились жить в новой реальности и теперь, когда вау-эффект прошёл, многие компании стали переключаться с чисто инфраструктурных вопросов на вопрос сохранности данных. Когда твои сервера у тебя под боком, ты сам себе хозяин и молодец. А что делать, когда твои продукты крутятся не пойми где? Довериться надежности облака? Бекапить облачные сервисы другими сервисами этого же облака? Бекапить из облака на землю? Бекапить одного облако в другое? Вопрос важный, ответ не ясен, давайте разбираться.
Для начала повторим банальное, но важное утверждение: облака - не серебряная пуля и не ответ на главный вопрос жизни, Вселенной и всего такого. Облако - это просто элемент инфраструктуры, который позволяет вам решать возникшие у вас задачи. И если сами облака работают уже достаточно стабильно и предсказуемо, то на идеологическом уровне всё ещё имеются проблемы. И основная заключена в том, что, начав использовать облако, вы получаете как бы две инфраструктуры: классическую и облачную. То есть каждая управляется своими инструментами и из разных мест, хотя всё 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. Так что не самое очевидное уравнение получается.
Исходя из всего сказанного выше, напрашивается очевидный вывод: сейчас уже не надо искать ответ на вопрос Как мне бекапить данные в облаке. Он давно решён, и на рынке есть решения на любой вкус. Однако на чём сейчас стоит сосредоточить своё внимание, так это на поиске ответа на вопрос Как мне сделать платформу для резервного копирования, чтобы я из единой консоли мог бекапить и восстанавливать свои данные независимо от того, где они находятся и куда мне хочется их восстановить?. Это и позволит вам рассматривать облако как полноценного участника вашей инфраструктуры, а не в виде обособленного ее элемента.
