Дисковая подсистема

Когда мы говорим  про ресурсы  дисковой  подсистемы,  то назвать  их можно три: объем места, скорость  чтения  и записи  в Мб/сек и скорость чтения-записи в количестве  операций  ввода-вывода  в секунду (Input/Output per second, IOPS,  или просто I/O).

Поговорим  сначала  про объем. Я приведу  соображения,  на которые следует ориентироваться, и пример расчета.

Соображения следующие:

Q  место на диске занимают сами файлы-диски виртуальных машин. Следовательно, нужно понять, сколько места нужно им;

Q  если для всех или части ВМ мы планируем  использовать тонкие (thin) диски, то следует спланировать их первоначальный объем и последующий рост (здесь  и далее под thin-дисками понимается  соответствующий тип vmdkфайлов, то есть функция thin provisioning в реализации ESX(i). Дело в том, что функционал thin provisioning может быть реализован на системе хранения независимо от ESX(i), и я имею в виду не функционал систем хранения);

Q  по умолчанию  для каждой ВМ гипервизор  создает файл подкачки, по раз-

мерам равный объему ее оперативной памяти. Этот файл подкачки располагается в папке ВМ (по умолчанию) или на отдельном LUN;

Q  если планируются к использованию снимки  состояния,  то под них тоже

следует запланировать место. За точку отсчета можно взять следующие соображения:

•    если снимки состояния будут существовать  короткий период после создания, например  только на время резервного копирования, то под них запасаем процентов десять от размера диска ВМ;

•    если снимки состояния будут использоваться со средней или непрогнозируемой  интенсивностью, то для них имеет смысл заложить  порядка  30% от размера диска ВМ;

•    если снимки состояния для ВМ будут использоваться активно (что актуально в сценариях, когда ВМ используются для тестирования и разработки), то занимаемый ими объем может в разы превышать номинальный размер виртуальных дисков. В этом случае точные рекомендации дать сложно, но за точку отсчета можно взять удвоение размера каждой ВМ. (Здесь  и далее под снимком  состояния понимается  соответствующий функционал ESX(i). Дело в том, что снимки состояния (snapshot) могут быть реализованы на системе хранения независимо  от ESX(i), и я имею в виду не функционал систем хранения.)

Примерная формула выглядит  следующим образом:

Объем места для группы ВМ = Количество ВМ ? (Размер диска ? T +

+ Размер диска ? S + Объем памяти – Объем памяти ? R).

Здесь:

Q  T – коэффициент тонких (thin) дисков. Если такие диски не используются, равен 1. Если используются, то абстрактно оценку дать сложно, зависит от характера  приложения в ВМ. По сути, thin-диски занимают  места на системе хранения  меньше, чем номинальный размер  диска. Так вот   – этот коэффициент показывает, какую долю от номинального размера занимают диски виртуальных машин;

Q  S – размер снимков состояния. 10/30/200 процентов, в зависимости от про-

должительности непрерывного использования;

Q  R – процент зарезервированной памяти. Зарезервированная память в файл подкачки не помещается, файл подкачки создается меньшего размера. Размер его равен: объем памяти ВМ минус объем зарезервированной памяти.

Оценочные  входные данные, для примера, см. в табл. 1.3.

Таблица 1.3. Данные для планирования объема дисковой подсистемы

Группа ВМ

Размер дисков одной ВМ, Гб

Используются тонкие диски?

Примерный размер снапшотов

Средний размер ОЗУ ВМ, Гб

Резервирование ОЗУ, %

Количе ство ВМ в группе

Инфраструктура

20

Нет

10%

2

0

15

Серверы приложений

20 + 20

Нет

10%

2

0

20

Критичные серверы приложений

20 + 80

Нет

10%

6

50

10

Тестовые и временные

20

Да

200%

2

0

20

Получаем оценку требуемого объема:

Q  инфраструктурная группа – 15 ? (20 + 20 ? 10% + 2 – 2 ? 0) = 360 Гб;

Q  серверы приложений – 20 ? (40 + 40 ? 10% + 2 – 2 ? 0) = 920 Гб;

Q  критичные серверы – 10 ? (100 + 100 ? 10% + 6 – 6 ? 0.5) = 1130 Гб;

Q  тестовые и временные  – 20 ?  (20 ?  30% + (20 ?  30%) ?  200% + 2 – 2 ?  0) =

= 400 Гб.

Всего получаем  2810 Гб. Обычно  рекомендуется размещать  8–15  ВМ на один LUN. Размер одного LUN ограничен как абсолютный максимум 2 Тб минус 512 байт.

Следовательно, мы можем  создать  два LUN  по 1,4 Тб и примерно  поровну распределить между ними виртуальные машины. Или  создать 4–5 LUN по 600– 800 Гб и поместить  машины  разных групп на разные LUN. Оба варианта  (и промежуточные  между  ними)  приемлемы.  Выбор  между  ними  делается,  исходя  из прочих предпочтений  (например, организационных).

Еще  одним  ресурсом  дисковой  подсистемы   является  производительность. В случае виртуальных машин скорость в Мб/сек не является надежным критери ем, потому что при обращении большого количества ВМ на одни и те же диски обращения  идут непоследовательно. Для виртуальной инфраструктуры более важной характеристикой является количество  операций ввода-вывода  (IOPS, Input/ Output per second).    нашей инфраструктуры должна позволять больше этих операций, чем их запрашивают виртуальные машины.

