Light-electric.com

IT Журнал
11 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Виртуальная машина на ssd

Годовая
подписка
на
Хакер

Xakep #251. Укрепляем VeraCrypt

Xakep #250. Погружение в AD

Xakep #248. Checkm8

Xakep #247. Мобильная антислежка

Переходим на SSD: как строили систему хранения данных в виртуализированной среде

Содержание статьи

Несколько лет назад начался переход от colocation к облачной модели ИТ-сервисов. Запросы рынка к облачным сервисам оказали существенное влияние на развитие систем хранения данных и требования, предъявляемые к их производительности.

Выбор СХД для корпоративного облака

При использовании виртуализации для корпоративного облака нагрузка со стороны виртуальной инфраструктуры на систему хранения произвольная. Разные приложения одновременно обращаются к СХД с разным профилем нагрузки — распределение ее невозможно спрогнозировать. При этом должны соблюдаться жесткие требования к количеству операций ввода-вывода (IOPS) и времени отклика (latency).

Под такой тип нагрузки лучше всего подходят системы хранения данных, построенные на базе твердотельных накопителей (SSD). Но еще несколько лет назад емкость SSD-накопителей была небольшой, а цена — очень высокой, что ощутимо влияло на конечную стоимость сервиса.

Чтобы найти баланс между высокой производительностью и большим объемом невостребованного дискового пространства, в виртуальном дата-центре можно использовать SSD-кеш на всех системах хранения (в пределах 5–15% от общей дисковой емкости), что снизит время отклика и увеличит производительность без добавления избыточного количества дисков. Высокая производительность такого подхода хорошо ощутима на решениях VDI (Virtual Desktop Infrastructure), где дедуплицированные данные занимают мало места в кеше и при этом создается впечатление, что диски виртуальных серверов размещены на SSD-томе.

WARNING

NetApp FAS3250

Рассмотрим системы хранения данных виртуального дата-центра, построенного на оборудовании HPE и NetApp. Эти компании лидируют в производстве быстрых, гибких и отказоустойчивых систем хранения, их СХД дают максимальную производительность при разнородной нагрузке.

Первой продуктивной системой хранения с использованием SSD-кеша была NetApp FAS3250, в которую устанавливались Flash Cache PCI-платы емкостью 1 Тбайт на каждый контроллер. Далее нарастить полезную емкость без снижения производительности позволили смешанные дисковые полки Flash Pool (по четыре SSD-диска на каждую полку с дисками других типов). Такой вид кеширования (Flash Pool) позволял ускорять операции чтения и записи, что было невозможно при использовании Flash Cache.

В основе архитектуры Data ONTAP (ОС NetApp) лежит файловая система WAFL (Write Anywhere File Layout), которая новые данные всегда пишет в свободное место, как при последовательной записи, что позволяет таким системам хранения иметь небольшой RAM-кеш контроллера при высоких показателях производительности. Подобная архитектура позволила получать хорошие результаты на произвольную запись даже на NL-SAS-дисках. Например, средние значения write при тестировании: 72 763 Кбит/с, 18 190 IOPS, latency — 1,7 мс. Данные получены с тестового виртуального сервера (программа тестирования fio, тестировался RAW-раздел без файловой системы), размещенного на NL-SAS-дисках (собран из 94 дисков по 2 Tбайт). Во время тестирования системы хранения были нагружены данными.

По умолчанию на дисковом уровне данные защищены технологией RAID-DP (как вариант модифицированного RAID 6). Если на других системах хранения часто применяется RAID 1 («зеркало»), то недостатки RAID 6 при случайной перезаписи нивелируются благодаря WAFL.

Механизм дедупликации позволяет не хранить повторяющиеся блоки данных ни на дисках, ни в кеше, а хранить их в единственном экземпляре и кешировать один раз, что сильно экономит емкость кеша. Этот эффект виден на образах операционных систем: все их файлы в основном одинаковые, поэтому все экземпляры виртуальных серверов занимают место одного виртуального диска. Такие технологии позволяют экономить на дисках компаниям с прогнозируемыми нагрузками.

