Как вы храните данные? Используете файловое хранилище, S3, базы данных, держите файлы прямо на сервере, храните все локально на HDD, SSD или даже флешке — вариантов масса, на любой вкус и цвет. В этой статье я предлагаю вспомнить, как развивалось хранение информации и как мы прошли путь от наскальной живописи до приватного S3. Это поможет разобраться, какую технологию лучше использовать для ваших задач. 

Все начинается с потребностей

Начнем с глиняных табличек — одной из самых древних форм записи, появившейся около 4 000 лет до нашей эры в Месопотамии. Эти плоские прямоугольные таблички изготавливали из природной глины, которую смешивали с водой до пластичного состояния. После нанесения клинописного текста их либо сушили на солнце, либо обжигали в печах. Это придавало табличкам удивительную долговечность. Благодаря этому они смогли пережить даже пожары и наводнения. 

Известно, что сегодня в музеях мира хранится около 500 000 таких табличек. Материал и техники для их изготовления выбирали так, чтобы они были максимально долговечными. Интересно, что глина сохраняла мелкие линии и позволяла записывать большой объем информации в ограниченном пространстве — это был главный информационный носитель своего времени.

Со временем люди поняли, что с 20-килограммовой книжкой из сухой глины ходить не так уж удобно. Да и объемы информации, которую требовалось распространять, росли. Поэтому переход к пергаменту и бумаге — это отклик на другую потребность: тиражирование и удобочитаемость.

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

Во II веке до н.э. египетские фараоны запретили вывоз папируса, чтобы сохранить преимущество Александрийской библиотеки. Именно конкуренция с папирусом стимулировала город Пергам и Черноморскую культуру перейти к использованию пергамента. Это позволило создавать книги в свитках и вести библиотеки с гораздо большей гибкостью. 

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

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

Облачная инфраструктура для ваших проектов

Виртуальные машины в Москве, Санкт-Петербурге и Новосибирске с оплатой по потреблению.

Подробнее →

Перфокарты и жесткие диски

Магнитные ленты и перфокарты вписали в историю информационных технологий эпоху автоматизации и масштабируемого хранения. А как они вообще возникли?

Перфокарты появились еще в XIX веке, благодаря изобретателю Герману Холлериту и развитию табуляторов. По сути, это были плотные бумажные карточки с определенным расположением отверстий, которые кодировали информацию — биты данных, 0 и 1. Машины считывали эти отверстия с помощью механических или оптических датчиков. Перфокарты стали первым шагом к аналоговым компьютерам. Это была одна из первых массовых систем автоматического хранения и обработки информации, применявшаяся в бухгалтерии, статистике и промышленных приложениях.

Магнитные ленты, в свою очередь, появились в 1928 году, когда немецкий инженер Фриц Пфлюмер впервые нанес магнитный слой на бумажную ленту. Позже, в 1950-х годах, магнитные ленты стали массово применяться в вычислительной технике, когда появились первые ЭВМ. 

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

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

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

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

Первый коммерческий HDD был разработан компанией IBM в 1956 году — это было устройство размером почти с холодильник, которое хранило всего несколько мегабайт данных. Из нового — возможность перейти к любой части диска без последовательного поиска, как в магнитных лентах.

Более поздний этап — это переход от жестких дисков с вращающимися магнитными пластинами к флэш-памяти (Flash), основанной на полупроводниковых технологиях. HDD обеспечивали случайный доступ к данным, что стало революцией по сравнению с лентами, но имели движущиеся части, подверженные износу и механическим повреждениям. В свою очередь флэш-память, начиная с коммерческого внедрения в 1980-х годах и массового распространения с начала 2000-х, предлагает быстрый доступ, высокую устойчивость к ударам и меньшие размеры. 

Примером является использование NAND-флэш, который позволил создавать компактные и надежные накопители, кардинально изменившие способы хранения в смартфонах, ноутбуках и дата-центрах. 3D NAND, вертикально наращивающий плотность хранения, стал следующим этапом развития, существенно увеличив емкость и производительность физических носителей данных. 

Флэш-хранилища требуют меньше энергии и обеспечивают большую скорость операций ввода-вывода. А это, как мы все видим, основа для современных систем хранения. Так что до сих пор нередко можно встретить такие сообщения :)

Файловые системы, RAID и сетевые стораджи

