Русский
Русский
English
Статистика
Реклама

Кластеры

Знакомство с Tanzu Mission Control

31.08.2020 18:16:08 | Автор: admin
Сегодня мы хотим поговорить о VMware Tanzu, новой линейке продуктов и услуг, которая была анонсирована во время прошлогодней конференции VMWorld. На повестке дня один из самых интересных инструментов: Tanzu Mission Control.
Осторожно: под катом чрезвычайно много изображений.



Что такое Mission Control


Как заявляет в своем блоге сама компания, основная задача VMware Tanzu Mission Control привнести порядок в кластерный хаос. Mission Control представляет из себя управляемую через API платформу, которая позволит администраторам применять политики к кластерам или группам кластеров и устанавливать правила безопасности. Основанные на модели SaaS инструменты безопасно интегрируются в кластеры Kubernetes через агента и поддерживают массу стандартных операций с кластером, включая операции управления жизненным циклом (развертывание, масштабирование, удаление и пр.).

В основе идеологии линейки Tanzu лежит максимальное использование open-source технологий. Для управления жизненным циклом кластеров Tanzu Kubernetes Grid используется Cluster API, Velero для бэкапов и восстановления, Sonobuoy для контроля соответствия конфигурации кластеров Kubernetes и Contour в качестве ингресс-контроллера.

Общий список функций Tanzu Mission Control выглядит так:
  • централизованное управление всеми вашими кластерами Kubernetes;
  • управление идентификацией и доступом (IAM);
  • диагностика и мониторинг состояния кластеров;
  • управление конфигурацией и настройками безопасности;
  • планирование регулярных проверок состояния кластера;
  • создание резервных копий и восстановление;
  • управление квотами;
  • визуализированное представление утилизации ресурсов.




Почему это важно


Tanzu Mission Control поможет бизнесу решить задачу управления большим парком кластеров Kubernetes, расположенных локально, в облаке и у нескольких сторонних провайдеров. Рано или поздно любая компания, чья деятельность завязана на IT, оказывается вынуждена поддерживать множество разнородных кластеров, расположенных у разных провайдеров. Каждый кластер превращается в снежный ком, которому нужна грамотная организация, соответствующая инфраструктура, политики, защита, системы мониторинга и многое другое.

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

Архитектура решения




Tanzu Mission Control это мультитенантная платформа, предоставляющая пользователям доступ к набору гибко настраиваемых политик, которые можно применять к кластерам и группам кластеров Kubernetes. Каждый пользователь привязан к Организации, именно она является корнем ресурсов групп кластеров и рабочих пространств (Workspaces).



Что умеет Tanzu Mission Control


Выше мы уже кратко перечислили список функций решения. Давайте посмотрим, как это реализовано в интерфейсе.

Единое представление всех кластеров Kubernetes предприятия:



Создание нового кластера:





Кластеру сразу можно назначить группу, и он унаследует заданные ей политики.

Подключение кластера:



Уже существующие кластеры можно просто подключить с помощью специального агента.

Группировка кластеров:



В Cluster groups можно группировать кластеры для наследования назначаемых политик сразу на уровне групп, без ручного вмешательства.

Workspaces:



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

Рассмотрим подробнее принципы работы Tanzu Mission Control в лабораторных работах.

Лабораторная работа #1


Разумеется, детально представить себе работу Mission Control и новых решений Tanzu без практики достаточно сложно. Для того, чтобы вы могли изучить основные возможности линейки, VMware предоставляют доступ к нескольким лабораторным стендам. На этих стендах можно выполнить лабораторные работы, используя пошаговые инструкции. Помимо собственно Tanzu Mission Control для тестирования и изучения доступны и другие решения. С полным списком лабораторных работ можно ознакомиться на этой странице.

Для практического ознакомления с различными решениями (включая небольшую игру по vSAN) отводится разное время. Не волнуйтесь, это весьма условные цифры. Например, лабу по Tanzu Mission Control при прохождении из дома можно решать до 9 с половиной часов. Кроме того, даже если таймер выйдет, можно будет вернуться и пройти всё заново.

Прохождение лабораторной работы #1
Для доступа к лабораторным работам понадобится аккаунт VMware. После авторизации откроется всплывающее окно с основной канвой работы. В правой части экрана будет помещена подробная инструкция.
После прочтения небольшой вводной части о Tanzu вам будет предложено пройти практику в интерактивной симуляции Mission Control.
Откроется новое всплывающее окно windows-машины, и вам будет предложено выполнить несколько базовых операций:
  • создать кластер
  • настроить его базовые параметры
  • обновить страницу и убедиться в том, что всё настроено корректно
  • задать политики и произвести проверку кластера
  • создать рабочее пространство
  • создать пространство имен
  • снова поработать с политиками, каждый шаг подробно разъясняется в руководстве
  • демо-апгрейд кластера




