Как вы знаете, у главного производителя средств для создания программных отказоустойчивых хранилищ под виртуализацию, компании StarWind, есть бесплатное издание флагманского продукта StarWind Virtual SAN Free.
Этот документ поможет вам понять, чем именно бесплатный StarWind Virtual SAN может вам пригодиться в инфраструктуре небольшого предприятия или филиала.
Напомним, что отличия платной и бесплатной версии решения приведены вот в этом документе:
Некоторые из вас знают, что для поиска и решения проблем в виртуальной инфраструктуры, среди прочих интерфейсов командной строки, есть такой инструмент, как Ruby vSphere Console (RVC).
Используется она достаточно редко, но ниже мы покажем пример ее использования на базе вот этой заметки от Кормака Хогана.
Чтобы запустить Ruby vSphere Console, нужно набрать в командной строке ESXi команду в следующем формате:
rvc [options] [username[:password]@]hostname
Например:
# rvc administrator:vmware@192.168.1.100
После этого появится приглашение ко вводу различных команд:
login as: root
VMware vCenter Server Appliance
administrator@192.168.1.100's password:
Last login: Thu Jul 17 22:29:15 UTC 2014 from 10.113.230.172 on ssh
Last failed login: Fri Jul 18 06:31:16 UTC 2014 from 192.168.1.20 on ssh:notty
There was 1 failed login attempt since the last successful login.
Last login: Fri Jul 18 06:31:35 2014 from 192.168.1.20
vcsa:~ # rvc administrator:vmware@192.168.1.100
0 /
1 192.168.1.100/
Их можно выполнять в рамках следующих пространств имен (namespaces):
Во второй снизу строчке мы видим пространство имен VSAN, относящееся к кластерам хранилищ Virtual SAN. Давайте посмотрим на решение одной проблемки с его помощью.
Допустим, вы увидели в кластере VSAN следующую ошибку в разделе Component Metadata Health:
Invalid state
Согласно вот этой статье KB 2108690, эта ошибка может относиться к физической проблеме с диском - когда процесс выделения физических блоков при сбрасывании их из кэша на диск идет очень медленно. Эта ошибка может свидетельствовать просто о высокой нагрузке на диск, в этом случае она уходит при спаде нагрузки. Но если она повторяется при малой нагрузке - значит с диском явно что-то не так.
В столбце "Component" указан component UUID диска, с которым возникла проблема - но как узнать, на каком хранилище он расположен, в консоли vSphere Web Client? Для этого мы и возьмем Ruby vSphere Console, а именно команду vsan.cmmds_find:
Компания VMware на днях выпустила множество обновлений своей продуктовой линейки в сфере серверной виртуализации. Прежде всего, важно, что было выпущено обновление VMware Virtual SAN 6.2, о котором мы подробно писали вот тут. Теперь его можно скачать и использовать в производственной среде.
Также для того, чтобы была обеспечена полная поддержка новых возможностей VSAN 6.2 была выпущена обновленная версия платформы виртуализации VMware vSphere 6.0 Update 2. Но самое главное там - это то, что теперь VMware Host Client (который вы знаете как ESXi Embedded Host Client) включен в стандартную поставку ESXi и доступен из коробки!
Напомним также, что о прошлом апдейте vSphere 6 Update 1, который вышел почти полгода назад, мы писали вот тут.
Посмотрим на новые возможности vSphere 6.0 Update 2. Что нового в ESXi 6.0 Update 2:
High Ethernet Link Speed: теперь ESXi 6.0 U2 поддерживает скорости ethernet-соединения 25G и 50G.
VMware Host Client: новый HTML5-клиент для управления одиночным хостом VMware ESXi, о последних версиях которого в виде VMware Fling мы писали вот тут, тут и тут. Это средство для выполнения основных административных задач, управления ресурсами и виртуальными машинами. Также Host Client подходит для поиска и решения проблем, возникших на отдельных хостах VMware ESXi, когда, например, vCenter Server или Web Client недоступны. Смотрите также Host Client 1.0 Release Notes.
vSphere APIs for I/O Filtering (VAIO): ESXi 6.0 Update 2 теперь поддерживает компонент IO Filter VASA Provider в полноценном IPv6-окружении.
Поддержка VMIOF версий 1.0 и 1.1, а также множество исправлений ошибок.
Поддержка двухфакторной аутентификации в vSphere Web Client средствами следующих технологий:
RSA SecurID
Смарт-карты (UPN based Common Access Card)
Поддержка изменения уровня логгирования vSphere ESX Agent Manager без его перезагрузки.
Поддержка vSphere Web Cient для Microsoft Windows 10.
Поддержка новых версий в качестве внешних СУБД VMware vCenter:
Microsoft SQL Server 2012 Service Pack 3
Microsoft SQL Server 2014 Service Pack 1
Помимо всего этого, в последнее время компания VMware выпустила также обновления следующих своих продуктов (о новых возможностях вы можете узнать из соответствующих Release Notes):
Среди возможностей решения для создания отказоустойчивых хранилищ VMware Virtual SAN 6.2 мы забыли упомянуть о нововведении в части обработки файлов подкачки - Sparse Swap.
Как вы знаете при создании виртуальной машины в обычной инфраструктуре под нее резервируется файл *.vswp, который равен по размеру объему сконфигурированной оперативной памяти виртуальной машины (либо объему незарезервированной памяти, то есть разнице между сконфигурированной и зарезервированной памятью, если она указана в настройке reservation). Это нужно на случай, когда машине не хватает свободной физической памяти (в ситуации, если уже не спасают техники memory overcommit), и она начинает сбрасывать страницы памяти в своп-файл на диске.
То есть, если вы создали ВМ с оперативной памятью 4 ГБ, то столько же займет и файл подкачки для этой ВМ. А теперь посмотрим на инфраструктуру Virtual SAN: если у вас задан параметр FTT=1, то каждый дисковый объект (в том числе и файл *.vswp) будет задублирован (если у вас mirror-конфигурация).
Теперь посчитаем, сколько места съест своп 100 виртуальных машин, у каждой из которых 4 ГБ оперативной памяти и которые размещены в кластере VMware Virtual SAN с FTT=1 в зеркальной конфигурации:
100 ВМ * 4 ГБ * 2 (FTT равен 1) = 800 ГБ
Да, именно так - почти терабайт только под своп. Кому-то это покажется расточительством, поэтому в Virtual SAN сделали такую штуку, как Sparse Swap. Эта функция позволяет создавать файлы подкачки vswp как тонкие, то есть растущие по мере наполнения данными, диски.
Для того, чтобы включить опцию Sparse Swap, нужно выполнить следующую команду на хосте VMware ESXi:
На сайте проекта VMware Labs появилась интересная и полезная утилита для тех, кому нужно проверить совместимость контроллеров хранилищ на хостах VMware ESXi со списком поддерживаемых устройств в кластере VMware Virtual SAN. C помощью VSAN Hardware Compatibility List Checker можно проверить модель и версию firmaware контроллеров LSI и HP, а также их различных OEM-вариаций.
Утилита поставляется в виде exe-файла, который находится в папке с архивом:
Для начала работы нужно просто ввести имя хоста ESXi и пароль пользователя root:
В качестве результата в папке с утилитой будет сформирован html-файл (этот шаблон можно редактировать в файле reportTemplate.html), в котором будет информация о совместимости контроллеров хранилищ со списком VSAN HCL (шильдики yes и N/A).
Некоторые нюансы работы утилиты:
Обнаружение версии firmware доступно только для контроллеров HP/LSI.
Необходимо, чтобы был установлен компонент LSI/HP CIM provider.
Требуется запущенная служба CIM Service (secure) на хосте ESXi на порту 5989.
Нужен доступ к хостам ESXi по протоколу HTTPS, по порту 443.
Интересно, что утилита VSAN Hardware Compatibility List Checker работает не только с последней версией Virtual SAN, но и с более ранними версиями. Скачать HCL Checker можно по этой ссылке.
Дата и время мероприятия: 15 марта 22-00 по московскому времени. Со стороны StarWind вебинар проводит Максим Коломейцев, поэтому вы сможете задавать вопросы на русском языке.
На вебинаре будут рассмотрены вопросы построения недорогой инфраструктуры из двух или более хост-серверов виртуализации Hyper-V, в которой обеспечивается отказоустойчивость на уровне хранилищ средствами продукта StarWind Virtual SAN, а управление реализуется средствами 5nine Manager. Помимо этого будет рассмотрен и экономический аспект экономии денежных средств при внедрении упомянутых решений.
Многие из вас знают блоггера Дункана Эппинга, который уже многие годы пишет о технических аспектах платформы виртуализации VMware vSphere, особенно фокусируясь на вопросах доступности виртуальных машин (механизм VMware HA) и кластеризации хранилищ Virtual SAN. В целом-то, на сегодняшний день это главный эксперт по VMware HA. Так вот, Дункан решил сделать полностью бесплатным свое техническое руководство по VMware HA "vSphere 6.x HA Deepdive", которое доступно онлайн на GitBook.
Особенно большой интерес представляют пункты про работу механизма VMware HA Admission Control (мы писали об этом тут), а также описание расширенных настроек (HA Advanced Settings).
Таги: VMware, vSphere, HA, Book, Бесплатно, Virtual SAN
Мы довольно часто пишем о технологии VMware VVols, которая позволяет организовывать виртуальные хранилища наиболее оптимально с точки зрения управления и производительности без файловой системы VMFS. Сегодня мы обсудим, как узнать, поддерживает ли ваш адаптер ввода-вывода технологию VMware VVols.
Начнем с того, почему адаптер и хранилище вообще должны ее поддерживать. Все просто - для доступа к томам VVols используется специальный служебный LUN, реализуемый в виде Protocol Endpoint (PE). Когда обычный FC-адаптер соединяется с хранилищем VMFS, он использует путь к LUN на базе адресов WWN, который состоит из номера HBA-адаптера, номера контроллера и, конечно же, LUN ID. Это все выглядит как vmhbaAdapter:CChannel:TTarget:LLUN (например, vmhba1:C0:T3:L1).
В случае с VVols и луном PE это уже работает несколько по-другому: появляются так называемые Secondary LUN IDs, которые адресуются как саблуны девайсом PE (secondary level IDs, SLLID). Этот Administrative LUN на устройстве PE не имеет емкости, но адресует тома VVols, которые находятся уже непосредственно на хранилище.
Сервер vCenter получает эти Secondary LUN IDs через механизм VASA Provider, реализованный через одноименный API. Далее уже хост ESXi (а точнее его I/O-адаптер, например, HBA-адаптер) работает в виртуальными машинами (а вернее с томами VVols) через Secondary LUN IDs (их, кстати, может быть не 255 как у LUN ID, а намного больше).
Надо отметить, что средства резервного копирования на уровне LUN не могут напрямую обратиться к этим Secondary LUN IDs, так как работа с ними идет только через хост VMware ESXi.
Так вот стандартная SCSI-команда REPORT_LUNS не подходит для обнаружения административных LUN, которые в отличие от LUN с данными, не имеют емкости. Поэтому VMware подала предложения в комитет T-10, отвечающий за SCSI-протокол, чтобы внести в его спецификацию некоторые изменения:
Самый простой способ узнать, поддерживает ли ваш FC/NFS-адаптер адресацию Secondary LUN IDs - это пойти в список совместимости VMware HCL:
В списке Features вы должны увидеть пункт Secondary LUNID (Enables VVols). Выберите его и посмотрите результат:
Тут уже видна подробная информация о драйвере и фича SLLID.
Далее можно заглянуть в ваш vmkernel.log и посмотреть нет ли там следующих строчек:
Sanity check failed for path vmhbaX:Y:Z. The path is to a VVol PE, but it goes out of adapter vmhbaX which is not PE capable. Path dropped.
Если есть - понятное дело, VVols не поддерживаются. Ну а в консоли сервера VMware ESXi параметры HBA-адаптера можно проверить следующей командой:
esxcli storage core adapter list
В колонке Capabilities будет видна строчка Second Level Lun ID, если поддержка VVols у вашего адаптера есть:
На стороне хранилища вам нужно убедиться, что VASA Provider включен и поддержка фич PE для VVols функционирует. Далее выполните следующую команду, чтобы убедиться, что хост ESXi видит девайс PE (обратите внимание, что он видится как диск):
esxcli storage core device list –pe-only
Если вы видите в строчке Is VVOL PE значение true, то значит все ок, и вы можете развертывать виртуальные машины на базе томов VVols.
Вебинар пройдет 3 марта в 16-00 по московскому времени. Проводит его Влад Караев, поэтому вы сможете задавать вопросы на русском языке.
Мероприятие будет особенно полезно администраторам небольших инфраструктур или филиалов, где под виртуализацию и хранение виртуальных машин сложно выбить у начальства даже 2 сервера. На минимальной конфигурации из двух серверов Влад покажет, каким образом можно построить надежную отказоустойчивую архитектуру хранения и исполнения виртуальных машин на платформе Microsoft Hyper-V с помощью решения StarWind Virtual SAN.
Продолжаем рассказывать о технологиях компании StarWind, являющейся лидером в сфере решений для создания отказоустойчивых хранилищ под виртуальные машины на платформах VMware vSphere и Microsoft Hyper-V. Оказывается, прямо сейчас вы можете протестировать технологию VMware VVols совместно с решением StarWind Virtual SAN.
Для этого у компании StarWind есть специальный документ "StarWind Virtual SAN VVOLs Technical Preview Guide", рассказывающий о том, как попробовать виртуальные тома VVols для vSphere в режиме технологического превью в рамках тестовой инфраструктуры из одного хост-сервера.
Для тестирования нужно использовать виртуальный модуль StarWind VSA, который развертывается как виртуальная машина в формате OVF.
Для развертывания тестового стенда вам потребуется один сервер VMware ESXi 6.0 под управлением vCenter 6 в следующей минимальной конфигурации:
8 ГБ RAM
2GHz+ 64-bit x86 Dual Core CPU
2 vCPU, 4 ГБ RAM и 50 ГБ хранилища для машины StarWind
Компания VMware, оказывается, имеет интересный инструмент для расчета стоимости владения инфраструктурой хранения на базе локальных серверов VMware Virtual SAN TCO and Sizing Calculator. Понятно, что инструмент это больше маркетинговый, чем приложимый к реальному миру, но давайте все же взглянем на него. Напомним, кстати, также, что недавно была анонсирована новая версия VMware Virtual SAN 6.2.
Первое, что нам нужно ввести - это основные параметры инфраструктуры (можно выбрать между серверной виртуализацией и виртуализацией настольных ПК). Сначала нужно указать число виртуальных машин и число ВМ на сервер VMware ESXi. Далее можно использовать один для всех профиль виртуальной машины, а можно добавить несколько:
Если вы не знаете, что такое FTT (Failures to tolerates) - загляните вот в эту нашу заметку.
Далее мы вычисляем требуемую полезную емкость, необходимую для размещения виртуальных машин в кластерах Virtual SAN с учетом требуемого уровня отказоустойчивости:
Затем мы переходим к кастомизации так называемой "Ready Node" (об этом мы писали вот тут). Это типовой серверный узел, который будет исполнять как виртуальные машины, так и хранить их на своих локальных дисках.
Также в самом начале нужно задать "Performance profile", то есть типовую предполагаемую конфигурацию хранилища/производительности дисков для узла Virtual SAN. Внизу будет выведена примерная стоимость инфраструктуры хранения:
Кстати, у VMware есть инструмент Virtual SAN Ready Node Configurator, который поможет определиться с точной конфигурацией узла и создать спецификацию на него с учетом производителя серверов, которые вы обычно закупаете для своей инфраструктуры.
Ну а далее мы получаем overview из параметров, которыми будет обладать ваша виртуальная инфраструктура:
Ниже вы увидите распределение дискового пространства по VMDK-дискам, их репликам и прочим вспомогательным компонентам.
Внизу вы увидите конфигурацию хостов и кластера Virtual SAN, а также обобщенную спецификацию на узел. После этого переходим к параметрам расчета стоимости владения (TCO - total cost of ownership). Это такой метод сравнения затрат, когда вы сравниваете один способ реализации хранения машин без кластера хранилищ на базе локальных дисков с инфраструктурой Virtual SAN за определенный промежуток времени (обычно 3 или 5 лет).
Вводим параметры лицензирования и его тип, а также стоимость поддержки для Virtual SAN. Ниже вводим параметры текущей серверной конфигурации без VSAN:
Далее нам показывают "экономию" на трудозатратах (операционные издержки), а также на электропитании и охлаждении:
Ну а в конце приводится сводная таблица по капитальным и операционным затратам, полученная в сравнении использования Virtual SAN-конфигурации и развертывания традиционных дисковых массивов. Обратите внимание, что даже в дефолтном примере капитальные затраты с VSAN существенно выше:
Ниже идут различные графики про экономию денег в различных аспектах:
И в завершение - структура издержек на владение инфраструктурой хранения c VSAN и без него:
Инструмент интересный, но бесполезный. Пользуйтесь!
В этой заметке мы рассмотрим новые возможности решения для создания отказоустойчивых хранилищ на базе хост-серверов VMware Virtual SAN 6.2. Напомним, что о прошлой версии Virtual SAN 6.1, вышедшей осенью прошлого года, мы писали вот тут.
Итак, давайте посмотрим на новые возможности VSAN 6.2:
1. Дедупликация и сжатие данных.
Теперь обе этих технологии оптимизации хранилищ используются совместно, чтобы достичь наилучших результатов по стоимости хранения данных. Сначала данные виртуальных машин дедуплицируются на уровне дисковой группы, а потом сжимаются, что позволяет уменьшить исходный размер ВМ до 7 раз, в зависимости от типов нагрузки в гостевых ОС, по сравнению с первоначальным размещением.
Каждый vmdk хранит только оригинальные дисковые блоки:
2. Технология Erasure Coding (коррекция ошибок - "RAID из узлов").
В версии Virtual SAN 6.1 если вы используете параметр failures to tolerate =1 (FTT, зеркальная избыточность), то вам нужна двойная емкость в кластере. То есть, если будет 100 ГБ под виртуальные машины, то на хостах суммарная емкость должна составлять 200 ГБ.
По аналогии с RAID5/6 и другими типами RAID с чередованием, пространство хранения Virtual SAN 6.2 представляет собой "RAID из хостов ESXi". Таким образом, можно использовать схемы 3+1 или 4+2, которые позволят иметь лишь в 1,3 раза больше физического пространства (для первой схемы), чем полезной емкости. Об этом мы уже писали вот тут.
Вот интересная таблица соответствия параметров FTT, требований к инфраструктуре хранения и получаемых емкостей при различных типах RAID из хостов VMware ESXi:
3. Регулирование Quality of Service (QoS).
Теперь на уровне виртуальных дисков VMDK доступна регулировка полосы ввода-вывода на уровне IOPS:
Эти настройки могут быть применены через механизм политик хранилищ Storage Policy-Based Management (SPBM). Скорее всего, это будет востребовано в больших облачных инфраструктурах, особенно у сервис-провайдеров, которым необходимо обеспечивать различные уровни обслуживания своим клиентам. Также это позволяет создать механизм для того, чтобы рабочие нагрузки, размещенные на одном хранилище, не влияли друг на друга в моменты наибольшей нагрузки на подсистему хранения.
4. Техника Software Checksum.
Эта техника позволяет своевременно обнаруживать сбои, относящиеся к аппаратным и программным компонентам во время операций чтения/записи. Тут выделяются 2 типа сбоев: первый - "latent sector errors", который, как правило, свидетельствует о физической неисправности носителя, и второй - "silent data corruption", который происходит без предупреждения и может быть обнаружен только путем глубокой проверки поверхности накопителя.
5. Полноценная поддержка IPv6.
Теперь Virtual SAN поддерживает не только IPv4 и IPv6, но и смешанные окружения IPv4/IPv6 (для тех случаев, когда, например, на предприятии идет процесс миграции на новую версию протоколов).
6. Сервис мониторинга производительности.
Эти службы позволяют наблюдать за производительностью кластера Virtual SAN со стороны сервера vCenter. Теперь не обязательно идти в консоль vRealize Operations, чтобы решать базовые проблемы. Теперь в плане мониторинга доступны как высокоуровневые представления (Cluster latency, throughput, IOPS), так и более гранулярные (на базе дисков, попадания в кэш, статистика для дисковой группы и т.п.).
Также предусмотрена возможность предоставления данных о производительности кластера Virtual SAN сторонним сервисам через API. Для хранения событий используется собственная распределенная база данных, не зависящая от сервисов vCenter и хранящаяся в рамках кластера.
Компания StarWind, производитель лучшего решения Virtual SAN для создания программных отказоустойчивых хранилищ под виртуализацию, объявляет интересный конкурс. Все что вам нужно сделать, это поделиться своей историей о проекте по созданию гиперконвергентной архитектуры хранилищ (hyperconverged storage architecture), то есть архитектуры, где различные средства управления средой хранения сведены воедино в едином комплексе, а его масштабироание выполняется за счет добавления новых узлов.
Напомним, что у StarWind есть также собственное решение для создания гиперконвергентной инфраструктуры на базе серверов Dell, гипервизора Microsoft Hyper-V, ПО для хранилищ StarWind Virtual SAN, резервного копирования Veeam Backup and Replication, а также средств управления 5nine Hyper-V Manager. Поставляется оно в виде готового программно-аппаратного комплекса.
Итак, участвуйте в конкурсе StarWind и выиграйте 500 баксов:
Ваши истории появятся в блоге StarWind, а вы и ваши друзья и коллеги смогут проголосовать за них. Сами истории принимаются до 15 апреля, а уже 18 апреля будет объявлен победитель, который и получит 500 долларов. Те, кто займет второе и третье места, получат призы $300 и $150 соответственно.
Какое-то время назад мы писали о функции Data Locality, которая есть в решении для создания отказоустойчивых кластеров VMware Virtual SAN. Каждый раз, когда виртуальная машина читает данные с хранилища, они сохраняются в кэше (Read Cache) на SSD-накопителе, и эти данные могут быть востребованы очень быстро. Но в рамках растянутого кластера (vSphere Stretched Cluster) с высокой скоростью доступа к данным по сети передачи данных, возможно, фича Site / Data Locality вам не понадобится. Вот по какой причине.
Если ваши виртуальные машины часто переезжают с хоста на хост ESXi, при этом сами хосты географически разнесены в рамках VSAN Fault Domains, например, по одному зданию географически, то срабатывает функция Site Locality, которая требует, чтобы кэш на чтение располагался на том же узле/сайте, что и сами дисковые объекты машины. Это отнимает время на прогрев кэша хоста ESXi на новом месте для машины, а вот в скорости в итоге особой прибавки не дает, особенно, если у вас высокоскоростное соединение для всех серверов в рамках здания.
В этом случае Site Locality лучше отключить и не прогревать кэш каждый раз при миграциях в рамкха растянутого кластера с высокой пропускной способностью сети. Сначала запросим значение Site Locality:
Компания VMware в своем блоге, посвященном продуктам линейки VMware vSphere, представила интереснейшее доказательство, что кластер VMware Virtual SAN дает надежность "шесть девяток", то есть доступность данных 99,9999% времени в году. А это меньше, чем 32 секунды простоя в год.
Бесспорно, приведенное ниже "доказательство" основано на множестве допущений, поэтому заявление о шести девятках является несколько популистским. С моей точки зрения, гораздо более вероятно, что админ с бодуна не туда нажмет, или, например, в команде vmkfstools укажет не тот LUN и снесет все виртуальные машины на томе VMFS (привет, Антон!), чем откажет оборудование с дублированием компонентов. Но все же, рассмотрим это доказательство ниже.
Прежде всего, введем 2 понятия:
AFR – Annualized Failure Rate, то есть вероятность отказа в год (носителя данных или другого компонента), выраженная в процентах.
MTBF – Mean Time Between Failures (среднее время между отказами). Это время в часах.
Эти 2 величины взаимосвязаны и выражаются одна через другую в соответствии с формулой:
AFR = 1/(MTBF/8760) * 100%
Обычно, как HDD, так и SSD накопители, имеют AFR от 0.87% до 0.44%, что дает от 1 000 000 до 2 000 000 часов MTBF. Далее для примера берут диск 10K HDD от Seagate (популярная модель ST1200MM0088), для которой AFR равен 0.44% (см. вторую страницу даташита) или 2 миллиона часов в понятии MTBF. Ну и взяли популярный SSD Intel 3710 для целей кэширования, который также имеет MTBF на 2 миллиона часов.
Для того, чтобы вычислить время доступности данных на таких накопителях, нужно понимать время, которое необходимо для восстановления бэкапа на новый накопитель в случае сбоя. По консервативным оценкам - это 24 часа. Таким образом, доступность данных будет равна:
2 000 000/ (2 000 000 + 24) = 0,99998
То есть, 4 девятки. Но диск - это еще не весь сервис. Есть еще надежность дискового контроллера, самого хост-сервера и стойки в целом (по питанию). VMware запросила данные у производителей и получила следующие параметры доступности:
Вот, доступность уже 3 девятки, что эквивалентно 8,76 часов простоя в год. Не так плохо, но это слишком оптимистичные значения - на деле есть прочие факторы, влияющие на доступность, поэтому уберем последнюю цифру из долей для доступности каждого из компонентов:
Получается 2 девятки, а это 3,65 дня простоя в год, что уже довольно критично для многих бизнесов.
Ну а теперь применим технологию VMware Virtual SAN, которая дублирует данные на уровне виртуальных машин и отдельных виртуальных дисков. Если мы используем параметр FTT (Numbers of failures to tolerate) равный 1, что подразумевает хранение одной реплики данных, то вероятность недоступности хранилища Virtual SAN данных будет равна вероятности отказа 2-х хранилищ одновременно, то есть:
(1-0.997)^2 = 0.00000528
Ну а доступность в данном случае равна:
1-0.00000528 = 0.999994
То есть, уже 5 девяток. Но это доступность для одного объекта VSAN, а отдельная виртуальная машина обычно имеет несколько объектов, допустим, 10. Тогда ее доступность будет равна:
0.999994^10 = 0.99994
В итоге, 4 девятки. Это 52,56 минуты простоя в год. В зависимости от того, сколько объектов у вас будет на одну ВМ, вы будете иметь доступность от 4 до 5 девяток.
А теперь возьмем FTT=2, то есть конфигурацию, когда имеется 2 дополнительных копии данных для каждого объекта в кластере Virtual SAN. В этом случае вероятность полного отказа всех трех копий данных:
(1-0.997)^3 = 0.00000001214
А доступность для ВМ с десятью объектами:
0.999999988^10 = 0.999999879
То есть, те самые 6 девяток, о которых говорится на слайде. Конечно, все это допущения, фантазии и игра с вероятностями, но читать это все равно интересно. Еще более интересно то, что оригинал этой статьи написала женщина)
Таги: VMware, Virtual SAN, HA, VSAN, Enterprise, Blog, Availability, Storage
Оба этих узла используются и как хост-серверы для виртуальных машин, и как узлы отказоустойчивого кластера хранилищ. Таким образом, в небольшом филиале данная конфигурация из двух хостов может поддерживать серверную инфраструктуру всего филиала. Во время вебинара будет проведена живая демонстрация процесса пошаговой настройки кластера хранилищ и серверов:
Дата и время вебинара: 28 января в 16-00 по московскому времени. Вебинар проведет Владислав Караев, а вы сможете задавать вопросы на русском языке.
Регистрируйтесь и не пропустите отличную возможность существенно сэкономить на средствах виртуализации серверов и хранилищ для небольшой инфраструктуры.
Вебинар пройдет 20 января в 22-00 по московскому времени. Участие бесплатное.
На вебинаре речь пойдет об унифицированном решении на базе серверов Dell, гипервизора Microsoft Hyper-V, ПО для хранилищ StarWind Virtual SAN, резервного копирования Veeam Backup and Replication, а также средств управления 5nine Hyper-V Manager (подробнее - тут).
Приходите на вебинар, посмотрите живую демонстрацию совместной работы перечисленных компонентов и узнайте, каким образом с помощью данного комплекса вы сможете существенно сэкономить финансовые ресурсы при условии решения текущих задач по надежному хранению виртуальных машин.
Если вы посмотрите в документ VSAN Troubleshooting Reference Manual (кстати, очень нужный и полезный), описывающий решение проблем в отказоустойчивом кластере VMware Virtual SAN, то обнаружите там такую расширенную настройку, как VSAN.ClomMaxComponentSizeGB.
Когда кластер VSAN хранит объекты с данными виртуальных дисков машин, он разбивает их на кусочки, растущие по мере наполнения (тонкие диски) до размера, указанного в данном параметре. По умолчанию он равен 255 ГБ, и это значит, что если у вас физические диски дают полезную емкость меньше данного объема (а точнее самый маленький из дисков в группе), то при достижении тонким диском объекта предела физической емкости вы получите вот такое сообщение:
There is no more space for virtual disk XX. You might be able to continue this session by freeing disk space on the relevant volume and clicking retry.
Если, например, у вас физический диск на 200 ГБ, а параметры FTT и SW равны единице, то максимально объект виртуального диска машины вырастет до этого размера и выдаст ошибку. В этом случае имеет смысл выставить настройку VSAN.ClomMaxComponentSizeGB на уровне не более 80% емкости физического диска (то есть, в рассмотренном случае 160 ГБ). Настройку эту нужно будет применить на каждом из хостов кластера Virtual SAN.
Как это сделать (более подробно об этом - в KB 2080503):
В vSphere Web Client идем на вкладку Manage и кликаем на Settings.
Под категорией System нажимаем Advanced System Settings.
Выбираем элемент VSAN.ClomMaxComponentSizeGB и нажимаем иконку Edit.
Устанавливаем нужное значение.
Надо отметить, что изменение этой настройки работает только для кластера VSAN без развернутых на нем виртуальных машин. Если же у вас уже продакшен-инфраструктура столкнулась с такими трудностями, то вы можете воспользоваться следующими двумя способами для обхода описанной проблемы:
1. Задать Object Space Reservation в политике хранения (VM Storage Policy) таким образом, чтобы дисковое пространство под объекты резервировалось сразу (на уровне 100%). И тогда VMDK-диски будут аллоцироваться целиком и распределяться по физическим носителям по мере необходимости.
2. Задать параметр Stripe Width в политиках VM Storage Policy таким образом, чтобы объекты VMDK распределялись сразу по нескольким физическим накопителям.
Фишка еще в том, что параметрVSAN.ClomMaxComponentSizeGB не может быть выставлен в значение, меньшее чем 180 ГБ, а значит если у вас носители меньшего размера (например, All-Flash конфигурация с дисками меньше чем 200 ГБ) - придется воспользоваться одним из этих двух способов, чтобы избежать описанной ошибки. Для флеш-дисков 200 ГБ установка значения в 180 ГБ будет ок, несмотря на то, что это уже 90% физической емкости.
Те из вас, кто использовал решение для обеспечения высокой доступности хранилищ под виртуализацию StarWind Virtual SAN, знают, что в продукте предусмотрена возможность асинхронной репликации данных на резервный узел для обеспечения катастрофоустойчивости. В этом случае на резервную площадку откидывается снапшот данных основного узла по заданному администратором расписанию.
В документе приведены как общие сведения об устройстве механизма асинхронной репликации данных StarWind Virtual SAN, так и подробные пошаговые инструкции по его настройке. Также советуем посмотреть еще один документ StarWind об асинхронной репликации.
Продолжаем рассказывать о решении номер 1 для создания программных хранилищ под виртуализацию VMware и Microsoft - StarWind Virtual SAN. Сегодня мы расскажем об альтернативном способе приобретения продукта, который может быть полезен, в основном, сервисным компаниям, которые предоставляют услуги пользователям на базе подписки.
Мы хотим рассказать о двух вариантах использования лицензий StarWind, которые позволяют перенести капитальные затраты (CapEX) в операционные расходы (OpEX) - это важно для провайдера ИТ-услуг, например, IaaS-хостинга виртуальных машин.
Первый вариант - аренда лицензий PaaS (Platform-as-a-Service). В этом случае заказчик платит по мере потребления услуги помесячно. Нет платежа - нет лицензии, тут все просто. StarWind выступает в виде облачной платформы хранения, к сервисам которой у клиента есть "подключение" и которая потребляется по SaaS-модели для клиента.
Второй вариант - лизинг ПО StraWind. В этом случае также есть помесячные платежи, но в результате всех выплат лицензия на ПО остается в собственности клиента, который далее может использовать ее и продлевать подписку на обновления.
Приходите на вебинар, чтобы узнать, как именно можно получить максимальный эффект от использования All-Flash хранилищ серверов хранения в сочетании с виртуализацией и проприетарной высокопроизводительной файловой системой LSFS от компании StarWind. Ребята действительно очень далеко продвинулись в этом плане.
Мы уже писали о том, что "растянутый" кластер VMware HA Stretched Cluster прекрасно работает и поддерживается вместе с отказоустойчивыми хранилищами Virtual SAN. Также мы писали о документе с лучшими практиками по построению таких кластеров, для которых требуется обеспечивать максимальную производительность.
Однако многие задаются вопросом - а как планировать ширину канала между площадками таких растянутых кластеров, чтобы обеспечить необходимую пропускную способность для синхронизации узлов кластера VMware Virtual SAN? В помощь таким пользователям компания VMware выпустила интересный документ "VMware Virtual SAN Stretched Cluster Bandwidth Sizing Guidance", в котором даются конкретные параметры и формулы для расчета необходимой пропускной способности между площадками.
Архитектура растянутого кластера в общем случае выглядит так:
Таким образом, имеет место быть 2 связи - между двумя площадками как узлами кластера, а также между каждой из площадок и компонентом Witness, следящим за состоянием каждой из площадок и предотвращающим сценарии Split Brain.
Для этих соединений рекомендуются следующие параметры:
Как известно, реальный трафик состоит из отношения операций чтения и записи, которое зависит от характера нагрузки. Например, в VDI-среде это отношение составляет примерно 30/70, то есть 30% - это операции чтения (read), а 70% - операции записи (write).
В среде растянутого кластера данные виртуальной машины всегда читаются с локальных узлов VSAN - это называется Read Locality. Ну а для операций записи, само собой, нужна определенная пропускная способность на другую площадку. Она рассчитывается как:
B = Wb * md * mr
где:
Wb - полоса записи данных.
md - множитель данных, он зависит от потока метаданных кластера VSAN и сервисных операций. VMware рекомендует использовать значение 1,4 для этого параметра.
mr - множитель ресинхронизации. Для целей ресинхронизации VMware рекомендует заложить в канал еще 25%, то есть использовать значение этого параметра 1,25.
Например, рабочая нагрузка у вас составляет 10 000 IOPS на запись (10 тысяч операций в секунду). Возьмем типичный размер операции записи в 4 КБ и получим параметр Wb:
Wb = 10 000 * 4KB = 40 MB/s = 320 Mbps
Мегабайты в секунду переводятся в мегабиты умножением на 8. Ну и заметим, что требование канала по записи нужно умножать на 1,4*1,25 = 1,75. То есть канал нужно закладывать почти в 2 раза больше от требований по записи данных.
Теперь считаем требуемую пропускную способность канала между площадками:
Многие из вас, следящие за новостями о лучшем продукте для создания отказоустойчивых хранилищ StarWind Virtual SAN, часто задаются вопросом - а чем это решение лучше существующих аналогов от VMware и Microsoft? Первый и наиболее очевидный ответ - цена. Просто посмотрите на то, сколько стоит VMware VSAN, и сравните это со стоимостью лицензий StarWind. Разницу вы почувствуете сразу.
Но это еще не все. Компания StarWind выпустила полезный каждому сомневающемуся документ "StarWind Virtual SAN: Differentiation [from competitors]", в котором весьма подробно рассмотрены преимущества продукта перед решениями от маститых вендоров.
Например, почему StarWind Virtual SAN лучше VMware Virtual SAN:
Для работы отказоустойчивых хранилищ StarWind нужно всего 2 узла (VMware требует минимум 3). Плюс StarWind не требует какой-то особенной инфраструктуры типа поддержки 10G Ethernet или SSD-дисков. У StarWind все проще.
VMware Virtual SAN лицензируется по числу процессоров ESXi плюс требуются лицензии на сам ESXi. У StarWind лицензия выйдет дешевле - вы можете лицензировать по числу узлов кластера хранилищ, либо весь датацентр сразу, и использовать бесплатные издания ESXi.
Кластер VMware Virtual SAN вы можете использовать только для платформы vSphere, а StarWind Virtual SAN можно использовать для хранения виртуальных машин на базе любого гипервизора - хоть ESXi, хоть Hyper-V, хоть XenServer.
StarWind Virtual SAN - это продукт, который сейчас находится в 8-й версии, а Virtual SAN - это всего лишь вторая версия решения. Поскольку это решение относится к самому нижнему уровню сервисов хранения датацентра, надежность работы решения является определяющим факторов.
Более подробно об этом и других продуктах для сравнения, в частности, Microsoft Storage Spaces, Microsoft Scale-Out File Server, HP Lefthand VSA, DataCore SANsymphony, Maxta и PernixData, вы можете узнать непосредственно из документа.
Компания VMware выпустила очень познавательный документ "An overview of VMware Virtual SAN caching algorithms", который может оказаться полезным всем тем, кто интересуется решением для создания программных хранилищ под виртуальные машины - VMware Virtual SAN. В документе описан механизм работы кэширования, который опирается на производительные SSD-диски в гибридной конфигурации серверов ESXi (то есть, SSD+HDD).
SSD-диски используются как Performance tier для каждой дисковой группы, то есть как ярус производительности, который преимущественно предназначен для обеспечения работы механизма кэширования на чтение (Read cache, RC). По умолчанию для этих целей используется 70% емкости SSD-накопителей, что экспериментально было определено компанией VMware как оптимальное соотношение.
SSD-диски значительно более производительны в плане IOPS (тысячи и десятки тысяч операций в секунду), поэтому их удобно использовать для кэширования. Это выгодно и с экономической точки зрения (доллары на IOPS), об этом в документе есть наглядная табличка:
То есть, вы можете купить диск SSD Intel S3700 на 100 ГБ за $200, который может выдавать до 45 000 IOPS, а это где-то $0,004 за IOPS. С другой же стороны, можно купить за те же $200 диск от Seagate на 1 ТБ, который будет выдавать всего 100 IOPS, что составит $2 на один IOPS.
Кэш на чтение (RC) логически разделен на "cache lines" емкостью 1 МБ. Это такая единица информации при работе с кэшем - именно такой минимальный объем на чтение и резервирование данных в памяти используется. Эта цифра была высчитана экспериментальным путем в исследовании нагрузок на дисковую подсистему в реальном мире, которое VMware предпочитает не раскрывать. Кстати, такой же величины объем блока в файловой системе VMFS 5.x.
Помимо обслуживания кэша на SSD, сервер VMware ESXi использует небольшой объем оперативной памяти (RAM) для поддержки горячего кэша обслуживания этих самых cache lines. Он содержит несколько самых последних использованных cache lines, а его объем зависит от доступной памяти в системе.
Также в памяти хранятся некоторые метаданные, включая логические адреса cache lines, валидные и невалидные регионы кэша, информация о сроке хранения данных в кэше и прочее. Все эти данные постоянно хранятся в памяти в сжатом виде и никогда не попадают в своп. При перезагрузке или выключении/включении хоста кэш нужно прогревать заново.
Итак, как именно работает кэширование на SSD в VMware Virtual SAN:
1. Когда операция чтения приходит к Virtual SAN, сразу же включается механизм определения того, находятся ли соответствующие данные в кэше или нет. При этом запрашиваемые данные за одну операцию могут быть больше одной cache line.
2. Если данные или их часть не находятся в RC, то для них резервируется буфер нужного объема с гранулярностью 1 МБ (под нужное количество cache lines).
3. Новые аллоцированные cache lines вытесняют из кэша старые в соответствии с алгоритмом Adaptive Replacement Cache (ARC), который был лицензирован VMware у IBM.
4. В случае промаха кэша каждое чтение одной cache line с HDD разбивается на чанки размером 64 КБ (этот размер тоже был определен экспериментально в ходе исследований). Это сделано для того, чтобы не забивать очередь на чтение с HDD "жирной" операцией чтения в 1 МБ, которая бы затормозила общий процесс ввода-вывода на диск.
5. В общем случае, одна операция чтения запрашивает лишь часть данных одной cache line, а первыми читаются именно нужные 64 КБ чанки с HDD-диска от этой cache line.
6. Запрошенные с HDD-диска данные сразу отдаются к подсистеме вывода и направляются туда, откуда их запросили, а уже потом в асинхронном режиме они попадают в соответствующие cache lines кэша и под каждую из них выделяется буфер 1 МБ в памяти. Таким образом устраняются потенциальные затыки в производительности.
В документе описаны также и механики работы кэша на запись (Write cache), для которого используется техника write-back, а также рассматриваются All Flash конфигурации. Читайте - это интересно!
Мы часто публикуем новости о предстоящих мероприятиях компании StarWind Software, выпускающей продукт номер 1 для создания программных отказоустойчивых хранилищ под виртуализацию - Virtual SAN. Не все из вас имеют возможность смотреть и слушать эти мероприятия в прямом эфире, особенно еще и потому, что зачастую они проводятся утром по тихоокеанскому времени, а у нас с вами в это время уже вечер.
Поэтому StarWind Software записывает каждый вебинар и публикует их записи по этой ссылке: https://www.starwindsoftware.com/resource-library. Просто в правой колонке жмете "Watch Now" для соответствующего вебинара (нужно будет зарегистрироваться):
Как некоторые из вас знают, сейчас в разработке у VMware находится новая версия продукта Virtual SAN (о текущей версии VSAN 6.1 мы писали вот тут), а скоро появится ее бета. Дункан написал пару интересных постов о том, какие возможности для экономии дискового пространства появятся в новой версии Virtual SAN.
А именно:
erasure coding
deduplication
compression
Обещают, что эти 3 вещи уменьшат потребляемое дисковое пространство в разы. Давайте посмотрим на некоторые детали этих возможностей.
Erasure coding (коррекция ошибок - "RAID из узлов")
Сейчас если вы используете параметр failures to tolerate =1 (зеркальная избыточность), то вам нужна двойная емкость в кластере. То есть, если будет 100 ГБ под виртуальные машины, то на хостах суммарная емкость должна составлять 200 ГБ.
По аналогии с RAID5/6 и другими типами RAID с чередованием, пространство хранения Virtual SAN будет представлять собой "RAID из хостов ESXi". Таким образом, можно будет использовать схемы 3+1 или 4+2, которые позволят иметь лишь в 1,3 раза больше физического пространства (для первой схемы), чем полезной емкости.
Но, понятное дело, для таких схем понадобится несколько больше хостов, чем, например, два.
Deduplication (дедупликация блоков)
Дедупликация блоков будет работать на уровне дисковой группы. Коэффициент дедупликации зависит от характера и разнообразия данных виртуальных машин, но при тестах он доходил до 8x.
Compression (сжатие данных)
Здесь каждый vmdk будет хранить только оригинальные дисковые блоки:
Ожидается, что для каждого 4KB блока в среднем удастся сэкономить 2KB.
Сделать запрос на бета-версию VMware Virtual SAN можно по этой ссылке.
Как и другие документы этой серии, этот whitepaper богат различными графиками и диаграммами, касающимися производительности решения. Например, вот производительность обычного кластера VMware Virtual SAN 6.1 и растянутого с задержками (latency) в 1 мс и 5 мс:
Основные моменты, раскрываемые в документе:
Развертывание и настройка Virtual SAN Stretched Cluster
Производительность растянутого кластера в сравнении с обычным
Производительность кластера при различных отказах (хост, сайт целиком)
Лучшие практики использования растянутых кластеров
Многие из вас в курсе, что решение StarWind Virtual SAN обеспечивает лучшую в отрасли защиту виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V за счет создания стабильно работающего отказоустойчивого кластера хранилищ. Напомним, что о новых возможностях последней версии продукта StarWind Virtual SAN v8 можно прочитать здесь.
Компания StarWind часто подает решение Virtual SAN на соискание различных премий, и этот год - не исключение. Совсем недавно решение Virtual SAN было выбрано финалистом премии SVC Award. Напомним, что год назад этот продукт занял второе место в рамках этой награды.
В этом году ваш голос просто обязан привести StarWind к победе! Голосуйте за StarWind Virtual SAN:
Проголосовать можно до 13 ноября. Искренне желаем нашим коллегам в этом году взять первую премию!
Компания StarWind Software, известная своим лучшим продуктом для созданиях отказоустойчивых хранилищ для VMware vSphere и Microsoft Hyper-V, на отдельном подсайте сделала доступной базу знаний StarWind Knowledge Base.
Статьи KB разбиты по категориям, по всей базе доступен поиск, к каждой статье есть тэги. На данный момент в базе 41 статья, среди которых есть несколько полезных в плане обучения, например, Logical block size или StarWind LSFS FAQ.
Скачать пробную версию продукта StarWind Virtual SAN можно по этой ссылке.
Мы уже писали о новой версии решения VMware Virtual SAN 6.1, предназначенной для создания отказоустойчивых хранилищ на платформе VMware vSphere. После того, как издания "hybrid" и "all-flash" были переименованы в "standard" и "advanced" соответственно, у пользователей появилось несколько вопросов о функциональности этих изданий.
Начнем с того, что в целом все осталось как было:
VSAN
STANDARD
VSAN
ADVANCED
VSAN FOR ROBO
(25 VM PACK)
Политики хранилищ Storage Policy Based Management (SPBM)
Итак, мы видим, что отличий у изданий Standard и Advanced теперь два:
Для конфигураций только из SSD-дисков серверов можно использовать только издание Advanced.
Для "растянутых" кластеров также можно использовать только издание Advanced. Но тут есть нюанс - растянутым кластером можно считать географически разнесенные площадки (на уровне двух разных зданий). Если у вас кластер на уровне стоек в двух серверных или на разных этажах - растянутым он не считается.
Также появилось издание VSAN for ROBO (remote or branch offices). Это издание позволяет использовать решение VSAN компаниям имеющую сеть небольших филиалов, где нет большого числа хостов ESXi. Для такой лицензии можно запустить не более 25 виртуальных машин в рамках филиала и одной ROBO-лицензии.
Здесь кластеры строятся на уровне каждого из филиалов, а witness-компонент (виртуальный модуль, следящий за состоянием кластера) располагается в инфраструктуре центрального офиса. Причем на каждый кластер VSAN нужно по отдельному witness'у. Этот самый witness позволяет построить кластер на базе всего двух узлов, а не трех, так как он следит за ситуацией split brain в кластере. Это позволяет удешевить решение для филиала, использовав для инфраструктуры из 25 машин всего 2 сервера. Более подробно о ROBO-сценарии написано вот тут.
А вот как выглядит настройка ROBO-издания Virtual SAN:
Ну и, само собой, ROBO-сценарии можно реализовывать по своему усмотрению на лицензиях Standard или Advanced.
RSS
