[IT-инфраструктура, Хранение данных, Хранилища данных, Облачные сервисы] Как выбрать облачную систему хранения данных, чтобы получить лучшую производительность и оптимизировать стоимость
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Многие компании активно переносят свои данные в облако, обеспечивая тем самым гибкость и масштабируемость своих приложений. Но те, кто впервые пробуют облачные технологии, нередко сталкиваются с проблемой выбора правильного облачного хранилища под конкретную задачу. Какой тип диска подключить? Когда использовать объектное хранилище, а когда файловое? Какие преимущества и недостатки у каждого из них в облаке? Как можно использовать их совместно, чтобы улучшить утилизацию ресурсов?Я Хамзет Шогенов, архитектор облачной платформы Mail.ru Cloud Solutions, расскажу о системах хранения данных, доступных на нашей платформе, подробно остановлюсь на их технических характеристиках и оптимальных вариантах использования.Типы дисков, которые вы можете использовать в облакеДиски в облаке специально предоставляются в том виде, в котором классическим операционным системам «привычнее» с ними работать, то есть они имитируют физические носители информации, такие как HDD и SSD. При подключении к инстансам виртуальных машин такие диски можно использовать как обычное блочное устройство с «сырым» дисковым пространством — блоками, на которые разбивается все дисковое пространство, когда оно размечается под ту или иную файловую систему, чтобы уже на размеченном пространстве размещать данные операционных систем и приложений.Но так как это все-таки виртуальные диски, для них доступны дополнительные возможности, например создание снимков состояния и шаблонов для новых дисков на их основе, смена типов дисков «на лету» и так далее. Эта функциональность была бы невозможна, если бы вы имели дело с физическим оборудованием, либо возможна, но за счет неоправданно высокой стоимости.Особенности облачных (блочных) дисков:
- Есть определенная гарантированная производительность в единицу времени на единицу объема хранения данных, выражаемая в операциях на диске в секунду (IOPS, пропускная способность).
- Широкий выбор типов дисков. Возможность изменения типа диска «на лету».
- Возможность создания снапшотов и образов (шаблонов) дисков.
- Гибкость управления. При масштабировании диска можно не выключать инстанс, к которому он подключен. Можно создавать и подключать к работающей ВМ новые диски.
- Совместимость. Диски можно рассматривать как локально подключенные накопители. Это позволяет разбивать их, форматировать и управлять ими с помощью знакомых инструментов и методов.
- По сравнению с традиционными физическими носителями при использовании дисков в облаке нет необходимости задумываться о типах RAID, количестве шпинделей и прочем. За обслуживание оборудования и программной части отвечают инженеры облачного провайдера.
Отличия облачных (блочных) дисков от других облачных систем хранения данных:
- Масштабирование производится вручную.
- Уменьшение размера существующего диска недоступно: потребуется пересоздание.
- Доступ возможен из любой зоны доступности (AZ), но ресурс локализован в одной AZ. Размещение диска и виртуальной машины в разных ЦОДах не рекомендуется, хотя это и возможно.
- Непригодны для одновременного доступа при работе как с блочным устройством.
- Наибольшая стоимость среди всех типов облачных хранилищ, если говорить про наиболее производительные типы дисков.
На нашей платформе поддерживаются несколько типов дисков: HDD, SSD, SSD High IOPS и Low Latency NVMe. Вначале рассмотрим характеристики, которые будут общими для всех дисков, затем остановимся более подробно на каждом из них.Примечание. Для каждого типа облачных дисков есть ближайший аналог из мира физических устройств. Но это не означает их полного технического соответствия. Также следует учесть, что бюджет на операции ввода-вывода в секунду для облачных дисков всегда определяется на определенный шаг дискового пространства. Я буду приводить значения SLA для 2 Тб пространства. С полным перечнем SLA для различных типов дисков можно ознакомиться здесь. Общие характеристики для всех типов облачных дисков
- Capacity. Рекомендуемый максимальный размер диска — 2 Тб.
- Масштабирование. Вручную через веб-консоль управления облаком или OpenStack CLI (Command Line Interface). Возможно только увеличение размера диска. Уменьшение недоступно, так как подобная процедура может негативно сказаться на работе файловой системы и целостности данных.
- Доступность. Гарантируется SLA, общий для облака, — 99,95%.
- Бэкапы и восстановление. Для всех дисков поддерживаются снапшоты и резервные копии. Создание снапшотов доступно через консоль управления облаком и OpenStack CLI. Создание бэкапов возможно через встроенный механизм MCS либо с использованием сторонних решений наших партнеров: Acronis и VMware Backup & Replication. Встроенный механизм хорош интеграцией с облачной платформой, сохранением бэкапов в S3, что дешевле, и платой только за хранение данных. Однако в этом случае нет возможности восстановления данных в ту же виртуальную машину и восстановления отдельных файлов.
- Границы доступности. Ресурс локализован в рамках одной зоны доступности (AZ, Availability Zone). Чтобы избежать потенциального снижения производительности работы, при создании диска, подключаемого к существующему инстансу, рекомендуется выбирать зону доступности инстанса.
- Безопасность. Доступ к данным ограничен механизмами изоляции ресурсов (различные Namespace) проекта.
- Механизм расчета стоимости. Цена определяется запрошенным объемом диска. При изменении размера стоимость автоматически пересчитывается.
Диски HDDБазовые диски, самые недорогие и наименее производительные. В традиционной инфраструктуре этому классу хранения соответствуют обычные диски HDD. Чаще всего используются в качестве загрузочных разделов ОС и файловых хранилищ.Характеристики, специфичные для HDDПоказательЗначениеIOPS (количество операций в секунду на 2 Тб пространства)Показатель SLA для чтения — 300–2400, для записи — 150–800. Приложения не всегда могут загрузить диск, это доступно в полной мере только для приложений, которые осуществляют чтение и запись в многопоточном режиме.Throughput (пропускная способность на 2 Тб пространства при размере блока 1М)Показатель SLA для чтения — 250 Мб/с, для записи — 100 Мб/с.Поведение при выходе физического оборудования из строяПроисходит без прерывания обслуживания и потери данных, так как для дисков обеспечивается двойная и тройная репликация данных.Диски SSDСтандартные диски, опережающие HDD по производительности, но обычно более дорогие. По соответствию физическим дискам они существенно быстрее, чем любые HDD, но медленнее SSD, в основном из-за того, что добавляются накладные расходы на сеть и репликацию. Чаще всего используют для хранения СУБД, телеметрии и очередей сообщений.Характеристики, специфичные для SSDПоказательЗначениеIOPS (количество операций в секунду на 2 Тб пространства)Показатель SLA для чтения — 1000–16 000, для записи — 500-8000.Throughput (пропускная способность на 2 Тб пространства, при размере блока 1М)Показатель SLA для чтения и записи — 400 Мб/с.Поведение при выходе физического оборудования из строяПроисходит без прерывания обслуживания и потери данных, так как для дисков обеспечивается тройная репликация данных.Диски High IOPS SSDБыстрые диски, более производительные и дорогие по сравнению с SSD. Соответствуют физическим дискам SSD потребительского класса. Чаще всего используются для хранения файлов в СУБД, аналитике и телеметрии с большими требованиями к производительности, чем у SSD.Характеристики, специфичные для High IOPS SSDПоказательЗначениеIOPS (количество операций в секунду на 2 Тб пространства)Показатель SLA для чтения — 10 000–45 000, для записи — 5000–30 000.Throughput (пропускная способность на 2 Тб пространства, при размере блока 1М)Показатель SLA для чтения и записи 500 Мб/с.Поведение при выходе физического оборудования из строяМожет случиться временная недоступность данных, сами данные не теряются. Необходимо дополнительно позаботиться о реализации отказоустойчивости на уровне приложения (application-aware). С лучшими практиками по созданию отказоустойчивых приложений можно ознакомиться по ссылке.Low Latency NVMeСверхбыстрые диски с минимальными задержками, доступные на высокочастотных конфигурациях ВМ. Самые производительные и дорогие. Этому классу хранения соответствуют физические диски NVMe. Используются там, где важно обеспечить минимальные задержки: высокопроизводительные СУБД, аналитика, кэш.Характеристики, специфичные для Low Latency NVMeПоказательЗначениеIOPS (количество операций в секунду на 2 Тб пространства)Показатель SLA для чтения — 10 000–75 000, для записи 5000-50 000.Throughput (пропускная способность на 2 Тб пространства, при размере блока 1М)Показатель SLA для чтения — 1200 Мб/с, для записи 900 Мб/с.Latency (задержка)SLA — максимум 0,5 мс. Устойчивы к отказу сети, виртуальная машина с такими дисками максимально близка к bare metal.Поведение при выходе физического оборудования из строяНаступает полная недоступность данных, есть риск потери данных. Необходимо дополнительно позаботиться о реализации отказоустойчивости на уровне приложения (application-aware). С лучшими практиками по созданию отказоустойчивых приложений можно ознакомиться по ссылке.Объектные хранилища S3 — еще один тип хранения данных в облакеВ S3 данные хранятся в виде объектов. Объект — это некая совокупность данных с уникальным идентификатором и бесконечным количеством метаданных. Для группировки объектов есть дополнительная сущность — бакеты. Это контейнеры для объектов, похожие на папки, но не являющиеся их полным аналогом. В проекте может быть один или несколько бакетов.Лучше всего S3 подходит для хранения неструктурированных данных и обработки большого количества объектов малого и среднего размера, которые редко изменяются и часто требуют параллельного доступа большого числа пользователей. Для обработки больших объектов доступна дополнительная функциональность — мультипоточная загрузка.S3 может выступать в качестве более надежной и дешевой альтернативы дискам HDD для большей части сценариев их использования.В нашем облаке доступны три класса объектных хранилищ S3, которые различаются по своему назначению и стоимости:
- S3 HotBox предназначен для хранения горячих данных — с частым доступом. В первую очередь это онлайн-сервисы с повышенной нагрузкой, работа которых требует хранения и раздачи контента: потоковая раздача мультимедиа, хостинг статических сайтов, хранилища для Backend-платформ. Могут также использоваться для анализа данных в Big Data, Data Mining и так далее. В HotBox хранение дороже, а исходящий трафик дешевле, входящий трафик не тарифицируется.
- S3 IceBox используют для хранения холодных данных — с редким доступом, например несколько раз в месяц. Чаще всего это годовая и месячная отчетность, документы, бэкапы и журналы, к которым периодически нужен быстрый доступ. По сравнению с HotBox в IceBox хранение дешевле, а исходящий трафик дороже, входящий трафик также не тарифицируется.
- Glacier подходит для хранения ледяных данных — массивных данных (от 100 Тб) с очень редким доступом. Это бэкапы, архивы и логи, к которым доступ может потребоваться несколько раз в год и реже. Из трех типов хранилищ в Glacier самая низкая цена на хранение данных, а весь трафик бесплатный. Такое хранилище подключается по отдельному запросу клиента.
Что хорошего в S3-хранилище:
- Неограниченный объем хранимых данных (петабайты).
- Подходит для неструктурированных данных за счет хранения дополнительной информации (метаданных) рядом с объектами.
- Разграничение доступа за счет ACL и префиксных ключей.
- Возможность одновременного использования большим количеством приложений.
- Стабильная скорость раздачи любых объектов независимо от числа одновременных обращений.
- Автоматическое и виртуально неограниченное масштабирование.
- Возможность настройки Webhooks для автоматической обработки при создании/удалении объектов (например, автообработка фото и видео).
- Возможность настройки жизненного цикла объектов. Например, удаление архивных данных по истечении максимального срока их хранения.
- У S3 нет понятия зоны доступности: это глобальный сервис. Его доступность обеспечивается из пяти ЦОД MCS.
- Наименьшая стоимость среди всех типов облачных хранилищ.
Основное отличие S3-хранилища от других облачных (блочных) систем хранения — блочные хранилища предназначены для использования виртуальными машинами и представляются как диски, а объектное хранилище доступно только по HTTP. Основные особенности S3
- Capacity. Нет ограничений на общий объем — можно хранить петабайты данных. В одном хранилище может быть до 25 бакетов, размер одного бакета произвольный. Число объектов в одном бакете не ограничено — свыше 1 млрд. Для конкретных объектов действуют следующие рейт-лимиты: 32 ГБ для обычного файла, 320 ТБ для multipart.
- IOPS (количество операций в секунду). Действуют следующие рейт-лимиты: для обычных запросов — 500 запросов в секунду, 10 млн запросов в день, для запросов на листинг — 15 запросов в секунду, 10 млн запросов в день.
- Throughput (пропускная способность). Поддерживается скорость передачи объектов 1 Гбит/с. Для быстрой доставки контента хранилище S3 можно интегрировать с сетью доставки контента (CDN, Content Delivery Network), имеющей более 400 точек присутствия во всем мире и емкость канала 1,5 ТБит/с.
- Масштабирование. Размер S3 не ограничен. Масштабирование происходит вверх и вниз автоматически, без дополнительных настроек со стороны пользователя.
- Доступность. Гарантируется SLA, общий для облака — 99,95%. Надежность хранения при этом составляет 99,99999%.
- Поведение при выходе физического оборудования из строя. Происходит без прерывания обслуживания и потери данных.
- Бэкапы и восстановление. Обеспечивается георепликация данных. В разработке функциональность версионирования объектов с возвратом к определенному номеру версии.
- Границы доступности. Возможен доступ из всех зон доступности региона, а также из любого места в интернете с использованием URL объектов.
- Протоколы доступа. S3 API. Главная особенность решения от MCS — полная совместимость с API S3.
- Безопасность. Обеспечивается за счет списков управления доступом (ACL, Access Control Lists) и префиксных ключей. На уровне каждого бакета можно определять, кто может создавать, удалять и перечислять объекты в нем. При организации внешнего доступа вне облака можно использовать HTTPS.
- Механизм расчета стоимости. Оплачивается за фактически использованные ресурсы и рассчитывается посекундно. Тарифный план зависит от типа выбранного хранилища: HotBox, IceBox или Glacier.
Файловые хранилища в облакеФайловое хранилище в облаке представляет собой систему хранения файлов, в которой все данные организованы иерархически в нисходящую сеть папок. На платформе MCS файловое хранилище предоставляется как сервис. С его помощью можно создать удаленную файловую систему, смонтировать ее на виртуальных машинах, а затем читать и записывать данные из инстансов в файловую систему и из нее.Чаще всего файловое хранилище используют в качестве системы хранения документов, общего пользовательского файлового пространства или общего персистентного хранилища данных для узлов кластера Kubernetes.Преимущества файловых хранилищ:
- Есть возможность как увеличения, так и уменьшения размера хранилища.
- Есть возможность создания снапшотов.
- Оптимальный вариант хранения для Legacy-приложений, требующих протокола SMB/NFS.
- Поддерживаются большим количеством классических систем.
Недостатки файловых хранилищ:
- Масштабирование производится вручную.
- Одновременный доступ ограничен полосой пропускания стандартного сетевого интерфейса.
- В настоящий момент для файловых хранилищ нет возможности выбрать другой тип диска, кроме HDD, в будущем появится возможность использовать SSD.
Основные характеристики файловых хранилищ
- Capacity. Рекомендуемый максимальный размер хранилища — 2 Тб. Максимальный размер файла — не больше запрошенного размера хранилища.
- IOPS (количество операций в секунду на 2 Тб пространства). Так как файловое хранилище базируется на дисках HDD, показатель SLA будет тем же: для чтения — 300–2400, для записи — 150–800.
- Throughput (пропускная способность на 2 Тб пространства, при размере блока 1М). Аналогично, как для HDD: для чтения — 250 Мб/с, для записи — 100 Мб/с.
- Масштабирование. Проводится вручную — через web-консоль управления облаком или OpenStack CLI (Command Line Interface). В отличие от облачных дисков возможно как увеличение, так и уменьшение размера файлового хранилища.
- Доступность. Гарантируется SLA, общий для облака, — 99,95%.
- Поведение при выходе физического оборудования из строя. При выходе из строя оборудования, с которого предоставляется дисковое пространство, сервис продолжает предоставляться. Но выход из строя компонентов самого сервиса, конечно, ведет к его прерыванию.
- Бэкапы и восстановление. Возможно создание снапшотов, бэкапирование из веб-консоли недоступно. Механизмы те же, что и для облачных дисков.
- Границы доступности. Доступ осуществим из сетей, которые имеют возможность маршрутизации IP-пакетов с сетью, где размещено файловое хранилище.
- Протоколы доступа. Подключить файловое хранилище к инстансам проекта можно по протоколам CIFS (SMB v3) или NFS.
- Безопасность. Доступ к файловым хранилищам осуществляется только из виртуальных машин внутри проекта (Namespace) MCS. При этом дается возможность настроить правила доступа к хранилищу в зависимости от IP клиента.
- Механизм расчета стоимости. Цена определяется в зависимости от запрошенного при создании объема хранилища. При изменении размера в дальнейшем стоимость автоматически пересчитывается.
Как выбрать облачную систему хранения с учетом потребностей компании: основные критерииПреобладающий тип операций (чтение/запись) и их частота. В первую очередь необходимо оценить, каким образом планируется обращаться к хранимым данным. Объектное хранилище S3 ориентировано на операции WORM. Оно не подойдет для частых модификаций объектов, обладающих большими размерами. Если для таких объектов скорость доступа критична и данные часто модифицируются, следует предпочесть файловые хранилища и, в зависимости от ситуации, облачные диски. Выбор конкретного типа дисков будет зависеть от требуемой производительности.При выборе S3 необходимо дополнительно определить частоту доступа к данным и выбрать соответствующий тип хранилища: HotBox, IceBox или Glacier.Требуемая производительность: IOPS, Throughput, Latency. Для систем, требующих низкой задержки и одновременно высокой пропускной способности, рекомендуется использовать блочное хранилище, оно же виртуальный диск. В объектных хранилищах модифицируемый объект перезаписывается целиком, в отличие от обычных дисков, где изменение всегда происходит на уровне конкретного блока данных. В порядке возрастания производительности диски можно расположить следующим образом: HDD, SSD, SSD High IOPS, Low Latency NVMe. Если требуется обеспечить минимальную задержку, Low Latency NVMe будет лучшим выбором, так как для этого типа диска определено SLA на данный показатель — 0,5 мс.Методы доступа к данным, используемые в классических приложениях (в первую очередь протоколы доступа, так как контроль над интерфейсами напрямую заказчику недоступен). Очень часто при переносе Legacy-приложений клиентов в облако требуется обеспечить конкретные, уже используемые ими протоколы. Конечно, обновление систем возможно, но, как правило, требует дополнительных затрат. В таких случаях выбор облачного хранилища полностью зависит от требований переносимого ПО. Например, файловые хранилища чаще всего выбирают, когда необходимы протоколы SMB/NFS. И это стало в свое время основной причиной того, почему у нас появилось файловое хранилище как сервис.Требования к организации доступа к данным. Доступ к дисковым и файловым хранилищам возможен из разных AZ, но ресурс локализован в одной AZ, то есть при недоступности этой AZ хранилище тоже может стать недоступным. Поэтому для доступа из нескольких зон доступности или из любой точки интернета вне облака S3 будет лучшим выбором.Цена. Среди облачных систем хранения данных минимальная стоимость у S3, она может меняться в зависимости от того, какие данные вы будете хранить. Важное преимущество S3 — необходимость оплаты только фактически используемых ресурсов.Для файловых хранилищ и обычных дисков цена определяется запрошенным объемом ресурсов. При этом цена дисков возрастает по мере увеличения их производительности: HDD, SSD, SSD High IOPS, Low Latency NVMe. Рекомендуем выбирать тот тип диска, который при достаточной для вас производительности будет дешевле всего, так как в дальнейшем при необходимости его можно будет изменить «на лету».Схема выбора оптимальной системы хранения данных с учетом описанных параметров в очень упрощенном виде приведена ниже. Она носит рекомендательный характер. Естественно, в зависимости от ситуации данные рекомендации могут быть и абсолютно нерелевантными, но для общих случаев они чаще всего корректны.
Упрощенная схема выбора облачного хранилищаКак показывает опыт, описанные выше требования во многом определяются типом хранимых данных. Поэтому можно выделить наиболее типичные сценарии использования для каждой системы хранения данных. В таблице ниже показано, как выбрать облачное хранилище в зависимости от того, какие данные планируется размещать.Система хранения данныхТипичные сценарии использованияS3 GlacierМассивные данные (от 100 Тб) с очень редким доступом: бэкапы, архивы, журналы, системные сообщения, логи.S3 IceBoxДанные с редким доступом: архивы корпоративных файлов, годовая/месячная отчетность, документы маленьких рабочих групп, бэкапы, системные сообщения, lоg-файлы. S3 HotBoxПотоковая раздача мультимедиа, хранилища для Backend-платформ, хостинг статических файлов и веб-сайтов, хранение данных для обработки (Big Data, Data Mining). Файловое хранилищеФайловые хранилища, воссоздание схемы Legacy-приложения, общее персистентное хранилище данных для групп контейнеров. HDDФайловые хранилища, загрузочные разделы. SSDСУБД, телеметрия, очереди сообщений, загрузочные разделы. SSD High IOPSСУБД, аналитика, телеметрия. С большими требованиями к производительности, чем у SSD, но меньшими, чем у Low Latency NVMe.Low Latency NVMeВысокопроизводительные СУБД, аналитика, кэш. Расчет необходимой производительности облачной системы хранения при переносе Legacy-приложенийОдин из основных критериев выбора типа облачного хранилища — это требуемая производительность для переносимых в облако Legacy-приложений. Как ее правильнее рассчитать? Предлагаем руководствоваться следующим набором правил:
- Определите критерии успешности прохождения тестирования. Это может быть выполнение операций за заданное количество времени, расходование определенного количества ресурсов на заданный набор данных и так далее.
- Настройте и запустите процесс снятия метрик на исходном сервере:
- количество потребляемых ядер;
- потребляемая частота CPU;
- количество операций ввода/вывода в секунду;
- задержки чтения/записи на дисках;
- эффективность использования ОЗУ.
- Подготовьте синтетические данные для нагрузочного тестирования.
- Создайте тестовый стенд, выделив на нем минимальное достаточное количество ресурсов в соответствии с расчетами. Расчеты стоит осуществлять с учетом фактического потребления ресурсов в часы наиболее высокой нагрузки. Далее, используя показатели из SLA MCS, пересчитать на ресурсы MCS.
- Предварительно настроив сбор данных (в соответствии с шагом 2) на тестовом сервере, выполните нагрузочное тестирование и определите степень достижения показателей, выбранных на шаге 1.
- Если показатели успешности не достигнуты, проведите диагностику для выявления «узкого места», исходя из анализа данных, собранных на шаге 5. Добавьте необходимый тип ресурса или пересмотрите архитектуру и вновь приступайте к тестированию.
- При успешном тестировании можно производить миграцию и начинать промышленную эксплуатацию.
Как сочетать облачные системы хранения между собойМы рассмотрели, как выбрать конкретное облачное хранилище под задачи и требования проекта. Но на практике различные виды облачных хранилищ можно и нужно комбинировать друг с другом. Это позволяет задействовать преимущества каждого типа хранилища для оптимальной утилизации ресурсов. Например, возможна следующая комбинация блочных дисков: для ОС использовать HDD, СУБД построить с использованием SSD High IOPS, а для кэша взять Low Latency NVMe. S3 в такую схему можно подключить для размещения медиаконтента (картинок и видео) с возможностью внешнего доступа или для хранения резервных копий.Если вы используете Kubernetes, S3 подойдет для хранения образов, а файловые хранилища — в качестве персистентного хранилища для групп контейнеров. Хотя здесь также в большинстве случаев с минимальными доработками можно научить ПО в контейнерах работать с более надежным и дешевым хранилищем S3.Варианты комбинации различных типов облачных хранилищ представлены на рисунках ниже.
Вариант комбинации облачных дисков на примере построения инфраструктуры для интернет-магазина с применением облачных сервисов
Вариант комбинации облачных дисков на примере построения инфраструктуры для интернет-магазина с использованием кластера Kubernetes и хранилища S3Итоговое сравнение облачных систем хранения данныхЯ рассказал про наиболее важные технические характеристики, которые чаще всего влияют на итоговый выбор облачного хранилища. Результат проведенного сравнения наглядно демонстрирует таблица ниже. Важно понимать, что единого алгоритма для выбора облачного хранилища быть не может: для каждого бизнес-кейса потребуется индивидуальный анализ. Но надеюсь, что представленная в статье информация поможет вам сделать правильный выбор.Показатель/Система хранения данныхHDDSSDSSD High IOPSLow Latency NVMeФайловое хранилищеS3Тип хранилищаБлочноеБлочноеБлочноеБлочноеФайловоеОбъектноеРазмер хранилищаРекомендуемый размер — 2 ТбРекомендуемый размер — 2 ТбРекомендуемый размер — 2 ТбРекомендуемый размер — 2 ТбРекомендуемый размер — 2 ТбНе ограниченМаксимальный размер файлаРазмер дискаРазмер дискаРазмер дискаРазмер дискаРазмер хранилища32 ГБ для обычного файла, 320 ТБ для multipartIOPS read SLA(на 2 Тб пространства)300 – 24001 000 – 16 00010 000 – 45 00010 000 – 75 000300 – 2400Действуют рейт-лимиты: для обычных запросов — 500 запросов/с, 10 000 000 запросов/день для запросов на листинг — 15 запросов/с, 10 000 000 запросов/деньIOPS write SLA(на 2 Тб пространства)150 – 800500 – 80005000 – 30 0005000 – 50 000150 – 800Latency SLAНе предусмотрен SLAНе предусмотрен SLAНе предусмотрен SLAМаксимум 0,5 мсНе предусмотрен SLAНе предусмотрен SLAThroughput read SLA(на 2 Тб пространства и размер блока 1 М)250 Мб/c400 Мб/c500 Мб/c1200 Мб/c250 Мб/cОбеспечивается скорость до 1 ГБит/c. При интеграции с CDN: 1,5 ТБит/сThroughput write SLA(на 2 Тб пространства и размер блока 1 М)100 Мб/c400 Мб/c500 Мб/c900 Мб/c100 Мб/cМасштабированиеВручную за счет увеличения размера дискаВручную за счет увеличения размера дискаВручную за счет увеличения размера дискаВручную за счет увеличения размера дискаВручную за счет увеличения/уменьшения размера хранилищаВиртуально не ограниченаДоступность:
- SLA
- Поведение при выходе физического оборудования из строя
99,95%99,95%99,95%99,95%99,95%99,95%Надежность хранения 99,99999%Без прерывания обслуживания, данные не теряются (за счет двойных и тройных репликаций)Без прерывания обслуживания, данные не теряются (за счет двойных и тройных репликаций)Может возникнуть временная недоступность, данные не теряются (необходимо обеспечить отказоустойчивость на уровне приложения)Недоступность и риск потери данных (необходимо обеспечить отказоустойчивость на уровне приложения)Сервис доступен при выходе из строя оборудования, но выход его компонентов из строя ведет к прерыванию сервисаБез прерывания обслуживания, данные не теряютсяБэкапы и восстановлениеРезервные копии, снапшотыРезервные копии, снапшотыРезервные копии, снапшотыРезервные копии, снапшотыСнапшотыГеорепликация данных, в планах — версионность объектовГраницы доступностиИз любой AZ, но ресурс локализован в одной AZИз любой AZ, но ресурс локализован в одной AZИз любой AZ, но ресурс локализован в одной AZИз любой AZ, но ресурс локализован в одной AZИз сетей, которые имеют возможность маршрутизации IP-пакетов с сетью, где размещено файловое хранилищеMultiAZ, глобальныйПротоколы доступаНеприменимоНеприменимоНеприменимоНеприменимоEthernet, SMB/NFSS3 APIБезопасностьДоступ ограничивается namespace проектаДоступ ограничивается namespace проектаДоступ ограничивается namespace проектаДоступ ограничивается namespace проектаДоступ ограничивается namespace проекта, можно настроить доступ по IP клиентаВозможность ограничения доступа с использованием ACL и префиксных ключей, внешний доступ по HTTPSЦенообразованиеЗа выделенные ресурсыЗа выделенные ресурсыЗа выделенные ресурсыЗа выделенные ресурсыЗа выделенные ресурсыЗа фактически использованные ресурсыЧто еще почитать по теме:
- Работа с объектным S3-хранилищем Mail.ru Cloud Solutions как с файловой системой.
- Принципы организации объектных хранилищ.
- Все обновления облачных хранилищ и другие новости наших облачных сервисов — в нашем телеграм-канале.
===========
Источник:
habr.com
===========
Похожие новости:
- [Python, Microsoft Azure, Тестирование веб-сервисов, Облачные сервисы] HTTP атака на Azure
- [Системное администрирование, Управление проектами, DevOps, Облачные сервисы] Закупки как сервис
- [Хостинг, Хранение данных, Законодательство в IT, Облачные сервисы] Лицензии связи
- [Программирование, Облачные сервисы, IT-компании] Обладательница фамилии True полгода не может воспользоваться своим аккаунтом в Apple iCloud
- [Исследования и прогнозы в IT, Облачные сервисы, Звук] «Вкл/выкл»: стриминговые сервисы вынуждены все чаще скрывать треки и менять содержимое библиотек
- [Законодательство в IT] «Закручивая гайки»: как запад планирует взаимодействовать с китайскими телекомами
- [Высокая производительность, Разработка мобильных приложений, IT-инфраструктура, Разработка под Android] Как мы ускорили запуск приложения Dropbox для Android на 30 % (перевод)
- [Платежные системы, Фриланс, Облачные сервисы, Удалённая работа] Финансы на фрилансе: 5 инструментов для учета и контроля
- [Системное администрирование, PostgreSQL, IT-инфраструктура, Администрирование баз данных] Курс «PostgreSQL: replication, backup and observability». Старт 6 апреля
- [Программирование] Некоторые программистские заблуждения о времени
Теги для поиска: #_itinfrastruktura (IT-инфраструктура), #_hranenie_dannyh (Хранение данных), #_hranilischa_dannyh (Хранилища данных), #_oblachnye_servisy (Облачные сервисы), #_mail.ru_cloud_solutions, #_s3, #_obektnoe_hranilische (объектное хранилище), #_hranilische_dannyh (хранилище данных), #_hranenie_dannyh (хранение данных), #_itinfrastruktura (ит-инфраструктура), #_blog_kompanii_mail.ru_group (
Блог компании Mail.ru Group
), #_itinfrastruktura (
IT-инфраструктура
), #_hranenie_dannyh (
Хранение данных
), #_hranilischa_dannyh (
Хранилища данных
), #_oblachnye_servisy (
Облачные сервисы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 03:27
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Многие компании активно переносят свои данные в облако, обеспечивая тем самым гибкость и масштабируемость своих приложений. Но те, кто впервые пробуют облачные технологии, нередко сталкиваются с проблемой выбора правильного облачного хранилища под конкретную задачу. Какой тип диска подключить? Когда использовать объектное хранилище, а когда файловое? Какие преимущества и недостатки у каждого из них в облаке? Как можно использовать их совместно, чтобы улучшить утилизацию ресурсов?Я Хамзет Шогенов, архитектор облачной платформы Mail.ru Cloud Solutions, расскажу о системах хранения данных, доступных на нашей платформе, подробно остановлюсь на их технических характеристиках и оптимальных вариантах использования.Типы дисков, которые вы можете использовать в облакеДиски в облаке специально предоставляются в том виде, в котором классическим операционным системам «привычнее» с ними работать, то есть они имитируют физические носители информации, такие как HDD и SSD. При подключении к инстансам виртуальных машин такие диски можно использовать как обычное блочное устройство с «сырым» дисковым пространством — блоками, на которые разбивается все дисковое пространство, когда оно размечается под ту или иную файловую систему, чтобы уже на размеченном пространстве размещать данные операционных систем и приложений.Но так как это все-таки виртуальные диски, для них доступны дополнительные возможности, например создание снимков состояния и шаблонов для новых дисков на их основе, смена типов дисков «на лету» и так далее. Эта функциональность была бы невозможна, если бы вы имели дело с физическим оборудованием, либо возможна, но за счет неоправданно высокой стоимости.Особенности облачных (блочных) дисков:
Упрощенная схема выбора облачного хранилищаКак показывает опыт, описанные выше требования во многом определяются типом хранимых данных. Поэтому можно выделить наиболее типичные сценарии использования для каждой системы хранения данных. В таблице ниже показано, как выбрать облачное хранилище в зависимости от того, какие данные планируется размещать.Система хранения данныхТипичные сценарии использованияS3 GlacierМассивные данные (от 100 Тб) с очень редким доступом: бэкапы, архивы, журналы, системные сообщения, логи.S3 IceBoxДанные с редким доступом: архивы корпоративных файлов, годовая/месячная отчетность, документы маленьких рабочих групп, бэкапы, системные сообщения, lоg-файлы. S3 HotBoxПотоковая раздача мультимедиа, хранилища для Backend-платформ, хостинг статических файлов и веб-сайтов, хранение данных для обработки (Big Data, Data Mining). Файловое хранилищеФайловые хранилища, воссоздание схемы Legacy-приложения, общее персистентное хранилище данных для групп контейнеров. HDDФайловые хранилища, загрузочные разделы. SSDСУБД, телеметрия, очереди сообщений, загрузочные разделы. SSD High IOPSСУБД, аналитика, телеметрия. С большими требованиями к производительности, чем у SSD, но меньшими, чем у Low Latency NVMe.Low Latency NVMeВысокопроизводительные СУБД, аналитика, кэш. Расчет необходимой производительности облачной системы хранения при переносе Legacy-приложенийОдин из основных критериев выбора типа облачного хранилища — это требуемая производительность для переносимых в облако Legacy-приложений. Как ее правильнее рассчитать? Предлагаем руководствоваться следующим набором правил:
Вариант комбинации облачных дисков на примере построения инфраструктуры для интернет-магазина с применением облачных сервисов Вариант комбинации облачных дисков на примере построения инфраструктуры для интернет-магазина с использованием кластера Kubernetes и хранилища S3Итоговое сравнение облачных систем хранения данныхЯ рассказал про наиболее важные технические характеристики, которые чаще всего влияют на итоговый выбор облачного хранилища. Результат проведенного сравнения наглядно демонстрирует таблица ниже. Важно понимать, что единого алгоритма для выбора облачного хранилища быть не может: для каждого бизнес-кейса потребуется индивидуальный анализ. Но надеюсь, что представленная в статье информация поможет вам сделать правильный выбор.Показатель/Система хранения данныхHDDSSDSSD High IOPSLow Latency NVMeФайловое хранилищеS3Тип хранилищаБлочноеБлочноеБлочноеБлочноеФайловоеОбъектноеРазмер хранилищаРекомендуемый размер — 2 ТбРекомендуемый размер — 2 ТбРекомендуемый размер — 2 ТбРекомендуемый размер — 2 ТбРекомендуемый размер — 2 ТбНе ограниченМаксимальный размер файлаРазмер дискаРазмер дискаРазмер дискаРазмер дискаРазмер хранилища32 ГБ для обычного файла, 320 ТБ для multipartIOPS read SLA(на 2 Тб пространства)300 – 24001 000 – 16 00010 000 – 45 00010 000 – 75 000300 – 2400Действуют рейт-лимиты: для обычных запросов — 500 запросов/с, 10 000 000 запросов/день для запросов на листинг — 15 запросов/с, 10 000 000 запросов/деньIOPS write SLA(на 2 Тб пространства)150 – 800500 – 80005000 – 30 0005000 – 50 000150 – 800Latency SLAНе предусмотрен SLAНе предусмотрен SLAНе предусмотрен SLAМаксимум 0,5 мсНе предусмотрен SLAНе предусмотрен SLAThroughput read SLA(на 2 Тб пространства и размер блока 1 М)250 Мб/c400 Мб/c500 Мб/c1200 Мб/c250 Мб/cОбеспечивается скорость до 1 ГБит/c. При интеграции с CDN: 1,5 ТБит/сThroughput write SLA(на 2 Тб пространства и размер блока 1 М)100 Мб/c400 Мб/c500 Мб/c900 Мб/c100 Мб/cМасштабированиеВручную за счет увеличения размера дискаВручную за счет увеличения размера дискаВручную за счет увеличения размера дискаВручную за счет увеличения размера дискаВручную за счет увеличения/уменьшения размера хранилищаВиртуально не ограниченаДоступность:
=========== Источник: habr.com =========== Похожие новости:
Блог компании Mail.ru Group ), #_itinfrastruktura ( IT-инфраструктура ), #_hranenie_dannyh ( Хранение данных ), #_hranilischa_dannyh ( Хранилища данных ), #_oblachnye_servisy ( Облачные сервисы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 03:27
Часовой пояс: UTC + 5