Релиз Red Hat Ceph Storage 4

10 марта 2020 года Red Hat анонсировал Red Hat Ceph Storage 4 – мажорный релиз, который добавляет ряд улучшений в масштабировании, мониторинге, управлении и безопасности. Дополнительно, одной из целей Ceph Storage 4, было спроектировать решение таким образом, чтобы с ним было проще начать работать.

Что такое Ceph?

Red Hat Ceph Storage – это серьезным образом масштабируемая платформа программно-определенного хранилища с открытым исходным кодом для развертываний с объемом хранилища вплоть до петабайтов (PB), предназначенное для современных рабочих нагрузок, таких как: анализ данных, искусственный интеллект/машинное обучение (AI/ML), облачная инфраструктура, медиа-репозитонии, хранение резервных копий, а также, многое другое. Оно спроектировано для обеспечения гибкости и помощи в решении проблем с хранилищем, с которыми сталкиваются современные окружения, а также с учётом будущих требований.

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

Рассмотрим наиболее значимые возможности, добавленные в новейшем релизе.

Укреплённый фронтенд (Frontend).

Red Hat Ceph Storage можно использовать для настройки объектного хранилища, совместимого с Amazon Simplified Storage Service (S3), на собственном оборудовании и взаимодействовать с ним через HTTP-шлюз Ceph при помощи Amazon S3 или OpenStack Swift API.

В данном релизе команда разработки представила Beast.Asio в качестве фронтенда по умолчанию для Object Store Gateway (RGW) и в качестве веб-фронтенда для Red Hat Ceph Storage. Beast может доставлять лучшую агрегированную пропускную способность с меньшим потреблением ресурсов, чем раньше, и позволяет Ceph RADOS Gateway (RGW) обеспечивать дополнительные соединения с меньшим потреблением памяти на каждый поток.

В 4-ой версии также добавлена поддержка классов хранилища совместимых с S3 для лучшего управления размещением данных в соответствии с потребностями приложений. Для всех кто заинтересован в размещении большого объёма данных от источников интернета вещей (IOT), создания моделей машинного обучения для искусственного интеллекта или архивации данных для нечастой выборки и управления – классы хранилища Ceph помогут управлять затратами на хранилище, при этом обеспечивая необходимый уровень производительности.

Ускоренный бэкенд (Backend).

Команда разработки не только улучшила фронтенд Red Hat Ceph Storage 4, но и представила BlueStore в качестве бэкенда по умолчанию для Ceph Object Storage Daemons (OSD), а также опубликовала результаты внутреннего тестирования, которые продемонстрировали видимый прирост производительности. BlueStore позволяет OSD писать напрямую на диск, а также предоставляет более оптимизированное хранение метаданных через RocksDB и предварительную запись журнала, которые расширяют, как пропускную способность, так и производительность ввода/вывода. В результате внутреннее тестирование показало лучшую производительность записи объектов (в два с лишним раза) и меньшую задержку, чем была представлена год назад.

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

Золотое правило системного администратора: «если что-либо нужно сделать больше чем один раз – автоматизируй это». Разработчики Red Hat Ceph Storage 4 также взяли его на вооружение и использовали опыт Ansible, чтобы упростить установку и управление.

В 4-ой версии была добавлена возможность установить кластер Ceph при помощи веб-интерфейса Cockpit. Под капотом данного решения используются сценарии Ansible (Playbooks).

Новый дашборд Red Hat Ceph Storage 4 предлагает новые возможности мониторинга, а также администраторы с его помощью могут управлять томами хранилища, создавать пользователей и даже запускать обновление кластера. Разумеется, инструменты командной строки никуда не делись и, по-прежнему, доступны, но 4-ая версия позволяет использовать их через веб-интерфейс.

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

Также была представлена довольно значимая возможность мониторинга, которая позволяет визуализировать IOPS, пропускную способность и задержки для превентивного определения проблем и устранения их.

Улучшенные утилиты.

Большинство администраторов знакомы с утилитой ceph-medic, которая позволяет определять проблемы, препятствующие работе Ceph. На аппаратных установках утилита использует файл инвентаризации Ansible, чтобы определить хосты и установить соединение по SSH для получения информации об установке и конфигурации.

В Ceph Storage 4, ceph-mefic позволяет подключаться к контейнеризированному кластеру разными типами подключений (docker, podman, Kubernetes или OpenShift). При использовании OpenShift или Kubernetes даже файл инвентаризации не нужен – файлы хостов генерируется динамически и группируются по типу демона.

Улучшенная файловая система Ceph.

В Ceph Storage 4 были реализованы несколько возможностей, которые будут полезны для администраторов хранилищ.

До Ceph 4, необходимо было погружаться в журналы сервера метаданных, чтобы увидеть статус запущенной файловой системы Ceph (CephFS). Теперь администраторы могут вызвать ceph -w (которая используется для отображения рабочей сводки статуса кластера Ceph), и это отобразит статус активных кустов.

Ещё больше.

Ceph Storage 4 имеет набор прочих улучшений, в том числе сокращённые требования масштаба для установки Ceph. Теперь необходимо всего три узла, чтобы начать работать с Ceph Storage 4, но для крупных организаций, Ceph можно масштабировать до объемов, измеряемых экзабайтами (Eb) с количеством объектов более одного миллиарда (по результатам внутреннего тестирования).

Также было улучшено шифрование и сокращена административная нагрузка в Ceph Storage 4. Red Hat предоставляет стандартный жизненный цикл поддержки продолжительностью 3 года и дополнительно два года поддержки (ELS) для организаций, которым это необходимо.

Заключение.

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

Для получения дополнительной информации о Ceph Storage 4, обратитесь к заметкам к релизу.

Релиз VMware vSAN 7

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

Гиперконвергентная инфраструктура (HCI) была быстро адаптирована организациями всех размеров для лучшего обеспечения бизнес требований. Большинство организаций, заинтересованы в более быстрой доставке новых товаров и услуг клиентам и сотрудникам; так как новые технологии существенно сократили время на разработку и доставку информационных продуктов, лица принимающие решения, относительно инфраструктуры информационных технологий, нуждаются в платформе, которая позволит быстро доставлять новые решения. Для этого было определено несколько путей:

• Простое управление инфраструктурой и ускоренное развертывание.
• Унифицированное блочное и файловое хранилище.
• Поддержка появляющихся технологий, таких как контейнеры.

Примечание.

Источник: Perry, Christian. Voice of the Enterprise, Servers and Converged Infrastructure, Budget and Outlook, 2019. 451 Research.

В соответствие с трендами и потребностями индустрии vSAN 7 упрощает управление инфраструктурой за счёт сокращения инструментария, необходимого для управления жизненным циклом серверов. Организации теперь могут унифицировать блочное и файловое хранилище при помощи vSAN, что сокращает потребность в сторонних решениях и ускоряет развертывание общих файловых ресурсов. Также vSAN включает новые возможности, расширяющие облачные приложения, за счет обеспечения поддержки файловых служб и дополнений vSphere для Kubernetes (ранее известного как Project Pacific) через VMware Cloud Foundation.

Упрощение обновления кластеров при помощи vSphere Lifecycle Manager.

Управление жизненным циклом – это продолжительная по времени задача, общая для администраторов, поддерживающих свои инфраструктуры при помощи нескольких инструментов, которые требуют специализированных навыков. На данный момент, клиенты VMware используют два разных интерфейса для управления: vSphere Update Manager (VUM) для обновления программного обеспечения и драйверов, а также утилиты, предоставляемые производителями серверов для обновления микропрограммного обеспечения (Firmware). В данном релизе, VMware HCI предоставляет основу для нового, унифицированного механизма обновления программного обеспечения и управления микропрограммным обеспечением – vSphere Lifecycle Manager (vLCM).

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

Встроенные файловые службы (Native File Services) для vSAN.

Встроенные файловые службы (Native File Service), интегрированные в vSAN, упрощают управление хранилищем, так как они помогают сократить зависимость от сторонних решений. vSAN 7 теперь поддерживает NFS v3 и v4.1, что в результате обеспечивает новые сценарии применения. Включение файловых служб происходит так же, как и включение других возможностей уровня кластера, таких как службы iSCSI, шифрование, дедубликация и сжатие. Весь жизненный цикл развертывания и поддержки файловых служб может быть выполнен через пользовательский интерфейс vCenter. Данная возможность помогает обеспечить широкий диапазон сценариев применения, требующих файловых служб с простой интеграцией.

Развертывание современных приложений на vSAN при помощи Enhanced Cloud Native Storage.

vSAN 7 расширяет и укрепляет возможности облачного хранилища, впервые представленные в vSAN 6.7 Update 3. vSAN теперь поддерживает использование встроенных файловых служб в качестве постоянных томов для кластеров Kubernetes. В дополнение к файловым службам, vSAN обеспечивает дополнение vSphere для Kubernetes (ранее известное как Project Pacific), которое обеспечивает возможность развертывания на хранилище (Datastore) vSAN рабочих нагрузок в контейнерах с сохранением состояния.

Общие улучшения.

Интегрированное представление DRS о конфигурациях растянутого кластера (Stretched Cluster).

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

Немедленная операция восстановления после замены наблюдающего хоста (Witness Host) vSAN.

vSAN 7 расширяет логику замены и повторной синхронизации наблюдающего хоста (Witness Host) vSAN для растянутого кластера (Stretched Cluster) и двух-узловых топологий. Когда устройство хоста наблюдателя vSAN должно быть заменено, это может быть легко сделано при помощи кнопки “Replace Witness” в vCenter. После замены, vSAN вызывает немедленную операцию восстановления, быстро приводя хост наблюдения vSAN к полноценному состоянию. Это улучшение помогает устранить уязвимость переходного процесса в защите уровня сайта за счёт расширения процесса восстановления хоста наблюдения vSAN.

Перенаправление ввода/вывода растянутого кластера (Stratched Cluster) на основе дисбаланса объема между сайтами.

Топология растянутого кластера (Stretched Cluster) vSAN предоставляет устойчивость виртуальных машин и данных в случае отключения сайта. Гибкость vSAN позволяет администраторам детально настраивать параметры конфигурации для отдельных виртуальных машин с разными уровнями защиты или связями (Affinity). В результате может получиться дисбаланс доступного объема в одном сайте по сравнению с остальными. vSAN 7 представил новую интеллектуальную возможность минимизировать влияние на производительность в связи с ограничивающими условиями. При обнаружении дисбаланса, vSAN проверяет множество параметров на основе того, что они ограничивают ввод/вывод и перенаправляет активный ввод/вывод в здоровый сайт. Эти предотвращающие проблемы шаги происходят без остановки работы виртуальных машин. Подобная оптимизация является отличным примером того, как представленные аналитические возможности vSAN гарантируют прогнозируемую работу несмотря на широкое разнообразие условий.

Точность отчетов об использованном пространстве на уровне виртуальных машин vSAN в интерфейсе vCenter.

vSAN 7 представил новый уровень целостности при создании отчётов об уровне объема виртуальных машин в vCenter для виртуальных машин, запущенных на vSAN. Изначально, vCenter рассчитывал объем для виртуальных машина на vSAN также, как и для виртуальных машин, размещенных на традиционном хранилище. Текущие улучшения помогут обозначить различия в отчётных данных между традиционными виртуальными машинами и vSAN в таких областях как представление кластера и хоста.

Улучшенные отчёты о памяти для будущих оптимизаций.

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

Видимость объектов vSphere Replication в представлении объема vSAN.

VMware vSphere Replication – это основанное на гипервизоре решение асинхронной репликации для виртуальных машин vSphere. Оно предоставляет простой и эффективный механизм для защиты и восстановления виртуальных машин. Репликация vSphere входит во все редакции, начиная с vSphere Essentials Plus Kit. vSAN 7 представил значительное улучшение для окружений, использующих vSphere Replication – администраторы теперь могут легко определять объекты данных, связанные с vSphere Replication на уровне объекта виртуальной машины, а также в представлениях объема на уровне кластера. Эта осведомленность о данных vSphere Replication помогает администратору определять ресурсы, используемые для нужд асинхронной репликации.

Поддержка для устройств большего объема.

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

Встроенная поддержка горячего добавления NVMe.

NVMe помогла установить новый уровень производительности для систем хранения. vSphere 7 представил одну возможность, которая соответствует или превышает возможности, связанные с более старыми устройствами SAS и SATA: поддержка горячего подключения устройств NVMe в vSphereи vSAN. Это предоставляет новый уровень гибкости и удобства обслуживания для хостов с устройствами NVMe, увеличивая время непрерывной работы за счёт упрощения задач обслуживания, связанных с добавлением, удалением и перемещением устройств хранения в хостах. Современные хосты могут иметь десятки подключенных устройств NVMe и преимущества от горячего подключения должно помочь как большим, так и маленьким окружениям.

Удаление требования Eager Zero Thick (EZT) для общих дисков в vSAN.

Данный релиз также представил улучшенную гибкость для приложений виртуальных машин (таких как Oracle RAC), использующих общие виртуальные диски. vSAN 7 устраняет предварительное требование формата Eager Zero Thick от дисков с флагами мульти-записи (Multi-Writer).

Заключение.

VMware vSAN 7 модернизирует гиперконвергентную инфраструктуру за счёт предоставления администраторам унифицированной плоскости управления хранилищем для блочных и файловых протоколов, а также предоставляет значительные улучшения, которые обеспечивают великолепное решение, как для традиционных, так и для облачных приложений. vSphere Lifecycle Manager сокращает сложность мониторинга и поддержки инфраструктуры за счёт консолидации инструментов обновления программного обеспечения, драйверов и микропрограммного обеспечения (Firmware), а также предоставляет модель требуемого состояния с применением требуемого образа. Общие файловые ресурсы vSAN 7 позволяют администраторам быстро разворачивать общие файловые ресурсы через единый рабочий поток; интегрированные общие файловые ресурсы также сокращают зависимость от сторонних решений и упрощают управление жизненным циклом. Так как облачные приложения под управлением Kubernetes также могут получить преимущества от общих файловых ресурсов vSAN, команда ИТ может консолидировать больше рабочих нагрузок в гиперконвергентной инфраструктуре (HCI) на базе vSAN и сделать её более эффективной. Дополнительные улучшения предоставляющие широкое разнообразие преимуществ, от расширенного мониторинга инфраструктуры, который помогает администраторам планировать будущие потребности, до инфраструктуры, готовой к завтрашнему дню, за счёт поддержки накопителей большего объема и увеличенного времени непрерывной работы за счёт горячего подключения NVMe. vSAN остаётся предпочтительной платформой, как для традиционных приложений, так и для эволюционирующих современных приложений, за счет бесшовной эволюции и быстрого внедрения инноваций.

P.S. С другими новыми возможностями VMware vSphere 7 можно познакомиться в статье «VMware vSphere 7: Основные службы для современного гибридного облака».

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

Тяжелым выдалось начало ноября, но пора возвращаться в привычный ритм, а на очереди у нас интересная тема по CentOS 8 – настойка iSCSI. Тема реализации цели (Target) и инициатора (Initiator) достаточно большая и подготовленный материал я разделил на два веб-каста:

• Настройка iSCSI в CentOS 8.
• Продвинутая настройка iSCSI в CentOS 8.

Сегодня я представляю вашему вниманию первый веб-каст из этой группы, он будет посвящен описанию передачи блочного хранилища по  протоколу iSCSI, участников передачи, способов организации фонового хранилища цели (Target) и элементов составляющих цель (Target) iSCSI. Демонстрационная часть веб-каста разделена пополам на две стороны, организующие передачу. В первой части демонстрируется установка пакетов, необходимых для работы интерфейса командной строки цели (targetcli), настройка службы цели (target.service) при помощи systemd, базовое разрешение порта в firewalld, настройка фонового хранилища и компонентов цели. (iSCSI). Во второй части демонстрируется смена имени инициатора iSCSI, настройка подключения к цели (Target) при помощи iscsiadm, форматирование логических единиц (LUN), а также монтирование логических единиц (LUNs) во время загрузки при помощи файла fstab.

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

P.S. В следующий м веб-касте речь пойдет о более комплексных возможностях настройки iSCSI и связанных компонентов в CentOS 8.

Посмотреть эту публикацию в Instagram

Публикация от Yuriy Lebedev (@lebedevum) 18 Ноя 2019 в 1:07 PST

Конвертация объединения сети (Bond) в группу (Team) в CentOS 7

Вот и пришло время для последнего веб-каста на тему продвинутого сетевого взаимодействия в CentOS 7.

В веб-касте вы найдете сравнение объединения сети (Bonding) с группировкой (Teaming), а также описание возможностей конвертации объединения (Bond) в группу (Team). Отдельно внимание в веб-касте удалено возможностям конвертации в разные форматы (ifcfg и JSON), переименованию интерфейса и отдельной конвертации опций объединения в конфигурационный файл группы.

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

P.S. Это заключительный веб-каст на тему группировки сети и девятый на тему сетевого взаимодействия, он охватывает практически все темы сетевого взаимодействия. Поэтому, если вы не знакомы с NetworkManager и его инструментом командной строки (nmcli), начните свое знакомство с веб-кастов на тему основ сетевого взаимодействия в CentOS 7:

• Комплексное именование сетевых устройств в CentOS 7
• Демон управления сетью (NetworkManager) в CentOS 7
• Настройка сети при помощи nmcli в CentOS 7

