Сейчас многие администраторы виртуальных инфраструктур VMware vSphere и Microsoft Hyper-V используют лидирующее на рынке решение StarWind Virtual SAN для создания отказо- и катастрофоустойчивых хранилищ под виртуальные машины. В прошлой статье мы рассматривали развертывание модуля StarWind SAN & NAS storage appliance а сегодня мы поговорим о его первоначальной настройке, которая может быть проведена через графическую консоль (Web Console) или текстовый интерфейс (Text Console)...

Многие администраторы виртуальных инфраструктур VMware vSphere и Microsoft Hyper-V используют лидирующее на рынке решение StarWind Virtual SAN для создания отказо- и катастрофоустойчивых хранилищ под виртуальные машины. Как правило, продукт Virtual SAN устанавливается как виртуальная машина на гипервизорах ESXi и Hyper-V, чтобы использовать серверы как вычислительные узлы и серверы хранения одновременно. Это оптимальное решение для филиалов.

Сегодня мы поговорим еще об одном варианте развертывания этой платформы - StarWind SAN & NAS storage appliance. Данный модуль, построенный на базе ОС Linux, развертывается в одном из двух вариантов:

• На "голом железе" (bare metal), то есть на сервере без операционной системы. Это позволяет вам превратить сервер в полноценный узел кластера хранилищ (storage provider).
• На виртуальной машине - в этом случае сервисы хранилищ реализует ВМ на базе ОС Linux.

В обоих случаях StarWind SAN & NAS будет предоставлять гипервизорам сервисы хранения для виртуальных машин по протоколам iSCSI, SMB и NFS.

После развертывания у администратора появятся следующие интерфейсы управления инфраструктурой хранилищ StarWind:

• Веб-консоль StarWind
• Локальная текстовая консоль сервера
• Плагин к vCenter
• Удаленный интерфейс командной строки CLI для операций в кластере

Итак, для начала вам нужно убедиться, что сервер соответствует системным требованиям для решения StarWind SAN & NAS storage appliance. Если все в порядке, то загрузите ISO-образ продукта по этой ссылке: https://www.starwindsoftware.com/san-and-nas#download.

Установочный диск вы можете подготовить с помощью ПО Etcher или Rufus для Windows, либо командой dd на Linux или macOS. Для сетевой загрузки смонтируйте ISO-образ к серверу с помощью iDRAC, iLo или IPMI.

Далее зайдите в BIOS и включите Legacy boot mode, после чего выберите CD\DVD или удаленный интерфейс загрузки в качестве загрузочного устройства.

Если все прошло успешно, сервер начнет показывать стадии загрузки установщика StarWind SAN & NAS:

Далее появится лицензионное соглашение, которое надо принять:

Затем выбираем единственную опцию "Install StarWind SAN & NAS":

Указываем один из доступных дисков:

Все проверяем и подтверждаем выбор:

После этого начнется установка StarWind SAN & NAS:

По завершении установки нужно перезагрузить сервер:

После этого вы можете управлять сервером StarWind через веб-интерфейс:

В открывшемся First Run Wizard вы сможете настроить все необходимые параметры сервера хранилищ. О настройке StarWind SAN & NAS через веб или текстовый интерфейс, а также через CLI, мы поговорим в следующей статье.

Скачать бесплатную пробную версию StarWind SAN & NAS storage appliance можно по этой ссылке.

Много лет назад мы писали о технологиях работы кэша write-through и write-back в ведущем на рынке виртуализации хранилищ решении StarWind Virtual SAN. С тех пор механика работы этих технологий была улучшена, но принципы остались теми же, как и большинство фундаментальных технологий. Сегодня мы поговорим о работе кэшей уровней L1 и L2, которые существенно улучшают быстродействие операций ввода-вывода.

При работе StarWind Virtual SAN с хранилищами используется кэш первого уровня (L1), располагающийся в оперативной памяти, а также кэш второго уровня (L2), размещенный на SSD-дисках, обеспечивающих высокое быстродействие системы.

StarWind использует традиционную оперативную память серверов (RAM) как буфер на чтение (write buffer) и L1-кэш, чтобы кэшировать операции записи, флэш-память SSD уже обслуживает кэш уровня L2. Оба кэша используют одни и те же алгоритмы - shared library, поэтому информация ниже применима, в основном, к кэшам обоих уровней. Об их отличиях мы также поговорим в статье отдельно.

При переполнении кэша нужно освободить его, используя какой-то алгоритм. StarWind применяет для этого алгоритм LRU - least recently used, то есть вытесняются данные (блоки), которые используются реже всего в последнее время.

В зависимости от степени исчерпания состояния кэша, его блоки могут находиться в одном из трех состояний: dirty, clean и empty. В самом начале блок помечается как empty - в нем нет данных, то есть блоки кэша не ассоциированы с блоками на диске. При работе кэша эти данные начинают заполняться. Блок помечается как dirty - если полезные данные были записаны в него, но еще не были записаны на диск (он не подтвердил запись данных). Блок помечается как clean, если данные из кэша были записаны на диск, либо блок кэша был записан в результате чтения в кэш блока с диска - то есть блок кэша и блок на диске содержат одинаковые данные.

Помните, что стандартный размер блока для кэша - 64 КБ.

Следующее полезное понятие - это прогрев кэша (cache warm-up). Эта концепция имплементируется на нижнем уровне в рамках сценария "in-memory" файловой системы LSFS (log-structured file system). Данные в кэш в этом случае попадают с диска, с учетом самых последних данных, записанных на диск.

Политики кэширования

Политика кэширования определяется вместе с другими параметрами кэша / устройств, когда они создаются. В StarWind Version 8 Release 5 режим работы кэша может быть изменен на лету для уже существующих устройств.

Write-back caching

Это режим, когда запись данных производится в кэш, но операция ввода-вывода (I/O) подтверждается, как запись на диск. Запись в основную память производится позже (при вытеснении или по истечению времени), группируя в одной операции несколько операций записи в соседние ячейки. Этот тип кэширования существенно ускоряет скорость записи данных на диск, однако имеет несколько меньшую надежность с точки зрения записи данных.

