Компания StarWind, известная своим решением номер 1 для создания отказоустойчивой инфраструктуры хранения виртуальных машин для платформы Hyper-V - StarWind Native SAN, выпустила интересный документ, понятно объясняющий превосходство своего продукта над аналогами, существующими на рынке:
Если говорить кратко, то все эти преимущества вытекают из архитектуры решения, которая построена на базе всего 2-х узлов, которые одновременно являются кластером хост-серверов и кластером хранилищ:
А это значит, что:
Это не требует затрат на приобретение дополнительного узла хранилища.
Более надежно - при отказе одного из узлов виртуальные машины продолжат без простоя работать на втором.
Более производительно - операции чтения идут сразу с локального диск узла, а операции записи могут использовать высокопроизводительный кэш.
Не так давно мы уже писали о новой версии решения для создания отказоустойчивых хранилищ для серверов VMware vSphere - StarWind iSCSI SAN & NAS 6.0. Одной из ключевых новых возможностей продукта является возможность создания треузловых кластеров хранилищ, которые более эффективны с экономической точки зрения, чем двухузловые.
Компания StarWind со своим продуктом прошла в финалисты конкурса "Storage, Virtualization & Cloud Awards", который отмечает заслуги производителей ПО в сфере хранения данных, виртуализации и облачных вычислений, в категории "Storage Software Product of the Year". Профиль компании StarWind на конкурсе можно посмотреть по этой ссылке.
Проголосовать нужно до 17 октября. Поддержите практически отечественного производителя, делающего реальные продукты, а не надувающих пузыри из соплей в Сколково!
Не так давно мы уже писали о технологии виртуальных томов vVOL, представленной на VMworld 2012, которая позволит дисковым массивам и хостам оперировать с отдельными виртуальными машинами на уровне логического дискового устройства, реализующего их хранилище, что повысит производительность и эффективность операций с ВМ.
Там же, на VMworld 2012, компания VMware представила технологию vSAN, реализующую распределенное хранение данных ВМ на локальных хранилищах хост-серверов VMware ESXi (Distributed Storage):
Концепция vSAN, включающая в себя Distributed Storage, является продолжением существующего подхода к организации общих хранилищ виртуальных машин на базе локальных дисков серверов - VMware vStorage Appliance. Работает это средство обеспечения отказоустойчивости хранилищ за счет полного дублирования хранилищ одного из узлов кластера, а также репликации данных между ними:
Теперь же, в скором времени в гипервизор VMware ESXi будет включена технология Distributed Storage, которая позволит агрегировать вручную или автоматически дисковые емкости (HDD и SSD) хост-серверов в единый пул хранения с функциями отказоустойчивости и кэширования:
Разрабатывается эта концепция на волне распространения SSD-накопителей в серверном оборудовании и СХД. Единый пул хранения кластера Distributed Storage будет не только объединять диски серверов (туда добавляются диски без созданных разделов с определенным администратором вкладом емкости в общий пул) и предоставлять пространство хранения виртуальным машинам на любом из хостов, но и будет управляем средствами политик механизма Policy-Based Storage Management. Интересно то, что размер кластера хранилища для Distributed Storage будет равен размеру кластера хостов (сейчас 32), в рамках которого все хосты имеют возможность использовать агрегированную емкость пула, даже те серверы, что не имеют дисков вовсе.
Все это будет интегрировано с механизмами HA, vMotion и DRS в целях обеспечения отказоустойчивости и балансировки нагрузки на хост-серверы. Кроме этого, агрегированный пул хранилищ будет поддерживать все основные технологии VMware для работы с хранилищами: снапшоты ВМ, связанные клоны, vSphere Replication (vR) и vStorage APIs for Data Protection (vADP).
С точки зрения политик хранения, Distributed Storage будет предоставлять следующие варианты для каждой виртуальной машины:
Доступная емкость и объем ее резервирования.
Уровень отказоустойчивости (степень дублирования данных на узлах = количество реплик).
Уровень производительности (какое количество SSD-кэша выделить для обслуживания реплик, а также число страйпов для диска ВМ, если необходимо).
Данные в кластере VMware Distributed Storage хранятся на локальных дисках узлов по схеме RAID-1, так как это дает максимальный экономический эффект с точки зрения затрат на 1 IOPS при условии комбинирования HDD-хранилищ данных и SSD-хранилищ кэша и данных (подробнее тут). SSD-кэш работает как фронтэнд для HDD-дисков, обрабатывая кэширование чтений и буферизацию записи для операций кластера, при этом сделано множество оптимизаций кэша для увеличения вероятности попаданий в кэш при чтении данных ВМ с дисков различных узлов.
Ну а на практике vSAN уже работает в лабораториях VMware, где инженеры демонстрируют возможности Distributed Storage:
Информации о времени доступности технологии VMware Distributed Storage пока нет. Возможно, базовые функции vSAN будут реализованы в VMware vSphere 6.0.
Не так давно мы уже писали о новой версии решения для создания отказоустойчивых хранилищ для серверов VMware vSphere - StarWind
iSCSI SAN & NAS 6.0. Одной из ключевых новых возможностей продукта является возможность создания треузловых кластеров хранилищ, которые более эффективны с экономической точки зрения, чем двухузловые.
В этой заметке мы приведем доступные издания StarWind
iSCSI SAN & NAS 6.0. Издание StarWind CDP - это просто iSCSI Target, без функций высокой надежности, которое обеспечивает защиту данных только средствами снапшотов. Издания High Availability - это полнофункциональные версии продукта, одинаковые по функционалу, но различающиеся лицензируемой емкостью хранилищ.
Возможности StarWind
iSCSI SAN & NAS 6.0:
Издание StarWind CDP
Издания High Availability
Назначение
Средний и малый бизнес
Малый бизнес
Средний бизнес
Крупный бизнес
Компоненты продукта
Доступная емкость хранилищ
Не ограничена
1ТБ/2ТБ/4TB/8ТБ
16ТБ/32ТБ/64ТБ
128ТБ/256ТБ/512ТБ
Централизованное управление
StarWind Console
StarWind Console
StarWind Console
StarWind Console
Число узлов, включенное в лицензию
1
2/3
2/3
2/3
Число одновременных iSCSI-соединений
Не ограничено
Не ограничено
Не ограничено
Не ограничено
Число Ethernet-портов
Не ограничено
Не ограничено
Не ограничено
Не ограничено
Число обслуживаемых физических и виртуальных дисков
Вместе с обновленной версией решения компания StarWind выпустила также ROI-калькулятор для расчета экономии денег на покупке хранилищ за счет механизма StarWind Global Deduplication.
Для 100-гиговых дисков виртуальных машин VMware vSphere получается экономия в 84%:
В качестве исходных параметров можно выбирать не только виртуальные машины, но и другие типы хранилищ физических серверов:
Доступен также выбор типа дисков (включая SSD) и используемого уровня RAID. Посчитать экономию за счет дедупликации StarWind можно здесь.
В конце прошлой недели компания StarWind Software объявила о выпуске своего флагманского продукта StarWind iSCSi SAN 6.0, предназначенного для создания двух- или треузловыхотказоустойчивых кластеров хранилищ для VMware vSphere и Hyper-V.
Новые возможности StarWind iSCSI SAN 6.0:
Возможность создания треузловых кластеров хранищ, что позволяет повысить уровень отказоустойчивости, производительности и надежности, а также более эффективно использовать дисковое пространство (RAID0 вместо RAID6). При этом все три узла являются активными и на них идет запись. По трем каналам синхронизации данные хранилищ синхронизируются между собой. Также все узлы обмениваются друг с другом сигналами доступности (Heartbeat).
Репликация на удаленный iSCSI Target через WAN-соединение с поддержкой дедупликации в конфигурации резервирования N+1. Об этом мы подробно писали тут.
Асинхронная репликация для дедуплицированных хранилищ. Любой iSCSI target может быть использован как хранилище назначения для репликации.
Поддержка Scale-Out File Servers в Windows Server 2012. Подробнее об этом здесь.
Поддержка механизмом дедупликации данных, которые удаляются с хранилищ - неиспользуемые блоки перезаписываются актуальными данными.
Использование памяти механизмом дедупликации сократилось на 30%. Теперь необходимо 2 МБ памяти на 1 ГБ дедуплицируемого хранилища при использовании блока дедупликациии 4 КБ.
Улучшенное управление HA-устройствами. Теперь можно добавить новый узел кластера StarWind к HA-устройству, удалить узел или переключиться между ними без необходимости заново пересоздавать HA Device.
HA-устройство может использовать другие типы устройств StarWind для хранения данных. Это может быть дедуплицированный диск, "тонкое" устройство IBV или устройство типа DiskBridge.
Возможность загрузки бездисковых серверов по iSCSI для хранилищ StarWind. Подробно процедура настройки этой функции описана в документе "StarWind iSCSI Boot".
Улучшенное резервное копирование для виртуальных машин VMware ESX/ESXi.
StarWind SMI-S agent, доступный для загрузки как отдельный компонент. Он позволяет интегрировать StarWind в инфраструктуру Systme Center Virtual Machine Manager (SC VMM), добавив StarWind Storage Provider, реализующий задачи управления таргетами и хранилищами.
Появилась полноценная поддержка механизма ALUA, работа с которым идет через SATP-плагин VMW_SATP_ALUA (подробнее об этом тут).
Некоторые дополнительные возможности для резервного копирования виртуальных машин на Hyper-V.
Новый GUI для управления процессом резервного копирования (интегрирован в Management Console).
Упрощенный процесс подключения серверов Hyper-V и ESXi.
Ну и главное, что в релизной версии появился VMware Backup Plugin для резервного копирования виртуальных машин VMware vSphere (он приобретается отдельно как дополнение).
Более подробно о новых возможностях StarWind iSCSI SAN 6.0 можно узнать на странице продукта. Сравнение изданий доступно тут, а сделать запрос на приобретение решения можно здесь.
Мы уже писали о недавно вышедшей обновленной бета-версии решения для создания отказоустойчивых хранилищ StarWind iSCSI SAN 6.0, где появилось множество новых возможностей, в том числе трехузловая архитектура кластеров хранилищ.
Причины, по которым желательно использоват трехузловой кластер, таковы:
1. Цена.
Если для двухузлового кластера рекомендуется дополнительный уровень отказоустойчивости на уровне RAID (например, RAID10), то вы получаете только 25% полезной емкости дисковых устройств (50% тратится на RAID и 50% остатка на поддержание синхронной копии). Для трехузлового же кластера можно обойтись RAID0, так как данные находятся на дисковых устройствах сразу трех узлов (можно использовать RAID0 или JBOD). Поэтому вы получаете 33% полезной емкости:
2. Надежность.
Очевидно, что три узла надежнее, чем два. Дополнительный уровень надежности, позволит обеспечить запросы самых критичных приложений предприятия.
К тому же, в первом случае, при выходе из строя одного из узлов, вы теряете 50% MPIO-путей, а во втором - только 33%.
3. Высокая производительность.
Когда в трехузловом кластере вы используете RAID0 - то данные с дисков читаются максимально быстро, а скорость записи ничем не уступает конфигурации с двухузловым кластером и RAID10. Кроме того, при выходе из строя узла в двухузловом кластере, кэш на втором узле очищается и переводится врежим write-through, что уменьшает производительность, а также вся система переходит в режим "degraded mode".
В случае с трехузловым кластером политики кэширования write-back сохраняются и потери производительности минимальны (приходим к обычному двухузловому кластеру).
Больше о продукте StarWind iSCSI SAN можно узнать здесь.
Мы уже писали о том, что в решении номер 1 StarWind iSCSI SAN для создания отказоустойчивых хранилищ VMware vSphere, есть возможность создания дедуплицированных виртуальных дисковых устройств (и вот тут), на которых могут быть размещены виртуальные машины.
Те из вас, кто следит за обновлениями StarWind, знают, что в последних версиях продукта появилась возможность репликации дедуплицированных устройств на другой узел кластера StarWind. Причем можно использовать репликацию дисковых устройств как в локальной сети, так и через WAN-сети в целях создания DR-площадки виртуальной инфраструктуры (пока экспериментально).
27-го августа выйдет StarWind iSCSI SAN 6.0, возможно, там последняя конфигурация уже будет поддерживаться полноценно. Пока ее можно тестировать и оценивать производительность и надежность.
Ну а чтобы уже сейчас приступить к развертыванию реплицируемых дедуплицированных iSCSI-хранилищ для вашей инфраструктуры VMware vSphere, компания StarWind выпустила хороший мануал по настройке этой функции "StarWind iSCSI SAN 5.9 Beta : DD devices with replication".
Ну и будете на VMworld 2012 - заходите на стенд StarWind (номер 536) - коллеги расскажут много интересного.
Мы уже писали о том, что такое и как работает технология VMware vStorage API for Array Integration (VAAI) (а также немного тут), которая позволяет передать операции по работе с хранилищами, которые выполняет компонент Data Mover в VMkernel, на сторону дискового массива. Это существенно улучшает показатели производительности различных операций (клонирования и развертывания ВМ, использования блокировок) за счет того, что они выполняются самим массивом, без задействования сервера VMware ESXi:
Если ваш массив не поддерживает примитивы VAAI, то чтобы склонировать виртуальный диск VMDK размером 64 ГБ, компонент Data Mover реализует эту операцию следующим образом:
Разделяет диск 64 ГБ на малые порции размером в 32 МБ.
Эту порцию 32 МБ Data Mover разделяет еще на маленькие операции ввода-вывода (I/O) размером в 64 КБ, которые идут в 32 параллельных потока одновремнно.
Соответственно, чтобы передать 32 МБ, Data Mover выполняет 512 операций ввода вывода (I/Os) по 64 КБ.
Если же массив поддерживает примитив XCOPY (он же Hardware Offloaded Copy и SAN Data Copy Offloading), то для передачи тех же 32 МБ будут использованы I/O размером в 4 МБ, а таких I/O будет, соответственно, всего 8 штук - разница очевидна.
Интересно, как работает VAAI с точки зрения ошибок при передаче данных: например, мы делаем клонирование ВМ на массиве с поддержкой VAAI, и вдруг возникает какая-то ошибка. В этом случае VMkernel Data Mover подхватывает операцию клонирования с того места, где VAAI вызвал ошибку, и производит "доклонирование" виртуальной машины. Далее ESXi периодически будет пробовать снова использовать VAAI на случай, если это была кратковременная ошибка массива.
При этом проверки в разных версиях ESXi будут производиться по-разному:
Для ESX/ESXi 4.1 проверка будет производиться каждые 512 ГБ передаваемых данных. Посмотреть этот параметр можно следующей командой:
# esxcfg-advcfg -g /DataMover/HardwareAcceleratedMoveFrequency Value of HardwareAcceleratedMoveFrequency is 16384
Это значение частоты 16384 нужно умножить на порцию 32 МБ и мы получим 512 ГБ. Чтобы поменять эту частоту, можно использовать команду:
Для ESXi 5.0 и выше все проще - проверка производится каждые 5 минут.
Помимо описанных в нашей статье примитивов Full Copy, Zero Block и ATS, начиная с версии ESXi 5.0, поддерживаются еще 2 примитива:
Thin Provisioning - механизм сообщения хостом ESXi дисковому массиву о том, что виртуальная машина или ее файлы с Thin LUN были удалены или перемещены (в силу разных причин - Storage vMotion, консолидация снапшотов и так далее), поэтому массив может забрать это дисковое пространство себе назад.
С точки зрения дисковых массивов, работающих на NFS (прежде всего, NetApp) в ESXi 5.0 также появилась поддержка примитивов VAAI:
Full File Clone – аналог функций Full Copy для VAAI на блочных хранилищах, предназначен для клонирования файлов виртуальных дисков VMDK.
Native Snapshot Support – передача на сторону массива функций создания снапшота ВМ.
Extended Statistics – включает возможность просмотра информации об использовании дискового пространства на NAS-хранилище, что полезно для Thin Provisioning.
Reserve Space – включает возможность создания виртуальных дисков типа "thick" (фиксированного размера) на NAS-хранилищах (ранее поддерживались только Thin-диски).
Функции VAAI включены по умолчанию и будут использованы тогда, когда станут доступны (например, при обновлении Firmware дискового массива, которое поддерживает VAAI).
Таги: VMware, vSphere, VAAI, Storage, ESXi, Enterprise, SAN
Компания StarWind Software, выпускающая продукт номер 1 StarWind iSCSI SAN для создания хранилищ для виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V, приглашает на вебинар "Introduction to SAN Infrastructures", посвященный созданию отказоустойчивой архитектуры хранения на базе данных платформ и протокола iSCSI, который пройдет завтра, 26 июля.
В рамках вебинара вы узнаете о том, как:
Настроить зеркало синхронизированных хранилищ с автоматическим восстановлением после отказа без простоя виртуальных машин
Создать синхронно реплицированную копию данных виртуальных хранилищ на DR-площадке
Как мы уже писали недавно, в VMware vSphere есть политика путей, называемая Fixed path with Array Preference (в интерфейсе vSphere Client 4.1 она называется VMW_PSP_FIXED_AP). По умолчанию она выбирается для дисковых массивов, которые поддерживают ALUA. Эта политика опрашивает дисковый массив (A-A или A-P), позволяя ему самому определить, какие пути использовать как preferred path, если это не указано пользователем...
Таги: StarWind, HA, iSCSI, Storage, Update, VMware, vSphere, SAN
В последнее время стало модным предоставлять виртуальные машины в аренду по модели IaaS. Этим занимается VMware со своей платформой vCloud в корпоративных инфраструктурах, а также Amazon, Microsoft и Google - в публичных облаках. Программы для облачных провайдеров есть также и поставщиков сопутствующих продуктов в сфере виртуализации, например, у Veeam и Кода Безопасности.
Напомним, что продукты StarWind позволяют создавать отказоустойчивые конфигурации хранилищ на базе iSCSI для виртуальных машин VMware vSphere, Microsoft Hyper-V и Citrix XenServer. При этом не требуется инвестиций в дорогостоящие хранилища Fibre Channel и сетевую инфраструктуру SAN, что делает продукты StarWind наиболее эффективными с точки зрения стоимости владения и единовременных капитальных затрат на создание инфраструктуры датацентра.
Кроме того, StarWind это:
Динамическое масштабирование хранилищ "на лету"
Отказоустойчивая конфигурация из двух или трех узлов кластера хранилищ
Использование существующих серверов и хранилищ данных
Компания StarWind, выпускающая продукт номер 1 для создания отказоустойчивых iSCSI-хранилищ серверов VMware vSphere и Microsoft Hyper-V, опять объявила о бесплатной раздаче NFS-лицензий на StarWind iSCSI SAN и StarWind Native SAN for Hyper-V для определенных групп ИТ-профессионалов. В их число входят:
Традиционно, бесплатные лицензии раздаются только для непроизводственного использования, т.е. только для целей тестирования, обучения, демонстраций и т.п. Ну и напомним, что если вы не принадлежите к данным группам ИТ-профессионалов, вы всегда можете скачать бесплатную версию StarWind iSCSI SAN Free, где есть следующие возможности:
Какие требования предъявляет дедупликация StarWind к аппаратному обеспечению:
Процессор. Минимально на сервере StarWind вам потребуются процессоры Intel Xeon Processor E5620 (или более поздние), либо их аналог по производительности от AMD. Рекомендуются процессоры Intel Xeon X5650 для получения максимальной производительности. При этом лучше иметь больше ядер с меньшей частотой, чем меньше ядер с большей частотой (раки по 3 рубля выгоднее) - это дает большую производительность для StarWind.
Память. Минимальное требование к опреативной памяти сервера StarWind iSCSI SAN - 4 ГБ. При этом нужно учитывать, что нужно закладывать сверх этого память на 2 вещи: дедупликацию и кэширование. Размер памяти, выделяемой для кэширования, выставляется в настройках при создании устройства StarWind, а вот размер памяти, необходимый для дедупликации понятен из следующей таблицы:
Больший размер блока дедупликации дает экономию памяти и процессорных ресурсов, но ухудшает показатели эффективности дедупликации, а на малых размерах блока дедупликации вам понадобятся существенные ресурсы сервера хранилищ StarWind. Ну и от размера блока зависит максимально поддерживаемый объем дедуплицированного диска (от 2 ТБ для 512 байт до 1024 ТБ для 256 КБ).
С точки зрения программного обеспечения, StarWind iSCSI SAN поддерживает любую серверную ОС Microsoft от Windows Server 2003 до Windows 2008 R2, но последняя является рекомендуемой платформой.
В интерфейсе StarWind дедуплицированное устройство создается с помощью мастера:
Далее просто выбираем размер блока дедупликации:
При настройке задачи резервного копирования в Veeam Backup and Replication на дедуплицированное хранилище StarWind не забудьте отключить встроенную дедупликацию от Veeam и компрессию, в соответствии с рекомендациями вендоров:
Кстати, вот один из тестов, показывающих эффективность дедупликации от StarWind для бэкапов Veeam (слева - архив с резервной копией, справа - файл дедуплицированного устройства StarWind):
Мы уже не раз писали о типах устройств в продукте StarWind iSCSI Target, который предназначен для создания отказоустойчивых iSCSI-хранилищ для серверов VMware vSphere и Microsoft Hyper-V, однако с тех времен много что изменилось: StarWind стал поддерживать дедуплицированные хранилища и новые типы устройств, которые могут пригодиться при организации различных типов хранилищ и о которых мы расскажем ниже...
Таги: StarWind, iSCSI, SAN, Enteprirse, HA, Storage, VMware, vSphere
Продолжаем рассказывать о средстве номер 1 StarWind Native SAN для создания отказоустойчивых хранилищ виртуальных машин для серверов Microsoft Hyper-V (тут о последней версии 5.8). Как известно, в средних и больших инфраструктурах серверов Hyper-V для управления хост-серверами и виртуальными машинами используется средство централизованного управления System Center Virtual Machine Manager (SC VMM). Поэтому администраторам хочется управлять серверами хранилищ StarWind непосредственно из консоли SC VMM. Для этого есть специальный компонент StarWind SMI-S Agent:
Поставить его с наскока не получится - нужно сначала прочитать документ "StarWind SMI-S Agent: Storage Provider for SCVMM", где описаны основные шаги установки этого агента и настройки SC VMM. Скачать StarWind SMI-S Agent можно по этой ссылке.
Ключевые особенности продукта от Symantec - возможность динамической балансировки запросов ввода-вывода с хоста по нескольким путям одновременно, поддержка работы с основными дисковыми массивами, представленными на рынке, и возможность учитывать характеристики хранилищ (RAID, SSD, Thin Provisioning).
Как можно узнать из нашей статьи про PSA, Veritas Dynamic Multi-Pathing (DMP) - это MPP-плагин для хостов ESXi:
Veritas DMP позволяет интеллектуально балансировать нагрузку с хостов ESXi в SAN, обеспечивать непрерывный мониторинг и статистику по путям в реальном времени, автоматически восстанавливать путь в случае сбоя и формировать отчетность через плагин к vCenter обо всех хранилищах в датацентре. Что самое интересное - это можно будет интегрировать с физическим ПО для доступа по нескольким путям (VxVM) в единой консоли.
Всего в Veritas DMP существует 7 политик для балансировки I/O-запросов, которые могут быть изменены "на лету" и позволят существенно оптимизировать канал доступа к хранилищу по сравнению со стандартным плагином PSP от VMware. Кстати, в терминологии Symantec, этот продукт называется - VxDMP.
Стоимость этой штуки - от 900 долларов за четырехъядерный процессор хоста (цена NAM). Полезные ссылки:
Если вам хочется поддержать компанию StarWind Software, выпускающую лучшие решения для создания отказоустойчивых кластеров хранилищ VMware vSphere и Microsoft Hyper-V, номинируйте ее продукты на сайте премии Storage Awards 2012:
Наши друзья из Киева будут очень вам благодарны, если вы укажете продукты StarWind iSCSI SAN или StarWind Native SAN for Hyper-V в следующих категориях (в других не надо):
"Storage Virtualization Product of the Year"
"Storage Product of the Year"
"Storage Company of the Year"
Чтобы узнать, чем хороши приведенные выше продукты, можно почитать следующие статьи:
Продолжаем рассказывать вам о решении номер 1 для создания отказоустойчивых хранилищ для серверов Hyper-V - StarWind Native SAN for Hyper-V. В середине февраля была выпущена версия 5.8 этого замечательного продукта, в которой появилось несколько полезных улучшений (напомним, что ранее была выпущена бета-версия 5.8).
Что нового появилось в StarWind Native SAN for Hyper-V 5.8:
Плагин дедупликации был существенно доработан: эффективность увеличилась до 80% и теперь поддерживается журналирование
Поддержка снапшотов для хранилищ виртуальных машин
Для отказоустойчивых хранилищ (HA Devices) могут быть использованы raw image files
iSCSI-трафик, идущий по каналу синхронизации между узлами StarWind HA теперь передается более быстро и надежно за счет замены транспорта MS iSCSI на собственный от StarWind (разработчики утверждают, что в MS iSCSI много багов, которые остались еще с 2006 года, что влияет на надежность решения)
Для канала синхронизации узлов и сигналов доступности могут быть использовано по несколько сетевых интерфейсов
Канал сигналов доступности (Heartbeat channel) теперь является обязательной конфигурацией для решения (во избежания несогласованности данных). Можно использовать для него публичную сеть - по нему не проходит много трафика.
Возможность "Switch partner" - для существующего узла StarWind HA может быть переназначен новый узел (это требует обновления пути доступа к хранилищам в Hyper-V).
Автоматическая синхронизация узлов после одновременного выключения двух узлов (например, отключение электричества). Если одно из дисковых устройств имеет более актуальные данные, то они будут автоматически синхронизированы на другой узел. Если вы используете методику кэширования write-back и хотя бы один из узлов был выключен некорректно (hard power off, например) - то автоматической синхронизации не произойдет, и будут ожидаться действия пользователя.
Возможность пометить узлы как синхронизированные ("Mark as Synchronized"). Это позволяет, например, при одновременном отказе сетевых компонентов обоих HA-узлов продолжить нормальный рабочий процесс, если неисправность не удается устранить сразу же. Как только оба узла будут связаны произойдет автоматическая синхронизация.
Возможность изменить размер HA-дисков узлов "на лету", без остановки работы виртуальных машин.
RAM disk - алгоритм генерации серийного номера был изменен для соблюдения его уникальности в пределах сети.
SPTI - параметр выравнивания буфера используется при проверки свойств устройства во время инициализации сервиса.
Появился компонент Hardware VSS provider for Deduplication and CDP devices, доступный как отдельный модуль для загрузки.
StarWindX - это фреймворк для управления решением StarWind через PowerShell, что позволит автоматизировать задачи продукта из сторонних приложений.
Hyper-V Backup Plugin - функциональное решение для резервного копирования виртуальных машин, доступное как отдельный компонент.
Полный список новых возможностей также приведен в этом документе.
Процедура обновления на StarWind Native SAN for Hyper-V 5.8 (потребуется небольшой простой хранилища и виртуальных машин):
Отключите всех клиентов от HA-узла, если это возможно.
Обновите StarWind на первом узле и дождитесь пока он запустится. На этом этапе работу с хранилищем будет осуществлять второй HA-узел.
На этом шаге придется прервать работу с хранилищем, запустив обновление на втором HA-узле StarWind.
Запустите синхронизацию на первом узле, по окончании которой второй узел перейдет в состояние "Ready" и станет обрабатывать запросы клиентов.
Как только первый узел также перейдет в это состояние процесс обновления можно считать законченным.
Продолжаем втягивать вас в процесс ознакомления с решением номер 1 StarWind Enterprise iSCSI для создания отказоустойчивых хранилищ виртуальных машин Microsoft Hyper-V и VMware vSphere. На этот раз несколько новостей о продукте StarWind Native SAN for Hyper-V (с резервным копированием StarWind Hyper-V backup Plug-in), который позволяет используя всего 2 сервера, сделать кластер из серверов Hyper-V и сделать хранилища прямо на этих серверах, которые продолжат непрерывно работать в случае отказа любого из них.
Во-первых, приходите сегодня на вебинар Толи Вильчинского, который быстро и четко говорит по-английски, но (наверняка) сможет ответить на ваши вопросы по-русски:
Мы уже не раз писали о продукте номер 1 для создания отказоустойчивых хранилищ iSCSI для виртуальных машин - StarWind Native SAN for Hyper-V (см. тут и тут). Напомним, что он позволяет, используя всего 2 сервера с установленной ролью Hyper-V сделать отказоустойчивый кластер как хранилищ, так и серверов, сэкономив 50% бюджета.
Сегодня хотим обратить ваше внимание на несколько документов по продукту StarWind Native SAN for Hyper-V, которые помогут детальнее ознакомиться с данным решением:
This white paper describes in details the benefits of the recently released StarWind revolutionary product called StarWind Native SAN for Hyper-V. The document highlights the might of server virtualization consolidated with the shared storage.
This white paper outlines advantages of server virtualization and gives detailed description of features and benefits provided by the shared storage. The document describes how to build a cost-effective, reliable and powerful storage infrastructure using the StarWind iSCSI SAN solution and lists the hardware prerequisites. The white paper also gives the step-by-step instruction of how to connect vSphere to ISCSI SAN.
This white paper mentions the advantages of virtualization and gives a short description of the components that help your system avoid downtime and stay 100% up and running. The document provides practical recommendations of how to build the replicated environment in order to ensure 100% uptime of your storage infrastructure.
This white paper provides an overview of how a SAN can help overcome limited IT budgets, being effective and inexpensive solution for educational institutions.
Как мы уже писали, недавно компания StarWind выпустила решение StarWind Native SAN for Hyper-V (возможности см. тут), которое позволяет построить кластер отказоустойчивости серверов и хранилищ для виртуальных машин Hyper-V, используя всего лишь 2 физических сервера, что вдвое сокращает затраты на внедрение решения и его обслуживание.
10 ноября компания StarWind проводит вебинар по продукту Native SAN for Hyper-V, ведет его Анатолий Вильчинский, который, как не трудно догадаться, говорит по-русски, поэтому вы сможете задать все интересующие вас вопросы по решению для вашей виртуальной инфраструктуры Hyper-V.
Дана и время вебинара: 10 ноября в 19-00 по московскому времени.
Компания StarWind, выпускающая продукт номер 1 для создания отказоустойчивых iSCSI-хранилищ для виртуализации StarWind Enterprise HA, на прошлой неделе выпустила новый продукт для создания кластера хранилищ виртуальных машин StarWind Native SAN for Microsoft Hyper-V (подробнее тут и тут). Отличительной особенностью продукта является то, что он позволяет орагнизовать отказоустойчивую конфигурацию серверов и хранилищ на базе всего лишь 2-х серверов Hyper-V, что в 2 раза сокращает затраты на оборудование (серверы, коммутаторы) и обслуживание решения.
Таги: StarWind, SAN, Hyper-V, iSCSI, Storage, HA, TCO, VMachines
Мы уже много писали о новом продукте StarWind Native SAN for Hyper-V, который позволит создать кластер отказоустойчивости серверов и хранилищ для виртуальных машин Hyper-V, используя всего 2 хост-сервера (это намного дешевле традиционных решений).
Напоминаем, что продукт выходит завтра, 18 октября.
Вебинар: "StarWind Native SAN for Hyper-V: конвергенция гипервизора и СХД"
18 октября, вторник
StarWind Native SAN for Hyper-V работает на локальном Hyper-V сервере и обеспечивает высокую доступность СХД при минимальных затратах и простоте развёртывания. Продукт идеально подходит для представителей малого и среднего бизнеса, которые не могут позволить себе аппаратные СХД, но хотят использовать следующие преимущества Hyper-V кластера:
Высокая доступность
Защита от сбоя жесткого диска
Защита от единой точки отказа. Безшовная интеграция с Hyper-V
Как мы уже писали тут, тут и тут, компания StarWind, выпускающая продукт номер 1 для создания отказоустойчивых хранилищ iSCSI для виртуальной инфраструктуры, выходит на рынок с новым решением - StarWind Native SAN for Hyper-V.
Основная идея продукта - дать пользователям возможность строить кластер отказоустойчивости серверов и хранилищ на базе двух серверов Hyper-V вместо четырех. Это сократит издержки на покупку оборудования и обслуживание решения при увеличении производительности (рекомендуется использовать адаптеры 10G).
Интересно посмотреть на расчеты по экономической составляющей решения - затраты уменьшаются почти в два раза (не нужно покупать еще 2 сервера, использовать порты коммутаторов, меньше тратится электричества и проще обслуживание). У компании StarWind есть подробное описание статей затрат:
Расчеты выглядят вполне правдоподобно. Все это приводит к тому, что стоимость капитальных и эксплуатационных затрат на содержание одного приложения снижается на 20-30%.
Немного скорректировалась дата выхода продукта StarWind Native SAN for Hyper-V - он появится 18 октября (записаться на получение можно тут).
Таги: StarWind, iSCSI, Hyper-V, SAN, Storage, HA, Update, TCO
Мы уже писали о новом продукте "StarWind Native Storage Appliance for Hyper-V" для создания отказоустойчивого кластера хранилищ на базе всего двух серверов Hyper-V (то есть, там же запущены и виртуальные машины). 15 сентября Константин Введенский, сотрудник StarWind проводил по этому продукту вебинар на русском языке, рассказывая об основных особенностях решения (напомним, продукт выходит 15 октября).
Появилась запись этого вебинара, которую всем пользователям платформы виртуализации Microsoft Hyper-V просто необходимо посмотреть (нужно зарегистрироваться на сайте):
Не так давно мы писали о новом продукте "StarWind Native Storage Appliance for Hyper-V", который позволяет создать отказоустойчивый кластер хранилищ на базе всего двух серверов Hyper-V (то есть на обоих серверах и виртуальные машины, и узлы кластера StarWind).
Компания StarWind Software, выпускающая продукт StarWind Enterprise iSCSI - номер 1 на рынке для создания отказоустойчивых хранилищ для серверов VMware vSphere и Microsoft Hyper-V, продолжает развивать ветку продукта, относящуюся к платформе виртуализации Hyper-V.
Новый продукт StarWind Native SAN for Hyper-V, планируемый к выпуску 15 сентября 2011 года, представляет собой средство для создания отказоустойчивой двухузловой конфигурации хранилища iSCSI на базе двух серверов Hyper-V.
Суть нативности StarWind iSCSI SAN для Hyper-V в том, что для создания полноценного и отказоустойчивого хранилища для виртуальных машин вам не понадобится вообще больше никакого "железа", кроме этих двух серверов.
StarWind Native SAN for Hyper-V - это Windows-приложение, которое вполне может существовать на обычном Windows Server с ролью Hyper-V. Поэтому вам не нужно дополнительного бюджета, кроме денег на приобретение продукта, что весьма актуально для небольших организаций, где собственно и используется Hyper-V.
Таким образом, на базе двух серверов у вас получится кластер высокой доступности (HA) и отказоустойчивый кластер хранилищ. Это будет очень интересно.
Если вы будете на VMworld 2011, который будет на днях, вы можете подойти к стойке StarWind (под номером 661) - там будут русскоговорящие ребята, которые вам расскажут и о StarWind Native SAN for Hyper-V, и об обычном StarWind Enterprise HA для VMware vSphere (сейчас актуальна версия StarWind 5.7).
Ну а мы, в свою очередь, в скором времени поподробнее расскажем о том, как работает StarWind Native SAN for Hyper-V.
Таги: StarWind, Enterprise, SAN, Hyper-V, Storage, Hardware, HA
Как знают администраторы систем хранения данных, у различных компонентов SAN-сети есть такой параметр как глубина очереди (Queue Depth). Он есть у HBA-адаптера сервера (на котором, например, работает VMware ESX / ESXi) и у порта Storage Processor'а системы хранения (SP). Глубина очереди определяет сколько операций ввода-вывода (IO) может быть одновременно обработано на устройстве.
Как мы уже писали, если до SP со стороны сервера ESX / ESXi используется один активный путь, то глубина очереди целевого порта массива (T) должна удовлетворять следующему соотношению:
T >= Q*L,
где Q - это глубина очереди на HBA-адаптере, а L - число LUN, обслуживаемых SP системы хранения. Если у нас несколько активных путей к одному SP правую часть неравенства надо еще домножить на P - число путей.
Соответственно, в виртуальной инфраструктуре VMware vSphere у нас несколько хостов имеют доступ к одному LUN через его SP и получается следующее соотношение:
T>= ESX1 (Q*L*P) + ESX2 (Q*L*P)+ и т.д.
Queue Depth на серверах
По умолчанию, для хостов VMware ESX / ESXi значение Queue Depth равно 32, как его изменить, читайте у нас тут и вот тут. Теперь внимание: этот параметр имеет значение только когда у вас только одна виртуальная машина на хост-сервере использует конкретный LUN. Если его используют уже 2 машины, то он игнорируется, а в действие вступает следующая расширенная настройка (Advanced Setting - как его задавать описано тут):
Disk.SchedNumReqOutstanding (DSNRO)
Этот параметр также по умолчанию равен 32. Он глобально определяет, сколько операций ввода-вывода (IOs) может максимально выдать одна виртуальная машина на LUN одновременно. В то же время, он задает это максимальное значение в IOs для всех виртуальных машин на этот LUN. То есть, если задано значение 32, то все машины могут одновременно выжать 32 IOs, это подтверждается в статье Jason Boche, где 3 машины генерируют по 32 одновременных IO к одному LUN, а реально к LUN идут все те же 32, а не 3*32:
Здесь видно, что активно выполняется 30 команд (максимально 32) для параметра DQLEN, а остальные 67 остаются в очереди. То есть параметр определяет максимальную планку в IO как для одной машины на LUN, так и для всех машин на LUN.
Важно, чтобы параметры Queue Depth и DSNRO были установлены в одно и то же значение. Это рекомендация VMware. Так что, если вздумаете изменить один из них - не забудьте и про второй. И помните, что параметр DSNRO для хоста - глобальный, а значит будет применяться ко всем LUN, подключенным к хосту.
Target Port Queue Depth на массивах
Для дискового массива (а точнее, SP) очередь - это то, куда он сладывает SCSI-команды в то время, пока обрабатывается и выполняется пачка предыдущих. Нормальный midrange-массив имеет глубину очереди 2048 и более. Если массив получает в очередь команд IO больше значения Target Port Queue Depth, то он назад выдает команду QFULL, которая означает, что очередь заполнена и хост-серверу нужно с этим что-то делать. VMware ESX / ESXi реагирует на это следующим образом - он уменьшает очередь на LUN и периодически (каждые 2 секунды) проверяет, не исчезло ли QFULL, и если исчезло, то начинает постепенно увеличивать глубину очереди для этого LUN (это может занять до одной минуты). Это и есть причины тормозов, которые часто возникают у пользователей VMware ESX / ESXi.
Как управлять очередью и адаптивный алгоритм VMware
Теперь становится понятным, почему мы сразу не выставляем параметр Disk.SchedNumReqOutstanding на хостах VMware ESX / ESXi в максимальное значение - мы можем вызвать QFULL на SP массива. С другой стороны, уменьшать его тоже нехорошо - мы ограничим количество операций IO с хоста на LUN.
Поэтому здесь нужен гибкий подход и он есть у VMware (adaptive queue depth algorithm). Работает он таким образом: мы его активируем с помощью параметров Disk.QFullSampleSize и Disk.QFullThreshold в Advanced Settings. Они влияют вот на что:
QFullSampleSize - если число число ответов QFULL (оно же BUSY) превысит его, то ESX / ESXi наполовину обрежет глубину очереди (LUN queue depth)
QFullThreshold - если число ответов о том, что QFULL или BUSY больше нет, превысит его, то ESX / ESXi будет постепенно увеличивать LUN queue depth на 1 (вроде бы, каждые 2 секунды).
Но сколько бы не уменьшалось DQLEN - ниже заданного нами значения DSNRO оно не упадет. Это защищает нас от неожиданного провала в производительности. Кстати, эти параметры тоже глобальные - так что если один (например, тормозящий) массив с хоста будет подвергаться такому адаптивному эффекту со стороны ESX / ESXi, то и для другого (например, производительного) тоже будут выполняться такие фокусы.
Теперь, что дополнительно можно почитать на эту тему:
То есть мораль всей басни такова - дефолтные зачения DSNRO и Queue Depth подходят для большинства случаев. Но иногда имеет смысл изменить их. Но в этом случае надо учитывать параметры системы хранения данных, структуру SAN, количество LUN и другие параметры, влияющие на производительность ввода-вывода.
RSS
