Не так давно мы писали о новой версии продукта 5nine Manager for Hyper-V 3.7, который предоставляет локальный графический интерфейс пользователя (GUI) для Windows Server и Windows Server Core, а также для бесплатного Hyper-V Server. Этот продукт позволяет одновременно управлять гипервизором Microsoft Hyper-V различных версий (2012 R2 / 2012 / 2008 R2 SP1). Совсем недавно (в январе этого года) вышла версия 5nine Manager for Hyper-V 3.9.
Таги: 5nine, Manager, Update, Hyper-V, Storage

Калькулятор для расчета необходимой дисковой емкости под кластер VMware Virtual SAN (VSAN).

Мы довольно много пишем про кластеры хранилищ VMware Virtual SAN (VSAN), которые создаются на базе локальных дисков серверов VMware ESXi (например, тут и тут, а в последний раз - тут). А сегодня мы хотим рассказать о калькуляторе, который может пригодиться для расчета необходимой емкости хранилищ под Virtual SAN.

Написал его Duncan Epping, известный специалист по VMware vSphere и блоггер - один из немногих, которому можно верить.

Калькулятор рассчитывает общее количество требуемого дискового пространства (HDD и SSD-диски) как для кластера в целом, так и для одного хоста VMware ESXi, принимая в качестве исходных данных следующие параметры:

• Количество ВМ в кластере хранилищ.
• Объем оперативной памяти машины (vRAM).
• Размер виртуального диска машины.
• Число хостов, используемое для построения кластера.
• Параметр Failures to tolerate (о нем мы писали тут).
• Процент дискового пространства на метаданные и прочие издержки виртуализации хранилищ (по лучшим практикам - где-то 10%).
• Процент пространства, которое занимает SSD-накопитель от дискового пространства на базе HDD-дисков хоста ESXi.

Поиграть с калькулятором дискового пространства для Virtual SAN можно по этой ссылке.

Компания StarWind, лидер в разработке решений для создания программных отказоустойчивых iSCSI-хранилищ для виртуальных машин, провела серию вебинаров вместе с Microsoft Украина на русском языке на тему программных хранилищ данных в Windows Server 2012.

В рамках онлайн сессии Microsoft, Юрий Хохлов, ведущий инженер-программист компании StarWind Software, рассказал о iSCSI Target и SMI-S от компании StarWind, а также рассмотрел некоторые тонкости, которые могут быть полезными в рабочей среде.

Все это теперь доступно в записи. Первая часть выступления касается следующих моментов:

• Обзор базовой работы с дисками
• Динамические диски
• Обзор типов томов, которые можно построить в Windows Server
• Создание программных рейдов
• Организация Storage Spaces в Windows Server 2012 R2
• Управление внешними хранилищами на примере Windows Server 2012 R2 + StarWind

Во второй части записи онлайн-трансляции можно узнать о таких подробностях работы хранилищ, как:

• Обзор файловых систем
• Свойства NTFS
• Работа с квотами
• Линкование
• File Server Resource Manager
• Теневое копирование

В ближайшее время будут еще вебинары, так что не отключайтесь.

Более подробно о сотрудничестве компании StarWind и Microsoft Украина можно почитать тут. Пробная версия продукта StarWind Native SAN for Hyper-V доступна по этой ссылке - http://ru.starwindsoftware.com/native-san-for-hyper-v.

Ну и напомним последние новости о новой версии StarWind V8, выпуск которой ожидается в ближайшее время.

Мы уже немало писали про кластеры хранилищ VMware Virtual SAN (последнее - тут и тут), а сегодня рассмотрим механизм работы запросов на чтение блоков, который описал в своем блоге Duncan Epping.

Итак, схема кластера VMware Virtual SAN:

Здесь мы видим такую картину - виртуальная машина находится на хосте ESXi-01, а ее блоки размером 1 МБ размещаются на хранилищах разных хостов. При этом блоком 1 владеет ESXi-01, а блоком 2 - ESXi-03. Хост ESXi-02 не принимает участия в обработке запросов ввода-вывода.

Схема работы запроса на чтение проста - сначала проверяется наличие блока в кэше на чтение (Read cache), и если там блока не оказывается, то проверяется Write buffer на хранилище SSD (если блок еще не успел записаться на HDD) и непосредственно сам HDD-диск. В данном случае блок 1 нашелся на SSD-диске в кэше на чтение.

Второй же блок обслуживается хостом ESXi-03, но его не оказалось в кэше на чтение, и он читается с HDD-диска. Тут надо отметить, что кластер Virtual SAN помещает блоки в кэш на чтение только на тех хостах, которые активно обслуживают этот блок и владеют им, а те хосты, которые просто хранят копию данных - в Read cache таких блоков не помещают.

Некоторым администраторам может понадобиться информация о том, как узнать LUN ID в Windows Server 2012 R2, например, при создании отказоустойчивого кластера на платформе Hyper-V (Failover cluster).

Делается это просто. Запускаем cmd и открываем diskpart:

Смотрим подключенные устройства командой:

list disk

Выбираем нужный LUN командой:

select disk <number>

Смотрим свойства устройства, где и показан LUN ID, командой:

detail disk

Мы уже много писали о технологии VMware Virtual SAN (VSAN), которая позволяет создать отказоустойчивый кластер хранилищ для виртуальных машин на основе комбинации SSD+HDD локальных дисков серверов VMware ESXi. Не так давно вышла обновленная бетаэтого решения, кроме того мы не так давно писали о производительности VSAN тут.

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

Итак, в нормальном режиме функционирования, при значении параметра FailuresToTolerate равном 1, который означает, какое количество отказов хостов может пережить кластер хранилищ, реплика одного VMDK будет размещена на дисках еще одного из хостов кластера:

Тут можно заметить 5 особенностей кластера VMware VSAN:

• Виртуальный диск VMDK и его реплика всегда находятся на разных хост-серверах VMware vSphere.
• ВМ не обязательно должна исполняться на том хосте ESXi, на дисках которого находятся ее хранилища.
• Компонент witness находится на третьем по отоношению к виртуальному диску и его реплике хосте, чтобы создать определенность на случай разделения сети VSAN (где окажется 2 компонента из набора "vmdk-реплика-witness" - тот сегмент и будет определяющим).
• Сеть VSAN используется для операций ввода-вывода и определения доступности.
• Реплика VMDK-диска вместе с основной копией образуют RAID-1 массив, который увеличивает производительность операций чтения в виртуальной машине, так как для чтения используются оба хранилища.

Кроме того, вследствие особенностей реализации кластера VSAN, надо понимать, что команды ввода-вывода не применяются к диску данных виртуальной машины, пока не пришло подтверждение об их записи на реплике. Но подтверждение приходит не от HDD-диска, где находятся данные ВМ (это было бы очень медленно), а от SSD-диска, который используется как энергонезависимый Write Buffer для команд ввода вывода. Таким образом, этот буфер (и данные, само собой) зеркалирован в рамках дисковой группы на другом хосте ESXi.

Теперь рассмотрим различные виды сбоев в кластере VSAN.

1. Ломается диск дисковой группы, где исполняется виртуальная машина.

Выглядит это так:

В этом случае такой диск сразу же помечается как "degraded", а команды ввода-вывода перенаправляются на другой хост-сервер VMware ESXi. При этом виртуальная машина этого не замечает, так как переключается на работу с SSD-буфером/кэшем и HDD-дисками другого хоста мгновенно (данные на момент сбоя были синхронизированы, ничего не потерялось).

Одновременно с этим сразу же начинается процесс построения реплики на другом хосте ESXi в рамках его дисковой группы, при этом проверяется, достаточно ли там свободных дисковых ресурсов. Если их недостаточно, то механизм VSAN будет ожидать. Как только вы добавите диски/дисковые группы на хостах - сразу же начнется процесс построения реплики (до его окончания машина будет помечена как "degraded").

Тут надо отметить, что в degraded-состоянии скорость записи данных останется прежней, простоя не будет, а вот скорость чтения упадет до построения новой реплики, поскольку второй копии данных пока нет.

2. Отказывает хост VMware ESXi целиком.

В этом случае запускать процесс восстановления сразу же, конечно, не нужно - мало ли что могло случиться с хостом, например, его случайно перезагрузили, или временно пропало сетевое соединение.

В этом случае происходит ожидание в течение 60 минут, и если отказавший хост ESXi не оживет, то начнется процесс создания реплики виртуального диска VMDK на другом хосте. Это время можно изменить в расширенной настройке кластера VSAN.ClomRepairDelay, но пока не известно будет ли это поддерживаться со стороны VMware.

3. Отказ SSD-диска в дисковой группе.

В кластере VMware Virtual SAN поддерживается 1 SSD-диск и до 7 HDD-дисков в одной дисковой группе. Всего на один хост VMware ESXi поддерживается до 5 дисковых групп.

В данном случае Failure Domain - это вся дисковая группа, включающая в себя SSD-диск, который используется для двух типов операций:

• Read Cache (70% емкости) - безопасное кэширование операций на чтение. На SSD-диске хранятся наиболее часто используемые блоки, что уменьшает I/O read latency для ВМ.
• Write Buffering (30% емкости) - когда приложение внутри гостевой ОС пытается записать данные, оно получает подтверждение записи тогда, когда данные фактически записаны на SSD (не на HDD), таким образом твердотельный накопитель используется как буфер на запись, что небезопасно при внезапном пропадании питания или отказе хоста. Поэтому данные этого буфера дублируются на других хостах кластера и их SSD-дисках.

Таким образом, при отказе SSD-диска, виртуальная машина начинает использовать реплику на уровне всей дисковой группы на другом хосте VMware ESXi. Вот почему выгодно делать две дисковых группы 3HDD+1SSD, чем одну  6HDD+1SSD.

Вот, в общем-то, и все. Более подробно об использовании SSD-дисков, их производительности и ресурсе можно прочитать вот в этой статье.

Продолжаем рассказывать о решении StarWind iSCSI SAN, предназначенном для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин (есть версия как для VMware, так и для Hyper-V).

Многих пользователей StarWind волнует вопрос о миграции хранилищ с Windows 2008 на Windows 2012 R2, которую они планируют сделать одновременно с обновлением на StarWind V8.

Вот простой алгоритм, как правильно обновить ОС узлов StarWind iSCSI SAN и (опционально) обновить сам продукт на новую версию:

1. Используя Replication manager, необходимо отсоединить все узлы-партнеры от устройств первого узла (StarWind1).
2. На этом узле (StarWind1) нужно установить новую ОС.
3. Далее нужно установить StarWind V6 на этом узле. 
4. Ко всем устройствам на StarWind1 нужно добавить их HA-партнеров через Replication manager и запустить синхронизацию.
5. Дождаться окончания синхронизации и соединиться с новыми таргетами.
6. Удалить всех HA-партнеров от второго (StarWind2) через Replication manager.
7. Установить новую ОС на StarWind2.
8. Установить StarWind V6 на StarWind2. 
9. Добавить партнеров ко всем HA-устройствам на узле StarWind2 через Replication manager.
10. Дождаться окончания синхронизации и соединиться с новыми таргетами.
11. Обновить StarWind V6 на StarWind V8, следуя вот этой процедуре.

Более подробно этому посвящена вот эта ветка форума StarWind.

Коллеги рассказали про интересный случай: создали RDM-диск для двух виртуальных машин MSCS-кластера "across boxes", подцепили его к виртуальным машинам на двух хостах ESXi, а производительность на нем упала до 10 МБ/сек, хотя этот диск находится на быстром FC-хранилище EMC VNX и скорость должна измеряться сотнями МБ/сек. При этом в качестве хост-платформы используется VMware vSphere 5.1.

Ответ оказался простым - для хранилищ EMC VNX хост ESXi выставляет политику путей по умолчанию Round Robin (балансировка по двум путям). При использовании кластера MSCS на кворумном диске вызываются SCSI-3 резервации. SCSI-3 резервация (registration) посланная по одному пути позволяет производить дальнейшие резервации или SCSI-команды только по этому пути.

А при использовании политики Round Robin, когда плагин PSP_RR переключает на другой путь, кластер MSCS получает ошибку и пробует сделать SCSI-3 резервацию повторно или выполнить другие команды.

Поэтому вместо политики Round Robin для конкретного хранилища и для данного RDM-диска надо использовать следующие политики путей (плагины PSP_MRU или PSP_FIXED), в зависимости от типа хранища. Они приведены в KB 1010041 и в таблице ниже:

Для того, чтобы выставить политику путей, нужно в разеле Storage в vSphere Client выбрать нужный HBA-адаптер и устройство, для которого создан RDM-диск, и из его контекстного меню выбрать пункт Manage Paths (это также можно сделать в свойствах виртуальной машины для диска):

После выставления корректной политики путей скорость для кворумного диска MSCS вырастет в разы. Кстати, если вы используете VMware vSphere 5.5 и выше, то такого поведения там уже нет, и все работает корректно.

О новых возможностях VMware vSphere 5.5 по поддержке кластеров MSCS мы уже писали вот тут.

Как многие знают, в VMware vSphere 5.5 появились возможности Virtual SAN, которые позволяют создать кластер хранилищ для виртуальных машин на основе комбинации SSD+HDD локальных дисков серверов VMware ESXi. Не так давно вышла обновленная бета этого решения, кроме того мы не так давно писали о производительности VSAN тут и тут.

Сегодня же мы поговорим о том, как нужно сайзить хранилища Virtual SAN в VMware vSphere, а также немного затронем тему отказоустойчивости. Более детальную информацию можно найти в VMware Virtual SAN Design & Sizing Guide, а ниже мы расскажем о подходе к планированию хранилищ VSAN вкратце.

Объекты и компоненты Virtual SAN

Начнем с простого ограничения по объектам (objects) и компонентам (components), которое есть в VSAN. Виртуальные машины, развернутые на vsanDatastore, могут иметь 4 типа объектов:

• Домашняя директория виртуальной машины Virtual Machine ("namespace directory").
• Объект файла подкачки - swap object (для включенной ВМ).
• Виртуальный диск VMDK.
• Дельта-диски для снапшотов. Каждый дельта-диск - это отдельный объект.

Каждый объект, в зависимости от типа RAID, рождает некоторое количество компонентов. Например, один VMDK, размещенный на двух томах страйпа (RAID 0) рождает два объекта. Более подробно об этом написано вот тут.

Так вот, ограничения тут следующие:

• Максимальное число компонентов на 1 хост ESXi: 3000.
• Максимальное число компонентов для одного объекта: 64 (это включает в себя тома страйпов и также реплики VMDK с других хостов).

На практике эти ограничения вряд ли актуальны, однако о них следует знать.

Сколько дисков потребуется для Virtual SAN

Во второй бета-версии VSAN (и, скорее всего, так будет в релизной версии) поддерживается 1 SSD-диск и до 7 HDD-дисков в одной дисковой группе. Всего на один хост VMware ESXi поддерживается до 5 дисковых групп. Таким образом, на хосте поддерживается до 5 SSD-дисков и до 35 HDD-дисков. Надо убедиться, что контроллеры хоста поддерживают необходимое количество дисков, а кроме того нужно проверить список совместимости VSAN HCL, который постоянно пополняется.

Также надо учитывать, что кластер хранилищ Virtual SAN поддерживает расширение как путем добавления новых дисков, так и посредством добавления новых хостов в кластер. На данный момент VMware поддерживает кластер хранилищ максимум из 8 узлов, что суммарно дает емкость в дисках в количестве 40 SSD (1*5*8) и 280 HDD (7*5*8).

Сколько дисковой емкости нужно для Virtual SAN (HDD-диски)

Необходимая емкость под размещение VMDK зависит от используемого параметра FailuresToTolerate (по умолчанию 1), который означает, какое количество отказов хостов может пережить кластер хранилищ. Если установлено значение 1, то реплика одного VMDK будет размещена на дисках еще одного из хостов кластера:

Тут можно сказать о том, как работает отказоустойчивость кластера Virtual SAN. Если отказывает хост, на котором нет виртуальной машины, а есть только VMDK или реплика, то виртуальная машина продолжает работу с основной или резервной копией хранилища. В этом случае начнется процесс реконструкции реплики, но не сразу - а через 60 минут, чтобы дать время на перезагрузки хоста (то есть если произошел не отказ, а плановая или внеплановая перезагрузка), а также на короткие окна обслуживания.

А вот если ломается хост, где исполняется ВМ - начинается процедура восстановления машины средствами VMware HA, который перезапускает ее на другом хосте, взаимодействуя при этом с Virtual SAN.

Более подробно этот процесс рассмотрен вот в этой статье и вот в этом видео:

Однако вернемся к требующейся нам емкости хранилищ. Итак, если мы поняли, что значит политика FailuresToTolerate (FTT), то требуемый объем хранилища для кластера Virtual SAN равняется:

Capacity = VMDK Size * (FTT + 1)

Что, в принципе, и так было очевидно.

Сколько дисковой емкости нужно для Virtual SAN (SSD-диски)

Теперь перейдем к SSD-дискам в кластере VSAN, которые, как известно, используются для вспомогательных целей и не хранят в себе данных виртуальных машин. А именно, вот для чего они нужны (более подробно об этом тут):

• Read Cache - безопасное кэширование операций на чтение. На SSD-диске хранятся наиболее часто используемые блоки, что уменьшает I/O read latency для ВМ.
• Write Buffering - когда приложение внутри гостевой ОС пытается записать данные, оно получает подтверждение записи тогда, когда данные фактически записаны на SSD (не на HDD), таким образом твердотельный накопитель используется как буфер на запись, что небезопасно при внезапном пропадании питания или отказе хоста. Поэтому данные этого буфера дублируются на других хостах кластера и их SSD-дисках.

Так каковы же рекомендации VMware? Очень просты - под SSD кэш и буфер неплохо бы выделять 10% от емкости HDD-дисков хоста. Ну и не забываем про значение FailuresToTolerate (FTT), которое в соответствующее число раз увеличивает требования к емкости SSD.

Таким образом, необходимая емкость SSD-хранилищ равна:

Capacity = (VMDK Size * 0.1) * (FTT + 1)

Ну и напоследок рекомендуем отличнейший список статей на тему VMware Virtual SAN:

• VSAN Part 1 – A first look at VSAN
• VSAN Part 2 – What do you need to get started?
• VSAN Part 3 – It is not a Virtual Storage Appliance
• VSAN Part 4 – Understanding Objects and Components
• VSAN Part 5 – The role of VASA
• VSAN Part 6 – Manual or Automatic Mode
• VSAN Part 7 – Capabilities and VM Storage Policies
• VSAN Part 8 – The role of the SSD
• VSAN Part 9 – Host Failure Scenarios and vSphere HA interop
• VSAN Part 10 – Changing VM Storage Policy on-the-fly

Мы уже писали о технологии VMware Virtual SAN, которая сейчас находится в режиме бета-тестирования. Кроме того, мы затрагивали тему производительности виртуальных ПК VMware Horizon View на хранилищах Virtual SAN (там про то, что VSAN масштабируется почти без потерь производительности).

Сегодня мы хотим рассказать еще о двух вещах. Во-первых, компания VMware выпустила обновление беты Virtual SAN, которое получило следующие новые возможности:

• AHCI fix - как писала VMware ранее, была проблема с контроллерами AHCI, которая приводила к потере данных на устройствах VSAN (см. PDL, Permanent Device Loss). Теперь эту проблему исправили, и можно продолжать тестирование на этих контроллерах.

