Существует три основных способа организации систем хранения данных (СХД) в корпоративных ИТ-системах и в системах облачных провайдеров:

• Блочные системы (Block Storage)
• Файловые системы (File Storage)
• Объектные системы (Object Storage)

Блочные системы называются так потому, что хранимые в них данные разбиваются на блоки одинакового размера. Блок данных – это не файл, не законченный объект, а просто некие данные в куске фиксированного размера (по-английски – chunk). Файл данных может быть размещён в конечном числе блоков, и если последний из этих блоков остаётся незаполненным, то он все равно будет иметь тот же фиксированный размер, что и заполненные блоки. Сервер получает доступ к этим блокам через сеть подключённых систем хранения SAN (storage attached network). Каждый блок может быть представлен как отдельный диск.

Блочная СХД может быть использована любой операционной системой как дисковый том этой системы. Каждому серверу может быть предоставлен практически неограниченный размер диска. Пользователь видит этот диск в интерфейсе операционной системы сервера. ОС сервера может подключаться к блокам данных через высокоскоростные интерфейсы FC (Fiber Channel) или iSCSI. Поэтому основное достоинство блочных систем – высокое быстродействие.

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

Размер блоков определяется производителем оборудования. Однако, архитектор, разрабатывающий дизайн корпоративной ИТ-системы, может определять размер блока данных в зависимости от требований конфигурации и сценария применения. Размер блока может зависеть и от типа физических дисков в системах хранения (жёсткие диски HDD, или флеш-накопители SSD), а также и от типа самих данных клиентов. Правильный выбор размера диска, во многих случаях, помогает оптимизировать параметры работы корпоративной ИТ-системы в целом.

Операционная система сервера присваивает каждому блоку данных простой идентификатор расположения (location ID), по которому его можно быстро найти в SAN. В этом лежит причина высокого быстродействия блочной СХД.

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

Когда нужны блочные системы

Обычно, блочные системы хранения выбираются, когда, при проектировании ИТ-системы, критичными являются такие параметры, как скорость ввода-вывода данных IOPS (input output operations per second), а также задержка (latency) доступа к данным через SAN. Например, это могут быть серверы баз данных или бизнес-критичных приложений, требующих высокого быстродействия и высокой надёжности.

В таких базах данных, как Oracle или SAP Hana, используются именно блочные системы. Виртуальные машины VMware также по умолчанию используют блочное хранение, поскольку при этом можно построить быстродействующую и многофункциональную виртуальную инфраструктуру. Блочное хранение может быть также использовано практически во всех архитектурах ЦОД, будь то стандартная файловая система для сервера или высоконадёжное хранение с резервированием RAID.

Блочные системы хранения в настоящий момент являются безусловным лидером по доле в корпоративном хранении данных как в малых предприятиях, так и в ИТ-системах крупных корпораций.

Наиболее употребительные области применения блочных СХД:

• Бизнес-приложения и СУБД, корпоративные системы CRM/ERP, такие как 1С, SAP, Navision, и другие;
• Хранение данных компаний и организаций.;
• Различные системы виртуализации: рабочих мест, сетевых функций, контейнерные технологии и пр.;
• Хранение «сырых» данных, получаемых от систем Интернета Вещей (IoT).

Блочное хранение в облаке

Блочное хранение данных – очень популярная услуга облачных провайдеров. Она даёт возможность использовать такое полезное качество, как «эластичность». То есть, пользователю нет необходимости закупать оборудование для СХД с «запасом на будущее». Он может заказать у провайдера ёмкость хранения в соответствии с текущими потребностями и потом быстро «дозаказать» её при необходимости. В большинстве случаев, этот процесс может занять несколько минут. При этом данные будут хорошо защищены доступностью услуги облачного хранения и технологией репликации в облаке. Кроме того, шифрование, которое обеспечивает облачный провайдер, не позволит другим серверам, использующим ту же облачную СХД, получить доступ к чужим данных. Таким образом, когда нужно быстро и недорого расширить имеющееся блочное хранилище, то использование услуги блочной СХД в облаке может быть оптимальным вариантом.

Если говорить не о публичном, а о частном облаке ИТ-системы или дата-центра (центров) крупной организации, то и здесь можно использовать сходные механизмы блочного хранения. При этом вместо разных заказчиков, данные которых нужно разделять в облаке, будут выступать подразделения (отделы, сервисы, филиалы) этой организации. И здесь использование блочного хранения чаще всего будет предпочтительным вариантом, поскольку эта технология обеспечивает высокую скорость бизнес-процессов организации, а также достаточную гибкость перераспределения ресурсов в масштабах организации.

Достоинства и недостатки блочной СХД.

В современных центрах обработки данных (ЦОД) блочное хранение очень распространено, вследствие следующих достоинств:

1. Производительность: быстродействие блочной CХД, поэтому для приложений, требующих высоких скоростей ввода-вывода (IOPS), таких как серверы баз данных, блочная СХД является оптимальным выбором. Производительность, вкупе с низкой задержкой доступа, является главным преимуществом блочной СХД.
2. Гибкость: тома с блоками данных можно быстро переносить, расширять и добавлять по мере роста организации, без какого-либо влияния на быстродействие. Кроме того, блочную СХД можно легко переносить с одного сервера на другой, путём простого редактирования маршрута назначения.
3. Невысокая нагрузка на файловую систему: многие приложения, такие как PHP, Apache, Exchange, SharePoint ориентированы на работу с блочной СХД и могут записывать данные непосредственно в блоки. Поэтому в файловой системе исключаются дополнительные операции записи-считывания.
4. Лёгкость модификации файлов: в блочной СХД при изменении файла необходимо изменять только те блоки, которые затронуты этими изменениями. В файловой и объектной СХД для этого необходимо перезаписывать весь файл или объект.
5. Загружаемость операционной системы: ОС может загружаться непосредственно из блочной СХД через SAN. Для этого нужно, чтобы BIOS сервера (физического или виртуального) могла работать с SAN.
6. Работа с разрешениями: лёгкость управления доступом к данным.

Недостатки у блочной СХД тоже есть. К ним можно отнести следующее:

1. Привязка к серверу: блочная СХД жёстко привязана к одному серверу в каждый момент времени и не может в этот момент разрешать доступ от другого сервера в ИТ-системе. Конечно, есть некоторые программные решения, которые могут устранить данный недостаток, но это требует повышения нагрузки (overhead) на файловую систему.
2. Ограниченность метаданных: объем метаданных (определяющих, что именно хранится) гораздо меньше, чем в файловой или объектной СХД. Это может повлиять на производительность работы некоторых приложений, критичных к использованию метаданных.
3. Стоимость: она в блочных СХД достаточно высока. Хотя для заказчиков сервисов, облачная услуга блочного хранения весьма доступна по стоимости, однако, для облачных провайдеров и для корпоративных ИТ-систем это довольно затратно, поскольку системы SAN довольно дороги и часто требуют наличия высококвалифицированного персонала для их обслуживания. Кроме того, со стороны заказчиков облачных услуг всегда необходима оплата объёма блочного СХД, даже если используется не весь объём.

Итоги сравнения блочных СХД с файловыми и объектными, можно свести в следующую таблицу:

	Блочные	Файловые	Объектные
Интерфейс	Операционная система	Пользователь	Программа через API
Относительная стоимость	Высокая	Высокая	Невысокая
Быстродействие	Очень высокое	Высокое	Среднее
Ареал применения	Часть ИТ-системы, охват FC / iSCSI	Вся ИТ-система, LAN	Интернет
Сценарии	ОС, базы данных	Общий пользовательский контент, веб-контент	Медиафайлы, сети доставки контента
Масштабируемость	Ограничена областью применения	Довольно высокая	Практически неограниченная