Решение проблемы msg.snapshot.error-QUIESCINGERROR при создании снапшотов VMware

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

   Описание работы системы: организовано резервное копирование виртуальных машин с помощью Veritas NetBackup. Одним из вариантов резервного копирования виртуальных машин является создание снапшотов этих машин и запись их на ленточное хранилище. Этот вариант не самый лучший, поскольку создание снапшотов виртуальных машин в принципе нельзя рассматривать как полноценный бэкап: есть вероятность возникновения ошибок ввода-вывода с последующим созданием "inconsistent backup". Тем не менее этот вариант был выбран и реализован, поскольку позволял вместо общей LAN использовать SAN-сеть для бэкапа, что увеличивало скорость копирования в существенное количество раз и разгружало LAN. 

   Перед резервным копированием машины через создание снапшота необходимо в идеале выключить виртуальную машину, но в продакшене это сделать проблематично. Поэтому используются специальные pre_- и post_freeze_scripts, которые останавливают нужные сервисы до создания снапшота, а потом восстанавливают работоспособность сервисов после завершения создания снапшотов. Такие скрипты используются и в других продуктах по созданию резервных копий, и даже в базе знаний VMware есть KB, посвященные созданию нужных скриптов.

CCNA Routing & Switching - Рекурсивный поиск в таблице маршрутизации

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

Чем отличается статический маршрут в интерфейс от маршрута на next-hop-адрес?

    В курсе CCNA Routing&Switching, который успешно преподается в нашей Академии разбирается множество интересных проблем и задач, с которыми специалисты сталкиваются в работе ежедневно. Некоторые из этих задач вызывают у студентов особенно большое количество вопросов, т.к. не всегда очевиден выбор тех или иных решений, технологий и даже настроек.

   Один из популярных вопросов, связанный с темой статической маршрутизации, звучит следующим образом: в каком случае статический маршрут настраивается с указанием интерфейса, а в каком - с указанием адреса next-hop и в чем разница между этими двумя вариантами указания маршрута?

Nateks NetXpert NX-3424GW - Достаем из коробки, делаем базовую настройку. Первое впечатление.

   Давно уже хотел создать рубрику "Сделано в России", но все не было то времени, то желания, то "подопытных кроликов". А тут вдруг стали попадать в руки железки российского производства (ну или каким-либо образом причастные к РФ). В общем то, что выдается под соусом "импортозамещения".

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

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

   Первым "кроликом" в данной рубрике оказался коммутатор L2  Nateks NetXpert NX-3424GW. Посмотрим, что можно сказать про это устройство по вышеуказанным пунктам.

Как включить\выключить беспроводные интерфейсы на точках доступа Cisco

   Иногда требуется включить\выключить вещание в том или ином диапазоне на точках доступа Cisco типа Lightweight, т.е. работающих без собственной ОС, полностью контролирующихся беспроводным контроллером Cisco.

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