Можно продуктивно использовать NFS как основной протокол подключения к дисковым массивам NetApp. Среди прочего данный тип подключения позволяет получить гибкую легко масштабируемую инфраструктуру при выносе части облака в резервный дата-центр, где также применяется технология Flash Pool при сайзинге системы хранения NetApp FAS8040.

Рассмотрим системы хранения 3PAR, линейки 74xx и 84xx. По результатам нескольких лет работы с массивами можно с уверенностью отнести их к числу лучших систем хранения для применения в виртуализированных средах. 3PAR для ускорения операций чтения на более медленных типах дисков предлагают использовать SSD-кеш с возможностью тиринга. Например, для размещения данных используется составной том: на SAS-дисках (

45%), на наиболее медленных NL-SAS (

5%). Так, на массиве нужно задать только изначальное процентное соотношение и периодичность миграции горячих и холодных блоков. Далее массив анализирует, к каким данным наиболее часто происходит обращение, и, набрав статистику, с определенной периодичностью производит миграцию с более медленного на более быстрый уровень и наоборот. Когда часть блоков располагается на «медленных» дисках, помогает SSD-кеш, работающий одновременно с тирингом. Также полезен механизм Dynamic Optimization, позволяющий на уровне системы хранения мигрировать виртуальные серверы на более производительный тип дисков без прерывания сервиса.

3PAR использует виртуализацию дискового пространства, а именно все однотипные физические диски в массиве разбиваются на кусочки (чанклеты) по 1 Гбайт, из которых строятся логические диски с заданным типом RAID. Далее из этих логических дисков создаются тома, что позволяет увеличить быстродействие, так как в операциях чтения/записи принимают участие все однотипные диски, установленные в массив.

Когда выходит из строя один из дисков, процесс ребилда (перестроения) занимает значительно меньше времени, чем при классическом подходе, когда используются отдельные диски под spare. Здесь как раз сказывается архитектура организации хранения на низком уровне. Массивы 3PAR не выделяют отдельных дисков под spare, они используют зарезервированные чанклеты, которые расположены на всех дисках, то есть при выходе одного диска из строя данные перемещаются со всех однотипных дисков массива на все, а не с многих на один, как в классическом сценарии.

All-flash

Долгое время построение систем хранения данных на базе SSD оставалось оправданно только для бизнес-критичных задач, так как SSD-носители были довольно дорогими и отличались небольшим сроком службы. SSD-диски имели достаточно низкий ресурс на запись/перезапись. Как только производители систем хранения смогли добиться высокого количества циклов перезаписи, стоимость all-flash-систем начала снижаться, а в некоторых случаях оказалась сопоставимой со стоимостью SAS. Стало возможным развертывание бизнес-критичных приложений в виртуальной среде с максимальным быстродействием и минимальным временем отклика.

Рассмотрим особенности работы all-flash систем хранения на примере HP 3PAR 8450. Массивы 3PAR разносят все тома по всем SSD-носителям массива, что при равномерном распределении нагрузки предотвращает износ конкретных дисков. При этом чип ASIC в каждом контроллере исключает запись нулевых блоков. Вместо центрального процессора массива он выполняет операции детектирования нулей, аппаратной поддержки XOR (для подсчета контрольных сумм в RAID 5, RAID 6), дедупликации и другие операции. Эти системы хранения позволяют использовать четыре контроллера в рамках одной системы в режиме Active/Active. Так, каждый из контроллеров может работать с каждым томом, и поэтому нагрузка равномерно распределяется по всем контроллерам. Чтобы избежать проседания производительности при выходе контроллера из строя или при его перезагрузке, кеш на запись зеркалируется между четырьмя контроллерами.

Одна из востребованных функций all-flash-массивов — QoS (Quality of Service), позволяющая гарантированно получать требуемые значения IOPS, latency в рамках виртуальной инфраструктуры.

Массивы 3PAR можно использовать в рамках двух разнесенных площадок, появляется возможность предложить функциональность Peer Persistence (разнесенный отказоустойчивый кластер VMware). В этом решении LUN с дисками виртуальных серверов реплицируется между массивами в разнесенных дата-центрах. К LUN создаются активные и пассивные пути, которые видны хостам ESXi. Реплика основного LUN представлена тем же WWN, что и основной. Поэтому для среды VMware переключение LUN с основного на резервный происходит прозрачно. Применение Peer Persistence позволяет нам автоматизировать процесс переключения между площадками и не требует привлекать дополнительные решения, как, например, VMware Site Recovery Manager.

