Бюджетная виртуализация. NFS vs iSCSI, что выбрать?

Статья опубликована в журнале «Системный Администратор»

Тестируем и выбираем тип хранилища для небольших виртуальных сред.

Введение

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

Почему не 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 в качестве транспортного протокола.
Уровни NFSТаблица №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) вместо более надежной оптики.
Уровни iSCSIТаблица №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

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

Результаты тестирования
Производительность NFS и iSCSI

Результаты FIO

fio NFS iSCSIВыводы

Как видно, из сводных таблиц, в большинстве тестов, на одном и том же оборудовании и тех же задачах, 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/