Возможно из-за веса, там каждые сотни грамм на счету, а манипулятор, которым можно оттолкнуться (достаточно длинный и сильный) видимо весит слишком много.
Есть сервисы, которые не умеют или не могут в LE, например потому что требуют wildcard сертификат, а его без доступа к DNS не получить.
Есть куча железок, куда сертификат надо заливать руками и никакого нормального API у них.
Есть внутреннии ресурсы, к которым нет доступа снаружи и нет доступа к DNS (или неподдерживаемый провайдер DNS) и на них нельзя автоматически выписывать сертификаты.
Наконец нет нормального софта по управлению и распространению сертификатов. Пока бложик на 1 компе все ок, а вот когда серверов десятки-тысячи приходится костылить свои решения, что бы выписывать на 1 сервере и распространять на другие.
И не понятно ради чего это делать - сертификаты воруют не так уж и часто и даже в случае кражи всегда есть возможность отозвать сертификат. Мошенники обычно не подделывают оригинальный сайт, т.к. помимо сертификата надо еще как то зароутить трафик на свой сервер вместо атакуемого, а регистрируют похожий домен и спокойно выписывают на него легитимный сертификат, причет обычно как раз LE.
Сейчас 2023, некоторые ноуты/материнки уже и не умеют грузится в легаси режиме.
Так что лучший сейчас подход - незашифрованный /boot, но подписанный инитрамфс + ядро Secure Boot + хранение части ключа в TPM. Ядро с инитрамфс пакуется в единое efi приложение и подписывается.
Это сделает невозможным скрытую модификацию бут раздела и сброс настроек UEFI для отключения secure boot.
Чтобы расположить пул на определенных ODS есть более простое решение — device classes (доступно если мне не изменяет память с 13 версии ceph). При создании OSD можно задать ему класс. По умолчанию у ceph 3 класса — hdd, ssd и nvme. Мы можем добавить OSD со своим классом, например hdd-slow или ssd-metapool. После этого мы создаем crush rule: ceph osd crush rule create-replicated replicated_hdd-slow default host hdd-slow
После этого создаем пул и назначаем ему crush_rule «replicated_hdd-slow». Все, пул будет располагаться только на OSD с указанным классом.
А планируются ли хоть что то из дорогих не игровых моделей на AMD? Сейчас на AMD в основном бюджетные игровые ноуты, а хочется что то типа XPS 15 — небольшой, с хорошим дисплеем, мощным процом и 16-32 RAM.
ИМХО, но если необходима многозадачность, то лучше взять нормальный язык программирования и написать логику на нем. В баше это реализовано ужасно и любой скрипт на 200+ строк и многопоточностью будет нечитаемой кучей кода. (Это не относится к xargs -P или parallel). Контроль кодов выхода, синхронизация потоков, доступ к общим данным. Конечно все это можно заколхозить на баше, но как сисадмин, я надеюсь, что мне не достанется такой подарок на поддержку.
Если в туннеле планируется движение не личных авто, а «общественных», то какой тогда смысл от машин в тоннеле? Просто потому что это тесла?
Небольшие электропоезда на 2-3 вагона перевезут намного больше пассажиров и сделают это быстро, безопаснее и с большим комфортом.
На крайний случай автобусы (можно тоже электрические).
Водород считается практически идеальным топливом, поскольку при сгорании он не выделяет вредных парниковых газов типа CO2 — только водяной пар.
Это относится только к сгоранию чистой пары кислород-водород. При горении водорода в воздухе все не так однозначно, т.к. образуются оксиды азота и другие соединения. И их образуется тем больше, чем больше температура горения, а у водородных ДВС она выше, чем у бензиновых.
Не зависит от дискового бэкенда. Диск может быть в LVM/ZFS/QCOW/NFS и тд.
Можно вместе со снапшотом делать дамп памяти. Актуально например для серверов БД (чтобы не повреждать ее).
В вашем случае добавляется еще и возможная неконсистентность XFS при снапшоте, а значит и QCOW образов на ней. В общем что-то вы конечно восстановите, но если приложению в госте критична консистентность данных, то можно напороться. В остальном ваш способ вполне подходит для резервного бэкапа.
Насчет надежности не скажу, у нас этот способ работает на паре машин, проблем не было. Но тут конечно стоит более масштабно протестировать.
А вы уверены, что lvcreate -s надежный?) Вы же сами написали про повреждение меты LVM.
Уверены, что у вас данные всех томов правильные и в какие то случайные сектора не записалась каша (например данные снапшотов)?
Спасибо, интересная ссылка.
Но я говорил о external snapshot, он не использует возможности QCOW, все операции со снапшотом делаются QEMU, можно снапшотить даже raw диски.
Почему не используете понятно.)
Не раскрыта тема того, что случилось с LVM VG. Почему оказалась повреждена мета?
Второй вопрос — почему вы не делаете снапшоты средствами QEMU (external snapshot)?
Работает стандартная MySQL репликация.
Обратите внимание, что RocksDB это только библиотека и она никак не завязана на MySQL и может применяться отдельно от него. А есть RocksDB плагины к MySQL (например у Percona он зовется MyRocks), которые реализуют интерфейс взаимодействия с библиотекой и интегрируют ее в MySQL.
Почитать подробнее можно например тут.
В MySQL DDL операции (ALTER, CREATE, RENAME TABLE и другие) не работают с транзакциями и выполняются сразу же, а не при комите.
Чтобы выполнить RENAME атомарно следует делать так:
CREATE TABLE history_tmp LIKE history;
RENAME TABLE history TO history_old, history_tmp TO history; ;
По теме самой статьи. Мы тоже некоторое время использовали партиционирование, но оно не удобно по следующим причинам:
Меняется схема данных. При обновлениях могут вылезать проблемы. (Актуально для версий <3.2, т.к. для них требовалась модификация индексов для работы партиционирования. )
Удаление данных происходит только целыми партициями. Нельзя одну метрику хранить неделю, а другую два года.
Поэтому сейчас мы применяем не партиционирование, а храним историю в таблицах с движком RocksDB. Плюсы следующие:
Встроенный housekeeper работает даже на больших объемах данных. Можно гибко назначать метрикам время хранения.
Отличное сжатие. По сравнения с InnoDB компрессией данные стали занимать примерно в 2 раза меньше места.
Простая процедура миграции. Надо только поставить RocksDB плагин и сделать ALTER нужных таблиц.
Не меняется схема, только движок для нескольких таблиц. Пока еще ни разу не было проблем при апгрейде. (3.4 -> 4.0 -> 4.2)
Выборки из БД также работают быстрее.
В общем для существующих инсталляций лучше использовать решение с RocksDB. Для новых лучше наверно использовать официальное решение с TimescaleDB.
Про 20к интересно, это на Galera или обычная репликация? Просто у нас уже при всплесках до 1-2к начинает расти очередь на отправку. При этом трафик сети в районе нескольких мегабит, есть мнение, что дело не в пропускной способности, а в latency сети.
Скорость записи ограничивается двумя параметрами: диском и сетью. С дисками у нас проблем нет, они могут сильно больше, чем у нас есть сейчас (сейчас 400-600 qps, диски могут вытянуть 40-60к). Сейчас ограничивающим фактором является сеть (1 Gbit/s), по ощущениям через нее можно пропихнуть 1.5-2к qps. Сеть планируем апгрейдить.
По масштабированию на уровне кластер — если понадобится вероятно будем шардировать на уровне приложения на несколько кластеров.
Все горячие данные помещаются в память, чтение с диска минимальное, в районе 100-200 IOPS. Да, большие выборки активно кэшируются, на nosql бд приходит около 30к rps. Из MySQL в основном делаются простые выборки по Primary Key для тех данных, которые нежелательно или не нужно кэшировать. Постоянно обновляется кэш и работают кроны, которые используют напрямую БД без кэша.
Если репликация всё равно асинхронная, то в чем принципиальная разница для разработчика разъедутся ноды на 10 или 1000 транзакций?
Важно то, что мы знаем на сколько они могут разъехаться, рассчитывать на константу проще. Подробнее ответил в комментарии выше.
По каким причинам в рассмотрение не попал MySQL NDB Cluster?
Честно говоря не помню, почему то исключили его из рассмотрения в самом начале поисков решения.
Вы абсолютно правы, репликация все равно асинхронная и думать все равно приходится. Разница в том, что у нас например длина очереди 173 транзакции, это примерно 0.5 сек отставания при больших транзакциях (округлим до секунды). Разработчик может быть уверен, что измененные данные окажутся на слейве через секунду. В случае обычной асинхронной репликации никаких гарантий нет и слейв может отставать например на пол часа. Хотя на корню это проблему конечно не решает, это не настоящая синхронная репликация.
Еще можно использовать переменную «wsrep_sync_wait=7». Это заставит ноду выполнить запрос только после применения всех транзакций в текущей очереди.
Как я уже писал отказоустойчивость это основная причина внедрения кластера у нас. Но защищены только те транзакции, которые успели реплицироваться на остальные ноды. При внезапном падении сервера могут быть потерянные транзакции.
Возможно из-за веса, там каждые сотни грамм на счету, а манипулятор, которым можно оттолкнуться (достаточно длинный и сильный) видимо весит слишком много.
Ужасное изменение.
Есть сервисы, которые не умеют или не могут в LE, например потому что требуют wildcard сертификат, а его без доступа к DNS не получить.
Есть куча железок, куда сертификат надо заливать руками и никакого нормального API у них.
Есть внутреннии ресурсы, к которым нет доступа снаружи и нет доступа к DNS (или неподдерживаемый провайдер DNS) и на них нельзя автоматически выписывать сертификаты.
Наконец нет нормального софта по управлению и распространению сертификатов. Пока бложик на 1 компе все ок, а вот когда серверов десятки-тысячи приходится костылить свои решения, что бы выписывать на 1 сервере и распространять на другие.
И не понятно ради чего это делать - сертификаты воруют не так уж и часто и даже в случае кражи всегда есть возможность отозвать сертификат. Мошенники обычно не подделывают оригинальный сайт, т.к. помимо сертификата надо еще как то зароутить трафик на свой сервер вместо атакуемого, а регистрируют похожий домен и спокойно выписывают на него легитимный сертификат, причет обычно как раз LE.
Конечно можно)
В любой UEFI за редким исключением, типа surface можно добавить свои ключи и Secure Boot прекрасно работает
Сейчас 2023, некоторые ноуты/материнки уже и не умеют грузится в легаси режиме.
Так что лучший сейчас подход - незашифрованный /boot, но подписанный инитрамфс + ядро Secure Boot + хранение части ключа в TPM. Ядро с инитрамфс пакуется в единое efi приложение и подписывается.
Это сделает невозможным скрытую модификацию бут раздела и сброс настроек UEFI для отключения secure boot.
ceph osd crush rule create-replicated replicated_hdd-slow default host hdd-slowПосле этого создаем пул и назначаем ему crush_rule «replicated_hdd-slow». Все, пул будет располагаться только на OSD с указанным классом.
Небольшие электропоезда на 2-3 вагона перевезут намного больше пассажиров и сделают это быстро, безопаснее и с большим комфортом.
На крайний случай автобусы (можно тоже электрические).
Это относится только к сгоранию чистой пары кислород-водород. При горении водорода в воздухе все не так однозначно, т.к. образуются оксиды азота и другие соединения. И их образуется тем больше, чем больше температура горения, а у водородных ДВС она выше, чем у бензиновых.
В вашем случае добавляется еще и возможная неконсистентность XFS при снапшоте, а значит и QCOW образов на ней. В общем что-то вы конечно восстановите, но если приложению в госте критична консистентность данных, то можно напороться. В остальном ваш способ вполне подходит для резервного бэкапа.
Насчет надежности не скажу, у нас этот способ работает на паре машин, проблем не было. Но тут конечно стоит более масштабно протестировать.
А вы уверены, что lvcreate -s надежный?) Вы же сами написали про повреждение меты LVM.
Уверены, что у вас данные всех томов правильные и в какие то случайные сектора не записалась каша (например данные снапшотов)?
Но я говорил о external snapshot, он не использует возможности QCOW, все операции со снапшотом делаются QEMU, можно снапшотить даже raw диски.
Почему не используете понятно.)
Второй вопрос — почему вы не делаете снапшоты средствами QEMU (external snapshot)?
Обратите внимание, что RocksDB это только библиотека и она никак не завязана на MySQL и может применяться отдельно от него. А есть RocksDB плагины к MySQL (например у Percona он зовется MyRocks), которые реализуют интерфейс взаимодействия с библиотекой и интегрируют ее в MySQL.
Почитать подробнее можно например тут.
Чтобы выполнить RENAME атомарно следует делать так:
По теме самой статьи. Мы тоже некоторое время использовали партиционирование, но оно не удобно по следующим причинам:
Поэтому сейчас мы применяем не партиционирование, а храним историю в таблицах с движком RocksDB. Плюсы следующие:
В общем для существующих инсталляций лучше использовать решение с RocksDB. Для новых лучше наверно использовать официальное решение с TimescaleDB.
diff -r ./ /empty_dir/ | awk -F ':' '{print $2}'
chown -v -R root:root ./По масштабированию на уровне кластер — если понадобится вероятно будем шардировать на уровне приложения на несколько кластеров.
Важно то, что мы знаем на сколько они могут разъехаться, рассчитывать на константу проще. Подробнее ответил в комментарии выше.
Честно говоря не помню, почему то исключили его из рассмотрения в самом начале поисков решения.
Еще можно использовать переменную «wsrep_sync_wait=7». Это заставит ноду выполнить запрос только после применения всех транзакций в текущей очереди.
Как я уже писал отказоустойчивость это основная причина внедрения кластера у нас. Но защищены только те транзакции, которые успели реплицироваться на остальные ноды. При внезапном падении сервера могут быть потерянные транзакции.