В очередной раз, о пользе анализаторов трафика

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

    Начнём, по традиции, издалека. Заказчик решил повысить уровень своего Microsoft Active Directory леса и домена с 2008 до 2012 R2. На самом деле, необходимость была только в повышении уровня до 2008 R2, но, учитывая сложность таких проектов в большой среде (а у заказчика было больше 1000 одних только Windows серверов в десятках географически распределённых локаций), Service Owner принял решение переходить сразу на 2012 R2. Тем более, что актуальным серверным билдом на тот момент уже был Windows Server 2012 R2.

    Для того чтобы повысить функциональный уровень, нужно сначала мигрировать все контроллеры домена на новую ОС. Процесс это, достаточно простой, с точки зрения Windows. Все сложности возникают в тех локациях, где реализована интеграция чего-нибудь стороннего с Active Directory средой. То есть почти везде:)

    Перечисление всех проблем той миграции — это материал для нескольких статей. Сейчас же нам интересна только одна средних размеров локация — два контроллера, тысяча пользователей, два EMC Celerra NAS устройства (еще, конечно, сотня серверов, базы данных и приложения, но про них мы говорить не будем). Помимо общих ресурсов, NASы использовались для хранения профилей пользователей. Когда есть два контроллера в одном сайте, то процесс миграции значительно упрощается — мы можем мигрировать один контроллер и, если что-то пошло не так, его всегда можно потушить — второй-то остаётся (тут важно отметить, что к этому моменту уже успешно прошла миграция нескольких локаций и никаких особых проблем никто не ждал).

    Итак, день Х настал и один из контроллеров был выведен из домена. Мы переставили ОС и заново подняли на нём роль. Сразу же стало понятно, что в этот раз без проблем не обошлось. У пользователей, которые получали новый контроллер в качестве Logon Server пропал доступ к их профилям и общим папкам. Вместо этого они видели грустное сообщение:

    image


    Мы потушили проблемный контроллер, создали под него отдельный искусственный сайт и добавили туда его IP адрес c /32 маской, перевели туда один тестовый клиент и начали тестирование (да, с этого можно было начать, но для экономии времени и ввиду низких рисков Service Owner разрешил включить контроллер сразу в живом сайте после конца рабочего дня). Недавно здесь была статья о full-stack администраторах. Это, без сомнения, очень классно, если у вас есть знания и права на всех устройствах, чтобы самому решить проблему. Чаще всего же в компании существует довольно жёсткое разделение команд на зоны ответственности и вы технически не можете проверить настройки NAS работая в команде поддержки Active Directory. Понятно, что раз проблема появилась после изменения вашего компонента инфраструктуры, то и проблемы, по умолчанию, на вашей стороне. Как найти причину ваших бед и получить аргументы для запроса на какие-то действия со стороны другой команды?

    Бесценным инструментом будет анализатор трафика. Здесь я немного лукавлю — одно из важных отличий Windows 2008 от Windows 2012 R2 — новая версия SMB протокола, так что я догадывался в чём будет проблема. Мой любимый инструмент в таких случаях — Wireshark (не сочтите за рекламу). Быстрая установка, запуск capture, попытка получить доступ к общей папке и что же мы видим с логах обмена пакетами?

    NegotiateProtocol Request
    NegotiateProtocol Response
    SessionSetup Request
    SessionSetup Response
    TreeConnect Request Tree:
    TreeConnect Response
    Ioctl Request
    Ioctl Response, Error: STATUS_INVALID_DEVICE_REQUEST

    Ioctl Response, Error: STATUS_INVALID_DEVICE_REQUEST показывает нам, что SMB сессия между пользователем и NAS устройством не установлена. Учитывая, что со старым контроллером всё работает, я получил подтверждение своей догадки — проблема в новой версии SMB. Вообще, NAS устройства в среде заказчика должны поддерживать новую версию SMB (в других локациях-то всё было нормально), так что следующей идеей стало поискать не нужно ли для этого обновить на них прошивку. Бинго! Форум вендора подтверждает нам, что старая версия прошивки Celerra не поддерживает обновлённый SMB. Информация отсылается команде поддержки NAS вместе с логами обмена пакетов, ссылками на сайт вендора и запросом на обновление прошивки. В следующие выходные прошивка обновлена и тесты подтверждают — теперь всё работает.

    В качестве послесловия. Когда я рекомендую знакомым воспользоваться анализатором трафика для изучения какой-либо проблемы, самая частая причина почему человек не хочет этого делать — он думает, что это очень сложно. Это не так! В большинстве случаев, для того чтобы понять, что происходит, достаточно посмотреть на лог обмена пакетами ну и иногда прочитать KB статью о том, как устроен интересующий вас протокол. Это очень просто. И это может сэкономить вам кучу времени.
    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 13
    • 0
      Можно для непонятливых чуть подробнее
      1) Клиент Windows 7
      2) NAS Cellera SMB 2.0
      3) DC Windows Server 2012 R2
      Понятно, что W7, может обращаться к сетевым ресурсам как по SMB2, так и SMB3. Если бы у вас была XP, то только SMB2, что не препятствует ей работать в лесу с DC Windows Server 2012R2.
      Другое дело что славная Cellera вдруг внезапно не смогла, расшифровать керберос-билет, выданный 2012R2, например.
      В чем же была проблема?
    • 0
      Анализатор трафика, а для многих wireshark это синоним, не сочтите за рекламу ), штука просто необходимая, допустим внедрение системы качества обслуживания без применения данного инструмента просто не представляю. А за статью спасибо, пример профессионального подхода к решению проблемы, к сожалению, зачастую не так…
      • 0
        а почему вообще такие мелочи как NAS не поддерживаются в актуальном виде?
        • 0
          Поддерживаются. Позвольте задать вам вопрос, через какой промежуток времени в вашей среде ставится последняя прошивка на все устройства? Как было сказано, в нескольких локациях до этого проблем не возникло, т.е. прошивка там уже была обновлена. Просто проект по переходу на последнюю прошивку ещё не добрался до этой локации (никто, собственно, и не торопился — всё же работало:)).
          • 0
            ну вообще у нас… если вышла новая прошивка, в течении месяца всё уже обработано. на всякий случай — есть тестовое отделение, на них проходят всячиские опыты в течении недели. NAS тонкие клиенты роутеры большие принтеры, ..
            • 0
              Я вам по хорошему завидую. Успевать за месяц обновить прошивки на всех устройствах это очень круто. У нас никогда не было столько людей в команде, чтобы можно было успевать так быстро всё сделать. Многие проекты обновления прошивок вообще висели в ожидании, если не было стимула аля, со старой прошивкой пропадёт поддержка вендора или вот, как здесь, со старой прошивкой не работают новые устройства.
              • 0
                27 отделений на отдел 4 человека
                • 0
                  Эти 4 человека занимаются только NAS для этой среды? Или всем? Занимаются ли они устройствами несокльких заказчиков?
              • 0
                У вас мир такой ванильный получается. Вышла прошивка, поставили прошивку. Зачем поставили, никто не понял.
                Потом поняли что новая глючит — даунгрейд не предусмотрен.
                Или как вариант в процессе апгрейда запороли девайс, а он не на гарантии.
                Жизнь она разнообразнее.
                • 0
                  Обычно две-три недели достаточно для выявления «глючности» прошивки под девайсы типа NAS.
                  Тем более, если прошивка проходит через тесты.
                  Если грамотно настроен мониторинг, а так же тестовые среды с репозитариями и разными версиями прошивок, то проблем возникнуть не должно.
                  Сталкивался с проблемой железного NAS-а и одной из известных бекап систем.
                  Там приходилось саму систему обновлять и NAS прошивку за ней. Иначе глюков было :(
                  У многих известных вендоров есть системы мониторинга прошивок и софта.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.