Страницы

пятница, 30 апреля 2021 г.

Стандартный коммутатор (vSS) в VMware vSphere 7

 

Давненько у нас не было веб-кастов про VMware vSphere 7, а тем временем пришло время обсудить устройство сети и стандартный коммутатор vSphere (vSphere Standard Switch).

В веб-касте представлено описание компонентов сети составляющих основу сетевого стека хостов ESXi, а все демонстрации веб-каста представлены в двух интерфейсах: веб-интерфейсе хоста ESXi и vSphere Client. В веб-касте вы найдете настройку существующего коммутатора (vSS) и создание нового стандартного коммутатора, в том числе демонстрируется настройка устойчивого соединения с внешней сетью при помощи группы входящих каналов (Uplink), создание групп портов (Port Group) и переключение ресурсов между стандартными коммутаторами. В результате демонстраций настраивается разделение трафика управления хостом ESXi с трафиком виртуальных машин.

Подробности и видео: LebedevUM.

P.S. Чуть позже я планирую вернуться к вопросу виртуальных сетей VMware vSphere.

понедельник, 26 апреля 2021 г.

Тонкости настройки syslog в Citrix ADC

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

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

Можно разделить требования к syslog Citrix ADC на две части: функциональные возможности Citrix ADC и операционная система Citrix ADC. Рассмотрим обе стороны этого вопроса.


Syslog для функциональных возможностей Citrix ADC.

Документация по syslog для Citrix ADC рекомендует использовать выражения продвинутых политик (Advanced Policy Expression) при настройке Citrix ADC, так как выражения классических политик (Classical Policy) устарели и не будут поддерживаться в будущих релизах.

Процесс настройки сообщений syslog для отправки на удаленный сервер в общем виде состоит из 3 шагов:

  1. Создание сервера syslog для определения назначения и способа отправки сообщений.
  2. Создание политик syslog для определения момента отправки сообщений.
  3. Привязка политик syslog для определения сообщений, которые должны быть отправлены.

Если нет особых требований, то абсолютно нормально отправлять все уровни журнала, за исключением уровня отладки (Debug). Уровень отладки может быть включен, в крайнем случае, для устранения неисправностей. Необходимо осторожно подходить к уровню отладки (Debug), так как на этом уровне генерируется значительный объем данных, который быстро заполняет доступное хранилище.

Если существуют требования учёта срабатываний списков контроля доступа (ACL), ведение журнала ACL должно быть включено и для сервера syslog, куда будут отправляться журналы, а также отдельные правила ACL для записи в журнал.

Также не лишним будет включить отправку пользовательских сообщений syslog. В противном случае в журнале не отобразятся настраиваемые действия (Actions).

Пример команд для настройки отправки сообщений syslog для хранения на сервер syslog и Citrix Application Delivery Management (ADM):

add audit syslogAction retention-syslog-SRV -logLevel EMERGENCY ALERT CRITICAL ERROR WARNING NOTICE INFORMATIONAL -acl ENABLED -userDefinedAuditlog YES

add audit syslogAction CitrixADM-syslog-SRV -logLevel EMERGENCY ALERT CRITICAL ERROR WARNING NOTICE INFORMATIONAL -userDefinedAuditlog YES

add audit syslogPolicy retention-syslog-POL true retention-syslog-SRV

add audit syslogPolicy CitrixADM-syslog-POL true CitrixADM-syslog-SRV

bind audit syslogGlobal -policyName retention-syslog-POL -priority 100

bind audit syslogGlobal -policyName CitrixADM-syslog-POL -priority 110


Syslog для операционной системы Citrix ADC.

Довольно часто в развертываниях встречается отсутствующая конфигурация для отправки сообщений о происходящем в операционной системе на внешний сервер syslog. Все, что попадает в журнал, – это вход пользователя в систему и запуск команды shell, ничего более в журнал на сервере syslog не попадает. Это значит, что в случае сбоя и невозможности получить локальный журнал на Citrix ADC, узнать подробности происходившего не получится. Более того, при условии возможности интерактивного входа, передовой опыт не позволяет доверять целостности файлов локальных журналов.

Некоторые конфигурационные файлы, хранящихся в /etc, могут быть скопированы в /nsconfig, для большей устойчивости в процессе перезагрузки. /etc/syslog.conf – один из примеров таких файлов.