Если блок находится в статусе empty или clean, то запись в кэш происходит практически мгновенно, на уровне скорости записи данных в RAM или на SSD. А вот как работает кэш в разных обстоятельствах:

• Если операции записи не были сделаны в dirty-кэш на протяжении некоторого времени (по умолчанию 5 секунд), то данные записываются на диск. Блок переходит в состоянии clean, но данные в нем остаются.
• Если все доступные блоки кэша находятся в состоянии dirty, то данные, хранимые в самых старых блоках, форсированно скидываются на диск, а новые данные записываются в эти блоки. В этом случае производительность кэша несколько падает из-за требующихся операций записи на диск, и она сравнима со скоростью такой операции с диском.
• Если происходит сбой в работе сервера или памяти (или его выключают на обслуживание), то данные в кэше write-back, помеченные как dirty, немедленно сбрасываются на диск. Если размер кэша большой (гигабайты), то эта операция может занять значительное время. Его можно оценить так: Flushing time = cache size / RAM write.

Политика кэширования write-back ускоряет производительность в следующих случаях:

• Флуктуации нагрузки - кэш позволяет сгладить пики нагрузки за счет аккумуляции большого числа записей в кэше во время всплесков до момента снижения нагрузки.
• Постоянная перезапись тех же самых блоков - в этом случае они постоянно перезаписываются только в кэше, а на диск сбрасываются пачки блоков по мере необходимости.

Помните, что политика write-back предпочтительна для L1-кэша и в данный момент недоступна для L2-кэша, который всегда создается в режиме write-through.

Write-through caching

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

При использовании этого типа кэширования не будет потери данных в случае неисправности сервера и памяти. Блоки памяти кэша в этом случае всегда помечены как clean.

Рекомендации по использованию кэша

L1 Cache

Он решает следующие проблемы:

• Запросы партнерского узла StarWind Virtual SAN могут приходить с небольшой задержкой и изменять порядок доступа к блокам, например, 1-2-3-4-5-6-7-8 изменится на 1-3-2-4-5-7-6-8. В этом случае L1- кэш сгладит поток последовательных запросов на запись с применением алгоритма round robin в дополнение к кэшированию. L1-кэш объединяет маленькие запросы записи в большие (write coalescing). Например, 16 запросов по 4k в кэш будут записаны на диск как единый блок 64к, что работает гораздо быстрее. Поэтому для такого кэша не нужно много памяти - от 128 МБ.
• L1 также компенсирует перезапись в те же секторы диска. Самая частая перезапись - это небольшие по размеру операции. Размер кэша должен зависеть от от частоты перезаписи данных и размера working data set. Чем чаще перезапись, теперь меньше вы можете делать кэш, но если больше размер working data set, то должен быть и больше кэш. В этом случае работает формула Tcached = Tdisk * (1 – (cache size) / (working set size)). В этом случае, если у вас кэш составляет 0.1 от data working set, процессинг данных будет составлять 0.9 от времени процессинга данных на диск. Если же cache size = working data set, то средний процессинг команд будет примерно равен времени процессинга команд в памяти.

StarWind L1 cache в режимах write-back и write-through может быть использован для:  

• Файловых устройств StarWind HA image file на базе HDD-хранилищ в конфигурации RAID 10.  
• Устройств StarWind LSFS на базе HDD в конфигурациях RAID 5, 6, 50, 60. Также посмотриите статью о требованиях устройств LSFS.

Также помните, что в большинстве случаев для дисковых массивов all-flash кэш уровня L1 вам не потребуется.

В идеале размер кэша L1 должен быть равен размеру working data set. Также размер кэша L1 влияет на время, которое вам потребуется, чтобы выключить сервер (нужно сбросить грязные блоки на диск). Также помните, что лучше не делать L1 кэш в режиме WB, чтобы не создавать ситуацию, когда большой объем данных может быть утерян.

При использовании кэша L1 в режиме write-back обязательно используйте UPS для серверов, чтобы не потерять часть данных. Время работы UPS должно позволяет сбросить содержимое грязного кэша на диск.

L2 Cache (Flash Cache)

Для обслуживания кэша L2 создается обычное устройство ImageFile device. У этого устройства нет таргета, и оно соединено с системой точно так же, как и устройство с данными (ImageFile or LSFS).

Система с кэшем L2 должна иметь больше оперативной памяти RAM для обеспечения накладных расходов. Формула тут такая: 6.5 ГБ RAM на 1 ТБ кэша L2, чтобы хранить метаданные. Более подробно о кэше L2 можно почитать в базе знаний StarWind.

StarWind L2 cache может быть использован для следующих сценариев:

• HA-устройства StarWind image file на базе HDD в конфигурации RAID 10.
• Устройства StarWind LSFS на базе HDD в конфигурации RAID 5, 6, 50, 60.
• HA-устройства StarWind image file на all-flash хранилищах в некоторых сценариях. Более подробно об этих сценариях можно почитать в базе знаний StarWind.

В большинстве случаев, когда у вас есть L1 кэш, кэш уровня L2 вам не потребуется. Размер L2 кэша должен быть равен среднему объему уникальных данных, запрашиваемых с хранилища на регулярной основе (определяется экспериментально).

Продолжаем рассказывать о главном продукте для создания отказоустойчивых хранилищ StarWind Virtual SAN, который позволяет обеспечивать бесперебойное функционирование кластеров виртуальных машин на базе серверов виртуализации VMware ESXi или Microsoft Hyper-V. Сегодня мы рассмотрим механизм назначения прав доступа инициаторов в консоли StarWind Management Console, с помощью которой администраторы управляют всеми аспектами виртуальных хранилищ.

Многим из вас знакома компания StarWind Software, выпускающая одни из лучших в отрасли продукты для организации отказоустройчивых хранилищ под платформы виртуализации. Компания производит как программные продукты (StarWind Virtual SAN для vSphere и Hyper-V), так и программно-аппаратные комплексы, представленные линейкой StarWind HyperConverged Appliance (HCA) и StarWind Storage Appliance. Сегодня мы поговорим именно о программно-аппаратных решениях StarWind Appliances...

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

Стек работы с хранилищами VMware ESXi настроен таким образом, чтобы адекватно реагировать на кратковременную потерю сигнала в канале iSCSI, которая может возникнуть по разным причинам (кто-то перекоммутировал соединение, дрогнул порт и т.п.). По умолчанию расширенные настройки iSCSI выставлены так, чтобы переживать кратковременные сбои в рамках одного пути в интервале 25-35 секунд. В это время I/O-запросы будут копиться в очереди, а потом, либо произойдет продолжение передачи при восстановлении текущего соединения, либо хост переключится на резервный путь (failover) текущего или резервного адаптера.

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

Для этого, если вы используете хранилища StarWind Virtual SAN, есть специальные настройки реагирования на подобные ситуации.

Итак, для начала вам нужно остановить службы StarWind Virtual SAN:

• В консоли StarWind Management Console проверить, что все устройства StarWind HA находятся в статусе "Synchronized" на всех серверах
• Проверить, что все датасторы имеют активные задублированные пути для всех серверов StarWind, а политика доступа по нескольким путям (MPIO) установлена в Round Robin
• На StarWind VSAN для Windows нужно выполнить команду для остановки служб StarWind: net stop starwindservice
• На виртуальном модуле StarWind VSA нужно выполнить такую команду: systemctl stop StarWindVSA

Далее открываем конфигурационный файл:

• На StarWind VSAN для Windows: C:\Program Files\StarWind Software\StarWind\StarWind.cfg
• На виртуальном модуле StarWind VSA: nano /opt/StarWind/StarWindVSA/drive_c/StarWind/StarWind.cfg

Далее там находим параметр iScsiPingCmdSendCmdTimeoutInSec и выставляем его значение, например в "1" (одна секунда).

Ну и, наконец, надо запустить службы StarWind VSAN:

• На StarWind VSAN для Windows: net start starwindservice
• На виртуальном модуле StarWind VSA: systemctl start StarWindVSA

Теперь нужно добраться до расширенных настроек iSCSI инициатора VMware ESXi. Открываем Advanced Options для адаптера в разделе Storage Adapters нужного нам инициатора:

И смотрим, какие настройки там выставлены:

Нас интересует:

• RecoveryTimeout - это как раз время, через которое активный путь помечается как "мертвый" (переводится в DEAD_STATE), когда по нему больше не приходит команд ввода-вывода.
• NoopInterval - это интервал, с которым происходит пассивное тестирование неактивных путей на предмет того, живы ли они.
• NoopTimeout - это время, через которое происходит пометка неактивного пути как DEAD, если по нему не получено ответа.

Эти настройки по умолчанию установлены в оптимальные с точки зрения вероятности отказа/потерь значения. Меняйте их только, если у вас есть особые требования приложений по непрерывной доступности хранилищ, и вы знаете, какое поведение системы хотите получить. Уменьшение таймаутов, очевидно, ведет к загрузке сети пингами каналов iSCSI и дополнительной нагрузке на устройства.

Дункан написал хорошую разъясняющую статью про загрузку ESXi с SD-карты и размещение раздела OSDATA на хранилище в SAN. Напомним, что мы писали о том, что VMware уходит от механизма загрузки ESXi с SD-карт ввиду их низкой надежности и неприспособленности под задачи гипервизора.

Как знают администраторы VMware vSphere, начиная с седьмой версии платформы, структура разделов ESXi теперь выглядит следующим образом:

Как мы видим, все основные разделы, не относящиеся к загрузке переехали в раздел ESX-OSDATA. Многие администраторы хотели бы хранить загрузочный раздел локально на SD-карте, а OSDATA - в сети SAN.

К сожалению, это не поддерживается.

Давайте взглянем на таблицу допустимых конфигураций из вот этой статьи VMware:

Действительно, тут как бы есть пункт, что при загрузке ESXi можно использовать SD-карту для Bootbank, а Managed FCoE/iSCSI LUN для OSDATA (но обратите внимание, что это Locally attached devices). Реально же FCoE, iSCSI и FC для загрузки ESXi с SAN можно использовать только тогда, когда и OSDATA, и Bootbank находятся на SAN-устройстве.

Компания StarWind Software, известная многим из вас как ведущий производитель программно-аппаратных хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, запустила новый продукт StarWind SAN & NAS, который предназначен для создания хранилищ на основе севреров с установленным там гипервизором. В качестве платформы StarWind SAN & NAS использует Linux...

На днях компания StarWind, ведущий производитель средств для создания программно-аппаратных хранилищ под виртуализацию, выпустила новую версию своего флагманского продукта - StarWind Virtual SAN v8 for Hyper-V (build 14120). Надо отметить, что в конце марта этого года StarWind уже выпускала обновление Virtual SAN (build 14033), поэтому ниже мы расскажем о новых возможностях обеих версий.

Итак, что нового появилось в StarWind Virtual SAN v8 for Hyper-V в этом году:

1. Компоненты VTL и Cloud Replication

• Поддержка Microsoft Azure - добавлена опция по загрузке файлов в Archive tier напрямую, без необходимости сначала добавлять их в Hot/Cool tier и дальнейшего перемещения в архив.
• Возможность Write Protect для виртуальных кассет.
• Минимальный размер кассеты установлен в 50 МБ.
• Режим VTL file operation mode изменен на принудительное закрытие неиспользуемых файлов. Если в работе слишком много частей виртуальных кассет, то много открытых файлов могло привести к исчерпанию ресурсов. Изменить это поведение теперь можно в параметре closedatafiles в конфиге StarWind.cfg.
• Исправлена ошибка при восстановлении кассет, разделенных на части, из облака (некоторые части могли не загружаться).
• Пофикшена ошибка в cloud replication, которая могла возникать, если установлена опция "Create new empty tapes automatically when existing tape removed from VTL for replication". Если она была включена, это могло привести к падению сервиса при создании новой виртуальной кассеты.

2. Улучшения синхронной репликации

• Исправлена ошибка с отклонением синхронизации HA-узла при перезапуске сервиса на одном из узлов (иногда процедура не стартовала автоматически).
• Исправлена ошибка, приводившая к падению сервиса в случае, если соединение с хранилищем или сетевое соединение испытывало падение производительности.
• Исправлена реализация алгоритма Node Majority failover strategy. Ранее она работала некорректно в случае, если соединение между узлами было нарушено, но только в одну сторону.
• Пофикшена процедура автоматического восстановления для трехсторонней репликации. Ранее она использовала информацию от двух из трех узлов, что некорректно для процедура auto-restore. Теперь учитывается статус от всех трех узлов.
• Поправлено некорректное поведение при операции расширения размера хранилища на узле. Это приводило к разрыву соединения для некоторых случаев, когда операции по работе с хранилищем занимали продолжительное время.
• Исправлена ошибка, которая вела к полной синхронизации вместо быстрой в некоторых случаях.
• Исправлена ошибка с обработкой IO-запросов на одном из хранилищ, приводившая к тому, что в случае зависания запроса на конфигурации с three-way репликацией происходила некорректная работа на всех трех узлах.

3. Основные улучшения

• Улучшения производительности для версии VSA (Virtual Storage Appliance).
• Исправлена проблема с закрытием сессии в случаях, когда обнаруживался критический недостаток ресурсов.
• Исправлена проблема с обработкой операции control connection close - в некоторых случаях это приводило к генерации большого числа нотификаций, а Management Console переставала отвечать.
• Исправлена процедура session close при остановке службы - теперь она не зависает в некоторых редких случаях.
• Исправлена проблема с зависанием Management Console при накатывании бесплатной лицензии на сервер без интернет-соединения.
• Было обновлено лицензионное соглашение.

4. StarWindX PowerShell Module

• Физические устройства теперь есть в общем списке устройств. Их можно использовать для экспорта с физических ленточных устройств.
• Добавлено свойство MaintenanceMode для объекта HA Device.

Загрузить пробную версию StarWind Virtual SAN v8 for Hyper-V можно по этой ссылке. Документация доступна здесь, а Release Notes - вот тут.

Отметим также, что обновился и продукт в формате виртуального модуля для платформы VMware - StarWind VSAN for vSphere (OVF Version 20210520, Version 8 build 14120). Release notes доступны тут (список улучшений там практически такой же, за исключением некоторых моментов в мартовской версии).

Компания StarWind, ведущий производитель программно-аппаратных решений для отказоустойчивых хранилищ под виртуальные машины, представила новое предложение - HCI Evaluation Kit для программно-аппаратных комплексов StarWind HyperConverged Appliance (HCA). С помощью набора для быстрого старта HCI Evaluation Kit вы сможете получить решение на базе вложенных (nested) виртуальных машин, в рамках которого будет работать sandbox-кластер...

Продолжаем рассказывать о лучшем в отрасли решении для создания программных хранилищ под виртуальные машины на базе хост-серверов ESXi - StarWind Virtual SAN for vSphere. Как многие знают, с какого-то момента StarWind стала поставлять свое решение для платформ VMware в виде виртуального модуля (Virtual Appliance) на базе Linux, который реализует основные сервисы хранения, дедупликации и компрессии, а также отказоустойчивости и обеспечения надежности данных в виртуальных машинах.

Для виртуального модуля StarWind работа механизма дедупликации и компрессии обеспечивается средствами Linux-движка Virtual Data Optimizer (VDO), который появился относительно недавно. Это удобный и надежный способ экономии дискового пространства за счет использования дополнительных емкостей оперативной памяти на хосте.

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

Что касается HDD и SSD-дисков, то нужно также спланировать конфигурацию RAID на хранилище хостов. Сделать это можно в соответствии с рекомендациями, описанными в базе знаний StarWind. Вы можете использовать программный или аппаратный RAID, о настройках которого мы расскажем ниже.

Что касается дополнительной оперативной памяти на хосте ESXi, то нужно выбирать ее объем, исходя из следующих критериев:

• 370 МБ плюс дополнительные 268 МБ на каждый 1 ТБ физического хранилища
• Дополнительно 250 МБ на 1 ТБ физического хранилища, если включена дедупликация (UDS index)

То есть для 4 ТБ физического хранилища с дедупликацией вам понадобится:

370 MB + 4 * 268 MB +4 * 250 MB = 2 442 MB RAM

Итого 2,4 ГБ оперативной памяти дополнительно к памяти под ОС виртуального модуля. Вообще, StarWind рекомендует 8 ГБ памяти для виртуального модуля - 4 ГБ на машину и 4 ГБ на движок VDO для работы с хранилищем.

Один VDO-том может работать с хранилищем до 256 ТБ, что покрывает максимум потребностей в рамках хранилищ на базе серверов. Также StarWind очень рекомендует использовать дисковые массивы All-flash или NVMe-оборудование.

Общее правило развертывания таких хранилищ таково:

• Под VDO: аппаратный или программный RAID (LVM или mdraid)
• Над VDO: "толстые" (thick) диски StarWind Virtual SAN в режиме stand-alone или HA

Надо понимать, что сам том VDO - это тонкий диск, растущий по мере наполнения, поэтому устройство под ним должно иметь расширяемую природу (MD RAID, LVM).

Примерная схема отказоустойчивого решения StarWind Virtual SAN for vSphere на базе 2 узлов выглядит так:

После того, как вы установите StarWind Virtual SAN, настроите виртуальную машину и StarWind Management Console, нужно будет настроить аппаратный или программный RAID для хранилища.

Если вы используете аппаратный RAID, то просто создайте виртуальный диск для ВМ StarWind Virtual SAN на его хранилище, но обязательно типа "Thick Provisioned Eager Zeroed" (также вы можете использовать RDM-диск):

Если же вы будете использовать программный RAID, то нужно будет использовать HBA или RAID-контроллер в режиме DirectPath I/O passthrough, чтобы получить прямой доступ к дискам и собрать на их базе RAID-массив.

Для этого вам нужно будте выбрать правильный HBA/RAID-контроллер как PCI-устройство:

И пробросить его напрямую в виртуальную машину StarWind:

После этого в StarWind Management Console можно будет собрать RAID нужного вам уровня:

Рекомендации тут такие:

После этого в виртуальном модуле StarWind на полученном хранилище нужно будет создать VDO-устройство с нужными вам параметрами:

vdo create –activate=enabled –deduplication=enabled –compression=disabled –emulate512=enabled –indexMem=%size% –vdoLogicalSize=%size% –device=%yourdevice% -n=%name%

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

После создания это устройство надо отформатировать в XFS со следующими параметрами:

Далее вы можете создавать хранилище StarWind на этом устройстве и (опционально) сделать его реплику на партнерском узле в режиме HA. Также рекомендуется выставить настройку Disk.DiskMaxIOSize на хосте ESXi

В значение 512:

Ну и про оптимизацию производительности I/O-планировщика прочитайте вот эту статью базы знаний StarWind. Если вам интересен процесс создания хранилищ с дедупликацией и компрессией на базе StarWind Virtual SAN в стиле "от и до", то рекомендуем прочитать вот эту статью.

Многие из вас знают про лучшее на рынке программно-аппаратное решение для организации хранилищ под виртуализацию StarWind Virtual SAN. О прошлом его обновлении, которое вышло весной этого года, мы писали вот тут.

Недавно компания StarWind выпустила обновление этого продукта в виде виртуального модуля OVF на базе Linux для VMware vSphere - VSAN OVF Version 20201027 Version 8 (build 13861).

Давайте посмотрим, что там появилось нового:

Общие улучшения и багофиксы

• Обновлено ядро модуля Linux Kernel.
• Настройка iScsiPingCmdSendCmdTimeoutInSec теперь по умолчанию выставлена в 5 секунд.
• Исправленный процесс логирования для оповещений по email, теперь они не смешиваются с общими событиями почтового сервера.
• Улучшены операции по остановке службы (ранее этот процесс мог подвиснуть в определенных обстоятельствах).
• Обновлена имплементация SCSI-протокола для более корректного процессинга команд UNMAP/TRIM.

Улучшения синхронной репликации

• Добавлена опция использования SMB-шары как ресурса witness для устройств с синхронной репликацией.
• Исправлена обработка персистентных резерваций для устройств с синхронной репликацией.
• Исправлены некоторые случаи обновления состояния партнерского узла после восстановления из ситуации split-brain.

Управляющая консоль (Management Console)

• Исправлено падение консоли, когда StarWind Event log содержал записи с некорректными строковыми значениями.
• Обновлен диалог настроек нотификаций по email (добавлена валидация и спрятаны поля логина-пароля при отсутствии необходимости аутентификации).

Модуль StarWindX PowerShell

• Добавлена возможность добавления HA-устройств в конфигурации Node Majority. Теперь узел StarWind или SMB-шара могут быть использованы как witness. Более подробно об этом можно узнать из примеров сценариев CreateHAPartnerWitness.ps1 и CreateHASmbWitness.ps1.

• Поправлена обработка параметра ALUA для командлетов по созданию HA-устройства.

Скачать пробную версию StarWind Virtual SAN для VMware vSphere в формате виртуального модуля OVF можно по этой прямой ссылке.

Производительность дисковой подсистемы в Linux зависит от различных параметров и настроек, одной из которых является тип планировщика для работы с потоком ввода-вывода (I/O scheduler). Если вы планируете использовать продукт StarWind VSAN for vSphere для создания программных хранилищ на базе виртуальных машин Linux (Virtual Storage Appliance), то информация ниже может быть вам полезна.

В зависимости от типа целевого хранилища, иногда целесообразно поменять используемый тип планировщика. Чтобы вывести текущий тип I/O scheduler, нужно выполнить следующую команду для выбранного устройства:

# cat /sys/block/sda/queue/scheduler
noop [deadline] cfq

В данном случае мы видим, что тип планировщика - это noop (он же none). В зависимости от версии ядра Linux, он также может быть выставлен как mq-deadline. Кстати, обратите внимание, что тип планировщика указывается на уровне отдельного дискового устройства.

Считается, что для SSD и NVMe-устройств лучше ставить планировщик none / noop, который уменьшает нагрузку на CPU, а вот для HDD-дисков лучше использовать mq-deadline, который показывает лучшие результаты по итогам синтетических тестов.

Чтобы поменять планировщик на noop для диска sdb, нужно выполнить следующую команду:

# echo noop > /sys/block/sdb/queue/scheduler

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

# cat /sys/block/sdb/queue/scheduler
[noop] deadline cfq

Но это все меняет тип планировщика на время, до перезагрузки, чтобы вы могли проверить разные планировщики и сделать тесты производительности. Чтобы сохранить эти изменения, нужно изменить файл scheduler.rules в директории /etc/udev/rules.d/

Например, если вы хотите поменять планировщик на noop для устройства sdb и установить политику "no read ahead" для него, то нужно добавить туда следующую строчку:

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sdb", ATTR{queue/scheduler}="noop", ATTR{queue/read_ahead_kb}="0"

Рекомендуется выставлять одинаковый тип планировщика на всех узлах, где расположены хранилища StarWind VSAN. Также надо отметить, что последние версии продукта StarWind VSAN for vSphere при установке автоматически выставляют тип планировщика noop для SSD-хранилищ.

За время карантина компания StarWind Software выпустила пару небольших обновлений своего флагманского продукта StarWind Virtual SAN V8, предназначенного для создания программных и программно-аппаратных хранилищ под виртуализацию.

Продукт продолжает развиваться, ведется большая работа над улучшением производительности и ошибками, давайте посмотрим, что в нем появилось интересного для платформ vSphere и Hyper-V:

• Для виртуального модуля StarWind VSAN for vSphere OVF (версия 20200515) была обновлена версия ядра Linux.
• Функция полной синхронизации с проверкой контрольных сумм (CRC), добавленная в прошлом релизе, теперь используется только для хранилищ на базе MS Storage Spaces. В этом случае тип синхронизации (Full или Full hash) показан в Management Console.
• Для старых хранилищ используется старый алгоритм с копированием данных без дополнительной проверки CRC, чтобы не влиять на производительность.
• Для запроса CRC исправлена проблема с Memory alignment. Также была исправлена проблема совместимости для виртуального модуля StarWind VSA.
• Множество исправлений ошибок, в том чиле важных с возможным повреждением данных - поэтому обязательно нужно обновиться.

• Добавлена проверка размера сектора для образа Flat Image - нельзя создать Flat Device с размером сектора 512 бай при физическом размере 4096 байт.
• Добавлен параметр валидации формата (format) для вызова Add-RamDevice. Допустимые значения: fat16, fat32, ntfs, raw.
• Добавлен параметр "force" для команды "remove".
• Добавлено свойство CreateTapeOnExport для вызова VTL ApplyReplicationSettings(). Подробнее в сэмпле скрипта VTLReplicationSettings.ps1.

• Запись нотификаций в текстовый файл не всегда теперь держит его открытым, а открывает и закрывает при необходимости.
• Улучшена безопасность при работе с SMTP и пофикшен баг с отсылкой письма без аутентификации.

• Число файлов в Log Rotate было увеличено до 20 во время обновлений существующих установок.

• Пофикшена ошибка с отображением событий из Event Log в зоне нотификаций. Иногда эти события не отображались.

Хранилища Flat Storage

• Улучшена обработка ответов для команд UNMAP/TRIM от хранилищ с файловой системой ReFS.

Прочее

• Исправления для процессинга команды EXTENDED COPY(LID4), которая возвращала ошибки в прошлых версиях.

Скачать самый свежий релиз StarWind Virtual SAN V8 for Hyper-V от 6 мая 2020 (build 13586) года можно по этой ссылке, а StarWind VSAN for vSphere OVF (версия 20200515 от 18 мая) - по этой ссылке.

Сегодня мы расскажем об отличиях коммерческой и бесплатной версий одного из лучших решений для создания отказоустойчивых программных хранилищ под виртуальные машины StarWind Virtual SAN. Последний раз мы писали о сравнении возможностей платной и бесплатной версий в далеком 2017 году, и с тех пор, конечно же, много что изменилось.

В последних числах августа компания StarWind Software, выпускающая продукты для организации хранилищ под виртуализацию, выпустила обновленную версию решения для создания iSCSI-хранилищ на платформах vSphere и Hyper-V - StarWind Virtual SAN V8 build 13182. Давайте посмотрим, что нового появилось в этом продукте...

Год назад компания StarWind Software анонсировала собственный таргет и инициатор NVMe-oF для Hyper-V, с помощью которых можно организовать высокопроизводительный доступ к хранилищам на базе дисков NVMe (подключенных через шину PCI Express) из виртуальных машин. За прошедший год StarWind достаточно сильно улучшила и оптимизировала этот продукт и представила публично результаты его тестирования.

Для проведения теста в StarWind собрали стенд из 12 программно-апаратных модулей (Hyperconverged Appliances, HCA) на базе оборудования Intel, Mellanox и SuperMicro, составляющий высокопроизводительный вычислительный кластер и кластер хранилищ, где подсистема хранения реализована с помощью продукта Virtual SAN, а доступ к дискам происходит средствами инициатора NVMe-oF от StarWind. Между хостами был настроен 100 Гбит Ethernet, а диски SSD были на базе технологии NVMe (P4800X). Более подробно о конфигурации и сценарии тестирования с технологией NVMe-oF написано тут.

Аппаратная спецификация кластера выглядела так:

• Platform: Supermicro SuperServer 2029UZ-TR4+
• CPU: 2x Intel® Xeon® Platinum 8268 Processor 2.90 GHz. Intel® Turbo Boost ON, Intel® Hyper-Threading ON
• RAM: 96GB
• Boot Storage: 2x Intel® SSD D3-S4510 Series (240GB, M.2 80mm SATA 6Gb/s, 3D2, TLC)
• Storage Capacity: 2x Intel® Optane™ SSD DC P4800X Series (375GB, 1/2 Height PCIe x4, 3D XPoint™). The latest available firmware installed.
• RAW capacity: 9TB 
• Usable capacity: 8.38TB 
• Working set capacity: 4.08TB 
• Networking: 2x Mellanox ConnectX-5 MCX516A-CCAT 100GbE Dual-Port NIC
• Switch: 2x Mellanox SN2700 32 Spectrum ports 100GbE Ethernet Switch

Схема соединений тестового стенда:

Для оптимизации потока ввода-вывода и балансировки с точки зрения CPU использовался StarWind iSCSI Accelerator, для уменьшения latency применялся StarWind Loopback Accelerator (часть решения Virtual SAN), для синхронизации данных и метаданных - StarWind iSER initiator.

Как итог, ввод-вывод оптимизировался такими технологиями, как RDMA, DMA in loopback и TCP Acceleration.

С точки зрения размещения узлов NUMA было также сделано немало оптимизаций (кликните для увеличения):

Более подробно о механике самого теста, а также программных и аппаратных компонентах и технологиях, рассказано здесь. Сначала тест проводился на чистом HCA-кластере без кэширования.

Результаты для 4К Random reads были такими - 6,709,997 IOPS при теоретически достижимом значении 13,200,000 IOPS (подробнее вот в этом видео).

Далее результаты по IOPS были следующими:

• 90% random reads и 10% writes = 5,139,741 IOPS
• 70% random reads и 30% writes = 3,434,870 IOPS

Полная табличка выглядит так:

Потом на каждом хосте Hyper-V установили еще по 2 диска Optane NVMe SSD и запустили 100% random reads, что дало еще большую пропускную способность - 108.38 GBps (это 96% от теоретической в 112.5 GBps.

Для 100% sequential 2M block writes получили 100.29 GBps.

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

А потом на этой же конфигурации включили Write-Back cache на уровне дисков Intel Optane NVMe SSD для каждой из ВМ и для 100% reads получили 26,834,060 IOPS.

Полная таблица результатов со включенным кэшированием выглядит так:

Да-да, 26.8 миллионов IOPS в кластере из 12 хостов - это уже реальность (10 лет назад выжимали что-то около 1-2 миллионов в подобных тестах). Это, кстати, 101.5% от теоретического максимального значения в 26.4М IOPS (12 хостов, в каждом из которых 4 диска по 550 тысяч IOPS).

Для тестов, когда хранилища были презентованы посредством технологии NVMe-oF (Linux SPDK NVMe-oF Target + StarWind NVMe-oF Initiator), было получено значение 22,239,158 IOPS для 100% reads (что составляет 84% от теоретически расчетной производительности 26,400,000 IOPS). Более подробно об этом тестировании рассказано в отдельной статье.

Полные результаты этого теста:

Все остальное можно посмотреть на этой странице компании StarWind, которая ведет учет результатов. Зал славы сейчас выглядит так :)

Многие из вас знают, что у компании StarWind есть продукт Virtual SAN для построения программных отказоустойчивых хранилищ, являющийся на сегодняшний день одним из лидеров отрасли. Но самое интересное, что у StarWind есть и программно-аппаратный комплекс HyperConverged Appliance (HCA), на базе которого можно строить недорогую инфраструктуру виртуализации и хранения для небольших компаний (а также для сценариев ROBO - remote or brunch offices, то есть филиалов).

Как вы знаете, мы часто пишем о лучшем продукте для создания отказоустойчивых хранилищ под виртуализацию StarWind Virtual SAN. На днях это решение было обновлено - вышел StarWind Virtual SAN Version 8 Build 12767. Надо отметить, что это первый релиз продукта в этом году. Прошлый состоялся в ноябре 2018 года.

Давайте посмотрим на новые функции и багофиксы StarWind Virtual SAN V8:

1. Основные возможности:

• Поддержка Signature Version 2 для S3-совместимых репликаторов Cloud Storage replicators.
• Запланированное удаление файлов с виртуального ленточного устройства на стороне публичного облака.
• Поддержка решения Azure Government storage для продукта StarWind VTL.
• Улучшена стабильность соединений и починены возможные маловероятные проблемы разрывов во время логина по протоколу iSCSI.

2. Исправления ошибок, пофикшены проблемы в:

• Механизме SMI-S.
• Сервисном модуле.
• Модуле репликации при получении неожиданных ответов от целевого сервера (System.Net.Http.HttpRequestException).
• Процессе построения списка репликаторов.
• Клиенте при переведения узла в режим обслуживания и изменении статуса синхронизации.
• Процессе переустановки NVMf Target.

Загрузить новый апдейт StarWind Virtual SAN V8 можно по этой ссылке. Release Notes доступны тут.

Нил Андерсон (Neil Anderson) прислал нам ссылку на интересный список "List of VSA Virtual Storage Appliances and SAN Storage Simulators", в котором представлены основные виртуальные модули (Virtual Storage Appliances, VSA) и симуляторы для создания программных общих SAN-хранилищ.

Вот список VSA-модулей и SAN-симуляторов, представленный по ссылке:

• FreeNAS VSA
• StarWind Virtual SAN VSA
• Open Media Vault VSA
• OpenFiler Unified Storage VSA
• NetApp ONTAP Simulator
• NetApp ONTAP Select VSA
• HPE 3PAR StoreServ Simulator
• HPE StoreVirtual VSA
• Dell EMC UnityVSA
• Dell EMC ViPR Software Defined Storage
• Dell EMC Isilon Simulator
• Dell EMC Data Domain Virtual Edition – Community Edition
• Oracle ZFS Storage Simulator
• IBM Spectrum Scale Virtual Machine
• HDS HCS Simulator
• Nimble Virtual Array VSA
• Nutanix Community Edition
• Synology DSM XPEnology Simulator
• NexentaStor Community Edition VSA
• Datacore Hyperconverged Virtual SAN
• StorMagic SvSAN Trial

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

• IBM StorWize V-Series Demo
• Dell EMC Unity All Flash Simulator Demo
• Dell EMC VNXe Demo
• Synology DSM NAS Demo
• QNAP QTS NAS Demo
• Thecus NAS Demo
• NetGear ReadyNAS NAS Demo

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

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

Давайте посмотрим, что нового появилось в Virtual SAN V8 (build 12585) от 25 октября:

• Добавлена поддержка ленточных устройств LTO8.
• Добавлены новые команды PowerShell для управления устройствами VTL и настройками Cloud Replication. Вы можете посмотреть примеры использования по адресу C:\Program Files\StarWind Software\StarWind\StarWindX\Samples\powershell\.

2. Демо-версия NVMf Target.

• Простой NVMf Target можно создать в демонстрационных целях. Существующий NVMf initiator можно теперь использовать для соединения с этим таргетом.
• Простые устройства RAM Disk и Flat Storage теперь поддерживаются. Например, рекомендуется использовать сетевые адаптеры Mellanox RDMA-enabled с последними драйверами от производителя.
• Также можно использовать любые другие адаптеры, которые реализуют слой NetworkDirect API.
• Учитывайте, что процесс установки StarWind VSAN перезаписывает конфигурационный файл NVMf Target (nvmf.conf). Если во время установки уже есть файл nvmf.conf, он будет сохранен как nvmf.conf.bak.
• Для новой версии запросите новый лицензионный ключ (даже если сейчас NVMf работает) - как для издания Free, так и для триальной лицензии.

• Исправлена проблема, когда процессор (CPU) узла хранения мог оказаться загружен на 100% CPU. Это происходило потому, что в некоторых случаях транспорт канала синхронизации мог загружать одно ядро CPU полностью. Если число каналов синхронизации совпадало с числом ядер CPU, сервис переставал отвечать.

• Раздел помощи был пермещен и теперь доступен по адресу: https://www.starwindsoftware.com/help/
• Другие полезные ссылки были добавлены в меню Help.

• Была пофикшена проблема, когда служба ядра Virtual SAN падала в системах с устройствами NVMe.

Скачать StarWind Virtual SAN V8 (build 12585) можно по этой ссылке.

Компания StarWind Software, известная своим лидирующим на рынке решением Virtual SAN для создания отказоустойчивых хранилищ под виртуализацию, обновила свою продуктовую линейку. Теперь она заточена под создание гиперконвергентной инфраструктуры (управление различными аспектами - хранилищами, узлами, сетью - из единой точки) на базе вычислительных узлов, которые одновременно еще и являются узлами кластера хранилищ.

Компания StarWind сегодня в 21-00 по московскому времени проводит интереснейший вебинар о своем виртуальном модуле на базе Linux для создания отказоустойчивых хранилищ под виртуализацию VMware vSphere - "Linux-based StarWind Virtual SAN – free and simple way to ensure high applications availability in vSphere environments".

