paint-brush
Все, что вам нужно знать для репатриации с AWS S3 на MinIOк@minio
8,892 чтения
8,892 чтения

Все, что вам нужно знать для репатриации с AWS S3 на MinIO

к MinIO12m2024/03/22
Read on Terminal Reader
Read this story w/o Javascript

Слишком долго; Читать

Давайте углубимся в затраты и экономию, связанные с репатриацией, чтобы вам было легче составить собственный анализ.

People Mentioned

Mention Thumbnail
featured image - Все, что вам нужно знать для репатриации с AWS S3 на MinIO
MinIO HackerNoon profile picture


Ответ на наш предыдущий пост Как репатриироваться с AWS S3 на MinIO , было необычным - мы получили десятки звонков от предприятий с просьбой дать совет по репатриации. Мы объединили эти ответы в этот новый пост, где мы углубимся в затраты и экономию, связанные с репатриацией, чтобы вам было легче составить собственный анализ. Миграция данных является непростой задачей для многих. На практике они направляют новые данные в MinIO и тратят время на миграцию старых данных из облака или оставляют их на месте, не увеличивая их.

Обзор репатриации

Чтобы репатриировать данные из AWS S3, следуйте этим общим рекомендациям:


  1. Обзор требований к данным: определите конкретные сегменты и объекты, которые необходимо репатриировать из AWS S3. Убедитесь, что вы понимаете потребности бизнеса и требования соответствия на каждом этапе.


  2. Определите пункт назначения репатриации. Вы уже решили репатриироваться на MinIO, теперь вы можете запустить MinIO в локальном центре обработки данных, у другого облачного провайдера или в колокейшн-центре. Используя требования из пункта 1, вы выберете оборудование или экземпляры для прогнозируемых потребностей в хранении, передаче и доступности.


  3. Передача данных: спланируйте и выполните передачу данных из AWS S3 в MinIO. Просто используйте встроенную пакетную репликацию MinIO или создайте зеркальное отображение с помощью клиента MinIO (см. Как репатриироваться с AWS S3 на MinIO подробности). Для передачи данных можно использовать несколько дополнительных методов, например использование AWS DataSync, AWS Snowball или Миграция данных TD SYNNEX или напрямую с помощью API AWS.


  4. Доступ к данным и разрешения. Убедитесь, что для репатриированных данных установлены соответствующие элементы управления доступом и разрешения для каждого сегмента. Сюда входят политики IAM и сегментов для управления доступом пользователей, аутентификацией и авторизацией для обеспечения безопасности данных.


  5. Блокировки объектов. Крайне важно сохранить политики сохранения блокировки объектов и юридического удержания после миграции. Целевое хранилище объектов должно интерпретировать правила так же, как Amazon S3. Если вы не уверены, спросите Оценка соответствия Cohasset Associates о реализации целевого хранилища объектов.


  6. Управление жизненным циклом данных. Определите и внедрите стратегию управления жизненным циклом данных для репатриированных данных. Это включает в себя определение политик хранения, процедур резервного копирования и восстановления, а также методов архивирования данных для каждого сегмента.


  7. Проверка данных: проверка переданных данных на предмет их целостности и полноты. Выполните необходимые проверки и тесты, чтобы убедиться, что данные были успешно переданы без каких-либо повреждений или потерь. После передачи имя объекта, ETag и метаданные, контрольная сумма и количество объектов совпадают между источником и местом назначения.


  8. Обновление приложений и рабочих процессов. Хорошая новость заключается в том, что если вы будете следовать облачным принципам создания своих приложений, все, что вам нужно будет сделать, — это перенастроить их для новой конечной точки MinIO. Однако если ваши приложения и рабочие процессы были разработаны для работы с экосистемой AWS, внесите необходимые обновления для размещения репатриированных данных. Это может включать обновление конфигураций, реконфигурацию интеграции или, в некоторых случаях, изменение кода.


  9. Мониторинг и оптимизация. Постоянно отслеживайте и оптимизируйте среду репатриированных данных, чтобы обеспечить оптимальную производительность, экономическую эффективность и соблюдение передовых методов управления данными.

Этапы репатриации

При составлении бюджета и планировании репатриации облака необходимо учитывать множество факторов. К счастью, наши инженеры проделали это со многими клиентами и разработали для вас подробный план. У нас есть клиенты, которые репатриировали все — от нескольких рабочих нагрузок до сотен петабайт.


Самая большая задача планирования — продумать выбор в отношении сети, выделенной полосы пропускания, серверного оборудования, затрат на архивирование данных, не выбранных для репатриации, а также человеческих затрат на управление и обслуживание собственной облачной инфраструктуры. Оцените эти затраты и спланируйте их. Затраты на репатриацию из облака будут включать плату за исходящие данные для перемещения данных из облака обратно в центр обработки данных. Эти сборы намеренно достаточно высоки, чтобы привести к привязке к облаку. Обратите внимание на эти высокие платы за исходящий трафик — они обосновывают экономический аргумент в пользу выхода из публичного облака, поскольку по мере роста объема данных, которыми вы управляете, плата за исходящий трафик увеличивается. Поэтому, если вы собираетесь репатриироваться, стоит принять меры раньше, чем позже.


Мы собираемся сосредоточиться на данных и метаданных, которые необходимо переместить – это восемьдесят процентов работы, необходимой для репатриации. Метаданные включают свойства и политики корзины (управление доступом на основе доступа/секретного ключа, управление жизненным циклом, шифрование, анонимный публичный доступ, блокировка объектов и управление версиями).


Давайте сейчас сосредоточимся на данных (объектах). Для каждого пространства имен, которое вы хотите перенести, проведите инвентаризацию сегментов и объектов, которые вы хотите переместить. Вероятно, ваша команда DevOps уже знает, в каких сегментах хранятся важные текущие данные. Вы также можете использовать Инвентарь Amazon S3 . На высоком уровне это будет выглядеть примерно так:


Пространство имен

Всего сегментов

Общее количество объектов

Общий размер объекта (ГБ)

Общий объем загрузки за день (ТБ)

Общий объем загрузки за день (ТБ)

нс-001

166

47 751 258

980 014,48

50.04

14.80

нс-002

44

24 320 810

615 033,35

23.84

675,81

нс-002

648

88 207 041

601 298,91

328,25

620,93

нс-001

240

68 394 231

128 042,16

62,48

12.45


Следующий шаг — составить список по пространствам имен каждого сегмента и его свойств для каждого сегмента, который вы собираетесь перенести. Обратите внимание на приложения, которые сохраняют и считывают данные в этом сегменте. В зависимости от использования классифицируйте каждый сегмент как данные горячего, теплого или холодного уровня.


В сокращенном варианте это будет выглядеть примерно так


Имя сегмента

Характеристики

Программы)

Горячий/Теплый/Холодный уровень

А

Скопируйте и вставьте JSON сюда

Искра, Айсберг, Дремио

Горячий

Б

Скопируйте и вставьте JSON сюда

Эластичный

Теплый

С

Скопируйте и вставьте JSON сюда

Эластичный (снимки)

Холодный


На этом этапе вам нужно принять некоторые решения по управлению жизненным циклом данных, и вам следует обратить на них пристальное внимание, поскольку это отличный способ сэкономить на комиссиях AWS. Классифицируйте объекты в каждом сегменте как горячие, теплые или холодные в зависимости от того, как часто к ним обращаются. Отличный способ сэкономить деньги — перенести корзины холодного уровня непосредственно в S3 Glacier — нет причин взимать плату за исходящий трафик только для того, чтобы загрузить еще раз.


В зависимости от объема данных, которые вы репатриируете, у вас есть несколько вариантов миграции. Мы рекомендуем загружать новые данные в новый кластер MinIO и работать с ними, одновременно копируя «горячие» и «теплые» данные в новый кластер с течением времени. Количество времени и пропускная способность, необходимые для копирования объектов, конечно, будут зависеть от количества и размера копируемых объектов.


Здесь будет очень полезно подсчитать общий объем данных, которые вы собираетесь репатриировать из AWS S3. Посмотрите на свой инвентарь и посчитайте размер всех ведер, которые классифицируются как горячие и теплые.


Общий объем данных горячего и теплого уровней = 1 534 096,7 ГБ.

Доступная пропускная способность = 10 Гбит/с.

Минимальное необходимое время передачи (общий размер объекта / доступная пропускная способность) = 14,2 дня.


Рассчитайте плату за исходящие данные на основе приведенной выше суммы. я использую список цен , но ваша организация может претендовать на скидку от AWS. Я также использую пропускную способность соединения 10 Гбит/с, но в вашем распоряжении может быть больше или меньше. Наконец, я исходю из предположения, что одна треть данных S3 будет просто перенесена в S3 Glacier Deep Archive.


Общий объем данных, перенесенных на S3 Glacier = 767 048,337 ГБ.

Комиссия за перевод S3 в S3 Glacier (0,05 доллара США за 1000 объектов) = 3773,11 доллара США.

Ежемесячная плата за хранение S3 Glacier Deep Archive = 760 долларов США.


Не забудьте запланировать использование S3 Glacier Deep Archive в будущем.


Общий объем передаваемых данных = 1 534 096,7 ГБ.

Первые 10 ТБ по цене 0,09 доллара США/ГБ = 900 долларов США.

Следующие 40 ТБ по цене 0,085 доллара США/ГБ = 3400 долларов США.

Следующие 100 ТБ по цене 0,07 доллара США/ГБ = 70 000 долларов США.

Дополнительно более 150 ТБ по цене 0,05 доллара США/ГБ = 69 205 долларов США.

Общая плата за выход = 143 504 доллара США.


Для простоты приведенный выше расчет не включает ни плату за операции с объектом (0,40 доллара США/1 миллион долларов США), ни стоимость листинга (5 долларов США/1 миллион долларов США). Для очень крупных проектов репатриации мы также можем сжимать объекты перед отправкой их по сети, что позволяет сэкономить часть затрат на исходящие данные.


Другой вариант — использовать AWS Snowball для передачи объектов. Каждое устройство Snowball имеет емкость 80 ТБ, поэтому мы заранее знаем, что нам понадобится 20 из них для нашей работы по репатриации. В стоимость каждого устройства входят 10 дней использования и 2 дня на доставку. Дополнительные дни доступны по цене 30 долларов США за устройство.


Плата за обслуживание 20 устройств Snowball (300 долларов США за штуку) = 6000 долларов США

Доставка R/T (3–5 дней по цене 400 долларов США за устройство) = 8000 долларов США.

Вывод данных S3 (0,02 доллара США/ГБ) = 30 682 доллара США.

Общая сумма сборов за снежный ком = 38 981,93 доллара США.


AWS взимает с вас стандартную плату за запросы, хранение и передачу данных за чтение и запись в сервисы AWS, включая Амазонка S3 и Служба управления ключами AWS (KMS) . При работе с Классы хранилища Amazon S3 . Для заданий экспорта S3 данные, передаваемые на ваше устройство Snow Family из S3, оплачиваются по стандартным тарифам S3 за такие операции, как LIST, GET и другие. За журналы Amazon CloudWatch Logs, Amazon CloudWatch Metrics и Amazon CloudWatch Events взимаются стандартные тарифы.


Теперь мы знаем, сколько времени займет миграция такого огромного объема данных и сколько это будет стоить. Примите деловое решение относительно того, какой метод соответствует вашим потребностям, исходя из сочетания сроков и комиссий.


На данный момент мы также знаем требования к оборудованию, необходимому для запуска MinIO локально или в колокейшн-центре. Возьмите приведенное выше требование к 1,5 ПБ хранилища, оцените рост объема данных и проконсультируйтесь с нашим Рекомендуемое оборудование и конфигурация страница и Выбор лучшего оборудования для развертывания MinIO .


Первый шаг — воссоздать корзины S3 в MinIO. Вам придется сделать это независимо от того, как вы решите перенести объекты. Хотя и S3, и MinIO хранят объекты с использованием шифрования на стороне сервера, вам не нужно беспокоиться о переносе ключей шифрования. Вы можете подключиться к выбранному вами KMS, используя MinIO KES для управления ключами шифрования . Таким образом, новые ключи будут автоматически генерироваться для вас по мере создания зашифрованных клиентов и сегментов в MinIO.


У вас есть несколько вариантов копирования объектов: пакетная репликация и mc mirror . Моя предыдущая запись в блоге, Как репатриироваться с AWS S3 на MinIO включены подробные инструкции для обоих методов. Вы можете копировать объекты непосредственно из S3 в локальный MinIO или использовать временный кластер MinIO, работающий на EC2, для запроса S3, а затем зеркально отображать его в локальном MinIO.


Обычно клиенты используют написанные нами инструменты в сочетании с оборудованием и услугами миграции данных AWS Snowball или TD SYNNEX для перемещения больших объемов данных (более 1 ПБ).


MinIO недавно заключила партнерское соглашение с Western Digital и TD SYNNEX, чтобы представить альтернативу Snowball. Клиенты могут запланировать периоды приема оборудования Western Digital и оплаты того, что им нужно в течение периода аренды. Что еще более важно, услуга не привязана к конкретному облаку — это означает, что бизнес может использовать ее для перемещения данных в облака, из них и между ними — и все это с использованием повсеместного протокола S3. Дополнительную информацию об услуге можно найти на сайте Служба миграции данных странице на сайте ТД СИННЕКС.


Метаданные сегмента, включая политики и свойства сегмента, можно прочитать с помощью get-bucket Вызовы API S3 а затем настроить в MinIO. Когда вы регистрируетесь в MinIO SUBNET, наши инженеры будут работать с вами над переносом этих настроек из AWS S3: управление доступом на основе ключа доступа/секретного ключа, политики управления жизненным циклом, шифрование, анонимный публичный доступ, неизменяемость и управление версиями. Одно замечание по поводу управления версиями: идентификатор версии AWS обычно не сохраняется при переносе данных, поскольку каждый идентификатор версии является внутренним UUID. В основном это не проблема для клиентов, поскольку объекты обычно вызываются по имени. Однако если требуется идентификатор версии AWS, у нас есть расширение, которое сохранит его в MinIO, и мы поможем вам его включить.


Обратите особое внимание на IAM и политики сегментов . S3 не будет единственной частью инфраструктуры AWS, которую вы оставите позади. У вас будет множество сервисных учетных записей, которые приложения будут использовать при доступе к корзинам S3. Сейчас самое время составить список и проверить все ваши сервисные аккаунты. Затем вы можете решить, следует ли воссоздавать их в своем провайдере удостоверений. Если вы решите автоматизировать, используйте Amazon Cognito для обмена информацией IAM с внешними IDP OpenID Connect и AD/LDAP.


Обратите особое внимание на управление жизненным циклом данных, такое как сохранение объектов, блокировка объектов и архивирование/многоуровневое хранение. Запустите get-bucket-lifecycle-configuration для каждого сегмента, чтобы получить удобочитаемый список правил жизненного цикла в формате JSON. Вы можете легко воссоздать настройки AWS S3 с помощью консоли MinIO или клиента MinIO (mc). Используйте такие команды, как get-object-legal-hold и get-object-lock-configuration чтобы определить объекты, требующие особого режима безопасности и управления.


