какую технологию следует внедрить чтобы обеспечить высокую доступность систем хранения данных
Хранение данных. Или что такое NAS, SAN и прочие умные сокращения простыми словами
TL;DR: Вводная статья с описанием разных вариантов хранения данных. Будут рассмотрены принципы, описаны преимущества и недостатки, а также предпочтительные варианты использования.
Зачем это все?
Хранение данных — одно из важнейших направлений развития компьютеров, возникшее после появления энергонезависимых запоминающих устройств. Системы хранения данных разных масштабов применяются повсеместно: в банках, магазинах, предприятиях. По мере роста требований к хранимым данным растет сложность хранилищ данных.
Надежно хранить данные в больших объемах, а также выдерживать отказы физических носителей — весьма интересная и сложная инженерная задача.
Хранение данных
Под хранением обычно понимают запись данных на некоторые накопители данных, с целью их (данных) дальнейшего использования. Опустим исторические варианты организации хранения, рассмотрим подробнее классификацию систем хранения по разным критериям. Я выбрал следующие критерии для классификации: по способу подключения, по типу используемых носителей, по форме хранения данных, по реализации.
По способу подключения есть следующие варианты:
подключение дисков в сервере
дисковая полка, подключаемая по FC
По типу используемых накопителей возможно выделить:
Если рассматривать форму хранения данных, то явно выделяются следующие:
По реализации достаточно сложно провести четкие границы, однако можно отметить:
RAID контроллер от компании Fujitsu
пример организации LVM с шифрованием и избыточностью в виртуальной машине Linux в облаке Azure
Давайте рассмотрим более детально некоторые технологии, их достоинства и недостатки.
Direct Attached Storage — это исторически первый вариант подключения носителей, применяемый до сих пор. Накопитель, с точки зрения компьютера, в котором он установлен, используется монопольно, обращение с накопителем происходит поблочно, обеспечивая максимальную скорость обмена данными с накопителем с минимальными задержками. Также это наиболее дешевый вариант организации системы хранения данных, однако не лишенный своих недостатков. К примеру если нужно организовать хранение данных предприятия на нескольких серверах, то такой способ организации не позволяет совместное использование дисков разных серверов между собой, так что система хранения данных будет не оптимальной: некоторые сервера будут испытывать недостаток дискового пространства, другие же — не будут полностью его утилизировать:
Конфигурации систем с единственным накопителем применяются чаще всего для нетребовательных нагрузок, обычно для домашнего применения. Для профессиональных целей, а также промышленного применения чаще всего используется несколько накопителей, объединенных в RAID-массив программно, либо с помощью аппаратной карты RAID для достижения отказоустойчивости и\или более высокой скорости работы, чем единичный накопитель. Также есть возможность организации кэширования наиболее часто используемых данных на более быстром, но менее емком твердотельном накопителе для достижения и большой емкости и большой скорости работы дисковой подсистемы компьютера.
Storage area network, она же сеть хранения данных, является технологией организации системы хранения данных с использованием выделенной сети, позволяя таким образом подключать диски к серверам с использованием специализированного оборудования. Так решается вопрос с утилизацией дискового пространства серверами, а также устраняются точки отказа, неизбежно присутствующие в системах хранения данных на основе DAS. Сеть хранения данных чаще всего использует технологию Fibre Channel, однако явной привязки к технологии передачи данных — нет. Накопители используются в блочном режиме, для общения с накопителями используются протоколы SCSI и NVMe, инкапсулируемые в кадры FC, либо в стандартные пакеты TCP, например в случае использования SAN на основе iSCSI.
Давайте разберем более детально устройство SAN, для этого логически разделим ее на две важных части, сервера с HBA и дисковые полки, как оконечные устройства, а также коммутаторы (в больших системах — маршрутизаторы) и кабели, как средства построения сети. HBA — специализированный контроллер, размещаемый в сервере, подключаемом к SAN. Через этот контроллер сервер будет «видеть» диски, размещаемые в дисковых полках. Сервера и дисковые полки не обязательно должны размещаться рядом, хотя для достижения высокой производительности и малых задержек это рекомендуется. Сервера и полки подключаются к коммутатору, который организует общую среду передачи данных. Коммутаторы могут также соединяться с собой с помощью межкоммутаторных соединений, совокупность всех коммутаторов и их соединений называется фабрикой. Есть разные варианты реализации фабрики, я не буду тут останавливаться подробно. Для отказоустойчивости рекомендуется подключать минимум две фабрики к каждому HBA в сервере (иногда ставят несколько HBA) и к каждой дисковой полке, чтобы коммутаторы не стали точкой отказа SAN.
Недостатками такой системы являются большая стоимость и сложность, поскольку для обеспечения отказоустойчивости требуется обеспечить несколько путей доступа (multipath) серверов к дисковым полкам, а значит, как минимум, задублировать фабрики. Также в силу физических ограничений (скорость света в общем и емкость передачи данных в информационной матрице коммутаторов в частности) хоть и существует возможность неограниченного подключения устройств между собой, на практике чаще всего есть ограничения по числу соединений (в том числе и между коммутаторами), числу дисковых полок и тому подобное.
Network attached storage, или сетевое файловое хранилище, представляет дисковые ресурсы в виде файлов (или объектов) с использованием сетевых протоколов, например NFS, SMB и прочих. Принципиально базируется на DAS, но ключевым отличием является предоставление общего файлового доступа. Так как работа ведется по сети — сама система хранения может быть сколько угодно далеко от потребителей (в разумных пределах разумеется), но это же является и недостатком в случае организации на предприятиях или в датацентрах, поскольку для работы утилизируется полоса пропускания основной сети — что, однако, может быть нивелировано с использованием выделенных сетевых карт для доступа к NAS. Также по сравнению с SAN упрощается работа клиентов, поскольку сервер NAS берет на себя все вопросы по общему доступу и т.п.
Unified storage
Универсальные системы, позволяющие совмещать в себе как функции NAS так и SAN. Чаще всего по реализации это SAN, в которой есть возможность активировать файловый доступ к дисковому пространству. Для этого устанавливаются дополнительные сетевые карты (или используются уже существующие, если SAN построена на их основе), после чего создается файловая система на некотором блочном устройстве — и уже она раздается по сети клиентам через некоторый файловый протокол, например NFS.
Software-defined storage — программно определяемое хранилище данных, основанное на DAS, при котором дисковые подсистемы нескольких серверов логически объединяются между собой в кластер, который дает своим клиентам доступ к общему дисковому пространству.
Наиболее яркими представителями являются GlusterFS и Ceph, но также подобные вещи можно сделать и традиционными средствами (например на основе LVM2, программной реализации iSCSI и NFS).
N.B. редактора: У вас есть возможность изучить технологию сетевого хранилища Ceph, чтобы использовать в своих проектах для повышения отказоустойчивости, на нашем практическим курсе по Ceph. В начале курса вы получите системные знания по базовым понятиям и терминам, а по окончании научитесь полноценно устанавливать, настраивать и управлять Ceph. Детали и полная программа курса здесь.
Пример SDS на основе GlusterFS
Из преимуществ SDS — можно построить отказоустойчивую производительную реплицируемую систему хранения данных с использованием обычного, возможно даже устаревшего оборудования. Если убрать зависимость от основной сети, то есть добавить выделенные сетевые карты для работы SDS, то получается решение с преимуществами больших SAN\NAS, но без присущих им недостатков. Я считаю, что за подобными системами — будущее, особенно с учетом того, что быстрая сетевая инфраструктура более универсальная (ее можно использовать и для других целей), а также дешевеет гораздо быстрее, чем специализированное оборудование для построения SAN. Недостатком можно назвать увеличение сложности по сравнению с обычным NAS, а также излишней перегруженностью (нужно больше оборудования) в условиях малых систем хранения данных.
Гиперконвергентные системы
Подавляющее большинство систем хранения данных используется для организации дисков виртуальных машин, при использовании SAN неизбежно происходит удорожание инфраструктуры. Но если объединить дисковые системы серверов с помощью SDS, а процессорные ресурсы и оперативную память с помощью гипервизоров отдавать виртуальным машинам, использующим дисковые ресурсы этой SDS — получится неплохо сэкономить. Такой подход с тесной интеграцией хранилища совместно с другими ресурсами называется гиперконвергентностью. Ключевой особенностью тут является способность почти бесконечного роста при нехватке ресурсов, поскольку если не хватает ресурсов, достаточно добавить еще один сервер с дисками к общей системе, чтобы нарастить ее. На практике обычно есть ограничения, но в целом наращивать получается гораздо проще, чем чистую SAN. Недостатком является обычно достаточно высокая стоимость подобных решений, но в целом совокупная стоимость владения обычно снижается.
Облака и эфемерные хранилища
Логическим продолжением перехода на виртуализацию является запуск сервисов в облаках. В предельном случае сервисы разбиваются на функции, запускаемые по требованию (бессерверные вычисления, serverless). Важной особенностью тут является отсутствие состояния, то есть сервисы запускаются по требованию и потенциально могут быть запущены столько экземпляров приложения, сколько требуется для текущей нагрузки. Большинство поставщиков (GCP, Azure, Amazon и прочие) облачных решений предлагают также и доступ к хранилищам, включая файловые и блочные, а также объектные. Некоторые предлагают дополнительно облачные базы, так что приложение, рассчитанное на запуск в таком облаке, легко может работать с подобными системами хранения данных. Для того, чтобы все работало, достаточно оплатить вовремя эти услуги, для небольших приложений поставщики вообще предлагают бесплатное использование ресурсов в течение некоторого срока, либо вообще навсегда.
Из недостатков: могут заблокировать аккаунт, на котором все работает, что может привести к простоям в работе. Также могут быть проблемы со связностью и\или доступностью таких сервисов по сети, поскольку такие хранилища полностью зависят от корректной и правильной работы глобальной сети.
Заключение
Надеюсь, статья была полезной не только новичкам. Предлагаю обсудить в комментариях дополнительные возможности систем хранения данных, написать о своем опыте построения систем хранения данных.
Как выбрать облачную систему хранения данных, чтобы получить лучшую производительность и оптимизировать стоимость
Многие компании активно переносят свои данные в облако, обеспечивая тем самым гибкость и масштабируемость своих приложений. Но те, кто впервые пробуют облачные технологии, нередко сталкиваются с проблемой выбора правильного облачного хранилища под конкретную задачу. Какой тип диска подключить? Когда использовать объектное хранилище, а когда файловое? Какие преимущества и недостатки у каждого из них в облаке? Как можно использовать их совместно, чтобы улучшить утилизацию ресурсов?
Я Хамзет Шогенов, архитектор облачной платформы 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 Мб/с.
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. Рекомендуем выбирать тот тип диска, который при достаточной для вас производительности будет дешевле всего, так как в дальнейшем при необходимости его можно будет изменить «на лету».
Схема выбора оптимальной системы хранения данных с учетом описанных параметров в очень упрощенном виде приведена ниже. Она носит рекомендательный характер. Естественно, в зависимости от ситуации данные рекомендации могут быть и абсолютно нерелевантными, но для общих случаев они чаще всего корректны.
Упрощенная схема выбора облачного хранилища
Как показывает опыт, описанные выше требования во многом определяются типом хранимых данных. Поэтому можно выделить наиболее типичные сценарии использования для каждой системы хранения данных. В таблице ниже показано, как выбрать облачное хранилище в зависимости от того, какие данные планируется размещать.
Система хранения данных
Типичные сценарии использования
Массивные данные (от 100 Тб) с очень редким доступом: бэкапы, архивы, журналы, системные сообщения, логи.
Данные с редким доступом: архивы корпоративных файлов, годовая/месячная отчетность, документы маленьких рабочих групп, бэкапы, системные сообщения, lоg-файлы.
Потоковая раздача мультимедиа, хранилища для Backend-платформ, хостинг статических файлов и веб-сайтов, хранение данных для обработки (Big Data, Data Mining).
Файловые хранилища, воссоздание схемы Legacy-приложения, общее персистентное хранилище данных для групп контейнеров.
Файловые хранилища, загрузочные разделы.
СУБД, телеметрия, очереди сообщений, загрузочные разделы.
СУБД, аналитика, телеметрия. С большими требованиями к производительности, чем у SSD, но меньшими, чем у 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
Итоговое сравнение облачных систем хранения данных
Я рассказал про наиболее важные технические характеристики, которые чаще всего влияют на итоговый выбор облачного хранилища. Результат проведенного сравнения наглядно демонстрирует таблица ниже. Важно понимать, что единого алгоритма для выбора облачного хранилища быть не может: для каждого бизнес-кейса потребуется индивидуальный анализ. Но надеюсь, что представленная в статье информация поможет вам сделать правильный выбор.