При использовании all-flash-массива на двух площадках RTT будет относительно высоким в сравнении с локальной площадкой, поэтому лучше применять асинхронную репликацию с удаленной площадкой или условно синхронную репликацию данных, когда массив на основной площадке не ждет подтверждения записи, а сразу стремится записать новые данные на удаленную площадку. Используя условно синхронную репликацию на SSD-дисках, можно сохранить высокую производительность локальной площадки и в то же время получить хороший RPO на удаленной.

Читать еще:  Перенести win 7 на ssd

Как сделать работу с виртуальными машинами более эффективной

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

Как сделать работу с виртуальными машинами более эффективной?

1. Свой гипервизор

Выбор программы для реализации виртуальных машин имеет огромное значение. Важно выбрать свой гипервизор – чтобы он и подходил функционально, и максимально отвечал аппаратным возможностям компьютера. Для Windows существует 3 основных гипервизора – Hyper-V, VMware и VirtualBox. Ни об одной из этих программ нельзя сказать, что она хуже или лучше своих аналогов. Все трое в чём-то хороши, но в чём-то проигрывают.

Hyper-V опционально поставляется на борту клиентских Windows, начиная с версии 8, а VirtualBox – бесплатное ПО. Возможностью бесплатного использования они выигрывают у платных продуктов VMware, в частности, у программы VMware Workstation, стоящей €275. Преимущество последней – функциональность и стабильность.

Самыми нестабильным гипервизором является VirtualBox. Эта программа постоянно совершенствуется, в неё вносятся изменения, что иногда отрицательно сказывается на стабильности её работы. Плюс к этому, VirtualBox слабо оптимизирована под работу с процессорами AMD, вследствие чего могут возникать проблемы в части интеграции гостевой и основной ОС.

Hyper-V – не самый функциональный гипервизор, с ограниченной поддержкой гостевых ОС, с недружелюбным интерфейсом, но именно штатный инструмент Windows лучше использовать на недостаточно мощных компьютерах.

Hyper-V предусматривает для гостевых ОС динамическое задействование оперативной памяти и разные типы подключения к виртуальным машинам, в частности, базовый тип с минимальной нагрузкой на аппаратные ресурсы. У Hyper-V самый быстрый и удобный механизм создания снапшотов (контрольных точек) и отката к ним. Поскольку реализован он на базе службы создания теневых копий Windows VSS.

2. Отдельный жёсткий диск

Для работы с виртуальными машинами не нужен какой-то сверхмощный компьютер, как, например, для современных игр. Не нужно производительной видеокарты, с гипервизорами можно спокойно работать даже на встроенной графике. Базовые требования по современным меркам смешны:

  • хотя бы двухъядерный процессор;
  • как минимум 4 Гб оперативной памяти.

Слабое место виртуальных машин – жёсткие диски HDD. И без того низкая скорость чтения и записи данных HDD в среде гостевых ОС ещё ниже из-за того, что данные пишутся не напрямую в дисковое пространство раздела, а в файл виртуального диска. Со считыванием, соответственно, та же ситуация. Потому чтобы хоть как-то снизить нагрузку на HDD, файлы виртуальных машин желательно размещать на другом диске – отдельном от того, на котором установлена основная ОС. Использование для этих целей SSD – идеальнейший вариант. Но за неимением финансовой возможности приобрести SSD нужного объёма сгодится и второй HDD.

3. Физический жёсткий диск

Виртуальная машина будет себя вести чуть резче, если её создать не на базе виртуального диска, а на базе реального. Hyper-V и VirtualBox работают только с виртуальными жёсткими дисками, а вот VMware Workstation предусматривает возможность создания виртуальной машины на базе физического носителя или отдельного его раздела.

Правда, в последнем случае Windows не захочет устанавливаться. Разве что можно попытаться восстановить систему из бэкапа. Но лучше, конечно, подобного рода эксперименты проводить с отдельным жёстким диском, на котором не хранятся ценные данные.