Раз уж мы заговорили о жизненном цикле, давайте на минутку поговорим о резервном копировании и аварийном восстановлении. Вам нужен дополнительный кластер MinIO для репликации для резервного копирования и аварийного восстановления?


После копирования объектов из AWS S3 в MinIO важно проверить целостность данных. Самый простой способ сделать это — использовать клиент MinIO для запуска mc diff для старых сегментов в S3 и новых сегментов в MinIO. Это вычислит разницу между сегментами и вернет список только тех объектов, которые отсутствуют или отличаются. Эта команда принимает аргументы исходного и целевого сегментов. Для вашего удобства вы можете создать псевдонимы для S3 и MinIO, поэтому вам не придется вводить полные адреса и учетные данные. Например:


 mc diff s3/bucket1 minio/bucket1


Хорошая новость заключается в том, что все, что вам нужно сделать, — это указать существующим приложениям новую конечную точку MinIO. Конфигурации можно переписывать приложение за приложением в течение определенного периода времени. Миграция данных в объектном хранилище менее разрушительна, чем в файловой системе: просто измените URL-адрес для чтения/записи из нового кластера. Обратите внимание: если вы ранее использовали сервисы AWS для поддержки своих приложений, они не будут присутствовать в вашем центре обработки данных, поэтому вам придется заменить их эквивалентом с открытым исходным кодом и переписать некоторый код. Например, Athena можно заменить на Spark SQL, Apache Hive и Presto, Kinesis на Apache Kafka и AWS Glue на Apache Airflow.


Если ваша миграция S3 является частью более масштабных усилий по перемещению всего приложения на локальную территорию, то, скорее всего, вы уже использовали Уведомления о событиях S3 для вызова нижестоящих служб при поступлении новых данных. Если это так, то не бойтесь — MinIO поддерживает уведомление о событии также. Самым простым переходом здесь было бы реализовать собственный веб-перехватчик для получения уведомлений. Однако если вам нужен более надежный и отказоустойчивый пункт назначения, используйте службы обмена сообщениями, такие как Kafka или RabbitMQ. Мы также поддерживаем отправку событий в такие базы данных, как PostgreSQL и MySQL.


Теперь, когда вы завершили репатриацию, пришло время обратить внимание на работу хранилища, мониторинг и оптимизацию. Хорошей новостью является то, что для MinIO не требуется никакой оптимизации: мы встроили оптимизацию прямо в программное обеспечение, чтобы вы знали, что получаете максимальную производительность для своего оборудования. Вам необходимо начать мониторинг вашего нового кластера MinIO, чтобы на постоянной основе оценивать использование ресурсов и производительность. MinIO раскрывает метрики через конечную точку Prometheus, которую вы можете использовать в своем Платформа мониторинга и оповещения по выбору . Подробнее о мониторинге см. Мультиоблачный мониторинг и оповещение с помощью Prometheus и Grafana и Метрики с MinIO с использованием OpenTelemetry, Flask и Prometheus .


С ПОДСЕТЬ , мы поддержим вас, когда дело доходит до Операции второго дня с МинИО. Подписчики получают доступ к встроенным автоматическим инструментам устранения неполадок, позволяющим обеспечить бесперебойную работу кластеров. Они также получают неограниченную поддержку напрямую от инженеров в режиме реального времени через наш портал поддержки. Мы также помогаем вам обезопасить свои инвестиции в объектное хранилище с помощью ежегодного обзора архитектуры.

Перенести и сохранить

Ни для кого не секрет, что времена выписывания пустых чеков облачным провайдерам прошли. Многие компании в настоящее время оценивают свои расходы на облако, чтобы найти потенциальную экономию. Теперь у вас есть все необходимое, чтобы начать миграцию с AWS S3 на MinIO, включая конкретные технические шаги и финансовую основу.


Если вас волнует перспектива экономии затрат на репатриацию, свяжитесь с нами по адресу: привет@min.io .


Также появляется здесь .