Кто-нибудь уже предложил использовать kubernetes вместо RHEL 5 для комплексного решения проблем? Сервисы на ipvs явно производительнее haproxy, есть хэлсчеки и все что надо для счастья, внешний nginx на ingress controller и внутренние - с костылями дополнительной логикой. Angie, к слову, вынес в коммерческую версию всё ровно то, что есть в Nginx Plus
Судя по таблице с ограничениями - точно он. И нет тени сомнений в лимите на 248 снапшотов и 248 файлов в файловой системе P.S.: Имелось в виду 2^48 файлов, и это только в одном каталоге, но для снапшотов этот лимит - 2^64 (хотя втыкать начинает после 10000)
Таких примеров "случайных" ошибок достаточно, особенно интересно то, что связаны они весьма часто с криптографией, типа cve-2008-0166. И по результатам аудита от независимых аудиторов, агенты АНБ общественная комиссия по расследованию приходит к выводу, что это авторы бага не нарочно
Использование слова Вы с большой буквы допустимо лишь при личном обращении. "Вам в ленту" явно противоречит такому использованию, это обращение к широкой аудитории. Следовательно, ИИ ошибся.
Такие посудомойки разбирают на оставшиеся в живых запчасти и продают на авито. Долго, но на собранную сумму, как мне кажется, можно купить две новых посудомойки. С другой стороны, если на авито есть сломавшаяся деталь за 1-2 тысячи рублей, это явно меньше, чем потратить 40+ тыщ на новую машинку. Но за 15 лет резина и пластик деградируют, есть вероятность, что одной деталью не обойдется
Вы сейчас точно про iOS? Песочница приложений, разрешения, подпись кода, и прочие механизмы безопасности? И это не считая того, что Apple, которая просто устраняет уязвимости в очередной версии iOS, не публикует никаких подробностей про это. Уязвимости, найденные независимыми реверсерами, в лучшем случае продаются Apple в виде bug bounty, или становятся основой для джейлбрейка, а в худшем - продаются той же NSO Group, никто про них CVE не напишет
Да, stateless приложение типа hello world без БД отлично работает в такой схеме. Зачем, правда, таким приложениям столь сложная схема переключения? Фаулер в схеме указывает еще и две БД - для blue и green. И этот прекрасный момент все сторонники b/g подхода почему-то обходят стороной. Делов-то, обеспечить синхронизацию БД сначала blue -> green, применить миграции к green, переключить нагрузку на БД green, ...[какая-то магия]..., и blue с green поменялось местами без потери данных. Если из схемы b/g убрать раздельные БД, оставив одну центральную, то начинаются пляски с совместимыми миграциями, и начинаются вопросы к миграциям при откате приложения на предыдущую версию, если не взлетело. По сравнению с которыми плюс одномоментного переключения на новую версию и обратно несколько меркнет
Информация о прекращении продаж/поддержки self-hosted решений Jira и Confluence DataCenter - неверна, прекращены продажи редакции Server, и будет прекращен выпуск обновлений для них. Jira и Confluence в редакции DataCenter предполагает лицензирование от 500 пользователей, при этом российским компаниям их также не продадут, но есть варианты.
Зачем вводить региональные ограничения? Бордюры по всей России, а поребрики - только в Питере. Ну и есть мнение, что поребрик - это камень, выступающий над дорогой, встречается в таком виде весьма нечасто
Запланированное устаревание есть и в энтерпрайзных моделях (я бы сказал, что именно в них, по причине большей надежности). Некоторые случаи всплывали наружу, а про некоторые только вопли пользователей на форумах, которые поставили две ссд в миррор, с предсказуемым результатом
Было бы логично рассмотреть интеграцию в код OpenTelemetry а не привязываться к одному вендору. А OpenTelemetry коллектор может отсылать трейсы и в ElasticAPM
Да, "бесплатные" снапшоты есть только в zfs и btrfs, в случае только добавления данных они, к тому же, не занимают места, служа своего рода резервной копией от удаления. Также, снапшоты можно использовать для инкрементального бэкапа (на самом деле - асинхронной репликации) на другой сервер/диск
Проблемы с SMR не возникают только в том случае, если диск используется как архив - постепенно заполняется от первого цилиндра к последнему. Тогда черепичная перезапись не производит лишний оверхед, и это верно для любой файловой системы. Если это не так, на диск идут записи мелкими блоками в рандомные места (по причине фрагментации), это приводит к двойной перезаписи шинглов. То, что на многочисленных тестах SMR видно как падение скорости записи на заполненном диске. На файловых системах с COW это проявляется в большей степени из-за того, что частичная перезапись файла приводит к записи новых блоков, и образованию "дырок" по факту дискарда неиспользуемых блоков. ZFS такую фрагментацию проблемой особо не считает, но не SMR
Крайне не рекомендуется использовать диски SMR под файловыми системами ZFS и BTRFS. Ну только если вы туда только пишете, не удаляете и не модифицируете файлы (cow же), то есть использовать для архивного хранения (но зачем тогда btrfs?). Также рекомендуется иногда запускать scrub - так хотя бы зеркало развалится раньше, чем данные на обоих дисках окажутся испорченными. Ну и насчет btrfs скорее всего те же рекомендации, что и для ZFS по части использования ECC - при пересчете контрольных сумм (да, при scrub в том числе), ошибки памяти приведут к расхождению посчитанных и хранящихся значений
Логично бы снимать резервные копии с выделенных для этой цели реплик. Вот как их остановить в один момент для получения бэкапов в более или менее один момент времени… Альтернативный вариант — файловая система со снапшотами, может быть даже на общем для всех узлов хранилище. Но какой профит от центральной СХД и шарда из монг — довольно интересный вопрос.
В трансляции задали резонные вопросы, из которых следует:
Рассчитывать на появление коллизий в SHA256 — надо быть очень большим пессимистом
на первом этапе не было железа для реализации шардов на нескольких серверах, но был диск для "партиций"
Основная гигантская коллекция была просто key-value без дополнительных индексов
И кто помешал не городить велосипеды, а просто репартиционировать коллекцию средствами монги, а затем, при переходе к шардам, и шардировать — не ясно совсем. При том, что в итоге в эксплуатации осталась и старая база с программными партициями, а значит и логика в коде
Звонили тут мошенники 6 раз за два дня, и каждый раз с нового номера в разных регионах. Бросаешь трубку — через 20 сек звонок с другого номера. Видимо есть какой-то стык у них с операторами в РФ, где позволяется подмена номера на российские.
На госуслугах есть форма сообщения о факте такого звонка — https://www.gosuslugi.ru/600465/1/form
Есть вопросы к методологии тестирования как минимум ZFS. Под bs512 и 4k для ZFS вы имели ввиду recordsize? Это тот, который дефолтно 128k? И который в CEPH 4МБ? При том, что размер блока записи/чтения для максимальной скорости у самих NVMe SSD, может доходить до 512к (см методологию тестирования Intel)? Совершенно понятно, откуда такая разница в результатах между 512 и 4к, файловая система делает в 8 раз больше операций над метаданными. Какой у вас планируется ворклоад, даже для баз данных рекомендуется 8k, разве что виртуалки с WinXP 512 используют? Также не указана версия ZFS, на NVMe показывает в несколько раз более высокие результаты вторая версия (штатно идет с Ubuntu LTS 22.04), у вас видимо дефолтная для 20.04LTS 0.8.3
Сразу видны уши Майкрософта в разработке спецификации UEFI (BMP - виндовый формат картинок, кому еще он мог понадобиться)
Кто-нибудь уже предложил использовать kubernetes
вместо RHEL 5для комплексного решения проблем? Сервисы на ipvs явно производительнее haproxy, есть хэлсчеки и все что надо для счастья, внешний nginx на ingress controller и внутренние - скостылямидополнительной логикой.Angie, к слову, вынес в коммерческую версию всё ровно то, что есть в Nginx Plus
Судя по таблице с ограничениями - точно он. И нет тени сомнений в лимите на 248 снапшотов и 248 файлов в файловой системе
P.S.: Имелось в виду 2^48 файлов, и это только в одном каталоге, но для снапшотов этот лимит - 2^64 (хотя втыкать начинает после 10000)
Таких примеров "случайных" ошибок достаточно, особенно интересно то, что связаны они весьма часто с криптографией, типа cve-2008-0166. И по результатам аудита от независимых аудиторов,
агенты АНБобщественная комиссия по расследованию приходит к выводу, что это авторы бага не нарочноИспользование слова Вы с большой буквы допустимо лишь при личном обращении. "Вам в ленту" явно противоречит такому использованию, это обращение к широкой аудитории. Следовательно, ИИ ошибся.
Такие посудомойки разбирают на оставшиеся в живых запчасти и продают на авито. Долго, но на собранную сумму, как мне кажется, можно купить две новых посудомойки. С другой стороны, если на авито есть сломавшаяся деталь за 1-2 тысячи рублей, это явно меньше, чем потратить 40+ тыщ на новую машинку. Но за 15 лет резина и пластик деградируют, есть вероятность, что одной деталью не обойдется
Вы сейчас точно про iOS? Песочница приложений, разрешения, подпись кода, и прочие механизмы безопасности? И это не считая того, что Apple, которая просто устраняет уязвимости в очередной версии iOS, не публикует никаких подробностей про это. Уязвимости, найденные независимыми реверсерами, в лучшем случае продаются Apple в виде bug bounty, или становятся основой для джейлбрейка, а в худшем - продаются той же NSO Group, никто про них CVE не напишет
Да, stateless приложение типа hello world без БД отлично работает в такой схеме. Зачем, правда, таким приложениям столь сложная схема переключения? Фаулер в схеме указывает еще и две БД - для blue и green. И этот прекрасный момент все сторонники b/g подхода почему-то обходят стороной. Делов-то, обеспечить синхронизацию БД сначала blue -> green, применить миграции к green, переключить нагрузку на БД green, ...[какая-то магия]..., и blue с green поменялось местами без потери данных. Если из схемы b/g убрать раздельные БД, оставив одну центральную, то начинаются пляски с совместимыми миграциями, и начинаются вопросы к миграциям при откате приложения на предыдущую версию, если не взлетело. По сравнению с которыми плюс одномоментного переключения на новую версию и обратно несколько меркнет
Информация о прекращении продаж/поддержки self-hosted решений Jira и Confluence DataCenter - неверна, прекращены продажи редакции Server, и будет прекращен выпуск обновлений для них. Jira и Confluence в редакции DataCenter предполагает лицензирование от 500 пользователей, при этом российским компаниям их также не продадут, но есть варианты.
Зачем вводить региональные ограничения? Бордюры по всей России, а поребрики - только в Питере. Ну и есть мнение, что поребрик - это камень, выступающий над дорогой, встречается в таком виде весьма нечасто
Запланированное устаревание есть и в энтерпрайзных моделях (я бы сказал, что именно в них, по причине большей надежности). Некоторые случаи всплывали наружу, а про некоторые только вопли пользователей на форумах, которые поставили две ссд в миррор, с предсказуемым результатом
судя по количеству инфоповодов с упоминанием названия компании, суть тут скорее маркетинговая
Было бы логично рассмотреть интеграцию в код OpenTelemetry а не привязываться к одному вендору. А OpenTelemetry коллектор может отсылать трейсы и в ElasticAPM
Да, "бесплатные" снапшоты есть только в zfs и btrfs, в случае только добавления данных они, к тому же, не занимают места, служа своего рода резервной копией от удаления. Также, снапшоты можно использовать для инкрементального бэкапа (на самом деле - асинхронной репликации) на другой сервер/диск
Проблемы с SMR не возникают только в том случае, если диск используется как архив - постепенно заполняется от первого цилиндра к последнему. Тогда черепичная перезапись не производит лишний оверхед, и это верно для любой файловой системы. Если это не так, на диск идут записи мелкими блоками в рандомные места (по причине фрагментации), это приводит к двойной перезаписи шинглов. То, что на многочисленных тестах SMR видно как падение скорости записи на заполненном диске. На файловых системах с COW это проявляется в большей степени из-за того, что частичная перезапись файла приводит к записи новых блоков, и образованию "дырок" по факту дискарда неиспользуемых блоков. ZFS такую фрагментацию проблемой особо не считает, но не SMR
Крайне не рекомендуется использовать диски SMR под файловыми системами ZFS и BTRFS. Ну только если вы туда только пишете, не удаляете и не модифицируете файлы (cow же), то есть использовать для архивного хранения (но зачем тогда btrfs?). Также рекомендуется иногда запускать scrub - так хотя бы зеркало развалится раньше, чем данные на обоих дисках окажутся испорченными. Ну и насчет btrfs скорее всего те же рекомендации, что и для ZFS по части использования ECC - при пересчете контрольных сумм (да, при scrub в том числе), ошибки памяти приведут к расхождению посчитанных и хранящихся значений
Логично бы снимать резервные копии с выделенных для этой цели реплик. Вот как их остановить в один момент для получения бэкапов в более или менее один момент времени… Альтернативный вариант — файловая система со снапшотами, может быть даже на общем для всех узлов хранилище. Но какой профит от центральной СХД и шарда из монг — довольно интересный вопрос.
В трансляции задали резонные вопросы, из которых следует:
И кто помешал не городить велосипеды, а просто репартиционировать коллекцию средствами монги, а затем, при переходе к шардам, и шардировать — не ясно совсем. При том, что в итоге в эксплуатации осталась и старая база с программными партициями, а значит и логика в коде
Звонили тут мошенники 6 раз за два дня, и каждый раз с нового номера в разных регионах. Бросаешь трубку — через 20 сек звонок с другого номера. Видимо есть какой-то стык у них с операторами в РФ, где позволяется подмена номера на российские.
На госуслугах есть форма сообщения о факте такого звонка — https://www.gosuslugi.ru/600465/1/form
Есть вопросы к методологии тестирования как минимум ZFS. Под bs512 и 4k для ZFS вы имели ввиду recordsize? Это тот, который дефолтно 128k? И который в CEPH 4МБ? При том, что размер блока записи/чтения для максимальной скорости у самих NVMe SSD, может доходить до 512к (см методологию тестирования Intel)? Совершенно понятно, откуда такая разница в результатах между 512 и 4к, файловая система делает в 8 раз больше операций над метаданными. Какой у вас планируется ворклоад, даже для баз данных рекомендуется 8k, разве что виртуалки с WinXP 512 используют? Также не указана версия ZFS, на NVMe показывает в несколько раз более высокие результаты вторая версия (штатно идет с Ubuntu LTS 22.04), у вас видимо дефолтная для 20.04LTS 0.8.3