На сайте проекта VMware Labs появилась новая интересная Open Source утилита - Distributed Trust Incident Reporting. Она предназначена для документирования инцидентов в сфере информационной безопасности, которое часто осуществляется на бумаге или в Excel даже в крупных компаниях. Некоторые системы имеют централизованную базу данных инцидентов с возможностью отслеживания ответных мер, принятых в качестве реакции на инцидент, но только на уровне собственного предприятия.
Текущие подходы по мнению VMware обладают рядом недостатков:
- Инцидент может затронуть несколько сущностей/компаний с разной ответственностью.
- Все они должны как-то отреагировать на него.
- Некоторые сущности не имеют доверия к другим.
- Нет одной стороны, которая отвечает за эксплуатацию всей системы с точки зрения безопасности.
Примером такого инцидента является нарушение процесса у производителя еды, в результате которого на полку розничной сети в продукт попадает опасный патоген. В этом случае следует серия звонков или писем от ритейлера к дистрибьютору, а далее к производителю, чтобы отреагировать на инцидент.
Утилита Distributed Trust Incident Reporting позволяет:
- Увидеть всем сторонам процесса зафиксированный инцидент.
- Позволяет всем сторонам отреагировать, как того требует ситуация и зафиксировать это.
- Принимает на вход отчеты информационных систем об инцидентах.
- Добавляет прозрачности между разными сущностями/организациями.
Работает это все на базе контейнеров Docker, а технологическую платформу фиксирования инцидентов предоставляют решения VMware blockchain или Ethereum blockchain.
Неясно, будет ли кто-то использовать эту систему от VMware, но, будем надеяться, она со временем интегрируется в существующую экосистему решений вендора для организации и эксплуатации виртуальной инфраструктуры на платформе vSphere.
Проект Distributed Trust Incident Reporting доступен для скачивания из репозитория GitHub.
Читать далее... - читать дальше и комментировать
|
Недавно мы писали о выходе обновленной версии решения для обеспечения катастрофоустойчивости виртуальных датацентров VMware Site Recovery Manager 8.2. Многие пользователи после ее релиза задались вопросом миграции на виртуальный модуль (Virtual Appliance), который построен на базе операционной системы Photon OS и управляется через веб-браузер.
Давайте вкратце рассмотрим этот процесс. В целом процедура миграции выглядит так:
- Убеждаемся, что ваш SRM на базе Windows обновлен до версии 8.2.
- Экспортируем конфигурацию и останавливаем SRM на хосте с Windows.
- Развертываем Site Recovery Manager Virtual Appliance и импортируем туда конфиг.
Пошагово этот процесс будет таким:
1. Логинимся в Site Recovery Manager for Windows, открываем командную строку и переходим в папку %SRM_INSTALL_DIR%\bin.
2. Запускаем следующий скрипт, он потребует ввод пароля администратора:
export-srm-data.bat
3. Экспортированную папку перемещаем на виртуальный модуль SRM.
4. Выключаем машину с SRM для Windows и логинимся как root в SRM VA.
5. Если вы создавали кастомные сертификаты, то их надо положить в папку /etc/ssl/certs (это файлы с расширением .pem). Импортировать сертификаты можно через Site Recovery Manager Appliance Management Interface.
Для изменения прав доступа к сертификатам используйте команду:
chmod a+r <new-root-ca>.pem
Далее выполните:
c_rehash
6. После этого запустите импорт окружения SRM, указав папку, которую вы экспортировали из Windows-окружения:
/opt/vmware/srm/bin/import-srm-data.sh <export_dir>
7. Вас попросят пароль администратора vCenter Single Sign-On, root виртуального модуля, а также пароль от файла, который был задан при экспорте конфигурации.
8. На вкладке Home веб-консоли решения SRM VA выберите импортированную пару сайтов и нажмите Actions > Reconnect. Выберите первый сайт из списка, введите адрес Platform Services Controller сервера SRM на резервной площадке и введите имя пользователя и пароль.
9. Далее вас попросят выбрать сервер vCenter, который нужно настроить и его сервисы, где вы просто нажимаете Next, а потом Finish.
Также весь этот процесс описан вот тут.
Читать далее... - читать дальше и комментировать
|
Недавно мы писали об обновлении продукта для комплексного управления и мониторинга виртуальной инфраструктуры VMware vRealize Operations 7.5. Ранее для этого решения был запущен маркетплейс Dashboard Sample Exchange, где пользователи сообщества vROPs могут публиковать собственные полезные дэшборды (их уже почти 130 штук), которые помогают в ежедневных операциях по управлению платформой VMware vSphere.
Совсем недавно VMware запустила еще один маркетплейс - Super Metric Sample Exchange. В инфраструктуре vROPs суперметрики (super metrics) - это те, которые образованы путем каких-либо комбинаций обычных метрик через математическую формулу (например, какой процент CPU виртуальная машина отъедает от всего хоста ESXi). Для редактирования таких метрик используется super metric editor (подробнее тут):
Чтобы начать работу с маркетплейсом, нужно перейти на сайт vRealize и нажать кнопку View Samples:
В качестве фильтра для языка программирования выберите "vRealize Ops Super Metrics":
Еще один способ найти суперметрики - это пойти на https://code.vmware.com/samples и также выбрать там в фильтре "vRealize Ops Super Metrics":
На выходе будут сэмплы кода для суперметрик (пока их совсем немного):
Можно скачать их в формате JSON, после чего импортировать в разделе vRealize Operations > Administration > Configuration > Super Metrics:
Также вы можете добавлять и собственные суперметрики на маркетплейс. Для этого на картинке выше есть пункт "Export Selected Super Metric". Метрика также будет экспортирована в формате JSON. Для ее загрузки на маркетплейс нужно использовать портал VMware {code}, где вам потребуется завести аккаунт.
Там у вас будет кнопка "Add New Sample":
После этого запустится мастер добавления нового сэмпла, где вы можете выбрать ваш JSON:
Далее нужно добавить максимально понятное и подробное описание созданной вами суперметрики:
Вообще, это очень правильный подход, когда вендор открывает возможности для создания и обмена контентом между пользователями своего продукта. Тут VMware можно похвалить.
Читать далее... - читать дальше и комментировать
|
Коллеги Rhys Hammond и Rose Herden выпустили неофициальное бесплатное руководство для подготовки к сертификации VMCE Study Guide (оно было сделано на базе их доклада на VeeamON 2017). Книжку можно скачать бесплатно, если ползунок справа в разделе цены установить на 0 (но можете и пожертвовать сколько-то за скачанный документ, если он вам понравится).
В рецензировании книги принимали участие члены сообщества Veeam Vanguards, которое объединяет технических профессионалов по всему миру, продвигающих технологии Veeam в массы.
Напомним, что компания Veeam Software известна своим главным в отрасли средством для резервного копирования и репликации виртуальных машин Veeam Backup and Replication.
VMCE (Veeam Certified Engineer) - это сертификация для инженеров, которая подтверждает знания и навыки работы с платформой по обеспечению бесперебойного функционирования виртуальных датацентров Veeam Availability Suite V9. Экзамен представляет собой 50 случайных вопросов из базы знаний об этой платформе, для успешной его сдачи нужно ответить правильно на 70% заданий.
Руководство занимает 56 страниц и доступно в форматах PDF и epub. Скачать VMCE Study Guide можно по этой ссылке. Читать далее... - читать дальше и комментировать
|
Недавно мы писали об утилите для тестирования производительности хранилищ HCIBench 2.0, которая помогает администраторам VMware vSphere валидировать конфигурацию кластера с точки зрения соответствия требованиям к производительности подсистемы хранения для приложений датацентра.
HCIBench используется для проведения синтетических тестов кластера хранилищ, когда нагрузка распределяется по нескольким виртуальным машинам на разных хостах ESXi. Генерация операций ввода-вывода происходит одновременно с разных ВМ согласно заранее определенному шаблону нагрузки.
А зачем вообще проводить тестирование кластера vSAN? Тут, как правило, есть следующие причины:
- Понимание возможностей инфраструктуры хранения и возможность убедиться в том, что в ней нет аномалий.
- Валидировать дизайн кластера vSAN с точки зрения приемо-сдаточных испытаний (User Acceptance Testing, UAT).
- Получить референсные значения, с которыми можно будет сверяться при внесении существенных изменений в архитектуру vSAN.
- Проведение тестов перед внедрением (PoC-проекты).
- Установление базового уровня пользовательских ожиданий после развертывания приложений.
По итогу тестирования производительности хранилищ vSAN вы должны получить ответы на следующие вопросы:
- Какого наибольшего числа операций ввода-вывода в секунду (IOPS) можно добиться?
- Какая ожидаемая задержка выполнения операций (latency) при требуемом числе IOPS для рабочей нагрузки?
- Какая максимальная пропускная способность операций чтения-записи (throughput)?
То есть результаты тестирования держатся на трех китах - IOPS, latency и throughput.
При проведении тестов нужно отключать все тормозящие технологии, такие как дедупликация и компрессия данных, а также шифрование на уровне кластера vSAN.
IOPS
Число выдаваемых IOPS зависит как от используемого оборудования для хостов и сетевых компонентов, так и от архитектуры системы. Актуальное число IOPS также зависит от уровня RAID в кластере vSAN, числа сетевых соединений между хостами, их загрузки и прочих факторов.
Обычно начинают тестирование с нескольких тредов на дисковый объект, а затем постепенно увеличивают это количество тредов, пока число выдаваемых IOPS не прекратит расти. При проведении тестирования число IOPS коррелирует с Latency, так как при увеличении одной операции ввода-вывода (размер блока операции) уменьшается число выдаваемых IOPS, а также увеличивается latency.
Latency
Обычно задержку измеряют в миллисекундах со стороны приложений, которые выполняют определенные операции. При этом, зачастую, нет каких-то референсных значений, их приходится выяснять экспериментальным путем (насколько это устраивает пользователей).
К увеличению задержек при выполнении операций приводят увеличение блока ввода-вывода, соотношение операций чтения и записи, одновременность исполнения операций ввода-вывода со стороны нескольких виртуальных машин и т.п.
Throughput
Пропускная способность важна при выполнении больших операций ввода-вывода, а также при различных паттернах чтения записи (последовательный/случайный). Чем больше размер I/O, тем очевидно больше пропускная способность. С точки зрения объема передаваемых данных одна операция I/O размером 256К равна 64 операциям ввода-вывода по 4К, но вот с точки зрения throughput это будут совершенно разные значения, так как займут разное время.
Методология тестирования хорошо описана в документации по HCIBench, а также вот в этой статье на русском языке. Работа с утилитой начинается по ссылке https://<HCIBench IP address>:8443.
Перед началом тестирования можно задать параметры среды - число виртуальных машин для кластера, количество их виртуальных дисков и их размер. Для ленивых есть параметр Easy Run, который позволит автоматически подобрать эту конфигурацию, исходя из размера кластера vSAN и параметров хостов ESXi:
Очень важно при тестировании также задать правильный профиль рабочей нагрузки (4 варианта на картинке выше).
После выполнения теста Easy Run вы получите выходной файл с результатами вроде vdb-8vmdk-100ws-4k-70rdpct-100randompct-4threads-xxxxxxxxxx-res.txt. Из имени файла можно понять использованную тестовую конфигурацию (она также будет в самом файле):
Block size : 4k
Read/Write (%) : 70/30
Random (%) : 100
OIO (per vmdk) : 4
Также в папке с результатами тестирования будет подпапка с отдельными файлами, где хранятся результаты самих тестов:
Если открыть один их этих файлов, мы увидим детальные параметры производительности различных компонентов среды vSAN:
Полученные параметры можно считать базовым уровнем для тестирования производительности кластера. Теперь нужно увеличивать параллелизм, то есть число тредов Outstanding I/O (OIO), для выжимки оптимальной производительности. Увеличение этого параметра будет увеличивать число IOPS, а также, как следствие, будет расти Latency. Так вы сможете понять, как инфраструктура хранения ведет себя в динамике, реагируя на изменение профиля нагрузки.
Чтобы изменить параметр OIO, нужно отключить Easy Run и в профиле рабочей нагрузки нажать Add:
Также для измерения пропускной способности вы можете поэкспериментировать с размером операции ввода-вывода. Современные ОС поддерживают размер I/O в диапазоне 32K - 1 MB, но для тестирования лучше использовать I/O в диапазоне 32K – 256K.
Еще какие моменты надо учитывать при тестировании:
- Синтетическое тестирование не учитывает, что профиль рабочей нагрузки в кластере в реальной жизни постоянно изменяется точки зрения соотношения операций чтения и записи и их рандомизации в потоке ввода-вывода. Используемая модель - всего лишь аппроксимация.
- Тесты ориентированы на отслеживание характеристик хранилищ, а не загрузки CPU и памяти хостов ESXi.
Читать далее... - читать дальше и комментировать
|
Некоторое время назад мы писали о новых возможностях недавно вышедшего обновления платформы виртуализации VMware vSphere Platinum 6.7 Update 2. Cреди новых возможностей гипервизора там есть фича "Новые возможности планировщика CPU помогают бороться с уязвимостями типа L1TF".
Оказывается, это довольно серьезное улучшение. Надо сказать, что планировщик гипервизора side-channel aware scheduler (SCA) появился еще в прошлой версии платформы. Он закрывал уязвимость L1TF (L1 Terminal Fault) в процессорах Intel за счет того, что процессы виртуальных машин запускались только в одном треде одного физического ядра. Это позволяло нивелировать вектор атаки данного типа, но приводило к существенному снижению производительности.
Особенно это чувствовалось, когда сервер ESXi был загружен по CPU полностью, и SCA первой версии в этом случае давал до 30% хуже результат, чем без него. Если же сервер был загружен, например, на 75%, то в производительность оставалась примерно той же, но без SCA нагрузка на CPU была существенно ниже.
Обо всем этом подробно описано в документе "Performance of vSphere 6.7 Scheduling Options":
Давайте вкратце посмотрим, о чем там говорится.
Итак, начиная с VMware vSphere 6.7 Update 2, появился обновленный планировщик SCAv2, который был существенно доработан по сравнению со своей предыдущей версией. Он позволяет исполнять контексты vCPU одной машины в разных гипертредах одного физического ядра процессора хоста. В этом случае атаке L1TF не подвержены взаимодействия типа VM/VM и VM/ESXi (чувствительная информация между ними не шарится в общем кэше).
В документе описано 2 типа тестов, которые проводились для планировщиков SCAv1 и SCAv2: работа хоста под максимальной нагрузкой по процессорам и под нагрузкой на уровне 75% от максимальной мощности всех CPU хоста ESXi (reduced load). В качестве базового уровня использовался планировщик без SCA (он же на картинке ниже обозначен как Default):
Если верить графикам, отражающим результаты тестирования различными бенчмарками, то планировщик SCAv2 работает существенно лучше во всех случаях, кроме очень большой (по выделенным ресурсам) виртуальной машины - Monster VM с базой Oracle и 192 vCPU, но такой кейс в реальной жизни случается весьма редко. Так что, в целом, улучшения были проведены весьма существенные (как минимум, на 11% планировщик стал более производительным по результатам тестов).
Помимо документа выше, информация об улучшениях планировщика приведена еще в KB 55806. Читать далее... - читать дальше и комментировать
|
Многие из вас, конечно же, прекрасно знают, как работает механизм VMware HA на платформе vSphere. Но для тех из вас, кто подзабыл, Дункан написал пост о том, через какой интерфейс VMkernel идет этот трафик.
Так вот, хартбиты механизма HA пойдут через тот vmk-интерфейс, на котором в vSphere Client отмечена галочка Management, как на картинке:
Надо понимать, что этот пункт, хоть и называется Management, имеет отношение только к HA-трафику. Это означает, что если галочка не отмечена, то через этот интерфейс все равно можно будет подключиться по протоколу SSH, а также присоединить хост ESXi к серверу управления VMware vCenter, используя этот IP-адрес.
Так что Management - это не про управление, а только про HA. Это касается только обычной виртуальной инфраструктуры, а вот в кластере vSAN трафик HA идет по выделенной под vSAN сети автоматически.
Читать далее... - читать дальше и комментировать
|
На днях компания VMware выпустила новую версию решения для обеспечения катастрофоустойчивости виртуальных датацентров VMware Site Recovery Manager 8.2. Напомним, что прошлая версия SRM 8.1 вышла довольно давно - аж в апреле прошлого года.
Главное нововведение данного обновления - это отказ от Windows и переход на виртуальный модуль (Virtual Appliance) на базе гостевой ОС Photon. Правда установщик под Windows пока еще доступен, но, скорее всего, его уже не будет в следующих версиях.
Давайте посмотрим, что еще нового появилось в новой версии VMware SRM 8.2:
- Полная совместимость с платформой виртуализации VMware vSphere 6.7 Update 2.
- Улучшения интерфейса управления на базе HTML5:
- Утилита SRM Configuration Import/Export Tool теперь доступна прямо из консоли решения.
- Теперь можно выбирать цветовые схемы пользовательского интерфейса, включая темную тему, которая показана на скриншоте выше.
- Отображение информации о емкости на влкадке Protection Groups Datastores.
- Возможность дать фидбэк в VMware касательно нового интерфейса.
- Улучшения публичного API:
- Возможность отсылать логи SRM на удаленный syslog-сервер.
- Поддержка шифрования сетевого трафика для vSphere Replication 8.2.
Скачать VMware Site Recovery Manager 8.2 (как в виде виртуального модуля, так и в виде установщика для Windows) можно уже сейчас по этой ссылке. Читать далее... - читать дальше и комментировать
|
Мы много пишем о решении для организации отказоустойчивых хранилищ на базе хостов ESXi - платформе VMware vSAN. Сегодня мы расскажем о дисковых группах на основе вот этого поста на блогах VMware.
Архитектура vSAN включает в себя два яруса - кэш (cache tier) и пространство постоянного хранения (capacity tier). Такая структура дает возможность достичь максимальной производительности по вводу-выводу, которая абсолютно необходима в кластере хранилищ на базе хостов.
Чтобы управлять отношениями устройств кэша и дисков хранения, решение vSAN использует дисковые группы:
У дисковых групп есть следующие особенности:
- Каждый хост, который дает емкость кластеру vSAN, должен содержать как минимум одну дисковую группу.
- Дисковая группа содержит как минимум одно устройство для кэша и от 1 до 7 устройств хранения.
- Каждый хост ESXi в кластере vSAN может иметь до 5 групп, а каждая группа - до 7 устройств хранения. То есть на хосте может быть до 35 устройств хранения, чего вполне достаточно для подавляющего большинства вариантов использования.
- Неважно, используете ли вы гибридную конфигурацию (SSD и HDD диски) или All-Flash, устройство кэширования должно быть Flash-устройством.
- В гибридной конфигурации устройства кэша на 70% используются как кэш на чтение (read cache) и на 30% как кэш на запись (write buffer).
- В конфигурации All-Flash 100% устройства кэша выделено под write buffer.
Write buffer и capacity tier
В принципе, всем понятно, что гибридная конфигурация хостов ESXi в кластере vSAN более дешевая (HDD стоит меньше SSD), но менее производительная, чем All-Flash. Но когда-то наступит время, и все будет All-Flash (в них, кстати, еще и нет нужды организовывать кэш на чтение, так как все читается с SSD с той же скоростью). Поэтому и выделяется 100% под write buffer.
При этом если операция чтения в All-Flash хосте находит блок в кэше - то он читается именно оттуда, чтобы не искать его в capacity tier. Максимальный размер write buffer на одной дисковой группе хоста ESXi - 600 ГБ. При этом если сам диск более 600 ГБ, то его емкость будет использоваться с пользой (см. комментарий к этой статье).
Для гибридных конфигураций 70% емкости кэша выделяется под кэш на чтение, чтобы быстро получать данные с производительных SSD-устройств, при этом vSAN старается поддерживать коэффициент попадания в кэш на чтение (cache hit rate) на уровне 90%.
Write buffer (он же write-back buffer) подтверждает запись на устройство хранения еще до актуальной записи блоков на сapacity tier. Такой подход дает время и возможность организовать операции записи наиболее эффективно и записать их на сapacity tier уже пачкой и более эффективно. Это дает существенный выигрыш в производительности.
SSD-устройства бывают разных классов, в зависимости от их выносливости (среднее число операций записи до его отказа). Все понятно, что для кэширования нужно использовать устройства высоких классов (они дорогие), так как перезапись там идет постоянно, а для хранения - можно использовать недорогие SSD-диски.
Вот сравнительная таблица этих классов (колонка TBW - это terabytes written, то есть перезапись скольких ТБ они переживут):
Помните, что нужно всегда сверяться с VMware Compatibility Guide, когда выбираете устройства PCIe flash, SSD или NVMe.
vSAN содержит в себе несколько алгоритмов, которые учитывают, как часто write buffer сбрасывает данные на сapacity tier. Они учитывают такие параметры, как емкость устройств, их близость к кэшу по времени записи, число входящих операций ввода-вывода, очереди, использование дискового устройства и прочее.
Организация дисковых групп
При планировании хостов ESXi в кластере vSAN можно делать на нем одну или более дисковых групп. Несколько дисковых групп использовать предпочтительнее. Давайте рассмотрим пример:
- Одна дисковая группа с одним кэшем и 6 устройств хранения в ней.
- Две дисковых группы с двумя устройствами кэша, в каждой по 3 устройства хранения.
Если в первом случае ломается SSD-устройство кэша, то в офлайн уходит вся дисковая группа из 6 дисков, а во втором случае поломка одного девайса приведет к выходу из строя только трех дисков.
Надо понимать, что этот кейс не имеет прямого отношения к доступности данных виртуальных машин, которая определяется политикой FTT (Failures to tolerate) - о ней мы подробно рассказывали тут, а также политиками хранилищ SPBM. Между тем, размер домена отказа (failure domain) во втором случае меньше, а значит и создает меньше рисков для функционирования кластера. Также восстановление и ребилд данных на три диска займет в два раза меньше времени, чем на шесть.
Кстати, некоторые думают, что в случае отказа дисковой группы, кластер vSAN будет ждать 60 минут (настройка Object Repair Timer) до начала восстановления данных на другие диски согласно политике FTT (ребилд), но это неверно. Если вы посмотрите наш пост тут, то поймете, что 60 минут vSAN ждет в случае APD (All Paths Down - например, временное выпадение из сети), а вот в случае PDL (Physical Device Loss) восстановление данных на другие дисковые группы начнется немедленно.
С точки зрения производительности, иметь 2 дисковые группы также выгоднее, чем одну, особенно если разнести их по разным контроллерам хранилищ (storage controllers). Ну и это более гибко в обслуживании и размещении данных на физических устройствах (например, замена диска во втором примере пройдет быстрее).
Работа операций ввода-вывода (I/O)
Как уже было сказано, в гибридной конфигурации есть кэши на чтение и на запись, а в All-Flash - только на запись:
При этом хост ESXi работает так, чтобы операции чтения с дисков попадали в кэш на чтение в 90% случаев. Остальные 10% операций чтения затрагивают HDD-диски и вытаскивают блоки с них. Но и тут применяются оптимизации - например, одновременно с вытаскиванием запрошенного блока, vSAN подтягивает в кэш еще 1 МБ данных вокруг него, чтобы последовательное чтение проходило быстрее.
Для All-Flash конфигурации кэш на чтение не нужен - все данные вытаскиваются с примерно одинаковой скоростью, зато все 100% кэша используются под write buffer, что дает преимущество в скорости обработки большого входящего потока операций ввода-вывода.
Ну и напоследок отметим, что vSAN при записи на флэш-диски распределяет операции записи равномерно между ячейками независимо от размера диска. Это позволяет диску изнашиваться равномерно и иметь бОльшую наработку на отказ.
Читать далее... - читать дальше и комментировать
|
Многие администраторы пользуются Putty для соединения с хостами VMware ESXi по протоколу SSH. Между тем, в веб-клиенте ESXi Embedded host client есть способ получить доступ к SSH-консоли прямо в браузере, реализованный на базе технологии HTML5.
Чтобы начать использовать консоль, надо сначала зайти на вкладку Services в разделе Manage и найти службу TSM-SSH:
Ее надо включить и поставить ей опцию запуска вместе с загрузкой хоста (Start and stop with host):
После этого в меню Action хостового веб-клиента надо выбрать пункт SSH Console:
Далее эта консоль загрузится в новой вкладке браузера:
Читать далее... - читать дальше и комментировать
|
Другие посты
Архив новостей
|  |
RSS
