Привет, Хабр! На связи Даша Косова, я продакт менеджер Рег.облака. Ситуация: на сервере закончилось место. Вы увеличиваете диск, выдыхаете, а через какое-то время всё повторяется. Потом приходит время переносить сервер, и вместе с ним переезжают все накопленные файлы. Перенос растягивается на выходные, а трогать эту машину лишний раз уже никому не хочется. Место на диске к этому моменту далеко не единственная проблема.
Почти все проекты начинают одинаково: один сервер, локальный диск, минимум сервисов. И это правильный старт. Усложнять архитектуру заранее — значит платить деньгами и временем поддержки за то, что пока не нужно. Проблемы приходят позже, когда пользователей, данных и сервисов становится больше, а хранение остается таким же, каким было в первый день.
Дальше разберу на примере условной онлайн-школы, как меняются требования к хранению по мере роста проекта и в какой момент стоит посмотреть в сторону сетевых дисков.
Навигация по тексту:
На старте хватает одного сервера
У школы в начале один сервер и одно приложение. На нем лежит сразу всё: операционная система, само приложение, база данных, пользовательские файлы. Записи вебинаров пока помещаются, домашние работы студентов тоже.
Такая схема выигрывает в простоте. Нет сетевых задержек между вычислениями и хранением, нечего настраивать отдельно, инфраструктура обходится недорого. На этом этапе никакой другой архитектуры и не нужно.
Проект растет, а увеличение диска перестает спасать
Студентов становится больше. Растут пользовательские файлы, распухает база данных, появляются резервные копии, копятся логи. Свободное место заканчивается.
Первое, что делает команда, — увеличивает диск. Обычно это помогает, но только до определенного момента. Потому что нехватка места — это симптом, а не сама проблема.
По мере роста данные начинают выполнять разные функции и предъявляют разные требования к хранению. Записи вебинаров читают редко и большими кусками, база данных требует быстрых ответов, логи пишутся постоянно и почти никогда не читаются. Просто добавить объем — не значит закрыть вопросы масштабирования, отказоустойчивости и сопровождения. Их придется решать отдельно.
Серверов становится несколько, а данные приросли к одному
Дальше архитектура усложняется. Появляются отдельный сервер приложений, отдельная база данных, несколько backend-сервисов и несколько экземпляров приложения.
И тут вылезает новое. Становится видно, насколько крепко данные приросли к железу. Записи занятий и работы студентов лежат на конкретной машине. Пересобрать ее страшно, перенести долго, а нарастить вычислительные мощности, не трогая хранение, не выйдет: диск едет вместе с сервером.
Здесь и появляется потребность в хранилище, которое живет отдельно от вычислительных ресурсов. Задача у него понятная: сделать так, чтобы данные перестали зависеть от судьбы конкретной виртуальной машины. Сервер можно будет пересобрать, обновить или заменить, а хранилище останется на месте и подключится к новой машине.
Отдельно проговорю, потому что ожидание частое: одновременная работа нескольких серверов с одними и теми же файлами — это другая история, блочное хранилище устроено иначе.
Что такое сетевой диск и как он устроен
Сетевой диск — это внешнее блочное хранилище для виртуальной машины в облаке. Данные отделены от конкретного сервера, и вы управляете ими независимо от вычислительных ресурсов.
Работает это так. Вы создаете сетевой диск нужного размера, он размещается в распределенном хранилище Ceph, дальше вы подключаете его к виртуальной машине. Для ВМ он выглядит как обычный локальный диск, хотя физически данные живут отдельно. При необходимости диск отключают и подключают к другой машине.
Модель работы тут простая: один диск живет с одной виртуальной машиной за раз. Отвязали от старой, подключили к новой — данные переехали, хотя физически никуда не двигались. Так диск и превращается в переносной контейнер с данными, который вы гоняете между серверами, пока сами серверы приходят и уходят. Главное отличие от локального диска в другом. Виртуальная машина меняется, пересоздается или падает, а данные остаются в отдельном хранилище и подключаются обратно.
Надежность здесь держится на тройной репликации. Каждый блок данных хранится в трех копиях, и если что-то случится с одной копией или с оборудованием, на котором она лежит, данные останутся доступны из остальных.
В Рег.облаке сетевые диски работают на SSD, причем SSD здесь — это класс хранения, а не тип диска. Подключаются они к машинам в пределах одного региона. Объем — от 10 до 500 ГБ с шагом 10 ГБ, а больше 500 ГБ расширяют по запросу в поддержку. Размер увеличивается без миграции данных, отключение и переподключение проходят без потерь.
Какие задачи закрывает сетевой диск
Тут важнее не устройство технологии, а то, что она снимает с команды:
хранение данных отдельно от вычислительных ресурсов;
масштабирование вычислительных мощностей независимо от системы хранения;
упрощение миграции между серверами;
более удобное резервное копирование;
использование одного диска как постоянного хранилища для разных ВМ в разное время.
Отсюда и типовые сценарии. Расширение дискового пространства, когда емкость нужна, а менять локальный диск или масштабировать сервер не хочется. Аварийное восстановление без ручных операций с бэкапами, чтобы сократить время простоя. Пересоздание и обновление виртуальной машины, когда инфраструктура обновляется, а данные остаются на месте. Работа с большими объемами данных — датасетами, аналитикой, медиаконтентом, логами и временными файлами приложений, где много операций чтения и записи. И разделение окружений dev, test и prod с единым источником данных.
Где локальный диск остается на своем месте
Сетевой диск не заменяет локальный во всех случаях.
Локальный диск физически подключен к конкретному серверу, поэтому данные лежат рядом с вычислительными ресурсами. Отсюда минимальные задержки и простая архитектура. Для задач, чувствительных к задержкам, — системных файлов, временных данных, отдельных типов нагрузок — локальный диск часто остается более подходящим вариантом. Выбор зависит от архитектуры проекта и требований к хранению.
Как понять, что проект вырос из локального диска
Обычно команда приходит к этому не после одного инцидента, а когда одни и те же вещи начинают повторяться:
Требования к надежности хранения растут. Важные данные уже рискованно держать только на локальном диске сервера, для них приходится отдельно продумывать резервное копирование и восстановление после сбоя.
Масштабирование упирается в диск. Вычисления и хранение растут одним куском, поэтому под лишние гигабайты приходится трогать сам сервер.
Миграция серверов занимает больше времени. Данные привязаны к конкретному VPS, поэтому при замене или переносе сервера едет не только приложение, но и большие объемы файлов.
Резервное копирование становится менее гибким. Данные лежат на локальном диске вместе с сервером, поэтому организовать для них отдельное копирование и восстановление сложнее.
Инфраструктура всё сильнее зависит от одного сервера. Вычислительные ресурсы вы замените быстро, а данные останутся привязаны к конкретному диску.
В нашей условной онлайн-школе со временем накопились тысячи записей занятий, учебных материалов и работ студентов. Место на сервере стало регулярно заканчиваться, локальный диск приходилось увеличивать, а перенос сервера означал и перенос всех накопившихся файлов. В итоге хранение данных решили отделить от самого сервера.
Что в итоге
Универсального способа хранить данные нет. Локальный и сетевой диски закрывают разные этапы развития проекта и разные типы данных, и выбирать между ними приходится каждый раз заново — исходя из текущих задач бизнеса, устройства инфраструктуры и планов по росту.
Единственное, что стоит держать в голове с самого начала: архитектура хранения должна меняться вместе с проектом, а не оставаться неизменной просто потому, что когда-то работала.
Если захотите посмотреть, как устроены сетевые диски у нас, заходите на сайт Рег.облака.