Выбор syslog local, зависит от конфигурации сервера syslog, на который будут отправляться сообщения. Для Citrix ADM можно использовать все доступные уровни local от 0 до 7. Звёздочка (*) после local7, определяет все сообщения для отправки на сервер syslog.

Также необходимо отредактировать /nsconfig/rc.netscaler для перезапуска демона syslog после загрузки, чтобы убедиться в использовании корректного конфигурационного файла. Если Citrix ADC сконфигурирован в высоко доступной паре, NSIP не может быть указан в явном виде, вместо этого, он может быть извлечен из файла na.conf, как показано в примере ниже.

Одна последняя вещь, которую нужно учесть – все команды, которые выполняются в оболочке, выполняются от имени пользователя root, который и будет указан в поле имени пользователя (username) в сообщениях syslog.

Для включения отправки сообщений syslog о событиях в операционной системе на внешний сервер выполните следующие действия:

1. Скопируйте /etc/syslog.conf в /nsconfig/syslog.conf.

2. Добавьте следующие строки в /nsconfig/syslog.conf.

local7.*                 @<IP-АДРЕС СЕРВЕРА SYSLOG>

local7.*                 @<IP-АДРЕС СЕРВЕРА SYSLOG>

3. Добавьте следующие строки в /nsconfig/rc.netscaler:

pkill syslogd

nsip=$(grep -i ‘set ns config -IPAddress’ /nsconfig/ns.conf | cut -d ‘ ’ -f 5)

/usr/sbin/syslogd -b $nsip -n -v -v -8 -C &

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

Надёжный внешний репозиторий для хранения журналов syslog – это критически важный аспект при устранении неисправностей, проведении расследований и прочих задачах. Надеюсь, информация из данного блога окажется для вас полезной и пригодится в дальнейшем. За основу данного материала я хотел бы поблагодарить Magnus Esse, а дополнительную информацию по ведению журнала событий аудита можно получить в документации.

четверг, 22 апреля 2021 г.

Настройка NGINX в CentOS 8

Продолжение группы веб-кастов на тему веб и прокси сервера NGINX в CentOS 8 – на этот раз речь пойдет о настройке сервера NGINX.

В веб-касте представлено описание и начальная настройка сервера Nginx, а центральное внимание уделено настройке виртуального хостинга на базе заголовков хоста (Host Header), IP-адресов и портов. Отдельное внимание уделено вопросам настройки контекста SELinux для контента веб-сайтов.

Подробности и видео: LebedevUM.

P.S. Это второй веб-каст в группе, поэтому если вы не знакомы с сервером Nginx, рекомендую предварительно посмотреть веб-каст «Установка NGINX в CentOS 8».

А следующий веб-каст будет посвящен настройке шифрования TLS для сервера Nginx.

Пример настройки виртуального хостинга на базе сервера Apache в CentOS 8 можно посмотреть в веб-касте «Настройка виртуальных хостов Apache в CentOS 8».

вторник, 20 апреля 2021 г.

Настоящее и будущее Citrix App Layering

Команда Citrix App Layering последние несколько месяцев усиленно работала над добавлением новых возможностей в продукт, а также над составлением планов по дальнейшему развитию. Рассмотрим релиз 2102, его возможности и представленные планы развития продукта.


Поддержка Google Cloud Platform.

Стала доступна официальная поддержка Google Cloud Platform (GCP) – это кульминация нескольких месяцев работы инженеров над шестой платформой, поддерживаемой Citrix App Layering. В результате клиенты Google Cloud могут использовать все возможности Citrix App Layering в GCP, также, как и в Azure, VMware vSphere, Microsoft Hyper-V, Citrix Hypervisor и Nutanix AHV.


Преимущества и сценарии применения.

Citrix App Layering теперь поддерживает GCP в следующих сценариях:

  • App Layering Management Appliance (ELM) теперь может быть развернут в GCP.
  • Новый соединитель платформы (Platform Connector) добавлен в ELM для подключения к GCP.
  • Уровни операционной системы (OS Layers), платформы (Platform Layers) и приложений (App Layers) теперь могут создаваться, управляться и публиковаться напрямую в GCP.
  • Эластичные и пользовательские уровни могут быть развернуты в GCP.
  • Соединитель GCP полностью поддерживает разгрузку составления композита.
  • Экспорт/импорт уровней теперь поддерживает GCP. Можно экспортировать уровни с ELM на другой платформе и импортировать их в ELM на GCP.
  • Теперь можно публиковать многоуровневые образы в GCP или для создания машин на базе Google Cloud.


