ЦОД. Конвергентные системы хранения данных

В любой организации, желающей автоматизировать свои процессы с помощью IT, задействовано множество прикладных систем. Каждая из этих систем, как правило, работает с определенным набором данных. В процессе своего развития отрасль пришла к состоянию, когда для хранения разрозненных наборов данных используют одну или несколько специализированных систем хранения. Такая консолидация ресурсов, безусловно, положительно сказывается на удобстве администрирования и доступности данных.

Отдельной задачей в таком сценарии стоит производительность при обращении к данным. Причина все та же – консолидация ресурсов, только теперь уже в несколько другом аспекте. А именно – наличие среды виртуализации, когда в пределах одного сервера работают несколько прикладных систем. Роль сервера – передавать их дисковые запросы на СХД. Здесь важным является тот факт, что сервер никак не упорядочивает дисковые операции при отправке в сторону СХД. В итоге, даже если изначально мы имели дело с двумя потоками последовательных операций чтения, то, в результате локальной буферизации на сервере, перед отправкой к СХД, эти два потока перемешаются друг с другом, и на СХД придет один поток, но уже случайных операций ввода-вывода. Этот явление в литературе получило название “Эффект блендера” (Blender effect).

Думаю, для большинства читателей вопрос “почему случайные операции выполняются медленнее последовательных” не является сложным. Однако, чтобы не оставлять белых пятен и рисовать единую картину, дам краткое пояснение. Проблема эта характерна для механических (магнитных) дисков. Когда такому диску приходит задание прочитать/записать несколько блоков данных, то значительное время он тратит на поиск места чтения/записи, т.к. для этого необходимо передвинуть магнитную головку в требуемое место. Для последовательных операций такую операцию нужно сделать однажды, а дальше – просто читать секторы друг за другом. Для случайных операций – необходимо выполнять позиционирование каждый раз заново.

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

Задачу можно решать несколькими способами.

Первый – вертикальное масштабирование существующих СХД. Фактически, добавление модулей RAM и дисков SSD. Плюсы и минусы такого подхода понятны. Плюсы – мы ничего не меняем и не перенастраиваем в архитектуре СХД, просто делаем устройство быстрее. Минусы – такие фокусы можно проворачивать лишь до определенного предела. Этот предел задает производитель, ограничивая количество слотов для установки модулей памяти и дисков SSD. Соответственно, этот подход идеален для тех случаев, когда существующая нагрузка растет медленно, а в СХД еще полно места для установки кэша. Хотелось бы обратить внимание, что в этом подходе важно, что SSD может использоваться именно как промежуточное звено хранения данных (кэш, или, при наличии лицензии на autotiering, один из уровней tier). Если, к примеру, производитель говорит, что в его СХД можно включить 100 дисков SSD – уточните, как они будут использоваться? Ведь одно дело, когда они задействованы в роли быстрой памяти, и улучшают производительность при обращении СХД в целом. А совсем другое дело, когда эти диски можно лишь объединить в RAID и отдать в виде LUN клиентам СХД. В этом случае производительность будет хороша лишь для этого LUN, а остальным не достанется ничего.

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

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

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

Для доступа к распределенной файловой системе требуется комплементарный компонент – клиентская часть, устанавливаемая на каждый гипервизор (в виде компонента операционной системы или в виде гостевой виртуальной машины). Фактически, это некий прокси. В сторону гипервизора он имеет стандартные протоколы сетей хранения данных (iSCSI, NFS), благодаря чему гипервизор “видит” дисковое пространство для размещения файлов виртуальных машин. В сторону же конвергентной СХД — работает некий внутренний протокол поверх стандартного транспорта TCP/IP. Собственно, секретный соус каждого производителя конвергентных СХД отчасти определяется алгоритмами работы между клиентской и серверной частями, а также тем, как располагаются данные в распределенной файловой системе. Для решения задачи распределения нагрузки клиентская часть работает в режиме балансировки, направляя запросы на разные серверы. В дополнение, каждый файл хранится в глобальной файловой системе в виде набора блоков заданного размера. Для увеличения производительности, разные блоки записываются на разные диски. Соответственно, при выполнении операций чтения можно считывать файл сразу с нескольких дисков нескольких серверов.

В дополнение к горизонтальной масштабируемости у конвергентных СХД есть еще одно свойство, облегчающее работу администратору. Оно проявляется в сценарии, когда планируется иметь три площадки для запуска приложений. В такой ситуации конвергентные СХД могут организовать синхронную репликацию данных между всеми тремя площадками. Это избавит администратора от необходимости помнить, где хранятся копии того или иного тома данных и может быть актуально, к примеру, в сценарии Disaster Recovery. А именно, вне зависимости от того, на какой из площадок перезапустятся приложения – там уже будет локальный экземпляр данных, с которым можно работать. Немного подробнее об этом сценарии, а также о конвергентных СХД в целом вы можете найти в материалах по теме.