Страницы

пятница, 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».

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

Выход из скриптов в Windows PowerShell 5

Очередной веб-каст в теме базовых скриптов в Windows PowerShell 5. На этот раз в центре внимания – выражения, прерывающие выполнение кода скрипта.

Центральное место в веб-касте отведено выражениям return и exit, позволяющим прерывать выполнение кода. Отдельное внимание в веб-касте уделено применению функций в теле скрипта и выполнению выражений прерывания в теле функций. Дополнительно в веб-касте описывается и демонстрируется передача выходных кодов при помощи выражения exit.

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

P.S. Это уже третий веб-каст в группе, поэтому если вы не знакомы со скриптами, рекомендую смотреть материал по порядку:

Все веб-касты в хронологическом порядке: Windows PowerShell 5.

А следующий веб-каст группы будет посвящен области действия переменных.

среда, 14 апреля 2021 г.

Протокол gRPC доступен для развертываний Citrix ADC

В Citrix ADC протокол gRPC – это легковесная, высокопроизводительная платформа удаленного вызова процедур (RPC) с открытым исходным кодом. Платформа gRPC оптимальна для работы с разными языками, запущенными на любых операционных системах. Она обеспечивает лучшую безопасность и производительность по сравнению с другими протоколами.

За счёт использования gRPC поверх протокола HTTP/2 можно:
  • Разрабатывать распределенные приложения для центров обработки данных и публичных/частных облачных инфраструктур.
  • Предоставлять ускоренные клиент-серверные коммуникации для мобильных, веб или облачных приложений.
  • Упрощать доступ к облачным сервисам и приложениям.
  • Разворачивать микро-сервисы.

Почему gRPC в Citrix ADC.


Протокол gRPC в Citrix ADC применяется поверх HTTP/2 для поддержки высоко производительных и масштабируемых интерфейсов разработки приложений (API). За счет использования двоичных значений вместо текста, достигается увеличенная эффективность полезной нагрузки с точки зрения потребления памяти и хранения значений в числовых форматах.

В Citrix ADC запросы HTTP/2 мультиплексируются в одном подключении TCP, обеспечивая несколько конкурентных сообщений без ущерба для использования сетевых ресурсов. Также используется сжатие заголовков с целью сокращения размера запросов и ответов.

Принцип работы gRPC.


Конечная конфигурация gRPC работает как отправка запроса gRPC от клиента по протоколу HTTP/2 и отправка ответа обратно от сервера gRPC. На следующей диаграмме показана работа конфигурации gRPC на устройстве Citrix ADC.


На диаграмме отображена схема работы gRPC и распределение потока трафика. Следующая функциональная последовательность описывает взаимодействие компонентов с трафиком в устройстве ADC и то, как устройство обрабатывает сервис gRPC:
  1. Для развертывания конфигурации gRPC, необходимо сначала включить HTTP/2 в профиле HTTP и включить глобальную поддержку HTTP/2 на стороне сервера.
  2. Когда клиент отправит запрос gRPC, виртуальный сервер балансировки нагрузки проверит трафик gRPC при помощи политик.
  3. На базе проверки политик, виртуальный сервер балансировки нагрузки (с привязанными к нему сервисами gRPC) завершит обработку запроса и перешлет его фоновому серверу gRPC.
  4. Аналогичным образом, когда сервер gRPC отвечает клиенту, Citrix ADC завершает обработку ответа и перенаправляет его клиенту gRPC.

Заключение.


Использование gRPC в развертывании Citrix ADC имеет преимущества над традиционными интерфейсами разработки приложений (API), так как работа происходит поверх протокола HTTP/2. Она поддерживает быстрые и эффективные коммуникации для развертываний микросервисов в облаках. Так как все большее число сервисов Citrix перемещается в облако, возможность обрабатывать вызовы gRPC при помощи Citrix ADC обеспечит требуемые производительность и безопасность вместе с простотой управления.

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

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

Расширение бесплатного доступа к Red Hat Enterprise Linux

25 февраля 2021 года Red Hat анонсировала новую бесплатную программу для нужд и потребностей проектов и организаций: Red Hat Enterprise Linux (RHEL) для Open Source Infrastructure. Присоединяясь к растущему набору бесплатных и недорогих программ, RHEL для Open Source Infrastructure предоставляет простой, четкий и задокументированный процесс доступа к RHEL для проектов, сообществ, органов стандартизации и прочих некоммерческих организаций, участвующих в создании программного обеспечения с открытым исходным кодом. Несмотря на дальнейшие планы Red Hat по пересмотру программ, мы познакомимся с тем, что доступно уже сегодня для всех заинтересовавшихся.

RHEL для Open Source Infrastructure расширяет существующую поддержку для проектов с открытым исходным кодом, которая теперь включает в себя:

  • Fedora для ведения разработки на переднем крае улучшений и расширений операционной системы Linux.
  • CentOS Stream для тестирования приложений и рабочих нагрузок до выхода следующего релиза лидирующей корпоративной платформы Linux.
  • RHEL для Open Source Infrastructure, чтобы дать сообществу, проектам, фондам и прочим организациям стабильную основу для создания и размещения инновационного программного обеспечения с открытым исходным кодом.

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

Red Hat регулярно предоставляет бесплатный доступ к RHEL таким группам, но процесс до текущего момента не был формализован, проработан, доступен и прозрачен, как этого бы хотелось. Вместе с анонсом смещения ресурсов на CentOS Stream в конце 2021, Red Hat хочет убедиться, что организации, создающие и тестирующие будущее программное обеспечение с открытым исходным кодом, имеют доступ к RHEL.


RHEL для Open Source Infrastructure.

Программа RHEL для Open Source Infrastructure предполагает бесплатный доступ к подписке RHEL для легальных организаций в пределах их инфраструктуры. Это включает в себя системы для разработки, тестирования и общих требований проекта (таких как веб-серверы, почтовые серверы и так далее). Эти подписки предоставляются с самостоятельной поддержкой по умолчанию, что обеспечивает полный доступ к клиентскому порталу Red Hat, статьям базы знаний и форумам, а также включает доступ к аналитическому инструменту Red Hat Insights. Также Red Hat может предоставлять бесплатную поддержку в зависимости от области и природы организации.

Neil McGovern, исполнительный директор Gnome Foundation:

«Будучи некоммерческой организацией мы опираемся на различную помощь, что помогает нам достигать целей, которые позволят каждому человеку получить доступ к технологиям, которым он сможет доверять. Подписки RHEL – важная часть этого. За счет полного управления операционной системой и обновлениями безопасности, мы можем сконцентрироваться на сервисах, которые мы предоставляем пользователям и разработчикам GNOME, без необходимости отвлекаться на фоновую операционную систему. Red Hat многие годы предоставляет нам эти сервисы по нулевой стоимости и мы с нетерпением ждём продолжения наших взаимоотношений в будущем. »


Доступ к подписке RHEL для Open Source Infrastructure.

Red Hat надеется на широкое применение RHEL в исходной разработке программного обеспечения с открытым исходным кодом, как в качестве платформы тестирования, так и в качестве надёжной основы для разработки. Данная программа доступна эксклюзивно для проектов и прочих организаций, поддерживающих создание программного обеспечения с открытым исходным кодом. В общем виде все программное обеспечение, распространяемое под лицензией, подтвержденной Fedora (Fedora-approved) предназначено для этой программы.

Проекты, спонсируемые коммерческими компаниями, также могут получить подписки RHEL для Open Source Infrastructure с условием использования полученного по программе только для независимой инфраструктуры проекта.

RHEL для Open Source Infrastructure не предназначена для индивидуальных разработчиков, текущих клиентов/партнёров Red Hat, государственных учреждений, академических или некоммерческих организаций, которые хотят использовать RHEL за пределами инфраструктуры проектов с открытым исходным кодом. Red Hat продолжит исследовать новые программы для традиционных некоммерческих и академических организаций, а также государственных учреждений. В то же время индивидуальные разработчики могут получить доступ к RHELчерез обновленную программу Red Hat Developer, а корпоративные клиенты могут получить RHEL для нужд разработки, обратившись к аккаунт-менеджеру за подпиской Developer for Teams.


Как получить подписку RHEL для Open Source Infrastructure.

Организации, заинтересованные в данной программе, могут обратиться на адрес program@redhat.com.

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

Данная программа не охватывает ситуации, когда проекты программного обеспечения с открытым исходным кодом используют инфраструктуру Public CI, предоставляемую сторонними компаниями, эта и другие программы продолжат работать, а Red Hat ещё не закончил расширять свои программы RHEL для полного соответствия потребностям сообщества. Все вопросы команде разработки можно задать на адрес centos-questions@redhat.com.

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

Установка NGINX в CentOS 8

Вот и пришло время для сетевого администрирования Linux. На этот раз в центре сервер NGINX, о его сценариях применения я расскажу в группе веб-кастов “Nginx в CentOS 8”. Группа будет состоять из 5 веб-кастов, все они уже записаны на базе актуальной версии CentOS Stream 8:

  • Установка NGINX в CentOS 8.
  • Настройка NGINX в CentOS 8.
  • TLS-шифрование NGINX в CentOS 8.
  • Обратное проксирование NGINX в CentOS 8.
  • Балансировка нагрузки при помощи NGINX в CentOS 8.


Сегодня я представляю вашему вниманию первый веб-каст группы, он рассказывает о возможностях NGINX, демонстрирует установку и описывает конфигурацию по умолчанию. Дополнительно в веб-касте представлены предварительные требования для установки NGINX, ключевые блоки и директивы конфигурационного файла nginx.conf, возможность выбора версии NGINX в потоках репозитория CentOS 8 и создание разрешения на доступ в FirewallD.

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

P.S. В следующем веб-касте, мы рассмотрим настройку веб-сервера NGINX в CentOS 8.

Если вас интересует тема веб-серверов в Linux, рекомендую обратить внимание на группу веб-кастов про Apache HTTP Server в CentOS 8, которую я публиковал ранее:

среда, 7 апреля 2021 г.

Доступна бета-версия Red Hat Enterprise Linux 8.4

31 марта 2021 стала доступна бета-версия Red Hat Enterprise Linux (RHEL) 8.4 – новейшей версии, лидирующей в мире корпоративной платформы Linux. Спроектированная для доставки корпоративных инноваций и ускорения цифровой трансформации от центра обработки данных до периметра и даже за его пределами, бета-версия RHEL 8.4 добавляет новые возможности и расширяет существующие компоненты для дальнейшего укрепления RHEL в качестве целостной основы открытых гибридных облаков.

Ключевые улучшения и новые возможности бета-версии RHEL 8.4 включают в себя:

  • Более простую и гибкую адаптацию гибридных облаков при помощи, улучшенной переносимости подписки между облачными и локальными окружениями, а также лучшую видимость развертываний подписки между сегментами гибридного облака.
  • Расширенное проактивное управление с новыми возможностями сервисов Red Hat Insights, в том числе аналитика угроз и отчёты соответствия безопасности, а также управление подписками, доступное сразу после развертывания RHEL 8.4.
  • Более мощная визуализация данных, которая может создавать простые представления данных производительности системы в веб-консоли RHEL, дашборде Grafana и Red Hat Performance Co-Pilot.

Будущие обновления в RHEL 8.4 добавят новые курируемые языки программирования и инструменты разработки через потоки приложений (Application Streams), более глубокую интеграцию с Red Hat Ansible Automation Platform и расширения в Red Hat Performance Co-Pilot для более лёгкого управления в реальном времени и визуализации. Полный список новых и расширенных возможностей бета-версии RHEL 8.4 представлен в заметках к релизу.


Релизы CentOS Stream и бета-версия RHEL.

Вместе с возросшим интересом к CentOS Stream, благодаря возможности заглянуть в следующий релиз RHEL, важно отметить, что RHEL – это не то же самое, что и CentOS Stream. В то время как CentOS Stream предоставляет непрерывную доставку новых разработок RHEL, выпуск бета версии RHEL – это “точка во времени” CentOS Stream, которая затем укрепляется и тестируется для выпуска в производственное окружение.

Любой может посмотреть или присоединиться к CentOS Stream в любое время, в то же время бета-версия RHEL доступна для обладателей подписки через Red Hat Customer Portal. Индивидуальные разработчики могут получить подписку, присоединившись к программе Red Hat Developer Program.

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

Передача аргументов скриптам в Windows PowerShell 5

 

Настало время продолжить тему скриптов в Windows PowerShell 5. На этот раз мы рассмотрим способы передачи аргументов скриптам. Так как тема аргументов была очень подробно рассмотрена в группе веб-кастов про функции, данный веб-каст акцентирован на общих моментах и ключевых особенностях передачи аргументов в скриптах.

Веб-каст описывает и демонстрирует два способа передачи аргументов: через переменную $args и при помощи параметров скрипта. Помимо самих способов веб-каст содержит информацию об обработке подаваемых аргументов, синтаксисе параметров, а также об использовании именованных и позиционных параметров в скриптах.

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

P.S. Это второй веб-каст в группе, поэтому если вы не знакомы со скриптами, советую начать просмотр с предыдущего веб-каста: «Скрипты в Windows PowerShell 5».

Все веб-касты в хронологическом порядке: Windows PowerShell 5.

В следующем веб-касте группы мы рассмотри специальные выражения в скриптах Windows PowerShell 5.