Форум русскоязычного сообщества Ubuntu


Хотите сделать посильный вклад в развитие Ubuntu и русскоязычного сообщества?
Помогите нам с документацией!

Автор Тема: История двухлетнего опыта использования ceph в веб-хостере и полученный опыт.  (Прочитано 7721 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн graddata

  • Автор темы
  • PreSale
  • Администратор
  • Старожил
  • *
  • Сообщений: 1836
  • BIGCloud
    • Просмотр профиля
Интересный пост на Хабре, описывающий опыт веб-хостера FirstVDS в его попытках сделать кластер на ceph, и честное описание всех значительной части проблем, которые они хапнули в процессе. Полезное и душеспасительное чтение для всех, кто рассматривает ceph как enterprise-grade решение.
Вкратце, бегло о lessons learned:

* Процесс «выучивания уроков» занял примерно два года, на сегодняшний день. Первая версия была собрана осенью 2014 года.

* Не все x86 сервера «одинаково полезны». Купленные специально под кластер сервера оказались глючными.

Чтобы опробовать новую архитектуру и избавиться от прежних недостатков, собрали тестовый стенд. И тут выяснилось интересное — специально купленные для сборки первой версии серверы оказались «палёными». Системная шина всех серверов работала медленно. В результате, все устройства, связанные с северным и южным мостами — карты IB, подключенные по PCI-E, диски, память — также работали медленно. Это объясняло большую часть проблем, с которыми мы столкнулись. В качестве пробы взяли несколько свободных нод, на которых обычно запускаем клиентские VDS. По тех. характеристикам они почти ничем не отличались. Собрали и запустили кластер на этих машинах, стали прогонять тесты. Всё летает! … купили новые серверы на базе Xeon 2630 …
* Далекая от оптимальности схема восстановления избыточности в ceph, требующая ручной регулировки.

Кластер справлялся с задачами — при выходе из строя дисков или нод целиком, он продолжал функционировать. Однако, каждая перебалансировка превращала ситуацию в критическую. При добавлении нового диска сглаживали пик нагрузки, используя веса. Вес отвечает за степень использования конкретного физического носителя. Устанавливаем новый диск, ставим вес 0 — диск не используется. После этого увеличиваем вес постепенно, и перебалансировка происходит маленькими порциями. Если же диск выходит из строя, то веса не срабатывают: ~1 Тб реплик надо «размазать» по оставшимся дискам сразу, и Ceph надолго уходит в режим записи данных, загружая диски «пустой» работой.
* Перестроение кластера ceph на ходу вызывает существенную нагрузку на серверы и влияет на нормальную работу приложений

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

При увеличении количества VDS кластер начинал работать нестабильно, и мы переносили клиентские машины на обычные ноды. …
После нескольких итераций стало ясно, что ситуация кардинально не меняется. Приняли решение перенести клиентов на обычные ноды и расформировать кластер.
Первая версия кластера не оправдала ожиданий. Клиенты сталкивались с дисковыми тормозами, а мы уделяли слишком много времени технической поддержке кластера.
* Несбалансированная система с купленными «для экономии» дисками SATA большой емкости стала проблемой при увеличении нагрузки.

* Сетевая распределенная запись на хранилище, без data locality, одновременно с высокой загрузкой кластера по вводу-выводу — зло.

* SSD в режиме кэша в ряде специфических ситуаций, например замене вышедшего из строя диска и последующей перебалансировке, работает плохо.

Около 5-ти месяцев система замечательно работала, радуя нас и клиентов. Так было, пока количество клиентов не достигло критического значения. Вместительные диски по 4-8 Тб всё-таки вылезли нам боком. При заполнении диска уже наполовину, он превращался в бутылочное горлышко — большое количество файлов, принадлежащих разным VDS, располагались на одном физическом носителе, и ему приходилось обслуживать большое количество клиентов. При выходе его из строя перебалансировка тоже проходила тяжело — надо перераспределить большой объём информации. SSD-кэш в таких условиях плохо справлялся со своими обязанностями. Рано или поздно диск кэша переполнялся и давал сигнал — с этого момента я ничего не кэширую, а только записываю сохраненную информацию на медленный HDD-диск. HDD-диск испытывает в это время двойную нагрузку — обрабатывает прямые обращения, которые поступают минуя кэш, и записывает сохраненные в кэше данные. Хранилище хорошо работало, пока дело не доходило до изменения дисковой конфигурации. Выпадение диска или добавление нового сильно замедляло общую пропускную способность хранилища.
* Низкое качество кода ceph, может привести к серьезным проблемам с разрушением хранилища данных.

Используйте LTS-выпуски Ceph. Не рассчитывайте, что будете накатывать новую версию с каждым релизом. Обновление — потенциально опасная операция для хранилища. Переход на новую версию повлечёт изменения в конфигах, и не факт, что хранилище заработает после обновления. Отслеживайте багфиксы — они бэктрекаются из новых версий в старые.
* Баги могут уничтожить как работу кластера в целом, так и содержимое хранилища.

18 февраля 2016 мы столкнулись с критическим багом Ceph: в процессе скидывания кэша на диск происходила некорректная запись блока данных. Это приводило к отключению процессов ceph-osd всех дисков, где хранились реплики злосчастного блока. Система сразу лишалась трёх дисков, а значит и всех файлов, размещенных на них. Запускался процесс перебалансировки, но не мог завершиться до конца — ведь из системы пропадали все три копии как минимум одного блока данных (и соответствующего файла), с которого началась проблема. Консистентность хранилища была под угрозой. Мы вручную удаляли ошибочные блоки, перезапускали процессы ceph-osd, но это помогало ненадолго. Ошибочная запись повторялась, балансировка начиналась снова, и хранилище рушилось. …
Напряженный поиск в интернете дал результат — закрытая бага в последнем на тот момент релизе Ceph Hammer. Наше хранилище запущено на предыдущей версии — Firefly.
Предупредили клиентов о недоступности серверов и приступили к обновлению. Переключились на другой репозиторий, в который залит фикс баги, выполнили yum update, перезапустили процессы Ceph — не помогло. Ошибка повторяется. Локализовали источник проблемы — запись из кэша в основное хранилище — и отключили кэширование полностью. Клиентские серверы заработали, но каждая перебалансировка превращалась в ад. Диски не справлялись с обслуживанием системной балансировки и клиентского чтения-записи.
Решили проблему кардинально — отказались от SSD-кэша
* Для полноценной работы кластера ceph требуется allflash конфигурация.

поставили SSD-накопители в качестве основных. Тут помогли ноды с большим количеством дисковых корзин, предусмотрительно купленные для кластера хранения. Заменяли постепенно: сначала добавили по четыре SSD в оставшиеся пустые корзины на каждом сервере, а после балансировки данных, стали по одному заменять старые HDD-диски на SSD. Делали по схеме: удаление диска, установка диска, балансировка данных, удаление, установка, балансировка и так далее по кругу, пока в нодах не остались только SSD. Заменяли на горячую …
Использовали промышленные накопители Samsung 810 размером 1 Тб. Не стали использовать SSD большего размера, чтобы не провоцировать ситуацию «узкого горлышка», когда на одном физическом носителе располагается много данных, и, следовательно на него приходится большое количество обращений.
Таким образом, постепенно мы заменили все накопители на SSD. И наступило счастье
Мои выводы (которые могут не совпадать с выводами авторов оригинального поста): ceph в продакшне — опыт для людей с железными яйцами. Скупой платит. И хорошо если только дважды. И тем более хорошо, если только деньгами. Забудьте об отпусках с семьей и отключенном на ночь звонке телефона. Это не для вас теперь.
Зато не скучно. :)

источник: http://blog.in-a-nutshell.ru/ceph-issues-in-firstvds-and-lessons-learned/

Оффлайн victor00000

  • Старожил
  • *
  • Сообщений: 15568
  • Глухонемой (Deaf)
    • Просмотр профиля
я думал, ждиски гарантия и VPS, VDS бесплатно.
Wars ~.o

 

Страница сгенерирована за 0.031 секунд. Запросов: 22.