Новости Статьи VMware Veeam StarWind Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4410 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru | Ссылка дня: 11 ИТ-специалистов, которых очень трудно нанять

Как построить масштабируемый продакшен-кластер небольшой инфраструктуры хранилищ StarWind Virtual SAN.


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


Таги: StarWind, Virtual SAN, Enterprise, HA, Storage

Забит раздел с логами на VMware vCenter Server Appliance (большой dnsmasq.log) - что делать?


Иногда у администраторов VMware vSphere появляется проблема на сервере VMware vCSA (виртуальный модуль vCenter), когда дисковое пространство в разделе /var/log забивается под завязку. Например, если выполнить команду ls, то получим вот такую картину:

vcsa-01:/var/log # ls -lh
total 4.6G
-rw-r----- 1 dnsmasq dnsmasq 17M Feb 4 08:32 dnsmasq.log
-rw-r----- 1 dnsmasq root 844M Jan 28 07:45 dnsmasq.log-20180128
-rw-r----- 1 dnsmasq dnsmasq 3.7G Feb 2 16:19 dnsmasq.log-20180204

Здесь мы видим целых 4,6 ГБ логов! Такая ситуация - не редкость, поэтому иногда нужно поменять настройки заполнения и ротации логов, чтобы раздел не забивался. В данном случае растет лог dnsmasq - кэша сервера DNS и DHCP на сервере vCSA (подробнее тут).

Вот тут мы уже писали о том, как сменить еженедельную ротацию на ежедневную, а теперь немного более подробно посмотрим на проблему. По этому вопросу есть специальная статья VMware KB - "Root partition on the vCenter Server Appliance is full due to dnsmasq.log files".

В качестве решения предлагается отредактировать файл /etc/logrotate.d/dnsmasq до следующего состояния:

/var/log/vmware/dnsmasq.log {
nodateext # добавляем эту строчку
daily # меняем со значения weekly
missingok
notifempty
compress # меняем со значения delaycompress
maxsize 5M # добавляем эту строчку
rotate 5 # добавляем эту строчку
sharedscripts
postrotate
[ ! -f /var/run/dnsmasq.pid ] || kill -USR2 `cat /var/run/dnsmasq.pid`
endscript
create 0640 dnsmasq dnsmasq
}

Кстати, размещение файла логов можно изменить в файле /etc/dnsmasq.conf, для этого надо поменять вот эту строчку:

log-facility=/var/log/vmware/dnsmasq.log

Сам же данный конфигурационный файл рекомендуется сделать таким:

listen-address=127.0.0.1
bind-interfaces
user=dnsmasq
group=dnsmasq
no-negcache
no-hosts
log-queries
log-facility=/var/log/vmware/dnsmasq.log
domain-needed
dns-forward-max=150
cache-size=8192
neg-ttl=3600

После этого перезапускаем сервис dnsmasq:

vcsa-01:~ # service dnsmasq restart
Shutting name service masq caching server
Starting name service masq caching server


Таги: VMware, vCSA, Logs, Storage, Troubleshooting

Ограничение виртуальных дисков по IOPS в среде VMware vSphere.


Блогер David Pasek опубликовал интересный пост, касающийся ограничения виртуальных машин и их виртуальных дисков по числу операций ввода-вывода. Смысл его в том, что автор, являющийся ярым сторонником обеспечения QoS на уровне виртуальных дисков, настоятельно рекомендует применять ограничения IOPS limit к виртуальным дискам машин, которые потенциально могут выесть много полосы ввода-вывода.

Сейчас ограничивать виртуальные машины по IOPS можно как на уровне виртуальных дисков на томах VMFS/RDM/NFS, так и на уровне томов VVols. Многие системы хранения оперирует понятием логического тома LUN, на котором размещается один том VMFS. Как правило, LUN - это логический том, что значит, что несколько LUN могут размещаться на одной физической группе дисков:

Таким образом, виртуальные машины, потребляющие много IOPS от хранилища (он называет их "noisy neighbor") могут существенно замедлить работу других производственных систем.

Поэтому для таких машин требуется создавать ограничения IOPS limit, которые можно задать для виртуального диска в опциях машин, либо привязать к VMDK диску политику с ограничениями по IOPS.

Например, в vSphere Web Client создаем новую VM Storage Policy с ограничениями IOPS limit for object:

А далее привязываем эту политику к диску VMDK в настройках ВМ:

Тут же в настройках можно задать значение в поле Limit-IOPs, если не выбирать политику.

Именно ограничение по IOPS делает поведение инфраструктуры хранения для виртуальных машин предсказуемым и управляемым. Ограничения по вводу-выводу позволят обеспечить минимально приемлемый уровень обслуживания для виртуальных машин, которым требуются ресурсы хранилища, с гарантией того, что остальные системы не съедят все доступные IOPS.

Ну и в заключение несколько аспектов данного рода ограничений:

  • Команды ввода-вывода (IO) нормализуются к блоку 32 КБ, то есть команда в 128 КБ будет преобразована в 4 IO.
  • IOPS limit не влияет на операции SVmotion (миграция хранилища), XVmotion (миграция машин без общего хранилища) и клонирование ВМ.
  • IOPS limit применяется только ко вводу-выводу гостевой ОС и не затрагивает операции с самим диском VMDK и его swap-файлами.
  • Если у машины несколько лимитов по IOPS для дисков на одном датасторе, то эти лимиты складывают и применяются для всей ВМ на этом датасторе в целом. Если же диски находятся на разных хранилищах, то тут уже действуют правила для каждого из групп дисков.
    • Например, если у каждой из 4 дисков машины на одном датасторе стоит лимит 100 IOPS, то для всей машины будет совокупный лимит 400. То есть, если три VMDK едят по 10 IOPS каждый, то четвертый диск сможет съесть максимум 370 IOPS.
    • А вот для NFS-хранилищ все работает несколько иначе - если у каждого из 4 дисков на одном датасторе стоит лимит 100 IOPS, то сколько бы ни потребляли остальные диски, для каждого из дисков будет применен максимальный лимит 100.
  • Полная информация об ограничении ввода-вывода для виртуальных машин приведена в KB 1038241.

Также рекомендуем почитать нашу статью "VMware Storage I/O Control (SIOC) - как это работает на практическом примере".


Таги: VMware, vSphere, Storage, Performance, VMDK, VMFS, NFS

Бесплатная утилита StarWind Deduplication Analyzer для оценки эффективности дедупликации.


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

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

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

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

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

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

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

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


Таги: StarWind, Virtual SAN, Бесплатно, Storage

Вышел Veeam Backup & Replication 9.5 Update 3 - масса новых возможностей.


На днях компания Veeam выпустила обновление своего флагманского продукта Veeam Backup & Replication 9.5 Update 3 для резервного копирования и репликации виртуальных машин, в котором появилось немало новых возможностей. Напомним, что Veeam B&R 9.5 Update 2 вышел весной этого года, поэтому долгожданное обновление под Новый год окажется весьма кстати.

