С момента запуска Hetzner Cloud в 2018 году мы постоянно работаем над расширением нашей платформы и даже предложили вам два разных типа хранилища для наших стандартных серверов на базе Intel: локальный (NVMe SSD) и сетевой (CEPH). Локальное хранилище всегда предлагало превосходную производительность и задержку при одинаковом уровне стабильности, что делает их лучшим выбором для всех наших клиентов. Об этом также свидетельствует тот факт, что более 95% всех существующих сегодня серверов используют локальное хранилище.

Чтобы упростить наше предложение и повысить эффективность наших пулов ресурсов, мы отказываемся от действующих сегодня типов серверов на основе сетевых хранилищ. Затронутые типы серверов: cx11-ceph, cx21-ceph, cx31-ceph, cx41-ceph, cx51-ceph. Все ваши существующие серверы на базе ceph будут продолжать работать, как раньше, и с вашей стороны не требуется никаких действий в отношении этих серверов. При создании новых серверов мы просим вас использовать их дублирующие части на основе локального хранилища (cx11, cx21, cx31, cx41, cx51).
Начиная с сегодняшнего дня, можно будет только изменить масштаб существующих типов серверов на основе сетевого хранилища на другой тип сервера на основе сетевого хранилища через API.

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

С 1 декабря 2021 года больше не будет возможности создавать новые серверы типа cx11-ceph, cx21-ceph, cx31-ceph, cx41-ceph, cx51-ceph.


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

Это изменение не коснется нашего продукта Volumes, который обеспечивает сетевое блочное хранилище.

Если у вас возникнут вопросы, мы с радостью поможем. Чтобы открыть запрос в службу поддержки, перейдите в пункт меню «Поддержка» в облачной консоли. Мы надеемся, что вы по-прежнему доверяете нам, поскольку мы постоянно работаем над расширением наших услуг, и вы можете рассчитывать на несколько новых функций, которые уже включены в нашу дорожную карту.

https://cloud4box.com

К сожалению наш дисковый массив ceph обеспечивающий работу всех виртуальных серверов частично вышел из строя. Часть данных пострадала. Какие есть варианты:

1. Если на сервере нет нужных вам данных, сообщите в тикет ваш сервер или серверы, а так же согласие на их переустановку. Сотрудники произведут все необходимые действия для возобновления работы сервера в порядке очереди.
2. Если на сервере есть нужные данные, то вы можете попробовать их забрать подключив iso образ, например gparted и загрузившись с него, подмонтировать диск вашего сервера забрать данные.
3. Если 2. вариант не получается сделать, мы обязательно поможем, но в порядке очереди. Очередь большая, запросов много.

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

Просьба-2. Иногда после решения проблемы клиент пишет спасибо, благодарю и пр. Просим воздержаться от подобных сообщений. Это создает дополнительную нагрузку на поддержку и мешает процессу восстановления.

Спасибо за понимание. Мы всячески стараемся решить проблему всеми возможными методами.

https://cloud4box.com

В Linux есть большое количество инструментов для отладки ядра и приложений. Большинство из них негативно сказываются на производительности приложений и не могут быть использованы в продакшене.

Пару лет назад был разработан ещё один инструмент — eBPF. Он дает возможность трассировать ядро и пользовательские приложения с низким оверхедом и без необходимости пересборки программ и загрузки сторонних модулей в ядро.
lwn.net/Articles/740157/

Сейчас уже существует множество прикладных утилит, которые используют eBPF, и в этой статье мы рассмотрим, как написать собственную утилиту для профилирования на основе библиотеки PythonBCC. Статья основана на реальных событиях. Мы пройдем путь от появления проблемы и до её исправления, чтобы показать, как могут быть использованы уже существующие утилиты в конкретных ситуациях.

Ceph Is Slow
В кластер Ceph добавили новый хост. После миграции части данных на него, мы заметили, что скорость обработки запросов на запись им гораздо ниже, чем на других серверах.

В отличие от других платформ, на этом хосте использовался bcache и новое ядро linux 4.15. Хост такой конфигурации использовался здесь впервые. И на тот момент было ясно, что корнем проблемы теоретически могло быть что угодно.

Investigating the Host
Начнем с того, что посмотрим, что происходит внутри процесса ceph-osd. Для этого воспользуемся perf и flamescope (подробнее о которых можно прочитать здесь):

Картинка говорит нам о том, что функция fdatasync() потратила много времени при отправке запроса в функции generic_make_request(). Значит, что, скорее всего, причина проблем где-то вне самого демона osd. Это может быть либо ядро, либо диски. Вывод iostat показывал высокую задержку обработки запросов bcache-дисками.

При проверке хоста мы обнаружили, что демон systemd-udevd потребляет большое количество времени CPU — около 20% на нескольких ядрах. Это странное поведение, так что нужно выяснить его причину. Так как Systemd-udevd работает с uevent’ами, мы решили посмотреть на них через udevadm monitor. Оказывается, генерировалось большое количество change-событий для каждого блочного устройства в системе. Это довольно необычно, поэтому нужно будет посмотреть, что генерирует все эти ивенты.

Подробнее
blog.selectel.ru/from-high-ceph-latency-to-kernel-patch-with-ebpf-bcc/

Для начала надо удалить диск с кластера.

На ноде управления исполняем:

ceph osd out ID

Где ID это номер osd мертвого диска.

На самой ноде с osd исполняем:

systemctl stop ceph-osd@ID

И на головной ноде полностью выводим osd из кластера:

ceph osd crush remove osd.ID
ceph auth del osd.ID
ceph osd rm ID

Теперь выключаем сервер, изымаем диск и вводим новый.

Смотрим привязки дисков и определяем где лежат журналы. На ноде с osd исполняем:

ceph-disk list | grep journal

Так мы увидим какой журнал подключен к какому диску.

Удаляем партицию с журналом с диска с журналами.

parted /dev/диск_с_журналом rm номер_партиции

Заводим диск в кластер.

Замечание: после создания новой ceph-osd номер партиции журнала будет не прежним а больше на 1 самого большого номера на диске с журналом. То есть, если на диске с журналами было 10 партиций, мы удаляем например 1-ю, то новая партиция будет на месте 1-й партиции но с номером 11 (появится дырка в нумерации разделов).

Замечание: также обнаружится, что вывод команд ceph osd tree и ceph osd df tree теряет сортировку. На самом деле там сортировка происходит по порядку создания osd-шек и вывод группируется по серверам.

Чтобы номер osd совпадал с тем, который у него был, нумерация должна быть сквозной и непрерывной, если у нас есть дырки в нумерации, то на момент ввода диска в кластер надо их закрыть. То есть сделать липовые osd:

ceph osd create $ID

Потом надо будет их удалить!

ceph osd rm $ID

Далее, на новом диске должна быть partition table типа gpt.

parted /dev/диск_с_данными mklabel gpt

Теперь можно создавать новый ceph-osd и заводить его в кластер.

Замечание: после создания osd-шка сразу начнёт заходить в кластер и начнётся синк. Поэтому желательно после ввода osd поставить ей reweight 0 и постепенно повышать. Так нагрузка на кластер будет минимальной:

ceph osd reweight $ID 0

С головной ноды запускаем (он сам создаст партицию на диске с журналом):

ceph-deploy osd prepare нода:/dev/диск_с_данными:/dev/диск_с_журналом

Все! Мы молодцы, мертвый диск заменен!