Разумеется, интерактивная симуляция не дает достаточной свободы для самостоятельного изучения: вы двигаетесь по заранее проложенным разработчиками рельсам.

Лабораторная работа #2


Здесь мы уже имеем дело с кое-чем посерьезнее. Эта лабораторная работа не настолько привязана к рельсам, как предыдущая и требует более внимательного изучения. Приводить её здесь целиком мы не станем: ради экономии вашего времени разберем только второй модуль, первый посвящен теоретическому аспекту работы Tanzu Mission Control. При желании вы можете пройти ее самостоятельно полностью. Этот модуль предлагает нам окунуться в управление жизненным циклом кластеров через Tanzu Mission Control.

Примечание: лабораторные работы Tanzu Mission Control регулярно актуализируются и уточняются. Если при прохождении вами лабораторной работы какие-то экраны или шаги будут отличаться от приведенных ниже, следуйте указаниям в правой части экрана. Мы же пройдемся по актуальной на момент написания статьи версии ЛР и рассмотрим ее ключевые элементы.

Прохождение лабораторной работы #2
После процесса авторизации в VMware Cloud Services, запускаем Tanzu Mission Control.



Первый шаг, предлагаемый лабораторией, развертывание кластера Kubernetes. Сначала нам необходимо получить доступ к ВМ с Ubuntu с помощью PuTTY. Запускаем утилиту и выбираем сеанс с Ubuntu.



Поочередно выполняем три команды:
  • создание кластера: kind create cluster --config 3node.yaml --name=hol
  • загрузка KUBECONFIG-файла: export KUBECONFIG="$(kind get kubeconfig-path --name="hol")"
  • вывод нод: kubectl get nodes




Теперь созданный нами кластер нужно добавить в Tanzu Mission Control. Из PuTTY возвращаемся в Chrome, переходим в Clusters и нажимаем ATTACH CLUSTER.
Из выпадающего меню выбираем группу default, вписываем предлагаемое лабой имя и нажимаем REGISTER.



Копируем полученную команду и идем в PuTTY.



Выполняем полученную команду.



Для отслеживания прогресса выполняем еще одну команду: watch kubectl get pods -n vmware-system-tmc. Дожидаемся, пока у всех контейнеров будет статус Running или Completed.



Возвращаемся в Tanzu Mission Control и нажимаем VERIFY CONNECTION. Если все прошло успешно, индикаторы всех проверок должны быть зелеными.



Теперь создадим новую группу кластеров и развернем там новый кластер. Идем в Cluster groups и нажимаем NEW CLUSTER GROUP. Вписываем имя и нажимаем CREATE.



Новая группа сразу должна появиться в списке.



Развернем новый кластер: идем в Clusters, нажимаем NEW CLUSTER и выбираем ассоциированную с лабораторной работой опцию.



Добавим имя кластера, выберем назначаемую ему группу в нашем случае hands-on-labs и регион деплоя.



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



Некоторые параметры нужно отредактировать, для этого нажимаем Edit.



Увеличим количество рабочих нод до двух, сохраним параметры и нажмем CREATE.
В процессе вы увидите такой прогрессбар.



После успешного деплоя перед вами будет такая картина. Все чеки должны быть зелеными.



Теперь нам надо скачать файл KUBECONFIG, чтобы управлять кластером с помощью стандартных команд kubectl. Это можно сделать прямо через пользовательский интерфейс Tanzu Mission Control. Скачиваем файл и переходим к скачиванию Tanzu Mission Control CLI нажатием click here.



Выбираем нужную версию и скачиваем CLI.



Теперь нам необходимо получить API Token. Для этого переходим в My Account и генерируем новый токен.



Заполняем поля и нажимаем GENERATE.



Полученный токен копируем и нажимаем CONTINUE. Открываем Power Shell и вводим команду tmc-login, затем токен, который мы получили и скопировали на предыдущем шаге, а потом Login Context Name. Выбираем info логи из предложенных, регион и olympus-default в качестве ssh-ключа.



Получаем namespaces:kubectl --kubeconfig=C:\Users\Administrator\Downloads\kubeconfig-aws-cluster.yml get namespaces.