4. Фиксированный виртуальный диск

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

Создание фиксированного диска обычно занимает несколько минут – 5, 10, 15, всё зависит от размера. Но это только в условиях файловой системы NTFS.

5. Файловая система REFS

Форматирование разделов диска в файловую систему REFS, коей Microsoft пророчит будущее в качестве преемницы NTFS, давно предусматривалось в серверных редакциях Windows. А после внедрения крупного обновления Creators Update эту возможность могут использовать и пользователи клиентской Windows 10. С преемницей пока ещё очень много проблем: REFS несовместима с версиями системы старше 10-й и пока что не может быть использована для системного раздела С. Но для несистемных разделов в среде актуальной Windows 10 её использовать можно. И если для хранения виртуальных машин выделить раздел, отформатированный в REFS, при работе с гостевыми ОС получим кое-какие преимущества.

REFS записывает нули в файл виртуального жёсткого диска фиксированного типа за считанные секунды. Так что при создании последних придётся ждать не 5, 10 или 15 минут, а 1, 2 или 3 секунды.

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

6. Исключения антивируса

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

7. Оптимизация гостевых ОС

Чтобы улучшить быстродействие гостевых ОС, к ним можно применять те же способы оптимизации, что и для реальных Windows:

Годовая
подписка
на
Хакер

Xakep #251. Укрепляем VeraCrypt

Xakep #250. Погружение в AD

Xakep #248. Checkm8

Xakep #247. Мобильная антислежка

Переходим на SSD: как строили систему хранения данных в виртуализированной среде

Содержание статьи

Несколько лет назад начался переход от colocation к облачной модели ИТ-сервисов. Запросы рынка к облачным сервисам оказали существенное влияние на развитие систем хранения данных и требования, предъявляемые к их производительности.

Выбор СХД для корпоративного облака

При использовании виртуализации для корпоративного облака нагрузка со стороны виртуальной инфраструктуры на систему хранения произвольная. Разные приложения одновременно обращаются к СХД с разным профилем нагрузки — распределение ее невозможно спрогнозировать. При этом должны соблюдаться жесткие требования к количеству операций ввода-вывода (IOPS) и времени отклика (latency).

Под такой тип нагрузки лучше всего подходят системы хранения данных, построенные на базе твердотельных накопителей (SSD). Но еще несколько лет назад емкость SSD-накопителей была небольшой, а цена — очень высокой, что ощутимо влияло на конечную стоимость сервиса.

Чтобы найти баланс между высокой производительностью и большим объемом невостребованного дискового пространства, в виртуальном дата-центре можно использовать SSD-кеш на всех системах хранения (в пределах 5–15% от общей дисковой емкости), что снизит время отклика и увеличит производительность без добавления избыточного количества дисков. Высокая производительность такого подхода хорошо ощутима на решениях VDI (Virtual Desktop Infrastructure), где дедуплицированные данные занимают мало места в кеше и при этом создается впечатление, что диски виртуальных серверов размещены на SSD-томе.

WARNING

NetApp FAS3250

Рассмотрим системы хранения данных виртуального дата-центра, построенного на оборудовании HPE и NetApp. Эти компании лидируют в производстве быстрых, гибких и отказоустойчивых систем хранения, их СХД дают максимальную производительность при разнородной нагрузке.

Первой продуктивной системой хранения с использованием SSD-кеша была NetApp FAS3250, в которую устанавливались Flash Cache PCI-платы емкостью 1 Тбайт на каждый контроллер. Далее нарастить полезную емкость без снижения производительности позволили смешанные дисковые полки Flash Pool (по четыре SSD-диска на каждую полку с дисками других типов). Такой вид кеширования (Flash Pool) позволял ускорять операции чтения и записи, что было невозможно при использовании Flash Cache.

Читать еще:  Перенос системы с hdd на ssd

В основе архитектуры Data ONTAP (ОС NetApp) лежит файловая система WAFL (Write Anywhere File Layout), которая новые данные всегда пишет в свободное место, как при последовательной записи, что позволяет таким системам хранения иметь небольшой RAM-кеш контроллера при высоких показателях производительности. Подобная архитектура позволила получать хорошие результаты на произвольную запись даже на NL-SAS-дисках. Например, средние значения write при тестировании: 72 763 Кбит/с, 18 190 IOPS, latency — 1,7 мс. Данные получены с тестового виртуального сервера (программа тестирования fio, тестировался RAW-раздел без файловой системы), размещенного на NL-SAS-дисках (собран из 94 дисков по 2 Tбайт). Во время тестирования системы хранения были нагружены данными.

По умолчанию на дисковом уровне данные защищены технологией RAID-DP (как вариант модифицированного RAID 6). Если на других системах хранения часто применяется RAID 1 («зеркало»), то недостатки RAID 6 при случайной перезаписи нивелируются благодаря WAFL.

Механизм дедупликации позволяет не хранить повторяющиеся блоки данных ни на дисках, ни в кеше, а хранить их в единственном экземпляре и кешировать один раз, что сильно экономит емкость кеша. Этот эффект виден на образах операционных систем: все их файлы в основном одинаковые, поэтому все экземпляры виртуальных серверов занимают место одного виртуального диска. Такие технологии позволяют экономить на дисках компаниям с прогнозируемыми нагрузками.

Можно продуктивно использовать NFS как основной протокол подключения к дисковым массивам NetApp. Среди прочего данный тип подключения позволяет получить гибкую легко масштабируемую инфраструктуру при выносе части облака в резервный дата-центр, где также применяется технология Flash Pool при сайзинге системы хранения NetApp FAS8040.

Рассмотрим системы хранения 3PAR, линейки 74xx и 84xx. По результатам нескольких лет работы с массивами можно с уверенностью отнести их к числу лучших систем хранения для применения в виртуализированных средах. 3PAR для ускорения операций чтения на более медленных типах дисков предлагают использовать SSD-кеш с возможностью тиринга. Например, для размещения данных используется составной том: на SAS-дисках (

45%), на наиболее медленных NL-SAS (

5%). Так, на массиве нужно задать только изначальное процентное соотношение и периодичность миграции горячих и холодных блоков. Далее массив анализирует, к каким данным наиболее часто происходит обращение, и, набрав статистику, с определенной периодичностью производит миграцию с более медленного на более быстрый уровень и наоборот. Когда часть блоков располагается на «медленных» дисках, помогает SSD-кеш, работающий одновременно с тирингом. Также полезен механизм Dynamic Optimization, позволяющий на уровне системы хранения мигрировать виртуальные серверы на более производительный тип дисков без прерывания сервиса.

3PAR использует виртуализацию дискового пространства, а именно все однотипные физические диски в массиве разбиваются на кусочки (чанклеты) по 1 Гбайт, из которых строятся логические диски с заданным типом RAID. Далее из этих логических дисков создаются тома, что позволяет увеличить быстродействие, так как в операциях чтения/записи принимают участие все однотипные диски, установленные в массив.

Когда выходит из строя один из дисков, процесс ребилда (перестроения) занимает значительно меньше времени, чем при классическом подходе, когда используются отдельные диски под spare. Здесь как раз сказывается архитектура организации хранения на низком уровне. Массивы 3PAR не выделяют отдельных дисков под spare, они используют зарезервированные чанклеты, которые расположены на всех дисках, то есть при выходе одного диска из строя данные перемещаются со всех однотипных дисков массива на все, а не с многих на один, как в классическом сценарии.

All-flash

Долгое время построение систем хранения данных на базе SSD оставалось оправданно только для бизнес-критичных задач, так как SSD-носители были довольно дорогими и отличались небольшим сроком службы. SSD-диски имели достаточно низкий ресурс на запись/перезапись. Как только производители систем хранения смогли добиться высокого количества циклов перезаписи, стоимость all-flash-систем начала снижаться, а в некоторых случаях оказалась сопоставимой со стоимостью SAS. Стало возможным развертывание бизнес-критичных приложений в виртуальной среде с максимальным быстродействием и минимальным временем отклика.

