Перенос данных из одного облачного хранилища в другое – сродни переезду. Для того чтобы он не стал пожаром, нужно подготовиться: оценить ваши потребности, возможности разных хранилищ и их ограничения. Вместе с DevOps-командой SimbirSoft рассмотрим несколько популярных сервисов, которые имеют дата-центры на территории страны – Yandex Cloud, VK Cloud Solutions, SberCloud – и разберем первые шаги по переезду. Статья может быть полезна тем, кто ищет площадку для переноса данных из другого облака или традиционной инфраструктуры.
![](https://habrastorage.org/getpro/habr/upload_files/79f/485/a9f/79f485a9fde50b14a5e16782d79d1ab7.png)
Для хранения данных в облаке многие компании ищут альтернативу Amazon Web Services, Google Cloud, Microsoft Azure. Услуги, которые они предоставляли ранее: облачное хранение данных и вычисления на собственных серверах – востребованы как крупными, так и малыми компаниями. Как правило, цены относительно доступны и есть возможность быстро масштабировать бизнес, экономя на покупке собственных серверов. Сравним, какие поставщики могут предложить бизнесу альтернативу.
Для примера рассмотрим проект, использующий следующие компоненты AWS для работы приложения.
![](https://habrastorage.org/getpro/habr/upload_files/af7/07d/3f7/af707d3f7c667c79fdf71358f66a8d8b.png)
Сравним, какую альтернативу предлагают отечественные сервисы.
![](https://habrastorage.org/getpro/habr/upload_files/4cb/4ae/745/4cb4ae745dee0bc8a21e0bb6831b2b25.png)
Далее – подробности. Так как представленные сервисы в той или иной мере выполняют схожие функции, сосредоточимся на описании их особенностей, квот, лимитов, если они есть.
Yandex Cloud
Одно из крупнейших облачных хранилищ данных в российской системе, создано и усовершенствовано благодаря технологиям Яндекса. Платформа работает как с частными, так и корпоративными проектами. Одной из ее особенностей является наличие большого количества разнообразных сервисов для распознавания речи и изображений, удаленных хранилищ, балансировщиков сетевой нагрузки, а также сервисов по работе со статистическими данными. На данный момент есть две зоны доступности, в которых можно развернуть приложение. Это обеспечивает отказоустойчивость и значительно снижает вероятность потери данных.
Ссылка на документацию: https://cloud.yandex.ru/docs
Yandex Object Storage. API сервиса совместим с API Amazon S3 интерфейсом. Это позволяет использовать множество инструментов, созданных для работы с объектными хранилищами, к примеру AWS CLI. Есть возможность выбора класса:
«Стандартное хранилище» – для активной работы с объектами;
«Холодное хранилище» – для длительного хранения объектов с редкими запросами на чтение.
Имеет квоты на объем в одном облаке в размере 1Тб и количество бакетов 25шт. Эти ограничения можно изменить по запросу в техническую поддержку.
Yandex Managed Service for Kubernetes позволяет управлять узлами напрямую, а также настраивать кластер Kubernetes с помощью консоли Yandex Cloud, CLI и API Managed Service for Kubernetes. Мастер, управляющий кластером Kubernetes, бывает двух типов:
«Зональный» создается в подсети одной зоны доступности;
«Региональный» создается распределенно – при недоступности одной из зон остается работоспособным.
Важно отметить, что внутренний адрес «регионального» мастера доступен только в пределах одной облачной сети Yandex Virtual Private Cloud.
Yandex Managed Service for PostgreSQL. Позволяет работать с кластерами базы данных PostgreSQL 10, 11, 12, 13, 14 версий и является аналогом Amazon RDS для PostgreSQL. Представляет кластер из одной или нескольких виртуальных машин с развернутыми серверами СУБД. Хосты могут находиться в разных зонах доступности. Их минимальное количество в кластере зависит от выбранного типа хранилища, а вычислительная мощность – от класса хоста.
Yandex Managed Service for Redis как замена Amazon ElastiCache помогает разворачивать и поддерживать кластеры серверов Redis 5 и 6. При их создании доступен выбор типа конфигурации:
burstable с гарантированной долей vCPU 100% – он предназначен для тестовой нагрузки и может содержать только один хост;
high-memory может содержать несколько хостов или шард (от одного до пределов текущей квоты).
Yandex Managed Service for Apache Kafka – поддерживаемый кластер серверов Apache Kafka® версий 2.8 и 3.0. В зависимости от количества хостов-брокеров в нем автоматически настраивается и размещается ZooKeeper:
кластер состоит из одного хоста – ZooKeeper размещается на нем же;
в ином случае – ZooKeeper будет размещен отдельно от брокеров на трех дополнительных хостах, они добавляются в кластер автоматически.
Хосты ZooKeeper нельзя удалить, но можно изменить их параметры с помощью CLI.
Отметим, что это неполный список сервисов, доступных в Yandex Cloud.
VK Cloud Solutions
Далее рассмотрим построение такой же инфраструктуры на платформе VK Cloud Solutions. Облачная бизнес-платформа предлагает разнообразные инструменты для работы с любыми размерами. На данный момент есть две зоны доступности. Компания предоставляет возможность клиентам пользоваться инфраструктурными и платформенными сервисами, экспертной поддержкой, кастомными и частными инсталляциями , а также помогает бизнесу мигрировать в облако.
Ссылка на документацию: https://mcs.mail.ru/docs
В VK Cloud Solutions Storage при создании бакета доступен выбор его типа:
«холодное хранилище»;
«горячее» хранилище»;
backup: подходит для размещения резервных копий автоматических и «ручных» инстансов. Он не подлежит самостоятельному созданию или удалению, а управляется сервисом резервного копирования.
В одном проекте доступно создание не более 25 бакетов. При этом ограничение на объем каждого из них отсутствует, однако количество размещаемых в нем объектов не может быть более миллиарда. Создать бакет можно как в Панели VK CS, так и используя S3 CLI.
В VK Cloud Solutions Containers есть преднастроенные типы сред, которые отличаются параметрами масштабирования и активированными расширениями:
Dev (разработка),
Staging (предрелизная среда),
Production («боевое» или «живое» окружение).
Можно выбрать либо отключить предустановленные аддоны для следующих кластеров:
Мониторинг на базе Prometheus Operator и Grafana;
Docker Registry, хранящий данные images в объектном хранилище VK CS;
Nginx Ingress Controller, для которого дополнительно создается балансировщик нагрузки.
Также есть возможность выбора конфигурации виртуальной машины:
По умолчанию доступны варианты Basic, Standard, Advanced.
Для создания индивидуальных вариантов следует обратиться в техподдержку: стоимость рассчитывается индивидуально для каждого запроса.
VK Cloud Solutions Databases позволяет развернуть в облаке решения на основе MySQL, PostgreSQL, MongoDB, Redis, ClickHouse, Postgres Pro, Tarantool: первые две доступны в single, master-slave и кластерных конфигурациях. После создания базы данных появляется возможность установить расширения, к примеру, мониторинг на основе Prometheus и флаги – они же параметры.
Важно отметить, что Redis на момент написания статьи доступен только в конфигурации single.
VK Cloud Solutions Queues – сервис очередей, доступные типы:
«Стандартный». Сообщение доставляется хотя бы один раз, но иногда – более одной его копии. Также стандартные очереди поддерживают практически неограниченное количество вызовов API, что удобно, когда важна пропускная способность.
«FIFO». При таком варианте сообщение доставляется один раз и остается доступным до тех пор, пока потребитель не обработает и не удалит его. Дубликаты не помещаются в очередь, порядок отправки и получения сообщений строго сохраняется. В качестве срока хранения можно указать значение от 60 секунд до 14 дней (по умолчанию это 5 дней). По достижении квоты сообщения удаляются автоматически.
SberCloud
SberCloud – компания-поставщик облачных услуг. Входит в экосистему «Сбера», работает как с физическими лицами, так и с корпоративными проектами различных компаний. Имеет в арсенале более 50 платформенных сервисов. Состоит из трех зон доступности.
Ссылка на документацию https://docs.sbercloud.ru/
Object Storage. При создании бакета можно выбрать классы «Стандартный», «Редкий доступ» и «Архив». Помимо уровня доступа различается минимальный срок хранения:
для «Стандартного» – минимальный срок хранения не требуется;
для «Редкого доступа» – 30 дней;
для «Архива» – 90 дней.
Последний не поддерживает обработку изображений. При восстановлении данных для класса «Стандартный» плата не взимается, а для остальных вариантов зависит от объема.
В Cloud Container Engine есть квота на количество и емкость ресурсов, к которым мы можем получить доступ. По умолчанию в каждом регионе можно создать не более пяти кластеров, которые содержат не более 50 узлов.
Relational Database Service. На текущий момент доступен выбор на базе таких решений:
MySQL 5.6 и 5.7;
PostgreSQL 9.5, 9.6, 10 ,11, 12,13;
Microsoft SQL Server 2008 R2 EE, 2012 SE, 2012 EE, 2014 SE, 2014 EE, 2016 SE, 2016 EE, 2017 SE, 2017 EE.
Для MySQL и PostgreSQL присутствует поддержка read-реплик и развертывание в режимах Single или Primary/Standby. Кластерная конфигурация доступна только для Microsoft SQL Server. Общее количество инстансов БД не может превышать 50.
Distributed Cache Service for Redis – доступные версии и их особенности:
для версии Redis 3.0 доступен вариант прокси-кластера, каждый экземпляр которого состоит из балансировщиков нагрузки, прокси-серверов, менеджеров кластеров и сегментов;
для версий Redis 4.0 и 5.0 доступен вариант работы в кластерном режиме.
В Distributed Message Service for Kafka на выбор есть две версии: Kafka 1.1.0 и 2.3.0. Важно отметить, что количество брокеров зависит от базовых ресурсов, они различаются от региона к региону. Количество тем (topics) не ограничено, но существует верхний предел совокупного количества разделов (partitions) в них. Когда лимит достигнут, темы создать не получится
Для каждого из представленных провайдеров доступно управление инфраструктурой с помощью Terraform, а также активация компонента DDoS Protection. Он позволит эффективно бороться с атаками, направленными на исчерпание емкости канала и вычислительных ресурсов. При этом если нужный вам сервис отсутствует, его аналог можно создать на базе виртуальной машины: например, Yandex Compute Cloud для Yandex Cloud.
На этом мы закончим краткий обзор российских предложений. Следующий раздел посвятим тому, на что следует обратить внимание при переезде в родные облака и переносе данных.
С чего начать переезд
Цель переноса данных – не потерять важную информацию и на новом месте создать структурированную систему ее хранения и обработки. Опираясь на нашу практику, мы рекомендуем владельцам продуктов пошаговую инструкцию, которая поможет начать этот процесс. Последовательное выполнение описанных действий – залог успешного переезда.
Пункт 1. Анализ данных и инфраструктуры. Составление плана переноса данных
Для оптимизации процесса переноса:
Проанализируйте все хранящиеся в облаках данные и приложения, выделяя наиболее важные из них;
Проведите полный аудит имеющейся у вас интеллектуальной собственности.
Так вы сможете определить объемы миграции, а следовательно, сроки, риски и потенциальные затраты. Также поймете, насколько ваши данные адаптированы к переносу и какие компоненты требуют реинжиниринга.
Самый главный момент, на который стоит обратить внимание – не стремитесь перенести в облако все и сразу. Для облачного хранения данных больше подходят стандартные бизнес-приложения. А вот уникальные решения, основанные на интеллектуальной собственности компании и являющиеся ключевым фактором преимущества перед конкурентами, лучше хранить там, где можно полностью их контролировать – в собственной инфраструктуре.
Следующим шагом мы советуем определить инструменты и подходящее время для выполнения переноса. Желательно провести тестовый перенос данных – своеобразную пробную попытку.
Пункт 2. Выбор оптимального сервиса облачного хранилища данных.
Выше мы представили краткий обзор самых популярных российских предложений. Исходя из своих потребностей и возможностей сервисов облачного хранения, компания выбирает вариант, подходящий именно ей.
Пункт 3. Реализация концепции – непосредственный перенос данных.
Главный этап переезда на другую платформу облачного хранилища – сама миграция. К моменту выполнения данного шага вы уже четко знаете ответы на следующие вопросы:
![](https://habrastorage.org/getpro/habr/upload_files/db2/2cc/89c/db22cc89cb0f7655ae0dffce5e4b2160.png)
При верном выполнении предыдущих шагов этот этап будет прозрачным и максимально продуктивным.
Пункт 4. Оптимизация данных на «новом месте»
Оптимизация позволяет получить максимальные преимущества от миграции. На данном этапе компания проводит аудит всех перенесенных данных, составляет сравнительную характеристику прошлого и нового сервиса облачного хранения, анализируя слабые и сильные стороны каждого. После этого будет легче сформулировать требования для кастомизации выбранной системы: так вам не «подсунут» ничего лишнего, и вы сможете обозначить необходимые изменения «на берегу».
Очевидно, что процесс переноса данных из одного облачного хранилища в другое требует большой концентрации внимания и времени. Это несложная, но энергоемкая операция. Тщательное планирование, анализ и продуманная система логистики обеспечат процессу наибольшую продуктивность.
Риски
Миграция в новое облако мало чем отличается от реализации любого другого проекта, именно поэтому и у данной операции есть свои риски. Рассмотрим подробнее наиболее распространенные проблемы, сопряженные с переездом: исключить все сложные ситуации невозможно, но подготовиться к ним вполне реально.
-
Неудачный выбор сервиса облачного хранения данных. Самая распространенная проблема – компания, неправильно оценив предложения на рынке, выбрала провайдера, чьи услуги не отвечают требованиям бизнеса . Советуем максимально подробно проанализировать свои потребности и выбирать сервис облачного хранилища с учетом:
стоимости,
функционала,
подхода к системе хранения и защите данных.
Стоит изучить максимально широкий спектр коммерческих предложений, предварительно пообщаться с потенциальным поставщиком услуг и обсудить наиболее критичные вопросы.
-
Ограничения доступности ресурсов компании в процессе переноса данных. Любой, даже самый четко организованный процесс миграции, потребует от компании временного отключения серверов. Это неминуемо скажется на работоспособности приложений и потенциально может вызвать проблемы с клиентами. Избежать серьезных последствий можно – базируйтесь на двух ключевых принципах:
скорость и продуктивность (об этом мы уже писали выше при обсуждении этапов миграции);
предварительная работа с клиентами.
Перед началом переноса обязательно сообщите клиентам о возможных проблемах, чтобы они подготовились к временной недоступности вашего продукта и возможным форс-мажорам. Простой может иметь катастрофические последствия для производительности приложений – а значит, и для лояльности клиентов – если не поддерживается надлежащим планом аварийного восстановления.
-
Обеспечение должного уровня безопасности данных. Заранее уточните у потенциального провайдера:
необходимые сертификаты и лицензии;
стандарты информационной безопасности;
тип оборудования и программного обеспечения.
Учитывайте, что облачные провайдеры предоставляют инструменты и услуги для защиты инфраструктуры, например, сети и вычислительные машины. Компания при этом несет ответственность за такие вещи, как защита сетевого трафика и безопасность приложений.
-
Недостаточная компетентность кадров. Процесс переноса данных в облачное хранилище требует от специалистов определенных профессиональных компетенций. IT-отдел должен закрывать следующие потребности:
обеспечение скорости загрузки системы и ее доступности;
защита от DDOS-атак;
покрытие тестированием;
проектирование инфраструктуры;
применение DevOps практик в работе;
использование гибких методологий управления проектами.
Если в компании таких компетенций не хватает (подробнее о них рассказывали здесь), как правило, рассматривают подключение внешней техподдержки с тем или иным уровнем SLA.
Подводя итоги
Мы рассмотрели популярные российские сервисы облачного хранилища, этапы миграции и проблемы, наиболее часто возникающие при переезде в облака.
Так как процесс индивидуален для каждой компании, описанные меры носят рекомендательный характер. Тем не менее общий алгоритм помогает заранее продумать все этапы и подготовиться к решению задач переноса данных в облачные платформы.
Надеемся, статья была вам полезна!
25 августа приглашаем вас на круглый стол онлайн «IT-щит для бизнеса: как сделать IT-продукт безопасным». На нем обсудим:
из чего складывается ИТ-безопасность и как ее выстроить;
какие расходы критически важны, а какие второстепенны;
способны ли аудиты безопасности принести реальную пользу.
Ссылка для регистрации: https://s.simbirsoft.com/kmQ1
Комментарии (4)
dimitrii_z
30.07.2022 11:21В статье ожидал увидеть практическое сравнение хотя бы 3 сервисов, а по факту - просто краткое перечисление из инета с некликабельными ссылками на документации.
Работали с Яндекс, выделенные серверы с поминутной тарификацией работы, на базе линукс. Очень удобно, цены нормальные, проблем с работой не выявлено во всяком случае за те пару сотен часов что использовали.
ermouth
Ни слова о SLA, а напрасно. Амазон S3 например компенсирует 100% стоимости услуги, если не обеспечивает 95% аптайм. Сравним:
Яндекс: 100% компенсации будет при 100% простое, причём Яндекс может останавливать свою инфраструктуру на ремонт – и в таком случае клиенту вообще ничего не положено, если ремонт до 8 часов в месяц.
Сбер: 100% не будет никогда, максимум 20% даже при полном простое. Как и у Яндекса, ремонт и прочее обслуживание (то-есть простой) не компенсируется. В отличие от Яндекса, верхнего предела нет.
Итого: СберКлауд – просто лавочка с большим рекламным бюджетом, не готовая вообще отвечать за свою работу. Яндекс – в 20 раз менее надёжен чем Амазон, как минимум судя по ответственности, которую они готовы нести.
До AWS обоим как до звёзд.
CherryPah
Спорить не буду, но в ситуации когда у меня лежит прод, вопрос по какому тарифу вернут мне средства, по 3 или 4 рубля за гигабайт - не самый насущный )
Особенно если это будет связано с потерей данных
ermouth
Это верно, но... Компания, не готовая отвечать за непредоставление услуг, всё же менее надёжна, а статья про критерии выбора.
Я заморачивался переездом в российские облака в первых числах марта, и был очень неприятно удивлён эрэфными SLA.