Какой путь проходят  обращения  гостевой ОС к физическим дискам в общем случае:

1.    Гостевая  ОС  передает  запрос  драйверу  контроллера SAS/SCSI (который для нее эмулирует  гипервизор).

2.    Драйвер передает его на сам виртуальный контроллер SAS/SCSI.

3.    Гипервизор  перехватывает его, объединяет  с запросами  от других  ВМ  и передает общую очередь драйверу  физического контроллера (HBA  в случае FC и аппаратного  iSCSI или Ethernet-контроллер в случае NFS и программного iSCSI).

4.    Драйвер передает запрос на контроллер.

5.    Контроллер передает его на систему хранения, по сети передачи данных.

6.    Контроллер системы хранения  принимает  запрос. Запрос  этот – операция чтения или записи с какого-то LUN или тома NFS.

7.    LUN – это «виртуальный раздел» на массиве RAID, состоящем из физиче ских дисков. То есть запрос передается контроллером СХД на диски этого массива RAID.

Где может быть узкое место дисковой подсистемы:

Q  скорее всего, на уровне физических дисков. Важно количество физических дисков в массиве RAID. Чем их больше, тем лучше операции чтения-записи могут быть распараллелены. Также чем быстрее (в терминах I/O) сами диски, тем лучше;

Q  разные уровни массивов RAID обладают разной производительностью. За-

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

•    RAID-10  – самый быстрый,  но наименее  эффективно использует пространство дисков, отнимая 50% на поддержку отказоустойчивости;

•    RAID-6  – самый надежный,  но страдает низкой производительностью на записи (30–40% от показателей RAID-10 при 100% записи), хотя чтение с него такое же быстрое, как с RAID-10;

•    RAID-5  компромиссен. Производительность на запись  лучше RAID-6  (но хуже RAID-10), выше эффективность хранения  (на отказоустойчивость забирается емкость лишь одного диска). Но RAID-5  страдает  от серьезных  проблем, связанных с долгим восстановлением данных после выхода из строя диска в случае использования современных  дисков большой  емкости и больших RAID-групп, во время  которого  остается незащищенным от другого сбоя (превращаясь в RAID-0) и резко теряет в производительности;

•    RAID-0,  или  «RAID  с нулевой  отказоустойчивостью», для  хранения  значимых данных использовать нельзя;

Q  настройки системы хранения, в частности кеша контроллеров системы хранения. Изучение документации СХД важно для правильной ее настройки и эксплуатации;

Q  сеть передачи  данных.  Особенно  если  планируется к  использованию IP

СХД, iSCSI  или NFS. Я ни в коем случае не хочу сказать, что не надо их использовать,  – такие системы давно и многими эксплуатируются. Я хочу сказать, что надо постараться убедиться, что переносимой  в виртуальную среду нагрузке  хватит  пропускной способности  сети с планируемой пропускной способностью.

Результирующая скорость дисковой  подсистемы  следует из скорости дисков и алгоритма  распараллеливания контроллером обращений  к  дискам  (имеются  в виду тип RAID и аналогичные функции). Также имеет значение отношение числа операций чтения к числу операций записи – это отношение мы берем из статистики или из документации к приложениям в наших ВМ.

Разберем пример. Примем, что наши ВМ будут создавать нагрузку до 1000 IOps, 67% из которых будет составлять чтение, а 33% – запись. Сколько  и каких дисков нам потребуется в случае использования RAID-10 и RAID-5?

В массиве  RAID-10  в операциях  чтения  участвуют  сразу все диски, а в операции  записи  – лишь половина  (потому  что каждый  блок данных записывается сразу на два диска). В массиве RAID-5 в чтении участвуют все диски, но при записи каждого блока возникают  накладные  расходы, связанные с подсчетом и изменением контрольной суммы. Можно считать, что одна операция  записи на массив RAID-5 вызывает четыре операции записи непосредственно на диски.

Для RAID-10:

Q  чтение – 1000 ? 0,67% = 670 IOps;

Q  запись – 1000 ? 0,33% = 330 ? 2 (так как в записи участвует лишь половина

дисков) = 660 IOps.

Всего от дисков нам надо 1330 IOps. Если поделить 1330 на количество IOps, заявленное в характеристиках производительности одного диска, получим требуемое количество  дисков в массиве RAID-10 под указанную  нагрузку.

Для RAID-5:

Q  чтение – 1000 ? 0,67% = 670 IOps;

Q  запись – 1000 ? 0,33% = 330 ? 4 = 1320 IOps.

Всего нам от дисков надо 1990 IOps.

По документации производителей один жесткий  диск SAS 15k обрабатывает 150–180 IOps. Один диск SATA 7.2k – 70–100 IOps. Однако есть мнение, что лучше ориентироваться на несколько другие цифры: 50–60 для SATA и 100–120 для SAS.

Закончим пример.

При использовании RAID-10 и SATA нам потребуется 22–26 дисков.

При использовании RAID-5 и SAS нам потребуется 16–19 дисков.

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

За кадром остаются методики получения требуемого для ВМ количества IOPS и отношение чтения к записи. Для уже существующей инфраструктуры (при переносе ее в виртуальные машины) эти данные можно получить с помощью специаль ных средств сбора информации, например  VMware Capacity Planner. Для инфра структуры планируемой – из документации к приложениям и собственного опыта.

Источник: Михеев М. О.  Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий