Напомним, что у компании StarWind есть отличное бесплатное решение для миграции физических и виртуальных машин - V2V Converter. С помощью этого продукта вы можете преобразовать образ виртуальной машины, который у вас работает на одной из платформ виртуализации, в нужный целевой формат ВМ, которая работает на базе виртуальных дисков соответствующего формата.
Давайте посмотрим, что в продукте появилось нового с начала этого года:
Добавлена поддержка конвертации виртуальных машин в Proxmox и из Proxmox
Улучшена функциональность конвертации для oVirt (OLVM и RHV)
Добавлена поддержка конвертации работающих виртуальных машин с ESXi в Hyper-V
Добавлена поддержка конвертации работающих виртуальных машин с Hyper-V на Hyper-V
Добавлена поддержка миграции виртуальных машин напрямую с хостов oVirt
Добавлена поддержка конвертации виртуальных машин в Oracle VirtualBox и из Oracle VirtualBox
Скачать StarWind V2V Converter можно совершенно бесплатно по этой ссылке.
Сейчас многие администраторы виртуальных инфраструктур 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 для операций в кластере
Установочный диск вы можете подготовить с помощью ПО 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.
Также помните, что в большинстве случаев для дисковых массивов 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 Virtual SAN, которое является сейчас одним из основных продуктов на рынке для организации отказоустойчивых кластеров хранилищ (а еще и самым технологически продвинутым). Сегодня мы поговорим об узле Witness node в кластерах и о том, как он помогает защитить его от массовых сбоев в виртуальной среде.
Многие из вас знают компанию StarWind Software, лидера в сфере поставки программных и программно-аппаратных решений для создания отказоустойчивых хранилищ. Помимо решений непосредственно для организации хранилищ, у компании есть и виртуальный модуль StarWind Backup Appliance, который предназначен для резервного копирования виртуальных машин на хранилищах StarWind. Это программно-аппаратный комплекс на базе оборудования NVMe, который позволяет избавиться от проблемы производительности хранилищ резервных копий и забыть о задаче планирования окна резервного копирования.
Модуль StarWind Backup Appliance поставляется в виде настроенного и готового к работе сервера резервного копирования, построенного на базе StarWind HyperConverged Appliance (HCA). Работа с продуктом происходит через удобный веб-интерфейс StraWind Web UI, есть также плагин StarWind для vCenter.
В апреле компания StarWind объявила, что StarWind Backup Appliance теперь включает в себя оборудование GRAID SupremeRAID - первую в мире карточку NVMe-oF RAID, которая обеспечивает высочайший уровень защиты данных в рамках технологии NVMe RAID на рынке.
Диски NVMe SSD постепенно становятся стандартом индустрии хранения данных, а решение для резервного копирования StarWind BA уже использует полностью только NVMe-хранилища. В этих системах была только одна проблема - с надежной реализацией RAID, и вот теперь она решена с помощью GRAID.
Традиционные RAID-контроллеры не были разработаны изначально для технологии NVMe, а программные RAID работают недостаточно эффективно, потребляя при этом большое число циклов CPU, что мешает рабочим нагрузкам сервера. Поэтому с теперь помощью карточек GRAID комплексы StarWind Backup Appliance обеспечат максимальную производительность и защиту данных на базе дисков NVMe SSD.
Вот так выглядят результаты тестов технологии GRAID по сравнению с текущими реализациями аппаратных RAID для NVMe:
Более подробно об этом нововведении можно узнать из пресс-релиза StarWind. Скачать пробную версию StarWind Backup Appliance можно по этой ссылке.
Многим из вас знакома компания 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 и дополнительной нагрузке на устройства.
Многим из вас знакомы продукты компании StarWind, предназначенные для создания отказоустойчивых хранилищ под различные платформы виртуализации. Сегодня мы поговорим о том, как настраивать аутентификацию доступа к хранилищам через протокол CHAP в решении StarWind Virtual SAN...
Недавно мы писали о новом продукте StarWind SAN & NAS от лидера в сфере программно-аппаратных хранилищ под виртуализацию - компании StarWind. Он предназначен для создания программных хранилищ на основе серверов с установленным там гипервизором.
Ну а на днях вышло еще одно новое решение - StarWind Backup Appliance. Оно, как можно догадаться, предназначено для резервного копирования виртуальных машин на хранилищах StarWind. Это программно-аппаратный комплекс на базе хранилища NVMe, который позволяет избавиться от проблемы производительности хранилищ резервных копий и забыть о задаче планирования окна резервного копирования.
Теперь бэкап на такое хранилище можно делать в любое время и без влияния на работу приложений и служб. За счет использования этого комплекса время резервного копирования у вас снизится минимум в 2 раза.
Более того, в случае сбоя вы сможете мгновенно восстановить виртуальные машины и файлы напрямую из резервной копии, обеспечив наилучшие показатели RPO и RTO по сравнению с традиционными решениями.
Модуль StarWind Backup Appliance поставляется в виде настроенного и готового к работе сервера резервного копирования, построенного на базе StarWind HyperConverged Appliance (HCA). Работа с продуктом происходит через удобный веб-интерфейс StraWind Web UI, есть также плагин StarWind для vCenter.
Высокая производительность и надежность решения достигается как за счет технологии NVMe, так и за счет отделения и изоляции сервисов резервного копирования от производственных данных. При этом сервисы бэкапа StarWind BA нагружают системные ресурсы только тогда, когда начинают выполнять задачу резервного копирования.
Важный момент, который стоит отметить - продукт Backup Appliance от StarWind поддерживается со стороны ProActive Premium Support, а значит, что ваша инфраструктура резервного копирования будет работать 24x7, даже когда вы в отпуске или спите.
Естественно, данные, находящиеся на хранилище резервных копий, надежно защищены с помощью технологий RAID и полностью отделены от сервисов, непосредственно реализующих резервное копирование. Ну а приятный бонус - это то, что вы можете выбрать один из следующих гипервизоров на модуле StarWind BA:
Microsoft Hyper-V версий 2016, 2019 или 2022
VMware vSphere версий 6.5, 6.7 или 7.0
На данный момент доступны 2 модели Backup Appliance (BA 30 и BA 60):
Как мы видим, обе модели представляют собой одноюнитовые серверы с 30 или 60 ТБ емкости (это полезная емкость после создания RAID) и 64 ГБ оперативной памяти на борту.
В качестве протоколов доступа к данным поддерживаются следующие:
iSCSI
SMB3
NFSv4.1
NVMe-oF
Ну и главное - в качестве ПО для резервного копирования используется лидирующий в отрасли продукт Veeam Backup and Replication V10 и V11. Тут можно быть спокойным - он работает надежно и быстро. В качестве системы мониторинга и отчетности можно использовать решение Veeam ONE.
Больше информации о решении StarWind Backup Appliance можно получить на этой странице. Живое демо продукта вы можете запросить вот тут.
Компания StarWind Software, известная многим из вас как ведущий производитель программно-аппаратных хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, запустила новый продукт StarWind SAN & NAS, который предназначен для создания хранилищ на основе севреров с установленным там гипервизором. В качестве платформы StarWind SAN & NAS использует Linux...
Итак, что нового появилось в 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 при накатывании бесплатной лицензии на сервер без интернет-соединения.
Физические устройства теперь есть в общем списке устройств. Их можно использовать для экспорта с физических ленточных устройств.
Добавлено свойство 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-устройство с нужными вам параметрами:
Здесь мы видим, что создается устройство с включенной дедупликацией, выключенной компрессией, нужным размером индексной памяти и заданного объема.
После создания это устройство надо отформатировать в 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 можно по этой прямой ссылке.
Многим из вас знакомы продукты компании StarWind, предназначенные для создания отказоустойчивых хранилищ под различные платформы виртуализации. Одним из лидеров отрасли является решение StarWind Virtual SAN, у которого есть множество функций хранения, обеспечения доступности и защиты данных. А сегодня мы поговорим еще об одном бизнесе компании StarWind - программно аппаратных комплексах для специальных задач...
Производительность дисковой подсистемы в Linux зависит от различных параметров и настроек, одной из которых является тип планировщика для работы с потоком ввода-вывода (I/O scheduler). Если вы планируете использовать продукт StarWind VSAN for vSphere для создания программных хранилищ на базе виртуальных машин Linux (Virtual Storage Appliance), то информация ниже может быть вам полезна.
В зависимости от типа целевого хранилища, иногда целесообразно поменять используемый тип планировщика. Чтобы вывести текущий тип I/O scheduler, нужно выполнить следующую команду для выбранного устройства:
В данном случае мы видим, что тип планировщика - это noop (он же none). В зависимости от версии ядра Linux, он также может быть выставлен как mq-deadline. Кстати, обратите внимание, что тип планировщика указывается на уровне отдельного дискового устройства.
Считается, что для SSD и NVMe-устройств лучше ставить планировщик none / noop, который уменьшает нагрузку на CPU, а вот для HDD-дисков лучше использовать mq-deadline, который показывает лучшие результаты по итогам синтетических тестов.
Чтобы поменять планировщик на noop для диска sdb, нужно выполнить следующую команду:
# echo noop > /sys/block/sdb/queue/scheduler
Потом надо обязательно проверить, что планировщик поменялся, следующей командой:
Но это все меняет тип планировщика на время, до перезагрузки, чтобы вы могли проверить разные планировщики и сделать тесты производительности. Чтобы сохранить эти изменения, нужно изменить файл scheduler.rules в директории /etc/udev/rules.d/
Например, если вы хотите поменять планировщик на noop для устройства sdb и установить политику "no read ahead" для него, то нужно добавить туда следующую строчку:
Рекомендуется выставлять одинаковый тип планировщика на всех узлах, где расположены хранилища StarWind VSAN. Также надо отметить, что последние версии продукта StarWind VSAN for vSphere при установке автоматически выставляют тип планировщика noop для SSD-хранилищ.
Как многие из вас знают, у компании StarWind, выпускающей лучший продукт Virtual SAN для создания программных iSCSI хранилищ под виртуализацию, есть и программно-аппаратный комплекс HyperConverged Appliance (HCA). Чтобы управлять этим решением в контексте всей инфраструктуры, существует продукт StarWind Command Center, на который мы сегодня посмотрим.
За время карантина компания 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.
Множество исправлений ошибок, в том чиле важных с возможным повреждением данных - поэтому обязательно нужно обновиться.
StarWindX PowerShell Module
Добавлена проверка размера сектора для образа Flat Image - нельзя создать Flat Device с размером сектора 512 бай при физическом размере 4096 байт.
Добавлен параметр валидации формата (format) для вызова Add-RamDevice. Допустимые значения: fat16, fat32, ntfs, raw.
Добавлен параметр "force" для команды "remove".
Добавлено свойство CreateTapeOnExport для вызова VTL ApplyReplicationSettings(). Подробнее в сэмпле скрипта VTLReplicationSettings.ps1.
Нотификации по электронной почте и в интерфейсе
Запись нотификаций в текстовый файл не всегда теперь держит его открытым, а открывает и закрывает при необходимости.
Улучшена безопасность при работе с SMTP и пофикшен баг с отсылкой письма без аутентификации.
Установщик
Число файлов в Log Rotate было увеличено до 20 во время обновлений существующих установок.
Management Console
Пофикшена ошибка с отображением событий из 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 Software, которая является одним из лидеров в сфере производства программных и программно-аппаратных хранилищ для виртуальной инфраструктуры.
StarWind HCA All-Flash
Первая важная новость - это выпуск программно-аппаратного комплекса StarWind HyperConverged Appliance (HCA) All-Flash, полностью построенного на SSD-накопителях. Обновленные аппаратные конфигурации StarWind HCA, выполненные в форм-факторе 1 или 2 юнита, позволяют добиться максимальной производительности хранилищ в рамках разумной ценовой политики. Да, All-Flash постепенно становится доступен, скоро это смогут себе позволить не только большие и богатые компании.
Решение StarWind HCA - это множество возможностей по созданию высокопроизводительной и отказоустойчивой инфраструктуры хранилищ "все-в-одном" под системы виртуализации VMware vSphere и Microsoft Hyper-V. Вот основные высокоуровневые возможности платформы:
Поддержка гибридного облака: кластеризация хранилищ и active-active репликация между вашим датацентром и любым публичным облаком, таким как AWS или Azure
Функции непрерывной (Fault Tolerance) и высокой доступности (High Availability)
Безопасное резервное копирование виртуальных машин
Проактивная поддержка вашей инфраструктуры специалистами StarWind
И многое, многое другое
Сейчас спецификация на программно-аппаратные модули StarWind HCA All-Flash выглядит так:
После развертывания гиперконвергентной платформы StarWind HCA она управляется с помощью единой консоли StarWind Command Center.
Ну и самое главное - программно-аппаратные комплексы StarWind HCA All-Flash полностью на SSD-дисках продаются сегодня, по-сути, по цене гибридных хранилищ (HDD+SSD). Если хотите узнать больше - обращайтесь в StarWind за деталями на специальной странице. Посмотрите также и даташит HCA.
Давайте посмотрим, что нового появилось в StarWind Virtual SAN V8 for Hyper-V:
Ядро продукта
Добавлен мастер для настройки StarWind Log Collector. Теперь можно использовать для этого соответствующее контекстное меню сервера в Management Console. Там можно подготовить архив с логами и скачать их на машину, где запущена Management Console.
Исправлена ошибка с заголовочным файлом, который брал настройки из конфига, но не существовал на диске, что приводило с падению сервиса.
Улучшен вывод событий в файлы журнала, когда в системе происходят изменения.
Улучшена обработка ответов на команды UNMAP/TRIM от аппаратного хранилища.
Добавлена реализация процессинга заголовка и блога данных дайждестов iSCSI на процессорах с набором команд SSE4.2.
Максимальное число лог-файлов в ротации увеличено с 5 до 20.
Механизм синхронной репликации
Процедура полной синхронизации была переработана, чтобы избежать перемещения данных, которые уже есть на хранилище назначения. Делается это путем поблочного сравнения CRC и копирования только отличающихся блоков.
Исправлена ошибка падения сервиса в случае выхода в офлайн партнерского узла при большой нагрузке на HA-устройство.
Значение по умолчанию пинга партнерского узла (iScsiPingCmdSendCmdTimeoutInSec) увеличено с 1 до 3 секунд.
Исправлена ошибка с утечкой памяти для состояния, когда один из узлов был настроен с RDMA и пытался использовать iSER для соединения с партнером, который не принимал соединений iSER.
Нотификации по электронной почте
Реализована поддержка SMTP-соединений через SSL/STARTTLS.
Добавлена возможность аутентификации на SMTP.
Добавлена возможность проверки настроек SMTP путем отправки тестового сообщения.
Компоненты VTL и Cloud Replication
Список регионов для всех репликаций помещен во внешний файл JSON, который можно просто обновлять в случае изменений на стороне провайдера.
Исправлена обработка баркодов с длиной, отличающейся от дефолтной (8 символов).
Исправлена ошибка падения сервиса при загрузке tape split из большого числа частей (тысячи).
Исправлены ошибки в настройках CloudReplicator Settings.
Модуль StarWindX PowerShell
Обновился скрипт AddVirtualTape.ps1, был добавлен учет параметров, чувствительных к регистру.
Для команды Remove-Device были добавлены опциональные параметры принудительного отсоединения, сохранения сервисных данных и удаления хранимых данных на устройстве.
Добавлен метод IDevice::EnableCache для включения и отключения кэша (смотрите примеры FlashCache.ps1 и FlushCacheAll.ps1).
VTLReplicationSettings.ps1 — для назначения репликации используется число, кодирующее его тип.
Свойство "Valid" добавлено к HA channel.
Сценарий MaintenanceMode.ps1 — улучшенная обработка булевых параметров при исполнении сценария из командной строки.
Тип устройства LSFS — удален параметр AutoDefrag (он теперь всегда true).
Средство управления Management Console
Небольшие улучшения и исправления ошибок.
Скачать полнофункциональную пробную версию StarWind Virtual SAN for Hyper-V можно по этой прямой ссылке. Release Notes доступны тут.
Сегодня мы расскажем об отличиях коммерческой и бесплатной версий одного из лучших решений для создания отказоустойчивых программных хранилищ под виртуальные машины StarWind Virtual SAN. Последний раз мы писали о сравнении возможностей платной и бесплатной версий в далеком 2017 году, и с тех пор, конечно же, много что изменилось.
Многие администраторы виртуальных инфраструктур в курсе про технологию NVMe (интерфейс Non-volatile Memory дисков SSD), которая была разработана для получения низких задержек и эффективного использования высокого параллелизма твердотельных накопителей. Такие устройства хоть и стоят дороже, но уже показывают свою эффективность за счет использования десятков тысяч очередей команд, что дает очень низкие задержки, требующиеся в таких сферах, как системы аналитики реального времени, онлайн-трейдинг и т.п.
К сожалению, протокол iSCSI (да и Fibre Channel тоже) разрабатывался тогда, когда инженеры еще не думали об архитектуре NVMe и высоком параллелизме, что привело к тому, что если использовать iSCSI для NVMe, использование таких хранилищ происходит неэффективно.
Главная причина - это одна очередь команд на одно устройство NVMe, которую может обслуживать iSCSI-протокол, весь смысл параллелизма теряется:
Вторая проблема - это то, что iSCSI использует процессор для диспетчеризации операций ввода-вывода, создавая дополнительную нагрузку на серверы, а также имеет некоторые сложности по перенаправлению потоков операций для нескольких контроллеров NVMe и устройств хранения на них.
Для этого и был придуман протокол NVMe over Fabrics (NVMe-oF), который не имеет таких ограничений, как iSCSI. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP.
Компания StarWind сделала свою реализацию данного протокола для продукта StarWind Virtual SAN, чтобы организовать максимально эффективное использование пространства хранения, организованного с помощью технологии NVMe. Об этом было объявлено еще осенью прошлого года. Он поддерживает 64 тысячи очередей, в каждой из которых, в свою очередь, может быть до 64 тысяч команд (в реальной жизни в одной очереди встречается до 512 команд).
Важный момент в реализации NVMe-oF - это применение технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы.
Также RDMA позволяет маппить несколько регионов памяти на одном NVMe-контроллере одновременно и организовать прямое общение типа точка-точка между инициаторами разных хостов (несколько Name Space IDs для одного региона) и этими регионами без нагрузки на CPU.
Такой подход, реализованный в продуктах StarWind, дает потрясающие результаты в плане производительности, о которых мы писали вот в этой статье. К этой статье можно еще добавить то, что реализация инициатора NVMe-oF на базе Windows-систем и таргета на базе Linux (который можно использовать в программно-аппаратных комплексах StarWind Hyperconverged Appliances, HCA) дала накладные издержки на реализацию всего 10 микросекунд по сравнению с цифрами, заявленными в даташитах производителя NVMe-устройств. Знающие люди поймут, насколько это мало.
Еще надо отметить, что бесплатный продукт StarWind NVMe-oF initiator - это единственная программная реализация инициатора NVMe-oF на сегодняшний день. В качестве таргета можно использовать решения Intel SPDK NVMe-oF Target и Linux NVMe-oF Target, что позволяет не зависеть жестко от решений StarWind.
Подробнее о StarWind NVMe-oF initiator можно узнать вот в этой статье. А загрузить его можно по этой ссылке.
В последних числах августа компания 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
Для оптимизации потока ввода-вывода и балансировки с точки зрения 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 Software известна своим лидирующим в отрасли решением Virtual SAN, которое позволяет создать отказоустойчивый кластер хранилищ для виртуальных машин на различных платформах. Сегодня мы расскажем о средстве StarWind Virtual Tape Library (VTL), реализующем виртуальную ленточную библиотеку, и его совместном использовании с решением для резервного копирования и репликации Veeam Backup and Replication.
Компания StarWind Software известна пользователям как производитель лучшего в отрасли программного решения Virtual SAN для создания отказоустойчивых хранилищ на базе хост-серверов виртуализации VMware vSphere и Microsoft Hyper-V. StarWind иногда выпускает бесплатные утилиты для администраторов виртуальных инфраструктур, и сегодня мы поговорим об очередной новинке - StarWind iSCSI Accelerator...
Компания StarWind хорошо всем вам известна как лидер отрасли в сфере производства программных и программно-аппаратных хранилищ под инфраструктуру виртуализации. В частности, одно из самых популярных решений StarWind Virtual SAN позволяет создать отказоустойчивый кластер хранилищ для виртуальных машин на базе всего двух серверов.
Эти серверы могут исполнять как вычислительную нагрузку для ВМ, так и предоставлять ресурсы хранения. Когда все аспекты инфраструктуры объединяются в единую систему управления, такая инфраструктура называется гиперконвергентной (Hyperconverged Infrastructure, HCI).
Недавно компания StarWind анонсировала HCI-решение Command Center, которое позволит из единого интерфейса осуществлять мониторинг виртуальной среды на базе хранилищ Virtual SAN, а также управлять ею.
Command Center - это веб-интерфейс, построенный на базе технологии HTML5, который дает средства для управления виртуальными машинами и хост-серверами виртуализации, где для каждой из сущностей доступно до 100 различных параметров настройки. Единая панель управления инфраструктуры HCI позволяет выполнять ежедневные операции до 5 раз быстрее по сравнению с использованием нескольких консолей.
С помощью Command Center можно будет не только управлять сущностями виртуальной инфраструктуры, но и контролировать такие процессы, как оркестрация операций, резервное копирование Veeam Backup & Replication и многое другое.
Только 5% функционала Command Center приходится на решение Virtual SAN, остальное - это управление гипервизорами, резервным копированием, инфраструктурой публичных облаков и прочими аспектами. Кстати, Command Center будет поддерживать различные гипервизоры - VMware vSphere, Microsoft Hyper-V, Red Hat KVM и, возможно, другие платформы.
С продуктом можно будет опционально докупить StarWind ProActive Support - она позволит собирать телеметрию с компонентов Command Center и на основе аналитики на стороне StarWind (ML/DL) выявлять причины возникающих проблем.
RSS