Развертывание и настройка.

Для развертывания Citrix App Layering в GCP, необходимо выполнить следующие шаги:

  1. Настроить проект GCP, в том числе для использования его с Citrix App Layering.
  2. Создавать виртуальную машину в проекте GCP, которая будет и использована для установки Citrix App Layering Appliance (ELM).
  3. Загрузить пакет установки ELM.
  4. Выгрузить системный диск ELM в GCP.
  5. Создать образ из системного диска.
  6. Создать экземпляр виртуальной машины из образа.

После завершения описанных выше шагов, можно приступить к созданию уровней операционной системы (OS Layers), платформы (Platform Layers) и приложений (App Layers), а также создать и развернуть шаблоны образов.

Для получения подробных инструкций по развертыванию Citrix App Layering на базе GCP обратитесь к документации


Рекомендации по использованию Citrix App Layering в GCP.

Следует отметить следующие предварительные требования/рекомендации при использовании Citrix App Layering в GCP:

  • Рекомендуется разворачивать ELM в GCP для управления уровнями и публикации шаблонов образов. Создание соединителя платформы GCP в ELM, не запущенного в GCP – это не протестированная конфигурация. В связи с требованиями к соединению и пропускной способности, производительность конфигурации с подключением из стороннего окружения (не GCP) может быть посредственной.
  • При импорте уровней из другой платформы, необходимо добавить версию уровня операционной системы и переключиться на использование новой версии уровня. Иначе машины упаковки и публикуемые образы будут уходить в ошибки с синим экраном.


Релиз Citrix App Layering 2104.

Citrix App Layering 2104 уже доступен для загрузки. Также можно выполнить обновление развернутого экземпляра для получения последних исправлений и расширений.


Главные приоритеты на 2021-ый год.

Команда разработки, планируя текущий год, определила для себя направления для расширений: управление, производительность и функциональность.


Окончание поддержки Silverlight.

Консоль управления App Layering переходит на более современную платформу. На сегодняшний день консоль управления построена на базе Microsoft Silverlight. Так как платформа Silverlight будет снята с поддержки 12 октября 2021 года, а также в связи с прочими целями, было принято решение о смене технологии, лежащей в основе пользовательского интерфейса.

Для решения этой задачи и обеспечения быстрой доставки новых возможностей, проект был разбит на несколько фаз:

  1. Шаблоны и уровни.
  2. Завершение нового пользовательского интерфейса и удаление Silverlight.


Фаза 1: Шаблоны и уровни.

В первую очередь команда разработки сосредоточится на реализации новых элементов пользовательского интерфейса для управления шаблонами образов (Image Templates) и уровнями (Layers). Эти два компонента составляют основу ежедневных задач управления Citrix App Layering. Приоритет этих возможностей над остальными элементами пользовательского интерфейса (пользователи/роли, система и так далее) даст администраторам улучшенный интерфейс для большинства административных задач.

Для административных задач за пределами шаблонов образов и уровней, администраторы будут переключиться обратно в текущую консоль на базе Silverlight. ELM будет поддерживать оба интерфейса (новый и на базе Silverlight), а переключение между ними потребует простого изменения URL в веб-браузере. Команда разработки надеется, что администраторам не потребуется слишком часто переключаться между пользовательскими интерфейсами.


Фаза 2: Завершение нового пользовательского интерфейса и удаление Silverlight.

Сразу после доставки нового интерфейса Citrix App Layering для управления шаблонами образов (Image Templates) и уровнями (Layers), команда разработки приступит к разработке оставшихся компонентов пользовательского интерфейса. После полной реализации нового интерфейса, устаревший пользовательский интерфейс будет удален вместе с фоновыми компонентами Silverlight, на которых он построен.


Запуск Silverlight после окончания поддержки.

Безопасное управление и доставка рабочего пространства – главный приоритет Citrix. В связи с тем, что Microsoft перестанет поддерживать Silverlight после октября 2021-го года, Citrix рекомендует своим клиентам изолировать устаревшую платформу Silverlight, реализовав доступ к устаревшей конфигурации App Layering через Citrix Secure Browser. Таким образом, пользователи смогут получить бесшовные возможности веб-приложения, где устаревшая консоль Citrix App Layering будет отображаться в любом предпочтительном локальном веб-браузере.


Улучшения производительности пользовательского уровня и уровня персонализации пользователя.

Большую часть 2020-го года команда разработки была сфокусирована на возможностях пользовательского уровня (User Layer) и уровнях персонализации пользователя (UPL) с целью улучшить производительность и пользовательские возможности, а также сократить время входа Windows (Logon Time). В рамках проводимых работ были проведены исчерпывающие тесты с целью глубже понять взаимосвязи пользовательских уровней, что привело к выработке специфических рекомендаций:

  1. Пользовательские уровни (User Layers) и уровни персонализации пользователя (UPL) App Layering спроектированы для работы только с не постоянными машинами Windows. Очень важно понимать, что дополнительные накладные расходы появляются при переходе на доставку непостоянных рабочих столов пользователям. Проведенные тесты показали разницу в 40% при переходе с постоянных на непостоянные рабочие пространства. Окружения непостоянных машин, меняют поведение Windows в некоторых специфичных областях, таких как первый вход пользователя в систему. Важно понимать влияние размера окружения для реализации лучшей производительности за исходные вложения в реализацию решения рабочего пространства без сохранения состояния.
  2. После включения пользовательских уровней (Users Layers) в образе, необходимо войти в систему более одного раза перед первым входом конечного пользователя и запуском процессов настройки. После начального входа, который отображает экран настройки “Windows Hello”, Microsoft рекомендует выполнить второй вход в Windows от пользователя, прежде чем все процессы начальной настройки завершатся. После полного завершения начальной настройки время входа значительно сокращается.
  3. Число выделенных виртуальных процессоров (vCPU) для непостоянных образов оказывает критическое влияние на время входа. Для локальных окружений 4 vCPU показали оптимальную производительность в тестах. В Azure два виртуальных процессора (vCPU) показали лучшее соотношение цены и производительности. Дополнительные виртуальные процессоры также будут обеспечивать прирост производительности, но потребуют дополнительных вложений.
  4. Если машины быстро используются/освобождаются, то в таком случае может проявляться заметное влияние на время входа. Рекомендуется откалибровать настраиваемый период, который рабочий стол должен ожидать после загрузки/перезагрузки, перед разрешением входа пользователя. Подробности настройки политик BrokerDesktopgroup можно получить в документации разработчика.

Команда разработки надеется, что данные рекомендации помогут спроектировать и оптимизировать решение Citrix App Layering для предоставления наилучших возможностей для пользователей. 

Также во время исследований были определены некоторые области для дальнейшего улучшения пользовательских уровней и уровней персонализации пользователя (UPL). Команда разработки сфокусируется на расширениях, которые позволят в дальнейшем увеличить производительность и в целом возможности Citrix App Layering уже в текущем году.


Заключение.

Команда разработки сейчас активно собирает обратную связь о внедрениях Citrix App Layering в Google Cloud. Также, вместе с новым интерфейсом планируется реализация значительных улучшений в администрировании.

Ну и в заключении хотелось бы отметить, что Daniel Lazar (менеджер продукта Citrix App Layering) заявил, что во второй половине года команда разработки представит несколько технологий для предварительного ознакомления. После выхода версий для ознакомления с технологиями я обязательно о них расскажу.

пятница, 16 апреля 2021 г.

Новое в VMware vSAN 7 Update 2

Обладая клиентской базой в 30 000 внедрений, команда разработки VMware vSAN не останавливается на достигнутом и продолжает реализовывать инновации. 9 марта 2021 года был анонсирован vSAN 7 Update 2, который доставляет гибкую, устойчивую, готовую к текущим и будущим нагрузкам инфраструктуру, что позволит клиентам соответствовать динамическим требованиям бизнеса без компромиссов в производительности, эффективности или надежности. Команда разработки расширила удобство vSAN, развернутого на различных физических топологиях, чтобы клиенты могли лучше удовлетворять потребности роста рабочих нагрузок.


Масштабирование без компромиссов.

Вычислительные кластеры vSAN HCI Mesh.

VMware представила потрясающую новую возможность в vSAN HCI Mesh:

  • В vSAN 7 Update 2 традиционные кластеры vSphere могут монтировать удаленное хранилище данных vSAN (Datastore). 
  • Вычислительные кластеры HCI Mesh могут потреблять ресурсы хранилища, предоставляемые удаленными кластерами vSAN. 
  • Кластеры vSphere могут подключаться к традиционным массивам хранилища. 

Вычислительные кластеры HCI Mesh используют протоколы vSAN для максимальной эффективности и возможности клиента с легкостью удовлетворить потребности любого сценария применения. 

Наиболее важное заключается в том, что вычислительные кластеры HCI Mesh не требуют какого-либо лицензирования vSAN.

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

Одна из наиболее интересных возможностей, относящихся к HCI Mesh – это интеграция с политиками хранения (Storage Policies). Теперь, при определении политик хранения, администратор может выбирать тип службы данных (такой как дедубликация и сжатие (Deduplication and Compression) или шифрование в состоянии покоя (Data-at-rest Encryption)).


Расширенные файловые службы.

Файловые службы vSAN – это мощное решение для обеспечения потребностей периметра, удаленных офисов и филиалов (ROBO). Теперь они могут поддерживать растянутый кластер и конфигурации из двух узлов.


Улучшения растянутого кластера.

Конфигурация растянутого кластера должна учитывать не только различные сценарии отказа, но и условия восстановления. vSAN 7 Update 2 представил интеграцию с размещением данных и распределенным планировщиком ресурсов (DRS), таким образом, вслед за восстановлением после сбоя, DRS будет удерживать состояние виртуальной машины в сайте, до тех пор, пока данные не будут повторно синхронизированы. Это гарантирует, что операции чтения не будут использовать каналы между сайтами (ISL). Только после полной повторной синхронизации DRS начнет перемещать состояние виртуальных машин в требуемые сайты в соответствии с правилами DRS. Это улучшение может существенно сократить не нужные операции чтения и освободить ресурсы каналов между сайтами (ISL) для выполнения повторной синхронизации с восстанавливаемым сайтом. Также следует отметить что vSAN 7 Update 2 увеличил максимальное количество хостов растянутого кластера до 40.


vSAN через RDMA.

Удаленный прямой доступ к памяти (RDMA) – технология, которая позволяет системам обходить процессор и отправлять данные с меньшей задержкой и сокращением накладных вычислительных затрат. В результате получается не только сократить потребление вычислительных ресурсов, но и увеличить производительность хранилища. Гиперконвергкнтная архитектура идеально подходит для RDMA и vSAN 7 Update 2 представил поддержку RDMA over Converged Ethernet version 2 (RCoEv2). Кластеры будут автоматически определять поддержку RDMA, что, в свою очередь, приведет к увеличению производительности приложений и консолидации нагрузок.


Оптимизация производительности.

В vSAN 7 Update 2 улучшена производительность и эффективность процессора при обработке операций RAID 5/6. Это обеспечивает эффективность пространства за счет очищающего кодирования (Erasure Coding) и в то же время увеличивает производительность приложений, сокращая накладные расходы процессора на каждую операцию ввода/вывода.


AMD EPYC.

В гипервизор и пути данных vSAN были добавлены оптимизации для соответствия возможностям процессоров AMD EPYC.


Инфраструктура разработки и искусственного интеллекта (AI).

Совместимое с S3 хранилище объектов для искусственного интеллекта/машинного обучения (AI/ML) и облачных приложений (Cloud Native Apps).

В начале февраля 2021-го года была анонсирована доступность Cloudian HyperStore и MinIO Object Storage на платформе постоянных данных vSAN. Теперь клиенты могут эффективно разворачивать, потреблять и управлять объектным хранилищем (совместимым с S3) для искусственного интеллекта/машинного обучения (AI/ML) и облачных приложений прямо из VMware HCI. Современные приложения могут быть развернуты при помощи нескольких кликов. Подобная автоматизация упрощает развертывание и настройку, а также гарантирует настройку решения в соответствии с рекомендациями производителя.


Расширенное облачное хранилище в vSphere и vSAN.

Облачное хранилище (Cloud Native Storage) в vSphere и vSAN было расширено для лучшей поддержки приложений с отслеживанием состояния на базе Kubernetes. Пользователи устаревшего облачного поставщика vSphere (vSphere Cloud Provider, vCP) могут легко мигрировать на драйвер интерфейса хранилища контейнеров (Container Storage Interface, CSI). Это позволяет Kubernetes развертывать и управлять постоянными томами, запущенными на платформе vSphere, которые поддерживают изменение размера без остановки. Использование драйвера CSI в vSphere и vSAN позволяет администраторам и разработчикам эффективно разворачивать, управлять и вести мониторинг приложений в контейнерах и виртуальных машинах, развернутых на единой платформе.


Улучшенная безопасность.

Простой поставщик ключей vSphere.

Вместе с vSphere и vSAN 7 Update 2 была представлена поддержка компонента «Native Key Provider», который может упростить управление ключами для окружений, использующих шифрование. Встроенная служба управления ключами (KMS) идеально подходит для vSAN в двух-узловых топологиях, развертывания в периметре, также это отличный пример, демонстрирующий подход VMware к внутренней безопасности. Дополнительно Native Key Provider поддерживает работу с ESXi Key Persistence для устранения зависимостей.


Инструменты для изолированных окружений.

Skyline Health Diagnostics – это инструмент самообслуживания, который добавляет некоторые преимущества Skyline Health напрямую в изолированное окружение. Инструмент запускается администратором с требуемой частотой. Он будет сканировать журналы для обнаружения ошибок и выдачи уведомлений к важным ошибкам со ссылками на соответствующие статьи в базе знаний (KB). Разработчики ставили перед собой цель – сократить время, которое администраторы тратят на устранение ошибок в изолированных окружениях.


Улучшения шифрования передаваемых данных (Data In Transit, DIT).

Модуль криптографии для шифрования DIT прошел проверку FIPS 140-2.


Упрощенное управление.

Расширения vSphere Lifecycle Manager (vLCM).

vSAN 7 Update 2 доставляет три расширения в vSphere Lifecycle Manager:

  • vLCM расширил возможности выбора систем Hitachi Vantara UCP-HC и Hitachi Advanced Servers в дополнение к серверам Dell 14G, HPE10G и Lenovo ThinkAgile, которые работают с vLCM.
  • vLCM теперь поддерживает кластеры vSphere с Tanzu и сетями NSX-T.
  • Создание кластера было упрощено за счет возможности выбора образа с существующего хоста.


Улучшенная устойчивость данных.

В случае возникновения незапланированного отключения vSAN 7 Update 2 будет немедленно записывать все инкрементальные обновления на дополнительный хост, помимо хостов, удерживающих активную реплику объекта. Это поможет гарантировать устойчивость измененных данных в случае отключения еще одного хоста, удерживающего активную реплику объекта. Данная возможность построена на базе улучшений, представленных в vSAN 7 Update 1, где эта техника использовалась для запланированных событий обслуживания. Это улучшение надежности данных имеет еще одно преимущество: сокращение времени за которое выполняется повторная синхронизация устаревших объектов.


Проактивная высокая доступность (Proactive HA).

vSAN 7 Update 2 теперь поддерживает vSphere Proactive HA, что позволяет превентивно мигрировать состояние приложений и любые потенциально сохраненные данные на другой хост.


Расширенный мониторинг.

Понимание здоровья и производительности сети – это важная часть обеспечения гиперконвергкнтной платформы, такой как vSAN. vSAN 7 Update 2 представил несколько новых метрик и проверок здоровья, для обеспечения лучшей видимости фабрики коммутации, которая соединяет хосты vSAN. Несколько новых метрик было добавлено для мониторинга физического уровня, в том числе для ошибок транспортировки и CRC, а также ошибок и пауз передачи и получения. Эти метрики используются не только для демонстрации графиков производительности на базе времени, но и для уведомления администратора о преодолении критических лимитов. Все эти новые сетевые метрики и предупреждения вместе с уже существующими в vSAN, предназначены для предоставления администратору детальных подробностей об используемой сети.


Быстрая загрузка vSphere.

Быстрая загрузка (Quick Boot) была расширена новой опцией «приостановка в памяти» (Suspend-to-memory). Это обеспечивает быструю установку исправлений с низким влиянием на vSphere без необходимости выполнять полную эвакуацию хоста.


Следующие шаги.

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

Дополнительные сведения о VMware vSphere 7 Update 2 можно получить в моей статье «Релиз VMware vSphere 7 Update 2».