Pull to refresh
23
Karma
0
Rating
SinTeZoiD @SinTeZoiD

User

40 каналов и чатов для тех, кто интересуется DevOps

Большой канал по мониторингу церковь метрик

Всегда актуальный список каналов находится на гитхаб github.com/goq/telegram-list

Он вам не дRook

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

Без разницы какой системой управления конфигурации я раскатываю ceph — в любом случае это гибче и надежнее, чем Rook.
Про VPA спорный вопрос. Если у вас выделенный кластер под ceph, то вы вероятно его не ограничиваете. Если кластер для ceph и приложений общий, то VPA и POD PRIORITY могут с играть решающую роль в работе всего кластера.

VPA и ограничение кластера по ресурсам в зависимости от политики или вынесет вам payload из кластера kubernetes или зарежет ceph, что приведет к его ООМ и опять таки выносу или тормозам вашего payload в кластере kuberentes. Но опять таки это вопрос сложности capacity planing.
Обязательно напишем статью, в ближайшее время, на тему возможностей конфигурирования rook.

Я с удовольствием почитаю, только пожалуйста не забудьте рассказать о сетевом взаимодействии и разделением по линкам.
Да, в первое время может быть больно, просто нужно отдавать отчет в своих действиях.

Пока я вижу только боль, повышенные риски и никих преимуществ перед классическим ceph.

Он вам не дRook

Любые параметры в rook можно задать через configmap.

Ок, допустим мы можем править конфиг каждой OSD, но тогда мы всё равно лишаемся удобства Rook.
А если не использовать rook, ceph у вас на тех же железках, что и kubernetes? Если да, то скорее всего вы имеете те же проблемы. В плане подбора ресурсов в kubernetes, можно и нужно использовать VPA.

Если у вас выделенные железки под ceph, то перед их покупкой вы обычно считаете capacity кластера и подбираете железо под нагрузку.
VPA по сути костыль. Концепт «давайте больше ресурсов поду, пока он не начнет влезать» — по сути ничем не отличается от безлимитного пода.
Не совсем понятно, почему для кластера ceph и rook по умолчанию рассматриваете разную конфигурацию серверов. Это не проблема rook!

Допустим у вас одинаковая конфигурация серверов под ceph и под kubernetes + Rook
2х10гб. В случае ceph я просто в конфиге прописываю через какой линк ходит служебный трафик, а через какой клиентский.
А теперь расскажите мне пожалуйста как вы проделаете этот фокус с распределением линков в Rook?
PS: В целом, вы описываете проблемы, которые преследуют rook точно так же как и ceph.
Так же, есть ощущение, что рассматривается одна из старых версий rook.

У Rook есть и свои проблемы, как например сложности дебага ceph демонов при проблемах.

Запускаем полноценный кластер на Kubernetes с нуля на Ubuntu 16.04

Пункты 1-3: Можно например почитать официальную документацию по установке кластера ceph. В котором все нормально расписано.
6)Что бы можно было ходить к подам снаружи можно взять другой сетевой плагин, например calico.
Отдельно стоит отметить, что kube-adm решение не для production.
p.s. Самую активную помощь по продуктам описанным в статье можно получить в каналах телеграм.
t.me/kubernetes_ru
t.me/ceph_ru

Rook — «самообслуживаемое» хранилище данных для Kubernetes

Иметь отдельное хранилище вне kubernetes. Можно на том же ванильном ceph.

Rook — «самообслуживаемое» хранилище данных для Kubernetes

А может не надо?
Концепция хорошая, но учитывая своеобразность ceph мне страшно тащить rook даже в лабу.
Ну и как всегда порекомендую наше сообщество в телеграм t.me/ceph_ru нас уже больше 600. Заходите, будем рады!

Выбор и настройка SDS Ceph

Не разобравшись в проблеме, надо сказать, что все не так.

Ваш гайд подталкивает к неправильной архитектуре — значит это плохой гайд. Если у вас есть нюансы, которые привели вас к такой архитектуре, то необходимо их указать, что сделано не было. Например зачем active-active между ЦОД? Как настроена балансировка RGW? Round-robin?
Загрузка в сутки порядка 200 файлов по 5-10Мб.

У меня есть подозрение, что можно было обойтись и без CEPH.

Выбор и настройка SDS Ceph

Сказать, что Ваше решение имеет недостатки как минимум по нагрузке на сеть, что надо гуглить best prictice перед тем как внедрять решения, что корявые внедрения отбрасывают тень на технологию, которая и так не идеальна. А пиар телеграм канала возможно убережет от ошибок следующих за вами «первопроходцев».

Выбор и настройка SDS Ceph

Перевели гайд с сайта и выложили на хабр? Отличный уровень!
По существу:
А как же нам обеспечить отказоустойчивость по ЦОД'ам?

Как оказалось в Ceph есть очень сильный инструмент — работа с crushmap

Ужасно! Как уже было сказано выше сети при балансировке будет плохо.
Но и это не самое печально. Самое печальное, что вы даже не загуглили как делать RGW multi dc
Механизм уже встроен в RGW и называется federation. И не надо таскать низкоуровневые данные через узкий канал между датацентрами.
Для тех, у кого есть вопросы по ceph его настройке, проектированию кластеров и прочему — проходите в наш телеграм канал t.me/ceph_ru нас уже почти 500 человек.

Собираем свой OpenShift Origin Cluster

Пробовали добавлять в рабочий кластер еще один мастер сервер? А какой-нибудь SDN прикрутить?

CEPH на прокачку

Главный миф, который стоит развеить после умирания cloudmouse это стабильность CEPH и его готовность к production. И я буду крайне рад, если мне его будут помогать развеивать. Вы же своим желанием сделать кластер «с малым количеством репликаций» лишь увеличиваете шансы пойти путём cloudmouse. К сожалению у CEPH есть нижнее ограничение по объему и количеству серверов. Этого нигде не пишут, но это выходит логически. И в некоторых случаях уж лучше взять старый добрый drbd со всеми его проблемами.

CEPH на прокачку

Ну так пару петабайт надо бить на пулы поменьше. Об этом и был разговор. Один пул на пару петабайт это путь в сторону боли.

CEPH на прокачку

10Gb, значение filestore max sync interval по умолчанию подходит в 99.9% случаях.

Только вот по умолчанию значение журнала 5Gb + в оф доке есть формула для расчёта размера журнала. Зачем тогда оно надо, если всем подходит?
Если понимать с вопроса «развернуть новый кластер?»
Не рассказывайте пожалуйста про rbd-mirror никому, т.к для прода он не готов и между разными версиями кластеров, в данный момент, в принципе не работает.

Если понимать с вопроса «развернуть новый пул?»
Риски от этого не изменяться, т.к. сервера с MON нужно обновлять до OSD. Отсюда следует, что изменение CRUSH-карты и распределение пула по определенным OSD нодам, ни чего полезного не даст.

А что, разве есть что-то лучше, чем синхронизировать пулы и переключить клиентов?
Нет, есть второй вариант выдать блочники клиентам из нового кластера и попросить их самих смигрировать в новый кластер, но если у вас публичное облако, то «ой».
МММ? ;)

Что вас смущает? Нет это не один такой сервер, если вы про общий конфиг.
C 30 дисками и 40Гбит/сек будет недостаточно, если использовать значения по умолчанию.

Совет про 10Гбит/сек был про то, что это надо минимум, а не вообще.
С использованием cfq scheduler на хостах с OSD.

Чем вызван выбор именно этого планировщика?

Уверен на 146%, что не переживете, если бы вы хорошо протестировали, вы бы это поняли.
переживете с помощью:
«osd_recovery_delay_start»: ">0",
«osd_max_backfills»: «1»,
«osd_recovery_threads»: «1»,
«osd_recovery_max_active»: «1»

Ок, на кластере у нас это есть но в посте нет. Косяк.
Из своего опыта могу смело сказать, что лучше анализировать через сокеты, более подробно: ceph --admin-daemon /var/run/ceph/ceph-osd.N.asok perf dump

Лучше, чем что? чем вывод ceph osd perf может быть, однако тем же ceph_exporter к prometheus это банально удобнее.
Говорит правду, просто нужно учитывать что на клиенте по умолчанию: rbd_cache = true

Интересное заявление, хотелось бы пруфов.

CEPH на прокачку

Здравствуйте.
Хотел объеденить в одном месте основные вопросы по приготовлению CEPH. Как показала практика не все готовы читать maillist, а вопросы возникающие в статье возникают довольно часто.
Если Вам есть что рассказать, то присоединяйтесь к нашей группе в телеграм по ссылке https://t.me/ceph_ru, будем рады.

Кластер хранилища Ceph на VMWare за 10 минут

CephFS должна вас спасти. Если будут вопросы, то пишите в канал в телеграм, там удобнее и быстрее решать вопросы.

Кластер хранилища Ceph на VMWare за 10 минут

Смотря какие цели ты ставишь. Могу сказать точно, что оно быстрее, чем GlusterFS )

Кластер хранилища Ceph на VMWare за 10 минут

Грустно, но такая плата за сохранность данных. Хотя допустим под бекапы можно использовать erasure-coding пулы, они дают больше места и нормально подходят для линейной записи.

Кластер хранилища Ceph на VMWare за 10 минут

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

Кластер хранилища Ceph на VMWare за 10 минут

Зависит от заполненности пула, количества ОСД и соотношения звезд. Если у вас кластер из 2х нод и 4х осд и size =2 забит на 80%, то да, при выпадении двух дисков вы скорее всего потеряете данные.
Фактор репликации 3, это при 90тб объема хранилища полезного у вас будет 30тб.

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity