#машины_aws

Пожалуй, лучший инцидент, что я когда либо видел.

Если вкратце:
1. Управление DNS записями для DynamoDB отвалилось, в итоге:
2. Эндпоинты DynamoDB (в том числе для внутреннего пользования) отвалились, в итоге:
3. Storage backend, которым выступала DynamoDB, одного из компонентов control plane EC2 отвалился, в итоге:
4. Отвалился NLB, который не мог следить за событиями EC2.

Очень радует, что AWS решил минимальными усилиями решить конкретную проблему, а не сделать отдельный внутренний Kinesis как тогда с инцидентом CloudWatch и Cognito.


Да и не пользуйтесь us-east-1, сколько еще повторять. Новые фичи раньше всех того не стоят.

В сети можно найти интересные посты про "переволновавшиеся" LLMки, как они могут проигнорировать инструкции об безысходности и всё же дропнуть вам базу на проде.

По случаю вспомнил замечательный рассказ Станислава Лема - Ананке. 1971 год, короткий рассказ, Марс, научная фантастика, как нынче модно это называть - про машинное обучение.

Первый раз я прочитал это произведение лет 5 назад, и подумал, что этот sci-fi уже про "несвершившееся будущее" и сильно так устарел (хотя даже тогда он меня покорил той самой богиней Ананке). Но в этом году, да ещё с такими историями про LLM, оказывается что мы всё таки дожили до этого будущего, про которое когда-то подумал Лем :) Вот такие они - грёзы по несбывшемуся будущему.

#books

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

Забавно было буквально вчера в некоторых чатах на проблему DDoS'а ботами-краулерами читать "да просто юзай CF!"

Тем временем сегодня Cloudflare отдыхает... Ждём постпортема.

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

На первый взгляд, ситуация выглядит странно - просто выкатили обновление на всю сеть целиком. Ни тебе тестов, ни blue/green и cherry picking, ни даже внятной системы отката изменений. И эти люди борются звание дома высокой культуры быта! (с)

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

Станет ли у Cloudflare меньше клиентов? Сомневаюсь. Более того, на ПФ в понедельник я слышал мнение, что мелкий бизнес а России даже уходит с отечественных CDN на CF (потому что до конца оранжевого гиганта блокировать пока не собираются, а "бесплатный" CDN и DDoS-защита никуда не исчезли). Про зарубеж я вообще молчу.

Так и живём

#thereisnoclouds @snakeslair

К вопросу о скорости починки cf, коммент от их CEO (link):

Because we initially thought it was an attack. And then when we figured it out we didn’t have a way to insert a good file into the queue. And then we needed to reboot processes on (a lot) of machines worldwide to get them to flush their bad files.

Все мы люди.

Про CPU steal-time

К своему чудовищному стыду я ещё недавно совершенно не знал, что гипервизоры с хостов прокидывают в виртуалку специальную метрику steal-time, и она забирается в промстэк вместе с system/user/idle и прочими стандартным node_exporter-ом.

CPU Steal-time буквально “украденное время”. Проц выдали не тебе, а соседу. Про эту метрику мне сказал коллега по ПК Хайлоада, Георгий Меликов, за что ему большое спасибо. Я проверил, что протягивается, и забыл.

Не прошло и 2х недель, вчера участник тренинга по перфомансу показывает жутко зашумленные графики стрельб, очень отдаленно напоминающие правильные, и говорит: я уже всё перепробовал, WTF. Замечаю большой steal time (почти равен сумме user+system) и пишу в саппорт, так и так, похоже, шумный сосед / перегруженный хост.

И да, саппорт подтверждает, виртуалку переносят, 100К RPS наливаются. Клауды такие клауды 🙂

👍 зато девопс пайплайн тераформ, а не вот это ваше всё
🔥 ну, за онпрем!

Когда-то про это коллеги хорошую статью написали https://habr.com/ru/companies/vk/articles/449316/

3 декабря в Мск будет OS DevConf 25 - "Конференция про разработку системного ПО, ядра Linux и open source".

