Конференции Олега Бунина (Онтико) corporate blog
System administration
*nix
Data storage
Data storages
Comments 20
-1
Потрясающе! Читается на одном дыхании, и очень поучительно. Спасибо!
-1
отдаете вы файлы размером в 1 Мб. Это означает, что если вы хотите обращаться с файлом как с одним куском информации, вы вынуждены загрузить все 100 тыс. файлов по 1 Мб в память, это 100 Гб памяти.

Кто-нибудь понял смысл этой цитаты? У них отменили потоковое чтение? А как же zero-copy transfer?

+2
Им просто не хотелось менять логику работы приложения, а хотелось серебряной пули с одной точкой входа.

Нужно три копии файла? Так выберите 3 самых менее нагруженных сервера и отправьте их параллельно на все три, пользователю покажите: «ваш файл закачался на 1 из 3 серверов», потом «2 из трёх», «ваш файл закачался».

Так пользователь будет понимать процесс, а до куче будет понимать что его данные в сохранности на трёх физических серверверах. Другой вопрос что там файлы могли заливаться через FTP (раз речь о сайтах) и такие сообщения уже не показать, но универсальное правило:
1. работа с дисками должна быть не зависимой друг от друга, тем более в рамках разных серверов
2. больше трафика — больше дисков и серверов — не надо доводить до того что один сервер с 20 терабайт файлов и от нагрузки помирает и от репликации помирает и вообще помирает.

Сам факт записи на три сервера программно исключает необходимость делать ребалансинг с диска.

Окей, не удалось за приемлемое время сделать три копии — делайте до 20% серверов резервными, закачивайте сразу четыре копии, после успешной закачки на нагруженные сервера (по чтению так как на них продакшин) временную четвёртую копию можно удалить, а на время резерва держать файлы в оперативной памяти. Хранить все файлы ведь на таком сервере не нужно, важно добавить быстрой надёжности.

Если вся система перегружена и файлы скапливаются в очереди и всё убивают своей лавиной то нужно научиться вовремя отключать сервис пользователю, иными словами не допускать ситуации когда неделю льётся трафик, а складывать некуда, сервис не работает совсем.

А так в целом доклад понравился, лучше чем предыдущий с HL++ о бинарных файловых хранилищах:)
0
«Сам факт записи на три сервера программно исключает необходимость делать ребалансинг с диска.»
— имел в виду что при первом появлении данных на диске не приходится их перераспределять по двум другим серверам
— если сервер вышел из строя то его роль подхватят все сервера на которых были аналогичные файлы — нагрузка размажется, не надо будет воротить сразу большим куском данных
— лимит доступа к каждому серверу позволит нормально отдавать файлы большинству пользователей и только 1-2% отрезать в случае если группа из серверов не большая и пришедший трафик из-за падения одного сервера не влезает размазанно по всем серверам.
— потом в фоне постепенно можно сделать третью копию файлов у которых в связи с отключением сервера стало копий меньше трёх. опять таки в размазанной нагрузке эти файлы можно слить по чуть-чуть с каждого сервера, а не создавая крайне не ровную нагрузку на 1-2 сервера.
0
А вариант с Ceph RadosGW не рассматривали? Вроде как оно распределенное и объектное и S3-совместимое.
0
Стоит учесть, что реально поддержку Ceph, как и починку разлетевшегося в щепки Ceph в мире может запровайдить только одна организация, в которой работают его коры. Что немного вкладывает твою мошонку в руки этой компании.
+5
Я могу проще про все что выше написано:
Мы не читали теорию!
Мы не читали документацию!
Мы не придумали архитектуру!
Мы вообще не думали!

Господа любой кто изучал реляционную алгербу и реляционные СУБД не когда никогда не будет НИЧЕГО КЛАСТЬ в BLOB базы данных. Это просто по архитектуре так. Это вот натурально из авиационной инженерии:

С мощным двигателем взлетит даже телега


Вот у вас так же.