Вебинар проведет Алекс Быковский, и вы сможете задавать вопросы на русском языке. Этот продукт очень давно ожидали пользователи StarWind (чтобы, например, не платить за лицензию Windows на сервер хранения), поэтому не пропустите уникальную возможность узнать подробности из первых рук.

Зарегистрироваться бесплатно!

В конце апреля этого года компания StarWind выпустила обновление лучшего на рынке решения для создания программных iSCSI-хранилищ под виртуализацию - StarWind Virtual SAN. В конце апреля было выпущено большое обновление Virtual SAN v8, а в середине мая был выпущен еще один небольшой апдейт.

Давайте посмотрим, что нового появилось в StarWind Virtual SAN v8 build 12146 и 12166:

• Для модуля Cloud Replication появилась поддержка Backblaze B2 Cloud Storage.
• Для синхронной репликации и режима обслуживания (maintenance mode) события, описанные в Event Log, стали более детализированными. Вот примеры:
  • (id 809) Underlying device response time is longer than expected.
  • (id 824) Partner "%s" request response time is longer than expected.
  • (id 825) Request execution time is longer than expected.
  • (id 821) Maintenance mode is turned ON.
  • (id 822) Maintenance mode is turned OFF.
• Несколько изменено поведение кластера - теперь при ручном отключении двух партнерских HA-устройств на сервере оставшийся узел выпадает в состояние "not synchronized". Также если выпадает HA-устройство, а затем Witness-узел, то при возвращении Wintness-узла в онлайн - работоспособность кластера автоматически восстанавливается.
• Теперь отсутствует интервал в 30 секунд между отправкой email-нотификаций, также можно поменять SMTP-порт.
• Если хранилище создается на устройстве, которое некорректно сообщает о размере физического сектора, StarWind все равно позволяет его создать, но с предупреждением.
• Для управления модулем VTL появилась функциональность StarWindX PowerShell. В составе продукта идут вот эти примеры:
  • \StarWindX\Samples\powershell\CreateVirtualTapeLibrary.ps1
  • \StarWindX\Samples\powershell\InsertVirtualTape.ps1
  • \StarWindX\Samples\powershell\RemoveVirtualTape.ps1
• Добавлен пример PowerShell-сценария для управления трехузловым HA-кластером на базе LSFS:
  • \StarWindX\Samples\powershell\CreateHA_3_LSFS.ps1
• Для LSFS была исправлена проблема на устройствах pre-V8R6 (при заполненности данными более 1,2 ТБ могла произойти потеря данных при рестарте сервиса). Были исправлены и некоторые проблемы апгрейда LSFS с релиза V8R5. Также было улучшено поведение LSFS при высоких нагрузках (изменена процедура дефрагментации).
• В Management Console была добавлена поддержка новой версии продукта StarWind VSA 2.0.
• Было сделано множество исправлений ошибок с HA-устройствами, снапшотами и хранилищами.

Очень рекомендуем текущим пользователям StarWind Virtual SAN v8 накатить это обновление (вот инструкция, как это сделать). Ну а тем, кто еще не развертывал StarWind в своей инфраструктуре - рекомендуем попробовать этот продукт бесплатно. Более подробно о решениях StarWind Software можно почитать в Resource Library.

Мы часто пишем о продукте StarWind Virtual SAN, который позволяет организовать кластеры отказоустойчивых хранилищ на базе серверов для виртуальных машин VMware vSphere и Microsoft Hyper-V. В связи с большим интересом к тому, как именно работает это решение с технической точки зрения, постараемся писать об этом побольше. Сегодня мы расскажем об опциональной файловой системе LSFS (Log-Structured File System), которая повышает производительность операций записи и срок службы накопителей.

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

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

Одной из возможностей данного решения является функция inline-дедупликации хранимых данных, которая позволяет существенно экономить дисковое пространство на конечных блочных носителях. Напомним, что еще в 2011 году мы писали о дедупликации StarWind, но с тех пор технология существенно ушла вперед, и вот уже несколько лет она работает надежно и эффективно.

Для тех, кто хочет заранее узнать, сколько именно места можно сэкономить с помощью продукта Virtual SAN, компания StarWind выпустила бесплатную утилиту StarWind Deduplication Analyzer, которая помогает вам проанализировать текущую структуру хранения виртуальных машин и получить отчет о потенциальной экономии. Запускать утилиту можно как для всего хранилища в целом, так и для отдельных виртуальных машин, чтобы идентифицировать ВМ, которые лучше всего ужимаются вследствие дедупликации на диске.

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

По итогам работы утилиты будет выведен отчет о возможной экономии дискового пространства и количестве уникальных блоков на диске, который можно сохранить и распечатать:

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

Работает утилита достаточно быстро, а главное, что пользоваться ей очень просто - выбираете папку и нажимаете кнопку Scan. При этом Deduplication Analyzer не требует установки и работает сразу при запуске скачанного файла.

Загрузить StarWind Deduplication Analyzer можно по этой ссылке.

Многим из вас известны решения компании StarWind и, в частности, ее флагманский продукт для создания отказоустойчивых хранилищ StarWind Vritual SAN. С помощью этого решения можно не только организовать программные хранилища на базе серверов Hyper-V, но и расширить кластеры StarWind в облако публичного сервис-провайдера, например, Microsoft Azure. Это позволяет получить множество преимуществ...

Многие из вас знакомы с решением номер 1 на рынке для создания программных отказоустойчивых кластеров хранилищ StaWind Virtual SAN. За последнее время продукты компании сделали большой шаг вперед, в том числе в плане интерфейсов, и сегодня мы рассмотрим процесс установки и начала использования централизованного средства мониторинга кластеров Storage Spaces Direct - StarWind Manager. Это полностью бесплатный продукт и доступен сейчас в статусе Preview.

Многим из вас известен продукт для организации отказоустойчивых кластеров хранилищ под виртуальную инфраструктуруру StarWind Virtual SAN. Он выпускается уже в течение многих лет и давно зарекомендовал себя как лучшее в отрасли решение для создания программных хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V. Его основные возможности приведены тут и вот тут. А сегодня мы расскажем о том, что продуктом и всеми его функциями стало можно пользоваться фактически бесплатно!