В середине XX века файловые системы начинались с примитивных парадигм вроде FAT (File Allocation Table) — простой, но быстро ставшей недостаточно надежной системы для все возрастающих объемов информации и разных сценариев записи.
За десятилетия разработки файловые системы стали отвечать новым требованиям: защите не только от случайных ошибок, но и от целенаправленных атак, внезапных сбоев носителей и человеческих ошибок.

Если NTFS и ext4 еще опирались на журналы транзакций и базовую карту размещения блоков, то современные подходы, как ZFS, уже предоставляют мощнейший контроль целостности, механику copy-on-write, автоматические снапшотам (моментальные снимки всего состояния) и дедупликацию данных. Все это вместе — ответ на новые угрозы: silent corruption, ransomware, потребность в откате к прежнему состоянию системы без даунтайма и потери производительности. 

В качестве базиса целостности и доступности выступают модели RAID. Простыми словами, RAID-массив — это несколько дисков, объединенных с выделением места под хранение информации для исправления ошибок в данных. Классические уровни (RAID 0, 1, 5, 6, 10) по-прежнему хороши, но выбор между ними — это всегда trade-off между IOPS, полезной емкостью и временем восстановления массива (rebuild). 

Следующий ключевой вопрос — это способы коллективного доступа и шаринга: SAN против NAS. SAN (Storage Area Network) строится вокруг блочного доступа и нужен там, где требуется высокая производительность и низкие задержки: базы данных, виртуализация, критичные системы высокой нагрузки. При этом SAN требует особой инфраструктуры и навыков администрирования, а его стоимость заметно выше.

NAS работает с файловым доступом, прост в подключении, идеален для общего хранения документов, резервного копирования и обмена файлами в организации. Внутри NAS зачастую используются те же файловые системы — например, ext4, Btrfs, ZFS. SAN же предлагают raw-устройства под специфические задачи, где важны строгое управление блоками и производительность.

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

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

Системы вроде Ceph, GlusterFS, SeaweedFS и другие позволили перейти к следующему уровню — теперь хранение и доступ к данным стали гибкими, надежными и максимально масштабируемыми, подстраиваясь под реальные потребности современных IT-инфраструктур без традиционных узких мест.

S3 и парадигма объектного хранения

Хранение данных вышло на новый уровень с появлением облачных технологий и S3.

Simple Storage Service (он же S3) был создан компанией Amazon в 2006 году и стал одним из первых масштабируемых облачных хранилищ с простым, но мощным API для работы с объектами данных.
Принципиальное отличие S3 от классических файловых или блочных хранилищ — это объектная модель хранения данных, в которой каждый сохраненный объект получает уникальный ключ и сопровождается набором метаданных, становясь самостоятельной «единицей смысла» для приложения.

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

Технически это плоское, неиерархическое пространство — flat namespace. Объекты идентифицируются по ID, что снимает ограничения классической иерархии и упрощает масштабирование. Без сложных вложенных структур управление проще. Время доступа к объектам стабильно, независимо от объема хранилища.

Версионирование объектов позволяет сохранять каждую историю изменений и быстро откатиться назад в случае чего. Это критично как для резервного копирования, так и для защиты от случайного удаления или атак. Метаданные — это полноценные first-class citizens, которые можно расширять, использовать в поиске и автоматических workflow. 

Горизонтальное масштабирование без ручного шардинга — фича S3. Вам не нужно заботиться о распределении данных по узлам, их репликации или отказоустойчивости: платформа сама управляет этим, позволяя расти «‎от гигабайта до петабайта‎», от мобилок до Enterprise-платформ. Это дает возможность строить event-driven архитектуры, где изменения данных запускают автоматические процессы обработки, аудита, пересылки и даже машинного обучения в режиме почти реального времени.

Обычно хранилища еще подразделяют по температуре классам. Стандартное используют, очевидно, в частых задачах: анализ Big Data, хранение и доставка мультимедиа. Из плюсов: стоимость запросов и трафика тут небольшая.

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

И самая глубинная часть нашего заплыва — ледяное хранилище. Оно подходит для хранения объектов, которые будут очень редко читать и изменять: резервных копий длительного хранения, логов и документов. С типом репликации Erasure Coding. Стоимость хранения — самая низкая, а запросов и трафика — самая высокая.

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

