Перенос данных из одного облачного хранилища в другое – сродни переезду. Для того чтобы он не стал пожаром, нужно подготовиться: оценить ваши потребности, возможности разных хранилищ и их ограничения. Вместе с DevOps-командой SimbirSoft рассмотрим несколько популярных сервисов, которые имеют дата-центры на территории страны – Yandex Cloud, VK Cloud Solutions, SberCloud – и разберем первые шаги по переезду. Статья может быть полезна тем, кто ищет площадку для переноса данных из другого облака или традиционной инфраструктуры.
Для хранения данных в облаке многие компании ищут альтернативу Amazon Web Services, Google Cloud, Microsoft Azure. Услуги, которые они предоставляли ранее: облачное хранение данных и вычисления на собственных серверах – востребованы как крупными, так и малыми компаниями. Как правило, цены относительно доступны и есть возможность быстро масштабировать бизнес, экономя на покупке собственных серверов. Сравним, какие поставщики могут предложить бизнесу альтернативу.
Для примера рассмотрим проект, использующий следующие компоненты AWS для работы приложения.
Сравним, какую альтернативу предлагают отечественные сервисы.
Далее – подробности. Так как представленные сервисы в той или иной мере выполняют схожие функции, сосредоточимся на описании их особенностей, квот, лимитов, если они есть.
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. Реализация концепции – непосредственный перенос данных.
Главный этап переезда на другую платформу облачного хранилища – сама миграция. К моменту выполнения данного шага вы уже четко знаете ответы на следующие вопросы:
При верном выполнении предыдущих шагов этот этап будет прозрачным и максимально продуктивным.
Пункт 4. Оптимизация данных на «новом месте»
Оптимизация позволяет получить максимальные преимущества от миграции. На данном этапе компания проводит аудит всех перенесенных данных, составляет сравнительную характеристику прошлого и нового сервиса облачного хранения, анализируя слабые и сильные стороны каждого. После этого будет легче сформулировать требования для кастомизации выбранной системы: так вам не «подсунут» ничего лишнего, и вы сможете обозначить необходимые изменения «на берегу».
Очевидно, что процесс переноса данных из одного облачного хранилища в другое требует большой концентрации внимания и времени. Это несложная, но энергоемкая операция. Тщательное планирование, анализ и продуманная система логистики обеспечат процессу наибольшую продуктивность.
Риски
Миграция в новое облако мало чем отличается от реализации любого другого проекта, именно поэтому и у данной операции есть свои риски. Рассмотрим подробнее наиболее распространенные проблемы, сопряженные с переездом: исключить все сложные ситуации невозможно, но подготовиться к ним вполне реально.
Неудачный выбор сервиса облачного хранения данных. Самая распространенная проблема – компания, неправильно оценив предложения на рынке, выбрала провайдера, чьи услуги не отвечают требованиям бизнеса . Советуем максимально подробно проанализировать свои потребности и выбирать сервис облачного хранилища с учетом:
стоимости,
функционала,
подхода к системе хранения и защите данных.
Стоит изучить максимально широкий спектр коммерческих предложений, предварительно пообщаться с потенциальным поставщиком услуг и обсудить наиболее критичные вопросы.
Ограничения доступности ресурсов компании в процессе переноса данных. Любой, даже самый четко организованный процесс миграции, потребует от компании временного отключения серверов. Это неминуемо скажется на работоспособности приложений и потенциально может вызвать проблемы с клиентами. Избежать серьезных последствий можно – базируйтесь на двух ключевых принципах:
скорость и продуктивность (об этом мы уже писали выше при обсуждении этапов миграции);
предварительная работа с клиентами.
Перед началом переноса обязательно сообщите клиентам о возможных проблемах, чтобы они подготовились к временной недоступности вашего продукта и возможным форс-мажорам. Простой может иметь катастрофические последствия для производительности приложений – а значит, и для лояльности клиентов – если не поддерживается надлежащим планом аварийного восстановления.
Обеспечение должного уровня безопасности данных. Заранее уточните у потенциального провайдера:
необходимые сертификаты и лицензии;
стандарты информационной безопасности;
тип оборудования и программного обеспечения.
Учитывайте, что облачные провайдеры предоставляют инструменты и услуги для защиты инфраструктуры, например, сети и вычислительные машины. Компания при этом несет ответственность за такие вещи, как защита сетевого трафика и безопасность приложений.
Недостаточная компетентность кадров. Процесс переноса данных в облачное хранилище требует от специалистов определенных профессиональных компетенций. IT-отдел должен закрывать следующие потребности:
обеспечение скорости загрузки системы и ее доступности;
защита от DDOS-атак;
покрытие тестированием;
проектирование инфраструктуры;
применение DevOps практик в работе;
использование гибких методологий управления проектами.
Если в компании таких компетенций не хватает (подробнее о них рассказывали здесь), как правило, рассматривают подключение внешней техподдержки с тем или иным уровнем SLA.
Подводя итоги
Мы рассмотрели популярные российские сервисы облачного хранилища, этапы миграции и проблемы, наиболее часто возникающие при переезде в облака.
Так как процесс индивидуален для каждой компании, описанные меры носят рекомендательный характер. Тем не менее общий алгоритм помогает заранее продумать все этапы и подготовиться к решению задач переноса данных в облачные платформы.
Надеемся, статья была вам полезна!
25 августа приглашаем вас на круглый стол онлайн «IT-щит для бизнеса: как сделать IT-продукт безопасным». На нем обсудим:
из чего складывается ИТ-безопасность и как ее выстроить;
какие расходы критически важны, а какие второстепенны;
способны ли аудиты безопасности принести реальную пользу.
Ссылка для регистрации: https://s.simbirsoft.com/kmQ1