Если вы не знакомы с объединением сети (Bonding), то познакомиться с данной технологией можно при помощи следующих веб-кастов:

• Объединение сети (Bonding) в CentOS 7
• Управление параметрами объединения сети (Bonding) в CentOS 7

Если вы не знакомы с группировкой сети (Teaming), то начните свой просмотр с предыдущих веб-кастов группы:

• Группировка сети (Teaming) в CentOS 7
• Группировка сети (Teaming) при помощи файлов ifcfg в CentOS 7
• Управление параметрами группировки сети (Teaming) в CentOS 7

P.S. Это не только последний веб-каст на тему сетевого взаимодействия, но и последний веб-каст по CentOS 7, так как в связи с релизом CentOS 8 все дальнейшие веб-касты будут выходить уже на базе этой версии операционной системы. Кстати, первый веб-каст про новую операционную систему «Настройка Gnome в CentOS 8» уже вышел.

Посмотреть эту публикацию в Instagram

Публикация от Yuriy Lebedev (@lebedevum) 10 Окт 2019 в 12:26 PDT

Управление параметрами группировки сети (Teaming) в CentOS 7

Настала очередь продолжить разбор высокой доступности сетевого взаимодействия в CentOS 7. В предыдущих веб-кастах мы разобрали настройку группировку сети при помощи интерфейса командной строки NetworkManager (nmcli) и конфигурационных файлов ifcfg. На этот раз речь пойдет об управлении параметрами группировки сети (Teaming) в CentOS 7.

В веб-касте представлено описание доступных инструментов для управления группировкой сети (Teaming), а также доступных бегунов (Runner) и наблюдателей канала (Link Watcher). Центральное внимание в веб-касте уделено демонстрации настройки и управления параметрами группировки сети (Teaming) при помощи таких инструментов как teamd, teamnl и teamdctl.

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

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

• Группировка сети (Teaming) в CentOS 7
• Группировка сети (Teaming) при помощи файлов ifcfg в CentOS 7

Если вы не знакомы с организацией сетевого взаимодействия в CentOS 7, начните свое знакомство с веб-кастов по базовому сетевому взаимодействию:

• Комплексное именование сетевых устройств в CentOS 7
• Демон управления сетью (NetworkManager) в CentOS 7
• Настройка сети при помощи nmcli в CentOS 7

Также возможно для вас окажутся полезными веб-касты, посвященные иному способу обеспечения высокой доступности сети – объединению (Bonding):

• Объединение сети (Bonding) в CentOS 7
• Управление параметрами объединения сети (Bonding) в CentOS 7

Следующий веб-каст станет заключительным в группе в нем мы рассмотрим конвертацию объединения сети (Bond) в группу (Team).

View this post on Instagram

A post shared by Yuriy Lebedev (@lebedevum) on Aug 9, 2019 at 12:38am PDT

Добавление и удаление серверов Storage Spaces Direct в Windows Server 2019

В предыдущих веб-кастах мы обсуждали развертывание двух и трех-узловых решений Storage Spaces Direct на базе Windows Server 2019. На этот раз речь пойдет о добавлении и удалении серверов в конвергентные и гиперконвергентные решения.

В веб-касте представлено описание процедуры горизонтального масштабирования Storage Spaces Direct, а также демонстрируется подготовка, добавление и удаление сервера. Дополнительно обсуждаются преимущества использования диспетчера отказоустойчивых кластеров (Failover Cluster Manager) и Windows PowerShell при добавлении и удалении серверов. Отдельное внимание уделяется вопросам масштабирования хранилища после изменения количества серверов в решении Storage Spaces Direct, а также демонстрируется использование вычислительных возможностей кластера виртуальными машинами Hyper-V.

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

P.S. Если вы не знакомы с конвергентными и гиперконвергентными решениями, то рекомендую начать свое знакомство со статьи «Обзор Storage Spaces Direct».

Это третий веб-каст про Storage Spaces Direct, поэтому если вас интересуют вопросы развертывания – обратитесь к предыдущим веб-кастам:

1. Развертывание Storage Spaces Direct в Windows Server 2019
2. Вложенная устойчивость Storage Spaces Direct в Windows Server 2019

Группировка сети (Teaming) при помощи файлов ifcfg в CentOS 7

Вот и пришло время продолжить наше изучение высокой доступности и продвинутой настройки сетевых интерфейсов в CentOS 7, на очереди у нас второй веб-каст посвященный группировке сети (Teaming) в CentOS 7.