Я бы сразу сказал, что ребят вам нужна документ-орентированая БД. В итоге всего три года потребовалось на понимание этой простой вещи. Как и то что в вашем случае нафиг не нужна сильная консистентность системы.

Ну и в заключение я оставлю эту картинку здесь
image

Увы но она соответствует вашим телодвижениям.
0
Ребят, размеры-то смешные, in-memory кэши ныне пожирнее бывают. 10TB это фактически 1 современный диск, который можно поставить на стол или 10 не-современных дисков. Если тирить хотзоны, так вообще все локальное и по-домашнему уютное.
+1
У меня в 2012-2016 проект рос примерно такими же темпами (сейчас тоже восемь серверов по 12 дисков в каждом; ~100Tb*3; ~10млрд картинок; запросов поменьше ~20млн/день).

Но в 2012 попалась статья о том, как хранятся картинки в YouTube.
А хранятся они там как записи в BigTable.
Чанки, версионирование, сжатие, удаление… практически всё к чему вы в итоге пришли, готовое.
В 2012 уже были три opensource клона (Hbase, Accumulo, Hypertable)

минусы такие:

1. при поломке одного из серверов, или даже всего лишь одного диска, чанки несколько минут распределяются между оставшимися серверами; хранилищ стало два, на том же железе, на kvm-виртуалках. Одно поменьше, восстанавливается за секунды.

2. большой сетевой траффик между HDFS-датанодами и таблет-серверами (можно упереться в гигабитную сетевуху при 100-300мбит общего чтения из хранилища); с этим можно бороться, например, сохраняя картинки одного 'сайта' рядом друг с другом.

Сейчас бы наверное посмотрел на Cassandra.
0
Cassandra не подойдет, она оптимизирована на запись, в чтение упрется.
0
За ceph с разбегу как то обидно. У нас он пару лет уже успешно применяется. С iops все отлично. пускаем на cepth VDSки.

osd-1 ~]# ceph status
cluster 1d071981-9840-4f01-983b-1f423bdbf56f
health HEALTH_OK
monmap e9: 3 mons at {a=172.16.0.1:6789/0,b=172.16.0.2:6789/0,d=172.16.0.4:6789/0}, election epoch 628, quorum 0,1,2 a,b,d
osdmap e42694: 33 osds: 33 up, 33 in
pgmap v34072165: 1152 pgs, 2 pools, 17894 GB data, 4497 kobjects
36066 GB used, 23074 GB / 59140 GB avail
1152 active+clean
client io 39018 kB/s rd, 27158 kB/s wr, 1819 op/s

Синтетический тест на запить iops=6177

# fio /tmp/wr.ini
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
fio-2.2.8
Starting 1 process
writetest: Laying out IO file(s) (1 file(s) / 953MB)
Jobs: 1 (f=1): [w(1)] [100.0% done] [0KB/18204KB/0KB /s] [0/4551/0 iops] [eta 00m:00s]
writetest: (groupid=0, jobs=1): err= 0: pid=11188: Fri Oct 28 05:02:18 2016
write: io=976560KB, bw=24708KB/s, iops=6177, runt= 39524msec
slat (usec): min=2, max=3318, avg=11.86, stdev= 9.37
clat (msec): min=1, max=416, avg= 5.17, stdev=11.16
lat (msec): min=1, max=416, avg= 5.18, stdev=11.16
clat percentiles (usec):
| 1.00th=[ 1608], 5.00th=[ 1880], 10.00th=[ 2064], 20.00th=[ 2384],
| 30.00th=[ 2640], 40.00th=[ 2928], 50.00th=[ 3248], 60.00th=[ 3600],
| 70.00th=[ 4128], 80.00th=[ 4896], 90.00th=[ 7072], 95.00th=[11072],
| 99.00th=[48384], 99.50th=[73216], 99.90th=[166912], 99.95th=[203776],
| 99.99th=[329728]
bw (KB /s): min= 7196, max=32800, per=100.00%, avg=24718.19, stdev=5477.65
lat (msec): 2=7.96%, 4=60.20%, 10=26.05%, 20=3.39%, 50=1.45%
lat (msec): 100=0.67%, 250=0.25%, 500=0.02%
cpu: usr=2.42%, sys=8.65%, ctx=181961, majf=0, minf=30
IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.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.1%, 64=0.0%, >=64=0.0%
issued: total=r=0/w=244140/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency: target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
WRITE: io=976560KB, aggrb=24708KB/s, minb=24708KB/s, maxb=24708KB/s, mint=39524msec, maxt=39524msec
0
Скромные у вас объемы. Хочу подробностей. Версия, сколько OSD, какой replication level.
0
Объемы хранилища? Есть же:

36066 GB used, 23074 GB / 59140 GB avail

OSD 33 штуки

Релика левел 2. Но думаем переходить на 3. Вопрос в финансировании пока.
0
Объемы хранилища? Есть же:

36066 GB used, 23074 GB / 59140 GB avail

OSD 33 штуки

Релика левел 2. Но думаем переходить на 3. Вопрос в финансировании пока.
0
взрослые парни просто не допускают, чтобы нагрузка на сервера у них превышала 30%


Правильно ли я понимаю, что по мнению автора статьи взрослые парни не допускают выкидывать менее 70% ресурсов серверных систем на ветер? Если это — красочная метафора, не мог бы автор пояснить её смысл?
Потому что когда датацентры борятся за доли процентов эффективности, где-то, возможно, всё совсем не так.
0
Вопрос вдогонку.

Я несколько раз прочитал про то, как вы уперлись в один гигабит пропускной способности сети. Это всё, конечно, было бы интересно и поучительно, окажись ваш опыт на десять лет раньше.
Можно было бы сказать: «Ага, автор говорит про нищебродство, так в 2008 10Г карточки и правда еще \»не очень\"." Хорошо, тогда 2х1Г, 4х1Г. Но вы же про 2012-2015гг, когда 10Г интерфейс дёшев. Или 2х-4х10Г.

Как у вас получилось не смасштабировать сеть? Или у вас НЕ получилось смасштабировать сеть, и за сухим «достижением предела пропускной способности» стоят десятки бессонных человеконочей?
+1
Почему выкидывать? Нагрузка на сервер, это один из многих параметров, которые необходимо учитывать.

Вот к примеру у меня есть система, в которой при нагрузке более 60% latency начинает взлетать чуть ли не экспоненциально. К счастью в этой системе это не критично, но неприятно, так как в худшем случае ждать запуска задачи иногда приходится в несколько раз дольше, чем она будет выполняться (характер нагрузки — пакетный).

Недавно на хабре в комментариях видел пример, где система работала под нагрузкой процентов в 90, но там поток задач был равномерен, одинаков и известен, по этому задержки были приемлемыми и не взлетали в небеса.

Другая сторона медали — резервирование.
Если у Вас есть кластер из 2 нод, то загружать каждую более чем на 50% категорически нельзя, ибо в случае выхода из строя одной из них вторая умрет от перегрузки.
Если ноды 3, то предел загрузки каждой из них — 2/3, если мы хотим пережить отказ одной ноды без падения.

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

И это далеко не все стороны, которые могут учитываться в реальной задаче и зависеть от загрузки оборудования.

Если сложить все это вместе, то вполне может оказаться, что в какой-то системе эти 30% загрузки — это и есть максимальная эффективность, при которой можно оказывать качественный сервис и еще одна доля процента экономии приведет к краху.
0

Вы серьёзно просите что-то сделать со статьёй, которой без малого год? Бесполезно же, разошлась везде уже именно в этом варианте. Да и комментарий с этой просьбой, который тут останется, будет намекать.


P.S. dsimonov просил удалить упоминания setup.ru из статьи, но затем изменил комментарий.

Only those users with full accounts are able to leave comments. , please.