Cloud storage

Jacky Parker Photography / Getty Images

Компания Robin, автор одноименного cloud-native решения для управления данными и приложениями корпоративных клиентов, например USAA, Sabre, SAP, Palo Alto Networks и Rakuten Mobile, сегодня рассказала о запуске новой бесплатной версии своего сервиса, в дополнение к крупному обновлению основного инструментария.

Robin.io обещает возможность cloud-native управления данными для контейнеризированных приложений с поддержкой типовых операций, например, резервное копирование и восстановление, снимки, возможность откатов и многое другое. Компания обеспечивает работоспособность на уровне железа, а также поддерживает основных поставщиков облачных услуг. Сервис не зависит от используемой базы данных, поддерживает PostgreSQL, MySQL, MongoDB, Redis, MariaDB, Cassandra, Elasticsearch и прочие.

Robin Cloud Native Storage работает с любыми нагрузками на любых платформах, основанных на Kubernetes, а также в любом облаке. Наша платформа с возможностями хранения, создания снимков, клонирования, миграции и обеспечения безопасности данных все они работают с простейшими командами предлагает командам разработчиков и DevOps-командам суперпростой, но высокопроизводительный инструмент для быстрого развертывания и управления вашими корпоративными нагрузками в Kubernetes.
Основатель и генеральный директор Robin, Partha Seetala.

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

Если говорить о корпоративных планах, то компания сегодня заявила, что она смещает фокус на цены, формируемые по потреблению, начиная с 0.42$ за узло-час (также предлагаются и годовые подписки). Корпоративный план включает поддержку 24x7 и не ограничивает число узлов и емкость хранилища.

Среди новых функций основного сервиса хранения Robin поддержка управления данными для Helm Charts, возможность указания точного местоположения данных (в основном это нужно для того, чтобы они находились как можно ближе к вычислительным ресурсам) и политики связывания, подразумевающей доступность для stateful приложений, зависящих от распределенных баз данных и платформ данных.

LogiMap ASRS Unit by Vidom

Veeam Backup & Replication коммерческая платформа для резервного копирования и управления данными облачной, виртуальной и физической среды. Она поддерживает разные сценарии хранения данных, в том числе использование S3-совместимых объектных хранилищ для хранения бэкапов, об одном из которых они сами недавно писали: про подключение к хранилищу MinIo.

Между тем, есть смысл использовать S3 в виде готового облачного сервиса, когда вы не хотите сами заниматься вопросами обслуживания и масштабирования хранилища. Сервис-провайдер даёт дополнительные функциональности (надёжность, безопасность и так далее) по стоимости ниже, чем большинство собственных инсталляций, за счёт массовости предоставления услуги.

Я покажу подключение Veeam к облачному объектному S3-хранилищу на примере Mail.ru Cloud Storage. Потому что я из этой команды :) Так что буду рад обратной связи по этому сценарию и самому сервису в комментариях.

Выбор в сторону объектного хранилища S3 в качестве хранилища бэкапов был вполне очевидным, так как:

1. Стандарт де-факто.
2. Многие производители уже реализовали в своих системах резервного копирования поддержку S3.
3. Надежность.
4. Низкая стоимость.

Тестовый стенд

Тестовый стенд:

1. Виртуальная машина с Windows (установлена Windows-Server-2019Std-ru.202006) для установки Veeam.
2. Виртуальная машина с Ubuntu 20.04 в качестве инстанса для бэкапа.
3. Настроенный доступ и бакет в хранилище MCS S3.

Установку Veeam опустим, она хорошо описана в официальной документации. Я использовал для установки версию Veeam Backup & Replication Community Edition, с выписанной пробной лицензией на месяц. Community Edition не поддерживает создание Scale-Out Backup Repository.

Далее перейдем к настройке.

Подключение Object Storage

1. Нажмите на Backup Repositories, далее правой кнопкой мыши вызовите Add Backup Repository:
   
   
   
2. Выберите Object Storage:
   
   
   
3. Выберите S3 Compatible:
   
   
   
4. Введите имя хранилища и нажмите Next:
   
   
   
5. В качестве Service point введите hb.bizmrg.com, регион default. Напротив Credentials нажмите Add:
   
   
   
6. Введите свой Access Key ID и Secret Access Key для доступа к S3 MCS, нажмите OK:
   
   
   
7. Выберите бакет и нажмите Browse напротив Folder для выбора папки, где в бакете будут храниться бэкапы:
   
   
   
8. Выберите существующую папку или создайте новую и нажмите ОК:
   
   
   
