Представьте, что вы, например, bitly — то есть очень большой сервис сокращения ссылок. И вот, вы хотите скопировать свои 150 ТБ сжатых данных с одного физического кластера на другой, новый. Чтобы сделать это, вы запускаете distcp из набора инструментов hadoop — и рады тому, насколько быстро он работает. Но, несколько позже, вы уже совсем не радуетесь жалобам обычных пользователей веб-сайта и API-клиентов — случаются ошибки, задерживаются ответы, а данные их дата-центра только запутывают. К старту курса о DevOps мы перевели материал о том, что делать, если вы, как и bitly, оказались в подобной ситуации.
Мы в bitly очень любим работать с данными и устройствами, а если говорить точнее, то с устройствами для передачи данных. Сегодня расскажем историю о том, как мы пытались перекачать через устройства очень и очень много данных.
Важной частью инфраструктуры bitly и основным инструментом команды Data Science и рабочей группы обслуживания операций и инфраструктуры (Ops/Infra) в течение довольно долгого времени был физический кластер hadoop — набор утилит, библиотек и фреймворк для разработки и выполнения распределённых программ, работающих на кластерах из сотен и тысяч узлов. Мы уже давно вынашивали идею подключения нового кластера, копирования и объединения данных старого кластера с данными нового.
И вот, были созданы ветки, проведена вся подготовительная работа, сгенерированы серверы и запущен новый кластер. Но, прежде чем приступить к изложению истории, приведём некоторые технические детали:
Для быстрого копирования данных с одного кластера на другой мы воспользовались инструментом 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?
Но команда Ops/Infra не проявляла признаков радости.
Её не устраивал синтаксис системы контроля сетевого трафика (Traffic Control, tc) в Linux, не говоря уже о совершенно неудобочитаемой документации. После напряжённого периода работы (с многочисленными проклятиями и разбиванием о стену клавиатур) мы смогли, наконец, создать не вызывающие отторжения работающие сценарии в tc. Были открыты ветви, написаны скрипты, выполнены развёртывания, проведены эталонные тестирования, и в результате было создано несколько тестовых узлов с таким кодом:
$ tc class show dev eth1
class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b
cburst 1561b
class htb 1:10 root prio 0 rate 819200Kbit ceil 819200Kbit burst 1433b
cburst 1433b
class htb 1:20 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b
cburst 1561b
$ tc filter show dev eth1
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
filter 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 16
filter 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 show
qdisc 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 5001
TCP 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 5001
TCP 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 5001
TCP 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 5001
TCP 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:100
class 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: 0
tokens: 906 ctokens: 906
После тестирования мы проверили хосты hadoop, подняв их скорости до первоначальных 1Gb после применения ролей traffic control. После всех описанных действий кластер hadoop вновь обрёл достаточно высокую производительность.
Мы осчастливили команду Data Science.
Команда Ops/Infra смогла приступить к устранению неполадок и поиску решений, при этом спокойно спать по ночам, зная, что сервис bitly будет вести себя нормально.
Мы осчастливили и команду Ops/Infra.
Эта статья подчёркивает, что правильная, эффективная организация инфраструктуры не менее важна, чем данные и программное обеспечение. По мере развития информационных технологий, увеличения нагрузок, специалисты DevOps, возможно, станут называться иначе, а область станет ещё более самостоятельной.
Источник статьи: https://habr.com/ru/company/skillfactory/blog/560148/
Мы в 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.
Но команда Ops/Infra не проявляла признаков радости.
Её не устраивал синтаксис системы контроля сетевого трафика (Traffic Control, tc) в Linux, не говоря уже о совершенно неудобочитаемой документации. После напряжённого периода работы (с многочисленными проклятиями и разбиванием о стену клавиатур) мы смогли, наконец, создать не вызывающие отторжения работающие сценарии в tc. Были открыты ветви, написаны скрипты, выполнены развёртывания, проведены эталонные тестирования, и в результате было создано несколько тестовых узлов с таким кодом:
$ tc class show dev eth1
class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b
cburst 1561b
class htb 1:10 root prio 0 rate 819200Kbit ceil 819200Kbit burst 1433b
cburst 1433b
class htb 1:20 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b
cburst 1561b
$ tc filter show dev eth1
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
filter 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 16
filter 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 show
qdisc 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 5001
TCP 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 5001
TCP 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 5001
TCP 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 5001
TCP 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:100
class 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: 0
tokens: 906 ctokens: 906
После тестирования мы проверили хосты hadoop, подняв их скорости до первоначальных 1Gb после применения ролей traffic control. После всех описанных действий кластер hadoop вновь обрёл достаточно высокую производительность.
Мы осчастливили команду Data Science.
Команда Ops/Infra смогла приступить к устранению неполадок и поиску решений, при этом спокойно спать по ночам, зная, что сервис bitly будет вести себя нормально.
Мы осчастливили и команду Ops/Infra.
Выводы:
- Попав в трудное положение, помните: ваш набор инструментов для управления средой так же важен, как и сама среда. Поскольку у нас уже имелся набор инструментов для комплексного контроля среды, мы сумели выбраться из ямы почти так же быстро, как попали в неё.
- Не загоняйте себя в трудные ситуации: изучите все нюансы среды, в которой будете работать. В данном случае нам следовало лучше понять и оценить масштабы миграции hadoop и её возможные последствия.
- Linux TC — это дорогой инструмент, но и отдача от него очень большая. Этот инструмент почти наверняка создавали бородатые люди с самыми мохнатыми свитерами на свете, и для его применения требуются время и терпение. В любом случае это невероятно мощный инструмент — он помог нам исправить наши собственные ошибки.
- Linux: Linux
И последнее
Эта история — хорошая иллюстрация "закона Мерфи для девопсов":Временные решения, подобные тем, о которых идёт речь в этой статье, позволили нам выиграть время для поиска и устранения неисправностей в сети. Мы разогнали кластер hadoop, перенесли его в собственную выделенную сеть, обошли проблему некачественного сетевого оборудования, укрепив тем самым основную сеть, и сделали много чего ещё. Оставайтесь с нами.
Эта статья подчёркивает, что правильная, эффективная организация инфраструктуры не менее важна, чем данные и программное обеспечение. По мере развития информационных технологий, увеличения нагрузок, специалисты DevOps, возможно, станут называться иначе, а область станет ещё более самостоятельной.
Источник статьи: https://habr.com/ru/company/skillfactory/blog/560148/