Страницы

вторник, 3 марта 2020 г.

Настройка SSL/TLS для Apache в CentOS 8


Настало время для заключительного веб-каста на тему Apache HTTP Server в CentOS 8. На этот раз мы рассмотрим шифрование веб-трафика, а точнее настройку SSL/TLS.

Данный веб-каст состоит из двух частей. В первой части описываются общие концепции SSL/TLS и цифровых сертификатов, а также демонстрируется генерация частного ключа, запроса на подпись сертификата и само-подписанного сертификата. Вторая часть сосредоточена вокруг модуля mod_ssl для Apache HTTP Server в ней описывается настройка и демонстрируется создание виртуального хоста для обеспечения SSL/TLS подключений к веб-серверу. Дополнительно в веб-касте затрагивается вопрос управления версиями TLS.

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

P.S. Это заключительный веб-каст на тему Apache HTTP Server в CentOS 8, если вы не знакомы с Apache HTTP Server, рекомендую смотреть веб-касты в хронологическом порядке:


Ну а следующие несколько веб-кастов на тему CentOS 8 будут посвящены дискам, разделам, томам и файловым системам.

четверг, 27 февраля 2020 г.

Анонс Red Hat Satellite 6.7 Beta


11 февраля Red Hat анонсировал доступность Red Hat Satellite 6.7 Beta. Данный релиз нацелен на новые и улучшенные интеграции, а также улучшенные возможностей безопасности и управления контентом.

Red Hat Satellite – это масштабируемая платформа управления исправлениями, развертываниями и подписками инфраструктуры Red Hat вне зависимости от того, где она запущена. Satellite 6.7 Beta содержит улучшения отчётов, автоматизации и поддержки.

Несмотря на то, что Satellite 6.7 Beta поддерживает хосты Red Hat Enterprise Linux 8, Satellite 6.7 должен быть установлен на хост Red Hat Enterprise Linux 7. Возможность запуска Satellite на хостах с RHEL 8 планируется в грядущих релизах.

Основные возможности Satellite 6.7 Beta:
  • Расширения автоматизации:
    • Улучшенная производительность для динамической инвентаризации внутри Ansible Tower, для увеличения скорости обновлений динамической инвентаризации.
    • Использование Ansible Runner внутри Satellite для лучшей длительной интеграции Ansible, что в свою очередь поддерживает актуальность Satellite с последними релизами Ansible.
  • Расширения интеграции Red Hat Enterprise Linux:
    • Возможность открывать и использовать веб-консоль для индивидуальных хостов с Satellite без дополнительной аутентификации.
    • Расширения System Purpose для подключения назначенных систем к ключам активации в процессе развертывания. Это спроектировано для предоставления целостных возможностей настройки данных подписок на новых хостах.
    • Расширения модуля Stream, содержащие возможность создавать представления контента, отфильтрованные на базе модуля, и возможность гранулировано обновлять представления контента с зависимостями.
  • Расширение возможностей безопасности:
    • Обновления к HTTP Proxy, разработанные для упрощения использования и обеспечения возможности настроить HTTP Proxy глобально или на базе отдельных репозиториев.
    • Олицетворение пользователя, которое позволяет администратору видеть представление другого пользователя в Satellite.
    • Поддержка аутентификации Common Access Cards (CAC) через Red Hat SSO для предварительного ознакомления с технологией.
  • Расширения управления контентом:
    • Новый шаблон отчета для создания отчётов по правам, упрощающих генерацию отчётов, используемым в Satellite.
    • Возможность импортировать и экспортировать шаблоны через пользовательский интерфейс Satellite и получение обновлений по статусу импорта/экспорта.
    • Поддержка загрузки RPM-пакетов с исходными кодами (файлы типа SRPM) через API или интерфейс командной строки.
  • Расширения развертывания:
    • Поддержка развертывания Azure, позволяющая создавать вычислительные ресурсы для Azure и разворачивать новые хосты в Azure через Satellite.
    • Расширения в вычислительных ресурсах Google Compute Engine (GCE) для добавления конечных точек интерфейса разработки приложений (API) и интерфейса командной строки (CLI).
  • Расширения производительности и масштабирования:
    • Улучшенный помощник настройки (Tuning Assistant), который добавляет новые средние (Medium) и большие (Large) профили настройки, оптимизирует существующие профили, позволяет упростить процедуру изменения профилей настройки по мере роста окружения и содержит общие улучшения производительности.
    • Улучшения производительности в задачах (Tasks), также включающие общую сводку по приостановленным задачам.
  • Еще немного нового:
    • Представлена опция для рандомизации порядка выполнения удаленных заданий, позволяющая сократить загрузку при выполнении большого числа заданий на большом количестве хостов.
    • Улучшения удобства использования, в том числе обновления PatternFly освежившие страницу входа и редактор шаблонов.

Клиенты с активными подписками Red Hat Satellite уже могут протестировать новые возможности Satellite 6.7 Beta.

Дополнительная информация доступна на странице часто задаваемых вопросов Red Hat Satellite 6.7 Beta.

среда, 26 февраля 2020 г.

Сплаттинг переменных в Windows PowerShell 5


Вот и подошла к концу группа веб-кастов, посвященных переменным в Windows PowerShell 5. Остался заключительный аккорд – «сплаттинг» переменных.

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

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

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

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

Ну а следующая группа веб-кастов станет самой большой в разделе Windows PowerShell 5, она будет посвящена управлению потоком (Flow Control).

вторник, 25 февраля 2020 г.

Рекомендации по проектированию VMware vSAN: Быстрые устройства хранения или быстрая сеть


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

