Компания StarWind Software, производитель средства номер 1 для создания отказоустойчивых хранилищ iSCSI для виртуальных машин VMware и Microsoft, выпустила интересный документ "StarWind High Availability Best Practices", где описаны лучшие практики для механизмов отказоустойчивости, имеющихся в продукте:
Данный документ подойдет как новичкам, так и опытным администраторам СХД StarWInd, поскольку в нем имеется описание необходимых настроек ОС, сетевого взаимодействия, тиминга адаптеров, канала синхронизации, а также имеются рекомендации по настройке HA-устройств, снабженные иллюстрациями.
Таги: StarWind, iSCSI, Storage, Whitepaper, VMware, Microsoft, HA
На прошлой неделе компания Veeam Software в очередной раз доказала, что является действительно инновационной компанией, которая выпускает продукты с возможностями, отсутствующими у других производителей программного обеспечения для платформ виртуализации.
Многие из вас знают продукты StarWind iSCSI SAN и StarWind Native SAN for Hyper-V, предназначенные для создания отказоустойчивых хранилищ виртуальных машин для платформ VMware и Hyper-V. Но немногие знают что компания выпускает целых 3 SDK, которые могут помочь разработчикам интегрировать сторонние решения с продуктами StarWind.
Вот эти пакеты:
StarWind iSCSI SAN SDK
Это основной SDK, позволяющий использовать функциональность продуктов StarWind. С его помощью можно:
Добавлять функции iSCSI Target в собственные приложения.
Разрабатывать собственные SCSI-устройства с нужной функциональностью
Соединять физические устройства с удаленными машинами (SPTI)
Более подробно о StarWind iSCSI SAN SDK можно почитать тут.
StarWind Deduplication SDK
Как понятно из названия, этот SDK позволяет использовать механизмы дедупликации StarWind. Это технология in-line дедупликации данных (то есть во время резервного копирования, а не после) на уровне блоков, которая уже надежно зарекомендовала себя в продуктах StarWind. Она позволяет добиться коэффициента дедупликации данных до 20 к 1, использует регулируемый размер блока (под разные задачи хранилищ) и позволяет использовать кэширование на SSD-накопителях и в оперативной памяти.Об этом средстве мы уже упоминали вот тут.
SDK включает в себя библиотеку кода, примеры использования и документацию по API. Более подробно о StarWind Deduplication SDK можно почитать тут.
StarWind Log-Structured File System (LSFS) SDK
LSFS - это файловая система, предназначенная для хранения нескольких файлов виртуальных устройств (в первую очередь, устройств - образов виртуальных дисков), которая оптимизирована для высокой производительности при нагрузках типа "random access" (что характерно как раз для виртуальных машин).
StarWind LSFS SDK предоставляет:
Слой хранения файлов, которые поддерживает высокую скорость ввода-вывода при случайной записи
Технологию снапшотов
Технологию Thin Provisioning для экономии дискового пространства хранилищ
Технологию дедупликации
Более подробно о StarWind LSFS SDK можно почитать тут.
Интересная статья обнаружилась у Кормака, касающаяся того, как работает LUN Discovery на хостах VMware ESXi. Оказывается все новые LUN, висящие на одном таргете обнаруживаются сервером ESXi автоматически по заданному таймауту.
То есть мы сначала делаем Rescan, чтобы добавить новый таргет (порт массива), например, T2 с LUN ID=10:
Дальше на этом таргете создаем новый LUN ID=20, и через какое-то время он автоматически появляется в списках устройств:
Все это потому, что по умолчанию каждые 5 минут вызывается проба (SCSI-команды REPORT_LUN и/или INQUIRY), целью которой является обнаружение новых устройств и путей на известных хосту таргетах. Настраивается это время (в секундах) в следующей расширенной настройке (по умолчанию 300 секунд):
Disk.DeviceReclaimTime
Кроме того, все это отрабатывает и тогда, когда происходят операции добавления (Rescan) или удаления таргета.
Какое-то время назад мы уже было подумали, что компания Parallels забила на виртуализацию серверов, продолжая продвигать контейнерную виртуализацию на базе технологии Virtuozzo. Ан, нет. На проходившем с 4 по 7 февраля Parallels Summit компания Parallels представила обновленные продукты Parallels Cloud Server и Parallels Cloud Storage.
В решении Cloud Server сочетается контейнерная виртуализация и виртуализация серверов (Parallels Containers и Parallels Hypervisor), а Cloud Storage - это облачное хранилище данных от Parallels, которое развертывается в инфраструктуре предприятия:
С помощью Parallels Cloud Storage сервис-провайдеры могут создать отказоустойчивый распределенный кластер для хранения данных на базе локальных дисков серверов (т.е. без SAN-инфраструктуры), в том числе и для виртуальных машин. Parallels Cloud Storage создает заданное количество копий на разных компьютерах и таким образом предотвращает потерю данных в случа сбоя одного из них (каждая дополнительная копия данных снижает скорость записи примерно на 10%, но улучшает чтение). Для большей надежности в Parallels Cloud Storage можно настроить использование контрольных сумм пользовательских данных и их проверку как при непосредственном доступе к данным, так и на регулярной основе.
Ну а продукт Parallels Cloud Server позволяет хранить и запускать виртуальные машины и контейнеры Parallels, выполнять горячую миграцию виртуальных серверов, а также расширять объем доступного пространства, не ограничиваясь объемом свободного места на локальном диске (т.е. подключать дисковые ресурсы пула Cloud Storage). Основной целевой аудиторией Parallels Cloud Server являются хостинг-провайдеры, которые расширяют перечень своих услуг, например до IaaS->PaaS->SaaS.
Интересной особенностью продукта Parallels Cloud Server является возможность развернуть виртуальные машины и контейнеры на одном физическом сервере. Также повысились возможности масштабируемости инфраструктуры Parallels - одной виртуальной машине можно назначить до 32 ядер процессора, 128 ГБ оперативной памяти и 5 ТБ дискового пространства. Кроме того, Parallels Cloud Server поддерживает до 1 ПБ доступного дискового пространства.
Запросить пробную версию Parallels Cloud Server можно на этой странице.
Если вам по каким-либо причинам понадобилось подключить флэшку или другое USB-устройство к VMware ESXi, например, в целях сбора диагностических данных или интеграции сторонних пакетов (или драйверов) в гипервизор, то сделать это можно способом, описанным ниже. Прежде всего отметим, что монтирование USB-хранилищ в консоль ESXi поддерживается только для файловой системы FAT16.
1. Сначала нужно отключить службу USB Arbitrator service, которая отвечает за проброс USB-девайсов в виртуальные машины хост-сервера. Для этого выполняем команду:
# /etc/init.d/usbarbitrator stop
2. Далее подключаем носитель к ESXi и проверяем девайс командой:
# esxcli storage core device list | grep -i usb
или смотрим список смонтированных файловых систем:
# esxcli storage filesystem list
После этого вы можете работать с USB-устройством через папку /vmfs/volumes/NO NAME/. Например, можно установить бандл ESXi с флешки:
Интересные новости приходят от Дункана: в VMware vSphere 5.0 Update 2 при переименовании виртуальной машины во время миграции Storage vMotion ее VMDK-диски также переименовываются (раньше это не работало - менялось только имя машины). Но это, почему-то, не включено по умолчанию.
Чтобы это заработало нужно добавить расширенную настройку VMware vCenter. Для этого идем в "Administration" -> "vCenter Server Settings" -> "Advanced Settings" и добавляем параметр:
provisioning.relocate.enableRename со значением true
Итак, титаническая работа была проделана - и диски теперь переименовываются. Однако, почему эта настройка не активирована по умолчанию? Непонятно - бажит наверное...
Для VMware vSphere 5.1 эта штука пока не актуальна (только vSphere 5.0 Update 2), но обещают, что скоро она заработает с очередным апдейтом. Кстати, а почему тут только интерфейс добавления расширенных настроек и нет удаления?
Продолжаем рассказывать о решении для создания отказоустойчивой инфраструктуры хранения виртуальных машин для платформы Hyper-V - StarWind Native SAN. Недавно, кстати, мы писали о том, что появилось бесплатное издание StarWind Native SAN for Hyper-V Free edition с функциями отказоустойчивости хранилищ хост-серверов.
На этот раз предлагаем вашему вниманию документ "Virtualization Reality:
Why StarWind Virtual SAN Solutions
Deliver Value When Compared to Microsoft", в котором рассмотрены 5 причин, исходя из которых решение StarWind Native SAN имеет преимущества и ценность по сравнению со встроенными средствами Microsoft Hyper-V, такими как Shared Nothing Live Migration, Hyper-V Replica и механизмом кластеризации через SMB 3.0.
Также в документе, помимо всего прочего, рассмотрены архитектуры Scale-Out File Servers, о которой мы уже писали вот тут, и построение кластеров Microsoft на базе дисковых полок SAS JBOD. Как не трудно догадаться, все это хуже, чем решение StarWind Native SAN.
Таги: StarWind, SAN, Hyper-V, Whitepaper, Storage, HA
Очень давно мы писали про тип виртуальных дисков Paravirtual SCSI (PVSCSI), который появился в VMware vSphere 4 и был создан для требовательных к ресурсам ввода-вывода нагрузок. На заре своего развития виртуальные диски типа PVSCSI не рекомендовались к использованию в качестве загрузочных, а также имели несколько серьезных багов, но широко тестировались в связи с тем, что показывали большую производительность, чем стандартный LSI SCSI.
Эту статью мы пишем, главным образом, здесь для того, чтобы сказать - уже можно. Виртуальные диски Paravirtual SCSI достаточно стабильно работают в VMware vSphere. В KB 1010398 мы видим матрицу поддержки дисков pvscsi для различных релизов VMware vSphere (обычные и boot-диски):
Guest operating system
Data Disk
Boot Disk
Windows Server 2008 R2 (64-bit only)
ESX/ESXi 4.0 Update 1, ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.0 Update 1, ESX/ESXi 4.1, ESXi 5.0
Windows Server 2008 (32 and 64 bit)
ESX/ESXi 4.X, ESXi 5.0
ESX/ESXi 4.0 Update 1, ESX/ESXi 4.1, ESXi 5.0
Windows Server 2003 (32 and 64 bit)
ESX/ESXi 4.x, ESXi 5.0
ESX/ESXi 4.x, ESXi 5.0
Windows 7 (32 and 64 bit)
ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.1, ESXi 5.0
Windows Vista (32 and 64 bit)
ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.1, ESXi 5.0
Windows XP (32 and 64 bit)
ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.1, ESXi 5.0
Red Hat Enterprise Linux (RHEL) 5 (32 and 64 bit) and all update releases
ESX/ESXi 4.X, ESXi 5.0
Not Supported
RHEL 6 (32 and 64 bit)
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
SUSE Linux Enterprise 11 SP1(32 and 64 bit) and later releases
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
Ubuntu 10.04 (32 and 64 bit) and later releases
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
Distros using Linux version 2.6.33 or later and that include the vmw_pvscsi driver
ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.1, ESXi 5.0
В VMware vSphere/ESXi 5.1 поддерживается все то, что поддерживалось и в предыдущих версиях платформы.
Что же раньше были за баги с PVSCSI? Смотрим, например, в статье тут, отсылающей нас к KB компании Microsoft. Ошибка существовала для ОС Windows Server 2008 R2 и была критической, а устранена была только в VMware vSphere 5.0 Update 1, о чем есть KB 2004578.
Теперь о том, как поставить диск типа PVSCSI в качестве загрузочного для виртуальной машины на ESXi. Выбираем в vSphere Client контроллер типа VMware Paravirtual :
В настройках виртуальной машины добавляем виртуальный floppy-дисковод и указываем образ дискеты с драйвером PVSCSI, который лежит в папке vmimages->floppies (если там ничего нет, идем сюда):
Дальше при выборе диск для установки Windows указываем драйвер с дискеты:
Дальше ставим все как обычно. Если хочется запихнуть драйвер PVSCSI в кастомизированную ISO-шку, то вам сюда. И да, драйвер на образе дискеты от Windows Server 2008 прекрасно работает на Windows Server 2012, который, в свою очередь, работает на VMware vSphere 5.1.
Компания StarWind Software, производящая продукт номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN & NAS, приглашает на бесплатный вебинар "Increase Operational Efficiency with StarWind!", который проводит Анатолий Вильчинский, системный инженер StarWind Software.
На вебинаре будет рассказано о том, как с помощью решений StarWind можно улучшить эффективность хранения данных виртуальных серверов за счет функций дедупликации, а также функций высокой доступности хранилищ (напомним, что использовать их можно бесплатно).
Вебинар состоится в четверг, 24 января в 19-00 по московскому времени. Регистрируйтесь!
Теперь, на основе статьи Франка, мы обобщим и актуализуем информацию по миграциям vMotion и Storage vMotion в разных контекстах - на уровне хранилищ, сети и хост-серверов VMware ESX.
Как и в прошлой статье, здесь будем пользоваться понятием стоимости миграции в единицах (cost) и максимального значения костов в тех же единицах (max cost), которое отображает предельно допустимое значение. Сумма костов операций vMotion и SVMotion не должна превышать max cost для соответствующего объекта (datastore, NIC и хост ESXi).
Теперь взглянем на таблички (в них есть не только vMotion, но и SVMotion):
Хост ESXi
Operation
Config Key
Cost
vMotion Cost
costPerVmotionESX41
1
Storage vMotion Cost
costPerSVmotionESX41
4
Maximum Cost
maxCostPerEsx41Host
8
Сеть
Operation
Config Key
Cost
vMotion Cost
networkCostPerVmotion
1
Storage vMotion Cost
networkCostPerSVmotion
0
Maximum Cost
maxCostPerNic
2
maxCostPer1GNic
4
maxCostPer10GNic
8
Хранилище (Datastore)
Operation
Config Key
Cost
vMotion Cost
CostPerEsx41Vmotion
1
Storage vMotion Cost
CostPerEsx41SVmotion
16
Maximum Cost
maxCostPerEsx41Ds
128
Читать эти таблички просто - например, для хоста ESXi стоимость миграции vMotion равна 1, а поскольку max cost равно 8, то всего на хост может быть 8 одновременных миграций в конфигурации по умолчанию. Либо допустимы одновременно: 1 миграция SVMotion (4 очка) и 4 штуки vMotion (по одному очку каждая), т.е. суммировать надо по костам: 4+1+1+1+1=8.
Для хранилища (Datastore) также есть ограничения vMotion, поскольку передаются страницы файла подкачки (если он не шаренный между хостами), а также производится передача владения VMX-файлом и другими файлами ВМ на хранилище. Но поскольку влияние это мало, то стоимость vMotion для хранилища всего 1 при максимальной емкости одновременных операций 128 (а вот SVMotion, требующая значительных ресурсов хранилища, "кушает" 16 единиц). Таким образом 1 операция vMotion съест 1 единицу коста, поэтому в этот момент для хранилища будет доступно только 7 миграций SVMotion, т.е. (128-1) div 16 = 7.
Соответственно, редактирование параметра Config Key для соответствующей операции позволяет изменять количество одновременных операций vMotion/SVMotion. Для редактирования параметра Config Key нужно отредактировать конфигурационный файл vpxd.cfg на сервере VMware vCenter, который находится в папке:
Если соответствующей секции нет, то ее можно просто добавить. Уменьшать максимальные косты точно можно, а увеличение работает не всегда. То есть гарантированно вы сможете только уменьшить число одновременных миграций vMotion или SVMotion, а вот увеличить - не факт. Ограничение можно делать двумя способами - повышением обычных костов или понижением максимальных костов.
Теперь самое интересное - это динамический параметр max cost для сетевых адаптеров. Как видно из таблицы, его действующее значение зависит от типа сетевого адаптера на хосте - 1G или 10G. Но, на самом деле, и не только от типа. Точнее - от скорости соединения для трафика vMotion между хостами ESXi, которую обнаруживает VMkernel. Таким образом:
Если VMkernel обнаруживает соединение на скорости 1Gbit/s - Maximum Cost выставляется в значение 4 (это верно и для случая соединения 1G<->10G).
Если VMkernel обнаруживает соединение на скорости 10Gbit/s - Maximum Cost выставляется в значение 8.
Если VMkernel обнаруживает соединение на скорости ниже 1Gbit/s - Maximum Cost выставляется в значение 2.
Таким образом, для адаптера возможны либо 2, либо 4, либо 8 одновременных миграций vMotion, в зависимости от действующей скорости соединения. Операция Storage vMotion, как видно из таблицы, костов сети не кушает.
Если ограничение для сети жестче (например, 4 миграции vMotion), чем ограничение для хоста (8 миграций vMotion) - то для машин этого хоста действует ограничение сети.
В прошлой статье про средство резервного копирования и восстановления StarWind Hyper-V Backup Plug-in (опция к StarWind Native SAN for Hyper-V) мы обещали рассказать про такие режимы восстановления как:
Restore in Sandbox - возможность восстановить ВМ без ее влияния на продуктивную работающую копию (восстановление происходит в изолированное виртуальное окружение)
Restore from archive - возможность восстановить ВМ напрямую из архива (в случае крайней необходимости)
Restore in Sandbox
Этот режим нужен тогда, когда требуется восстановить ВМ в изолированное окружение и что-нибудь проверить, например, что все данные внутри остались целостными и приложения работают (т.е. архив пригоден для восстановления). Для этого нужно выбрать пункт "Restore in Sandbox" для резервной копии:
Восстановленная и запущенная виртуальная машина будет полностью изолирована от работающей продуктивной копии за счет собственных настроек сетевого взаимодействия и отдельного хранилища.
Вот так это выглядит в консоли Hyper-V Manager:
Restore from archive
Этот режим можно использовать только в экстренных случаях, когда виртуальная машина должна быть восстановлена безотлагательно. Для этого нужно выбрать пункт "Launch VM from Archive" из контекстного меню хранимой резервной копии.
После этого будет выдано предупреждение:
Чекбокс перед восстановлением заставляют поставить потому, что такой тип восстановления приведет к тому, что все инкременты данной резервной копии будут потеряны (т.е. останется только полная резервная копия последнего состояния), поскольку нужно запустить виртуальную машину, используя образ ВМ из архива.
Поэтому, если есть возможность, следует использовать варианты восстановления "Restore Original VM" или "Restore in Sandbox"
Напомним также, что у StarWind есть плагин для резервного копирования виртуальных машин и на платформе VMware vSphere - VMware Backup Plug-in.
На днях компания VMware провела целых два тестирования (тут и тут), целью которых было сравнение производительности виртуальных дисков VMDK и RDM виртуальных машин на платформе VMware vSphere 5.1. Напомним про предыдущие сравнения VMFS и RDM, где основной моралью был тот факт, что оба этих типа виртуальных дисков практически идентичны по производительности, поэтому их следует использовать только в случаях, когда требуется специфическая функциональность (например, кластеры MSCS и большие диски для RDM):
Итак, для первого тестирования использовалась следующая конфигурация:
В качестве нагрузки использовался тест DVD Store для приложения, симулирующего интернет-магазин на платформе mySQL 5.5. Также было задействовано несколько тестовых клиентов для создания реальной нагрузки.
Масштабируемость производительности под нагрузкой (OPM - это orders per minute):
Как видно из результатов, масштабируемость производительности при увеличении числа ВМ почти линейная, а результаты различных типов дисков - идентичны (на самом деле, VMDK показал себя на 1 процент быстрее RDM для 1-й ВМ и чуть медленнее для 4-х ВМ):
Затраты ресурсов CPU на обслуживание операций ввода-вывода также чуть-чуть (на тот же 1%) лучше в пользу VMDK:
Теперь обратимся ко второму исследованию. Там использовалась следующая тестовая конфигурация, выдающая 1 миллион IOPS на тестах:
Hypervisor: vSphere 5.1
Server: HP DL380 Gen8
CPU: Two Intel Xeon E5-2690, HyperThreading disabled
Memory: 256GB
HBAs: Five QLogic QLE2562
Storage: One Violin Memory 6616 Flash Memory Array
VM: Windows Server 2008 R2, 8 vCPUs and 48GB.
Iometer Configuration: Random, 4KB I/O size with 16 workers
Тут уже измерялась производительность в IOPS для виртуальных машин на платформе VMware vSphere 5.1. При этом варьировался размер блока ввода-вывода (I/O Size) и сравнивались VMDK диски в VMFS5 и RDM-тома (нагрузка - случайное чтение):
Здесь уже на тот же самый 1% выигрывает RDM (для тестов на I/O). В тестах на MB/s ситуация в одном тесте оказалась в пользу VMFS. Масштабируемость тут уже показана не совсем линейная, при этом завал кривой начинается после размера блока в 4 Кб (единственный и по умолчанию в vSphere 5.1).
Второй тест - 60% операций чтения и 40% операций записи:
Такой рост производительности на блоке в 4 Кб объясняется просто - массив, примененный в тестировании, использует размер блока 4 Кб.
Вывод обоих тестов - виртуальные диски VMDK и RDM практически идентичны с точки зрения производительности.
Сегодня мы хотим обратить ваше внимание на документ "StarWind iSCSI SAN & NAS: Multipathing", в котором детально и по шагам рассказывается о настройке механизма доступа по нескольким путям (MPIO) при использовании сервера хранилищ StarWind iSCSI SAN. В руководстве рассматривается настройка серверов на базе следующей схемы подключения:
В документе описаны способы настройки серверов как на платформе Windows Server 2008, так и Windows Server 2012.
Duncan и Frank, известные своими изысканиями в сфере механизмов отказоустойчивости (HA) и балансировки нагрузки (DRS) в виртуальной инфраструктуре VMware vSphere, опубликовали паруинтересныхматериалов, касающихся настройки среды vCloud Director и механизма Storage DRS.
Как вы знаете, в настройках кластера хранилищ (Datastore Cluster) есть галка, которая определяет, будут ли виртуальные диски VMDK машин обязательно находиться на одном хранилище (Datastore) при миграции средствами механизма Storage DRS:
Надо отметить, что галка Keep VMDKs together by default - это не совсем простая для понимания галка. Если ее не поставить, то действовать будет обратное - диски виртуальной машины будут обязательно размещаться на разных хранилищах. Это, по заверениям блоггеров, даст больше гибкости в использовании механизма SDRS в среде vCloud Director при перемещении виртуальных машин между хранилищами, что даст больше преимуществ в динамически балансирующейся среде (особенно для "тонких" дисков). Соответственно, по умолчанию галка Keep VMDKs together by default должна быть выключена.
Одновременно с этим компания StarWind объявила также о том, что решение StarWind iSCSI SAN 6.0 для хранения виртуальных машин VMware vSphere также становится бесплатным (при использовании дисковых ресурсов до 128 ГБ), при этом доступны все возможности продукта для обеспечения отказоустойчивости хранилищ. Об этом подробно написано в документе "StarWind iSCSI SAN Free. The difference between free and paid editions".
Для тех, кому лень открывать документ на английском, приводим обновленное сравнение бесплатного и коммерческого изданий StarWind iSCSI SAN 6.0:
StarWind iSCSI SAN
Free Edition - бесплатно
Коммерческие издания (в зависимости от лицензируемой емкости 1 ТБ - 512 ТБ)
Компоненты продукта
Лицензируемая емкость хранилищ
Не ограничена для одного узла и ограничение 128 ГБ для HA-конфигурации (на узел)
1 ТБ - 512 ТБ
Размер кэша
512 МБ
Не ограничен
Централизованное управление
StarWind Console
StarWind Console
Число серверов, входящее в лицензию
2
2 или 3
Число одновременных соединений по iSCSI к хранилищам
Кроме того, не так давно были воплощены в жизнь такие полезные службы vSphere для работы с SSD-накопителями, как SSD Monitoring (реализуется демоном smartd) и Swap to SSD (использование локальных дисков для файлов подкачки виртуальных машин). Однако функции кэширования на SSD реализованы пока совсем в базовом варианте, поэтому сегодня вам будет интересно узнать о новой технологии Virtual Flash (vFlash) для SSD-накопителей в VMware vSphere, которая была анонсирована совсем недавно.
Эта технология, находящаяся в стадии Tech Preview, направлена на дальнейшую интеграцию SSD-накопителей и других flash-устройств в инфраструктуру хранения VMware vSphere. Прежде всего, vFlash - это средство, позволяющее объединить SSD-ресурсы хост-серверов VMware ESXi в единый пул, используемый для задач кэширования, чтобы повысить быстродействие виртуальных машин. vFlash - это фреймворк, позволяющий сторонним вендорам SSD-накопителей и кэш-устройств использовать собственные алгоритмы для создания модулей обработки кэшей виртуальных машин (плагины vFlash Cache Modules). Будет реализован и собственный базовый алгоритм VMware для работы с кэшем.
Основная мысль VMware - предоставить партнерам некий API для их flash-устройств, за счет которого виртуальные машины будут "умно" использовать алгоритмы кэширования. Для этого можно будет использовать 2 подхода к кэшированию: VM-aware caching и VM-transparent caching:
VM-aware Caching (vFlash Memory)
В этом режиме обработки кэширования флэш-ресурс доступен напрямую для виртуальной машины, которая может использовать его на уровне блоков. В этом случае на уровне виртуального аппаратного обеспечения у виртуальной машины есть ресурс vFlash Memory определенного объема, который она может использовать как обычный диск в гостевой ОС. То есть, приложение или операционная система должны сами думать, как этот высокопроизводительный ресурс использовать. Можно вообще использовать его не как кэш, а как обычный диск, хотя идея, конечно же, не в этом.
VM-transparent Caching (vFlash Cache)
В этом случае виртуальная машина и ее гостевая ОС не знают, что на пути команд ввода-вывода находится прослойка в виде flash-устройств, оптимизирующих производительность за счет кэширования. В этом случае задача специализированного ПО (в том числе от партнеров) - предоставить оптимальный алгоритм кэширования. В этом случае будет доступна настройка следующих параметров кэша:
Гарантированный объем (Reservation size)
Выбор программного модуля-обработчика (vFlash Cache Module)
Размер блока (настраивается в зависимости от гостевой ОС)
Что делать с кэшем при перемещении виртуальной машины посредством vMotion (перенести вместе с ней или удалить)
При vMotion сервер vCenter будет проверять наличие необходимых ресурсов кэширования для виртуальной машины на целевом хосте ESXi. Для совместимости с технологией VMware HA, виртуальная машина должна будет иметь доступные vFlash-ресурсы на хранилищах хостов в случае сбоя (соответственно, потребуется эти ресурсы гарантировать).
В целом vFlash в VMware vSphere обещает быть очень перспективной технологией, что особенно актуально на волне роста потребления SSD-накопителей, постепенно дешевеющих и входящих в повсеместное употребление.
Компания HP обновила Firmware для своих серверов HP ProLiant, доступное для гипервизора VMware ESXi 5.0 и более поздних версий. Обновление доступно по этой ссылке.
Процесс обновления Firmware проходит из сервисной консоли серверов VMware ESXi, при этом предварительными требованиями является наличие следующих компонентов:
Мы уже писали о некоторых функциях утилиты esxcli в VMware vSphere, которая работает с различными пространствами имен, такими как network, storage, hardware и прочими. Сегодня мы хотим остановиться на новых функциях по управлению устройствами ввода-вывода I/O Device Management (IODM), пространство имен для которых появилось в VMware vSphere 5.1. Цель этих новых инструментов - дать администратору инструменты для понимания уровня, на котором происходят проблемы с хранилищем в сети SAN (см. тут).
Это новое пространство имен выглядит вот так:
esxcli storage san
Например, мы хотим сделать Reset для FC-адаптера:
esxcli storage san fc reset -A vmhba3
А потом посмотреть его лог, который включает в себя информацию о таких событиях, как разрыв соединения:
esxcli storage san fc events get
Можно собрать статистику по iscsi-адаптеру командой:
esxcli storage san iscsi stats get
Кроме того, в VMware vSphere 5.1 появились функции мониторинга твердотельных накопителей - SSD Monitoring, реализуемые метриками, которые собирает каждые полчаса демон S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology). Находятся стандартные плагины в /usr/lib/VMware/smart_plugins (кстати, вендоры дисковых устройств могут добавлять туда свои плагины вместо имеющихся generic-плагинов). Надо также отметить, что эти метрики не передаются в vCenter и доступны только через esxcli.
Посмотреть статистики SSD-дисков можно командой:
esxcli storage core device smart get -d naa.xxxxxx
Жирным выделены метрики, которые могут оказаться полезными. Параметр Reallocated Sector Count не должен сильно увеличиваться со временем для исправных дисков. Когда дисковая подсистема получает ошибку read/write/verification для сектора, она перемещает его данные в специально зарезервированную область (spare area), а данный счетчик увеличивается.
Media Wearout Indicator - это уровень "жизни" вашего SSD-диска (для новых дисков он должен отображаться как 100). По мере прохождения циклов перезаписи диск "изнашивается" и данный счетчик уменьшается, соответственно, когда он перейдет в значение 0 - его жизнь формально закончится, исходя из рассчитанного для него ресурса. Кстати, этот счетчик может временно уменьшаться при интенсивных нагрузках диска, а потом восстанавливаться со временем, если средняя нагрузка на диск снизилась.
В этой статье мы расскажем о новых возможностях, которое приобрело это средство номер 1 для создания iSCSI-хранилищ под виртуализацию Hyper-V.
Итак, что нового:
Много улучшений High Availability. Во-первых, улучшился уровень юзабилити - теперь интерфейсы выглядят проще и работают быстрее. Многие операции снабжены мастерами. Во-вторых, улучшился движок HA - теперь можно производить операции add, remove
и switch для HA-узла без вывода его в режим "Offline".
Новые функции HA-устройств. Теперь в качестве HA-устройств могут быть использованы такие девайсы как deduplicated, thin-provisioned IBV или
DiskBridge. Это означает, что теперь доступна функциональность дедупликации, thin provisioning, снапшоты и прочее для HA-устройств.
Улучшения дедупликации:
Asynchronous replication of deduplicated data - теперь данные для репликации по медленным каналам (WAN) могут передаваться асинхронно, что позволяет использовать решение в DR-сценариях. Кроме того, теперь любой тип устройства может быть целевым для репликации.
Deletion of unused data - неиспользуемые блоки, появляющиеся на дедуплицируемом хранилище, записываются актуальными данными, что позволяет использовать пространство более эффективно.
Decreased memory usage - в этой версии StarWind Native SAN на 30% снижены требования к памяти сервера. Теперь при использовании блоков 4 KB только 2 МБ оперативной памяти требуется на 1 ГБ хранимых данных.
Полная поддержка Windows Server 2012.
Скачать StarWind Native SAN for Hyper-V 6.0 можно по этой ссылке. И напоминаем, что у этого решения есть полнофункциональная бесплатная версия.
Таги: StarWind, iSCSI, SAN, Update, Hyper-V, Storage, HA
Некоторые из вас, вероятно, видели документ, называющийся "VMFS File Locking and Its Impact in VMware View 5.1", доступный у нас вот тут. Он вкратце рассказывает о нововведении в VMware View 5.1 - теперь для пулов связанных клонов (Linked Clones) можно использовать кластеры до 32-х хостов, а не 8 как раньше. Но работает это только для тех окружений, где реплика базового образа размещена на NFS-хранилище, для VMFS же хранилищ ограничение осталось тем же самым - кластер из максимум 8 хостов. Давайте разбираться, почему это так.
Во-первых, посмотрим как выглядит классическая структура связанных клонов в инсталляции VMware View:
В пуле связанных клонов, который мы можем построить с помощью VMware View Composer, находится создаваемый и настраиваемый базовый образ (может быть со снапшотом), из которого создается реплика этой ВМ (Replica), на базе которой из дельта-дисков строятся уже конечные десктопы пользователей. При этом данные реплики используются одновременно всеми связанными клонами, которые располагаются на хост-серверах ESXi кластера.
Теперь напомним, что мы уже рассматривали типы блокировок (локов) в кластерной файловой системе VMFS. Однако там рассмотрены не все блокировки, которые могут быть применены к файлам виртуальных дисков. Мы рассматривали только эксклюзивную блокировку (Exclusive Lock), когда только один хост может изменять VMDK-файл, а все остальные хосты не могут даже читать его:
Такие блокировки используются в традиционном окружении инфраструктуры виртуализации для серверной нагрузки в виртуальных машинах. Очевидно, что такие блокировки не подходят для доступа к данным файла виртуального диска реплики VMware View.
Поэтому есть и другие типы блокировок. Во-первых, Read-Only Lock (в этом режиме все хосты могут читать один VMDK, но не могут менять его):
Во-вторых, Multi-Writer Lock:
В режиме такой блокировки сразу несколько хостов могут получить доступ к VMDK-файлу на общем хранилище VMFS в режиме Read/Write. При использовании инфраструктуры связанных клонов на хранилище применяются локи типа Read-Only Lock и Multi-Writer Lock, что требует одновременного доступа нескольких хостов ESXi к одному файлу. Естественно, где-то в локе должны храниться данные о том, какие хосты используют его.
А теперь посмотрим на внутренности лока. Они как раз и содержат все UID (User ID) хостов, которые работают с VMDK-файлом, в структуре "lock holders". Надо отметить, что для работы автоматической процедуры обновления лока необходимо, чтобы его размер был равен одному сектору или 512 байтам. А в этот объем помещается только 8 этих самых UID'ов, а девятый уже не влезает:
Напомню, что мы говорим про диск реплики, который необходим сразу всем хостам кластера с виртуальными ПК этого пула. Поэтому, как и раньше, в VMware View 5.1 нельзя использовать для реплики, размещенной на томе VMFS, кластер из более чем восьми хост-серверов VMware ESXi.
Однако можно поместить реплику на том NFS. По умолчанию протокол NFS не поддерживает file locking, однако поддерживает механизм Network Lock Manager
(NLM), который использует схему блокировок "advisory locking":
В этой схеме клиенты файла NFS могут координировать между собой совместный доступ к файлу (в нашем случае - VMDK). При этом никакого лимита на 8 хостов в этом механизме нет. Однако раньше в VMware View не позволялось использовать более 8 хостов в кластере для пула связанных клонов.
Теперь это сделать можно и, во многих случаях, даже нужно, выбрав NFS-хранилище для пула Linked Clone:
Там собственно и будут раскрыты все новые возможности этого решения, у которого есть еще и полнофункциональная версия StarWind Native SAN for Hyper-V Free Edition, ограниченная лишь объемом хранилища (128 ГБ).
Многие знают компанию StarWind как производителя средства номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN под виртуальные машины VMware vSphere. Не так давно вышла обновленная версия StarWind iSCSI SAN 6.0 этого решения. Но, как известно, StarWind предлагает еще и отказоустойчивое решение для серверов Hyper-V.
15 ноября компания StarWind сделала 3 важных анонса, которые вам будут, безусловно, интересны:
Во-первых, вышла новая версия продукта под гипервизор Microsoft Hyper-V: StarWind Native SAN 6.0 (документ с описанием новых возможностей вот тут)
Во-вторых, вышла финальная версия решения для резервного копирования виртуальных машин на VMware vSphere, поставляемого в виде плагина - VMware Backup Plug-in. Теперь продукт полностью поддерживает новую платформу VMware vSphere 5.1.
Поскольку из этих новостей самая интересная - третья, то мы расскажем о бесплатном продукте StarWind Native SAN for Hyper-V Free edition. Он позволяет построить небольшой, но отказоустойчивый кластер хранилищ из двух серверов Microsoft Hyper-V на основе протокола iSCSI, без необходимости вложений во что бы то ни было - серверы под СХД или лицензии. Можно взять 2 обычных хост-сервера Hyper-V и забацать кластер.
Давайте взглянем на отличие бесплатного продукта от его платной версии:
StarWind Native SAN for Hyper-V
Free Edition - бесплатно
Small Business
Midsize Business
Enterprises
Компоненты продукта
Лицензируемая емкость хранилищ
Не ограничена
(HA-хранилище ограничено размером 128 ГБ)
1 ТБ / 2 ТБ (HA)
4 ТБ / 8 ТБ (HA)
16 ТБ/Не ограничено (HA)
Централизованное управление
StarWind Console
StarWind Console
StarWind Console
StarWind Console
Число серверов, входящее в лицензию
2
2 или 3
2 или 3
2 или 3
Число одновременных соединений по iSCSI к хранилищам
Из таблицы видно, что бесплатная версия StarWind Native SAN for Hyper-V Free edition практически ничем не отличается от платной, кроме ограничения на размер отказоустойчивого хранилища в 128 ГБ. Полное сравнение платного и бесплатного изданий StarWind Native SAN for Hyper-V доступно по этой ссылке.
Мы уже не раз затрагивали тему vswp-файлов виртуальных машин (файлы подкачки), которые используются для организации swap-пространства гипервизором VMware ESXi. Эти файлы выполняют роль последнего эшелона среди техник оптимизации памяти в условиях недостатка ресурсов на хосте. Напомним, что в гипервизоре VMware ESXi есть такие техники как Transparent Page Sharing, Memory Ballooning, a также Memory Compression, которые позволяют разбираться с ситуациями нехватки памяти, необходимой виртуальным машинам.
Напомним также, что первым эшелоном оптимизации памяти является техника Memory Ballooning. Она работает за счет использования драйвера vmmemctl.sys (для Windows), поставляемого вместе с VMware Tools. Он позволяет "надуть" шар внутри гостевой ОС (balloon), который захватывает физическую память, выделенную этой ОС (если ее много), и отдает ее другим гостевым операционным системам, которые в ней нуждаются. Этот balloon не позволяет гостевой ОС производить работу приложений с данной областью памяти, поэтому если им потребуется дополнительная память - она будет уходить в гостевой своп. Это более правильный подход, чем свопировать гостевую ОС в файл подкачки vswp на томе VMFS, поскольку операционная система сама лучше разбирается, что и когда ей класть и доставать из свопа (соответственно, быстродействие выше).
Однако, когда памяти у всех виртуальных машин совсем мало или отдельной ВМ ее требуется больше, чем сконфигурировано, а также происходит постоянное обращение к памяти (особенно, если в гостевых ОС нет VMware Tools), гипервизор начинает использовать vswp-файл подкачки, который по умолчанию находится в папке с виртуальной машиной. Мы уже писали о том, что в целях повышения быстродействия можно положить vswp-файлы виртуальных машин на локальные SSD-хранилища серверов ESXi, а также о том, как удалять мусорные файлы vswp.
Ниже мы приведем 8 фактов о swap-файлах виртуальных машин, которые основаны на вот этой заметке Фрэнка Деннемана:
1. Хранение vswp-файлов на локальных дисках сервера ESXi (в том числе Swap to Host Cache) увеличивает время vMotion. Это очевидно, так как приходится копировать vswp-файл в директорию ВМ (или другую настроенную директорию), чтобы его видел целевой хост.
2. С точки зрения безопасности: vswp-файл не чистится перед созданием. То есть там лежат не нули, а предыдущие данные блоков. Напоминаем, что размер файла подкачки равен размеру сконфигурированной памяти ВМ (если не настроен Reservation). Если же у машины есть Reservation, то размер vswp-файла определяется по формуле:
То есть, если в настройках памяти машины ей выделено 4 ГБ, а Reservation настроен в 1 ГБ, то vswp-файл будет составлять 3 ГБ.
3. Как происходит копирование vswp-файла при vMotion? Сначала создается новый vswp-файл на целевом хосте, а потом копируются только swapped out страницы с исходного в целевой vswp-файл.
4. Что происходит при разнице в конфигурации размещения vswp-файлов в кластере и для отдельных хостов? Напомним, что в настройках кластера VMware vSphere есть 2 опции хранения vswp-файлов: в папке с ВМ (по умолчанию) и в директории, которая указана в настройках хоста:
Если на одном хосте настроена отдельная директория для vswp, а на другом нет (то есть используется папка ВМ), то при vMotion такой виртуальной машины vswp-файл будет скопирован (в папку с ВМ), несмотря на то, что целевой хост видит эту директорию на исходном.
5. Обработка файлов подкачки при нехватке места. Если в указанной директории не хватает места для свопа ВМ, то VMkernel пытается создать vswp-файл в папке с ВМ. Если и это не удается, то виртуальная машина не включается с сообщением об ошибке.
6. vswp-файл лучше не помещать на реплицируемое хранилище. Это связано с тем, что используемые страницы памяти, находящиеся в двух синхронизируемых файлах, будут постоянно реплицироваться, что может вызывать снижение производительности репликации, особенно если она синхронная и особенно при vMotion в недефолтной конфигурации (когда происходит активное копирование страниц и их репликация):
7. Если вы используете снапшоты на уровне хранилищ (Datastore или LUN), то лучше хранить vswp-файлы отдельно от этих хранилищ - так как в эти снапшоты попадает много ненужного, содержащегося в своп-файлах.
8. Нужно ли класть vswp-файлы на хранилища, которые развернуты на базе thin provisioned datastore (на уровне LUN)? Ответ на этот вопрос зависит от того, как вы мониторите свободное место на тонких лунах и устройствах своего дискового массива. При создании vswp-файла VMkernel определяет его размер и возможность его создания на уровне хоста ESXi, а не на уровне устройства дискового массива. Поэтому если vswp-файл активно начнет использоваться, а вы этого не заметите при неправильной конфигурации и отсутствии мониторинга тонких томов - то могут возникнуть проблемы с их переполнением, что приведет к сбоям в работе ВМ.
Невозможно ощутить все преимущества виртуализации, не имея систему хранения данных. В рамках данного семинара мы расскажем, почему СХД NetApp наилучшим образом подходит для построения виртуальной инфраструктуры:
Мы уже писали о новых возможностях продукта номер 1 для создания откзоустойчивых хранилищ виртуальных машин StarWind iSCSI SAN & NAS 6.0, а также анонсировали вебинар "Что нового в версии 6.0", который прошел 24 октября. Для тех, кто пропустил это мероприятие, компания StarWind выложила запись этого вебинара на русском языке, который традиционно ведет наш коллега Анатолий Вильчинский.
Мы уже писали о том, что компания Veeam анонсировала скорую доступность решения номер 1 для резервного копирования и репликации виртуальных машин - Veeam Backup and Replication 6.5. Ожидается, что новая версия продукта будет выпущена в 4-м квартале этого года.
А пока пользователи ожидают новой версии продукта, компания Veeam выпустила документ "Veeam Backup & Replication What’s New in 6.5 Sneak Peek", из которого можно узнать о его новых возможностях. Итак, что же нового появится в новой версии B&R:
E-discovery and item recovery for Exchange Version 6.5 - в новой версии появился полнофункциональный Veeam Explorer for Exchange - технология поиска, просмотра и восстановления объектов (писем, папок, пользователей) из резервных копий почтовых серверов Exchange Server 2010. Делать это можно с резервными копиями ВМ, их репликами, а также снапшотами HP StoreVirtual VSA и LeftHand.
Restore from SAN snapshots - появилась технология Veeam Explorer for SAN Snapshots (пока только для хранилищ HP), которая поддерживает гранулярное восстановление виртуальных машин напрямую из снапшотов, сделанных устройствами хранения HP StoreVirtual VSA и HP LeftHand. Эта технология разработана совместно с HP и поддерживает все функции Veeam: Instant VM Recovery, Instant File-Level Recovery и Explorer for Exchange item recovery.
Поддержка VMware vSphere 5.1 - новая версия продукта полностью поддерживает обновленную платформу виртуализации, а также резервное копирование и репликацию виртуальных машин с гостевыми ОС Windows Server 2012 и Windows Server 8.
Полная поддержка функций Windows Server 2012 Hyper-V - Veeam Backup & Replication 6.5 поддерживает следующие возможности для Hyper-V:
Changed block tracking для томов CSV v2 и SMB v3
Поддержка формата виртуальных дисков VHDX
Поддерка больших дисков до 64 ТБ
Также Veeam Backup может быть использован для миграции на новую версию Hyper-V - можно создать резервные копии ВМ на Hyper-V 2008 R2 и восстановить их на Hyper-V 2012
Advanced monitoring, reporting and capacity planning - теперь, за счет еще более тесной интеграции с продуктом Veeam One в составе пакета продуктов Veeam Management Suite, решение Veeam B&R в составе позволяет выполнять следующие задачи:
Мониторинг инфраструктуры резервного копирования в реальном времени
Идентификация незащищенных виртуальных машин
Анализ доступных ресурсов, хранилищ и многое другое
Множество нововведений и улучшений: среди них можно отметить поддержку механизма дедупликации в Windows Server 2012, возможность резервного копирования конфигурации самого Veeam Backup and Replication, улучшения производительности и уменьшение потребления ресурсов, а также возможность восстановления файлов в гостевую ОС в их оригинальное размещение в один клик. Обо всех дополнительных нововведениях можно прочитать в первоисточнике.