Рассмотрим особенности работы all-flash систем хранения на примере HP 3PAR 8450. Массивы 3PAR разносят все тома по всем SSD-носителям массива, что при равномерном распределении нагрузки предотвращает износ конкретных дисков. При этом чип ASIC в каждом контроллере исключает запись нулевых блоков. Вместо центрального процессора массива он выполняет операции детектирования нулей, аппаратной поддержки XOR (для подсчета контрольных сумм в RAID 5, RAID 6), дедупликации и другие операции. Эти системы хранения позволяют использовать четыре контроллера в рамках одной системы в режиме Active/Active. Так, каждый из контроллеров может работать с каждым томом, и поэтому нагрузка равномерно распределяется по всем контроллерам. Чтобы избежать проседания производительности при выходе контроллера из строя или при его перезагрузке, кеш на запись зеркалируется между четырьмя контроллерами.

Одна из востребованных функций all-flash-массивов — QoS (Quality of Service), позволяющая гарантированно получать требуемые значения IOPS, latency в рамках виртуальной инфраструктуры.

Массивы 3PAR можно использовать в рамках двух разнесенных площадок, появляется возможность предложить функциональность Peer Persistence (разнесенный отказоустойчивый кластер VMware). В этом решении LUN с дисками виртуальных серверов реплицируется между массивами в разнесенных дата-центрах. К LUN создаются активные и пассивные пути, которые видны хостам ESXi. Реплика основного LUN представлена тем же WWN, что и основной. Поэтому для среды VMware переключение LUN с основного на резервный происходит прозрачно. Применение Peer Persistence позволяет нам автоматизировать процесс переключения между площадками и не требует привлекать дополнительные решения, как, например, VMware Site Recovery Manager.

При использовании all-flash-массива на двух площадках RTT будет относительно высоким в сравнении с локальной площадкой, поэтому лучше применять асинхронную репликацию с удаленной площадкой или условно синхронную репликацию данных, когда массив на основной площадке не ждет подтверждения записи, а сразу стремится записать новые данные на удаленную площадку. Используя условно синхронную репликацию на SSD-дисках, можно сохранить высокую производительность локальной площадки и в то же время получить хороший RPO на удаленной.

Разгружаем SSD или установка ОС на vhd

Не далее как сегодня (февраль 2014 года) я приобрёл новенький SSD и основной проблемой стало уменьшение количества записи на него, т.к. именно это снижает ресурс диска.

Решение я выбрал не совсем стандартное. А именно заключающееся в использовании разностных VHD дисков. Операционные системы Windows начиная с Windows 7 позволяют загружаться с виртуального жёсткого диска. А диски эти могут быть очень интересного вида, так называемые «разностные».

Идея использования такого диска заключается в том, чтобы создать образ диска «только для чтения», который будет расположен на SSD, и привязанный к нему образ «для записи», расположенный на обычном HDD. И периодически производить слияние этих образов. Таким образом я надеюсь снизить объём количества изменений на диске до минимума

Опубликовано на Habrahabr.ru

Коллеги, хотелось бы вновь обсудить вопрос увеличения ресурса SSD

Идея, думаю, не нова и заключается в следующем: создать разностный VHD, базовая часть которого будет храниться на SSD, а разница (сравнительно небольшая) на HDD. Таким образом значительно сокращается количество записей на SSD, а т.к. работающая система пишет не так много данных (и соответственно читает из этой области также не много), то размещение этой информации на HDD не должно привести к значительному падению производительности. Далее необходимо только периодически производить слияние дисков для поддержания производительности системы на должном уровне. Однако не всё оказалось так просто…

Окружение

Основная задача — иметь под рукой достаточно производительную и отзывчивую среду (что обеспечивается наличием в системе SSD) в виде хоста и виртуальных машин различного назначения.

Основная проблема — множество операций записи, которые генерирует хост и виртуальные машины при работе, что отрицательно сказывается на ресурсе SSD.

В качестве основного подопытного был выбран достаточно свежий Windows 2012 Server R2 (имеется большой интерес к RemoteFX). Но та же идея увеличения ресурса SSD будет справедлива и для Windows 8.1 Pro (только начиная с этой редакции поддерживается native boot, но отсутствует RemoteFX). Вариант с размещением на хосте только гипервизора (например, VMWare ESXi на быстрой USB 3.0 флешке) был отвергнут ввиду острой необходимости использовать всю мощь хоста в играх и другом требовательном к железу ПО.

Читать еще:  Ssd диск не инициализируется что делать

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

Изучаем вопрос

Изучение спецификации формата VHD показало, что в файле формата VHD может указываться относительный и абсолютный путь к родительскому образу.

Относительный путь сразу отбраковывается, а вот абсолютный стал интересным вариантом. Но практика показала, что есть явная проблема с тем, что буква диска назначается в неизвестный момент загрузки системы и, первая мысль, что не работает именно поэтому. Но в среде Windows есть ещё один способ адресации — через явное задание GUID тома вместо буквы, например: \?Volumeimage.vhd

Для упрощения проверки был создан виртуальный диск с длинным именем (C:1234567890123456789012345678901234567890123456image.vhd) и разностный диск (D:image_diff.vhd). Открыв разностный VHD hex-редактором можно найти соответствующую ссылку на родительский VHD и изменить путь на \?Volumeimage.vhd… После этого диск монтируется в систему через diskpart. Но… Установленная на него система не работает: ошибка 0xC03A000D (проблема с цепочкой образов диска). При первом приближении показалось, что проблема кроется в том, что при использовании жёсткого диска с MBR система генерирует случайные GUID для томов и какой GUID назначен томам — не известно.

Дальнейшее изучение вопроса показало, что начиная с Windows 8/2012 появился формат дисков VHDX и они также поддерживают Native boot. В спецификации по VHDX найдено упоминание о том, что в файлах данного формата изначально предусмотрено сохранение пути к родительскому VHDX в формате пути с указанием GUID тома (так называемый volume path). При этом оговаривается даже порядок поиска родительского диска: relative path, volume path, absolute win32 path.

После изучения созданного разностного диска формата VHDX и в hex-редакторе стало понятно, что действительно данная информация сохранена в файле. Однако сохраняется проблема с GUID томов MBR дисков. Но это решилось разбиением диска под GPT. При таком варианте разбиения диска GUID тома становится постоянным. При этом базовый диск должен располагаться на томе GPT, а разностный может размещаться как на диске GPT, так и на диске MBR.

Были проведены опыты по запуску системы с различными сочетаниями дисков и загрузчиков (BIOS, EFI), но результатов они не принесли. Система по-прежнему отказывается загружаться при разнесении файлов VHDX-диска.

Решено было потратить пару часов и изучить под микроскопом сам загрузчик (WindowsSystem32winload.exe и WindowsSystem32winload.efi) начиная с Windows 7. После этого всё стало на свои неутешительные места:

  1. Windows 7 — в загрузчике присутствует код только для работы с дисками формата VHD
  2. Windows 8/2012 — в загрузчике присутствует код для работы как с VHD так и с VHDX дисками… но в нём присутствует работа только с относительным путём (relative_path) к родительскому диску. И даже прописывание в этот параметр пути с GUID не даёт положительного результата
  3. Windows 8.1/2012R2 — загрузчик несколько вырос по размеру, но полноценной реализацией работы с VHDX так и не обзавёлся

Заключение

Таким образом получается, что Windows 8/2012 содержит в своём арсенале технологию создания гибридных дисковых систем, которая потенциально может увеличить ресурс SSD+HDD в разы. Но эта технология почему-то не до конца реализована в загрузчике, ввиду чего невозможно применить её на практике. Остаётся только надеяться, что в следующем обновлении (или релизе) загрузчик будет доработан.

Пока что остаётся рассматривать только вариант с классическим ускорением работы виртуальных машин: хостовая ОС размещается на HDD, базовый диск виртуальных машин размещается на SSD и создаётся снапшот на HDD, который периодически объединяется с базовым диском (по заданию или, например, при достижении размера снапшота в 1Гб). Ну или просто дождаться, когда SSD хотя бы сравняются с HDD по цене/объёму.

Хотелось бы также узнать мнение читателей по вопросу есть ли смысл таким образом увеличивать ресурс SSD? Может быть у сообщества есть ещё какие-нибудь идеи как организовать описанную схему? Может быть я что-то упустил?

Создание виртуального SSD для vSphere 5.5

Автор: vik_kr Дата: 07 Декабрь 2014 . Категория: Статьи

Использование виртуального твердотельного накопителя поможет Вам сэкономить и время и деньги. VMware vSphere 5.5 новейшая редакция передовой платформы виртуализации, это аппаратный гипервизор, устанавливается непосредственно на физический сервер и делит его на несколько виртуальных машин, которые могут работать одновременно, используя одни и те же физические ресурсы. Дисковое пространство необходимое для установки снижено до 150 MB платформы vSphere, за счет отсутствия базовой операционной системы. Управление такой платформой может производиться удаленно.

Одним из апгрейдов компании VMware vSphere 5.5 является Flash Read Cache или как его еще называют vFlash. Это фреймворк, с его помощью возможно объединить SSD-ресурсы хост-серверов VMware ESXi в единый пул, который используется для кэширования, что позволит сторонним вендорам SSD накопителей и кэш-устройств использовать свои алгоритмы для создания модулей обработки кэшей виртуальных машин, которые интенсивно используют подсистему ввода-вывода для операций чтения. Это повышает скорость их быстродействия.

vFlash обеспечивает высокую производительность кэша чтения, что значительно ускоряет работу приложений, надежное и экономичное хранилище для сред vSphere. Что бы ускорить работу приложений, запущенных на нескольких виртуальных машинах можно использовать vFlash. Это возможно сделать, не имея физического SSD, заменив его на виртуальный SSD, с помощью трюка с vSphere применив виртуальный SSD вместо физического.

Процесс создания виртуального SSD прост. Хотя это всего лишь временная замена физического SSD. Виртуальные SSD позволяют сэкономить деньги на оборудовании, почти никак не влияя на производительность. Вот шаги для создания виртуального SSD:

  • создайте физический локальный виртуальный диск на хост ESXi, который вы хотите сделать vFlash, убедитесь, что размер локального виртуального SSD не превышает размера физического хоста ESXi;
  • укажите путь для ESXi хоста локального виртуального диска (e.g., mpx.vmhba1:C0:T0:L0);
  • откройте Secure Shell (SSH) сессию для каждого ESXi хоста;
  • преобразование физического локального виртуального диска на локальный виртуальный SSD, используя следующие esxcli командные строки для изменения.

Storage Array Type Plugin (SATP) позволит Вашему хранилищу vСentre I/O сбалансировать нагрузку должным образом при использовании нового виртуального диска. Во всех средах VMware vSphere балансировка нагрузки осуществляется с помощью реализованного на платформе vSphere планировщика Distributed Resource Scheduler (DRS). DRS объединяет хосты ESX и ESXi, чтобы осуществлять на них оптимальное распределение нагрузки от запущенных виртуальных машин (VM).

Вот код который создает правила SATP и активирует строку SSD:

Следующий шаг, проверить правильность создание правил SATP:

Далее идет рекламация новой виртуальной SSD, что бы способствовать применению правил SATP:

Наконец, убедитесь, что новый виртуальный SSD был создан:

Если Ваш Is SSD введен верно, локальный диск теперь можно считать виртуальным. Вы можете использовать графический интерфейс пользователя или следующую команду, что бы обновить vSphere хранилище:

Теперь, когда ваша виртуальная SSD создана и проверена, Вы можете добавить его на Ваш ESXi host(s) и начать пользоваться vFlash. Его легко настроить — просто настроив его на vCenter Web client.

Настройка vFlash:

  • в vSphere Web Client, перейдите к узлу;
  • после этого перейдите на вкладку «Manage» и выберите «Settings»;
  • в разделе vFlash, выберите «Virtual Flash Resource Management», затем нажмите «Add Capacity»;
  • из списка доступных SSD устройств, выберите только что созданный локальный диск виртуальной SSD, и что бы запустить его нажмите «OK».

Несколько советов

Теперь, когда ваш vFlash настроен и работает, вы можете начать пользоваться предоставляемыми им «благами». Не забудьте убедиться, что у Вас VM version 10, так как на другой версии ваши Виртуальные машины «не выиграют» от преимуществ vFlash. Рекомендуется настраивать vFlash под каждый ESXi Host. Благодаря появлению таких носителей можно создать надежное и экономичное хранилище для сред vSphere. Выгодное соотношение цены и производительности.

Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector
×
×