В веб-касте представлено описание группировки сети и ее компонентов, а именно доступных бегунов (Runner) и наблюдателей канала (Link Watcher) в CentOS 7. Центральное место в веб-касте отводится демонстрации настройки группировки сети (Network Teaming) при помощи конфигурационных файлов ifcfg. Отдельное внимание уделено директивам TEAM_CONFIG и TEAM_PORT_CONFIG из конфигурационных файлов порта и группы (Team) и их синтаксису.

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

P.S. Если вы не знакомы с группировкой сети (Teaming) или вас интересует настройка при помощи интерфейса командной строки NetworkManager, то начните свое знакомство с веб-каста: «Группировка сети (Teaming) в CentOS 7».

Познакомиться же с основами сетевого взаимодействия в CentOS 7 можно при помощи следующих веб-кастов:

• Комплексное именование сетевых устройств в CentOS 7
• Демон управления сетью (NetworkManager) в CentOS 7
• Настройка сети при помощи nmcli в CentOS 7

А в следующем веб-касте речь пойдет про параметры группировки сети (Teaming).

View this post on Instagram

A post shared by Yuriy Lebedev (@lebedevum) on Aug 8, 2019 at 3:52am PDT

Обновление отказоустойчивого кластера до Windows Server 2019

Пришло время продолжить разговор на тему Windows Server 2019, на очереди у нас вопрос обновление отказоустойчивого кластера (Failover Cluster) до Windows Server 2019.

Начиная с Windows Server 2016 появилась новая возможность обновления отказоустойчивых кластеров с минимальным простоем или вообще без него. В данном веб-касте речь пойдет о том, как процесс устроен и что изменилось в связи с выходом Windows Server 2019.

В веб-касте вы найдете описание процедуры обновления отказоустойчивых кластеров, предварительные требования и поддерживаемые сценарии обновления. Центральное место в веб-касте уделяется демонстрации обновления отказоустойчивого кластера с Hyper-V на базе Windows Server 2016 до Windows Server 2019, без остановки виртуальных машин. При этом половина демонстраций выполняется при помощи диспетчера отказоустойчивых кластеров (Failover Cluster Manager), а вторая при помощи Windows PowerShell. Отдельное внимание в веб-касте уделяется вопросу функционального уровня (Functional Level) отказоустойчивого кластера и демонстрации его повышения.

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

P.S. Это уже не первый веб-каст про обновление до Windows Server 2019, ранее я публиковал веб-каст: «Обновление доменных служб Active Directory (AD DS) до Windows Server 2019».

Ближайшее время я планирую сделать еще несколько веб-кастов на тему обновления до Windows Server 2019.

Группировка сети (Teaming) в CentOS 7

Здравствуйте коллеги!

Продолжаем изучать продвинутые конфигурации сети в CentOS 7, на очереди у нас группировка сети (Network Teaming). Группировка (Teaming), в отличии от объединения (Bonding), это новинка CentOS 7 (RHEL 7), поэтому ей нужно уделить больше времени. Собственно, про группировку сети (Network Teaming) я подготовил и записал 4 веб-каста:

• Группировка сети (Teaming) в CentOS 7
• Группировка сети (Teaming) при помощи файлов ifcfg в CentOS 7
• Управление параметрами группировки сети (Teaming) в CentOS 7
• Конвертация объединения сети (Bond) в группу (Team) в CentOS 7

Сегодня я представляю вашему вниманию первый из них, в веб-касте вы найдете информацию о группировке сети (Teaming), особенностях ее архитектуры, поведении интерфейсов группы (Team), установке демона teamd и доступных инструментах для настройки и управления группировкой сети (Network Teaming). Центральное место в веб-касте отведено созданию сетевой группы (Team) при помощи интерфейса командной строки NetworkManager (nmcli) и тестированию ее работы при отключении портов.

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

P.S. Если вы не знакомы с настройкой сети в CentOS 7, начните свое знакомство с веб-кастов из группы «Базовое сетевое взаимодействие в CentOS 7»:

• Комплексное именование сетевых устройств в CentOS 7
• Демон управления сетью (NetworkManager) в CentOS 7
• Настройка сети при помощи nmcli в CentOS 7

Познакомиться с альтернативным способом объединения сетевых интерфейсов можно при помощи группы веб-кастов «Объединение сети (Bonding) в CentOS 7»:

• Объединение сети (Bonding) в CentOS 7
• Управление параметрами объединения сети (Bonding) в CentOS 7