Статья опубликована в журнале «Системный Администратор»
Тестируем и выбираем тип хранилища для небольших виртуальных сред.
Введение
При построении виртуальной инфраструктуры бюджетного уровня, порой, даже у профессионалов возникает вопрос, какой тип хранилища и протокол доступа к нему использовать. Различные источники говорят по разному и часто сбивают с толку. Попробуем разобраться, как оно есть на самом деле.
Почему не FC
Безусловно лучшим решением для построения высокопроизводительных и надежных сетей хранения данных(далее СХД) для любых задач, является использование оптических каналов и Fibre Channel Prototocol(FCP).
FCP инкапсулирующий SCSI команды, изначально разрабатывался с учетом всех тонкостей блочного обмена данными. В нем отсутствуют основные недостатки классических сетевых протоколов типа TCP/UDP, в которых данные могут теряться или приходить не последовательно, что не приемлемо для SCSI. Заголовок пакета FCP минимален в отличии от того же iSCSI, что значительно сокращает накладные расходы. Аппаратные контроллеры FC — HBA(Host Bus Adapter) полностью берут на себя генерацию заголовков пакетов снимая тем самым нагрузку с центральных процессоров. А высокопроизводительные оптические каналы (2Gb/4Gb/8Gb и выше) обеспечивают надежную передачу данных на большие расстояния.
О FC и сетях хранения, построенных с его применением, написаны целые книги [1] и перечислять его достоинства можно долго, но хочется сказать о его главном недостатке.
Высокая стоимость отдельных компонентов FC(HBA, коммутаторы и тому подобное) и суммарная стоимость конечной реализации, пожалуй, является определяющим фактором заставляющим отказаться от сетей хранения на базе FC. Так же далеко не каждая инфраструктура, в том числе и виртуальная, нуждается в FC. Например для полноценной работы нескольких десятков виртуальных машин(ВМ) не обязательно строить дорогостоящую систему хранения. А все технологии, присущие виртуализации (живая миграция ВМ, высокая доступность и так далее) так же реализуемы на iSCSI или NFS. Более того, некоторые платформы виртуализации, например такие как ProxmoxVE [3] или CloudStack [2] и вовсе не умеют работать с FC, тогда использование как iSCSi и NFS доступно на всех платформах. В общем, можно сказать однозначно, что NFS и iSCSI — быть! А вот, что и где эффективнее использовать, поговорим далее.
Немного о NFS
Network File System (NFS) — является протоколом сетевого доступа к файловым системам. NFS клиенты получают доступ к файлам на NFS сервере путем отправки RPC-запросов (Remote Procedure Call) на сервер. Если разложить структуру протокола NFS по уровням эталонной модели OSI, то выглядеть это будет примерно так:
— На прикладном уровне, выполняется собственно сам NFS, осуществляющий вызовы удаленных процедур (RPC), которые и производят различные операции с файлами и каталогами на сервере.
— Далее, RPC-вызовы передаются протоколу XDR (eXternal Data Representation), который работает на презентационном уровне и является меж платформенным стандартом абстракции данных. Протокол XDR описывает унифицированную, каноническую форму представления данных, не зависящую от архитектуры вычислительной системы. При передаче пакетов RPC-клиент переводит локальные данные в каноническую форму, а сервер проделывает обратную операцию.
— После унификации данных, сервис RPC (Remote Procedure Call), с клиентской стороны обеспечивает запрос удаленных процедур и их выполнение на сервере, представляя функции сеансового уровня. На этом, слои, специфичные для NFS заканчиваются. После чего данные инкапсулируются в стандартные TCP/UDP пакеты и отправляются дальше на лежащие ниже уровни эталонной модели OSI.
Стоит отметить, что в большинстве реализаций, NFS использует именно TCP в качестве транспортного протокола.
Таблица №1. Сопоставление уровней модели OSI и NFS
На практике, NFS реализуется очень просто и абсолютно прозрачно для любых клиентских приложений, которые и не подозревают, что их данные фактически находятся на NFS-сервере.
Пожалуй, за счет своей простоты, реализация NFS-сервера и клиента присутствует во всех современных Linux/Unix дистрибутивах, а так же в новых версиях Windows Server (2008 и выше).
NFS в контексте виртуализации
Прежде всего, NFS позволяет построить масштабируемое и легкое в управлении сетевое хранилище данных без использования дорогостоящего оборудования. Для работы NFS, достаточно обычного Gigabit Ethernet.
При этом весь функционал платформ виртуализации, такой как: горячая миграция виртуальных машин, балансировка нагрузки, высокая доступность, миграция между хранилищами, доступен так же, как при использовании FC.
К минусам NFS, стоит отнести не возможность предоставления ВМ блочного устройства или его логического раздела(LUN) целиком (Raw Device Mapping), что доступно при использовании протоколов FC и iSCSI. При использовании NFS, диски ВМ могут быть только в виде файлов, что делает кластеризацию ВМ не возможной. Так же NFS, не позволяет выполнить загрузку гипервизора по сети с системы хранения.
В случае с блочными устройствами и соответствующими протоколами (FC и iSCSI) некоторые платформы виртуализации, например VMware vSphere и Citrix XenServer создают на подключенных хранилищах собственную, кластерную файловую систему(ФС), что может оказаться эффективнее NFS работающей зачастую поверх обычных ФС. В дополнение к и так весомым минусам, можно отнести отсутствие в NFS какой-либо авторизации, кроме не всегда удобной возможности разграничивать доступ к хранилищу по ip-адрессам.
Отдельным минусом хочется выделить, проблемы производительности NFS. За счет внутренних особенностей протокола и высоких накладных расходов, связанных с инкапсуляцией нескольких протоколов высокого уровня в стандартный пакет TCP, сокращается объем полезной нагрузки (реальных данных) в пакете. Для оптимизации производительности и отказоустойчивости NFS, необходим ряд более тонких настроек, выполнение которых можно отнести к минусам протокола.
Вопросам оптимизации производительности будет просвещена отдельная статья.
Немного о iSCSI
Internet Small Computer System Interface () – сетевой протокол, обеспечивающий взаимодействие объектов (Целей и Инициаторов) в сетях хранения данных. Стоит обратить внимание на то, что в данной статье рассматривается только программно реализуемый iSCSI. Поэтому, под объектами подразумеваются серверы, операционные системы, платформы виртуализации выступающие в роли Инициаторов и блочные устройства расположенные в системах хранения (являющиеся Целями). В iSCSI, так же как и в FC транслируются SCSI команды, а данные передаются блоками только в качестве транспорта, iSCSI использует стандартный стек TCP/IP вместо FCP, а средой передачи являются стандартный Ethernet(1Gb/10Gb) вместо более надежной оптики.
Таблица №2. Уровни протокола iSCSI.
По функционалу, iSCSI, очень похож с FC, но значительно дешевле. Сегодня, программная реализация iSCSI доступна во всех современных ОС, а основной сферой его применения является виртуализация, в которой он поддерживается практически всеми платформами.
В контексте виртуализации iSCSI позволяет так же как и в случае с NFS, построить масштабируемое сетевое хранилище с возможностью использовать все присущие виртуализации функции.
К особенностям iSCSI в противовес NFS можно отнести возможность предоставления виртуальным машинам, диска (LUN в терминологии SCSI) целиком (Raw device mapping), что позволяет строить кластеры из нескольких ВМ. Так же на LUN-ах можно размещать произвольную файловую систему. В случае с iSCSI, возможна авторизация по связке имени и пароля.
К минусам, можно отнести более сложный чем с NFS, процесс настройки требующий немного больше навыков. Так же как и в случае с NFS, iSCSI имеет большие накладные расходы в связи со многоуровневой инкапсуляцией данных.
Тестовый стенд NFS vs iSCSI
Так как тема статьи ориентированна на инфраструктуры начального уровня то и тестовый стенд решено было собрать крайне бюджетный.
В качестве хранилища был выбран старый сервер с одноядерным процессором, 1 гигабайтом оперативной памяти и обычной сетевой картой Gigabit Ethernet без TOE (TCP Offload Engine). Дисковая система была представлена тремя новенькими SATA дисками.
В качестве ОС был выбран CentOS 6.3 установленный на отдельный жесткий диск не задействованный в тестах.
Один из жестких дисков был отформатирован в ext4 и выполнял роль NFS хранилища. Использовался NFS версии 4.
Последний из трех жесткий диск без каких либо приготовлений был полностью экспортирован как iSCSI-Target.
Использовался tgt версии 1.0.24
LVM(Logical Volume Management) использовался только на диске с ОС!
Прмечание: Я специально не акцентирую внимание на марках оборудования и конкретных частотах/оборотах и других характеристиках. В рамках данного тестирования, проводится сравнение двух протоколов относительное друг друга, и выявление создаваемой ими нагрузки на одном и том же оборудовании и тех же задачах.
Безусловно, данная конфигурация не является примером системы хранения даже для домашнего использования. А показатели ее производительности будут больше пугающими чем оптимистичными. Но, для сравнительного тестирования большего, на мой взгляд, ничего и не нужно.
В качестве узла виртуализации был выбран не менее бюджетный, но более производительный сервер с двухядерным процессором, 8 гигабайтами памяти и обычной сетевой картой Gigabit Ethernet без каких либо аппаратных функций.
В качестве ОС использовался Proxmox VE 2.1.
Методика тестирования
Так как в случае с NFS, диски ВМ могут храниться только в виде файлов. А iSCSI-диски могут быть подключены к ВМ напрямую. Было решено создать на NFS хранилище диск ВМ в размер всего хранилища в формате RAW дабы немного уровнять позиции протоколов.
Базовые тесты
На Proxmox-хосте был создана виртуальная машина с установленной ОС Windows Server 2003 Enterprise R2 (образ ее лежал на отдельном хранилище).
К виртуальной машине, в качестве локальных SCSI-дисков были подключены iSCSI-диск на прямую и RAW-файл с NFS-хранилища.
Вначале были проведены синтетические тесты производительности дисков с использованием ПО HD Tune Pro v3.50 внутри ВМ.
Далее были выполнены практические тесты с копированием различного рода данных.
Утилита FIO (Flexible I/O tester)[4]
На сегодняшний день, это, пожалуй, наиболее перспективное средство для тестирования дисковых массивов и систем хранения. В отличии от классического iometer [5], последний релиз которого датируется 2006 годом, FIO активно развивается и совершенствуется. Утилита позволяет гибко описать тесты с помощью конфигурационных файлов, в которых можно задать любые условия.
Для использования FIO, была установлена ВМ с ОС Ubuntu 12.04 к которой были подключены оба тестируемых хранилища в качестве локальных SCSI-дисков.
Конфигурация тестов
Тест на чтение
Запуск: fio read.ini
Содержимое read.ini
[readtest]
blocksize=4k
filename=/dev/<имяТестируемогоДиска>
rw=randread
direct=1
buffered=0
ioengine=libaio
iodepth=32
Тест на запись
Запуск: fio write.ini
Содержимое write.ini
[writetest]
blocksize=4k
filename=/dev/<имяТестируемогоДиска>
rw=randwrite
direct=1
buffered=0
ioengine=libaio
iodepth=32
Каждый тест был проведен по три раза после чего в таблицу заносилось среднее значение. Тестирование проводились последовательно. Вначале с одним хранилищем, затем с другим. В один момент времени в работе было только одно хранилище! Кроме выполняемых тестов, ни сервер выполняющий функции хранилища, ни узел виртуализации не были заняты другой работой, кроме стандартных процессов ОС.
Результаты тестирования
Результаты FIO
Выводы
Как видно, из сводных таблиц, в большинстве тестов, на одном и том же оборудовании и тех же задачах, iSCSI показывает лучшие результаты производительности. При использовании iSCSI нагрузка на ЦПУ как на хосте, так и у ВМ значительно выше. Такая же ситуация и с нагрузкой на сеть. В тех же задачах, iSCSI генерирует значительно больше трафика чем NFS. В свою очередь нагрузка NFS более равномерная и прогнозируемая.
Отдельно хочется отметить, сильную деградацию производительности NFS при большем количестве операций записи. И хотя в некоторых синтетических тестах на запись, NFS показала лучший результат, время самих тестов, было значительно дольше, чем в случае с iSCSI. В практических же тестах на запись, хорошо видны более высокие показатели iSCSI.
Ссылки
1. Основы проектирования СХД на базе FC — http://www.all-ebooks.com/2012/11/19/249511-osnovy-proektirovanija-san.html
2. Краткий обзор последней версии CloudStack —http://www.opennet.ru/opennews/art.shtml?num=35271
3. Обзор Proxmo VE 2.1 — http://www.servernews.ru/articles/595907
4. Утилита FIO и тонкости замера производительности хранилищ —http://habrahabr.ru/post/154235/
5. Тестирование с помощью программы IOmeter — http://habrahabr.ru/post/78632/
Помогла ли вам статья?