S3-хранилища бывают приватными и публичными. Давайте разберемся, в чем разница.

Приватное S3

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

Приватное S3 — это когда приходит клиент и говорит: «Нужно решение, чтобы настроить все под свои нужды и иметь отдельное облако‎»‎.‎‎ Наши инженеры создают отдельную инсталляцию. Выделяют место на этаже или целый этаж, заполняют его железками, на которых и разворачивается приватное S3. Оно подстраивается под любые запросы бизнеса. Смысл приватного S3 — в кратном увеличении производительности и скорости загрузки и выгрузки данных.

Можно реализовать кастомную инсталляцию, которая будет существовать отдельно. Ее можно построить в любом регионе: в Москве или Санкт-Петербурге.

Главное отличие приватного S3 — это выделенный, изолированный пул ресурсов.

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

При необходимости приватное S3 хранилище можно интегрировать с остальной инфраструктурой Selectel (облачные или выделенные серверы) через Direct Connect или L3VPN, обеспечивая единую, защищенную инфраструктуру. 

Публичное S3

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

1. Переходим в панель управления и выбираем нужный нам проект (или создаем новый). 

Идем в раздел Продукты → Хранение и обработка данных → S3.

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

Например, для нужд резервного копирования оптимальным вариантом будет приватный бакет с холодным хранением. Бакет со стандартным хранением больше подойдет для сайта — к примеру, чтобы не хранить фото на сервере сайта, можно использовать ссылку на бакет. А там и до CDN недалеко.

2. Теперь осталось выбрать адресацию. Есть два ее вида:

• v-Hosted — имеет вид <backup.domain.ru> и в документации S3 описывается как рекомендуемая,

• Path-style — имеет вид <domain.ru/backup>, описывается как устаревший и планируемый к отключению в будущем.

Selectel также рекомендует к использованию для любых проектов v-Hosted тип адресации.

Для защиты данных от непреднамернного удаления рекомендуется использовать версионирование. Это позволит вернутся к разным версиям объекта восстаноить даже удаленные данные.

3. После создания контейнера кликаем по его названию и переходим внутрь.

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

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

Если пользователей еще нет, вы увидите вот такую страницу:

Нажимайте Добавить пользователя. Сервисный пользователь — учетная запись без доступа в панель управления, но с доступом к API и другим инструментам. В нашем случае аккаунт нужен только для взаимодействия с файлами внутри бакета, поэтому прав пользователя достаточно. Выберите имя, придумайте пароль (или сгенерируйте его по кнопке), укажите из списка роль member, выберите проект и нажмите Добавить пользователя.

Если все сделано правильно, вы увидите вот такую страницу:

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

S3 ключ будет использоваться для подключения к бакету. У одного пользователя может быть несколько ключей, но все разграничение прав происходит именно по пользователю. То есть если один пользователь будет иметь несколько ключей, то доступы к бакетам у всех них будут едины. Рекомендую использовать один сервер, один бакет, один ключ. Во всяком случае, для резервных копий.

И вот мы получаем Access key и Secret key. Предупреждение о том, что ключ доступен для просмотра один раз, появляется не для красоты. Отнеситесь к этому ответственно, если не хотите потом заниматься настройкой доступов заново. Хост для подключения в моем случае — s3.ru-1.storage.selcloud.ru.

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

Для удобства хранения ключей можно использовать медежер секретов Selectel. В нем же можно создавать Let’s Encrypt сертификаты котороые в дальнейшем можно использовать в S3 хранилище. Подробнее о продукте в официальной документации 

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

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

Затем нажимаем Добавить правило, выбираем сервисного пользователя — и вот его уже в правах стоит несколько ограничить. Если этого не сделать, под данным пользователем можно будет редактировать настройки бакета. В нашем случае это категорически не рекомендуется, поэтому советую настроить минимально необходимые права для загрузки: GetBucketPolicy, AbortMultipartUpload, GetObject, PutObject, ListBucket, ListBucketMultipartUploads, ListMultipartUploadParts.

Когда права администратора и сервисного пользователя настроены, нажмите Сохранить. В итоге вкладка Политика доступа должна иметь вот такой вид:

Будущее хранения в децентрализации? 

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

Насколько вы готовы доверить ИИ управление хранением? Как думаете, гибридные модели — это путь к более устойчивому будущему? Делитесь мнениями и прогнозами в комментариях!