Комментарии 25
Потрясающе! Читается на одном дыхании, и очень поучительно. Спасибо!
отдаете вы файлы размером в 1 Мб. Это означает, что если вы хотите обращаться с файлом как с одним куском информации, вы вынуждены загрузить все 100 тыс. файлов по 1 Мб в память, это 100 Гб памяти.
Кто-нибудь понял смысл этой цитаты? У них отменили потоковое чтение? А как же zero-copy transfer?
Им просто не хотелось менять логику работы приложения, а хотелось серебряной пули с одной точкой входа.
Нужно три копии файла? Так выберите 3 самых менее нагруженных сервера и отправьте их параллельно на все три, пользователю покажите: «ваш файл закачался на 1 из 3 серверов», потом «2 из трёх», «ваш файл закачался».
Так пользователь будет понимать процесс, а до куче будет понимать что его данные в сохранности на трёх физических серверверах. Другой вопрос что там файлы могли заливаться через FTP (раз речь о сайтах) и такие сообщения уже не показать, но универсальное правило:
1. работа с дисками должна быть не зависимой друг от друга, тем более в рамках разных серверов
2. больше трафика — больше дисков и серверов — не надо доводить до того что один сервер с 20 терабайт файлов и от нагрузки помирает и от репликации помирает и вообще помирает.
Сам факт записи на три сервера программно исключает необходимость делать ребалансинг с диска.
Окей, не удалось за приемлемое время сделать три копии — делайте до 20% серверов резервными, закачивайте сразу четыре копии, после успешной закачки на нагруженные сервера (по чтению так как на них продакшин) временную четвёртую копию можно удалить, а на время резерва держать файлы в оперативной памяти. Хранить все файлы ведь на таком сервере не нужно, важно добавить быстрой надёжности.
Если вся система перегружена и файлы скапливаются в очереди и всё убивают своей лавиной то нужно научиться вовремя отключать сервис пользователю, иными словами не допускать ситуации когда неделю льётся трафик, а складывать некуда, сервис не работает совсем.
А так в целом доклад понравился, лучше чем предыдущий с HL++ о бинарных файловых хранилищах:)
Нужно три копии файла? Так выберите 3 самых менее нагруженных сервера и отправьте их параллельно на все три, пользователю покажите: «ваш файл закачался на 1 из 3 серверов», потом «2 из трёх», «ваш файл закачался».
Так пользователь будет понимать процесс, а до куче будет понимать что его данные в сохранности на трёх физических серверверах. Другой вопрос что там файлы могли заливаться через FTP (раз речь о сайтах) и такие сообщения уже не показать, но универсальное правило:
1. работа с дисками должна быть не зависимой друг от друга, тем более в рамках разных серверов
2. больше трафика — больше дисков и серверов — не надо доводить до того что один сервер с 20 терабайт файлов и от нагрузки помирает и от репликации помирает и вообще помирает.
Сам факт записи на три сервера программно исключает необходимость делать ребалансинг с диска.
Окей, не удалось за приемлемое время сделать три копии — делайте до 20% серверов резервными, закачивайте сразу четыре копии, после успешной закачки на нагруженные сервера (по чтению так как на них продакшин) временную четвёртую копию можно удалить, а на время резерва держать файлы в оперативной памяти. Хранить все файлы ведь на таком сервере не нужно, важно добавить быстрой надёжности.
Если вся система перегружена и файлы скапливаются в очереди и всё убивают своей лавиной то нужно научиться вовремя отключать сервис пользователю, иными словами не допускать ситуации когда неделю льётся трафик, а складывать некуда, сервис не работает совсем.
А так в целом доклад понравился, лучше чем предыдущий с HL++ о бинарных файловых хранилищах:)
«Сам факт записи на три сервера программно исключает необходимость делать ребалансинг с диска.»
— имел в виду что при первом появлении данных на диске не приходится их перераспределять по двум другим серверам
— если сервер вышел из строя то его роль подхватят все сервера на которых были аналогичные файлы — нагрузка размажется, не надо будет воротить сразу большим куском данных
— лимит доступа к каждому серверу позволит нормально отдавать файлы большинству пользователей и только 1-2% отрезать в случае если группа из серверов не большая и пришедший трафик из-за падения одного сервера не влезает размазанно по всем серверам.
— потом в фоне постепенно можно сделать третью копию файлов у которых в связи с отключением сервера стало копий меньше трёх. опять таки в размазанной нагрузке эти файлы можно слить по чуть-чуть с каждого сервера, а не создавая крайне не ровную нагрузку на 1-2 сервера.
— имел в виду что при первом появлении данных на диске не приходится их перераспределять по двум другим серверам
— если сервер вышел из строя то его роль подхватят все сервера на которых были аналогичные файлы — нагрузка размажется, не надо будет воротить сразу большим куском данных
— лимит доступа к каждому серверу позволит нормально отдавать файлы большинству пользователей и только 1-2% отрезать в случае если группа из серверов не большая и пришедший трафик из-за падения одного сервера не влезает размазанно по всем серверам.
— потом в фоне постепенно можно сделать третью копию файлов у которых в связи с отключением сервера стало копий меньше трёх. опять таки в размазанной нагрузке эти файлы можно слить по чуть-чуть с каждого сервера, а не создавая крайне не ровную нагрузку на 1-2 сервера.
А вариант с Ceph RadosGW не рассматривали? Вроде как оно распределенное и объектное и S3-совместимое.
Я могу проще про все что выше написано:
Мы не читали теорию!
Мы не читали документацию!
Мы не придумали архитектуру!
Мы вообще не думали!
Господа любой кто изучал реляционную алгербу и реляционные СУБД не когда никогда не будет НИЧЕГО КЛАСТЬ в BLOB базы данных. Это просто по архитектуре так. Это вот натурально из авиационной инженерии:
С мощным двигателем взлетит даже телега
Вот у вас так же.
Я бы сразу сказал, что ребят вам нужна документ-орентированая БД. В итоге всего три года потребовалось на понимание этой простой вещи. Как и то что в вашем случае нафиг не нужна сильная консистентность системы.
Ну и в заключение я оставлю эту картинку здесь
Увы но она соответствует вашим телодвижениям.
Мы не читали теорию!
Мы не читали документацию!
Мы не придумали архитектуру!
Мы вообще не думали!
Господа любой кто изучал реляционную алгербу и реляционные СУБД не когда никогда не будет НИЧЕГО КЛАСТЬ в BLOB базы данных. Это просто по архитектуре так. Это вот натурально из авиационной инженерии:
С мощным двигателем взлетит даже телега
Вот у вас так же.
Я бы сразу сказал, что ребят вам нужна документ-орентированая БД. В итоге всего три года потребовалось на понимание этой простой вещи. Как и то что в вашем случае нафиг не нужна сильная консистентность системы.
Ну и в заключение я оставлю эту картинку здесь
Увы но она соответствует вашим телодвижениям.
Можете сделать развернутый ответ (или статью)?
в этом нет иронии или критики. Просто интересно. Люди написали ситуацию, проблемы и решения. Вы говорите что решения в корне неверные, дайте направления куда копать для других, что бы они не повторяли ошибок.
Например:
«Использование ДОБД „имя БД“ дает результаты XY при нагрузке Z, при этом параметры А, B равны С и D.
в этом нет иронии или критики. Просто интересно. Люди написали ситуацию, проблемы и решения. Вы говорите что решения в корне неверные, дайте направления куда копать для других, что бы они не повторяли ошибок.
Например:
«Использование ДОБД „имя БД“ дает результаты XY при нагрузке Z, при этом параметры А, B равны С и D.
Всего через 5 лет у меня спрашивают :)
РСУБД не предназначены для хранения файлов. То что там есть blob не говорит о том что стоит туда класть файлы.
Направления просты, выбирайте решения по тому, что у вас важное и почитайте обзорную статью по различным базам данных.
Например тут
https://proglib.io/p/11-tipov-sovremennyh-baz-dannyh-kratkie-opisaniya-shemy-i-primery-bd-2020-01-07
И только потом думайте что использовать.
Гхм, Isilon наше все :-)
Ребят, размеры-то смешные, in-memory кэши ныне пожирнее бывают. 10TB это фактически 1 современный диск, который можно поставить на стол или 10 не-современных дисков. Если тирить хотзоны, так вообще все локальное и по-домашнему уютное.
У меня в 2012-2016 проект рос примерно такими же темпами (сейчас тоже восемь серверов по 12 дисков в каждом; ~100Tb*3; ~10млрд картинок; запросов поменьше ~20млн/день).
Но в 2012 попалась статья о том, как хранятся картинки в YouTube.
А хранятся они там как записи в BigTable.
Чанки, версионирование, сжатие, удаление… практически всё к чему вы в итоге пришли, готовое.
В 2012 уже были три opensource клона (Hbase, Accumulo, Hypertable)
минусы такие:
1. при поломке одного из серверов, или даже всего лишь одного диска, чанки несколько минут распределяются между оставшимися серверами; хранилищ стало два, на том же железе, на kvm-виртуалках. Одно поменьше, восстанавливается за секунды.
2. большой сетевой траффик между HDFS-датанодами и таблет-серверами (можно упереться в гигабитную сетевуху при 100-300мбит общего чтения из хранилища); с этим можно бороться, например, сохраняя картинки одного 'сайта' рядом друг с другом.
Сейчас бы наверное посмотрел на Cassandra.
Но в 2012 попалась статья о том, как хранятся картинки в YouTube.
А хранятся они там как записи в BigTable.
Чанки, версионирование, сжатие, удаление… практически всё к чему вы в итоге пришли, готовое.
В 2012 уже были три opensource клона (Hbase, Accumulo, Hypertable)
минусы такие:
1. при поломке одного из серверов, или даже всего лишь одного диска, чанки несколько минут распределяются между оставшимися серверами; хранилищ стало два, на том же железе, на kvm-виртуалках. Одно поменьше, восстанавливается за секунды.
2. большой сетевой траффик между HDFS-датанодами и таблет-серверами (можно упереться в гигабитную сетевуху при 100-300мбит общего чтения из хранилища); с этим можно бороться, например, сохраняя картинки одного 'сайта' рядом друг с другом.
Сейчас бы наверное посмотрел на Cassandra.
За 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
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
Объемы хранилища? Есть же:
36066 GB used, 23074 GB / 59140 GB avail
OSD 33 штуки
Релика левел 2. Но думаем переходить на 3. Вопрос в финансировании пока.
36066 GB used, 23074 GB / 59140 GB avail
OSD 33 штуки
Релика левел 2. Но думаем переходить на 3. Вопрос в финансировании пока.
взрослые парни просто не допускают, чтобы нагрузка на сервера у них превышала 30%
Правильно ли я понимаю, что по мнению автора статьи взрослые парни не допускают выкидывать менее 70% ресурсов серверных систем на ветер? Если это — красочная метафора, не мог бы автор пояснить её смысл?
Потому что когда датацентры борятся за доли процентов эффективности, где-то, возможно, всё совсем не так.
Вопрос вдогонку.
Я несколько раз прочитал про то, как вы уперлись в один гигабит пропускной способности сети. Это всё, конечно, было бы интересно и поучительно, окажись ваш опыт на десять лет раньше.
Можно было бы сказать: «Ага, автор говорит про нищебродство, так в 2008 10Г карточки и правда еще \»не очень\"." Хорошо, тогда 2х1Г, 4х1Г. Но вы же про 2012-2015гг, когда 10Г интерфейс дёшев. Или 2х-4х10Г.
Как у вас получилось не смасштабировать сеть? Или у вас НЕ получилось смасштабировать сеть, и за сухим «достижением предела пропускной способности» стоят десятки бессонных человеконочей?
Я несколько раз прочитал про то, как вы уперлись в один гигабит пропускной способности сети. Это всё, конечно, было бы интересно и поучительно, окажись ваш опыт на десять лет раньше.
Можно было бы сказать: «Ага, автор говорит про нищебродство, так в 2008 10Г карточки и правда еще \»не очень\"." Хорошо, тогда 2х1Г, 4х1Г. Но вы же про 2012-2015гг, когда 10Г интерфейс дёшев. Или 2х-4х10Г.
Как у вас получилось не смасштабировать сеть? Или у вас НЕ получилось смасштабировать сеть, и за сухим «достижением предела пропускной способности» стоят десятки бессонных человеконочей?
Почему выкидывать? Нагрузка на сервер, это один из многих параметров, которые необходимо учитывать.
Вот к примеру у меня есть система, в которой при нагрузке более 60% latency начинает взлетать чуть ли не экспоненциально. К счастью в этой системе это не критично, но неприятно, так как в худшем случае ждать запуска задачи иногда приходится в несколько раз дольше, чем она будет выполняться (характер нагрузки — пакетный).
Недавно на хабре в комментариях видел пример, где система работала под нагрузкой процентов в 90, но там поток задач был равномерен, одинаков и известен, по этому задержки были приемлемыми и не взлетали в небеса.
Другая сторона медали — резервирование.
Если у Вас есть кластер из 2 нод, то загружать каждую более чем на 50% категорически нельзя, ибо в случае выхода из строя одной из них вторая умрет от перегрузки.
Если ноды 3, то предел загрузки каждой из них — 2/3, если мы хотим пережить отказ одной ноды без падения.
Третья сторона — рост системы. Новое оборудование прирастает обычно дискретно, а нагрузка может увеличится непредсказуемо и нужно держать оперативный резерв для прохождения пиков или просто роста аудитории.
И это далеко не все стороны, которые могут учитываться в реальной задаче и зависеть от загрузки оборудования.
Если сложить все это вместе, то вполне может оказаться, что в какой-то системе эти 30% загрузки — это и есть максимальная эффективность, при которой можно оказывать качественный сервис и еще одна доля процента экономии приведет к краху.
Вот к примеру у меня есть система, в которой при нагрузке более 60% latency начинает взлетать чуть ли не экспоненциально. К счастью в этой системе это не критично, но неприятно, так как в худшем случае ждать запуска задачи иногда приходится в несколько раз дольше, чем она будет выполняться (характер нагрузки — пакетный).
Недавно на хабре в комментариях видел пример, где система работала под нагрузкой процентов в 90, но там поток задач был равномерен, одинаков и известен, по этому задержки были приемлемыми и не взлетали в небеса.
Другая сторона медали — резервирование.
Если у Вас есть кластер из 2 нод, то загружать каждую более чем на 50% категорически нельзя, ибо в случае выхода из строя одной из них вторая умрет от перегрузки.
Если ноды 3, то предел загрузки каждой из них — 2/3, если мы хотим пережить отказ одной ноды без падения.
Третья сторона — рост системы. Новое оборудование прирастает обычно дискретно, а нагрузка может увеличится непредсказуемо и нужно держать оперативный резерв для прохождения пиков или просто роста аудитории.
И это далеко не все стороны, которые могут учитываться в реальной задаче и зависеть от загрузки оборудования.
Если сложить все это вместе, то вполне может оказаться, что в какой-то системе эти 30% загрузки — это и есть максимальная эффективность, при которой можно оказывать качественный сервис и еще одна доля процента экономии приведет к краху.
Всё сложно.
Вы серьёзно просите что-то сделать со статьёй, которой без малого год? Бесполезно же, разошлась везде уже именно в этом варианте. Да и комментарий с этой просьбой, который тут останется, будет намекать.
P.S. dsimonov просил удалить упоминания setup.ru из статьи, но затем изменил комментарий.
Каких только кадавров не придумают люди, вместо того чтобы просто использовать ZFS.
Спасибо за интересный пост.
Ужасно смешно было читать, как крутые сталкеры в продакшене запихивали файлы в PostgreSQL.
Это же такая древняя и любимая разработчиками «мясорубка»!
Еще в 2001 году помню ноги ломали на смешных объемах 100GB и 7М файлов.
Ужасно смешно было читать, как крутые сталкеры в продакшене запихивали файлы в PostgreSQL.
Это же такая древняя и любимая разработчиками «мясорубка»!
Еще в 2001 году помню ноги ломали на смешных объемах 100GB и 7М файлов.
внимательно прочел 2 раза. не убедил доклад. все же надо теорию знать.
посоветую статьи Stefan Radtke о IsilonSD Edge
или переведенное на русский Прозрачное облачное многоуровневое хранилище на базе Isilon CloudPools
кстати, IsilonSD Edge для хранилищ до 36 ТБ — безплатный.
посоветую статьи Stefan Radtke о IsilonSD Edge
или переведенное на русский Прозрачное облачное многоуровневое хранилище на базе Isilon CloudPools
кстати, IsilonSD Edge для хранилищ до 36 ТБ — безплатный.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опыт построения и эксплуатации большого файлового хранилища