Почему приглашаю:
- мы с коллегой впервые анонсим наш новый SDS - RawStor. Расскажем почему решили писать ещё один сторадж, и ответим, почему в нём "client всегда прав". (всё в опенсорсе)
- будет ещё несколько докладов про стораджи: SPDK, Lustre (очень жду этого доклада, к примеру, контрибьюторы приедут!)
- ну и много других докладов рядом с Linux

Увидимся!

И продолжаем приглашения на новогодние тусовки :) Приходите - увидимся!

InfraDev Community приглашает на Cloud Fail ((Over)): специальный новогодний выпуск InfraDev Meetup.

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

Спикеры:
☁️Василий Степанов, руководитель направления инфраструктурных сервисов, VK Cloud, VK Tech.
☁️Константин Крамлих, руководитель поднаправления сетевых продуктов, Yandex.Cloud.
☁️Секретный доклад: подробности добавим позднее.

Подробнее о докладах читайте на странице мероприятия.

Когда: 18 декабря, с 18:00 до 23:59 
Где: Москва, Ленинградский пр., 70, офис VK Tech, БЦ «Алкон» (количество мест ограничено).
Приходите на встречу или участвуйте онлайн.

Зарегистрироваться.

А тем временем - минио закрылись. Кто форкнет первым?

Devin AI got fired

Кстати, уже доступны записи докладов, ютуб/рутуб/вк.

Но это же канальчик и про стораджи, так что приведу доклады про сторадж:
- мой с коллегой, про наш сторадж RawStor ютуб/рутуб/слайды (@gmelikov @vasi2y)
- про SPDK в MWS ютуб/рутуб (@swaoter)
- обзорный про Lustre FS от контрибьюторов с 20-летним стажем ютуб/рутуб

В прошлом посте с подавляющим лидерством победило мнение, что безопасность в виде init_on_alloc + init_on_free в ядре не нужна.

А теперь вопрос: сколько из этих 20 людей пошли и отключили её?:)

У меня уже было выключено много где, хакеры, фас!

Обратил внимание на очень интересный доклад от крупной компании на 4 буквы про их опыт с планировщиками нагрузки.

Для начала забавность - ноги растут от шедулера, который для SteamDeck делали вальвовцы - scx_lavd. Да, шедулер "для игр" приживается в промышленном мире серверов :)

Идеи лежат правильные:
- задержки доступа между ядрами процессора весьма ощутимы, есть смысл реже мигрировать нагрузку между ними, да и чтобы горячие L1-L2 кеши больше помогали
- есть смысл использовать в моменте как можно меньше ядер, чтобы минимизировать потребление и тепловыделение
- уменьшив потребление, мы можем больше питания/тепла задействовать на активные ядра
- и тут (барабанная дробь) - по факту у нас уже давно любой многоядерный процессор с "одинаковыми" ядрами содержит весьма разные по свойствам ядра:
- Всегда есть более экономное ядро, но которое не возьмёт максимальную частоту
- и наоборот - есть максимально прожорливое ядро, которое может взять те самые 5+ГГЦ частоты, но оно одно на весь чип
- и это мы даже не начали говорить про процы с топологиями аля big+little, речь про рядовые "ryzen/epyc" процы с "честными" ядрами
- и даже не продолжили говорить про NUMA топологии (которые нынче даже в рамках одного чиплетного процессора присутствуют!)

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

Я решил попробовать scx_lavd на своём ноутбуке с Debian testing и ядром 6.17. Настроен был более позитивно, чем оказалось на самом деле, в итоге эффект от "ничего не изменилось на уровне погрешности" до лагов звука из браузера при каких-то расчётах на все ядра аля слайсера 3d моделей. Важный момент - я тестировал кейс "от сети", когда нет надобности экономить потребление. В поездках потестирую ещё работу от батареи, там ожидаю больший эффект на её длительности жизни. В остальном - пока дефолтный шедулер EEVDF из свежих ядер стал отличной заменой переусложнённому CFS.

К слову - ставится scx_lavd легко, подход подключения шедулера через ebpf работает хорошо. Вообще, мне очень нравится тенденция на лёгкие эксперименты с такими основательными задачами, вспоминается похожая история из мира компрессоров с OpenZL, статью по которому я тоже разбирал.


Желаю всем нам больше простора для экспериментов в новом году!