Многие компании активно переносят свои данные в облако, обеспечивая тем самым гибкость и масштабируемость своих приложений. Но те, кто впервые пробуют облачные технологии, нередко сталкиваются с проблемой выбора правильного облачного хранилища под конкретную задачу. Какой тип диска подключить? Когда использовать объектное хранилище, а когда файловое? Какие преимущества и недостатки у каждого из них в облаке? Как можно использовать их совместно, чтобы улучшить утилизацию ресурсов?
Я Хамзет Шогенов, архитектор облачной платформы 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 и Veeam Backup & Replication. Встроенный механизм хорош интеграцией с облачной платформой, сохранением бэкапов в S3, что дешевле, и платой только за хранение данных. Однако в этом случае нет возможности восстановления данных в ту же виртуальную машину и восстановления отдельных файлов.
Границы доступности. Ресурс локализован в рамках одной зоны доступности (AZ, Availability Zone). Чтобы избежать потенциального снижения производительности работы, при создании диска, подключаемого к существующему инстансу, рекомендуется выбирать зону доступности инстанса.
Безопасность. Доступ к данным ограничен механизмами изоляции ресурсов (различные Namespace) проекта.
Механизм расчета стоимости. Цена определяется запрошенным объемом диска. При изменении размера стоимость автоматически пересчитывается.
Диски HDD
Базовые диски, самые недорогие и наименее производительные. В традиционной инфраструктуре этому классу хранения соответствуют обычные диски HDD. Чаще всего используются в качестве загрузочных разделов ОС и файловых хранилищ.
Характеристики, специфичные для HDD
Показатель | Значение |
|---|---|
IOPS (количество операций в секунду на 2 Тб пространства) | Показатель SLA для чтения — 2000, для записи — 800. |
Throughput (пропускная способность на 2 Тб пространства при размере блока 1М) | Показатель SLA для чтения — 250 Мб/с, для записи — 100 Мб/с. |
Поведение при выходе физического оборудования из строя | Происходит без прерывания обслуживания и потери данных, так как для дисков обеспечивается двойная и тройная репликация данных. |
Диски SSD
Стандартные диски, опережающие HDD по производительности естественно и более дорогие. По соответствию физическим дискам они существенно быстрее, чем любые HDD, но медленнее традиционных физических SSD, в основном из-за того, что добавляются накладные расходы на сеть и репликацию. Чаще всего используют для хранения файлов данных СУБД, телеметрии и очередей сообщений.
Характеристики, специфичные для SSD
Показатель | Значение |
|---|---|
IOPS (количество операций в секунду на 2 Тб пространства) | Показатель SLA для чтения — 16 000, для записи — 8000. |
Throughput (пропускная способность на 2 Тб пространства, при размере блока 1М) | Показатель SLA для чтения и записи — 400 Мб/с. |
Поведение при выходе физического оборудования из строя | Происходит без прерывания обслуживания и потери данных, так как для дисков обеспечивается тройная репликация данных. |
Диски High IOPS SSD
Быстрые диски, более производительные и дорогие по сравнению с SSD. Соответствуют физическим дискам SSD потребительского класса. Чаще всего используются для хранения файлов данных СУБД, данных аналитики и телеметрии, работа с которыми связана с большими требованиями к производительности, чем у SSD.
Характеристики, специфичные для High IOPS SSD
Показатель | Значение |
|---|---|
IOPS (количество операций в секунду на 2 Тб пространства) | Показатель SLA для чтения — 45 000, для записи — 30 000. |
Throughput (пропускная способность на 2 Тб пространства, при размере блока 1М) | Показатель SLA для чтения и записи 500 Мб/с. |
Поведение при выходе физического оборудования из строя | Возможна временная недоступность данных, сами данные не теряются. Необходимо дополнительно позаботиться о реализации отказоустойчивости на уровне приложения (application-aware). С лучшими практиками по созданию отказоустойчивых приложений можно ознакомиться по ссылке. |
Low Latency NVMe
Сверхбыстрые диски с минимальными задержками, доступные на высокочастотных конфигурациях ВМ. Самые производительные и дорогие. Этому классу хранения соответствуют физические диски NVMe установленные локально в гипервизорах. За счет дополнительно примененного слоя абстрагирования работы с данными у этих дисков есть все те же преимущества, что и у остальных виртуальных дисков. Но при этом физическое расположение диска в том же шасси, где в оперативную память загружена работающая с ней виртуальная машина, обеспечивает размеры задержек на накладные расходы, стремящиеся к нулю.
Используются там, где важно обеспечить минимальные задержки: высокопроизводительные СУБД, аналитика, кэш.
Характеристики, специфичные для Low Latency NVMe
Показатель | Значение |
|---|---|
IOPS (количество операций в секунду на 2 Тб пространства) | Показатель SLA для чтения — 75 000, для записи 50 000. |
Throughput (пропускная способность на 2 Тб пространства, при размере блока 1М) | Показатель SLA для чтения — 1200 Мб/с, для записи 900 Мб/с. |
Latency (задержка) | SLA — максимум 0,5 мс. Устойчивы к отказу сети, виртуальная машина с такими дисками максимально близка к bare metal. |
Поведение при выходе физического оборудования из строя | Возможна временная недоступность данных, есть риск потери данных. Необходимо дополнительно позаботиться о реализации отказоустойчивости на уровне приложения (application-aware). С лучшими практиками по созданию отказоустойчивых приложений можно ознакомиться по ссылке. |
Объектные хранилища S3 — еще один тип хранения данных в облаке
В S3 данные хранятся в виде объектов. Объект — это некая совокупность данных с уникальным идентификатором и бесконечным количеством метаданных. Для группировки объектов есть дополнительная сущность — бакеты. Это контейнеры для объектов, похожие на папки, но не являющиеся их полным аналогом. В проекте может быть один или несколько бакетов.
Лучше всего S3 подходит для хранения неструктурированных данных и обработки большого количества объектов малого и среднего размера, которые редко изменяются и часто требуют параллельного доступа большого числа пользователей. Для обработки больших объектов доступна дополнительная функциональность — мультипоточная загрузка.
S3 может выступать в качестве более надежной и дешевой альтернативы дискам HDD для большей части сценариев их использования.
Мы используем реализацию объектного хранилища S3 собственной разработки
В нашем облаке доступны три класса объектных хранилищ S3, которые различаются по своему назначению и стоимости:
S3 HotBox предназначен для хранения горячих данных — с частым доступом. В первую очередь это онлайн-сервисы с повышенной нагрузкой, работа которых требует хранения и раздачи контента: потоковая раздача мультимедиа, хостинг статических сайтов, хранилища для Backend-платформ. Могут также использоваться для анализа данных в Big Data, Data Mining и так далее. В HotBox хранение дороже, а исходящий трафик дешевле, входящий трафик не тарифицируется.
S3 IceBox используют для хранения холодных данных — с редким доступом, например несколько раз в месяц. Чаще всего это годовая и месячная отчетность, документы, бэкапы и журналы, к которым периодически нужен быстрый доступ. По сравнению с HotBox в IceBox хранение дешевле, а исходящий трафик дороже, входящий трафик также не тарифицируется.
Glacier подходит для хранения ледяных данных — массивных данных (от 100 Тб) с очень редким доступом. Это бэкапы, архивы и логи, к которым доступ может потребоваться несколько раз в год и реже. Из трех типов хранилищ в Glacier самая низкая цена на хранение данных, а весь трафик бесплатный. Такое хранилище подключается по отдельному запросу клиента.
Что хорошего в S3-хранилище:
Неограниченный объем хранимых данных (петабайты).
Подходит для неструктурированных данных за счет хранения дополнительной информации (метаданных) рядом с объектами.
Разграничение доступа за счет ACL и префиксных ключей.
Возможность одновременного использования большим количеством приложений.
Стабильная скорость раздачи любых объектов независимо от числа одновременных обращений.
Автоматическое и виртуально неограниченное масштабирование.
Возможность настройки Webhooks для автоматической обработки при создании/удалении объектов (например, автообработка фото и видео).
Возможность настройки жизненного цикла объектов. Например, удаление архивных данных по истечении максимального срока их хранения.
У S3 нет понятия зоны доступности: это глобальный сервис. Его доступность обеспечивается из пяти ЦОД MCS.
Наименьшая стоимость среди всех типов облачных хранилищ.
Основное отличие S3-хранилища от других облачных (блочных) систем хранения — блочные хранилища предназначены для использования виртуальными машинами и представляются как диски, а объектное хранилище 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 файловое хранилище предоставляется как сервис. С его помощью можно создать удаленную файловую систему, смонтировать ее на виртуальных машинах, а затем читать и записывать данные из инстансов в файловую систему и из нее.
Чаще всего файловое хранилище используют в качестве системы хранения документов, общего пользовательского файлового пространства или общего персистентного хранилища данных для Docker-контейнеров в составе кластера Kubernetes.
Преимущества файловых хранилищ:
Есть возможность как увеличения, так и уменьшения размера хранилища.
Есть возможность создания снапшотов.
Оптимальный вариант хранения для Legacy-приложений, требующих протокола SMB/NFS.
Поддерживаются большим количеством классических систем.
Недостатки файловых хранилищ:
Масштабирование производится вручную.
Одновременный доступ ограничен полосой пропускания стандартного сетевого интерфейса.
В настоящий момент для файловых хранилищ нет возможности выбрать другой тип диска, кроме HDD, в будущем появится возможность использовать SSD.
Основные характеристики файловых хранилищ
Capacity. Рекомендуемый максимальный размер хранилища — 2 Тб. Максимальный размер файла — не больше запрошенного размера хранилища.
IOPS (количество операций в секунду на 2 Тб пространства). Так как файловое хранилище базируется на дисках HDD, показатель SLA будет тем же: для чтения — 2000, для записи — 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
Итоговое сравнение облачных систем хранения данных
Я рассказал про наиболее важные технические характеристики, которые чаще всего влияют на итоговый выбор облачного хранилища. Результат проведенного сравнения наглядно демонстрирует таблица ниже. Важно понимать, что единого алгоритма для выбора облачного хранилища быть не может: для каждого бизнес-кейса потребуется индивидуальный анализ. Но надеюсь, что представленная в статье информация поможет вам сделать правильный выбор.
Показатель/Система хранения данных | HDD | SSD | SSD High IOPS | Low Latency NVMe | Файловое хранилище | S3 |
|---|---|---|---|---|---|---|
Тип хранилища | Блочное | Блочное | Блочное | Блочное | Файловое | Объектное |
Размер хранилища | Рекомендуемый размер — 2 Тб | Рекомендуемый размер — 2 Тб | Рекомендуемый размер — 2 Тб | Рекомендуемый размер — 2 Тб | Рекомендуемый размер — 2 Тб | Не ограничен |
Максимальный размер файла | Размер диска | Размер диска | Размер диска | Размер диска | Размер хранилища | 32 ГБ для обычного файла, 320 ТБ для multipart |
IOPS read SLA(на 2 Тб пространства) | 2000 | 16 000 | 45 000 | 75 000 | 2000 | Действуют рейт-лимиты: для обычных запросов — 500 запросов/с, 10 000 000 запросов/день для запросов на листинг — 15 запросов/с, 10 000 000 запросов/день |
IOPS write SLA(на 2 Тб пространства) | 800 | 8000 | 30 000 | 50 000 | 800 | |
Latency SLA | Не предусмотрен SLA | Не предусмотрен SLA | Не предусмотрен SLA | Максимум 0,5 мс | Не предусмотрен SLA | Не предусмотрен SLA |
Throughput read SLA(на 2 Тб пространства и размер блока 1 М) | 250 Мб/c | 400 Мб/c | 500 Мб/c | 1200 Мб/c | 250 Мб/c | Обеспечивается скорость до 1 ГБит/c. При интеграции с CDN: 1,5 ТБит/с |
Throughput write SLA(на 2 Тб пространства и размер блока 1 М) | 100 Мб/c | 400 Мб/c | 500 Мб/c | 900 Мб/c | 100 Мб/c | |
Масштабирование | Вручную за счет увеличения размера диска | Вручную за счет увеличения размера диска | Вручную за счет увеличения размера диска | Вручную за счет увеличения размера диска | Вручную за счет увеличения/уменьшения размера хранилища | Виртуально не ограничена |
Доступность:
| 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/NFS | S3 API |
Безопасность | Доступ ограничивается namespace проекта | Доступ ограничивается namespace проекта | Доступ ограничивается namespace проекта | Доступ ограничивается namespace проекта | Доступ ограничивается namespace проекта, можно настроить доступ по IP клиента | Возможность ограничения доступа с использованием ACL и префиксных ключей, внешний доступ по HTTPS |
Ценообразование | За выделенные ресурсы | За выделенные ресурсы | За выделенные ресурсы | За выделенные ресурсы | За выделенные ресурсы | За фактически использованные ресурсы |
Что еще почитать по теме:
