== небольшой плейлист по Network
https://youtube.com/playlist?list=PLprvDkBQwz6bOaO1N0vDaHX-jqlvlKIhp
- Routing VS Nat
- Построение отказоустойчивой сети (Bonding, LAG, LACP)
- Построение отказоустойчивой сети VPC
- Обеспечение бесперебойного интернета (VRRP)
- настройка DNS балансировки и failover
- Тесты на боевой системе

NAT - это медленно
Ip Tables - Это медленно
при NAT нагрузка на ЦПУ выше
при использовании Kubernates/swarm и пр сеть нельзя обьединить с физическим интерфейсом хоста (а при использовании ВМ это сделать МОЖНО)

== DNS Best Practices, Network Protections, and Attack Identification

https://tools.cisco.com/security/center/resources/dns_best_practices

шикарное чтиво если сложно заснуть

== Представление о структуре отказоустойчивого кластера
https://youtu.be/hBrc-jJFbAw

CEPH как кластерная система хранения файлов . ВАРИАНТОВ НЕТ

каждый сервак должен иметь МИНИМУМ две раздельнче сетевые карты с оптикой. настроен бондинг

два физических роутера

два узла nginx

== Установка кластера кафки на 3 ноды.
https://youtu.be/OTxnQ289pvg
проперти, кластер, настройка
- кафка
- зукипер

== Понимание принципов работы kafka на практике
https://youtu.be/Ep9ZQjrn1Rs
- продюссер всегда пишет в лидера. остальные партиции на одной ноде только для чтения

все время хотелось понять как оно работает. шикаааарная статья. лайк

== Знакомство с хранилищем Ceph в картинках
https://habr.com/ru/post/313644/

Алгоритм CRUSH (Controlled Replicated Under Scalable Hashing)
- позволяет однозначно определить местоположение объекта на основе хеша имени объекта и определенной карты, которая формируется исходя из физической и логической структур кластера (датацентры, залы, ряды, стойки, узлы, диски)

== Как мы отказоустойчивый кластер запускали
https://habr.com/ru/company/first/blog/314106/

== толковый плейлист по кластеру Postgres & Patroni
https://youtube.com/playlist?list=PLprvDkBQwz6YQLJQ_qlm3-gkk-BXYuuR0

== Что такое кластер Postgres, как он работает и для чего нужен Patroni
https://youtu.be/GtHtRyPcmIM

кластер постгреса работает из коробки

split-brain = разделение двух мастеров

постгрес не поддерживает мастер-мастер !

демон патрони занимается синхронизацием знанием о том кто мастер а кто реплика.

база etcd используется как транспорт и состояние для patroni

haproxy просто разруливает трафик на запись и на чтение. его мутирует patroni напрямую

НО хапрокси это единственная точка отказа

pgbouncer множественный коннект к постгресу . АБСОЛЮТНО БЕСПОЛЕЗЕН ЕСЛИ ИСПОЛЬЗУЮТСЯ ПЕРСИСТЕНТНЫЕ КОННЕКШНЫ
нужен только что бы использовать много частых коннекшнов, не создавая их часто физически

НИКОГДА НЕ ПОДНИМАЙТЕСЬ ПО СЕТЕВОМУ УРОВНЮ ЕСЛИ В ЭТОМ НЕТ НЕОБХОДИМОСТИ

📝 Docker, Kubernetes, OCI, CRI-O, containerd & runc: How do they work together?

Взял вот в этой статье - An attempt to understand container runtime.

#containers #runc #containerd

Это точно сохраню тут

Оглавление книги:

Введение
Часть I. Изоляция и многоверсионность
Изоляция
Страницы и версии строк
Снимки данных
Внутристраничная очистка и hot-обновления
Очистка и автоочистка
Заморозка
Перестроение таблиц и индексов
Часть II. Буферный кеш и журнал
Буферный кеш
Журнал предзаписи
Режимы журнала
Часть III. Блокировки
Блокировки отношений
Блокировки строк
Блокировки разных объектов
Блокировки в памяти
Часть IV. Выполнение запросов
Этапы выполнения запросов
Статистика
Табличные методы доступа
Индексные методы доступа
Индексное сканирование
Вложенный цикл
Хеширование
Сортировка и слияние
Часть V. Типы индексов
Хеш-индекс
B-дерево
Индекс GiST
Индекс SP-GiST
Индекс GIN
Индекс BRIN

