Проектирование ЦОД, виртуализация: Жесткие диски, СХД и IOPs !!!

Disclaimer: данная статья не является каким либо Best Practice от какого либо вендора и является осмыслением собственного опыта, а так же понимания процессов. Вся информация предоставляется "as is" без каких либо гарантий. Данная статья является продолжением общего цикла о виртуализации на Windows Server 2012, ссылки на другие статьи см. в конце;

Не многие задумываются о значении СХД при построении решений виртуализации, а так же значении системы доступа сервера виртуализации к СХД (iSCSI, FC, FCoE, SAS). Однако, даже имея супер мощные серверные платформы СХД может стать тем узким местом, которое сделает Вашу виртуализированную инфраструктуру нежизнеспособной, несущей больше рисков, чем выгоды.

Для начала кратко резюмируем то, что мы знаем о СХД, протоколах и методах соединения хранилищ и серверов и т.д. Итак...

Диски

Диски обладают следующими характеристиками:

• интерфейс подключения (SAS, SATA и т.д.)
• скорость вращения шпинделя Rotaitions Per Minute (RPM)
• количество операций ввода - вывода в секунду
• время "случайного" доступа к данным
• кэш (ОЗУ)

Интерфейс подключения -  отвечает за скорость передачи данных от шины к диску и обратно. Каждый интерфейс имеет свои скоростные характеристики:

ПРИМЕЧАНИЕ! Информация в таблицах могла устареть или измениться с момента написания статьи.

Interface	Alternative	Specification	Clock	Maximum
	Names	Document		Throughput (MB/s)	Throughput (Mbit/s)
SSA	Serial Storage Architecture		200 MHz	40 MB/s	320 Mbit/s
SSA 40			400 MHz	80 MB/s	640 Mbit/s
Fibre Channel 1Gbit	1GFC		1 GHz	100 MB/s	800 Mbit/s
Fibre Channel 2Gbit	2GFC		2 GHz	200 MB/s	1600 Mbit/s
Fibre Channel 4Gbit	4GFC		4 GHz	400 MB/s	3200 Mbit/s
Fibre Channel 8Gbit	8GFC		8 GHz	800 MB/s	6400 Mbit/s
Fibre Channel 16Gbit	16GFC		16 GHz	1600 MB/s	12.8 Gbit/s
SAS 1.1	Serial attached SCSI	INCITS 417-2006	3 GHz	300 MB/s	2400 Mbit/s
SAS 2.0		INCITS 457-2010	6 GHz	600 MB/s	4800 Mbit/s
SAS 3.0		T10 Project: 2212-D for approval	12 GHz	1200 MB/s	9600 Mbit/s
IEEE 1394	Serial Bus Protocol (SBP)	IEEE Std. 1394-2008		400 MB/s	3200 Mbit/s
SCSI Express	SCSI over PCIe (SOP)	T10 pre-standard	8 GT/s	985 MB/s	7877 Mbit/s
USB Attached SCSI	UAS	INCITS 471-2010	5 Gbit/s	~400 MB/s	~3200 Mbit/s
ATAPI	ATA Packet Interface	NCITS 317-1998	33 MHz DDR	133 MB/s
SCSI-1	Narrow SCSI	SCSI-1 (1986)[15]	5 MHz	5 MB/s	40 Mbit/s
Fast SCSI		SCSI-2 (1994)	10 MHz	10 MB/s	80 Mbit/s
Fast-Wide SCSI		SCSI-2;	10 MHz	20 MB/s	160 Mbit/s
		SPI-5 (INCITS 367-2003)
Ultra SCSI	Fast-20	SPI-5 (INCITS 367-2003)	20 MHz	20 MB/s	160 Mbit/s
Ultra Wide SCSI		SPI-5 (INCITS 367-2003)	20 MHz	40 MB/s	320 Mbit/s
Ultra2 SCSI	Fast-40	SPI-5 (INCITS 367-2003)	40 MHz	40 MB/s	320 Mbit/s
Ultra2 Wide SCSI		SPI-5 (INCITS 367-2003)	40 MHz	80 MB/s	640 Mbit/s
Ultra3 SCSI	Ultra-160; Fast-80 wide	SPI-5 (INCITS 367-2003)	40 MHz DDR	160 MB/s	1280 Mbit/s
Ultra-320 SCSI	Ultra-4; Fast-160	SPI-5 (INCITS 367-2003)	80 MHz DDR	320 MB/s	2560 Mbit/s
Ultra-640 SCSI	Ultra-5; Fast-320	SPI-5 (INCITS 367-2003)	160 MHz DDR	640 MB/s	5120 Mbit/s

 http://en.wikipedia.org/wiki/SCSI

 