Многие, архитектуры, построенные на базе гиперконвергентных инфраструктур, дополняют эту тайну. Что наиболее важно для производительности кластера vSAN: быстрые устройства хранения или быстрая сеть? Это популярный вопрос и хотя ответ заключается в том, что они оба важны, требуется некоторое пояснение, чтобы лучше понять, почему влияние на окружение может быть разным.

Обработка ввода/вывода (I/O Processing) в vSAN.


Одна из сильных сторон vSphere – это возможность приоритезации. Ассортимент планировщиков, встроенных в гипервизор управляет процессами на процессоре хоста, входящей и исходящей сетевой активностью и вводом/выводом хранилища. Так как планировщики – это процессы уровня ядра, они выполняют свою работу крайне эффективно.

VMware vSAN использует собственный планировщик для определения и приоритезации различных типов ввода/вывода хранилища, запущенного через стек. Это часть работы, которая делает компонент Adaptive Resync, представленный в vSAN 6.7, столь эффективным. Обратите внимание, что данные механизмы помогают приоритезировать локальные действия ввода/вывода на хосте. 

Устройства хранения (Storage Devices).


Исходная производительность устройств хранения сильно различается, даже если рассматривать только твердотельные накопители. Устройства SATA, SAS и NVMe имеют существенные отличия, выливающиеся, в итоге, в производительность, а также в целостность. Даже самые быстрые устройства NVMe, использующие NAND флеш, не являются лидерами производительности, новые технологии, такие как 3D XPoint (Intel Optane) позволяют преодолеть некоторые препятствия, связанные с NAND. Индустрия хранения развивается очень быстро, но благодаря архитектуре vSAN, новые технологии можно гранулировано встраивать, позволяя инфраструктуре ЦОД эволюционировать.

При планировании высокопроизводительного кластера vSAN, необходимо использовать быстрые устройства хранения на буферном уровне (Buffer Tier) и на уровне ёмкости (Capacity Tier). Устройства хранения – это часть финального отрезка пути данных и менее производительные устройства могут привести к невозможности соответствия необходимым ожиданиям производительности.

Сетевое взаимодействие (Networking).


Сетевые коммутаторы и интерфейсы, подключенные к ним – это то, что связывает все компоненты воедино. Сетевое взаимодействие играет особенно важную роль в гиперконвергентной инфраструктуре (HCI), так как действия ввода/вывода могут быть расширены за пределы локального хоста. К сожалению, промышленная практика ссылки на спецификацию коммутатора просто по максимальной скорости порта отменяет все важные подробности коммутационного оборудования. Возможности коммутационного оборудования зависят от многих факторов, таких как: пропускная способность соединительной платы, доступный объем буферизации портов на коммутаторе, а также являются ли платы ASIC достаточно мощными для соответствия требованиям обработки пактов в окружении. Эти факторы зачастую и являются причинами недостаточной производительности. John Nicholson выпустил отличную серию статей на эту тему и, совместно с Broc Yanda, презентовал сессию на VMworld.

Другое испытание с коммутационным оборудованием заключается в том, что его типичный жизненный цикл в производстве дольше, чем у прочих активов центра обработки данных (ЦОД). Продолжительный жизненный цикл обозначает, что архитектору нужно быть более осведомлённым о будущих требованиях и, в связи с их изменениями, возможно, придется инвестировать раньше, чем планировалось.

Как они опираются друг на друга.


Планировщики на базе хоста, такие как vSAN, приоритезируют ввод/вывод по мере его генерации хостом или поступления на аппаратный стек хоста. Они не поддерживают сеть и не предполагают, что другие пакеты могут ожидать отправки на хост. Но неправильно подобранные коммутаторы, не справляющиеся с нагрузкой, могут привести к падению производительности. Если сеть испытывает перегрузки какой угодно формы (пропускная способность, обработка или буферизация), это может стать аспектом правил TCP. По мере увеличения частоты сброса пакетов увеличивается количество повторных передач. Не смотря на надёжность TCP, шаги обработки при перенасыщении становятся дорогостоящими для пиковой производительности и целостности. Хуже всего то, что перенасыщение оказывает влияние на все системы, подключенные к коммутаторам.

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

Например, если клиент использует скромные коммутаторы 10 Gb и рассматривает 25/100 Gb – это решение приходит не от уровня утилизации коммутаторов, а с целью исключить узкое место на уровне коммутаторов, не позволяющее узлам использовать свой потенциал по максимуму. Вместе с увеличением производительности хостов, необходимо увеличивать и производительность сети.

Итоги.


Оптимизация производительности часто заключается в исключении узких мест там, где их легче обнаружить и исключить. Инвестиции в более производительное коммутационное оборудование поможет сместить вопрос конкуренции в сторону хоста, где за счет соответствующих планировщиков – управление проще, а восстановление требуемого уровня производительности при помощи более быстрых устройств хранения легче. Хорошие коммутаторы стоят достаточно дорого, но с учётом более продолжительного жизненного цикла коммутаторов и возможностью vSAN легко добавлять новое, более быстрое оборудование, это становится мудрым шагом в любом проекте центра обработки данных (ЦОД).

пятница, 21 февраля 2020 г.

Настройка виртуальных хостов Apache в CentOS 8


Очередной веб-каст на тему Apache HTTP Server в CentOS 8. На этот раз в центре внимания виртуальный хостинг.

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

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

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

Следующий веб-каст станет заключительным в группе, в нем речь пойдет о настройке шифрования веб-трафика Apache HTTP Server.