== 3 Things You Might Not Know About Numbers in Python
https://davidamos.dev/three-things-you-might-not-know-about-numbers-in-python/

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

впрочем неплохой канал. просмотров у него неслабо для математического контента.

плейлист по производным https://youtube.com/playlist?list=PLGtfmJuN1mTA_vI3eLT8jMTEeJ0YDIh-z

== Задачи, приводящие к понятию производной
https://youtu.be/CQpX5f7iIvM

== Определение производной. Геометрический и физический смысл производной.
https://youtu.be/kJE2lqMJe5Q

== Геометрический смысл производной. Уравнение касательной и нормали.
https://youtu.be/KLzq2TTZN34

== Вычисление производных примеры. Самое начало.
https://youtu.be/gIk3EkrYkTg

== Производная сложной функции пример
https://youtu.be/muwAE0Fjlec

== Производная неявной функции примеры
https://youtu.be/7YpyHLHBCw4

== Почему сообщество разработчиков ядра заменяет iptables на BPF?
https://habr.com/ru/company/otus/blog/646335/

Скорость, вот почему

== Scale Kubernetes to support 50000 services
https://www.slideshare.net/LCChina/scale-kubernetes-to-support-50000-services

Where is the latency generated (IPTables)?
- not incremental
- copy all rules
- make changes
- save all rules back
- IPTables locked during rule update

Time spent to add once rule when there are 5k services (40k rules) = 11min

20k services (160k rules) = 5 hours

== FFmpeg
https://youtu.be/pqrKhA_femQ
эх. вспоминается хакатон =)

​[Перевод] Embedded Linux. Отладка ядра

Придя в embedded linux из мира микроконтроллеров, такого привычного инструмента отладки кода, как пошаговая отладка кода на целевой железке с помощью аппаратного программатора, - очень не хватало. В предыдущих статьях описано, как мы учились дебажить загрузчик u-boot: 1, 2. С ядром все оказалось сложнее. Например, выяснилось, что ядро Linux в принципе невозможно скомпилировать с отключенной оптимизацией (-O0). В статье описывается как нам все таки удалось запустить ядро на микропроцессоре ARM в режиме пошаговой отладки.

#linux #guide

кто бы мог подумать что матан мне станет настолько интересным как сейчас

На Хабре появилась очередная статья о том, как php пытаются натянуть на хайлоад, используя для этого костыли swoole.

Статья потрясающая, ведь в ней перечислены все минусы этого подхода по сравнению с Go, Node и т.д., а выводы сделаны противоположные здравому смыслу.

В статье api, которое пишет в базу, нагрузка всего 300rps.

1) Приложение жрет 2 гига памяти и 8 ядер cpu. Ну хз, Go сожрало бы в несколько раз меньше. У меня микросервисы обычно потребляют в разы меньше при гораздо большей нагрузке. Хотя, конечно, зависит от конкретики приложения.

2) раздел "простота инфраструктуры", цитирую:

"...внутри контейнера будет всего 11 процессов: 1 tini (supervisor)+entrypoint, 1 master процесс, 1 manager процесс и 8 worker процессов."

Вы чо, ребят? Какая тут простота? Особенно учитывая, что они зачем-то перезапускают процессы воркеров раз в час.

Image весит всего 120 мегабайт. Ну неплохо, но если это так важно, то в Go можно оставить вообще один бинарник (FROM scratch), и он будет весить по сути вообще около нуля.

3) чтобы добиться постоянного соединения к бд и редису, пришлось написать несколько оберток к библиотекам и драйвер к doctrine.

4) 4ms уходит на обработку запроса без логики (пустой запрос или даже 404). Сорян, но это очень много.

5) в течение месяца после выкатки они вылавливали странные ситуации. Что-то там текло при коннекте к посгресу и тд.

Итог) Вывод делают такой: php закапывать рано, все норм.

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

Отдельно хочу заметить, что описанное в статье могла намутить только команда прокачанных php-синьоров, которые готовы ловить и фиксить необычные проблемы. А на Go с задачей "highload api, которое лезет в базу" справился бы начинающий по стандартному мануалу. И у него не возникло бы ни одной серьёзной проблемы.