Теперь консоль Veeam Backup & Replication представляет собой не только сам продукт, но и в рамках Veeam Availability Suie интегрирует управление такими решениями, как Veeam Agent for Microsoft Windows и Veeam Agent for Linux. То есть вы теперь можете создавать задачи как для бэкапа виртуальных машин с помощью Veeam Backup and Replication, так и для бэкапа файлов/папок/дисков серверов с помощью агентов из одной консоли. Все эти задачи можно контролировать одновременно для всей своей физической и виртуальной ИТ-инфраструктуры.

Посмотрим на прочие новые возможности решения:

1. Группы защиты (protection groups).

Это объекты для Veeam Agents, которые объединяются по категориям - например, компьютеры, добавляемые по IP или DNS-имени, объекты Active Directory, такие как organizational units (OUs), группы или компьютеры, а также списки хостов из CSV-файла.

Также появилась логика исключений - если вы защищаете, например, системы с помощью Veeam Agent на неподдерживаемом Veeam B&R гипервизоре, то нужно снять галочку "All virtual machines":

Также теперь можно исключить из бэкапа ВМ, которые находятся в офлайне более 30 дней, чтобы Veem B&R не пытался туда установить агентов. Ну и, кроме того, в исключения можно добавить отдельные объекты.

Удобство таких групп в отличие от статически определенных списков в том, что, например, в OU Active Directory компьютеры могут добавляться и удаляться - и Veeam B&R будет регулярно обновлять эти данные.

2. Политика резервного копирования Managed by Agent для десктопов и серверов.

Она используется для тех рабочих станций, режим работы пользователей которых непредсказуем, а также для удаленных серверов с нестабильным соединением. В этом случае нужно выбирать опцию Managed by Agent:

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

Если вы выберете Managed by backup server - то уже сервер резервного копирования будет определять окно, в рамках которого будет проходить бэкап.

3. Поддержка новых систем и продуктов.

Теперь Veeam Backup & Replication 9.5 Update 3 поддерживает Microsoft Windows Server 2016 версии 1709, VMware vCloud Director 9 и Microsoft SQL Server 2017. Кроме того, поддерживаются диски 4 ТБ в Microsoft Azure, а также регионы Azure Germany и China.

Ну и поддерживаются ленточные устройства LTO-8.

4. Поддержка VMware Cloud on AWS.

Эта поддержка была анонсирована Veeam еще на прошедшем VMworld 2017. Теперь решение от Veeam можно использовать для резервного копирования внутри облачных сред, а также для репликации онпремизных виртуальных машин в облако.

5. "Корзина" для сервис-провайдеров Cloud Connect.

Теперь сервис-провайдеры могут установить число дней, в течение которых будут храниться удаленные объекты резервного копирования. Зачем? Все просто - если какое malware поудаляет сами машины и бэкапы у сервис-провайдера, их можно будет хотя бы восстановить из корзины.

6. Data location logging.

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

7. Интеграция со снапшотами IBM Spectrum Virtualize и Lenovo Storage V Series.

Теперь в Veeam Backup & Replication 9.5 Update 3 есть интеграция с массивами IBM Spectrum Virtualize семейств IBM SAN Volume Controller (SVC) и IBM Storwize, а также интеграция с Lenovo Storage V Series (массивы на основе IBM Spectrum Virtualize). Интеграция доступна как для Veeam Explorer for Storage Snapshots, так и для Backup from Storage Snapshots.

Загрузить Veeam Backup & Replication 9.5 U3 можно по этой ссылке. Скоро там же будут доступны обновления Veeam Agent for Microsoft Windows 2.1 и Veeam Agent for Linux v2.


Таги: Veeam, Backup, Update, Storage, Agent

Как расходуется дисковое пространство в кластере VMware vSAN при удалении файлов?


Cormac Hogan написал занимательный пост о об использовании дискового пространства в кластере VMware vSAN. Всех интересует - умеет ли vSAN возвращать дисковое пространство хранилищу при удалении файлов в гостевой ОС виртуальной машины? Ответ - пока нет, но над этим работают.

Cormac провел вот какой эксперимент: взял виртуальную машину в кластере vSAN с гостевой ОС Windows Server 2012 R2, у которой было 386.7 ГБ занятого места (сама ВМ была развернута на тонких дисках):

Затем он скопировал туда данные на 800 МБ, после чего увидел, что занятое место увеличилось до 388.37 ГБ, то есть выросло на 1,6 ГБ. Это логично, так как vSAN работал в режиме RAID-1 (зеркалированные VMDK-диски):

Далее он удалил только что скопированные файлы и убедился, что занятое дисковое пространство осталось тем же самым (то есть, в vSAN нет поддержки UNMAP/TRIM изнутри гостевой системы):

Между тем, он снова скопировал те же 800 МБ и к радости администраторов заметил, что дисковое пространство увеличилось лишь на 20 МБ (в совокупности на 40 МБ с учетом RAID-1).

То есть занятые после прошлого копирования блоки были использованы повторно:

Такая штука есть у Windows Server, но у Linux в файловой системе ext4 такой трюк не прокатит - все равно при повторном копировании блоки разместятся в другом месте, и пространство будет использовано повторно. Но это особенность файловой системы ext4, об этом подробно написано тут и тут. Для ФС ext3 и XFS это не актуально, там блоки тоже будут переиспользоваться.

Ну и помните, что описанное применимо только для удаления файлов изнутри гостевой ОС, если же вы удалите на хранилище vSAN виртуальную машину или другой объект - пространство сразу же вернется в общий пул хранения.


Таги: VMware, vSAN, Storage, vSphere, VMachines

Предотвращение создания виртуальных машин на определенных датасторах в VMware vSphere Storage Policy Based Management (SPBM).


Довольно давно мы уже рассказывали о механизме применения политик для хранилищ при развертывании виртуальных машин - VMware vSphere Storage Policy Based Management (SPBM). А недавно Кормак Хоган опубликовал интересную заметку, касающуюся возможности выбора политик SPBM конкретным пользователем во время развертывания новой виртуальной машины.

Прежде всего, в vSphere нет механизма назначения прав доступа пользователей на конкретную политику SPBM - все пользователи видят все политики. Но сам механизм разграничения прав существует - его можно реализовать на уровне прав доступа к хранилищам.

Например, пользователю ben мы даем доступ Read-only к хранилищу VVols1, то есть создавать виртуальные машины он на нем не может:

А на хранилище VVols2 делаем его администратором:

В итоге, при развертываниии виртуальной машины пользователь ben видит оба хранилища - VVols1 и VVols2 и все доступные политики хранилищ (комбобокс VM storage policy):

Однако, обратите внимание, что при выборе хранилища VVols1 в разделе Compatibility написано о том, что пользователь не имеет достаточных привилегий, чтобы создать машину на этом датасторе.

You do not hold the privilege to allocate space on the selected datastore

Между тем, кнопка Next активна. Но если нажать ее, мастер все равно дальше не пустит:

Вверху мы увидим:

Specify a valid location

Ну а если выбрать VVols2, то все проверки пройдут успешно, и пользователь сможет там создать виртуальную машину:


Таги: VMware, Storage, Security, SPBM, vSphere

Кто использует VVols в качестве хранилищ VMware vSphere?


