По поводу аварии в Яндекс.Облако.

Амазон терял данные пользователей на EBS в 2011 году.
Сервис S3 лежал несколько часов в одном из регионов. Из-за этого у конечных пользователей были проблемы различного масштаба, от сломавшихся холодильников до неработающих пультов от телевизора.

GitLab убил production базу. Во время восстановления выяснилось, что бекапы работали некорректно, и восстановили в итоге из снимка ФС по чистому везению.

ЦОД GCP ушел в отказ, когда в него ударила молния два раза подряд. Два. Раза. Подряд.

Github в результате цепочки отказов работал в деградированном режиме 24 часа и 11 минут.

Про отказы Facebook, Instagram и ВК я вообще молчу.

У меня нет инсайдов о том, что именно произошло в Я.О, но по тем крупицам информации, что я нашел - это не самое страшное, что могло случиться, и масштаб трагедии гораздо меньше, чем пишут на Pikabu и Хабре.

На DevOps Forum Moscow я сказал, что будущее ИТ за развитием публичных и гибридных облаков, и Яндекс делает титаническую работу.

Я желаю команде Яндекс.Облако удачи в решении инцидента, и пусть это будет их последняя крупная авария.

Прекращайте спекуляции и own your reliability (c)

Оказывается, есть упрощённая версия Grafana для терминала. Удобно, информативно, визуально приятно:

https://github.com/slok/grafterm

#фидбечат #monitoring #grafana

Другой подход к быстрому управлению трафиком это BPF (eBPF), XDP (Express Data Path). Обзор того как это устроено в Cloudflare, где на каждом этапе прохождения трафика он используется.

Если пользуетесь OpenVPN, то для того чтобы совместить его HTTPS на однном сокете не надо ничего придумывать, достаточно опции port-share:

port 443
port-share 127.0.0.1 4443

Конечно, сам веб сервер придётся унести на другой порт. Поможет во многих случаях когда открыт только 443, для публичного Wi-Fi такое часто бывает, собственно поэтому и полез настраивать. В современных реалиях не проблема держать только сервер для VPN на любых портах, так что это ограничение так себе. Работает только с TCP, рассчитано конечно на веб, но теоретически можно и с SSH совместить.

Битва за IPv4. Возможно, в ближайшем времени мы увидим куда масштабнее события, а может и не увидим.
Худо бедно, но адреса всё ещё есть. Этот лишний миллион не сделает погоды, это просто показатель дефицита и ценности ограниченного ресурса. Который "внезапно" таким стал. Даже не сам факт возвращения, а новость об этом факте.
В зоне RIPE NCC всё относительно просто - платишь членские взносы, получаешь адреса. Одна юридическая организация может стать LIR и получить /22 в руки (пока) много раз. Если проблема решается деньгами - это не проблема, что показывает что адреса ещё есть.

О! MSK-IX включила фильтрацию по RPKI. Так-то учитывали они это давно, специальное комьюнити есть по результатам проверки - 8631:65510 если подписан и валиден, а теперь вот ещё и фильтруют.
Правда проникновение RPKI всё равно оставляет желать лучшего, но даже небольшие шаги это шаги.

в дополнение @LookinGlassBot

whois-бот

@WhoisDomBot - поиск информации о доменах и IP-адресах.

Есть ли жизнь с мультикаст трафиком в Wi-Fi? Статья про основные проблемы таких решений и как сделать жизнь чуть лучше. Ищите точки и производителей которые имеют опцию Multicast-to-Unicast, могут преобразовывать один мультикаст поток во много уникастовых. Тогда и снупинг начинает работать и жить становится веселее, хотя надо учитывать нюансы.

Uber хвалит QUIC: большая статья про проблемы TCP в разрезе Uber специфики и как они решились с QUIC. Тесты проводились в Дели, как самом плохом в плане задержек регионе и показали значительное улучшение показателей. А то что всё работает в пространстве пользователя, для Uber это плюс.

Экскурсия по лаборатории Ericsson в Москве (часть 2 и часть 3) от @abloud62. Много фоточек крупным планом, в основном радио железок, но есть и другие.

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

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

Урок простой - никогда не экономьте доступный и условно бесконечный ресурс, будь то оптические кабели или IP адреса (тем более серые). Если есть возможность запланировать больше - запланируйте больше. В нашем случае проблема решается просто добавлением параллельной магистрали, благо всё в рамках одного помещения. А вот в случае с IP новый блок получится, как правило, уже в другой подсети и будет не очень красиво, что, скорее всего, потащит за собой дополнительные строчки в конфиге и ресурсы маршрутизатора.

Серия статей про Cumulus Linux на theasciiconstruct.com, от базовой настройки интерфейсов до BGP, EVPN, VXLAN и это ещё не конец. Предполагается что используемые технологии и протоколы уже знакомы как и знаком Linux, вся суть именно в том как это на Cumulus. Используется единая топология, в каждой статье к сети добавляется новый функционал и выполняется его настройка. Быстрый обзор для желающих оценить: "А как оно там?"

Менеджер конфигураций CDIST для серверов. Шаблон конфигурации формируется на Shell. Говорят так лучше, не надо учить никаких YAML, а Shell и так все знают. Это подаётся как преимущество. Кроме того это полноценный язык с циклами и условиями и вызовом любых внешних модулей. Для управления серверами, опять же, нужен только Shell и доступ через SSH.

Сами шаблоны (манифесты) помимо Shell формируются из типов (действий). Фактически, это те же скрипты, соответственно можно создавать свои, но многие стандартные действия определены. Вот такая строчка в манифесте __file /etc/cdist-configured может создать файл cdist-configured на всех обслуживаемых хостах.

На первый взгляд выглядит просто, может даже очень просто - как внутренний проект который писали-писали, он разросся, а потом пришёл Ansible и надо было что-то решать. Но по факту требований действительно мало, кроме того что надо и правда хорошо разбираться и любить именно Shell. Разработчики его точно знают, это хорошо видно в приводимых примерах. Будет ли он удобным? Кому-то точно будет.

tcpcrypt добрался до RFC8548. У нас есть IPSec для L3, есть TLS для L7. Теперь есть tcpcrypt для L4.
Отличие - всё должно работать из коробки сетевого стека, L4 уровень делает его прозрачным и для NAT. Аутентификация не встроена (только шифрование), поэтому её придётся делать отдельно. Если узлы не договариваются о шифровании, используется обычный TCP. Простым языком что это за зверь можно читать здесь. Есть ещё сайт tcpcrypt.org, но там что-то с DNS не так и сейчас не работает :(

​Во время грозы все боятся молний, что обосновано. У нас не так часто такие аварии, но как правило они масштабны. Последний раз потеряли узел который делили со своими партнёрами, оборудование которых получило удар, а мы в довесок по медному патчу.

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

История о том как устроить себе DNS amplification attack и решить проблему честно "обманув" Unbound.

Дано, периодические задачи Hadoop в облачной среде и всплески PTR запросов. Всё это начинает упираться в лимиты AWS, что приводит к повторной попытке запроса и усиливает эффект. Так как система многоуровневая, то и второй уровень DNS пытается повторить запрос из-за таймаута, что даёт в итоге 7 кратное усиление количества запросов к серверам. А всё это вместе выливается в SERVFAIL.

Инженеры это аккуратно посчитали и пришли к выводу что лучше разделить логически обработку PTR запросов для серой сети и публичной и убрать один уровень.Так как Unbound считает время для каждого правила отдельно, а для PTR серой сети ответ приходит быстрее, это не вызывает роста повторных попыток запросов, как было раньше с общим счётчиком retry timeout на все запросы. Результат - полностью устранённое усиление из-за повторных запросов.

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

DNS один из тех протоколов который впитывает в себя всё новые и новые функции и является скрытым под капотом очень многих современных решений. Актуальнейшая задача поиска и публикации сервисов решается во многих случаях через DNS, хотя и имеет свой API скрывающий суть вещей. Так что расслабляться не стоит, старая гвардия будет долго в строю, пусть и в новой обёртке.

Мы тоже живём на Unbound в качестве кеширующего сервера. У нас около 3000 запросов в секунду и 95% попадание в кеш. Это, к слову, о порядке величин для сравнения с графиками из статьи.

P.S. Иногда я пропускаю интересные сообщения даже в тех каналах которые читаю. Спасибо огромное всем читателям кто делится со мной ссылками, мне всегда интересно. И многим кто потом читает посты в этом канале, я думаю, тоже. Без вас никак.

В уже очень далёком 1999 я купил компакт диск с названием на обложке "Техническая документация" (сейчас вместе со мной всплакнут мои однокурсники). Это была сборная солянка из дампов сайтов, например OpenNET каких-то учебников, How-To, утилиты... Не было никакой оболочки, всё было отсортировано по каталогам в которых надо было ещё разобраться.

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

Russ White про BGP Monitoring Protocol, который уже хочется начать использовать. Потому что некоторые вещи, из того что там есть, добываются очень большим трудом и всё равно не получается в полном объёме. А видеть что происходит с BGP в большом разрешении очень полезно. Это стандарт с 2016 года, в софтовых роутерах уже есть реализации (как минимум базовые) или они на подходе.

RIPE NCC проводит опрос о своей работе и пожеланиях, для всех кто работает с ними и их сервисами.

Ах, да. Есть возможность выиграть iPad.