Еще в 2015 году мы писали о документе "VMware NSX for vSphere Network Virtualization Design Guide", в котором был рассмотрен референсный дизайн инфраструктуры виртуализации сетей в виртуальном датацентре и описывалась архитектура решения NSX на физическом и логическом уровнях. Тогда этот документ занимал 160 страниц.
С тех пор много всего поменялось (решение NSX разделилось на NSX-T и NSX-V), функциональность продуктов для виртуализации сетей существенно расширилась, поэтому выпущенный недавно компанией VMware новый документ "VMware NSX-T Reference Design Guide" теперь занимает 300 страниц! Доступен он абсолютно бесплатно и, по-сути, представляет собой книгу о продукте NSX-T:
Основные корневые разделы документа:
NSX-T Architecture Components
NSX-T Logical Switching
NSX-T Logical Routing
NSX-T Security
NSX-T Load Balancer
NSX-T Design Considerations
NSX-T Performance & Optimization
Если вы администратор решения VMware NSX на большом предприятии, то это самая лучшая книга, чтобы почитать на новогодние праздники:)
Скачать VMware NSX-T Reference Design Guide можно по этой ссылке.
Первый момент - это то, что вам не потребуется Storage Replication Adapter (SRA), чтобы использовать репликацию на уровне дискового массива. Тома VVols изначально поддерживают управление хранилищами и их репликацией за счет механизма Storage Policy-Based Management (SPBM). Когда вы настраиваете репликацию VVols, она устанавливается не на уровне LUN, а на уровне виртуальных машин.
Все это упрощает управление репликацией виртуальных машин (нет необходимости настройки и обслуживания SRA), а также повышает гранулярность управления за счет оперирования на уровне отдельных виртуальных машин, а не всего LUN в рамках настройки SRM Protection Groups:
Второй важный момент - это то, что поскольку репликация VVols происходит на уровне виртуальных машин и их хранилищ, то ввиду меньшей гранулярности ВМ можно параллельно реплицировать на разные хранилища в соответствии с политиками SPBM, но при этом с разной периодичностью в зависимости от места назначения и их Protection Groups:
В традиционной инфраструктуре хранилищ, когда вы делаете тест восстановления хранилищ в SRM, то он должен выполняться для целой Protection Group, что рождает определенные сложности и условия при подготовке к тестированию. Для томов VVols все происходит гораздо проще, с учетом разной частоты репликации для виртуальных машин и большей гранулярности тестирования. Также это дает возможности простого восстановления отдельной ВМ в случае сбоя.
Между тем есть некоторые ограничения использования томов VVols и SRM:
SRM не поддерживает защиту виртуальных машин, которые имеют нереплицируемые виртуальные диски.
SRM не поддерживает защиту виртуальных машин с разными дисками на базе VVols, которые имеют разные политики хранилищ с точки зрения репликации и разные replication groups.
vVols не поддерживают восстановление шаблонов виртуальных машин (templates).
VVols поддерживает применение разных политик SPBM к дискам виртуальной машины, но чтобы эта ВМ поддерживалась со стороны SRM, нужно, чтобы все ее диски были настроены на базе одной политики:
Тома vVols 2 с поддержкой репликации уже поддерживаются на стороне хранилищ Dell EMC (PowerMax), HPE и Pure Storage. Также в ближайшем будущем ожидается существенное расширение этого списка.
Более подробную информацию вы можете получить по следующим ссылкам:
Многие администраторы платформы для сетевой защиты приложений в контейнерах, виртуальных машин и невиртуализованных нагрузок VMware NSX-T часто сталкиваются с проблемами, связанными с политиками устаревания паролей (password expiration policies), которые заставляют менять пароль локальных аккаунтов к консоли системы:
По умолчанию администратор должен менять пароль каждые 90 дней. Чтобы узнать о текущей политике паролей и сроке действия текущего пароля, надо выполнить следующую команду:
> get user admin password-expiration
Wed Dec 23 2020 UTC 16:38:51.380
Password expires 90 days after last change. Current password will expire in 90 days.
Чтобы изменить число дней, по прошествии которого пароль устаревает, надо выполнить эту команду:
> set user admin password-expiration 10
Ну и чтобы вовсе отключить устаревание пароля, надо выполнить следующее:
> clear user admin password-expiration
После этого нужно проверить, что политика отключена:
> get user admin password-expiration
Wed Dec 23 2020 UTC 16:44:56.671
Password expiration not configured for this user
Большинство администраторов, которым требуется управление виртуальной инфраструктурой VMware vSphere с помощью сценариев используют интерфейс VMware PowerCLI, который является оберткой движка PowerShell. Это требует наличие отдельного хоста, с которого идет исполнение сценариев, а также часто требуются такие сервисы, как vRealize Orchestrator и vRealize Automation.
Поэтому, начиная с VMware vSphere 6.7, появился новый Open Source интерфейс для управления виртуальной средой - Script Runtime Service (SRS). Он представляет собой Kubernetes-приложение для управления инстансами PowerCLI и вызова командлетов через REST API.
Интерфейс SRS позволит интегрировать управление исполнением сценариев PowerCLI в vSphere Client для виртуальных машин и приложений.
SRS создает отдельное пространство имен в кластере Kubernetes, которое позволяет PowerCLI работать как Kubernetes pod. Этот легковесный PowerCLI pod реализуется как образ контейнера, который имеет все модули PowerCLI и требует только необходимые управляющие компоненты, трансформирующие ввод и вывод для сценариев, а также управляющие исполнением запрошенного сценария.
Первоначальная инсталляция SRS запускает задачу Kubernetes, которая регистрирует SRS в сервисах провайдера идентификации vSphere SSO. Единожды аутентифицированные клиенты SRS API автоматически включаются в список доверенных на серверах vCenter.
Надо отметить, что сейчас SRS находится еще в ранней стадии разработки и не работает с vSphere with Tanzu (поэтому не развертывайте его со службами Supervisor Cluster).
Попробовать работу с движком SRS можно двумя путями:
1. Устанавливаете SRS в кластере Kubernetes на любую из машин (инструкции здесь)
2. Устанавливаете SRS на специальным образом подготовленную виртуальную машину на базе Photon OS (инструкции тут).
Начать экспериментировать с SRS API можно, перейдя по ссылке:
https://{SRS-IP}/swagger/index.html
SRS использует механизм vCenter Server SSO для идентификации и аутентификации. У любого пользователя с доступом через SSO есть возможность настроить PowerCLI-соединения к серверам vCenter Servers. Как начать это делать описано вот тут.
SRS работает с vSphere 6.7 и более поздними версиями. Сообщить о проблемах вы можете вот тут, а также присодинившись к VMware Code и каналу в Slack.
Вчера мы писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1c, где главным нововведением стала интеграция функций миграции Advanced Cross vCenter Server vMotion Capability (ранее это был виртуальный модуль Cross vCenter Workload Migration Utility) в интерфейс vSphere Client. Оно же называется XVM.
Эта функциональность используется для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). При этом не требуется настроенного механизма Enhanced Linked Mode (ELM) или Hybrid Linked Mode (HLM) для серверов vCenter в разных датацентрах.
Один из главных сценариев такой миграции - это горячий перенос виртуальной машины из онпремизной инфраструктуры VMware vSphere в облачную среду VMC on AWS.
Для подобного рода миграций vMotion теперь есть 2 рабочих процесса: миграция ВМ на другой vCenter, а также импорт с целевого vCenter виртуальной машины источника:
Для функциональности XVM поддерживается и режим пакетной миграции, для которого вы можете указать несколько виртуальных машин, выбрать пункт Migrate и начать их одновременный перенос (пункт Cross vCenter Server export):
При миграции можно выбрать новый vCenter или один из уже сохраненных, что очень удобно при миграции групп ВМ в несколько заходов. К сожалению, Saved vCenters сохраняются только в рамках одной пользовательской сессии:
Дальше мастер будет похож на аналогичный в обычном vMotion, где будут выполняться стандартные предпроверки:
Как и при обычном vMotion, вы можете сменить хранилище виртуальной машины, а также ее сеть, чтобы она соответствовала инфраструктуре назначения. Затем начнется стандартная задача миграции:
На целевом vCenter тоже будет отображаться задача по приему vMotion от источника:
На целевом vCenter можно также самостоятельно инициировать прием миграции, выбрав пункт Import VMs из контекстного меню кластера:
Чтобы провести такую миграцию, также надо подключить исходный vCenter:
При успешном подключении вы сможете выбрать виртуальные машины, которые требуется перенести в другой датацентр:
Таким образом, эта функциональность может быть использована для следующих случаев:
Миграция онпремизных ВМ в облачный датацентр VMC on AWS без необходимости настройки Hybrid Linked Mode (HLM)
Переход на новую версию платформы vSphere путем переноса рабочих нагрузок со старых серверов
Миграция ВМ в рамках обновления инфраструктуры VMware Cloud Foundation (VCF)
Консолидация датацентров или перераспределение их содержимого
Вывод из эксплуатации старого оборудования со старыми версиями vSphere
Глобальная перебалансировка виртуальных машин между окружениями VCF
Миграция инфраструктуры на одно из публичных облаков VMware Cloud
На днях компания VMware выпустила обновление VMware vSphere 7 Update 1c, в котором появилось довольно много всего нового для минорного апдейта.
Давайте посмотрим, что именно:
Статистики по физическим сетевым адаптерам - добавилось 5 новых параметров (dropRx, dropTx, errorsRx, RxCRCErrors и errorsTx), которые позволяют вам обнаружить сетевые ошибки и предпринять действия по исправлению ситуации.
Параллельное обновление хостов в кластерах, которые находятся под управлением vSphere Lifecycle Manager. Теперь хосты ESXi под управлением vLCM можно одновременно перевести в режим обслуживания и начать их обновление.
Advanced Cross vCenter vMotion - это функциональность виртуального модуля Cross vCenter Workload Migration Utility, который был предназначен для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). Теперь эта штука интегрирована в vSphere Client, где удобно работать с миграциями ВМ между датацентрами (поддерживается и пакетная миграция нескольких ВМ):
Можно подключать сторонние плагины для управления сервисами на платформе vSAN Data Persistence из vSphere Client таким же способом, как вы управляете сервером vCenter.
Улучшения vSAN DOM scrubber (проверка блоков, к которым давно не было обращений).
Улучшения Supervisor Cluster:
Изоляция пространств имен (Supervisor Namespace Isolation) за счет выделенного маршрутизатора T1 Router (кластеры в сети NSX-T используют для этого новую топологию).
Поддержка NSX-T 3.1 для Supervisor Clusters
Удалена поддержка Supervisor Cluster версий 1.16.x.
Улучшения служб Tanzu Kubernetes Grid for vSphere:
Поддержка HTTP/HTTPS Proxy – вновь созданные кластеры Tanzu Kubernetes могут использовать глобальные прокси HTTP/HTTPS для исходящего трафика, а также скачивать образы контейнеров из интернет-репозиториев.
Вновь созданные кластеры Tanzu Kubernetes из коробки интегрированы со службой vSphere Registry Service. Также с этой службой будут интегрированы кластеры, обновленные до новой версии.
Кластеры Tanzu Kubernetes теперь могут монтировать дополнительные тома к виртуальным машинам, что позволяет увеличивать дисковую емкость узлов. Это дает возможность пользователям развертывать большие образы контейнеров, которые больше дефолтного размера в 16 ГБ.
Скачать VMware vSphere 7 Update 1c можно по этой ссылке. Release Notes доступны тут.
Не так давно мы писали о технологии vSphere Clustering Service (vCLS), которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Делается это за счет того, что на хостах есть агентские виртуальные машины служб vCLS.
Дункан Эппинг описал ситуацию, когда эти виртуальные машины просто не включаются с ошибкой в консоли vSphere Cleint:
Insufficient resources
Если посмотреть в детали сообщения об ошибке, то там будет примерно следующее:
The target host does not support the virtual machine's current hardware requirements.
Также может быть показано следующее сообщение:
Feature 'MWAIT' was absent, but must be present.
Выходов из этой ситуации может быть два - так как они могут быть обусловлены разными причинами. Причем первый вариант - это официально поддерживаемый со стороны VMware путь устранения проблемы для кластера в целом, а второй - "народный способ" для отдельных ВМ.
Вариант 1:
Для устранения ошибки про Feature 'MWAIT' нужно убедиться, что опция Monitor/MWAIT включена в BIOS (Enabled). vCLS включает EVC на базе виртуальных машин для каждой ВМ. Если же это не помогло или вы не можете это сделать, то нужно использовать метод, описанный ниже.
Вариант 2:
Апгрейдим ВМ в плане "Compatibility" до последней версии виртуального железа “VM version 14” (меню апгрейда есть по правой кнопке в vSphere Client).
Выбираем нужную ВМ, переходим на вкладку Configure и идем в VMware EVC.
Нажимаем "Edit" и выбираем “Yes” для подтверждения изменения настроек
На днях компания VMware выпустила обновление своего пакета vRealize Operations Management Pack for Kubernetes 1.5.1, которое позволяет отслеживать состояние контейнерных сред Kubernetes из консоли Operations. Напомним, что ранее оно называлось Management Pack for Container Monitoring.
Надо отметить, что vRealize Operations с помощью данного пакета может обеспечивать мониторинг как сред Tanzu Kubernetes в публичном или онпремизном облаке, так и инфраструктуры OpenStack с развернутыми кластерами Kubernetes.
Давайте посмотрим, что появилось нового в MP for Kubernetes 1.5.1:
1. Поддержка vRealize Operations Advanced
Теперь пользователи издания Advanced также могут использовать пакет управления, ранее эта возможность была доступна только владельцам лицензий Enterprise. Для vRealize Operations Cloud поддержка также сохранилась.
2. Улучшенный сбор метрик средствами Prometheus
Многие пользователи сред Kubernetes используют Prometheus для сбора метрик в кластерах. Теперь vRealize Operations за счет MP может запрашивать метрики с сервера Prometheus, а данные об инфраструктуре получать напрямую через Kubelet API.
Такая интеграция по-прежнему позволит вам использовать механизмы интеллектуального анализа данных, в том числе Troubleshooting Workbench и Metric Correlation.
Prometheus хранит данные в отличном от vRealize Operations формате. Чтобы преобразовать и получить данные для метрик Prometheus можно использовать следующих экспортеров (exporters):
Если ваша команда разработки дорабатывает какие-то метрики в экспортерах, то они автоматически становятся доступны в vRealize Operations.
vRealize Operations также собирает метки (labels) с серверов Prometheus. Они могут включать важные данные, такие как IP-адреса узлов, имена приложений или процессов, номера версий или даже, например, какие метрики используются для конкретного ядра CPU:
Для игнорирования ненужных метрик (например, GUID) можно использовать фильтры:
3. Мониторинг приложений в Kubernetes
Теперь интеграция vRealize Operations и Prometheus позволяет более глубоко взглянуть на уровень приложений:
В данном примере показано приложение Redis, для которого используется экспортер Telegraf. Для него vRealize Operations может видеть такие метрики как: число клиентов, как много времени CPU требуется на выполнение вызовов, информацию о памяти и application backlogs.
4. Поддержка новых Tanzu Mission Control API
Теперь vRealize Operations и MP могут не только автоматически мониторить облачные среды Tanzu Mission Control на платформе AWS, но и полностью поддерживают обновленный API. Также недавно было анонсировано, что Tanzu Mission Control будет поддерживать Tanzu Kubernetes Grid on vSphere 7, и вскоре эта поддержка будет добавлена и в Management Pack.
Скачать VMware vRealize Operations Management Pack for Kubernetes 1.5.1 можно по этой ссылке. Документация находится здесь.
Компания Veeam, производитель лидирующих на рынке средств для обеспечения доступности виртуальных датацентров, в декабре объявила о доступности для скачивания новой версии Veeam Backup for Microsoft Office 365 v5. Напомним, что с помощью этого решения можно производить резервное копирование и восстановление данных Office 365 из облака, а также бэкапить локальные данные Microsoft Exchange, OneDrive и Sharepoint.
Давайте посмотрим, что нового появилось в этом решении:
1. Поддержка Microsoft Teams
Многие Enterprise-администраторы используют Microsoft Teams для создания среды совместной работы для команд различного размера в рамках предприятия. Теперь Veeam Backup for Microsoft Office 365 v5 позволяет производить резервное копирование этих сред с использованием специального API от Microsoft.
Этот API позволяет узнать, с каким каналом ассоциирован каждый data point, что позволяет организовать бесшовное резервное копирование и восстановление сред Microsoft Teams для SharePoint Online, Exchange и OneDrive.
Veeam Explorer for Microsoft Teams включает в себя возможности восстановления для каналов, настроек, прав доступа, приложений и вкладок, включая данные и компоненты.
Также появилась возможность поиска по 17 полям:
2. Улучшения производительности
Теперь объекты SharePoint обрабатываются параллельно для каждого сайта, что существенно ускоряет процесс бэкапа. Также одна инсталляция бэкап-сервера может обрабатывать до 5 раз больше прокси, что увеличивает возможности по управлению бэкапом больших инфраструктур. При этом прокси не обязательно должны быть в том же или трастовом домене.
Кроме того, теперь данные Office 365 в два раза быстрее перемещаются между локальной БД и объектным хранилищем репозиториев.
3. Обновление Restful API
Помимо поддержки Microsoft Teams, появились функции отчетности о ежемесячном использовании ресурсов, что позволяет гибко использовать эту информацию в целях биллинга (она поставляется в виде JSON). Через API теперь также можно управлять лицензиями пользователей.
Скачать можно по этой ссылке. Также Veeam выпустила целую книжку "Microsoft Teams Backup", в которой описаны лучшие практики по резервному копированию таких пользовательских сред.
Вот список продуктов и их версий, которые затронет отсутствие поддержки Flash со стороны браузеров:
Продукт
На что нужно обновляться
vSphere 6.7 GA или старее
6.7 Update 3 или новее
Horizon 7.8 или старее
7.10 или новее
vCloud Director 10 или старее
10.1 или новее
NSX for vSphere 6.4.7 или старее
6.4.8 или новее
Site Recovery Manager 6.5 или старее
8.1 или новее
vSAN 6.5 или старее
6.7 Update 3 или новее
vRealize Orchestrator 7.5 или старее
7.6 или новее
vRealize Automation 7.6 или старее
8.0 или новее
vRealize Operations 6.5 или старее
6.6 или новее
В июне этого года, в связи с большим числом заявок от крупных компаний, было решено сделать Workaround для Flash Player. Чтобы включить его для отдельных URL, нужно внести изменения в файл mms.cfg, где следует добавить следующие строчки:
На сайте проекта VMware Labs появилось обновление утилиты VMware Event Broker Appliance (VEBA) v0.5. Напомним, что это решение, которое позволяет пользователям создавать сценарии автоматизации на базе событий, генерируемых в VMware vCenter Service. Например, VEBA может выполнять такие рабочие процессы, как автоматическое привязывание нужного тэга ко вновь создаваемой виртуальной машине. Работает он по модели "If This Then That". О версии VEBA 0.3, вышедшей весной этого года, мы писали вот тут.
Давайте посмотрим, что нового появилось в продукте, начиная с версии 0.3 и вплоть до вышедшей на днях версии 0.5:
Новый интерфейс VEBA Direct Console UI (DCUI)
Новые примеры функций Incident Management
Новый пример функции на Golang
Возможность развертывания VEBA в существующем кластере Kubernetes (см. тут)
Обновление базовой ОС на последний релиз Photon OS 3.0 Rev2
Сетевой провайдер (CNI) контейнеров Weave заменен на Antrea
Поддержка кастомизации Docker bridge network (default: 172.17.0.1/16) через свойство OVF-шаблона
Возможность мониторинга виртуального модуля VEBA через vRealize Operations (см. тут)
Какое-то время назад мы писали о полезном документе "Product Lifecycle Matrix", в котором приведены основные моменты касающиеся жизненного цикла продуктов VMware: дата доступности продукта для загрузки, окончание поддержки, завершение технического сопровождения и дата снятия с продаж.
Наш читатель Ser указал на интересный ресурс - это онлайн-тул Product Lifecycle Matrix, который выводит актуальную информацию из указанного документа в возможностью сортировки и фильтрации по нужным колонкам:
Удобно, что в таблице можно не только искать нужный продукт (кстати, не ищите vSphere, потому что там продукты разделяются на ESXi и vCenter), но и экспортировать полученный табличный вид в PDF или CSV, а также вывести его на печать.
Красным отмечены даты у продуктов, для которых поддержка или техническое сопровождение заканчивается в ближайшие 6 месяцев, а фиолетовым - те, у которых поддержка уже закончилась. Обратите внимание, что также есть отдельная вкладка для неподдерживаемых и устаревших продуктов.
На сайте компании Veeam появился кумулятивный Patch 3, который вы можете накатить на релиз продукта для резервного копирования и репликации виртуальных машин Veeam Backup and Replication 10a. Главная новая фича данного патча - это официальная поддержка новой версии платформы виртуализации VMware vSphere 7 Update 1.
Это уже третий кумулятивный патч после релиза версии 10а в июле этого года.
Давайте посмотрим на новые возможности, появившиеся в третьем патче к Veeam B&R v10a:
Полная поддержка VMware vSphere 7.0 U1, включая обновленный vSphere API, а также виртуальных машин с Virtual Hardware 18.
Автоматическое исключение из бэкапа системных ВМ, используемых службой vSphere Clustering Service (vCLS).
Поддержка Microsoft Windows 10 20H2 и Microsoft Windows Server 20H2 как гостевых ОС, защищенных методом host-based backups и agent-based backups. Также туда можно поставить компоненты Veeam Backup & Replication.
Поддержка дистрибутивов RHEL 8.3 и SLES 15 SP2 со стороны Veeam Agent for Linux 4.0.1.2372 - как в плане функций агента, так и в плане установки компонентов Veeam B&R.
Добавлена поддержка S3-совместимого объектного хранилища со включенным версионированием и отключенным object lock (например, Backblaze B2).
Перед обновлением убедитесь, что номер билда вашей версии - это 10a (build 10.0.1.4854) в разделе Help -> About консоли Veeam Backup & Replication. После апгрейда номер билда должен измениться на 10.0.1.4854 P20201202.
Скачать Veeam Backup and Replication 10a Patch 3 можно по этой ссылке.
Компания VMware запустила новый ресурс core.vmware.com, посвященный технической информации для администраторов инфраструктуры VMware vSphere, решений vSAN, Horizon, vRealize и других платформ.
На новый портал переехал контент с ресурсов Storage Hub и vSphere Central, который был актуализован и теперь будет регулярно пополняться технической информацией в виде документов и видео.
Документов будет много, но основной упор будет делаться на продукты vSphere, vSAN и Cloud Foundation.
Кстати, раз уж речь зашла о документации, расскажем, что VMware потихоньку начинает добавлять техническую документацию по продуктам на русском языке на сайт VMware Docs (мы писали об этом тут). Смотрите, например, что уже есть по vRealize Automation:
В прошлом году мы писали о полезной утилите VMware Configuration Maximums Tool, которая позволяет выводить максимальные конфигурации для различных продуктов VMware. Эта очень полезная штука для администраторов vSphere умеет не только выводить список всех максимумов, но и сравнивать их для разных версий одного продукта.
Для этого нужно выбрать пункт меню "Compare Limits" и указать сравниваемые версии продуктов:
Штука эта очень удобная, но у нее есть большой недостаток - она выводит все конфигурации максимумов (для NSX-T, например, их 274 штуки, поэтому сложно отследить, что именно изменилось).
Поэтому Dale Coghlan написал интересный PowerCLI-модуль VMware.CfgMax, который решает эту проблему - в режиме командной строки можно узнать об изменениях максимумов, а также сделать еще несколько полезных вещей.
После установки модуля можно вывести список доступных продуктов, которые есть на configmax.vmware.com:
Для конкретного продукта можно вывести список его версий/релизов:
Также для конкретной версии можно вывести список категорий максимумов:
С помощью командлета можно вывести все максимумы для конкретного продукта и определенной его версии:
Можно вывести все конфигурации в рамках заданной категории:
Ну и, наконец, с помощью командлета Compare-CfgMaxLimits можно сравнить максимумы конфигураций для разных версий одного продукта:
Как вы видите, тут есть поле CompareStatus, которое и говорит нам, новая ли эта настройка (New), измененная по сравнению с прошлым релизом (Modified), нетронутая (пусто) или удаленная (Deleted) в новой версии.
С помощью параметра New можно, например, вывести все новые настройки:
Параметр Modified выведет только отличающиеся максимумы конфигураций:
Ну а параметр Deleted выведет устаревшие настройки:
Ну и все вместе, без неизмененных значений:
Очень удобная штука, все это также можно экспортировать в формат CSV и сравнивать в Excel. Для этого можно использовать следующую команду:
PS > $product = Get-CfgMaxProduct -Name 'NSX-T Data Center'
PS > $releaseA = $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.0.0'
PS > $releaseB = $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.1.0'
PS > Compare-CfgMaxLimits -Product $product -Release $releaseA -CompareRelease $releaseB | Export-Csv -Path compare-status.csv -NoTypeInformation
Скачать данный PowerCLI сценарий с примерами вы можете по этой ссылке.
На днях компания VMware рассказала об основных моментах новой модели лицензирования, которая появилась в продуктовой линейке VMware Horizon. Главным нововведением стал переход на подписочную модель на продукты, чтобы соответствовать тенденции по переходу пользователей на удаленный режим работы в связи с пандемией.
Переход на новую subscription-based схему начался уже сейчас и завершится к 6 мая 2021 года, когда обычные лицензии Horizon перестанут существовать.
По заверениям VMware это даст пользователям следующие преимущества:
Единую среду для управления лицензиями онпремизных инсталляций и облачных пользовательских сред - все это будет делаться через Horizon Control Plane.
Облачные сервисы могут применяться к онпремизным десктопам, расширяя их функциональность. Если же пользователям нужны только онпремизные инфраструктуры - то и там можно будет использовать десктопы на базе подписки.
Администраторы смогут разворачивать новые десктопы в облаке без капитальных затрат, а также создавать их в целях HA/DR. Это позволит гибко подходить к вопросу отказо- и катастрофоустойчивости, добавляя или удаляя резервные системы по мере надобности.
Возможность перехода между тарифами. Теперь пользователи смогут использовать гибкую систему ценообразования и апгрейдов, чтобы постепенно стремиться к получению оптимальной конфигурации.
Инструменты для получения единой среды EUC (End User Computing) для всех пользователей на любых устройствах с помощью облачного решения Workspace ONE, интегрированного с VMware Horizon.
В ближайшее время ожидаем документ с подробным описанием новой схемы лицензирования VMware Horizon на базе подписки.
Компания VMware на днях выпустила обновление продукта Cloud Director Availability 4.1, предназначенного для создания резервной инфраструктуры в одном из публичных облаков сервис-провайдеров на основе VMware vCloud Director (так называемая услуга Disaster-Recovery-as-a-Service, DRaaS).
Нововведения сфокусированы в трех основных областях - улучшенная совместимость с другими компонентами, новые возможности в плане контроля инфраструктуры и новые функции для архитектур на базе одной или нескольких площадок:
Давайте посмотрим на основные новые возможности Cloud Director Availability 4.1:
1. Новые e-mail оповещения для клиентов
Основные улучшения в этой области рассмотрены в видео выше. Вместо того чтобы логиниться в интерфейс, пользователи могут получать оповещения по почте, имея при этом высокую степень кастомизации для них со стороны провайдера:
Провайдер может контролировать, к каким событиям может иметь доступ клиент.
2. Поддержка шифрования Cloud-to-Cloud
Теперь возможности шифрования виртуальных дисков машин поддерживаются и в распределенных сценариях, когда нужно переместить зашифрованную на базе политик виртуальную машину между площадками с включенным шифрованием, где используется один KMS-сервер.
3. Поддержка аутентификации на нескольких площадках с использованием собственного провайдера
Теперь клиенты могут использовать единую аутентификацию с использованием собственного провайдера identity provider (SSO/LDAP/SAML), что позволяет не вводить логин-пароль при соединении с разными площадками.
4. Упрощенный мастер начальной конфигурации
Здесь было сделано множество улучшений в плане упрощения процесса первой настройки решения - например, можно сохранить логин-пароль для соединения с различными виртуальными модулями, которые участвуют в конфигурации.
5. Улучшенные нотификации для провайдеров
Теперь нотификации вынесены в отдельный раздел, могут рассылаться по электронной почте, а провайдер может управлять нотификациями клиентов.
6. Разделение операций Migrations и Protections
Теперь управление для Migrations и Protections полностью разделено и доступно на базе независимых контролов:
7. Резервное копирование и восстановление виртуальных модулей Cloud Director Availability 4.1
Теперь Virtual Appliances, входящие в состав Cloud Director Availability 4.1, можно бэкапить, а также восстанавливать с случае сбоев производственных систем. Важно, что восстановление, как и бэкап, делается в несколько кликов.
Если у вас версия Cloud Director Availability 4.0 то до 4.1 можно обновиться сразу, а вот с версии 3.5 придется обновляться через 4.0. Более подробная информация о продукте приведена здесь.
Недавно компания VMware залила на GitHub актуальную версию графики для составления схем и диаграмм в Microsoft Visio и OmniGraffle - VMware Stencils. Иконки и графика доступны еще и в формате Microsoft PowerPoint, а также в векторном формате SVG.
Напомним, что в прошлый раз о стенсилах VMware Stencils мы писали год назад вот тут, а в то время не было версии для OmniGraffl под Mac OS.
На днях на сайте проекта VMware Labs появилось очередное интересное обновление - новая версия гипервизора VMware ESXi Arm Edition 1.2 для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства).
Напомним, что о версии ESXi Arm Edition 1.1 мы писали вот тут, а здесь также рассказывали об установке этого гипервизора на платформу Raspberry Pi.
Давайте посмотрим, что нового в VMware ESXi Arm Edition 1.2:
Если у хоста нет датасторов, то datastore browsing отключен
Пофикшен отсутствующий параметр context_id для вызовов CPU_ON
Исправлена проблема с контроллером GICv2 (теперь SGI всегда включены и работают как устройства GIC-500)
Поддержка гостевых ОС на базе big-endian
Убраны требования/ограничения на initrd для ВМ без UEFI
В целом, все это технические фиксы - но обновить вашу тестовую лабу не помешает. Новая версия ESXi Arm встает только как свежая установка, обновление прошлых версий не поддерживается. Можно сохранить прошлые тома VMFS, выбрав опцию "Preserve VMFS", но машины надо будет перерегистрировать заново.
Скачать ESXi Arm Edition 1.2 можно по этой ссылке.
Напомним, что NVMe-oF - это реализация технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP. Для всего этого нужна поддержка RDMA со стороны HBA-адаптера хоста ESXi.
Поддержка NVMe-oF для доступа к хранилищам появилась еще в VMware vSphere 7, а в обновлении Update 1 была улучшена и оптимизирована. В указанном выше документе рассматривается сравнение производительности традиционного протокола Fibre Channel Protocol (SCSI FCP) с реализацией FC-NVMe в vSphere 7.0 U1.
Для всех бенчмарков использовался тот же HBA-адаптер и инфраструктура сети хранения данных SAN. Для генерации нагрузки использовались утилиты fio (для создания разных по размеру операций ввода-вывода I/O, а также паттернов нагрузки) и Microsoft CDB (бенчмарк для генерации OLTP-нагрузки в SQL Server).
Результат оказался весьма интересным. С точки зрения IOPS протокол NVMe-oF смог выжать почти в два раза больше операций ввода-вывода практически для IO любого размера:
Задержка (Latency) также снизилась практически в два раза:
На картинке ниже приведены результаты теста Microsoft CDB для базы данных в числе транзакций в секунду:
Здесь также виден значительный прирост для NVMe-oF, а для двух виртуальных машин производительность выше почти в раза!
Остальные интересные детали тестирования - в документе.
На днях один из сотрудников компании VMware сделал аддон Helm Chart под решение vRealize LogInsight Cloud, который позволяет обрабатывать логи кластеров Kubernetes в среде VMware vSphere и TKG (Tanzu Kubernetes Grid).
Отдельные инсталляции кластеров K8 на платформах vSphere/AWS
После установки аддона вы можете начать собирать метрики с кластеров TKG и K8 в вашем окружении, а также визуализовывать их на дашбордах наподобие вот такого:
Вообще Helm - это менеджер пакетов для Kubernetes. Это один из лучших путей поиска, шаринга и использования программного обеспечения в кластерах K8. Helm Charts это YAML-манифесты Kubernetes, объединенные в один пакет, который можно развернуть в среде K8. После запаковки установка Helm Chart в кластере производится одной командой helm, которая позволяет просто указать параметры развертывания и апгрейда.
Перед использованием данного средства вам понадобятся:
Многие администраторы уже используют продукт VMware vSAN 7 Update 1 для создания отказоустойчивых кластеров хранилищ на базе серверов ESXi. Некоторое время назад мы писали про технологию Cloud Native Storage (CNS), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.
Давайте посмотрим, что нового появилось в возможностях CNS в обновлении vSAN 7 U1:
1. Расширение томов PersistentVolumeClaim
В Kubernetes v1.11 появились функции расширения томов за счет изменения объекта PersistentVolumeClaim (пока только офлайн). Помните, что уменьшение тома (shrink) не поддерживается.
2. Статический провижининг в Supervisor Cluster
Эта возможность позволяет презентовать существующий том в кластере K8s, который будет интегрирован с vSphere Hypervisor Cluster (он же Supervisor Cluster, vSphere with K8s, Project Pacific).
3. Поддержка vVols для vSphere K8s и TKG Service
Теперь обеспечивается поддержка внешних хранилищ на базе vK8s и TKG с использованием томов vVols.
4. Функции Data Protection for Modern Applications
В vSphere 7.0 U1 появились функции поддержки резервного копирования Dell PowerProtect и Velero для Pacific Supervisor и TKG кластеров. Для Velero вы можете инициировать создание снапшотов через Velero plugin и хранить их в облаке S3.
5. Функции vSAN Direct
Возможность vSAN Direct позволяет использовать Direct Attach Storage (обычно на базе физических HDD-дисков) для хранения виртуальных машин VMware vSphere.
Вы можете создавать vSAN Direct Datastores, которые не являются общими для кластера датасторами, но физические диски таких хранилищ можно, например, напрямую подключать к виртуальным модулям (Virtual Appliances) или к контейнерам, исполняемым в среде vSphere, которым нужно объектное хранилище, но при этом хочется использовать его напрямую, минуя стандартный путь данных vSAN.
Мы уже много писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1. Сегодня мы посмотрим подробнее, что нового появилось в плане механики резервного копирования виртуальных машин (Data Protection), реализуемой через VMware vStorage API for Data Protection.
1. Функции Network QoS для трафика резервного копирования
Теперь возможности приоритезации трафика Network QoS доступны и для трафика резервного копирования виртуальных машин. Настроить это можно в vSphere Client в разделе System Traffic > Configure > Edit:
Основное назначение данной настройки - дать возможность урезать полосу канала резервного копирования таким образом, чтобы это не влияло существенным образом на трафик производственной среды.
2. Улучшенная обработка задач резервного копирования
Теперь при входе хоста ESXi в режим обслуживания во время резервного копирования есть флаг Entering Maintenance Mode (EMM), что означает, что операции бэкапа должны переключиться на другой хост ESXi, где сессия NFC (network file copy) может быть продолжена. Это автоматическое переключение происходит прозрачно для задачи резервного копирования, но требует от ПО для бэкапа поддержки данного флага, чтобы обнаружить момент переключения.
3.Улучшенное масштабирование для одновременно запущенных задач РК
Для окружений, где параллельно запущено множество задач резервного копирования, ограничения сервера vCenter могут стать проблемой. Использование сервиса VPXA не позволяет кастомизировать буфер памяти для задач, обрабатываемых через vCenter. В апдейте vCenter Server 7.0 U1 теперь можно настраивать буфер памяти, чтобы обрабатывать множество потоков резервного копирования. Например, для 50 одновременных бэкапов нужно использовать 96 MБ памяти.
4. Улучшения vSphere APIs for I/O Filtering (VAIO)
Фреймворк VAIO - это основной интерфейс для партнерских решений, которые могут перехватывать запросы ввода-вывода операционной системы к виртуальному диску. В этом случае команда ввода-вывода (I/O) не будет применена к диску без прохождения через IO Filter, созданный сторонним ПО.
Теперь здесь появились следующие улучшения:
CIM provider теперь стал 64-битным
Сами VAIO-фильтры теперь будут распространяться как компоненты, а не VIB-пакеты
Напомним, что в vSphere 7 появилась концепция компонентов вместо отдельных VIB-пакетов. В vSphere 7 компоненты - это набор VIB-пакетов, которые может использовать Lifecycle Manager, чтобы накатывать патчи. Теперь компоненты можно накатывать через esxcli с использованием команды component apply.
На сайте virten.net (клевый, кстати, ресурс) появилось описание серьезной ошибки файловой системы VMware VMFS 6, которая используется для создания датасторов в ESXi 7.0 (Build 15843807) и 7.0b (Build 16324942). Он касается кучи ФС (VMFS heap), которая переполняется из-за некорректной работы механизма ее очистки. В VMware vSphere 7 Update 1 эта ситуация решена. Сама проблема описана в KB 80188.
Симптомы переполнения кучи, как правило, следующие:
Датасторы на хостах показывают статус "Not consumed"
Виртуальные машины не могут выполнить vMotion
Виртуальные машины "сиротеют" (переходят в статус "orphaned") при выключении
При создании снапшота возникает ошибка "An error occurred while saving the snapshot: Error."
В логе vmkernel.log могут появляться следующие сообщения об ошибках:
Heap vmfs3 already at its maximum size. Cannot expand
Heap vmfs3: Maximum allowed growth (#) too small for size (#)
Failed to initialize VMFS distributed locking on volume #: Out of memory
Failed to get object 28 type 1 uuid # FD 0 gen 0: Out of memory
Память для кучи VMFS принудительно очищается при аллокации ресурсов файловой системы, например, обычных thick-дисков. Поэтому воркэраунд получается следующий - нужно создать диск Eager zeroed thick на всех смонтированных к хостам ESXi датасторах. Делается это командой:
Проблема только в том, что нужно выполнить эту операцию на каждом датасторе каждого хоста. Поэтому есть вот такая команда для всех датасторов и хостов:
# for I in $(esxcli storage filesystem list |grep 'VMFS-6' |awk '{print $1}'); do vmkfstools -c 10M -d eagerzeroedthick $I/eztDisk;echo "Removing disk $I/eztDisk"; vmkfstools -U $I/eztDisk; done
Результат будет примерно таким:
Сейчас какого-то отдельного патча для решения этой проблемы нет, поэтому нужно самостоятельно следить за поведением инфраструктуры. Основным симптомом является появление в vmkernel.log следующего сообщения:
Maximum allowed growth * too small for size
Если у вас есть такой продукт, как VMware Log Insight, то вы можете настроить аларм на появление этого сообщения в логе.
На сайте проекта core.vmware.com появился интересный документ из будущего, описывающий особенности проектирования и сайзинга кластеров хранилищ vSAN, актуализированный 4 декабря этого года - VMware vSAN 7 Update 1 Design Guide:
На самом деле, документ этот очень полезен для администраторов VMware vSAN, планирующих развертывание корпоративной инфраструктуры хранилищ на базе серверов ESXi. В нем рассматриваются все новые возможности версии vSAN 7 Update 1, включая технологию HCI Mesh, которая позволяет смонтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов):
Основные разделы документа:
vSAN Design Overview
vSAN Limits
Network Design Considerations
Storage Design Considerations
VM Storage Policy Design Considerations
Host Design Considerations
Cluster Design Considerations
Determining if a Workload is Suitable for vSAN
Sizing Examples
vSAN Sizing Tool
VMware vSAN GSS Support
Очень полезная вещь - это наличие рекомендаций и лучших практик по различным аспектам проектирования кластров:
Интересная табличка по рекомендациям выставления опций по реакции на событие изоляции (Isolation Responce / Isolation Policy):
Интересны также указания на часто встречающиеся ошибки проектирования:
В общем, документ мегаполезный. Скачать VMware vSAN 7 Update 1 Design Guide можно вот тут.
На днях на сайте проекта VMware Labs появилась новая версия средства VMware OS Optimization Tool (билд b2000), предназначенного для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач. Напомним, что о прошлом релизе (b1171) мы писали вот тут.
Давайте посмотрим, что интересного появилось в новой версии:
Новая опция, позволяющая отложить обновления фич или сразу накатить их (или пропустить)
Такая же опция, касающаяся quality updates
Возможность пропустить обновления Office Click-to-Run
Добавлены команды по остановке и отключению служб App Volumes при повторном включении Windows Update
После этого они будут установлены в значение automatic, если Windows Update будет снова отключен
Также в новом билде было поправлено много ошибок:
Исправлена проблема, из которой останавливался автоматический логин в издания Server и WVD после применения Sysprep
Исправлено подтверждение перезагрузки в процессе генерализации Win10 1607 LTSB
Исправлена проблема с невозможностью включения антивируса в Windows 10 2004
Исправлена проблема со скачиванием обновлений фичей при повторном включении Windows Update
Выбор Common options теперь сохраняется при следующих запусках OS Optimization Tool
Для всех вкладок пользователи могут применять разные настройки Common Options на оптимизируемой системе
На вкладке Update есть опция включения/выключения обновлений Office 365, 2016, 2019
На вкладке Store Apps есть чекбокс для отключения удаленных встроенных приложений.
Скачать VMware OS Optimization Tool b2000 можно по этой ссылке.
Многие администраторы платформы VMware vSphere задаются вопросом - что произойдет, если изменить политику хранилищ (Storage Policy) в кластере vSAN для виртуальной машины? Будет ли после этого выполнена операция по перестроению дисковых объектов (Rebuild), что повлечет дополнительную нагрузку на хранилища и займет время?
Также в некоторых условиях операция Rebuild может не выполняться, но выполняется Resync - добавление новых копий данных, при котором исходные копии данных не изменяются (например, вы увеличиваете значение политики FTT, что влечет создание новых дисковых объектов).
Ответ на этот вопрос зависит от того, какую политику и на что вы меняете. Дункан Эппинг провел полезные тесты в своей лабе, чтобы выяснить, в каких случаях происходит Rebuild/Resync. После каждой операции он через интерфейс командной строки проверял, происходила ли операция ресинхронизации. Далее он свел полученные результаты в таблицу ниже, чтобы при изменении политики администраторы vSAN представляли, что произойдет дальше.
Компания VMware пару недель назад объявила о выпуске бета-версии операционной системы Photon OS 4.0 Beta. Напомним, что эта ОС используется сейчас уже во всех виртуальных модулях VMware (Virtual Appliances), которые реализуют различные вспомогательные сервисы. Напомним, что о прошлой версии Photon OS 3.0 мы писали весной прошлого года вот тут.
Давайте посмотрим, что нового появилось среди возможностей обновленной ОС:
1. Ядро реального времени для приложений телекома и vRAN (Virtual Radio Network)
Наступает эра 5G, и VMware сделала в Photon OS 4.0 возможности поддержки телеком-приложений реального времени на уровне ядра (Photon Real Time kernel). Это позволит технологиям vRAN (Virtual Radio Network) использовать возможности ОС Photon при развитии инфраструктуры 5G-операторов.
2. Безопасность
Photon 4.0 получила поддержку таких технологий по обеспечению безопасности, как SELinux, Security Encrypted Virtualization – Encrypted Status и Intel Software Guard Extensions. Обязательная система контроля доступа, прошитая на уровне ядра, позволяет SELinux дать администраторам гранулярный и гибкий доступ к ресурсам. Также Photon OS позволяет из коробки, на уровне политик, обеспечить нужды приложений в изоляции. Также поддерживается SELinux для контейнеров, что было протестировано для docker, containerd и runc.
Поддержка драйверов Intel SGX drivers позволяет приложениям использовать ресурсы CPU для создания "анклавов" - полностью защищенных модулей исполнения, недоступных на аппаратном уровне другим процессам.
3. Оптимизации производительности для решения vSphere with Tanzu
Исторически Photon ОС имела специальный контекст ядра linux-esx, который был специальным образом оптимизирован для работе на платформе VMware ESXi точки зрения производительности и предоставляемых возможностей. В Photon 4.0 то же самое появилось и для контейнерной среды исполнения vSphere with Tanzu, например, уменьшение времени запуска для контейнеров и приложений.
4. Улучшения компонентов ОС
В Photon 4.0 были обновлены более 700 пакетов, включая ключевые компоненты, такие как tdnf, pmd, network config manager и многие другие. Также в релиз включены превью-фичи для, которые ожидаются в финальной версии ОС. Поэтому рекомендуется не использовать бету Photon 4.0 для производственных сред.
Разработка Photon OS очень сильно опирается на участие комьюнити. Поэтому ваши комментарии, предложения и отчеты об ошибках можно добавлять вот тут.
В этом релизе, как в прошлом, ОС распространяется в бинарном предзапакованном формате - загрузочный ISO, предустановленный минимальный OVA-пакет, кастомизированный под VMware, образ Amazon AMI, образ Google GCE, образ Azure VHD, а также образ Raspberry Pi (протестированный для архитектуры ARM64).
Образы Photon OS 4.0 Beta можно скачать по этой ссылке. Публичный репозиторий доступен вот тут.
Многие из вас знают про лучшее на рынке программно-аппаратное решение для организации хранилищ под виртуализацию StarWind Virtual SAN. О прошлом его обновлении, которое вышло весной этого года, мы писали вот тут.
Недавно компания StarWind выпустила обновление этого продукта в виде виртуального модуля OVF на базе Linux для VMware vSphere - VSAN OVF Version 20201027
Version 8 (build 13861).
Давайте посмотрим, что там появилось нового:
Общие улучшения и багофиксы
Обновлено ядро модуля Linux Kernel.
Настройка iScsiPingCmdSendCmdTimeoutInSec теперь по умолчанию выставлена в 5 секунд.
Исправленный процесс логирования для оповещений по email, теперь они не смешиваются с общими событиями почтового сервера.
Улучшены операции по остановке службы (ранее этот процесс мог подвиснуть в определенных обстоятельствах).
Обновлена имплементация SCSI-протокола для более корректного процессинга команд UNMAP/TRIM.
Улучшения синхронной репликации
Добавлена опция использования SMB-шары как ресурса witness для устройств с синхронной репликацией.
Исправлена обработка персистентных резерваций для устройств с синхронной репликацией.
Исправлены некоторые случаи обновления состояния партнерского узла после восстановления из ситуации split-brain.
Управляющая консоль (Management Console)
Исправлено падение консоли, когда StarWind Event log содержал записи с некорректными строковыми значениями.
Обновлен диалог настроек нотификаций по email (добавлена валидация и спрятаны поля логина-пароля при отсутствии необходимости аутентификации).
Модуль StarWindX PowerShell
Добавлена возможность добавления HA-устройств в конфигурации Node Majority. Теперь узел StarWind или SMB-шара могут быть использованы как witness. Более подробно об этом можно узнать из примеров сценариев CreateHAPartnerWitness.ps1 и CreateHASmbWitness.ps1.
Поправлена обработка параметра ALUA для командлетов по созданию HA-устройства.
Скачать пробную версию StarWind Virtual SAN для VMware vSphere в формате виртуального модуля OVF можно по этой прямой ссылке.
Это такая утилита, построенная на принципах клеточного автомата (cellular automata, CA), которая позволяет смоделировать характеристики производительности для путей данных в кластере vSAN. Сам методика клеточных автоматов позволяет смоделировать и исследовать комплексную систему со множеством элементов, работающих параллельно и имеющих короткие соединения между собой, при этом создающих эмерждентную сущность.
При симуляции стека хранилищ данная утилита моделирует передачу блоков данных по сети через аппаратные ресурсы по различным коротким соединениям, таким как CPU->кэш->DRAM->SSD/HDD, соединения PCIe, Ethernet и т.п. Вот небольшое видео о том, как это работает:
Основная цель такой симуляции - получить идеальные показатели пиковой пропускной способности к хранилищам - так называемая speed-of-light (SOL) throughput.
При моделировании запросов ввода-вывода на чтение-запись применяются различные модели движения блоков данных по сети. Эти модели включают в себя функции репликации данных, вычисление parity, контрольных сумм, шифрование, компрессия данных и некоторые другие факторы, влияющие на длительность операций.
Результаты можно использовать для бенчмаркинга реальных инфраструктур, изменения настроек для повышения производительности, а также понимания затыков (bottlenecks), понижающих общую производительность стека работы с хранилищами vSAN в виртуальной инфраструктуре.
Вот пример такого моделирования:
В общем, если у вас есть время на подобные игры - скачивайте Storage Simulator Using Cellular Automata по этой ссылке. Инструкции по использованию доступны там же на вкладке "Instructions".
RSS