Мы много пишем о технологии Virtual Volumes (VVols), которая сравнительно недавно появилась в платформе виртуализации VMware vSphere. Совсем недавно мы писали о том, что будет в следующих версиях VVols, а сегодня давайте посмотрим на текущее положение дел.

Eric Siebert написал интересный пост о том, сколько компаний использует VVols сейчас в производственно среде. На данный момент VVols применяется примерно у 2% клиентов VMware, что весьма и весьма мало. Связано это, в первую очередь, с ограничениями технологии и небольшим количеством партнеров ее поддерживающих.

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

  • Все больше клиентов переходят с vSphere 5.5 на vSphere 6.x, где VVols полностью поддерживаются.
  • В vSphere 6.5 поддерживается функциональность аппаратной репликации томов VVol, что является очень важной и нужной фичей.
  • Партнеры расширяют поддержку этой технологии в своих новых массивах.
  • Клиенты все больше узнают о технологии, в том числе через этот пост:)

Если посмотреть на статистику использования VVols администраторами vSphere в различных компаниях, то во времени она выглядит так:

Категория Январь 2016 Январь 2017 Сентябрь 2017
Общее число систем с использованием VVols 46 258 361
Системы, где до 10 томов VVol 36 111 165
Системы, где 11-50 томов VVol 5 51 71
Системы, где 51-100 томов VVol 3 11 35
Системы, где более 100 томов VVol 2 43 90
Самый большой клиент (по числу томов VVol) N/A 1 457 VVols / 576 машин 2 656 VVols / 727 машин
10-й по величине клиент VVol (по числу томов) N/A 477 VVols / 169 машин 944 VVols / 216 машин

В принципе, прогресс за этот период выглядит неплохо (особенно в категории 100+), но в абсолютном выражении это, все-таки, очень мало. Ну и вот небольшой августовский отчет IDC про данную технологию - "VVols Provides Powerful Application-Aware Management for vSphere Environments".

Пара интересных роликов, вышедших на днях:


Таги: VMware, VVols, Storage, vSphere

PowerCLI-сценарий для обнаружения логических дисков Windows в виртуальных дисках VMDK.


Allan Kjaer написал интересный скрипт PowerCLI, который позволит определить, какие логические тома Windows находятся в виртуальных дисках VMDK машин на платформе vSphere. Как-то я сталкивался с такой проблемой, поэтому может быть она не такая уж и редкая.

Скрипт соединяется с управляющим сервером VMware vCenter, запрашивает учетные данные к гостевой ОС Windows, после чего строит отчет о том, на каких дисках VMDK какие разделы были обнаружены. Отчет включает в себя индекс диска Windows, букву диска и метку тома.

Вот так он выглядит:

"vmName      vmHardDiskDatastore vmHardDiskVmdk           vmHardDiskName windowsDiskIndex windowsDiskSerialNumber          vmHardDiskUuid                   windowsDeviceID    drives   volumes
------ ------------------- -------------- -------------- ---------------- ----------------------- -------------- --------------- ------ -------
test-vm FC01 test-vm/test-vm.vmdk Hard disk 1 0 6000c29c481f32e9763fe6d2d8dc8f7b 6000C29c481f32e9763fe6d2d8dc8f7b \\.\PHYSICALDRIVE0 C:
test-vm FC01 test-vm/test-vm_1.vmdk Hard disk 2 1 6000c297d1a7352ed5ee1b870023f57d 6000C297d1a7352ed5ee1b870023f57d \\.\PHYSICALDRIVE1 D: Data
test-vm FC03 test-vm/test-vm.vmdk Hard disk 3 2 6000c290e36c2f3b641a56308551e998 6000C290e36c2f3b641a56308551e998 \\.\PHYSICALDRIVE2 {E:, F:} {New Volume, New Volume}

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


Таги: VMware, PowerCLI, Storage, VMachines

Новая версия калькулятора VMware vSAN 6.5 и vSAN 6.6.1 Resource Calculator.


Летом мы писали о калькуляторе для сайзинга хранилищ инфраструктуры VMware vSAN 6.2. С тех пор вышли новые версии vSAN 6.5 и vSAN 6.6.1, в которых было реализовано несколько новых возможностей, соответственно, обновился и калькулятор - его новая версия доступна по этой ссылке. Новая версия построена на базе документов VMware vSAN Design and Sizing Guide 6.5 и 6.6.1 (глава 10.2 Capacity Sizing Example II).

Калькулятор представляет собой Excel-таблицу, в которой есть поля для ввода исходных данных (черные - это аппаратные параметры инфраструктуры и данные по консолидации ВМ, синие и зеленые - остальные параметры). Ранее этот калькулятор представлял собой Excel-документ в облаке OneDrive, но теперь любой может скачать его.

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

В левой области таблицы данные параметры рассчитываются для All-Flash архитектуры кластера Virtual SAN, а правая часть предназначена для расчетов гибридной архитектуры (обычные HDD-диски для данных, а SSD-носители - для кэша).

Более подробно о калькуляторе написано вот тут.


Таги: VMware, vSAN, Calculator, Storage

Бесплатная книга "vSphere 6.5 Host Resources Deep Dive" (570 страниц!).


Автор известного технического блога о платформе VMware vSphere, Frank Denneman, совместно с одним из коллег выпустил весьма интересную книгу "vSphere 6.5 Host Resources Deep Dive".

В рамках 570-страничного талмуда авторы рассказывают все технические детали управления ресурсами на уровне хоста ESXi, такими как память, процессор, стек работы с хранилищами и сетевая архитектура. Довольно много содержимого книги посвящено архитектуре NUMA-узлов и оперативной памяти, механикам работы CPU и ядра VMkernel, а также прочим самым глубоким моментам программных и аппаратных компонентов хоста ESXi.

По уверению авторов книга покрывает, например, следующие технические вопросы:

  • Оптимизация рабочих нагрузок для систем Non-Uniform Memory Access (NUMA).
  • Объяснение того, как именно работает механика vSphere Balanced Power Management, чтобы получить преимущества функциональности CPU Turbo Boost.
  • Как настроить компоненты VMkernel для оптимизации производительности трафика VXLAN и окружений NFV.

В общем, книга очень крутая и мудрая. Скачать ее можно по этой ссылке.


Таги: VMware, Book, ESXi, Blogs, Storage, CPU, Memory

Как правильно вывести хост VMware ESXi из кластера vSAN.


Иногда администратору решения по организации отказоустойчивых кластеров VMware vSAN требуется вывести отдельный хост VMware ESXi из кластера, после чего использовать его диски для организации томов VMware VMFS виртуальных машин уже не в рамках кластера.

Правильно делать это следующим образом.

1. Проверяем, является ли хост членом кластера vSAN:

esxcli vsan cluster get

2. Выводим хост ESXi из кластера:

esxcli vsan cluster leave

3. Убедимся, что хост вышел из кластера:

esxcli vsan cluster get

мы должны получить сообщение:

Virtual SAN Clustering is not enabled on this host

4. После этого надо очистить конфигурацию vSAN для дисков на хосте.

Для начала найдем все диски командой:

esxcli vsan storage list

далее идентифицируем диски vSAN, выполнив команду:

partedUtil getptbl <путь к устройству>

Здесь мы видим, что один из разделов еще видит себя частью vSAN. Сначала надо снять лок с диска, отключив автоуправление со стороны кластера vSAN (то есть, разрешаем ручные операции с хранилищами vSAN):

esxcli vsan storage automode set --enabled false

Если этого не сделать, мы получим такую ошибку:

Unable to remove device: Can not destroy disk group for SSD naa.6000c29c581358c23dcd2ca6284eec79 : storage auto claim mode is enabled

5. После этого можно окончательно вывести диск из кластера vSAN следующей командой:

esxcli vsan storage remove -s naa.50026b724712194a

здесь опция -s значит SSD-диск (так отключаются устройства кэширования), а если мы хотим вывести обычный диск, то вместо -s надо использовать опцию -d.


Таги: VMware, vSAN, Обучение, Storage, ESXi

Несколько советов по дедупликации, компрессии и экономии дискового пространства в кластере VMware vSAN.


John Nicholson написал интересный пост с советами по экономии дискового пространства в кластере VMware vSAN, а также некоторыми рекомендациями по использованию техник дедупликации и сжатия данных.

Вот каким моментам следует уделить внимание:

1. Посмотрите на параметр политики хранения object space reservation (OSR) - если он установлен в 0, то виртуальные диски машин будут тонкими. Если же он будет больше 0, то пространство под диски будет резервироваться и vSAN не сможет эффективно использовать дедупликацию, так как будет вынужден поддерживать фиксированные резервы дискового пространства под ВМ.

2. Помните, что параметр резервирования свопа установлен в 100%, но это можно поменять, как мы писали в этой статье. Уменьшение параметра резервирования свопа оправдано, когда вы не собираетесь использовать memory overcommitment (то есть, ресурсов у вас с запасом), а значит виртуальным машинами не потребуется активно сбрасывать страницы в своп в случае недостатка физической памяти.

3. Помните, что отдельно развертываемые виртуальные машины c дисками типа "thick" или "Eager Zero Thick" (например, со старых клиентов vSphere Client или через консоль) могут перекрывать настройку политики OSR. Чтобы пофиксить это, вы можете переприменить политику хранения (storage policy) на эти хранилища. William Lam написал несколько скриптов, которые позволяют найти такие ВМ и накатить политики по-новой.

4. Убедитесь, что данные записываются на capacity tier - только там они будут дедуплицироваться и сжиматься. Если вы развернули всего 3-4 машины, они могут остаться в буффере (write buffer). Механизмы vSAN не тратят ресурсы на дедупликацию и сжатие объектов, которые долго не живут (то есть, находятся в буффере на запись). Например, 10 машин по 8 ГБ диска каждая тоже могут остаться на стейджинге и, пока не переместятся в постоянное хранилище, не будут дедуплицированы.

Вот тут можно посмотреть, как именно отрабатывает дедупликация, и сколько она экономит дискового пространства:

Ну и вот что Джон рекомендует в плане тестирования дедупликации и компрессии:

  • Самый простой способ организовать тестирование - запустить клонирование 200+ виртуальных машин, они сразу пойдут в capacity tier, и механизм дедупликации включится.
  • Надо помнить, что тестирование этих механизмов и реальное их применение дадут разные результаты, так как при тестировании вы последовательно пишете данные на хранилище и избегаете узких мест, связанных с дестэйджингом из кэша во время размеренного использования кластера vSAN в продакшене.
  • Тестирование алгоритма сжатия на данных, которые плохо сжимаются - плохая идея, так как в этом случае vSAN не будет тратить ресурсы на их сжатие, чтобы записать на хранилище. Это позволит быстрее читать их, а экономия с точки зрения диска будет небольшой (к тому же, алгоритм сжатия LZ4 не такой быстрый, как хотелось бы).
  • При резких всплесках объема записываемых данных и IOPS, которые не помещаются в кэш, видно, что механизмы сжатия и дедупликации приостанавливаются и теряют эффективность. Это связано с тем, что vSAN прежде всего должен обеспечить хороший показатель latency (то есть уровня сервиса), а уже во вторую очередь эффективность механизмов дедупликации и компрессии.

Ну и в довершение, интереснейший документ от VMware - "vSAN Space Efficiency Technologies".


Таги: VMware, Storage, vSAN

Как увеличить VM Guest Partition с помощью PowerCLI.


Как часто вам приходится увеличивать логические диски внутри гостевых ОС ВМ? Довольно часто, не так ли? Вам надо сначала найти вашу ВМ в vSphere Client, потом кликнуть Edit Settings и перво-наперво увеличить виртуальный диск ВМ. После вы должны будете открыть RDP к вашей ВМ, затем открыть Disk Management, выбрать Rescan Disks из контекстного меню и только после этого ещё один правый клик на нужном вам логическом диске и вот сейчас выбрать Extend Volume...


Таги: VMware, PowerCLI, Storage, PowerShell, VMachines, ESXi, vSphere

VMware vSphere APIs for I/O Filtering (VAIO) - как это работает.


Недавно компания VMware выпустила интересный документ VMware vSphere APIs for I/O Filtering (VAIO), в котором описываются основные принципы работы данной технологии. Ниже мы расскажем о них вкратце, а также затронем тему того, каким образом можно использовать VAIO в производственной среде.

VAIO - это технология и API, которые позволяют получать прямой доступ к потоку ввода-вывода (I/O Stream) гостевой ОС виртуальной машины. Механизм VAIO уже сейчас способствует созданию партнерских продуктов для решения самых разнообразных задач (например, кэширование write-back и write-through). VAIO основан на механике Storage Policy Based Management (SPBM), которая предназначена для управления правилами хранения виртуальных машин и их работой с хранилищами.

Техническая реализация данного механизма подразумевает использование драйвера VAIO (filter driver), который устанавливается на хосте VMware ESXi как пакет VIB и не требует установки никакого специального ПО в гостевой ОС виртуальной машины.

Посмотрим на эту картинку, на которой изображен путь данных от виртуальной машины к физическому устройству хранения. На ней представлены 2 компонента, относящиеся к VAIO. Первый - это VAIO фреймворк, работающий на уровне ядра VMkernel и определяющий действующую политику фильтра. Второй - это IO Filter, представляющий собой программное обеспечение, работающее на уровне пользовательской среды исполнения (User World) сервера ESXi. Этот драйвер фильтра исполняет свою функцию (например, кэширование данных или их репликация), после чего передает их на физическое устройство хранения для записи.

Такая архитектура позволяет драйверу IO-фильтра получать доступ к потоку ввода-вывода, не сильно не влияя на производительность исполнения SCSI-команд. Еще одна особенность IO-фильтра - это возможность иметь доступ к потоку ввода-вывода как в сторону записи (от ОС к хранилищу), так и в обратную сторону (квитанции о прохождении команд). Это полезно, например, при использовании IO-фильтра для технологии репликации, где очень важно получать квитанции о записи данных на диск.

Кстати, SCSI-команды попадают к IO-фильтру сразу после того, как они проходят слой эмуляции SCSI (он же vSCSI), что позволяет использовать VAIO для любых типов хранилищ - VMFS, NFS, SCSI и vSAN. Ну а перехват команд IO-фильтром перед их отсылкой в сетевой стек к хранилищу позволяет обеспечить целостность данных и безопасность.

Еще, если внимательно посмотреть на архитектуру прохождения потока ввода-вывода, можно заметить, что драйвер IO-фильтра работает на уровне User World, а значит в целом не влияет на стабильность работы сервера ESXi. Даже если он вдруг прекратит свою работу, основной стек прохождения SCSI-команд, расположенный в ядре, продолжит работать в нормальном режиме.

Работает IO Filter на уровне отдельных VMDK-дисков конкретных ВМ, что открывает широкие возможности для механизма политик Storage Policy Based Management (SPBM) и применения их к отдельным виртуальным машинам и сервисам.

Все вышеперечисленное позволяет применять VMware VAIO при решении следующих типов задач:

  • Encryption – стороннее ПО за счет использования механизма VAIO может на лету шифровать и расшифровывать поток данных от виртуальной машины. Таким образом на хранилище будут помещаться уже шифрованные данные. Гранулярность работы VAIO позволяет обслуживать данные, идущие даже не от всей виртуальной машины, а только от одного приложения.
  • De-duplication - этот механизм уже использует решение VMware Virtual SAN. В реальном времени можно дедуплицировать данные, проходящие через драйвер и в таком виде уже класть на хранилище в целях экономии дискового пространства. Эта техника доступна и партнерам VMware.
  • Tiering - данные различной степени важности, критичности или классифицированные по другим критериям теперь можно класть на хранилища с разными характеристиками производительности и доступности (ярусы). Механизм VAIO тут поможет проанализировать характер данных и определить конечное их место назначения.
  • Analytics - теперь можно анализировать непосредственно поток данных от конкретной виртуальной машины и на основе этого строить множество различных решений, включая решения по кэшированию (например, такой продукт как PrimaryIO, который можно напрямую подключить к гипервизору). Затем можно, например, искать в трафике данные определенных приложений, либо, использовать механизм write-back кэширования.

Технология VAIO работает, начиная с VMware vSphere 6.0 Update 1, поддерживает горячую миграцию vMotion (VAIO должна быть доступна на целевом хосте) и кластеры VMware DRS (должна быть доступна на всех хостах).

Давайте теперь посмотрим, как VAIO работает на практике на одном из примеров. Чтобы начать работать с VAIO, вам нужно установить IO Filter в виде VIB-пакета, который реализует функциональную составляющую партнерского продукта для VMware vSphere.

Как правило, вместе с фильтром идет и политика SPBM (аналогичная тем, которые есть для vSAN или VVols, например), которую можно назначать виртуальным машинам на уровне виртуальных дисков VMDK.

Эту политику можно назначить при создании виртуальной машины в разделе Select Storage (в данном случае это политика кэширования на SSD):

Пример политики, идущей вместе с фильтром, как правило включает в себя Common Rule - правила, которые реализуют Data Services (то есть основной функционал фильтра) и определяются через компоненты Storage Policy Components (путем добавления компонентов в разделе Common Rules).

Например, в данном случае это тип кэширования Write Through или Write Back, который мы задаем в разделе Common Rules при создании новой политики хранения:

По умолчанию эти компоненты устанавливаются вместе со встроенными фильтрами vSphere и другими продуктами, которые пополняют набор IO-фильтров, а соответственно и компонентов по мере их установки. За счет использования Storage Policy Components возможности IO-фильтров могут быть включены в любую из уже настроенных политик VM Storage Policies.

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

Ну а сами IO-фильтры от разных производителей вы можете найти в VMware Compatibility Guide по этому адресу - https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vaio.

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


Таги: VMware, vSphere, VAIO, Storage, API, SPBM, VMachines

Топ-4 рекомендаций к модернизации СХД.


Это гостевой пост компании ИТ-ГРАД - сервис-провайдера, предоставляющего виртуальные машины в аренду.

Если у вас есть система хранения данных, то рано или поздно она обязательно подвергнется модернизации, так как невозможно представить развивающийся бизнес без постоянного роста вычислительных ресурсов. Карло Велтен, генеральный директор Crisp Research, на первой конференции FlashForward, состоявшейся 1 июня 2017 года в Мюнхене, рассказал о четырех главных требованиях к модернизации систем хранения, которые сделают ИТ-инфраструктуру более надежной и современной.

Но рекомендации не имеют смысла без реализации на практике, поэтому остановимся на каждой из них применительно к новейшей системе хранения данных NetApp® All Flash FAS.

Масштабируемость (Skalierbarkeit)

NetApp® All Flash FAS обладает уникальной возможностью масштабирования среди продуктов компаний, представляющих на рынке решения с флэш-памятью. Все модели All Flash FAS могут быть расширены до 24 узлов. Это позволяет добиться невероятной «сырой» емкости в 7,3 Пб, что значительно больше, чем могут предложить конкуренты сегодня или в ближайшем будущем.

Но это еще не все! 5 июня этого года NetApp представила новую прошивку ONTAP® 9.2. С ее помощью клиенты могут масштабировать свою систему хранения почти до бесконечности, используя облачное хранилище. В версии 9.2 реализована новая технология FabricPool, которая позволяет осуществлять автоматический tiering между частными и публичными облаками, перемещая холодные данные с SSD-агрегата на более медленный объектный уровень (облако Amazon S3 или СХД NetApp StorageGRID). Это повышает эффективность использования мощностей и защиту инвестиций.

Хорошим примером использования масштабирования СХД от NetApp служит кейс Европейского космического агентства, ознакомиться с которыми вы можете по данной ссылке.

Производительность и доступность (Performance and Verf?gbarkeit)

Производительность системы хранения – очень важный параметр, так как потребности бизнеса очень быстро меняются, а ИТ-инфраструктура должна им соответствовать и быть гибкой. Поэтому создание вычислительных центров на базе самых мощных из представленных на рынке СХД, таких как All Flash FAS, является очень выгодным вложением. Результаты тестов SPC-1 показывают, что All Flash FAS входит в тройку самых быстрых систем хранения, доступных на текущий момент. Она также имеет отличный показатель соотношения цены и производительности – тот же рейтинг СХД доказал, что AFF 700s имеет лучшее соотношение $/IOPS из 10 протестированных систем.

Безопасность хранения данных (Datenhoheit and Sicherheit)

Сейчас набирают популярность решения гибридного облака, но безопасное перемещение данных между узлами внутри него все еще вызывает сомнения и опасения. Для решения этой проблемы NetApp предлагает Data Fabric. С помощью технологии Data Fabric вы можете безопасно перемещать данные в облаках (частных или публичных) и управлять ими, чтобы получить все преимущества гибридной модели. Модели NetApp серии All Flash FAS могут быть интегрированы в Data Fabric для репликации, создания резервных копий и распределения данных по различным уровням систем хранения в публичном или частном облаке.

Для того чтобы узнать больше об этой технологии, ознакомьтесь с нашим информационным буклетом.

Эффективность (Effizienz)

Для повышения эффективности системы хранения используют такие технологии, как сжатие, дедупликация и экономное распределение (thin provisioning), но ONTAP теперь также позволяет делать дедупликацию на уровне агрегата (aggregate level) и уменьшать передачу избыточных данных между томами, что повышает эффективность хранения на 30%. Это важно как клиентам крупных центров обработки данных, которые ищут способы занимать меньше пространства путем оптимизации инфраструктуры, так и небольшим поставщикам услуг для сервисных провайдеров, когда платить приходится за каждый отдельный юнит. Переход на эффективную технологию флэш-памяти дает значительную экономию для клиентов независимо от их размера. ИТ-организации, которые перешли на систему хранения All Flash FAS, сократили используемую площадь от 4 до 10 раз.

О примере повышения эффективности вы можете прочитать в кейсе факультета гражданского строительства (FCE) Чешского технического университета (CTU).

All Flash FAS от NetApp удовлетворяет всем требованиям к модернизации СХД и может быть рекомендована для компаний любого уровня и масштаба.

Для более детального знакомства с решением NetApp All Flash FAS и другими системами хранения данных NetApp, предоставляемыми компанией «ИТ-ГРАД», обращайтесь в центр компетенции. Здесь вы всегда сможете задать интересующие вас вопросы и обсудить различные варианты построения ИТ-инфраструктуры.

Ссылка на статью в блоге ИТ-ГРАД.


Таги: IT-Grad, Storage, Обучение, Enterprise, NetApp

Проблема с VMware vCenter Server Appliance (vCSA) - ошибка 503 Service Unavailable.


Как пишут многие, в последнее время с виртуальным модулем VMware vCenter Server Appliance (vCSA) часто случаются проблемы. Например, вот такая ошибка появляется время от времени:

503 Service Unavailable (Failed to connect to endpoint: [N7Vmacore4Http20NamedPipeServiceSpecE:0x0000559b1531ef80] _serverNamespace = 
/ action = Allow _pipeName =/var/run/vmware/vpxd-webserver-pipe)

Как пишет Anthony Spiteri, зачастую эта ошибка связана с тем, что Linux-система, на базе которой работает vCSA (а именно Photon OS в vCSA 6.5), пока еще имеет достаточно ненадежную реализацию стека работы с хранилищами (в отличие от того, который есть в Windows). Поэтому при некоторых неполадках со стораджем или появлении высокой задержки (latency) сервер vCSA может "выпадать".

Ведь vCSA 6.5 имеет аж 12 файлов виртуальных дисков VMDK (раньше их было два), с которыми что-нибудь да может иногда случиться. Один из вариантов решения - проверить диски утилитой e2fsck, которая может проблем в случае 503 ошибки. Также проблема может таиться в USB-устройствах, и тогда вам поможет вот эта статья. А еще можно заглянуть вот сюда.

Может еще помочь выполнение следующих команд в консоли vCSA для перезапуска vSphere Web Client (надо будет подождать 15 минут):

service-control --stop vsphere-client
service-control --start vsphere-client

Ну и не забудьте заглянуть в эту ветку форумов VMware.

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


Таги: VMware, vCSA, Bug, Storage, vSphere

Как конфигурировать SDRS Anti-Affinity правила с PowerCLI – Часть 3


Это Часть 3 в серии о Storage DRS. В предыдущей части мы говорили о том как создавать и удалять SDRS Anti-Affinity правила. Чтобы закрыть тему, нам осталось редактировать/реконфигурировать существующие правила. Логично предположить, что это будет функция Set-SdrsAntiAffinityRule.


Таги: SDRS, PowerCLI, vSphere, VMware, Storage

Как выбрать дисковый контроллер для VMware vSAN?


Многие администраторы больших виртуальных инфраструктур VMware vSphere, в которых работают кластеры отказоустойчивых хранилищ VMware vSAN, часто задаются вопросом, какой дисковый контроллер выбрать для организации хранения на хостах ESXi.

Дункан Эппинг дает простую рекомендацию - надо брать один из самых недорогих поддерживаемых контроллеров, который имеет большую глубину очереди (Queue Depth). Например, часто в рекомендациях для vSAN можно встретить контроллер Dell H730, который является весьма дорогим устройством, если брать его на каждый сервер.

Но его не обязательно покупать, достаточно будет дискового контроллера Dell HBA 330, который и стоит дешевле, и глубину очереди имеет в 10 раз больше, чем H730 (хотя оба они соответствуют требованиям vSAN). Да, у H730 есть кэш на контроллере, но он в данном случае не требуется. Лучше использовать интерфейс NVMe для подключения отдельного SSD-кэша, не затрагивающего RAID-контроллеры (его нужно размещать как можно ближе к CPU).

Поэтому итоговая рекомендация по выбору дискового контроллера для кластеров vSAN проста - берите любое недорогое устройство из списка совместимости vSAN Compatibility Guide, но с хорошей глубиной очереди (например, HP H240), а на сэкономленные деньги отдельно организуйте кэш на базе NVMe.


Таги: VMware, SSD, Hardware, vSAN, NVMe, Storage

Что нового будет в Virtual Volumes (VVols) в следующей версии VMware vSphere?


На прошедшей конференции VMworld 2017 в рамках сессии "VMware Virtual Volumes Technical Deep Dive" компания VMware рассказала о технических аспектах технологии VVols, а также возможностях, которые появятся в следующей версии платформы виртуализации VMware vSphere:

Самый интересный слайд показывают в конце презентации:

Во-первых, надо отметить, что следующая версия vSphere будет иметь номер 6.7, а, во-вторых, давайте посмотрим на три фичи, которые появятся в VVols, подетальнее:

  • Support for Microsoft Cluster Server (MSCS) – это была одна из причин, по которой администраторы до сих пор используют RDM, а этот вариант использования не поддерживается со стороны VVols. Данная поддержка позволит расширить сферу использования технологии.
  • Performance parity with VMFS – в данном случае цель VMware - обеспечить высокую производительность VVols, поскольку сейчас есть промежуточный компонент Protocol Endpoint, который замедляет работу подсистемы ввода-вывода. Также будут оптимизированы такие операции как bind, соединения VASA, а также обработка метаданных томов VVols. Кстати, в целом-то VVols должна работать даже побыстрее, чем VMFS.
  • IPv6 support – платформа vSphere уже давно поддерживает IPv6, а сами VVols будут поддерживать IPv6 на уровне службы VASA Provider.

Поддержка NFS 4.1 и операций BIND/UNBIND/REBIND. Сейчас они делаются через VASA provider, которые идут через control path, поэтому медленные, а будут работать через Protocol Endpoint (то есть data path, что быстрее).

Будем следить за новостями о новых возможностях VMware vSphere 6.7.


Таги: VMware, vSphere, VVols, Storage, Update

Переделка "толстых" файлов подкачки виртуальных машин в кластере VMware vSAN на "тонкие".


Некоторые из вас знают, что, начиная с версии vSAN 6.2, стало возможно создание "тонких" (thin) файлов подкачки. В более ранних версиях vSAN было возможно создавать только reserved своп-файлы, что требовало довольно больших объемов дисковой памяти. То есть, если у машины 16 ГБ оперативной памяти, то в два раза больше будет занято и на диске под своп (32 ГБ), так как при FTT=1 (failures to tolerate) дисковые объекты дублируются в рамках кластера.

Поэтому для сред, в которых достаточно памяти у хостов, и отсутствует Memory Overcommitment, сделали параметр в настройках кластера SwapThickProvisionDisabled, позволяющий виртуальным машинам создавать тонкие файлы подкачки.

Чтобы выставить эту настройку, есть специальный скрипт PowerCLI, который применяет ее ко всем хостам ESXi кластера vSAN.

Однако выставить настройку недостаточно - ведь, чтобы файлы подкачки стали тонкими, то есть пересоздались, надо перезагрузить (выключить и включить) виртуальные машины с толстыми swap-файлами. Найти такие машины позволит вот этот Python-сценарий. Ну а дальше уже перезагрузите машины по списку - это позволит вам сэкономить значительный объем дискового пространства кластера.


Таги: VMware, vSAN, Storage, ESXi, VMachines

Как конфигурировать Storage DRS кластеры с PowerCLI – Часть 1.


Несмотря на растущую популярность технологии VMware vSAN, большинство крупных предприятий по-прежнему частично или полностью продолжают работать с общими хранилищами (shared storage). Есть достаточно PowerCLI командлетов для конфигурирования большинства аспектов HA/DRS кластеров, однако для SDRS кластеров выбор не велик.


Таги: VMware, PowerCLI, SDRS, Storage

Улучшения производительности VMware vSAN 6.6 по сравнению с 6.5.


Весной этого года вышло обновление решения для создания отказоустойчивых кластеров для виртуальных машин на платформе vSphere - VMware vSAN 6.6. Прошлая версия продукта Virtual SAN 6.5 вышла еще осенью 2016 года, и vSAN 6.6 заметно продвинулся в плане функционала. Но, оказывается, это решение стало еще и существенно лучше в плане производительности. И на эту тему есть полезный документ "vSAN 6.6 Performance Improvements", описывающий результаты тестирования обеих версий продукта.

Для тестов использовалось одинаковое оборудование (кластер All-Flash) и 3 типа симуляции рабочей нагрузки:

  • Random Read
  • Random Write
  • Mixed random Read/Write (70/30%)

Посмотрим на графики, показывающие улучшения в различных аспектах:

Большое рабочее множество данных (Large Working Set)

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

Так выглядит суммаризованный график улучшения по числу IOPS для трех типов нагрузок и различных уровнях RAID:

Вот так выглядит уменьшение задержек при обращении к дискам (Latency). Чем ниже столбик - тем сильнее уменьшилась задержка:

Так выглядит отдельный график по IOPS для типа нагрузки 70% чтения и 30% записи:

Так выглядит Latency для этого типа нагрузки:

IOPS для Random Writes:

Latency для Random Writes:

Малое рабочее множество данных (Small Working Set)

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

Так выглядит суммаризованный график улучшения по числу IOPS для трех типов нагрузок и различных уровнях RAID (заметьте, что процент улучшений здесь значительно выше, чем для Large Working Set):

Вот так выглядит уменьшение задержек при обращении к дискам (Latency). Чем ниже столбик - тем сильнее уменьшилась задержка (также улучшения более существенны, чем для Large Working Set):

Так выглядит отдельный график по IOPS для типа нагрузки 70% чтения и 30% записи:

Так выглядит Latency для этого типа нагрузки:

IOPS для Random Writes:

Latency для Random Writes:

В целом, мы видим, что по всем параметрам и для всех аспектов (рабочее множество, тип нагрузки, уровень RAID) решение vSAN 6.6 обходит своего предшественника (а в некоторых случаях - весьма существенно).


Таги: VMware, vSAN, Performance, Storage

Обзор бесплатного продукта StarWind Manager для мониторинга кластеров Storage Spaces Direct и не только.


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


Таги: StarWind, Manager, Storage, Microsoft, Spaces, S2D, Virtual SAN

VMware vSAN Sizer - утилита для подбора оборудования и расчета объема хранилищ под кластеры vSAN.


Компания VMware сделала доступной небольшую онлайн-утилиту для сайзинга серверов хранения виртуальных машин, работающих в отказоустойчивых кластерах хранилищ - VMware vSAN Sizer. Также она производит подбор необходимых конфигураций серверов (для расчетов принимается, что все узлы будут использовать конфигурацию All-Flash SSD).

VMware vSAN Sizer доступен по адресу: https://vsansizer.vmware.com/

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

На первом этапе нам показывают, сколько нужно серверов и неразмеченного хранилища (Raw Storage):

Ниже мы видим технические характеристики каждого из хостов ESXi:

Ну а в рамках дополнительной информации можно вывести параметры дисковых групп (кэш и емкость хранения). В моем случае это 2 дисковых группы:

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


Таги: VMware, vSAN, Sizing, VMachines, Storage, Hardware

VMware vSAN 6.6 Configuration Assist - помощь в настройке среды для кластеров хранилищ.


В статье о новой версии продукта для организации отказоустойчивых кластеров хранилищ vSAN 6.6 мы писали о том, что появилась утилита Configuration Assist, созданная для того, чтобы после установки кластера правильно сконфигурировать среду vSphere, чтобы все работало корректно и соответствовало необходимой конфигурации платформы.

Первоначальные задачи по настройке кластера, развертываемого через Easy Install или vSphere Web Client, включают в себя настройку порта VMkernel для трафика vSAN, выделение дисков и т.п. Как часть процесса установки, мастер vSAN Setup Wizard заботится о таких специфических вещах, как дедупликация и компрессия, число узлов, растянутый это будет кластер или нет, но не заботится об общих настройках среды VMware vSphere.

Для этого и был сделан раздел vSAN Configuration Assist, который вам поможет со следующими операциями:

  • Настройка высокой доступности vSphere High Availability.
  • Настройка балансировщика vSphere Distributed Resource Scheduler (DRS).
  • Конфигурация vSphere Distributed Switch для трафика vSAN.
  • Настройка vMotion для ВМ.
  • Позволит убедиться в том, что все доступные накопители используются для кластера.
  • Есть средства конфигурации хостового контроллера.
  • Есть необходимая версия микрокода (firmware) хостового контроллера.

Все эти задачи можно выполнить из различных разделов vSphere Web Client, но мастер Configuration Assist позволяет сделать это в единой точке интерфейса как часть рабочего процесса по конфигурации кластера vSAN. Ну и важный момент, что это своего рода чеклист необходимых задач постконфигурации кластера хранилищ.

Вот как это примерно делается (приведен пример, как настроить для vSAN или vMotion интерфейсы VMKernel):

Выделение дисков под кластер идет в момент его развертывания, но после установки это уже можно сделать через Configuration Assist:

Конечно же, необходима настройка vSphere HA/DRS:

Ну и последнее, но не менее важное - утилита позволяет вам обновлять микрокод узлов различных OEM-производителей, таких как Dell, Lenovo, Fujitsu и SuperMicro:

Поэтому первым делом после развертывания кластера vSAN идите в раздел Configuration Assist клиента Web Client.


Таги: VMware, vSAN, vNetwork, VMachines, Storage, HA, Web Client

Вышел кастомизированный образ HPE Customized ESXi May 2017.


Оказывается, еще в начале мая компания HP совместно с VMware выпустила кастомизированный образ гипервизора vSphere - HPE Customized ESXi May 2017, предназначенного для установки на серверы HP.

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

HPE Customized ESXi May 2017 доступен для скачивания по этой ссылке. Предыдущие образы (для более ранних версий гипервизора) можно также скачать с сайта VMware по этим ссылкам:

Номера билдов и их содержимое приведены вот в этом документе HPE (там же есть ссылки на соответствующие драйвера и офлайн бандлы ESXi). Ну а руководство по кастомизированным билдам HPE Custom ESXi находится вот тут.


Таги: HP, ESXi, Update, VMware, vSphere, Hardware, Storage, Bugs

Новая версия продукта StarWind Virtual SAN Free - полная функциональность бесплатно!


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


Таги: StarWind, Virtual SAN, Бесплатно, Storage, iSCSI, NFS

StarWind Virtual SAN в виде виртуального модуля на базе Linux.


Многие пользователи небольших виртуальных инфраструктур ищут надежные решения для организации программных хранилищ, при этом им бы не хотелось покупать отдельную лицензию на Windows Server под узлы хранения.

Специально для них компания StarWind, известная своим продуктом Virtual SAN, позволяющим организовать отказоустойчивые кластеры хранилищ, создала виртуальный модуль StarWind Virtual Storage Appliance (VSA) на базе Linux.

Сегодня в 21-00 по московскому времени StarWind проведет бесплатный вебинар "StarWind Virtual Storage Appliance – now on Linux", где будет рассказано об этом новом продукте компании:

StarWind VSA представляет собой полностью готовую к импорту в вашу виртуальную среду виртуальную машину, реализующую все необходимые сервисы Virtual SAN. Развертывается она буквально в пару кликов, а далее управляется через удобную веб-консоль (StarWind Web console).

Чтобы узнать больше о возможностях продукта и вживую увидеть его демонстрацию (а также позадавать вопросы на русском языке) - регистрируйтесь на вебинар. Скачать StarWind Virtual Storage Appliance можно по этой ссылке.


Таги: StarWind, VSA, Virtual Appliance, Storage, Webinar

Как планировать дисковые емкости для растянутых кластеров VMware vSAN 6.6 (Stretched Clusters).


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

Напомним, что для этого теперь есть 2 политики: Primary level of failures to tolerate (PFTT) и Secondary level of failures to tolerate (SFTT). Для растянутого кластера PFTT определяет защиту между площадками, реализуемую по схеме RAID-1. А политика SFTT для растянутого кластера определяет защиту на уровне локального сайта, которая может быть реализована по схеме RAID-1 (на обычных дисках), а также RAID-5 или RAID-6 (для архитектуры All-Flash).

Это, кстати, означает, что при полном отказе одного из сайтов растянутого кластера, виртуальные машины выжившего сайта все еще будут защищены на уровне отдельных хостов или виртуальных дисков. Единственное, что для этого компонент Witness должен быть доступен. Ну и, само собой, при отказах дисков/хостов внутри площадки виртуальные машины также будут защищены в соответствии с политикой SFTT.

Все это вызывает логичный вопрос - а как планировать емкость обеих площадок, на которых работает vSAN? Кстати, нельзя называть эти площадки основной и резервной, так как они работают в режиме Active-Active.

Традиционно, до введения политик избыточности на уровне каждой из площадок, планирование емкости было простым - надо было просто удвоить исходную емкость одной площадки. В vSAN 6.2 появилась не только защита RIAD-1 (mirroring), но и RIAD-5/6 (erasure coding), что позволяет в рамках растянутых кластеров организовать различные схемы размещения данных. Отметим, что алгоритм erasure coding между площадками пока не реализуем ввиду ограничений на уровне домена отказа (Fault Domain). Поэтому между площадками - только Mirroring.

Учитывая все это, в VMware сделали единую табличку, которая поможет вам при планировании емкостей инфраструктуры vSAN как для растянутого кластера, так и для кластера в рамках одной площадки:

В поле PFTT для растянутых кластеров мы видим 1, а для обычных 0. FTM (Failure Tolerance Mode) - это режим обеспечения отказоустойчивости на уровне каждого из сайтов. Напомним, что для обычных дисков он может быть только Mirroring, а для All-Flash архитектур - Mirroring или Erasure Coding.

SFTT определяет число отказов дисковых объектов внутри площадки, которое сможет перенести каждая из площадок вашего растянутого кластера.

Таким образом, если вы организуете растянутый кластер хранилищ на базе архитектуры All-Flash со средствами защиты Erasure Coding в рамках площадки и Mirroring между площадками, то вам потребуется 266% исходной дисковой емкости виртуальных машин (ее можно скорректировать на экономию от Thin Provisioning).

Ну а если вы будете использовать обычные диски и защиту Mirroring как внутри площадки, так и между площадками - вам потребуется 400% исходной емкости.

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


Таги: VMware, vSAN, Storage, Enterprise, Stretched

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18    >   >>
Реклама



Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

06/03/2018:  ИТ-стратегия 2018
24/05/2018:  IT&SECURITY FORUM (Казань)

Быстрый переход:
VMware IT-Grad StarWind Enterprise Citrix Security Code Offtopic Veeam Cisco vGate Microsoft Cloud SDRS Parallels IaaS 5nine HP VeeamON VMFS RVTools PowerCLI VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo Nutanix vRealize VirtualBox Symantec Gartner Softline EMC Login VSI Xen Teradici Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter VMachines Webinar View VKernel Events Hardware Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell vSphere IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V vCloud vCSA Horizon DRS Visio NSX Intel OpenStack vSAN Agent Backup Tools Networking esxtop VVols HA Book Photon VMworld vROPs Labs Fusion Cloud Computing SSD Client Comparison Workstation Blast SRM App Volumes Performance Manager Nested AWS Log Insight XenDesktop VSA vNetwork SSO LSFS Workspace Host Client VMDK VTL Update iSCSI SDDC Virtual Appliance Whitepaper PowerShell Appliance VUM V2V Cache Support Обучение Web Client Mobile Automation Replication Desktop Fault Tolerance DR Vanguard SaaS Connector Event Free Datacenter SQL VSAN Lifecycle Sponsorship Finance FT Converter XenApp Snapshots VCP Auto Deploy SMB RDM Mirage XenClient MP Video Operations SC VMM Certification VDP Partners PCoIP RHEV vMA Award Network USB Licensing Logs Server Demo vCHS Calculator Бесплатно vExpert Beta SAN Exchange MAP ONE DaaS Monitoring VPLEX UCS SDK Poster VSPP Receiver vMotion VDI-in-a-Box Deduplication Forum Reporter vShield ACE Go nworks iPad XCP Data Recovery Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Graphics Director Migration Diagram Bug Troubleshooting Air API CLI Plugin DPM Memory Upgrade SIOC Flex Mac Open Source SSH VAAI Chargeback Heartbeat Android MSCS Ports SVMotion Storage DRS Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Сравнение Oracle VirtualBox и VMware Workstation.

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Как использовать возможности VMware vSphere Management Assistant (vMA).

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Отличия VMware ESXi 4 free (бесплатного), ESXi 4 и ESX 4 в составе VMware vSphere.

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2018, Александр Самойленко. Правила перепечатки материалов.