Название	Пропускная способность шины (Mbit/s)	Скорость передачи (MB/s)
eSATA	3 000	300
eSATAp
SATA revision 3.0	6 000	600
SATA revision 2.0	3 000	300
SATA revision 1.0	1 500	150
PATA 133	1 064	133.5
SAS 600	6 000	600
SAS 300	3 000	300
SAS 150	1 500	150

 http://ru.wikipedia.org/wiki/SATA

ПОДСКАЗКА! В данной статье содержиться сравнительное тестирование дисков с разными интерфейсами и производительностью (от 24.08.12) http://www.sgidepot.co.uk/diskdata.html

Скорость вращения шпинделя диска - отвечает за скороть доступа к данным с диска. Операции чтения или записи, осуществляемые на дисках, определяются, как ввод или вывод (I/O operations per second) или IOPs.

Существует несколько  показателей, которые были бы нам интересны:

• Read IOPs – Суммарное количество операций чтения которые осуществляются за секунду
• Write IOPs – Суммарное количество операций записи которые осуществляются за секунду
• Total IOPs – Суммарное количество операций записи/чтения которые осуществляются за секунду
• Averange Random Access Time - время случаяного доступа к данным на диске
• Queue Lenght- очередь диска.

Каждый тип диска имеет определенное количество IOPs-ов, средние данные по дискам примерно следующие:

RPM	IOPS
15000 RPM	~155-170
10000 RPM	~110-125
7200 RPM	~65-85

ПРИМЕЧАНИЕ! Данные приблизительные и могут отличаться от вашей конкретной ситуации. Для уточнения проведите тестирование дисков своей СХД или серверов.

Среднее время "случайного" доступа к данным или Averange Random Access Time - отвечает за скорость, с которой механизм жесткого диска может позиционировать головку чтения или записи  над нужной дорожкой. Время доступа - величина переменная, она полностью зависит от начального и конечного положения головок, поэтому в качестве характерного показателя выбирают среднее время доступа. В некоторых дисках данные размещаются не по всей пластине, а только по ее крайней части, что позволяет увеличить скорость чтения и тем самым существенно уменьшить время доступа.

Очередь диска - даёт нам понять количество запросов, ожидающих обслуживания. Количество ожидающих запросов ввода-вывода должно соответствовать продолжительности не более чем 1,5—2 оборота шпинделя, производимых физическим диском. К примеру, для 8 дискового массива длинна очереди не должна быть выше 14-16 при пиковой загрузке.

Интерфейсы подключения СХД к серверам и кэш RAID контроллера дисков

Это те элементы, которые возникают при взаимодействии хоста (сервера) с дисковой подсистемой и её контроллером. Чем выше скорость передачи данных, тем быстрее процессор получит возможность их обработать и не будет простаивать в состоянии idle.

Однако тут не всё так просто. Скорость передачи данных дисковой подсистемы можно условно разделить на две части:

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

вторая: взаимодействие дискового контроллера и его кэш с хостом (процессором, ОЗУ и т.д.) (Frontend - between Application and Logical Volume)

Тут особую роль играет несущая или метод коммутации и протокол, а так же кэш.

Сначала о подключениях СХД в серверу: SAS интерфейс (может быть и Shared SAS), FC, DAS, Ethernet Network Adapter (iSCSI) или Ethernet  HBA  и т.д. Если говорить о количестве необходимых интерфесов подключения необходимо понимать два фактора:

• Обязательно надо понимать, что стабильную работу виртуализированных сервисов компании даст не только отказоустойчивость на основе самих приложений, но и  на аппаратном уровне, поэтому чаще всего встречается рекомендации о минимум двух адаптерах подключения  от СХД к каждому узлу кластера; Так же наличие дублирующих элементов (соединения в кросс, запасных коммутаторов (если используются) и т.д.)
• Достаточная пропускная способность интерфейсов. Здесь имеет смысл подумать о количестве информации, которая будет передаваться по этим интерфесам в разных режимах: загрузка ВМ, операционная нагрузка, при обращениях к сервисам ВМ (к примеру: базам данных), служебный трафик сетевых пакетов и узлов координаторов кластеров; Будет ли вам достаточно 1 Gbps сетевого адаптера или вам надо приобретать HBA 10 Gbps, или FC, а сколько их нужно? Последний пункт тоже влияет на стоимость решения...

Как определить достаточно ли пропускной способности? Частично тут нам может помочь MAP - Microsoft Assesment and Planning Toolkit (о данной утилите я писал встатье http://www.techdiving.pro/2012/10/blog-post_16.html). При оценке готовности к виртуализации этот solutions accelerator собирает данные о работе дисковых подсистем физического сервера: объёме данных и затрачиваемых IOPs (Maximum, Avarange) и другую полезную информацию.

Мы можем пересчитать затрачиваемые IOPs в мегабайт в секунду, к примеру, и тем самым получить примерный объём передаваемого трафика по сети к хранилищу (полоса пропускания). Да, к этому трафику так же добавится служебная информация, используемая протоколом транспортировки данных и это тоже можно учесть (объём служебной информации будет различаться, в зависимости от протоколов передачи данных).

MB/s = (IOPs * KB per IO) / 1024 , где KB per IO = размеру кластера на диске.

К примеру, у нас есть 25 серверов, потребляющих 85 IOPs в среднем, т.е.

((25*85)*4)/1024  = ~8,5 Mb/s (или ~66,4 Mbps), вроде бы одна карта 1 Gbps справится и плюс одна для резервирования, но существует не просто  режим стабильной работы, а так же загрузка систем и пиковые часы. Это тоже необходимо учитывать, чтобы понять возможные максимумы, которые необходимо заложить в рассчёт (опять же в этом нам поможет MAP или различные стресс-тест эмуляторы или методики рассчётов, которые существуют для продуктов Microsoft).

ПРИМЕЧАНИЕ! Не забывайте о том, что дополнительную нагрузку на СХД дают не только виртуальные машины, но и процессы, запускаемые на них (к примеру: проверка антивирусом виртуального рабочего места может очень серьёзно нагрузить СХД)

Так же мы можем пойти от обратного, к примеру, зная только размер кластера диска и объём данных, к примеру в мегабайтах в секунду,  которые мы будет прогонять по сети, мы можем определить и полосу пропускания (в секунду, в минуту, в час), но  и IOPs, которые необходимо получить от СХД..

IOPS = MB/s Throughput  * 1024  / KB per IO , где Mb/s Throughput можно получить, разделив утилизацию полосы пропускания в Mbps на 8.

Конечно в данных рассчётах существует погрешность, но в целом, исходя из показателей моего тестового стенда - это вполне похоже на правду (см. раздел статьи "К делу").

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

MPIO Policies on TechNet

ПРИМЕЧАНИЕ! В Hyper-V 3.0, на сегодняшний день, нет возможности зарезервировать определённое количество IOPs за конкретной виртуальной машиной, только для хоста виртуализации или группы хостов. Такая возможность появиться в Windows Server 2012 R2, судя по CTP редакции, и будет называться Storage QoS.

А теперь о кэш:

Скорость взаимодействия процессора и оперативной памяти намного выше, чем время доступа к информации на диске. Именно для выравнивания этой разницы был придуман кэш диска (дисковой подсистемы или контроллера RAID).

Кэш устройств хранения или контроллеров увеличивает производительность системы за счёт оптимизации использования операций ввода-вывода.

Итак, на скорость доступа к данным влияют не только сами диски, но и кэш даннных котроллера и дисков, а так же технология передачи данных от контроллера к узлу виртуализации. Это необходимо учитывать при выборе дискового массива, контроллера и определении протокола взаимодействия между СХД и хостами. О некоторых нюансах использования iSCSI и FCoE.

ПРИМЕЧАНИЕ! Иногда необходимо отключить кэширование, такие ситуации возникают, когда целостность данных превалирует над скоростью считывания-записи.

Так же стоит обратить внимание на функционал Native Command Queue у дисков (см. ссылки).


RAID массивы

К сожалению, у каждого RAID массива есть определённое количество операций связанных с записью каких либо данных на массив. Данный "Administrative penalty", пожалуй назовём это так, способен существенно сказаться на производительности массива.

RAID	I/O Penalty
RAID 0	1
RAID 1	2
RAID 5	4
RAID 6	6
RAID 10	2
RAID DP	2

К делу...

Итак, для теста я использовал полку NetApp FAS 2040 с 12 SATA 7,2 RPM дисками на RAID DP. Полка соединена с серверами виртуализации:

• 2 сервера по 2 сетевых адаптера 1 Gb/s;
• 1 сервер по FC;
• 4 Ethernet адаптера по 1 Gbps на СХД

При создании платформы виртуализации не стоит экономить на СХД и дисках, к примеру, следующий график показывает, что происходит с полкой, при единовременном старте 8 виртуальных машин (замечу, что 2 из трех хостов виртуализации соединены с полкой по iSCSI 1 Gb/s).

Исходя из данных, которые я привёл, вы можете легко понять максимальную производительность системы хранения данных (о том, как посчитать производительность дисковой подсистемы в разных режимах см. ниже), и представить, что будет при единовременном старте или высокой утилизации 75 виртуальных машин , которые развёрнуты в нашем демо облаке на сегодняшний день.

Недостаточная производительность дисковой подсистемы может вызвать сбои в загрузки сервисов и самих операционных систем, либо сильно увеличит время прихода виртуальной машины в рабочее состояние, когда она способна обрабатывать запросы пользователей. Именно поэтому необходимо планировать порядок загрузки виртуальных машин и время "паузы", через которое те или иные машины будут стартовать в зависимости от приоритета. Более того, время отклика GUI интерфейсов виртуальных машин так же зависит от скорост работы СХД.

Так же надо помнить о том, что Windows оперирует блоками памяти по 4К и для оптимизации процесса записи данных на диск ОС формирует блоки по 1Mb (т.к. Windows считает, что использует локальный, выделенный ей одной диск, такие диски хороши при записи большых блоков). Однако, гипервизоры, получая данные от виртуальной машины сначала разбивают их на части, подходящие по размеру под сектор диска, а затем  пишут в рандомно выбраные сектора, что может вызвать падение производительности, особенно в RAID массивах с высоким административным пенальти.

В зависимости от процентного соотношения количества операций ввода/вывода СХД будет демонстрировать разную производительность. Давайте рассмотрим на конкретном примере.

Существуют формулы расчёта для различного рода сценариев, мы созьмём два:

• Производительность полки при 85% операций записи и 15% чтения RAID 10 (или DP)
• Производительность полки при 85% операций чтения и 15% записи в RAID 10 (DP)

Они помогут нам понять приближенные к максимуму значения.

Итак, для начала расчитаем максимальную производительность IOPs полки. Для этого мы умножаем количество дисков на количество поддерживаемых дисками IOPs.

~ TotalIOPs = 12 * 75 = 900 IOPs

Теперь рассмотрим первый сценарий, для этого нам необходимо выполнить рассчёт по формуле ниже:

WriteScenarioIOPs = ((TotalIOPs * 0,85)/ (RAIDPenalty)) + (TotalIOPs * 0.15)

итого получаем WriteScenarioIOPs  ((900 * 0,85)/ (2)) + (900 * 0.15) = 517,5 IOPs пиковой нагрузки.

А для второго сценария ReadScenarioIOPs мы изменим проценты, а формула прежняя:

ReadScenarioIOPs = ((900 * 0,15)/ (2)) + (900 * 0.85) = 832,5 IOPs

В итоге мы видим, что СХД с суммарной производительностью в 900 IOPs выдаёт 517,5 IOPs при активной записи и 832,5 при активном чтении. Замечу, что при RAID 5 результаты были бы минимум в двое ниже для сценария записи.

Пример: Quick Migration 12 виртуальных машин, используемых для тестовых целей, с одного узла кластера на другой.

При загрузке сетевого адаптера 1 Gbit/sec  iSCSI на 50-55% максиму, миграция съела в пиковую нагрузку 1000 - 1100 IOPs/sec (к сожалению со скриншотом поторопился:)) но в среднем варьировалась от 550 до 780 IOPs/sec.

При этом  производительность СХД реально составляла ~500 - 670 IOPs в секунду (тут есть погрешность). Посему процесс миграции происходил достаточно долго (более 3-х минут). Естественно, что при высокой загрузке виртуальных машин этот процесс мог бы растянуться на большее время.

Мы можем скоректировать производительность СХД, получив количество необходимых дополнительных дисков, зная количство необходимых IOPs.

Для этого надо:

DisksRequired = ((IOPs%Read + (IOPs%Write * RAIDPenalty))/IOPsPerDisk

IOPs%Read = количество планируемых пиковых операций чтения
IOPs%Write = количество планируемых пиковых операций записи
RAIDPenalty = административный пенальти
IOPsPerDisk = операций ввода/вывода, которые поддерживает выбранный носитель

Так же, мы можем понять сколько IOPs требуется конкретному приложению или системе исходя из следующих счётчиков производительности (Опять же не забываем про MAP, и максимальные значения показаний счётчиков):
 

Microsoft Windows Performance Counter	Industry Standard IOPS Name
Disk Transfers/sec	Total IOPS
Disk Reads/sec	Read IOPS
Disk Writes/sec	Write IOPS
Disk Queue	-

Так же можно воспользоваться информацией от ПО управления HBA адаптерами или самой СХД.

Для отслеживания состояния CSV можно воспользоваться набором счетчиков


А для iSCSI, помимо базовой сетевой статистики интерфейса iSCSI, можно использовать следующий набор



Надеюсь, что кратко изложенная здесь информация и методики, помогут Вам  в принятии определённых решений в отношении СХД для Вашей платформы виртуализации. Буду рад Вашим комментариям или дополнениям.


Ссылки
http://en.wikipedia.org/wiki/Hard_disk_drive
http://en.wikipedia.org/wiki/Hard_disk_drive_performance_characteristics
http://en.wikipedia.org/wiki/Disk_buffer
http://en.wikipedia.org/wiki/Native_Command_Queuing
http://en.wikipedia.org/wiki/Tagged_Command_Queuing
http://en.wikipedia.org/wiki/IOPS
http://recoverymonkey.org/2012/07/26/an-explanation-of-iops-and-latency/
http://www.ssdfreaks.com/content/599/how-to-convert-mbps-to-iops-or-calculate-iops-from-mbs
http://habrahabr.ru/company/netapp/blog/102059/ - про FCoE и iSCSI плюсы и минусы
http://blogs.technet.com/b/askpfeplat/archive/2013/03/10/windows-server-2012-hyper-v-best-practices-in-easy-checklist-form.aspx
http://technet.microsoft.com/en-us/magazine/dd744830.aspx
http://www.shofkom.com/2010/04/15/moving-the-pagefile-to-another-drive-in-windows-server-2008/
http://theithollow.com/2012/03/understanding-raid-penalty/

Другие стати цикла
Проектирование ЦОД, виртуализация: как правильно обеспечить требования к производительности виртуальной машины
Проектирование ЦОД, виртуализация: как расчитать требования к аппаратному обеспечению для виртуализации инфраструктуры
Проектирование ЦОД, виртуализация: виртуализация "ЗА" и "ПРОТИВ"


Подборка ресурсов по VDI (немного устаревшие, но полезные)


Atlantis Computing
http://www.atlantiscomputing.com/win7iops  
Citrix Virtual Desktop Resource allocation
http://community.citrix.com/display/ocb/2010/11/12/Virtual+Desktop+Resource+Allocation  
IOMeter
http://www.iometer.org/  
WinSAT
http://technet.microsoft.com/en-us/library/cc742157(WS.10).aspx  
Performance Analysis of Logs (PAL) Tool
http://pal.codeplex.com/  
Win7 perfmon

http://technet.microsoft.com/en-gb/library/cc749249.aspx  
Logman

http://technet.microsoft.com/en-us/library/cc788121(WS.10).aspx  
ESXTop

http://communities.vmware.com/docs/DOC-5490 http://www.yellow-bricks.com/esxtop/  
ESX Storage Queues and Performance

http://communities.vmware.com/docs/DOC-6490  
XenServer Storage

http://support.citrix.com/article/ctx119088  
Understanding Memory Resource Management in VMware ESX 4.1
http://www.vmware.com/files/pdf/techpaper/vsp_41_perf_memory_mgmt.pdf  
SSD performance

http://www.ssdperformanceblog.com/2010/07/free-space-and-write-performance/  
VDI for developers
http://ultrasub.nl/2011/05/05/vdi-and-iops/