- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здравствуйте, интересует опыт эксплуатации Ceph. Везде пишут что RBD, в принципе, можно использовать в продакшене, при 10Gbps проблем нет. Если кто-то использует, или есть что сказать, просьба поделиться опытом.
Не советую, ибо split brain
Вроде мыши Ceph использовали. Все померло, включая все бекапы.
Не советую, ибо split brain
поддержу.
что будет если вы по любой причине грохните блочное устройство?
Подчеркиваю: речь идет о Ceph RBD, а не о CephFS. RBD вроде как используют некоторые компании в продакшене уже более года, просто, по понятным причинам, они не расскажут подробностей..
Именно про RBD вам и ответили
А как же статьи вроде этой? http://habrahabr.ru/company/performix/blog/218065/
Поменьше читайте то, что пишут на Хабре, ибо тут ссылка на мой сайт, если нарушает - модераторы могут удалить это сообщение.
Затестили 3 ноды Ceph RBD через 10 Gbps линки, в каждой по 1 шт 1 Tb десктопных SSD. Издевались всяко путем синтетических тестов и укладывания нод, все восстанавливалось, если не ложилась большая часть кластера. Скорость записи 22-240 Mbyte/s, скорость чтения в раза два выше. Репликация стояла в значении 3, думаю в 2 будет быстрее. В продакшен все-равно стремно, пока кто-то из тех, кто имеет опыт, не отпишет. Но навскидку ничего плохого не нашли. Особенно если еще и делать бекапы на сторонний сервер на случай если кластер развалится так, что не собарть. ИМХО не основанное ни на чем - люди слишком сильно масштабируют горизонтально, думаю оно норм работает при наличии десятка нод по несколько винтов в каждой и, скорее всего будут затыки в сети при нескольких десятках нод по несколько десятков винтов в каждой...
Хочется и колется... Это выходит гораздо дешевле даже SOHO дисковых полок, не говоря о ентерпрайзе, или SDS, которые лицензируются по объему.
Тест из виртуалки, у которой диск на Ceph RBD, файловая система XFS, диск виртуалки RAW, виртуализация KVM.
RDB - status - OK
-----
FIO TEST
test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.0.13
Starting 1 process
test: Laying out IO file(s) (1 file(s) / 2048MB)
Jobs: 1 (f=1): [m] [98.6% done] [879K/331K/0K /s] [219 /82 /0 iops] [eta 00m:01s]
test: (groupid=0, jobs=1): err= 0: pid=1140: Wed Sep 23 10:09:55 2015
read : io=1535.2MB, bw=21598KB/s, iops=5399 , runt= 72784msec
write: io=525168KB, bw=7215.5KB/s, iops=1803 , runt= 72784msec
cpu : usr=4.72%, sys=23.73%, ctx=306455, majf=0, minf=20
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued : total=r=392996/w=131292/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
READ: io=1535.2MB, aggrb=21597KB/s, minb=21597KB/s, maxb=21597KB/s, mint=72784msec, maxt=72784msec
WRITE: io=525168KB, aggrb=7215KB/s, minb=7215KB/s, maxb=7215KB/s, mint=72784msec, maxt=72784msec
Disk stats (read/write):
vda: ios=391328/130728, merge=10/8, ticks=4019054/626786, in_queue=4645689, util=99.97%
-------------
DD WRITE
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 1.5068 s, 178 MB/s
[root@vm61 /]# rm test
rm: remove regular file `test'? y
[root@vm61 /]# dd if=/dev/zero of=/root/testfile bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 26.1885 s, 41.0 MB/s
[root@vm61 /]# dd if=/dev/zero of=/root/testfile2 bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 48.2158 s, 22.3 MB/s
[root@vm61 /]# dd if=/dev/zero of=/root/testfile bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 48.566 s, 22.1 MB/s
Для того что бы понять как это работает - нужно тестово внедрить.
Я рассматривал месяц назад такой вариант для клиента. Хотелось извратиться с больших хранилищем, так как клиент отдает media. Забил, лениво было. Сделал DSR (direct service return) и прикрутил split clients через nginx.
так мне было проще.
У вас цель какая ? Вы хотите нарастить производительность или объем ? Или модное слово "облако" попробовать?
Здравствуйте, интересует опыт эксплуатации Ceph. Везде пишут что RBD, в принципе, можно использовать в продакшене, при 10Gbps проблем нет. Если кто-то использует, или есть что сказать, просьба поделиться опытом.
можно Ceph но серваков надо много я бы где-то от 6 начал бы его юзать. RBD гиблое дело под HA.