9. Если необходимо установить лимит места, которое могут занимать бэкапы, поставьте галочку Limit object storage consumption и установите лимит. Галочку immutable не ставьте, MCS S3 пока не поддерживает эту функцию. Нажмите Next:
   
   
   
10. Создание объектного стораджа завершено:
    
    
    

Подключение Scale Out Backup Repository (SOBR)

Логика работы Veeam такова, что использовать напрямую объектное хранилище S3 нельзя, необходимо собрать расширяемое хранилище, состоящее из локального репозитория бэкапов и хранилища S3, куда будут переноситься бэкапы из локального хранилища, в соответствии с настроенной политикой переноса. Обратите внимание, что SOBR-хранилище недоступно в Community-версии приложения, необходима лицензия.

1. Выберите в левой колонке Scale-Out Repositories и нажмите в поле справа правую кнопку мыши. Выберите Add scale-out backup repository:
   
   
   
2. Введите имя репозитория и нажмите Next:
   
   
   
3. Нажмите Add и добавьте локальное хранилище:
   
   
   
4. Выберите политику размещения бэкапов либо хранение полных и инкрементальных бэкапов вместе, либо разнесение их по хранилищам. Нажмите Next:
   
   
   
5. Поставьте галочку Extend scale-out backup repository capacity with object storage и добавьте созданное ранее объектное хранилище. Ниже настраивается политика работы как видно на скриншоте, у нас настроено сразу же переносить вновь созданные бэкапы в S3, а также переносить уже существующие бэкапы старше 7 дней. Нажмите Apply:
   
   
   
6. SOBR-хранилище успешно создано:
   
   
   

Настройка бэкапа Linux-сервера

Настроим бэкап тестового сервера Linux. Для бэкапа Veeam должен установить свой агент на Linux-сервер.

1. Добавим данные сервера Linux, который мы хотим бекапить. Нажмите в нижнем левом углу экрана на Home, в верхнем левом углу на Backup Job и выберите Linux computer:
   
   
   
2. Выберите Server и Managed by backup server. Настраивать задания можно как централизованно, так и на серверах, которые мы хотим бэкапить, в настройках Veeam-агента. В данном случае настроим управление со стороны сервера Veeam:
   
   
   
3. Выберите название нового задания и нажмите Next:
   
   
   
4. Нажмите на Add и выберите Individual computer:
   
   
   
5. Введите имя или IP-адрес Linux-сервера, который будем бэкапить, напротив Credentials нажмите Add. В выпадающем меню выберите тип авторизации по паролю или по ключу. В нашем случае по ключу:
   
   
   
6. Введите имя пользователя, выберите на диске предварительно сохраненный файл с приватным ключом к серверу. Приватный ключ формируется при заказе инстанса в панели управления MCS. Установите галочку Elevate account privileges automatically, нажмите OK:
   
   
   
7. Выберите, что бэкапить в данном случае весь сервер. Нажмите Next:
   
   
   
8. Выберите хранилище, куда будут помещены бэкапы. В нашем случае настроенное ранее Scale-Out Backup Repository. Нажмите Next:
   
   
   
9. Настройте расписание запуска и нажмите Apply:
   
   
   
10. Если необходим немедленный запуск задания, установите галочку Run the job when I click Finish. Нажмите Finish:
    
    
    

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

Прогресс бэкапа можно увидеть, если нажать на Last 24 Hours/Running и выбрать созданное нами бэкап-задание Ubuntu1:



После окончания бэкапа в web-интерфейсе S3 MCS можно увидеть, что Veeam создал папку с бэкапом сервера:



На этом настройка закончена, удачи!

В нашем телеграм-канале новости об этом и других сервисах на облачной платформе Mail.ru Cloud Solutions.

Еще про использование S3-хранилища:

• Работа с объектным S3-хранилищем как с файловой системой.
• Пример event-driven приложения на основе вебхуков в объектном S3-хранилище.
• На пальцах о том, как объектные хранилища используют в разных отраслях.
• Архитектура S3: 3 года эволюции Mail.ru Cloud Storage.

Flying Fortress by Nele-Diel

Команда объектного S3-хранилища Mail.ru Cloud Storage перевела статью о том, какие критерии важны при выборе объектного хранилища. Далее текст от лица автора.

Когда заходит речь об объектном хранилище, как правило, люди думают только об одной характеристике цене за ТБ/ГБ. Конечно, эта метрика важна, но она делает подход однобоким и приравнивает объектное хранилище к инструменту для хранения архивов. Плюс такой подход уменьшает важность объектного хранилища для технологического стека предприятия.

Выбирая объектное хранилище, стоит обращать внимание на пять характеристик:

• производительность;
• масштабируемость;
• совместимость с S3;
• реакция на сбои;
• целостность.

Эти пять характеристик новые метрики объектного хранилища, наравне со стоимостью. Рассмотрим их все.

Производительность

Традиционные объектные хранилища не отличаются производительностью. Поставщики услуг постоянно жертвовали ей в погоне за низкими ценами. Однако с современными объектными хранилищами всё иначе.

Скорость различных хранилищ приближается к Hadoop или даже превосходит ее. Современные требования к скорости чтения и записи: от 10 ГБ/с для жестких дисков, до 35 ГБ/с для NVMe.

Такой пропускной способности достаточно для Spark, Presto, Tensorflow, Teradata, Vertica, Splunk и других современных вычислительных фреймворков в стеке аналитики. Тот факт, что MPP-базы данных настраивают на объектные хранилища, говорит о том, что оно всё чаще используется как основное хранилище.

Если ваша система хранения не обеспечивает нужную скорость, вы не можете использовать данные и извлекать из них значения. Даже если вы извлекаете данные из объектного хранилища в структуру обработки в памяти, всё равно потребуется пропускная способность для передачи данных в память и из нее. У устаревших объектных хранилищ ее недостаточно.

Это ключевой момент: новый показатель производительности пропускная способность, а не задержка. Она требуется для масштабируемых данных, и это норма в современной инфраструктуре данных.

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

Масштабируемость

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

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

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

У мультиклиентности множество характеристик. Хотя параметр говорит о том, как организации предоставляют доступ к данным и приложениям, он также относится и к самим приложениям, и к логике их изоляции друг от друга.

Характеристики современного подхода к мультиклиентности:

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

Совместимость с S3

Amazon S3 API фактически стандарт для объектных хранилищ. Каждый поставщик ПО для объектного хранилища заявляет о совместимости с ним. Совместимость с S3 двоичная: либо она реализована в полном объеме, либо ее нет.

На практике возможны сотни и тысячи пограничных сценариев, когда при использовании объектного хранилища что-то идет не так. Особенно у поставщиков проприетарного ПО и услуг. Его основные сценарии использования прямое архивирование или резервное копирование, поэтому причин для вызова API немного, варианты использования однородны.

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

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

Открытый исходный код означает: приложения не привязаны к поставщику и более прозрачны. Это обеспечивает долгий жизненный цикл приложения.

И еще несколько замечаний насчет открытого исходного кода и S3.

Если вы запускаете приложение для работы с большими данными, S3 SELECT на порядок повышает производительность и эффективность. Это происходит за счет использования SQL для извлечения из хранилища только тех объектов, которые вам необходимы.

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

Наконец, реализация S3 должна поддерживать Amazon S3 API-интерфейсы шифрования на стороне сервера: SSE-C, SSE-S3, SSE-KMS. Еще лучше, если S3 поддерживает защиту от несанкционированного доступа, которая действительно безопасна.

Реакция на сбои

Показатель, который, вероятно, часто упускают из виду, то, как система обрабатывает сбои. Неудачи случаются по разным причинам, и объектное хранилище должно обрабатывать их все.

Например, есть единственная точка отказа, метрика этого равна нулю.

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

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

Встроенная защита от стирания и деградации данных гарантирует: вы можете потерять столько дисков или узлов, сколько у вас есть блоков четности обычно это половина дисков. И только тогда ПО не сможет возвращать данные.

Отказ редко проверяется под нагрузкой, но такая проверка обязательна. Моделирование сбоя под нагрузкой покажет совокупные затраты, понесенные после сбоя.

Консистентность

Показатель консистентности в 100% также называют строгой консистентностью. Консистентность ключевой компонент любой системы хранения, но строгая консистентность встречается довольно редко. Например, Amazon S3 ListObject не является строго консистентным, он консистентен только в конце.

Что подразумевается под строгой консистентностью? Для всех операций после подтвержденной операции PUT должно выполняться следующее:

• Обновленное значение видно при чтении с любого узла.
• Обновление защищено резервированием от сбоя узла.

Это означает: если выдернуть штекер в середине записи, то ничего не потеряется. Система никогда не возвращает поврежденные или устаревшие данные. Это высокая планка, которая имеет значение для многих сценариев: от транзакционных приложений до резервного копирования и восстановления.

Заключение

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

Об объектном хранилище Mail.ru Cloud Solutions: Архитектура S3. 3 года эволюции Mail.ru Cloud Storage.

Что еще почитать:

1. Пример event-driven приложения на основе вебхуков в объектном S3-хранилище Mail.ru Cloud Solutions.
2. Больше чем Ceph: блочное хранилище облака MCS
3. Работа с объектным S3-хранилищем Mail.ru Cloud Solutions как с файловой системой.
4. Наш канал в Телеграме с новостями об обновлениях S3-хранилища и других продуктов.

На ежегодной конференции NetApp Insight и последовавшей за ней Cloud Field Day 9 (CFD) компания NetApp представила новые продукты и рассказала о стратегии компании на будущее. Кроме прочего, NetApp анонсировала множество новых проектов, связанных с мультиоблачными решениями.

Полноценный переход к Data Fabric

Когда-то компания специализировалась только на решениях, в основе которых была ONTAP собственная операционная система компании для хранилищ данных, таких как NetApp FAS и AFF. Однако несмотря на то, что система действительно хорошо работает, ее невозможно применить ко всем новым продуктам NetApp. Это мешало развитию новых решений.

В 2019 году NetApp рассказала об изменениях в стратегии развития и выпуске новых продуктов на основе Data Fabric (фабрика данных) это единый комплекс из технических и программных компонентов, который помогает организациям управлять данными в гибридных и мультиоблаках, объединять локальную и облачную инфраструктуру. Такие решения упрощают управление большими массивами данных и интеграцию облачных технологий для заказчиков.

Это было стало большим шагом вперед для компании. NetApp начала разрабатывать такие продукты, как объектное хранилище StorageGrid, купила компанию Solidfire, интегрировала различные семейства продуктов, чтобы все работало вместе, и добавила дополнительные инструменты, чтобы упростить жизнь своим клиентам. В конце концов, ONTAP перестала быть единственным ответом на все вопросы, и компания стала двигаться вперед.

Облако, построенное на основе Data Fabric

Концепция Data Fabric и год назад включала облако, но в некоторых аспектах она была неполной. Data Fabric была разработана еще до успеха Kubernetes, а о мультиоблаке и речи не шло.

После Insight и CFD, обновление стратегии кажется завершено. Можно сказать, что NetApp сегодня является одним из наиболее развитых провайдеров на рынке гибридных технологий. Проекты Astra или даже новый VDS (Virtual Desktop Service) используют в основе Data Fabric.

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

Фактически, NetApp позиционирует семейство своих продуктов как основу для беспрепятственного перемещения данных из локальной среды в облако, а затем управления ими с единым пользовательским интерфейсом, независимо от используемых облачных платформ. То есть NetApp предоставляет разнообразные возможности для работы с данными в облаках, расширяя для пользователей свободу выбора.

Компания создает набор интересных решений на основе надежных и согласованных методов управления данными. С определенной точки зрения эта стратегия похожа на стратегию VMware: их стек теперь доступен во всех облаках, а на его основе построены дополнительные решения (например, Disaster-Recovery-as-a-Service или послеаварийное восстановление как услуга, появившийся в результате приобретения Datrium).

Что в итоге

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

Большинство предприятий меняют свое представление об ИТ-инфраструктуре. Гибридные и мультиоблачные решения теперь стали нормой. Пользователи хотят быстро и просто запускать свои приложения там, где этого требует бизнес. Быть просто поставщиком хранилищ уже недостаточно.

Важно отметить, что с этой точки зрения NetApp не одинока (мы уже упоминали VMware). Аналогичной стратегии придерживаются и у других компании, такие как RedHat. Все они хотят создать единый пользовательский интерфейс независимо от того, где клиент развертывает свой бизнес (и данные).

Прогноз

Сможет ли NetApp снова измениться? Будет ли это надежный поставщик облачных услуг и станет ли компания настоящим поставщиком гибридных облачных хранилищ? Компания хорошо справилась с переходом на Data Fabric и находится на правильном пути, чтобы повторить успех. Сравнивая NetApp с некоторыми другими традиционными поставщиками систем хранения, у них действительно хорошие возможности расширить список услуг и закрепится на рынке облачных технологий.

---

Блог ITGLOBAL.COM Managed IT, частные облака, IaaS, услуги ИБ для бизнеса:

• Какой вид облаков выбирают компании сегодня. Российская и зарубежная практика
• Главные тенденции ИТ-индустрии в 2021 году по версии Gartner
• Эволюция ИТ: от локальных серверов до managed services
• Боли стартапов: как правильно развивать ИТ-инфраструктуру

---