распределенное файловое хранилище (nginx, zfs, perl)....

Распределенноефайловоехранилище(Nginx, Perl, ZFS)

Mons AndersonОлег Мамонтов

NAS, SAN or custom?

SAN: FC/iSCSINAS: NFS/CIFS/...Custom: *

Что нам нужно?

– отдавать данные– по протоколу HTTP

HTTP это nginx ;)

Что нам нужно?

User → nginx → SAN ?User → nginx → NAS ?User → nginx → nginx ?

Стоимость решений

Nginx: $NAS: $$SAN: $$$$$$$

Наше хранилище

8 U, 24Tb4 x ( 2U, 6Tb ( 2+10 Tb raw )

4 x redundancyfor each file

Что нам нужно от хранилища?

CRUD!(Create, Read, Update, Delete )

Read → HTTPC, U, D → ?

Read → HTTPC, U, D → HTTP!

WebDAV

– Простой– Прозрачный– Поддерживаемый в nginx*– Легко реализуемый

* WebDAV + ACL

Patch:– X-ACL: 0644– X-Time: 1234567890

Step by step: Front

nginxC

Storage

storageN/2

N Tb =

Storage

storage

Front hash

Storage

storage

Front hash

storage

Storage

storage

Front hash

storage

Storage

storage

Front hash

storage

Resizer

storageimage_filter()

Front hash

storage

Resizer

storageimage_filter()

Front hashLowCPU

storage

Resizer

storage

FrontResize

ResizeResize

storage

Hashing

storage

Front HashResize

ResizeResize ?

storage

Hashing

storage

ResizeResize

ResizeScaleHash(time,id)

Hashing

URL: http://…/ObjectIDObjectID = (xxx)-(xxx)-…

ID Time

Hashinga

FF Timeline

past upgrade over futurestart

Hashing

TimeHash(Time) {0x0000 - 0x00FF � [ a, b ]0x00FF - 0x02FF � [ a, c, d ]0x02FF - 0x0FFF � [ c, d ]0x0FFF - 0xFFFF � [ f ]

} � groups

Hashing

IDHash(ID, groups) � group

Hashing

TimeHash(const Time) = constIDHash(const ID, groups) = const

Access Control

ACLDstorage

storagegroup ACLD

Perl:- AnyEvent::HTTPD- AnyEvent::HTTP- AnyEvent::DBI

Access Control: Public object

→ GET /XXXPerl handler (check perms)

← 200 OK

Access Control: Protected object� GET /XXX� Perl handler

� X-Accel-Redirect: /access/...� GET /access/...� proxy_pass http://ACLD � X-Accel-Redirect: /int/..� GET /int/..

� � 200 OK

Result?

Front Resize Storage ACL

2+2=4, 2+2=4, 2+2=4, …

Front Resize Storage ACL!CPU

Cache?

Cache…

Front Cache Resize Storage ACL

Cache is a problem :(

/cacheproxy://resize

/source/?q=/i/AxB

/iproxy://store

resize()

/internal200 OK

/iproxy:

//storage

/i/AxB

/iproxy://cache

/i/AxB /sourcehandler()

XAccel: /cache/i/AxB+(mtime:ctime:status)

/i/AxB+

/source/?q=/i/AxB

cachestore

200 OK HIT

/sourcehandler()

/source/?q=/i/AxB+

XAccel: /int

200 OK200 OK200 OK

Front Cache Resize Storage ACLD

Combine?

MEM CPU HDD

Combined! Money are saved :)

Deployed on same hosts

Full resource consumption

Combined, but scalable!

Cachecluster

Cache Resize Storage+

Resizecluster

Storagecluster

Create, Update, Delete?Storage group

storage

PUTDELETEOPTIONS

Temporary lossStorage group

storage

PUTDELETEOPTIONS

Flashing errorStorage group

storage

No file? Ask a friend!Storage group

storage

404fallback proxy_pass

404 Fallback: avoiding recursionStorage group

storage

GET ask next…

unlessasked

404 FallbackStorage group

storage

Just...

proxy_next_upstream http_404

Again about PUTStorage group

storage

How about single PUT?Storage group

storage

PUTDELETEOPTIONS

ZFS«replication»

Приоритеты выбора решения● Надежность / избыточность хранения

● Производительность чтения и записи

● Возможность распределения нагрузки

● Потенциальная масштабируемость

● Стандартные аппаратные компоненты

● Простота в настройке и обслуживании

Традиционная работа с дискомФайловая система

Файловая система

Менеджер томов

RAID контроллер

Дисковые устройства

Имя <=> объект (inode)

объект <=> LBA тома

LBA тома <=> LBA RAID

LBA RAID <=> LBA диска

Rampant layering violation ;)

Файловая система (zfs)

Модель агрегации (zpool)

Дисковые устройства

stripe / mirror / raidz / ?

stripe – быстро, дешево, ненадежно

mirror – быстро, надежно, дорого

raidz – относительно надежно, недорого, медленно :(

Универсального решения нет :(

Конфигурация Объем, GB IOPS

stripe 1 x 100 10000 20000

mirror 2 x 50 5000 20000

raidz 1 x ( 99 + 1 ) 9900 200

raidz 5 x ( 19 + 1 ) 9500 1000

raidz 33 x ( 2 + 1 ) 6600 6600

Дано: 100 дисков по 100GB, 200 IOPS

Наше хранилище — 6TB / 2U2U: 2 x 500MB + 10 x 1TB, SATA-2

mirror raidz1 raidz1 raidz1

stripe

Будущее уже наступило!

snapshot

мгновенный снимок

(cow - быстро, дешево)

rollback

откат файловой системы

на заданный снимок

“альтернативная реальность”

(ветка из снимка)

дамп снимка

(полный или разностный)

receive

воссоздание

снимка из дампа

“Почти” репликация1. Создание мгновенного снимка (snapshot)2. Получение инкрементального дампа (send)3. Пересылка дампа на целевую машину (socketpipe)4. Восстановление дампа на целевой машине (receive)5. Создание клона файловой системы (clone)6. Переустановка символической ссылки (link -fhs)7. sleep && goto п.1;

Неочевидные нюансы

Зачем нужны клоны и символические ссылки?

Удаление старыхснимков и клонов

● Минимизация лага репликации

● Мониторинг актуальности

● Уникальные имена файлов при обновлениях

● Двухуровневое кеширование

Олег Мамонтов <lonerr@cpan.org> Рамблер Интернет Холдинг

распределенное файловое хранилище (nginx, zfs, perl)....

Technology

tarantool как платформа для...

ихаил Ширяев инженер по...

О.В.Сухорослов "Распределенное...

Отказоустойчивая обработка 10m...

Файловое хранилище hitachi nas 3090....

Главная / Файловое...

распределенное файловое...

Файловое хранилище hitachi nas 3080....

playmarket 2.0 whitepaper · Архитектура...

Файловое хранилище hitachi nas 3200....

ekbpy'2012 - Данила Штань -...

Асинхронное распределенное...

Ф.А. Перепелица Эффективная...