Неадвно мы писали о новых возможностях средства для создания отказоустойчивых кластеров хранилищ VMware Virtual SAN 6.0, где одной из таких возможностей стала возможность конфигурации
All-Flash кластера VSAN (то есть, когда и для кэша, и для данных используются SSD-диски):
Естественно, эта штука работает намного быстрее, чем раньше, поскольку прежде данные можно было размещать только на HDD-дисках. Но насколько это стало быстрее?
Чтобы показать некоторые цифры на практике, компания VMware провела тест на bootstorm - ситуацию, когда множество десктопов загружаются одновременно (например, в начале рабочего дня). Для этого была использована следующая конфигурация:
64 высокопроизводительных узла кластера Virtual SAN исключительно на SSD-дисках (All-Flash).
6401 виртуальных ПК (то есть по 100 каждом хосте), которые включаются одновременно.
Результаты теста оказались весьма позитивными:
За 24 минуты все виртуальные ПК загрузились.
Еще за 16 минут все десктопы получили IP-адреса и были готовы к работе.
В итоге все заняло 40 минут. Для почти шести с половиной тысяч машин это весьма и весьма неплохой результат. Кроме того, отмечается, что команда VMware не использовала никаких специальных настроек или модификаций ПО - тест работал, что называется, "из коробки".
Не так давно мы писали о новых возможностях решения для отказоустойчивости хранилищ VMware Virtual SAN 6.0, которое выйдет вместе с новой версией платформы виртуализации VMware vSphere 6. Одной из таких новых возможностей стал режим All-Flash Configuration, когда хост-сервер ESXi использует только SSD-накопители. При этом быстрые и надежные накопители используются для целей кэширования (cache tier), а устройства попроще - для хранения данных (capacity tier).
Чтобы использовать конфигурацию All-Flash нужно специальным образом пометить диски хост-серверов ESXi для яруса Capacity Tier. Сделать это можно через консоль RVC, либо через интерфейс ESXCLI на каждом из хостов.
Так, например, это делается через RVC:
А вот последовательность команд ESXCLI:
Получается, что на каждом из хостов кластера Virtual SAN администратор должен с помощью CLI-интерфейса обозначать диски, которые будут использоваться для создания яруса хранения виртуальных машин. Жутко неудобно.
Кстати, узнать о том, входит ли конкретный диск в Capacity Tier можно с помощью команды VSAN Disk Query (vdq):
# vdq -q
Так вот, коллеги с punchingclouds.com делают утилиту с GUI, которая позволит назначать дисковым устройствам на хостах ESXi это свойство быстро и удобно, экономя часы времени (представьте, что у вас 64 узла в кластере, на каждом из которых по 10 SSD-дисков, то есть надо назначить 640 дисков!).
Для начала работы надо ввести данные учетной записи VMware vCenter, а также пользователя на хостах VMware ESXi. Минус тут в том, что пароль на всех хостах должен быть одинаковый (но это обещают исправить в следующей версии, сделав загрузку csv-файла с паролями).
Перед тем, как приступить к операциям с дисками, нужно включить SSH на хостах ESXi (настройка на хостах происходит через ESXCLI), делается это кнопкой "Enable SSH". Далее можно сгруппировать похожие устройства по хостам или кластеру, после чего отметить нужные устройства в списке дисков.
Ну и далее нажимаем кнопку "Set Capacity Flash", чтобы назначить диски для хранения виртуальных машин, или "Remove Capacity Flash", чтобы отвязать их от этой роли.
Утилита VMware VSAN All-Flash Configuration Utility скоро будет доступна, следите за обновлениями здесь.
Как вы знаете, недавно компания VMware сняла эмбарго на освещение новых возможностей платформы виртуализации VMware vSphere 6.0, о которых мы писали вот тут (и тут). На блогах, посвященных технологиям виртуализации, появилось много разных статей о новых возможностях продукта, и мы уже писали о технологии непрерывной доступности VMware Fault Tolerance 6.0.
Сегодня мы хотим рассказать об отказоустойчивых кластерах VMware Virtual SAN 6.0, для которых версия программного обеспечения продвинулась с 1.0 сразу до 6.0 (поэтому пользователи, все же, не должны заблуждаться насчет зрелости продукта - это его вторая версия).
Итак, что нового появилось в VMware Virtual SAN 6.0:
1. Поддержка архитектуры All Flash для создания кластера хранилищ.
Теперь доступны два варианта развертывания VSAN:
Hybrid – Virtual SAN, как и раньше, использует SSD-диски для кэширования, а для хранения ВМ используются обычные HDD-диски. Максимально возможные конфигурации этой архитектуры стали выше (например, стало 64 хоста в кластере).
All Flash – Virtual SAN использует имеющиеся Flash-накопители как для кэширования, так для хранения ВМ.
Отличия между данными архитектурами:
В конфигурации All Flash девайсы, ответственные за кэширование, будут производить только кэширование записи и не будут делать кэширование на чтение (это очевидно почему). В гибридной конфигурации, как и раньше, 30% емкости SSD-кэшей используется для Write Buffer, а 70% - для кэша на чтение.
В целом, утверждается, что решение Virtual SAN теперь готово к полноценной промышленной эксплуатации.
2. Возможность High Density Direct Attached Storage(HDDAS).
Теперь кластеры Virtual SAN удобно использовать в окружениях с блейд-системами. Для них поддерживаются как SDD, так и HDD-устройства, включая flash-хранилища блейд-серверов.
Если раньше блейд-системы не очень подходили для организации кластеров ввиду физических ограничений по локальным хранилищам, то теперь это вполне подходящий вариант использования для корпоративной инфраструктуры. Поддержка устройств будет строго контролироваться и постоянно обновляться в VMware HCL.
3. Новая файловая система и формат On-Disk.
Virtual SAN в VMware vSphere 5.5 использовал модифицированный формат файловой системы VMFS с измененным механизмом блокировок, которая называлась VMFS-L. Теперь же в VSAN 6.0 используется файловая система VSAN FS, специально предназначенная для кластеров хранилищ.
Старый формат VMFS-L поддерживается и в новой версии, но VMware предлагает провести миграцию хранилищ, тем более что это делается без простоя сервисов.
4. Функции Proactive Rebalance.
В Virtual SAN 6.0 появилась возможность ребаланса объектов по виртуальным дискам в случае, если подключается новый узел vSphere или если диски заполнены на 80% и более. Делается это через Ruby Console.
5. VSAN Fault Domains
(группы отказа).
Теперь в VSAN можно определять домены отказа, то есть группы хостов у которых может произойти одновременный сбой (например, отказ питания на стойке), чтобы все их объекты были задублированы в других доменах:
Теперь реплики объектов происходят не на уровне хостов, а на уровне Fault Domains (в данном случае инфраструктура хранения переживет отказ одной стойки):
6. Новые функции для дисков (Serviceability Functions).
Light LED on failures – включение LED-индикатора при отказе.
Turn on disk LED manually - включение LED-индикатора вручную для диска, чтобы его можно было найти на массиве.
Marking a disk as local – если диск не обнаружился как локальный, его можно пометить вручную из GUI.
Marking a disk as SSD - теперь эта опция есть в GUI, нужна если диск автоматически не распознается как SSD.
7. Улучшения сетевого взаимодействия.
Теперь Virtual SAN 6 поддерживает конфигурации на уровне Layer 3. Кроме того, теперь доступна конфигурация с Jumbo Frames. Ну и добавлена поддержка возможностей vDS и Network IO Control (NetIOC).
8. Новый тип виртуального диска VMDK - vsanSparse.
Ранее использовались стандартные Redo-диски, но они не были приспособлены под кэширование и другие функции VSAN FS, поэтому сделали новый тип диска vsanSparse.
9. Улучшенные функции Disk/Disk Group Evacuation.
Возможность эвакуации данных с отдельного диска или группы перед тем, как вы его хотите вывести из эксплуатации физически. Ранее приходилось переводить весь хост в Maintenance Mode, чтобы было очень неудобно при поломке лишь одного диска.
10. Новое представление Resynchronization Dashboard.
Это представление показывает статус объектов, которые по тем или иным причинам находятся в состоянии ресинхронизации. Также показывается примерное время окончании синхронизации:
11. Новые службы 3rd Party File Services.
Сторонние вендоры теперь могут надстраивать свои решения над VMware Virtual SAN. Например, мы писали о таком решении совсем недавно - это NexentaConnect.
12. Полноценная поддержка командлетов PowerCLI.
Ранее интерфейс PowerCLI поддерживался неофициально, теперь же командлеты задокументированы и поддерживаются:
13. Службы мониторинга жизнедеятельности (VSAN Health Services).
Теперь для компонентов Virtual SAN доступна информация об их состоянии:
14. Storage Consumption Models.
Возможность визуализовать использование ресурсов хранения Virtual SAN 6.0 при создании или изменении VM Storage Policy.
О доступности VMware Virtual SAN 6.0 будет объявлено отдельно.
Таги: VMware, Virtual SAN, Update, VSAN, vSphere, Storage, SSD, HA
Многие из вас знают про решение VMware Virtual SAN, представляющее собой средство для создания отказоустойчивых кластеров хранилищ на базе локальных дисков серверов VMware ESXi. Но это всего лишь средство для хранения и обеспечения отказоустойчивости виртуальных машин, а можно ли все пространство хранения в небольшой компании организовать полностью на базе локальных дисков серверов и управлять ими из одной точки?
Компания Nexenta считает, что можно, предлагая пользователям VMware vSphere и VMware Virtual SAN продукт NexentaConnect, позволяющий создавать NFS и SMB ресурсы для размещения данных виртуальной среды и пользователей на локальных дисках хост-серверов.
NexentaConnect это надстройка над Virtual SAN, которая предоставляет следующие возможности централизованно управляемого хранилища:
Экспорт файловых шар по протоколам NFSv3, NFSv4 и SMB 2.1.
Оптимизированный кэш на чтение, размещенный на стороне хост-серверов.
Техники сжатия данных и дедупликации.
Быстрая настройка прямо из vSphere Web Client.
Совместимость с VMware HA и DRS.
Интеграция с доменом AD (поддержка AAA и Kerberos).
Использование преимуществ Virtual SAN.
NexentaConnect состоит из следующих компонентов:
Плагин для vSphere (как для Web Client, так и для vSphere Client).
NexentaConnect Manager – виртуальный модуль (Virtual Appliance) на базе Ubuntu Linux (64 Bit), предоставляющий сервисы управления решением, такие как мониторинг, планировщик событий, база данных, обслуживание операций и т.п.
NexentaConnect Filers – это компоненты, реализующие, собственно, экспорт сетевых шар. Развертываются автоматически по одному на кластер Virtual SAN в момент создания первой общей папки.
Особенности файлеров:
Отдельная файловая система, составленная из виртуальных дисков VMDK по 2 ТБ (для каждой из политик хранения). 2 ТБ - это для того, чтобы обеспечить поддержку со стороны VMware VSAN. Всего можно объединить до 30 VMDK на файлер.
Размер блока 128 КБ.
Развертывание при первом обращении - масштабирование пространства хранения по требованию.
Развертывание как Thin provisioned, так и в режиме заранее аллоцированного пространства.
Параметры файлеров:
ОС Ubuntu Linux (64 Bit)
4 vCPU
16 GB RAM
Минимум 2 виртуальных диска (до 30)
Объем диска до 2 TB
2 сетевых адаптера
Достоинства продукта:
Сжатие данных алгоритмом LZ4 в реальном времени с небольшой нагрузкой на CPU.
До 500 MB/s на компрессию (на ядро).
До 1.5 GB/s на декомпрессию (на ядро).
Дедупликация нулевых блоков.
Дедупликация данных в режиме Tech Preview (полноценная будет во второй версии).
Требования для развертывания NexentaConnect:
VMware vSphere 5.5 или выше
VMware vCenter Server 5.5 U1 или выше (Windows и Linux)
ESXi 5.5 U1 или выше
Кластер VMware vSphere с установленным Virtual SAN
VMware vSphere Web Client
VMware HA (опционально)
Службы каталога (Directory Services - опционально)
Microsoft Windows Active Directory 2008 R2 или выше
VMware vCenter Server 5.5 U1 или выше
DNS
DHCP
NexentaConnect - это еще один способ построить Scale-Out файловый сервер (то есть масштабирующиеся по требованию службы хранения). Например, это востребованной в инфраструктуре виртуальных ПК предприятия, где требуется хранить не только виртуальные машины, но и данные их пользователей.
Об одном из подобных решений - StarWind Virtual SAN - мы регулярно пишем (сейчас это лучшее решение на рынке). Вот тут, например, мы писали про документ о построении инфраструктуры файловых сервисов на базе StarWind.
Добавим, что решение NexentaConnect доступно не только для инфраструктуры VMware vSphere, но и для Citrix XenServer (пока в бете). Больше подробностей о продукте можно узнать вот на этой странице.
Вебинар пройдет 21 января в 22-00 по московскому времени:
На вебинаре вы узнаете про протокол SMB 3.0 и технологию Microsoft Clustered Storage Spaces, с помощью которых и продукта StarWind Virtual SAN можно строить программно-определяемые хранилища (software-defined storage). Вы узнаете, как можно получить надежную и масштабируемую инфраструктуру хранилищ для платформы виртуализации Microsoft Hyper-V, дополняя технологию Storage Spaces возможностями Virtual SAN.
Вебинар проводят Jon Toigo из компании Toigo Partners International LLC и Анатолий Вильчинский из компании StarWind Software.
На днях компания Citrix анонсировала покупку компании Sanbolic, выпускающей инструменты для агрегации различного типа хранилищ в единой консоли управления. Продукт Sanbolic позволяет объединить модные нынче server attached storage (на базе локальных дисков серверов), облачные хранилища, такие как Amazon AWS, а также традиционные дисковые массивы SAN. Предполагается, что такое решение позволит крупным предприятиям скорее адаптировать хранилища на локальных дисках и облачные ресурсы.
Основная задача Sanbolic - объединить хранилища (например, локальные диски серверов) в единый пул, обеспечить отказоустойчивость за счет распределения данных по узлам и избыточности и презентовать тома уже конечным узлам-потребителям. В этом плане Sanbolic напоминает VMware Virtual SAN или, например, Nutanix.
В качестве файловой системы используется Melio FS, а сами тома презентуются как шары SMB/CIFS или NAS. Melio FS поддерживает объединение хранилищ до 2000 физических узлов и до 18 миллионов терабайт пространства. Более подробно о возможностях этой ФС написано тут.
Софт Sanbolic поддерживает системы Windows, Linux, Xen, KVM, Hyper-V и OpenStack и не поддерживает VMware vSphere (что сыграло свою роль в покупке именно компанией Citrix). Таким образом, похоже что Citrix планирует составить конкуренцию таким продуктам, как VMware Virtual SAN и StarWind Virtual SAN. Также среди подобных решений можно отметить Maxta MxSP, SimpliVity и Scale Computing.
Более подробно о решениях Sanbolic можно почитать по этой ссылке.
Компания StarWind Software, ведущий поставщик решений для создания отказоустойчивых программных хранилищ, объявляет о начале серии регулярных вебинаров каждый четверг о продукте Virtual SAN. Мероприятия будут проходить в дружелюбной и расслабленной обстановке, без маркетинговых прогрузов и пушей. Там будет постепенно и неспешно с технологической точки зрения рассказываться о том, как правильно "потреблять" продукт, то есть использовать весь спектр его возможностей в корпоративной инфраструктуре.
В дополнение к этой акции, StarWind запустила еще одно промо - при приобретении одного из изданий Virtual SAN до 31 декабря вы получаете скидку 15%!
Комбинация этих двух акций означает вот что - если даже сейчас у вас полностью выработан бюджет 2014 года, вы можете просто разместить заказ на StarWind Virtual SAN со скидкой 15% сейчас, а заплатить деньгами первого квартала 2015 года.
Все подробности вы можете узнать непосредственно по адресу: sales@starwindsoftware.com.
Компания StarWind поздравляет вас с наступающим Новым годом и Рождеством!
Полтора месяца назад мы просили наших читателей проголосовать за продукт StarWind Virtual SAN, который позволяет создавать отказоустойчивые кластеры хранилищ для виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V.
Наш призыв был услышан, и решение StarWind Virtual SAN заняло второе место в номинации Storage Virtualisation Product of the Year (продукт года в сфере виртуализации хранилищ). Поздравляем наших коллег с этим достижением! И благодарим вас за голосование за лучший продукт для виртуализации хранилищ.
Продукт StarWind Virtual SAN уже многие годы на рынке и работает в производственной среде тысяч компаний по всему миру.
Напомним основные возможности StarWind Virtual:
Высокая доступность с синхронным зеркалированием: 3-узловой кластер высокой доступности
Автоматическое восстановление после отказа
Восстановление с быстрой синхронизацией
Непрерывная защита данных и мгновенные снимки
Асинхронная репликация по WAN (ускоренная): конфигурация N+1
Горизонтально-масштабируемое NAS-хранилище
Глобальная дедупликация
Тонкое резервирование
и многое другое (подробнее о новых возможностях тут)
Скачать пробную версию StarWind Virtual SAN можно по этой ссылке (там есть версия как для VMware, так и для Hyper-V).
Таги: StarWind, Award, Storage, iSCSI, Virtual SAN
Согласно условиям предложения, вы получаете возможность на срок до 90 дней отсрочить платеж по подписанному счету за лицензии на любые издания StarWind Virtual SAN.
Кроме того, на данные продукты действует еще одно беспрецедентное предложение - 30-дневный манибэк в случае, если что-то в продукте вас не устроит (без каких-либо вопросов).
Для того, чтобы воспользоваться данным предложением, нужно заполнить форму вот по этой ссылке, или направьте письмо на этот адрес - sales@starwindsoftware.com.
Бесплатную лицензию полнофункционального Virtual SAN для Hyper-V с функциями отказоустойчивости на два узла могут получить следующие категории специалистов:
Microsoft Certified Trainers (MCTs)
Most Valuable Professionals (MVPs)
Microsoft Certified Professionals (MCPs)
О новых возможностях последней версии StarWind Virtual SAN v8 вы можете прочитать у нас вот тут, а ниже напомним основные возможности продукта, из-за которых вам прямо сейчас стоит обратиться за бесплатной лицензией:
Гипер-конвергированная конфигурация (поддержка нескольких гипервизоров)
Разделение вычислительных ресурсов и хранилища
Хранилище, ориентированное на виртуальные машины (LSFS)
Локальный кеш
Отказоустойчивость и высокая доступность
Вертикальное и горизонтальное масштабирование
Гибкие требования к аппаратному обеспечению
Асинхронная репликация
Снапшоты и межузловая мультиуровневость хранения
Дедупликация и сжатие
Виртуальная ленточная библиотека (VTL)
Более подробно о возможностях продукта можно прочитать вот тут.
Для запроса бесплатной лицензии Virtual SAN for Hyper-V обратитесь в компанию StarWind через форму контакта.
Таги: StarWind, Virtual SAN, Бесплатно, MCP, MVP, Microsoft, Обучение
Многие пользователи VMware Virtual SAN (VSAN), когда проводят тест бэкапа одной виртуальной машины, замечают, что время резервного копирования этой ВМ существенно больше, чем таковое для машины, размещенной на дисковом массиве.
Дункан в своем блоге подробно разбирает эту проблему. Тут дело вот в чем - когда вы используете дисковый массив, то виртуальная машина "размазывается" по дискам RAID-группы, что позволяет читать одновременно с нескольких дисков. Это дает хорошую производительность операции резервного копирования для одной машины.
Кластер же VSAN работает немного по-другому. Это объектное хранилище, в котором виртуальный диск ВМ хранится на одном хосте и его реплика существует на втором. Кроме этого, есть кэш на SSD-диске (но его еще нужно "прогреть"). То есть выглядит все это следующим образом:
Соответственно, при бэкапе одной виртуальной машины данные читаются только с двух HDD-дисков, а не с нескольких как в традиционной архитектуре дисковых массивов, при этом сам кластер VSAN может состоять из нескольких хостов (до 32 узлов). То есть, это архитектурное ограничение.
Однако если мы будем делать одновременный бэкап нескольких виртуальных машин с хранилища Virtual SAN время этой операции уже будет сравнимо с дисковым массивом, поскольку будет задействовано сразу несколько дисков на каждом из хостов, плюс хорошо прогреется кэш. Поэтому проведение такого теста (ведь он ближе к реальным условиям) и было бы более показательным при сравнении Virtual SAN и традиционных хранилищ.
То же самое относится и к VDI-инфраструктуре на базе VSAN - многие пользователи отмечают, что первая фаза операции Recompose (когда создается реплика - полный клон ВМ) отрабатывает весьма медленно. Однако если вы делаете много таких операций - кэш прогревается, и одновременное создание нескольких клонов начинает работать заметно быстрее в расчете на одну машину.
Компания StarWind, поставщик ПО номер 1 для создания отказоустойчивых кластеров хранилищ в инфраструктурах VMware vSphere и Microsoft Hyper-V (о возможностях продукта - тут), спешит анонсировать свои ноябрьские вебинары.
Многие из вас знают решение номер один для создания программных отказоустойчивых кластеров хранилищ StarWind Vurtial SAN и успешно его применяют в производственной среде своего предприятия.
Продукт StarWind Virtual SAN уже многие годы на рынке, работает как часы и спасает данные многих тысяч пользователей - поэтому он заслуживает, чтобы его оценили по достоинству.
Напомним основные возможности StarWind Virtual:
Высокая доступность с синхронным зеркалированием: 3-узловой кластер высокой доступности
Автоматическое преодоление отказа
Восстановление с быстрой синхронизацией
Непрерывная защита данных и мгновенные снимки
Асинхронная репликация по WAN (ускоренная): конфигурация N+1
Значительно снизить капитальные и операционные затраты на создание инфраструктуры хранилищ для виртуальных машин, а также снизить стоимость владения виртуальной инфраструктурой (TCO) с помощью StarWind Native SAN for Hyper-V.
Увеличить производительность хранилищ без покупки дополнительного "железа".
Масштабировать объем хранилища по мере роста требований к объему данных.
Убедиться, что доступность вашей подсистемы хранения составляет 99.9999% без вложения миллионов.
Скачать пробную версию StarWind Virtual SAN можно по этой ссылке.
Не секрет, что на рынке для создания отказоустойчивых программных хранилищ для виртуальных машин есть два лидера - это StarWind Virtual SAN (о котором мы часто пишем) и VMware Virtual SAN (продукт компании VMware для своей платформы vSphere).
В таблице ниже мы решили показать, почему StarWind Virtual SAN во многом лучше VMware Virtual SAN, рассмотрев значимые для администраторов технические критерии выбора продукта. Конечно же, это не все критерии и по каким-то параметрам Virtual SAN от VMware будет работать лучше, кроме того продукты представляют собой различные архитектуры построения отказоустойчивых кластеров, но тем не менее в каком-то ракурсе сравнить их все-таки можно.
Итак:
Критерий сравнения
StarWind Virtual SAN
VMware Virtual SAN
Минимальное число узлов кластера
2
3
Максимальное число узлов
Не ограничено (разные кластеры)
32 (один кластер)
Максимальная емкость кластеров
Не ограничена (разные кластеры)
148 ТБ (один кластер)
Наличие Flash-накопителей (SSD)
Не требуется
Обязательно
Тип RAID
Любой
Только 5, 10
Наличие коммутатора 10G
Не обязательно
Обязательно
Технология дедупликации
Встроенная (in-line)
Отсутствует
Поддержка создания кластеров хранилищ для ВМ Hyper-V
Да
Нет
Кэш
В памяти (WB or WT) или Flash cache
Только Flash cache
Более подробно о новых возможностях восьмой версии StarWind Virtual SAN можно узнать вот тут, а тут доступен документ со сравнением платного и бесплатного изданий продукта.
Таги: StarWind, Virtual SAN, Сравнение, VMware, vSphere, Storage, HA, iSCSI
Компания StarWind, поставщик ПО номер 1 для создания отказоустойчивых кластеров хранилищ в инфраструктурах VMware vSphere и Microsoft Hyper-V (о возможностях продукта - тут), в ближайшее время проведет два интересных вебинара:
На совместном с компанией Veeam вебинаре Макс Коломейцев от имени StarWind расскажет, как с помощью продуктов StarWind Virtual SAN для отказоустойчивой конфигурации хранилищ и Veeam Backup and Replication для резервного копирования достичь высоких показателей RTO и RPO в вашей виртуальной инфраструктуре. Вебинар для тех, кто давно хочет понять, как эти два продукта уживаются вместе, и какой позитивный эффект они дают.
Бесплатный вебинар пройдет 30 сентября в 22-00 по московскому времени. Как раз после ужина. Регистрируйтесь!
Вебинар пройдет 1 октября также в 22-00 по московскому времени.
На этом вебинаре Макс Коломейцев расскажет про развертывание и настройку кластеров серверов и хранилищ на базе платформы Microsoft Hyper-V и продукта StarWind Virtual SAN (а также про отсутствие необходимости приобретать дополнительное железо и ПО). Напомню, что Макс является продакт-менеджером Virtual SAN, а значит знает о нем абсолютно все. Регистрируйтесь и спрашивайте!
Мы часто пишем о продукте StarWind Virtual SAN, который позволяет построить надежные отказоустойчивые кластеры хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V на основе технологии iSCSI (подробнее - тут).
Недавно компания StarWind сделала заманчивое предложение для пользователей: при покупке или апгрейде решения Virtual SAN до конца сентября вы можете выбрать один из двух бонусов - скидку 20% или бесплатный дополнительный год технической поддержки и обновлений ASM (Annual Support & Maintenance). Напомним, что 1 год поддержки уже включен в стоимость продукта.
Предложение действует в случае, если вы до конца сентября:
Покупаете любое издание продукта StarWind Virtual SAN.
Обновляетесь на издание с большей емкостью кластера хранилищ (Capacity tier upgrade).
Компания VMware выпустила интересный документ "Microsoft Exchange Server Performance on VMware Virtual SAN", в котором рассматривается случай тестирования нагрузки виртуальных серверов Microsoft Exchange размещенных в кластере Virtual SAN и работающих на серверах VMware ESXi.
В VMware использовали конфигурацию кластера VSAN из пяти узлов (Dell PowerEdge R720xd с процессорами Intel Xeon Processors E5-2650 и 128 ГБ памяти в каждом), на одном из узлов была машина с контроллером Active Directory, а для генерации нагрузки использовался отдельный клиент:
Детальная конфигурация стенда:
В качестве программной платформы использовался Exchange Server 2010, установленный в ОС Windows Server 2008 R2. На каждом хосте было размещено две виртуальных машины с Exchange - роли Mailbox и HUB.
С помощью Exchange Load Generator была сгенерирована нагрузка пользователей отсылающих и получающих письма. Для теста взяли 12 000, 16 000 и 20 000 пользователей с профилем нагрузки 150 отправляемых писем в день. Каждый почтовый ящик был инициализирован в размере 100 МБ.
При тестах Sendmail на указанном количестве пользователей выведен средний результат выполнения операций (Avg) и результат, уложившийся в 95 процентов опытов (95% latency).
Поскольку принято считать, что Latency до 500 миллисекунд для Exchange считается нормальной при отправке писем - то результаты тестов показывают, что такая конфигурация вполне жизнеспособна на десятках тысяч пользователей.
Больше подробностей можно узнать непосредственно из документа.
Не так давно мы писали про обновления портала vmwarewalkthroughs.com, на котором можно в интерактивном режиме пройти по шагам конфигурации различных продуктов в интерфейсе соответствующего решения.
После проведения конференции VMware VMworld 2014 этот портал был достаточно сильно обновлен, там появилось несколько новых демок, улучшилась категоризация обучающих материалов, ну и он стал называться VMware Feature Walkthrough, переехав на новый адрес: http://featurewalkthrough.vmware.com.
Теперь там симпатичный интерфейс и удобная навигация + много новых демонстраций, которые были сформированы из проведенных лабораторных работ HoL (hands-on-labs) на VMworld 2014:
Эти демы продуктов примечательны тем, что там вам предлагают пошагово пройти некоторый рабочий процесс прямо в интерфейсе соответствующего решения с подсветкой нужных элементов настройки:
Когда наиграетесь с демами, можно переходить на новый уровень - практические задания Hands-on-Labs, на которых уже будет сформулирована задача, а вам будет необходимо ее решить в соответствующей консоли. Сделать это можно также на отдельном портале http://hol.vmware.com/.
Компания StarWind Software, производитель средства номер один для создания отказоустойчивых кластеров StarWind Virtual SAN, недавно обновила свою библиотеку открытых документов, касающихся технических аспектов решения.
Также рекомендую заглянуть в раздел Technical Papers, где для новичков будет очень полезен Quick Start Guide по StarWind Virtual SAN. Все качается по прямым ссылкам и без регистрации.
Компания VMware выпустила интересный и полезный документ в виде таблицы - Virtual SAN 5.5 Validation Guide. Он позволяет решать проблемы, возникшие в кластерах хранилищ VSAN, как на стадии пре-инсталляции, так и после развертывания решения.
Изначально эту таблицу использовали сотрудники технической поддержки VMware для решения проблем, возникающих в среде Virtual SAN, но потом его было решено выпустить публично в целях стимуляции самоподдержки пользователей.
Документ составлен техническими специалистами VMware для своих нужд, поэтому там так предельно много конкретики, что очень полезно администраторам VMware vSphere в повседневной работе.
В первой части рассматриваются засады, которые может получить пользователь при развертывании кластера Virtual SAN, в во второй уже приводятся ситуации, которые могут возникнуть после инсталляции и в процессе эксплуатации решения.
При этом (где это возможно) приводятся шаги vCenter Web Client или сценарии CLI (RVC, ESXCLI, PowerCLI), которые позволят идентифицировать и ликвидировать проблему. Документ живет и постоянно обновляется, поэтому можно периодически заглядывать - не обновилась ли его версия (сейчас это 2.1).
Также очень рекомендуют в целях траблшутинга обращаться к инструменту vSphere Ruby Console (RVC), который позволяет автоматизировать множество задач. Полезные ссылки:
На днях компания VMware выпустила долгожданный онлайн-сервис Virtual SAN Sizing Tool, который позволяет оценить необходимые аппаратные мощности, требующиеся для поддержания инфраструктуры хранилищ VSAN на базе локальных дисков серверов VMware ESXi.
В качестве исходных данных утилиты принимается конфигурация типовой виртуальной машины:
а также типовая аппаратная конфигурация хост-сервера ESXi:
Для виртуальных машин вам могут показаться непонятными параметры "Number of failures to tolerate" и "Number of disk stripes per object" - о них мы писали вот в этой статье.
В качестве результата расчетов будет выведена следующая информация:
Число хостов заданной конфигурации, необходимых для поддержания инфраструктуры VSAN.
Размер SSD-диска для дисковой группы HDD на хосте.
Максимумы по числу компонентов в кластере (машины, диски).
Полезная емкость кластера (зависит также от параметра FTT).
Емкость кластера по оперативной памяти.
Кроме того, дается брейкдаун по использованию дисковых емкостей, а также объем оперативной памяти под нужды Virtual SAN на хостах:
При расчетах используются следующие допущения:
Все хосты кластера имеют одинаковый аппаратный профиль, включая число HDD и SSD-дисков, объем памяти и количество ядер CPU.
Предполагается, что у всех виртуальных машин одинаковые требования к хранилищу: как по дисковой емкости и числу дисков, так и по нагрузке на СХД.
Предполагается, что у всех виртуальных машин одинаковая VSAN Policy, то есть параметры FTT и disk stripes per object.
Никаких кнопок для начала расчета нажимать не нужно - данные формируются "на лету". Приступить к работе с VMware Virtual SAN Sizing Tool можно по этой ссылке.
Компания StarWind объявляет о начале интересной акции. Как вы знаете решение номер 1 на рынке для создания программных iSCSI-хранилищ StarWind Virtual SAN лицензируется на определенную емкость в рамках отказоустойчивого кластера. Так вот, только до 31 августа, сделав апгрейд любого издания StarWind Virtual SAN на издание с большей емкостью хранения, вы получаете бесплатно 1 год технической поддержки и обновлений продукта (ASM, Annual Support & Maintenance).
Это включает в себя поддержку по email и телефону, а также все обновления, которые выходят к продукту.
Напомним основные возможности продукта StarWind Virtual SAN:
Отказоустойчивость узлов типа Active-Active.
Возможность создания двух или трехузловой конфигурации кластера хранилищ.
Некоторое время назад компания VMware выпустила интересный документ "Understanding Data Locality in VMware Virtual SAN", касающийся локальности данных, то есть механизмов соблюдения временных и пространственных характеристик правильного чтения данных в целях оптимизации производительности кластера хранилищ Virtual SAN.
Мысль тут такая: локальность данных бывает двух типов:
временная (Temporal locality) - это когда есть вероятность, что данные, использованные сейчас, потребуются снова в ближайшее время (это актуально, поскольку в инфраструктуре виртуализации несколько машин на хосте часто используют одни и те же данные).
пространственная (Spatial locality) - ситуация, когда есть вероятность, что после чтения некоторой области данных потребуется прочитать и данные находящиеся рядом - то есть в соседних блоках на хранилище.
Так вот, в документе подробно разбирается, каким именно образом обеспечивается работа с этими особенностями локальности данных применительно к кэшированию данных на хранилищах SSD хостов VMware ESXi.
Примерами работы с локальностью данных являются следующие особенности кластеров Virtual SAN:
Каждый раз, когда виртуальная машина читает данные с хранилища, они сохраняются в кэше (Read Cache) на SSD-накопителе и эти данные могут быть востребованы очень быстро. Это работа с Temporal locality.
С точки зрения Spatial locality, при кэшировании данных в кэш сохраняется также и "окрестность" этих данных в рамках чанков по 1 МБ.
Virtual SAN имеет адаптивный алгоритм по вытеснению и сохранению данных в кэше - если данные используются редко, они выпадают с SSD-накопителя, а часто востребованные данные будут находиться там постоянно.
Virtual SAN распределяет экземпляры данных по разным хост-серверам ESXi и работает при чтении сразу с несколькими узлами, но при чтении одного диапазона логических адресов работа идет только с одной репликой. Обусловлено это двумя фактораи: во-первых, увеличивается шанс того, что читаемые данные уже находятся в кэше на SSD, а значит будут прочитаны быстрее, ну и, во-вторых, один блок данных всегда будет закэширован только на одном узле, а значит дорогое SSD-пространство не будет пожираться дубликатами блоков.
В общем документ очень интересный - почитайте. Там еще много полезной информации на эту тему.
Вебинар будет посвящен интересному вопросу: как использовать вычислительные ресурсы и хранилища для виртуальных машин - держать их вместе (как это делается с помощью StarWind Virtual SAN для платформы Hyper-V) или раздельно (классическая архитектура хост-серверов и отдельно программных или аппаратных хранилищ).
Очевидно, что первый вариант дешевле и выгодней, так как используется меньше хост-серверов, а на них одновременно создаются отказоустойчивые кластеры как для вычислительных мощностей (ВМ), так и для хранилищ (виртуальные диски). Но может быть здесь есть какие-то подводные камни? Приходите на вебинар и спросите!
На мероприятии будут рассмотрены следующие вопросы:
Обзор рынка решений для создания программных хранилищ.
Неприятности, которые несет собой традиционная архитектура аппаратных СХД.
Обзор решений распределенных хранилищ с функциями отказо- и катастрофоустойчивости.
Рассмотрение масштабируемых архитектур хранения, в том числе сугубо на базе программных решений.
Вебинар пройдет 20 августа в 22-00 по московскому времени.
В этом посте мы сравним дисковые массивы DotHill 3730 и NetApp 5412. Сравнение и тестирование проводилось с целью определить целесообразность смены систем хранения данных DotHill на СХД NetApp. Один из заказчиков ИТ-ГРАД много лет использовал дисковые массивы DotHill 3730 для хранения всякого нужного, но пришло время их менять. Не то чтобы они были плохие, просто за несколько лет эксплуатации накопились обиды...
Те из вас, кто еще застал VMware ESX 2.x-3.x, наверняка помнят, что в VMware vSphere несколько лет назад иногда возникала проблема некорректного выравнивания блоков на двух уровнях - гостевой ОС по одношению к VMFS и VMFS по отношению к блокам дискового массива (подробнее здесь и здесь):
В такой ситуации смещения блоков на разных уровнях (гостевая ОС, VMFS, дисковый массив) чтение одного кластера в ОС виртуальной машины потенциально могло привести к чтению сразу трех чанков дискового массива.
Были даже специальные утилиты (о них мы писали тут и тут), которые занимались этой проблемой и позволяли получить вот такую правильную картинку, где чтение одного кластера в гостевой ОС приводило к чтению только одного чанка дискового массива.
Выравнивание на стороне файловой системы VMFS было реализовано еще в VMFS-3 (для vSphere 3.x и 4.x), где стартовый Logical Block Address (LBA) выставлялся в значение 128, а в VMFS-5 (начиная с vSphere 5.x) выравнивается по LBA 2048.
Корректное выравнивание в гостевых ОС Windows было также реализовано достаточно давно, начиная с Windows Server 2008 и Windows Vista (естественно, и в версиях 7/8 тоже), начало партиций уже выровнено как положено.
Как же дела обстоят с хранилищами VMware Virtual SAN, которые не используют VMFS?
Тут надо понимать два момента:
1. Virtual SAN использует свое собственное нативное хранилище объектов, и не использует VMFS, поэтому проблем VMFS<->хранилище и VMFS<->гостевая ОС не существует.
2. Проблема гостевая ОС<->хранилище потенциально может существовать для старых ОС (например, Windows Server 2003), однако даже в этом случае она будет мало влиять на производительность.
И вот почему проблема выравнивания блоков в среде VMware VSAN является надуманной:
1. Все операции записи идут через SSD-накопитель как буфер, где они складываются в пачки и только потом идут на HDD, соответственно, импакта тут нет.
2. Операции чтения также обслуживаются кэшем на SSD (vFRC), поэтому тут тоже почти не будет потерь производительности в невыровненной конфигурации.
Поэтому, вывод один - не заморачивайтесь проблемой выравнивания блоков в среде VMware Virtual SAN.
Не так давно мы писали про документ "VMware Virtual SAN Ready Nodes", в котором приведены примеры серверных конфигураций от различных производителей, подходящих в качестве готовых узлов отказоустойчивого кластера хранилищ VMware Virtual SAN.
На прошлой неделе компания VMware провела обещанное обновление этого документа, добавив туда новые серверные системы от Cisco (4 спецификации) и Hitachi (1 спецификация). Таким образом, теперь в документе есть 29 вариантов конфигураций для следующих вендоров серверного оборудования:
Dell (3 узла)
Fujitsu (5 узлов)
HP (10 узлов)
SuperMicro (6 узлов)
Cisco (4 узла)
Hitachi (1 узел)
Напомним, что к каждой спецификации на сервер прилагается профиль нагрузки, для которой предлагается его использовать, например, VDI-инфраструктура с числом виртуальных ПК до 100 или серверная инфраструктура на 60 ВМ. Также прилагается примерная конфигурация виртуальной машины, например: Virtual Machine Profle: 2 vCPU, 6 GB Memory, 2 x 60 GB virtual disks.
Кроме того, были сделаны следующие добавления:
Для серверов Dell указаны партномера (DellStar Solution IDs - только штаты), работа над партномерами для других вендоров - в процессе. Для большинства узлов будет единый SKU для всех вендоров.
Сбалансировано количество дисков для конфигураций с несколькими дисковыми группами.
Для всех узлов (кроме Hitachi) была добавлена USB/SD card, с которой можно грузить ESXi.
Пока нет SKU для данных узлов, вы можете просто присылать документ "VMware Virtual SAN Ready Nodes" вендору и говорить что-то в стиле "хочу такую штучку".
Прямо сейчас в Вашингтоне (D.C.) проходит традиционная ежегодная конференция для партнеров Microsoft Worldwide Partner Conference 2014. Если вы в данный момент там находитесь, не забудьте зайти на стенд #2320 компании StarWind Software, чтобы пообщаться с нашими коллегами, которые представляют решение для создания программных отказоустойчивых хранилищ StarWind Virtual SAN (о возможностях решения мы писали тут).
Кроме того, напомним, что StarWind будет обязательно представлять свои продукты на главном событии года, посвященном виртуализации - VMware VMworld 2014, которое пройдет в Сан-Франциско c 24 по 28 августа. Заходите к нашим ребятам на стойку #401.
RSS