Вводим kubectl --kubeconfig=C:\Users\Administrator\Downloads\kubeconfig-aws-cluster.yml get nodes, чтобы убедиться, что все ноды в статусе Ready.



Теперь в этом кластере нам предстоит развернуть небольшое приложение. Сделаем два развертывания coffee and tea в виде сервисов coffee-svc и tea-svc, каждый из которых запускает разные образы nginxdemos/hello and nginxdemos/hello:plain-text. Делается это следующим образом.

Через PowerShell зайдем в загрузки и найдем файл cafe-services.yaml.



Из-за некоторых изменений в API нам придется его обновить.

Pod Security Policies включены по умолчанию. Для запуска приложений с привилегиями необходимо привязать учетную запись.

Создаем привязку: kubectl --kubeconfig=kubeconfig-aws-cluster.yml create clusterrolebinding privileged-cluster-role-binding --clusterrole=vmware-system-tmc-psp-privileged --group=system:authenticated
Деплоим приложение: kubectl --kubeconfig=kubeconfig-aws-cluster.yml apply -f cafe-services.yaml
Проверяем: kubectl --kubeconfig=kubeconfig-aws-cluster.yml get pods



Модуль 2 закончен, вы прекрасны и восхитительны! Пройти остальные модули, включающие управление политиками и проверки на соответствие советуем самостоятельно.

Если вы хотите пройти эту лабораторную работу целиком, найти ее можно в каталоге. А мы перейдем к заключительной части статьи. Поговорим о том, на что удалось посмотреть, сделаем первые аккуратные выводы и развернуто скажем, что такое Tanzu Mission Control применительно к реальным бизнес-процессам.

Мнения и выводы


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

Польза Tanzu Mission Control


Система вышла действительно интересная. Сразу же хочется выделить несколько удобных и полезных плюшек:
  • Можно создавать кластеры через веб-панель и через консоль, что очень понравится разработчикам.
  • Управление RBAC через воркспейсы реализовано в интерфейсе пользователя. В лабе пока не работает, но в теории отличная вещь.
  • Централизованное управление привилегиями на основе шаблонов
  • Полный доступ к namespaceам.
  • Редактор YAML.
  • Создание сетевых политик.
  • Мониторинг здоровья кластера.
  • Возможность делать резервное копирование и восстановление через консоль.
  • Управление квотами и ресурсами с визуализацией фактической утилизации.
  • Автоматический запуск инспекции кластеров.

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

Приведем несколько высокоуровневых примеров.

В чужой кластер со своим уставом
Допустим, у вас есть команда разработчиков, в которой четко распределены роли и обязанности. Каждый занят своим делом и не должен даже случайно помешать работе коллег. Или же в команде есть один или несколько менее опытных специалистов, которым вы не хотите давать лишние права и свободы. Предположим также, что у вас есть Kubernetes сразу от трех провайдеров. Соответственно, чтобы ограничить права и привести их к общему знаменателю, придется поочередно заходить в каждую панель управления и все прописывать вручную. Согласитесь, не самое продуктивное времяпрепровождение. И чем больше у вас ресурсов, тем муторнее процесс. Tanzu Mission Control позволит руководить разграничением ролей из одного окна. На наш взгляд, очень удобная функция: никто ничего не сломает, если вы случайно забудете где-то указать нужные права.

Кстати, наши коллеги из МТС в своем блоге сравнивали Kubernetes от вендора и open source. Если вы давно хотели узнать, в чем отличия и на что смотреть при выборе welcome.

Компактная работа с логами
Еще один пример из реальной жизни работа с логами. Предположим, в команде также имеется тестировщик. В один прекрасный день он приходит к разработчикам и возвещает: в приложении обнаружен баг, срочно фиксим. Закономерно, что первое, с чем захочет ознакомиться разработчик это логи. Посылать их файлами через электронную почту или Telegram моветон и прошлый век. Mission Control предлагает альтернативу: можно задать разработчику специальные права, чтобы они могли читать логи только в конкретном пространстве имен. В таком случае тестировщику достаточно сказать: в таком-то приложении, в таком-то поле, в таком-то namespace есть баги, и разработчик без труда откроет логи и сможет локализовать проблему. А за счет ограниченных прав не полезет сразу её чинить, если компетенция не позволяет.

В здоровом кластере здоровое приложение
Еще одна отличная возможность Tanzu MC отслеживание здоровья кластера. Судя по предварительным материалам, система позволяет просматривать некоторую статистику. На текущий момент сложно сказать, насколько именно детализированной будет эта информация: пока что все выглядит достаточно скромно и просто. Есть мониторинг загруженности CPU и RAM, показаны статусы всех компонентов. Но даже в таком спартанском виде это очень полезная и эффективная деталь.

Итоги


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

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

Остается только опробовать Tanzu на тестовом стенде, чтобы реально понять все его плюсы, минусы и нововведения. Как только такая возможность нам представится, мы поделимся с читателями Хабра подробным отчетом о работе с продуктом.
Подробнее..

Перевод Сеть в bitly Linux tc для минимизации издержек и забавы ради

02.06.2021 20:09:34 | Автор: admin

Представьте, что вы, например, bitly то есть очень большой сервис сокращения ссылок. И вот, вы хотите скопировать свои 150 ТБ сжатых данных с одного физического кластера на другой, новый. Чтобы сделать это, вы запускаете distcp из набора инструментов hadoop и рады тому, насколько быстро он работает. Но, несколько позже, вы уже совсем не радуетесь жалобам обычных пользователей веб-сайта и API-клиентов случаются ошибки, задерживаются ответы, а данные их дата-центра только запутывают. К старту курса о DevOps мы перевели материал о том, что делать, если вы, как и bitly, оказались в подобной ситуации.


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

Важной частью инфраструктуры bitly и основным инструментом команды Data Science и рабочей группы обслуживания операций и инфраструктуры (Ops/Infra) в течение довольно долгого времени был физический кластер hadoop набор утилит, библиотек и фреймворк для разработки и выполнения распределённых программ, работающих на кластерах из сотен и тысяч узлов. Мы уже давно вынашивали идею подключения нового кластера, копирования и объединения данных старого кластера с данными нового.

И вот, были созданы ветки, проведена вся подготовительная работа, сгенерированы серверы и запущен новый кластер. Но, прежде чем приступить к изложению истории, приведём некоторые технические детали:

  • bitly работает с огромными объёмами данных: на момент миграции кластер hadoop занимал более 150 ТБ дискового пространства сжатых потоковых данных, то есть данных, полученных в результате работы наших различных приложений. Объёмы таких данных продолжали увеличиваться в результате дополнительной обработки другими приложениями;

  • физически инфраструктура bitly располагается в центре обработки данных нашего партнёра. Она состоит из трёх физических видов шасси (приложения, хранилище и база данных), расположенных в ряд в смежных стойках. На момент написания этой статьи каждое шасси имело три физических гигабитных Ethernet-канала (каждый логически изолирован посредством организации сети VLAN) прямой канал, обратный канал и схему удалённого управления (для внеполосного управления серверными шасси). Каждое соединение после прохождения через ряд патч-панелей и коммутаторов подключается к нашим главным коммутаторам через стеклянное оптоволокно 10 Gb по звездообразной схеме сети;

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

Вернёмся к нашей истории.

Для быстрого копирования данных с одного кластера на другой мы воспользовались инструментом distcp, поставляемом в комплекте с кластером hadoop. Говоря просто, инструмент distcp выдаёт задание программному фреймворку mapreduce (используемому для параллельных вычислений над очень большими наборами данных в компьютерных кластерах) на перемещение данных из одного кластера hdfs в другой при копировании узлов в режиме "многие ко многим". Инструмент distcp сработал быстро, и это нас порадовало.

Но тут сломался сервис bitly, и это не привело в восторг команду Ops/Infra.

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

Теперь нам нужно было решать сразу две противоречивые задачи: с одной стороны, надо было продолжать миграцию hadoop, а с другой устранить неполадки и понять, в чём же кроется наша сетевая проблема.

Мы ограничили количество диспетчеров mapreduce, которые инструмент distcp использовал для копирования данных между кластерами, что позволило искусственно снизить пропускную способность при копировании и кое-как возобновить миграцию. После завершения копирования нам, наконец, удалось установить новый кластер взамен старого.

В новом кластере было больше узлов, значит, по идее, hadoop должен был работать быстрее.

Мы, кажется, осчастливили команду Data Science.

Но, к сожалению, поскольку кластер hadoop стал крупнее и быстрее, во время работы mapreduce на большее количество узлов стало передаваться большее количество данных, и это привело к непредвиденному эффекту:

Сервис bitly опять сломался, на этот раз очень серьёзно. Команда Ops/Infra была от этого не в восторге.

Первым импульсивным действием было вообще отрубить hadoop.

Но такое решение очень не понравилось команде Data Science.

Отключение кластера hadoop самое плохое из возможных решений (по последствиям может сравниться разве что с поломкой bitly), поэтому мы вернули кластер в состояние 1995 года, заставив все сетевые карты перейти на 100 Мбит/с (с 1 Гбит/с) с помощью команды ethtool -s eth1 speed 100 duplex full autoneg on. Теперь можно было спокойно подключить hadoop, но какой же медленной стала его работа!

Команда Data Science по-прежнему не выказывала признаков восторга.

И действительно, работа кластера была настолько "тормозной", что при вводе данных, выполнении запланированных заданий ETL (извлечения, преобразования и загрузки) и выдаче отчётов стали часто возникать сбои, постоянно срабатывали аварийные сигналы, будившие среди ночи членов команды Ops/Infra.

Надо ли говорить, как это не нравилось команде Ops/Infra!

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

Сделаем ещё одно небольшое отступление:

Что нам было доступно в bitly?

  • roles.json : список серверов (app01, app02, userdb01, hadoop01 и т. д.), ролей (userdb, app, web, monitoring, hadoop_node и т.д.), а также сведения об отображении серверов на роли (app01,02 -> app, hadoop01,02 -> hadoop_node и т. д.);

  • $datacenter/jsons/* : каталог, содержащий json-файл для каждого логического сервера с атрибутами, описывающими сервер, IP-адресами, именами, информацией конфигурирования и, что наиболее важно в нашей истории, расположением стоек.;

  • Linux : Linux.

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

Но команда Ops/Infra не проявляла признаков радости.

Её не устраивал синтаксис системы контроля сетевого трафика (Traffic Control, tc) в Linux, не говоря уже о совершенно неудобочитаемой документации. После напряжённого периода работы (с многочисленными проклятиями и разбиванием о стену клавиатур) мы смогли, наконец, создать не вызывающие отторжения работающие сценарии в tc. Были открыты ветви, написаны скрипты, выполнены развёртывания, проведены эталонные тестирования, и в результате было создано несколько тестовых узлов с таким кодом:

$ tc class show dev eth1class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b    cburst 1561bclass htb 1:10 root prio 0 rate 819200Kbit ceil 819200Kbit burst 1433b     cburst 1433bclass htb 1:20 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b     cburst 1561b$ tc filter show dev eth1filter parent 1: protocol ip pref 49128 u32 filter parent 1: protocol ip pref 49128 u32 fh 818: ht divisor 1 filter parent 1: protocol ip pref 49128 u32 fh 818::800 order 2048 key     ht 818 bkt 0 flowid 1:20     match 7f000001/ffffffff at 16filter parent 1: protocol ip pref 49129 u32 filter parent 1: protocol ip pref 49129 u32 fh 817: ht divisor 1 filter parent 1: protocol ip pref 49129 u32 fh 817::800 order 2048 key     ht 817 bkt 0 flowid 1:10     match 7f000002/ffffffff at 16filter parent 1: protocol ip pref 49130 u32 filter parent 1: protocol ip pref 49130 u32 fh 816: ht divisor 1 filter parent 1: protocol ip pref 49130 u32 fh 816::800 order 2048 key     ht 816 bkt 0 flowid 1:20     match 7f000003/ffffffff at 16<snipped>$ tc qdisc showqdisc mq 0: dev eth2 root qdisc mq 0: dev eth0 root qdisc htb 1: dev eth1 root refcnt 9 r2q 10 default 100     direct_packets_stat 24

Говоря простым языком, есть три класса управления траффиком. Каждый класс это логическая группа, на которую может быть подписан фильтр, например:

class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b cburst 1561b

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

Каждый фильтр это конкретное правило для конкретного IP (к сожалению, каждый IP выводится в шестнадцатеричном формате), поэтому фильтр:

filter parent 1: protocol ip pref 49128 u32 filter parent 1: protocol ip pref 49128 u32 fh 818: ht divisor 1 filter parent 1: protocol ip pref 49128 u32 fh 818::800 order 2048 key     ht 818 bkt 0 flowid 1:20     match 7f000001/ffffffff at 16

можно интерпретировать как "subscribe hadoop14 to the class 1:20", где "7f000001" можно интерпретировать как IP для hadoop14, а "flowid 1:20" класс для подписки. Затем запускаем команду qdisc, формирующую более или менее активную очередь для устройства eth1. Данная очередь по умолчанию помещает любой хост, не определённый в фильтре класса, в класс 1:100:

qdisc htb 1: dev eth1 root refcnt 9 r2q 10 default 100 direct_packets_stat 24

В такой конфигурации любой хост (hadoop или другой), находящийся в одной стойке с конфигурируемым хостом, получает фильтр, назначенный классу "1:10", разрешающий скорость передачи до ~800 Мбит/с для класса в целом. Аналогичным образом для предопределённого списка ролей, считающихся "ролями приоритетных узлов", создаётся фильтр по тому же правилу "1:100". Такие узлы выполняют довольно важные задачи, например запускают сервисы hadoop namenode или jobtracker, а также наши узлы мониторинга. Любой другой хост hadoop, не находящийся в той же стойке, подключается к классу "1:20", ограниченному более консервативным классом ~200 Мбит/с.

Как было сказано выше, любой хост, не определённый в фильтре, попадает в класс по умолчанию для eth1 qdisc, то есть в класс "1:100". Как это выглядит на практике? Вот хост, подпадающий под действие правила "1:100":

[root@hadoop27 ~]# iperf -t 30 -c NONHADOOPHOST------------------------------------------------------------Client connecting to NONHADOOPHOST, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 35897 connected with NONHADOOPHOST port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.1 sec   735 MBytes   205 Mbits/sec

Теперь при подключении к другому хосту, расположенному в той же стойке или подпадающему под правило "1:10":

[root@hadoop27 ~]# iperf -t 30 -c CABINETPEER------------------------------------------------------------Client connecting to CABINETPEER, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 39016 connected with CABINETPEER port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.0 sec  2.86 GBytes   820 Mbits/sec

Что произойдёт при подключении к двум серверам, подпадающим под правило "1:10"?

[root@hadoop27 ~]# iperf -t 30 -c CABINETPEER1------------------------------------------------------------Client connecting to CABINETPEER1, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 39648 connected with CABINETPEER1 port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.0 sec  1.47 GBytes   421 Mbits/sec[root@hadoop27 ~]# iperf -t 30 -c CABINETPEER2------------------------------------------------------------Client connecting to 10.241.28.160, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 38218 connected with CABINETPEER2 port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.0 sec  1.43 GBytes   408 Mbits/sec

Трафик уменьшится вдвое? Похоже на правду. Даже лучше стало относительно проще отслеживать тренды данных, анализируя статистические данные, выводимые на наши сервисы трендов:

$ /sbin/tc -s class show dev eth1 classid 1:100class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit     burst 1561b cburst 1561b Sent 5876292240 bytes 41184081 pkt (dropped 0, overlimits 0 requeues 0) rate 3456bit 2pps backlog 0b 0p requeues 0 lended: 40130273 borrowed: 0 giants: 0tokens: 906 ctokens: 906

После тестирования мы проверили хосты hadoop, подняв их скорости до первоначальных 1Gb после применения ролей traffic control. После всех описанных действий кластер hadoop вновь обрёл достаточно высокую производительность.

Мы осчастливили команду Data Science.

Команда Ops/Infra смогла приступить к устранению неполадок и поиску решений, при этом спокойно спать по ночам, зная, что сервис bitly будет вести себя нормально.

Мы осчастливили и команду Ops/Infra.

Выводы:

  • Попав в трудное положение, помните: ваш набор инструментов для управления средой так же важен, как и сама среда. Поскольку у нас уже имелся набор инструментов для комплексного контроля среды, мы сумели выбраться из ямы почти так же быстро, как попали в неё.

  • Не загоняйте себя в трудные ситуации: изучите все нюансы среды, в которой будете работать. В данном случае нам следовало лучше понять и оценить масштабы миграции hadoop и её возможные последствия.

  • Linux TC это дорогой инструмент, но и отдача от него очень большая. Этот инструмент почти наверняка создавали бородатые люди с самыми мохнатыми свитерами на свете, и для его применения требуются время и терпение. В любом случае это невероятно мощный инструмент он помог нам исправить наши собственные ошибки.

  • Linux: Linux

И последнее

Эта история хорошая иллюстрация "закона Мерфи для девопсов":

Закон Мёрфи для девопсов: "Если что-то может пойти не так, значит, что-то уже идёт не так, просто Nagios ещё не предупредил".

Временные решения, подобные тем, о которых идёт речь в этой статье, позволили нам выиграть время для поиска и устранения неисправностей в сети. Мы разогнали кластер hadoop, перенесли его в собственную выделенную сеть, обошли проблему некачественного сетевого оборудования, укрепив тем самым основную сеть, и сделали много чего ещё. Оставайтесь с нами.

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru