Ответ на наш предыдущий пост
Чтобы репатриировать данные из AWS S3, следуйте этим общим рекомендациям:
Обзор требований к данным: определите конкретные сегменты и объекты, которые необходимо репатриировать из AWS S3. Убедитесь, что вы понимаете потребности бизнеса и требования соответствия на каждом этапе.
Определите пункт назначения репатриации. Вы уже решили репатриироваться на MinIO, теперь вы можете запустить MinIO в локальном центре обработки данных, у другого облачного провайдера или в колокейшн-центре. Используя требования из пункта 1, вы выберете оборудование или экземпляры для прогнозируемых потребностей в хранении, передаче и доступности.
Передача данных: спланируйте и выполните передачу данных из AWS S3 в MinIO. Просто используйте встроенную пакетную репликацию MinIO или создайте зеркальное отображение с помощью клиента MinIO (см.
Доступ к данным и разрешения. Убедитесь, что для репатриированных данных установлены соответствующие элементы управления доступом и разрешения для каждого сегмента. Сюда входят политики IAM и сегментов для управления доступом пользователей, аутентификацией и авторизацией для обеспечения безопасности данных.
Блокировки объектов. Крайне важно сохранить политики сохранения блокировки объектов и юридического удержания после миграции. Целевое хранилище объектов должно интерпретировать правила так же, как Amazon S3. Если вы не уверены, спросите
Управление жизненным циклом данных. Определите и внедрите стратегию управления жизненным циклом данных для репатриированных данных. Это включает в себя определение политик хранения, процедур резервного копирования и восстановления, а также методов архивирования данных для каждого сегмента.
Проверка данных: проверка переданных данных на предмет их целостности и полноты. Выполните необходимые проверки и тесты, чтобы убедиться, что данные были успешно переданы без каких-либо повреждений или потерь. После передачи имя объекта, ETag и метаданные, контрольная сумма и количество объектов совпадают между источником и местом назначения.
Обновление приложений и рабочих процессов. Хорошая новость заключается в том, что если вы будете следовать облачным принципам создания своих приложений, все, что вам нужно будет сделать, — это перенастроить их для новой конечной точки MinIO. Однако если ваши приложения и рабочие процессы были разработаны для работы с экосистемой AWS, внесите необходимые обновления для размещения репатриированных данных. Это может включать обновление конфигураций, реконфигурацию интеграции или, в некоторых случаях, изменение кода.
Мониторинг и оптимизация. Постоянно отслеживайте и оптимизируйте среду репатриированных данных, чтобы обеспечить оптимальную производительность, экономическую эффективность и соблюдение передовых методов управления данными.
При составлении бюджета и планировании репатриации облака необходимо учитывать множество факторов. К счастью, наши инженеры проделали это со многими клиентами и разработали для вас подробный план. У нас есть клиенты, которые репатриировали все — от нескольких рабочих нагрузок до сотен петабайт.
Самая большая задача планирования — продумать выбор в отношении сети, выделенной полосы пропускания, серверного оборудования, затрат на архивирование данных, не выбранных для репатриации, а также человеческих затрат на управление и обслуживание собственной облачной инфраструктуры. Оцените эти затраты и спланируйте их. Затраты на репатриацию из облака будут включать плату за исходящие данные для перемещения данных из облака обратно в центр обработки данных. Эти сборы намеренно достаточно высоки, чтобы привести к привязке к облаку. Обратите внимание на эти высокие платы за исходящий трафик — они обосновывают экономический аргумент в пользу выхода из публичного облака, поскольку по мере роста объема данных, которыми вы управляете, плата за исходящий трафик увеличивается. Поэтому, если вы собираетесь репатриироваться, стоит принять меры раньше, чем позже.
Мы собираемся сосредоточиться на данных и метаданных, которые необходимо переместить – это восемьдесят процентов работы, необходимой для репатриации. Метаданные включают свойства и политики корзины (управление доступом на основе доступа/секретного ключа, управление жизненным циклом, шифрование, анонимный публичный доступ, блокировка объектов и управление версиями).
Давайте сейчас сосредоточимся на данных (объектах). Для каждого пространства имен, которое вы хотите перенести, проведите инвентаризацию сегментов и объектов, которые вы хотите переместить. Вероятно, ваша команда DevOps уже знает, в каких сегментах хранятся важные текущие данные. Вы также можете использовать
Пространство имен | Всего сегментов | Общее количество объектов | Общий размер объекта (ГБ) | Общий объем загрузки за день (ТБ) | Общий объем загрузки за день (ТБ) |
---|---|---|---|---|---|
нс-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 дня. |
Рассчитайте плату за исходящие данные на основе приведенной выше суммы. я использую
Общий объем данных, перенесенных на 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, включая
Теперь мы знаем, сколько времени займет миграция такого огромного объема данных и сколько это будет стоить. Примите деловое решение относительно того, какой метод соответствует вашим потребностям, исходя из сочетания сроков и комиссий.
На данный момент мы также знаем требования к оборудованию, необходимому для запуска MinIO локально или в колокейшн-центре. Возьмите приведенное выше требование к 1,5 ПБ хранилища, оцените рост объема данных и проконсультируйтесь с нашим
Первый шаг — воссоздать корзины S3 в MinIO. Вам придется сделать это независимо от того, как вы решите перенести объекты. Хотя и S3, и MinIO хранят объекты с использованием шифрования на стороне сервера, вам не нужно беспокоиться о переносе ключей шифрования. Вы можете подключиться к выбранному вами KMS, используя
У вас есть несколько вариантов копирования объектов: пакетная репликация и mc mirror
. Моя предыдущая запись в блоге,
Обычно клиенты используют написанные нами инструменты в сочетании с оборудованием и услугами миграции данных AWS Snowball или TD SYNNEX для перемещения больших объемов данных (более 1 ПБ).
MinIO недавно заключила партнерское соглашение с Western Digital и TD SYNNEX, чтобы представить альтернативу Snowball. Клиенты могут запланировать периоды приема оборудования Western Digital и оплаты того, что им нужно в течение периода аренды. Что еще более важно, услуга не привязана к конкретному облаку — это означает, что бизнес может использовать ее для перемещения данных в облака, из них и между ними — и все это с использованием повсеместного протокола S3. Дополнительную информацию об услуге можно найти на сайте
Метаданные сегмента, включая политики и свойства сегмента, можно прочитать с помощью get-bucket
Обратите особое внимание на
Обратите особое внимание на управление жизненным циклом данных, такое как сохранение объектов, блокировка объектов и архивирование/многоуровневое хранение. Запустите 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. Это вычислит разницу между сегментами и вернет список только тех объектов, которые отсутствуют или отличаются. Эта команда принимает аргументы исходного и целевого сегментов. Для вашего удобства вы можете создать
mc diff s3/bucket1 minio/bucket1
Хорошая новость заключается в том, что все, что вам нужно сделать, — это указать существующим приложениям новую конечную точку MinIO. Конфигурации можно переписывать приложение за приложением в течение определенного периода времени. Миграция данных в объектном хранилище менее разрушительна, чем в файловой системе: просто измените URL-адрес для чтения/записи из нового кластера. Обратите внимание: если вы ранее использовали сервисы AWS для поддержки своих приложений, они не будут присутствовать в вашем центре обработки данных, поэтому вам придется заменить их эквивалентом с открытым исходным кодом и переписать некоторый код. Например, Athena можно заменить на Spark SQL, Apache Hive и Presto, Kinesis на Apache Kafka и AWS Glue на Apache Airflow.
Если ваша миграция S3 является частью более масштабных усилий по перемещению всего приложения на локальную территорию, то, скорее всего, вы уже использовали
Теперь, когда вы завершили репатриацию, пришло время обратить внимание на работу хранилища, мониторинг и оптимизацию. Хорошей новостью является то, что для MinIO не требуется никакой оптимизации: мы встроили оптимизацию прямо в программное обеспечение, чтобы вы знали, что получаете максимальную производительность для своего оборудования. Вам необходимо начать мониторинг вашего нового кластера MinIO, чтобы на постоянной основе оценивать использование ресурсов и производительность. MinIO раскрывает
С
Ни для кого не секрет, что времена выписывания пустых чеков облачным провайдерам прошли. Многие компании в настоящее время оценивают свои расходы на облако, чтобы найти потенциальную экономию. Теперь у вас есть все необходимое, чтобы начать миграцию с AWS S3 на MinIO, включая конкретные технические шаги и финансовую основу.
Если вас волнует перспектива экономии затрат на репатриацию, свяжитесь с нами по адресу:
Также появляется здесь .