C4 Model

Меня сильно заинтересовали способы грамотной визуализации архитектуры программных систем, потому что диаграмы уровня [kafka] → [scala] → [postgresql] порядком поднадоели. Хочется выработать максимально информативный, но в тоже время удобный способ рисовать то, что мы проектируем.

Из того, что нашёл, больше всего понравился фреймворк C4model. Но зачем вообще нужен целый фреймворк для визуализации? Без него каждый раз приходится импровизировать, что нарисовать на диаграмме. А нарисовать хочется многое: юзер-стори, технологии, карту микросервисов и хранилищ, технические ограничения... В итоге получается либо картинка с хаотичным набором стрелочек и квадратиков с перемешанными абстракциями «всё в одном», либо фрустрация и рисование примитивной схемы а-ля «ну тут сервис, тут база, всё понятно вроде».

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

Мне нравится подход C4, но с парой ремарок:

→ Я бы сократил C4 до C3. Визуализация связей внутри кода приложения кажется избыточной: если все сервисы пишутся по единым паттернам в неком подобии гексагональной архитектуры, то и связи между модулями будут типовыми. Лучше инвестировать в выработку организационных стандартов кодирования, чем в рисование/генерацию UML.
→ В микросервисных реалиях одно приложение содержит в себе совсем немного компонент, поэтому на третьем уровне вместо статической диаграммы внутренностей отдельного приложения лучше нарисовать основные процессы, которые оно выполняет. Для этого хорошо подходит диаграмма последовательности из PlantUML.
→ Описание слоёв не является догмой и должно адаптироваться под нужды организации или команды.

Напишите в комментарии, что вы у себя используете для визуализации/документирования разработок?

Метастабильные падения

Я просто обожаю эксплуатацию.

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

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

Ретраи

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

Кэш

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

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

Сверхоптимизации

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

Что произошло на самом деле:
1. Мы научились оптимизировать пайплайн очень хорошо, без модельки он завершался
2. Пайплайн вырос в сотню раз, но мы все ещё хорошо его оптимизировали
3. Мы поменяли модельку оптимизации
4. Теперь не хватит ресурсов компании его завершить

В итоге надо руками прописывать как запускать стадии, что противоречит всем моделям эластичности Клауда.

Ближайший простой пример: алгоритмам сжатия не стоит иметь формат, который умеет сжимать в экспоненту раз, а то и в квадрат. Из-за этого есть zip-бомбы.

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

Решения, которые стоит рассматривать при проектировке

* Приоритеты. Делать приоритеты хорошим запросам.
* Лимиты. Если что-то оптимизируете, не оптимизируете это в сотню раз, если можете эту сотню в итоге потерять и не справиться.
* Всегда планировать нагрузку без оптимизаций, которые когда-то могут не работать, в том числе кэши. Пусть оно замедлит на 100ms ответ, но оно хотя бы не упадёт. Учения, стресс тестирование пригодится.
* Деградация. Попытайтесь задизайнить бэкенд, чтобы он эластично деградировал, скажем, не искать лучший маршрут в Google Maps, а рассматривать только X%.
* Следите за системой, одно падение может обнаружить баг, который был годами. Обычно происходит так: система ломается чуть-чуть, что-то подозрительное происходит, на след день что-то ещё хуже, через 2 дня всё падает крахом.

[1] Metastable Failures in Distributed Systems

Some absolutely great software - a tools, written in Rust, which can improve your daily workflow and can help get things done faster:

Terminal emulator:

https://github.com/alacritty/alacritty

File managers:

https://github.com/ranger/ranger
https://github.com/ranger/ranger/wiki/Similar-software#hunter-rust

https://github.com/rabite0/hunter

#Rust

Подборка популярных и малоизвестных сервисов проверки email адресов на утечки пароля по слитым базам данных.

https://haveibeenpwned.com
https://leakedsource.ru
https://leakcheck.io
https://monitor.firefox.com
https://dehashed.com
https://breachalarm.com
https://sitecheck.sucuri.net
https://intelx.io/

Обсудить в чате 👉 https://news.1rj.ru/str/+jrxm2KHbIl9kMDQy