• New RVC Commands - теперь в Ruby Virtual Console, которая входит в состав VMware vCenter 5.5, есть команды по управлению хранилищами в пространстве имен spbm (Storage Policy Based Management). Существующие политики можно найти в папке "~/storage/vmprofiles".

• PowerCLI fling - многим пользователям интересна автоматизация задач в VMware vCloud Suite. Теперь и для VSAN есть набор командлетов PowerCLI, которые позволяют управлять хранилищами VSAN. Более подробно об этом здесь.

• Limit Changes - в первой бета-версии дисковая группа могла иметь 1 SSD-Накопитель и до 6 HDD-дисков, но поскольку есть серверы, в которых восемь слотов, то HDD-дисков теперь поддерживается до 7 штук (SSD по-прежнему один).

Во-вторых появилась третья статья в серии про Virtual SAN - "VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 3" из цикла статей, где делаются всяческие замеры производительности хранилищ VSAN.

В этот раз сравнивалось некий дисковый массив "all flash storage array", который работает на SSD-накопителях, и 7-ми и 8-ми узловые кластеры Virtual SAN. Результаты в очках, поставленных VDImark (View Planner QoS), поставленные кластеру из хостовых хранилищ и дисковому массиву:

Напомним, что очки VDImark - это число виртуальных машин, которое может быть запущено на данной аппаратной конфигурации с соблюдением определенного порогового значения для операций (на самом деле минимум 95% операций должны попасть в эти трешхолды для ВМ, чтобы их засчитали).

Результаты тестов оказались весьма неплохими. Картинка для тестов по времени отклика операций группы А (интерактивные операции пользователя):

Группа B:

Вывод: Virtual SAN - очень неплох в сравнении с нативной производительностью какого-то SSD-массива (VMware, что это за массив-то??).

Ну и ссылки на все статьи цикла:

• VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 1
• VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 2
• VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 3

Не так давно мы писали про новые возможности VMware Horizon View 5.3 - одного из лидирующих решений на рынке виртуализации корпоративных ПК. Несколько дней назад этот продукт стал доступен для скачивания (линк на загрузку).

Напомним, что основной ожидаемой новой возможностью VMware Horizon View 5.3 стала полноценная поддержка 3D-графики в виртуальных ПК в режиме vDGA (пока только для карт NVIDIA).

Напомним вкратце о новых возможностях VMware View 5.3 (полный список - тут и в Release notes):

• Windows Server 2008 R2 Desktop Operating System Support - возможность использовать эту ОС для виртуальных ПК, что интересно для тех организаций, который хотят предоставлять виртуальные ПК в аренду (кастомизировав серверную ОС под десктопную, так как Microsoft запрещает предоставление в аренду настольных ОС).
• Поддержка Windows 8.1 для виртуальных ПК.
• Использование VMware Horizon Mirage для управления десктопами View (подробнее - тут).
• Поддержка технологии Virtual SAN и таких хранилищ для десктопов (по-прежнему, в бета-режиме).
• Memory Recommendation messages - возможность получения рекомендаций для сайзинга по памяти Connection Server.
• Полноценная поддержка режима Virtual Dedicated Graphics Acceleration (vDGA).
• Улучшения механизма связанных клонов - теперь для пула Linked-Clone доступна политика Storage Overcommit.
• View Persona Management Supportability Improvements - улучшения режима виртуализации пользовательских профилей.
• Возможность добавлять группу "Администраторы" к перенаправляемым механизмом Persona Management папкам.
• Плагин View Agent Direct-Connection Plug-in - возможность организовать прямое соединение по протоколу PCoIP между клиентом и виртуальным ПК, минуя View Connection Server.
• View Composer Array Integration Support - полноценно поддерживается технология View Composer API for Array Integration (VCAI), которая позволяет передать часть операций по работе с виртуальными ПК на сторону дискового массива.
• Поддержка до 350 соединений для шлюза Blast Secure Gateway.
• VMware ThinApp 5.0 - обновленная версия средства для виртуализации приложений.
• Клиент VMware View Client 2.2 при использовании ОС Linux теперь может работать с аудио/видео-потоком.
• Поддержка Multimedia Redirection для десктопов Windows 7
• Обновленный HTML Access в составе Horizon View 5.3 Feature Pack (куча улучшений)
• Flash URL Redirection - перенаправление swf-потока на клиентское устройство.
• Режим Unity Touch теперь поддерживается для Windows Server 2008 R2 и Windows 8.1.
• USB 3.0 redirection support - возможность перенаправления таких устройств в виртуальные ПК.
• Поддержка БД Oracle 11.2.0.3.

Кроме этого, были обновлены все клиенты VMware View до версии 2.2 (теперь поддерживается iOS 7). Вот документация по этим клиентам, где можно узнать о новых возможностях каждого:

•  iOS
• Android
• Mac OS X
• Linux
• Windows
• Windows Store
• HTML Access (Blast)

Теперь официальные документы по Horizon View 5.3:

• What’s New in VMware Horizon View 5.3
• Using VMware Horizon View Client for Windows (View 5.3)
• VMware Horizon View Feature Pack Installation and Administration (View 5.3)
• Using VMware Horizon View HTML Access (View 5.3)
• VMware Horizon View Agent Direct-Connection Plugin Administration (View 5.3)

Остальные документы еще не обновились.

Интересное видео по настройке View 5.3 совместно с хранилищами VSAN:

И на эту же тему интересная статья - Horizon View 5.3 Storage Optimization Features–Deep Dive.

Прямое соединение по PCoIP:

Скачать VMware Horizon View 5.3 можно по этой ссылке.

С выходом обновленной версии платформы виртуализации VMware vSphere 5.5 компания VMware ввела новую модель Native Device Driver Architecture, которая позволяет использовать нативные драйверы для VMkernel вместо драйверов под Linux.

Однако, помимо этого нововведения, VMware также убрала и неофициальную поддержку многих SATA-контроллеров, которые раньше и не заявлялись как работающие, но вполне нормально функционировали на whitebox-конфигурациях (например, контроллеры ASMedia и Marvell). Теперь многие SATA-контроллеры в ESXi 5.5 просто не работают.

Но не все так плохо. Поскольку поддержка старой модели драйверов еще осталась (неизвестно будет ли она в следующей версии ESXi, но скорее всего будет, так как не все партнеры успеют перейти на новую модель), то можно заставить работать некоторые неподдерживаемые контроллеры SATA AHCI, поскольку сам драйвер AHCI остался в виде модуля VMkernel (ahci). Andreas Peetz не только написал хорошую статью о том, как это сделать, но и сделал кастомные VIB-пакеты для добавления поддержки некоторых SATA-контроллеров AHCI.

Суть такая - автор раньше думал, что команда vmkload_mod ahci заставляет ESXi загружать драйверы для всех обнаруженных PCI-устройств, то оказалось, что она конфигурирует только устройства, которые есть в файле /etc/vmware/driver.map.d/ahci.map. А там неподдерживаемых девайсов не появляется. Поэтому надо сделать отдельный map-файл и добавить ссылки соответствующих устройств (их PCI ID) на драйвер AHCI.

Андреас сделал VIB-пакет позволяющий добавить поддержку ESXi следующих SATA-контроллеров:

• ASMedia Technology Inc. ASM1061 SATA IDE Controller (1b21:0611)
• ASMedia Technology Inc. ASM1062 Serial ATA Controller (1b21:0612)
• Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s controller (1b4b:9123)
• Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller (1b4b:9172)

В каментах Андреас принимает заявки на добавление поддержки нужных SATA-контроллеров, так что если их в приведенном выше списке - пишите ему и он добавит.

Процедура добавления поддержки контроллеров такова. Добавляем возможность использования кастомных драйверов на ESXi:

esxcli software acceptance set --level=CommunitySupported

Разрешаем использование http на хосте в фаерволе:

esxcli network firewall ruleset set -e true -r httpClient

Устанавливаем VIB-пакет:

esxcli software vib install -v https://esxi-customizer.googlecode.com/files/sata-xahci-1.0-1.x86_64.vib

Пакет sata-xahci предоставляется как в виде VIB-файла, так и в виде Offline Bundle. Включить драйверы в состав установщика ESXi можно с помощью инструментов ESXi-Customizer или ESXi-Customizer-PS.

В отделе маркетинга компании StarWind Software, ведущего производителя решений для создания программных отказоустойчивых iSCSI-хранилищ, открыта вакансия технического писателя в Киеве!

Обязанности:

• Создание и оформление технической и эксплуатационной документации (презентаций, web-сайтов, руководств пользователей, хелп-файлов);
• Перевод технической и маркетинговой документации на русский/английский;
• Контроль качества и стилистическое редактирование документации;
• Тесное сотрудничество с отделами R&D и Q&A.

Ключевые навыки:

• Отличное владение письменным русским языком;
• Уверенный технический английский язык;
• Знания в области СХД и виртуализации (Microsoft, VMware);
• Умение четко и структурировано излагать свои мысли;
• Опыт написания технической документации.

Хотите присоединиться к замечательной команде? Присылайте резюме: hr@starwindsoftware.com.

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

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

Напомним, что Flash Read Cache позволяет использовать кэширование данных только на чтение для дисков VMDK виртуальных машин, работает она на уровне гипервизора и существенно улучшает производительность виртуальных машин, которые интенсивно используют подсистему ввода-вывода для операций на чтение. Очевидно, что SSD-кэш, который по производительности находится между оперативной памятью и обычными дисками, существенно повышает быстродействие в системах, где периодически наблюдается недостаток ресурсов RAM. Все это дело работает в кластере до 32 хостов ESXi.

Итак, первый документ о том как работает технология Flash Read Cache - "What’s New in VMware vSphere Flash Read Cache":

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

Второй документ - это официальный FAQ VMware по технологии Flash Read Cache - "VMware vSphere Flash Read Cache 1.0 FAQ". Так как она появилась впервые, и не все технические особенности ясны администраторам, в документе даны ответы аж на 67 вопросов.

Интересные факты из этого FAQ:

• В качестве интерфейсов накопителей поддерживаются SATA, SAS и PCI Express.
• До 8 устройств vFlash на один хост ESXi и до 4 ТБ емкости на устройство (до 400 ГБ на один VMDK). На один контейнер VFFS (то есть на хост) поддерживается до 32 ТБ.
• В качестве хранилищ ВМ механизмом поддерживаются тома VMFS/NFS/vRDM (pRDM не поддерживается).
• Настраивается только через Web Client.
• При изменении настроек vFlash все кэши для дисков сбрасываются.
• Thin provisioning не поддерживается технологией vFlash.
• При миграции виртуальной машины средствами vMotion можно использовать 2 политики: Always migrate the cache contents (copy) - кэш копируется вместе с ВМ и Do not migrate the cache contents (drop) - кэш очищается. Техники VMware HA / SVMotion также полностью поддерживается.
• Механизм VMware DRS при миграции не затрагивает машины с включенным Virtual Flash Read Cache.
• Операции, которые очищают кэш ВМ: suspend, изменение конфигурации, удаление, перезапуск машины или хоста, восстановление из снапшота. Операции, которые не очищают кэш: снятие снапшота, клонирование, миграция vMotion, fast suspend/resume.
• В vCenter есть 3 специальных метрики для мониторинга vFlash (IOPS, Latency и объем кэша).
• Кэшем vFlash можно управлять через ESX CLI: get –m <module> -c <cache file name>
• Файлы кэша vFlash находятся в следующей директории на хосте: /vmfs/volumes/vffs/vflash

Информацию об официально поддерживаемых механизмом VMware vSphere Flash Read Cache устройствах можно найти по этой ссылке: http://www.vmware.com/resources/compatibility/search.php?deviceCategory=vfrc

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

Консоль управления, свойства тома с файловой системой LSFS:

Обзор доступных хранилищ StarWind v8...

Продолжаем рассказывать о решении StarWind iSCSI SAN V8, предназначенном для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин, которое имеет множество новых возможностей, о которых мы писали в посте про первую бету продукта StarWind V8.

Недавно вышла вторая бета-версия продукта StarWind V8 Beta 2, все в том же зомби-стиле:

Основные новые возможности StarWind V8 Beta 2:

• L2 Flash Cache - кэш уровня L2, который работает непосредственно с кэшем уровня L1 в RAM, что существенно улучшает производительность.
• Файловая система LSFS, которая изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины (это дело недалекого будущего). Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.
• Inline-дедупликация StarWind, которая не создает нагрузку на подсистему хранения и не "крадет" IOPS'ы у продуктивного хранилища.
• Simplified and improved GUI - улучшенный интерфейс мастеров развертывания хранилищ для Windows Server 2012 с поддержкой скриптов PowerShell.
• Возможность интеграции с механизмом SMI-S для Windows Server 2012 R2.

Новые возможности, относящиеся именно к Beta 2:

• Massive Scale-Out storage architecture - возможность масштабирования узлов кластера хранилищ до любого числа (а не только 3 как сейчас).
• Asynchronous WAN-replication - возможность асинхронной репликации между узлами и возможность создания катастрофоустойчивого решения для хранилищ.
• Поддержка примитивов VAAI для устройств на одном узле и устройств с синхронной репликацией: поддерживаются команды WRITE SAME, EXTENDED COPY, ATS.
• Репликация конфигурации узла, включая информацию о снапшотах, что позволяет в случае сбоя сохранить созданную оригинальную конфигурацию и реплицировать ее уже, например, на третий узел.

Скачать StarWind V8 Beta 2 можно по этой ссылке, а лицензионный ключ можно взять тут.

Продолжаем рассказывать о решении StarWind iSCSI SAN V8, предназначенном для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин, которое имеет множество новых возможностей.

Не так давно компания StarWind со своим флагманским продуктом (StarWind iSCSI SAN & NAS) попала в шортлист награды Storage, Virtualization, Cloud (SVC) Awards 2013 сразу в двух номинациях: "Virtualization Management Product of the Year" и "Storage Virtualization Product of the Year".

В этом посте мы просим вас проголосовать за наших коллег из Украины для того, чтобы поддержкать один из лучших продуктов для создания iSCSI-хранилищ под виртуальные машины.

Голосуйте!

Мы уже писали о технологии VMware VSAN, которая позволяет построить распределенный кластер хранилищ на базе локальных дисков серверов VMware ESXi. Этот кластер позволяет отказоустойчиво хранить виртуальные машины и обращаться к ним с любого из хостов. Недавно компания VMware опубликовала результаты тестов работы ВМ в VDI-инфраструктуре на базе хранилищ VSAN.

Продолжаем рассказывать о решении StarWind iSCSI SAN V8, предназначенном для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин, которое имеет множество новых возможностей.

Некоторые из вас знают, что для малого бизнеса есть небольшие ("настольные") системы хранения данных, например, WD Sentinel DX4000. Так вот компания StarWind состоит в партнерстве с WD, которая интегрирует решения StarWind iSCSI Target в свои хранилища. Об этом есть отдельный док "WD Integrates StarWind iSCSI SAN & NAS to Their WD Sentinel TM DX4000 NAS Appliance":

iSCSI Target от StarWind конфигурируется через WD Sentinel Dashboard и позволяет использовать хранилища для виртуальных машин VMware vSphere/Citrix XenServer/Microsoft Hyper-V для небольших инсталляций. Все это включает в себя надежное кэширование от StarWind, которое существенно повышает производительность работы.

Не так давно мы писали о технологии VMware VSAN, которая позволяет строить распределенные кластеры хранилищ на базе локальных дисков серверов VMware ESXi и которая была анонсирована на прошедшей конференции VMworld 2013. Напомним, что эта технология была куплена вместе с компанией Virsto Software (у нее русские корни, между прочим), и она на данный момент находится в статусе бета-версии. Эта штука умеет использовать локальные диски как источник хранения данных, а SSD-накопители - как кэш на чтение и буфер на запись.

На днях компания VMware выпустила интересный документ для тех, кто хочет немного вникнуть в архитектуру решения VMware VSAN - "What’s New in VMware Virtual SAN (VSAN)".

Документ содержит следующие секции:

• Introduction
• Requirements
• Install and Configure
• Architecture Details
• Storage Policy Based Management

Пример создания кластера VSAN представлен ниже - видно, что он поддерживает все распределенные службы VMware - HA, DRS, vMotion и прочее.

Создаваемые VSAN-хранилища управляются на базе политик, которые определяются правилами, например, избыточность в хостах или число дисковых страйпов:

Эти политики хранилищ можно назначать виртуальным машинам при создании, а также проверять различные сущности VMware vSphere на соответствие им. В общем, интересный документ - почитайте.

В последнее время очень и очень модным стал запуск публичных облаков, предоставляющих в аренду виртуальные машины (Infrastructure as a Service - IaaS). Мы уже писали про многих и продолжаем следить за следующими игроками на этом рынке:

• Amazon AWS - лидер на рынке облачных вычислений, предоставляющий сервисы IaaS на основе гипервизора Xen.
• Rackspace - второй после Амазона в США.
• VMware vCloud Hybrid Service - публичное облако от VMware, ориентированное на крупные компании.
• Microsoft Windows Azure - публичное облако Microsoft на основе собственной ветки гипервизора Hyper-V.
• Google Compute Engine - анонсированное недавно публичное облако Google, предназначенное для аренды мощностей под ресурсоемкие вычисления.
• Oracle Public and Private Cloud - решение полностью поддерживающее ПО Oracle.
• Citrix CloudStack 3 - облачный сервис аренды виртуальных машин от Citrix.

И это далеко не полный перечень того, что присутствует сейчас на рынке. Каждый уважающий себя вендор создает свое собственное публичное облако, обязательно с какой-то своей фишкой и дистанцированием от конкурентов. Но нас не обманешь - скоро половина из этих облаков вымрет, оставив на рынке 2-4 популярных решения для большинства задач.

Однако заметка не об этом, а о том, что компания Verizon, известный штатовский телекоммуникационный провайдер, также объявила о запуске своей публичной IaaS-инфраструктуры.

Verizon выходит на тропу войны с конкурентами, прежде всего Amazon и Rackspace, предоставляя два основных продукта:

• Verizon Cloud Compute - аналог облака Amazon EC3, предназначенного для получения вычислительных мощностей ВМ по требованию.
• Verizon Cloud Storage - сервис хранения данных, аналогичный сервису облачного хранения Amazon S3.

Сервис предоставляется на базе виртуальных машин под управлением гипервизора Xen, а сами ВМ будут чарджиться на основе платы за почасовое использование. Для пользователей будет доступна возможность выбора требуемого уровня сервиса (SLA) и модная нынче архитектура software-defined data center.

Интересно что инфраструктура Verizon Enterprise Cloud будет построена на базе вычислительных коробок с 4 ТБ оперативной памяти и 100 ТБ дискового пространства, занимающих аж 10 юнитов в стойке каждая (все расчитано на 50-100 виртуальных машин). Для пользователей заявляется такое преимущество - в отличие от конкурентов, размер ресурсов серверов можно будет задавать полностью по требованию, без дискретных уровней (как, например, есть сейчас у Rackspace).

Сервис будет запущен на базе следующих семи датацентров по всему миру:

• Culpepper, Va.
• Santa Clara, Calif.
• Denver
• Miami
• London
• Amsterdam
• Sao Paulo, Brazil;

В 2014 году добавится еще азиатский датацентр.

Конечно же Verizon не новичок на этом рынке - еще в далеком (по меркам облаков) 2009 году в программе VMware vCloud участвовал купленный впоследствии сервис-провайдер Terremark (тогда еще это была отдельная от Verizon компания).

Больше подробностей про облако Verizon можно узнать на специальном ресурсе - verizonenterprise.com/verizoncloud, где также происходит набор участников в бета-программу.

Ну и напоследок - писькомер. Как все хорошо у Verizon, и как все плохо у Amazon и Rackspace:

Многие администраторы виртуальной инфраструктуры VMware vSphere сталкиваются с необходимостью копировать файлы в гостевую ОС виртуальных машин. Делают они это путем копирования на системную шару или обычный общий ресурс, пробросом дисков через RDP и прочими методами.

Но многое из этого оказывается неприемлемым по тем или иным причинам. Чтобы этого всего избежать, Manfred Meier выложил на сайте VMware Directory утилиту vGuestExplorer, которая позволяет получить доступ к файловой системы гостевой ОС виртуальной машины даже без непосредственного сетевого соединения с ней.

Делается это посредством соединения по PowerCLI / PowerShell через VIX API к гостевой ОС виртуальной машины. Можно подключаться к серверу VMware vCenter, а можно к отдельному хосту VMware ESXi. Обязательно наличие установленных VMware Tools в гостевой ОС.

Работает vGuestExplorer как для Windows, так и для Linux.

Установка утилиты проста:

• Устанавливаем PowerCLI и выставляем параметр Set-Executionpolicy как Unrestricted.
• Выполняем PowerCLI как Administrator и запускаем команду:
  Set-PowerCLIConfiguration -InvalidCertificateAction ignore -ProxyPolicy NoProxy -Confirm:$False
  
• Запускаем установку vGuestExplorer.
• Убедитесь, что VMware Tools установлено в той ВМ, в которую вы будете копировать файлы.

Скачать vGuestExplorer можно по этой ссылке.

Многие пользователи VMware vSphere применяют репликацию уровня хоста (host-based) для защиты виртуальных машин и их хранилищ. Сама эта технология появилась еще в версии VMware vSphere 5.1 и активно используется в vSphere 5.5. Напомним также, что функции vSphere Replication используются в решении VMware Site Recovery Manager для построения катастрофоустойчивой инфраструктуры небольших компаний.

На днях компания VMware выпустила виртуальный модуль (Virtual Appliance) под названием vSphere Replication Capacity Planning Appliance, который призван помочь при планировании пропускной способности канала сети под репликацию.

Эта бесплатная утилита, доступная на сайте проекта VMware Labs, позволяет смоделировать воздействие vSphere Replication на продуктивную сеть без реальной генерации трафика.

Возможности vSphere Replication Capacity Planning Appliance:

• Интерфейс командной строки для настройки репликации в режиме "preview mode", без реального потребления хранилища.
• Веб-страница, представляющая графики по потреблению канала для каждой репликации.
• Не требует ресурсов сети и хранилищ.

Как начать пользоваться:

1. Установить виртуальный модуль.
2. Как только он загрузится, залогиниться по SSH или в консоль с логином/паролем - root/vmware.
3. Выполнить команду:
cd /opt/vmware/hbrtraffic/
4. Выполнить команду для симуляции репликации конкретной ВМ (VM_name):
   ./bin/configureReplication --vc --vcuser Administrator --vcpass --lwd <IP_of_the_Appliance> --vmname <VM_name>

После того, как операция будет выполнена (10-15 минут) получившиеся графики можно посмотреть по адресу:

https://IP_of_the_Appliance:5480/vr-graphs/

Скачать vSphere Replication Capacity Planning Appliance можно по этой ссылке.

Как мы уже писали, не так давно компания StarWind выпустила бету обновленной версии решения StarWind iSCSI SAN V8, предназначенную для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин, которая имеет множество новых возможностей. Помимо всего прочего, обновилась консоль управления StarWind Management Console, которая стала выглядеть приятнее и современнее:

Некоторые заметки по установке беты StarWind V8:

1. Предыдущие версии решения StarWind могут быть обновлены на бета-версию просто установкой продукта поверх существующей инсталляции.

2. Обратите внимание, что устройства типов Mirror, IBV и Deduplication, созданные в 6-й версии решения, имеют ограниченную поддержку в V8. Данные с них нужно перенести на новый ImageFile или устройство LSFS.

3. Для добавления функции синхронной репликации для устройств нужно использовать replication manager. Устройство типа LSFS нужно использовать, когда требуется thin-provisioning (растущее по мере наполнения данными хранилище) и функции снапшотов.

4. Для обновления существующих HA-устройств нужно выполнить следующую последовательность действий:

• Отсоединить всех клиентов (хост-серверы), если это возможно (простой при обновлении все равно будет).
• Обновить ПО StarWind на первом узле. Дождаться пока запустится сервис StarWind. В это время клиентские сессии (если они есть) будут идти через второй узел.
• Обновить ПО StarWind на втором узле, предварительно отключив клиентов. В этот момент хранилище будет для них недоступно.
• Запустить синхронизацию с первого узла. Второй узел сменит статус на "ready" и начнет принимать соединения хост-серверов. Теперь можно безопасно включить HA-устройство в продакшен.
• Дождаться окончания синхронизации, после чего первый узел также сможет обеспечивать соединения хостов.

Как начать пробовать бету StarWind V8 прямо сейчас:

• Загрузить StarWind 8.0 beta по этой ссылке - http://starwindsoftware.com/tmplink/StarWindBeta.exe
• Добавить лицензионный ключ - http://starwindsoftware.com/tmplink/sw6_06092013_beta8_beta8.swk
• Загрузить SMI-S Provider (совместим только с Windows 2012 R2 + SCVMM 2012) - http://starwindsoftware.com/tmplink/StarWind_SMIS_1_00_3_beta.exe
• Почитать configuration guide к SMI-S - http://www.starwindsoftware.com/images/content/technical_papers/StarWind-SMI-S.pdf

Некоторое время назад мы писали про технологию Virtual SAN (VSAN) компании VMware, которая позволяет объединить локальные дисковые ресурсы хост-серверов VMware ESXi в единый пул хранения для виртуальных машин, управляемый на базе политик. Этот продукт сейчас находится в стадии публичного бета-тестирования, и основан он на разработках купленной компании Virsto.

Однако многие из вас знают, что у VMware есть также продукт vSphere Storage Appliance (VSA), о котором мы также немало рассказывали на страницах VM Guru (например, тут, тут и тут). И этот продукт также предназначен для построения распределенных хранилищ на базе локальных дисков хостов, но уже для небольшой инфраструктуры.

Давайте посмотрим, чем же отличаются эти два продукта - VMware VSA и VMware VSAN:

Из таблички видно, что продукт vSphere Storage Appliance подходит для небольших компаний и начинающих в сфере виртуализации, а вот технология VSAN подойдет уже серьезным организациям с большой продакшен-инфраструктурой.

На самом деле, так как продукты делали разные компании (VSA - VMware, а VSAN - Virsto), то они имеют разные функции и не являются вариациями одного и того же решения, хотя многие понимают VSAN как развитие идеи VSA.

Мы уже немало писали о новой версии продукта StarWind iSCSI SAN 8 (тут и тут), предназначенного для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V. Не так давно проходило закрытое бета-тестирование StarWind v8, а сейчас уже публичная бета-версия этого продукта доступна для загрузки.

Новые возможности этой бета-версии:

• L2 Flash Cache - кэш уровня L2, который работает непосредственно с кэшем уровня L1 в RAM, что существенно улучшает производительность.
• Файловая система LSFS изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины (это дело недалекого будущего)
• Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что существенно увеличивает производительность.
• Inline-дедупликация StarWind, которая не создает нагрузку на подсистему хранения и не "крадет" IOPS'ы у продуктивного хранилища.
• Simplified and improved GUI - улучшенный интерфейс мастеров развертывания хранилищ для Windows Server 2012 с поддержкой скриптов PowerShell.
• Возможность интеграции с механизмом SMI-S для Windows Server 2012 R2.

В состав возможностей следующей беты StarWind v8 будут также включены следующие возможности:

• Возможность масштабирования узлов кластера хранилищ до любого числа (а не только 3 как сейчас).
• Поддержка механизма виртуальных ленточных библиотек (Virtual tape library, VTL).
• Возможность асинхронной репликации между узлами.

Скачать StarWind v8 Beta можно по этой ссылке.

Многим из вас знакомы продукты StarWind iSCSI SAN и StarWind Native SAN for Hyper-V, предназначенные для создания отказоустойчивых хранилищ виртуальных машин для платформ VMware и Hyper-V в частных облаках предприятий. Хранилища, построенные на базе технологии StarWind iSCSI, не требуют дополнительных инвестиций в инфраструктуру сети хранения, работают на базе проверенного протокола iSCSI и имеют функции отказоустойчивости на базе двух или трехузловых кластеров.

Скоро выходит новая версия StarWind, в которой будут, как минимум, следующие новые возможности:

• Файловая система LSFS изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины (это дело недалекого будущего)
• Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что существенно увеличивает производительность.
• Inline-дедупликация StarWind, которая не создает нагрузку на подсистему хранения и не "крадет" IOPS'ы у продуктивного хранилища.

А сегодня мы приглашаем вас в программу закрытого бета-тестирования StarWind iSCSI SAN & NAS:

Участие в бета-тестировании - это лучший способ первым узнать о продукте и получить несколько плюшек за хорошие репорты.

Не так давно мы уже писали о планируемых новых возможностях VMware vSphere 5.5, однако большинство новых функций были описаны в общих чертах, кроме того, до последнего момента так и не было окончательно известно, что же еще нового появится в vSphere 5.5. На проходящей сейчас конференции VMworld 2013 компания VMware наконец-то объявила о выходе обновленной платформы VMware vSphere 5.5, которая стала еще более мощным средством для построения виртуальных инфраструктур.

Компания StarWind Software, поставщик программного обеспечения для виртуализации хранения данных, и группа компаний МУК, лидер рынка проектной дистрибуции, объявили о подписании дистрибьюторского соглашения на территории Украины, Грузии, Молдовы и Беларуси.

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

Компания StarWind Software является разработчиком программного обеспечения для систем хранения данных, сертифицированного для использования в таких виртуальных средах, как VMware vSphere, Microsoft Hyper-V и Citrix XenServer. Продукты StarWind являются высокопроизводительными и экономически эффективными решениями для управления СХД, которым доверяют более 30 тыс. пользователей по всему миру.

Также в рамках соглашения с 15 августа по 15 сентября 2013 года для компаний-партнеров МУК будет доступно эксклюзивное предложение по приобретению совместных разработок компаний Microsoft и StarWind Software. Они представляют собой два экономически выгодных решения для компаний малого/среднего бизнеса и организаций корпоративного сектора, которые позволят упростить виртуализацию инфраструктуры заказчика, обеспечить надежную защиту данных и гибкость в администрировании, а также снизить общие затраты.

Более подробно о соглашении можно прочитать в пресс-релизе компании StarWind.

Компания StarWind Software, поставщик программного обеспечения для виртуализации хранения данных, и компания «Майкрософт Украина» объявили об эксклюзивном предложении – совместном решении для виртуализации бизнеса, которое позволит упростить процесс виртуализации, обеспечит надежную защиту данных, легкость в управлении ИТ-инфраструктурой и снизит общие затраты на ИТ.

Экономически выгодное решение от компаний «Майкрософт Украина» и StarWind дает возможность приобрести две лицензии Windows Server 2012 с 15% скидкой и одну лицензию StarWind Native SAN for Hyper-V с 50% скидкой.

StarWind Native SAN for Hyper-V – это программное обеспечение для создания системы хранения данных (СХД), работающее на базе iSCSI-протокола, разработанное специально для среды гипервизора Hyper-V. Одна лицензия StarWind Native SAN for Hyper-V устанавливается на два Hyper-V сервера, создавая отказоустойчивый кластер, и не нуждается во внешних хранилищах данных и дополнительном оборудовании. СХД от StarWind полностью поддерживает технологии Динамической миграции и Высокой доступности от «Microsoft», а также предоставляет широкий набор функций для обеспечения продолжительности бизнес-процессов и эффективного аварийного восстановления данных.

Интересно видео о решениях StarWind для Microsoft Hyper-V можно посмотреть по этой ссылке.

Информация с сайта компании Microsoft Ukraine  о совместном решении со StarWind: http://www.microsoft.com/ukraine/licensing/where/special/starwind.mspx

В зависимости от размеров бизнеса и потребностей клиентов, компании «Майкрософт Украина» и StarWind предлагают два варианта «доступной виртуализации». Для клиентов малого и среднего бизнеса – лицензия Windows Server 2012 Standard, позволяющая запускать 2 виртуальные машины в гипервизоре, и лицензия StarWind Native SAN for Hyper-V с объемом хранилища на 4ТВ. Для организаций корпоративного сектора - лицензия Windows Server 2012 Datacenter для запуска неограниченного количества виртуальных машин и лицензия StarWind Native SAN for Hyper-V с неограниченным объемом хранилища.

Данное предложение будет доступно только через дистрибьюторскую сеть группы компаний МУК с 15 августа по 15 сентября 2013 года.

Более подробно о предложении StarWind и Microsoft можно узнать из этой брошюры. Торопитесь - акция действует с 15 августа по 15 сентября 2013 года только на территории Украины