В прошлой статье мы рассмотрели кластеризацию RabbitMQ для обеспечения отказоустойчивости и высокой доступности. Теперь глубоко покопаемся в Apache Kafka.

Здесь единицей репликации является раздел (partition). У каждого топика один или несколько разделов. В каждом разделе есть лидер с фолловерами или без них. При создании топика указывается количество разделов и коэффициент репликации. Обычное значение 3, это означает три реплики: один лидер и два фолловера.

Привет, Хабр! Я Артем Карамышев, руководитель команды системного администрирования Mail.Ru Cloud Solutions (MCS). За последний год у нас было много запусков новых продуктов. Мы хотели добиться, чтобы API-сервисы легко масштабировались, были отказоустойчивыми и готовыми к быстрому росту пользовательской нагрузки. Наша платформа реализована на OpenStack, и я хочу рассказать, какие проблемы отказоустойчивости компонентов нам пришлось закрыть, чтобы получить отказоустойчивую систему. Я думаю, это будет любопытно тем, кто тоже развивает продукты на OpenStack.

Общая отказоустойчивость платформы складывается из устойчивости её компонентов. Так что мы постепенно пройдём через все уровни, на которых мы обнаружили риски и закрыли их.

Видеоверсию этой истории, первоисточником которой стал доклад на конференции Uptime day 4, организованной ITSumma, можно посмотреть на YouTube-канале Uptime Community.

Всем привет! Несколько месяцев назад мы запустили в продакшн наш новый open-source проект — Grafana-плагин для мониторинга kubernetes, который назвали DevOpsProdigy KubeGraf. Исходный код плагина доступен в публичном репозитории на GitHub. А в этой статье мы хотим поделиться с вами историей о том, как мы создавали плагин, какие инструменты использовали и с какими подводными камнями столкнулись в процессе разработки. Погнали!

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

Кто везде — тот нигде. Кто проводит жизнь в странствиях, у тех в итоге гостеприимцев множество, а друзей нет.

Сенека.

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

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

Отказоустойчивость и высокая доступность — большие темы, так что посвятим RabbitMQ и Kafka отдельные статьи. Данная статья о RabbitMQ, а следующая — о Kafka, в сравнении с RabbitMQ. Статья длинная, так что устраивайтесь поудобнее.

Рассмотрим стратегии отказоустойчивости, согласованности и высокой доступности (HA), а также компромиссы, на которые приходится идти в каждой стратегии. RabbitMQ может работать на кластере узлов — и тогда классифицируется как распределенная система. Когда речь заходит о распределенных системах, мы часто говорим о согласованности и доступности.

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

TL;DR. Некоторые люди смотрят на мир иначе. Софтверная компания из Нью-Йорка решила использовать это как конкурентное преимущество. Её штат на 75% состоит из тестировщиков с расстройствами аутистического спектра. Удивительно, но необходимые аутистам вещи оказались полезными для всех: гибкий график, удалённая работа, общение в Slack (вместо личных встреч), чёткая повестка каждого совещания, отказ от открытых офисов, отмена собеседований, карьерная альтернатива повышению до менеджера и т. д.

Раджеш Анандан основал компанию Ultranauts (бывшая Ultra Testing) с соседом по комнате общежития в Массачусетском технологическом институте Артом Шектманом с одной целью: доказать, что нейрологическое разнообразие (neurodiversity) и аутизм сотрудников — это конкурентное преимущество в бизнесе.

«В аутистическом спектре невероятное количество людей, чьи таланты игнорируют по самым разным причинам,  — говорит Анандан.  — Им не дают честного шанса добиться успеха на работе из-за атмосферы, рабочего процесса и ”привычных” деловых практик, которые не слишком эффективны в принципе, а для людей с таким мышлением особенно вредны».

В конце августа Imperva оповестила клиентов сервиса Cloud WAF (бывш. Incapsula) об утечке конфиденциальной информации и инициировала сброс паролей учетных записей. Оказалось, что посторонние получили доступ к хешам паролей, ключам API и SSL-сертификатам.

10 октября исполнительный директор компании Крис Хайлен (Chris Hylen) и технический директор Кунаи Ананд (Kunal Anand) изложили post mortem с деталями инцидента. Как такое могло произойти у компании, которая специализируется на защите данных и приложений?

Если резюмировать, проблема возникла из-за некорректной миграции БД с собственного хостинга на Amazon Web Services.

В своем сообщении Крис Хайлен перечисляет ряд ошибок, сделанных во время миграции. Все вместе, они позволили неизвестным украсть админский ключ API к одному из аккаунтов в продакшне на Amazon Web Services. Расследование показало, что неавторизованный доступ произошёл ещё в октябре 2018 года.

Админский ключ дал злоумышленнику доступ к снимку БД с различными сведениями о клиентах, которые зарегистрировались до 15 сентября 2017 года. Информация включала адреса электронной почты, хэшированные и солёные пароли, а для некоторого количества клиентов — ключи API и предоставленные клиентами SSL-сертификаты.

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

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

В этом посте концепция распределенной трассировки будет рассмотрена через призму микросервисной архитектуры: как это все интегрируется и автоматизируется через Istio, а затем весь процесс упрощается и обрабатывается через Backyards — наш сервисный продукт для Istio.

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

---

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

Но даже это не помогло: я получил все ту же ошибку.

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

Недавно мне посчастливилось взять интервью у веб-разработчика крупнейшего в мире сайта для взрослых — Pornhub.

Цель: узнать о технологиях и новинках в области работы с веб-API и, конечно же, как все это реализовано в рамках Pornhub. Наслаждайтесь!

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

Сегодня мы зарелизили новую версию нашего плагина для мониторинга k8s — grafana.com/grafana/plugins/devopsprodigy-kubegraf-app — о котором писали ранее.

Ключевая фича новой версии — возможность аутентификации с помощью bearer-токена. Теперь посредством манифестов (которые можно найти тут) вы можете создать пользователя с readonly-доступами, получить токен (в ридми описан весь процесс) и использовать его в окне конфигурации вашего кластера.

Канареечный деплой — это очень эффективный способ тестирования нового кода на каком-то подмножестве пользователей. Он значительно снижает трафик-нагрузку, с которой могут возникнуть проблемы в процессе развертывания, так как происходит только в пределах определенной подгруппы. Эта заметка посвящена тому, как организовать подобный деплой средствами Kubernetes и автоматизации деплоя. Предполагается, что вы кое-что знаете о Helm и ресурсах Kubernetes.

Сегодня свершился релиз нового и очень полезного опенсорсного проекта, созданного дирекцией разработки ITSumma — плагина в Grafana для мониторинга Kubernetes. Он включён в официальный графана-стор — grafana.com/grafana/plugins/devopsprodigy-kubegraf-app

На минувшей неделе в городе И случился книжный фестиваль. Случился уже в третий раз. С одной стороны, это иркутский фестиваль, с другой — международный: приехали Эрленд Лу, Линор Горалик, Мариам Петросян и ещё с десяток авторов солидной известности. Мы пока в книжной области такой известности не достигли, но тем не менее представили на фестивале своё издательство ITSumma Press и нашу первую книгу. И самый частый вопрос, который нам задавали, — «зачем айти-компании издательство?»

Мы уже писали о том, как готовились к изданию первой книги и с какими интересностями столкнулись на этом пути («а ну-ка покажи мне свой ISBN»). Но на этот вопрос ответ тогда толком не сформулировался. А сейчас он есть.

За годы существования Pinterest 300 миллионов пользователей сервиса создали более 200 миллиардов пинов на более чем 4 миллиардов досок. Чтобы обслуживать эту армию пользователей и обширную контент-базу, портал разработал тысячи сервисов, начиная от микросервисов, с которыми может справиться несколько CPU, и заканчивая гигантскими монолитами, которые крутятся на целом парке виртуальных машин. И вот наступил момент, когда взгляд компании упал на k8s. Чем же «кубик» глянулся «Пинтересту»? Об этом вы узнаете из нашего перевода свежей статьи из блога Pinterest engeneering.



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

В ходе поддержки этого зоопарка инструментов команда разработки сталкивается с рядом проблем:

Современный веб практически немыслим без медиаконтента: смартфоны есть практически у каждой нашей бабушки, все сидят в соцсетях, и простои в обслуживании дорого обходятся компаниям. Вашему вниманию расшифровка рассказа компании Badoo о том, как она организовала отдачу фотографий с помощью аппаратного решения, с какими проблемами производительности столкнулась в процессе, чем они были вызваны, ну и как эти проблемы были решены с помощью софтового решения на основе Nginx, обеспечив при этом отказоустойчивость на всех уровнях (видео). Благодарим авторов рассказа Олега Sannis Ефимова и Александра Дымова, которые поделились своим опытом на конференции Uptime day 4.

— Начнем с небольшого введения о том, как мы храним и кэшируем фотографии. У нас есть слой, на котором мы их храним, и слой, где мы фотографии кэшируем. При этом, если мы хотим добиваться большого хитрейта и снижать нагрузку на стораджи, нам важно, чтобы каждая фотография отдельного пользователя лежала на одном кэширующем сервере. Иначе нам пришлось бы ставить во столько раз больше дисков, во сколько у нас больше серверов. Хитрейт у нас в районе 99%, то есть мы в 100 раз снижаем нагрузку на наши storage, и для того, чтобы это сделать, еще 10 лет назад, когда все это строилось, у нас было 50 серверов. Соответственно, для того, чтобы эти фотографии отдавать, нам нужно было по сути 50 внешних доменов, которые эти серверы обслуживают.

Естественно, сразу встал вопрос: а если у нас один сервер упадет, будет недоступен, какую часть трафика мы теряем? Мы посмотрели, что есть на рынке, и решили купить железку, чтобы она решила все наши проблемы. Выбор пал на решение компании F5-network (которая, кстати, не так давно купила NGINX, Inc): BIG-IP Local Traffic Manager.

Пара слов от нашего translate-бюро: обычно все стремятся переводить самые свежие материалы и публикации, и мы не исключение. Но терминалы — это не то, что обновляется раз в неделю. Поэтому мы перевели для вас статью Антуана Бопре, опубликованную весной 2018 года: несмотря на солидный по современным меркам «возраст», на наш взгляд, материал совершенно не потерял актуальности. Кроме того, в оригинале это серия из двух статей, но мы приняли решение объединить их в один большой пост.



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

Что нужно для успеха IT-компании в 2019 году? Лекторы на конфах и митапах говорят много громких и не всегда понятных нормальным людям слов. Борьба за время деплоя, микросервисы, отказ от монолита, DevOps-трансформация и много-много чего ещё. Если отбросить словесную красоту и говорить прямо и по-русски, то всё сводится к простому тезису: делайте качественный продукт, причем делайте его с комфортом для команды.

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

Вся эта история от «по модулю» прекрасна, но… Так получилось, что часть админов резко окрестили в DevOps, а от самих DevOps-инженеров стали требовать, как минимум, навыков телепатии и ясновидения.

За последние несколько лет базы данных временных рядов (Time-series databases) превратились из диковинной штуки (узкоспециализированно применяющейся либо в открытых системах мониторинга (и привязанной к конкретным решениям), либо в Big Data проектах) в «товар народного потребления». На территории РФ отдельное спасибо за это надо сказать Яндексу и ClickHouse’у. До этого момента, если вам было необходимо сохранить большое количество time-series данных, приходилось либо смириться с необходимостью поднять монструозный Hadoop-стэк и сопровождать его, либо общаться с протоколами, индивидуальными для каждый системы.

Может показаться, что в 2019-м году статья про то, какую TSDB стоит использовать, будет состоять лишь из одного предложения: «просто используйте ClickHouse». Но… есть нюансы.

Действительно, ClickHouse активно развивается, пользовательская база растет, а поддержка ведется очень активно, но не стали ли мы заложниками публичной успешности ClickHouse'а, которая затмила другие, возможно, более эффективные/надежные решения?

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

Летом традиционно снижается и покупательская активность, и интенсивность изменения инфраструктуры веб-проектов, говорит нам Капитан Очевидность. Просто потому что даже айтишники, случается, ходят в отпуск. И CТО тоже. Тем тяжелее тем, кто остаётся на посту, но сейчас не об этом: возможно, именно поэтому лето — лучший период для того, чтобы не торопясь обдумать существующую схему резервирования и составить план по её улучшению. И в этом вам будет полезен опыт Егора Андреева из AdminDivision, о котором он рассказал на конференции Uptime day.

При строительстве резервных площадок, при резервировании есть несколько ловушек, в которые можно попасть. А попадаться в них совершенно нельзя. И губит нас во всем этом, как и во многом другом, перфекционизм и… лень. Мы пытаемся сделать всё-всё-всё идеально, а идеально делать не нужно! Нужно делать только определённые вещи, но сделать их правильно, довести до конца, чтоб они нормально работали.

Failover — это не какая-то такая весёлая фановая штука «чтоб было»; это вещь, которая должна сделать ровно одно — уменьшить время простоя, чтобы сервис, компания, теряла меньше денег. И во всех методах резервирования я предлагаю думать в следующем контексте: где деньги?